仕様書の書き方

管理者になったとき困らない 実践的ソフトウェア開発工程管理

さて、この１週間何が忙しかったのかと言うと、かなりの量のドキュメントを書いていたので、連日晩くまで、仕事をしてしまい、なかなか家にも帰れず、ブログも書けずな毎日でした。こっそり会社からブログを更新する事もできるのですが、さすがにそんな余裕もありませんでしたよ…。

はぁ…。

何を書いていたのかというと、プログラムの設計仕様書なのですが、これがまた書くのに苦労するんです。詳細であれば良いってもんでもないですし…、最近はデザインレビューと言って、チームのみんなで確認し、チェックする様な体制に遅ればせながら、ウチの会社もなって来ましたので、こう、他人が見ても理解がしやすく、かつ、私のイメージを伝え、飽きさせないような資料にしなければなりません。これが、なかなか難しいのです。

教科書通りに書いてしまうとなんか項目を埋めただけの様な、味も素っ気も無いドキュメントになってしまいますし、適当にさっぴくとレビューの必要性が薄れると…。絶妙なバランスが必要なんですね。

で、何枚も何枚も書いて気が付いたのですが、結局ドキュメントに書かなければいけない事ってのは、自分が知りたい事、という考えに至りました。なんとなく客観的にみて、自分が書きたい事ではなく、知りたい事を意識してまとめてみると、それなりに自分で納得できる形になりました。

新人さん達のドキュメントを見ると、どうも迷いみたいな物が見え隠れしていて、この辺の感覚がまだまだのような気がします。なんかそういう事を伝えて行けたらなぁと思う今日この頃です。

仕様書の書き方 ２ へ続く

・Software people―ソフトウェア開発を成功に導くための情報誌 (Vol.5)