分かりやすい仕様書を考える

仕様を作る、という行為は極めて難解でかつ細かい作業です。たとえ企画を立案した人間であっても、仕様書をきちんと立てるのはかなり難しいでしょう。かく言う僕も、自分が作る仕様書が人に伝わりやすくて良くできた仕様書が構築できているかの自信はありません。とはいえ曲がりなりにも僕はプログラマーでもあるのだから、仕様書を作る時には僕が分かりやすくて組み上げる時に決まっていないと困る項目から遡っていって作るようにしています。
その上で抜けが無いかのチェックとか、文章の伝わりやすさとか、図をどうするとか色々あるとは思うんですけどね。

自分がプログラマーをやっている上で特に分かりやすい仕様書だなと思う点は主に2点です。
一つは構成している機能がきちんとブロック分けされていること。こういう機能です、こういう画面です、と言うことが書いてあるだけってのは実際のところ設計図としての仕様書としてはかなり不十分な事が多くて、計算式やユーザーの操作に対してどういった処理を行うのかが出来るだけ一つ一つ決めてあることが望ましいと思います。極端な話、画面イメージが無かったとしても機能リストとして成立するのであれば、その仕様書は分かりやすいものになってると思います。勿論実際にそんな仕様書を作るのは相当難しいと思いますけど、少なくともそういう心持ちで画面イメージや全体像は伝えるための補助に留める、くらいの方が仕様書としては分かりやすくて決め事がきちんと設定されている形になるかと思います。

もう一つは、想定されるパターンが多く記載されていることです。勿論これは実際に作っていく上で気がつくことも多い事だとは思うのですが、だからといって全く想定しないと確認事項が山盛りになることは火を見るよりも明らかでしょう。最低限、記載しているうちに浮かんだ疑問は自分で解決して処理優先や例外処理を記載するべきです。これによって前述のブロック分けも更に細分化されていくので、仕様策定と検証は出来るだけ繰り返すことでより良い仕様書になると思います。

企画職というのはどうしても感覚値を重視しがちなのですが、プログラミングというのは理論と構造の組み立ての塊。億劫がらずに言葉に落とし込んでいって、本当に伝えなければならない感覚だけを残すように心がけられると良いのですが。