デスマーチを生み出してしまう要因として、ヒアリングの甘さや見積もり精度の低さなどが挙げられますが、人的な原因として担当者の『楽観主義』があります。今回はデスマーチとこの楽観主義の関係性について事例を交えて解説していくことにしましょう。
手慣れたパッケージだと曖昧な契約締結しデスマーチへ
主に製造業へのパッケージ導入を得意とするSIerのA社は、サービス業を展開するC社からシステム改修案件の打診を受けます。
C社の打診内容は、自社の既存システムでは膨れ上がる業務情報の処理が滞りがちになっているため、ハードウェアも含めて業務システムを改修したいといったものでした。A社にしてみれば手慣れた内容の案件であり、特に問題となる点も見受けられなかったため、取り扱うパッケージを部分的に導入しながらのシステム改修を提案します。
A社はこのパッケージ導入に関して豊富な実績とノウハウを有しており、特に細かい見積もりやヒアリングを行わなくても、大枠の予算や工期にズレは生じないであろうという楽観的な予測の元、提案をしてしまいます。
ただ一つ、C社の業務要件が変更になる可能性がある点について若干の不安がありましたが、パッケージの機能の中で十分吸収できると考えたA社は、業務要件が変更されたときの取り決めを深く掘り下げないままに、契約を締結してしまったのです。
予想を上回る変更が発生しデスマーチ化
いざパッケージの導入と追加開発がスタートすると、C社の業務内容はこれまで経験したクライアントと大きく異なるうえに、打ち合わせの度に変わる業務要件に翻弄されてなかなか仕様が固まりません。
パッケージのどの部分を適用するのか、適用したとしてチューニングやパラメータ設定はどのように行うのかといった部分が一向に進まず、当然のことながら周辺の改修や追加開発も手つかずのまま時間だけが過ぎて行きます。
プロジェクトの開始に合わせて集めた人員も、ろくな成果をあげないままリリースの時期を迎えてしまい、やっと仕様が固まったころには開発チームは圧倒的な人手不足に陥ってしまいました。
当然プロジェクトはデスマーチとなり、顧客の業務要件を最後まで吸収しきれないまま、ほんの1部分をパッケージの機能に置き換えることが精一杯となってしまったのです。
C社にしてみれば期待をはるかに下回る中途半端なシステムが手元に残り、A社は時間と人員のコストだけが嵩んで赤字を計上し、誰もが得をすることなくプロジェクトは幕を閉じました。
「ノウハウ」と「実績」にあぐらをかいた楽観主義
システム開発の現場においてノウハウや実績はとても大切なことです。特にパッケージ導入のようにある程度の大枠が決まっているシステム開発では、「この要件ならばパッケージの機能で吸収できるはず」という楽観的な見方から、顧客との細かい調整を省くことも可能です。
これはパッケージ導入のメリットでもあるため、一概に悪と断じることはできません。
しかし当初の予定や仕様は、変更されるためにあると言っても良いほど頻繁に変化するのがIT業界におけるシステム開発。特に基幹業務システムに手を加えるとなると、工期は数カ月から数年になることもあり、その間に顧客の要件は変わっていくでしょう。
現代のビジネス環境はめまぐるしい速さで変化を求められるため、SIerも過去の実績とノウハウに依存していては方向性を見失ってしまうことになりかねません。
ノウハウと実績から生み出すべきものは「楽観主義」ではなく、「先見性」です。
今後起こりうる仕様変更のパターンに対応できる下地作りこそが、デスマーチを防ぐための重要な礎となることを認識しておく必要があります。
エンジニア個人としても、今自分が担当しているシステムがどの程度変更に耐えられるものなのか、今一度再確認しておくことで、将来のデスマーチを防ぐことに役立つでしょう。
デスマーチについては、ヒアリングの重要性やヒアリング手法も過去にご紹介しています。合わせて参考にしていただき、デスマーチの発生を未然に防いでください。
デスマーチに関して、こんな記事がよみたい！などご要望がありましたら、ぜひご意見をお願いいたします。編集部にて検討させていただきます。
invalid URL
