2016.04.17

開発プロジェクトを遅延・失敗に導く可能性が高い8つのパターン

kuni

5年ぶりに伸ばしていた髪をバッサリ切って短髪気味にしたら、爽やかさが(自称)5割増になった代表の国本です。

さて、先月セゾン情報システムズが大型プロジェクトの開発遅延により約150億円の和解金支払い方針が決定というニュースが業界では大きく取り上げられていましたが。

ここまで大規模なプロジェクトは極端にせよ、大なり小なり開発プロジェクトには納期の遅延や、全く使いものにならないシステムが出来上がってしまういわゆる「炎上プロジェクト」は枚挙に暇がありません。

そこで今回はこれまでの私の経験値(実体験？)から、開発プロジェクトを遅延や失敗に導いてしまう可能性が高いパターンを8つ程あげてみようと思います。

Contents

パターン1．ゴール・ビジョンについてメンバー間で共通認識を持てていない
パターン2．社外・社内含めてステークホルダーが多すぎる
パターン3．必要なスキルセットを保持したチーム構成となっていない
パターン4．マルチベンダー体制で、かつ利害関係が複雑化している
パターン5．プロジェクト契約があいまい
パターン6．丸投げ体質でコミット意識が低い(俗に言う「いい感じに」)
パターン7．会議・進捗管理が形骸化している
パターン8．成果物に対する品質を担保できていない
まとめ

パターン1．ゴール・ビジョンについてメンバー間で共通認識を持てていない

新たに開発を行うシステムやリプレースを行うサービスが、どのようなビジョンを掲げ、最終的にどのようなゴールを目指しているのか？このもっとも重要な本質部分を実開発に携わるプロジェクトメンバーレベルまで全員できちんと理解せずに開発を進めた場合に、全く使えない代物が出来上がってしまう可能性が非常に高いです。

パターン2．社外・社内含めてステークホルダーが多すぎる

「この連携仕様はxx部の〇〇さん」「この業務については△△部の□□部長」など、システムの仕様やサービス設計にあたり非常に多くのステークホルダーが絡み、かつ関係が複雑で外部からの指示系統も複数あるようなプロジェクトの場合、関係各社の調整コストが膨れ、結果的にスケジュールを圧迫させる大きな要因となります。

パターン3．必要なスキルセットを保持したチーム構成となっていない

開発サービスや、リニューアルのシステム特性に応じたシステム・アーキテクチャを適切に検討・設計・実装できるメンバーでチーム構成せずに、単純に自分たちの実績や知見ベースでのみでしか考えないような形で開発を進めているプロジェクトの場合、本来ゼロベースで開発する必要がなかった汎用的な機能を実装してしまったりするなど、不要なコスト・工数が膨らみ、プロジェクトの失敗要因となり得る場合があります。

パターン4．マルチベンダー体制で、かつ利害関係が複雑化している

商用プロダクトを多数投入するケースや、比較的大きめの規模のプロジェクトにおいて、複数のベンダーが責任分界点を引いてプロジェクトに参画するようなマルチベンダーでの開発プロジェクトとなる場合があります。

多数のベンダーが絡むプロジェクトでは、必然的に複雑な利害関係が生まれやすく、プロジェクトのゴールを目指すのではなく、各ベンダーが自社の売上と利益を第一優先に考えやすく、本来目指すべきプロジェクトのゴールとかけ離れた方向に進む要因となり得ます。

パターン5．プロジェクト契約があいまい

これはユーザーとベンダーがお互い初見の場合に発生しやすいパターンですが、プロジェクトの開始前に開発成果物やテスト方式、品質定義、検収条件などにおいて、両社間できっちりと話し合いを行わずに信頼ベースでプロジェクトがスタートしてしまい、プロジェクトが進むにつれ、両社の意識の乖離が明らかになり最終的に成果物に掛かるコストや納期遅延の大きな要因となります。

パターン6．丸投げ体質でコミット意識が低い(俗に言う「いい感じに」)

これは、発注するユーザ側や、いわゆる多重下請け構造下の上位ベンダー側によく見られると思いますが、開発プロジェクトに対しての当事者意識が低く「なんとなくいい感じに」と丸投げした結果、プロジェクト内での適切なリスクヘッジや、コントロールがなされず、開発納期が大幅に遅れ、コストが増大する要因となります。

パターン7．会議・進捗管理が形骸化している

特に明確な根拠・必要性もなく週次で関係者全員を集めての定例、資料を読み合わせるだけの会議、開発状況を正確に見える化せず、エクセルを塗り絵しているだけのWBSなどが横行している現場では、形骸化した会議や進捗管理に工数が割かれ、ほんとうに危険な進捗アラートを見落とし、品質問題やスケジュール遅延を誘発する要因となります。

パターン8．成果物に対する品質を担保できていない

初期段階での設計レビュー・コードレビューなどがスケジュール的な要因やスキルセット不足で未実施の場合。また、テストコードの不足やソフトウェア品質の見える化などの基準が曖昧なプロジェクトでは、プロジェクトの後半でバグや品質問題が顕在化するケースが多く、納期の遅延や開発コストの増大を発生させる大きな要因となります。