2つの視点で状況把握ができていますか?

連載 [第2回] :

2022年5月20日(金)

はじめに

前回で、私がプロジェクトマネージャーを担える人材の育成を始めたきっかけとして「プロジェクトマネージャーを目指す方と私との間に、色々な面でプロジェクトマネージャー像に対するギャップがあり、さらにそれぞれの切り口で評価した際のギャップが激しい」こと、そしてその理由として「これからプロジェクトマネージャーを目指そうという方の殆どがプロジェクトマネージャーの担当する仕事のごく一部しか把握しておらず、把握している一部の仕事も、実際には目的を把握せず、作業としてしか捉えていない事に原因があると思っている」と説明しました。そこで今回は、私が感じているギャップとその原因のうち、特によく遭遇する事例を紹介したいと思います。

サブリーダーのPM批判

私がプロジェクトマネージャーをサポートもしくは育成する立場で、プロジェクトメンバーをフォローアップするための1on1ミーティングを行った際の話です。サブリーダークラスのメンバーから「今回のプロジェクトでのPMは自分よりも仕事ができていない!」とか「PMなのに現場の状況を具体的に把握できていない!」といったPM批判が繰り広げられることがあります。サブリーダークラスになり、脂の乗り始めたあたりのメンバーからすると、SE業務や仕事の流れも一通り覚え、技術面やメンタル面での勘所も分かり始めた状況で、他メンバーのサポートなどもでき、まるでシステム開発工程の全てが自分の手の内で動いている感覚を覚えるタイミングです。

プロジェクト管理には製造以外にも膨大な工程や領域がありますが、大規模プロジェクトで一番ボリュームのある部分は設計・製造・テスト工程になる訳で、その工程を「自分がコントロールしている!」と思ってしまうシチュエーションがサブリーダークラスには多く発生します。しかし、私の立場からすると、サブリーダークラスのメンバーの言っていることも正しいのですが、PMの行動も報告を受けている範囲では正しいと判断します。

進捗・品質管理の基本

メンバーが数人から十数人程度といった規模の小さいプロジェクトでは、プロジェクトメンバーが複数の役割を兼任するケースが非常に多くあります。そしてそのケースではPMがリーダーを兼任しますが、規模が小さいと、PMが全メンバーの成果物をチェックしたり、メンバーのうち誰かの進捗や品質が悪い状態でもPMが残業や休日出勤で対応すれば帳尻を合わせることができてしまいます。まさにここが落とし穴で、中〜大規模プロジェクトでも、サブシステムやサブチーム単位に分割すると、サブリーダーから見たプロジェクトの景色は小規模プロジェクトの景色と非常によく似ているのです。しかし、中～大規模プロジェクトのPMが全てのメンバーや成果物の状況を具体的に把握しようとすると、確実に破綻します。

では、PMはどうすれば良いのかと言うと、色々と手法はありますが、メジャーなものとして、プロジェクトの初期段階で大量製造工程を含むプロジェクト全体のリスクを見極め、どこに不確実要素があるのかを事前把握します。その後、実際に大量製造工程に入る際にウォークスルーレビュー(同じ工程に関わる全員もしくは主要メンバーを集めた手厚いレビュー)を実施し、レビューイーの成果物精度や、レビュー参加者の成果物基準理解度を向上させます。そして、それ以降は各メンバー、もしくはチーム単位で報告される進捗や品質を見て、矛盾のある箇所や違和感のある個所を見つけ出し、そこを徹底的に追及し進捗遅れや品質低下の潰しこみを行います。

ここで注意すべきなのが、各メンバーやチーム単位で報告してもらう進捗や品質は、必ず数値で表わせるようにする点です。例えば、進捗なら未着手は0％、着手は10％、作成・セルフチェック完了は50％、レビュー完了は80％、レビュー指摘対応完了は100％など、具体的な基準を明示し、各メンバーが独自の判断で報告を挙げないようにします。そして、全てのタスクと成果物を数値で整理し、進捗は遅れているのか進んでいるのか、品質は良いのか悪いのかを数値と共に状況のコメントを報告してもらい、そこから矛盾点や違和感のある個所を探るのです。

一般的に、サブリーダークラスや小規模プロジェクトのPMが具体的に中身を把握して自分の感覚で状況を押さえたものを「定性評価」と言い、状況を一定の指標に従って数値化し、数値のあるべき状況と実際の矛盾を見つけて追及して状況を押さえたものを「定量評価」と言います。私がPMをサポートや育成する場合は、まず定量評価を行い、その上でサブリーダーやメンバーの定性評価をヒアリングし、最後に自分で納得の行かない箇所などをサンプリングでチェックすることで状況を正確に把握するように助言をしています。つまり、これができないと中～大規模のプロジェクトマネジメントは任せられないのです。逆に定量評価→訂正評価の手順を踏んで状況を押さえていれば、小規模プロジェクトでも間違いが起きづらくなるのです。

他の業界の進捗・品質管理

実は、ITのプロジェクトマネジメント以外でも定量評価、定性評価を非常に重視し、理解しやすい運用をしている業界があります。旅客機のパイロットの世界です。

旅客機のパイロットになるには、最初に自家用操縦士という資格を取得します。基本は自分の目で見た風景や状況を元に操縦する「有視界飛行」の技術力が問われますが、これはあくまで個人の趣味であったり、旅客機のパイロットになるための入門的な資格です。実際にパイロットになるには、有視界飛行だけでなく、雲などに囲まれて周囲の視界がない状態でも、飛行機に搭載された計器類や地上からの誘導電波の情報などを把握し、頭の中で風景や状況をイメージしながら飛行できるようになる必要があります。このような飛行方式を「計器飛行」と言います。

しかし、実際の旅客機パイロットは、有視界飛行でも計器飛行でもなく「計器飛行方式による飛行」を行っています。たとえ目視だけ、もしくは計器だけでの飛行が可能でも、必ず事前に「飛行計画」を航空管制に提出し、常に航空管制に自分が操縦する飛行機の状況を客観的に把握してもらうと共に、他の飛行機の客観的な状況も確認してもらい、パイロットは自分の飛行機の計器類の数値、自分の目で見た形式や飛行機の状況、管制官からの情報を総合して操縦する方式を採用しています。航空機の場合、機種にもよりますが、速いときは時速1,000Km近くに達します。そうすると、いくら目視で周囲の状況が分かっても、真正面から向かって来る飛行機がいた場合には時速2,000Kmで近づいて来ることになるので、気付いたときには衝突回避が不可能になる場合や、晴天だから大丈夫と思って有視界飛行をしていたら、突然雲に囲まれて自分がどこを飛んでいるか分からなくなるなどの突発的なトラブルが発生する可能性もあります。そのようなトラブルにも対処できるように、航空業界では「計器飛行方式による飛行」を徹底しているのです。

ITプロジェクトに当てはめると…?

なかなかイメージしにくいかも知れませんが、ITの世界でも同じようなことは起こり得ます。例えば200人の技術者が同時に設計と開発を行うプロジェクトがあったとしましょう。計算しやすくするために、1人の技術者が1か月働くためのコストが100万円とすると、月間で2億円かかります。つまり1日当たり1,000万円かかる計算です。そのようなプロジェクトで、各メンバーが自己申告での定性的な進捗管理をしていた場合にどうなるでしょうか。各メンバーが「やや遅れているな…」程度の自覚があったとして、「どこかで残業か休日出勤して取り戻せば良い」と高をくくってしまうこともよくあります。この各メンバーの「やや遅れている」を定量化してみたら、全員1日遅れていたなんてことになれば、PMは1,000万円の損失リスクを負ってしまう訳です。飛行機の空中衝突事故や墜落事故よりは被害は少ないかも知れませんが、お客様や会社にそのようなリスクを負わせることはできません。そういったリスクを適切に回避するためにもPMは定量評価→定性評価→適切なハンドリングを基本動作にすべきなのです。これからPMを目指すサブリーダークラスの方は、ぜひこの点を意識して今後のお仕事をしてみてはいかがでしょうか。