1. はじめに
本記事では、IT業界の中でもインフラ系に焦点を当てたシステム構築プロジェクトにおける基本設計について記載します。
1-1. 背景
本記事を書くに至った背景は主に2つです。
- インフラに焦点を当てた設計に関する文書が少ない
- 設計時に何を記載するべきか筆者自身が毎回悩む
→ ガイドライン的に残しておくことで見直して設計業務を効率化したい
1-2. 本記事の目的（ゴール）
本記事を読むことにより、インフラシステム構築において基本設計とはどういうものか、基本設計書に記載するべき内容は何かなどをおおまかに理解することを目指します。
2. 基本設計とは何か
まずは基本設計とは何か、何のために行うのかを理解しておく必要があります。
基本設計は、前段にある要件定義で定義した要件を満たすために
どのようなシステムとするか
を決める工程になります。
もう少し具体的に言うと、導入するシステムのあるべき姿（要件）を目指すために
- どのようなシステム構成にするか
- どの機能を使うのか
- どのような設定内容とするのか
の大枠とその理由（根拠）を考え・決める工程です。
3. 基本設計の設計要素
基本設計は前段の要件定義で定義した内容を満たすために、どのようなシステムにするかを設計する工程であるため、要件定義で決める内容に沿って考えていくと理解しやすいかと思います。
要件定義では、主に以下の内容を定義します。
- 業務要件
- 機能要件
- 非機能要件
そのため、基本設計でもそれぞれ業務設計、機能設計、非機能設計を行うと考えればイメージしやすいです。
機能設計、非機能設計は基本的にどのプロジェクトでも必要な設計になるかと思いますが、
業務要件については単なるシステムリプレイスであれば必要ない場合もあるかもしれません。
以下にそれぞれの設計についての概要を記載します。
3-1. 業務設計
業務設計では、システムを導入することによってどのような業務フローとなるかを設計します。
実際の設計書では、
- 現在の業務フロー（図）
- システム導入後の業務フロー（図）
といった内容を記載します。
3-2. 機能設計
機能設計では、どのような機能を実装するかを設計します。
アプリケーション開発であれば、開発する機能を設計するのでイメージしやすいかと思いますが、
インフラシステムの場合は、機能を提供するのは「サーバー」となるため、
機能 ≒ サーバー
と考えてみるとイメージしやすいのではないでしょうか。
つまり、システム全体で必要となる機能をどのようなサーバーを使って実装するかを設計します。
3-3. 非機能設計
非機能設計では、システムが提供する機能以外の部分でシステムが満たすべき要件をどう実現するかを設計します。
主に、性能や耐障害性といった目に見えにくい部分の設計を行う工程です。
要件にもよりますが、概ね以下のような設計を行うことになります。
- 可用性（信頼性）
- 性能・拡張性
- 運用・保守性
- 移行性
- セキュリティ
以下にそれぞれの設計について概要を記載します。
3-3-1. 可用性（信頼性）
可用性（信頼性）では、システムを安定稼働させるための指針について設計します。
具体的には
- 稼働率（継続性）
- 耐障害性（冗長化）
- 災害対策
- 障害回復性
などの項目について設計します。
稼働率は、導入するシステムが稼働しているべき時間を定め、1年間でどれぐらいの稼働（もしくは障害によるダウンの許容範囲）をパーセンテージで表すことが多いです。
（99.999%、ファイブナインなどを目指すことが多いですね）
耐障害性は、いわゆる冗長化です。
物理的な機器の冗長化から、仮想で動作するサーバの冗長化など片系障害時でもサービス提供可能とするためにどのような構成とするかを設計します。
災害対策は、比較的大きなシステムで設計することが多いです。
サーバ単位ではなくシステムを丸ごと冗長化し、物理的に離れたデータセンタなどにシステムをそれぞれ導入するなど天災等による障害への耐性として設計します。
障害回復性は、障害発生時の復旧目標時間やどの時点まで復旧することを目標とするかなどを設計します。
稼働率にも関係してくる部分でもあります。
3-3-2. 性能・拡張性
性能・拡張性では、システムにどの程度のパフォーマンスを出すように設計するか、将来的なリソース面の懸念などに対してどうするかを設計します。
性能は、システムがどのような機能を持つかにもよりますが、例えば
- ウェブサーバであればレスポンスタイム
- DNSサーバであれば同時に処理できるクエリ数
- メールサーバであれば1分間に送受信できる件数
などでしょうか。
性能は、提供する機能（サーバ）に対してそれぞれ設計するものと認識しておいても良いでしょう。
拡張性は、将来的にシステムを使うユーザーが増加した場合に、リソースの枯渇が発生したらどうするか？などを設計します。
主な方針としては、
- リソースを増やす
- システムを拡張する（サーバを増やすなど）
の2パターンに分けられると思います。
3-3-3. 運用・保守性
運用・保守性では、システムをどのように運用し、メンテナンスなどの作業を行うかを設計します。
可用性を考えて設計したとしても、時間が経過するにつれて劣化やバージョンが古くなるなどによって、どうしても人の手を入れなければならなかったり、安定稼働させるためにシステムで提供する機能とは別に定期的に行わなければならない動作などが発生します。
その際に、どのような運用を行うかを設計します。主に、
- 通常運用
- 障害発生時運用
- 定期保守運用
に何を行うかを設計することが多いです。
ここは設計書によっては、「運用設計」として大きなくくりで設計することもあるかもしれません。
通常運用では、システムの稼働時間（お客様の業務時間であることも多いです）や障害に備えたバックアップの運用、定期再起動運用をどうするかなどを設計します。
障害発生時運用では、障害が発生した際の基本的な対応方針を設計します。バックアップのリストアによる復旧、再起動による復旧、などになります。
定期保守運用では、使用するソフトウェアの新しいバージョンや脆弱性に対するパッチが出た場合の適用方針や、適用タイミング（適用までの流れ）などを設計します。
3-3-4. 移行性
移行性では、システムをどのように導入するかを設計します。設計する項目としては主に、
- 移行時期（導入時期）
- 移行方式（導入方式）
- 移行対象
などを計画するイメージです。
段階的にサーバ（機能）を導入していく、並行稼働期間を設ける、などです。
移行性というと、新規導入よりも既存システムのリプレイスの方がイメージしやすいかもしれません。
3-3-5. セキュリティ
セキュリティでは、システムの安全性を高めるためにどのような対策をするかを設計します。項目は多岐にわたりますが、主に
- アクセス制御
- 暗号化
- ウイルス対策
などを設計することが多いと思います。
アクセス制御では、システムにアクセスできるユーザーや権限だったり、システムの機能を使うことができるユーザーやIPなどの制限をどうするかを設計します。
暗号化では、システムで扱うデータを漏洩や盗聴などから守るために、どのように暗号化するか、暗号化方式、どこを暗号化するかなどを設計します。
ウイルス対策では、外部や内部からのウイルスからどのようにシステムを守るかを設計します。主にウイルス対策ソフトを導入するなどが多いかと思いますが、エージェントへのパターンファイル適用間隔をどうするかなどを設計します。
運用と近い部分もあるため、運用・保守性の設計と被る部分もあるかもしれません。
以上が、基本設計の主な設計要素とそれぞれの概要になります。
4. 最後に
いかがだったでしょうか。
本記事を書いたのは一部自分のためでもありましたが、少しでも基本設計のイメージが伝わっていると幸いです。
設計の仕方、設計書の書き方次第では多少変わる部分もあるかと思いますが、本記事に記載した内容のイメージを持っていれば大筋を外れることはないかと思います。
あとは設計した内容を文書という形で設計書に記載していくことになります。設計書記載についての記事もどこかで書けたらいいなぁ。。。そのうち書きます。
本記事を読んだインフラ系SEの方々が、少しでもシステム基本設計を効率よくできますように。