フューチャーアドベントカレンダー 2025 の 22 日目の記事です。
はじめに
ここ数年にわたってアーキテクトチームのリーダーとしてチームを組成し、試行錯誤しながらビルディングしてきました。
私の中では、ただチームをマネジメントするだけではなく「強いアーキテクトを育成する」というミッションを持って取り組んできましたが、その中で何を想い、どう動いてきたかをここに残そうと思います。
メンタルモデル
話を進めていくにあたって、まずはここで対象としている「アーキテクトチーム」というものに対する目線を合わせておきます。
アーキテクトチームの役割
アーキテクチャという言葉にさまざまな定義・解釈があるように、アーキテクトチームといっても、その姿は組織によって大きく異なります。
本記事におけるアーキテクトチームとは、一般的に「ソフトウェアアーキテクト」や「テックリード」と呼ばれる役割に近いことを担うチームととらえてもらえるとよいでしょう。
あくまで一例ですが具体的には次のような作業に責任を持ちます。
- アーキテクチャドライバの特定
- システム全体構成の設計
- サービスカット/機能配置の設計
- 各種技術選定
- 処理方式設計
- 設計規約・設計ガイドラインの整備
- コーディング規約・実装ガイドラインの整備
- 開発環境の構築
- アプリケーションアーキテクチャの設計・実装
- フレームワークや共通機能の設計・実装
- 個別機能設計レビュー
- 個別機能の実装レビュー
- クラウドインフラの設計・構築
- 構成管理、CI/CD 設計・構築
- 非機能テスト（性能、セキュリティ、障害など）の計画と実行 etc...
その役割は多岐にわたりますが、ざっくりいうと「技術領域に関して重要な意思決定を行い、技術面での品質担保に責任を持ちつつデリバリまでをリードする」チームと言えそうです。
チームの規模・特性
当初は 2~3 名で始まり、最終的には 15 名程度にまで拡大しました。
リーダーの私が社会人歴 13 年目、領域別（フロントエンド、バックエンド、インフラ）のサブリーダーが 5~9 年目、各メンバは 3~6 年目程度とジュニア・ミドルクラスが中心となります。先ほど説明したアーキテクトとしての経験を豊富に積んできた人はほとんどおらず、個別の技術領域に強みを持った人や技術的なチャレンジをしたいという人が集まったようなチームでした。
システムの規模・特性
この話をする上でそこまで重要ではありませんが、機能数は 100~150 程度のそれなりにミッションクリティカルなエンタープライズ領域のサービスとイメージしてもらえればよいでしょう。エンタープライズと聞くとレガシーな印象を持たれる方もいるかもしれませんが、既存技術のしがらみや制約などがないまっさらなところからスタートした新規のシステムとなります。
思想や価値観を共有する
初期段階において力を入れたのは、チームとして全員が同じ方向を向いて進んでいくための土台づくりです。
具体的には次のようなことを行いました。
チーム規範（Team Norms）の策定
チーム規範とは、チームの中において求められる行動や判断の前提を言語化したものです。
タックマンモデル では、チーム形成のプロセスは「Forming（形成期）」「Storming（混乱期）」「Norming（統一期）」「Performing（機能期）」「Adjourning（散開期）」の 5 段階（もともとは 4 段階）があるとされています。
チーム規範の策定はチームの Forming（形成）から Norming（統一）までをできる限り短くするための取り組みです。こういってしまうと大げさに聞こえるかもしれませんが、簡単に言えば「チームの中で動くときに大切なこと」を言語化して 1 枚のスライドで示したにすぎません。具体的には次の 3 点を掲げました。
批判をせず、高い水準を追求する
これは一言で言えば Amy Edmondson の心理的安全性と責任の 4 象限 における「Learning Zone」を目指していこうということです。
チームとして人を批判することなく、安心して意見を出せる心理的安全性の高い状態を目指す、それは何でも受け入れる「ぬるい状態（Comfort Zone）」をつくることを意味するわけではありません。心理的安全性を土台としつつも、チームとしての判断に対しては妥協せず、建設的な議論を通じてより良い答えを探し続けていく環境をつくろうとしました。
正解を求めずトレードオフを理解する
Mark Richards がソフトウェアアーキテクチャの第一法則として述べた 1 ように、ソフトウェアアーキテクチャはトレードオフがすべてです。
アーキテクトチームのあらゆる設計判断においては、常に複数のソリューションを手札として持ち、何を優先し、何を犠牲にしているのかを理解することが求められます。
また、これは同時に、安易に「答え」や「正解」を求めるような仕事の進め方をしてはいけない（そもそも正解などない）ことを意味しています。
あくまでリーダーに確認するのは「ゴール」や「考え方」であって、自分自身が仮説を持った上で最善だと考えられるものにたどり着けるまで思考することが重要です。
すべての意思決定に責任を持つ
アーキテクトの意思決定は、その良し悪しがすぐに結果として現れるものではありません。
私の経験では、設計や技術選定の結果がはっきりと見えてくるまでには、早くても数年（経験では 3 年以上）かかることがほとんどです。
だからこそ、意思決定を行う際には「いまどう見えるか」ではなく、数年後にそのシステムと向き合う自分たちの姿を意識しなければなりません。
そのときに発生する負債や苦労も含めて、自分が引き受ける覚悟を持てるかどうかがアーキテクトに求められる責任だと考えています。（キラキラ技術を採用して退職、その後残った人が苦労する、という話は、みなさんもどこかで聞いたことがあるでしょう。）
以上3点が私のチームが掲げた規範となります。
このような規範をつくることでチームメンバの意識を合わせたいというのはもちろんですが、今振り返ると「リーダーがちゃんとチームをつくろうとしている」という意思を示したかったという側面も大きかったように思います。
アーキテクチャコンセプトの策定
チーム規範が「どう振る舞うか」をそろえるためのものだとすると、アーキテクチャコンセプトは「どこに向かうのか」をそろえるためのものです。
旅にたとえると、チーム規範が「歩き方」を示すのに対し、アーキテクチャコンセプトは「方角」を示すようなものと言えそうです。
アーキテクチャコンセプトは、ビジネスとして何を実現したいのか（ビジネスゴール）から導出されるものであり、アーキテクチャがどのような世界観（という言葉を私はよく使っていました）を実現すべきなのかを言語化したものです。
ここでいうコンセプトは、マイクロサービスとかモノリスといった具体的な構成や技術選定を指すものではありません。
ときとしてアーキテクチャの議論では、理由や前提がないまま「マイクロサービスでいくぞ」といったような話が先行してしまうことがあります。
そのような技術ありきでコンセプトを描いてしまったら、アーキテクチャそのものが目的化してしまっているスメルだと言えるでしょう。
ビジネスと紐づいたシステム視点のコンセプトを定めることで、あらゆる技術的な議論において「この判断は、目指している方角に沿っているか」という問いが立てやすくなります。
コンセプトは答えを与えるものではありませんが、迷ったときに立ち返るための拠り所として機能します。
アーキテクチャ方針の策定
アーキテクチャ方針は、アーキテクチャコンセプトをもう一段階具体化したものです。
アーキテクチャコンセプトが「方角」を示すものであれば、アーキテクチャ方針は「具体的なルートの選び方」といったところでしょうか。
具体的には次のように、システムアーキテクチャの設計に影響するものを中心に方針化を進めていきました。
- システムを構成するサービスの分割方針
- アーキテクチャドライバ（ビジネス要求、機能要求、非機能要求など）2 をもとにしたシステムやサービスの実現方針
- クラウドサービスやミドルウェア、フレームワーク、ライブラリの技術選定方針
- ネットワークの設計方針
- 可用性、性能・拡張性、セキュリティ、運用・保守などの非機能の方針
あくまでこれは設計そのものではなく、設計をするための軸、土台となるようなものです。
もちろん実際に方針を描くにあたっては、ある程度具体の設計に踏み込みながら進めていく形にはなりますが、あくまで設計ではなく方針であるというところの位置付けや抽象度を意識して整理を進めていった形になります。
方針化などせずにいきなり具体の設計に踏み込んだほうがクイックにゴールまでたどり着けると思った方もいるかもしれません。
この理由としては、意思決定の属人化を防ぎつつ、設計判断や意思決定そのものをメンバにスケールさせたかったからです。
さらにメンバの入れ替わりが発生したとしてもチームとして一貫した意思決定を実現できることも狙いとしてありました。
意思決定のスキームを整備する
アーキテクチャとは、Martin Fowler 曰く「重要で変更が困難な意思決定」3であり、Michael Keeling 曰く「望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構成するかということに対する、重要な設計判断が集まったもの」4です。
その定義にはいろいろな解釈がありますが、技術上の意思決定や設計判断に大きく関わることは間違いないでしょう。
そのためアーキテクトチームとしてこの意思決定や設計判断をどう行うかを考えることは非常に重要です。
意思決定の場の設計
まずは意思決定を行う場そのものをどう設計するかを考えました。
どれだけ立派な規範や方針があっても、それを使って判断する場が機能していなければ、有効なものにはならないからです。
アーキテクトチームでは、日次で 1 時間、技術的な意思決定や設計判断、ないしはそこに至るまでの議論や壁打ちを行うためのミーティング枠をあらかじめ確保する形にしました。
ミーティングは Slack のリスト機能を活用して、相談したいネタを持っている人が日付、所要時間、必須参加者を指定してエントリ（ネタがなければその日はスキップ）するスタイルです。
設計者としての狙いは次のとおりです。
- メンバ視点ではカレンダーを見てミーティング調整するコストがかからない、リーダー視点ではミーティングの流量を一定コントロールできる
- メンバ全員が存在を認知しているオープンな場で議論することで、フロントエンド、バックエンド、インフラそれぞれ技術専門性をもった参加者からさまざまな角度での意見がもらえる
- 自身の領域外ではあるが、興味のある分野の議論などは、いわゆる ROM 専で参加することで、技術的な知見を得られる
10 数人規模のチームだからということもありますが、このミーティングスタイルは結果として非常に体験がよいものでした。
チーム規範で掲げた内容にも関連しますが、この場は正解を求めたり、誰かが答えを与えたりする場ではありません。
各自が自分なりに検討したうえで「現時点ではこう判断すべきだと思う」という案を持ち寄り、それを複数の視点から吟味し、納得感のある判断に落としていくための場です。
重要だったのは、結論そのもの以上に、そこに至るまでの思考やトレードオフ（いわゆるHowよりWhyの部分）をチームとして共有することでした。
このプロセスを繰り返すことで、アーキテクトとしての思考力が徐々に底上げされていったように感じています。
意思決定の記録
アーキテクチャ上の意思決定を記録する方法としては ADR（Architecture Decision Record）が有名です。結論からいうと私のチームでは ADR のフォーマットで文書化する方法にはこだわりませんでした。
これは生成 AI の登場が大きいと言えるでしょう。
ミーティングは Google Meet を利用して実施していましたが、録画と Gemini による自動メモ作成を有効化することで、文字と動画でのすべての記録を残します。
自動起こしされた会議メモはすべて NotebookLM にアップロードすることで、過去の意思決定に対する経緯などを誰でも気軽にプロンプトで尋ね、回答を得ることができます。
ADR で達成したかった目的は十分達成できているので必要ありませんでしたが、会議メモの内容から ADR の生成ももちろん可能です。
また、これは当初意図した狙いではありませんでしたが、ミーティングを固定枠にしたことで自動生成される会議メモや動画を一元的に管理でき、NotebookLM への連携がスムーズにできたのはうれしい誤算でした。
コンフリクトへの対応
意思決定を行ううえで、全員が同じ意見であれば、そんな簡単なことはないでしょう。
実際には、技術的な背景や経験、専門領域の違いから、意見がきれいにそろわない場面も少なくありません。むしろ、チームが健全に機能していれば、そうしたコンフリクトは自然に発生するものだと考えています。
リーダーとして意見が割れたときにどう判断するのかの軸を持っておくことは重要です。
私が意識していたのは、単に「どちらが正しいか」を決めることではなく、主に次の点を軸として判断していました。
- その設計判断がアーキテクチャのコンセプトや方針を明確に逸脱していないか
- その設計判断に担当者自身の明確な意思や理由があるか
- その設計判断とは異なる意見のトレードオフを担当者が適切に理解したうえで判断できているか
これらを満たしているかどうかを軸に、最終的なジャッジを実施していました。
また、すべての判断を同じ重さで扱っていたわけではありません。
その設計判断がビジネスやシステム全体に与える影響の大きさ、失敗した場合のリスク、後からの変更容易性なども考慮し、「どこまで厳しく見るべきか」というランク付け（といっても High/Normal の 2 分類程度ですが）を自分の中では持つようにしていました。
そのうえで、これらの観点をクリアしていると判断できる場合には、たとえ私自身の考えや好みと異なっていたとしても、最終的には担当者の意思を尊重するようにしていました。
これは自ら意思決定を行うことがシステムに対するオーナーシップをはぐくむと考えているからです。
また、自らの意思決定の結果をきちんと見届け、そこからフィードバックを得ることが（仮に失敗を伴ったとしても）アーキテクトとしての成長につながると信じていたからです。
メンバの視野を広げる
意思決定のスキームを整えることは重要ですが、それだけでアーキテクトとしての判断力が磨かれるわけではありません。
アーキテクトには、ある特定の技術に深く精通していること以上に、複数の選択肢を比較しながら判断できるだけの「技術の幅」が求められます。
しかし、特定のプロジェクトやチームの中だけで仕事をしていると、どうしても扱う技術や考え方は限定され、前提や視点が凝り固まりがちになります。
だからこそ、普段の業務の中だけに閉じず、外の世界の技術や考え方に触れる機会を意図的につくることを重視していました。
Slack における技術情報の共有
私は日常的に X で技術情報を収集していますが、いわゆる「今巷で話題の技術ネタ」のようなものが日々あると思います。
少し前の話題で言えば、澁川さんが 3 日目のアドカレ で投稿していた Package by Feature の話もそうですね。
こうした情報は、すぐにプロジェクトに適用できるかどうかは別として、「世の中ではこういう設計の考え方が議論されている」という事実そのものを知ることに価値があります。
Slack にはこのような自分がおもしろいと感じた投稿や記事などを、感想も添えつつ、積極的に流すようにしていました。
全員がすべてを深く読むことはまったく期待していません。
なんとなくタイムラインに流れてきて記憶の片隅にでも引っかかりを残すことができればよいな、くらいの気持ちです。
勉強会への参加を推奨する
勉強会やカンファレンスについても、定期的に共有していました。
特に現在メンバが取り組んでいる設計領域に関係するようなものは積極的に（ただし参加を強制するわけではなく、あくまで参考程度に）発信していました。
時には若手のメンバとともに勉強会に参加し、終了後に感想戦のような形で話すこともありました。メンバのためと偉そうなことを言いながら、私が純粋に一緒に勉強会でワイワイできる仲間を増やしたかっただけのような気もします。
技術書の紹介/読書会の開催
私自身が読んで良かった技術書の中でも、特定のメンバに刺さりそうなものは「XX さんとか YY さんあたりにお勧め」というような形で紹介していました。
また、チームとして取り組んでいるシステムのど真ん中となるような技術領域をテーマとした書籍などは、読書会を企画し、有志で読み進めるような取り組みも行いました。
当然メンバは日々の業務が忙しいため、このような取り組みは基本的に強制力が働かないようにしなければなりません。
リーダーという立場上、意図しないパワーが働いてしまうことには細心の注意を払いながら、気兼ねなく参加も、不参加もできるカジュアルなチーム文化を整えていくことも意識したところです。
社内の技術コミュニティでの活動
プロジェクト外の取り組みとして、私が関与している社内の技術コミュニティの活動に、興味のあるメンバが積極的に関われるようドアオープナーとなりました。
今年は Future Architecture Guidelines の作成に力を入れていましたが、Web フロントエンド設計ガイドラインなどは、私と私のチームのフロントエンド領域に強いメンバが中心となって作成・公開したものとなります。
総じて、これらの取り組みを通じて一貫して意識していたのは、メンバに何かをやらせることではなく、自発的に視野を広げるためのきっかけや選択肢を用意する、というスタンスです。視野を広げることは、強制されて身につくものではありません。
興味を持った人が、自分のペースで一歩外に出てみる、そのためのドアをいくつ用意できるかが、私の仕事でした。
メンバを知る
チームとしてのしくみや方針を整え、成長のための機会を用意しても、それだけでメンバ一人一人が同じように成長できるわけではありません。
誰に、どこまで任せるのか、どのタイミングで背中を押すのか。それを判断するためには、メンバ個人の状態を知る必要があります。
そのための取り組みの 1 つとして 1on1 に力を入れました。
頻度は月に 1 回程度、1 回あたり 20~30min で、ジュニアからシニアまでアーキテクトチームの全メンバを対象としていた形です。
1on1 の必要性については賛否あると思いますが、少なくとも「チームをつくる」「メンバを育成する」というリーダーの目線では間違いなく必須だと感じています。
私の主な目的は、メンバの身体的、精神的な状態を確認することでした。
ここが不調な状態では、そもそも「育成」というステージに立つことができません。
合わせて、サブリーダー視点から見たメンバの様子や、逆にメンバ視点から見たサブリーダーやチームの状態なども聞くことで、チーム全体がヘルシーな状態にあるかを確認する場としても使っていました。
もちろん 1on1 をやる以上、メンバにとっても実施する意義や旨味がないと成り立ちません。
業務進捗やタスクの話をしないことを基本原則としつつ、直近悩んでいること、キャリアの壁打ち、良かった点・悪かった点、今後の展望など、できる限り自分よりもメンバが話す時間を多く取ることを意識して臨んでいました。
1on1 も 15 回/月程度の開催になると、純粋な時間の確保、体力面でもそれなりにたいへんです。どのくらい費用対効果が高かったのかは正直なところまだわかっていません。
ただし 1on1 を通じて、普段の業務では知り得なかったメンバのポジティブな一面が見えることは多く、やらないよりは確実にやってよかったという手応えはあります。
まだ私も 1on1 については手探りな状態であり、次回からはもっと作戦を立てつつ効果的な振り返りができるよう継続していきたいなという気持ちです。
リーダーとしてチームのために動く
最後に、私自身が日々リーダーとして動く中で、メンバ、ひいてはチームのバリューを最大化させるために意識的に取り組んできたことを紹介します。
コミュニケーションの橋渡しを担う
アーキテクトチームといってもチームの中に領域（フロントエンド、バックエンド、インフラ）が存在し、領域ごとにサブチームがつくられると、サブチーム間のコミュニケーションコストは増加します。
さらに、アーキテクトチームの仕事はチーム内だけで完結するものばかりではありません。
ほかのチーム、プロジェクトリーダー、顧客など、複数のステークホルダを巻き込みながら進めるものが数多くあります。
普段あまりコミュニケーションを取らない人に対するコンタクトは、チーム内でのコミュニケーションと比べてコストが高いため、その最初の橋渡し役となるよう積極的に動いていました。細かい話にはなりますが Slack でスレッドを立て関係者を巻き込む、ミーティングをアレンジする、前提となるコンテキストを補足する、などです。
一時的なハブとして動き、流れができたら自然に手を引く、次からはメンバに任せるという形のフォローを意識しました。
常に 1 つ先のフェーズのために手を動かす
たとえば、メンバが設計を実施しているとき、私は開発環境の構築（cf. エンタープライズな現場で実現するモダンな開発環境構築）やプロトタイプの開発、開発ワークフローの整備などを行っていました。またメンバがコーディングを実施しているときは、結合テストの実施にむけた環境構築、デプロイ、疎通などをオーケストレーションするなど、常に一歩先のフェーズを意識して手を動かすようにしていました。
狙いはシンプルで、チーム全体の流れをとめないためです。
あるフェーズがおわった瞬間に「次にやるべきこと」が見えていないと、そこで一度スピードが落ちます。
そのため、メンバがフェーズの切り替わりを意識することなく、シームレスに次の作業へ走り続けられる状態をつくることを意識していました。
不調なチームを早めに察知し、フォローする
複数のチーム（サブチーム）を見ていると、順調なチームもあれば、不調なチームもあるでしょう。
リーダーとしてすべてのチームに対して 100%のフォローができるわけではありません。どこに自分のリソースを投下するかは常に優先順位付けが必要です。
不調の要因は、技術的難易度が高い、生産性がなかなか上がらない、物量に対して人的、時間的リソースが足りていないなどさまざまです。
いずれにせよ、なるべく早期にスメルを検知し、早めに手当することが望まれます。
リーダー自身がタスクを抱えすぎると、この検知が遅れたり、検知できたとしても対応が遅れたりします。常に状況に応じて動ける余力を残しておくことが重要です。
また、不調に見えているチームばかりをフォローしていると、順調そうに見えていたチームがそうでなくなることもあるので注意です。
私は、週次でチームの最新状態を把握しつつ、月次くらいの粒度でどのチームに自分のリソースをどれくらい割り当てるかをプランニングしていました。
おわりに
2025 年最後のアーキテクトポエムでした。
このチームビルディングの結果としてメンバが強くなったのかどうかを測るのはとても難しいです。もちろん飛躍的な成長を遂げたメンバもいますが、それはそのメンバがもともと優秀だった（勝手に成長した）と考えるのが普通でしょう。
いずれにしても、チームビルディングにおいては、結果を追うことよりも、明確な意思や戦略をもって取り組むことが重要です。
そしてできればこの記事のように、その意思や戦略を言語化し、メンバからフィードバックを得られるとよいのではないでしょうか。
最後まで読んでくださりありがとうございました。