Joel on Software パート2：仕様書とはどんなものか？

WhatTimeIsIt.comという架空のサイト構築に関する仕様書を
サンプルに話を進めていて非常に面白い。
良く出来ている。

著者は以下をいつも仕様書に入れるらしい。
どれもとても納得できる。

作り始めは「この仕様書は未完成である」と入り仕様書が完成に近づいたら
「何か抜けがあれば知らせて欲しい」と記述する。
素晴らしいリスクヘッジ。

「仕様書はひとりの人間によって書かれ、所有されるべきだ。」
ひとりでドキュメントを作ることは同意。
ただ、品質を高めるためにはドキュメントレビューを実施すると良さそう。

「製品をデザインするときは、人々がその製品をどのように使うかについて、
現実的で行き来としたシナリオが頭の中に入っている必要がある。」
これは肝に命じて置かなければならない。
僕はこういった配慮が欠けていることが多いです。

「あなたは開発をはじめてすぐに機能の選択にとりかからなければならない。」
時間軸の関係上、当然全ての機能を満たすことはできない。
できないことは早期に定義しておくに限る。

一見してわかる簡単な項目があると初めて見る人にはわかりやすい。

「詳細は、機能仕様書でもっとも重要な部分だ。」
個人的にはもっとも重要であるとは思わなかった。
最も重要だと思うのは「仕様書は生きている必要がある」かな。

未解決の問題は見える化しよう！という話。

気づいたことは書こう。

更新を忘れ去られるドキュメントのなんと多いことか！
ドキュメントを更新し続けなければ製品の成長は見込めないと
思っている。
著者の「一定のマイルストーンごとに仕様書のコピーを印刷する。」
という行動は見習いたい。

明日はやさしい機能仕様書パート3

やっと自身のリソースのゆとりが出てきた。
この隙にいままで着手できていなかったチケットをさばく（さばいてもらう）。
また、次回プロジェクトのガントチャートを記述する。
ガントチャートを書くのは楽しい。なぜこの作業がこんなに楽しいのかはわからないが。