SWAT×Agile Coach: 異なるスキルが共創するまで

こんにちは！Agile SWATチームの谷村、日下、荒瀬です。普段私たちはLINEヤフー株式会社およびグループ会社のアジャイル開発のサポートをしています。

もともとSWATチーム（谷村、日下が所属）とAgile Coachチーム（荒瀬が所属）は別々のチームでしたが、1つのチームとして協働でAgile開発支援をすることになりました。なぜタッグを組んだのか、どのようなシナジーが生まれたかをお話しします。

SWATチームとAgile Coachチーム、それぞれの強みと課題

SWAT チームは、社内のさまざまなサービスの技術サポートを行っています。この名前は、警察の特殊部隊を連想させるような仕事内容から来ています。具体的には、各部門の開発チームだけでは対応できない技術的課題に対応し、依頼内容に応じて適切なメンバーをアサインし、開発チームとともに数カ月間で課題の解決にあたります。

SWAT メンバーは、技術課題に対して持ち前の技術力で突破する力を持っています。また、多くのサービスやプラットフォームでの経験を通じて、広範な知識を有しています。

一方、支援を通じて技術的な改善を実施しても、撤退後に改善が継続しない、または支援の中で組織上の課題があった際に解決が難しいという課題も存在します。

Agile CoachはLINEヤフー株式会社およびグループ企業のものづくりに深く関わり、プロセス改善や仕組み作りの提案や人材育成を行っています。また、セミナーやカンファレンスも実施しています。過去の事例は以下のリンクからご覧いただけます。

• チームの協働関係を強化するスクラム活用方法
• ヤフーとベトナム拠点の海を越えたスクラム開発の話
• 大規模スクラムのプロジェクト実践事例 〜 不確実性を乗り切った工夫の紹介
• ヤフーのアジャイル開発事例を紹介”Yahoo! JAPAN Agile 1st”

Agile Coachはスクラムやリーンなどのプラクティスを組み合わせて、組織に適した改善プランを提案し、コーチします。これまで学んできたアジャイル開発のフレームワークと関連するスキル、組織特有の文化を尊重しながら組織を改善してきた経験の二つが強みです。

以前からSWATのような専門的なスキルが高い部隊と手を組むことで、より深くクライアントの課題解決に貢献できると考えていました。しかし、SWATとAgile Coachのサポート条件やそれぞれが提供する価値や評価基準が異なることから、コラボレーションが困難という課題がありました。

コラボレーションはトップの判断

コラボレーションのきっかけは谷村、日下、荒瀬が同じ組織に編成されたことでした。これまでにもSWATとAgile Coach双方が偶然にも同じ支援先で活動していましたが、お互い支援理由や条件が異なり、有効なコラボレーションにまで至りませんでした。

そこで、組織のトップの判断により、SWATとAgile Coachの混合チーム、つまりクロスファンクショナルチームを作りました。支援前から互いの価値観や強みの認識、支援条件など、複数コーチ体制による協働のためのセットアップをしました。

SWATとAgile Coachの支援準備

クロスファンクショナルチームになった後、SWATメンバーの谷村、日下は社外のアジャイル開発研修に参加し、基本的な知識を学び始めました。異なる専門領域や新しいスキルの学習に抵抗がないSWATチームの素地が幸いし、前向きに取り組めました。

研修後は全員でスクラム勉強会を毎週実施しました。勉強内容は以下の通りです。

• スクラムガイドの読み合わせをしながら、基礎となる原理・原則を学ぶ

スクラムガイドとは、スクラムの権威が作成・公開している、スクラム開発における公式ガイドです。勉強会では、スクラムガイドに書いてある文章に対してコンテキストを想像したり具体化することで、共通理解を深めました。

• 勉強会自体を実際の支援活動に見立てて実践トレーニングする

一方的なプラクティス伝授にならず、撤退後も改善が継続するように、荒瀬が支援時に実際に行っているコーチング、ファシリテーションを体験し、リフレクションを繰り返すことで身につけました。

• コミットメント、評価基準の統一

それまで谷村、日下らSWATのコミットメントは技術課題の解決であり、支援期間内での解決度合いで活動を評価していました。

一方、荒瀬のコミットメントは事業KPIで、定量数値と定性的な活動理由で評価していました。コミットメントを事業KPIに統一し、支援フェーズや組織規模に応じてカスケードダウンした定量評価を持つことにしました。評価には、数字の分析や活動による影響も添えられるようになりました。

支援準備のまとめ

支援準備では、Agile SWATの各メンバーの価値観や評価基準を統一するのに苦労しました。組織ミッションを具体化する過程で、メンバー間の価値観の違いが際立ってきました。

この似たようで非なる価値観は簡単に統一できないがゆえに、常にコミュニケーションを取り頻繁にアライアンスしました。クロスファンクショナルチームになって協調、共創、関係性を構築するためのソフトスキルが格段に磨かれたことを実感しています。

現場に出てやっていること

ここからは実際の現場での体験を話します。

スクラムマスターとしてスクラムガイドの読み合わせを実施

日下が参加したスクラムチームでの役割はスクラムマスターです。参加した当初は依頼主からはSWATとしての期待があり、開発メンバーとして技術課題の解決をしていました。

その中でアジャイル開発の支援も先方に提案したところ、スクラムマスターを担うことになりました。支援先チームの状態はメンバーが流動し要求の変化が多い状態でした。組織課題の改善やプロダクト品質向上を図る目的でスクラムを導入しました。

スクラムマスターとして最初の取り組みは、スクラムイベントの設定やスプリント開始までのToDoリストの作成、スクラムの学習プランの検討でした。

スクラムの学習プランの一つが、Agile SWAT チームの勉強会でも実施したスクラムガイドの読み合わせです。毎朝30分を使って、他チームや企画の方も巻き込んで実施しました。具体的な進め方は、スクラムガイドのPDFを貼ったMiroを使って、各回のファシリテーターと音読者を持ち回りで担当する音読形式で実施しました。疑問や意見、議論は付箋に残しました。（ちなみにMiroからはアジャイル開発ツールというテンプレートも提供されています）

また、読み合わせの事前・事後で理解度を確認するために、10問程度の小規模なテストを実施しました。そして、日下自身も初めて読み合わせを主導する旨を伝え、読み合わせ自体を全員で作り上げたいという意図を共有しました。

図. 読み合わせにスクラムガイド（ Ken Schwaber & Jeff Sutherland – Scrum Guides(2020) ）を使用した Miroの様子

読み合わせが進む中で、その都度ルールをアップデートしていきました。なお、スクラムの哲学を感じてほしかったため、ルールを変更するときは主体的に決定してもらうよう心がけました。とくに印象深かったのは理想的なペースを決めようとする提案とそれに関する議論です。読み進めるペースが遅いという課題感を持った方からの提案であり、それ自体は自分も納得していました。

しかし全員で議論してみると、読み合わせのモチベーションにかなり差があるとわかり、ペースが速いという意見もありました。自分も読み合わせの始め方を反省する出来事であったとともに、それを踏まえてペースを決定できたことは、全員で判断するようにしたことで実現した改善だと思います。

現在は、さらに実践的な勉強会およびプロダクトビジョンに関する共有会を開催しています。

大規模アジャイル開発で Agile Coach

谷村が参加している支援先は、すでに複数チームで大規模アジャイル（以下LeSS）を導入しているサービスです。谷村 が参加する前から先行して荒瀬がサポートしていました。導入初期の過程は昨年のアドベントカレンダーでも記事にしています。

ヤフーとPayPayカードが大規模スクラム合同実践 〜 若手スクラムマスターがやってみた

組織が成長するにつれてLeSSのチーム数が増えてきました。Agile SWATチームの改善には、各チームごとに取り組む独自改善と、その中でも全チームに有効なものの展開の２つがあります。そこでさらにプロダクト品質やチームの活動をより良くする改善サポートへ、谷村が特定のチームにチームメンバー兼コーチとして加わりました。

ここからは改善活動の一部をご紹介します。プロダクト品質改善の計画作りです。以下の項目を最初に作りステークホルダーと合意しました。

• プロダクト品質の改善した状態
• 改善効果はいつごろを想定しているか
• 取り組む上で誰とコンセンサスを取るのか
• 改善チームの選定基準や展開方法
• 改善効果を測る指標やその理由
• 必要な学習リソース
• ステークホルダーへの共有タイミング
• ファーストステップは何か

実際に行ったファーストステップは、テスト駆動開発の導入と完成の定義のアップデートです。

テスト駆動開発を用いることで、早期のフィードバックによるバグの発見、システム仕様の明確化などのメリットを受けられます。今回参加したチームの一部のメンバーにも、テスト駆動開発を実施した方がいいのでは、という声がありました。これを開発スタイルとして根付かせるために、主に二つの工夫をしました。

一つ目はモブプログラミングで実施しました。理由としては手法とそのメリットのイメージをつかんでもらうためには、体験学習が有効だと考えたからです。

二つ目は実際のプロジェクトを対象としました。初期投資を抑え有効な取り組みか早期判断するためです。

次に、スクラムでは品質を担保するために決める「完成の定義」のアップデートです。チーム数増加に伴い、共通の完成の定義の解釈・判断をブレないものにする必要が出てきました。また、組織が成長したことで、完成の定義の基準を向上させることも可能となりました。

現在はテストの自動化の対象を受け入れテストにまで広げ、完成の定義にこのテストも追加できるように取り組んでいます。

おわりに

本記事では、SWATとAgile Coach、それぞれの強みや価値観など、異なるバックグラウンドを持つメンバーが一つのチームを目指した取り組みについて紹介しました。SWATとAgile Coachそれぞれが意識したことを最後にご紹介します。

SWATは、これまでの支援先では技術的な課題を解決することにフォーカスしていました。しかし、この取り組みでは、単に技術を伝授するだけでなく、組織に貢献をするのも重要です。そのためには自身の価値観のアップデートが必須でした。勉強会や研修で原理原則やプラクティスをインプットし、実際の支援でプラクティスの実践を積んだ経験の双方が、その助けになっていたと思います。

Agile Coachはアジャイル開発をSWATに教えるときは一方的な座学ではなく、互いに意見を出し合える場作りにフォーカスしました。またそれぞれが支援先に入ってからは、取り組んだことよりもどのような体験し、学習したかを共有するのに重宝しました。

これからもSWATとAgile Coachは、ともに学び、成長し、組織の改善に貢献していきたいと考えています。