非エンジニアのプログラミングに要求仕様書は必要か

IT業界には仕様書やその前段階の要求仕様書と言った開発ドキュメントと呼ばれる書類があります。

非エンジニアがマクロやPythonでちょっとした自動化ツールを作るのにこうした開発ドキュメントが必要かどうか考えてみたいと思います。

そもそも要求仕様書と言うものが何のために存在するのか、から考えます。誰かに何かを作って貰うときに何を作って貰うか伝えますよね。レストランなら既存のメニューがあるので、これ、下さいと言うだけでOKです。

家で、きょう何食べたい？って聞かれたらカレーって言えばOKです。これは何故かと言うと、レストランなら既存メニューから選び、家でのカレーは毎回同じレシピなので、作り方がわかるからです。

要するに作る側の人が作り方がわかればいいのですね。でも、いつもと違う具のカレーが食べたかったら、それを伝えなくてはなりません。

つまり、きょうは豚肉では無く鶏肉をいれてほしいとか、そういうことです。何をしたいのかを明確にしてあげます。

私たちが自分自身の業務を自動化するためツールを作るのには、これで十分です。

カレーの例で言えば、きょうは鶏肉がいい、と言う例を挙げました。これは、家族がきょうは久しぶりにチキンカレーが食べたいんだな、と足りない言葉を脳内補完してくれてるから成り立つんですよね。

もし、親戚の家とかに行ったら、骨付きのフライドチキンがカレーの上に乗せられて、あ、こういうつもりじゃなかったんですけど… ってなるかもしれません。

よくわかっていない場合は、より細かく伝えないといけないと言うことですね。

自分自身のためのちょっとした便利ツールなら要求仕様書は要らないと言ったのはここです。自分は自分のやりたいことがわかっているので、要求仕様書を作る必要がありません。結構時間も掛かるので、やめとくのがいいと思います。

一方で人のためにツールやシステムを作る場合は手間はかかりますが、たくった方が結果的によいです。頼まれて作ってあげたのに、こういうのじゃないって言われたらお互い悲しいですよね。

カレーの場合、少なくとも材料と完成品は伝えておくべきでした。下ごしらえの方法は作る側に任せればいいので、せめて自分がほしいものを明確に伝えるべきだったわけです。半熟卵をのせてほしいときは何分くらいゆでたやつなのかも伝えた方が安全です。

「こんなはずじゃなかった」は個人レベルの便利ツール程度なら、簡単に修正できますし、所詮便利ツールなので、なかったらなかったで問題無いため、不要と考えられます。

それでは会社として正式に使っていくようなシステムを作ったり、作って貰うときはどうでしょうか。

こう言うことを考える時は、無かったらどうなるかを考えてみるのがオススメです。

要求仕様書が無かったらどうなるのか。要求が明確ではないので「こんなはずじゃなかった」が起きる。しかも要求が明確ではないので、修正してもまた期待はずれになる。

じゃあ、要求仕様書がなくても、たまたまバッチリなツールができたとしたらどうでしょうか。

ツールを開発した人がいなくなってしまうと、業務が変わったりして仕様を変更したいとき、その仕様変更を実装するのは困難です。

そのため、仕様書があれば改修ができます。しかし、仕様書が無くても要求仕様書があれば、一から同じものを別の人が作ることが可能となります。

私はここの意義が大きいと思います。最悪の場合でも、また作ればいい、という状況にできる事は、リスク回避の面で重要だからです。

半熟卵をカレーに乗せる例を書きましたが、料理したことがない人は何分くらい茹でたらいいのか検討もつきませんよね。そう、自分がほしいとき物はどうやったらできるのかを正確に伝えるのはかなり難しいです。依頼する側も少しは料理できる方がいい、と言うことです。

しかし、開発者側が依頼者に、あなたもプログラミング勉強してくれよ、というのはどう考えても方向違い。

だったら、せめて何をしてほしいのかを、具体的に聞き取って行きましょう。

トロトロの半熟卵がいいのか、ちょっと黄身が垂れるくらいがいいのか。ゆで時間はこっちで調べたるからそれくらい教えてよ、って感じです。

業務ではテキストで出力するのか、テキストなのかとか、そういうことです。

自分は何のためにその作業をしているのか、後工程は自分の作業結果をどう活用しているのか。

そう言ったことを整頓していくと、自ずと求めていることが分かってきます。まずは業務の棚卸し、整理から始めてみましょう

要求仕様書そのものの書き方は私より遥かに詳しい人達がたくさん解説しているので、そちらをご参照ください。

その時、プロのをそのまま取り入れは必要はありません。再現出来るところに重きをおけばよいと思います。

ゆんの業務改善ブログ