インフラの要件定義について

IT インフラエンジニアとして20年間キャリアを積み重ねてきましたが、改めてインフラの要件定義について考えてみました。

実際日常の業務を振り返ってみると「要件定義」なんてものは全く意識せずに、「CPU 2個、メモリ 8GB Linux サーバ1台」なんていうレベルで EC2 インスタンスを構築しているような感じで、要件定義を考える暇なく次から次へとサーバを構築しているような感じです。

要件定義とは何か

要件定義はシステムを開発するうえで必ずやらなければいけません。

必要ではなく必須（ひっす）です。

必要だと、なくてもいいような印象になりますが、要件定義は必要ではなく「必須」です。

つまり、必ずなければいけません。

ユーザーさんがお金を払ってでも作りたいということは、何かしら「やりたいこと」「目的」があります。

例えば、「作業工数を減らしたい」「同じ作業を自動的に短時間でやりたい」「数字を入れたら自動的に計算結果が欲しい」などです。

当然ユーザーさんにヒアリングをしてもあいまいになるはずなので何度も繰り返し聞き、具体化していかなければいけません。

インフラにとって要件定義とは非機能要件になる

まずは目標（ゴール）を決めなければいけません。

何をしたいのか？何ができたらいいのか？どんな課題があるのか？

社内SEの場合は経理の人が勘定奉行を使いたいと言ってきたとします。

その場合は、当然「DBは冗長化して可用性を高めて、障害を想定してバックアップは1日2回取得してください。」なんてことは言うはずはありません。

おそらく「別に要件はないが、使えればそれでいい」と答えると思います。

それで「ああそうなんですね」とサーバ1台だけ構築してバックアップも取らない場合、いざ何かあると「バックアップから戻して」とか「え？バックアップ取ってないの？」とか1台構成でディスク障害が発生して障害対応をすると、「何で長時間使えないの？」とか平気で言ってきます。

ここらへんの機能要件ではない非機能要件がインフラエンジニアにとってメインの業務になりますが、ユーザーさんが要件を言ってくることはほぼほぼ、100%ないと言っていいでしょう。

経理の人なら「IT を知らないだろうな」と警戒して細かく要件を聞き出すことをすると思いますが、開発側が依頼をしてきた時も要注意です。

しかも開発のメンバーはインフラにも詳しかったりするので、普通に要件を聞き出したして、「これで要件は固まったな」思ってサーバを構築して引き渡し後に「あれ？使えない」ということがあります。

結局、要件を聞き出しても10%くらいしか聞き出せてないと諦めて、残りの90%を自分で考えなければいけません。

ユーザーさんと打ち合わせをして何をしたいのかをヒアリングし、どのようなシステムが求められているのかを明確にし、具体的に必要な機能を洗い出すためにどうすればいいのか。

例えば非機能要件のヒアリングシートを作成してお郁、ユーザーさんに入力してもらうとか、一生にヒアリングシートを埋めるとかしないといけません。

非機能要件とは

ユーザーさんにとってシステム開発とは、ある数値を入力すると、この数値が出力されるなど、特定のシステムの話になりますが、インフラの場合は大体決まっています。

ルールや標準化ができていれば楽

非機能要件で聞き忘れて後から変更ということがあります。

もう1回作り直しとか。

そんなことがないようにするためにあらかじめルールや標準を決めておくと楽です。