システム開発プロジェクトでありがちな失敗の原因と対策

どんなシステム開発プロジェクトにも失敗のリスクがあります。

どれほどしっかり計画を立ていても、すべてのフェーズにおいて地雷が潜んでいます。

日経コンピュータ（2018年3/1号）によると、「3年を超えるような大規模プロジェクトに限ると、成功率は16％しかない」と言われています。

システム開発プロジェクトはどうしてこれほどまでに失敗してしまうのでしょうか。

この記事では、ソフトウェア開発企業である弊社Rabiloo（ラビロー）の業界知識と経験を元に、開発を請け負う側のベンダー企業、開発を依頼するユーザー企業の双方がリスクをコントロールするために何ができるかを考えていきます。

 

 

システム開発プロジェクトでありがちな失敗事例

以下は開発を受注するベンダーがよく経験する失敗事例です。

• 同じエラーを繰り返し、このバグは修正されたと思っていたが、2か月後に本番環境でまた現れた。
• プロジェクトの最終段階で、チームメンバーが突然辞めてしまい、リリース日が計画よりも遅れてしまった。
• プロジェクトは7ヶ月間行われた。最初の2ヶ月はチーム全体で70％を実行し、6ヶ月目の終わりには80％が完了。しかし最後の1ヶ月に残りの20％を実行できなかった。
• ユーザー企業の仕様通りで実装したはずなのに、納品後クレームが殺到した。完成品が発注者の要求と全く異なっていたため、その機能をバグだと判断された。
• プロジェクトは順調に進み、納期にリリースされたが、支払いの段階で問題が生じてしまった。

このような、失敗の原因はどこにあるのでしょうか。

 

 

システム開発プロジェクトでよくある失敗の原因7つ

そもそも完璧なシステム開発プロジェクトなど存在しません。

むしろプロジェクトには失敗はつきものだと考えたほうが現実的です。どれほどしっかりマネジメントできていると思っても、必ず問題は生じるものです。

では、システム開発プロジェクトでの失敗の「原因」は何でしょうか。以下によくある失敗の原因を7つ取り上げます。

1. 解決すべき問題とプロジェクトの目的が不明確
2. プロジェクトのステークホルダー（利害関係者）を見誤る
3. 計画の作成と更新の不備
4. リスクマネジメントが甘い
5. プロジェクトの範囲、特にフェーズとスコープに対するコントロールができない
6. コミュニケーションがうまくいかない
7. プロジェクトのリソース管理が不十分 

ではそれぞれ詳しく解説していきます。

 

①解決すべき課題とゴールが不明確 

発注者の意図が正確に伝わっていない、ということが原因でシステム開発が失敗するケースです。

要件定義のフェーズで、発注者と開発者の意図がずれてしまうことはこれまでよく生じてきました。

ベンダーは発注者の注文通りに仕上げても、「失敗」とみなされることがあります。

なぜでしょうか。

ここで覚えておかなければならないのは「発注者」とは、直接の窓口となる「IT部門」だけに限定されないということです。

実際のユーザーとなる「業務部門」の意向、そしてシステムに必要な機能の優先順位を最終的に決める「経営者」、そして「IT部門」の3者が、同じゴールに向かってはじめてプロジェクトは成功します。

そもそも、ゴールの設定が経営者の意図とずれているならば、いくらコストと時間をかけても、結局は無駄な機能が盛り込まれたあまり役に立たないシステムが出来上がってしまう結果になってしまいます。

こうした最悪の事態を避けるため、ベンダーは発注者が本当に解決したい課題をしっかり見分けて、経営者と同じゴールに向かってプロジェクトをスタートさせなければなりません。

 

②プロジェクトのステークホルダーを見誤る

ステークホルダー（利害関係者）の認識不足により、プロジェクトは失敗する可能性があります。 ステークホルダーとは、一見するとプロジェクトとは何の関係もないようなものや、製品の品質に影響を与えないような部分も含まれます。

ステークホルダーは単に顧客のことだ、と考えてはいけません。例えば アプリの管理者（CH playやApp store）もステークホルダーの一人です。

プロジェクトのステークホルダー全体を特定することは、システム開発プロジェクト管理において非常に重要です。

まず、ステークホルダーを内部と外部の2つのグループに大きく分けることができます。

グループを分けた後は、部門、組織内のポジション、プロジェクトに対する役割（リーダー、サポート担当者、オブザーバー）などで分けます。 これにより、プロジェクトのゴールを特定し、それぞれの関係者の態度や行動を調整しながらプロジェクトが成功するように計画を立てることができます。

そして、ステークホルダーのリストを記録したドキュメントを作成し、定期的に更新する必要があります。 そのリスト上の名前、肩書き、役割は別々にする必要があります。 なぜなら、ステークホルダーの代わりになれる人がいれば、名前だけを差し替えればよいからです。

また、ステークホルダー・リストの長さは、プロジェクトの規模を評価する上で有効な要素となります。

 

③計画の作成と更新の不備

失敗したプロジェクトはしっかり計画が作成されていたか？

NASAの調査によると、失敗したプロジェクトのほとんどは、計画の不備が原因であることがわかっています。

計画の作成・管理・監視・更新には多くの時間がかかります。 しかし、計画はプロジェクトを常に円滑に実行し続けるための強力なツールです。

計画を立てることで、タスク・人数・タスクの数を制限するだけでなく分解することもできます。 そこから、社内で人員や要件に変更があった場合、人員の動員が容易になります。

プロジェクトの進捗を常に予定通りにするために、変更があるたびに、その変更に対する評価とともに計画を更新することを常に忘れないようにしましょう。

 

④リスクマネジメントが甘い

プロジェクトを成功させるには、リソース、時間、進捗状況、プロジェクトに対するステークホルダーの態度などの要素を要素をうまくコントロールすれば十分だと考える人もいるでしょう。 しかし、それだけでは不十分です。「何がプロジェクトを失敗させる原因になるのか」と問いかける必要があります。

不可抗力に抵抗することはできるのでしょうか。

できます。ある程度のリスクはしっかりコントロールすることができます。

まず、プロジェクトのすべての段階で、リスクを特定し、それから発生する可能性を高いものから低いものまで、できる限り詳細に評価する必要があります。 そして、それぞれのリスクについて、そのリスクがプロジェクトの中で生じた場合の対応策を書いておきます。

このステップをマスターしていれば、プロジェクトが深刻なダメージを受けることはありません。

リスクを特定するには、経験と一般的な知識が必要です。 経験と知識をしっかり蓄積していってください。

 

⑤プロジェクトの範囲、特にフェーズとスコープに対するコントロールができない

多くのシステム開発プロジェクトが失敗しているのは、エンジニアやプロジェクトマネージャーが、プロジェクトのスコープ、スプリント、フェーズ、範囲を理解していないところに原因があります。

さらに、開発の過程において、ステークホルダーは常にソフトウェアが完璧になるように、「機能やインターフェースを変更・追加したい」と考えています。

しかしこれは、うまくコントロールしないと、開発チームがコア機能を担当する時間が足りなくなってしまう結果を招きます。そうなるとソフトウェアは、ユーザー側の最低限のニーズさえ満たせないものとなってしまいます。

そのため、重要なことだけを集中して行うことが失敗を避ける上で重要な鍵となります。 

発注者が仕様変更をたくさん加えようとするのを制限しようとするのではなく、ユーザー側が何を必要としているのか、何を求めているのか、そしてそれがプロジェクトにどんな影響を与えるのかを理解してもらうのが良いでしょう。

まず、プロジェクトチームがスプリント、フェーズ、スコープで何をするかを決定する必要があります。 必ず重要度の高い順にランク付けし、これらのタスクが何の目標を達成するために行われているのかをユーザー企業に確認します。

上記が合意されたあとは、途中で変更または新機能が追加されるたびに、両者は以下の質問を検討する必要があります。 

1. この要件が変更・追加されたのはなぜか。これは本当に意味があり、プロジェクトの当初の目的を達成するのに役立つのか。
2. この要件の優先順位は何か。 実行にはどのくらい時間がかかるのか。 リスクは何か。影響の範囲はどのくらいか。

答えが得られたら、あとは計画を更新し、変更要求を作成するだけです。 そして、通常のタスクのように解決します。

つまり、ユーザー企業とベンダーの開発チームの双方が、この段階で変更をきちんと認識し絶対に必要だと考えていれば、すべてがスムーズに進み、効果率も改善されます。

 

⑥コミュニケーションがうまくいかない

「計画」がプロジェクトを正しい方向に導くための「舵」だとすれば、「コミュニケーション」は成功のプロジェクトに欠かすことのできない「潤滑油」です。

プロジェクトのコミュニケーションには、ユーザー企業とのコミュニケーションと社内でのコミュニケーションが含まれます。 顧客とのコミュニケーションを効果的に行なうことで、プロジェクトに関する誤解を避けることができます。また社内での 効果的なコミュニケーションは、プロジェクトを円滑に進め、軌道に乗せることができます。

では、効果的なコミュニケーションとは何でしょうか。

以下に4つの方法をご紹介します。社内の開発チームだけでなく、ユーザー企業とのコミュニケーションにも適用してください。

• デイリーミーティング：誰も取り残されないようにするため、またPMがプロジェクトの進捗状況を毎日把握できるようにするために、この方法は効果的です。
• 報・連・相：報告・連絡・相談をきっちり行なうことです。要するに、解決すべき問題を適切なコミュニケーション方法で伝え、その問題の解決策を双方で見つけることです。
• 双方向のコミュニケーションの維持：誤解や勘違い、理解不足をなくすために、相手としっかり対話し、理解していても必ず相手に再確認する。重要事項は書面での確認が必要。
• アクティブリスニング：相手の「言っていること」ではなく、「伝えたいこと」を理解します。オフショア開発を行なう場合は、相手との通訳・再確認を行います（上記の双方向コミュニケーションと組み合わせて行なう）

他にも、ボディランゲージを学ぶことや、オープンでフレンドリーな態度でコミュニケーションをとることは、あなたとプロジェクトの双方にとって大きな助けとなるでしょう。

 

⑦プロジェクトのリソース管理が不十分

ここでのプロジェクトのリソースとは、そのプロジェクトに属する人員、資材、施設、設備、資金、ソフトウェア、ドキュメントなどのことです。

例えば、システム開発の場合、プロジェクトの内部に情報セキュリティの仕組みや規定がないと、ハッキングされたソースコードが外部に流出してしまう可能性が高くなります。 

そこから、プロジェクトは一瞬にして失敗し、さらに悪いことに、訴訟や補償を伴うこともあります。

または、プロジェクト予算は増やせないのに、新しい要件や修正要求だけがどんどん増えて、その結果リソースを圧迫し、赤字プロジェクトになってしまう場合もあります。

ドキュメントに関しては、ドキュメントが古くて更新されていなかったり、プロジェクトチームの関係者が入れ替わる間に、失われていることもあります。

これらを管理するには、プロジェクトの開始時に、思いつく限りのプロジェクトリソースをリストアップし、その重要性と状態を「リソース管理」ドキュメントで評価しておく必要があります。そして紛失した場合の修復計画も追加しておきます。

 

 

まとめ

この記事では、システム開発プロジェクトの大半が失敗にいたってしまう本質的な7つの原因について考察しました。

1. 解決すべき問題とプロジェクトの目的が不明確 
2. プロジェクトのステークホルダー（利害関係者）を見誤る
3. 計画の作成と更新の不備
4. リスクマネジメントが甘い
5. プロジェクトの範囲、特にフェーズとスコープに対するコントロールができない
6. コミュニケーションがうまくいかない
7. プロジェクトのリソース管理が不十分 

ユーザー企業とベンダー企業の考えのすり合わせは、非常に難しいですが、最も重要な作業です。

Rabiloo（ラビロー）は日本を始めとして世界中の企業とタッグを組んでプロジェクトを行う、ベトナムのシステム開発企業です。

弊社が請け負うプロジェクトにおいては、本記事で取り上げた失敗の原因をいつも徹底して回避し、プロジェクトをマネジメントしています。

これまで、文化や言語の壁を乗り越えていくつものプロジェクトを成功させてきました。

弊社はクライアントのビジネスパートナーとしてプロジェクトの成功にコミットします。

信頼できるオフショア開発ベンダーをお探しの企業様、ぜひ一度お気軽にお問い合わせください。

お見積り・ご相談は無料です。

お問い合わせはこちらから