PMあるある（進捗（しんちょく）状態の可視化）
作成日：2021/04/07
PMあるある（進捗（しんちょく）状態の可視化）
このコラムはプロジェクトマネジャー（以下PM）の日常を通してPMの課題をご紹介します。
「あーっ、それってあるよね。」「もっとこうしたらいいのに。」「同じような悩みだなぁ。」など、PMあるあるを息抜きに楽しんでください。
本コラムで登場するプロジェクト（以下PJ）は実在のものですが固有名詞は仮名です。
また数値も一部変更していますのでご了承ください。
PJ概要
- 見積額：2,000万円
- 開発期間：7カ月
- 体制：3～5名 (フェーズにより増減)
- 内容：受注情報、収支情報を記録参照する業務管理アプリ開発
- 主な要素技術：C#、SQLサーバー、Web関連
- 状況：業務管理アプリへ追加機能開発中
プロジェクトメンバーの紹介
- PM（寺島学）：業務管理アプリ開発PM。鹿児島出身48歳。
- SE（高井桜子）：5年目の開発/試験のリーダー。東京出身。28歳。
- SE (山形健一) ：3年目のSE。開発/試験担当。東京出身22歳。
- SE/立石薫子：1年目のSE。試験担当。東京出身25歳。
新型コロナウイルスの感染症拡大に伴って在宅での勤務も増えてきています。
顔を合わせたコミュニケーションがとりにくくなっている今こそ、進捗管理に多くの課題を感じているプロジェクトマネジャーがいます。
ここではプロジェクトの進捗管理の場面を再現しながら、進捗管理のポイントを確認していきましょう。
製造工程でメンバーのひとりが発熱発生。
新型コロナウイルス罹患（りかん）の可能性があり5日間自宅静養していた。
その間残されたメンバが残業でカバーしていたが予定したシナリオ消化ができず作業遅延が止まらない。
そしてPCR検査の結果が陽性と判明した。
その結果現有メンバーだけではリリースが2週間以上遅延する見通しとなった。
PMは役員を巻き込み別案件で稼働中のベテランを引き抜き臨時投入し作業遅れを回避した。
しかし単価の高いベテラン投入のためコストが予定を超過していた。
PMは上司の了解を得てマネジメントリザーブを使いコストのベースラインを維持することにした。
この一件でコスト管理に意識が高まってきた。
見積時に計画した品質（Q）コスト（C）納期（D）で成果物を提供することがPMに求められる。
コストを費やしリソース増強すれば品質向上また納期短縮が可能である。
しかし請負型であるため受託側の理由でのコスト増加は利益を圧縮さらに赤字に転落する場合がある。
そこでPMは計画にない事象を見つけ問題となればアクションを打たねばならない。
QCDを管理状態つまり予定と実績の差異とその発生の原因が把握された状態を維持していかなければならない。
そのためにメンバーからの状況報告は大事な情報源でありPMの意思決定に欠かせない。
PM(寺島)
17時だ。さぁ中間報告会を始めよう。
SE(高井)
それじゃ報告をお願いします。
SE(山形)
きょう予定した作業は終わりました。予定作業数：5、済み：5、残：0。遅れなしです。
SE(立石)
私は予定作業数：7、済み：6、仕掛け：1。あと１時間程度で終わる見通しです。
SE(高井)
ありがとう。すると私を含めた合計が、予定：14、済み：12、仕掛け：2。この仕掛けは本日中に終了できそうなので現時点で問題なしです。
PM(寺島)
了解。それじゃこの会議は終了。いつもの通り今日の作業結果はあす朝の報告会に提出してください。今回はわずか1分で終わったな。
SE(高井)
予定通りだと、問題なし、で簡単ですけど毎回こうはいかないでしょう。
PM(寺島)
そうだね。さぁ、立石さん、その場合はなにを報告してくれるのかな？
SE(立石)
定時報告項目で、さっきと同じシナリオ消化について予定/済み/残の具体的な件数でしょうか。
PM(寺島)
それだけ？「付加情報（適宜）」に相当するものは無いかなぁ？
SE(立石)
あー、あとですね、問題の原因候補と遅れの経緯を伝えます。あくまで私見ですけど。
SE(高井)
仮説を立てるのはエンジニアとして大事。そして遅れの要因よね。対策を検討するため大事なインプットで付加情報よ。必ず報告してください。あと、自分で考えた対策とそれに要する工数も添えてくれるとなお良いわ。心がけてみて。
PM(寺島)
高井さん、きょうは早く終わって時間あるから進捗管理のポイントについて話してくれないか。
SE(高井)
はい。それじゃ立石さん、そもそもですけど、なんで進捗を管理する必要あると思う？
SE(立石)
やはり作業終了が予定通りになるかを見通すためでしょう。遅れたら取り戻すアクションが必要ですよね。
SE(高井)
そうね。試験工程なら状況はシナリオの実施/残件数が進捗を把握する指標になることは間違いないわ。他に進捗の把握に利用できる指標はない？
SE(立石)
う～ん、なんでしょうか。毎朝の報告会では前日の不具合件数を報告します。ただ、この値単独では進捗にどう関係したのかわからないです。なんとなく多いなぁとか、きょうは１件だけでテストはサッと終わったなぁ、と感じますけど。これも不具合件数も進捗把握の指標になるのですか？
SE(高井)
もちろん！内在する不具合を見つけ可能な限りつぶす。試験の目的はここよ。だから不具合件数は品質の状態を把握するだけでなく試験工程の進捗を把握する大事な指標なの。この話題は大事なので別の機会に改めて説明するわ。宿題として品質計画書を再読しておいて。これには、試験の目的、品質の評価基準、不具合検出の目標、試験環境、シナリオ構成、不具合検出後の対処手順等記載したのよ。いまは必要な点だけ頭にいれて作業してもらっているけど、その背景にある情報を理解することで自分たちの作業品質はグッと良くなるから。
SE(立石)
そういえばキックオフのときに説明あったことを思い出しました。けどその内容はちゃんとわかってなかったなぁ。今になって気づきました。宿題の件、了解です。
PM(寺島)
さて繰り返すが、プロジェクト管理のポイントはQCDだ。それらを管理する手法は各種計画書で規定しています。良い機会なのでこのタイミングで試験計画書、品質計画書、この２つの文書を再読してください。内容に不明な点が出てきたら、これまでより理解が深まった成長の証し。ぜひ質問してください。
予定に対して作業の遅れや進みを確認ことが進捗管理です。
そのため納期(D)に主眼が置かれますがシナリオの消化だけはプロジェクト全体の状況をつかめません。
予定通り進めるため残業し結果としてコスト超過する場合もあるでしょう。
不具合件数が少ない場合にはシナリオやデータなど環境に問題があるかもしれません。
進捗状況の把握はプロジェクト成功要因のひとつです。
品質(Q),コスト(C)、納期(D)は独立でなく関係するため、進捗＝納期と単眼でとらえずQCDすべての観点で状況を把握することが必要です。
進捗可視化は各種計画書に記載します。
