LIGでは、オフショア開発事業にてシステム・アプリ開発のご支援をしています。クライアント様からオフショア開発って失敗しないの？ と聞かれることが多々ありますが、国内・オフショア問わず、残念ながら失敗してしまうITプロジェクトが多くあります。
今回は、過去に私が経験したシステム開発の失敗事例を、主に発注者の視点から分析し、プロジェクトが失敗する原因とその対策方法についてまとめました。
プロジェクトが上手くいかず不安やお悩みをお持ちのシステムご担当者様は、ぜひ読んでみてください。
システム開発を依頼できる企業は国内に多数あるため、どの企業に依頼すればいいか迷ってしまいますよね。最初のご相談相手として、業界歴10年以上のベテランPMがプロジェクトに伴走する弊社LIGはいかがでしょうか？
- ベテランPMが事業戦略など上流工程から支援
- ノーコードツール開発により保守運用しやすいシステムを提供
- 125名超の海外人材を活用した多彩な開発体制に対応
「こんなシステムは対応できる？」「まずは見積もりがほしい」などお気軽にご連絡ください。翌営業日以内に折り返しご連絡いたします。
目次
※編集部注:2021年9月に公開された記事を再編集しました。
システム開発における失敗とは何なのか
失敗事例を紹介する前に、そもそも失敗とは何かを明確にしたいと思います。
システム開発が成功したかどうかを判断する基準には、QCDが順守されているかという点があります。
QCDとは、「Quality（品質）」「Cost（コスト）」「Delivery（納期）」の頭文字をとった、物作りに重要な3項目をまとめて指すものです。
事実、システム開発のほとんどが失敗している
ビジネスにおけるIT活用の重要性から、近年では多くの企業がシステム開発に取り組んでいます。特に、十数年前に構築された、レガシーシステムの刷新は「やらなければいけないとは思っているが、なかなか一歩が踏み出せない」といったお話しも伺います。
その理由を裏付けているとも言えるのが、プロジェクトが成功する割合を算出したデータです。
企業IT動向調査報告書 2021 ユーザー企業のIT投資・活用の最新動向によると、500人以上の会社の場合、予定通りの工期で終わったプロジェクトは15.8％、予定通りの予算でおさまったが24.3％、品質に満足しているという回答は18.1％という結果がでています。「成功」の定義を、先ほどお伝えしたQCD（品質・予算・納期）の順守とする場合、これを全て満たしている企業はかなり少ないことがわかります。
ちなみに、大規模な国際調査である Standish Group による CHAOS Report では、成功率は31%とのことです。（参考： CHAOS 2020: Beyond Infinity Overview. January’2021, QRC by Henny Portman）
なんと……7割が失敗しています。この結果をみると、大規模な基幹システムの刷新は、確かに躊躇したくなる数字ですね。
失敗の原因は、今も昔も変わらない
ITプロジェクト実態調査2018によると、成功率は年々改善されているものの、失敗の原因は今も昔もかわらないという結果がでています。
では、その変わらない失敗の原因とはなんなのでしょうか？
次項目では、現場でよくある失敗談をふまえ、その原因と対策方法までをまとめています。
システム開発が失敗する原因と対策方法
要件定義が不十分
私の経験上、要件定義が明確なプロジェクトほど、納期やコストは当初の予定通りに進みます。逆に要件定義が不十分であれば、プロジェクト途中で大きな仕様変更が起こりやすく、結果としてプロジェクトが失敗に終わる傾向があります。
要件定義が不十分になる原因は、開発者側が発注者側の要望をそのまま受け入れて開発してしまうことが多いです。
開発社側は、「なぜその機能が必要なのか」という観点で要望を検証し、要件を決めていくことが開発を成功へ導く近道になります。
なお、発注者側も開発者側に任せっきりになり、細かいチェックを疎かにしてしまわぬよう留意しましょう。機能が必要である背景を説明するなど、齟齬を防ぐためにできることもあるはずです。
要件定義は、課題や要望を把握しシステムの内容を具体化する非常に重要なステップです。後工程で要件の追加や変更が頻発して手戻り作業の発生を防ぐためにも、発注者側と開発者側がしっかりとコミュニケーションをとる必要があります。
開発チーム内のコミュニケーションが取れていない
プロジェクト進行中に最も重要視すべき点は「コミュニケーション」です。国内・海外問わず、「伝えたいことを正しく伝える」にはお互いの努力が必要ですし、正しい情報が正しく伝わらないと間違った認識のまま開発が進んでしまう恐れがあり、そうなると成果物が仕様とはかけ離れていたり、修正を何度も繰り返す必要が出てきたりとリスクが大きくなります。
このような悪循環にならないためにも、チーム内のコミュニケーションの問題点を事前に把握し、定期的な進捗管理でプロジェクト完了率を確認し合いながら、開発を進めていくようにしましょう。
作業工数を算出する見積もりの根拠となる情報が不足している
作業工数に対する見積書作成は責任の重い業務です。予算や納期、品質に関わる特記事項はすべて見積書に記載されている内容をもとにプロジェクトが進みます。
見積もりの失敗は、プロジェクトの失敗に直結します。見積を失敗してしまう理由の多くは、先に述べた要望をきちんと引き出せず、今ある情報で作業工数を見積もってしまうケースです。また、作業工数は、開発メンバーのスキルと実行できる作業量によっても左右されますので、事前に開発メンバーのスキルに関しても情報収集をしっかりと行い、工数の計算をしましょう。
業務を理解せず、勘や経験で工数を見積もっている
見積もりを求められる段階では、依頼者が最終的な納品物のイメージを正確に描けていないことが多いです。正確に描けていない納品物に対して、勘や経験で見積もってしまうのは危険。
特に経験が浅いエンジニアはこのような失敗に陥りやすいので、経験豊富なスペシャリストがヒアリングを実施し、発注者のアイデアを現実的な要求・要件として分解すると同時に、調査期間を設け依頼者の業務を理解することで、見積もりの精度を向上させましょう。
機動的かつ迅速に対応できる体制が構築できていない
開発要件に対して、しっかりと体制を組んでいたつもりでも、急な仕様変更が生じて失敗してしまった経験はありませんか？ 要求が頻繁に変わる可能性がある場合は、仕様変更を予測して、最初から対応しやすい設計や体制にしておく必要があります。
言われた通りの開発ではなく、要件定義から設計、開発まで、自律的に動けるように、お互いに協力し、常に連携を意識することが大切です。
- 💡オフショア開発の場合は特に注意
- 海外人材を活用するオフショア開発では、コミュニケーションをスムーズに取れる体制かどうか発注前にチェックすることが重要です。慣れていないのに英語でコミュニケーションが必要だったり、時差が大きい国だったりすると対応にラグが発生してしまう可能性が高いからです。
日本人ディレクターが窓口となっているところであれば、上記のようなリスクも抑えられます。弊社LIGでも国内のベテランPMや英語堪能なディレクターがチームを組み開発体制を構築しています。アジャイルやラボ型など柔軟な開発体制を構築できるので、どんなことでもぜひご相談ください。
テストを軽視してしまう
システムに何か問題があった場合、日本は「作った側に問題がある」と考える傾向が強いため、テスト工程を省略してしまったり、確認すべき事項を確認しないままテストが終わってしまったり、結果として不具合を見逃してしまうことがあります。
テスト条件やテスト観点を曖昧にせず、確認したい内容は何なのか、確認すべき結果が出力されるまでの作業手順や期待値、合格ラインなど、しっかりとテストケースでチェックしましょう。
プロジェクト管理者のスキル不足
プロジェクトを進める上では、プロジェクトマネジャーの能力や経験が成果に大きな影響を与えます。必要な人員を配置する、要件や仕様の変更があった場合のスケジュール管理、市場変動リスクの管理など、プロジェクトマネジメントはやるべき仕事がたくさんあります。
また、ステークホルダーとのコミュニケーション不足により、プロジェクトの方向性が乖離するなどもよくある失敗例です。
プロジェクト推進において十分なマネジメントスキルがある人物かどうかは、必ずおさえておきましょう。
あるECサイト構築プロジェクトの失敗事例
ここまではシステム開発のよくある失敗例を紹介しましたが、もう一つ、とあるアパレル系ECサイトを構築するプロジェクトで起きた失敗事例について解説します。
- 開発概要
-
- 開発費用：600万円
- 開発期間:6ヶ月
結果的に、システムは稼働したものの、バグが多く、肝心の売上も予定の20％に満たないという結果になりました。なぜこのようなことが起こったのか、その要因を紹介します。
【要因】発注側の事情を考慮しない見積もりであった
前提として、発注側はIT/Webにあまり詳しくない場合がほとんどです。今回の事例も同様で、発注側の担当者はどんな準備が必要で、それにどれくらい時間がかかるのかを全く把握できていませんでした。
その結果、納期1ヶ月を切っているのに管理画面の使用が決まっておらず、また「会社案内」「返品規定」といった必要なコンテンツの作成も全て後手後手に回ってしまいます。急いで作ったことでデザインも納得いくものにはならず、結局、サイトの半分以上を作り直し、納期が半年以上遅れることになりました。
これは、開発側が発注側の事情を考慮できていなかったことで、生じた失敗事例です。
成功のポイント
このような事例を成功させるためには、開発側でコントロールできる部分とそうではない部分を分けて考えることが重要です。
開発側は、「クライアントがコンテンツのアイデアを出す」「クライアントが意思決定する」といった、開発側でコントロールできない項目があることを認識する必要があります。それを踏まえ、事前に発注者側にもやるべきことを伝え、それを見据えた納期を見積もることが必要不可欠となります。
▼さらに詳しく知りたい人はこちら ECサイト構築プロジェクトの失敗事例とその対策方法
安達裕哉
成功率を100％へ導くには？
成功率がたとえ80％でも10%でも、100％でない限りはプロジェクト予算や人々の労力が無駄になっているという事実には変わりがありません。
ITプロジェクトは、経営やマネジメントに直結します。失敗の原因に一つでも当てはまったら、一つひとつ課題をクリアにしながら開発を成功へと導きましょう。
ポイントが多すぎてやっぱり不安だなぁという方もいらっしゃるかと思います。そんな方は、以下でおすすめのシステム開発会社を紹介しています。
実際に仕事をする中で安心して任せられる企業を中心にまとめているので、よければ参考にしてください。
【プロ厳選】おすすめシステム開発会社28社｜目的別に紹介
Michitoshi Kudo
システム開発で大切なのは企業の課題を正しく認識し、解決する最適な方法を提案してくれる会社を選ぶことです。そのためには豊富な経験とスキルを持った人材が多い企業に依頼するのが安心といえます。弊社LIGでは、
- 業界歴10年以上、大手外資系企業で大小さまざまなプロジェクトを担当したコンサルタント
- 数々の世界的アワードを受賞してきた、UIUXにも強いデザイナーチーム
- BubbleやFlutterFlowなどノーコードツールでの開発にも対応
など、ベテランPMや経験豊富なメンバーが貴社のニーズに応じたご提案をいたします。
「とりあえず見積もりをお願いしたい」という場合も気軽にご連絡ください。
