アーキテクチャを設計するといふこと 2025年版

アーキテクチャを設計すると いふこと 2025年版

About Me • 米久保 剛 (よねくぼ たけし) • ITアーキテクト / プロダクト開発 • X: @tyonekubo

I. アーキテクチャの設計（基本）

アーキテクトと何か • ITスキル標準 – ITアーキテクト • ビジネス及びＩＴ上の課題を分析し、ソリューションを構成する情報 システム化要件として再構成する。… ITスキル標準 V3 https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itss/download_v3_2011.html • 情報処理技術者試験 – システムアーキテクト（SA） • 情報システム戦略を具体化するための情報システムの構造の設計や、 開発に必要となる要件の定義、システム方式の設計及び情報システム を開発する業務に従事し、次の役割を主導的に果たすとともに、下位 者を指導する。… システムアーキテクト試験 https://www.ipa.go.jp/shiken/kubun/sa.html

• https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itss/download_v3_2011.html
• https://www.ipa.go.jp/shiken/kubun/sa.html

アーキテクトとは何か • アプリケーションアーキテクト • インテグレーションアーキテクト • インフラストラクチャアーキテクト • ソリューションアーキテクト • ビジネスアーキテクト • 建築家（アーキテクト）

アーキテクトとは何か アーキテクチャを設計する人

アーキテクトとは何か アーキテクチャを設計する人

アーキテクチャ 古代ギリシア語 architectonice : architectonice techne の省略であり、 architechton の techne を意味する。 architechton : 始原、原理、首位を意味する arche と、職人を意 味する techthon との合成語。 “ 建築は、たんなる職人的な技術だけでなく、原理的知識をもち、 職人たちの上に立ち、諸技術をすべ、制作を企画し指導しうる者 の技術として理解されていた。 （中略）テクネーという語は、狭義の技術だけでなく、制作（ポ イエーシス）一般を意味していたのである。 出典：柄谷行人『隠喩としての建築』

アーキテクチャ “ 要するに「Architecture」の語源には、以下の3つの要素が含ま れていることになります。 1. 「始原、原理、首位」を意味する要素 2. 「職人」を意味する要素 3. 「制作」一般を意味する要素 （中略）「原理」という概念が含まれているということです。本 書のアーキテクトの中心をなす「抽象」という概念が、 「Architecture」には、既に含まれていたということです 出典：細谷功、坂田幸樹『アーキテクト思考』

アーキテクチャ ソ フ ト 、 コ ト 、 抽 象 制作の ための原理 建築と Architecture のギャップ ↓ 「アーキテク チャー」 “Architecture” ハ ｜ ド 、 モ ノ 、 具 体 「建築」 日本語圏 英語圏 出典：細谷功、坂田幸樹『アーキテクト思考』図2-02

アーキテクチャ （ソフトウェアにおける）アーキテクチャの定義 “ 環境におけるシステムの基本的な概念や特性が、 その要素や関係、および設計と進化の原則に具体化されたもの 出典：ISO/IEF/IEEE 42010:2011 （日本語訳は発表者による）

アーキテクトとは何か アーキテクチャを設計する人

設計（デザイン） ラテン語 designare : 「線を引く」「記号に表す」「指し示す」 中世以降、図として描画する、計画する、というように意味が拡 張された

設計（デザイン） “ design の語源を辿ると、この言葉の本質が見えてきます： 1. 印をつける行為：最初に明確な意図や目印を設定すること 2. 指し示す行為：方向性や目的を明確にすること 3. 視覚化する行為：抽象的なアイデアを具体的な形にすること 出典：Claude Opus 4.1

設計（デザイン） 時代の変遷とともに「デザイン」の概念は拡張され続けている。 • 人間中心設計（HCD） • デザイン思考 • ユーザーエクスペリエンスデザイン • サービスデザイン、etc （広義の）デザイン : 課題解決のための、創造的な取り組み

アーキテクチャ設計とは アーキテクチャ 制作のための原理 設計 課題解決のための創造的取り組み 意図、目的、方向性を示し、アイデアを形にする →ではなぜ、アーキテクチャを設計するのか？

アーキテクチャ不在だと？ （例1）部分最適化、サイロ化されたシステム （例2）巨大な泥団子と化したレガシーシステム 欠如しているものは何？ ✓全体的視点 ✓長期的視点 ✓秩序 ✓戦略 ✓方針 これらをもたらすものが アーキテクチャ

（例）コード行数カウンター • ディレクトリ配下のソースコードの行数をカウントする JavaScriptのCUIプログラム • 言語ごとにファイル数、合計行数、コード行数、空行数、コメ ント行数をカウントして表形式で結果を出力する

（例）コード行数カウンター Claude Code（モデルはOpus 4.1）に雑な指示を与えて生成。 > nodeで実行できるコード行数カウンタを実装して。 > 言語別にファイル数やコード行数を出力する。 メインプログラム（index.js）のみの一枚岩のプログラムであり、 動作はするがアーキテクチャと呼べるものはない。 index.js 課題 • プログラムが長く読みづらい • ベタ書きが多く拡張性が低い • テストコードが存在しない

（例）コード行数カウンター改善版 詳細な要求を文書で明確に示し、生成させる。 spec.md ## 基本仕様 - 指定されたディレクトリ以下のコード行数をカウントする。 - カウント対象のファイルは拡張子で判別する。 - `.yaml` と `.yml` のように、同じ言語であっても複数の拡張子が存在す る場合があるが、同じ言語としてまとめてカウントする。 ・・・ ## 保守性 - 単一責任原則に従い、適切な単位にモジュール分割を行う。 - `SOLID`、`DRY`、`KISS`、`Tell Don't Ask`などの設計原則に従う。 - 可読性の高いコードを書く。 ## テストコード - 分割されたコンポーネント単位にJestでテストコードを実装する。 - t-wadaのテスト駆動開発のやり方に従う。 - テストコードでモックを多用しない。そのためにテスト容易性を考慮し た設計を行う。 ・・・

（例）コード行数カウンター改善版 構造化され、 アーキテクチャが出現。

アーキテクチャ設計により得られたもの 苦痛 価値 わかりづらい 理解しやすさ 修正しづらい 修正しやすさ テストしづらい テストしやすさ index.js

品質特性 • ユーザーが求める機能要求を満たすことが最重要 • その上で、重要視される品質特性（非機能要求）も大事 機能要求 品質特性 理解容易性 コード行数を カウントできる 修正容易性 テスト容易性

機能要求と品質特性 ## 基本仕様 - 指定されたディレクトリ以下のコード行数をカウントする。 - カウント対象のファイルは拡張子で判別する。 - `.yaml` と `.yml` のように、同じ言語であっても複数の拡張子が存在す る場合があるが、同じ言語としてまとめてカウントする。 ・・・ ## 保守性 - 単一責任原則に従い、適切な単位にモジュール分割を行う。 - `SOLID`、`DRY`、`KISS`、`Tell Don't Ask`などの設計原則に従う。 - 可読性の高いコードを書く。 ## テストコード - 分割されたコンポーネント単位にJestでテストコードを実装する。 - t-wadaのテスト駆動開発のやり方に従う。 - テストコードでモックを多用しない。そのためにテスト容易性を考慮し た設計を行う。 ・・・ 機能要求 品質特性

品質特性はどこから来るか • 顧客／ユーザーがおかれた文脈や、ニーズによって決まる 一回使うだけ 動けばOK index.js 機能適合性 （のみ） よく使うツール なので利用し続 けたい 理解容易性 修正容易性 テスト容易性

品質特性次第で解法は変わる コード行数カウンターに以下のようなニーズがあったら？ • 複数リポジトリに分散した大規模コードベースを対象に • 短時間でコード行数を一括集計したい 品質特性 アーキテクチャ Map スケーラビリティ Input 時間効率性 Map Reduce Map Map/Reduceパターンの並行処理 Output

アーキテクチャ設計とは？ • ソフトウェアが役に立つためには、機能要求を満たすことに加 えて、達成すべき目標（品質特性）がある • これらの品質特性の達成は、技術的な難易度の高さやトレード オフの発生によって、一筋縄ではいかない • 様々な課題を克服し、ソフトウェアを制作する上での原理や方 針を定めていくことがアーキテクチャ設計の本質である

アーキテクチャ設計の流れ 出典：『アーキテクトの教科書』図3.1.1

アーキテクチャの定義 “ 環境におけるシステムの基本的な概念や特性が、 その要素や関係、および設計と進化の原則に具体化されたもの 目的 根拠 実現方法 制作指針

II. アーキテクチャの設計（応用）

アーキテクティング 一連のアクティビティ＝アーキテクティング architect [名詞] : architectureを設計する人 architect [動詞] : architectureを設計する architecting [動名詞] : architectureを設計する行為

アーキテクティング（概念モデル） 記述する 上位目的 品質特性 * * 達成する 達成する 能力を与える ソフトウェア アーキテクチャ 実現する アーキテクティング

アーキテクチャ設計の意義（一般化） アーキテクチャ システム（系）によって上位目的を達成するために、 システムに必要な能力を与える アーキテクトの仕事（＝アーキテクティング）は、ソフト ウェアアーキテクチャに限定せず、拡張することができる

“カチ”の設計 • アーキテクトは「価値」と「勝ち」を設計する CodeZipe エンジニアキャリア図鑑 https://codezine.jp/article/detail/21816

• https://codezine.jp/article/detail/21816

価値を設計する 正しいもの を 正しく作る 正しいものを作るには？ ✓ビジネスサイドとの共創 ✓顧客視点・ユーザー視点 ✓仮説検証型アプローチ 正しく作るには？ ✓ソフトウェアエンジニアリング ✓開発プロセス ✓組織設計、チームビルディング

勝ちを設計する 勝ち筋を見出し、戦略を立てる 戦略を立てるとは？ ✓ゴールを明確にし、 ✓取りにいくもの／いかないものを決め ✓資源の配分を行う https://www.docswell.com/s/tyonekubo/ZXEW33-2024-10-26-124043

• https://www.docswell.com/s/tyonekubo/ZXEW33-2024-10-26-124043

DDDの戦略的設計 ✓問題空間におけるサブドメインと、 解決空間における境界づけられた コンテキストとを、なるべく一致 させる ✓サブドメインの種類（コア／支援 ／汎用）に応じて実現手段を使い 分ける 例） コアドメイン：優秀な人材を集中投入して内製 支援サブドメイン：ローコードツールの活用 汎用サブドメイン：SaaSの利用 出典：『実践ドメイン駆動設計』図2-2

実現手段の使い分け：AI活用 • AIに委託 or AIと伴走 出典： t-wada『AI時代のソフトウェア開発を考える』 https://speakerdeck.com/twada/agentic-software-engineering-findy-2025-07-edition

• https://speakerdeck.com/twada/agentic-software-engineering-findy-2025-07-edition

2-6-2の法則（働きアリの法則） • 集団におけるパフォーマンスの経験則 • 2割の人は良いパフォーマンス • 6割の人は平均的なパフォーマンス • 2割の人は悪いパフォーマンス • どんな組織にも、一定数、パフォーマンスの悪い人は存在する • 残酷だが、受け入れなければならない現実 • リスクマネジメントが必要 良 リスク：他の人の サポートに翻弄 平均 悪 リスク：他の人の 足を引っ張る

2-6-2の法則と生成AI • 元々のパフォーマンスと、生成AIの活用効率との間には、正の 相関があるように見える（経験則） • パフォーマンス格差は広がるリスクが高い • AI駆動開発を軌道に乗せるための戦略が必要 良 平均 イネイブラとして、 AIリテラシーの底上 げ 悪 AIに代替

社内政治 勝ち筋を見出すために、ポジティブな意味での社内政治は重要。 “ 摩擦を軽減し組織全体の成長へと繋げる行為が社内政治 出典：nakamichi『プロジェクトにおける政治について』 https://speakerdeck.com/ichimichi/puroziekutoniokeruzheng-zhi-nituite

• https://speakerdeck.com/ichimichi/puroziekutoniokeruzheng-zhi-nituite

社内政治 具体的にどうするの？ →アーキテクトなりの社内政治のやり方： • ステークホルダーマップを作る • それぞれの立場や優先事項を把握し、行動原理の仮説を立てる • ナラティブアプローチによる「対話」 ※ナラティブ（narative）： 物語を生み出す「解釈の仕組み」あるいは「世界観」

III. アーキテクトとして成長するには

アーキテクトの人材像 • アーキテクティングを中心の柱に据え、他の柱を立てていく • 土台となるソフトウェアエンジニアリングも重要 • 業務知識やソフトスキルも重要 出典：『アーキテクトの教科書』図6.1.1

アーキテクトとしての技術力の向上 『アーキテクトの教科書』の使い方 設計原則・パターンから 品質保証まで幅広く学ぶ 全体感を整理 して俯瞰する 初学者 専門的な書籍で 深掘りする 中級

アーキテクチャは特殊解 一般解としてのアーキテクチャ 抽出、抽象 アーキテクチャスタイル アーキテクチャパターン 抽象 特定の状況に 知識を適用 具体 評価 実例としてのアーキテクチャ 特殊解としてのアーキテクチャ

アーキテクチャの学び方 『アーキテク トの教科書』 2〜4章で学ぶ 経験知 ①自らの経験を通して学ぶ ②他者の経験を見聞きして学ぶ

ソフトスキル 技術力と同じくらい重要なのがソフトスキル。 ソフトスキルが伴ってこそ、ビジネスに技術で貢献できる。 出典：『アーキテクトの教科書』図6.1.4

リーダーシップ “リーダーシップとは、自分に求められた役割と責務を理解し、正 しいゴールを設定して主体的に行動する意志のことです。 出典：『アーキテクトの教科書』 組織の一人ひとりがリーダーシップを持って自律的に行動するに は、「内発的動機づけ」が重要 →内発的動機づけのために何が必要？ ✓組織のWHY ✓共通のゴール ✓ナラティブ

思考力 アーキテクトが鍛えておくとよい思考方法： • 具体と抽象 • 推論 • メンタルモデル • 仮説思考 • クリティカルシンキング／ラテラルシンキング • アナロジー思考 • TOC（制約理論）、ECRS …など

具体と抽象 • 最も重要な基礎思考能力 • 「具体と抽象スライダー」で抽象度を適切にコントロールでき るようになる • 実例による範囲の特定（外延）→ 本質理解と概念定義（内包） A Aとはxxxという共通の 性質を持つものである

具体と抽象 • 分類、パターン化 例）「具体と抽象を行き来する」って抽象的だなと疑問を持つ →具体化して考えてみる →分類、整理するとパターンが見えてくる →具体と抽象の行き来パターン： 1. 問題解決パターン 2. 一般化パターン 3. コンセプトの転用パターン 4. 要約・詳細パターン https://note.com/yonekubo/n/n4fe61173fe15

• https://note.com/yonekubo/n/n4fe61173fe15

推論 3つの推論技術を駆使できるようになる • 演繹法 • いわゆる三段論法（アリストテレス） • 前提知識に状況を当てはめることで、結論を導き出す • 帰納法 • 事例の観察を通して、共通のルールを炙り出す（一般化） • アブダクション • 「結果」をうまく説明できる「仮説」を立てる推論 • 逆向き推論（レトロダクション） 説明仮説 アブダクション 結果 もし{説明仮説}が前提として 成り立つと仮定したら、{結 果}が起こるのも尤もだ →故に{説明仮説}は真である

メンタルモデル 道具の動作原理やメカニズムについて、心の中に構築するモデル ※あくまで「モデル」なので、正確である必要はない 例）LLMを関数として捉える →可変長引数（トークン）の与え方により振る舞いを制御可能 https://zenn.dev/yonekubo/books/c47eb828fd972d

• https://zenn.dev/yonekubo/books/c47eb828fd972d

思考力（推論）の活用例 例）AIエージェントが生成するコードの精度を向上させるには？ まずは使いたおして、具体事例（経験）を収集する。 事例A 事例B 観察 プロンプトにコー ドサンプルが含ま れていると精度が 高いようだね 事例C 帰納法による知識の獲得 生成されるコードの精度を上げるに は、プロンプトにコードサンプルを 含めるとよい プロンプトエンジニアリングにおい て実例によるヒントは効果がある （One-shot/Few-shot） コード生成もLLMなので、プロン プトエンジニリングが適用できる 演繹法による結果予測 生成されるコードの精度を上げるに は、プロンプトにコードサンプルを 含めるとよい

思考力（推論）の活用 例）AIエージェントが生成するコードの精度を向上させるには？ コンテキストに与えて いる情報量が多すぎ て、効果が薄まってい るとしたら？ 事例A （疑問）事例Dでは AIが言うことを聞 かず、ハルシネー ションを起こすの はなぜだろう？ 事例B 事例C 事例D 観察 ？ 情報量が多 過ぎると効 果が薄まる 生成する コードの精 度が下がる 実験・観察に より仮説を検 証（帰納法） 結果 アブダクションによる問題解決 ✓ コンテキストに含める情報の細分化 ✓ 重要なルールの繰り返しや強調

まとめ

• 価値を生み出すソフトウェアを開発するために、 制作の原理たるアーキテクチャを定めることが重 要 • アーキテクトは、システム（系）が上位目的を達 成することに主体的に関わり、価値と勝ちを設計 する活動を担う • アーキテクトとして活躍するには幅広い知識・経 験・技能が必要となるが、思考力を鍛えることは レバレッジが効く

参考書籍リスト # タイトル 著者 出版社・出版年 1 アーキテクトの教科書 価値を生むソフトウェアのアーキ テクチャ構築 米久保 剛 翔泳社（2024） 2 隠喩としての建築 柄谷 行人 講談社（1989） 3 構想力が劇的に高まる アーキテクト思考――具体と抽象 を行き来する問題発見・解決の新技法 細谷 功、坂田 幸樹 ダイヤモンド社（2021） 4 実践ドメイン駆動設計 ヴォーン・ヴァーノン 翔泳社（2015） 5 他者と働く 「わかりあえなさ」から始める組織論 宇多川 元一 NewsPicksパブリッシング（2019） 6 モチベーション3.0 持続する「やる気!」をいかに引き出 すか ダニエル・ピンク 講談社（2010） 7 新装版 アブダクション 仮説と発見の論理 米盛 裕二 勁草書房（2024）