システム方式設計書：「システム構造」の書き方

システム（アプリケーション）方式設計書には何を書いたらいいのでしょうか。
章ごとに何を書いたらいいのかを解説していきます。
まずは、第1章システム構造からです。

システム構造に書くこと概要
システム構造に書く要素
システム構造　「概要」
システム構造　「方式設計」
システム構造　「実装方式」

システム構造に書くこと概要

システム構造はシステム方式設計書の第1章に当たる章です。
システム方式設計書は解説者によって記載する方式の順番など違いますが、システム構造はほとんどの場合一番初めに書かれています。

システム（アプリケーション）方式設計書は主に開発するアプリケーション（プログラム）の仕組みついて設計していきます。
一方、システム構造はアプリケーションが動作する環境について設計します。
ハードウェアやミドルウェアなどの環境の設計です。

システム方式設計の各方式に記載する要素については下記の記事をご覧ください。

システム方式設計の構成

システム方式設計書に書くことは3つ「概要」「方式設計」「実装方式」という話を以前しました。では、そのとおりに設計をするとどのようなイメージになるのでしょうか。実際に方式設計章のレイアウトを用意しました。システム方式設計をするときのイメージにしてください。

システム構造に書く要素

システム構造の章にはどのような技術要素について書いたらいいのでしょうか。
いくらか列挙してみます。
Webを使ったシステムでは次のような要素が考えられます。

・ハードウェア要件（CPU、メモリなど）
・クライアント端末、サーバの配置関係
・クライアント、サーバに導入されているミドルウェアなどの資産
・ネットワーク機器（負荷分散装置）とサーバのつながり
・プリンタや外部ディスク（NAS)などの外部装置とのつながり
・連携する他システム
・システムの利用シーン（利用者情報）
・負荷分散方式
・タイムアウト方式

このような要素について方式を決め、仕様を説明します。

システム構造　「概要」

システム構造の「概要」には採用する仕組みを箇条書きで書いていくといいでしょう。
いくらかの例を挙げてみます。

クライアント端末、サーバの配置関係

クライアント端末の要件として、HTMLベースのブラウザを使ったシステムにするのか、アプレットを使うのか、スマートクライアント方式、クライアントサーバ方式、などどれを採用するのか。
それを採用する理由は何でしょう。
不特定多数の人がアクセスするようなホームページやECサイトを作る場合は、クライアント端末の制約をなるべく受けないHTMLベースのブラウザを使ったシステムがいいですね。

この方式が決まると、サーバの配置が決まってきます。
Webサーバ、アプリサーバ、DBサーバという構成になります。

クライアント、サーバに導入されているミドルウェアなどの資産

特に、サーバに配置されているミドルウェアに関する制約を確認しておきます。
オーナー側からの指定があるかもしれません。
帳票は他システムで使っているアプリを指定されることが多いです。
利用するアプリによって出力できる帳票や、プログラムの書き方が違ってくるので今後の作業に影響します。

ネットワーク機器（負荷分散装置）とサーバのつながり、負荷分散

こんかいのシステムでは負荷分散の要件があるでしょうか。
負荷分散の要件があればアプリを配置するサーバの数が増えます。
負荷分散装置の種類によって構築するアプリの側で考えなければならないことが増えます。
例えば、セッション管理です。
負荷分散されたサーバ間でセッションを共有できるのか、共有できなければセッションを使わず一時情報をDBに格納するなどの仕組みを考える必要があります。

システム構造　「方式設計」

システム構造の方式設計にはこのシステムで採用する方式の説明をしていきます。
これもいくらか例を挙げてみます。

ハードウェア要件

サーバやクライアント端末のCPUやメモリスペックの要件を記載します。
サーバのスペックについては大量アクセスが想定される場合に十分な性能が確保されているか。
クライアント性能は画面の表示スピードにかかわります。

この項目については、どれくらいだったらOKという基準値はありません。
経験値からこれくらいのスペックならいいかな？と思うぐらいです。
オープン系のシステムではシステムを作ってみないと性能はわからないところがあります。
正直なところ、形骸化している設計項目だと思いますが、一応書いておぐらいの項目です。

システム構成図

クライアント端末、サーバの配置関係を表現します。
クライアントはインターネット上に配置されるのか、社内のクローズドのネットワークに置かれるのか。
インターネットに公開するシステムの場合、WebサーバはネットワークのDMZエリアに置いて、アプリサーバをイントラネット上に置くなどを決めます。

クライアント、Webサーバ、アプリサーバ、ＤＢサーバなどの誰と誰がつながっているのかを表現します。
普通はクライアントとWebサーバはつながっていますが、クライアントとアプリサーバやDBサーバ、ファイルサーバがつながることはありません。
必ずWebサーバを経由します。
ファイルダウンロードやアップロードの仕組みを作る場合はWebサーバを経由して、アプリサーバのプログラムを経由してファイルを取得してWebサーバに転送して、クライアントまで送るという仕組みを考える必要があるのです。

ソフトウェア要件

サーバやクライアント端末にインストールされているアプリを列挙します。
サーバの場合は、Webサーバ、DBなどのミドルウェアやそのバージョン。
Javaのバージョンなども列挙します。
クライアント端末はこのシステムを使うために必要なアプリケーションとそのバージョンです。
ブラウザを利用するシステムの場合は最低限動作を保証するブラウザの種類（ChromeやEdgeなど）を明らかにします。
ブラウザが違うと微妙にレイアウトが崩れることがあります。
こっちのブラウザに適合するデザインにすると他では崩れるなどあります。
オーナーと最低保証するブラウザを合意しておかないと、のちにいろいろな要求を追加されることがあります。

利用シーン

どのような人が、何人ぐらい同時に利用する想定かを明らかにしておきます。
ECサイトでは不特定の利用者になります。
社内システムでは従業員などです。
利用者は何人ぐらいがターゲットで、同時に使う人は何人ぐらいかを想定して書きます。
これによって負荷分散の必要性やセキュリティの強度を検討するときの材料になります。

負荷分散方式

負荷分散装置やアプリケーションで負荷分散を行う場合に、どのような負荷分散方式を採用するかを明らかにします。
負荷分散の方式によって構築システムで考慮が必要な事項が発生することがあります。

タイムアウト方式

WebサーバやDBサーバにはタイムアウト時間を設定します。
パソコンを使っているとアプリが動かなくなってしばらく待たされることがありますよね。
こんな時にいつまでも待ち続けるわけにはいきません。
一定時間待ったらエラーを返す仕組みを持っています。
この待ち時間を設定を設計します。
一般的にはクライアント端末に近いシステムはタイムアウト時間を長く、クライアント端末から遠いシステムは短く設定します。