私の会社のメンバは、全員がここ２〜３ヶ月以内に入社した。
CTOだけが何年もいる。
それ以前はどうなっていたのか非常に気になる。

そんなわけで、まだ入社して日が短いメンバでリリース済みのサービスを保守拡張している。

現在の開発スタイルは「CTOの思いつき駆動」で、CTOの思いつきが作業の一番の割り込みになっている。
思いつきが２〜３個あると、仕事のスタックが増えて行き、何がそもそも積まれていたのか、作業のゴールは何だったのかが曖昧になっていく。

そのため、今はCTOにバックログを作ってもらうようにお願いして、いっしょになって作っている。
これができたら割り込みがあっても、少なくとも優先順位は保たれるはず。
ゴール(Doneの定義）については、割り込み時によく合意することを意識づけしていきたい。
近い将来、チームでDoneの定義についても話し合う時間が欲しいなぁ。

話がそれた。

入社したてのメンバばかりなので、全体像を合わせるために「『我われはなぜここにいるのか』をやりましょう！」とチームに提案した。
そして、OKをもらった。

明日開催するのだけれど、早くも反省。

• プロダクトオーナーへの根回しが必要。
  • 特に”チームのイメージ合わせをするため”のような目的を合意しておくことと、”やたらとメンバの意見を否定しない”とかプロセスの合意が必要だと思った。開催前に根回しできるならやりたい。
• 合意にいたるプロセスデザインが必要。
  • 『アジャイルサムライ』とか”決めればいいよ”ぐらいの感じで気軽に書いてるけど、実際に決めるとすると、どう合意形成するのか？　ここはファシリテーションのスキルが必要だと思う。

そこで合意形成のプロセスについては、以下の３点を意識するようにした。

• 話し合いの目的を再確認する。
  • 「チームのイメージ合わせ」が目的。（特にプロダクトオーナとその他の人とのイメージ合わせ）
• グランドルールを決めておく
  • 今回は３点。「他の人の話を否定しない」「他の人の話の内容・意味をよく知ろうとする」「積極的に質問する」
• メンバの意見は付箋ベースにする
  • 「プロダクトオーナーの前で意見が出しにくい」などの抵抗感を減らしたい

でも、意見を出したあとにどうやって決めているんだろう？
決め手は何だろう。　その場に投げかけてみてもいいけど、案は持っておいた方がよさそう。

今のところは、以下の４軸ぐらいを持っておいて、チームが合意したもので進めてみたい。

• 「一番実現したいこと」
• 「一番ユーザの利益になりそうなこと」
• 「一番自分たちの利益になりそうなこと」
• 「一番心に響いたこと」

他の会社はどうやって合意形成のプロセスを進めているんだろう？
気になる。

…さて明日。やってみよう！