システムエンジニアのためのQCDとAI活用

1. QCDの本来論

QCDは「品質・コスト・納期を守りましょう」という標語ではない。プロジェクトの制約の中で、何を優先し、どのリスクを受け入れ、いつ判断するかを共有するための管理軸である。

QUALITY

Q：品質

要求されたものを、期待される品質で提供できるか。

要求・仕様との整合
機能・性能・安全性・信頼性
保守性・運用性
説明・手順・ドキュメントの分かりやすさ

COST

C：コスト

決められた予算・工数・体制の中で実現できるか。

見積と実績
手戻り・再作業
追加要求・仕様変更
外注費・機器費・現地再訪費

DELIVERY

D：納期

必要な時期までに、利用できる状態として提供できるか。

工程計画と実績
依存関係・前提条件
問題の早期検知
納入後に顧客が利用開始できること

「納入した」ではなく、「お客様が利用できる状態になった」までをDeliveryとして考える。

今回の対象エンジニアは、システムを作るだけでなく現地導入や顧客説明まで担う。そのため、技術的に動作した時点ではなく、利用開始可能な状態までをQCDの対象として捉える必要がある。

2. 工程ごとにQCDは形を変える

QCDは開発工程だけに存在するものではない。要件定義から納入・説明まで、全工程にQ・C・Dが存在する。

工程	Q：品質	C：コスト	D：納期
要件定義	要求の抜け・認識齟齬を防ぐ	不要機能・過剰要求を増やさない	要件確定を引き延ばさない
設計	要件を正しく構造・方式に落とす	過剰設計・不要な複雑化を避ける	レビュー・意思決定を滞留させない
実装	正しく、保守可能な実装にする	作り直し・重複実装を減らす	実装残量と遅延要因を把握する
テスト	必要な観点・異常系まで確認する	再試験・不必要なテストを減らす	問題を後工程へ持ち越さない
現地納入	安全かつ正しく導入する	再訪問・追加作業を防ぐ	作業可能時間内に完了する
顧客説明	正確で理解可能な説明をする	再説明・問い合わせを減らす	利用開始を遅らせない

要件定義の曖昧さは、後工程のQ・C・Dすべてに波及する。

上流で数十分確認を省略した結果、設計変更・再実装・再テスト・現地再訪が必要になれば、その「小さな節約」はプロジェクト全体では大きな損失になる。

3. QCDを見る4つの視点

同じQCDを見ていても、顧客・会社・エンジニア・第三者監査では見ている対象が異なる。この違いを理解すると、「自分は何をすべきか」「誰に何を伝えるべきか」が明確になる。

お客さん成果・利用価値を見る
「期待通り使えるか」

会社・管理側契約・採算・体制を管理
「プロジェクトを成立させる」

プロジェクトQ・C・Dを統合して成立させる

エンジニア日々の判断と実行
「作る・確認する・伝える」

第三者監査プロセスと証跡を確認
「適切に管理されたか」

視点	主に見るもの	Q	C	D
お客さん	成果・利用価値	期待通り使えるか	費用に見合うか	必要な時期に使えるか
会社・管理側	契約・採算・信用	品質事故を防げるか	予算・利益を守れるか	契約納期を守れるか
エンジニア	実作業・技術判断	正しく作れているか	無駄・手戻りがないか	計画通り進んでいるか
第三者監査	証跡・プロセス	品質管理が実施されたか	承認された範囲で管理されたか	計画・変更管理が適切か

会社・管理側の役割

品質基準を定める
レビュー・テスト工程を設ける
必要な有識者・体制を用意する
不具合対応方針を決める

見積・予算を作る
工数超過を把握する
追加要求を変更管理する
採算悪化前に対策する

マイルストーンを設定する
遅延リスクを管理する
人員・優先順位を調整する
必要なら顧客と納期調整する

会社の責任：エンジニアの頑張りでQCDを維持するのではなく、QCDを守れる仕組みと判断経路を用意する。

エンジニアの役割

不明点を確認する
レビューを受ける
テスト結果を残す
不具合を隠さない

手戻りを減らす
不要作業を増やさない
工数超過を早く伝える
勝手に仕様を追加しない

残量を把握する
遅延要因を早く伝える
依存関係を確認する
現地作業前に準備を完了する

エンジニアが一人でQCDの結果責任を負うわけではない。

重要なのは、異常・不確実性・超過兆候を早期に検知し、判断できる相手へ正しく伝えること。

第三者監査の役割

監査は成果物を作る役割ではなく、「決められた管理が行われ、その事実を証明できるか」を確認する役割である。

実施する

→

記録する

→

確認する

→

証明できる

4. QCDは「全部最大化」ではなく、トレードオフを管理する

現場では、品質・コスト・納期のすべてを無制限に高めることはできない。重要なのは、制約が変わったときに何を守り、何を調整するかを明示的に判断することである。

状況	考えられる選択	影響
納期が迫っている	機能範囲を調整する	Dを守る代わりにスコープを調整
品質リスクが高い	追加テスト・レビューを行う	Qを守るためC/Dへ影響する可能性
追加要求が発生	費用・納期を再見積する	勝手に吸収せずC/Dの条件を再設定
現地問題が発生	切戻し・延期・暫定対応を判断	安全性・影響度を見てQ/Dの優先度を判断

問題を発見すること自体はQCD上の失敗ではない。

問題を抱え込み、選択肢がなくなってから表面化させることがQCD管理上の大きな失敗になりやすい。

5. QCDに対してAIに何を期待するのか

AIはQCDを保証する装置ではない。作る・調べる・比較する・確認する速度を上げ、人間が判断に使える情報量を増やす「増幅器」と考える方が実態に近い。

QCD	AIへの主な期待	現時点での見方	注意点
Q	レビュー、テスト生成、抜け漏れ検出、説明・文書品質向上	コード品質・文書品質・レビュー速度の改善を示す研究がある	AI出力そのものにも誤りがある。最終確認は必要
C	調査・実装・資料作成の工数削減、手戻り削減、処理量増加	タスク完了数や一部作業速度の改善実績がある	AI利用料・レビュー・教育・ガバナンス費用もCに含める
D	実装、テスト、レビュー、ドキュメント作成の高速化	個人・局所作業の高速化実績は多い	下流工程が詰まれば、プロジェクト全体の納期は改善しない

「AIで作業が速くなる」≠「プロジェクトが早く終わる」

実装量だけが増えても、レビュー・テスト・結合・承認・現地作業が従来のままなら、ボトルネックが後工程へ移るだけである。

AI活用後の基本形

人が目的・制約を決める

→

AIが調査・生成・比較

→

人が検証・判断

→

記録・承認して実行

6. AIにはどのような実績があるか

「AIは速い」という印象ではなく、実証研究で確認されているものを分けて見る。なお、研究ごとに対象・タスク・AIツールが異なるため、数値を自社プロジェクトへそのまま適用することはできない。

+26.08%

完了タスク数

Microsoft、Accenture、Fortune 100企業で行われた3つのフィールド実験を統合した研究では、 4,867人のソフトウェア開発者において、AIコーディング支援を利用した群の完了タスク数が26.08%増加。経験の浅い開発者ほど導入率・生産性向上が大きい傾向も報告された。

出典：Microsoft Research, June 2025

+53.2%

全10単体テスト通過の可能性

GitHubによる202人の経験者を対象としたランダム化実験では、 Copilot利用者は課題で全10個の単体テストを通過する可能性が53.2%高かった。可読性・信頼性・保守性・簡潔性にも統計的に有意な改善が報告された。

出典：GitHub Research, 2024

+7.5%

ドキュメント品質

DORA 2024では、AI導入率25%増加と、ドキュメント品質7.5%向上、コード品質3.4%向上、コードレビュー速度3.1%向上との関連が報告された。

出典：DORA / Google Cloud, 2024

19%遅延

熟練OSS開発者では逆効果の例も

METRの2025年RCTでは、慣れた自分のリポジトリで作業する熟練OSS開発者16人・246タスクを対象に、 AI利用時の完了時間が19%長くなった。本人たちはAIにより速くなったと感じていた点も特徴的。

出典：METR, July 2025

DORAが示した「局所改善と全体最適の違い」

DORA 2024では、AI導入の増加と個人レベルの品質・レビュー改善が確認される一方、 AI導入率25%増加に対して、デリバリースループット1.5%低下、デリバリー安定性7.2%低下との関連も報告された。 DORAは、小さなバッチや堅牢なテストなどの基礎がなければ、開発工程の改善がそのままソフトウェアデリバリー改善にはつながらないと説明している。

2025年DORAはさらに、AI導入を「ツールの問題ではなくシステムの問題」と位置付け、個人の生産性向上を製品・組織の成果へ変換するには、基礎的な開発能力、健全なデータ環境、明確なAI方針、ユーザー中心、内部プラットフォーム、バリューストリーム管理などが重要だとしている。

実績の読み方： 「AIを使えば必ず○%速くなる」という意味ではない。

タスクの種類、対象システムへの習熟度、AI利用方法、レビュー方法、組織の開発プロセスによって結果は大きく変わる。したがって、自社で導入する場合は導入前後を測定する必要がある。

7. 4者の視点にAIを重ねる

視点	AIへの期待	AIに任せないもの
お客さん	より早い提供、品質の安定、説明の分かりやすさ、問い合わせ対応の迅速化	受入判断、業務上の優先順位、リスク受容
会社・管理側	見積補助、進捗分析、リスク抽出、レビュー支援、変更影響分析	契約判断、予算承認、責任分担、人員配置、最終意思決定
エンジニア	調査、設計案、実装、テスト、レビュー、障害分析、説明資料作成	要求の確定、安全判断、最終検証、顧客への約束
第三者監査	証跡の横断検索、差分確認、不足・矛盾・未承認候補の抽出	監査結論、適合判定、責任判断

会社・管理側 × AI

工数・進捗

障害・変更要求

テスト結果

→

AIによる分析

→

Q/C/Dリスク候補

→

管理者が判断

エンジニア × AI：工程別の使い方

工程	AIへの依頼例	人が確認すること
要件定義	曖昧な表現、矛盾、確認質問候補を洗い出す	顧客意図、業務制約、要求の正式確定
設計	設計案比較、リスク、非機能観点のレビュー	方式選定、制約適合、責任境界
実装	コード生成、リファクタ、説明、レビュー	仕様適合、セキュリティ、性能、保守性
テスト	正常・異常・境界値・組合せ観点を生成	要求とのトレーサビリティ、重要度、網羅性
現地納入	手順レビュー、確認漏れ、切戻し条件の抽出	現地条件、安全、実機確認、作業判断
顧客説明	専門用語の言い換え、FAQ、説明構成を作る	契約・仕様との整合、誤解を生まない表現

8. 第三者監査とAI

監査領域では、AIは「監査人の代わり」ではなく、大量の証跡から確認すべき箇所を探す補助者として考える。

AIに期待できること

要件定義書とテスト結果の対応確認
設計変更と承認記録の突合
レビュー未実施候補の抽出
手順書と実際の構成差分の確認
バージョン・日付・承認者の不整合候補抽出
大量の記録から例外・異常パターンを探す

AIに任せてはいけないこと

「問題なし」という最終判定
契約適合性の最終判断
重大度・責任の確定
監査証跡そのものの改変
根拠不明なAI回答を証拠として扱うこと

AIの回答ではなく、AIが指摘した根拠となる一次資料を確認する。

監査で重要なのは「AIがそう言った」ことではなく、要件・承認記録・テスト結果・変更履歴などの原証跡である。

9. AI導入効果をQCDで測る

AI活用を評価するときは「使った人が便利と感じたか」だけで終わらせず、 Q・C・Dそれぞれの指標を導入前後で比較する。

軸	測定候補	見るポイント
Q	レビュー指摘数、後工程流出不具合、再テスト率、顧客問い合わせ、手順ミス、ドキュメント修正回数	速度だけ上がって品質が落ちていないか
C	作業工数、レビュー工数、手戻り工数、AI利用料、教育時間、再訪問コスト	局所的な削減が別の費用へ移っていないか
D	リードタイム、工程滞留時間、レビュー待ち、変更対応時間、納入準備期間	ボトルネックが後工程へ移っていないか

測定するときの最低ルール

導入前の基準値を取る。
AI利用の有無だけでなく、どの工程・どの用途で使ったかを記録する。
工数だけでなく、品質と手戻りも測る。
個人作業速度と、プロジェクト全体のリードタイムを分ける。
1回の成功例ではなく、複数案件・一定期間で傾向を見る。

10. エンジニアが日々使えるQCD × AIチェックリスト

観点	自分に問いかけること
Q：要求	この成果物は、そもそも要求を満たしているか。AIが作った内容を仕様と照合したか。
Q：確認	認識違い・抜け・例外条件はないか。別視点のレビューにAIを使えるか。
C：手戻り	いま曖昧なまま進めると、後で作り直しにならないか。
C：過剰	必要以上に作り込んでいないか。AIが出した追加案を無条件に採用していないか。
D：残量	「何%終わったか」ではなく、「あと何が残っているか」を説明できるか。
D：異常	今の時点で報告・相談すべき遅延要因はないか。
会社	自分で抱え込む問題か、会社・管理者が判断すべき問題かを切り分けたか。
顧客	技術的完成だけでなく、顧客が利用・理解できる状態になっているか。
監査	実施しただけでなく、後から「実施した」と証明できる記録が残っているか。
AI	AIの回答を根拠にしていないか。根拠となる仕様・コード・ログ・証跡を確認したか。

11. 最後に：AI時代のQCD

AIはQCDを直接保証するものではない。

AIによって、作る速度・調べる速度・確認する速度は上げられる。しかし、何を作るかを決めること、どのQCDを優先するか判断すること、どのリスクを受け入れるか決めること、成果物に責任を持つことは、人と組織の役割である。

AIをうまく使った場合

確認ポイントが増える
調査・生成が速くなる
早い段階でリスクを発見できる
人は判断と顧客対応へ時間を使える
QCD全体の改善につながる可能性が高まる

仕組みが弱いままAIだけ入れた場合

コード・資料だけ大量に生成される
レビュー・テストがボトルネックになる
誤りまで高速に量産する
責任の所在が曖昧になる
「速く作ったのに全体は遅い」が起こる

間違ったものを、安く、速く、大量に作れることもAIの能力である。

だからこそ、AI時代にはQCDの基本、要求管理、レビュー、テスト、変更管理、証跡管理がこれまで以上に重要になる。 AIは良いプロセスを増幅できる一方、弱いプロセスも増幅する。

参考資料

Google Cloud / DORA, Announcing the 2024 DORA report
https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report
Google Cloud / DORA, 2025 State of AI-assisted Software Development
https://cloud.google.com/resources/content/2025-dora-ai-assisted-software-development-report
Google Cloud / DORA, 2025 DORA AI Capabilities Model
https://cloud.google.com/resources/content/2025-dora-ai-capabilities-model-report
Microsoft Research, The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers, June 2025
https://www.microsoft.com/en-us/research/publication/the-effects-of-generative-ai-on-high-skilled-work-evidence-from-three-field-experiments-with-software-developers/
GitHub, Does GitHub Copilot improve code quality? Here’s what the data says
https://github.blog/news-insights/research/does-github-copilot-improve-code-quality-heres-what-the-data-says/
METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 10, 2025
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
METR, We are Changing our Developer Productivity Experiment Design, February 24, 2026
https://metr.org/blog/2026-02-24-uplift-update/