FAST導入1年ログラス×ユーザベース対談

チームより先にタスクがある──導入1年で分かったFASTの本質【ログラス×ユーザベース】

クラウド経営管理システムを開発する株式会社ログラスでは、事業の成長に伴って、組織面でのさまざまな課題に直面しました。

スクラムチームがサイロ化し、プロダクトの全体像にずれが生じたり、チーム間のコミュニケーションコストが増大したり……。そうした課題を解決するため、同社は2024年8月、「FAST」という新たな開発プロセスの導入に踏み切りました。

FAST導入から1年──。開発現場はどう変わり、どんな学びが得られたのでしょうか。

今回はアジャイル開発に取り組む株式会社ユーザベースの中嶋淳さん・福田航輝さんが、ログラスの飯田意己さん・粟田恭介さんとディスカッション。FASTの背後にあるユニークな考え方やXP（eXtreme Programming）との共通点・相違点を深掘りします。

FASTとXPには「組織の流動性」という共通点がある
FASTって何？特徴を簡単におさらい
- FAST（Fluid Adaptive Scaling Technology）の主な特徴
スクラムっぽさを残しながら移行し混乱を避けた
「自律性」と「流動的なチーミング」を現場はどう捉えたのか
FASTガイドには書かれていない「価値、原則、柱」の考え方
FASTの本質は「やるべきことをやる」から考えられること
型に縛られることなく、これからも進化していく
合わせて読みたい注目記事

FASTとXPには「組織の流動性」という共通点がある

── まずはじめに、皆さんの自己紹介をお願いします。

飯田　私は2024年11月からログラスのVPoEを務め、複数のプロダクトを横断的に見る立場でしたが、この8月に組織改編でHead of Engineeringとなりました。プロダクトである「Loglass 経営管理」について、現場とより近い距離でマネジメントを行うポジションとなり、FASTミーティングのファシリテーションなどを行っています。

粟田　僕は現場のエンジニアで、当初はどちらかというと、“FAST反対派”でした。FASTを導入してから勉強し始めたのですが、今では没頭しています。アジャイルコーチと相談しながら、「FASTをどううまく進めていくか」を試しては成功や失敗を繰り返し、改善しながら現在に至っています。

中嶋　ユーザベースで「Speeda」というプロダクト開発をしています。今回お話を伺いたいと思ったのは、私たちも7〜8年にわたり、100名規模の開発組織で「チームを定期的に変える」という流動的な開発を実践しているからです。ログラスさんのFASTに強い共通点を感じ、その裏側にある「価値、原則、柱」といった思想の部分をぜひ伺いたいと思っています。

福田　私は、ユーザベースにジョインする前はアジャイル開発の経験自体がなく、正直アジャイルもXPもよく分からない状態からスタートしました。しかし、こうしたアプローチを突き詰めていくと、ユーザーに素早く価値を届け続けるためにあるのだなということが理解でき、どんどん開発自体が楽しくなっています。

だからこそ、その背景にある思想の部分にとても興味があります。中嶋が話したチームのあり方の類似点もそうですし、私たちの会社が掲げる「バリュー」と、FASTの「価値、原則、柱」。この二つの思想を比べるとどうなのか。そのあたりを、ぜひいろいろと伺えればと思います。

FASTって何？特徴を簡単におさらい

本題に入る前に、この記事のテーマである「FAST」について、その特徴を簡単に整理しておきます。

FAST（Fluid Adaptive Scaling Technology）の主な特徴

流動的なチーム編成
- 開発組織内に固定チームは存在せず、やるべきこと（活動アイテム）に応じて、メンバーが自律的に集まり短期間のチームを作る。このチーム組成は「バリューサイクル」と呼ばれる短い期間で繰り返される
重要な用語
- コレクティブ：開発に関わるメンバー全体の集団のこと
- ビッグピクチャー：コレクティブが目指す共通の「目的とミッション」のこと
- FASTミーティング：唯一の公式イベント
  - 参加者が自ら議題とプロセスを決める、大規模な会議・ワークショップの手法「OST（オープンスペーステクノロジー）」をベースにしており、参加者の自発性を重視する
  - 3部構成で、次のサイクルで誰が何に取り組むかを「マーケットプレイスボード」で可視化する
基本的なサイクル
- 最初のFASTミーティングで情報が共有され、メンバーが自律的に取り組む活動アイテムを提案（ピッチ）して選び、チームが組成される。数日間で開発し、次のミーティングでまた情報が共有され、メンバーはまた新たなチームに参加する
▶️ FAST ※公式Webサイト / ▶️ FAST - FAST Guide ※日本語訳も公開されている

スクラムっぽさを残しながら移行し混乱を避けた

── ログラスの取り組みについては1年前に「なぜFASTにチャレンジするのか」という切り口で紹介しました。それから1年たって、FASTの成果をどのように評価していますか。

飯田　移行後のある時点からコード増加のスピードが鈍化しているような状態があれば、「何かが起きているな」と分かります。そのため、コードの増加量やブレーク数（開発フロー上で発生する中断イベントの発生回数）といった指標を継続的に見ていますが、そこはあまり変わっていません。ですから、スループット自体は出ていそうだと見ています。

▲ 自律的なスケーリング手法FASTにおけるVPoEとしてのアカウンタビリティ

中嶋　スクラムに慣れていた開発現場に、FASTを取り入れてガラッと変わったわけですよね？新しいプロセスを導入すると一般的には指標が落ちそうですが、あまり変わっていないのはすごいことなのではないかと思います。なぜなんでしょう？

粟田　「FAST」はその名前から、ガラッと変わるイメージを持たれるのですが、実は穏やかに導入することもできるんです。

私たちの場合は、アジャイルコーチの方が丁寧に導入を進めて、各チームに「Single Team FAST」（組織全体ではなく、単一の固定チームだけで実践するFAST）を試験的に導入し、その後に複数チームを合併してFASTに移行したのが、大きな混乱が起きなかった要因の一つだと思います。これはFASTのカンファレンスでも評価された、比較的新しい、独自の取り組みだったようです。

飯田　一方で、ビジネスサイドからは「リリースの頻度がちょっと下がってない？」といった声が出てきており、開発サイドの体感値としても同様に感じていました。

ただ、開発アイテムが一つ一つ大規模化し、企画してから実際にリリースするまでのリードタイムが長くなってしまったり、古いコードを作り直す機会が増えたりすると、ユーザーに届く価値が相対的に薄れてしまうことがありますよね。そうした状況が、リリース頻度の低下として現れているのかなと思います。

また、開発チーム全体として、フレームワークや体制の問題以前に責任の所在や役割分担をうまく共有できていないというコミュニケーション上の課題があって、それもリリース期間が長くなる要因の一つかもしれません。

「自律性」と「流動的なチーミング」を現場はどう捉えたのか

ログラス×ユーザベース

── コミュニケーションの難しさとは、具体的にはどのようなものでしたか？

粟田　私たちの現場と経営層・マネージャー間の意思疎通というのは、あまり課題としては感じていません。どちらかというと課題は「FASTで何を目指すのか」というところです。

── コミュニケーションは機能していても、目指すべきゴールの解像度が人によって違うということでしょうか？

粟田　はい、まさにそういうことです。プロジェクトが複雑になるにつれ、各自が自律的に動いていくのは良いとして、「その動きは、本当にチーム全体のゴールに向かっているだろうか」という不安が生じます。個性を尊重し、みんなが自分なりに解釈して動きながらも、個別最適に陥らないようにできるのか。この点で、全員の意思を一つにまとめるのが、以前より難しくなったと感じています。

── 「自律性」は、FASTにおけるキーワードの一つですよね。

福田　私たちユーザベースはもともとXPをやっており、新たにジョインしてくる人たちも各人がオーナーシップを持って取り組むことを前提にして入ってくるため、FASTの自律性との親和性も高いのではと思っています。

ログラスさんの場合、スクラムが急にFASTに変わって、「自律的に動こう」となると驚きもあったのではないかと思うのですが、実際のところ、どのように捉えられたのですか？

粟田　ログラスも何かをやるべきだと思えばやる人ばかりなので、「自律的に」という呼びかけをネガティブに捉えた人は少ないと思います。

飯田　ただマネジメントの立場からすると、全員が全員、自律性を発揮すれば十分なスキルセットを備えたパフォーマンスが出るかというと、そうではないと思っています。

前職でウォーターフォールしか経験してこなかった人が、スクラムをすっ飛ばしていきなりFASTと言われてもよく分からないでしょう。場合によっては「自律性ハラスメント」、つまり本人のスキルや経験を無視して「自律的に」と求めることが、意図せず過度なプレッシャーを与えてしまうことになりかねません。ですので、メンバーをどうフォローアップするかが課題かもしれません。

ただ、組織という大きな視点で見ると、自律性を支える仕組みも作っています。例えば経営陣との関係では、どういった開発プロセスで進めるかといった細部は経営イシューではなく、現場に任せるという切り分けができています。その上で、どのような手順やルールで経営陣に説明責任を果たすかについて合意ができれば、組織運営は円滑に進められる状況だと考えていました。

中嶋　そう言われると、ユーザベースの場合は、「個人のWill（やりたいこと）を大事に」と背中を押されるようなところがありますね。ただこれは、XPうんぬんというよりも、開発組織の構造や評価基準による部分が大きい。

評価基準の一つにもバリューが含まれています。そのため、「バリューに沿った行動ができたか」を定期的に評価して本人にフィードバックする。この繰り返しによって、バリューが少しずつ組織に浸透していくのだと思います。

福田　例えば、ユーザベースのバリューの一つに「異能は才能」というものがあり、いろいろな尖った人がいてOK、というカルチャーなんです。その尖り方も人それぞれ。逆に、あまり押しつけてしまうこともなく、チームそれぞれにうまくバランスを取りながらやっていると捉えています。

飯田　なるほど、評価制度にバリューを組み込むことで、文化レベルのアラインメントを図っているんですね。私たちの課題は、もう少し手前の「目標設定」の段階なんです。正直、今のFASTのやり方ではそこがまだうまくできていなくて。ユーザベースさんでは具体的な目標設定のプロセスはどうされているんですか？

中嶋　ログラスさんより、自由度は少し狭めている印象があります。私たちの場合、だいたい3カ月周期でチームを移動できます。そのタイミングでどんなことをやるチームがあるかは、CTOの林をはじめ、テクニカルPdMというロールを持つエンジニアがある程度決める。何人の枠が必要か決まったら、メンバーに希望を出してもらうという流れで進めています。

ですから、「やること」は決まっていても、いざチームが集まってやり始めようとしたものの、話し合ってみると「あれ、これって今やる必要はないよね」となり、その日のうちに解散することもあります。ついこの間もありました（笑）。

── その場で解散するというのは、すごい自律性ですね！ログラスのFASTでは、サイクルが短い中で、そういったことは起こり得るのでしょうか？

粟田　私たちの場合、以前は週に2回「FASTミーティング」をしていましたが、最近は1回になっています。

── 現在は週1回のサイクルが基本なのですね。そのサイクルの中で行われる「流動的なチーミング」についても伺います。この仕組みもFASTの特徴ですが、逆に「常に流動しなければ」という誤解もあったと聞いています。そこをどう解いていったのでしょうか。

粟田　誤解を解いたというよりも、「このタスクに対してこのチーム構成は最適なのか？」という、そもそもの話をちゃんとするようになったという方が、正確だと思います。

「本来やるべきものに力をかける」という原点に立ち返ったことで、流動性を高めることも選択肢の一つだし、流動性を高めないことも選択肢になる。つまり、模索の結果「流動的にチーミングできる」という定義に落ち着いた感じです。

中嶋　どのように人を流動させ、チームを変えていくかという基準があるわけではない？

粟田　ルールで明確に決めるのではなく、文化っぽい感じでなじませたいという思いもあるため、厳密にはありません。ただ、新たな機能を作る際にはリードできる人がいないと不安な部分もあるため、「コア開発者のような人はいる？」といった相談ができるようになってきています。

福田　「流動してもいいし、しなくてもいい」ということにすると、逆にチームが固定化してしまう可能性はないのですか？

粟田　「固定化すること＝悪」ではないんです。FASTの概念では、まず「コレクティブ」という大きな集団があり、その中にチームがあります。流動するのはチームで、コレクティブは流動しません。加えて、チームの存在価値は何かというと、チームの目標達成ではなく、コレクティブの目標達成です。

なので、個々のチームがうまくいくことよりも、組織全体としてどうなのかという視点が重要になります。この「全体的な視点」をいかにメンバーに共有するかがポイントになります。

FASTガイドには書かれていない「価値、原則、柱」の考え方

中嶋　今のお話は、FASTの「価値、原則、柱」に含まれている考え方なのでしょうか？ユーザベースの流動性の背景にある考え方と違っていてとても興味深いです。

というのは、私たちの場合は常に「自分の『Will』のあるところに行きなさい」と。その上で全体感のバランスを考えるという順序で進めています。それは、XPの原則の一つに、単にプロダクトを作るだけでなく開発者自身の満足も両立できるような考え方があるからだと思っています。

飯田　そう言われると、FASTだからというより、ビジネスへのコミットやプロダクトへの貢献志向の強いログラスだから、という部分が大きい気がしますね。

粟田　飯田さんの言うように、ログラスの文化が大きく影響しているのは確かだと思います。その上で、FASTというフレームワーク自体も、僕たちの貢献志向のような考え方を支える思想を持っていると感じています。

例えば、FASTの「柱」には「流動的なチーミング」とありますが、具体的な方法は示されていません。他にも「Y理論によるガバナンス」といった言葉は、「環境さえあれば人は自主的に最高の仕事をする」という、人間への信頼が前提になっています。ですから、開発者を尊重するという部分はFASTも変わらず、大事にしていると思います。

つまり、FASTが提供するのはルールではなく、「個々を信頼し、自律性に任せる」という土台なのだと思います。そして、その土台があるからこそ、「チームの成功よりコレクティブの成功を優先しよう」という僕たちの考え方が、初めて機能する。

中嶋　何度かFASTの「価値、原則、柱」について出てきていますが、これらの関係性はどのようなものでしょう。XPの場合は、価値があり、それに紐付くプラクティスがあり、その隔たりをエンジニアリングのコンテキストに寄せて埋める原則がある、という考え方ですが、FASTの場合はどのような構造でしょうか。

粟田　僕は、XPの場合とそれほど関係性は変わらないと思っています。自律性もそうですが、FASTというものを体現しようとしたときに「価値、原則、柱」が生まれてくるものではないかと思っています。

飯田　自分の場合は若干印象が異なります。XPの場合はプラクティスは日々意識し、明確にやるものですが、FASTにおける柱は、そこまで意識するものではないと思っています。FASTには、「FASTミーティングをやりましょう」といったミニマムなルールがあり、それに従うことで良くも悪くも実践することはできます。

しかし、「本当にうまく回せているのか」「どういった振る舞いをすればよりFASTっぽくなるのか」を探求していくと、結果的に「価値、原則、柱」になっていく、という感じです。

── 粟田さんは実践の結果として思想が「生まれる」。飯田さんはFASTを探求して思想に「行き着く」。プロセスは異なりますが、お二人ともFASTの思想を「日々の行動マニュアル」としてではなく、指針として捉えている。

福田　興味深いですね。私たちの場合、XPのバリューに立ち返る機会が非常に多くあります。評価基準に盛り込んで360度フィードバックの際に考えるのはもちろん、採用面接やチーム開発の中でも、「バリュー」という言葉が出てきて“普段使い”しています。ログラスさんではそんなふうに使うことはあるんですか？

粟田　会社のミッションやバリュー・テックバリューに関する言葉は頻繁に出てきますが、現場でFASTの「価値、原則、柱」はめったに出てきません。でも、それはそれでいいのかな、と。

FASTはフレームワークとしては薄く、それに沿って仕事をするだけではうまくいかないと実感しています。FASTをベースに、自分たちで何かを作らなければいけないと思っています。その際に、「価値、原則、柱」が出ることもありますが、僕はあまり直接的に言うことはありません。

飯田　FASTは「ルールやプロセスに関する話が少ない」と言われがちですが、それは覚えるべき「手順」が少ないだけなんです。

その分、「なぜそうするのか」という思想を深く理解する必要がある。だから、フレームワークとしては薄くても、開発をうまく成り立たせるために認知しておくべきものの総量はそんなに変わらないと感じます。そう考えると、具体的なプラクティスが決まっているスクラムやXPのほうが、ある意味シンプルだったかもしれません。

── そうなると、スクラムやXPの方法論に慣れているエンジニアの方が、FASTを始める際には抵抗や違和感は薄いのでしょうか？

飯田　そういう意味でも、FASTは玄人向けのような気がしてきました。「あ、これって、スクラムで言っていたあれのことね」といった解釈がつながれば、うまく立ち振る舞いやすくなると思います。

結局のところ、本質まで含めるとキャッチアップコストはそれなりにあるため、安易に勧められない理由の一つはそういうところにもあると思います。

飯田さん

── キャッチアップコストや学習コストを考えると移行という段階を踏まないほうがいいように思えますが。

粟田　それでも、個人的にはいきなりFASTをやらない方がいいんじゃないかと思っています。

── 一度スクラムなどを経験して、その課題を感じてからの方が、FASTの価値を理解しやすい？

粟田　僕らがFASTに取り組もうと考えたのは、スクラムチームが過度にサイロ化し、それぞれのチームの目標のみにフォーカスしてしまったという過去の経緯があってのことです。そうした背景や思想を理解せずにいきなりFASTに取り組んでも、目指したいところにはたどり着けないという感覚があります。

逆に、スクラムの経験者がFASTに入ってくると、「普通にレトロスペクティブやスクラムイベントをやればいいんじゃない？」と考えるかもしれません。プラクティスを取り入れることは問題ないのですが、FASTの思想との違いなどを理解しないと、再び過度なサイロ化が進む可能性があります。これを感覚的に理解できるのは、スクラムでの失敗を経験したからこそだと感じます。

根底のところに立ち返るには、いきなりFASTから入るよりも、まずスクラムチームでの失敗の歴史を学ばないと難しいかもしれないな、と。

▲ FAST導入1年間のふりかえり〜現実を直視し、さらなる進化を求めて〜

── なるほど。

飯田　私たちの中におけるFASTのやり方そのものも、随時アップデートしています。守破離の「破」のように、もともとのFASTの思想からちょっとずれたやり方も行っています。

例えば、今は責任者レベルがクォーターごと、半期ごとにどういったことをするかというロードマップについて責務を持ち、テックリードが「誰がそれを見ていくのか」を決めるようになっています。全員が高い目線を持って、自律的にそれを組み替えていくというFASTの思想からは外れたやり方になっているんです。

もはや「FAST」と呼ばなくてもいいのかもしれないとちょっと思っています。アジャイルな開発でもあり、XPと同じような要素があるんだろうなと思っています。

FASTの本質は「やるべきことをやる」から考えられること

── スクラムやXPと比較して、FASTならではの方法論というのはありますか？

粟田　スクラムの場合、まずチームがあり、そこにどういった人が必要かを考え、スプリントの期間内にどんなインクリメントを出すべきかを考えていきます。まずチームがあり、期間があり、やること（タスク）がある、という感じです。

FASTを本当に体現するには、それらがすべて逆になります。まず、プロダクトとして何をすべきかがあり、その目標に向けた適切なチェックポイントを設け、それをどのメンバーでやっていくかという順番です。

チームよりも先にタスクがあり、今やらなくてもいいタスクに対してはチームを考えなくてもいい。やるべきことをちゃんとやる、というところから考えられるのがFAST本来の良さなのかなというのが学びです。

もう一つ大事なのが、やるべきことに、コレクティブ全体で取り組むという点です。

エンジニアだけで「実装します」と言うのではなく、PdMやデザイナーも含めて「もっと良い方法はないか」を全員で考える。最近、こうした議論が自然にできるようになったのは、とても良い兆候だと感じています。

福田　 FASTのガイドを読んでも、正直、「流動的な組織を作るためのフレームワークなんだな」くらいしか分からなかったのですが、粟田さんのお話を伺って解像度がとても上がりました！実践して気付く部分も多かったのですか？

粟田　その通りです。

福田　例えば、FASTミーティングでは、やるべきことを、マーケットプレイスに出すのは誰がやっているんですか。

粟田　そこはOSTと同じで、「スチュワード」と呼ばれる人が出しています。「なぜ今これをやるべきだと思っているのか」というピッチをするのは、肩書きに関係なく誰がやってもいいですし、議論をリードする資格はあるんです。そこで他のメンバーからの協力を得て初めてチームが作られるので、「一緒にやっていこう！」というふうに、多様なメンバーが自発的にリーダーシップを発揮する状況にできるといいなと思います。

中嶋　私たちのプロダクトチームでは、誰でもピッチするところまではできていませんね。ユニークな取り組みだと思います。

粟田　もちろん僕らの場合も、スチュワードをやるのはある程度固定的なメンバーではあるんですよね。その中で、少しずつ交代しながらスチュワードをやってもらっています。

もちろん、自分からは出したくない人もいるでしょうし、「この人と一緒にやりたい」といって仕事をするのもありです。結局、ここで出すのはタスクであり、そこにできるチームのあり方までは決められていませんから。

── マーケットプレイスでの自律的な動きがよく分かりました。ただ、今のお話は組織が大きくなるほど、その自律性を保ちながら全体を把握するのが難しくなりそうですね。FASTに取り組む上で、スケールするのかどうかの課題についても伺えますか。

飯田　公式では150人ぐらいまではスケールできると書いてあります。ですが、ログラスは今、50人くらいになってきていて、その中で全員が状況を共有し、次のバリューサイクルでこのチームはどうなるのかといったコンテキストを合わせるのは非常に難しい状況になっています。

やはり、プロダクトの責任者が把握できる限界というのはあり、それ以上にはスケールしないと思うんですよね……。規模としては「これくらいが適切だよね」という現実解も見えてきそうだなと思っています。

中嶋　ユーザベースの場合は、全体を管理する人がそんなにいないため、数分調べて分からないことがあれば「隣のチームに聞きに行こう」と言っています。そこでも分からなければ、さらに隣のチームに……と数珠つなぎに聞いていけば、そのうち知っている人に行き当たる、という感じで。あえて全体を一人で把握しようとはしないのが、私たちのやり方かもしれません。

中嶋さん

福田　全体的な状況については、CTOが一人で全てを把握するという体制ではありません。各チームが自己組織化していることを信頼し、現場の判断に多くが委ねられている。それが、私たちの組織のあり方として良しとされています。

飯田　私たちも昔はそういう緩い運用をしていたのですが、プロダクトが本当に大きくなってしまい、「誰に聞いても答えを持っていない」という状況がありました。その課題を解決するために、FASTとは別のところで、責任者に情報を集約してアカウンタビリティを果たす枠組みを作っています。

中嶋　飯田さんのお話、非常によく分かります。ログラスさんでは「責任者に情報を集約する」という仕組みで解決されているのですね。

私たちのアプローチは先ほどお話したように、「知っている人をいかに早く探し出すか」という文化を重視している。もちろん、他部門から見れば、分かりにくさはあるのですが。

型に縛られることなく、これからも進化していく

── 1年をへて、粟田さんは“FAST反対派”からどう変わったのでしょうか？

粟田　今では、社内で一番FASTにのめり込んでいます（笑）。

最初は、すごくうまく回っていた自分のスクラムチームが壊されるのが嫌で、反対でした。でもそれは、僕が自分のチームという狭い視点でしか物事を見ていなかったからです。

全社でFASTを始めてみると、僕らのチームは良くても、組織全体では価値を出せていない課題がたくさんあることに気付きました。

そのとき、「自分のスクラムチームが良ければいい」という話ではない、と。コレクティブ全体でプロダクトをどう良くしていくかを考えなければいけないと痛感し、のめり込んでいきました。

粟田さん

── 例えばスクラムを採用している会社で、FASTとの両立、あるいはブレンドといった選択肢は有り得るのでしょうか。

粟田　FASTでは、チーム単位でどう動くかは自由なので、そこにスクラムのプラクティスを導入したければやればいいと思います。逆に、スクラムチームを壊さずに、Single Team FASTを入れてみる、というのもいいと思います。

ブレンドはできるし、スクラムに限らず、私たちが最近取り入れているFASTの守破離の「破」のようなプラクティスなどとのミックスはやっていく必要があると思っています。

僕も最初にスクラムチームでFASTを試したときは、スプリントレビューとレトロスペクティブだけ残して、プランニング・リファインメント・デイリースクラムをなくしました。代わりにFASTミーティングを実施し、そこで次のバリューサイクルでやることとサイクルの期間を決めて解散という流れで進めました。なくしたスクラムイベント相当の活動については、バリューサイクルの中で必要に応じて実施しました。慣れ親しんだスクラムイベントの良さも残しながら、少しずつFASTの流れを体験できたと思います。

中嶋　ユーザベースにもチーム間の流動性があり、さらに一つのチームの中でも、やるべきタスクやペアプログラミングの相手を入れ替えるという具合に、チーム内でも流動性を高める仕組みを入れています。

── どちらも「型」に固執せず、目的のために工夫されて進化している、と。ユーザベースのチーム内での流動性は、どういった目的で行われているのでしょうか。

福田　私たちの場合は、流動性を高めて入れ替えることで、みんなの目を入れてより品質を高め、知識共有を深めるという意味合いが強いですね。その点で、価値を出すために一番最適なチームを組むというFASTの前提とは目的が少し違うなと感じました。

福田さん

── 今回のディスカッションを通じて、自社の開発に生かせそうな部分はありましたか。

福田　あらためて私たちのXPの取り組みとログラスさんのFASTは近いな、と再認識しました。

ある程度、一定のメンバーが方向性を決める部分はありつつも、僕らもチームの中で、「今何をやるべきか」をしっかり議論しますし、必要に応じて他のチームから有識者を「レンタル」し、流動性を高めたりしています。本質的に必要な部分に取り組んでいるという意味で非常に近い。

一方で、方向性を決めるメンバーがある程度固定化しているというのは、組織としては引き続き課題だと思っています。現実として、自分のチーム内のことは分かっていても、それ以外のところは分からないという濃淡も出てきてしまっています。

今回のディスカッションでXPとFASTは両立できると分かったので、そこを埋めるための仕組みを考えていきたいなと思いました。

中嶋　私はあらためて、FASTはスクラムなど他のアジャイルの方法論を前提に、それをスケールさせるためのフレームワークなんだなという印象が強まりました。

チームをシャッフルしたり人が流動的に行き来したりするという部分は似ていても、ユーザベースの取り組みはXPの延長線上にあり、ログラスさんは外部から意図的にFASTを導入したという出発点の違いを感じることができたのも面白かったです。

FASTというフレームワークそのものを導入するというよりも、その中にある大事なエッセンスをうまく使うことで、自分たちらしく進められそうだなと感じました。

── 最後に、ログラスのFASTの展望について聞かせてください。

粟田　僕は今のログラスにおいては、FASTが一番最適なフレームワークだと思っています。FASTを通して得た、個別最適と全体最適のバランスをどう取っていくか、といった考え方は、この先FASTをやめてスクラムに戻ったとしても確実に生かし、他のスクラムチームのことを考えながら進めていけると思っています。

これから加わってくる新しい人にも、FASTで得たことを伝えながら、方法論よりもプロダクトそのものをどうするか、という話を増やしていきたいと思っています。

飯田　私もXPとFASTにいろいろな共通点があったなと思います。ベースにあるのはアジャイルな価値観で、そこからそれぞれ別の進化形を目指している途上にある。

まだまだやるべきことはありますが、仲間を増やしながら、エンジニアサイドだけでなく、PdMやデザイナー、QA、さらにビジネスサイドまで含めて全体にこの価値観が染み渡り、機能する状態を作っていけたらいいなと思っています。