今の時代に無くてはならなくなってきた「アジャイルコーチ」という仕事
はじめまして。アジャイルコーチの藤原（@daipresents）です。普段はアジャイルコーチとしてスタートアップからITと関連の薄い大企業まで、幅広くお仕事をさせていただいています。
私のキャリアはJavaエンジニアからはじまり、その後、楽天に移って当時はまだ珍しかったCI/CDの構築や、ソース管理ツールやタスク管理ツールといった、現在では当たり前のように使われている「開発を支援する環境」の整備を担当していました。
アジャイルコーチと名乗るまで
そして、2010年代前半にアジャイル開発を実践するようになり、アジャイルコーチとして社内のプロジェクト支援を行ってきました。当時はあまりメジャーではなかった「アジャイルコーチ」と名乗った理由はいろいろあるのですが、自分がやれることがわかりやすい名前であることや、今後この職業が一般的になってほしいという、うっすらとした期待もあったからです。
現場支援だけではなく、現場のことをより知るために、EC事業のエンジニアリングマネージャとして数年経験させていただいたあとに、メルカリに移りました。
今風のアジャイルを求めて
メルカリでは、「アジャイル開発やDevOps時代にマッチする品質保証の形」をテーマに、テスト自動化やQA組織の立ち上げを経験しました。畑違いの「QA」や「テスト」の分野に興味を持ったのは、アジャイルコーチとして案件に係るなかで常に問題になってきた「QAフェーズがボトルネック」をどうしても解消したかったからです。
残念ながら、次世代のQA組織の構築は、志半ばで頓挫してしまいましたが、その後、フリーランスになり、自分の会社を作って活動を続ける今でも、「アジャイル開発」と「次世代QA」のしごとは続いています。
アジャイルコーチが求められる理由
アジャイルコーチは大人気？
波はありますが、アジャイルコーチという仕事の引き合いは多くなってきていると感じています。大抵は、面談からはじまり、ヒアリングへと続いて、具体的な支援の提案へと進むのですが、たくさんの話を傾聴すると、お客様の抱える課題の本質が少し見えてきます。
情報はたくさんあるが使い方がわかりにくい
私がアジャイル開発に深く関わるようになった10年前と比べると、現在は関連する書籍も増え、当時は探しても見つからなかった事例が、いたるところで共有されています。
情報はあふれるようにありますが、教科書で習ったアジャイル開発を当てはめてもうまく噛み合わないことなんてざらです。
研修のトレーナーは話を聞いてくれるかもしれませんが、研修の僅かな時間のなかで、適切なアドバイスを出せるものでしょうか？
銀の弾丸がない
完璧な解決策はなかなかないものです。実際に現場の課題を聞くとアジャイル開発だけで解決できるものが少ないケースもあります。
ただ、「銀の弾丸なんてない」と思考停止になるのではなく、「銀の弾丸」という言葉を生み出したフレデリック・ブリックス氏が「王道はない。しかし、道はある」と語るように、我々は常に探し続ける、改善し続けるしかありません。
自分たちのやり方を探りながら見つけ出し、普及させ、活用していくという、苦しいが一貫した努力こそ、飛躍的な改善をもたらします。しかし、これはとても難しいチャレンジであり、理解者や協力者が必要になってきます。
アジャイルコーチの登場
私は「アジャイルコーチ」を以下のように定義しています。
- アジャイル開発等を活用して、顧客の達成したいビジョンの実現を加速させる存在
- アジャイル開発等を活用して、開発チームや開発組織を最強に仕上げる存在
簡単にまとめると、ひとつは顧客のために向かい、ひとつは開発チームのために向かう仕事です。
顧客は会社とも言えるかもしれません。結局、会社のどこか一部分だけハッピーになっても、全体でうまくいかないものです。よって、全体感を持つ活動が必要です。
さらに、私は開発チームを良くするのが得意なので、偏りが生まれてしまうかもしれませんが、全体の中でも開発チームの底上げに注力しています。これは私がエンジニア出身だからであり、ソフトウェアを扱う企業にとってはとても大切な手段だと考えているからです。あくまで、開発はひとつの手段でしかないかもしれませんが。
「アジャイル開発等を活用して」と書いているのもポイントです。「それはアジャイル開発ではどうにもならないですよね」ということもあるので、全てをアジャイル開発でなんとかするのは不可能だからです。
案件によっては開発に関わらない場合もありますし、開発側だけにしか関われないケースもあります。ただ、どんな案件であっても、ふたつの視点をもって顧客の課題解決に挑んでいます。
フェーズ別のアジャイルコーチの活動ログ
アジャイルコーチとしての関わり方や具体的な仕事内容
仕事の流れはとてもシンプルです。「コーチ」と名のつくように、最終的にコーチングを主としていますが、場合によってはティーチやコンサルティングしなければならないケースもあります。
- 機能リリースまでの課題をクライアントへヒアリング
- 関係者で課題の原因分析、優先度設定、アクションプランの設定
- 実行
- ふりかえり
これはアジャイル開発の流れにも似ており、銀の弾丸を探し続けるために、関係者と共通認識を持ち、試行錯誤しながら改善を続けます。全体を通してコーチとしての関わりを強めていきます。
しかし、流れは同じであっても、会社や組織によって抱える問題は様々です。この記事ではいくつかよくあるケースに抽象化して紹介させていただこうと思います。
人が増えてきたスタートアップの話
はじめは少人数でやっていた開発も、事業の成長とともに人数も増え、これまでできてきたコミュニケーションの質を維持できないケースがあります。
ビジネス成長はよろこばしいことですが、組織の成長を待ってくれませんし、エンジニアの成長ですら無視して先に進んでしまいます。このギャップが広がると組織やチームはどんどん疲弊していきます。
マネジメント層の採用もひとつの解決策かもしれませんが、まずは今いるメンバーでどこまでよくできるか？ を相談されることが多いです。
まず意識したいのが高速化
求められるのは、さらなる効率化としてのアジャイル開発です。さらに、大人数になってきたときにでも「型」となる仕事の流れを作っておきたいという意図もあります。
いつものようにヒアリングから課題設定、アクションプランを立てますが、ここでのポイントは「開発サイクル」です。
たとえば、多少のリスクを取れるなら、「高速で」開発サイクルを回しながら、できない部分を見つけ、できる方法を「高速で」考えていきます。
ここでいう高速は純粋な速さであり、1日1サイクルでもいいし、1時間1サイクルでもよいです。いつものスピードより速くまわせば、すぐにボトルネックがわかります。さらに、それぞれのイベント（朝礼やプランニングなど）の意味や意義の確認もはやく終わります。
次に意識したいのが「ふりかえり」の質
次にポイントになるのは「ふりかえり」です。
大抵の場合、初回はたくさん問題が挙げられますが、全部解決するのは難しいので、実行力があるチームなら難しいけど大きな課題をひとつとりあげ、実行力がないチームならできる課題を選んで、すぐ解決にとりかかります。
あとはこれを繰り返しながら、スクラムマスターとして活動できる人を育てます。私はよく「私の仕事がなくすのが仕事」と顧客に説明していますが、これを実現するため、育成はいつも大きな課題です。
図：期待値調整や現状確認で使っているロードマップ例。今どの位置にいてどこを目指すかの指針にしている（参考： https://twitter.com/daipresents/status/1316342129271042048 ）
うまくいくときも、いかないときもありますが、成果をあえてまとめるなら、スクラムマスター育成と、開発を回せるようになること。さらに、もっとうまくいけば、改善活動までできるようになることでしょうか。
このあたりの成果も、活動当初に顧客と念入りに期待値を合わせます。
特定の課題を持った開発組織の話
ある特定の課題を相談されるケースもあります。たとえば、最近では、アジャイル（俊敏）な開発が影響してか、「開発ははやくなってきたけど、テストコードやQAフェーズがボトルネックになってリリースまでが結局遅い」という悩みを相談されるケースが多いです。
本来は全体感を持って課題解決に挑みたいところですが、まずは目につくところからなんとかしたい気持ちもわからないこともないので、そういった場合は、その課題に集中して課題解決活動を行っています。
たとえば、「QAがボトルネック」であれば、ボトルネックにならない方法を考えます。人手を増やしてもいいでしょうし、アウトソースしてもいいと思います。ただ、私は個人的に人手ではなく、エンジニアリングやテクノロジーの力で課題を解決していきたいので、テストの自動化であったり、バグが作り込まれにくい仕組みの導入をおすすめしています。
図： 最近ではAI技術を活用したテストサービスが台頭してきている
たとえば、最近知名度が上がりつつあるテスト自動化サービス mabl（メイブル）の導入を薦めています。自分でテスト自動化環境を組み上げる力ある開発組織であればそれでもいいかもしれませんが、サブスク形式ですぐに利用開始できるこういったサービスは、他のSaaSと同じく、今後主流になっていくと思います。
古い言葉で言うなら「車輪の再発明を避ける」ですし、今風に言うならば「時代は所有するより、利用するへ」でしょうか。
こういったエンジニアリングやテクノロジーの力で課題を解決することで、ボトルネックを解消するだけでなく、テストや品質に対する理解を開発全体へ浸透させていく効果もでてきます。
歴史ある企業のIT部門支援の話
最近ではDXブームの影響か、開発組織ではなく、開発会社に発注する立場の企業さまから依頼を受けることもあります。
たとえば、「開発会社がアジャイル開発を進めてくるが評価できない」といった悩みを抱えており、開発側ではなく発注側で改善活動を行います。
受発注の形式ですと発注側が強くなりがちに思いますが、そうならないように、アジャイル開発の恩恵を受けるためにお互いがやるべきことを議論してもらい、納得した上で実行するように促していきます。
開発には開発の都合があり、発注側も同じです。どちらかを決めなければならないなら私のスポンサーとなる発注側を選ぶかもしれませんが、できるだけ中立になり、プロダクト開発の成功を共通ゴールにして改善活動を進めます。
「アジャイル開発」というだけあって開発が中心になる部分はあるかもしれませんが、開発外が本気で取り組んでくれる環境ですと、1段階上のアジャイル開発が実現できます。
その恩恵は単純な開発スピードアップだけではなく、ビジネスや開発といった部門を超えてプロダクトを作り上げていくことで、プロダクトと共に組織も個人も成長いく興奮を体験できます。
これから必要なのは副業などで経験の幅を広げること
認知されるにしたがって成果が問われる
アジャイルコーチという言葉がまだあまり使われていなかった時代に比べれば、今では専門の会社が日本でもあったり、ある程度認知度も上がってきたように思います。
これはとても喜ばしいことですが、そうなると次に求められるのは、アジャイルコーチがもたらす成果でしょう。
高い成果を高確率であげられるアジャイルコーチはこれからもモテモテです。しかし、すでにコモディティ化してしまったアジャイル開発の、教科書的な原理原則だけ語るアジャイルコーチの価値はもう下がってきていると思います。
打率を上げるためにも打席に立たなければならないため、アジャイルコーチとしての経験をどう積んでいくかが問われてきました。
モテモテになるために必要なこと
あくまで私個人の仮説になりますが、ひとつは同じことをきちんと再現できること。もうひとつは、異なった経験をどれだけできるかがポイントになると思っています。
「同じことをきちんと再現できること」は、お客様が成功の階段を2段飛ばし（あるいはもっと飛ばして！）で登っていただくために必要です。
そのためには、過去の経験から似たような事例を思い出し、そのお客様にマッチした方法を見つけ、最短で問題解決できるように促していきます。
似たような経験が多ければ多いほど、習熟度は増し、成功率も高まってきます。
上記がある特定領域を深堀りする形であるなら、「異なった経験をどれだけできるか」は領域を広げるために必要な要素です。
同じ現場はどこにもありません。そのときどきによって変化する環境の中でどう適用していくか。上達するには場数を踏むしかありません。
私は会社内で複数プロジェクトを経験しましたが、比較的似通った課題が多い印象でした。おそらく「同じことをきちんと再現できること」のトレーニングにも最適だったのでしょう。
そして、副業やフリーランスを経て起業してさまざまな企業様の現場に足を運ぶようになり、「異なった経験をどれだけできるか」を一気に学べるようになりました。
比べると圧倒的に後者のほうが経験値は大きく、これはアジャイルコーチに限らずですが、所属する会社に限らず、さまざまな経験は何かと役に立つということだと感じています。