第２話 要件定義書を書いてみる
「ここまで、自動的に設定してくれると助かります。
そして、ここは上限チェックを付けて……」
「ここまでを自動的に処理して欲しいです。
確認する必要があるので、結果は直ぐに分からないとダメです」
「それなら、ここの処理も週ごとに出して欲しいです。
稼働日の平均も出してくれると、比較しやすいですね」
「５年前までのデーターを保持してください。
法律で決まっていますので」
今現在、新しく担当することとなった客先で、北地課長と一緒に要望を聞いて回っている最中だ。
実はこの直前に、北地課長が「システムを考える前に、実際に使用する方々からも要望を聞きたい」と発言した。
（何故だろう？）と？で俺の頭の中は一杯になっていた。
それまでにも、こちらの担当者からシステムに対する要望を延々と聞かされていたからだ。
この事は、北地課長と会社に帰り、今日の打ち合わせの擦り合わせと称して話していた時に納得させられた。
「あそこで、作業されている方の話を聞きに行ったのは、実際に動かしている画面を見たかったのと、操作中に気づいたことを教えて欲しかったからなんだ。
聞かれて答える内容は、ある程度ふるいに掛けられた内容だけなんだ。
捜査している内に、「こう言うのも欲しい」って気が付くことも有って、それが無いと予想以上のストレスになることがあるんだ。
それが積み重なって、低い評価になってしまう事もある。
どうせ作るのなら、少しでも現場の声に答えた方が良いと思う」
「実際に使うのは現場の人ですもんね」
「そうなんだよ。
偶に担当者の方が考えた機能と、現場で要望される機能でぶつかることがある。
そんな時は、現場の人を巻き込んで、現場の声を優先した方が良いよ」
『僕の考えた最強のシステム』より、使う人の声を反映させたシステムの方が良いって事か。
俺達が考えて作った機能でも、使う人が『使い難い』って思ったら使われなくなるだろうしな。
そんなこんなで、ヒアリングの結果を纏めて要件定義書を作成する。
出来上がった要件定義書の機能は盛り沢山だ。
殆どの事が作業せずに処理されるという、正に夢のようなシステムだ。
例えるならば、材料をそのまま入れたらフランス料理のフルコースが出来上がる様なシステムを構築するような感じだ。
「流石に、これはこのまま出せませんよね……」
出来上がった要件定義書を北地課長へ提出すると、「そうだね、もうちょっと分かりやすい言葉にしてくれると良いかな？」との返事だった。
「分かりやすい言葉ですか？」
「うん、相手は業務知識はあるけど、システムの事は全く知らないズブの素人なんだ。
そんな相手に対して、業界用語や略語を使っても分からないだろう？ 要件定義は、そんな人にも分かるようなものを作らないとだめなんだ」
「はい、分かりました」
「それに、そこに書かれているものが全部作ることになるとは限らない。
まぁ、良くても半分くらいかも知れないね。
全部の機能を作るだけの予算は取れないと思うから。
これを見ながら、取捨選択をしていくんだ」
「はい、ありがとうございます」
席に戻り、要件定義書を素人でも分かるようなものにしていく。
どうすれば良いか？ とも思ったが、業界用語や略語をネット検索して出てきた説明を参考にして修正していく。
随分と文書としての量は増えてしまったが、分かりやすくなったのではないかと思う。
