進捗報告をぶっ壊す（２）

大規模なITプロジェクトにおいて、進捗管理をしているアリバイ作りのために、クライアントに伝わらない報告を淡々と読み上げる儀式を前回から批判している。

前回の約束通り、まずは結論として進捗管理のあるべき姿を説明したい。長い伝統は急には変えられないかもしれない。
それでもわたしたちはあるべき姿に近づいていかなければならない。
読者がプロジェクト責任者であるならば、今すぐ変えてほしい。あなたが率先して改革を主導し、ツールに投資するべきである。お願いします。

マイクロ納品、リアルタイム納品

進捗報告では、作業状況を技術者と管理者が自己評価し、報告資料に変換する作業が非効率である。
せっかく手間をかけて作っても、クライアントには成果が積みあがっている様子が見えないし、理解も難しい。
そんな伝わらない情報には価値がない。

プロジェクトの成果は、通常、契約終了直前に「納品」という形でまとめて提出されるのが一般的である。
そうではなくて成果を作り始めたらリアルにそれを共有するようにする。

プロジェクトは会社の枠、契約の枠を超えてワンチームでやれないか。

現実のプロジェクトでは、みんな作業中の情報を隠したがる。「社内のレビューが済むまで品質の悪いものは社外に出さない」という古い価値観に囚われがちであるが、悪いところが後になってわかるよりは早めに見えた方がいいともいえるので、改めていきたい。

どうしても仕掛中の成果物を見せたくないのであれば、後述のチケット管理を通じて社内でレビューを依頼している様子をチケットで表現する方法がある。

ITプロジェクトの成果物は技術的で専門的な内容である。そのため、プロジェクトマネージャーからの解説をクライアントが求めていると考えられてきた。
2025年あたりから、クライアントの担当者は解説を待たずとも、自分で生成AIに尋ねればよくなった。

ここから始めても問題ない。人に聞かなくてよいので恥ずかしいところは何もない。
「今週、16機能中10機能まで作成が終わると聞いていたけれど、ここにあるもので足りている？」「このプログラムにはコメント行を省いて何行くらいあるかな」「テストは何パーセントくらい進んでいるのか」のように、聞きたい切り口で自分で聞くことができる。
１時間の儀式の中から自分の欲しい情報を拾うよりも早い。

クライアントがAIとともに成果物の内容を読み始めると、報告の価値尺度が変わってくる。

「誰が、何をしたか」という進捗報告を、
「何を、誰に届けたか」という成果管理に変えていきたい。

言い回しを変えるのが目的ではない。
人は「自分のタスクだ」と認知すると、自分の基準で進捗率を刻みたがる。
そこで「30%できました! 現在制作中です!!」「作成したファイルはまだ自分のパソコンのデスクトップ上にあります」の類は成果として認めないこととする。
作業者の手元を離れて共有された時点で初めて価値として認めることにする。
「検討します」「調整します」「調査します」も成果としては認めない。

成果の測定は機械でもできるものにする。プログラムの行数。ドキュメントのファイル数。
かつてはソフトウェアに行われる設定は可視化できなかったが、現在ではInfrastructure as Codeといって、プログラミングのように記述するものになっている。
進捗報告だけのために、人間がExcelシートやWord文書を作成する必要はない。
「先週の成果はこの共有ディレクトリーに入っています。以上」これでおしまい。

大規模なプロジェクトチームでは、進捗をとりまとめるだけで時間がかかる。

• メンバーは毎週木曜期限で個人の報告書を書き、

• リーダーが金曜に確認してチームの報告書にまとめ、

• PMOが週末とりまとめて、

• PMが週明けに承認して、

• PMOがクライアント定例向けに事前送付。

これではクライアントの報告が火曜になってしまう。

「おそらく」でごまかさず、情報の鮮度を改善したい。リアルタイムの状況を、共有ストレージやドキュメント管理ツールにアクセスするようにする。

チケット管理、かんばん管理

成果物管理に移行しても、ただちに検討、調整、調査がなくなるわけではない。また、人によって価値創造の形は異なる。
プログラムを作る仕事も、機器の設定をする人も、外部システムとの接続にあたって他社と交渉する仕事も、どちらも立派な仕事として認めなければならない。
これを同じフォーマットで報告させるためにExcelシートで作ったWBS(Work Breakdown Structure)が共有されてきたが、いろいろ不都合がある。

詳しくは次回以降説明するが、一言で言うと「WBSを管理している人にしか記述内容の読解が困難で、ニュアンスを正確に伝えることはできない」資料なので進捗報告で使うのは禁止としたい。

かわりに、クラウドサービスのプロジェクト管理ツールや看板管理ツールに置き換える。
これらはWBSの中身を理解していなくても、誰でも依頼を起票できる。依頼先では作業を実施したら数クリックで報告ができる。
しゃべる仕事の人も、資料を作る仕事の人も、機器の調整をする人も、どんな職種の人もチケットで依頼を受けてチケットで報告する。これで報告の形が一本化される。

チケットは、起票した人から依頼者に向けて書かれる。相手にわかってもらわなければならないので、他人に伝わらないひとりよがりのチケットというのは理論的には作られない。
実際は人間がやることなので、変なチケットや放置されたチケットがあればPMやPMOが拾ってあげて是正を促す。

成果物管理と同様、これもリアルタイムで、誰がどのくらい溜めているのか、納期超過を起こしているのかをダッシュボードを見れば一目でわかる。
打合せの場で１週間分とりまとめて報告するという儀式は不要だ。

依頼が起票されるとリアルタイムで依頼先メンバーのパソコンにポップアップが現れる。わざわざ朝礼、夕会、デイリータッチポイントと呼ばれる打合せを開くまで依頼を待つ必要はない。
たまたまその人が休暇だったら、休み明けにスマートフォンを見た時にメールが届いているようにすることもできる。

ひとつの依頼に多重の手間をかける無駄はやめにしたい。
例えば、次のようなルーティンは、依頼するという作業だけに１件あたり合計30分くらいかけている。

• 依頼をメールで送る

• チャットで「メールしましたので確認してください」と念を押す

• さらにミーティングでも口頭で念を押す

ツールに入れたらその後のリマインドはすべてツールに任せることにする。
納期超過を起こしている人に対しても自動で催促が届く。

納品をリアルタイムとし、進捗に代えて成果を管理していく。
特徴をおさらいする。

• 成果は機械的に収集し、進捗を測定可能にする

• 進捗の測定に作業者の主観を含めない

• 人が進捗を測定して文書化する作業は廃止

• 全員集めて読み上げるというくだらない儀式は当然廃止

• 進捗はリアルタイムで見えるようにして情報鮮度を上げる

• 報告を得たい人が得たい切り口で成果物を探索する

• 専門的技術的なことは報告を得たい人が自分で生成AIに聞いて解決できる

従来の進捗報告を知っている方に対しては、以上で説明を終わります。
まだ進捗報告を見たことがない人も読んでいるかもしれないので、次回以降補足を加えていきます。
今回の内容が難しかった方は(3)(4)を読んでから戻ってきてください。

続く