【#01】めっちゃ大事！ システムの「柔軟性」とアーキテクチャ
非IT企業でシステムエンジニアとして働くサラリーマンです。「システム設計と人生設計は同じ」との気付きから、「自己実現を支えるアーキテクチャとは？」をテーマに技術的で意識高い系の記事を投稿しています。この記事が「面白かった！」という方はフォローまたはシェアしてもらえると嬉しいです。
今回、システムの「柔軟性」とアーキテクチャ設計の関係についての考察結果を紹介します。今回の結論は以下の３つです。
✅ システムの「柔軟性」がビジネスを成功に導く！
✅ 「柔軟性」はアーキテクチャによって実現される！
✅ アーキテクチャ設計ではシステムの要素・機能・データの配置を同じ判断基準で決める！
システムの「柔軟性」がビジネスを成功に導く
システムは一体何のために使われているのでしょうか？多くの場合、システムは企業のビジネスを成功に導くための手段として使われています。そして、ビジネスを成功に導くためにシステムに求められるもの、それは「柔軟性」です。
昨今、ビジネス環境の変化スピードが早く、ユーザの要求も日々変化しています。いわゆる、不確実性の高い「VUCAの時代」です。この変化の激しい環境において、各企業はライバル企業に取り残されないように、ユーザの要求の変化をいち早く察知し、製品やサービスを改善し続けなければいけない状況にあります。
つまり、ビジネス環境の変化に柔軟に対応していかなければいけません。しかし、日本の製品やサービス開発では、環境の変化に対して柔軟に対応できているのでしょうか？
例えば、書籍「ソフトウェアファースト」では、日本企業の製品やサービス開発における様々な問題点が指摘されています。その中で、柔軟性の欠如について以下のような問題提起がなされています。
常にユーザーの声に耳を傾けながら変えていかなければならないわけです。規模や業種を問わず、日本企業のプロダクト開発にはこうした柔軟で素早い判断が足りていないのではと感じることが少なからずあります。
（出典：及川卓也「ソフトウェアファースト」）
環境の変化に応じて、柔軟に対応していくといのは「なかなか難しい」というのが現状のようです。
その原因の１つとして、製品やサービスをウラで支えているシステムに柔軟性がないということが考えられます。ちょっと変更を加えるただけで、期間もコストもかかってしまうようなシステムを使っていた場合、環境の変化に柔軟に対応していくことは難しいでしょう。
そして、「柔軟性」を持たない製品やサービスは、ユーザの要求に合わなくなり、使われなくなります。当然、製品やサービスをウラで支えているシステムも使われなくなり、企業にとって技術的な負債となってしまいます。
システムは、私達エンジニアが大切な命の時間を費やして開発した作品です。その作品が、ビジネス価値を生み続けるためにも、「柔軟性」を備えたシステムを開発することが課題であると考えています。
「柔軟性」はアーキテクチャによって実現される
では、システムが「柔軟性」を備えるためににはどのようにすればいいでしょうか？「なんとなく開発したシステムに、なんとなく柔軟性が備わっていた。」なんてことは、もちろんありません。柔軟性はシステム開発における「アーキテクチャ設計」において意図的に作り込んで行く必要があります。
「アーキテクチャ設計」の説明の前に、まず、システム開発の全体像から説明したいと思います。
システム開発は、大きく分けて「要件定義」「設計」「実装」「テスト」の４つの工程を経て進んでいきます。
（１）「要件定義」
ユーザの要求（ユーザがやりたいこと）を元にシステムで実現する機能・性能を決める工程です。システムで何をするか？「what」を決めます。
（２）「設計」
「要件定義」で決まった機能・性能を実現する方法を決める工程です。「what」を実現するためにどうするか？「what」に対する「how」を決めます。
（３）「実装」
「設計」で決まった実現方法に従って、プログラミングや各種設定を行う工程です。「how」に従って「what」を実現できるようにします。
（４）「テスト」
「実装」されたシステムを実際に動作させながら、「要件定義」で決まった機能・性能が実現できていることを確認する工程です。「what」が実現できていることを確認します。
システムの柔軟性は、まず、「要件定義」で議論されます。「要件定義」では、ユーザの要求を元に、システムが実現する機能・性能をそれぞれ、機能要件・非機能要件として定義していきます。例えば、「商品の一覧を表示できる。」とか「注文を受け付けることができる。」といった機能面の要求は機能要件、「24時間365日使える。」とか「利用者10万人まで対応できる。」といった性能面の要求は非機能要件となります。システムの柔軟性、例えば「1日以内に新機能を追加できる。」という要求は非機能要件に含まれることになります。
そして、次の「設計」において、定義された機能要件・非機能要件の実現方法を決めていきます。このとき、機能要件と非機能要件の実現方法はそれぞれ別の観点での設計が必要です。例えば、Wikipediaでは「機能要件の設計はシステム設計、非機能要件の設計はシステムアーキテクチャ」との解説があります。
機能要件を実装するための設計がシステム設計であり、非機能要件を実装するための設計がシステムアーキテクチャとなる。
（出典：Wikipedia）
ただ、ちょっと難解ですね。
私は、自身の経験から機能要件と非機能要件の実現方法を以下のような観点で解釈しています。
機能要件 ：プログラミングで実現する。
非機能要件：アーキテクチャで実現する。
若干、言い過ぎかと思うものの、自身の経験から最もしっくりきている解釈です。「設計」では「機能要件をプログラミングで実現する方法」および「非機能要件をアーキテクチャで実現する方法」の２つを決めるというのが私の解釈です。
そして、「実装」では機能要件をプログラミングで、非機能要件をアーキテクチャで実現できるようにします。最後に、「テスト」にて機能要件・非機能要件がそれぞれ実現されていることを確認します。
このように、システムの柔軟性は「要件定義」にて非機能要件として定義され、「設計」にてアーキテクチャ設計を行い、「実装」することでシステムに備わります。
このシステム開発の工程については、こちらの書籍にとても詳しく解説されています。「もっと具体的に知りたい！」という方はこちらも参考にしてみてください。
アーキテクチャ設計ではシステムの要素・機能・データの配置を同じ判断基準で決める
では、システム開発の「設計」にて行う「アーキテクチャの設計」とは、どんな作業なのでしょうか？私は、専門書で学んだ内容と、自身の経験から「アーキテクチャ設計とは、システムの構成要素に対して、データと機能の配置を、同じ判断基準で決めていく作業」ではないかと考えています。
私がアーキテクチャ設計を学んだなかで、特にオススメするのが「Clean Architecture 達人に学ぶソフトウェアの構造と設計」という書籍です。有名な書籍なのでご存じの方も多いと思います。また、読み物としてもとてもおもしろい書籍で、技術的にもアーキテクチャ設計者のバイブル本と言ってもいいぐらい濃い内容となっています。（ただ、この書籍はやや玄人向きなので、とっつきやすい書籍を【参考文献】に紹介しておきます。）
この書籍では「アーキテクチャのルールはどれも同じである！」との主張のもと、アーキテクチャ設計に関する汎用性の高い技術的な考察が多数紹介されています。その中で、アーキテクチャの３つの大きな関心事として、以下のような紹介があります。
アーキテクチャの３つの大きな関心事とは「コンポーネントの分離」「データ管理」「機能」である。
（出典：Robert C. Martin「Clean Architecture 達人に学ぶソフトウェアの構造と設計」）
上記の内容は、私自身が「アーキテクチャの設計」として行っていた作業とほぼ同じであったため、「やっぱりそうか！」と非常に納得感がありました。
システム設計を行う際、私はシステムの構成要素をザックリと決めたあと「どこにどのデータを配置するのがいいなぁ」「この機能はここに配置したほうがよさげだなぁ」という思考を巡らせていました。そして、この思考こそが「アーキテクチャ設計」であったことに、私自身も気付いたのです（今更かよっ！）。
しかし、これだけの思考だと、実は「オブジェクト指向で設計ました。」というだけの話になります。エンジニアであれば、誰もがフツーにやっていることです。
私は「アーキテクチャ設計」と「単なるオブジェクト指向での設計」の違いは、「共通の判断基準に基づいているかどうか」であると考えています。先程の「どこにどのデータを配置するのがいいなぁ」という思考において、共通の「判断基準」のもと意志決定を行っていくことこそが「アーキテクチャ設計」であると考えです。
では、その「判断基準」とやらは何なの？ということについては、次回の記事で考察したいと思います。
まとめ
今回の記事のまとめです。
✅ システムの「柔軟性」がビジネスを成功に導く！
✅ 「柔軟性」はアーキテクチャによって実現される！
✅ アーキテクチャ設計ではシステムの要素・機能・データの配置を同じ判断基準で決める！
次回は、アーキテクチャ設計における判断基準について、代表的なフレームワークであるエンタープライズアーキテクチャを元に、考察したいと思います。
【参考文献】
アーキテクチャ設計の初心者向け書籍。JAWS-UGのマイクロサービス勉強会で「とても勉強になった！」と紹介されていたので、購入したところ「確かに！」と唸りました。アーキテクチャ設計を進めるうえで、知っておくべき最低限の内容が網羅されています。
この記事が気に入ったらサポートをしてみませんか？