PMPの弱点を、耳で振り返る（約9分）

今週の弱点レポートです。耳だけで聞ける内容にまとめました。

まず全体の様子です。模試は1回目より2回目で伸びていて、三つの分野すべてで正解が増えました。ただ、事業環境の分野は2回目でもいちばん低いままです。失点には、はっきりした偏りがあります。誤答の回数が多かった8問は、すべて二つのテーマに集まっていました。一つは変更管理、もう一つは品質計画です。今回はこの二つに絞って話します。

ほかにも取りこぼしが見えるテーマがあります。リスクを計画したあとの監視と、どの文書をどの場面で更新して共有するか、という点です。ただ、解いた数が少なく、今は兆候の段階です。文書の扱いは、このあと話す変更ログの話と根が共通しています。

一つ目の弱点は、変更管理です。 取り違えやすいのは、変更ログが何のための記録か、という点です。変更の状況を伝えるテーマでは、13問中4問しか正解できていません。変更ログと課題ログ、それに変更要求そのものの区別が、あいまいになっている可能性があります。

変更ログの役割はこうです。各変更要求の内容と処理状況を記録して、関係者へ状況を伝える土台にします。承認、却下、保留といった今の状態を一覧にしておく記録です。担当者と期限を割り当てて未解決事項を追いかけるのは、課題ログの役割です。承認した変更がベースラインに正しく反映されたかを確かめるのは、構成管理の役割です。新しい脅威や好機を評価するのは、リスク登録簿の領域です。

では、事例で考えます。予測型で進む料金収受システムの更新です。変更管理委員会が機能の追加を承認しました。プロジェクトマネージャーは、その結果をメールで一斉に知らせました。実装は数か月先です。ところが運用部門は、もう検証環境で確認できると思い込み、手順書の改訂を始めました。財務部門は、支出計画に金額がないと問い合わせてきました。品質保証の責任者は、誰がいつ検証するのかと尋ねています。承認のあと、状況報告は一度もしていません。

正しい考え方は、まず変更ログを関連する計画と照らし合わせることです。そのうえで、承認済みだがまだ実装していない、という今の状態を示します。実装と支出と検証の予定、それに責任者をはっきりさせて、関係部門へ早く共有します。その後も、状況を報告し続けます。要点は、承認されたことは、実装済みでも検証済みでもない、ということです。同じ変更要求を出し直す対応は外れです。実装を急に前倒しする対応も外れです。どちらも、伝え方の問題を別のことで解こうとしているからです。

判断がまだ出ていない場面も、よく問われています。アジャイルで進む在庫最適化の開発です。提案は影響分析の最中で、判断は次の運営委員会で出ます。各地の店舗責任者が、それぞれ別の人に問い合わせていて、答えがばらついています。正しい考え方は、提案の状態、影響の概要、判断予定日、次のアクションを、共有ダッシュボードに記録することです。あわせて、更新の担当と頻度を決めます。通知の方法は、店舗責任者と合意します。プロダクトオーナーを窓口にすること自体は悪くありません。ただ、プロダクトオーナーのバックログ管理と、運営委員会の承認権限は分けて考えます。

モバイル送金アプリの事例も、考え方は同じです。判断の前でも、審査状況、未確定事項、判断予定日、次に更新する時点を、関係者ごとに伝えます。脆弱性の技術的な詳細だけは、認可された人に限ります。そして、変更ログの状態を更新します。

覚えておく一言です。 変更ログは、変更の今の状態を伝える土台。

二つ目の弱点は、品質計画です。 取り違えやすいのは、ハイブリッド型のプロジェクトで、一つの品質プロセスを全体に当てはめてしまうことです。品質のプロセスとツールを計画するテーマでは、13問中5問の正解でした。

事例です。電力会社の、スマートメーター基盤の更新です。法定検査や施工基準が決まっている設置工事と、ネットワークの敷設は、予測型で進めます。分析ダッシュボードや料金シミュレーションは、イテレーションを重ねて作ります。二つは、データ連携のインタフェースでつながります。品質担当者は、検査手順と様式の統一を求めています。ソフトウェア側のリードは、反復開発に合う品質活動を求めています。

正しい考え方は、成果物の性質、開発のやり方、規制に合わせて、品質の手法を選び分けることです。施工側には、基準に沿った段階的な検証と法定検査を計画します。ソフトウェア側には、完了の定義と自動回帰テストを計画します。そして大事なのが、つなぎ目です。それぞれが基準を満たしていても、連携したときに品質の問題が出ることがあります。だから連携インタフェースには、双方で合意した受入基準、品質メトリクス、追跡の方法、統合テストをいつ行うかを、先に決めておきます。施工側の手順を一律に押しつける案は外れです。連携テストを最後の統合にまとめる案も外れです。

医療機器のソフトウェア開発の事例では、欠陥の多くが開発完了後の最終テストで見つかり、手戻りが重くなっていました。正しいのは、設計レビュー、静的コード解析、スプリント内の自動回帰テストを、完了の定義に組み込むことです。あわせて、品質の尺度と許容限界を計画の段階で決めます。基本の原則は、検査よりも予防です。最終テストを延ばしても、欠陥は後ろの工程で見つかるままです。

交通アプリの事例では、関係者の期待があいまいでした。分かりやすい、快適、すぐ復旧できる、という言い方だけだったのです。正しいのは、重視される品質特性ごとに、測れるメトリクスを決めて合意することです。そして、それを受入基準と、反復ごとのレビューの観点に結びつけます。

もう一点、実験計画法の目的でもつまずいています。根本原因分析や、検査対象を抜き出す統計的サンプリングと、混同している可能性があります。実験計画法は、複数の因子の水準を計画的に組み合わせて試す手法です。そして、それぞれの因子の効果と、因子どうしの交互作用を、統計的に評価します。交互作用とは、ある因子の効果が、別の因子の水準によって変わることです。

覚えておく一言です。 品質の手法は部分ごとに選び、つなぎ目は先に決める。

では、頭の中で答えてみてください。声に出さなくて大丈夫です。

一つ目の問いです。変更管理委員会が変更を承認し、結果を一斉に知らせました。実装は数か月先です。その後、運用部門が、もう確認できるはずだと動き出しました。プロジェクトマネージャーは、何をするべきでしょうか。 少し考えてみてください。

答えです。まず、変更ログを関連する計画と照らし合わせます。そのうえで、承認済みだが未実装という今の状態と、実装と支出と検証の予定、そして責任者を関係部門へ共有します。そのあとも、状況を報告し続けます。理由は、承認は実装済みを意味しないからです。承認のあとの状態が伝わっていなかったことが、誤解の原因でした。

二つ目の問いです。品質計画の場面で、実験計画法を使う主な目的は何でしょうか。他の組織の実績と比べて目標を決める手法とは、どう違うでしょうか。 少し考えてみてください。

答えです。実験計画法は、複数の因子の水準を組み合わせて試し、各因子の効果と交互作用を評価するためのものです。他の組織の実績と比べて、目標や優れた慣行を見つけるのは、ベンチマーキングです。欠陥を種類別に数えて重点を絞るのは、パレート図の用途です。

最後に、覚えておく一言をもう一度言います。 変更ログは、変更の今の状態を伝える土台。 品質の手法は部分ごとに選び、つなぎ目は先に決める。

アプリの復習で同じテーマに出会ったら、この二つを思い出してください。今週のレポートは以上です。