プロジェクトチームの進捗会議はやめなさい

on


ちょっと挑戦的なタイトルですね。なんでこんなタイトル付けたんだろう。はて。
今日の某プロジェクトは、まぁ、客観的に大規模プロジェクトです。で、そのシステムから見ればサブシステムのチームを運営しながらも、メンバを検体として色々とOJT、そう、On the Job Trainingしつつ、こう思い至ったわけです。

「週次の進捗会議なんて意味ないや。」


チームの会議体
プロジェクトの規模が大規模になればなるほど、会議体をとおして意思疎通、上位下達をすることになるんですが、それはそれとして「必要なことなのでやっておいてください。」というスタンスです。勿論、ワタシのロールとして、意思判断が必要な場なのであれば是が非でも席がなくても出ますけれど。


プロジェクトチームを中心として対外的な会議体とすればそうした外部？いや上位か、に決められた会議体には必要都度赴きますが、チームの中も勿論会議体はあるわけです。それはたった一つ。

会議体名称 開催頻度 出席 会議主要議題 会議形式
朝会 日次 チームメンバ全員必須 進捗確認　昨日の実績・今日の予定・問題の共有 スタンドアップミーティング　15分以内厳守


これだけ、です。で、スタンドアップミーティングとあるので気付いたかもしれませんが、アジャイルのスクラムのアレです。アレなデイリースタンドアップミーティングで進捗会議をするんですね。


え？ずるい？いやいや。大規模開発のプロジェクトで全体管理はウォーターフォールのシステム開発手法を取っているからと言って、アジャイルの手法を使ってはいけないだとか、スクラムだとか手を出していけないわけではないでしょ。プロジェクトマネージャなら、いいとこ取りするものですよ。


大体、大規模であればあるほど、会議体の構造がネストして会議で重要な判断や“わたしたちのチームにとって”大切な情報が伝わってくるのが遅かったり、欠落したりするものです。それを精神論や横横の繋がりで拾うには限界があるし。もう、そういうものだ、と思っていたほうが精神衛生上好ましいわけです。


それは、上位の判断は変わるもの、ということを諦念せよ、ということです。そう丁寧してしまったら後は受け止める側でどのようにクラッシャブルゾーンを作っておくか、という情報伝達の構造設計になるわけです。いつ変わるかわからないコトをずっと口を開けて待っているのはアホですしそんなリソースも割けませんし。


適宜変わる＝随時変わる、のですから、それは受け取る側のインターバルを短くしておかないと吸収できる構造を作る必要がある。インターバルは時間に左右されるからその時間のスダイダーをコントロールできない外部のインプットを受け取ってもビックリしないように調整するわけです。で、入ってくる情報が適宜来て受け取った後の工程の調整や修正に素早く伝えられるようにインターバルを“日次”にしたんです。


チームは変化に強くないといけない
ワタシの感覚だと、“変化に強い”という言葉が来るとその後に続くことはビジネスの、だとかそう言ったビジネスを取り巻く環境に対する、とイメージしてしまうんですけれど、今はちょっと違うんです。


まぁ、ビジネスを取り巻く環境が、には違いないけれど、そうした外界からの作用も含めて、今いるチームが外界からの作用に対してチームへのインパクトがマイナスの方向については最小限に、プラスの方向については最大限に受け止められるようなチームビルディングをチームの運営をしたいと思っています。


そうした変化に対する反応、受容の特性を持つためにはそれを受け止めるためのしくみが必要で、その実現方法の一つがいつ来るかわからないインパクトに対するチーム内でのレスポンスの速度、だと思うんです。


なら、外界からの情報のインプットがある都度、でいいじゃないかと思うかもしれないけれど、それほど、程度として、可及的速やかに対応する必要性のあるものはその発現性の確率は少ないんです。それ自体が起きる時点で既に緊急事態として扱うとしてしまえば、それはその対応を全力でしてしまえばいい。そう扱うことを決めておけば、それ以外の、それなりに対応が必要であろうインシデントをどのインターバルで扱うことが、対応が最遅となったときの影響を想定して決めればいい。


その結果が、日次開催の朝会となるわけです。


週のまとめ
なら、会議体は一つだけなんだ、と思われるかもしれません。「え？いやいやお前が一つって言ったんじゃないか。」って速攻で突っ込まれそうですが、突っ込んでください。会議体ではないんですが、もう一つ、場を設けているんですよ。それが、週末のまとめの“ふりかえり”です。

毎週末に“ふりかえり”をやる。


ふりかえりは、例のアレです。コレ。



ふりかえりをケプトでやります。これで、今週のチームメンバ一人ひとりの振る舞いを振り返るんです。これをやると何がいいか。それは、日常の会話に埋もれてしまう、現場で調整してしまっているような、本来はプロジェクトとしてエスカレーションしないといけないようなYK(＝危険予知)とか、ノウハウとか、暗黙知になってしまうことを形式知に引っ張り出せるということです。デプロイに行ったら現場監督にあんなこと言われた、とか。事前に知らされていないことを要求された、とか。


そうしたことはメンバ一人が抱えておくものじゃないと思うんです。大人数でやっているならこそ、コミュニケーションコストを抑えるためにも統制も必要なんですから。


あと、なによりメンバ一人ひとりの気づきやストレスを強制的に吐き出してもらうことで、タスクに関連しないことを話す場を持つということです。それの価値は見えないし、直接のタスクの進捗には影響しないけれど、ノウハウが共有されることで間接的に別のメンバに作用することもあるわけで、そうした知を介する場の機会を作ることもプロジェクトマネージャの仕事だと思うんです。すべてはプロジェクトが思い描くように進捗させるという意思を実現するためなのです。


規模に関わらず、ウォーターフォールのシステム開発であればこそ、メンバの想いや感じていることをフィードバックする“文化”も“お作法”もないです。キッパリ。だからこそ、ウォーターフォールのシステム開発をやっているなら、システム開発が終わってからの反省会ではなくて、毎週末にケプトでフィードバックをすることをお勧めします。というか、「やりやがれデス。」です。


ケプトのやり方　つ　KPTを使ったプロセス改善：An Agile Way：オルタナティブ・ブログ


15分の朝会と週末ケプトがあれば、週次ミーティングなんて「ポイっ！」です。で、進捗情報はいつも新鮮で情報共有も“双方”で取り交わせる。要らないでしょ？週次ミーティング。