事業やプロダクトの成長を目指すとき、必然的にエンジニアリングのタスクも増えてチームは拡大し、開発組織のスケーリングという新たな課題が発生します。アジャイルにおいても開発をスケールさせるフレームワークはいくつかありますが、十分な知見が得られず試行錯誤している企業も多いのではないでしょうか。
クラウド経営管理システムを開発する株式会社ログラスでも、事業の成長に伴っていくつもの課題に直面しました。同社ではスクラムを導入していましたが、チーム間やエンジニア間のコミュニケーションコストが増大したり、チームが担当する領域以外の知識に乏しくなって全体感を把握するメンバーが減少したりしていました。
こうした課題にこれまでのやり方では解決が難しいと判断した同社は、スケールする開発プロセスとしてFASTの導入に取り組んでいます。これまでもアジャイルだけでなくドメイン駆動型設計（DDD）などを積極的に取り入れてきたログラスにおいて、FASTの導入もまた大きなチャレンジとなっています。
同様のフレームワークとしてはScrum@ScaleやLeSSなどが知られていますが、なぜログラスではそうした実績ある手法ではなく、あえてFASTを選んだのでしょうか。その背景と実践について、同社の開発本部長／事業執行役員VPoEの飯田意己さんと、開発をリードしたエンジニアの南部豪さんにお話しを伺いました。
- FAST ─ ネットワーク型組織における流動的なチーミングを特徴とする軽量なスケーリングアジャイルフレームワーク
- 複数チームでのスクラムには連携と調整の課題感がある
- スクラムチームごとにFASTを導入して実践してみた
- 「自律的な組織になるためにFASTをやるぞ」とトップダウンで推進するのは自律的な組織なのかという悩み
- FAST移行の懸念点や戸惑いをガイドラインや対話で解消
- スクラムにしっかり取り組んできたからこそ先行事例がなくてもFASTを自走させることができた
- 導入で見えてきた課題を解決して次のステップに挑戦する
- 合わせて読みたい関連記事
- 飯田 意己（いいだ・よしき） X: @ysk_118
- 株式会社ログラス 開発本部長 事業執行役員VPoE
2015年に株式会社クラウドワークスに入社。エンジニア、スクラムマスター、プロダクトオーナーを経て、2019年から執行役員として開発部門の統括を行う。2020年に株式会社ログラスにソフトウェアエンジニアとして入社。プロダクト開発に携わったのち、1人目のエンジニアリングマネージャーとして組織設計、マネジメント体制の構築、エンジニア採用、採用広報・ブランディングの推進を行う。シニアエンジニアリングマネージャー、プロダクト開発部長を経て、2024年11月より現職。
- 南部 豪（なんぶ・ごう） X: @go_dev5
- 2023年9月に株式会社ログラスに入社。マスタ領域のフィーチャーチームのリードをする傍ら、E2Eや非同期処理など、プロダクト横断的に活用できるものの基盤を整備する。
犬を愛し、犬に愛された男。
FAST ─ ネットワーク型組織における流動的なチーミングを特徴とする軽量なスケーリングアジャイルフレームワーク
インタビューに入る前に、FASTについて簡単に説明しておきます。
▶️ FAST ※公式Webサイト
FAST（Fluid Adaptive Scaling Technology、流動的適応性スケーリング技術）とは、アジャイルなソフトウェア開発をスケールさせる軽量なフレームワークです。アジャイルコーチなどを務めるQuinton Quartel（クイントン・クオンテル）さんが2010年代半ばに提唱しました。
▶️ There's a New Kid on the Agile Block — FAST Agile
FASTの特徴は、開発組織のなかに固定的なチームが存在せず、流動的にチーミングされる点です。やるべきこと（活動アイテム）をやりたい人が必要なだけ集まるチーム組成を、短い期間（バリューサイクル）で繰り返します。どの「やるべきこと」にコミットするかを、各メンバーが自律的に考えて行動することが求められます。
FASTでは、開発に関わるメンバー全体をコレクティブと言い、コレクティブが目指す「目的とミッション」をビッグピクチャーと呼びます。ビッグピクチャーのために必要なあらゆる情報と活動は、コレクティブのなかで可視化されることが求められます。
FASTにおいて唯一定められているイベントがFASTミーティングで、これはOST（オープンスペーステクノロジー）という課題解決のワークショップ手法をベースにしています。OSTでは、メンバーが課題を持ち寄り・コミットし・解決していくプロセスを、参加者が自発的に推進します。
FASTミーティングは次の3部構成になっています。バリューサイクルごとに、どの活動アイテムが選ばれて誰が担当するのかを、マーケットプレイスボードで可視化します。
- 第1部 ... チームごとの状況を共有してコレクティブの理解を同期し、前のサイクルを終了する
- 第2部 ... プロダクトマネージャーがビックピクチャーや状況の変化を共有する
- 第3部 ... ここまでの情報をもとにマーケットプレイスと呼ばれる形式で、次のサイクルに向けた自律的なチーミングを行う
FASTの基本的なサイクルでは、最初のFASTミーティングで情報が共有され、メンバーが自律的に取り組む活動アイテムを提案（ピッチ）して選び、チームが組成されます。数日間で開発し、次のミーティングでまた情報が共有され、メンバーはまた新たなチームに参加します。
FASTの公式サイトでは、この手順をまとめた「FASTガイド」の日本語訳も公開されています。記事公開時の最新版は2024年1月にリリースされたVersion 3.0ですが、全体で7ページというとても軽量なフレームワークになっています（参考までにスクラムガイドの日本語版PDFは18ページ）。
それでは、ログラスがどのようにFASTに取り組んでいるのかを聞いていきましょう。
複数チームでのスクラムには連携と調整の課題感がある
── ログラスでは2024年8月から、メインプロダクトの開発組織においてFASTを全面的に導入されたそうですが、導入までの経緯を簡単に教えてください。
飯田 ログラスのメインプロダクトでは、これまで機能領域ごとに3つのスクラムチームを設け、それぞれが担当するフィーチャーごとに開発していました。しかし、リリースから数年がたち、プロダクトも組織も拡大してきたことで、固定チームが3つあることによる課題がいくつか見えてきました。
この課題へ対応するには開発のスケーリングが必要という話が今年（2024年）の2月ごろから出てきて、4月にスケーリングをテーマにした勉強会を始めました。アジャイルコーチをお願いしている今井健男（@bonotake）さんに主導してもらい、エンジニアリングマネージャーから現場エンジニアまでざまざまなポジションから有志で14名のメンバーが集まりました。
勉強会では、課題の洗い出しとそれに対する開発手法について、およそ2カ月にわたり話し合いました。スケーリングの手法としても「LeSS」「Scrum@Scale」そして「FAST」の3つが主に検討され、最終的にログラスにはFASTが向いているのではないかという結論になりました。
── どういった点で向き不向きが判断されたのでしょう。
飯田 議論の中では、最も移行コストが小さいScrum@Scaleでは、固定チームによる領域をまたいだ開発の課題を解決できるかどうかに疑問があるという意見が出ました。LeSSも移行はしやすそうであるものの、ひとりのプロダクトオーナーが全ての開発チームを見るのは現状のログラスにとって現実的ではなさそうだ、といった意見がありました。
一方、FASTは3つの中で移行コストが最も高く、最もチャレンジングな取り組みではあるけれど、チームが流動的であることや、個々のメンバーが特定の機能領域ではなくプロダクト全体を考える必要があることなどが今のログラスにとって合っているのではないかということで、有力候補としてのポイントになりました。
── 少し話を戻しますが、従来のスクラムによる開発にどんな課題を感じていたんでしょうか。
飯田 例えば、ある機能開発をチームをまたいで進めようとなった場合に、Pull Requestのレビューをどうするのか、開発自体をどちらのチームがリードするのか、開発自体をどこまで一緒にやるのか、といった関わり方の調整に時間を取られることがありました。
チームをまたいだ開発では、チームごとのカルチャーやコミュニケーションのスタイルにおいて小さなギャップがあり、そこをすり合わせながら開発する必要があるため連携が取りづらいという課題がありました。
南部 この10月にリリースされたBS（貸借対照表）機能でも同様でした。当時から私が開発をリードしていましたが、開発に際して3つのチーム全体が連携する必要があり、まさにこの調整の問題に直面して開発スピードに課題を感じていました。
BS機能は、お客様が自分のデータを入力する部分と、入力されたデータが紐付けられるマスターを整備する部分、最終的に数字を画面にレポーティングとして表示する部分から成り立っています。ちょうど当時の3つのスクラムチームが、それぞれの機能領域を分担していたのです。
このときチームによって必要とされる情報の量や粒度が異なっており、詳細な説明が必要なチームとそうでないチームがあって、コミュニケーションにかなり時間を取られました。また、他のチームにPull Requestのレビューをお願いしたときに他のタスクのため時間が割けず、開発がしばらく止まってしまうこともありました。
▶️ 参考：クラウド経営管理システム「Loglass」が、「BS機能」を10月22日（火）より提供開始
スクラムチームごとにFASTを導入して実践してみた
── 南部さんが抱えていた課題は、勉強会の成果によって解決されたのでしょうか。
飯田 実は5月に勉強会が終了した時点では、まだメインプロダクト開発の全体をFASTに移行するとまでは決めておらず、チーム横断でFAST導入を検討する「推進チーム」を組成していました。そのタイミングで、南部のチームをはじめ先行してチーム単位で実証のためにFASTを導入するチームがいくつか現れました。
── リリース時期から見て、BS機能は途中からFASTで開発された成果と言えるでしょうか。
南部 そうですね。BS機能の開発の途中で、従来のスクラムからFASTに移行しました。私自身は勉強会には参加していなかったのですが「FAST」という手法が良さそうだという話をちょうど聞いたのです。
資料や動画が全て残されていたので、勉強会での議論や検討内容もキャッチアップできましたし、すぐに自分が求めるものに近いと感じました。特に、やるべきタスクに対するリソースの配分を自分たちで考えて調整できるところにメリットを感じました。
当時は開発スピードなどの課題感がとても大きかったので、藁をもつかむ思いで6月からチームでFASTを導入しました。メンバーには事前に頭出しを行い、スクラムのあるスプリントが終わったタイミングで、そのままFASTに移行したのです。急な変更でしたが、希望を感じていましたし、メンバーにも協力してもらえました。
── スクラムからFASTへの移行で問題になりそうな点はありましたか。
南部 FASTは、各メンバーにものすごく自律性が求められるフレームワークなので、そこについて不安はありました。それまでのスクラムチームでは、機能領域が閉じていることでWhy・Whatの認知負荷は減らした上で、あるタスクに対してどう開発するかという「How」を考えることが多かったのですが、FASTではプロダクト全体の視点から「なぜ今やるのか」「どうしてこのやり方なのか」といった「Why」の部分まで各メンバーが考えないといけません。
── 実際に移行はスムーズに進みましたか。
南部 とりあえず最初のFASTミーティングをやってみましたが、率直な感想として目指したことは何も実現できませんでした。形だけのFASTミーティングになっていて、結果的にそれまで担当していた作業をそれぞれのメンバーが引き継いで開発するだけだったのです。
── どう対応したのでしょうか。
南部 皆の意識を変えないといけないと思い、アジャイルコーチに相談しながらFASTミーティングの進め方を改善していきました。まず、現在の市場・プロダクトが置かれている状況・お客様がどういったことで困っているのかといったエピソードを、PdMに話してもらうようにしました。
また、マーケットプレイスで着手したい活動アイテムをピッチ（提案）する人を、毎回変えてもらうようにもしました。
週2回ほどのペースでFASTミーティングを開催していますが、最初の1カ月は毎回いろいろな工夫をしながら悪戦苦闘していました。そうやってFASTの考え方と進め方がメンバーに浸透していくにつれて、開発のサイクルも回るようになってきました。
── FASTでの開発はどんなサイクルになるのでしょうか。
南部 FASTには、スクラムのスプリントのような決められた期間はありません。FASTミーティングも、デイリースクラムに近い位置付けと考えた方がよいです。
── スプリントのレビューとプランニングを合わせたようなイメージでしたが違うんですね。
南部 はい。担当した活動アイテムについて、次のFASTミーティングまでに必ず何かの成果を出す必要はありません。ただし進捗の目処は共有するので、そこが小さなゴールのようになります。その結果、タスクが細かい粒度で区切られ、スピード感のある開発ができるようになりました。
こう話すと締切に追われるイメージに捉えられるかもしれませんが、小さなチェックポイントごとに目標を確認しながらの作業になるので、ちょうど心地よい焦りを感じられます。
── バリューサイクルが短いわりには追い立てられる感じにはならないんですね。
南部 気を付けないとそうなってしまうかもしれませんね。ただ「そうならないように」という意識は全体で共有できています。メンバーが自律的に関わることも大きいでしょう。
── 6月末の開発生産性カンファレンスでFASTの導入が紹介されたころはそういった状況だったんですね。
