プロマネやスクラムマスタが決めてはいけない

on プロジェクトマネージャ スクラムマスタ チーム

このツイートの気持ちを少しだけ補足すると、本エントリの方が9月で満60歳になられる（おめでとうございます）とのことで、同じようにあと数年（とは言え猶予は7年くらいある）もすると60歳になってしまう自分にゾッとするなぁ、と。

 今の仕事以外の活動は実はその60歳を超えたときの種まきで、一部は既に成果が出ているところもあるが、もう少し主たる業務に置き換えられるようにしたいと考えているが今のところ、はまだまだ試行錯誤中な状況なのだ。

特に、ソフトウェア開発のエンジニアの組織づくりに関わりたいと思っているのでVPoEやマネージャが必要な経営者の方はお声掛けいただければありがたい。

そうしたエンジニアのチームを構築するとき、特に有期限性を持つプロジェクトでのチーミングで気をつけておきたいのはプロマネやスクラムマスタがオーダをバンバンと出すようなチーム作りになってはいけないと思っているし、自分がプロマネのポジションになる場合は、そうならないように仕組みづくりをするように心掛けている。

プロマネ・スクラムマスタ（1人）　→　チーム（N人）

図　プロマネ・スクラムマスタが決める関係

ありたい姿はこうだ。

プロマネ・スクラムマスタ（1人）　←　チーム（N人）

図　チームが決める関係

 チームが決めるようになって欲しい理由

メリットしかないから。

チームが作業プロセスを決め、完了条件を合意し、チームで進捗させる。チームで進めているから誰かの進捗が滞れば気がつくし、負荷が低いメンバが自然と手助けする。

プロマネは先々の計画を考えること、チームの進捗上のリスクを識別することに専念できるのでリスク回避が半端ない。

もしプロマネがチームも識別していないリスクを識別したら、これはどうすればいいかを示せばいいだけだ。

プロジェクトでのチームづくりで気をつけたいと上述したが、継続的な開発を続けるプロダクト開発ではより重要になる。なぜなら、チームが属する組織の意思決定がチームの判断に影響するからだ。 

 一般的に組織が成長すると意思決定は多段に置かれるマネージャの分掌の範囲で決定するようなり、チームの裁量はプロマネやスクラムマスタの持つ裁量よりも小さくなってしまう。小さな裁量は、思考範囲を狭め、制約事項だらけの中だけで考えてしまうと従来の意思決定や慣習に沿おうとする力学が働く。

それを少しでも緩和するためにプロマネやスクラムマスタが持つ裁量をチームに移譲をするのだ。移譲を受けたチームは少しでも裁量が増えれば伸び代が増え、放置しても進められるようになる。成果として組織貢献が可視化されればさらに権限を付与することも可能になる。

プロマネやスクラムマスタからチームが決めるように促し、それが上手くいかなくても心配しなくて良い。何が起きようともプロマネやスクラムマスタが責任をとる構図は変わらない。だったら、チームが決める方で失敗した方が学びが多い。

まぁ、そうも言っていられなくなったら、ちょっとだけ関与を増やせば良い。もう、トップダウンではやっていられない。そっちの方がリスクが高い時代なのだから。

 

 

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ