LASSIC Media らしくメディア
ITプロジェクトを失敗させない進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- ITプロジェクトの成否は、開発が始まる前の企画・要件定義という上流工程でおおむね決まります。
- 丸投げ・要件膨張・意思決定の遅れといった典型パターンには、経営の関与不足という共通点があります。
- 目的の明確化と段階的な意思決定の仕組みを経営が担うことが、失敗を防ぐ現実的な進め方になります。
目次
ITプロジェクトが失敗する要因は上流工程に集中する
ITプロジェクトの失敗要因とは、開発工程そのものよりも、企画・要件定義という「上流工程」での目的不明確・要件の曖昧さ・体制不備に起因するトラブルを指します。IPA（情報処理推進機構）は、上流工程での作業不備に起因する手戻りが開発現場の課題となっている状況を受け、2017年に発注者向け・計画立案者向けの上流工程強化ガイドを公開しました*1。プロジェクトの成否は、要件定義が固まる前の段階でかなりの部分が決まっているといえるのではないでしょうか。
ITプロジェクトが失敗する場合、原因の多くは開発工程の技術的な問題ではなく、その手前にある企画・要件定義の不備に遡ります。何を実現したいのかという目的が曖昧なまま開発に着手すると、後になって要件の解釈違いや仕様の追加が続出するためです。
IPA/SECの上流工程強化ガイドは、システム再構築における手戻りの多くが要件定義段階の課題に起因すると整理しています*1。発注者側の視点で書かれた「ユーザのための要件定義ガイド」と、受注者側も含めた再構築リスクを扱うガイドの2冊構成になっている点が特徴です*1。
上流工程を軽視する背景には、早く開発に着手したいという現場の焦りや、要件定義工程を「コストのかからない準備期間」と捉える誤解があります。しかし要件定義が固まらないまま開発を進めると、手戻りのたびに設計・実装・テストをやり直す事態になりかねません。
丸投げ・要件膨張・意思決定の遅れ — 失敗の典型パターン
ITプロジェクトの失敗には共通するパターンがあります。ここでは代表的な4つの型を整理します。
丸投げ：発注者が要件確定を委託先に依存する
発注者が「詳細はお任せします」という姿勢で委託先に要件定義を丸投げすると、業務を熟知していない外部パートナーが推測で仕様を固めることになります。完成後に「思っていたものと違う」という指摘が出やすく、大規模な手戻りにつながりやすい型です。
要件膨張：関係者の要望を際限なく積み増す
複数の部門から要望を集める過程で、当初の目的から外れた機能まで要件に加わり続ける現象です。優先順位を付けずに要望をすべて受け入れると、スケジュールと予算が当初計画から乖離していきます。
工数見積もり不足：楽観的な前提で計画を組む
過去の類似案件との比較や、想定外の作業（既存システムとの連携調整・データ移行・利用者教育など）を十分に考慮しないまま工数を見積もると、後半工程でしわ寄せが生じます。見積もりの前提条件を明文化し、関係者間で合意しておくことが欠かせません。
テスト軽視・意思決定の遅れ：終盤で品質と判断が追いつかない
スケジュールが逼迫すると、真っ先に圧縮されるのがテスト工程です。加えて、仕様変更や追加要望の可否について経営層の判断が遅れると、現場は前に進めないまま停滞します。この2つは終盤に同時発生しやすく、リリース直前の混乱を招く典型例といえるでしょう。
企画と要件定義の質が完成後の手戻りコストを左右する
IPAが継続的に収集してきたエンタープライズ分野のソフトウェア開発の定量データでは、テスト工程で検出される不具合密度が低いプロジェクトほど、完成後の信頼性が高い傾向が示されています*2。テスト開始時点までにどれだけ品質を作り込めているかが、最終的な信頼性に直結するという見方です*2。
この傾向は、上流工程での作業品質が後工程の結果を左右することを裏付けています。初期の設計や要件定義が粗い状態で開発を進めると、テスト段階になって初めて問題が表面化し、手戻りの範囲が設計・実装・テストの全体に及びます。
手戻りが発生すると、修正のためのコストは工程が進むほど増大します。要件定義段階で発見できた誤りであれば文書の修正で済みますが、テスト段階で発覚した場合は設計からやり直すことになりかねません。発注者側にとっても、要件定義の段階でどれだけ時間と人員を投じるかが、その後の総コストを決める分岐点になります。
IPA/SECの上流工程強化ガイドも、システム再構築における手戻りの多くが要件定義段階に起因すると整理しており*1、上流工程への投資が結果的にプロジェクト全体のコストを抑える方向に働くことがうかがえます。
目的・体制・意思決定・リスク管理 — 失敗させない進め方
ITプロジェクトを失敗させないための進め方は、目的の明確化・体制と役割の整備・段階的な意思決定・リスク管理・品質の作り込みという5つの要素で構成されます。
目的と成功基準の明確化を最初に行う
プロジェクトを始める前に、何を達成すれば成功と言えるのかという成功基準を、経営層と現場の双方が共有できる形で言語化します。「業務効率化」のような抽象的な表現ではなく、対象業務・対象範囲・達成したい状態を具体的に記述することが出発点になります。
体制と役割を明確にし責任の所在を定める
発注者側にプロジェクトオーナー・業務責任者・IT責任者の役割を置き、誰が何を決める権限を持つのかを最初に定めます。役割が曖昧なまま進めると、仕様の変更要望が出るたびに「誰が承認するのか」で時間を消費することになるためです。
段階的な意思決定でリスクを早期に発見する
要件定義・設計・開発・テストといった節目ごとに、経営層を含めたレビューと意思決定の場を設けます。工程が進んでからまとめて判断するのではなく、各段階で立ち止まって確認する仕組みが、問題の早期発見につながります。
リスク管理を計画段階から組み込む
想定される主要リスク（要件変更・要員確保の遅れ・既存システムとの連携課題など）を計画段階で洗い出し、発生時の対応方針をあらかじめ決めておきます。リスクが顕在化してから対応を検討するのでは後手に回りやすいため、事前の備えが重要になります。
品質は上流工程で作り込む
品質はテスト工程で作り込むものではなく、要件定義・設計の段階で作り込むものだという認識を関係者間で共有します。上流工程での確認を丁寧に行うことが、結果としてテスト工程の負荷軽減にもつながるはずです。
発注者が担う役割 — 経営と情シスが握るべき3点
ITプロジェクトの成否を分けるのは、委託先の技術力だけではありません。発注者側である経営層・情シス部門長がどこまでプロジェクトに関与するかが、同じくらい大きな影響を持ちます。
丸投げをせず要件定義に主体的に関わる
IPA/SECの「ユーザのための要件定義ガイド」は、発注者自身が要件を言語化する力を身につけることを目的として作成されました*1。委託先に丸投げするのではなく、発注者自身が業務要件を整理し、委託先との対話を通じて要件を固めていく関わり方が求められます。
要件の優先順位を経営の視点で判断する
現場から上がる要望をすべて実現しようとすると、スケジュールと予算が破綻します。経営層は、プロジェクトの目的に照らして「今回実現すべきこと」と「次の機会に回すこと」を切り分ける役割を担います。この判断を現場任せにすると、優先順位付けの責任の所在が曖昧になりがちです。
意思決定を素早く行う体制を整える
仕様変更や追加要望の可否について、経営層の判断待ちで工程が止まる事態は避けなければなりません。承認ルートを事前に定め、判断に必要な情報を委託先から受け取れる仕組みを整えておくことが、プロジェクト全体の停滞を防ぎます。
PMO・要件定義支援という外部活用の選択肢
目的の明確化・体制整備・段階的な意思決定・リスク管理を自社の人員だけで担うには、プロジェクトマネジメントの専門知識と、複数プロジェクトを見てきた経験の両方が求められます。情シス部門が通常業務と兼務しながらこれらを整えるのは、負荷の大きい取り組みになりやすいのが実情です。
この負荷を軽減する選択肢として、PMO（プロジェクトマネジメントオフィス。プロジェクトの計画・進捗・品質を横断的に管理する機能）の外部活用や、要件定義段階からの伴走支援があります。社内に専任のプロジェクトマネジメント人材を確保する場合と比較して、既存の知見やフレームワークをすぐに活用できる点が違いになります。
LASSICのように受託開発と運用保守を担う事業者は、要件定義段階からプロジェクトに伴走し、目的の明確化や体制設計を発注者と一緒に整理する関わり方が可能です。プロジェクトを丸投げする関係ではなく、上流工程を発注者とともに作り込むパートナーとして外部を活用する発想が、失敗を防ぐ現実的な選択肢の一つになるのではないでしょうか。
まとめ：ITプロジェクトを失敗させない3つの判断軸
本稿では、ITプロジェクトが失敗する要因と、失敗させないための進め方を経営視点で整理しました。要点を3つに集約すると次の通りです。第一に、失敗の要因は開発工程そのものよりも、企画・要件定義という上流工程の不備に集中しています。第二に、丸投げ・要件膨張・意思決定の遅れといった典型パターンには、発注者側の関与不足という共通点があります。第三に、目的の明確化と段階的な意思決定の仕組みを経営が担い、必要に応じてPMOや要件定義支援を外部活用することが、失敗を防ぐ現実的な進め方になります。
よくある質問
ITプロジェクトの失敗を防ぐには、まず何から着手すればよいですか。
まずプロジェクトの目的と成功基準を、経営層と現場が共有できる言葉で言語化することから始めるとよいでしょう。目的が曖昧なまま要件定義に進むと、後工程で解釈違いが表面化しやすくなります。目的の明確化ができた後に、体制整備と意思決定の仕組みづくりに進む順序が現実的です。
要件定義にはどのくらいの期間をかけるべきですか。
プロジェクトの規模・対象業務の複雑さによって必要な期間は異なるため、一律の目安を示すことは難しいのが実情です。重要なのは期間の長さではなく、関係者全員が要件に合意できているかという到達状態であり、合意が不十分なまま次工程に進まないことが手戻りの防止につながります。
委託先に要件定義を任せてしまうのはなぜよくないのですか。
委託先は自社の業務プロセスを発注者ほど深く理解していないため、要件定義を任せきりにすると推測で仕様が固まりやすくなります。IPA/SECの発注者向けガイドも、発注者自身が要件を言語化する力を身につけることを目的としており*1、発注者が主体的に関わる姿勢が求められます。
PMOを外部に依頼すると社内にノウハウが残らないのではありませんか。
関わり方次第でこの懸念は軽減できます。外部のPMOに進捗・品質管理の実務を担ってもらいながら、意思決定そのものは発注者側の体制で行うという役割分担にすれば、判断のノウハウは社内に蓄積されます。委託範囲を事前にすり合わせておくことが大切です。
意思決定の遅れを防ぐには、どのような体制が必要ですか。
仕様変更や追加要望の可否を判断する承認ルートを、プロジェクト開始前に定めておくことが有効です。判断に必要な情報を委託先からどのタイミングで受け取るかも合わせて決めておくと、経営層の判断待ちで工程が止まる事態を避けやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：IPA（情報処理推進機構）「ユーザのための要件定義ガイド 第2版」https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/youkenteigi20190912.html（2017年）
- *2 出典：IPA（情報処理推進機構）「ソフトウェア開発分析データ集」https://www.ipa.go.jp/digital/software-survey/metrics/index.html
