【インフラエンジニア向け】 要件定義と基本設計の違い 當眞 尚平 2023/11/14 

1.自己紹介 2.はじめに 3.要件定義とは 4.基本設計とは 5.まとめ 目次 

自己紹介 2023/11/13 

自己紹介 2023/11/13 ⚫名前：當眞 尚平（とうま しょうへい） ⚫所属：株式会社SHIFT サービス＆テクノロジー本部 ITソリューション部 ⚫クラウドエンジニア、コンサルタント ⚫略歴 2012年 インフラほぼ未経験だったもののお客様に近い立ち位置でインフラ案件に参画。 2016年 AWS案件に初参画。AWSの便利さに感動し今後はAWS案件一択にさせてもらう。 2021年 AI勉強のためAWS DeepRacerを始める。 MLOpsエンジニアを目指す。 2023年 現職入社。AWSコンサルタントとして従事。 

案件略歴 2023/11/13 サーバ・ネットワーク周 りの新規構築案件。基 礎スキル固めの時期 AWS案件に初アサイン。 超優秀なITアーキテクト の方に圧倒的な差を感 じながらいろいろ学ぶ AWS案件でプロマネに抜擢！ しかしスキル不足で炎上。。 AWSの大規模新規構築 案件にCI/CDリーダーとし て参画も開発スキル不足 で炎上。。 AWSシステム運用・提案案件 IaC導入の提案をし、 運用を実現させる AWSクラウドネイティ ブ、サーバレス化支 援案件 2012年 2016年 2019年 2017年 2018年 2022年 2023年 新規AWS構築案件でIaC （Terraform）推進リーダー IaC、CI/CDの提案、 要件定義案件にコン サルタントとして参画 

はじめに 2023/11/13 

対象者について ・インフラ案件の要件定義と基本設計の違いがわからない ・要件定義書と基本設計書のどちらに書くべきか迷ってしまう項目がある インフラプロジェクトをやっていると要件定義と基本設計の線引きが曖昧になってしまうことがあります。 「要件定義とは」、「基本設計とは」を解説しながら、それぞれの違いを把握できる構成にしました。 前提知識：インフラ案件の詳細設計、構築経験 2023/11/13 

本日得られること 要件定義と基本設計の線引き（※）が明確になっていると どちらの設計書に書くべきか迷いにくくなるので、 業務効率化され、見やすい成果物の作成ができるようになります。 ※後述しますが、案件によって線引きが変わるのでそれも意識できていると良いです。 2023/11/13 

本日の説明範囲 インフラエンジニア 要件定義 基本設計 詳細設計 構築 統合・ テスト 導入・受 入れ支援 運用・保守 本日解説範囲 下流工程 インフラ案件全体の流れは下記の通りで、今回は上流工程の解説になります。 上流工程 

要件定義と基本設計の違い 本日お伝えするインフラ案件の要件定義と基本設計ですが、 それぞれを一言でいうと 要件定義は「何をやるか決める」 基本設計は「どうやってやるか決める」 フェーズになります。 これを知っておくだけで「これは基本設計に書くべきことだな」とかの判断ができるようになります。 これが最重要でとりあえずこれだけは持って帰ってもらいたいです。 ここからはもう少しイメージできるように各フェーズについて詳しく話していきます。 2023/11/13 

要件定義とは 2023/11/13 

インフラ案件の要件定義で書くべき こと 要件定義で決めることは以下の３つになります。 ・（コスト・スケジュールの制約を鑑みて）何をやるかを決める ※要件定義書には決め手になった理由まで書く ・基本設計以降のフェーズのコスト見積もり ・本当にできるのか裏どりしておく 要件定義は大きく機能要件と非機能要件に分かれます。 ※インフラ要件定義書はほぼ非機能要件です。 2023/11/13 

機能要件と非機能要件の違い 【機能要件】 画面遷移イメージなどのこと。 開発エンジニアがメインで担当 RPFをインプットにする 【非機能要件】 性能要件などのこと。 インフラエンジニアがメインで担当 RPF、開発の要件定義書をインプットにする RFPには記載が無いことが多い 2023/11/13 

機能要件とは お客様が作成する提案依頼書(RFP)、または開発の要件定義書に記載されていることを インフラ要件に落とし込みます。 インフラの機能要件は、開発と違ってそこまで多くなく 下記くらいかと思います。 ・概要レベルのシステム構成（→サーバー台数、（Webサーバー、DBサーバーなどの）種別がわかるもの） ・必要なソフトウェア ・どんな通信が発生するか（通信要件） 2023/11/13 

非機能要件とは インフラエンジニアがヒアリングしながら要件を固めていきます。 要件定義書の非機能要件の章はIPAが公表している非機能要求グレードに 沿った作りになっていることが多いです。 下記の資料を参考に非機能要件（可用性、性能・拡張性、セキュリティ、運用・保守）を行います。 ※非機能要求グレードは成果物の一部にもなるのでおすすめです。 ・（参考）経営に活かす IT 投資の最適化 https://www.ipa.go.jp/files/000004568.pdf ・非機能要求グレード活用表 https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html 2023/11/13 

可用性 可用性の章ではそのシステムの運用スケジュール（稼働時間・停止予定）やRTO、RPOを定めます。 ※RTO、RPOについて RTO（Recovery Time Objective）・・障害が発生してから何時間で復旧させるのか RPO（Recovery Point Objective）・・障害が発生した際に、どの時点のバックアップまで戻すのか 2023/11/13 

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

セキュリティ セキュリティ要件は満たすことを前提に進めることが多いです。 エンドユーザー側が細かい要件を持っていることもあります。 具体的には下記のようなことを検討します。 ・パッチ適用、ウイルス対策の頻度をどうするか ・通信はどこまで暗号化するか ・不正追跡は何年前まで調査できないといけないか（監査ログの保管期間） 2023/11/13 

運用・保守性 今まで紹介してきた可用性、性能・拡張性、セキュリティの非機能要件を満たすには 運用・保守が必須になります。 監視、ジョブ管理、ログ管理、リリース管理といったインフラ運用に必須の要件については それぞれ独立した章で定義することが多いですが、 カテゴリ的には運用・保守になると思います。 2023/11/13 

要件定義の業務の実際 インフラエンジニアが要件定義でやるべきことは機能要件や非機能要件を整理してまとめることです。 これは下流フェーズ（詳細設計以降）の理解があればそれほど難しくありません。 なぜなら現場で要件定義書のフォーマットが用意されているのと、類似案件に答えが書いてあってそれに従って書くだけだからです。 ただし書いたことの説明はできる必要があります。 ※もしフォーマットが無ければ下記のサンプルを纏めてくれているサイトなどを参考にすればよいかと思います。 簡単・便利！現場ですぐに使える要件定義書テンプレート・サンプル7選+α https://itinfoshop.com/system-requirement-deliverable/ あとは開発やエンドユーザーに決めてもらう必要のある項目を洗い出してヒアリングシートにまとめて聞いたりします。 2023/11/13 

基本設計とは 2023/11/13 

インフラ案件の基本設計で書くこと 基本設計書には要件定義書で定義した実現したい項目（何をやるか）に対する対応策（どうやってやる か）を書きます。 基本設計でお客様への確認事項をFIXさせ、詳細設計、構築フェーズを「たんたんと作業を行うだけの状 態」にすることを目標とします。 【基本設計書で書くこと】 ・機能要件に対する対応策（システム構成、ソフトウェア構成、ネットワーク構成） ・非機能要件に対する対応策（可用性、性能・拡張性、セキュリティ、運用・保守） ・案件独自に利用するサービスごとの設計（※解説対象外） 2023/11/13 

機能要件に対する対応策 要件定義書に書かれるシステム構成、ソフトウェア構成図をもう少し具体化していきます。 サーバー: 各サーバー（Webサーバー、データベースサーバー等）の役割や接続関係を示します。それぞれ のサーバーにどのソフトウェアを導入するかまで記載すると良いです。 ネットワーク：ロードバランサー、VPN接続なども含めます。 外部接続: インターネットや他の外部システムとの接続ポイントを明確にします。 セキュリティ対策: ファイアウォールの位置や、セキュリティゾーンの区切りなど、セキュリティに関する情報も含め ます。 バックアップ: バック保管場所など、バックアップの概要を示します。 2023/11/13 

非機能要件に対する対応策 可用性 可用性要件に基づいて冗長構成やバックアップについて検討します。 ・サーバー冗長化 停止許容時間が短いシステムの場合、 同一サーバーを複数台構築して上位にロードバランサーを配置して 負荷分散する方式が一般的です。 ・バックアップ RPO要件からバックアップ頻度を決定します。 RTO要件からリストア方式を決定します。 2023/11/13 

非機能要件に対する対応策 性能・拡張性 ・性能 同時接続ユーザー数を鑑み、機能要件の応答速度を満たすような構成にしないといけません。 経験則でこれくらいの構成かなという風にざっくり決めることもあります。 性能懸念があるシステムの場合は性能試験を実施し、構成を確定させます。 ・拡張性 拡張をスケールアップで行うか、スケールアウトで行うかを検討します。 （サーバー台数増やすとライセンス数変わることがあるため、拡張の優先順位決めの時には要注意です。） 2023/11/13 

非機能要件に対する対応策 セキュリティ セキュリティエンジニアという職種があるくらいにセキュリティで考えることは多いです。 ここではインフラエンジニアが考える必要のある項目のみに抜粋して記載します。 （AWSでは簡単にセキュリティ実装する方法があり、インフラエンジニアが全て対応できるようになってきていま す。） インフラエンジニアとして設計が必要になる要素としては下記のようなことがあげられます。 ・パッチ適用頻度 ・マルウェア対策ソフト導入 ・ウイルススキャン設計（スケジュール、頻度、範囲） ・暗号化通信実装方式（SSL証明書管理） 2023/11/13 

非機能要件に対する対応策 運用・保守性 基本設計とは別に運用設計というフェーズがあることが多いです。 運用設計はいつ誰が何をやるかを明確に定義する必要があり、 要件定義書と基本設計書をインプットに設計します。 ここでは運用設計のことについては書きません。 基本設計書に記載する運用・保守性の章はシステムの構成に影響する運用項目についてのみを記載します。 具体的には以下のようなことを記載します。 ・運用作業一覧（運用で何をやるのかを一覧化） ・ジョブ一覧（運用スクリプト一覧） ・監視項目一覧 ・ログ一覧 ・リリース方式設計 2023/11/13 

まとめ 2023/11/13 

まとめ 改めて再掲ですが 要件定義は「何をやるか決める」 基本設計は「どうやってやるか決める」 フェーズになります。 これを知っておくだけで「これは基本設計に書くべきことだな」とかの判断ができるようになります。 これが最重要でとりあえずこれだけは持って帰ってもらいたいです。 2023/11/13 

さいごに 私自身、初めて上流工程を任された時は不安だったのですが、 今思うと下流工程の理解がしっかりできていればそこまで恐れることはなかったなと思います。 新しいことを任されるとき、新しいことができないことは仕方ないと思ってもらえますが、 過去にやったことができなかった場合には大きな指摘をもらうことになります。 上流工程を始めたときに問題となるのは下流工程の知識不足がほとんどなので、 今下流工程を担当されている方は、今の経験を大事にすることが 上流工程を担当するための最良の準備になると思います。 2023/11/13 

ご清聴ありがとうございました 2023/11/13