記事のサマリー（TL;DR）
- freee のインターン生が 2025年7月10〜11日開催の Scrum Fest Sendai 2026 に参加し、AI × スクラム実践の最前線を報告
- Claude にドメイン知識のマークダウンを渡し、ホワイトボードツールのデータを MCP 経由で読み込ませる「仕様駆動開発」環境の整備事例が登場
- Conway の法則の「準同型」は「1対1対応」ではなく、組織を必要以上に大きくしないことの重要性を示す概念だと再解釈
国内 freee・kintone 利用企業の開発組織が注目すべき実践ポイント
今回のレポートで特筆すべきは、Claude と MCP を組み合わせた「仕様駆動開発」の具体的な運用例が、すでに国内スクラム現場で実装されている点です。ドメイン知識をマークダウンで整備し、ホワイトボードツール上のチームの知見を API/MCP 経由で Claude に読み込ませるという構成は、freee や kintone のように固有の法律・業務知識が複雑に絡む SaaS 開発において再現性が高いアプローチです。知識整備の過程そのものが他プロダクトへの横展開や新業務創出につながるという点は、AI 導入投資の費用対効果を考える経営層・情シス担当者にとっても参考になります。また、Conway の法則を「準同型」として正しく理解することは、大規模リプレイスや組織再編を検討する際に、システム設計と組織構造の整合性を適切に評価する視点を与えてくれます。
詳細
Scrum Fest Sendai 2026 とは
Scrum Fest（スクラムフェス）は、アジャイル開発やスクラムの実践者が初心者からエキスパートまで一堂に集まる大規模コミュニティイベントです。全国各地で開催されており、ほぼ毎月いずれかの地域でイベントが実施されています。今回は 2025年7月10日（金）〜11日（土）の2日間、仙台で開催されました。レポートを執筆した kenken 氏は freee 会社設立プロダクトでエンジニアインターンとして勤務しており、今回が初めてのカンファレンス参加でした。発表セッションだけでなく、他社エンジニアとの交流機会も充実していたと述べています。
セッション 1：「学びを奪うのは、AIじゃない。その賢さに頼りきることだ」
発表の概要
2年目エンジニアとスクラムマスターによる、AI を用いた仕様駆動開発（Specification-Driven Development）の実践報告です。スクラムマスターがどのように Claude 活用環境を整備し、2年目エンジニアがその環境でどのように業務に取り組んでいるかが語られました。
Claude × MCP による知識基盤の構築
最も印象的だった考え方は、「わからないことがあった時に直接教えるのではなく、AI に聞けば回答が返ってくるよう環境を整備し直した」というアプローチです。
具体的には次の2点が実施されていました。
- Claude へのドメイン知識の注入：プロダクトの背景となるナレッジや法律知識などを細かくマークダウン形式にまとめ、Claude に渡す
- ホワイトボードツールとの MCP 連携：チームメンバーが蓄積した「気をつけていること」「失敗談」などをホワイトボードツールにまとめ、API / MCP 経由で Claude が読み込める状態にする
この整備は「本当に大変だった」と正直に語られていましたが、その過程で得た実践知が他プロダクトの開発にも転用できるようになったこと、また整備内容に関心を持った人への共有が新たな業務機会につながったことも報告されています。結果だけでなく、整備プロセス自体に価値があるという主張は、AI 導入をコスト中心で捉えがちな企業にとって重要な視点です。
セッション 2（ワークショップ）：チームの鏡になる — 自分の癖を知ると、チームのパターンが見えてくる
ゴットマン博士の「関係の4毒素」
このワークショップは、心理学者ジョン・ゴットマン（John Gottman）博士が提唱する「関係性を悪化させる4つの毒素」を軸に構成されていました。スクラムチームの対人関係に直接応用できる内容です。
| 毒素 | 内容 | 解毒剤 |
|---|---|---|
| 非難 | 相手の性格・人格を攻撃する | 主語を「私」にして自分の感情と状況を伝える |
| 侮辱・軽蔑 | 皮肉・嘲笑で相手を見下す | 相手へのリスペクトを意識し、感謝を言葉と態度で表現する |
| 防御 | 言い訳や自己正当化をする | 相手の指摘に耳を傾け、非がある部分を素直に認める |
| 逃避・無視 | 会話や話し合いを拒絶する | 感情的になっていることを認め、数十分の休憩後に再開する |
ワークショップを通じた考察
参加者同士で「自分はどの毒素が出やすいか」「なぜ生じるのか」を議論し、さらにチームレベルでも同様に分析しました。レポート著者の考察によれば、非難・侮辱は感情的な期待の伝え方から生じやすく、防御・逃避は責任の所在が曖昧な問題で自己保護に走ることで発生しやすいとのことです。
ワークショップ後、システムコーチ（人間関係をコーチングする専門職）との対話から、同じ人物でも所属コミュニティによって出やすい毒素が変わるという知見も得られました。チームの雰囲気が悪化した瞬間ごとに「どの毒素が・なぜ発生したか」を都度振り返ることが、健全なチームダイナミクスの維持につながると考察されています。
セッション 3：Conway の法則を “ちゃんと” 使うために — 原典で Conway は何を言っていたのか
Conway の法則とは
Conway の法則とは、「組織がシステムを設計するとき、組織構造を模倣したような設計に縛られがちになる」という法則です。メルヴィン・コンウェイ（Melvin Conway）が 1968年に発表した論文に由来します。
よくある誤解：「1対1対応」説
この法則はしばしば「システムの構造と組織の構造は1対1対応する」と説明されますが、Conway の原論文では数学的な表現で**「準同型（homomorphism）になる」**と書かれています。準同型は1対1対応（全単射）でも相似系でもありません。
発表者のぼのたけ氏が示した例では、複数のモジュールと依存関係を持つソフトウェアが、単一組織（個人開発や小規模企業）にマッピングされるケースも Conway の法則の成立例として挙げられていました。これは明らかに1対1対応ではありません。
Conway が本当に言いたかったこと
準同型の概念を正しく踏まえたうえで、ぼのたけ氏は「大規模システムはなぜ崩壊するのか」というテーマについて次のように考察しました。
- 大きいシステムを設計するために多くの人員を投入したくなる
- 人員を増やしてサブグループへの仕事の移行を進める
- その結果、グループ間のコミュニケーションが取りづらくなる
- 準同型として定義されていた関係が崩壊し、Conway の法則が成り立たなくなる
- システム自体も崩壊する
この一連の流れから、Conway が本当に主張したかったのは「システムの変更に柔軟に対応できる組織にしておくべきだ（＝組織を必要以上に大きくしすぎない）」ということではないか、という再解釈が提示されました。
freee の組織構造との接点
レポート著者は、freee が Conway の法則を活かした組織構造を実践していると感じたと述べています。プロダクトを細かく分割し、それぞれ少数のチームで構成することで、プロダクト間コミュニケーションを維持しやすい設計になっているという観察です。今後は『チームトポロジー（Team Topologies）』を読んでさらに考えを深めたいと締めくくられています。
今回のカンファレンス全体を通じて
今回のセッションは、細かい技術実装の話よりも「組織がどうあるべきか」「どのような開発体制をとるべきか」に焦点を当てたものが多かったとレポートは総括しています。AI が急速に発展するなかで、最適な組織・開発体制のあり方は継続的に変化しており、技術だけでなくチーム構造や対人ダイナミクスの視点を持つことの重要性が改めて示された場でした。