🕌

FAST×AIで考える、未来の組織像〜FASTはAI時代のスタンダードとなり得るか〜

に公開

1. はじめに

この記事では、AIの急激な進化が組織にどのような変化をもたらすのか、そしてFASTがAI時代のスタンダードとなり得るのかについて考えてみます。

ChatGPTの登場以降、AI技術は目覚ましい進歩を遂げています。特に2024年に入ってからは、コード生成AIプロダクトマネジメントAIなど、開発プロセスに直接関わるAIツールが次々と登場し、私たちの働き方を大きく変えようとしています。

この変化は、単にツールの置き換えではありません。AIが人間の認知負荷を大幅に軽減し、組織の構造そのものを変える可能性を秘めています。そして、この変化に対応できる組織設計の一つとして、FASTが1つの最適解となり得るのではないかと個人的には考えています。(異論は認める)

この記事では、AI時代における組織の変化を予測し、FASTがなぜその時代に適しているのかを勝手に語ってみようと思います。

2. FAST とは

FAST(Fluid Adaptive Scaling Technology または Fluid Scaling Technology)は、人々が仕事を中心に自己組織化する方法です。今回の記事ではFASTそのものの詳細な解説は割愛しますので、詳しく知りたい方は以下を参考にしてください。

https://www.fastagile.io/
https://drive.google.com/file/d/1jkKpvhWcF1N0-7B-9tCkRNXZnphHrHxP/view

FASTの特徴として、最小限の構造と流動的なチーミングを通じて適応性と創発を実現する点が挙げられます。この特徴が、AI時代の組織に求められる柔軟性とスピードと非常に相性が良いと考えられています。

3. 急激なAIの進化に伴い組織はどう変化するのか

まずは、組織がどう変化していくのかを考えてみます。

3.1. 組織はこれまで以上に小さくするトレンドが強くなる

AIの進化により、組織の最適規模 は、これまで以上に小さくなっていくのではないかと考えています。

従来、組織を拡大する際の課題は「人を増やした際のコミュニケーションコスト」でした。そのため、場合によっては「人を増やさない方が良い」という判断もありえましたが、現実的にはほとんどの組織がアウトプットを増やすために、そこにリソースを投下し、組織を拡大させてきたと思います。

しかし、AI時代では「人を増やすのではなく、AIを増やす」という選択肢が生まれます。

人を増やした場合

  • アウトプット量とコミュニケーションコストが増加
  • 意思決定の複雑性が増大
  • チーム間の調整に時間がかかる

AIを増やした場合

  • アウトプット量とAIのマネジメントコストが増加
  • しかし、AIのマネジメントコストは人間のコミュニケーションコストより低い
  • スケーラビリティが高い

これらを比較すると、ある程度の人数以上になれば、人を増やすよりもAIを増やす世界になることが予想されます。AIによってアウトプットは増加するため、結果として、人は増えなくてもアウトプットは増える、が実現できる世界がくると考えています。

ただし、プロダクト開発においては、アウトプットが多ければ良いということではないので、そこは常に意識しておきたいですね。

3.2. 知識や情報が局所化する

これから先はより一層、人同士の協業という感覚が薄れ、人はAIと協業するようになると考えています。その結果、知識や情報の局所化が進むことが予想されます。

チームは並列に動き協業の機会が減るため、組織全体での知識共有が減少します。また、AIに情報を押し付けることで、特定の人間とドキュメントに情報が集まるようになります。結果として、口頭でしか伝わらないような情報は抜け落ちる可能性があります。

増え続ける情報をAIに押し付けること自体は問題ではなく、ここで問題視しているのは「局所最適」と「全体最適」のバランスです。局所化した情報を元に局所最適だけを繰り返してしまうと、プロダクト全体で見た際に整合性を失ってしまったり、本来解決するべき課題を解決できないリスクが残ります。

ドキュメントの管理方法を工夫するなどで回避できる可能性もあると思いつつ、プロダクト全体への意識を失うリスクも潜んでいるため、この変化とは慎重に向き合っていく必要があると思います。

3.3. 職種の壁が薄れていき今まで以上に自律的な働き方を求められる

AIにより各職種のスペシャリティは少しずつ薄れていく可能性があると考えています。当然、AIに置き換えられないスペシャリティも必ず存在すると思いますし、仮に置き換えられたとしても、新たなスペシャリティを作り出す人が現れるような気がしています。

ここで言いたいのは「デザイナーがいないからUI/UX設計が進まない」「エンジニアがいないからプロトタイプの実装が進まない」のような状況は少しずつ減っていくのではということです。

2025年7月時点では、まだデリバリーのアウトプット量の増大に留まっており、ディスカバリーのアウトプット量にはそこまで寄与していない(気がする)と思いますが、今後さらにAIが進化することで、ディスカバリーのアウトプット量も大きく増加すると考えています。

つまり、並列で特定の職種に依存しない小さなチームでディスカバリーもデリバリーも高速に実行する という状況になるのではないかという仮説です。ディスカバリーとデリバリーは、これまで以上にシームレスに繋がり、従来から存在している ディスカバリーとデリバリー の境界は少しずつぼやけていくと考えています。

これらの状況を踏まえると、特定の誰かに依存しない意思決定モデルを構築していかなければ、AI時代の速度に追いつけないという危機感を感じています。いくらチームがアウトプット量を増やしたとして、良い意思決定を素早く実行できなければ、宝の持ち腐れになってしまいます。

3.4. 品質保証がボトルネックになる

これについては特にさまざまな場所で語られているので繰り返しですが、AIに説明責任を追わせられない以上、品質保証に人間が介在することは避けられません。

仮にAIだけがシステムを使って、システムに何かあった際にはAIが謝罪会見を行い、AIが記者として取材する、みたいな世界線にならなければ、そのシステムにおける説明責任は人間にあり続けるのだろうなと思っています。

AIの進化により品質保証のための手段はより効率化され、少ない人間で実行することは可能になると思いますが、「AIがテストしたからリリースしてOK」となることは当面ないだろうと推測しています。それこそ、「Claude Code ActionでIssueから自動で実装をしてもらって、コードレビューもざっとした感じ問題なさそうだけど、リリースできてないPR」とかありませんか?(僕はあります)

また、品質保証というのは何も「想定通りに動作すること」だけを保証するものではありません。人間にとって使いやすいシステムになっているかであったり、思っても見ない操作をされたときにどんな動きをするか?といった、人間にしか確認できない項目もたくさん存在しています。特に探索的テストやモンキーテストのようなテスターの勘や経験に依存するようなテストをどれだけAIが再現できるかというのも1つ大きなポイントになると考えています。

まとめると、人がシステムを使う以上、人が説明責任を負う必要がある。テスト実行自体はAIによりある程度は置き換えられるが、すべてではない。ということかなと思っています。

4. 急激なAIの進化に伴いシステムはどう変化するのか

次に、システムの変化についても考えてみましょう。

4.1. 組織は小さくなるがシステムもそれに合わせて小さくなるとは限らない

先ほど、組織は小さくなるトレンドが強くなると言いましたが、組織は小さくなっても、システムが小さくなるとは限らない という風に私は考えています。

理由として最も大きいのはそもそも小さくする必要性が薄れていくためです。もちろん、マイクロサービスアーキテクチャの文脈で述べられているように、システムを適切に分割することにはたくさんのメリットがあります。それはAI時代においても享受できるメリットなのではないかと思います。しかし、マイクロサービスアーキテクチャは運用のコストも大きく上がりますし、システムの適切な分割は非常に難易度が高いと思います。

システムを分割するということは、基本的にはシステムを担当するチームというものも必然的に生まれるのではないかと考えています。1つのチームが複数システムを見ることもあると思いますが、そのシステムにおける最終的な意思決定権や、コードを修正する権利もそのチームが持つと思います。そうすると、チーム間のコミュニケーションは増えます。

また、システムが大きくなりすぎたので適切に分割し認知不可を下げる、というパターンもあるかと思います。こういったケースにおいては、特に分割の必要性は薄れていくと思っています。これはもはや自明かもしれませんが、なぜなら認知負荷はAIに押し付けることが可能だからです。これからどんどん人間ではなくAIがコードを書くようになると予想すれば、人間ではなくAIがコードを理解できれいれば良くなります。

具体的に言うと、Unknown Unknowns に対して、AIを活用することで容易に立ち向かうことが可能になると考えています。これは、AIが膨大なコードベースから関連性を検索し、Known Unknowns に変えるためのサポートをしてくれるからです。ただし、これを実現するためにはAIに正しくデータを読み込ませるということが重要になってきます。システムを分割し完全に依存関係がなければ、そのシステムのデータだけを渡せば良くなります。しかし、移行途中などで完全に依存が切れていない場合は、結局どちらのデータも渡す必要が生じます。また、システムを完全に独立させるということは、全体に対して共通の修正をAIにやってもらう、といったことは逆にやりにくくなります。(このあたりはコードベースの工夫で避けられるかもしれませんが)

つまり、システムを小さくしても、享受できるメリットが減っているかもしれないということです。大きくするべき、小さくするべきという二項対立ではありませんが、リスクとメリットを天秤にかけて、今まで以上に慎重に選択が求められる時代になるのではと考えています。

4.2. 一般化されたそこそこ使えるシステムが生まれやすくなる

結論から言うと「AIの進化と活用が進み、人が人との対話や交流を忘れ、AIとの壁打ちで満足してしまった結果、イノベーションが起きにくくなる」という懸念を持っています。

というのも、AIが得意としているのは知識の整理と最適化であり未知の想像ではありません。インターネット上の膨大なデータや既存のコードベース、要望など、これまでの蓄積された知識を整理し、最適な形でアウトプットすることはとても高品質に実施できると思いますし、これはみなさんも体感している部分だと思います。ランダムな情報からパターンを導き出し、一般化し、という部分も問題なくこなす感覚はあります。

しかし、いわゆる突拍子もないようなアイデアはなかなかAIからは出てきません。既存の枠組みをぶっ壊して、「そもそもこれじゃね?」みたいな提案は見たことがありません。FASTの文脈では創発と呼ばれていますが、こういった分野はAIがまだ苦手としていると言えそうです。また、データに表現しきれない人間の感覚のような部分もAIにはまだ理解できていない要因だと思っています。お客様の話している雰囲気、空気感のようなものから本質的な課題を導き提案するようなことは、まだできないと考えています。

これが私の考える一般化されたそこそこ使えるシステムが生まれやすくなる理由です。

5. 急激なAIの進化に伴い我々は何を求められるのか

続いては、そういった状況において我々にどんなことが求められるのかを考えていきます。

5.1. 分割、統合のどちらにも耐えられる必要がある

先ほど、チームは小さくなると言いましたが、基本的には小さなチームを並行で動かすが、どこかで統合するタイミングが来る、というのが私の考えです。

これは、どの企業もAI活用を活用してアウトプットを増やすため、リードタイムの短さは重要な指標のままで、その競争に勝つ必要があるからです。そして、リードタイムを短くするためには、人が増えることによるコミュニケーションコストを払ってでもチームを統合してフォーカスする必要があります。また、品質保証の文脈においては、人間のリソースが必ず必要になります。ある一定のタイミングまでは小さなチームを並列に動かして探索を進めながら、「これだ!」という注力ポイントが決まった時点で、ある程度のチームを統合し、終わったらまた解散する、といった流動的なチーミングの考え方を取り入れることが必要になってきます。

そのため、チームを作り直すごとに多大な調整コストがかかってしまったり、新しく作ったチームでパフォーマンスを出すための準備期間が長いような状態は、今後の変化の速さには追いつけないということです。これは、今までのチームを主軸とした考え方からの大きなマインドチェンジが必要となります。

5.2. 大幅な外的環境の変化に耐えられる必要がある

突然ですが、みなさん「1年後、3年後、5年後にAIがどうなっているか予想ができますか?

私はできません。というのも、実は私、Cursorは2023年の1月頃に見つけて使っていた時期があります。多分、結構早い方なんじゃないかなって思っています。ただ、当時はまあ使いやすいけど、う〜ん、まあ...みたいな感触で、その後いったん使うのをやめました。そこから、さまざまなAIを使ったツールが台頭して、いまやCursorも時代遅れか?みたいなことを言われるような状態です。これを2023年の1月頃に予測できていれば、その当時からCursorを使いまくって、古参ぶってました。確実に。

このように、AI技術の進歩は予測不可能で、我々の考えうる速度を大きく上回る可能性があります。そして、それはAIが進化した現代においては、より早くなる可能性を秘めているということです。これも先ほどのチームの流動性と関連するのですが、つまるところ、のんびりAIの使い方を学んで覚えてみたいなことをやっている暇はないということです。そんなことをやっている暇にまた新たなツールが出てきたりと、環境が変化してしまいます。

常日頃の取り組みから、変化を恐れない、変化の速度に負けない、そういった組織の土壌を作っていくことが生き残っていくために必要だと私は考えています。

5.3. 属人化させないプロダクトマネジメントの重要性が高まる

唐突にプロダクトマネジメントの話が出てきて混乱したかもしれませんが、これは ディスカバリーもデリバリーも高速化し、アウトプットが増大世界では、よりどこに集中するのかが重要になる、ということです。

先ほど書いたように、人間が使うシステムを作る以上、人間によるプロダクトマネジメントは必要だと考えています。現時点でも、簡単なものであればAIの力を借りて、エンジニアではない人が作りたいものを簡単に作ることができるという世界になってきています。逆に言えば「なぜ作れるのに作らないの?」という疑問を持たれやすいということです。

そして今後は、より作れるものも増えていくでしょうし、何を作るのか?というディスカバリーもAIの力を借りることで効率化される未来は予測できます。そうなると、こういった疑問や早く作った方が良いという圧力を強く受けるようになります。

また、AIが書いたコードはそこまで保守性に優れているとは言い難く、ツギハギなシステムになっていく懸念もあります。そうすると、技術的な負債解消の必要性も上がるかもしれません。こういった状態においては、どこにフォーカスしていくのかという、プロダクトマネジメントがより重要になってきます。

しかし、1人の人間がこれらすべてを把握し適切な判断を下すことは非常に難しいと思います。もし完璧にこなせる人間がいたら、その人にすべての意思決定を担ってもらうのが良いと思いますが、大体のケースにおいては、プロダクトオーナーがボトルネックとなる可能性が高いのではないかと考えています。

そのため、多数のメンバーがプロダクトオーナーと近しい(≠同じ)視点を持ち、意思決定を行える組織になっていく必要があると考えています。まずは自分たちで意思決定をして問題ないかどうかの見極め力を身に着け、次に意思決定内容の精度を上げていくというのが求められると考えています。

5.4. これまで以上にスウォーミングを使いこなす必要がある

プロダクトマネジメントにより注力するべきポイントが決まったとして、それに対応して即座に動きを変えられる組織を作っておく必要があります。リードタイム競争に勝つためには、スウォーミングを体現することは避けては通れません。AIにより置き換えられる部分はAIによって置き換えれば良いでしょう。しかし、人間にしかやれない仕事が現状残っていることも事実です。

このように、人間がボトルネックになる世界では、人間が必要なチームに人間を集中させるという動きを取らねばなりません。そして、これをなるべく広い組織で実現することで、ハイリスクではありますがハイリターンを得ることに繋がると考えています。要はスウォーミングによって集められる人間がどれだけ多いかという話です。

特定のチームに深く入り込み「私はここから出ることはできない」という状態をなるべく避け「状況に応じていつでも移動できますよ」という状態を維持しておく、属人性をなるべく排除するというのが、今後重要性を増すのではないかと思っています。

5.5. イノベーションを起こしやすい状態にしておく

先ほど書いた「AIの進化と活用が進み、人が人との対話や交流を忘れ、AIとの壁打ちで満足してしまった結果、イノベーションが起きにくくなる」という状況を回避するためです。

これについては、具体的にこういう取り組みをしたら良い、みたいなものは考えれていません、すみません。ただ、これまで以上にビルドトラップに陥りやすくなり、ぱっとしないモノを作ってしまうリスクが高まっているということだけは認識しておく必要があるなと感じます。

これから我々は人間との対話よりもAIとの対話に進んでしまう可能性は高いです。なぜなら、人と話すよりAIと話すほうが楽だからです。同じことを何度聞いても怒らないし、それっぽい答えをすぐに用意してくれます。「そもそもそれっておかしくない?」みたいな問いを投げかけてくることも少ないです。結局のところ「気持ち良く効率的に会話をする相手」には、AIが最適なんだと思っています。

しかし、人との対話でしか生まれないものもたくさんあります。例えば、お互いの感覚を共有することから生まれるアイデア、インサイトのようなものであったり、対話の中で共感し、情熱を生み出す場合もあります。さらに、建設的な批判を繰り返すことによって、より本質的な議論へと遡ることも可能です。これらは一見すると非効率に見えるかもしれませんし、簡単なことではありません。しかし、これを避けるべきではないというのが私の考えです。

プロダクトをつくるというのは、クリエイティブな活動であるということを忘れず、意図的にイノベーションを起こしやすくするプロセスにする必要があると思います。

6. FASTはAI時代のスタンダードとなり得るか

それでは最後にここまでの話をふりかえり、FASTがどう貢献するのか?を見ていきましょう。

6.1. 流動的なチーミングによりスウォーミングが促進される

FASTは、チームではなくタスク中心に流動的なチーミングが行われるため、スウォーミングを促進しやすい特徴があります。ここで誤解しないで欲しいのは、FASTを使えばスウォーミングできるではなく、スウォーミングを促進しやすいということです。チームをつくる際に、こういう職種が必要とかそういう縛りもなく、人は入れ替わる前提なので、状況に応じたメンバー構成を組みやすい特徴があります。

極論ですが、FASTミーティングにおいて、各自が取り組むべきタスクを選択するため、これを最優先で倒すべきだという認識が揃っていれば、全員がそのタスクに取り組んでも良いわけです。そして、その際に誰かの許可を得たり合意を取る必要はありません。各自が自律的に判断すれば良いとされています。

そのため、コレクティブで注力するべきものの認識が揃っているのであれば、それに各メンバーが自律的に群がる仕組みになっています。ただし、逆に言えば、これは優先的に取り組むべきという判断を各自が下せるようになる必要があります。

スウォーミングができるではなく、スウォーミングを促進しやすい仕組みが整っている、というのは、こういうことです。

6.2. プロダクトマネジメントの課題に集合知で立ち向かう

FASTはボトムアップなネットワーク型の組織構造を謳っていますが、すべてをボトムアップに決める仕組みではありません。事業計画などは当然、開発組織の一存では決まりませんし、大枠のプロダクト戦略なども同様です。それらをベースに、PdMがBigPictureをいったツールやFASTミーティングを使って、コレクティブに方向性を指し示します。

ただし、BigPictureには時期という概念は存在しないため、「〜までにやるべき」といった可視化は原則おこないません。また、BigPictureに置かれていない差し込みのタスクであったり改善系のタスクなども日常的にこなしていく必要があります。そして、これらの情報をもとにFASTミーティングで自律的に取り組むべきタスクを選択します。この際、すべてのメンバーが精度の差はあれ、プロダクトマネジメント観点で考える必要があります。具体的には、いまこれをなぜやるべきなのか、どういった価値が出せるのか、どれくらいインパクトが見込めるのか、などです。

こうして考え抜いた結果、自分の取り組むべきタスクを選択します。誤解されがちですが、意思決定は合議で行う必要はありません。また、PdMに決めてもらうということも本来であれば行うべきではありません。判断が合っていようが間違っていようが、意思決定は自らの意思で行うべきだと私は思っています。そうしなければ「基本的には自由にさせてほしいけど困ったら決めて欲しい」みたいなワガママを言っている状態になるのも、個人的にはなんかダサいなって思います。

これは、全員が小さな領域においてのプロダクトオーナーになるための修行をしているとも言えます。全体的な目線を俯瞰して大枠の戦略であったり、方針はこれまで通り、PdMがプロダクトオーナーとして意思決定を行うべきだと思いますが、それ以外の細かい部分までPdMに判断を仰ぐことは逆に速度低下や意思決定の質の低下を招きます。人間はAIではありません、すべてを把握することは不可能です。

6.3. 複雑適応系の考えによりイノベーションが促進される

ただでさえ「AIの進化と活用が進み、人が人との対話や交流を忘れ、AIとの壁打ちで満足してしまった結果、イノベーションが起きにくくなる」という懸念を抱いている状態なのに、それに拍車をかけるような組織構造を採用してしまったらどうなるでしょうか。より一層、人々は効率的にアウトプットを出すことに注力してしまいます。それではイノベーションは起きません。

しかし、FASTは組織をEdge of chaosに置くため、そこに存在するときにイノベーションが最も促進されるとされています。もちろん、FAST以外にもイノベーションを起こしやすく考え方やツールは存在します。それこそ、ホンダの提唱したワイガヤなどは、自分もとても好きで、とても共感しています。

https://www.sbbit.jp/article/cont1/32161

しかし、FASTでは根本的な組織構造からこの問題にアプローチすることが可能です。ただ、これも同様に、FASTをやったからイノベーションが起こるではなく、起こしやすくするための仕組みが整っているに過ぎません。そこは勘違いしないようにしたいですね。

6.4. 変化への強さを育むことができる

今後の時代の変化において、これが最も大切な要素だと私は思っています。これから先、変化はより速く・激しくなり、複雑さは増す一方だと思っています。そういった自体の変化に、個人だけではなくチームや組織としても追従していかねばなりません。

FASTは他のフレームワークと比較しても構造や仕組みが最小限であるため、さまざまな状況に応じて、新たなプロセスを適応していけます。また、状況に応じたプロセスを生み出すことも可能です。実際に弊社でも、さまざまなオリジナルの仕組みを導入しています。

そして、これはなんとなく思っているだけなんですが、FASTにおけるベストプラクティスのようなものは、今後も生まれないのではと思っています。変化を推奨するフレームワークである以上、どんな組織の状態もスナップショットであり、その形がベストであり続けることはないと思っているからです。

また、FASTは思想を理解してそれを体現しようとする姿勢が非常に重要です。結局これも同じで、FASTをやったから変化に強くはなれません。変化に置いていかれない強さを手に入れるための修行ができるフレームワークだと認識するのが良いと思います。

6.5. チームの規模に関係なく使えるフレームワークである

そして、最後にそもそもの話をするんですが、FASTはスケーリングのためのフレームワークではない気がしています。スケーリングのためでなく、スケーリングにも耐えられるフレームワークなんだろうなと、最近は感じています。実際に、Single Team FASTという考え方もあり、多くの組織も最初はSingle Team FASTから始めたとされています。つまり、組織やシステムの規模は関係なく使うことができるということです。

これらのFASTが持つ特性やメリットは、必ずしも大きな組織でなければ享受できないわけではないのです。まずは小さなチームでFASTを試して、そこから広げていくという使い方もできますし、FASTをやるべきではなくなったチームがあれば、FASTをやめれば良いと思っています。例えば、大きな機能群からプラットフォーム的な機能を抜き出したときに、プラットフォームチームと元々のストリームアラインドチームは同じコレクティブで活動するべきでしょうか?別々のコレクティブとなりFASTを継続する手段もあれば、ストリームアラインドチームだけFASTを続け、プラットフォームチームはスクラムをやっても良いわけです。

このように、プロダクトや組織に求められている状況に応じて、柔軟に変化をしていけるというのが、FASTの良いところだと思っています。

7. まとめ

AIの急激な進化により、私たちの働き方は大きく変わろうとしています。組織はより柔軟に、より自律的になることが求められ、システムはより複雑に、より統合的になる可能性があります。しかし、これらの変化を完全に見通すことは不可能です。

これらの見えない変化に対応するためには、分割と統合に耐えられる組織大幅な外的環境の変化に耐えられる組織AIの力を最大限に引き出せる組織が必要です。特に、人間がボトルネックになる世界では、スウォーミングを体現し、属人性を排除して、イノベーションを起こしやすい状態を維持することが重要になります。

FASTは、これらの要求に応える可能性を秘めています。チームの規模に関係なく使える流動的なチーミングによりスウォーミングが促進される集合知による分散型意思決定複雑適応系の考えによるイノベーション促進変化への強さなど、AI時代の組織に求められる要素を多く持っています。

これは1年間やってきたからこそ言えるのですが、FASTを使いこなすには修行が必要です。思想を理解することも大変、理解したところで実践するのも大変です。コレクティブの全員がこれまで以上にリーダーシップを発揮していく必要があります。決して簡単な道のりではありませんが、AI時代の組織設計を考える上で、非常に興味深い選択肢の一つと言えるでしょう。

まとめると、未来の組織は、人間とAIが共存し、柔軟に適応し続ける組織になると思っています。そして、FASTはその実現のための重要なツールの一つとなる可能性があるはずです。

もっと詳しく話したい方はこちらから!

この記事を読んで、もっとFASTについて詳しく話したいなと思ってくれたそこのあなた、ぜひPittaからカジュアル面談の申込みお待ちしています!

https://pitta.me/matches/CMegIkhpGqgD

大規模アジャイルのフレームワーク、FASTについてなんでも話しましょう! というテーマで、FASTに関する疑問や雑談など、なんでも気軽にお話しできます。1年間FASTを最前線で実践してきた経験を包み隠さずお話しますので、気軽にお申し込みください!

GitHubで編集を提案
株式会社ログラス テックブログ

Discussion