AI時代の「組織OS」を書き換える Team+開発の失敗とこれから
はじめに
こんにちは、Findy Team+開発でEMを務めている奥村です。
現在、ファインディでは各リーダー陣によるシリーズブログを発信しています。その中でCTO佐藤からは「挑戦」について、VPoEの浜田からは「エンジニアリングの役割を超えた『染み出し』」についてのメッセージがありました。
今回の私の記事では、佐藤や浜田が掲げる「挑戦」や「ビジョン」に対して、現場の組織として具体的にどんな意思決定と取り組みをし、どう試行錯誤しているかという、現在進行形の具体な生々しい取り組みと描いている未来を書きたいと思います。
これまで：効率と予測可能性を追求
2025年のTeam+開発は、プロダクトの成長と人員の増加に合わせて「いかに安定して、高速に仮説検証を回せるか」に主眼を置いていました。
当時は「開発及びリリーススピードの最大化」を追求していましたが、それは単に速く作ることが目的というわけではなく、「仮説検証を高速化し、市場や顧客からのフィードバックを得るサイクルを最短にする」ことこそが、私たちが一番目指していたことでした。
そのために、当時は以下のような仕組みを選択していました。
職能による分業：BE/FEの境界を意識し、それぞれの専門性を尖らせることで、スループットの最大化を目指しました。加えてエキスパートを機能開発のチームとは分離して横断的な技術改善に取り組むようはからいました。
スクラム開発：複数のチームがありながらプロダクト全体での優先順位を意識し、リソースを最適配分することで、検証すべき課題への最短距離を検討しました。
トップダウンな情報の流れ：「PdM → EM → チーム」という明確な情報の流れを作り、予測可能性（いつ、何がリリースされるか）を担保しました。
この体制は、当時の状況において一定の効果を発揮しました。しかし、組織が拡大してチームが複数になり、検証すべき課題がより複雑になるにつれ、新たな壁も見え始めていました。スピードを優先するあまり、エンジニアが「何を作るか（価値）」の背景にあるドメイン知識に触れる機会が限定的になり、また、チームの垣根を越えたエンジニア同士の交流も少なくなっていました。
その結果それぞれのチームやメンバーが作るだけになっていました。
変化：AIによる「破壊」とエンジニアの「自律」へのシフト
より能動的に自律的に動ける開発組織あるいはエンジニアでありたい。その想いがありつつ逆行している感覚がありました。そこで定期的なサーベイ調査で定性的に組織の課題を洗い出し、OSTを実施して意見の発散と交流を促し、次の期に向けた情報収集と土壌づくりを行いました。
設問をお見せすることはできませんが、複数回のサーベイ調査から、デプロイ頻度やレビュー負荷については課題がないことを確認できた一方で、トイル対応の負荷やコラボレーションの不足が懸念として見えてきました。
OSTでは、サーベイ調査と同様にコラボレーション関連のトピックや、Team+のこれからについてのトピックなどが上がりました。
一方で、ご存知の通り2025年から2026年にかけてAIツールの進歩によってコードを書くコストが劇的に低下しました。AIを活用することで個々のアウトプットのスピードが上がることに加えて、他領域の開発にも入り込みやすくなりました。開発以外でも仕様の整合性チェックやドキュメンテーション、影響範囲の調査なども容易になりました。
エンジニアが、スピーディに確実に実装することはもはや当然として、事業に対してこれまでとは異なる関わり方を求められています。
これらを背景に「個の自律がチームを支え、組織の統合がプロダクトを輝かせる」をテーマに掲げ2026年に新しい体制と方針を打ち出しました。
私たちが直近で仕掛けた、組織を「進化」させるための取り組みを紹介します。
Epic Ownerの導入
機能開発を行う際にチームでのアサインをやめ、担当エンジニア（=Epic Owner）を設定するようにしました。担当エンジニアはPdMやデザイナーと直接会話をしてフルスタックで開発をします。これまでバックエンドあるいはフロントエンドのみを担当していたメンバーもAIを活用して領域を跨いで開発をしてもらっています。まだ企画への入り込みは行えていませんが、なにをなぜ作るのか理解を深められるようになり、他領域への貢献のハードルを下げられ、安定した進捗を望めるようになりました。
これまで並行して進められている機能開発数＝チーム数でしたが、現在は機能開発数≦メンバー数となっています。
合同レビューの実施
現在Team+開発は2チームで開発をしていますが、互いが何を開発しているのか見えない部分もあり、機能として正しくとも価値として正しいのかという葛藤があるままリリースがなされていました。価値として良いもの届けられるように、リリースする前にそれぞれのチームが開発しているものをレビューする場を設けました。この場には事業部のセールスやカスタマーサクセスのメンバーにも参加してもらい、「欲しかったやつ！」「こういうお客さんにはどう案内すると良さそうか？」「⚪︎⚪︎できないと価値にはならなそう」などと意見を発散しています。これを元にリリース前にバックログを書き換えより良いものをリリースできるように取り組んでいます。
技術改善の公募
機能開発と技術改善が分断していたためこの統合を目指しました。バックエンド・フロントエンドそれぞれのエキスパートがイシューを作成し、EMと共に隔週で優先度を判断します。その後チーム全体向けに公募をかけて手を挙げたメンバーがエキスパートと共に技術改善に取り組みます。メンバーの理解を深めたい領域や挑戦したい内容に自主的に名乗りを挙げる形になり、積極性と技術の両面での成長が期待できるようになりました。
アラート対応のローテーション
これまでアラートや問い合わせの対応が属人化する傾向にあり根本的な対応も後手に周り、トイル削減の動きがやり切れていませんでした。機能開発をすればするほど機能開発をする時間がなくなっていく状態でした。そのような状況を打破するためにアラート対応をウィークリーで二名ずつローテーションをして週の最後にふりかえりを行うようにしました。1週間固定だからこそ「面倒なことは減らしたい」という動機で根本の解消を進めてもらっています。
７：２：１の比率
上2つに関連して、機能開発に集中し続けた結果、これまで技術改善やトイル削減が進みませんでした。これを踏まえてリソースの充て方を「機能開発：技術改善：トイル対応=７：２：１」を正とすることにしてPdMと合意をしました。活動を制限するというより、Googleの20％ルールに近い考えです。またトイル対応に関してはエラーバジェット的に越えないようにしようという基準として定めました。上2つの取り組みを支える共通認識として機能しています。
挑戦：Team+開発が向き合う「組織」と「システム」の現在地
上記の取り組みは、まだ始まったばかりです。私たちは現在、大きく分けて「組織」と「システム」の2つの側面で「伸びしろ（＝解くべき難問）」に直面しています。
【組織】AI時代の「開発生産性」を自ら再定義し、体現する
私たちは「開発生産性」を最大化するためのプロダクトを作っています。だからこそ、私たち自身が「AI時代の開発生産性とは何か」を最も深く、模索し、理解し、体現する存在でなければなりません。
「作る」の先にある、事業への染み出し
AIがコードを書く時代、エンジニアの価値は「仕様通りに作ること」から「技術を使ってどう事業を勝たせるか」にシフトします。個々が企画から実装、リリース後の効果測定までを完遂する「フルサイクル・フルスタック」なプロフェッショナルとして、事業に向き合う組織を目指しています。
切磋琢磨し、共に成長していける土壌
それぞれのメンバーが自律してプロダクトやサービスに貢献していくためには更なる成長が必要です。個々の自律を尊重しつつ、互いの知見をぶつけ合い、フィードバックし合う。高い視座でプロダクトの未来を語り合い、共に成長していける。そんな強いエンジニア組織を今まさに作り上げている最中です。
【システム】進化に伴う「構造的課題」への挑戦
プロダクトの成長に伴い、利用企業の層がスタートアップ・ベンチャーだけでなく、大企業（エンタープライズ）へと広がっています。この「顧客層の変化」が、システム面での新たな挑戦を連れてきました。
大規模データに対するパフォーマンスと負債の解消
初期フェーズでは十分だった設計や運用も、大企業の膨大なデータ量やユースケースの拡大により、システムとしては負債が生まれてきています。障害もストレスもないパフォーマンスの追求、エンタープライズ特有の権限管理やデータ連携、より堅牢で柔軟なアーキテクチャへの刷新が模索しています。
「使いやすさ」の再構築
UI/UXにおいても課題があります。大量データ・多機能化が進む中で、いかに直感的で迷わないUI/UXを提供し続けられるか。複雑なドメインをシンプルに解きほぐすフロントエンドの改善も、私たちが取り組むべき課題です。
また、下記に現在向き合っている技術課題や挑戦テーマをまとめていますのでこちらも併せてどうぞ。
おわりに
CTO佐藤やVPoE浜田が掲げた挑戦は、現場の泥臭い意思決定と試行錯誤の積み重ねによってのみ実現されます。
ありがたいことに「ファインディってレベル高そう」と言っていただくことが多いですが、Team+開発はまだまだ未完の組織です。むしろ、AI時代によりこれまでの前提が塗り替えられる中で、新しい開発組織や開発プロセスのあり方、開発生産性というドメインを自分たちの手で模索し構築している実験場です。
この、ドメインもプロダクトも組織も、書き換えていく正解のない課題に共に取り組んでくれる仲間が必要です。興味や関心を覚えた方は是非カジュアルにお話ができればと思います。
