進捗管理でどこまで把握してどこまで報告するか

勝手に立ち上がった勉強会（立ち上げのお誘いを受けた限定的なもの）で共通テーマを掲げつつシステム開発手法やらプロジェクトマネジメントの事例を共有して、それぞれの専門職としての疑問や突っ込んだところを聞いたり、専門家としての見解をフィードバックしたりしているんですけれど。ある回の中で進捗管理でどこまでプロマネとして把握してどこまで（プロジェクトチームから見たときの）外部（社内もチームから見たら外部だし顧客も同じで程度の差がある）へ報告するかという話題になったんですね。

と、ここまで前振りです。

ある事例では、コンテキストを読む限り全部見せている、と。

ちょっと思い出してください。例えばウォーターフォールでシステム開発手法をやっていると、工程の最初（基本は前工程の後半で）次工程の計画を立てる（WBSからスケジュール化する）じゃないですか。ね。で、実際始めると計画外の作業が増えるんですよ。例えば、技術調査とか環境構築時のトラブルとかパッケージの問い合わせとかでトラップを踏んだ（製品バグ）とか。最初は課題管理レベルだったものが見通しが長そうなテーマが出てくるわけです。

問題なんだとその会合でも言ったのだけれど、多くのケースは良くて課題管理に押し込んでしまっていて作業として可視化しないんですよ。進捗上は見えない。チームの中でさえ、担当をアサイン（というか地雷を踏んだメンバがそのまま引っ張る）したらあとは「解決した。え、いつするの」的な感じでやっているはずです。で、ズルズルと。

だって、WBSにないですからね。誰からもトレースされないんですよ。さらに言えば、適切な解決期限も設けない。で、そのトラップが解決していなければ後続作業が着手できないところまで来て、初めて騒ぎ出す…と。

あるあるでしょう。

話を戻して全部見せている事例はそうしたこともチケット駆動でやっているのでチケットを発行しないと作業を認めない、というチケット駆動のお手本のようなやり方をしているので全部チケットに入っていく。

その上、全部見せているから管理対象となる作業の母数（＝チケット）が増えていく。本来、これは顧客やマネジメントから見たら不安になるし、困るんですよ。

何が困るというと、前週と比較ができないんです。母数が増えるから。やるとしたら比率で把握するしかない。でも、比で把握してもダメなんですよね。マイルストーンまでに必要な作業が終わるかどうかをマネジメントしたいので。

どこまで把握すればいいか

標題に戻して。進捗管理をどこまで把握すればいいか。

これは全て把握してチケットなり（excelでもいいけれど）WBSに記載しなければダメです。リソースの割り当て状況が把握できないので。カンバンで可視化してWIPをモニタリングしていればいいけれど。

どこまで報告するか

これはステークホルダマネジメントの一部だと思うんですよ。あと、プロマネとしてどこまで裁量（プロマネが腹を括るか）でプロジェクトのコントロールを確保するか、統制するかの問題なのです。

顧客から見たらアウトソースしているプロジェクトが転ければ、顧客プロジェクトがパーになるかもしれないので早く悪いことは報告しろ、包み隠さず報告しろというんですよ。でも、それ真面目にやるとマイクロマネジメントとして介入されるんです。顧客が官僚主義なら100％そうなります。顧客の中で担当が詰められますから。

そう考えると（過去の報告を思い出しつつ）計画作業をベースとして予実と課題のインパクトとプロジェクトの見通しを把握できる情報をあまり加工せずに出すのがいいかと。

あまり加工しないとは、例えばチケット管理システムで、報告用のビューを作っておいてそれだけ報告するイメージ。課題は課題のチケットビューを作って流し込みしておしまい、みたいな。

社内と顧客との差はと言えば、社内のレビューアが有能ならそのまま見れば、と開放しておくのがいいと思います。お前たち用のレポートはない。これ見て判断しろ、と。エンジニアのはずなので。