利益:
- 変更要求、問題ログ、変更管理ボード (CCB)、品質基準の概念を理解し、人工知能のサポートを利用して影響分析草案を作成する能力。
- 人工知能を使用して、変更の範囲、時間、コスト、品質 (鉄の三角形) の影響を視覚化し、根本原因分析の草案を作成する能力
- 変更の承認と品質の受け入れは有能な意思決定者に属し、人工知能の影響分析を検証する必要があることを理解する能力。
計画通りに進むプロジェクトはありません。顧客が新しいリクエストを持ち込んだり、予期しないエラーが発生したり、要件が変更されたりします。この単元の主題は、これらの避けられない変化を混乱に陥る前に管理することです。承認なしに作業を変更しないことを保証する変更管理、発生した問題を記録して解決する問題管理、成果物が「十分な」レベルを満たしていることを保証する品質管理の 3 つのメカニズムについて学びます。 AI は、変更要求の範囲、時間、コスト、品質への影響を可視化し、問題の根本原因を調査し、品質基準の草案を作成するという、3 つの点すべてにおいて強力な分析パートナーです。しかし、変更の承認と品質の受け入れは常に有能な意思決定者にかかっています。 AI の影響分析は、検証なしに決定すべきではありません。
変更管理と鉄のトライアングル
変更リクエストは、範囲、スケジュール、予算、またはリソースの変更を提案する正式なリクエストです。制御されていない変更は、これまでの単元で見られたスコープ クリープの主な原因です。解決策は、すべての変更をゲートに通すことです。変更管理委員会 (CCB) は、変更要求を評価し、承認/拒否する権限のあるグループです。
それぞれの変更の影響を理解するには、鉄の三角形の概念が重要です。範囲、時間、コストは相互に関連しています (品質が中間にあります)。 1 つを変更すると、他の変更にも影響します。スコープを拡大すると、時間が増加するか、コストが増加するか、品質が低下します。 「同じ時間、同じ予算でより多くの仕事をする」には、多くの場合、品質が犠牲になります。優れた影響分析は、これら 3 つ（4 つ）の側面に対する変更の影響を明確に示します。
通常、変更プロセスは次のとおりです。登録リクエスト → 影響分析 (範囲/時間/コスト/品質/リスク) → CCB の決定 → 承認された場合の計画、スケジュール、予算の更新 → 関係者への説明会。承認されていない変更は実装されません。
問題管理と品質管理
問題は、リスクとは異なり、すでに発生した問題です（リスクは将来の不確実性であり、問題は今日の現実です）。問題ログは、未解決の問題、その優先順位、所有者、解決ステータスを追跡するライブ リストです。問題の根本原因を見つけるには、次の 2 つのテクニックが一般的です。 5 Whys — 「なぜ?」継続的に質問することで、表面的な症状から根本原因を突き止めます。特性要因図 - 原因をカテゴリ (人間、プロセス、材料、機械、環境) にマッピングします。
品質管理には 2 つの部分があります。品質保証 (QA) はプロセスが正しく機能していることを保証し (予防)、品質管理 (QC) は出力が基準を満たしているかどうかをチェックします (検出)。受け入れ基準と完了の定義は、ジョブがいつ本当に完了するかを決定する基準です。
コンセプト
何
例
変更リクエスト
計画変更の正式な要請
「レポート画面にフィルターを追加」
影響分析
範囲/時間/コスト/品質への影響
「+5 日、+3% 予算、中リスク」
CCB
承認権限
スポンサー + PM + テクニカルリーダー
問題
現実化した問題
「テスト環境がクラッシュしました」
根本原因
本当の理由（5つの理由）
「バックアップ構成が正しくありません」
品質基準
合格基準
「エラー率 < 1%」
ステップバイステップ: AI による変化と品質
- リクエストを明確にしてください。変更リクエストを「何を、なぜ、誰が望んでいるのか」として書きます。曖昧な需要は分析できません。
- 影響分析の草案。範囲、時間、コスト、品質、リスクの観点から、AI に影響の概要を尋ねます。数字をチームデータと照合します。
- オプションを生成します。 AI に「承認/拒否/延期/部分適用」オプションとそれぞれの結果をリストさせます。
- CCBに提出します。分析を意思決定者に渡します。許可なく申請しないでください。
- 根本原因の分析。 AI に問題に対して 5 つのなぜチェーンとフィッシュボーン カテゴリを生成させます。実際のデータを使用してテストします。
- 品質基準の管理。成果物を AI に渡し、受入基準に従って欠陥/不適合の草案を作成してもらいます。最終的な承認は専門家によって行われます。
注意: AI は隠れた依存関係や間接的な影響を認識していないため、変更の影響が「わずか 2 日」など軽微であるように見える場合があります。影響分析は、作業を実行するチームによる検証なしに「最終的な」ものとして CCB に提示されるべきではありません。
ミニケース3個
ケース 1 — 変更の実際のコスト。顧客は「画面のちょっとした変更」を希望していました。 PM は AI にリクエストを送信し、影響分析草案を受け取りました。変更は 3 つのモジュール、+6 日、+4% の予算に影響を与えました。チームはこれを確認した。 CCB は顧客に実際のコストを示しました。クライアントは変更を次のフェーズに延期しました。 「少ない」と思われていた需要も、混乱に陥る前になんとか対応できた。
ケース 2 — 根本原因が見つかりました。あるチームでは、テスト環境が頻繁にクラッシュしていました。コーディネーターは問題レポートを AI に渡し、5 なぜチェーンを要求しました。この連鎖は、「ディスク不足 → クリーンアップ タスク未定義 → プロセス所有者なし」ということになりました。チームは、表面的な症状 (崩壊) ではなく、根本原因 (孤立した洗浄プロセス) を解決しました。問題は再発しませんでした。
ケース 3 — 過小評価された影響。あるチームはAIの「この変更による影響は最小限」という草案を検証せずに承認した。この変更によりクリティカル パスへの依存関係が解消され、プロジェクトは 9 日遅れました。教訓: チームによる検証がなければ、影響分析を意思決定の基礎として使用することはできません。
弱いプロンプト / 強いプロンプト
弱いプロンプト:
この変更リクエストを検討してください。
サイズもデータも意思決定の枠組みもありません。 AI は表面的で、おそらく過度に楽観的な答えを返します。
強力なプロンプト:
あなたの役割: 変更管理アナリスト。変更リクエスト: [説明]。リクエスト者: [役割]。正当化: [理由]。コンテキスト: 現在の範囲、スケジュール (クリティカル パスが添付されている)、予算ステータス (割合)。タスク: 鉄の三角形による影響分析ドラフトの作成:- 範囲への影響、時間への影響 (クリティカル パスに影響するか?)、コストへの影響、品質への影響、新たなリスク- オプション: 承認 / 拒否 / 延期 / 部分的。 eachRule の結果: 数値効果をドラフトし、「[チーム検証が必要]」でマークします。隠れた依存関係がわからないと仮定します。正確なスピーチ。最終的な決定は CCB にあります。
このプロンプトは強力です。これには、鉄の三角形のフレーム、オプションの生成、ドラフト警告、意思決定者の強調が含まれます。
追加のテンプレート:
#5 なぜエンジン「なぜ？」 [問題] という質問を 5 回続けて尋ねることで、根本原因を突き止めます。各ステップでは、次の原因をどのようにデータで検証するのかも書きます。でっちあげの理由を付け加える。
# フィッシュボーンプロデューサー次の問題の考えられる原因をカテゴリ (人間、プロセス、ツール/マシン、材料、環境、方法) ごとにリストします。最も可能性の高い 3 つの理由にチェックを入れ、確認方法を提案します。
# 品質検収検査員以下の合格基準に従って納品物を品目ごとに検査します。満たされている、満たされていない、不確かなものを区別します。最終的な受け入れの決定は専門家にあると述べてください。
よくある間違い
- 承認なしの変更の実装: 承認なしの変更は範囲の変更そのものです。
- 影響を過小評価する: AI が「小さな」変更と呼ぶものは、隠れた依存関係を伴う大きな変更になる可能性があります。
- 症状を解決して根本原因を残す: 5 つの「なぜ」を実行しないと、問題が再発します。
- 問題とリスクを混同する: 将来のリスク、現在の問題。それらは異なる方法で管理されます。
- 品質基準を主観的なものにしておくと、「良さ」は測定できません。許容基準は数値でなければなりません。
- 検証せずに CCB に影響分析を提出する: 誤った分析は誤った決定を助長します。
ヒント: すべての変更要求に「ノー」と言うのも、管理者の決定です。優れた PM は、変更を拒否することでプロジェクトが保護されることを知っています。 PM はすべてのリクエストを受け入れ、プロジェクトではなく顧客を管理します。
要約すると
変更、問題、品質の管理により、避けられない変化の中でもプロジェクトを存続させることができます。変更は CCB を通過し、鉄の三角形 (範囲、時間、コスト、品質) を通じて分析されます。問題は記録され、5 つのなぜとフィッシュボーンを使用して根本原因に対処します。品質は測定可能な合格基準によって保証されます。 AI は影響分析、根本原因調査、品質監査を加速します。ただし、影響数値のチーム検証、変更の承認、および品質の受け入れは、権限のある人間の権限に委ねられます。
アプリケーションタスク
プロジェクトから変更リクエスト (実際または潜在的な) を受け取ります。 AI からアイアン トライアングルを通じて影響分析の概要と意思決定オプションを生成します。チームの誰かに数値を確認してください。また、現在の問題を取り上げ、「5 なぜエンジン」で根本原因を突き止め、根本原因に対する解決策を導きます。影響分析を CCB 決定形式で要約します。
チェックリスト
- [ ] 鉄のトライアングル（範囲・時間・コスト・品質）による変化を分析してみました。
- [ ] ドラフトとしてマークされたチームデータで衝撃の数値を検証しました。
- [ ] 承認を得るために所轄官庁 (CCB) に変更を提出しました。
- [ ] 5 Reasons/fishbone で問題の根本原因を見つけました。
- [ ] 品質の受け入れを測定可能な基準に関連付けました。
- [ ] 承認なしに変更を実装したわけではありません。