読みたくなるような仕様書を書けと

2006/5/3 02:35

この記事ではアフィリエイト広告を利用しています。

ジョエル・オン・ソフトウェアはジョエルさんの個人的意見で書かれているらしいけど、内容が豊富でかなりタメになることが多いです。多分全部読んでからブログに感想書いてては最初のほうに読んだ内容をきっと忘れてしまうと思うので、まだ前半25%くらいしか読んでませんがちょっとメモしておこうと思います。「バグは最初のうちに潰しておけ」というのと同じですね。

この本の最初のほうで重点的に語られているのが「仕様書を書け」ということなのですが、ただフォーマットに沿ったつまらない仕様書を書くのは無駄であると述べています。まさにごもっともな話。大学時代の最初のほうでプログラミングの演習があって、課題のプログラムを作るときに「一緒に仕様書を書け」というのがあったのを思い出しました。このプログラムはどんなもので、使われている関数はどんなで引数と返り値はどんなで・・・といった内容を書くものでした。当時「こんなのわざわざ書いてどうすんねん」と思ってたのですが、やはりそのような形式でわざわざ書くのは無駄だったようです。

ジョエルさんが言う仕様書は、読み手が読みたくなるような面白さのエッセンスを加えた仕様書です。必要な機能が実例を交えて利用シーンを想像できるように書かれているのが良い仕様書であると述べています。とは言っても眞鍋かをりのブログのような文章で仕様書を書くのは行き過ぎかもしれません。人が読みたくなるような仕様書を書くためにはある程度の文才が必要で、そのために仕様書を書く専門の人がいるべきだとも書かれてました。もしくはプログラマに文章を書く勉強をさせなさいとも。(ブログ書いてりゃいいかな？)

前の会社でも開発担当でしたが、仕様書は多分ありませんでした。このアプリケーションがどういう機能を持っているかとか、こんな入力に対してどういう出力がされるかとかは全て実際にアプリケーションを使ってみるか、プログラムを日本語で書いた設計書を読むしかありませんでした。ある機能について質問されたときも、仕様書ではなく設計書の中を探したりしていて大変でした。

今の会社でも、仕様書がありません。「チームのメンバーそれぞれがぼんやりと頭の中で知っている」という状態かもしれません。私はまだ入って2ヶ月ちょいなので、既存のアプリケーションの動作に関して知らない部分がまだまだあります。なので分からない部分はソースコードを読み解くことで把握しようとしています。ソースを読むことは勉強になるのですが、仕様を把握するためにソースコードを読むのは時間がかかるので得策ではないのです。

読みやすい仕様書があればホント助かりますね。