RSGT2022の発表資料の行間を埋める説明文書
2022年1月6日に、Regional Scrum Gathering Tokyo 2022 (RSGT2022)で、『社内アジャイルコーチの卒論』と題してお話しさせていただきました。
プレゼン資料はこちらです。
一方で、プレゼン資料だけでは伝えづらい「行間」というものもあります。それらを埋めるための説明文書を作成しましたので、共有させていただきます。プレゼン資料と一緒に確認していただければ幸いです。
はじめに
私は、2021年8月末日でLINE株式会社を退職しました。これは、2012年12月に楽天株式会社に入社して以来約9年間続けてきた、社内アジャイルコーチを辞めたということでもあります。
この9年間、非常に多くの人・チーム・組織に関わり、数多の実験と失敗を重ね、社内アジャイルコーチとしてのキャリアを積み重ねてきました。
この度、社内アジャイルコーチを辞するにあたり、これまでのキャリアで得た多くの事例・知見をアジャイル実践者の皆さんに共有することは、日本および世界のアジャイルコミュニティへの貢献になると考えました。
9年の蓄積を45分のセッションで全て話すことは非現実的であるため、説明のしやすさの観点から、(1) チーム、(2) 技術、(3) 組織の3点からお話させていただきます。
1. チーム
この章では、「ヒト」およびその集合である、「チーム」の扱い方について説明します。
アジャイルの文脈では、次のようなチームにどのように接するべきかが、よく議論されます。
- アジャイル初心者のチーム
- 各ロールのエゴが強くて対立の多いチーム
- 他人事感の強いチーム
社内アジャイルコーチとしての経験から言うと、これらへの唯一の正解はなく、自分たちが試行錯誤を繰り返した中で、うまくいったと感じられたものが「正解」と考えます。
そこでこの章では、私が実際に試して「正解」だと感じたものをご紹介します。
(1) アジャイル初心者のチーム
このチームは、「学ぶ」ということを知らないということが主要な課題です。加えて、失敗を恐れ、効率的に学習できない傾向もあります。特に日本人のみで構成されるチームの場合、この傾向が顕著です。さらに、「会社は勉強の場じゃない」・「会社で勉強するな」のような発言をする上司がいる場合、学ぶことを悪だと捉えるバイアスがここに加わります。
上記のようなチームにおいて社内アジャイルコーチは、チームに入り一員となり、一緒に痛い目に遭いながら背中を見せ続けることで学び方を教えるアプローチが有効に機能します。さらに、基本Teaching、場に応じてFacilitatingを使い分ける方法が有効です。
具体的には、コーチが実験と失敗を何度も見せ体験させることで、失敗で学習を加速するという体験をチームに提供します。加えて、コーチが率先して失敗することで、チームに対して「失敗しても大丈夫だ」という安心感・心理的安全性を提供できます。さらに、そのような振る舞いに興味を示すチームメンバーがいる場合、その人が強力な改善のドライバーになりうるため、コーチとしての経験やスキルを教え込むと良いです。また、勉強することで成果につながることを、結果として上司に見せ続けることで、上司が納得せざるを得ない状況にすることも、有効なアプローチです。但し、そのような上司は、後で決定をひっくり返す恐れもあるため、成果を出した段階で必ず意図を説明し、協力を取り付けることが肝要です。
(2) 各ロールのエゴが強くて対立の多いチーム
このチームは、「こんなことも分からないの？」・「これはルールだから従え」のように、他者を攻撃する話し方が多いことが、特徴であり課題です。
より具体的には、「自分の前提は正しい」・「自分の前提は他者も理解しているべきだ」という思い込みを各メンバーが持っていること、またその思い込みを他者に明示的に伝えていないことが共通点です。
そうした思い込み、および言葉と前提のズレの存在を見える化し、チーム全体で認め合うこと、その上でチーム共通の目的に各自の前提を合わせることが、基本的な解決方針となります。その際、NVC（Nonviolent Communication）が有効なアプローチとなります。メンバー間の言葉と心の距離を縮めることができます。
(3) 他人事感の強いチーム
このチームは、自力での課題解決の意思・能力が薄弱で、いつも「他の人・チームがやってくれるはず」と考えていることが課題です。従って、そのチームを課題解決の当事者としてしまうことで、当事者意識への「バリア」を無理やり消すことが、一つのショック療法として有効です。
Flywheelのメタファというものがあります。Flywheelは、ちょっと回しただけではすぐに止まってしまいます。回し続けるためには、常時力を与え続ける必要があります。一方で、力を与え続けると、加速度が徐々に高められます。このFlywheelと同じように、チームを当事者にし続け、常に活動し続けるファシリテーションが、改善に有効に作用します。
また、他人事感が強まる原因として、他の人・チームがボトルネックであるケースがあります。その場合は、社内アジャイルコーチとして、チームと一緒にボトルネックを解決することが、当事者意識を高める点でプラスです。
同様のことは、経営層がコーチ任せの場合にも当てはまります。逆に、経営層のコミットが得られない場合は、遅かれ早かれ施策をひっくり返されるため、チームから離れることを私は勧めます。
この章のまとめは、次の3点です。
- アジャイル初心者のチームは、コーチが背中で学び方を教えることが有効です。
- 各ロールのエゴが強いチームは、NVCで言葉と前提のズレを正すことが有効です。
- 他人事感の強いチームは、当事者意識への「バリア」を消すことが有効です。
2. 技術
この章では、アジャイル推進時に常につきまとう、「技術」の扱い方について説明します。
アジャイルの文脈では、技術の扱い方について、次のような議論がよく行われます。
私の社内アジャイルコーチとしての経験から言うと、これらもケースバイケースです。「コンテキスト依存」という言い方もできます。
一方で、いずれの方法が妥当かを判断する根拠は、あった方が便利です。私はこれまでの社内アジャイルコーチとしての経験から、「MUT」という判断軸を活用しています。
「MUT」とは、以下の英単語の頭文字をつなぎ合わせたものです。
- Maturity: チームの成熟度
- Urgency: 緊急性
- Trust: コーチへの信頼度
ちなみにこの「MUT」は、あくまで私個人の経験ベースで生み出したアイデアで、学術的な裏付けはないです。加えて「MUT」は、厳密に数値的に表現し判断するというよりも、それぞれのバランスを見て判断する形を取ります。社内アジャイルコーチとしての「観察眼」が、そこでは役に立ちます。
(1) 「開発の足回り」
CI/CD/DevOpsなどは、誰がどこまで整備するべきでしょうか？先の「MUT」では、次の2つのパターンが考えられます。
(a) アジャイルコーチが実施するパターン
Mがやや低く、Uが高い場合が、このパターンに当てはまります。
このパターンは、チームに整備の経験がない場合に有効です。また、アジャイルプロセスの習得の緊急性が高い場合、こちらの方が集中しやすく、また後で自動化による加速度的効果を得られやすいです。そのため、私が好んで使用するパターンでもあります。
但し、チームが（社内）アジャイルコーチに頼る恐れ、また（社内）アジャイルコーチがチームに過度にコミットしてしまう恐れがあります。そのため、一人でやりすぎず、必ず早期にチームに引き継ぐTeachingを意識することが重要です。
(b) チームに任せるパターン
MTが高くUが低い場合が、このパターンに当てはまります。
このパターンは、チームに整備の経験がある場合に有効です。また、アジャイルプロセスの習得の緊急性が低い場合に馴染みやすいです。
このパターンでは、Facilitatingが機能しやすいです。Lintやセキュリティチェックなど、チームがまだやっていないことに目を向かせると良いです。他にも、セキュリティチェックやdeployの高速化など、工夫をインストールできる余地があれば、それらにも目を向けられるようにしましょう。
(2) テスト自動化
これも、誰が何をどこまで行うべきでしょうか？先の「MUT」では、次の2つのパターンが考えられます。
(a) チームに任せるパターン
MTが高くUが低い場合が、このパターンに当てはまります。
テスト自動化が（アジャイルでは）開発の一環となりつつあること、およびプロダクトの責任範囲を考えると、チームが担当するのが理に適います。
このパターンでは、ペアプロなどを活用し、開発の一環としてのテスト自動化の考えをインストールするFacilitatingをお勧めします。
(b) アジャイルコーチが実施するパターン
Mが低くUが高い場合が、このパターンに当てはまります。
このパターンは、チームの作業の代行者には絶対にならないことが重要です。チームの成長を阻害しかねません。また（社内）アジャイルコーチは、これが面白くなりすぎて全てやろうとする誘惑に打ち克つことも求められます。
そのため（社内）アジャイルコーチとしては、Teachingを活用し、最初の例の作成に止め、チームメンバーにやり方を教えることにフォーカスすることをお勧めします。
(3) 開発そのもの
（社内）アジャイルコーチは、どこまで関与・寄与すべきでしょうか？
アジャイルコーチが実施するパターン
Tが極端に低い場合が、このパターンに当てはまります。
但しこのパターンは、チームの信頼を急ぎ得る必要がある場合だけ限定した方が良いです。例えば、「理論倒れ」はのコーチは、実際嫌われる傾向があります。そのような問題を回避するために、自身の実力を見せつつ、課題解決を一緒に行うことで、一体感を生み出す「必要悪」的に活用しましょう。
また、どこかで第三者視点を失いかねないリスクがあるため、必要な信頼を得られたら、早期にチームに任せましょう。
この章のポイントは、「チームの学習・成長が全て／中心」であるということです。
社内アジャイルコーチは、触媒・潤滑油であることに徹することが重要です。加えて、実務の実施主体にはならないことも必要です。さらに、これらのパターンだけで情報収集をしすぎないことも必要です。過度のメトリクスは、「管理型」へ陥る恐れがあります。
この章のまとめは、次の3点です。
- MUTのバランスで判断することが有効です。
- コーチの観察眼を活かしましょう。
- ひとりでやりすぎてはダメです。
3. 組織
これまでの章では、チーム・メンバーがメインの説明をしてきました。この章では、一つのチームを良くしただけでは解決できない、組織レベルの課題へのアプローチを説明します。
私たちは、アジャイルに限らず、次のような議論をよく耳にします。
- 会社よりもコミュニティの方が自分を認めてくれるのではないか？
- コミュニティは「逃げ」で、仕事ができない人の集まりなのではないか？
- この会社・同僚・上長・役員に人生を賭ける価値はあるだろうか？
これらの議論は表層的で、より深い分析が必要と私は考えます。私はこれらの分析のために、組織の内側と外側、公式と非公式からなる4象限の考え方を活用します。以下では、この4象限に沿って、先の議論を分析していきます。
(1) 社内の仲間
組織の内側・非公式にある「社内の仲間」・「社内コミュニティ」については、「心のValue Stream」の構築が重要と私は考えます。これは、社内で、価値を共有できる同士、および業務を進める上で協力できる仲間・チームを見つけ、その組み合わせでvalueの提供・価値観の共有・心が折れそうな時のリカバリをできるようにするという意味です。
ちなみにこの言葉は、私の思いつきです。適切な用語があれば、教えてください。
(a) 社内の「お隣さん」を味方につける
これは、書籍『アジャイルサムライ−達人開発者への道』にも書かれている考え方で、自分たちの近くにいるキーパーソン・チーム・組織と関係を構築し、成果を出しやすくしようというものです。
(b) Spotify Model
これは、組織の公式のラインだけではなく、プロダクトや同様の関心事を持つ人たちによるマトリクス型の組織及びコミュニティを活用しようという考え方です。
(c) オーラの泉メソッド by 川口さん
これは、RSGTの運営委員でもあるかわぐちやすのぶさん発案の考えです。自分以外に同じことを言ってくれる人がいることで、自分の主張を他の人にもシームレスに届けやすくなります。
(2) 社外の仲間
組織の外側・非公式にある「社外の仲間」・「社外コミュニティ」は、会社という「前提」から離れて考える点で有効です。
具体的には、会社・社内だけに目を向けていると、視野が狭くなり、心身を消耗させるリスクがあります。加えて、社外コミュニティOSSは、情報収集や学習の手段として有効です。さらに、会社の改善の観点では、「外圧」「世論」を有効活用できることがあります。
また、社外に目を向けることは、決して「逃げ」ではなく、「スキル」であると私は考えます。というのも、社外に目を向けることで心をリセットすることができ、Burnoutを予防・防止することができます。また、良いコンディションは、良い価値を生み出しやすくなる源泉でもあります。
(3) 自社の経営層
組織の内側・公式の、特に「経営層」は、尊重しつつ過度に頼らない、「条件付き利用」という発想が「安全」です。
というのは、経営層の全社的視点と影響力は、明らかに有効ではあります。一方で、常に味方とは限らない点に注意する必要があります。
特に、経営層が意思決定の意思・能力を持たない場合、全部丸投げされて逃げられることもあります。そのような兆候が見えた場合は、強い意志を持ってその組織を離れることを、私はお勧めします。
この章のまとめは、次の3点です。
- 社内の仲間のチェーンを構築しましょう
- 社外に適切に目を向けるスキルを身につけましょう
- 自社の経営層は、距離を縮めつつ依存はしないようにしましょう
結論
ここまで色々とお話しさせていただきましたが、私は社内アジャイルコーチとして、次のように多くの失敗をしてきました。
まず、ラインマネージャーになり、昇進に目が眩み、アジャイルコーチとして皆を成長させることよりも、会社の経営方針にメンバーを従わせることを優先するという失敗をしました。
次に、アジャイルに理解のある同士、自分を理解してくれる同士を社内に見つけきれず、孤独に負けました。
さらに、会社を信用しすぎました。マネージャーや役員に嘘をつかれ、守るべきチームが切り捨てられました。役員間の対立のとばっちりを受け、仲間やチームが会社を去っていきました。会社が自分と同じ方向を向いていると思い込んでいました。
身から出た錆も多いのですが、こうした失敗から私は、以下のことを学びました。
まず、常に自身を組織の外側に置き、当事者にはならないことです。課題は理解するものの、課題解決の当事者にはならないこと。また、自分自身は課題を解決するための手助けであり続けること。これが、アジャイルコーチとして心がけるべきことです。
次に、社内外に仲間を増やすこと。社内に同好の士のチェーンを作ること。社外のコミュニティにも自身の居場所を作ること。社外にメンターを見つけ定期的に対話すること。これらは、孤独に打ち勝ち、自分自身を成長させ続けるために有用です。
さらに、自身の組織での栄達よりもコーチ対象の成長を、そして自身の成長を重視することです。一生涯学習し続けること、そして「教える」であり「教わる」であり続けることが、持続可能かつ実りの多い人生となります。
私自身、ニックネームが「ヒーロー」であることもあり、多くの人の役に立つ「ヒーロー」として、そして「ヒーロー」としてのアジャイルコーチというものを度々意識して行動し続けてきました。
しかし、今の私ならば、自信を持って言えます。火消しのように、無理して目立つような存在としてのヒーローは、もう要りません。自分だけがヒーローになる必要はないし、みんなをヒーローにする必要もありません。
自身と関わる人たち全てが刺激し合いながら成長し続け、課題を解決し続けること。そのための一助であり続けたい。それが、私が社内アジャイルコーチを卒業してたどり着いた、今の境地です。
