まとめ

要求分析は、どんなシステムを作りたいかという要求を詳細にまとめるもので す。そして、要求をすべて網羅していないといけません。要求をすべて把握で きてはじめてそれに最適なシステムを作ることができるのです。開発するエン ジニアは開発対象であるシステムの使われ方については何の知識も持っていな いのが普通です。例えその業界では常識となっていても普通の人からすると意 外に思うことはいくらでもあります。こういう場合、その業界では常識となっ てしまっているが故に、単に発注側の人から話を聞いただけではそういった話 は出てこないのが普通です。開発者の側から質問をしなくてはいけません。

発注者の側から話を始めると、彼らが自分の思っている事をとりとめもなく話 し始めます。それを聞くとなんとなく相手の要求がわかったような気がしてし まい、その場はそこで聞くのをやめてしまいがちです。しかし、実際に作り始 めてみると様々な疑問が湧いてきます。要するに相手の要求が実際のところわ かってはいなかったのです。相手の要求を網羅的に聞き出すには相応の手順が 必要です。だから、発注者の側から話しはじめるのではなく、開発者側から手 順通りに質問を始めなくてはいけないのです。

対象となるシステムについて何の知識もないのにどうやって質問を始めるか？ この問題を解決するのがユースケース分析です。ユースケース分析はこう教え ています。まず誰が使うのかを尋ねなさい、そしてその人が何をするのかを尋 ねなさい、と。これで話の糸口をつかむわけです。こうして手順通りに網羅的 に質問を重ねていくわけです。

要求を持っているのは開発側ではなくシステムを発注する側です。しかし残念 なことに発注側はソフトウェアのプロではないため、要求を詳細に分析するこ とができません。だからこの作業はソフトウェアのプロである開発側のエンジ ニアが発注側の人に直にヒアリングして行うべきです。対話で進めていく作業 ですから、FAXによる質問状では往復に時間がかかりすぎて現実的ではありま せん。せめて電話、できれば会議室で面と向かって話をすべきです。相手がリ アルタイムでやりとりできる場合に限っては電子メールやチャットを活用して もよいかと思います。