FASTをやめて1年が経ったので取り組みを振り返る

はじめに

こんにちは、ログラスの飯田です。

ログラスの経営管理プロダクトの組織では2024年8月からFASTというアジャイルフレームワークを用い開発を行っていました。
当時、国内の事例はほとんどなく、ログラスからは国内初の事例としてFASTに関する記事を積極的に発信していたのでご存じの方もいるかもしれません。

さて、そんなFASTですが実は2025年の10月ごろに取り組みを終了しています。

公式な発信として取り組みを終了したことを発信するのはこの記事が初になるため、その後どうなったのか？と気になっていた方はぜひお読みいただければ幸いです。

時系列の整理

最初に、全体の流れを並べておきます。

大きな点は組織構造が2025年8月に職種別の本部からプロダクト別の本部体制に移行したことです。

なぜ今まで発信しなかったのか

理由は2つあります。

1つは、組織再編とその後の体制安定化に注力していたからです。2025年の秋から翌年の春にかけて、開発組織はかなり揺れていました。対外発信よりも内部の安定化に全リソースを集中させる判断をしていました。

もう1つは、個人的な理由です。最終的に取り組みをうまくいかせられなかった、という事実を自分の中で内省するのに、正直なところ時間がかかりました。国内初の事例として発信してきたものを、やめましたと書くのは私の力不足に向き合う必要もあり、何をどこまで自分たちの問題として言語化できるのか、自分の中で整理がつくまでに1年かかった、というのが正直なところです。

したがって、この記事はフレームワークの良し悪しを説くものではありません。私の所属する経営管理という一つのプロダクト組織で、何が起きて、我々がどう判断したかの記録として読んでいただければと思います。

検討期 - なぜ選んだか

当時の課題

当時の経営管理プロダクトは、機能領域ごとに分かれた3つのスクラムチームで開発していました。この体制の課題が顕在化したのがBS機能といった領域横断の大きな開発でした。3チームの連携が必要になったとたん、以下のような課題に直面しました。

1. 機能領域に閉じたフィーチャー開発の目線から、プロダクト全体の価値になっているかを検証する必要がある

2. 機能領域ごとのチームそれぞれのカルチャーが形成されており、領域を跨いだ開発に、都度調整コストがかかる

3. ドメイン知識が領域ごとに分断され、全体を把握・判断できるメンバーが少ない

3案を比較してFASTを選んだ

2024年4月から約2ヶ月、アジャイルコーチの今井さん(@bonotake)に入っていただき、EMから現場のエンジニアまで14名で勉強会をやりました。比較したのはScrum@Scale、LeSS、FASTの3つを検討し、最終的にFASTを選択しました。

• Scrum@Scale

  • 移行コストは最も小さいが、領域横断の課題が解けるのかに疑問が残った

• LeSS

  • 移行は容易だが、単一POの前提が当時の体制では現実的ではなかった(課題3に該当)

• FAST

  • 移行コストは最も高いが、適応的なチーミングとプロダクト全体思考が、解きたい課題に合致していた

意思決定に至る過程でも多くの議論がありましたが、この記事では割愛します。

導入に際して社内では「手引き」といったドキュメントを作成しました。選定理由がこう残っています。

2つ目について、ブランディング起点でHowを選択することは本質的ではないのですが、これまで創業期からDDDといった設計手法を価値を享受できるレベルで実践してきたという組織的な自負もあり、これができたら純粋にすごいと思えるものにチャレンジしようというモメンタムがありました。
またFASTそのものについての細かい解説はこの記事では触れず、公式のGuideおよび弊社メンバーによる過去の記事を参照ください。

検証基準も置いていた

導入時に、2025年4月を期限とした検証基準を置いていました。プロダクトKPIの目標達成に向けて課題を組織全体が認知し機動的な開発が推進できていること、市場不具合率が悪化していないこと、MTTRが悪化していないこと、CS側から見たときにコミュニケーションコスト（MTGなど）が増えていないことの4点です。

結論から言うと、この基準でFASTを評価することはできませんでした。指標は確かに目標水準に届いていませんでしたが、その要因はターゲット選定やオンボーディング、顧客側の事情も含まれ、開発プロセス固有の因果関係を説明することは難しいものでした。基準を置いたこと自体は良かったと思いますが、プロセスの効果を測るには遠すぎる指標となっていました。

一方で、当初置いた検証基準以外のところで課題が表出化したとも考えています。

誰がこのプロセスを導入するのか？このプロセスは誰を助けるのか？

導入前の2024年7月、私はこんなことを悩んでいました。「自律性を重視するFASTを、マネージャーがトップダウンで推進することは自律的なのか？」

この悩み自体今でも妥当な観点だったと思いますが、より重要だったのは「トップダウンかどうか」ではなく、「誰の視点で選んでいるのか」だったと振り返っています。

FASTはエンジニア視点でスケーリングしやすいという観点から選ばれています。もちろん、エンジニア以外のメンバーにとってもメリットがあると考えて意思決定していますが、PdM視点でのやりづらさには、当時の私はきちんと向き合えていませんでした。連載記事で当時のPdMが書いていた一文が、それをそのまま表しています。

これは当時の組織構造とも繋がっています。当時、チームは職種横断で組んでいたものの、組織図とマネジメントラインはプロダクト本部（PdM、デザイナーが所属）と開発本部（エンジニアが所属）に分かれていました。つまり職種横断を前提とするプロセスを、職能で分かれた組織図の上に載せていたことになります。

このGapはFASTをやめる決断をするまで埋められずに残ることになります。

どう入れたか

ここは、今回振り返るまで自分でも言語化できていなかった部分です。

当初の計画は「それぞれのチーム内で試行し、年内までに組織全体へ展開する」でした。それが2024年7月8日の推進チームの議論を経て、早期の全体移行に変わります。

議論の論点は、「小さく始めるかどうか」ではなく、「どの単位で小さく始めるか」でした。

• 当時のVPoEの意見：小さく始められるやり方を考えた方がいい。ただしその単位は機能チームではなく、ビジネス単位のほうがよいのでは。同時に、事業目標を鑑みるとある程度ゴリッと進めて早く失敗して学ぶ必要があるフェーズに来ている

• アジャイルコーチの懸念：ある機能単位で切り出すと、メンバーを剥がされた残りのチームがパフォーマンスを落とすのではないか。それを避けるなら、結局全体をFASTにするしかなくなる

結果として、「全体での試行をさっさと始めてしまったほうがいい」という方向になりました。

ただし、見落としていたことがあります。

この時点で、チームによってはうまく回っていたとは言えない課題が残っていました。翌日にコーチがまとめた現状認識には、こう書かれています。

これは、その後1年以上にわたって、まったく同じ形で残り続けた課題です。終了を決める2025年9月の議論でも、同じことを別の言葉で話しています。

つまり、1チームで解けていない課題を、解けないまま3チームに広げてしまった。

これはエンジニアに閉じないプロダクト組織全体のケイパビリティの課題をプロセスで解こうとした見誤りだったと感じています。

FAST期 - 何が起きたか

当時のブログ記事では、3つのフェーズに分けて振り返っています。
プロダクトマネジメント観点とは別に、エンジニア視点の課題も表出化しました。

フェーズ1：提供価値を高める模索（2024年8〜10月）

当時の私の評価は「意外とスムーズ、もっと早くやればよかった」でした。チームの解散と再編成そのものは、思ったよりも大きな混乱なく回っていました。

一方で、この時期から兆候は出ていました。枠（スロット）※の上限を常に全部使い切ろうとする、運用タスク用の枠で新規開発をしてしまう、といったことです。

※枠（スロット）： 特定の目的やタスクのために一時的・流動的に編成される作業枠（チーム）の社内用語

フェーズ2：品質と効率の両立（2024年11月〜2025年1月）

障害の発生が通常より多くなるなど、品質面の課題が顕在化します。一つの要因として以下のようなサイクルがありました。

枠を使い切る → リソースが分散する → 1枠あたりの人数が減る → キーパーソンが全ての枠に入れない → 品質が下がる

対策として、通常開発の枠数を約半分に制限し、改善専用の枠を設けました。ただし、この対策でも障害件数をゼロにすることはできず改善が着実に積み上がっているという実感には至りませんでした。

フェーズ3：組織全体最適化（2025年2月〜7月）

チームをある程度固定化して安定させる方向に動きます。これは一定の効果があった一方で、副作用もはっきりしていました。当時の社内資料の表現をそのまま載せると、「コレクティブが個別チームの寄せ集めに見える状況」「チーム間の繋がりの希薄化」「FAST自体の形骸化」です。

この学びは私の過去の登壇資料でも触れており、THE ENTERPRISE AND SCRUMに載っているコア開発者の制約が表出化しました。

内部的にはディスカバリーツリーによって横断的な可視性が高まり、プロダクト全体の議論に各メンバーが関わりやすくなったというメリットの一方で、短寿命のチーム、リソース分散といった課題が品質や育成に与えていたデメリットも明確になりました。

課題の整理

これらの課題はより構造的な捉え方をすべきだったと考えています。

1. 非常時に単独で決める人を置けなかった

「集合知」は「合議」ではありません。FASTは集合知を前提としていますが、合議は推奨していません。導入段階でも、全体で合意しなくても決められるような設計がなされていました。平常時は、それで回っていたと思います。

問題は大きな意思決定の際で、優先順位の判断や緊急時の判断には、単独で決める(スクラムでいうところの)プロダクトオーナー的な人が必要です。その役割をPdMに求めましたが、当時のPdMの体制においては機能しませんでした。新規事業や既存の重いディスカバリーにリソースを寄せる必要があり、デリバリーまで関与する余裕はありませんでした。

そのような状況においては一定開発チームからデリバリーの意思決定を担っていく必要があり、集合知で機動的に判断していく形を取ろうとしました。

一方で、実態としては個々が持っている知識や能力を集結させれば解ける問題だったかというとそうではなく、結局のところ、純粋に大きな問題に対して大きな意思決定ができる人（もしくは組織的なケイパビリティ）が必要であったという振り返りになると考えています。

つまり、一人の人が持つのが難しいから集合知で解決しようというアプローチの前提が揃っていなかったということです。

2. 外から進捗が見えなくなった

2024年8月、我々はEMの役割に「他部署に対する説明責任」を置きましたが、同時に「タスクのアサインなどのマイクロなマネジメントはしない」と定義しています。

結果として細かい状況把握が難しくなり、「EMに聞いても現場に入っていないため、どうなっているのかがいまいちわからない」状態が発生しました。

ただ、これはより深い構造的な課題があり、VP・PdM・EMの三層にまたがる課題として捉えた方がよいと考えています。VPだった私自身も現場への関与が薄くなり、何が起きているかを把握するのが難しくなっていました。

FASTでは、説明責任はコレクティブの各メンバーが果たす、という設計思想があり、個々の練度が求められるフレームワークです。一方で、部門間のコミュニケーションの練度のばらつきはありましたし、そのばらつきに対してどう責任を果たすかというマネジメント的な設計も不十分でした。結果として部門外からみたときの透明性が低くなったという結果になりました。

3. 育成のコストを見積もれなかった

チームの寿命が短く、編成を現場が決める状態では、誰が誰を見るのかが定まりません。オンボーディングと育成の主体があいまいな状態が発生してしまいました。

ただしこれを「チーム編成を流動的にすると育成ができなくなる」とまで言うのは、断定しすぎだと思っています。正確には、育成の難易度が上がる（コストが上がる）ということです。

そして経営管理というドメインの複雑さが、要因としてかなり大きいと思います。もっとドメイン理解が容易なプロダクトであれば、ここまで苦労しなかったはずです。つまり、我々はそのコストを十分に見積もれず、制御しきれなかった。

ちなみにFAST公式は、むしろ「学びやすさ」をフレームワークの長所に挙げています。ルールが極小で、覚えることも制約も少ないからです。ただ、それはペアプロのような常時協働が当たり前にある、という暗黙の前提の上に成り立っているのかもしれません。

どうやめたのか

2025年8月の組織再編では、プロダクト組織として戦略を経営から現場まで一本化すること、情報流通などレポートラインの透明化を強化することを目的に、それまでの職種カットの本部体制からプロダクトカットの組織体制に移行し、新たにプロダクトごとにプロダクト開発責任者というロールを設置しました。

この移行を経る中で、8月時点では方針は「FASTの仕組みは残す」「変更点は最小」としていましたが、9月以降の体制整備の議論において、以下の論点を盛り込みました。

10月のタイミングで定例なども組み直し、FASTミーティングと成果共有会が「経営管理定例」に統合され、全体ふりかえりは廃止して各チームで実施する形になりました。

FASTの終了は、なし崩しではなく明示的に宣言しています。これまでの開発部門の責任者であり導入の意思決定者でもあった私から、ここまで挙げた課題を関係者と議論したうえで、組織再編後のプロセスのアップデートとしてFASTの終了を宣言しました。

続けるのではなくやめると判断したのは、前提を揃えられないまま続けるコストが、得られる利得を上回ったと考えたからです。

以降、プロダクト全体の優先順位と大きな判断は各機能領域のPdMが、チーム内のタスクの優先順位とアサインはリードメンバーが担う形になりました。

今振り返ると、「集合知で決める」ことがそもそも機能していなかったことはフェーズというよりかはケイパビリティの問題であり、結果的に決められる体制にしたことで解決したという形です。

リビルド期 - 組織が最も揺れた半年

移行直後の2025年10月のアジャイルコーチ主導のアンケート調査で、「自律性をもって行動できている」と「納得感を持って開発に取り組めている」が、いずれも全期間の最低値を記録しました。セルフアサインメントを手放した影響が、そのまま可視化されました。

• チーム間でも数値にブレがあった。回復していたチームと、低いままのチームがあった

• 当時最も課題視されていた「仕事のしやすさ」「楽しさ」のスコアはずっと低いままだった

そして、数字よりも正確に組織の状態を表していた指標がありました。アンケートの自由記述の『書かれ方』です。

10月以降は匿名・非公開希望が増えており、結果的に組織を自分たちのものとして捉える空気感は小さくなったと捉えています。

プロセスを変えるというのは、単にプラクティスを入れ替えることではなく、各個人が組織に対して持つオーナーシップにも大きな影響があります。

まず組織として事業課題にフォーカスする必要があったため、そのモードの切り替えは必要だったと考えていますが、その後どうやって自分たちの中で効力感を作っていくのかは継続的に考えなければいけないテーマです。

今どうしているか（2026年8月時点）

結論から言うと、スクラム回帰でもFAST継続でもない、第三の形になっています。

• 残ったもの

  • チーム単位のスプリント運用とDaily Scrum（スクラムのプラクティス）／FAST期の改善専用枠の後継／経営管理全体を1つの部として見る単位

• 消えたもの

  • FASTミーティング／マーケットプレイス／セルフアサインメント／全体ふりかえり／バリューサイクル

• 加わったもの

  • レポートラインに沿った情報流通経路の設計

これは「回帰」なのか

形だけを見れば、いまは機能領域ごとのチーム開発に戻っています。FASTで解こうとしたのは、まさに「機能領域に閉じたフィーチャー開発」だったので、元の状態に戻ってしまったと思われるかもしれません。
ただ、当時と違う点もあります。

• 各機能領域にPdMを置き、プロダクト開発責任者へのレポートラインを持たせている。「決める人／説明する人」の空白は、ここで構造的に埋まっています

• 各機能領域にリードエンジニアを置き、デリバリーの実行責任と品質に対する責任を持たせている

つまり、機能領域チームに「戻った」のではなく、機能領域チームに、当時なかった責任の所在を足したと読むのが正確だと思っています。

なお、「流動性」という言葉は誤解を招きやすいので分解して補足すると、以下のようになります。

経営管理全体として何をしなければいけないかという目線からの戦術実行は今も続いていて、そのために異動が必要であればフットワーク軽く動く。このフットワークの軽さは、FAST期に身についたものかもしれません。

一方で、現場からは懸念も出ていました。

責任の所在が明示されましたが、再びサイロ化が進みやすい構造になったという捉え方もできます。この視点を忘れてしまうと各チームのサイロが強化され、以前の状態に回帰してしまいます。

振り返って

品質指標の話

導入検討時の指標のうち、品質関連の指標については、FASTをやめた後も半年間は大きく変化しませんでした。

障害件数は、導入前後は悪化しましたが、それ以降は一定改善が進み、FAST期も、やめた直後も、大きく変化はせず推移していました。インシデントコマンダーなど事後対応も含めて大きく改善が進んだのは2026年4月以降で、FASTの終了から半年が経っています。効いたのは、品質課題の横断的な分析、テスト実装の拡充、リリース判定の強化といった、フレームワークとは無関係な具体策でした。

前提が揃わなかった、ということ

ログラスでFASTを実践するためには、成り立つための前提条件がいくつもありました。手引きに明記したもの、FAST Guideが暗黙に置いていたもの、そして導入時の我々が意識していなかったもの。並べてみると、その多くが揃わなかったことが分かります。

ただし「環境が悪かった」で済む話ではない

成功条件が揃わなかったことは、「環境が悪かった」で済む話ではなく、現場では、はっきりと痛みを伴う具体的な課題として表出しました。

FASTに課題を感じていた人がいたことは事実です。ここを「前提が揃わなかっただけ」と言い換えてしまうと、当時その痛みを引き受けた人の実感を否定することになります。

我々のFASTの運用には明確に課題がありました。FASTを選んだ時点で、我々はこれらの前提を揃える責任も一緒に引き受けており、手引き自体が「移行コストは高い」と認識して選んでいます。見積もりきれていなかったのは移行のコストではなく、前提を揃え続けるコストだったと振り返っています。

一方で、取り組みとして単に「失敗だった」と結論付けてしまうことももったいない解釈だと思っています。同じ1年で、確かに得たものがありました。プロダクト全体を考える視座。ディスカバリーツリーによる内部の透明性。職種を越えた議論。対話とアンチサイロという価値観。これらは数値には出ませんが、組織の学びとしては確実に刻まれていると思っています。

今後

取り組んだ期間も関わった人数も多い取り組みでしたので、構造的にも複雑で難しい振り返りでしたが、この内容は社内でも発表し、経営管理プロダクト外の人も含めて解釈や学びを深めることができました。

ログラスのバリューにはBut We Goという厳しい現実を直視しそれを乗り越えられると信じて前に進んでいくというバリューがありますが、こうした取り組みの振り返りとうやむやにせず組織の強さに還元していく発信としてポジティブに受け取っていただけたと思っています。

今後AI時代のプロダクト組織のあり方など、まだまだ模索しがいのある状況が続いているので、引き続き強いプロダクト組織を作っていけるよう試行錯誤していきたいと考えています。

このようなディスカッションが盛り上がる組織ですので、関心のある方はぜひお声がけください！

最後に

FASTをやめたのは、フレームワークの良し悪しを判断した結果ではありません。1年という期間を経て改善を積み重ねることができた部分もありましたが、当時の私たちは前提を揃えきれず、うまく機能させられなかった、という結論です。

また、1年前の組織再編からは多くの人の様々な思いが入り混じる中で、試行錯誤しながら1年走ってきました。この1年で当時事業に向き合うために必要だった観点は現在は整えることができました。フレームワークのせいにせず、プロダクト開発に必要な要素を愚直に揃えることに向き合ってきた1年だったなと思っています。
一緒に取り組んできたメンバーには感謝しかありません。

冒頭にも記載しましたが、ログラスの経営管理という一つの組織で、現在まで何が起き、我々がどう判断したかの記録としてまとめました。N=1の事例として、自分の組織に当てはまるところがあれば参考にしていただければ幸いです。