#目次
1.はじめに
2.全体概要
3.要件定義フェーズ
1.はじめに
簡単に自己紹介と記事掲載の背景と目的を書きます。
自己紹介
・新卒2年目のインフラエンジニア
・大学時代にC言語を授業で受けていたが、全くわからず。。
・入社後の研修では、Javaの研修がメイン(研修でインフラはあまりやってない)
記事掲載の背景と目的
1つの案件で、要件定義～運用までの全行程に関わる機会があり、とてもたくさんの気づきを得れました。
私がその案件で得た学びが「1〜2年目のインフラエンジニア」の方や「インフラ案件を初めてやるよ！」という方の参考になればと思い記事を掲載しています。
※私の経験ベースなので、多少一般論と異なることもあるかもしれませんが、ご了承ください。
2.全体概要
まず簡単にどんな案件なのかの説明から。
私は、EOSL(End of Service Life)を迎えるHWとSWのライフサイクル対応を行っていました。
ん？どういうこと？という方向けにもう少し簡単な説明を！
そもそもサーバやOS、ソフトウェアなどには保守期限（保証期間みたいなもの）があります。
保守期間内であればサーバなどに障害が発生した際にベンダーが対応してくれます。
もう少し実生活に近づけて例えるならば、電化製品を購入の際に「○年保証します！」という保証書が入っていますよね？
その保証期間と同じようなものをイメージしていただければ大丈夫です。
この保守期限を過ぎてしまった場合、ベンダーが障害対応をしてくれません。
となると、障害の発生で業務やサービスが長時間停止してしまう可能性が出てきます。
サービスの停止によって多額の損失を得るなんてことも。
その状態は好ましくない！ということでサーバの置き換え対応を行いました。
じゃあその案件は、全体的に案件がどう進んでいるの？という説明を。
インフラ案件は、サーバなどのHWの購入等で後戻りしづらいことから基本的にウォーターフォールモデルで進んでいます。
ウォーターフォールモデルとは？という方向けに簡単な説明を！
ウォーターフォールモデルとは？
ウォーターフォールモデルとは、図2.1のようにシステムの要件定義から設計、製造、テストまで、各開発フェーズを段階的に進めていく開発モデルです。フェーズごとに進んでいくことから、仕様変更や前のフェーズに不足が発生した場合、前のフェーズに戻り、やり直さなければなりません。
詳しくは以下サイトをご覧ください！
https://system-engineer.jimdo.com/ウォーターフォールモデル/
図2.1,ウォーターフォールV字モデル
余談ですが、各フェーズでODSCというフレームを意識して進めていくと、うまく進んでいくのでは？と思ってます！
ODSCの内容は以下参照。
http://global-optimum.com/blog/2010/06/プロジェクトの計画と実行-odsc-とは？/
私が参画した案件をベースに各フェーズについて紹介していきます。
（本記事では、要件定義のみです！以降のフェーズは次回の記事までお待ちください！）
3.要件定義フェーズ
要件定義を一言で言うと、
「お客様の要望を元に、システムの機能や性能を定義すること」です。
で、実際にどんなことするの？
という視点で続きを書いていきます。
要件定義フェーズでは、以下の内容を決め、要件定義書が作成します。
・プロジェクトの進め方
・機能要件
・非機能要件
インフラエンジニアの仕事は非機能要件がメインとなります。
では、それぞれの項目ではどのようなことを決めるのかもう少し詳細に書いていきます。
プロジェクトの進め方
プロジェクトを進めていく上で必要な以下の項目を定義します。
プロジェクトの目的
今回は、「EOSLによって非サポートとなるHWとSWを最新化することで、サポートを受けられる状態にすること」
を目的と置いています。
プロジェクト体制図
それぞれの役割を明確にし、誰が何をしているかが明確にわかる図を作成します。
以下の図は例として参考にしてください。
https://www.it-innovation.co.jp/2010/08/17-145655/
図3.1.プロジェクト体制図
連絡ツールとルール
必要な連絡ツールとルールを定義します。
メールとなる場合、プロジェクトの名称を件名に付与するようにルールを指定する場合があります。
機能要件
機能要件とは、どのような機能がそのシステムに必要なのかを定義したものです。
フリマサイトを例にあげると、
・商品の売買ができること
・ユーザーの登録ができること
etc…
などが挙げられます。
非機能要件
非機能要件とは、機能要件以外の要件を指します。
以下に具体例を書きます。
・可用性要件（可用性、耐障害性、災害対策、回復性、成熟性）
- サーバの稼働時間はいつからいつまで？
- シャットダウンはしても平気？
- もしサーバに障害が起きたら何分以内に復旧が必要？
などを決めていく
・性能・拡張性（業務処理量、性能目標値、リソース拡張性、性能品質保証）
- レスポンススピードはどのくらい？
- データ処理ってどのくらいするの？
- どうやって拡張できるようにする？
などを決めていく
・運用・保守性（通常運用、保守運用、障害時運用、運用環境、運用・保守体制、運用管理方）
- どんな風に運用していくの？
などを決めていく
・移行性（移行時期、移行方式、移行対象（機器）、移行対象（データ）、移行計画）
- 何をいつどうやって移行するの？
などを決めていく
・セキュリティ（前提条件・制約条件、セキュリティリスク対応、セキュリティ診断、セキュリティリスク管理、アクセス・利用制限、データの秘匿、不正追跡・監視、ネットワーク対策、マルウェア対策、Web対策）
- システムの安心をどう守る？
などを決めていく
・環境・エコロジー（システム制約/前提条件、システム特性、適合規格、機材設置環境条件、環境マネージメント）
- 耐震/免震、重量/空間、温度/湿度、騒音
などを決めていく
以上の項目をまとめ、要件定義書を作成すれば要件定義フェーズ完了です。
基本設計以降は次回の記事（複数出す予定）に記載しようかと思いますので次回記事を乞うご期待ください！！！