この記事は、Insight Edge Advent Calendar 2025の11日目の記事です！！
はじめに
こんにちは。アジャイル開発チームでエンジニアリングマネージャーをしている三澤です。本記事では今年実施したチームビルディング施策をご紹介します。
弊社Insight Edgeは、住友商事グループ各社のDXを推進するためにプロジェクト単位でチームを組成するスタイルをとっています。
そのため、「これまで一緒のプロジェクトに入ったことがないメンバーと次のプロジェクトでチームを組む」という状況が発生します。 だからこそ、プロジェクトをまたいでコミュニケーションを取り、互いの思考や技術観を知ることが重要となります。そこで今回実施したのが「アーキテクチャ大喜利」 です。
ここからは、実施背景から実施までに準備したこと、当日の様子、そして実際にやってみて分かった知見をご紹介します。
目次
なぜアーキテクチャ大喜利をやることにしたのか
企画のきっかけとなったのは、昨年読んだFindy Toolsの記事「アーキテクチャ大喜利『もし、⚪︎⚪︎な仕様のサービスを立ち上げるなら、あなたはどんなアーキテクチャを組みますか？』」でした。
著名なエンジニアが同じ仕様をテーマにそれぞれの視点から設計案を語る形式となっており、読み物としても非常に面白いものでしたが、これを読んだ時にふと思いました
「この形式、社内コミュニケーションにも使えるのでは？」
と。
同じ技術課題に対して人によってどう発想が分かれるのかを見ることは、それだけで相互理解と技術向上につながります。
そこで、この記事のコンセプトはそのままに、以下の2つを目的としたチーム活動として実施することに決めました。
実施の目的
- 普段関わらないメンバー同士のコミュニケーション促進
- 技術力の底上げ（特にアーキテクチャ思考）
当日までに準備したこと
チーム活動としてのアーキテクチャ大喜利の成否は「お題」で9割決まると言っても過言ではありません。ゆえに、参加者が楽しみながらも、技術的な思考を深められるような絶妙なバランスのお題を作る必要がありました。
そのために今回はChatGPTと対話を重ねながらお題をブラッシュアップしていく方法を取りました。
具体的には 1. 議論の方向性を揃えるための「制約」 2. 個性を引き出す「設計の余白」 3. 2時間で完結させるための「スコープ管理」
の3つのポイントを意識しながら作成しました。
1. 議論の方向性を揃えるための「制約」
お題に制約がないと注目すべき論点がバラバラになり比較がしづらくなります。よって共通の論点を確実に着目させるための仕組みが必要になります。そこで今回は以下のような制約を設定しました。
- テーマ: LLM（AIエージェント）での大規模ドキュメント要約
- 時間的制約: 1件約1分の個別要約を最大20件、さらに3分の統合処理を経て、全体を15分以内に返す。
- 負荷要件: 10〜30件の並行リクエストに耐えられること。
- 技術的課題:
- 共通APIから取得できるのはメタ情報のみ。PDFやテキストなどのドキュメント本体は自前で解析・抽出する必要がある。
- LLMの応答遅延や失敗を考慮したリトライ処理が必須。
このような制約を設けることにより、単純な逐次処理のアーキテクチャでは不可能になります。これにより、参加者は「並列・非同期処理」「スケーラビリティ」といった論点を議論することが可能になります。
2. 個性を引き出す「設計の余白」
一方で制約をガチガチに設定すると正解が一つに近づいてしまい大喜利としての面白さが薄れます。 そこで今回は同じ要件でも複数の解き方が存在する状態を作りました。
データ前処理の流儀
ドキュメント形式がバラバラなため、「どこまで丁寧に前処理するか」でチームの個性が出るはずです。「最初にすべてを共通フォーマットに変換する堅実派」や「プロンプトエンジニアリングで吸収する柔軟派」など、アプローチが分かれることを狙いました。
UX要件の解釈を委ねる
「ユーザが進捗を見られること」とだけ定め、具体的な方法は問いませんでした。これにより、「WebSocketでリアルタイム性を追求するチーム」や「ポーリングでシンプルさを選ぶチーム」など、何を大切にするかで技術選定が変わってくるはずです。
（余談ですが、最終的には似た構成に寄ったのですが、それはそれで「Insight Edgeの設計文化の一貫性」が見えて面白かったポイントです。）
3. 2時間で完結させるための「スコープ管理」
最後に、2時間という限られた時間で議論が脇道に逸れないよう考えなくていいことを明確にしました。
あえて周辺要件をシンプルに
データソースを「共通リポジトリ1箇所」に限定し、複雑な認証などをスコープ外に。これにより、参加者は「AIエージェントの非同期並列処理」という本丸に集中できます。
議論の道標を提示
お題の最後に「考慮すべき観点」としてヒントを提示し、議論が迷子にならないよう工夫しました。
以下が実際にイベントで使用したお題です。
作成したお題
# アーキテクチャ大喜利：大規模リサーチ用「ドキュメント要約・統合エージェント」 以下の前提・要件を満たすシステムを **どんな技術スタックで** 構成するかを議論・発表してください。 2時間の検討時間内で、クラウドサービスやミドルウェアを含めた設計アイデアをまとめましょう。 --- ## 前提（シナリオ） - **企業規模 / 利用者：** - 研究者・アナリスト・社員など数百～数千名がいる大企業を想定。 - 彼らが、日常的にドキュメント（PDF, テキスト, スライド等）を参考にして新しいリサーチやレポートをまとめるニーズがある。 - **目的：** - ユーザがまとめて指定した複数のドキュメントを、**AIエージェント（LLM）** で自動的に要約したい。 - 個別要約だけでなく、最終的に **全体を統合したサマリ**（重複排除や結論の集約）を作成して返す。 - **ドキュメント保管：** - 各部署が作成したファイルは **1つの共通リポジトリ**（S3や企業内ストレージ）に集約されている前提で**共通APIでアクセスできる**ものとします。 - ただし、**共通APIから取得できるのは“インデックス（メタ情報）”のみ**で、実際のドキュメントは**PDFや生テキストのまま**格納されており、システム側でテキストの解析・抽出が必要になる。 （例：PDFパーサーやテキスト抽出、OCRなど。どう実装するかは自由） - APIではカテゴリとファイルの種類、件数を指定することでメタデータを取得することができる - カテゴリは1,000種類 --- ## 要件 1. **処理時間の制限** - 依頼から **15分以内** に、最大20件のレポート要約と統合要約を完了し、ユーザへ結果を返すこと。 2. **1レポート要約にかかる時間** - 1件あたり **約1分** を想定（テキストであればという前提）。 3. **複数ユーザからの同時リクエスト** - 1度に **10～30件** 程度の並行リクエストが来る可能性がある（高負荷を想定）。 4. **ドキュメントの検索・抽出** - 共通APIから取得できるのはレポートのメタ情報（タイトル、更新日、URL等）のみ。 - 実際のドキュメントコンテンツはPDFやテキストのまま別途ダウンロードし、**自前で必要な箇所を抽出・解析**する必要がある。 5. **進捗表示 / 結果受け取り** - ユーザが「何件終わったか」「残りの所要時間は？」などのステータスを確認できる仕組みを用意する。 - 全要約完了後、最終的な統合サマリを取得できる（Web UI / PDF / JSON など形式は自由）。 6. **AIエージェント（LLM）の利用** - 外部API（例：OpenAI）や自前GPUクラウド（Kubernetes上のモデルなど）、いずれでも可。 - セキュリティ・コスト・性能を考慮し、採用理由を示すこと。 7. **再実行** - 異なるユーザが同じレポートを指定する可能性がある。 8. **統合要約の工程** - 個別要約がすべて揃った後、重複・矛盾を排除し **最終レポート** を生成。 - この統合要約工程に **約3分** かかる想定。 --- ## 考慮すべき観点 - **並列実行と非同期フロー** - 1件1分×20件 + 3分 = 23分をどう15分以内に短縮するか？ - オートスケーリング／キュー＆ワーカー/並列化など。 - **モニタリング・運用** - 高負荷時にどのようにスケールさせる？ - LLM呼び出しが遅延した／失敗したときのリトライ＆エラーハンドリングは？ - LLMOpsはどうする？ - **コスト / セキュリティのトレードオフ** - 外部LLMだと開発が簡単だが機密データや費用は？ - 自前LLMの場合はGPUリソース管理が必要。 - **ユーザビリティ / 部分的可視化** - レポートの一部が要約完了した時点で結果を先行表示するか、すべて終わってから返すか。 - 進捗状況をどう把握してユーザに通知するか（WebSocket, Push, Polling等）。 --- ## 大喜利のお題 - **目的**: 「どんな技術スタックやクラウドサービスで、上記要件を満たすシステムを作るか」 - **ゴール**: - 2時間の検討時間内に、「自分たちならこう作る！」というアーキテクチャ案をまとめ、**構成図・主要コンポーネント・フロー**など発表頂きます。 - 発表では **なぜその技術スタック・構成を選んだのか**、**どのように時間・高負荷・ドキュメント解析の課題を解決するか**、**コストやセキュリティとのトレードオフ** など、考えたことを自由に語ってください。 - **ポイント**: - 「どんなクラウドサービス・技術を使ってこの要件を満たすか？」 - 「どのように15分以内で最大20件の要約と統合要約を処理するか？」 - 「複数ユーザの同時依頼をどうさばくか？」 - 「進捗表示やエラー処理をどのように実装するか？」
当日の進め方
当日は、最大3人の小規模チームを複数つくり、チームに分かれて2時間の検討＋1時間の発表という合計3時間のスケジュールで実施しました。
ポイントは、ジュニアとシニアをバランスよく混ぜたチーム編成にしたことです。
また、今回はあえて事前にお題は共有せず、時間制限のある中で考えてもらう形式としました。
そのようにすることで、
- シニアの思考プロセスを間近で学べる
- ジュニアの柔軟な発想が議論に新しい視点をもたらす
- 普段同じPJにいないメンバー同士で自然に役割分担が生まれる
という効果が期待できます。ただし、事前にお題を共有しない点については、終了後アンケートで事前共有しても良かったのではないか、とのコメントもあったため、目的と手段のバランスはしっかりと考える必要があります。
また、このアーキテクチャ大喜利は「技術発表会」ではないので、
- 正解よりもなぜその構成を選んだのかという思考を明らかにすること
- 人によるアプローチの違いがあること
を理解して進めることが重要です。事前にそのような目的をメンバーに伝えることで、より適切な議論が生まれてくると考えます。
やってみて得られた効果と改善点
実施後のアンケート結果を見ると、参加者の満足度は非常に高いものとなりました。
- 今回の取り組みは楽しかったですか？：平均 4.7点 / 5点
- またこのようなイベントはやりたいですか？：平均 4.7点 / 5点
- 勉強になりましたか？：平均 4.5点 / 5点
- 時間は十分でしたか？：平均 3.2点 / 5点
- 難易度はどうでしたか？：平均 2.8点 / 5点 （本設問のみ3がちょうど良いレベルと設定）
この結果を見ると、「楽しさ」と「学び」が高水準で両立できており、イベントとしては成功だと考えられます。一方で、「時間は十分でしたか？」という質問に対する点数は低く、運営上の課題も見えました。
以下、具体的にもらったコメントを交えて良かった点と改善点を振り返ります。
良かった点
普段関わらないメンバーの技術のクセが分かった
「この人はユースケースから考えるんだ」「この人はデータ構造を先に固めるタイプだ」など、発想の違いがよく見えました。実際に以下のようなコメントがありました。
メンバごとの得意領域が異なるおかげでそれぞれをカバーしながら議論をしつつ、メンバの考えも理解することができて有意義だった
普段一緒に仕事していないメンバーとアーキテクチャ設計の議論できて、それぞれが持っている知識、業務からの知見、日々感じている課題を共有できた。共通言語がまた一つ増え、今後一緒に仕事したら役に立ちそうだと思った
これらの結果は、実際のプロジェクトでチームを組むときのコミュニケーションコストを下げることができると考えます。
思考過程の共有で学びが多い
アーキテクチャ設計は結果だけ見ても学べる量が限られます。 しかし検討中のコミュニケーションや大喜利形式での発表を通じて、トレードオフの優先順位など、普段は見えにくい部分を明らかにすることができました。実際に以下のようなコメントがありました。
普段使わないもの(AWS ※1)で設計できたので勉強になってよかった
議論を通じて、自分が知らない部分、他のチームメンバーもあまり分かっていない部分を把握できるようになり、今後しっかり調べて、情報発信すべきポイントなども掴むことができました
このように、単に設計知識を得ただけでなく、お互いにどこが分かっていて、どこが分からないか、を更新できたことは大きな収穫でした。
※1 弊社はプロジェクト毎にクラウドを使い分けており、普段Google CloudやAzureをメインで使っているメンバもいます。
改善点
設計にばらつきが出なかった
事前に「個性が出る仕掛け」を用意したつもりでしたが、結果的にはどのチームも似た構成になってしまいました。実際に以下のようなコメントがありました。
各チーム似たりよったりになったので、LLM自前みたいな普段やらないような制約があるともっとおもしろくなるかなと思いました
これは先にも書いた通り、ある意味弊社メンバのスキルが安定していると言うことも意味しますが、大喜利としての幅・技術力向上という意図に対してはもう少し広げたかったところです。
時間配分と事前準備
「時間は十分でしたか？」の回答は平均3.2点でしたが、内訳を見ると「2（足りなかった）」と「4（十分だった）」に意見が割れました。 当日は30分延長することになったため、時間内に収める工夫が必要と考えられます。実際に以下のようなコメントがありました。
お題を先に共有して、それぞれ事前にリサーチして持ってくるのも良いではないかと思います。ある程度調べられて事前準備がある状態だと議論もよくなり、より良い設計もできるのではないかと思いました
日々の業務を進める中で事前準備の時間を作るのも難しいかもしれませんが、事前準備をすることで議論に深みや幅を持たせられる可能性があり、今後検討していきたいと考えています。
これらの結果を踏まえると、今回のお題設定における①議論の方向性を整える制約と②個性が出る余白、そして③時間内で深めるスコープ管理はまだ改善の余地があったと言えます。
そのため、次回に向けては、
- 明確に複数の方向性があり得るお題
- 要件に明らかな矛盾を仕込む（例：コスト最優先 vs 精度最優先）
- 技術選定の自由度が高いテーマ（その場合には事前調査時間を作る）
などを混ぜたいと考えています。そうすることで今回でなかったバリエーションを増やせそうだと感じました。
ただ総じて交流イベントとしては成功だったと考えています。
今後の展開と応用の可能性
アーキテクチャ大喜利の考え方は他の場面にも応用可能だと考えています。
今後のアイデア例
新人・若手向けの設計トレーニング お題形式だと、ハンズオンより「思考の深さ」が見えやすい。
プロジェクト開始前のキックオフでのアイスブレイクアクティビティ 「この人はこう考えるんだ」が最初に掴めると、初動が圧倒的に速い。
今後もテーマを変えながら継続し、Insight Edgeの文化として根付かせていければと考えています。
この記事が、皆さんのチームや組織のコミュニケーションを活性化させる、何かのヒントになれば幸いです。
