本編に入る前にクイズ
Q. 以下の技術参考書のうち、「アーキテクチャ」について、最もページをさいている書籍はどれでしょう。
正解は・・・・ 「Design It!」 です。
この本の副題は 「プログラマーのためのアーキテクティング入門」です。「プログラミング」と「デザイン」がどのようなかかわりがあるのでしょうか。イメージしながら、読み進めてみましょう。
本編
業務アプリケーションのソースコードを書くとき、よく耳にする単語の1つがアーキテクチャです。
英単語のarchitecture（建築術、建築様式、建物、構造など）から由来していると思いますが、プログラミングの文脈では、どんな意味なのでしょうか。
アーキテクチャを正しく理解し、プログラミングスキルを向上するのが、この記事のゴールです。
この記事の目次
- アプリケーションアーキテクチャ
- アプリケーションアーキテクチャパターン
- アプリケーションアーキテクト
事前のおことわり
「ソフトウェア」には、OS（オペレーティングシステム）やドライバなど、さまざまなものがありますが、この記事で「ソフトウェア」というときは、アプリケーションソフトウェアを指します。
みなさんが、業務効率化のために作成する「業務アプリケーション」に読み替えていただいて問題ありません。「アプリケーションアーキテクチャ」も、同様です。
また、ソフトウェアアーキテクチャは、ソフトウェア工学の設計法であるということも、事前にお伝えしておきます。
アプリケーションアーキテクチャ
アプリケーションアーキテクチャとは、アプリケーションの品質を向上させるための設計法です。
アプリケーションの品質
アプリケーションの品質は、国際標準化機構（ISO）により、ISE/IEC 25010として、定められています。
とても、たくさんの項目がありますが、どの項目に着目して「このアプリケーションは品質がいいね」と評価するかは、人それぞれです。
たとえば、品質にセキュリティを求める人にとっては、高セキュリティであることが、アプリケーションの品質が高いといえるでしょう。
アプリケーションの変更容易性
わたしが考える、ノンプログラマーにとって価値が高いアプリケーションの品質は「変更容易性」です。
図1－7でいくと、「外部・内部品質」の「保守性」にあたります。
アプリケーションの変更が楽、テストしやすい、再利用しやすい、というのがノンプログラマーにもっとも価値をもたらす品質ではないでしょうか。
アプリケーションアーキテクチャパターン
原始時代から、人間は建築物を建ててきましたが、いい建物を作るための設計法（アーキテクチャ）を常に研究してきたはずです。（わたしの妄想です）
すると、だんだん、設計するときの特定の問題に対する、再利用可能な解決策が見えてきました。それをまとめたのが「アーキテクチャパターン」です。
アーキテクチャパターンは常に発見され、最新技術としてアップデートされ続けています。
ノンプログラマーがアプリケーションを作成するときに、どのアーキテクチャパターンを用いると、アプリケーションの品質を高められるのか、意識を向ける必要がありそうです。
主なアーキテクチャパターン
とはいえ、ノンプログラマーがアプリケーションを設計するときに、使えそうなアーキテクチャパターンは、さほど多くありません。
ほとんどは、伝統的なレイヤーパターンを基本とします。
そして、レイヤーパターンで起こりがちな、要素をデタラメに抽象したために複雑になってしまった構造を、また別のアーキテクチャパターンやアーキテクチャを選んで設計し直すことで、アプリケーションの品質を高めていくことができます。
| パターン名 | パターンを構成する要素 | 主なアーキテクチャ |
|---|---|---|
| レイヤー | 機能的にまとまりのあるモジュールのグループ | 3層アーキテクチャ、MVC |
| ポート＆アダプター | ビジネスロジック、インターフェイス、データソースとのやりとり、など機能別モジュール | ヘキサゴナルアーキテクチャ |
| 多層 | 機能的責務、通信メカニズム、セキュリティ要件 | （概念的にはレイヤーパターンと似ているが、多層パターン実行時の要素を処理するもの。主にWebアプリなど） |
重要なことは、アプリケーションの設計は、一度設計したら終わりではなく、常に改善され続けることで、アプリケーションの品質を高めていくことです。
アプリケーションアーキテクト
アーキテクチャは設計であり、アーキテクチャパターンは設計課題の再利用可能な解決策でした。
そして、これらを使いこなす、神のような存在がアーキテクト（建築家・設計者）です。
アプリケーションアーキテクトは、アプリケーションの品質を高めるプロですが、他にもインフラアーキテクトや、データベースアーキテクトなども存在します。
アーキテクトは、クライアントと共にアプリケーションの品質をすり合わせしたり、実際にリファクタリング（プログラムを書く）するといわれています。
プロジェクトマネージャー（を兼任することもある）であり、システムエンジニア（プログラマー）であり、設計デザイナーである感じでしょうか。
アーキテクトが不足している
「2045年の壁」という問題を耳にしたことはあるでしょうか。
COBOLなどの古いプログラム言語で、業務アプリケーションを現役で開発していた世代が、一斉に定年を迎える問題です。
誰も読むことができない、修正ができないソースコードは、レガシーシステム（負の資産）と呼ばれています。
課題対策として、アーキテクトが必要だと言われています。
出典：これからの人材のスキル変革を考える ～DX時代を迎えて～ – IPA
アーキテクトは常に、アプリケーションの開発者や利用者などのステークホルダーに寄り添っています。
また、世界中のアーキテクチャ最新動向などをキャッチしながら、アプリケーションの品質を高める活動を行っています。
ドメイン駆動設計に用いられるオニオンアーキテクチャやクリーンアーキテクチャ、または最新のイベント駆動型アーキテクチャなど、便利で豊かなアプリケーションの設計ができるのは、アーキテクトのおかげなんですね。
アーキテクトはじめの一歩
わたしたちのようなノンプログラマーにとって、ドメイン駆動設計の習得がとてもむずかしいのは、アーキテクチャを理解できていないからかもしれません。（わたしの個人的な仮説です）
実際に、かんたんなアーキテクチャを意識しながら、アプリケーションの設計をしてみましょう。
まとめ
以上で、「アーキテクチャ」について、お届けしました。
世界中でノーコード・ローコード環境が普及していくことにより、ノンプログラマーが爆発的に増え、プログラマ不足は解消されていくでしょう。
しかし、一方で、アプリケーションの品質については、あまり多く語られていません。
また新たなレガシーシステム（負の資産）をつくらないように、「ノンプログラマーアーキテクト」の存在が求めれらるでしょう。
次回は、「3層アーキテクチャでアプリケーション設計をしてみよう」をお届け（予定）します。
