こんにちは、グループ経営ソリューション事業部の米久保です。本記事は電通総研 Advent Calendar 2025 15日目の記事です。
アーキテクト思考とは
この記事において、アーキテクト思考とはITアーキテクトが仕事をするうえで身につけておくべき思考方法、ツールやフレームワーク、その利用方法を総称するものとします。その有用性はアーキテクトの枠を超えて、他の職種にも大いに役立つものです。
アーキテクト思考と呼べるものには、今回取り上げる「雲」「弁証法」の他にも、「メンタルモデルの構築」「システム思考」「推論」「トレードオフ分析」「分割統治」などさまざまなものがあります。
対立の解消は課題解決の鍵
アーキテクトの仕事とは、上位目的を達成するための全体構想を描き、実現への道筋を計画し、その実行を主導することです。その過程では大小さまざまな問題が発生し、それらを乗り越えてゴールへ向かうために、日々課題解決が求められます。
課題解決が一筋縄ではいかないのは、相互に対立する要件や事象がしばしば存在するためです。AとBを両立させることが困難な、「あちらを立てればこちらが立たず」という状況です。英語でいうとTrade-off（トレードオフ）ですね。
このようなとき、双方のメリットとデメリットを挙げて比較評価したうえで、選択という意思決定を下すのがトレードオフ分析です。アーキテクトとして、トレードオフ分析を適切に行う技術を身につけることの重要性は言うまでもありません。が、トレードオフ分析に入る前に、一呼吸入れてクリティカル・シンキングで問いかけてみましょう。
本当にその対立は、二者択一で選択しないといけないのでしょうか？
対立を乗り越える思考法
私たちは、対立している（と思われる）二つの主張を目にしたとき、どちらかを選ばなければならない、すなわち二律背反の関係であると考えがちです。思い込み、あるいは思考のバイアスを克服するためには、それに適した思考ツールを活用するのがよいでしょう。
この記事では「雲」と「弁証法」をご紹介します。
雲
「雲」は、書籍『ザ・ゴール』で有名なエリヤフ・ゴールドラット博士の生み出したTOC思考プロセスの道具の一つです。「クラウド」「対立解消図」と呼ばれることもあります。雲では、対立関係を図に描くことで、その解消の糸口を見出します。
具体例で考えましょう。ソフトウェア開発プロセスにおいて、レビューのリードタイムや工数、レビューアの負荷はしばしば問題となります。
開発者
「レビューがなかなか返ってこない」「指摘事項の対応に時間がかかる」「レビューをもっと簡素化してほしい」
レビューア
「品質担保のためにしっかりと厳格なレビューをしなくては」「指摘すべき点が多くてどうしても時間がかかる」
対立関係にある、「レビューを厳格化したい」という主張（D）と「レビューを簡素にしたい」という主張（D'）を起点に雲を描くと、次の図のようになります。
- Dからの矢印の先には、Dを必要条件（つまり上位の目的）とする項目を描く（B）
- 同様にD'を必要条件とする項目を描く（C）
- BとCの両方を必要条件とする、共通の目標を描く（A）
雲は、対立関係は解消できるはずというスタンスを取ります。どうやって解消するのでしょうか？ まずは、DとD'が暗黙の前提としている事柄や仮定を洗い出します。
レビューを厳格化（D）
- 厳格なレビューを行うには時間がかかる
レビューを簡素化（D'）
- レビューを簡素化すればリリースサイクルの短縮が可能
これらの前提、仮定を疑ってみます。
- 厳格なレビューには必ず時間がかかるのだろうか。時間を削減する方法があるのでは？
- レビューを簡素化して品質の悪いソフトウェアをリリースしたら、問合せ対応や障害対応に時間を要して全体としてはリリースサイクルが長くなるのでは？
以上を踏まえて、たとえば以下の施策を打つことで、厳格なレビューを行い、なおかつリードタイムを短くしよう、というのが雲による対立解消のアプローチです。
- 静的解析ツールや、AIレビューを導入する
- Pull Requestのサイズを小さくする
弁証法
弁証法の歴史は古く、古代ギリシャの哲学者ソクラテスが対話を通じて真理に近づく方法として用いた問答法は、弁証法の一種とされています。現代で使われる弁証法の基礎論理を確立したのはドイツの哲学者ヘーゲル（1770年～1831年）です。
- 命題（テーゼ：正）の提示
- それと矛盾する、または否定する命題（アンチテーゼ：反）の提示
- それらを本質的に統合した命題（ジンテーゼ：合）の考案
先と同じ例を使って考えてみましょう。
テーゼ（正）
レビューを厳格に行う
アンチテーゼ（反）
レビューを簡素化する
これらを統合した、高次の解決策を考えます。そのためには、それぞれのテーゼの本質は何かを考えることが必要です。
テーゼ（正）
レビューを厳格に行うのはなぜか？ どのような価値観に基づくのか？
- 品質が重要である
- ソフトウェアの一貫性が大事である
- 良いソフトウェアを作る人、組織を育てていきたい
アンチテーゼ（反）
レビューを簡素化するのはなぜか？ どのような価値観に基づくのか？
- 顧客に素早く価値を届ける必要がある
- フィードバックループを短縮して継続的に学習し改善すべき
それぞれが大事にしている価値や目指す方向性を踏まえて、目的そのものから問い直すのが弁証法的アプローチです。
ジンテーゼ（合）
レビューの目的を再定義する：学習する組織としてのレビュー
具体的な施策としては、たとえば以下のようなアイデアが考えられるでしょう。
- 対面でレビューを行い、ペア設計／ペアプロで設計の改善やリファクタリングを行う
- 対面レビュー実施時のトランスクリプトやgit差分データを生成AIに要約させ、レビューガイドラインを更新する
- レビューガイドラインを活用して生成AIによる事前レビューを実施する
まとめ
この記事では、アーキテクト思考として「雲」と「弁証法」をご紹介しました。これらは、二律背反のトラップから逃れ、対立を解消したり、対立を乗り越えたりする方法として利用できる思考ツールです。
日々の業務でうまく活用することができれば、強力な武器となることでしょう。
執筆：@tyonekubo
（Shodoで執筆されました）
