システム開発管理のQCD改善

本連載は、「IT部門における生成AI活用」と題して、生成AIを起点にIT部門の価値創出を支援する実践知についての解説記事です。

第2回では、システム開発管理全体を横断し、生成AIがQCD（Quality／Cost／Delivery）にどのような変化をもたらし得るのかを考察します。

開発管理は不確実性の高い状況下で意思決定を重ねる高度なマネジメントが求められる領域ですが、その実務において生成AIは判断の質とスピードに影響を与え始めています。 本稿では、各工程における活用の考え方と効果、留意点を整理しながら、IT部門において人がより注力すべき判断のあり方を示します。

1．エグゼクティブサマリー
2．背景：「システム開発管理」とはどのような業務か
3．施策：生成AIは「判断に至る前工程」を整える
4．まとめ：開発管理の「判断設計」をアップデートする

システム開発管理の現場では、従来、品質未達・コスト増大・納期遅延といったQCD課題が発生しています。これらの原因は、担当者個人の努力や力量不足よるものとは限りません。人員不足や外部委託に依存した開発体制、属人化、ベテラン社員の退職によるノウハウの流出といった組織的課題に起因しており、その結果として根深く残り続けている問題です。

本稿では、生成AIを「作業を自動化・効率化するツール」としてではなく、IT/DX部門の「決める力」（意思決定）や「動かす力」（業務部門とのコラボレーションを通じた推進）を支えるサポーター」として位置付けて論を展開します。

KPMGコンサルティングでは、これまで発注企業の立場でシステム開発推進を担うIT/DX部門への支援実績を積み重ねてきました。その知見を基にシステム開発管理において、現場ですぐに実践でき、早期の効果実現（Quick Win）を狙うことができるユースケース集を用意しています。

これらの経験に基づき、システム開発管理の各プロセス（構想・要求・要件定義～設計・開発管理～UAT・運用検討）における生成AIのユースケースを紹介します。

本稿が、貴社の各部門に所属すするメンバーの皆さまが生成AIを活用し、透明性・再現性のある意思決定や、業務部門との対話・交渉・協力を通じた力強いプロジェクト推進を実現するための一助となれば幸いです。

システム開発は不確実性の高い状況下での意思決定の連続であり、プロジェクトチームには「決める力」と「動かす力」が求められます。ベンダーに開発を依頼する場合であってもその守備範囲は広く、少なくとも以下の領域を横断します。

• プロジェクト全体の構想（目的・スコープ・体制・計画等） 
• 要求・要件の定義 
• 設計・開発・テスト工程の品質・進捗管理 
• 業務部門・ユーザーコミュニケーション 
• ベンダーコミュニケーション、成果物の受入れ 
• 課題・リスク管理と意思決定支援 
• ドキュメント統制・ナレッジ管理 
• リリース・運用移行の管理 
• コスト・調達管理

いずれも、情報・人・成果物が分散するなかで、正解が一意に定まらない判断を迅速に行うことが求められる領域です。

現場で繰り返し発生する品質低下・コスト増大・納期遅延は、担当者個人の力量不足によるものとは限りません。 実際の開発現場では、外部委託に依存したシステム開発管理体制に起因する構造的な課題が多く見受けられます。

もちろん、外部委託自体は活用方法次第でQCDを大幅に改善し得るものであり、多くの現場ではそれを期待して、あるいは人材不足によりやむなく、外部リソースが活用されています。

一方で、外部リソースに過度に依存することで次のような問題を抱えてしまう企業も少なくありません。

• 情報の分断
  外部委託を前提とした体制では、業務理解や設計判断の多くがベンダー側で行われ、社内には成果物のみが残りやすくなります。要求定義書、要件定義書、設計書、過去プロジェクト資料、議事録が複数のツールやフォルダに点在し、「なぜその仕様になったのか」という判断の経緯が見えにくくなります。その結果、上流工程での考慮漏れや認識齟齬が生じやすくなります。
• 属人化
  業務知見とシステム開発知見の双方を持つ人材が社内に十分に育たないまま、特定の担当者やベンダーに判断が集中します。コアメンバーの異動・退職をきっかけに、レビュー品質や判断品質が急激に低下し、リリース前後には過剰な確認やレビューが積み重なり、コストと心理・身体的負荷を押し上げる要因となります。
• 判断遅延
  影響調査や仕様判断にはベンダーへの確認が必要となり、その都度会社をまたいだコミュニケーションのリードタイムが発生します。複数ベンダーを活用する場合、報告粒度や形式が異なるため、全体像の把握に時間を要します。また社内で即断できる人材が限られている（属人化も発生している）場合、情報が揃っていても判断できる人材が現場に育たず、結論が先送りされがちです。その結果、作業は進んでいても意思決定が滞留し、リードタイムが伸びていきます。

前述のように、外部委託を前提とした役割分担は、判断の主体と判断材料を分断しやすく、情報の分断・属人化・判断遅延を生み出しやすい構造的特徴があります。この根深い課題を見直さない限り、QCD課題は繰り返されます。

この文脈において、生成AIは単なる自動化ツールではありません。判断に必要な情報・視点・仮説を高速で揃えるサポーターとして位置付けることが重要です。生成AIは前工程（探索・整理・ドラフト・比較・観点提示）を下支えし、人は判断や合意形成に集中します。エンジニアの多能工化と相まって、上流・中流工程を社内で担える体制への転換が、現実的な選択肢として見えてきます。

本章の最後に生成AIが社員の意思決定をどのように支えるのか、生成AI活用の一例として「プロジェクト企画書レビューの自動化」を、実際のイメージに沿って紹介します。

※活用が見込まれるユースケースをPower Automateを用いて実装イメージであり、実際にプロジェクトで活用・効果創出された仕組みではありません

（1）ユーザーが特定のSharePointフォルダにプロジェクト企画書をアップロードする。

（2）企画書のアップロードをトリガーに、Power Automateのフローが起動し、AI機能（AI Builder）により企画書のレビュー結果が生成され、Excelのテーブルに結果が書き込まれる。

（3）Power Automateにより、起案者へレビュー結果の生成を通知するメールが自動で送信される。

（4）メールに記載のリンクを開くと、生成AIによる実施レビュー結果が記載されたExcelを閲覧できる。

（5）アップロードした企画書やレビュー結果ExcelのURLがSharePointリストに自動で書き込まれる。ここから、Power Automateの承認フローを動かすこともできる。

生成AIは、開発管理の現場から手作業を消し去る魔法の道具ではありません。むしろ、人の「決める力」や「考える力」を支えるための前提や土台を整える存在です。

生成AIを「判断に至る前工程」に組み込むには、単なるツール導入ではなく、判断設計そのものの見直しが不可欠です。

ドキュメント整備や運用設計が不十分な場合、期待した成果を得ることは困難です。生成AIの出力はあくまで仮説として扱い、盲信せず、人が判断すべきポイントをあらかじめ設計しておくことが重要です。対人コミュニケーションを含め、人に求められる役割は今後もタフなものとして残ります。

自社の業務を最も理解しているのは自社自身です。その前提に立ち、上流・中流工程を社内で主体的に担い、ニッチな専門性が求められる領域は外部委託を活用する。このようなシンプルで柔軟な開発スキームへ転換することで、ばらつき・重複・滞留といった構造的な罠を小さくしていくことができます。

「何をAIに任せ、どこで人が介入し、どこで最終判断を行うのか」。この線引きを運用設計に落とし込むことこそが、迅速かつ持続的にビジネス価値を創出できるIT部門への近道と筆者は考えます。

※本文中に記載されている会社名・製品名は各社の登録商標または商標の場合があります。

KPMGコンサルティング
マネジャー　兼子 恭輔