challenge_club LT 会 by ＠kiws 1 

自己紹介 名前：いわさ（@kiws@kixxchllng ） 職場：自動車関連メーカー勤務 R&D エンジニア 仕事：センサ開発のプロジェクトリーダー デジタル信号処理、モデルベース開発、AI など幅広くやってます。 最近やっていること 他の組織との仕様調整、識別アルゴ開発、デモソフト開発、シミュ環境の立上、車両実験など。 社内外に技術紹介でいろんなところに行けそうです。 Discord で読書会やってます！もくもく読書会よければご参加ください！ challenge_club LT 会 by ＠kiws 2 

「どうして、こんなに頑張っているのに、組織の動きが遅いんだ？」 「チーム同士の調整に追われ、本来やりたい開発に集中できない… 」 challenge_club LT 会 by ＠kiws 3 

そんな経験がありますか？ その閉塞感は“ 個人” ではなく、" チーム構造そのもの" に原因があるとしたら？ " なぜチームが機能しなくなるのか" を知ることができたら？ 「価値をもっと早く届けるにはどうすればよいか」 を追求できたら？ challenge_club LT 会 by ＠kiws 4 

『チームトポロジー』 は、 チームの認知負荷 境界の決め方 チーム同士の関わり方 これらの観点から、現場で起こりがちな悩みにヒントを与えてくれる… かもしれません。 私自身は、吉羽さん（Ryuzee さん）の講演をきっかけに本書を知り、 CULTIBASE Radio でも話題になっていたことでさらに興味を深めました。 ※ hidetake さんが読まれていたのをきっかけに、読み直しました！ challenge_club LT 会 by ＠kiws 5 

チームトポロジーとは？ 近年、DX の進展でビジネスは加速し、 特にその変化を最も受けているのが ソフトウェア開発の現場 と言われています。 アジャイル、DevOps を取り入れ、 「どうすれば高速に価値を届けられるか」を試行してきました。 さらに、生成AI によってそのスピードはさらに上がり、状況は刻々と 変化しています。 チームトポロジーでは、こうした環境で最適な チーム構造 と チーム間の関わり方 を体系化しています。 challenge_club LT 会 by ＠kiws 6 

コンウェイの法則と逆コンウェイ戦略 「組織の構造は、つくるシステムに反映される」 これが コンウェイの法則 です。 縦割りの組織で作るシステムは、自然と複雑で調整コストの高いものになります。 これは、誰かの努力不足ではなく 構造の問題 です。 challenge_club LT 会 by ＠kiws 7 

そこで重要になるのが 逆コンウェイ戦略。 作りたいシステムアーキテクチャを先に描き、それに合わせて「組織構造を調整する」アプローチです。 例：マイクロサービスを目指す → 小規模チームへ再構成 こうすることで、チームの境界とシステムの境界が一致し、開発速度と品質が向上します。 challenge_club LT 会 by ＠kiws 8 

チームファースト思考 チームトポロジーの中心にあるのが「チームファースト思考」 。 焦点は“ 個人” ではなく、 チーム全体が無理なく機能し続けられるか。 鍵となるのが 認知負荷 です。 チームが理解し、扱い、改善し続けるために必要な「頭の負担」のこと。 challenge_club LT 会 by ＠kiws 9 

認知負荷が高くなると スピードが落ちる 品質が下がる 失敗が繰り返される 実際、多くの技術的な問題に見える現象は、 実は チームが抱え込みすぎている ことそのものに原因があります。 また、よくある落とし穴として、 「チーム間の情報共有をもっと増やそう」 「もっと密にコミュニケーションしよう」 これらは必ずしも良い結果を生みません。 重要なのは、複雑性を抑えること！ challenge_club LT 会 by ＠kiws 10 

チームトポロジーが示すポイント 1 チーム10 名程度が最適 認知負荷に見合う責任範囲を保つ 外部との関係は Team API で明確化 チームAPI （Team API ） は、 「このチームが何を提供するのか」 「どう連携するのか」 「どこまで関与する のか」といった外部との関係性を示す“ 仕様書” 。 公式のテンプレートも GitHub で公開されており、実務でそのまま使える形になっています。 challenge_club LT 会 by ＠kiws 11 

4 つの基本的なチームタイプ 1. ストリームアラインドチーム 顧客価値ストリームに沿って、機能開発〜運用を一貫担当する主役のチーム。 2. コンプリケイテッドサブシステムチーム 高度な専門知識が必要な領域を扱い、複雑な負荷を引き受ける専門チーム。 3. プラットフォームチーム 基盤やツールを “X-as-a-Service” として提供し、他チームの負荷を下げる。 4. イネーブリングチーム 技術的な壁に当たったチームを一時的に支援し、学習を促す。 challenge_club LT 会 by ＠kiws 12 

チームインタラクションモード（関わり方の設計） コラボレーション 複雑で不確実な領域を扱うときに、短期間だけ密に協力する関わり方。 ただし負荷が高いので、長期化させないことが大切です。 X-as-a-Service あるチームが基盤・機能・ツールを“ サービスとして安定的に提供する” 関わり方。受け取る側は毎回相 談せずに利用できるため、認知負荷が下がります。 ファシリテーション 技術的な壁にぶつかったチームを、一時的に支援し、学習を促す関わり方。イネーブリングチームがこ の役割を担います。 challenge_club LT 会 by ＠kiws 13 

challenge_club LT 会 by ＠kiws 14 

私の業務での例 私は R&D 領域の中でも センサ技術を専門に扱う少人数チーム に所属しています。 人数は10 名ほど ほぼ全員が技術者（アルゴ、ソフト、高周波、電気、機構など技術は多様） 会社内でこのセンサ専門家は私たちだけ センサは最終的に車両コンポーネントの一部となり、 製品全体のUX は別の事業部が担当します。 challenge_club LT 会 by ＠kiws 15 

■ チームタイプとインタラクションモード この構造をチームトポロジーで整理すると、 製品側の開発チーム → ストリームアラインドチーム 私たちのセンサ技術チーム → コンプリケイテッドサブシステムチーム 顧客提案時の連携 → コラボレーション さらに言えば、例えば、 社内のGitHub 環境 → プラットフォームチーム(X-as-a-Service) クラウド開発支援 → イネーブリングチーム challenge_club LT 会 by ＠kiws 16 

■ 課題の構造 “ 負荷の偏り” や“ 調整の難しさ” は、 個人の努力だけではなく 構造 に起因している可能性がある。 R&D チームでは、 技術開発 実証評価 営業提案（複数商材） 製品側の構想議論 技術問い合わせの対応 これらが同時進行。認知負荷が高まりやすい状況も。 PL, 課長, 部長, ベテラン社員etc 、プロジェクト外部からの情報共有がいろんなIF で、API で入ってくる。 challenge_club LT 会 by ＠kiws 17 

■ Team API の整理 GitHub テンプレートと生成AI を使い、自チームの外部仕様（API ）を定義しました。 APIの具体例（私のチームに当てはめたサンプル）を考えてください。 ## 私のチームの状況 （自分のチームを説明） いきなり実装せず、不明点があれば、質問してください。 ## TeamAPIのテンプレート 以下のリポジトリを参考にしてください。 https://github.com/TeamTopologies/Team-API-template challenge_club LT 会 by ＠kiws 18 

特に重要だったのは次の2 点でした。 担当しない領域（What we don’t own ） 避けたい利用方法（Don’t ） 社内唯一の専門チーム（しかも少人数）であるため、 多案件の並行対応は困難 長期コラボは持続不可能 → 組織的な投資計画が必要ですが、これは上層部判断領域です。 challenge_club LT 会 by ＠kiws 19 

■ Team API が浮かび上がらせた組織の構造問題 強み： 社内唯一の高度専門チームであること 研究開発から提案・検証まで一気通貫で対応できること 事業部と直接コラボできる関係があること 課題： 少人数で多責務を抱え、認知負荷が高くなりやすい コラボレーションが短期から長期に変質しやすい 仕様策定や要求整理など、本来他チームが持つべき領域が流れ込みやすい challenge_club LT 会 by ＠kiws 20 

つまり、私のチームは、 高専門性 × 少人数 × 多責務 × 多案件 × 複数事業部との連携 という 高価値でありながら、過負荷になりやすい構造 を持っています。 Team Topologies の視点で整理すると、 コンプリケイテッドサブシステムチームの過負荷化（認知負荷爆発） コラボレーションの常態化（短期 → 長期に変質） 境界の曖昧さ（責務が勝手に流れ込んでくる） Team API を作る作業は、単にチーム紹介の資料を作ることではなく、 “ どこがボトルネックになりそうか” を可視化する作業そのものでした。 challenge_club LT 会 by ＠kiws 21 

まとめ challenge_club LT 会 by ＠kiws 22 

さいごに 強く感じたのは、現場の「忙しさ」や「調整の大変さ」は、 個人ではなく“ 構造” の問題 だという点です。 関係者が増え、影響範囲が広がり、仕事が膨らんでも、 「努力すれば何とかなる」と思いがちです。しか し実際には、構造が整わなければ永遠に全力疾走で疲弊するだけです。 境界を少し整理し、 コラボレーション期間に区切りをつけ、 Team API で責務を共通言語化する 小さいことの積み重ねですが、それだけでもチームの負荷は軽くなります。 説明しきれなかった点も多いので、興味があればぜひ本書を読んでみてください。 challenge_club LT 会 by ＠kiws 23 

リンク チームトポロジー （単行本）価値あるソフトウェアをすばやく届ける適応型組織設計 GitHub/TeamTopologies ryuzee によるブログ記事： 【資料公開】30 分で分かった気になるチームトポロジー note 記事: 【読書メモ】チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 challenge_club LT 会 by ＠kiws 24 

ご清聴ありがとうございました！ Structure your teams for fast flow! challenge_club LT 会 by ＠kiws 25