見出し画像

CSP-SM受けてみることにした そのxに向かって「ファシリテーターが全員の意志としての開発をサポートするために何ができるか」

ここまでのあらすじはここから

2.2 ファシリテーターが、その場の全員の総意として開発を進めていくための行動を少なくとも3つあげよ

  • プランニングポーカー:ポイント見積もり

  • Using the Clock:残り時間を教えて発表のタイミングだと気づかせる

  • Encouraging:参加者を巻き込み活性化させる

プランニングポーカー

●やり方

ポイント見積もりの際に、チームメンバー全員で各バックログの相対見積もりを行うゲーム。(ゲームが正しい表現なのだろうか・・・)

※実際にフィボナッチ数列の数字が書かれたカードを出し合うチームもありますが、私のチームではその場で使える手なりチャットに入力なりで表現しています。

●具体例

全員の総意として開発を進めるために、チェックポイントがあります。

  1. 事前のすり合わせなしで同時に数値を出す

  2. 最大の数値と最小の数値を出したメンバーに対してなぜそう思ったのか意見を出してもらう

  3. 意見から改めてポイント見積もりをする

1を行うことで、第一印象や情報操作としてのポイントを提示してもらいます。事前に誰かしらが発言することで、集団心理として悪影響があるからです。

  • 事前に提示された数値が自然と基準になって見積もりをしてしまう心理的効果(名前を忘れた・・・

  • 同じものを出していなければいけないという単純な同調圧力

ここを回避するために同時に出します。

2の重要性は、数値の差分を出すことではなく、「なぜそのポイントが必要と思ったか」の考えの共有が重要です。

3で改めてポイント見積もりをして合意する必要があります。
私はポイントのブレ幅は重要視はしていません。しかし、チームが合意する議論をしているかを見定める必要はあると感じています。

どのプラクティスを使うにしても匿名性が高くない環境だと総意にならないこともあります。しかし、その場合の問題は技量ではなくチームの関係性だと考えています。オープンに自分の意見を共有できる関係性構築が優先しなければいけません。

●チームでの体験

プランニングポーカーを利用した同時見積もりを実施して、チームのその時の体感を表現することは出来ました。

しかし、それはその場の自分の意思を無理やり表現させるテクニックでしかないと感じました。その提示に自信がないメンバーは、無理やりに意見を出させられる事に不安感を出します。意見を出したとしても、他のメンバーの意見に迎合する会話しかできないこともありました。

このプラクティスを使用すると、ファシリテーターとしては、会議中の総意を作り上げる事が可能になります。

しかし、チームが総意で開発を進めるためには、日々の関係性の積み重ねで自由な議論をする経験をしていないといけないことを学びました。

残り時間のリマインド

一例目でやる気を出しすぎたので、ここからは内容薄めで・・・。

●やり方

会議のタイムキープをしている時に、会議の残り時間やその議題の終わりが近いことを参加者に意図的に共有します。

そうすることで、発言する機会がここにしかないことを発言できていない人に知らせます。

●具体例

意見集約の終了前のタイミングで「これで終了しますが、何か質問や意見はありませんか?」と促します。

終了する前に再度確認をすることで、ここでしか発言できないことを参加者が認識します。

●チームでの体験

自分のチームに対しては、少なくとも会議終了前には最後の時間であることを伝えるようにしています。

実際に会議をしていて、悩んでいる様子だったり、納得がいっていないような雰囲気を出しているメンバーがいる場合に使うと効果的でした。

人によって、理解に時間がかかることもあります。また、意見をまとめる時間が必要なメンバーもいます。
しかし、複数人で会議が進むことで、それぞれの思考の時間軸での進行が難しくなります。

最後に意見を聞くことで、新たに議論が再熱してしまうこともあります。
それでも、総意としての開発ができることは大きなメリットでした。

自動テストのカイゼンについて議論が集中していたレトロスペクティブがありました。そこで、この残り時間のリマインドをしたことで、あるメンバーから「そもそも全体最適を考えると、テストツールが問題ではなく、チーム間での情報共有が問題だ」という意見が出てきました。

その意見のおかげで、手段としてのテスト自動化のカイゼンに議論が白熱していた議論が変わりました。チーム間で情報共有ができていない事が問題なのだから、どのタイミングで情報を共有すべきかの議論に変更し、無事に次のチャレンジに落とし込めました。

巻き込み

●やり方

発言の少ないメンバーに対して、声をかけていくことで意見を抽出する。それにより、全員の総意となる意見の情勢を行う。

●具体例

会議中に発言の少ないメンバーがいる場合に「〇〇さんはどう思いますか?」など話を共有することや、アイディアをもらうようにして会話に巻き込みます。

残り時間のリマインド同様に、それぞれのメンバーのペースや個性があります。そのメンバーが場に馴染み、意見しやすい環境を作る事が狙いです。

●チームでの体験

新しくプロダクトチームが誕生するときに、ステークホルダーを含めた情報共有の会議がありました。
どのようなプロダクトをなぜ作るのかというのを共有する会議です。

私は参加者が参加者を呼ぶ形式の会議のファシリテーターを任されました。

どのようなステークホルダーかはわかりませんが、途中から会議に参加する人もいる10人規模の会議でした。

10人規模だとコミュニケーションパスも多くなるので、固定のメンバーしか発言をしません。
オンライン会議であったので、カメラをオフにしているメンバーもいました。
メンバーの理解度や巻き込まれ状況がわかりませんでした。
説明の区切りをつけるごとに、ランダムに発言ができていないメンバーの状況を伺うことをしました。また、意見を求めることもしました。

単純に「元気ですか?」と話を聞いてみただけでも、そのタイミングで的確な質問をしてくれるメンバーもいました。

その結果、プロダクトの目的と背景の共通認識が取れ、方向性の一致した開発のスタートが切れたと感じました。

まとめ

ファシリテーターとして、会議中にサポートをできることは限られているように感じた。

ファシリテーターだとしても、より創造的な会議にするためには関係者同士の関係性や力関係を見抜く力が必要だと感じました。
また、事前に関係性を作り込めるなら、できるだけそうすることがいいように感じます。

スクラムマスターなら尚更、関係者との関係構築が必要です。
さらにいうと、関係者同士も創造的な会議を行えるように場の構築をする必要があることを再認識しました。