はじめに
本記事は、開発生産性カンファレンスに向けて発信する、ログラスで導入したスケーリングフレームワークFASTに関する連載記事「#私から見たFAST」シリーズの4記事目です。
FAST導入の取り組みの変遷をお伝えできればと思います。
内容は、弊社エンジニアの粟田とアジャイルコーチとして参画いただいている今井氏にインタビューを行い、その内容をもとに福土が記事を構成しました。
なお、FASTの詳細な考え方ややり方などについては詳しく触れません。
詳しい情報を知りたい方は、下記をご参照ください。
FAST Guide
FAST導入の背景と理想状態
ログラスでは、従来複数のスクラムチームで開発を行っていましたが、以下のような課題を抱えていました：
- 機能領域に閉じた開発の課題
- 組織成長・異動に伴う調整コスト
FAST導入前は各機能担当のチームが固定でした。
チームが固定であることは特定の機能領域に閉じたディスカバリーや機能開発であれば効率的です。
ただプロダクトの規模が大きくなるにつれ、プロダクト戦略の中で1つの機能領域に閉じない提供価値を模索する必要があり、今までにない密な機能横断的な連携が必要な状況でした。
これによってチーム間の連携にかかるコストが徐々に大きくなっていました。
また、新規事業立ち上げによる異動が発生し始め、メンバーの配置変更や新しいチーム編成に伴う調整コストも都度発生していました。
特定のドメイン知識を有する開発者がチームから離れることで、知識が少数のメンバーに属人化し、開発速度の低下やリスクの集中といった課題もありました。
これらの課題は、組織の拡大や既存社員の新規事業への異動によって、今後さらに顕在化してくることが予想される状況という背景でFASTを導入しないかという話が上がっていました。
理想状態
ログラスではFAST導入により、いくつかの理想状態を目指しています。
- 全体のプロダクト課題を組織全体が認知し、機動的な開発が推進できている
- 多能工組織への移行
多能工組織について補足すると、こちらは専門性を保ちながらも、1人のメンバーが複数の業務に対応できるような人材を育成し、必要に応じて異なる領域でも貢献できる組織を指しています。
ログラスにおいてもプロダクト戦略上ドメインである経営管理全体のビジネスにフォーカスして課題解決を行う上で開発組織が多能工であることが必要であると考え、こういった理想状態を目指していました。
FASTは、最小限の構造と流動的なチーミングを通じて適応性と創発を実現する超軽量なスケーリングフレームワークであるため上記の理想状態を目指す上で適切と判断し、導入に至っています。
この記事を読む上での前提知識
この記事を理解するために、以下の概念を説明します：
- コレクティブ：複数の機能開発チームを統合したチーム単位
- バリューサイクル：FASTにおける開発サイクルの単位。このバリューサイクルごとにチーム編成を見直す
- マーケットプレイス：メンバーが取り組みたい活動を提案・説明し、他のメンバーがその中から参加したい活動を選択することで、自然にチームが形成される仕組み
- スウォーミング：複数のメンバーがSwarmして(群がるようにして)1つのタスクに集中して取り組む協働スタイル。開発物のリードタイムを短くし、チームの問題解決能力を向上させ、チーム内のナレッジシェアを促進させる効果がある
- 枠（スロット）：特定のタスクや目的のために編成される作業枠。従来の固定チームとは異なり、必要に応じてメンバーが流動的に参加する。ログラス独自の呼び方
- 枠数制限：カンバンのWIP制限を流用したもの。枠の最大数を決めておくことで、並列に活動できる最大のチーム数を制限し、スループットの向上やチーム間の協力が促進されるプラクティス。ログラス独自の呼び方
理想状態に向けた3つのフェーズ
以下では、FAST導入から2025年6月現在までの約8ヶ月間の変遷を3つの時期に分けてご紹介します。
「プロダクト提供価値を高める模索」期（2024年8月〜10月）
この期の位置づけ
この期は、「全体のプロダクト課題を組織全体が認知し、機動的な開発が推進できている」に向けた初期の取り組みがあったように感じます。
当時の状況
この時期の大きな背景として、プロダクトの提供価値の優先順位づけが複雑な状況にあったことが挙げられます。
スタートアップ特有のビジネス環境の変化が激しく、お客様との案件が多数並行して進む中、機能単位での意思決定が求められる場面が多くありました。
また、ロードマップは非常にタイトなスケジュールとなっており、現実的にリリースできる機能数とのバランス調整が困難な状況でした。
こうした状況下で、FAST導入初期は、複数の価値提供を可能な限り並行して模索するというマインドセットがメンバー間で強い時期でした。
FAST導入のアプローチと適応度の差
弊社では、まず各スクラムチームが個別にスクラムからFASTへ移行し、その後でチームを統合してコレクティブを形成するという段階的な導入を行いました。
この導入過程で、元々のスクラムチームによってFASTへの適応度に差が生まれています。
適応度に言及する上で重要なポイントは枠数制限です。
FAST提唱者であるQuinton Quartel氏が書いた記事ではカンバンのプラクティスをそのまま利用しているためWIP制限と言及されていますが、WIP制限を行わずにFAST活動が進む中で、それぞれのチームの進捗が遅く追跡も難しい状況となったという言及があります。
したがってログラスでもスクラムチームであった時に各チームにて枠数制限を設けてFASTへの移行を図りました。
一部のスクラムチームでは、スウォーミング文化が根付いており、それが結果的にFASTととても相性が良かったため、FASTを上手く使いこなしていました。
そのチームでは枠数制限も問題にならず、結果的には枠数を余らせるほどでした。
一方、別のスクラムチームでは、従来の1人1タスク制に慣れていたため、スウォーミング文化があまり根付いていない現状がありました。
その結果このチームでは枠数が複数立ち上がったままタスクの並列開発化が進んでいました。
これらチームを統合しコレクティブを組成してFASTを開始した結果、以下のような事象が発生しました。
- 枠数の上限を常に全部使い切ろうとする
- 加えて運用タスク用に残していた枠で新規開発を行う
一部のプロダクトではなく全体のプロダクト課題にメンバーが向き合えるようになったことは良かったのですが、その結果並列で様々な課題に向き合うという動きとなってしまい、当初の理想であった機動的な開発ができているとは言い切れない状況であったと思います。
得られた学びと次期への活かし方
この期では以下の学びを得ました：
- 新しいフレームワーク導入時は既存チームの文化や働き方がそのまま持ち込まれる可能性がある
- スウォーミング文化が根付いていないチームではFAST導入前の準備が重要となる
この時期は枠数制限の重要性が認識されておらず、だんだんおざなりになっていたのですが、次期では改めてその重要性と向き合うことになりました。
「品質と効率の両立」期（2024年11月〜2025年1月）
この期の位置づけ
この期は、「全体のプロダクト課題を組織全体が認知し、機動的な開発が推進できている」に対してさらに進展させようとする動きが多かったように思います。
品質課題への対応
この時期は、障害の発生が通常より多くなるなど、品質面での課題が顕在化した時期でもありました。
FAST導入の影響もあったと思われる一方、前述のタイトなスケジュールなど、それ以外の要因も複数あったと考えられています。
先ほどの話にも関わりますが、枠数を使い切るということは、それだけエンジニアリソースが分散し、1つの枠あたりの人数が少なくなることを意味します。
また、各機能ごとにキーパーソンとなる人が全ての枠に入ることはできないため、開発物の品質が下がる可能性もあります。
こうした状況を受け、エンジニアリソースの集中を目指し、通常開発の枠数をそれまでより半分ほどに大幅に制限しました。
改善専用の枠の設置
この時期の重要な変化として、改善専用の枠が正式に設置されていることが挙げられます。
改善専用の枠では、アラート対応やCSからのお問い合わせ対応、上記対応以外の時間はアラート削減の改善を実施するというルールを設けていました。
これにより、従来後回しになりがちだった改善・運用系のタスクに取り組むことができるようになりました。
得られた学びと次期への活かし方
この期では以下の学びを得ました：
- 枠数制限により、足りない枠の中で何に集中するべきかを考えるきっかけになった
- 改善専用の枠により、運用・改善タスクに組織的に取り組むことが可能になった
- 枠が少なくなることでメンバーの配置に余裕が出て、枠ごとに必要となるケイパビリティを有したメンバーを呼び込みやすくなった
品質と効率の基盤は整ったものの、チーム固定化による新たな課題が見えてきたため、次期では組織全体の最適化に焦点を当てることになりました。
「組織全体最適化」期（2025年2月〜現在）
この期の位置づけ
この期は、「多能工組織」に向けた透明性確保と協働促進の動きが特に見られました。
チーム間の壁を取り払い、コレクティブ全体での最適化を図るための取り組みが様々行われました。
前期で構築した品質と効率の基盤の上に、組織全体の透明性向上とチーム間協働の促進に取り組んでいるのが特徴的です。
チーム固定化による安定化とその副作用
この時期には、前期までの品質課題や枠数制限による制約の中で、各チームが独自の文化を芽生えさせながら、ある程度チームを固定化させて開発を安定させようとする動きが広がりました。
また、ビジネス上の重要な取り組みが複数並行して進む中で、各チームが個別に成果を出すことに集中する雰囲気も強まりました。
しかし、この固定化の動きの副作用として、コレクティブが個別チームの寄せ集めに見える状況、チーム間の繋がりの希薄化、FAST自体の形骸化といった課題が生まれています。
透明性の向上
こうした課題に対応するため、この時期の大きな取り組みとして、マーケットプレイスの改善によるタスクの透明性向上が挙げられます。
障害対応、問い合わせ、障害時のポストモーテムで上がった改善タスクなどの可視化、運用／改善／新規開発タスクをマーケットプレイス上で同列に扱う、「次に取り組むべきタスク」を議論できる素地の整備といった可視化が進みました。
また、チーム間の協働促進に向けて、特定のメンバーが主導する改善の動きが活発化しました。
内部品質や外部品質観点を改善する枠の組成、非機能要件を監視して、適切にエスカレーションする枠の組成、トップダウンで決めるのではなくPdM（プロダクトマネージャー）、EM（エンジニアリングマネージャー）、エンジニア、デザイナーを巻き込んだOKR（目標と主要な結果）の検討などが行われました。
ただし、全員が改善に取り組めていたわけではなく、特定のメンバーが改善を主導するという状態です。
これらは記事のまとめでも書いていますが、これから向き合うべき課題となっています。
得られた学びと現在の取り組み
この期では以下の学びを得ました：
- 全体へ目を向けられていないチームの固定化の場合、安定感はもたらすが副作用として個別チームの寄せ集まりに見える状況やチーム間の繋がりの希薄化が生じる可能性がある
- マーケットプレイスの改善により、タスクの透明性向上とタスク主導の運営に向けた取り組みが進んだ
- ボトムアップの改善はよかったが実態として特定のメンバーが主導する形となっており、特定のメンバーに負荷が偏ってしまわないような工夫が必要
これらの課題に対し、チーム毎の良さは活かしつつ、コレクティブ全体のまとまりのある状態を目指す立て直しが進められています。
理想状態への軌跡と現在地
3つのフェーズを経て、元々の課題を振り返ると、機能領域に閉じた開発の課題や組織成長・異動に伴う調整コストといった問題に対して、以下のような進展が見られています。
全体のプロダクト課題を組織全体が認知し、機動的な開発が推進できている
マーケットプレイスの改善により、コレクティブ内のタスクの透明性が向上し、運用／改善／新規開発タスクを同列に扱えるようになりました。ただし、各チームで独自文化が芽生え、チーム間の協働の自然発生やコレクティブ全体のまとまりの強化が課題として残っています。
枠ごとに必要となるケイパビリティを有したメンバーを呼び込みやすくなり、チームによってはディスカバリーに参入するエンジニアや、エンジニアと共同してAIツールを駆使して体験設計をするデザイナーもちらほら出てくるようになりました。
一方でまだ1人のメンバーが様々な種類の業務に対応できる状態には至っておらず、改善活動も特定のメンバーが主導する形になりやすい状況です。
まとめ
いかがでしたでしょうか？弊社でFASTを導入した約8ヶ月間の変遷についてお話させていただきました。
FAST導入は3つのフェーズを経て進化してきており、各フェーズで異なる課題と学びがありました。「プロダクト提供価値を高める模索」期から、「品質と効率の両立」期を経て、現在は「組織全体最適化」期にあり、そこでの課題改善に取り組んでいます。
現在残っている課題として、チーム間協働の促進や組織全体の最適化がありますが、これらも様々な実験を通して着実に改善を積み重ねることで、理想とする開発組織に近づけるようにしていきたいと考えています。
今後もFASTの進化と共に、より良い開発組織の実現を目指していきます。
イベント案内
7月にアジャイルやFASTをテーマにしたイベントを開催します！
どちらもオンライン / オフラインのハイブリッド開催で、オフラインでは懇親会もご用意しています。ぜひご参加ください！
7月17日（木）19:00- 「アジャイル×AIの今と未来を語る」日本にアジャイルを広めた先駆者・平鍋氏とログラスCTOが「アジャイル × AI」をテーマに対談します。
FASTについてもテーマに取り上げ、両者の視点から語ります。
7月24日（木）19:00-「Loglass Tech Talk vol.6 FAST実践のリアル〜壁にぶつかり、悩み、試し続けた1年間〜」FASTを実践した1年間のリアルな苦悩や試行錯誤を、エンジニア、QA、PdM、デザイナーといった各ロールの視点から発信します！
