1人がチームになる、開発組織のフラクタル / Fractals in Development Organizations

STORES Tech Conf 2026 "World 2"の登壇資料です。

Transcript

1. 1人がチームになる、 開発組織のフラクタル kitapashi
2. 自己紹介 北橋 祐貴 - Webエンジニア 2022年8月入社 ID基盤/顧客管理基盤/データ分析 など、 横断プロダクトの開発をたくさんやってます アナログレコード蒐集家/選曲家でもあります
3. さて AIとはうまく付き合えていますか？
4. 私は この間AIと良い開発をすることができました
5. この発表で話すこと・話さないこと 話すこと - 実際のプロジェクト推進の中でAIとどのように関わったか - そこから得た、「AIのいる世界」での開発に対して自身が考えていること 話さないこと - プロジェクトの技術詳細や細かい実装テクニック
6. 実践 -STORESデータ分析のUI統合-
7. 前提 - STORESプラットフォーム とは STORESは複数のプロダクトが集まってできたプラットフォーム
8. 前提 - STORESプラットフォーム とは 現状、プロダクトごとにシステム・ドメインが分かれている
9. 前提 - STORES データ分析 とは プラットフォームとしてプロダクト横断した分析を提供するプロダクト
10. 課題 - ドメインを統合したい ドメインが散らばっていることが品質向上/プロダクトの拡張の障壁になっていた - それぞれのプロダクトごとにセッションが分かれている →セッションに紐づける機能がプロダクトを横断できない コードベース/インフラも散らばっている →横断開発の難易度が高まる → プラットフォーム内のドメインを全てdashboard.stores.appに統合したい！
11. 統合前後のアーキテクチャ Before
12. 統合前後のアーキテクチャ After
13. アーキテクチャにまつわる大きな意思決定 dashboard.stores.appとして稼働するUIに、STORES分析のUIを移植 ひとつのフロントエンドとして統合し切る Q:LBのパスルーティング/セッション周りの仕組みだけを取り込んで別UIのままでも良いのでは？ A: 確かにより簡単に実現はできる。ただしシステム全体を見た時の複雑性は高まってしまう 最終的にモノリスを目指している。このタイミングでやってしまうのが効果的 AIの力を借りることで実装の移植も実現し切れるだろう
14. 他己紹介 kuro - STORES の業務を支える AI アシスタント 2026年2月入社 開発・ログ分析・データ抽出... なんでもやってます Slackで会話しながらタスクを進められます 今回実装を全てやりました
15. 今回の開発フロー 1人+AI(kuro)で完結する形で進める - 人間が指示を出す kuroが実装してPRを作成する 人間がレビューする 人間がマージする
16. PoC localで1つのUI/APIを移植、特にUIについて移植できるかを検証 - ここは手元のClaude Codeで実施、課題を1つずつ指示して直した
17. 前準備 - 検討 システムの差分を どのように吸収するかを決める - 移行元/移行先のシステムを静的解析 差分箇所について、 それぞれどのように統合するか意思決定
18. 前準備 - 手順作成 PoCとして1画面を移行する中で、 システムの差分によって UIが崩れる箇所が多発... ↓ セッション内での移植完了までのやり取 りから移植手順を作成 - まずはファイルをそのままコピー 命名規則を統一 移植先の実装ルールに合わせた調整(lint等) CSS Modulesの差分に伴うレイアウト調整 etc…
19. 前準備 - タスク分割とcontext doc作成 実装時にkuroに渡す、 「これさえ読めば実装できるdoc」を作成 - タスクの一覧 - タスク間の依存関係 - PoCで発見した実装時の注意点
20. APIの実装 ここからはkuroにタスクを並列で依頼していく - 分析APIに接続するEPはproxyとして実装 - dashboardのbackendで処理が完結するEPは新規実装
21. UIの実装 こちらも事前にタスク分割したのでそれをkuroに並列に依頼していく
22. QA/調整 - 全体の実装が出揃ってきたタイミングで実際に触れ、動作確認 - 使用感の差分があるところを1つずつkuroに依頼し、修正 - QA表もコードから生成してもらい実施、発見した課題もkuroに依頼し、修正
23. 結果 移植に成功 🎉 - 実作業: 2週間程度 変更コード行数: 33,488行 PR数: 58本 旧UI/BFFは実装/インフラ共に完全に削除 リリースに関連した問い合わせ: 1件
24. 結果 AIと共に速く、大きい成果を出せた！
25. では... なぜAIと共に速く、大きい成果を出せた？
26. 考察 -AIとともに開発をする-
27. Recap - 今回実施したこと - アーキテクチャを設計 PoCを行い実現できるかを検証 検証結果からタスクを分割して実装計画を作成 APIを順に実装 UIを順に実装 QAを行い、最終調整 リリース
28. Recap - 今回実施したこと - アーキテクチャを設計 PoCを行い実現できるかを検証 検証結果からタスクを分割して実装計画を作成 APIを順に実装 UIを順に実装 QAを行い、最終調整 リリース …素朴！
29. Recap - 実施した工夫 - コンテキスト込みのdocを作る - タスクを分割する - Conflict防止のため、タスク間での依存関係を整理 - 依存関係からタスクの実施順序を決める
30. Recap - 実施した工夫 - コンテキスト込みのdocを作る →新しく入ってきたメンバーに前提知識を伝える - タスクを分割する →複数のメンバーで1つのEpicを分担する - Conflict防止のため、タスク間での依存関係を整理 →メンバー間で作業の重複を発生させないようにする - 依存関係からタスクの実施順序を決める →メンバー間で作業の待ちを発生させないようにする これらはいずれも”プロジェクトマネジメント”と言われていたものではないか？
31. AI Agentは”同僚”？ kuroはSlackで対話する形式のInterfaceを取っている ↓ 同僚にタスクの協力を仰ぐ時と同じInput/Outputをしている ↓ これはもはや同僚そのもの(Duck Typing) お願い！ お願い！ やったよ！ やったよ！
32. 1人: N AI Agentの”チーム” 同僚に対して自分がリーダーとして指示を出しプロジェクトを完遂する これはもはや”チーム”そのもの これはかつて人間が組成していたチームと相似形をなす
33. なぜ速く作れたのか？ 人間が1人だったから... - AIとのチームにおいて、人間は常にリーダーのポジションを担う - 最終的な意思決定を担うリーダーは少ない方が速い - 仔細の意志決定まで複数の人間が議論すると時間がかかるため - World 2においては、Epicに対して携わる人間は1人の方が速い
34. なぜ速く作れたのか？ 人間が1人だったから... - AIとのチームにおいて、人間は常にリーダーのポジションを担う - 最終的な意思決定を担うリーダーは少ない方が速い - 仔細の意志決定まで複数の人間が議論すると時間がかかるため - World 2においては、Epicに対して携わる人間は1人の方が速い …では、その1人の意思決定の正しさ、質はどう担保するのか？
35. なぜ正しく作れたのか？ 中心にいる人間が知識・経験を持っていたから 1. ドメイン・プロダクトへの理解 →移植前の仕様を深く理解していたので、成果物のギャップを正しく測れた 2. STORESとしてのアーキテクチャの方針に関する知識 →プラットフォームの全体観に沿うアーキテクチャを設計できた 3. プロジェクトマネジメント・QA等の経験 →過去に経験があったため、AIとのチームに対しても適用できた
36. エンジニアリングは死ぬのか？ 死なない。 - 確かにコードは書いていない - が、ここまで話した人間の実践は、間違いなくエンジニアリング - プロダクト/システムを作っていく中で、人間が担う領域が、 1人がチームになる相似化を経て移った - それに伴ってエンジニアリング内での重要度が変わっただけ - World 2 でも、エンジニアリングは変わらず必要で、学び続ける必要がある
37. まとめ - World 2では、AIと協業することで、大きな成果を出せるようになった - AIと速く、大きな成果を生むためには、 1人がチームになる必要がある - そのチームが正しい道に進むためには、 中心にいる人間(あなた)の意志・知識・スキルが必要不可欠 - エンジニアの仕事はなくならない エンジニアリングは死なない
38. さて と、いうのが2026年4月時点の話でした
39. その後 -Fable 5、未来へ-
40. Fable 5とMulti Agent Orchestration Fable 5でのMulti Agent Orchestrationの指揮精度の衝撃(焦) 今回の実践↓を、4月時点より明らかに精度が高く実行できるようになった - タスク分割設計 - Sub Agentへの指示出し - 実装結果の検証 より大きいタスクを渡しても会話の中で一定達成できる状態に
41. 1人がチームになる、 開発組織のフラクタル kitapashi
42. ところで、フラクタルって？ フランス出身の数学者ブノワ・マンデルブロが命名した幾何学の概念 部分が全体と似る「自己相似性」を、何層も繰り返し持つ構造を指す ロマネスコ シルピンスキーのギャスケット
43. 開発組織のフラクタル これは「開発組織の自己相似化について、深度が深まった」と言えるだろう 4月: “チーム” - 1人 ×N AI Agent 現在: “組織” - 1人 ×M AI Agent ×N AI Agent 再帰的に自己相似する、 開発組織のフラクタルの中に我々はいる その中で人間の立ち位置が変わった
44. まとめ(改訂) - World 2では、AIと協業することで、大きな成果を出せるようになった - AIと速く、大きな成果を生むためには、 1人がチームに、そして組織になる必要がある - その組織が正しい道に進むためには、 中心にいる人間(あなた)の意志・知識・スキルが変わらず必要不可欠 - エンジニアの仕事は(きっと)なくならない エンジニアリングは(今のところ)死なない
45. あなたなら、どうしますか？
46. ご清聴ありがとうございました