はじめに： 開発プロセスの現状
PeopleXの開発プロセスについては先日も記事になっていますが、ここではよりエンジニア目線で、課題感や行った取り組み、FASTの学びについて書いていこうと思います。
PeopleX AI面接は2025年4月にローンチしてから継続的に品質の向上や機能開発を行っています。チームの規模もリリース当初に比べて上がってきており、現在はPdM、エンジニア、デザイナー、QA合わせて10名を超える規模に成長してきています。
現在の開発プロセスは、月一回の機能リリースというサイクルと、一週間の開発サイクルの2つのサイクルで回っています。スクラム経験者も多く、私自身もスクラムマスターの経験もあるのですがそのエッセンスは取り入れつつも開発プロセスはスクラムではありません。
ある程度規模の大きな開発を要する機能はエピックとして、プランニングや担当決めや、設計のフローなどが定められており、ターゲットとなるリリース日に合わせて開発を進めていきます。週次のサイクルとしては週次ミーティングがあるくらいでスプリントレビューなどがあるわけではないため、作業の進め方は（ある程度の指針やコンセンサスはあるものの）個々人に任されているというスタイルでやっています。
チームが大きくなるにつれ生まれた課題感
スクラムガイドでもチームの人数は敏捷性を維持するために通常は10名以下と小さくするよう書かれており、実感としても10人は多いなと感じていました。色々変数はあるので一概には言えないですが、個人的には6名を超えてくるくらいで分割したい気持ちになってきますね。
チーム人数が多くなってくるとコミュニケーションの経路数が
引用: 生成AI時代のチーム設計 ― 役割と協働の再構築 | Ryuzee.com
チームではエンジニアメンバーで振り返りも行っていますが、担当している機能が各々異なり、それぞれが抱える課題感も異なるため、具体的な機能開発での課題感を発信することに躊躇が生まれ、開発チーム全体で取り組める課題の話に終始してしまう傾向があるように感じていました。（開発チーム全体で取り組める課題の話をすることが悪いというわけではありませんが。）
暗黙的な「小チーム」の組成とFASTとの類似性
チーム体制については「チーム分割できないかなあ」とうっすら思っていたところだったのですが、エピックごとに数名が担当になるという現在の開発スタイルは、一時的にそのエピックの実現のための小チームが組成されているとみなすこともできるのではないだろうか、とふと思い至りました。そう気付いてからは「チーム分割すべし」という思いを手放せるようになりました。
そのような一時的な小チームがあるとみなすことで、例えば振り返りならその一時的な小チームで振り返りすることで、具体的に取り組んだ機能の課題について自然に話すことができ、各人の参加者意識が高まり、濃い振り返りができるのではないでしょうか。チームでもこのような話をして、今後はエピックの担当者ごとに振り返りを行ってみよう、と先日決まりました。
そして、この「エピックごとの担当者で組成された一時的な小チーム」という構図はFASTと似ているのではないかと思いました。
FAST (Fluid Adaptive Scaling Technology) とは、開発プロセスのフレームワークで、私はログラスで導入されたという発信で知りました。FASTの詳細な説明はリンク先に譲ります。
FASTでは、固定されたチームに仕事を割り振るのではなく、活動アイテム(work item)に対して人が動的に割りつくというアプローチが取られます。このFASTのアプローチと、AI面接チームでのエピックごとに担当を決めるやり方に類似性を感じ、FASTから活かせる学びがあるのではないかと興味が出てきました。
FASTの特性とスクラムとの比較
実はこれまでに社内でもスクラムを導入するかどうかはカジュアルな雑談の場などでは度々話題に上がることはありました。それでもスクラム導入に舵を切ることがなかったことの要因としては、「スクラムでやることは手段であり目的ではない。価値を生み成果を出すことが目的なので、それにスクラムが最善ならやるけど、スクラムでやることに固執するのは違うよね」という話がありました。ちょうどタイムリーな記事を見かけたのでご紹介。
他にも、これまでのスクラムの経験からスクラム導入に慎重なスタンスの人が結構いました。理由はセレモニーを実施することのコストであったり、生産性への疑問だったり、スクラムマスターに不満足であったり…。個人的には少し悔しさを感じましたし、世の中うまく回っていないスクラムは多いんだなと実感させられました。
FASTも従来のアジャイル手法に対するアンチテーゼとして生まれたということで、FAST Webサイトの "Do we really need another agile method? What problems does FAST solve?" という質問の回答を翻訳して引用しましょう。
FASTは、ダークアジャイル問題、アジャイルの大規模展開、そして単なるデリバリーではなくプロダクト主導型の取り組みに対応する手法として開発されました。
ダークアジャイル問題
FASTは、形式的な自己組織化ではなく、それを不可避のものとすることで（単なる口先だけの対応ではなく）、なぜ多くのアジャイル導入が形骸化したりゾンビアジャイル化したりするのかという根本的な問題を解決しようとしています。
従来のアジャイル手法で開発に携わるソフトウェア開発者と話をすると、会議に時間を取られすぎるという共通の不満を耳にします。FASTはこの問題を解決し、開発者が本当に活躍でき、楽しみながら働ける環境を作ることを目的としています。
アジャイルの大規模展開
複数チーム間で作業を分割し、それらを同期させ続けるという課題が、アジャイルの大規模展開における核心的な課題です。FASTはこの課題を解決するため、「チームの中のチーム」というアプローチを採用しました。これは業界でもユニークな手法で、ネットワーク型組織モデルと流動的なチーム編成を組み合わせることで、純粋で複雑かつ適応性の高いシステムを実現します。
ネットワーク型で流動的な集合体は、静的なチーム編成やサイロ化によって生じる以下の問題を解決します：
- 限られた知識リソースの共有が容易になる
- 知識やスキルの相互共有が促進される
- 労働力や人材を最も必要とされる場所に柔軟に配置できる
- 依存関係が解消される
プロダクト主導型の取り組み
マーティ・ケイガン、メリッサ・ペリー、ジョン・カッター、テレサ・トレスといった現代のプロダクトマネージャーの著書や資料を読めば、FAST以前のアジャイル手法が彼らのプロダクト開発業務（製品そのものに関する作業）には役立たず、単なるデリバリー業務にしか対応していなかったことが分かるでしょう。従来のアジャイル手法はプロダクトディスカバリーには適しておらず、彼らはこれらのアジャイル手法をデリバリー業務にのみ推奨していたのです。
確かにスクラムの各種セレモニーの意義は理解しつつも、全員参加の会議体は多く、その時間を作業に充てたいと思う人がいても人情として理解はできますし、スケーリングの問題についても単一スクラムチームなら回せていたとしても、複数スクラムチーム体制になると、ではLeSSにするかどうするかとか運用は難しくなりますよね。
ディスカバリーとデリバリーについても、このテーマだけで長い記事になりそうなのであまり立ち入りませんが、従来の手法はデリバリーに偏りすぎているという興味深いトピックですね。
スプリントゴールに相当するものがない？
FASTの開発サイクルはバリューサイクルと言います。この長さに決まりはありませんが、短いサイクルで行われます。
スクラムは開発サイクルとしてはスプリントがあり、スプリントゴールを設定することが求められます。スプリントゴールは「スプリントの唯一の目的である」とあり、スクラムにおける重要な要素です。今年は「スプリントゴールで価値を駆動しよう」という書籍を読んだこともあり、FASTのバリューサイクルでスプリントゴールに相当するゴールの設定について言及がないことについて気になりました。
代わりにバリューサイクルの開始時にはPdMからビッグピクチャー（大きな単位のチームであるコレクティブが目指す目的とミッション）が改めて共有されます。ビッグピクチャーはプロダクトビジョンなどに相当するもので、恐らくそのバリューサイクルで成し遂げたいこととの関連も踏まえた話がされるのだと推測しますが、よりハイレベルな目的を繰り返し伝え、個々のメンバーはより自律的に、自己組織化された動きが求められるということなのだろうと思いました。
おわりに
今回は現在のチームとFASTとの類似性から、個人的な興味でFASTについて調べてみました。
今のチームとFASTの親和性も感じたので、より成果を安定的に出せる効果的なチーム体制に寄与しそうなことであれば考え方やプロセスを取り入れてみたいと感じました。
この記事は PeopleX Advent Calendar 2025 の15日目の記事でした（大遅刻）。
PeopleXのテックブログです。採用情報：hrmos.co/pages/peoplex/jobs 対話型AI面接「PeopleX AI面接」、エンプロイーサクセスPF「PeopleWork」、人事業務自動化AIエージェント「HR Operator」など、AIプロダクト多数開発しています。
Discussion