■ 1. 取り組みの経緯と発信の背景
- FASTの終了:
- ログラスの経営管理プロダクト組織は2024年8月からFASTというアジャイルフレームワークで開発していた
- 国内初の事例として積極的に発信してきたが、2025年10月ごろに取り組みを終了した
- 終了を公式に発信するのはこの記事が初になる
- 発信が1年遅れた理由:
- 2025年秋から翌春にかけて開発組織が揺れており、対外発信より内部の安定化に全リソースを集中させた
- 取り組みをうまくいかせられなかった事実を内省し、自分たちの問題として言語化するのに1年かかった
- 記事の位置づけ:
- フレームワークの良し悪しを説くものではない
- 経営管理という一つのプロダクト組織で何が起きて、どう判断したかの記録である
- 組織構造の転換:
- 2025年8月に職種別の本部からプロダクト別の本部体制へ移行したことが全体の流れの中で大きな点となる
■ 2. 導入検討期: なぜFASTを選んだか
- 当時の課題:
- 機能領域ごとに分かれた3つのスクラムチーム体制で開発しており、BS機能のような領域横断の大きな開発で課題が顕在化した
- 機能領域に閉じたフィーチャー開発の目線ではなく、プロダクト全体の価値になっているかを検証する必要があった
- 機能領域ごとにチームのカルチャーが形成され、領域を跨いだ開発に都度調整コストがかかっていた
- ドメイン知識が領域ごとに分断され、全体を把握・判断できるメンバーが少なかった
- 3案の比較:
- 2024年4月から約2ヶ月、アジャイルコーチの今井さんに入ってもらい、EMから現場エンジニアまで14名で勉強会を実施した
- Scrum@Scaleは移行コストが最も小さいが、領域横断の課題が解けるのかに疑問が残った
- LeSSは移行が容易だが、単一POの前提が当時の体制では現実的ではなかった
- FASTは移行コストが最も高いが、適応的なチーミングとプロダクト全体思考が解きたい課題に合致していた
- 選定理由の記録:
- 社内の手引きには、移行コストは高いが理想状態を実現できる可能性が他のスケーリング手法より高いと判断したと残っている
- 日本で事例がなく、DDD×スクラムで作ってきたブランディングをUpdateできる可能性も理由として記した
- ブランディング起点でHowを選択すること自体は本質的ではない
- 創業期からDDDを価値を享受できるレベルで実践してきた自負があり、純粋にすごいと思えるものに挑戦するモメンタムがあった
- 検証基準の設定と限界:
- 2025年4月を期限に、プロダクトKPI達成に向けた課題認知と機動的な開発推進、市場不具合率、MTTR、CS側から見たコミュニケーションコストの4点を置いた
- 指標は目標水準に届かなかったが、要因にターゲット選定やオンボーディング、顧客側の事情も含まれ、開発プロセス固有の因果関係は説明できなかった
- 基準を置いたこと自体は良かったが、プロセスの効果を測るには遠すぎる指標だった
- 当初置いた検証基準以外のところで課題が表出化した
■ 3. 導入判断の見誤り
- 誰の視点で選んだのか:
- 導入前の2024年7月、自律性を重視するFASTをマネージャーがトップダウンで推進することは自律的なのかと悩んでいた
- 観点として妥当だったが、より重要だったのはトップダウンかどうかではなく誰の視点で選んでいるのかだった
- FASTはエンジニア視点でスケーリングしやすいという観点から選ばれており、PdM視点でのやりづらさに当時は向き合えていなかった
- 当時のPdMは、なぜFAST導入という大きな変化を行うのか意図が完全に理解できず戸惑いを感じていたと書いている
- 組織構造とのGap:
- チームは職種横断で組んでいたが、組織図とマネジメントラインはプロダクト本部と開発本部に分かれていた
- 職種横断を前提とするプロセスを、職能で分かれた組織図の上に載せていた
- このGapはFASTをやめる決断をするまで埋められずに残った
- 全体移行という選択:
- 当初計画はチーム内で試行し年内に組織全体へ展開するものだったが、2024年7月8日の推進チームの議論を経て早期の全体移行に変わった
- 論点は小さく始めるかどうかではなく、どの単位で小さく始めるかだった
- VPoEは、小さく始める単位は機能チームではなくビジネス単位がよく、事業目標を鑑みるとゴリッと進めて早く失敗して学ぶフェーズに来ていると述べた
- アジャイルコーチは、ある機能単位で切り出すとメンバーを剥がされた残りのチームがパフォーマンスを落とすと懸念した
- 結果として全体での試行をさっさと始めるという方向になった
- 解けていない課題の拡大:
- この時点でチームによってはうまく回っていたとは言えない課題が残っていた
- コーチはWhatに関する自律性をチームで確保できておらず、意思決定の責務がチーム内で曖昧だと記録している
- この課題はその後1年以上まったく同じ形で残り続け、終了を決める2025年9月の議論でも同じことを別の言葉で話した
- 1チームで解けていない課題を、解けないまま3チームに広げてしまった
- エンジニアに閉じないプロダクト組織全体のケイパビリティの課題を、プロセスで解こうとした見誤りだった
■ 4. FAST期に起きたこと
- フェーズ1: 提供価値を高める模索:
- 2024年8月から10月にかけての期間で、当時の評価は意外とスムーズ、もっと早くやればよかったというものだった
- チームの解散と再編成そのものは思ったよりも大きな混乱なく回っていた
- 一方で枠の上限を常に全部使い切ろうとする、運用タスク用の枠で新規開発をしてしまうといった兆候が出ていた
- 枠とは特定の目的やタスクのために一時的・流動的に編成される作業枠を指す社内用語である
- フェーズ2: 品質と効率の両立:
- 2024年11月から2025年1月にかけて、障害の発生が通常より多くなるなど品質面の課題が顕在化した
- 枠を使い切りリソースが分散し、1枠あたりの人数が減り、キーパーソンが全ての枠に入れず品質が下がるというサイクルが要因の一つだった
- 対策として通常開発の枠数を約半分に制限し、改善専用の枠を設けた
- この対策でも障害件数はゼロにできず、改善が着実に積み上がっている実感には至らなかった
- フェーズ3: 組織全体最適化:
- 2025年2月から7月にかけて、チームをある程度固定化して安定させる方向に動いた
- 一定の効果があった一方、コレクティブが個別チームの寄せ集めに見える状況、チーム間の繋がりの希薄化、FAST自体の形骸化という副作用が出た
- THE ENTERPRISE AND SCRUMに載っているコア開発者の制約が表出化した
- ディスカバリーツリーによって横断的な可視性が高まり、プロダクト全体の議論に各メンバーが関わりやすくなるメリットもあった
- 短寿命のチームとリソース分散が品質や育成に与えるデメリットも明確になった
■ 5. 構造的な課題の整理
- 非常時に単独で決める人を置けなかった:
- 集合知は合議ではなく、FASTは集合知を前提とするが合議は推奨していない
- 全体で合意しなくても決められる設計にしており、平常時はそれで回っていた
- 大きな意思決定や緊急時の判断には、単独で決めるプロダクトオーナー的な人が必要だった
- その役割をPdMに求めたが、新規事業や重いディスカバリーにリソースを寄せる必要があり、デリバリーまで関与する余裕がなく機能しなかった
- そのため開発チームがデリバリーの意思決定を担い、集合知で機動的に判断する形を取ろうとした
- 実態としては個々の知識や能力を集結させれば解ける問題ではなく、大きな意思決定ができる人か組織的ケイパビリティが必要だった
- 一人が持つのは難しいから集合知で解決しようというアプローチの前提が揃っていなかった
- 外から進捗が見えなくなった:
- 2024年8月にEMの役割へ他部署に対する説明責任を置く一方、タスクのアサインなどマイクロなマネジメントはしないと定義した
- 結果として細かい状況把握が難しくなり、EMに聞いても現場に入っていないためどうなっているのかわからない状態が発生した
- VP・PdM・EMの三層にまたがる課題であり、VPだった自分自身も現場への関与が薄くなり把握が難しくなっていた
- FASTは説明責任をコレクティブの各メンバーが果たす設計思想であり、個々の練度が求められる
- 部門間コミュニケーションの練度にばらつきがあり、そのばらつきにどう責任を果たすかのマネジメント的な設計も不十分だった
- 結果として部門外から見たときの透明性が低くなった
- 育成のコストを見積もれなかった:
- チームの寿命が短く編成を現場が決める状態では、誰が誰を見るのかが定まらない
- オンボーディングと育成の主体があいまいな状態が発生した
- チーム編成を流動的にすると育成ができなくなると言うのは断定しすぎであり、正確には育成の難易度とコストが上がる
- 経営管理というドメインの複雑さが要因として大きく、ドメイン理解が容易なプロダクトであればここまで苦労しなかった
- そのコストを十分に見積もれず、制御しきれなかった
- FAST公式はルールが極小で覚えることも制約も少ないことから学びやすさを長所に挙げている
- それはペアプロのような常時協働が当たり前にあるという暗黙の前提の上に成り立っている可能性がある
■ 6. どうやめたのか
- 組織再編:
- 2025年8月に、戦略を経営から現場まで一本化することとレポートラインの透明化を目的に、職種カットからプロダクトカットの組織体制へ移行した
- 新たにプロダクトごとにプロダクト開発責任者というロールを設置した
- 方針の転換:
- 8月時点ではFASTの仕組みは残す、変更点は最小という方針だった
- 9月以降の体制整備の議論で、現場から声を吸い上げる仕組みを整えた上で集合知で決めるを減らすという論点を盛り込んだ
- 組織規模的に全員で決めることが難しいフェーズになってきたことが理由である
- 具体的な変更:
- 10月に定例を組み直し、FASTミーティングと成果共有会を経営管理定例に統合した
- 全体ふりかえりは廃止し、各チームで実施する形にした
- 明示的な終了宣言:
- なし崩しではなく、開発部門の責任者であり導入の意思決定者でもあった自分から明示的に終了を宣言した
- ここまで挙げた課題を関係者と議論したうえで、組織再編後のプロセスのアップデートとして宣言した
- 続けるのではなくやめると判断したのは、前提を揃えられないまま続けるコストが得られる利得を上回ったからである
- 意思決定の再配置:
- プロダクト全体の優先順位と大きな判断は各機能領域のPdMが担う形になった
- チーム内のタスクの優先順位とアサインはリードメンバーが担う形になった
- 集合知で決めることが機能していなかったのはフェーズというよりケイパビリティの問題であり、決められる体制にしたことで解決した
■ 7. リビルド期: 組織が最も揺れた半年
- アンケート結果の悪化:
- 移行直後の2025年10月のアジャイルコーチ主導の調査で、自律性をもって行動できているとの納得感を持って開発に取り組めているが全期間の最低値を記録した
- セルフアサインメントを手放した影響がそのまま可視化された
- チーム間でも数値にブレがあり、回復したチームと低いままのチームがあった
- 最も課題視されていた仕事のしやすさと楽しさのスコアはずっと低いままだった
- 自由記述の書かれ方:
- 数字よりも正確に組織の状態を表していた指標は、アンケートの自由記述の書かれ方だった
- 10月以降は匿名・非公開希望が増え、組織を自分たちのものとして捉える空気感は小さくなった
- プロセス変更の本質:
- プロセスを変えることは単にプラクティスを入れ替えることではなく、各個人が組織に対して持つオーナーシップにも大きな影響がある
- 組織として事業課題にフォーカスする必要があったため、そのモードの切り替えは必要だった
- その後どうやって自分たちの中で効力感を作っていくのかは継続的に考えなければいけないテーマである
■ 8. 現在の体制
- 第三の形:
- 2026年8月時点で、スクラム回帰でもFAST継続でもない第三の形になっている
- 残ったものはチーム単位のスプリント運用とDaily Scrum、FAST期の改善専用枠の後継、経営管理全体を1つの部として見る単位である
- 消えたものはFASTミーティング、マーケットプレイス、セルフアサインメント、全体ふりかえり、バリューサイクルである
- 加わったものはレポートラインに沿った情報流通経路の設計である
- 回帰ではなく責任の所在の追加:
- 形だけを見れば機能領域ごとのチーム開発に戻っており、FASTで解こうとした課題に戻ったと思われるかもしれない
- 各機能領域にPdMを置きプロダクト開発責任者へのレポートラインを持たせ、決める人と説明する人の空白を構造的に埋めた
- 各機能領域にリードエンジニアを置き、デリバリーの実行責任と品質に対する責任を持たせた
- 機能領域チームに戻ったのではなく、当時なかった責任の所在を足したと読むのが正確である
- 流動性の再定義:
- 経営管理全体として何をしなければいけないかという目線からの戦術実行は今も続いている
- そのために異動が必要であればフットワーク軽く動き、この軽さはFAST期に身についたものかもしれない
- 現場からの懸念:
- 職能をまたいだ組織構成にできたのにプロダクトを中心に置けず、機能単位やプロジェクト単位のチームに中心が戻りつつあるという声が出ている
- 責任の所在は明示されたが、再びサイロ化が進みやすい構造になったという捉え方もできる
- この視点を忘れると各チームのサイロが強化され、以前の状態に回帰してしまう
■ 9. 振り返りと結論
- 品質指標の推移:
- 品質関連の指標はFASTをやめた後も半年間は大きく変化しなかった
- 障害件数は導入前後で悪化したがそれ以降は一定改善が進み、FAST期もやめた直後も大きく変化せず推移した
- インシデントコマンダーなど事後対応も含め大きく改善が進んだのは、FAST終了から半年後の2026年4月以降である
- 効いたのは品質課題の横断的な分析、テスト実装の拡充、リリース判定の強化といったフレームワークとは無関係な具体策である
- 前提が揃わなかった:
- FASTを実践するには、手引きに明記したもの、FAST Guideが暗黙に置いていたもの、導入時に意識していなかったものなど多くの前提条件があった
- 並べてみると、その多くが揃わなかった
- 環境が悪かったで済む話ではない:
- 成功条件が揃わなかったことは現場ではっきりと痛みを伴う具体的な課題として表出した
- FASTに課題を感じていた人がいたことは事実であり、前提が揃わなかっただけと言い換えれば当時痛みを引き受けた人の実感を否定することになる
- FASTの運用には明確に課題があり、FASTを選んだ時点で前提を揃える責任も一緒に引き受けていた
- 見積もりきれていなかったのは移行のコストではなく、前提を揃え続けるコストだった
- 失敗と結論付けない理由:
- 単に失敗だったと結論付けることはもったいない解釈である
- プロダクト全体を考える視座、ディスカバリーツリーによる内部の透明性、職種を越えた議論、対話とアンチサイロという価値観を得た
- これらは数値には出ないが、組織の学びとして確実に刻まれている
- 今後:
- 構造的にも複雑で難しい振り返りだったが、社内でも発表し経営管理プロダクト外の人も含めて解釈や学びを深めることができた
- ログラスのバリューであるBut We Goは、厳しい現実を直視しそれを乗り越えられると信じて前に進むという意味である
- 振り返りをうやむやにせず組織の強さに還元する発信としてポジティブに受け取ってもらえた
- AI時代のプロダクト組織のあり方など模索しがいのある状況が続いており、引き続き強いプロダクト組織を作るべく試行錯誤していく
- 結論:
- FASTをやめたのはフレームワークの良し悪しを判断した結果ではない
- 1年で改善を積み重ねられた部分もあったが、当時の自分たちは前提を揃えきれずうまく機能させられなかった
- 当時事業に向き合うために必要だった観点は現在は整えることができた
- フレームワークのせいにせず、プロダクト開発に必要な要素を愚直に揃えることに向き合ってきた1年だった
- N=1の事例として、自分の組織に当てはまるところがあれば参考にしてほしい