インフラエンジニアの上流工程その２
前回、下記の記事でインフラエンジニアの上流工程の中の「提案」について紹介させていただきました。
今回は「提案」後、プロジェクトの最初に行われるインフラエンジニアの「要件定義」について、紹介させていただきます。
要件定義とは
要件定義はお客さんのやりたいことをまとめていく作業になります。
例えば、「どのターゲットに対して商品を売っていけばよいか、分析したい」といったようなやりたいこと（要件）を整理していきます。
要件定義は大きく、機能要件と非機能要件にわかれまして、インフラエンジニアとしては非機能要件をまとめていくことになります。
機能要件というのは、先ほどの「どのターゲットに対して商品を売っていけばよいか、分析する」ための機能のように、システムがどんな機能を持てばよいかの要件のことです。
非機能要件は機能ではない使い勝手の部分だったり、システムの安定性、拡張性といった要件のことです。
例えば、「どのターゲットに対して商品を売っていけばよいかを分析する」のに、1か月かかると言われたらそんなシステムは使いたくないですよね。
非機能要件では、そのシステムのレスポンス速度を設定したりします。
そうなるとレスポンス速度を3秒とかに設定すれば、要件定義は終わりかというとそういう単純なものではありません。
利用者が何人いて、分析するためのインプットのデータが何TBでとか、そういった前提を決めておかないと、後で実現不可能な要件定義が出来上がってしまいます。
インフラエンジニアの要件定義
先ほど、インフラエンジニアは非機能要件をまとめていくとお話ししました。
非機能要件というのはどういったものがあるかというと、以下のようなものがあります。
・可用性
・性能拡張性
・運用・保守性
なんだ、意外と少ないなと思われるかもしれませんが、それぞれの要素はかなり多く、まじめにやると240項目ほどの要件整理が必要です。
この240項目についてはIPA（情報処理推進機構）のサイトで確認することができます。
※非機能要求グレード本体を参照してください。
インフラエンジニアを目指す方、現役の方、アプリケーションエンジニアの方、必見の内容になっています。
要件定義のコツ
非機能要求グレードに沿って、お客さんの要件をまとめていけばいいなんて、上流工程も楽勝だなと思われるかもしれませんが、そう、簡単にはいきません。
要件定義のコツとして、下記のポイントに注意をしながら進めていく必要があります。
・実現可能であるか
・予算は超えないか
要件定義を進めていくと、何でもかんでも最高レベルの品質が設定されていきます。
例えば、システムの利用時間が9時から17時までで十分なのに、24時間365日稼働させるといった、要件を設定してしまうと、システムは全て多重化して、運用体制は三交代勤務の体制になります。
こうなってくると、当初設定していた予算を軽く超えるシステムになってしまいます。
要件定義が当初想定していたシステムとは異なるものが出来上がりそうな時は、
要件定義の段階で、その要件入れると予算超えてしまいますよ、
とか、
それをやると休日出勤や夜間勤務増えちゃいますよ、
と言った牽制を入れつつ想定していた構成に近づくような要件定義に近づけていくのが重要です。
ある程度、完成形を想定して要件定義をしていかないと、プロジェクトの終盤で要件定義のときと話が違うじゃないかとか、なんとか予算内に抑えろといった揉め事が多発します。
私も社内SEなので気持ちはすごくわかるのですが、お客さんは夢見がちです。
夢の世界から現実に引き戻すのも、SIerの大事なお仕事です。
最後に
いかがでしたでしょうか。
今回は上流工程の中の要件定義について紹介しました。
インフラエンジニアとしては非機能要件を定義していくことになります。
この非機能要件をうまくコントロールしないと、プロジェクトの後工程で揉め事が発生しますので注意していきましょう。
また、今回紹介した非機能要求グレードも是非、一読してみてください。