1000本突破
1000本突破

システム開発が失敗する3つの原因。失敗する割合も紹介

Akemi

こんにちは、LIGのAkemiです。LIGでは、Web制作、マーケティング支援の他、「BiTT開発」というオフショア開発事業にてシステム・アプリ開発のご支援もさせていただいております。クライアント様からオフショア開発って失敗しないの? と聞かれることが多々ありますが、国内・オフショア問わず、残念ながら失敗してしまうITプロジェクトには共通点があります!

プロジェクトが上手くいかず、不安や、お悩みをお持ちのシステムご担当者様は、ぜひ読んでみてください。

ITプロジェクトの半分が失敗する?!

ビジネスにおけるIT活用の重要性から、多くの企業が持続的にITプロジェクトに取り組んでいます。特に、十数年前に構築された、レガシーシステムの刷新は、「やらなければいけないとは思っているが、なかなか一歩が踏み出せない」といったお話しも伺います。

その理由を裏付けているとも言えるのが、プロジェクトが成功する割合を算出したデータです。
「ITプロジェクトの成功」を、当初予定していたQCD(品質・予算・納期)の順守とする場合、成功率は52.8%という数字が出ています(参照:ITプロジェクト実態調査2018)。

なんと……半分が失敗しているんです。

ちなみに、大規模な国際調査である Standish Group による CHAOS Report では、成功率は31%とされています。(参考: CHAOS 2020: Beyond Infinity Overview. January’2021, QRC by Henny Portman)

な、なんと……7割が、失敗している。

この結果をみると、大規模な基幹システムの刷新は、確かに躊躇したくなる数字ですね。

一つでも当てはまったら要注意!失敗の原因はこれです

また、ITプロジェクト実態調査2018によると、成功率は年々改善されているものの、失敗の原因は今も昔もかわらないという結果もでています。では、その変わらない失敗の原因とはなんなのでしょうか? よくある失敗談からまとめてみましたので、チェックしてみてください。

コミュニケーション不足

要望をきちんと引きだぜず、要件定義が不十分

要件定義は、課題や要望を把握して、解決策となるシステムの内容を具体化する非常に重要なステップです。後工程で要件の追加や変更が頻発し、多くの手戻り作業の発生を防ぐためにも、多くのケースで決定的に足りないのは、要望を引き出すヒアリング力。

依頼者の要望をそのまま受け入れて開発すると、往々にして役に立つシステムになりません。「なぜその機能が必要なのか」という観点で要望を検証し、要件を決めていくことが開発を成功へ導く近道になります。

開発チーム内のコミュニケーションが取れていない

開発で最も重要視すべき点は「コミュニケーションの問題」です。国内・海外問わず、「伝えたいことを正しく伝える」にはお互いの努力が必要ですし、正しい情報が正しく伝わらないと間違った認識のまま開発が進んでしまう恐れがあり、そうなると成果物が仕様とはかけ離れていたり、修正を何度も繰り返す必要が出てきたりとリスクが大きくなります。

このような悪循環にならないためにも、チーム内のコミュニケーションの問題点を事前に把握し、定期的な進捗管理でプロジェクト完了率を確認し合いながら、開発を進めていくようにしましょう。

情報不足

作業工数を算出する見積もりの根拠となる情報が不足している

作業工数に対する見積書作成は責任の重い業務です。予算や納期、品質に関わる特記事項はすべて見積書に記載されている内容をもとにプロジェクトが進みます。

見積もりの失敗は、プロジェクトの失敗に直結します。見積を失敗してしまう理由の多くは、先に述べた要望をきちんと引き出せず、今ある情報で作業工数を見積もってしまうケースです。また、作業工数は、開発メンバーのスキルと実行できる作業量によっても左右されますので、事前に開発メンバーのスキルに関しても情報収集をしっかりと行い、工数の計算をしましょう。

業務を理解せず、勘や経験で工数を見積もっている

見積もりを求められる段階では、依頼者が最終的な納品物のイメージを正確に描けていないことが多いです。正確に描けていない納品物に対して、勘や経験で見積もってしまうのは危険。

エンジニアなどのスペシャリストがヒアリングを実施し、発注者のアイデアを現実的な要求・要件として分解すると同時に、調査期間を設け依頼者の業務を理解することで、見積もりの精度を向上させましょう。

開発体制

機動的かつ迅速に対応できる体制が構築できていない

開発要件に対して、しっかりと体制を組んでいたつもりでも、急な仕様変更が生じて失敗してしまった経験はありませんか? 要求が頻繁に変わる可能性がある場合は、仕様変更を予測して、最初から対応しやすい設計や体制にしておく必要があります。

言われた通りの開発ではなく、要件定義から設計、開発まで、自律的に動けるように、お互いに協力し、常に連携を意識することが大切です。

テストを軽視してしまう

システムに何か問題があった場合、日本は「作った側に問題がある」と考える傾向が強いため、テスト工程を省略してしまったり、確認すべき事項を確認しないままテストが終わってしまったり、結果として不具合を見逃してしまうことがあります。

テスト条件やテスト観点を曖昧にせず、確認したい内容は何なのか、確認すべき結果が出力されるまでの作業手順や期待値、合格ラインなど、しっかりとテストケースでチェックしましょう。

成功率を100%へ導くには?

成功率が たとえ、80%でも 10% でも、100%でない限りは、プロジェクト予算や人々の労力が無駄になっているという事実には変わりがありません。ITプロジェクトは、経営やマネジメントに直結します。失敗の原因に一つでも当てはまったら、一つひとつ課題をクリアにしながら開発を成功へと導きましょう。

ポイントが多すぎてやっぱり不安だなぁという方もいらっしゃるかと思います。ご相談ベースでも構いませんので、気軽にお声がけください!

オフショア開発について相談してみる

サービス紹介資料ダウンロード

「BiTT開発」導入事例

 

▼BiTT開発について詳しくはこちらから!