業務システム受託開発、失敗しないための進め方——なぜ「小さく作って試す」のか

中小企業のデジタル化は着実に進んでいる。デジタル化の取組が「業務効率化やデータ分析」「ビジネスモデルの変革」といった段階まで進んだ企業の割合は、2019年時点では2割に満たなかったのに対し、2022年時点では3割を超えた（中小企業庁「2023年版中小企業白書」）。一方で、システム導入・刷新のプロジェクトのうち、コスト・納期・満足度のいずれかを満たせず「失敗」に終わったものは47.2%——約半分にのぼるという調査もある（日経コンピュータ「ITプロジェクト実態調査2018」、1,745件対象）。

システム化に取り組む会社は増えているのに、なぜ約半分が思うようにいかないのか。liensが受託開発で採っているのは「一番困っている業務を1つ選び、小さく作って、試しながら作り上げる」という進め方だ。要件を最初にすべて固めてから一括で発注する従来型の進め方と比べて、なぜこちらが有効なのか、データで具体的に見ていく。

要件定義工程の見落としを要件定義工程のうちに見つけた場合の手戻りコストを1.00とすると、基本設計2.30倍、パッケージ設計5.90倍、プログラム設計6.38倍、プログラミング9.33倍、統合テスト11.86倍、システムテスト13.09倍と後工程になるほど跳ね上がる — 要件定義の見落としは、気づくのが遅れるほど直すコストが跳ね上がる（出典: IPA「ユーザのための要件定義ガイド第2版」事例をもとに作成）

要件定義の見落としは、あとになるほど高くつく

IPA（情報処理推進機構）が「ユーザのための要件定義ガイド第2版」で紹介している事例（基盤”Server系”・処理形態”Online”のケース）によると、要件定義工程で混入した欠陥を要件定義工程のレビューで摘出できた場合の手戻りコストを「1.00」とすると、発見が遅れるほど倍率は跳ね上がる。基本設計で気づけば2.30倍、パッケージ設計5.90倍、プログラム設計6.38倍、プログラミング9.33倍、統合テスト11.86倍、そして最後のシステムテスト工程まで持ち越すと13.09倍になる（デグレード率25%を想定したケース。基盤が”Host系”の場合はシステムテストで13.70倍）。

要件をすべて固めてから一括で作り切り、最後にまとめてテストする進め方は、この構造上「問題の発覚が最後になりやすい」というリスクを抱えている。認識のズレに気づいたときには、すでに設計・実装の大部分が終わっていて直すコストが最大化している、という状態になりやすい。

「一括で全部発注」は、規模が小さくても安全ではない

JUAS（日本情報システム・ユーザー協会）「企業IT動向調査報告書2021」（2020年度調査）によると、開発規模が100人月未満という比較的小規模なシステム開発プロジェクトでも、工期が「予定通り完了」したのは39.1%（n=829）、予算が「予定通り完了」したのは52.6%（n=823）、成果物の品質に「満足」と回答したのは28.9%（n=827）にとどまる。

この調査の回答企業は東証一部上場企業等が中心で、必ずしも中小企業の実態そのものではない。ただし、要件定義の精度が結果を左右するという構造は、発注側の企業規模を問わず当てはまる。むしろ「小規模な案件だから安全」という思い込みのほうが危うい。規模の大小にかかわらず、要件・仕様の詰めが甘いまま一括で発注すれば、思った通りには終わらないリスクがある。