楽しい仕様書と生産性に関する考察

結論：楽しい仕様書は将来にわたってチームの生産性を向上させる。

仕様書を書く効果

『Joel on Software』（オーム社 2005）でジョエルはこんなことを書いている。

「仕様書の最も重要な役割はプログラムをデザインすることだ。」

仕様書を書くには設計することを強いられる。仕様書段階での設計は、実装しながらする設計に比べてはるかに簡単にレビューでき、手直しできるので、生産性の向上につながる。ジョエルはこうも言っている。

「大きな理由の2番目はコミュニケーションにかかる時間を節約できるということだ。」

仕様書を1度書くだけで、実装時やテスト時に何度も参照され、コミュニケーションコストを大幅に節約するし、認識の齟齬を防げる。このとき、ちゃんと皆に仕様書を読んでもらうには、楽しく（可笑しく）読める仕様書が大切になってくる。

先ほどの設計の話と合わせて、仕様書を書くということは開発からテスト、保守まで含めた生産性を向上させることは明らかだ。

話は変わって『Peopleware』（日経BP社 2013）を取り出そう。ニューサウスウェールズ大学での調査の結果として、こんなことが書いてある。

「上司が日程的なプレッシャーを少しもかけなかったプロジェクトは、最高の生産性を示した」

私の個人的な経験から、生産性が高いのはやるべきことがはっきりしている、つまりどうやって実装したらいいか道筋が見えているときだ。そういうときは、期日の目標値を定められないで放任されるほど、高品質なものが早く完成する傾向にある。仕事への誇りからくる高生産性だと思う。

逆に、生産性が低いのは、対象の理解ができておらず、何から手を付けるか分からないときである。こういうときは、タスクをやらなくちゃと思いつつ、何も進まずに非生産的な時間を過ごしてしまう。強制的に期日の目標値を定めてもらわないと仕事が進まないケースだ。

このように、上司が強制的に期日を設定するのが必要なときもある。しかし、その生産性は、やるべきことが見えているときに放任される場合の生産性よりずっと低い。

チームの生産性を常に最高に保つにはどうすればよいか。自分たちのチームに新たに配属された人が、そのチームで作っているソフトウェアをよく理解できるようにしておくことだと思う。もちろん、そうしておけば新人だけでなく既存メンバーがよりよくソフトウェアを理解することにもつながる。

メンバーが対象ソフトウェアをよく理解していれば、ソフトウェアの修正タスクに対する実現方法が思いつきやすくなる。この状態になれば、期日を設定せずタスクを割り当てることができ、自動的に最高の生産性を発揮するはずである。

つまり、楽しく読め、きちんと対象を理解できるような仕様書をいつでもちゃんと書いておくことは、後々、そのチーム全体の生産性を最高の状態に保つことにつながる。