ソフトウェアアーキテクチャとは？おすすめパターンも紹介！

ソフトウェア開発の際に飛び交うアーキテクチャという言葉。

なんとなく聞いたことはあっても、どのような意味があるのかと興味や疑問を持ったことはないでしょうか。

また、誰かに聞かれたときに、きちんとその意味を説明できるでしょうか。

そこでこの記事ではソフトウェアアーキテクチャに関して基本的な考え方と重要ポイントを解説します。

ソフトウェア アーキテクチャとは

ソフトウェアアーキテクチャとはソフトウェアの構造図とソフトウェアを構成する要素の関係のことです。

ただし、業界の中で定義があいまいな言葉であり、「構造設計のすべて」と表現されることもあります。

「アーキテクチャ」とはもともと建築学や建築術、構造を示す言葉です。

家を建てるときに間取りや価格、キッチンの使いやすさなどを加味して設計図を構築するように、ソフトウェアにおいても、セキュリティやユーザーの使い勝手など、様々な要件を鑑みて設計を検討する必要があります。

アーキテクチャ設計

設計の詳細を形作るには、顧客の要望をヒアリングするのはもちろん、文字通りの要望だけではない、ユーザーの真のニーズを探っていく必要があります。

そのためには、綿密なコミュニケーションが不可欠です。

コミュニケーションが不十分なままでは、顧客側と開発側で、アーキテクチャの理解に齟齬が出てしまいます。

その結果、適切なアーキテクチャが構築されずに開発が進むことになり、例えば2015年にオリンピックで使われる予定の国立競技場の設計やデザインが問題になったように、顧客側の指示で開発の中止を余儀なくされることも考えられるのです。

そんな事態に陥らないよう、以下ではアーキテクチャ設計の注意事項をご紹介します。

ソフトウェア開発工程の一番最初に行う

まずは、ソフトウェアアーキテクチャは開発の初期段階で決定する必要があります。

なぜなら、全体設計に沿って後工程の仕様が決定されるためです。

例えば、エンドユーザーの利便性と管理者の利便性が相反する場合、どちらかを優先して構築する必要があります。

エンドユーザーの利便性を優先する場合には見た目部分をわかりやすく作る必要があるでしょう。

また、表示部分を開発する担当者や内部処理を開発する担当など後工程のアサインのしやすさにも繋がります。

アーキテクチャ決定前後に、顧客との認識合わせをする

次に注意すべきことは、全体のアーキテクチャ決定前後には顧客との認識をしっかり合わせる必要があるということです。

なぜなら、いったんアーキテクチャが決定すると、その後の修正は困難だからです。

全体の構造設計が決まった後には、それを前提に、必要な役割ごとに必要な機能などの洗い出しを進めます。

この洗い出しは全体の顧客の希望や、予算および納期の制約などをもとに、より具体的な粒度で決定していきます。

その際、開発の根幹であるソフトウェアアーキテクチャ決定後に前提を覆すような要望や制約は後工程の詳細の練り直しが必要になるために容易ではありません。

また、その変更を実施した場合の全体への影響を評価することも困難です。

そのため、全体のアーキテクチャ決定の際には、顧客としっかりコミュニケーションをとり、きちんと認識を合わせなければなりません。

役割としてのソフトウェアアーキテクトに必要なこと

ソフトウェアアーキテクチャを統括する責任者を「ソフトウェアアーキテクト」と言います。

ソフトウェアアーキテクトはプロジェクトの形によって個人、チームのいずれかを指すことがあります。

それぞれの場合において必要となることを紹介します。

個人での場合

プロジェクトチームにおいて、アーキテクトが個人で参画する場合、プロジェクトのリーダーを兼ねる場合がほとんどです。

したがって、 技術面でのリーダーシップを発揮するとともに、成果を上げることに重点を置きプロジェクトの原動力になる必要があります。

原動力となるためには技術的な決定権を持つことも重要ですが、顧客やベンダーなどの関係者の考えを理解、調整して落とし所を見つける力を求められます。

この時、一方の利益をもたらすが、また一方では不利益を被ることがあるため、技術的な観点からの説得を要することがあります。

また、プロジェクトメンバーに対しても力が発揮できるように環境づくりをすることも必要になります。

チームでの場合

アーキテクチャの設計は高い技術力が求められるため、個人ではなく、各分野に分けて複数人のチームとしてアーキテクトの役割を持つことがあります。

その場合、アーキテクトの役割を持つチームは、ビジネス面や技術面においてバランスの取れた状態にする必要があります。

また、 得意不得意があるプロジェクトリーダーを支える役割が期待されます。

プロジェクトのあるべき姿や目標、目的を見失いチームとして機能しなくなる危険性を未然に防ぐため、プロジェクトリーダーに従いつつ、全体を俯瞰した調整を意識するとよいでしょう。

双方に共通して大切なこと

個人にしろチームにしろ、アーキテクトとしての役割を果たすために大切なことは、自分たちのプロジェクトチームはもちろん、顧客とその背景にある組織を常に意識することです。

顧客担当者は個人でも、開発するソフトウェアは会社や部署などの組織に納品することがほとんどです。

アーキテクトは多くの関係者とコミュニケーションをとる必要があり、実際にソフトウェアを使用するユーザーや管理者だけでなく出資しているスポンサーやより上位の部署なども意識せざるを得ません。

そのため、組織の中で実質的な決定権限があるのはどこなのかを認識する必要があります。

また、プロダクトの納入後でも組織の中の力関係は継続されるため、可能な限り早い段階でアーキテクチャに関わるリスクを排除し安定したものにするためには、アーキテクトの情報収集力と交渉力、すなわちコミュニケーションスキルが試されます。

知っておくと良いアーキテクチャパターン

アーキテクチャパターンとは開発する際の設計パターンのことを指しています。

ソフトウェアアーキテクト個々人のスキルや経験に依存しすぎず、誰でも一定水準のアーキテクチャを設計できるよう、今までに活用されてきた技術を参考として使用できるようにしたものです。

以下では代表的なアーキテクチャパターンを5つ紹介します。

MVC

MVCは「機能ごとにプログラムの中を分けて記述する」ことを基本概念としています。

そのため、

●誰がみてもわかりやすい

●機能ごとの記述のため、メンテナンスがしやすい

●役割分担しやすい

という特徴があります。

MVCは「Model」「View」「Controller」の頭文字を取った略称です。

「Model」はデータや論理的な処理を担当する役割で、実際にはデータベースなどが当たります。

「View」はユーザーから見える部分のことでデータの入力や「Controller」からの受け取った情報を出力する役割があります。

「Controller」は「Model」と「View」を繋ぐ役割があり、ユーザーの操作を内部(Model)に反映させる機能があります。

MVP

MVPはMVCの「Controller」が「Presenter」に取って変わったパターンです。

MVCよりも柔軟性があります。

MVCでは「View」と「Model」の依存性が高い傾向がありましたが、「Presenter」が「View」と「Model」両方のインスタンスを持っているため、MVPでは「View」と「Model」の依存性が低い反面、機能が複雑になると「Presenter」と「Model」の依存性が高まります。

POSA

Patten-Oriented Software Architecturenの略で複数のカテゴリのアーキテクチャパターンが含まれています。

それぞれのカテゴリの中にも複数パターンがあり、例えば「混沌から構造へ」に含まれるBlackboardは解決策が見つかっていない問題に対してサブシステムを組み合わせることにより近しい答えを導き出すアーキテクチャです。

フォームとコントロール

Visual Basicなどでよく使用されていたスタイルで画面にチェックボックスやボタンをドラッグアンドドロップで設置して開発するものです。

同じ画面上にコントローラ（イベントが発生した時の処理をする機能）も設置するため、どのような処理がされているのかわかりやすいが、処理が増えてくるとコーディングが必要になることがあります。

プレゼンテーション・モデル

プレゼンテーション・モデルはMVCの「Model」における表示部分の処理のみを担う「プレゼンテーション・モデル」を設置するパターンです。

その他の処理については「Model」に委譲するため、「View」や「Controller」から見れば「プレゼンテーション・モデル」で全ての処理がされているように見えます。

まとめ

ソフトウェアアーキテクチャとはソフトウェア開発における構造図のことで、一番最初に決定する必要のあるものでした。

責任者であるアーキテクトには技術的なスキルと関係者とやりとりをしてアーキテクチャに反映するためにコミュニケーションスキルが求められます。

また、アーキテクト個々人のスキルや経験による差を埋めるために、今までに活用されてきたアーキテクチャパターンを使用する方法があります。

アーキテクトとして開発に関わるときに利用してみてはいかがでしょうか。