・インフラ案件の要件定義と基本設計の違いがわからない
・要件定義書と基本設計書のどちらに書くべきか迷ってしまう項目がある

インフラプロジェクトをやっていると要件定義と基本設計の線引きが曖昧になってしまうことがあります。
「要件定義とは」、「基本設計とは」を解説しながら、それぞれの違いを把握できる構成にしました。

要件定義と基本設計の線引きが明確になっていると
どちらの設計書に書くべきか迷いにくくなるので、
業務効率化され、見やすい成果物の作成ができるようになります。

本記事のテーマはインフラ構築がこなせる程度の技術力を持っている方向けの話ではありますが、
インフラ初心者の方にもイメージしやすいようにまとめています。

※インフラ基礎知識が足りていないと感じる方には下記の記事もおすすめです。

本記事のテーマ

インフラ案件の要件定義と基本設計の違いについて書いています。
具体的には下記のとおりです。
・インフラ案件の要件定義で書くべきこと
・インフラ案件の基本設計で書くべきこと
・どちらに書くか決まってないこと、なぜかどちらにも書くこと

※インフラ案件全体の流れは下記の通りで、今回は上流工程の解説になります

要件定義と基本設計の違い

本記事でお伝えするインフラ案件の要件定義と基本設計ですが、
それぞれを一言でいうと
要件定義は「何をやるか決める」
基本設計は「どうやってやるか決める」
フェーズになります。

これを知っておくだけで「これは基本設計に書くべきことだな」とかの判断ができるようになります。
これが最重要でとりあえずこれだけは持って帰ってもらいたいです。

ここからはもう少しイメージできるように各フェーズについて詳しく書いていきます。

インフラ案件の要件定義で書くべきこと

要件定義で決めることは以下の３つになります。
・（コスト・スケジュールの制約を鑑みて）何をやるかを決める
　※要件定義書には決め手になった理由まで書く
・基本設計以降のフェーズのコスト見積もり
・本当にできるのか裏どりしておく

要件定義は大きく機能要件と非機能要件に分かれます。
※インフラ要件定義書はほぼ非機能要件です。

機能要件とは

お客様が作成する提案依頼書(RFP)、または開発の要件定義書に記載されていることを
インフラ要件に落とし込みます。
インフラの機能要件は、開発と違ってそこまで多くなく
下記くらいかと思います。

・システム構成（→サーバー台数、（Webサーバー、DBサーバーなどの）種別がわかるもの）
・必要なソフトウェア
・どんな通信が発生するか（通信要件）

非機能要件とは

インフラエンジニアがヒアリングしながら要件を固めていきます。
要件定義書の非機能要件の章はIPAが公表している非機能要求グレードに
沿った作りになっていることが多いです。
下記の資料を参考に非機能要件（可用性、性能・拡張性、セキュリティ、運用・保守）について解説します。

・（参考）経営に活かす IT 投資の最適化

可用性

可用性の章ではそのシステムの運用スケジュール（稼働時間・停止予定）や
RTO、RPOを定めます。

RTO（Recovery Time Objective）・・障害が発生してから何時間で復旧させるのか
RPO（Recovery Point Objective）・・障害が発生した際に、どの時点のバックアップまで戻すのか

参考：これだけは覚えて！「RPO」と「RTO」

可用性要件の分類例としては下記のようなものがあります。

参考：非機能要求を決めきる　－システム基盤の非機能要求を漏れなく決める－

要件を定めながら無理な要件になっていないか（本当に実現できるのか）は判断しておく必要があるので、
実現可否（復旧方法など）の調査もしておきます。

性能・拡張性

性能・拡張性の章ではシステムの性能上限をどの程度にするかを定めます。
クラウドであれば自動的に拡張させるか、拡張のさせ方も決めておきます。

セキュリティ

セキュリティだけはコスト度外視で要件を満たすことを前提に進めることが多いです。
具体的には下記のようなことを検討します。

・パッチ適用、ウイルス対策の頻度をどうするか
・通信はどこまで暗号化するか
・不正追跡は何年前まで調査できないといけないか（監査ログの保管期間）

運用・保守

今まで紹介してきた可用性、性能・拡張性、セキュリティの非機能要件を満たすには
運用・保守が必須になります。

監視、ジョブ管理、ログ管理、リリース管理といったインフラ運用に必須の要件については
それぞれ独立した章で定義することが多いですが、
カテゴリ的には運用・保守になると思います。

要件定義の業務の実際

インフラエンジニアが要件定義でやるべきことは
機能要件や非機能要件を整理してまとめることです。

これは下流フェーズ（詳細設計以降）の理解があればそれほど難しくありません。
なぜなら現場で要件定義書のフォーマットが用意されているのと、
類似案件に答えが書いてあってそれに従って書くだけだからです。
ただし書いたことの説明はできる必要があります。

※自分が大手のSIerしか経験なく、恵まれていただけかもですが
　もしフォーマットが無ければ下記のサンプルを纏めてくれているサイトなどを参考にすればよいかと思います。
　簡単・便利！現場ですぐに使える要件定義書テンプレート・サンプル7選+α
　https://itinfoshop.com/system-requirement-deliverable/

あとは開発やエンドユーザーに決めてもらう必要のある項目を洗い出して
ヒアリングシートにまとめて聞いたりします。

インフラ案件の基本設計で書くべきこと

基本設計書には要件定義書で定義した実現したい項目（何をやるか）に対する対応策（どうやってやるか）を書きます。
基本設計でお客様への確認事項をFIXさせ、
詳細設計、構築フェーズを「たんたんと作業を行うだけの状態」にすることを目標とします。

システム構成

要件定義書に書かれるシステム構成図をもう少し具体化していきます。
具体的には下記の資料を作成します。
・ハードウェア構成図・一覧
・ソフトウェア構成図・一覧
・ネットワーク構成図

下記の農林水産省『ハードウェア構成図』のサンプルが参考になります。

可用性

可用性要件に基づいて冗長構成やバックアップについて検討します。

・ハードウェアレベルの冗長性
下記は参考になりそうでした。
（クラウド案件では考慮不要なので、意識が薄れてきています。。）

※「インフラ設計のセオリー」という書籍はいろいろな方がおすすめしており、読んでみようと思いました。

・サーバー冗長化
停止許容時間が短いシステムの場合、
同一サーバーを複数台構築して上位にロードバランサーを配置して
負荷分散する方式が一般的です。

・バックアップ
RPO要件からバックアップ頻度を決定します。
RTO要件からリストア方式を決定します。

性能・拡張性

・性能
同時接続ユーザー数を鑑み、機能要件の応答速度を満たすような構成にしないといけません。
経験則でこれくらいの構成かなという風にざっくり決めることもあります。
性能懸念があるシステムの場合は性能試験を実施し、構成を確定させます。

・拡張性
拡張をスケールアップで行うか、スケールアウトで行うかを検討します。

参考：スケールアップとスケールアウトの違いとは？メリット・デメリットを解説

メリット・デメリットは上記サイトの通りです。
（サーバー台数増やすとライセンス数変わることがあるため、拡張の優先順位決めの時には要注意です。）

セキュリティ

設計要素としては下記のようなことがあげられます。
・パッチ適用頻度
・ウイルス対策ソフト導入
・ウイルススキャン設計（スケジュール、頻度、範囲）
・暗号化通信実装方式（SSL証明書管理）

セキュリティ対策について詳しく知りたい方は以下が参考になります。

運用・保守性

基本設計とは別に運用設計というフェーズがあります。
要件定義書と基本設計をインプットに設計します。（運用設計書という別紙に纏めることが多いです）

参考：運用設計って何をするんですか？

運用設計は上記の通りかなり広い範囲を網羅した形で記載されますが、
ここでは運用設計のことについては書きません。

基本設計書に記載する運用・保守関連の項目について記載します。
（システムの構成に影響する運用項目についてのみを記載します。）

基本的には「運用で何をやるのかを一覧化しておく」くらいでよいです。
（詳細は運用設計フェーズで確定させます。）

・運用作業一覧
・ジョブ一覧（運用スクリプト一覧）
・監視項目一覧
・ログ一覧
・リリース方式設計

まとめ

改めて再掲ですが
要件定義は「何をやるか決める」
基本設計は「どうやってやるか決める」
フェーズになります。

さいごに

初めて上流工程を任された時に上流工程の経験がないから不安はある
というのはものすごく分かるのですが、
下流工程の理解がしっかりできていればそこまで恐れることはないかなと思います。

新しいことを任されるとき、新しいことができないことは仕方ないと思ってもらえますが、
過去にやったことができなかった場合には大きな指摘をもらうことになります。

上流工程を始めたときに問題となるのは下流工程の知識不足がほとんどなので、
今下流工程を担当されている方は、今の経験を大事にすることが
上流工程を担当するための最良の準備になると思います。

参考資料

経営に活かす IT 投資の最適化
https://www.ipa.go.jp/files/000004568.pdf

これだけは覚えて！「RPO」と「RTO」
https://www.networld.co.jp/solution/learn_first/backup/1st/p08_10.html

非機能要求を決めきる　－システム基盤の非機能要求を漏れなく決める－
https://www.ipa.go.jp/files/000005263.pdf

運用設計…って、何をするんですか？『運用☆ちゃん』Incident 005
https://next.rikunabi.com/journal/20180427_t15_iq/

スケールアップとスケールアウトの違いとは？メリット・デメリットを解説
https://www.kagoya.jp/howto/engineer/itsystem/scale-up_scale-out/