本記事は『アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築』の「第1章 アーキテクトの仕事」から一部を抜粋したものです。掲載にあたって編集しています。
アーキテクトの定義
複雑な構造物であるソフトウェアにおいて非常に重要なアーキテクチャを適切に設計するには、ソフトウェア開発業務に関わる幅広い知識や経験が必要とされます。そのため、アーキテクトという専門の職種が存在します。
アーキテクトという職種に関する日本国内での標準的な定義を確認しておきましょう。
ITスキル標準V3でのITアーキテクト
情報処理推進機構（IPA）がまとめた『ITスキル標準V3 2011』では、ITアーキテクトの職種を以下のように説明しています。
- ビジネス及びIT上の課題を分析し、ソリューションを構成する情報システム化要件として再構成する。
- ハードウェア、ソフトウェア関連技術（アプリケーション関連技術、メソドロジ）を活用し、顧客のビジネス戦略を実現するために情報システム全体の品質（整合性、一貫性等）を保ったITアーキテクチャを設計する。
- 設計したアーキテクチャが課題に対するソリューションを構成することを確認するとともに、後続の開発、導入が可能であることを確認する。
- また、ソリューションを構成するために情報システムが満たすべき基準を明らかにする。さらに実現性に対する技術リスクについて事前に影響を評価する。
また、当該職種は「アプリケーションアーキテクチャ」「インテグレーションアーキテクチャ」「インフラストラクチャアーキテクチャ」の専門分野に区分されるとされています。
最近は物理的なサーバー機器、ネットワーク機器を用いてインフラ構築を行うケースは減り、クラウド環境上にシステムを構築することの方が多くなっています。インテグレーション（統合）についてもクラウドベンダーが提供するサービスを利用することができます。よって実際の職務上はこれらの専門分野の垣根は低くなりつつあり、以前に増して広範囲な知識がアーキテクトに求められるようになりました。
情報処理技術者試験でのシステムアーキテクト
同じIPAが管轄する情報処理技術者試験の区分の一つであるシステムアーキテクト試験（SA）では、その業務と役割を以下としています。
- 情報システム戦略を具体化するための情報システムの構造の設計や、開発に必要となる要件の定義、システム方式の設計及び情報システムを開発する業務に従事し、次の役割を主導的に果たすとともに、下位者を指導する。
アーキテクトの主要な職務
情報処理推進機構ITスキル標準のITアーキテクト、情報処理技術者試験のシステムアーキテクト、それぞれで定義されたアーキテクトの職務内容はほぼ同じです。
細かく読むとITアーキテクトの方には戦略的情報化企画への主体的な関わりが記述されている点が違うのですが、情報処理技術者試験にはその職務にあたるITストラテジストが別に存在するためと筆者は推察します。いずれにしても、企業のIT戦略を実現するための最適なアーキテクチャの設計ならびに実現がアーキテクトの主要な職務となります。
そのため、アーキテクトは単に技術トレンドに目を向けるだけではなく、企業の事業活動のビジョンやミッション、それに基づく経営戦略やIT戦略を正しく理解した上で、業務部門の人たちと円滑にコミュニケーションを取ることが求められます。そうでなければ、システムを正しいアーキテクチャへ導くことはできないのです。
2000年代の時代背景とアーキテクチャ設計のトレンド
筆者がIT技術者としての経歴をスタートした2000年代初頭と本を執筆している現在とでは、アーキテクチャ設計上の考慮事項が大きく変わっています。
2000年代、企業の業務システムではメインフレームからオープン系システムへの移行が進みました。また、インターネットの爆発的な普及やスマートフォンの登場をきっかけに、ECサイトをはじめとする一般消費者向けのWebサイトも新たな販売チャネルとして重要な位置付けとなりました。
このような背景から、IT技術やアーキテクチャの面では以下のようなトレンドがありました。
WebアプリケーションやSOAの普及
当時は今ほど技術的な選択肢は広くありませんでした。クライアント端末にインストールされた業務アプリケーションからデータベースサーバーへアクセスするクライアントサーバーシステム（C/Sシステム）からWebアプリケーションへの移行が進み、StrutsやRuby on RailsといったWebアプリケーションフレームワークが生まれ、人気を博しました。 Webアプリケーションはブラウザ〜APサーバー〜DBサーバーという三層構造を取りますが、アプリケーションアーキテクチャもそれに対応する形でUI層〜ビジネスロジック層〜データベース層という三層レイヤードアーキテクチャが主流でした。
C/SシステムとWebアプリケーションの典型的なアーキテクチャは図のとおりです。
アプリケーション統合の観点では、既存のアプリケーション機能をサービスという単位で再利用することを狙ったSOA（Service Oriented Architecture）という設計思想が生まれ、SOAに基づくアプリケーション統合基盤としてESB（Enterprise Service Bus）と呼ばれるミドルウェア製品も大企業を中心に導入が進みました。
Java言語を用いたエンタープライズ向け開発ならJava EE、SOAのサービスを実装するプロトコルはSOAPという具合に標準化も進みました。そして標準に準拠することが是とされたため、アーキテクチャの設計にあたっても基本はベストプラクティスに従えば問題ありませんでした。一方で、標準が重厚になり過ぎて開発効率が下がってしまうという課題もあり、そういった背景からSpring Frameworkのような当時軽量コンテナと呼ばれたアプリケーションフレームワークが世の中に出てきたのもこの頃です。
2020年代の時代背景とアーキテクチャ設計のトレンド
2020年代においては、BtoC（一般消費者向け）であれBtoB（企業向け）であれ、魅力的なサービスを顧客に対していかに素早く提供できるかが重要となっています。バックオフィスの業務システムや経営可視化ツールなど企業内には数えきれないほど多くのソフトウェアが存在し、それらは相互に繋がっています。
2023年には生成AIが一大ブームとなりましたが、AI関連技術の進化は加速度を増しており、サービスへの組み込み事例や業務改善への活用事例も多くなりました。
このような背景から、IT技術やアーキテクチャの面では次のようなトレンドがあります。
クラウドの普及
Amazon Web Services（AWS）がクラウドサービスの提供を開始したのは2006年のことですが、2011年にアジアパシフィック東京リージョンが利用可能となると、日本国内の企業による利用も増加の一途をたどりました。AWSに加えて、Microsoft Azure、Google Cloudの三つがクラウドコンピューティングの巨人とされています。現在では新たなシステムを導入する際には、まずはクラウド基盤を最優先に検討をすべきという、クラウドファーストの考え方も浸透しています。
アプリケーションを設計する上でも、クラウド環境へのデプロイやクラウド事業者が提供する様々なサービスを利用することを前提とし、クラウドに最適化したアーキテクチャを選定すべきとする、クラウドネイティブという概念が重要視されています。
REST APIの普及
REST（REpresentational State Transfer）は、HTTPの仕組みを利用してアプリケーション間のデータ通信をシンプルに実現する設計原則です。REST原則に則ったAPIをREST APIと呼びます。そのシンプルさからAPIの実装手段としてのREST APIの採用は広がり、様々なクラウド上のサービスがREST APIを提供するようになりました。その結果、アプリケーションやサービス間の連携がより容易に実現可能となりました。
マイクロサービス
複数の独立した小さなサービスを組み合わせて一つのアプリケーションを構築するマイクロサービスアーキテクチャが提唱され、採用事例も増えています。
サービス単位で独立して開発やデプロイが行えることや、サービス単位でスケーリングができること、サービスに適したテクノロジーを採用できることなど、マイクロサービスには多くのメリットがあります。
一方で分散システムは本質的に複雑であり、分散システム特有の課題に向き合う必要があります。それでも、ソフトウェアのアジリティを高めるアーキテクチャとしてマイクロサービスは検討してみる価値があるでしょう。
多種多様性
ソフトウェアのコードを記述するプログラミング言語には、JavaやC#のようなオブジェクト指向言語、HaskellやClojureのような関数型言語、アクターモデルを採用したErlangなど数多の言語が存在し、それぞれが特色を持っています。オブジェクト指向と関数型の性質を併せ持つハイブリッド言語も増えています。
データベースは従来のRDBMSだけでなく、カラム指向DBやドキュメント指向DB、グラフ指向DBなどいわゆるNoSQLデータベース製品を用途に応じて使い分けることが可能となりました。
フロントエンド開発は、従来はWebアプリケーションサーバーがレンダリングして返却したHTMLをWebブラウザが描画し、jQueryなどのJavaScriptライブラリを読み込んで利用し、クライアントの振る舞いを実現していました。最近はReactやVue.jsなどのJavaScriptライブラリを利用したSPA（Single Page Application）アーキテクチャが主流となり、ReactとVue.jsに対応したフロントエンドフレームワークとしてNext.jsやNuxtなども人気があります。
このように、アプリケーションの各層で利用可能なテクノロジーは多岐にわたり、適材適所で組み合わせて利用することが求められます。
アーキテクトが備えるべき能力や考え方
変化に柔軟に対応して顧客に価値を提供し続け、企業に競争優位をもたらすソフトウェアを生み出すために、多種多様なテクノロジーを評価、選定してアーキテクチャを構築するアーキテクトという仕事はとても大変で、だからこそ非常にやりがいのある仕事だと思います。
アーキテクトの仕事の進め方や具体的な作業手順は本書『アーキテクトの教科書』で説明しますが、ここではアーキテクトが備えるべき能力や考え方について、筆者の考えをまとめます。
設計力、コーディング力
アーキテクチャの設計はクラス設計やコンポーネント設計と比べてより概念レベル、方針レベルの検討が必要となり、考慮すべき観点も異なるのは事実です。しかし、全く別物というわけではありません。アーキテクチャレベルでも通用する設計原則は多くあります。筆者は、下位レベルの設計やコーディングをしっかりできる技術者でなければ、良いアーキテクチャ設計は難しいと考えています。
また、技術トレンドは常に移り変わり、以前は良いパターンとされていたものがある日を境にアンチパターンとなってしまうようなケースがあります。ですので、設計力とコーディング力は常に磨き続ける必要があるでしょう。
抽象化能力
良い設計は抽象と具象がうまく分離されています。問題領域において重要な本質部分と、置き換え可能な詳細部分に分けて考えることで、ソフトウェアには柔軟性や拡張性が生まれます。これはアーキテクチャレベルにも当てはまる普遍的な原理です。
具体例を収集し、その分析結果から一般的に適用されるパターンや方針を導き出す、つまり抽象化するという能力はとても大事です。ただし、顧客やステークホルダーと会話する際には抽象レベルだけで話すといわゆる空中戦になりがちなので、具体例を用いた方がうまくいきます。つまり、抽象と具象を自由自在に行ったり来たりする能力があると、とても重宝します。
ビジネスの理解
すべての企業活動の目的は継続して利益を出すことであり、そのために経営戦略やIT戦略が立案されます。IT戦略を実現し、企業に利益をもたらすソフトウェアの礎となるのがアーキテクチャです。もしアーキテクトがビジネスに対する理解が浅い状態でアーキテクチャを設計したなら、優先事項を間違えて捉えてしまって、その結果役に立たないアーキテクチャができあがってしまうリスクがあります。
ではどの程度の理解があればよいかというと、アーキテクトが所属する会社や組織、その文化や風土、期待される役割などによって異なります。事業会社に所属するアーキテクトであれば、その事業内容や競争優位性についてきちんと把握しておくべきでしょう。SIerなどのITベンダーに所属するアーキテクトの場合、システムを提供する顧客は都度変わるかもしれませんが、一般的な業務知識や業界特有の商習慣や規制などの知識があった方が顧客とのコミュニケーションが円滑に進みます。
とはいえアーキテクトはビジネスの専門家ではないので、ビジネスの専門家と会話をし、いかにしてソフトウェアやそのアーキテクチャにとって重要な情報を引き出せるかがポイントとなります。つまりアーキテクトは「聞き上手」であるべきです。
好奇心
繰り返しになりますが、ソフトウェアを実現する技術は絶え間なく進化し、まさに日進月歩です。昨日のベストプラクティスが今日のアンチパターンといったことが起こり得る業界にわれわれは身を置いています。
ですから、一つの決まったやり方に固執するのではなく、様々な選択肢を評価し、その中から選択するという行為がアーキテクトには求められます。そのためには、常日頃からアンテナを張って情報を収集し、面白そうなものがあれば試しにちょっとしたコードを書いてみるといった姿勢が大切です。
完璧主義よりも合理主義
大人数で開発する大規模なソフトウェアの、どのコード断片を取っても良い設計、良いコードになっているというのは理想ではありますが現実的ではありません。ソフトウェアの重要な部分は徹底的にレビューを実施するが、そうでもない部分について多少は目を瞑るというような割り切りも、時には必要です。
ソフトウェアのアーキテクチャも同様で、すべての項目で満点を取れるアーキテクチャは存在しません。課題に優先順位をつけて取り組み、ほどほどに良いアーキテクチャを目指すべきです。アーキテクチャは目的ではなく手段であると認識し、合理的な判断を下すこともアーキテクトの役目です。
