「アーキテクチャ」という言葉をやめる試み
「アーキテクチャ」はとても重要です。しかしながら「アーキテクチャ」という言葉は多義的で、指す範囲が人やコンテキストによって大きく変わります。このことはあまり問題視されていないように思いますが、例えば「新しいプロジェクトの『アーキテクチャ』設計しといて」といったコミュニケーションが行われたとき、すれ違いによる大事故が発生する可能性を秘めているのです。
「アーキテクチャ」が引き起こすすれ違い
「アーキテクチャ」が指す範囲の広さは、コミュニケーションにおいて深刻な摩擦を生む可能性があります。指示を出した側は、クラウド構成やデータベースの選定といったインフラストラクチャ・アーキテクチャの設計を意図していたかもしれません。一方、指示を受けた側は、ドメイン駆動設計（DDD）やクリーンアーキテクチャのようなアプリケーションの内部構造の設計を始めたかもしれません。
どちらも「アーキテクチャ」ではありますが、このすれ違いは手戻りやスケジュールの遅延を引き起こします。より深刻なのは、互いに「なぜ、こんな基本的なことを理解してくれないんだ」と 不信感 を抱いてしまうことです。この問題は、エンジニア間の暗黙知に頼った、曖昧な言葉の使用が原因で起こります。（これで最近わたしは信用を1うしなった…気がする）
「アーキテクチャ」をより具体的な言葉に置き換える
このコミュニケーションの問題を解決するには、「アーキテクチャ」という包括的な言葉を避け、より具体的な言葉で話すことをルール化することが有効です。以下に示すように、話す内容の範囲に応じて言葉を使い分けることで、関係者間の認識を一致させることができます。
- システム全体・組織レベルの設計
企業全体のIT戦略や、複数のシステムにまたがるような大きな設計について話す場合は、以下のような言葉を使います。
「ソリューション設計」
「システム全体の構成」
例：
曖昧な指示:「このサービスのアーキテクチャをどうするか話し合いたい。」
具体的な指示:「マイクロサービス間を疎結合にするためのソリューション設計について話し合いたい。」 - インフラ・基盤の設計
クラウド構成やネットワーク、ミドルウェアなど、アプリケーションを動かす基盤について話す場合は、以下のような言葉が適しています。
「インフラ構成」
「クラウド・インフラストラクチャの設計」
例：
曖昧な指示:「この機能のアーキテクチャを考えてほしい。」
具体的な指示:「この新機能のために、AWS上でのインフラ構成を考えてほしい。ECSとLambdaのどちらを使うか決める必要がある。」 - アプリケーション内部の設計
単一のアプリケーション内部の構造や、コードの設計方針について話す場合は、以下のような言葉を使います。
「アプリケーションの内部設計」
「ドメイン設計」
「パッケージ構造」
例：
曖昧な指示:「この機能のアーキテクチャレビューをお願いします。」
具体的な指示:「この新機能のアプリケーション内部設計（特に、ドメインモデルと依存関係）についてレビューをお願いします。」 - 重要な技術的決定
特定の技術要素の選定や開発プロセスの方針など、システム全体に影響を及ぼす決定について話す場合は、以下のような言葉が有効です。
「技術選定の方針」
「デプロイメント戦略」
「データ設計」
例：
曖昧な指示:「このプロジェクトのアーキテクチャを議論しよう。」
具体的な指示:「このプロジェクトで、RDBとNoSQLのどちらを使うべきかというデータ設計について議論しよう。」
おわりに
「アーキテクチャ」という言葉を意図的に使わないようにするだけで、チーム内・チーム間のコミュニケーションは改善します。この小さな習慣が、無用なすれ違いを減らし、よりスムーズで効率的な開発へとつながります。
副次的な効果として、「アーキテクチャ」という言葉を禁止すると、ほかの同様の広義的な言葉に敏感になり他のコミュニケーションでも明瞭な意味を持つ言葉を使うようになったり、ゆるふわで考慮漏れが多かった「アーキテクチャ設計」が要素が洗い出されて網羅度があがったりしてうれしかったです。
Discussion