この記事では10月9日開催「Loglass TECH TALK vol.4〜ログラスが挑むFASTでのスケーリング戦略〜」で登壇したエンジニア南部の発表内容の書き起こしをご紹介します。
当日のアーカイブ配信はこちらからご覧いただけます！
エンジニア 南部 登壇「FAST導入ドキュメンタリー 〜導入の苦悩とログラスの強さ〜」
FASTの概要と導入背景
南部：私からは実際にFAST導入を推進し、FASTのコレクティブという組織の中にいた一員として、日々どのようなことを感じていたかをお話ししたいと思います。
まず、FASTの基本的な流れについて説明させていただきます。
FASTにはスクラムと似たようなイテレーションがあり、これをバリューサイクルと呼んでいます。ログラスでは大体2日間で1サイクルを回しています。
各バリューサイクルの終わりにFAST MTGがあり、これがFASTフレームワークの唯一のMTGです。
FAST MTGは3部構成になっており、第1部では前回のサイクルの振り返り、第2部ではプロダクトのゴール確認、第3部では次のサイクルのアイテム出しとアサインを行っています。
FAST導入のプロセスと初期の課題
ログラスでは、今年の4月頃にスケーリングフレームワークの検討を開始し、ログラスにはFASTが合っているかも知れないという結論を出していました。
結果的に、最初は各機能領域のチームに先行導入し、課題やメリットを確認した上で、全チーム統合してFASTを実施するという流れで導入を進めました。
私のチームが最初にFASTを導入することになったのですが、当時のチームの状況は非常に複雑で、具体的にはチーム人数が11人と多く、しかも直近3ヶ月以内の入社のメンバーがほとんどという状態でした。
また、3つの異なるコンテキストの開発エピックを並行して進めなければならず、日々の運用タスクで1日潰れてしまうこともあり、開発時間の確保が難しい点に課題感がありました。
スクラムイベントだけで午前中がほとんど埋まってしまい、さらにEMとの1on1やオンボーディングなども加わって、時間的にも状況的にも、生産性があがらない状態が続いていました。
FAST導入の決断と準備
そういった状況を改善するため、当時の私はチームを2つに分けてプランニングやリファインメントを2倍速にできないかとか、PdMと相談して優先度をつけて1つずつ片付けていけないか打診するなど、いろいろな方法を試みましたが、どれもあまり上手くいきませんでした。
そんな中で、スケーリングフレームワークとしてログラスに合いそうという話が出ていたFASTについて知り、これが解決策になるのではないかと考えました。
チームメンバーには課題感の共有をしたうえで、エピックごとにチームを分けたいことや、分けたチームで独自にプランニングやリファインメントをしたいという考えを伝えたところ、課題感は共感されつつも「本当に課題を解決できるのか」という厳しい意見も正直ありました。
その反応を受けて私自身がFASTを導入したいがためにHowを先に考えすぎていたことに気づき、フレームワークよりもチームの生産性向上という本質的な課題に寄り添うことの重要性を再度意識するきっかけにもなりました。
FAST導入後の変化と成果
その後、実際に私のチームでFASTを導入した後には、ポジティブな変化が見られるようになりました。
開発時間が増加し、PRの作成数も増え、チームメンバーからは「自分が行うべきタスクが明確になった」「アウトプットが出しやすくなった」という声が聞こえるようになりました。
また、業務委託の方からは「担当タスクに対する責任感が強まった」「他チームとの連携やコミュニケーションが増えた」という感想も聞くことができました。
特に大きな変化として、以前は触れなかった機能領域に異なるチームのメンバーが入り、新しい経験をできるケースが増え、これによって個々のメンバーのケイパビリティも増えたと感じています。
FAST導入の全体展開
私のチームでのある程度の手応えがあったのを受けて、他のチームにも試験導入をすることになりました。
各チームでメリットと懸念両方の意見がでた中でも最終的には「とりあえずやってみよう」という声が多く上がり、チャレンジに対する前向きな姿勢にはログラスの強さを感じました。
全体導入のスケジュールとしては8月7日にFAST推進チームのメンバー追加募集があり、8月20日の全体導入が決定しました。
1ヶ月足らずの準備期間で、手引書の作成、CSとの連携方法の変更、コードオーナーシップの再考など、多くのことを一気に進めて全体導入が始まりました。
現在の課題と改善策
全体導入から約2ヶ月が経ち、今はいくつかの課題に直面しつつも改善のサイクルを回せています。
まずフロー効率の悪さという課題に対しては、タスクが待ち状態になりやすい傾向があるので、バリューサイクルで扱うアイテム数を制限したり、一人で完結するアイテムを減らす試みをしています。
次に機能開発に注力するあまり、技術的負債の解消が後回しになりがちな傾向も見えてきました。これに対しては、数サイクルにわたって強制的に技術的負債解消だけを行うサイクルを設けるなどの対策をはじめています。
また、全体のゴールが見えにくくなっているという課題もあります。
プロダクトが大規模化し、全体のゴールが把握しづらくなっているので、PdMと別途MTGを設けて、ゴールの明確化をしようとしています。
さらに開発スピードは向上した一方で、それに伴う品質低下のリスクも認識しており、これに対してはシフトレフトやシフトライトの取り組みを強化しています。
課題もいくつか見え始め、それに対しては1つ1つ改善をはじめている一方で、リソース配分に関する議論が活発になったことは大きな進歩だと感じています。
例えば、「リソースを追加すればこのタスクはすぐに終わる」「この進捗は危険だから人を追加しよう」といった柔軟なリソース調整の議論が行われるようになり、全員が同じ方向を向いて開発に取り組めている証拠だと思っています。
今後の課題と展望
今後の課題としては、次のようなものがあると感じています。
1つ目は優先度決定プロセスの改善で、PdMへの過度な依存を減らし、チームメンバー全員が全体感を持って判断できるようにする必要があると考えています。
2つ目に情報共有の強化で、タスクの背景理解を深め、自信を持ってアイテムを提案できる環境を作る必要があります。
3つ目にプロダクトビジョンと顧客ニーズのバランスで、長期的なビジョンと短期的な顧客要求のバランスをどう取るかが課題になっています。
これらの課題に対応するために、PdMとの対話の機会を増やして、全体のアイテム把握を継続的に行うことを予定しています。
また、新しい領域に移動する際のオンボーディングを強化し、同期の時間や頻度を増やすことも検討しています。
最後に、FASTの導入は確かに難しく大変です。
一方で「やってみよう」という前向きな姿勢でチャレンジできるログラスのカルチャーはすばらしいと思っていますし、このカルチャーがあるからこそ、さらに良くなっていけると私自身は強く感じています。
