私がエンジニアリングマネージャーとしてミーティング等をファシリテーションするとき、その内容に関わらず共通して意識していることがあります。そしてディテールを見れば意識やテクニックを使い分けている部分があります。それらの言語化にトライしてみようと思います。

ボリュームが出そうなので何本かの記事に分けて書きます。今回はその第1段です。

どのミーティングにも共通して意識すること、またはEMがファシリテーションをする重要な理由

ミーティングの成功という目先の結果だけでなく、その場での経験がメンバーの関係性、習慣、文化に良い影響を与え、未来の変化の材料となることを意識します。

ファシリテーション時の意識を大雑把に分ければ、①ミーティングを成功させるための意識、②チームが変化していくための布石を打つ意識、の2つが存在するということです。 特に後者はEMの役割と密接に関わりますし、チームの将来像を見据えてるEMだからこそ持てる意識だと思います(スクラムチームであればスクラムマスターが同様のことを考えることになると思います)。

この一連の記事で取り扱うのは②になります。
①については過去にレトロスペクティブのファシリテーションガイドにまとめたことがあるので、よければ併せてご参照ください。

Daily Standup で垣間見える自責思考に向き合う

Daily Standup のファシリテーションでは、チームメンバーの意識の向き先を「個々人の成果」から「チームの成果」に変えるために、考え方の癖の修正してもらうことを意識します。具体例から説明します。

多くの良心的なメンバーには責任感があり、自責思考が備わっています。分かりやすいであろう事例は「自分の失敗は自分で取り返さねば」という行動です。「思ったより進捗が出ずに遅れが発生し、しかしまだ自分が残業してがんばれば計画通りのペースを取り戻せそうだ」という場面で「今日中に終わらせます」と言ってしまう経験は、エンジニアなら誰でも想像できるのではないでしょうか。

もちろん責任感が強いの素晴らしいことですが、もしその遅れがチームにとって致命的であれば、チームの総力をもって解決するほうが良いはずです。

完了できずにいるタスクがチームにとって最優先の仕事であるなら、他のタスクが予定通りに終わっていたとしても、チームの成果としては「一番大事な仕事が終わっていない」となります。それはタスクを終えられなかった個人だけの問題ではなく、「最優先の仕事の進捗よりも優先順位の低い仕事の進捗を優先したチームの判断が間違い」だと捉えられます。

視野をチームの外に広げて、ステークホルダーの目線で考えてみると「チームの誰が遅れを生んだか」よりも「チームは仕事を優先順位の沿って成し遂げたか」のほうが重要であることが想像できると思います。

今回は具体例として『遅れ』にフォーカスしましたが、成果をより良くする場面においても考え方は同様です。主語を『私』から『チーム』に変えて、チームが完遂すべき仕事の優先順位に基づいて個々人のタスクを進行すべきです。

そのためにDaily Standup を実施しているはずですが、この考え方を定着させる際に自責思考の癖の修正が必要になることがあり、そこでファシリテーションの出番です。

ファシリテーションで自責思考を軌道修正する

キッパリと考え方を切り替えてもらうように単刀直入な問いかけを利用します。

先述のような「計画に対する遅れ」の議論をファシリテーションする場合は、例えば以下のような質問を使います。

  • 話題に上がっている問題はチームにとってどの程度の優先順位ですか？
  • その問題の原因分析にどれだけ時間を割きますか？　今イテレーションに残された時間や仕事の優先順位と比較して判断してください
  • 話題に上がっている問題の解決をチームの最優先事項として取り組む場合、誰が何をすると良さそうですか？

「チームの中の誰が責任をとるか」の考え方から「チームの成果を最大にするために何をするか」の考え方へシフトさせるための直接的な問いかけを意識します。

(今後の記事で紹介する予定の)別のミーティングの事例では、チームメンバーの考え方を尊重しつつ緩やかに変化を起こすような問いかけを使うこともありますが、今回のように考え方をガラッと変えること狙うときは直接的な問いかけをするようにしています。

いつも特定の人が遅れる場合は

そうは言っても、「いつも遅れる人がいる」「全然責任感がない人がいる」など、今回紹介したファシリテーションの意識をすんなり受け入れられないチーム事情もあると思います。

すべての事例に解答を持っているわけではないですが、いくつかのアプローチを添えて補足とします。

ジュニアなエンジニアやジョインして間もないエンジニアが、他のメンバーに比べて知識や経験が浅いために計画の精度が低く、結果遅れが生じる場面はしばしばあると思います。
それに備えるには、チームは最初から「計画が変更になる前提」でいると良いです。最初につくった計画の精度は40％程度であると捉え、まずは1日手を動かしてみてその実践を材料に計画を修正することを、あらかじめ計画しておきます。

ここまで読んでAgile 開発経験値の高い人は気付いていると思いますが、Daily Standup の本来の使い方がこれです。進捗を元に計画の見直しをすることが本来の目的です。

ですので、既にこれは実践しているけれどそれでも遅れ続けている人に困っている事例に対し別の選択肢を提案するなら、ペアアサインはいかがでしょうか。見積もりが上手い人や、そのタスクへの適正が高い人、仕事の進め方が上手い人などとペアアサインすることで仕事の仕方を学ぶ機会が増え、同時にそれまでの遅れの原因を発見できる可能性があるからです。

それさえも有効打にならず遅れ続ける人がいる場合、その人の適正の問題やチームメンバーとの関係性の問題などを考えるようにしています。少なくともその人が故意に遅れているはずはないですし、自分たちが採用して受け入れた人であれば能力が劣っているはずもありません(可能性の話をすれば悪意や能力不足の可能性もゼロではないですが、疑わずに信じることができなければそもそもチームとして破綻しています)。
チームメンバーには能力があり、タスクを完遂したい気持ちも責任感もあり、その上で遅れが生じる何らかの要因があると捉え、根気強く原因切り分けをしていくことが重要です。

おわりに

今回はDaily Standup のファシリテーション経験を思い出しながら書きました。

チームメンバーの意識の向き先を「個々人の成果」から「チームの成果」に変えることになぜこんなにもこだわるかと言うと、その先に自律的なチーム、自己組織化されたチームがあると考えているからです。チームが変化していくための布石を打つのは、変化の先にある自律的なチーム像を描き、そこに至るためのステップとしての行動というわけです。

今後は「ふりかえり」「課題バックログのリファインメント」「チームビルディング系ワークショップ」などのファシリテーションについて書こうと思いますが、他にも聞いてみたい事例があればぜひ@aloerina_までご連絡ください。どなたでも大歓迎です。