フルスクラッチ開発の落とし穴! 仕様凍結を守れない企業が陥る5つの失敗
「まだ追加できますか?」が破滅の合図! 仕様凍結で守る納期とコスト
2025-03-24

フルスクラッチ開発は、事業の特性に合わせた最適なシステムを構築できる反面、適切な管理を怠るとプロジェクトが迷走するリスクがあります。その中でも特に注意が必要なのが「仕様凍結の管理」です。仕様凍結が守られないと、追加開発の繰り返しやコストの膨張、納期の遅延など、多くの問題が発生します。
本コラムでは、仕様凍結を守れない企業が陥る5つの失敗について解説し、フルスクラッチ開発を成功させるためのポイントを紹介します。
>>フルスクラッチ(オーダーメイド)のシステム開発について詳細はこちら
目次
【記事要約】旭川医大とNTT東の裁判、仕様凍結後の追加開発要望が争点に
電子カルテを含む病院情報管理システムの開発失敗を巡る訴訟で、札幌高裁は一審判決を覆し、旭川医科大学に全責任があると判断した。プロジェクト開始後、医大側は大量の追加開発を要求。NTT東は625項目を受け入れた後、仕様凍結に合意したが、その後も171項目の要望が続いた。高裁は、仕様凍結の合意が開発要望の拒否に相当すると認定し、NTT東のプロジェクトマネジメント義務違反を否定。契約解除時点でシステムはほぼ完成していたとし、旭川医大に約14億円の賠償を命じた。ユーザー企業には、開発ベンダーの説明を受け、プロジェクトを適切に管理する責任があることが改めて示された。
出典:日経コンピュータ「失敗の全責任はユーザー側に、旭川医大とNTT東の裁判で逆転判決」2017年9月29日
【記事要約】旭川医大とNTT東、仕様凍結後の追加開発が訴訟に発展
旭川医科大学とNTT東日本の病院情報管理システム開発は、仕様の追加・変更が続いたことで開発遅延に陥り、最終的に契約解除と訴訟に発展した。当初2009年9月の稼働予定だったが、仕様変更が相次ぎ、2009年7月に仕様凍結を決定。しかし、その後も171項目の追加要望があり、NTT東は136項目を受け入れたが、開発はさらに遅延した。2010年4月、旭川医大は契約を解除し、NTT東は23億円の損害賠償を請求。裁判では、仕様凍結後の追加開発が争点となり、旭川医大の協力義務違反が指摘された。ユーザー企業には、仕様を適切に管理し、開発ベンダーと協力する責任があることが改めて示された。
出典:日経コンピュータ「システム開発の失敗を巡り裁判に至るまで、旭川医大とNTT東の2010年」2010年10月13日号
ポイントをひとことで
仕様凍結を守れないことが、フルスクラッチ開発の最大のリスクです。
本コラムが指摘するように、仕様変更が繰り返されると、開発の迷走・コスト増・納期遅延・品質低下・信頼関係の悪化といった深刻な問題が発生します。特に、事業会社側が仕様管理を適切に行わないと、追加要件が無限に膨らみ、プロジェクトが破綻する可能性もあります。
成功のカギは、仕様を適切に凍結し、必要な変更のみを慎重に管理すること。 そのためには、要件定義の精度向上・変更管理の明確化・影響分析の徹底が不可欠です。フルスクラッチ開発を成功させるには、仕様凍結を戦略的に活用し、開発の安定性を確保することが求められます。
失敗1:追加要件の連鎖による開発の迷走
仕様凍結後にも「やはりこの機能が必要だ」といった追加要件が次々と出てしまうケースです。開発の途中で業務部門や経営層からのリクエストが増え、仕様が膨れ上がることで、プロジェクトが終わらなくなることがあります。
回避策:
- 仕様決定の段階で、関係者全員の合意を得る
- 仕様変更のルールを明確にし、不要な追加開発を防ぐ
失敗2:コストの膨張による予算オーバー
仕様変更が頻繁に発生すると、その都度追加の開発費用がかかります。当初の予算を超えてしまい、結果的にシステム開発を断念せざるを得なくなることもあります。
回避策:
- 仕様変更時のコスト試算を事前に行い、意思決定を慎重にする
- 「予算内での調整」を前提に仕様変更を検討する
失敗3:納期の遅延によるビジネス機会の損失
システムの導入が予定より遅れることで、業務の効率化や競争力強化の機会を逃してしまうことがあります。特に、新サービスのローンチに合わせたシステム開発が遅れると、企業にとって大きな損失となります。
回避策:
- 仕様凍結後の変更を最小限に抑える
- スケジュールに影響が出る場合は、優先度の低い機能を次フェーズに回す
失敗4:システムの品質低下と運用トラブル
仕様変更が繰り返されると、開発途中で作り直しが発生し、コードが複雑化します。その結果、バグやシステム障害が発生しやすくなるため、運用開始後に大きなトラブルにつながることがあります。
回避策:
- 仕様確定後は慎重に変更を判断する
- 仕様変更時には十分なテスト期間を確保する
失敗5:システム開発会社との信頼関係の崩壊
頻繁な仕様変更により、システム開発会社と事業会社の間で意見の対立が生まれ、関係が悪化するケースもあります。最悪の場合、開発の途中で契約が打ち切られることもあります。
回避策:
- 仕様変更の際は、開発側の負担も考慮して合意形成を行う
- 開発初期の段階で「どこまでの変更を受け入れるか」を取り決める
まとめ
仕様凍結を守れないことで生じるリスクは多岐にわたります。追加要件の増加、コストの膨張、納期遅延、品質低下、信頼関係の悪化など、どれもプロジェクトの成功を妨げる要因になります。フルスクラッチ開発を成功させるためには、仕様凍結のルールを明確にし、適切な変更管理を行うことが不可欠です。
仕様を適切に管理し、無駄な変更を防ぐことで、スムーズな開発進行と高品質なシステム構築が可能になります。フルスクラッチ開発を検討する際は、ぜひ仕様管理の重要性を再認識し、戦略的に進めていきましょう。
仕様凍結を適切に管理しなければ、プロジェクトは迷走します。
フルスクラッチ開発において、追加要件の増加・コストの膨張・納期の遅延・品質低下といったリスクを防ぐためには、仕様管理のノウハウが不可欠です。フレシット株式会社は、仕様凍結の徹底と、的確な変更管理の仕組みを活用し、開発プロジェクトを確実に成功へ導きます。
当社は、事業会社のビジネス戦略を理解し、必要な要件を明確に整理する力を強みとしています。開発前の綿密なヒアリングを通じて、本当に必要な機能を見極め、無駄な仕様変更を抑えながら、高品質なシステムを提供します。
「コスト・納期・品質を守りながら、最適なシステムを構築したい」とお考えなら、ぜひフレシット株式会社にご相談ください。
>>フルスクラッチ(オーダーメイド)のシステム開発について詳細はこちら
<著者プロフィール>
フレシット株式会社 代表取締役 増田 順一
柔軟な発想でシステム開発を通して、お客さまのビジネスを大きく前進させていくパートナー。さまざまな業界・業種・企業規模のお客さまの業務システムからWEBサービスまで、多岐にわたるシステムの開発を手がける。一からのシステム開発だけでは無く、炎上案件や引継ぎ案件の経験も豊富。システム開発の最後の砦、殿(しんがり)。システム開発の敗戦処理のエキスパート。