さて。ITの開発現場では「単独・単品」で作られ存在する仕様書が珍しくない、と思う。 関数仕様だけ、画面仕様だけ、シーケンス図だけ、みたいな。確かに手分けして量産するにはこれがラクなのだけど、 本来それらは統合されて、大きなドキュメントの体裁に…

仕様書に書いてあることは、そのままコードに落としたい。そのためにも、仕様書とコードを１対１で対応させたい、と思う。つまりは、「仕様書のここは、このクラス／モジュールに書いてあります」としておきたい。そして、その中身は、 「2-3章の機能は、こ…

さて。先日のアジャイルラジオの感想です。まずは共同所有のこと。正直、ひとのコードを積極的に「さわる」ことはないです。 コードが見れる環境にあるし、コードレビューもするけど、 「直す」「変える」のは抵抗あるな、と思う。こういうことをすることに…

仕様書の書き方のことを何度か書いたが、 まず出発点は「口で説明できること」なんだと思う。話し言葉でちゃんと伝えることができるということは、 話す前に、あるいは話しながらでも、 話す内容がきちんと整理できていて、伝えるための言葉の用意ができてい…

仕様書の書き方、第２弾です。漏れ抜けのないようにと、あれもこれもと盛り込みたくて、 ついつい長文になってしまうこと、けっこう多いように感じています。しかし、仕様書は、まずは「箇条書き」です！要素をきちんと分解し、１つのことを１つの項目として…

（仕様書というよりは）資料を書くときにごく普通に意識していること。■言葉を統一する 同じものを指すのなら、常に同じ言葉で書き表す。■初出のものには説明を 重要なもの・ことについては、章を割いて説明する。 読み手の前提知識がどの程度で、どこまで説…