IT業界には「デスマーチ」すなわち「死の行進」と呼ばれる言葉が存在します。エンジニアとして長らくIT業界に身を置いていれば、必ず耳にする機会があるでしょう。デスマーチはプロジェクトメンバーを疲弊させ、プロジェクト自体の失敗や大きな赤字を招くため、結果的に誰も得をすることがありません。今回は、まさに三者一両損であることから社会問題と化しているデスマーチについて具体的な事例を紹介し、それを防ぐためのヒアリング手法についてまとめてみたいと思います。
■目次■
保守フェーズまで含んだ大規模開発案件を受注したA社
SIerのA社は、大手電子機器メーカーのサプライチェーン部門を担う子会社Bから、サプライチェーンを管理するシステム開発案件を受注しました。
しかも開発だけではなく、システムがリリースされたあとの保守フェーズも面倒を見ることになり、まさに上流から下流まで一貫した大型案件となったのです。
不況のさなかで久々の大型受注に社内が色めき立つのもつかの間、社内にはアサインできるエンジニアがほとんどおらず、どう考えても納期に間に合わないことが明らかになりました。
しかしそれでも営業担当者は、この機を逃せばまたしばらくは大型案件を受注できるチャンスが巡ってこないと強く主張し、どうにか帳尻を合わせて欲しいと開発部門に迫ります。
自社の業績が芳しくないことを知っていた開発部門のPMは、それをしぶしぶ了承。
B社に提出する見積書に、書類上だけで計算を合わせた計画を提出してしまいます。
「システム開発、その後の障害対応、運用保守」まで全て面倒を見るという内容で契約を交わし、開発プロジェクトをスタートさせます。
テストフェーズでデスマーチ化
その後しばらくは順調に進んでいたB社の案件が崩れ始めたのは、テストフェーズに入ってからのことです。
外部の協力会社からの寄せ集めで急造された開発チームは、スキルも知識も十分ではないエンジニアが多く、実際に構築されたシステムは仕様の確認漏れからくる不具合の嵐となってしまいました。
特にB社の他のシステムとの連携が全く取れておらず、一から他システムとの連携仕様を固める必要があったのです。
大幅な手戻りを余儀なくされたA社は、自社の社員を総動員して対処するも、圧倒的な時間と人員の不足からプロジェクトはデスマーチ化。
結局納期には間に合わず、その後の「運用保守フェーズ」の部分については契約が取りやめになる事態にまで発展したのです。
最終的にA社、は運用保守フェーズ部分の契約が白紙になったことと、不具合修正に対応する社員を多数動員したことで、多額の赤字を計上するという結果になりました。
デスマーチを防ぐためにはヒアリング段階で要件をなるべくスリムに
SIerのA社がB社から受注したシステム開発案件がデスマーチ化してしまったことの原因は、大型案件であるということに目がくらみ、開発の仕様をしっかりヒアリングしないままにプロジェクトを開始してしまったことでしょう。
テストフェーズのような下流工程でデスマーチが起こってしまう原因として、システムでクリアすべき要件が多すぎるという点があります。
顧客は「全てできます！」と言い切る営業を好む傾向があることは否めませんし、ある程度は融通を利かせなければ、新規の開発案件を勝ち取ることが難しいことも事実です。
しかし入口としては全てを許容しつつも、その後は具体的な要求定義、要件定義を進めていくうえで、顧客からの要求を整理してスリム化しながら要件としてまとめていくことが大切になります。
間口を広くとって、流れてくる水（要求）をできるだけ広範囲で受け止めながらも、ヒアリングでそれを絞り込んで細く濃縮していくイメージです。
下流工程に落とし込んでいくにしたがって、追加要望や仕様変更があるのは開発の常ですから、それをある程度見越したヒアリングが必要になります。
線引きをしっかりと！SLAの作成しながらのヒアリング
テストフェーズになってから、テスト結果レビューのさなか、顧客との間に重大な認識のズレが発覚したことはありませんか？
テストフェースと言えばプロジェクトもいよいよゴール間近という段階。
この段階で認識のズレが発覚すると、短期間で膨大な修正作業や追加作業が発生し、人員も工期も不足するため、高確率でデスマーチ化してしまいます。
特に他システムとの連携テストや、システム全体の動きをリハーサルする統合テストフェーズで認識のズレが発覚した場合は致命的です。
これは多くの場合、ヒアリング後のSLA（サービスレベルアグリーメント）を作成していない、もしくはSLAの詰めが甘いことが原因として考えられます。
今回の件で言えば、A社がB社の他システムとの連携仕様についてどこまで責任を持つのかを、具体的に線引きしておく必要があったのです。
ヒアリングを進めていく上で顧客要望をSLAに落とし込み、さらにそこから自社の責任範囲も明確にして、システム開発における着地点としておくことが、下流工程をデスマーチ化させない方法です。
今回のような事例は、よく見聞きする状況ではないでしょうか。今後は、自分の為にもヒアリング段階から注力することをおすすめします。デスマーチをなくす仕事術では、要件定義の重要性についても解説しています。合わせて参考にしてみて下さいね。
invalid URL
