組織にアジャイルな考え方やプラクティスを取り入れていく際、アジャイルに関して豊富な知識と経験を持つアジャイルコーチは非常に頼りになる存在です。Agile Journeyを読む方であれば、もしかしたらコーチングを受けた経験をお持ちかもしれません。
ただし、「アジャイル」は考え方や価値観であり、単一の実装形態があるわけではなく、また、アジャイルに取り組みたいと考える組織の規模や業種、メンバー構成も当然ながらまちまちです。このように前提が不確実な状態で、アジャイルコーチはいかにして依頼する組織の課題と改善のアプローチを見つけていくのでしょうか。
本稿では、こうしたアジャイルコーチにまつわる疑問を、数多くの組織の改革にコーチとして携わってきた吉羽龍太郎（よしば・りゅうたろう / @ryuzee）さんに投げかけます。組織に内在する課題の見つけ方、アジャイルな取り組みを進めていくための準備やアプローチ、そして組織にアジャイルを浸透させていくための考え方など、吉羽さんの言葉には、アジャイルに取り組む人たちの背中を押してくれる多くの示唆がありました。
吉羽さんへの取材はリモートで実施された。
- 「アジャイルに取り組んでみたけど、うまくいかない！」の原因はなんだ？
- 期待値の設定、時間の確保……コーチングを充実させるための準備ってなに？
- コーチングは「検査」と「適応」の連続。根本課題にアプローチする方法を探る
- アジャイルな取り組みを、より広く組織に定着させていくには？
- 関連記事
「アジャイルに取り組んでみたけど、うまくいかない！」の原因はなんだ？
──アジャイルコーチを依頼するクライアントは、これからアジャイルに取り組もうとしている場合と、すでにアジャイルな取り組みを進めている場合の2パターンに分類できると思います。それぞれの組織は、どのようなモチベーションや課題感からコーチングを依頼するのでしょうか。
吉羽 まず「これから組織全体としてアジャイルに取り組みたい」というケースは、組織の上層部から依頼を受けることが多い傾向があります。DX推進と並行してアジャイルという言葉も浸透してきていて、「自社でも取り組まないと遅れてしまう」という危機感が起点にあるのでしょう。アジャイルな取り組みは不確実性の高い環境に組織が適応するためのアプローチであるがゆえに、ソフトウェア開発以外の業種にも適用されるようになってきています。
一方、「すでにアジャイルに取り組んでいる」ケースは、アジャイルを始めてみたもののどうもうまくいっているように思えない、という課題感から依頼を受けることが多いです。「望んでいたアジャイルは本当にこれなんだろうか……」という悩みを抱えていて、現状うまくいっていないことは明らかだけど、どこに問題があるのかがわからない、というパターンです。
「アジャイル」とは考え方や価値観です。組織の従来のやり方、仮にウォーターフォールに慣れ親しんだ組織がアジャイルに取り組むのであれば、価値観を大きく変えないといけません。しかし、過去の価値観や考え方から脱却できないままアジャイルに取り組むので、「どこに問題があるのかわからない」という状況に陥ってしまうケースが見られます。また、アジャイルのフレームワークの1つであるスクラムにしても、公式のガイドには定義や理論だけで具体的なやり方については書かれていません。こうした前提があるので、初めて取り組む人がわからないことばかりなのは当然だと思います。
また、「やってみたけど、うまくいかない」ケースでは、スタート時点での準備不足が原因の場合もあります。たとえば、初めてスクラムに取り組むのであれば、まずはチームの全員でスクラムガイドを読んだり、トレーニングを受けたりして、メンバーの認識のベースラインを揃えることが必要です。しかし、こうした準備が整うより先に始めてしまったばかりに、メンバー間の認識のズレが生じてしまう。ズレを修正するためには結局学習することになるので、それまでに投じた時間が無駄になってしまいます。
さらに言えば、開発チームだけではなく、営業部門や組織外の関係者にもアジャイルについて正しく理解してもらう必要があります。関係者全員の認識が揃っていなければ、アジャイルな取り組みになにを期待するかがズレてしまい、ともすれば炎上案件につながってしまいます。
──課題やその原因が見えないままだとしたら、依頼者はアジャイルコーチにどのような役割を期待したらよいのでしょうか。
吉羽 まず、コーチが入ればすべてうまくいくかといったら、そんなことは全くないですし、1〜２週間コーチが入って劇的に組織が変わるということはありません。アジャイルコーチとは、「炎上プロジェクトを上手にさばく、火消しのPM」のような目の前の課題を解決する存在ではなく、もっと持続的な営みです。
ですから、コーチには「なにかを代わりにやってもらう」ことではなく、基本的にはスキルトランスファーの道具としての役割を期待してもらうといいと思います。
──「スキルトランスファー」ということは、コーチの持つアジャイルな思考、やり方を自分の組織に落とし込んでいく、というイメージですね。
吉羽 はい。初めはコーチが示す手本を見たり、説明を受けたりしながら、一緒に取り組んでみる。そして、一つできるようになったら別のスキルに取り組んでいくということを繰り返し、メンバー内のスキルを上げていくために役立ってもらうというのが、よいコーチの使い方だと思います。
こうしたプロセスはインフラのパフォーマンスチューニングに似ていて、1ヶ所変更して良い結果が出たら継続して次の変更をする、うまくいかなかったら戻す、といったように、着実にちょっとずつ組織やチームを改善していきます。
──アジャイルコーチングは中長期的な取り組みという認識が必要ですね。
吉羽 私の場合、コーチングに着手して、いきなりなにか手を打つことはしません。重要なのは対象のチームや組織の様子をじっくり観察し、メンバーの声を聞くことです。コーチは外部の第三者なので、初見では物事を一面的にしか捉えられません。考えられるアプローチはさまざまですし、改善の適切なペースやメンバーの方々のアジャイルに対する理解度も違うので、観察した上でなにが有効かを考えていきます。
期待値の設定、時間の確保……コーチングを充実させるための準備ってなに？
──クライアントがアジャイルコーチを依頼しようとしたときに、まず知っておいたほうがいいこと、準備しておくことはありますか？
吉羽 依頼を受ける際、絶対に失敗したくないという「完璧主義の呪い」にかかっている組織が多いと感じます。ですが、アジャイルな取り組みというのは、短い期間に区切ることで実験を容易にする側面を持っていますので、小さい失敗はいっぱいしてもかまわないのです。「ミスなく完璧にやろう」ではなく、「トライアル＆エラーを繰り返して適切なやり方を模索しよう」という思考を理解しておくといいと思います。
準備に関しては、コーチングに対して「こういうことを達成したい」という期待値を設定しておくとよいと思います。ですが、具体的な期待値を設定できるということは、組織の課題が理解できている状態といえ、コーチを呼ばなくても自分たちで課題解決に取り組めます（笑）。
──なるほど。コーチが必要な組織＝課題が捉えられていない組織であるとしたら、的外れな期待値を設定してしまうのでは？
吉羽 的外れでもいいんです。大事なのは期待値設定そのものではなく、組織の中で階層をまたがって、チームの課題や、「コーチに期待すること」がなにかを話し合い、考えることだからです。話し合いの中で、チームのみんなが「自分たちのやり方には問題がありそうだ」と認識を一致させておくことが重要なんです。コーチとして呼ばれて行ってみたら、アジャイルコーチを入れたがっていたのはマネージャーだけで、他のメンバーは知らんふり……という状況ではコーチングが成立しませんから。
もう一つ重要な準備は、時間を確保することです。コーチングの過程では、フィードバックしたり話を聞いたりとコミュニケーションに時間を割くことが多いので、メンバーに時間的余裕がないとどうにもなりません。また、時間的余裕がないと、慣れたやり方のほうが早いからといって従来のやり方に流れてしまう。一定の時間は投資しないとうまくならないので、その時間は確保しておくといいでしょう。
──十分な時間を確保するのは難しいケースも多いと思いますが、なにか解決法はありますか？
吉羽 組織としてアジャイルに取り組んだことがない場合、ミッションクリティカルなプロダクトやプロジェクトではなく、安全な環境で時間をとれるメンバーを集めて始めるとよいですね。そして早い段階で目に見える成果を出すことが重要です。改革の機運は長く続きません。ジョン・コッターが「変革の８段階のプロセス」で「短期的な成功を生み出す」と示しているように、組織にアジャイルな考えを定着させるには早めに成果を出すことが必要です。できれば「見た目にインパクトがある」プロジェクトを見つけて成功させられれば、その後、組織の中で「良い先行事例」として紹介していけます。
──アジャイルに取り組む上では、組織構造の整備が必要なこともあると思います。
吉羽 チーム単位でコーチングをする場合、チームに権限が必要なこともあります。その時に階層構造が深くて、なにを決めるにも承認リレーが必要な組織だと、コーチングをスムーズに進めていくのは難しいですね。ただ、Webサービス / プロダクトを提供している企業で、ここまで組織が硬直しているケースは少ないです。
──大きな企業の場合、組織構造を整えるのはさらに難しくなりそうですね。
吉羽 おっしゃるとおり、大企業が組織構造を変えるのはハードルが高くコストもかかります。ですから、アジャイルな取り組みを「小さく始める」ことを検討するといいでしょう。組織全体をいきなり変えるのは難しいので、たとえば組織内の各部署から人を集めてバーチャルチームを構成してみる。そして、チームが集中して仕事できる環境を作り、成果を出していくよう心がけるといいです。バーチャルチームを運用していく中で、部門をまたいでコミュニケーションするよりも、プロダクト単位で人を固めたほうがムダがない、という認識が醸成されてくれば、チーム外にも伝播し組織構造まで変わってくる可能性はあります。
僕が関わったあるお客様は、アジャイルに取り組む際に、従来の情報システム部門や開発部門とは異なるチームを新たに別拠点に作りました。別チームにすることで「従来的なやり方」の制約を受けにくく、アジャイルという新たな取り組みが進めやすくなります。また、新チームの部長がアジャイルな取り組みを熱心に広報したことも良い結果につながっています。幹部やゲストにこの開発拠点に見学に来てもらったり、さまざまなイベントで登壇したりして社内の関心を集めることで、アジャイルの取り組みはスケールしました。結果的に組織がゆるやかにスケールしていきました。
──「小さく始める」の好例ですね。気になるのは「どんな人が」小さく始めるかです。新規でアジャイルに取り組むチームを立ち上げるときに、メンバー構成で意識したほうがよいことはありますか。
吉羽 メンバーの選び方は重要です。当然ですが、やる気のあるメンバーを集めてチームを組むのが、成功のコツだと思います。アジャイルに基づく働き方を気に入っている人はたくさんいますが、もちろん、すべての人に馴染むわけではありません。
アジャイルの実践手法は基本的にはチームで取り組むものです。また、スクラムやペアプロミングといった手法を見れば分かるように、コミュニケーションもかなり要求されます。こうしたやり方に馴染まない気質の人、たとえば「成果さえ出せれば、個人の裁量で進めていい」というやり方が好きな人、ひとりでもくもくとコードを書くのが好き、というタイプの人には、アジャイルな取り組みはフィットしにくいんです。
──アジャイルに前向きに取り組めるマインドが重要なのですね。
技術力は鍛えていけますが、マインドを変えていくのは大変ですから。とはいえ、アジャイルへの情熱があれば、開発経験や技術力は不問でいい、というわけではありません。技術力なくして、1週間や2週間という短いスパンでプロダクトや価値をユーザーに届けられません。だから技術力は絶対的に重要ですが、同時に技術力がすべてではないということですね。
コーチングは「検査」と「適応」の連続。根本課題にアプローチする方法を探る
──実際のコーチングのプロセスをお聞きしていきます。先ほど、まずはチームや組織の様子を観察するところから始めると伺いましたが、コーチングのプランの方向性はどのようにデザインしていくのでしょうか。
吉羽 コーチングに着手する段階で、「1ヶ月後はここまできるようになる。2ヶ月後はここまできるようになる」といったプランが立つことは100％ないです。そもそもチームがどういう状態かは、資料や説明だけで分かるものではありません。だからこそ、先ほど言ったような観察が必要になってきます。その上で、チームや組織がどのような課題を抱えているのかを聞いて深掘りする。そうして達成したいトッププライオリティが見えてきたら、そこに近づくような方策を試していきます。
スクラムの三本柱は「透明性」「検査」「適応」ですが、アジャイルコーチングもこれに近く、「検査」と「適応」の連続です。なにか新たな取り組みをやってみて、検査する。そして、うまくいきそうだったら定着させるし、間違っていそうだったら修正するの繰り返しです。そしてもちろん、チームの成長速度はチームによって異なります。ですから、コーチング開始と同時にロードマップや方向性を定めることはないんです。
──組織やチームが課題を見出す上で大事なことはなんでしょうか。
吉羽 「プロセス」ではなく「プロダクト」にフォーカスして考えてみてください。そもそもプロダクトを開発する理由はなにか、顧客に価値提供できているか、適時デリバリーできているか、といった根本的な問いのなかから課題を探らないと、結局なにも解決しない、という可能性があります。
ヒアリングしていると、「スクラムがうまくいかない」とか「プロダクトバックログアイテムの粒度をどうしたらよいか」というHow（どうやるか）の部分に課題を見出そうとする方が多いです。しかし、話を深掘りしていくと、そもそもチームが生み出すべき価値を届けられていない、という根本的な課題にたどり着くことが多いです。
──根本課題を明らかにしたうえで、Howをどうするかという話になるのですね。
吉羽 そうです。たとえば、スプリントレビューで実際に動作するインクリメントをデモできない、という課題を抱えたチームで考えてみます。こうした課題が生じる原因は以下の例のように、さまざま考えられます。
- ひとつのスプリントでは終わらないくらい大きなサイズのプロダクトバックログアイテムに着手してしまい、物理的に終わりようがない
- サイズは適切なものの、特定個人の開発スキルに期待しすぎてしまい、スプリントがギャンブルになってしまっている
- チームの開発スキルでは追いつけないスケジュールになってしまっている
そして、スケジュール通りに進まないということに対しては、基本的にはスコープを調整するしかありません。ただし、調整するにしても、
- チームの現実の速度できることにまず取り組む
- 機能の網羅性が必要なら全部の機能で100点を取るのではなく70点を目指し網羅性を確保する
- 完成度が重要なら、なにか機能を落とし高優先度の機能の完成度を高める
など、状況に応じていろいろなオプションが考えられます。このようなオプションを示し、チームが適切な判断ができるようコーチングしていきます。
コーチングが進んでいくなかで、「あれ、自分たちは昔よりだいぶできるようになったな」と、チームが自らの成長に気づくタイミングが訪れます。僕の経験則では、きちんと取り組めば3〜6ヶ月ほどで成長が見られることが多いです。もちろん、コーチの僕から見ても、うまくなったと感じられます。
──体感的なものだけでなく、アジャイルな取り組みがうまくいっているかを示す指標もあるのでしょうか。
吉羽 これはアジャイルに限った話ではありませんが、プロダクト開発を行う以上、「プロダクトが価値を提供できているかどうか」を計測するための指標は絶対に必要です。継続的に指標を計測し、開発者だけでなくプロダクトチーム全体で観測し続けなければならない、とクライアントにはよく伝えています。North Star Metricのような指標、さらに、それをブレイクダウンしたKPIは当然必要です。ほかに、開発チームのパフォーマンスを捉えるならば、『LeanとDevOpsの科学』で提唱されているFour Keys Metrics（変更リードタイム、デプロイ頻度、サービス復元時間、変更障害率）も活用できるでしょう。現在の「アジャイルな取り組み」がこれら指標にどのような影響を与えているか、という観点で捉えてみてください。
──アジャイルコーチング自体を評価する指標ではないのですね。
吉羽 僕個人としては、そこにはあまり意味がないと思っています。なぜなら、チームや組織が真に追求すべきは、価値あるプロダクトを素早く提供することであり、アジャイルコーチングの成否ではないからです。
アジャイルな取り組みを、より広く組織に定着させていくには？
──組織の一部で採り入れたアジャイルな取り組みを、全社的に浸透させようとしたときに、どのようなアプローチがありますか。
吉羽 ひとつは、うまくいっているチームのやり方を積極的に共有していくことです。アジャイルに取り組むチームのやり方を自由に見学できるようにすることも、組織に浸透させていく上で有効でしょう。ただし、認識すべきは「アジャイルはチームによって合うやり方が違う」という点です。ときに組織は「標準化」の名の下に画一的なやり方を推進しようとしますが、チームごとにやり方は違っていいんです。
ナレッジを共有していく方法は他にもいろいろあります。アジャイルを実践する、あるいは関心のある人たちを集め、社内コミュニティを作って意見交換できるようにするのも良い方法です。「スクラムフェス」や「スクラムギャザリング」といった社外のアジャイル関連のイベントや勉強会で話すのも有効ですね。社内での個別アプローチよりも社外での実績のほうがアピール手段として有効な場合もありますから。
ほかに、月1回程度、定期的に社内の全チームが集まって合同で自分たちのプロダクト発表会みたいなものを開いている企業もあります。デモデイのように自チームの取り組みの成果を発表するんです。この場合、経営層やマネージメント層も参加して、夕方くらいからビール片手に参加できるような会が理想的です。経営 / マネージメント層が新しい取り組みに関心を持ち、サポートする姿が見えると社内に広がっていきやすいと思います。
すでにアジャイルな取り組みが進み練度が高まっているチームがあれば、トレーニングを通じて浸透を試みるのも王道的手法です。すでに何度もアジャイルな取り組みでプロダクトを開発していれば、メンバーの経験が豊かになり、他者に教えられるレベルになっているはずです。その人たちが教える立場になり、社内で新しいチームを作る時にトレーニングをしたり、社内セッションや勉強会を開催することで、より広がっていくでしょう。
──人が育っていくことによってアジャイルが広がっていくということですね。
吉羽 経験を積むことでどんどんうまくなって、だんだんコーチのような役割をできるようになってくるんです。初めは僕のような第三者が全チームをトレーニングしていたのが、途中から自分たちでトレーニングを提供できるようになります。そうなると、僕の役割は横にいてその人たちが答えられない質問に答えるようなオブザーバー的な立ち位置に変わっていきます。コーチのコーチ、相談役みたいな役割ですね。
このようにチームが自走できるようになるのがコーチングの理想的な結果です。自走段階になればコーチが関与する必要性も減り、顧問的に薄く関わるだけでも十分になります。
──コーチングを経て、根付き始めたアジャイルな取り組みを形骸化させずに継続的に推進し、組織に定着させるためにはなにが必要でしょうか。
吉羽 アジャイルを組織風土へと育んでいきたいと思うなら、急がないことです。定着させるには、年単位で時間がかかるという認識が必要です。
先にお話したように、小さく始め、少しずつ目に見える成果と賛同者を増やしていき、組織に行き渡らせるしかありません。地道なプロセスですが、積み重ねているうちに、あるラインを突破して一気に広がっていく段階に達するときがやってきます。こうした「壁を突破する」タイミングを信じて、焦らずに継続して取り込んでいくことが大事です。突破するまでの助走期間こそ、アジャイルコーチをうまく使ってください。コーチはリクエストに応じて惜しみなく知見を提供してくれるはずです。「自分の守備範囲はここまで」というのは、それこそアジャイルな考え方ではないですからね。
関連記事
取材・構成：森嶋良子
編集：はてな編集部
- 吉羽龍太郎（よしば・りゅうたろう） @ryuzee
- 株式会社アトラクタ取締役CTO / アジャイルコーチ。クラウドコンピューティング、DevOps、インフラ構築自動化、アジャイル開発、組織改革を中心にオンサイトでのコンサルティングとトレーニングを多くの組織に提供している。Scrum Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ（CTC）。『SCRUM BOOT CAMP THE BOOK』、『エンジニアリングマネージャーのしごと』『チームトポロジー』など、数多くの書籍執筆、翻訳も行い、アジャイル関連の発信活動を行う。
Webサイト：ryuzee.com
