今回は、開発対象のシステムのアーキテクチャ(アーキテクチャ)方針を明確化します。本項ではあくまで、主な2種類のアーキテクチャの概要を紹介して次回から2種類アーキテクチャについて説明します。

情報システムにおけるアーキテクチャの位置付け

アーキテクチャとは「構造体」を意味します。情報システムにおけるアーキテクチャとは、IT システムの構造であり、環境であり、基盤であり、制約でもあります。前述した「情報システムの使命」を実現するための業務プロセス、データ、そしてその交差点を管理するに当たり、基盤となるものと言い換えてもよいでしょう。

明確化したデータと業務プロセス、機能、そしてその交差点を管理する上で、必要とされるアーキテクチャを、非機能要件に基づいて明確化します。

昨今、アーキテクチャの選定が、機能/非機能要件に影響を与えるケースが出てきました。詳しくは後述しますが、主に「クラウド」の普及によるものです。この場合、機能(UIや処理内容部分のこと)/非機能(性能、信頼性、操作性など機能以外の部分)要件とアーキテクチャは、相互の影響を意識しつつ明確化していく必要があります。本章では上の図のパターンを基本とし、下の図のパターンについても触れていきます。

要件定義で扱うアーキテクチャ

企業情報システムのアーキテクチャには、EA (エンダープライズ、アーキテクチャ)をはじめ、様々な捉え方や用語定義があります。とはいえ、本書のテーマである要件定義の段階においては、最低限以下の2つについて、それぞれの要件を明確にしておくことがゴールとなります。

システムアーキテクチャ
アプリケーションアーキテクチャ

前者を後者と峻別する文脈から「インフラアーキテクチャ」に限定する考え方もあります。しかし本書では、システムインフラだけでなく、クライアント/サーバー型や Web、クラウドアーキテクチャといったように、システム構成全般を指す「システムアーキテクチャ」も、要件定義段階で明確にすべきアーキテクチャと考え、検討の対象とします。

後者は「ソフトウェアアーキテクチャ」と呼ばれる場合もあります。前者と同様に、広い意味でアプリケーション、ソフトウエア、ソフトウエア標準を包括して、それらの構造を指す言葉として使用し、前者同様に要件定義にて明確にすべきアーキテクチャと考え、検討の対象とします。

この2つが両輪のように支え合って、システムの基盤となるのです。システムアーキテクチャは非機能要件を基に、主にインフラの方向性を明確化していきます。アプリケーションアーキテクチャは機能要件を基に、主にソフトウエア開発の方向性を明確化していきます。

別の見方をすると、これらのアーキテクチャは、ビジネスの静的側面である「データ」と動的側面である「業務プロセス」を、要件レベルではあるものの、機能/非機能という両方の側面から支える情報システムの基盤と言ってもよいかもしれません。

いずれにしても、要件定義において2つのアーキテクチャの在り方を明確にすることが、情報システムの価値を、より大きく左右するようになったことは紛れもない事実です。

求められるレベル

要件定義において、2つのアーキテクチャをどこまで落とし込むかは、意見の分かれるところです。私の考えでは繰り返しになりますが「求められる見積のレベルに応じて」です。要件定義において「大枠」を掴み、ある程度の方向性を明確にするのか厳格な要求仕様として確定するのかで、求められるレベルは異なります。

方向性を掴み、可能な限り明確化した上で、設計の段階で変更可能にするために「バッファ」を残しておくのが現実的であると、私は考えています。次項以降で、2つのアーキテクチャを明確化していきます。