📋 1枚で分かる結論
📖 目次
1. はじめに：アジャイルを巡る2つの誤解
ソフトウェア開発の現場では、アジャイル開発に対して両極端な誤解が存在しています。一方は「アジャイル万能論」、もう一方は「ウォーターフォール絶対論」です。本記事では、これら両方の誤解を解きほぐし、エビデンスに基づいた適切な開発アプローチを提示します。
❌ 誤解①：アジャイル万能論
これら両方の立場は、ソフトウェア開発の本質を見誤っています。現実のソフトウェア開発では、「変化は必ず起こる」という前提と、「すべての変化に対応できるわけではない」という制約の両方を受け入れる必要があります。
2. 誤解の根源：アジャイルマニフェストの正しい読み方
アジャイル開発に対する誤解の多くは、2001年に発表された「アジャイルマニフェスト」の不完全な理解に起因しています。マニフェストの原則の一つには次のように書かれています。
（意訳）要求の変更はたとえ開発の後期であっても歓迎します。アジャイルプロセスは変化を味方につけることで、お客様の競争力を引き上げます。 — Agile Manifesto, Principle 2（原文は英語、上記は意訳）[1]
この文言だけを読むと、「いつでも自由に変更できる」と解釈してしまいがちです。しかし、この原則は「変更を完全に排除するのではなく、変更に対応するプロセスを持つべきだ」という意味であり、「無制限に変更を受け入れる」という意味ではありません。
2-1. アジャイルの創始者たちの真意
InfoQの記事では、アジャイルコミュニティの著名なリーダーであるShane Hastie氏が、この誤解について明確に指摘しています。
また、同記事では次のような重要な指摘もなされています。
2-2. 「変化への対応」と「無計画」の違い
ここで明確にしておくべき重要な区別があります。
| 概念 | 正しい理解 | 誤った理解 |
|---|---|---|
| 変化への対応 | 変化が起こることを前提として、対応できる仕組みを設計しておく | 何も決めず、変化が起きたら都度対応する |
| 計画の柔軟性 | 計画は立てるが、学習に基づいて修正可能にしておく | 計画を立てない、または計画を無視してよい |
| 設計の進化 | 核となる構造は早期に確立し、詳細は段階的に決定する | 設計なしにコードを書き始め、後からすべて直す |
📚 用語ミニ辞書（本記事で使う主要用語）
3. 変更の分類：どの変更が「破り」になるのか
アジャイル開発で対応できる変更と、対応が困難な変更（「アーキテクチャ破り」）を理解するには、変更の種類を分類して考えることが重要です。以下の表は、変更のタイプごとに「後から対応できる難易度」を整理したものです。
| 変更タイプ | 具体例 | 対応難易度 | 事前設計の必要性 |
|---|---|---|---|
| 機能の詳細変更 | 画面項目の追加、バリデーションルールの変更、表示文言の修正 | 🟢 低い | 低い（リファクタリングで対応可能） |
| 業務ルールの変更 | 承認フローの段階追加、割引計算ロジックの変更 | 🟡 中程度 | 中程度（拡張ポイントの事前設計が有効） |
| 非機能要件の変更 | 性能10倍、可用性99.9%→99.999%、ゼロトラスト対応 | 🔴 高い | 高い（アーキテクチャ決定に影響） |
| ドメインモデルの根本変更 | BtoCからBtoB転換、シングルテナント→マルチテナント | 🔴 高い | 高い（データ構造全体に影響） |
| 運用・規制要件の追加 | 監査ログ強化、GDPR対応、SOC2準拠 | 🟡〜🔴 中〜高 | 中〜高（横断的関心事として影響大） |
| 契約・統合方式の変更 | REST→GraphQL、同期→非同期、外部API仕様変更 | 🔴 高い | 高い（インターフェース設計に影響） |
3-1. 「破り」の程度を理解する：極端な例から現実的な例まで
「アーキテクチャ破り」の極端な例として、「ワークフローシステムをフライトシミュレーターに作り変える」という比喩を考えてみましょう。これは明らかに非現実的な変更であり、誰もが「それは新規開発だ」と判断できます。
しかし、現実のプロジェクトで問題になるのは、「これは対応すべき変更なのか、それとも新規開発なのか」の判断が曖昧なケースです。以下に、現実によく起こる「破り」に近い変更の例を示します。
これらの変更は、「ワークフロー→フライトシミュレーター」ほど極端ではありませんが、アーキテクチャの想定範囲を超える可能性が高く、単なるリファクタリングでは対応困難なケースが多いです。
3-2. 変更の「軸」を事前に定める意味
上記の分類から分かるように、「どの種類の変更が起こりやすいか」を事前に特定し、その変更に対応できるアーキテクチャを設計しておくことが重要です。これが「変更の軸を定める」ということです。
4. 学術研究が示す「変更対応の限界」
アジャイル開発における変更対応の限界について、学術研究は重要な知見を提供しています。ここでは、特に影響力のある2つの研究を詳しく見ていきます。
4-1. Boehm & Turner の研究：「アーキテクチャ破り」問題
カーネギーメロン大学のBarry Boehm氏とRichard Turner氏は、2004年の著書「Balancing Agility and Discipline: A Guide for the Perplexed」において、アジャイル開発と計画重視の手法を実証的に比較検討しました[3]。この研究は、アジャイル開発の限界を学術的に示した先駆的な文献として広く引用されています。
著者らは、XP（エクストリームプログラミング）の「リファクタリングで設計改善を続ければ、変更コストは増大しない」という前提について検証しました。その結果、「この前提は脆弱であり、要求ストーリーが増えるほどリファクタリングに費やす労力の割合が上がった」という実証データを示しています[3]。
これは直感的にも理解できます。小規模なシステムでは、コード全体を把握している開発者がリファクタリングを効率的に行えます。しかし、システムが大きくなると、変更の影響範囲を特定すること自体が困難になり、リファクタリングのコストは規模とともに増大する傾向があります。
さらに重要なのは、Boehm氏らが「アーキテクチャ破り（architecture breakers）」と呼ぶ問題の存在です。これは、「初期のシンプル設計の決定によって予測可能な将来の変更に対応できず、リファクタリングでは手に負えない破綻を招くケース」を指します[3]。
具体的な「アーキテクチャ破り」の例として、研究では以下のような変更が挙げられています。
- 信頼性要件のエスカレーション：当初99%の可用性で設計したシステムに、99.999%の可用性が求められる
- スループット要件の劇的な変化：想定の100倍のトランザクション処理が必要になる
- リアルタイム制約の追加：バッチ処理を想定していたシステムにリアルタイム応答が求められる
- セキュリティ要件の強化：社内システムとして設計したものを外部公開する必要が生じる
「ソフトウェアにはそのアーキテクチャで柔軟に対応できる変更の範囲（設計の許容範囲）が存在し、想定範囲を超えるような大きな変更は『設計上の限界』を超えてしまう」[3]
極端な例を挙げれば、「ワークフローシステムをフライトシミュレーターに作り変える」ような方向転換は、どれだけアジャイルに開発を進めても現実的ではありません。そして、前節で示したように、現実のプロジェクトでは「性能10倍」「マルチテナント化」といった、それほど極端でなくても「破り」に近い変更が頻繁に発生します。
4-2. Breivold らの研究：アジャイルとアーキテクチャの関係
2010年のヨーロッパソフトウェアアーキテクチャカンファレンス（ECSA）で発表されたHongyu P. Breivoldらの論文「What Does Research Say About Agile and Architecture?」は、アジャイル開発とソフトウェアアーキテクチャの関係について、それまでの実証研究を体系的に調査した重要な文献です[4]。
著者らは、アジャイル手法が「アーキテクチャへの十分な配慮が欠けている」と批判される点に注目し、その批判の妥当性を検証しました。結論として、「大規模システムで初期アーキテクチャがスケールしないと後で大規模な作り直し（リワーク）につながる」という懸念が正当であることを示しています[4]。
特に注目すべきは、XPの「YAGNI（You Aren't Gonna Need It：今必要ないものは作らない）」原則に対する批判的検証です。
この研究は、アジャイルプラクティスを無批判に適用することの危険性を学術的に示しています。重要なのは、研究者らが「将来的に必要となりうる変更の方向性を見極め、それに対応できるアーキテクチャ上の備えを持つこと」の重要性を強調している点です[4]。
4-3. 学術研究のまとめ：変更対応力には限界がある
5. 業界ガイドラインに見る変更管理の原則
学術研究だけでなく、実務で広く採用されている業界ガイドラインも、アジャイル開発における変更管理について明確な指針を示しています。ここでは主要な4つのフレームワーク/ガイドラインを見ていきます。
5-1. Scrum Guide：変更のタイミングを管理する
Scrumは最も広く採用されているアジャイルフレームワークの一つです。Ken Schwaber氏とJeff Sutherland氏によって作成されたScrum Guide（2020年版）は、変更について次のように述べています[5]。
（意訳）スプリント中は、スプリントゴールを危うくするような変更は行わない — The 2020 Scrum Guide（原文は英語、上記は意訳）[5]
これは非常に重要な原則です。「アジャイルだから変更を歓迎する」という言葉が、「いつでも自由に変更できる」という意味ではないことを明確にしています。
Scrumの本質は、変更を排除することではなく、変更のタイミングを管理することにあります。これにより、開発チームは安定した期間（スプリント）で作業に集中でき、ステークホルダーも「いつ変更要求を出せば良いか」が明確になります。
5-2. SAFe：意図的な設計と創発的な進化のバランス
大規模開発向けのアジャイルフレームワークであるSAFe（Scaled Agile Framework）は、アーキテクチャについてより具体的な指針を示しています[6]。
SAFeでは、「意図的なアーキテクチャ（Intentional Architecture）」と「創発的な設計（Emergent Design）」のバランスを取ることが原則とされています[6]。
SAFeのガイドライン「Agile Architecture」には、Leanアーキテクチャの第一人者James O. Coplien氏の言葉が引用されています。
SAFeの重要なコンセプトの一つが「アーキテクチャのランウェイ（Architectural Runway）」です。
今後のイテレーションで予定される機能要求を実現できるだけのアーキテクチャ上の土台を前もって構築しておくという概念です[6]。飛行機の滑走路（runway）のように、将来の「離陸」（機能実装）のために十分な「助走距離」（アーキテクチャの準備）が必要という考え方です。
5-3. Disciplined Agile：規律あるアジャイル
PMI（Project Management Institute）が支援するDisciplined Agile（DA）は、その名称通り「規律あるアジャイル」を強調しています[8]。
DAの原則では、チームが単にアジャイルプラクティスを盲目的に適用するのではなく、ガバナンス（組織の方針）や組織上の制約を考慮し、状況に応じて最適な意思決定をすることを求めています[8]。
特に重要なのは、Disciplined Agile Delivery（DAD）における「Inceptionフェーズ」の存在です。これは、開発の最初に製品のビジョン策定や基本アーキテクチャの確立を行うフェーズであり[8]、アジャイルプロジェクトでも最初に全体構造の青写真を描くことの重要性を示しています。
5-4. Lean Software Development：決定の延期と最後の責任ある瞬間
Mary & Tom Poppendieck夫妻による「Lean Software Development」は、製造業のリーン生産方式の原則をソフトウェアに適用したものです[9]。リーンの7原則の一つに「決定の延期（Defer Commitment）」があります。
しかし、ここで重要なのは「最後の責任ある瞬間（Last Responsible Moment）」という概念です。
決定を保留してもよいのは「最後の責任ある瞬間」までであり、それを過ぎてしまうと却って悪い結果になるという点が強調されています[9]。「期限を過ぎれば決定しないこと自体が最悪の決定になる」のです。
| 決定の種類 | 推奨されるアプローチ | 理由 |
|---|---|---|
| 可逆的な決定（技術的詳細、UI設計など） | 遅く決める、必要になった時点で決定 | 情報が増えてから決定した方が良い結果になる |
| 不可逆的な決定（アーキテクチャの根幹、プラットフォーム選択など） | 慎重に検討して早めに決める | 後から変更するコストが非常に高い |
| 変化の軸となる部分（拡張ポイント、インターフェース） | 柔軟性を確保する設計を事前に行う | 将来の変更に低コストで対応できるようにする |
5-5. 業界ガイドラインのまとめ
業界標準のガイドラインはいずれも、「アジャイルだからと言って『無計画でその場しのぎに何でも変更して良い』わけではない」と述べています。
- Scrum：スプリント単位で変更タイミングを管理する
- SAFe：将来を見据えたアーキテクチャ策（Architectural Runway）を準備する
- Disciplined Agile：ガバナンスと組織の制約を考慮した意思決定を求める
- Lean：決定のタイミングに注意を払い、「最後の責任ある瞬間」を見極める
6. 実務者の知見：なぜ事前設計が必要なのか
学術研究と業界ガイドラインに続いて、ソフトウェア開発の第一線で活躍する実務者たちの知見を見ていきます。彼らの経験に基づく洞察は、なぜアジャイル開発でも事前設計が必要なのかをより具体的に理解する助けになります。
6-1. James O. Coplien：「少しの計画が大きな無駄を省く」
James O. Coplien氏は、オブジェクト指向設計とアジャイル開発の両分野で世界的に知られる技術者です。彼の著書「Lean Architecture: for Agile Software Development」（Gertrud Bjørnvig氏との共著、2010年）は、アジャイルとリーン志向のソフトウェア設計について書かれた実務書として高く評価されています[7]。
Coplien氏の主張のポイントは、「将来起こり得る変更要求の『軸』をあらかじめ見定めて、その部分には柔軟性を持たせる設計にしておくこと」です。これにより、後からの大変更にも落ち着いて対処できるようになります。
6-2. Robert C. Martin（Uncle Bob）：「アーキテクチャは決定を遅延させる」
Robert C. Martin氏（通称「Uncle Bob」）は、SOLID原則の提唱者として知られ、アジャイル開発コミュニティで最も影響力のある人物の一人です。彼の著書「Clean Architecture」（2017年）では、アーキテクチャの目的について次のように述べています[10]。
この言葉は一見矛盾しているように聞こえるかもしれません。「事前にアーキテクチャを決めることで、決定を遅延させることができる」とはどういう意味でしょうか？
Martin氏の主張を理解する鍵は、「何を決めるか」と「何を決めないか」を区別することにあります。
重要なのは、Martin氏が「大規模な事前設計」を推奨しているわけではないという点です。
6-3. Robert C. Martin：SOLID原則とOCP（開放閉鎖原則）
Martin氏の著書「Agile Software Development: Principles, Patterns, and Practices」（2002年）では、アジャイル開発における設計原則（SOLID原則）が体系的に紹介されています[11]。中でもOCP（Open-Closed Principle：開放閉鎖原則）は、変更対応の設計において核心的な役割を果たします。
これは、「将来必要となる拡張には容易に対応できるように設計し、既存の安定した部分はなるべく変更せずに済むようにする」という考え方です[11]。
6-4. Martin Fowler：「設計は死んでいない」
Martin Fowler氏は、リファクタリングの概念を広めた人物として知られ、アジャイル開発の実践において最も影響力のある技術者の一人です。2004年に発表した記事「Is Design Dead?」は、アジャイル登場当初に生じた「設計は不要になったのか？」という議論に答えたものです[12]。
Fowler氏は、アジャイル開発者に求められるスキルとして、「コードを書いている最中にも常に先々の変更を念頭に置き、今日の決定が将来変更を要することを理解して設計する」ことを挙げています[12]。
6-5. 実務者の知見のまとめ
7. アーキテクチャ設計の実践：何を固定し、何を柔軟にするか
ここまでの議論を踏まえ、実際のプロジェクトで「何を固定し、何を柔軟にするか」を決める具体的なアプローチを見ていきます。
7-1. 変更の軸を特定する
アーキテクチャ設計の第一歩は、「変更の軸」を特定することです。変更の軸とは、将来的に変化する可能性が高い方向性のことです。
| ドメイン | 典型的な変更の軸 | 設計上の対応 |
|---|---|---|
| ECサイト | 決済方法の追加、配送オプションの拡張 | 決済・配送をプラグイン構造に |
| 業務システム | 承認フローの変更、帳票フォーマットの追加 | ワークフローエンジン、テンプレートエンジンの採用 |
| SaaSプロダクト | マルチテナント対応、料金プランの追加 | テナント分離の仕組み、課金モジュールの独立 |
| データ分析基盤 | データソースの追加、分析手法の拡張 | ETLパイプラインの抽象化、分析アルゴリズムのプラグイン化 |
変更の軸を特定するための質問
- ビジネス環境の変化によって、どの機能が最も影響を受けやすいか？
- 競合他社の動向や市場トレンドから、どのような機能追加が予想されるか？
- 規制や法律の変更によって、どの部分の変更が必要になる可能性があるか？
- ユーザーからのフィードバックで、最も頻繁に言及される改善要望は何か？
- 類似システムの進化の歴史から、どのような変更パターンが見られるか？
7-2. 固定すべき部分と柔軟にすべき部分
変更の軸を特定したら、システムを「固定すべき部分」と「柔軟にすべき部分」に分類します。
- ドメインの核となる概念とその関係
- システム全体の分割方針（レイヤー、サービス境界）
- 非機能要件を満たすための基本方針（スケーラビリティ、セキュリティ）
- 外部システムとの連携方式
- データの一貫性を保証する仕組み
7-3. 境界を明確にする設計パターン
固定部分と柔軟部分を分離するために、いくつかの設計パターンが有効です。
パターン①：依存性逆転による境界の確立
Clean Architecture の核心である「依存性逆転の原則」を適用し、変化しやすい部分が安定した部分に依存するようにします。
パターン②：ストラテジーパターンによる拡張ポイント
変更の軸が明確な部分には、ストラテジーパターンを適用して拡張ポイントを設けます。
パターン③：設定駆動による振る舞いの外部化
ビジネスルールの詳細を外部設定として切り出すことで、コード変更なしにルールを変更できるようにします。
8. ケーススタディ：成功と失敗から学ぶ
理論的な議論だけでなく、実際のプロジェクトでどのような問題が発生し、どのように対処されたのかを見ることで、「何を固定し、何を柔軟にするか」の判断がより具体的に理解できます。
以下のケースは、筆者の経験および業界で報告されている典型的なパターンを基に構成した合成ケース（架空の事例）です。特定の企業やプロジェクトを指すものではありませんが、現実に頻繁に発生する問題パターンを反映しています。
8-1. 失敗事例：「アーキテクチャ破り」が発生したケース
ケースA：ECサイトの性能要件変更
状況：
あるECサイトは、当初1日あたり1,000件の注文処理を想定して設計されました。「アジャイルだから後から対応できる」という判断のもと、性能要件は深く検討されず、単一のモノリシックなアプリケーションとして構築されました。
問題の発生：
サービス開始1年後、マーケティングキャンペーンの成功により、ピーク時には1日10万件の注文が発生するようになりました。システムは深刻な性能問題を抱え、注文処理に遅延が発生し、ユーザー離れが始まりました。
対応の困難さ：
- モノリシック構造のため、特定の処理だけをスケールアウトすることが困難
- データベースが単一点となり、ボトルネックを解消できない
- 注文処理、在庫管理、決済処理が密結合しており、部分的な改善が不可能
- 結果として、システム全体の再構築が必要となり、予定外の6ヶ月の開発期間と多大なコストが発生
Boehm & Turnerの研究[3]が指摘する「スループット要件の劇的な変化」は、まさにこのケースのような状況を指しています。性能要件は「アーキテクチャ破り」を引き起こす典型的な要因であり、想定されるトラフィック規模と成長予測は、プロジェクト初期に検討すべき重要な「固定すべき」判断事項です。
ケースB：業務システムのマルチテナント化要求
状況：
ある企業が社内向け業務システムを開発しました。「まずは自社で使い、将来的にSaaS化するかもしれない」という曖昧な想定のもと、シングルテナント前提で設計が進められました。
問題の発生：
1年後、経営層から「このシステムをSaaSとして外販したい」という要求が出されました。これには複数の顧客（テナント）のデータを安全に分離し、顧客ごとの設定やカスタマイズを可能にする必要がありました。
対応の困難さ：
- データベース設計がテナント分離を全く考慮していない
- 設定値や定数がコードにハードコードされている
- 認証・認可の仕組みが単一組織前提
- 既存のコードベースの70%以上に影響が及ぶ大規模改修が必要
このケースは、「変更の軸」の特定が不十分だった例です。ビジネスの方向性として「将来的にSaaS化」の可能性が少しでもあるなら、それを変更の軸として認識し、以下の対応を取るべきでした。
- データモデルにテナントIDを最初から含める（使わなくてもコストは小さい）
- 設定値を外部化する習慣を持つ
- 認証・認可を独立したモジュールとして設計
8-2. 成功事例：適切な「変更の軸」設計
ケースC：決済方法の継続的追加
状況：
あるサブスクリプションサービスでは、当初クレジットカード決済のみをサポートしていました。しかし、「決済方法の追加」は高確率で発生する変更であると認識し、決済処理をStrategy パターンで設計していました。
変更の発生：
- コンビニ決済の追加（6ヶ月後）
- QRコード決済の追加（1年後）
- 企業向け請求書払いの追加（1年半後）
対応の容易さ：
- 各決済方法の追加は、新しいStrategyクラスの実装のみで完了
- 既存の決済処理コードには一切手を加える必要がなかった（OCP準拠）
- 各追加は2〜3スプリントで完了し、既存機能へのリグレッションなし
8-3. ケーススタディのまとめ
| 観点 | 失敗事例の共通点 | 成功事例の共通点 |
|---|---|---|
| 変更の軸の認識 | 「アジャイルだから後から対応できる」と楽観視 | 高確率で発生する変更を事前に特定 |
| アーキテクチャ設計 | 現時点の要件のみに最適化した設計 | 変更の軸に対応する拡張ポイントを事前に設計 |
| 依存関係の管理 | コンポーネント間が密結合 | 関心の分離と疎結合の維持 |
| 変更発生時のコスト | システム全体に影響、大規模改修が必要 | 影響が局所化、追加のみで対応可能 |
9. ウォーターフォール絶対論への反論
ここまで、「アジャイル万能論」の誤りを指摘してきました。しかし、本記事の目的は「ウォーターフォールに戻るべきだ」と主張することではありません。むしろ、適切なアーキテクチャ設計を行えば、ウォーターフォール型では不可能だった柔軟性を実現できることを示すことも重要です。
9-1. ウォーターフォールの本質的限界
ウォーターフォール型開発には、本質的な限界があります。
- 要件の不確実性への対応：プロジェクト初期に全ての要件を正確に把握することは、多くの場合不可能
- フィードバックの遅延：実際に動くソフトウェアを見るまで、ユーザーは自分が本当に欲しいものを理解できないことが多い
- 変更コストの増大：一般に、開発が進むほど変更コストが大きくなりやすい傾向がある（増加率は文脈依存）
- リスクの後ろ倒し：技術的なリスクや統合の問題が、プロジェクト後半まで発見されない
9-2. アジャイルが提供する価値
適切に実践されたアジャイル開発は、これらの限界を克服する手段を提供します。
9-3. 「すべてを事前に決める」ことの弊害
ウォーターフォール絶対論者がしばしば主張する「すべてを事前に決めてから開発に入るべき」というアプローチには、重大な弊害があります。
| 「すべて事前に決める」の問題 | なぜ問題なのか | アジャイルアプローチ |
|---|---|---|
| 情報不足での意思決定 | プロジェクト初期は最も情報が少ない時期であり、この時点での詳細な決定は誤りやすい | 核となる構造は早期に決め、詳細は情報が増えてから決定 |
| 変更への硬直性 | 詳細な事前計画があると、「計画通りに進めること」が目的化し、必要な変更が抵抗される | 計画は学習に基づいて継続的に更新されるものと位置づける |
| 過剰な設計 | 実際には必要にならない機能やケースまで事前に設計してしまう（YAGNI違反） | 必要になった時点で設計・実装（ただし拡張ポイントは事前に設計） |
| フィードバックの欠如 | 計画段階ではユーザーからのフィードバックを得る手段がない | 早期に動くソフトウェアを届け、実際のフィードバックに基づいて改善 |
9-4. バランスの取れたアプローチ
結論として、「すべてを事前に決める」アプローチも「何も事前に決めない」アプローチも、どちらも極端で不適切です。最適解はその中間にあります。
10. 実践ガイド：バランスの取れたアプローチ
ここまでの議論を踏まえ、実際のプロジェクトで活用できる実践的なガイドラインを示します。
10-1. プロジェクト開始時のチェックリスト
10-2. アーキテクチャ決定の記録（ADR）
重要なアーキテクチャ決定は、ADR（Architecture Decision Record）として記録しておくことを推奨します。
ADRの例：決済システムの設計
ステータス： 承認済み
コンテキスト： 将来的に複数の決済方法に対応する必要がある
決定： 決済処理をStrategy パターンで実装し、新しい決済方法を追加する際に既存コードの変更を最小化する
結果： 新しい決済方法の追加が容易になる（OCP準拠）
変更の軸との関係： 決済方法の追加は高頻度の変更の軸として特定されている
10-3. ステークホルダーとの期待値調整
アジャイル開発の成功には、ステークホルダーとの適切な期待値調整が不可欠です。
ステークホルダーへの説明に使える比喩
非技術者に「アーキテクチャの限界」を説明する際、以下の比喩が効果的です。
🏠 建物の建築の比喩：
「建物を建てる途中でも、壁の色を変えたり、部屋の家具配置を変えることは容易です。しかし、基礎が固まった後で『やはり地下室が欲しい』『10階建てを30階建てにしたい』といった変更には、大幅な追加工事や、場合によっては建て直しが必要になります。ソフトウェアも同様です。」
🚗 車のカスタマイズの比喩：
「セダンを購入した後で、シートの素材を変えたり、オーディオをアップグレードすることは可能です。しかし、『やはりトラックとして使いたい』という要求には、車を買い替えるしかありません。私たちのシステムも、想定している範囲の変更には対応できますが、システムの性質自体を変える要求には限界があります。」
10.5. よくある質問（FAQ）
アジャイル開発におけるアーキテクチャと柔軟性について、よく寄せられる質問に回答します。
Q1：「アーキテクチャを事前に決める」と「Big Upfront Design（BUFD）」は何が違うのですか？
重要な違いは「何を決めるか」と「どの程度の詳細さで決めるか」にあります。
BUFD（避けるべきアプローチ）：
- すべての機能の詳細設計を事前に行う
- 数ヶ月かけて包括的な設計ドキュメントを作成
- 実装前にすべての決定を確定させようとする
- 設計完了後は変更を受け付けない
適切な事前設計（推奨されるアプローチ）：
- システムの核となる構造と変更の軸のみを検討
- 数日〜数週間程度で概要レベルの設計を行う
- 詳細は実装時に決定し、必要に応じて修正
- 学習に基づいてアーキテクチャも継続的に改善
Robert C. Martin氏の言葉を借りれば、「数ヶ月もかけて詳細な設計図を書く必要はないが、数日程度かけてシステムの構造を熟考し、概要を図にしてみることは有益だ」[10]ということです。
Q2：変更の軸を特定できない場合はどうすればよいですか？
変更の軸が明確でない場合でも、取るべきアプローチはあります。
- 汎用的な良い設計原則に従う
変更の軸が不明でも、SOLID原則、関心の分離、疎結合といった汎用的な設計原則に従うことで、多くの変更に対応しやすくなります。
- 類似システムの進化を参考にする
同じドメインの他システムがどのような変更を経験してきたかを調査することで、自システムで起こりうる変更を予測できます。
- ステークホルダーへのヒアリング
ビジネス側に「1年後、3年後にどのような変化を予想しているか」を聞くことで、変更の軸のヒントが得られます。
- 最初はシンプルに、ただし拡張可能に
不確実性が高い場合、まずシンプルな設計で始めつつ、後から拡張しやすい構造（疎結合、明確なインターフェース）を維持します。
- 定期的な見直し
開発が進むにつれて変更パターンが見えてきます。レトロスペクティブで「予想外の変更が多い部分」を特定し、必要に応じてリファクタリングします。
Q3：ステークホルダーに「アジャイルでも何でも変更できるわけではない」と説明するにはどうすればよいですか？
前述の建物・車の比喩に加えて、以下のフレーミングも効果的です。
具体的なコミュニケーションのポイント：
- プロジェクト開始時に「想定している変更の範囲」を明示的に合意する
- 大きな変更要求が来たときは、影響範囲とコストを可視化して説明する
- 「できない」ではなく「これだけのコストがかかる」と伝える
- 代替案（段階的な対応、スコープの調整）を提示する
数値で示す例：
「この変更は、想定範囲内であれば2スプリント（4週間）で対応可能です。しかし、ご要望の内容はアーキテクチャの想定を超えているため、対応には約6ヶ月と追加予算○○万円が必要になります。段階的に対応する方法もありますが、いかがでしょうか？」
Q4：アジャイル開発でアーキテクトの役割はどう変わりますか？
アジャイル開発においても、アーキテクトの役割は重要です。ただし、その役割の性質が変化します。
従来のアーキテクト像：
- プロジェクト初期に詳細な設計を完成させる
- 設計ドキュメントを作成し、開発者に指示する
- 設計変更の承認権限を持つゲートキーパー
アジャイルにおけるアーキテクト像：
- ガイドとメンター：チームが良い設計判断をできるよう支援する
- 技術的ビジョンの番人：全体の方向性を維持しつつ、詳細はチームに委ねる
- 継続的な設計者：一度決めて終わりではなく、学習に基づいて継続的に設計を改善する
- リスク管理者：技術的リスクを特定し、対処を支援する
- チームの一員：象牙の塔にこもるのではなく、実際のコードにも関与する
Martin Fowler氏が述べるように、「優れた設計者には『将来の変化を見据えて今の設計に活かす』スキルが求められる」[12]のであり、これはアジャイルにおいても変わりません。
Q5：小規模プロジェクトでもアーキテクチャを事前に検討する必要がありますか？
プロジェクトの規模によって、必要な事前検討の深さは異なります。
小規模プロジェクト（1-3人、数ヶ月）：
- 詳細なアーキテクチャドキュメントは不要
- ただし、以下は最低限検討すべき
- 主要なコンポーネントの分割方針
- データの永続化方法
- 外部連携があればそのインターフェース
- ホワイトボードでの議論と簡単なスケッチで十分
中規模プロジェクト（4-10人、半年〜1年）：
大規模プロジェクト（10人以上、1年以上）：
- SAFeのArchitectural Runwayのような計画的な設計投資
- チーム間の依存関係管理
- サービス境界の明確な定義
- 継続的なアーキテクチャレビュー
重要なのは、プロジェクトの規模に関わらず「何を固定し、何を柔軟にするか」という視点は持つべきということです。その検討の深さと形式は規模に応じて調整します。
Q6：「YAGNI（You Aren't Gonna Need It）」と「事前のアーキテクチャ設計」は矛盾しませんか？
一見矛盾するように見えますが、適切に理解すれば両立可能です。
YAGNIの正しい理解：
- 「今必要ない具体的な機能の実装は後回しにせよ」という原則
- 推測に基づいて使われない機能を作ることへの戒め
- 対象は具体的な機能の実装
事前のアーキテクチャ設計の目的：
- 将来の変更に対応しやすい構造を作ること
- 具体的な機能ではなく、拡張ポイントを設計すること
- 対象はシステムの構造と変更可能性
両立の例：
決済システムの例で言えば、「将来PayPay決済が必要になるかもしれないので、今のうちにPayPay対応のコードを書いておこう」はYAGNI違反です。しかし、「決済方法の追加は起こりうるので、Strategyパターンで拡張可能にしておこう」はYAGNIに違反しません。後者は具体的な機能ではなく、拡張のための構造を作っているからです。
Breivoldらの研究が指摘するように、YAGNIの過度な適用は「将来の要求への備えを危うくする可能性」があります[4]。重要なのは、「具体的な機能の先行実装」と「柔軟性を持たせるための構造設計」を区別することです。
Q7：変更要求が「想定範囲内」か「想定範囲外」かを判断する基準は？
以下の質問に答えることで、判断の目安が得られます。
| 質問 | 「Yes」なら想定範囲内の可能性大 | 「No」なら想定範囲外の可能性大 |
|---|---|---|
| 既存の拡張ポイントで対応可能か？ | 新しいクラス/モジュールの追加で対応 | 既存コードの大幅修正が必要 |
| データモデルの変更は軽微か？ | カラム追加程度で済む | テーブル構造の根本変更が必要 |
| 非機能要件の変更を伴わないか？ | 性能・可用性の要件は変わらない | 性能10倍、可用性99.999%など大幅変更 |
| 影響範囲は局所的か？ | 特定のモジュール内で完結 | 複数のモジュールにまたがる |
| 類似の変更を過去に行ったか？ | 同種の変更実績がある | 前例のない種類の変更 |
判断に迷う場合は、影響範囲の調査（スパイク）を行い、実際のコストを見積もってからステークホルダーと協議することをお勧めします。
Q8：技術的負債とアーキテクチャ設計の関係は？
11. 結論：「変化と上手に付き合う」ということ
本記事では、学術研究、業界ガイドライン、実務者の知見という3つの観点から、アジャイル開発における「柔軟性」の本当の意味と限界を検討してきました。
主要な論点の要約
| 論点 | 誤解 | 正しい理解 |
|---|---|---|
| 変更対応 | いつでも自由に変更できる | アーキテクチャの許容範囲内で、適切なタイミングで対応する |
| 事前設計 | 不要、走りながら考えればよい | 変更の軸と核となる構造は事前に決め、詳細は段階的に決定する |
| リファクタリング | 何でも後から直せる | アーキテクチャ破りの変更には対応困難、コストは規模とともに増大傾向 |
| 計画 | 計画は立てない | 計画は立てるが、学習に基づいて継続的に更新する |
「アジャイル万能論」への回答
アジャイル開発は「何でも後から変更できる魔法の手法」ではありません。学術研究（Boehm & Turner[3]、Breivoldら[4]）が示すように、変更対応力にはアーキテクチャによって規定される限界があります。
業界ガイドライン（Scrum[5]、SAFe[6]、DA[8]、Lean[9]）はすべて、変更のタイミングとスコープを管理する仕組みを持ち、「無秩序に何でも変更してよい」とは述べていません。
「ウォーターフォール絶対論」への回答
一方で、「すべてを事前に決めてからでないと開発に入れない」というアプローチも適切ではありません。適切なアーキテクチャ設計を行えば、変更のコストを低く抑える範囲を大幅に広げることができます。
最終メッセージ
アジャイル開発を成功させる鍵は、「何を固定し、何を柔軟にするか」を意識的に決定することです。この決定がアーキテクチャ設計であり、その範囲内での変更をアジャイルに対応することが、持続可能な開発の道筋です。
ビジネス層と開発チームが、この「柔軟性の範囲と限界」について共通理解を持つことが、健全なプロジェクト運営の基盤となります。
参考文献
- Beck, K., et al. (2001). Manifesto for Agile Software Development. https://agilemanifesto.org/
- Hastie, S. (2013). アジャイルの柔軟性: 短所か長所か. InfoQ Japan. https://www.infoq.com/jp/news/2013/07/flexibility-agile-flaw-strength/
- Boehm, B., & Turner, R. (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley Professional. https://ptgmedia.pearsoncmg.com/images/9780321186126/samplepages/0321186125.pdf
- Breivold, H. P., Sundmark, D., Wallin, P., & Larsson, S. (2010). What Does Research Say About Agile and Architecture? Proceedings of the 5th European Conference on Software Architecture (ECSA). https://www.es.mdu.se/pdf_publications/1800.pdf
- Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. Scrum.org. https://scrumguides.org/scrum-guide.html
- Scaled Agile, Inc. (2021). Agile Architecture. Scaled Agile Framework (SAFe). https://scaledagileframework.com/agile-architecture/
- Coplien, J. O., & Bjørnvig, G. (2010). Lean Architecture: for Agile Software Development. Wiley.
- Ambler, S. W., & Lines, M. (2019). Choose Your WoW!: A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. Project Management Institute. https://www.pmi.org/disciplined-agile
- Poppendieck, M., & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit. Addison-Wesley Professional.
- Martin, R. C. (2017). Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall. https://blog.cleancoder.com/uncle-bob/2011/11/22/Clean-Architecture.html
- Martin, R. C. (2002). Agile Software Development: Principles, Patterns, and Practices. Prentice Hall.
- Fowler, M. (2004). Is Design Dead? martinfowler.com. https://martinfowler.com/articles/designDead.html
