メンバは裁量を渡されてもリーダの期待していることはコントロールできないことに気づいている

振り返れば、綺麗に(プロジェクトの立ち上げの意)から参画してチームを作っていく経験よりは、途中から参画して、そのチームをなんとかする的な方が多い。なんとかするは、想像のとおりトラブりかけているケースもあるし、チームの仕事が溢れていてチームとして機能していないケースもあった。

どちらのケースも、単なるメンバのときもあったし、サブリーダのときもあったし、プロマネのときもあった。

後者のケースは単純といえば語弊があるかもしれないが、目標を実現できる計画を作り、作業を完了できればいい。(自分がリーダの場合は)作業はメンバに協力をしてもらわなければならない。自分でこうやれば目標を実現できるというプランを作り、メンバはそれをやることに同意して、チームで実際にやって小さな結果を積み上げていく。

  • このプロセスで作りたい(全員の作業の順序を同じにする)
  • プロセスには完了の定義を設ける(全員が同意してほしい)

リスタートを切るとき、やるのはこれがメインだったりする。これを始めるためには前準備というか現状の整理は山ほどあるが、それはやっておくとして、全員の作業順序を揃えることで作業もれが発生しないように防止する。完了の定義をするのは、アウトプットの下限を揃える意味合いがある。

これをソフトにではあるが、定着するまで繰り返し言うし、これを守ってくれている間は、トラブルを起こしたとしてもそれは自分の責任であるからトラブルを起こしたエンジニアは必ず守ると宣言する。

ここまで言っているのだからやらないと思うが、もしこれを守らないでトラブルを起こしたら、助けないと言う(実際にそうしたらプロジェクトは困るのでそんなことはしない)。

プロセスは、工程内の作業の段取りである。Aをやって次はBをやってCでレビューする的なものである。AなりBなりCには必ず作業のアウトプットが付いて回る。この段取りは、プロジェクトの固有な管理要求に耐えられる最低限の状態でメンバに提案する。

提案するのは実務でそのプロセスを使うのはメンバだから、メンバがそれでやってみようと言ってくれないと始まらないからである。意見をもらって、変えた方が良いところは変え、全員が同意して始めてもらい、途中で期待するようにできなければ都度修正する。修正はメンバに任せる。

スケジュールどおりに作ってくれればいいと言いたいところだが、どう作って欲しいかはリーダ役とメンバ全員ですり合わせをしてから始めないと、メンバはメンバで『後出しジャンケンや追加であれこれやってと納期直前で言ってくるんでしょう』と思っているかもしれない。

そこの溝を埋めないと、いくらリーダがあとは保証するからと言っても、メンバは『やってみるか』と言う気になってくれないのではないか。

メンバは経験的に、裁量を渡されてもリーダの期待していることはコントロールできないことに気づいている。

それはリーダ側でマネジメントはしないといけない。