本記事では、2025年5月14日に開催されたオンラインイベント「【技術選定を突き詰める】Online Conference 2025」内のセッション「後悔しないための技術選定とアーキテクチャ設計 ～不確実性を乗りこなすための原則～」の内容をお届けします。同セッションでは、株式会社レクターの広木大地（@hiroki_daichi）さんに、技術選定の前提となるアーキテクチャという概念をはじめ、技術選定・アーキテクチャ設計におけるポイントをお話しいただきました。ぜひ本編のアーカイブ動画とあわせてご覧ください。
広木：それでは始めさせていただきます。「後悔しないための技術選定とアーキテクチャ設計」と題しまして株式会社レクターの広木が発表させていただきます。
まず初めに自己紹介です。新卒1期で株式会社MIXIに入り、サービス執行役員本部長を務めたのち退社、株式会社レクターで技術と経営を繋ぐアドバイザリーとしていろんな会社の支援をしております。また『エンジニアリング組織論への招待』という本を書かせていただいております。
今回お話しするのは技術選定の前提となるアーキテクチャという概念の理解、技術的負債とかは何か、そしてそこを繋ぐ大きな権力の流れみたいなことを皆さんと考えていき、少し回りくどい話も含めながら説明できればと思っています。
「アーキテクチャ」という概念を理解する
そもそもアーキテクチャという言葉は何なのか。この根本理解が技術選定を考える上でも重要なポイントになると僕は思っています。アーキテクチャという言葉に対する一般的なイメージといえば、インフラの設計図のような青写真、システムの骨格とかルール技術スタック、モジュール分割、データフロー、あるいは建築基準などをイメージされるんじゃないでしょうか？
実はアーキテクチャという言葉は元々建築用語でしたが、哲学的なところにまで広がり、人間の行動様式や社会関係を規定する重要な要素になっていると言えます。建築物が人の動きを決めてるように、社会制度やテクノロジーのアーキテクチャも私達の行動や権力関係に影響を与えているのです。
ローレンス・レッシグという法学者が人々の行動を規制する4つの力として、法律、社会規範、市場、アーキテクチャというものを挙げました。このアーキテクチャの定義としていたのは、「ある選択肢を選びやすく、また同時に選びにくくするという性質を環境に与えることで、人々の行動を自発的に促す仕組み」として説明されてきました。 デジタル空間ではソフトウェアやハードウェアの技術的構造（コード）が人間の行動を制御する力として機能していると解説しています。また、アーキテクチャが持つ力を利用してメリットを最大限に引き出す活動はアーキテクティングと呼ばれています。
アーキテクチャの持つ権力の発生源
この「何かを選びやすくし、選びにくくする力」が何によって生まれるのかを別の視点から見ていきましょう。少々複雑な話になりますが、アーキテクチャの持つ力の源泉は、依存性と交換可能性の関係によるものだと捉えています。
ある選択肢を持つ側が「権力」を持っていて、持たない側が「依存」しているという状態の繋がりがあります。この選択肢を持つ側からすると別の選択肢を選べるという関係が理不尽であったり、権力関係を作っていくわけです。これをソフトウェアで考えてみると、交換可能性が低い状況、依存している側が理不尽を引き受けている状態のことを「技術的負債」。逆に交換可能性が高い、別の選択肢を持って変化に適応できるメリットがある状況を「アーキテクチャ」と定義していきます。
クルーシュテンの2012年の定義によると技術的負債というものは見える・見えないという軸と、プラスの価値・マイナスの価値の軸で4象限に分けたときに、見えないプラスの価値があるものをアーキテクチャと呼び、見えないマイナスの価値のあるものを技術的負債と呼んでいました。
良いアーキテクチャを判断する上で重要なのが「交換可能性」です。
インターフェースの抽象化：実装の交換を容易にし、特定の技術への依存度を下げます。
マイクロサービス：サービスごとの交換を可能にし、システム全体の柔軟性を高めます。
コンテナ／IaC：インスタンスやベンダーの交換を容易にし、インフラの柔軟性と効率性を向上させます。
「交換可能性」が高い設計は、システムの持続可能性や進化能力を高める良いアーキテクチャへと繋がります。
選択肢を持つ側が強者となり、持たない側は従属する関係性が生まれます。この依存関係が理不尽さや技術的負債の原因になるため、交換可能性の設計は本質的に権力の再分配を意味します。これこそがアーキテクティングの本質だと言えるでしょう。
ソフトウェアコントローラビリティと技術的負債
このように技術的負債を再定義していくと古いシステムが技術的負債というわけではないことがわかります。組織が必要な速度で交換する能力を失うことが課題であり、変化がなければそもそも技術的負債問題も存在しません。
この技術的意思決定の副作用（時間とともに実装とドメイン／ビジネス知識の差分が生じてくる状態）は常に発生しえます。問題はその間違った意思決定を修正できないことです。再設計にはこれまでの累積工数を短い工期で再構築するという組織能力が必要です。技術選定のツケを払うのは本人だけとは限りません。
実際の課題はソフトウェアコントロールアビリティという概念を導入した方がわかりやすいでしょう。ソフトウェア単独で捉えたものが技術的負債の概念であり、実際にそれを修正するにあたり、これらの様々な要因によって要求されたスピードでソフトウェアをコントロールするという能力が組織から失われている状態が問題です。
では、技術選定を考える上でのポイントは何か？起こりうる変化＝不確実性に対して組織がソフトウェア交換できることが大事です。ただ不確実性を完全に先読みすることは不可能であり、すべてを柔軟に設計しようとすると、「eval」のように何も決めないことと同義になってしまい、実用性が失われます。「何をしないのか、何をする代わりに何をしないのか」を決め、その代わり「何を容易にするのか」を同時に決める、それがアーキテクティングです。その中で不確実性の発生源を捉える必要があります。変わりうるもの、変わり得ないものは何なのか、これが考えていく上でのポイントになります。
依存が避けられないのであれば、何に依存すべきか、というのはソフトウェアの法則として存在しており、このあたりがソフトウェアを考えていく上で重要な原則になります。
技術的な意思決定には副作用がつきものですが、それは避けられません。重要なのは、抽象的な構造（ドメインモデル、つまり問題解決のための抽象的な枠組み）を先に発見しておくか、それとも後から見つけるか、という点です。
最近はこういった進化的アーキテクチャという考え方が算出されるようになっています。進化的アーキテクチャとは継続的なリファクタリングとリリースを前提に、要求への適応度が高い方向に全身的に、斬新的に変化していくという考え方です。技術的負債を適応度が低いアーキテクチャと捉え直して、適応度関数を定義して継続的に測定します。適応度が下がってきたら進化させるための組織文化を重要視し、組織自体のアーキテクチャを変えることを前提とした考え方です。
目的と手段の階層構造
変化が起きたときに素早く適応できる必要がありますよね。ただし組織能力にも限界があります。どのように良い設計を評価したらいいでしょうか？
ソフトウェアにおける抽象は、まさに「鮭も豚も、夕食のメイン素材になりうる」という例のように、特定の目的を達成するための共通性や役割に注目して再発見されるものです。これは、存在論的な分類（脊椎動物である、といった静的な特性）よりも、「何のためにその抽象が存在するのか」という目的によって形作られます。
こういった目的論的な抽象というものがソフトウェアには存在しています。目的と手段は階層構造になっていて、一般的に目的は変化しにくく、手段は変化しやすいというものが連鎖的に起こっているのです。
ペースレイヤリング
アーキテクチャを考える上で、目的と手段の代わりに変化するペースが異なる場合があることを説明するペースレイヤリングという概念を説明します。ペースレイヤリングというのは、作家・思想家であるスチュワート・ブランドが提唱した概念であり、スティーブ・ジョブズの有名な講演で話された「Stay hungly, Stay foolish」というフレーズの元ネタを考えた人物でもあります。
ペースレイヤリングとは、変化のペースが異なる階層が重なり合って構成されているとする概念です。世の中にはこのようにさまざまな階層構造が存在しており、変わりやすいものが適応力を提供し、変わりにくいものがレジリエンスをもたらすという構造にあります。
この考え方が、現在のソフトウェアのレイヤリングアーキテクチャにも適用されています。もう一つソフトウェアにおいてペースレイヤリングの概念としてよく語られるのはSoR、SoEの概念になります。
ソフトウェアにおけるペースレイヤリング
システム変化速度に応じて、以下のように捉えます。
遅い「SoR (System of Record：記録のシステム)」：データの正確性/安定性を重視する基幹システムであり、変更は慎重
速い「SoE (System of Engagement：エンゲージメントのシステム)」：UXと俊敏性を重視し、市場変化に素早く対応するユーザー接点
この変化のスピードが異なる2つの層（SoRとSoEなど）を分けて設計・開発する考え方は、バイモーダルソフトウェアやペースレイヤリングを利用したアーキテクチャとなります。
要求のオニオンモデル
さらに変化をもたらす原因や考え方として、「要求のオニオンモデル」というものもあります。
これは、ソフトウェアの要求というのは多層的な外部制約の中で定義されるという考え方です。中心に至るまでに、階層が深くなればなるほど具体的なものとなります。しかし実は元々の要求は社会や環境からきており、そこに対してサービスを提供していくという概念です。各層からの制約が段階的に具体化され、要求が作られていくのがこのモデルです。
ビジネスの階層構造
ビジネスにも目的と手段の階層構造があります。目的のために手段は常に変化しえます。ミッション、ビジョン、戦略、戦術、施策などもそうですが、目的と手段の階層構造をビジネスアーキテクチャと呼びます。
ビジネスには目的と手段をベースとした階層構造がありますが、ソフトウェア要求は社会、法律、ビジネス、業務の要に多層的に影響を与える構造にあります。社会や法律、業務、顧客にはそれぞれ異なる変化のペースがあり、構造物はそれに対応した堅牢性と適用性が求められます。ソフトウェアは目的論的な抽象構造で、より安定した抽象に依存し、より上位の目的に対して手段を交換できる必要があります。
社会構造とビジネスというものが、不確実性の波を引き起こします。アーキテクチャは、プリズム、あるいはフーリエ変換のように周波数に分解してその周波数成分ごとに定義された構造になっているわけです。この変化に相当する部分を交換できる必要があります。つまりビジネスという不確実性の波に柔軟に応じていくことが、望ましいアーキテクチャなのです。
こういった原理を踏まえ、アーキテクチャ設計や技術選定で何を考えるかというこれまでの抽象的な議論をもとに、より具体的な部分を考えていきます。そこでソフトウェアコントロールラビリティの不等式という概念を解説します。
ソフトウェアコントローラビリティの不等式
ソフトウェアコントローラビリティとは、組織がソフトウェアを交換できるかどうかということが重要だという考え方です。ソフトウェアのライフサイクルやサイズ、依存性、交換リスク等を掛け合わせたものが、組織ケイパビリティを下回る限りそのリスクは許容できます。しかし組織ケイパビリティを上回ってしまった場合は、意思決定することできないという方程式になります。サイズが大きく寿命が長いほど重要な意思決定になってきます。
『Making Software』という本に掲載された論文では、技術選定やアーキテクチャ設計にどれくらいの時間をかけるべきかを分析しています。これは、ソフトウェアのサイズが大きくなるにつれて発生する手戻りコストと、アーキテクチャやリスク解決に費やした時間のバランスを取りながら、最適な点（スイートスポット）を見つけることを目指すものです。ただライフサイクルを読むことは難しく、PMFを達成するまで試行錯誤が必要であり、PMF後にプロトタイプを再構築しようとしても「セカンドシステム症候群」となり、実際には困難なことが多いです。
以前書籍でも書きましたが、「マイクロサービス化のスイートスポット」のように、再構築するのであれば期間を設定し、タイミングを見極める必要があります。
またモジュールの依存性についても依存性の高いものほど高い組織ケイパビリティが求められます。ではどこで責任を分けるべきなのかというと、APIやワークフローのプロトコルで区切られているか、多くのシステムから使われる共通部品なのかそうでないのか、ライブラリなのかフレームワークなのか、そしてそもそも依存性を分解できるのか、といった問いに集約されます。
依存性の分析としてフレームワークとライブラリの違いを評価すると、自分たちのユーザーコードをどちらが呼び出すかという点が異なることがわかります。
ライブラリ: ユーザーが書いたコード（ユーザーコード）がライブラリを呼び出します。この場合、システム全体のアーキテクチャへの依存性は比較的低いと言えます。
フレームワーク: フレームワーク側がユーザーコードを呼び出す構造になっており、ユーザーコード全体がフレームワークに依存している状態になるため、非常に依存性が高いと言えます。
このように、ライブラリとフレームワークの技術選定では依存性の違いからフレームワークの技術選定を慎重に行う必要があります。
依存性の分析の中で「バッテリー同梱」と呼ばれるフルスタック型のフレームワークのようにすぐ使えるものは比較的依存性が高いです。一方、UNIX哲学に基づき一つのことをうまくやるものは依存性は低いが常にオーケストレーションが必要となります。どちらを選ぶかは重要です。OSSのコミュニティサイズでは前者の方が構築しやすいですが、後者の方が交換可能性は高いと言えます。 クラウドサービスにも同様に依存性があります。IaaS、コンテナ仮想化、k8sなどはある程度標準化されコモディティ化しているものは依存性は低いです。反対に独自のインターフェースにアプリケーション依存してるようなPaaSやIDaaSは依存性が高くなります。強烈な通貨安、関税、Amazonライバル企業からの買収、経済安保などクラウドマイグレーションやリパトリエーションの可能性はゼロではありません。
交換リスクの分析も交換・頻度の交換とか修繕頻度はどのぐらいか、ビジネスアーキテクチャのどこに位置してるいるか、要求のオニオンモデルのどこから変更要請されるか、技術のマクロトレンドのどこから変更を要請されるか、エンドオブライフのタイミングはいつ来るのか、どこまでサポートされるのか、上記のことを分析する必要があります。
ビジネスアーキテクチャを理解するために、そしてこのステークホルダーインタビューというのも重要なプラクティスです。「なぜ、いつ、どのように」という目的の階層を掘り下げたり、ポイントビューのテンプレートをつくり観点を文章化します。組織ごとにいろんな言語化のコストが異なるので、自分たちからヒアリングを行います。ドメインエキスパートだとしても言語化するというのは苦手な場合が多く、ヒアリングを工夫したり自らも理解していく必要があります。
不確実性ストーミングというプラクティスもリスクの洗い出しに有効です。リスクの発生頻度と影響度で4象限でプロットし直すと、リスクソースとなるものをどんどん張り出していきます。それを分析することで対策を検討するストーミングを行います。
交換リスクの分析では、システムを交換する理由と依存性が一致しているかを確認することが重要です。例えば、「システムが古くなったからUIを全て書き換える」というケースでは、交換する理由と依存性との間に、明確な一致が見られないことがあります。このような場合、大きなメリットが得られにくい意思決定になってしまいますよね。
ライフサイクル×依存性×交換リスク＜組織ケイパビリティ
これまで、ライフサイクル、依存性、交換リスクといったソフトウェア側の要素について見てきました。次に組織のケイパビリティについてです。組織のケイパビリティには自社とコミュニティの2つがあります。
自社ケイパビリティ:自分たちでソフトウェア交換・管理できる能力を指します。
- 技術スタックに対する社内の知識・経験のレベル
- チームの規模と専門性の分布
- 開発・運用プロセスは成熟度
- 技術的負債への対応と組織文化 これらの要素が揃っているほど、自社でソフトウェアをコントロールする能力が高いと言えます。
コミュニティのケイパビリティ： OSSや外部サービス等といったコミュニティがライブラリやサービスを維持発展できる能力を指します。
- コミュニティの規模
- 提供主体の社数
- コントリビューターの活動状況
- 開発ロードマップの公開有無
- 採用状況と求人これらの要素を評価することで、そのソフトウェアが長期的に維持・発展していく可能性を判断できます。
コミュニティのケイパビリティを計るガバナンス要素として、やはり重力圏を持つエコシステムが強いです。周辺ツールセットの充実や導入コストの低さ、エコシステムを最も大きいものに引力が生まれ、そこに人が引き寄せられてコミュニティサイズがさらに大きくなり、技術開発が進みます。「ロードマップなきリリースは渡し舟なき川渡り」とも表現できます。定期リリースと公開ロードマップがないプロジェクトは、開発者を足止めしたり、コミュニティのガバナンス要素が弱いと判断されます。「資金は炎、コミュニティ酸素」という言葉もあります。企業の後ろ盾はちゃんと火を灯してくれますが、多様なコントリビューターがいなければ、物は長く持ちません。また求人票が消えた技術というのも、緩やかなEOL宣言みたいなものです。その技術に関する求人状況を把握し準備することが必要です。
一方で気に入ったサービスとかソフトウェアがあれば、コミュニティに積極的に参加して自ら盛り上げていくことも重要です。自分が良いなと思ったものであれば自身の参加することでコミュニティとしてのガバナンスが効く形に変え、維持されることを目指していくのが良いのではないのでしょうか。ですから技術選定／アーキテクチャ設計というのは難しいですが、失敗をリカバリできる体制やチーム、組織そしてコミュニティを作り上げることが最も重要なポイントになります。
生成AIで何が変わるか
これまでの考えを踏まえ、生成AIエージェントの時代でどのように変化していくのかを考え、いくつか関連する事例を整理しました。
変更リスクの発生源を捉えた設計
そもそもの変更リスクの発生源を捉えた設計というのが必要です。例えば省令とか法改正とか、公式なドキュメントというのは、その公式なドキュメントから引っ張ってきて計算ロジックを自動生成してアップデートすると変更リスクの発生源自体を捉えた状態からスタートできます。
エージェント型のAI駆動型のインターフェース
外部サービスにAPI変更があっても目的さえ伝えておけば自動実行してくれるという、今のA2AやMCPとかの考え方に近しいものです。ライブラリを単なるAPIコールとして渡すのではなく目的さえ伝えておけばアップデートされ自動的に実行できるでしょう。
自動アップデート付きフレームワーク
また最近増えつつあるのはAIがバッテリーとして入っていって、自動アップデートやエージェントベースを構築するものです。フレームワークの中にもそういった機能を持ったエージェント機能が増えてきています。
この目的と手段の梯子の手段の部分から順番に自動化されてくるような形でアーキテクチャは変更されてくるのだと考えます。
まとめになりますが、アーキテクチャは社会を取り巻く、目に見えない力を生み出す構造です。 このアーキテクチャを構成する様々な側面として、ビジネスモデル、組織構造、プロジェクト、そしてアーキテクチャがあります。実際の問題はソフトウェア自体が古くなる技術的負債そのものではなくて、ソフトウェアコントロールアビリティの喪失が問題でした。技術選定／アーキテクチャ設計は非常に難しいですが、誤った選択をしたと思ったらリカバリーできる組織能力や体制を整えることが重要です。
意思決定の経験を正しく学び、それを将来に繋げ、未来のチームメイトに配慮しましょう。これで僕からの講演は以上です。ご清聴ありがとうございました。
アーカイブ動画
イベント本編は、アーカイブ動画を公開しています。あわせてご覧ください。
▼動画はこちら
後悔しないための技術選定とアーキテクチャ設計 ～不確実性を乗りこなすための原則～
※動画の視聴にはFindyへのログインが必要です。