はじめに

こんにちは、GxPグループのGraatでアジャイルコーチをしている斎藤です。

この記事はグロースエクスパートナーズ Advend Calendar 2023の8日目の記事です。

さて、今年11月にかけて某クライアント企業に対して、スクラムをベースにしながら実装も全編モブプログラミングで実施するというアジャイル開発入門研修を実施しました。
研修内のモブプログラミング中にいくつかのチームで見られた事象が、モブプログラミングに限らずアジャイルチームでよく見られる事象でありながらも、「チーム開発」にとって大きな問題につながる事象であると感じたため、今回はその事象と解決策を共有します。

事象について

以下の2点がその事象です。

常に、特定のエキスパートが指示をしている
常に、チャレンジングではなく、安全かつ無難な案を合意形成している

上記の事象はモブプログラミングに限らず「チーム活動」の様々な場面で良く見られますし、「特定のエキスパートが指示をしている」のも、「チャレンジングではなく、安全かつ無難な案を合意形成している」のも、状況によっては適切であることも多々あります。

しかし、両者の事象が「常に」発生しているとしたら対処が必要です。

なぜならば、1は、属人化やチーム全体の成長の停滞を、2は、チャレンジングな意思決定と学習を積み重ねる組織やプロダクトに対する劣後という問題をそれぞれ引き起こし、放置すると致命的な停滞という大きな問題をチームにもたらすからです。

さらに、個人的にはこれらの事象はチーム開発にとって恐ろしい事象の一つだとも考えています。

なぜなら、このようなチームは一見仲が良く調和しているように見え、それなりに成果が出るからです。言い換えれば、チームが「安定」しているように見えるため、それが「停滞」という問題だと認識されづらいのが恐ろしいのです。

解決策

ここからは各事象の背後にある原因（課題）を解決するためのアイディアを述べます。

1、2の事象とも、背景にある原因（課題）を考えながら、打開するためのアクションをチームに提案し、実施していくことが解決策です。提案者はチームメンバーやエンジニアリングマネージャーなど誰でも良いのですが、多いのはスクラムマスターやアジャイルコーチだと思うため、ここからはそれを前提に書いてきます。

以下に、それぞれの事象に対する代表的な原因と対策のアイディアの一例を挙げます（もちろん、ここで挙げることはごく一例であり、チームによって原因や解決策は千差万別であることに留意してください）。

1. 「常に、特定のエキスパートが指示をしている」を打開するためのアクション例

属人化の問題点や自己組織化の重要性の理解不足が原因の場合
- チームメンバーに属人化の問題点や自己組織化の重要性を伝える
エキスパートが「指示を出すこと」以外のコミュニケーション方法に不慣れなことが原因の場合
- 指示を出すのではなく、チームメンバーのコーチとして振る舞うやり方を伝える
モブプログラミングの進め方の理解不足が原因の場合
- モブプログラミングの基本的な進め方（ナビゲーターとドライバーを定期的に交代するなど）を教えたり、モブプロパターン（「Riding Shotgun」や「ファシリテーター」パターンなど）を導入したりすることで、特定の人だけが話す状況を防ぐ
チームメンバーの知識やスキル不足が原因の場合
- 勉強会やLearning Sessionなどでチームメンバーの全体知識を底上げする
チームメンバーの権威勾配（チーム内の上下関係）が原因の場合
- 権威や知識が一番低い人間から先に発言するルールをワーキングアグリーメントに加える

2.　「常に、チャレンジングではなく、安全かつ無難な案を合意形成する」を打開するためのアクション例

失敗を非難・糾弾するルールやカルチャーが原因の場合
- （自分の失敗を見せたり、失敗を責めずに学習を促すことなどを通じて）失敗と学習が重要だというルールやカルチャーを形成する
自分たちが手が届かない課題を扱ってはいけないとチームメンバーが思い込んでいることが原因の場合
- 自分たちが手が届かない課題を扱う重要性と、大きな課題を、自分たちで解決可能な課題に分解するテクニックを伝える
チームメンバーが自分たちが持っている枠組みでしか発想できないことが原因の場合
- 「あらゆる制約が無いとしたら、どのような解決策が考えられるか？」といった質問などのコーチングのテクニックを活用する
- イノベーションを起こすためあえて10倍の成果を目指す「10X思考」や、時間を極端に絞り思いもよらないようなアイディアを生み出すための「クレイジー8」などのUXデザインのテクニックを活用する

解決策を実施する際の注意点

ここからは実際にアクションを提案・実行する際の注意点です。

上記に限らずいかなるアクションを採用しても、慣れたやり方を変えることによるチームメンバーからの拒否反応、人間関係の悪化、生産性の低下、失敗などのさまざまなリスクを背負うことになります。
したがって、アクションを提案・実行する際には、チームメンバーだけではなくマネジメントを含むステークホルダーに対しても、それぞれの性格や反応やビジネスの状況などを見極めながら、（「許可を求めるな、謝罪せよ」とあえて説明しない戦略も含めて）慎重に戦略を立て、検査と適応を積み重ねる必要があります。

まとめ

もしもあなたがスクラムマスターやアジャイルコーチならば、メンバーの雰囲気が良く、「ベロシティ」が安定していて、たとえチームメンバーやステークホルダーがその状況に満足していたとしても、冒頭に述べた1や2の事象が見えるようならば、決してそこに踏み留まってはいけません。あなたは、（タックマンモデルで言うところの）「混乱期」にチームを導く責任があります。

大胆にまたは注意深く、ロジカルにまたは共感的に、チームとステークホルダーを揺さぶり続けましょう。

チームの「安定」はゴールではなく、真の意味での「チーム開発」のスタートであり、あなたの腕の見せ所であり、怖さでもあり、かけがえの無い楽しさでもあります。

お互い、頑張ってまいりましょう！

「マーちゃん、俺たちもう終わっちゃったのかなぁ？」「バカヤロー、まだ始まっちゃいねぇよ」（北野武映画『キッズ・リターン』（1996年）より）

はじめに

事象について

解決策

1. 「常に、特定のエキスパートが指示をしている」を打開するためのアクション例

2. 「常に、チャレンジングではなく、安全かつ無難な案を合意形成する」を打開するためのアクション例

解決策を実施する際の注意点

まとめ

2.　「常に、チャレンジングではなく、安全かつ無難な案を合意形成する」を打開するためのアクション例