私は、学生の頃からプログラミングをしている。まぁ、オリジナリティ溢れる創造性の高いものなんて作ったことはないが、まぁ、簡単なWebなシステムだったらだいたい思ったものを作ることができていた。当時の仕様は、どこにあるか、というと、それは私の頭。

そして、私は、自分でこんなのあったらいいなぁ、と思ったものを作っていた。また、人から頼まれ簡単なプログラムを作成したこともある。まぁ、それらは基本的に小規模なシステムだったので、仕様は私の頭の中ということが可能だった。しかし、学生時代に少し大きめのシステムを作成することを頼まれ作っていたが、途中で放り投げてしまったものがある。放り投げておいた私が言うのもなんだが、あれは、リリースしなくてよかったと思う。リリースしていたら、今頃、いや、もっと前に悲惨なことになっていただろう。しかしながら、お世話になっておきながらシステム開発を放り投げておいて申し訳ない気がして、その依頼者に顔を合わせることはできない。それでも、リリースはしなかったことが不幸中の幸いと感じる。

今は、会社で働いている。確かに学生の頃よりは、マシなものを作っている。セキュリティにも敏感になってきたし、コーディングのレベルも上がってきている。しかし、不満がないことはない。今思っている不満と、前の自分のシステム開発失敗のケースはちょっと似ていて、同じような気持ちにさせられる。両方に一致することは。要求仕様を決めるのは、自分ではないということである。それは、学生の頃も今も仕事の依頼者、さらにその先にいる他の依頼者が要求仕様を決める人となる。そこで、依頼者の曖昧な表現をシステム化するために、要求仕様を詰めなければいけない。これを怠ると崩壊する。後々になって、要求仕様が曖昧なため、ここは、どうしよう。。。と考え、依頼者に聞くと、「うーん、じゃぁ、こうして。」って変更依頼が来る。また、すでに決まったことでさえ、「やっぱり、あれは辞めて、このようにして。」って変更依頼が来る。そこで時間の関係と急な変更により、アドホックな解決手法を選択する。変更が少数である場合は、被害が少ないだろう。しかし、数が多い場合と致命的な場合は、崩壊を招く。

まぁ、仕様変更はよくあることなので、しょうがない点も多々ある。しかし、それでも、ある時点までの要求の詰めにより、ある程度は、防ぐことが可能であると考える。被害を最小にするために。そして、底辺の開発者が、要求仕様決定のインタフェースである人と険悪な関係とならないように。

もちろん自分のために作るシステムも要求仕様が大事だが、それは自分の責任の範囲内で行う。しかし、会社の仕事としては、それは、自分の責任の範囲外となる。往々にして、会社で作成しているシステムの要求仕様は詰まってないなぁ、と感じる今日この頃。