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

ITプロジェクトの進捗報告について、連載している。
はじめから読みたい方は、こちら。
前回先に結論を書いたので、これから勉強しようという方への解説である。すでに、実務で進捗報告を経験した人には不要かもしれない。

そもそも進捗報告とは何かを生成AIに尋ねた。

定義

典型的な報告は、作業の依頼先から依頼元に対して行われる。
本稿で取り上げたいのは業務を受託したIT会社からクライアントに対するものであり、コミュニケーション強化、期待値調整、リスクの早期発見と共有、意思決定迅速化が活動の意義である。

生成AIはさらに、こんなことを言う。

まあ、それは確かに重要だろう。
でも、現実の世界では戦略的なコミュニケーションが成立しているのか。

効果

このような効果があればうれしいことは否定しないが、近年、進捗報告を受けていて認識できるのは4の「変更管理・追加要件の吸収」くらいである。ただそれも、変更管理表のExcelシートに行が追加されて進捗報告からのインプットが転記されるだけの場合もあり実施体制が「適切な」吸収をしているかは疑わしい。

プロジェクト管理が行き届いたプロジェクトでは突っ込みどころがない報告が行われていることは認めよう。
しかし、報告がすばらしいから管理が行き届いたわけではない。

進捗報告から何らかの価値を見出すことが難しくなっている。

以前はあったかもしれない。
遅延の測定方法に変化があったかどうかはわからない。以前は正確に測定されていた、あるいは今は測定されていないことを示す証拠はどこにもない。問題は遅延が発覚した後のプロセスである。

• 現場で遅延が発覚する→現場のリーダーが危機感を感じる→叱責を避けようとする→周りの人が手伝う→それでも回復しなければ頑張ってサービス残業で克服する→報告日までに遅延の暴露が回避される

• 現場で遅延が発覚する→対策が検討される→アクションプランとスケジュール修正が検討される→報告日までに報告内容が資料化される

今はこれらのようなことが少なくなった。

1. 作業の細分化が進みすぎた。
   技術の高度化、複雑化、情報システムに対するアクセス権管理の厳格化、案件掛け持ちの増加。

2. 雇用の多様化が進んだ。
   オフショア人材の活用、リモート作業、フリーランスの活用。Aさんが作業できなかったら隣のBさんが代わってあげたくてもできない。

3. 職場の文化も変化した。
   かつての日本のモーレツサラリーマンは、風邪を引いても台風が来ても律儀に出勤していた。感染症や通勤困難を理由とした進捗報告は以前であればありえなかった。
   今はその反対であり、なんなら適当な理由が見つからなければ体調不良を理由にしておけばいいという考えを持つ者もいる。

かつては日本人の美徳が進捗報告にも行き届いていた。遅れは恥だった。今は、遅延は事実なのだからありのままを伝えればいいと考えられている。報告者は報告こそが仕事なのであって、報告内容の改善に責任を持とうとはしない。

そんなことを言いたいのではない。
進捗報告の限界を誰も口にしないということを問題にしている。
やるものだからやることとされている。思考が停止している。

関係者全員を集めて、関係者の貴重な労働時間を割いて定例会議は行われる。時間を給料に換算したらその会議はいくらの人件費がかかっているのだろうか。

要約すると「期待」が共有されただけである。人件費が浪費されている。

プロジェクトの進捗が悪化したとき、クライアントはプロジェクトマネージャーに責任を取るよう要求するのが一般的である。

気持ちはわかるが、日本のIT業界はリーダー層が枯渇している。ましてや傾いたプロジェクトの尻拭いを喜んでやってくれる優秀な人材なんていない。無理して起用したら辞めてしまう。
日本における情報システムの受託サービスは薄利のビジネスである。調子の悪さがお客様にまで見えている案件では、すでに内部では炎上していて追加のコストも発生している可能性が高い。
仮に代わりの人が来て成功させたとしてもインセンティブやボーナスを払う余裕もなく、仕方なく昇進という飴を与えたとしても「昇給もなく責任が重くなっただけ」と言われてしまう。

このような裏事情を理解していれば、委託先の社長や事業部長クラスを呼び出してマネージャーの能力不足を指摘しても「早速、優秀な人材を起用して全力でお支えします」とはならないことがおわかりだろう。

時間やスキルの制約により、プロジェクトの中身を見渡して評価することができないクライアントが、進捗報告という儀式を見てプロジェクトの悪化を発見したところで、クライアントが採れる行動は「マネージャー交代の要求」くらいしか思いつかず、それは実現するかどうかわからないのである。

詰んでいる。

次回に続く。