頑張るエンジニアにはアンドンの紐を引けない

どこの組織でもプロジェクトの月次報告はあるようです。その月次報告で何をするか、つまりその会議で何をするかは報告事項か承認事項のどちらかです。報告事項はやっている工程は問題ありませんとか工程の品質はそこそこです、とかそんなことを話していると思います。審議内容が承認、つまり決議をするのであれば工程終了と次工程突入の承認をもらうとかリリース判定を審議してもらうとか。

プロジェクトの報告内容がグダグダ過ぎると、開発責任者とか全社のプロジェクト監査員的な人たちから書き方やら報告内容の構成やらと会議の狙いとは違うお作法的なところで躓いて、良くても数ページにわたる条件付き、最悪はリジェクトされてしまうのです。あーめん。

リスクを識別していれば

月次報告会が機能しているかどうかは、会議での発言がプロジェクトチームの活動の報告内容が定性的すぎるとか、報告書より口頭説明での言い訳が多いとかやっている作業の内容が第三者として理解できないなどの綻びからプロジェクトの将来が見通せるか、出来ていると言っている成果物が確認できるか、機能検証がプロジェクトの要件でテーラリングされて設計されているか、セキュリティ要件が識者により検証されているかなどなどのツッコミがあるかどうかで判別できます。

こうした場で実際やることをやっていれば報告するプロジェクトマネージャやスクラムマスタは言い切れるし、裏付けを持って言い切られることで隠蔽しているかどうかをレビューアは敏感に察してリスクがそのプロジェクトにあるかを識別することができます。

でも、その月次報告会が昨日していれば。

エンジニアの方がリスクに鈍感

そう言った月次報告会に出てくるようなマネージャやPMO的なおじさんたちより現場に一番近いエンジニアの方がプロジェクトの作業に携わっているのだから、今プロジェクトで起きかかっていることがプロジェクトのリスクの芽となるかどうかはわかりそうなものですが、なぜか周りのおじさんたちの方がリスクを見つけるのがお上手です。

エンジニアの方が一つひとつの作業に直接携わり、進捗上の障害となる作業の当事者なのに。

違和感を感じたらアンドンの紐を引く

やはり、作業に没頭してというよりプロジェクトの進捗を脅かすリスクが発現しそうな事象は、プロジェクトのメンバとして日々、時間で追われていると手が届く範囲しか関心をが及ばず、例えば、試験方針がなく、思いつきでエンジニアが試験仕様をソースコードに合わせて作っているのではないかとか、セキュリティの観点で全く対策をしていないとか、と起きていても気づくことができないのではないかと思ったりもします。

プロジェクトのリスクはプロジェクトマネージャがやればいいと思うかもしれないですし、実際そういう役割の方がいいのはそのとおりです。

でも、やはりプロジェクトのファーストラインに陣取るエンジニアは「これでいいんだっけ」という違和感を感じているかどうかだけでもプロジェクトマネージャに感じたタイミングでリアルタイムでつぶやいてくれればものすごく助かるのです。リスク識別の観点で。

生産ラインであればアンドンの紐を引いてラインを止めるんですよね。じゃあ、ITのプロジェクトではどうするか。

月次報告会でレビューアが外から眺めてアンドンの紐を引くようではそれこそ1ヶ月遅れになることだってあるし、遠い距離からリスクを識別しているのでエンジニアの後ろに隠れてしまえば見つけられません。

結局、ITプロジェクトでのアンドンの紐を引くのはエンジニアです。結果的に生産ラインの工員と同じファーストラインの役割の人が一番早いタイミングでラインを止められるし、違和感を感じやすいのです。