仕様書ではなく、仕様を管理したい
■ まとめの縮小版
仕様書は作ることが目的ではない。
本来は、
なぜその仕様になったのか
何を実現したいのか
どのように動作するのか
を共有するためのものだ。
しかし現実には、
「承認された瞬間から更新されなくなる」
仕様書が多い。
私は仕様書の完成度よりも、
仕様が生き続ける仕組みの方が重要だと思っている。
■ プロジェクト途中参加の洗礼
プロジェクトに途中参加すると、
まず仕様書を読むことになる。
そして仕様書だけでは理解できず、
ソースコード
デバッグログ
実機確認
を行う。
すると高い確率で気づく。
実装と仕様書が違う。
これは私が20年間ソフトウェア開発をしてきた中で、
ほぼ毎回発生していた。
■ なぜズレるのか
理由は単純だ。
開発中に仕様変更や設計変更が発生するからである。
実装して初めて、
性能が足りない
制約に引っかかる
他機能と矛盾する
ことが見つかる。
その結果、
実装側で妥協点を見つける。
しかしその変更が仕様書へ反映されない。
だから実装と仕様が乖離する。
■ 日本の開発は手戻りを嫌う
この問題が起こる背景には、
日本の開発文化がある。
日本のソフトウェア開発は、
手戻りを極端に嫌う。
一度承認された仕様を変更すると、
原因説明
再レビュー
再承認
が必要になる。
つまり、
仕様を修正するだけで大量の作業が発生する。
だから誰も仕様書を直したがらない。
■ 私が承認しなかった話
過去に私は仕様書レビューで
大量の指摘を出したことがある。
当然ながら修正が終わるまでは承認できない。
すると、
「先に承認だけしてください」
と言われた。
しかし私は承認しなかった。
■ 怒られたけれど後悔はない
結果として上司には怒られた。
「早く進めろ」
と言われた。
しかし私は納得できなかった。
ここで妥協してしまえば、
後工程で何倍もの工数になることが見えていたからだ。
実際には、
要求
実現可能性
妥協点
を整理して仕様を作り直した。
その結果、
設計の手戻りはあったが、
開発全体は前倒しで進み、
十分な検証期間を確保できた。
■ 仕様書は完成した
しかし別の問題が発生した。
その仕様書を次のモデルで流用した時だ。
修正履歴が増え、
取り消し線だらけになり、
何が正しいのかわからなくなった。
私は思った。
これは本当に仕様書なのか？
■ ドキュメント中心の限界
現代のソフトウェア開発はスピードが求められる。
それなのに、
仕様書
設計書
実装
を別々に管理している。
だから変更が発生するたびに、
複数の成果物を修正しなければならない。
結果として、
どこかが更新されなくなる。
■ 問題は人ではなく仕組み
私は、
仕様書が形骸化する原因は
担当者の怠慢ではないと思っている。
問題は仕組みだ。
更新コストが高すぎるのである。
更新が面倒だから、
補足資料を作る
メールで説明する
口頭で共有する
になってしまう。
そして情報が分散する。
■ 仕様を構造化したい
だから私は今、
仕様書そのもののあり方を見直している。
私が目指しているのは、
文章中心の仕様書ではなく、
構造化された仕様管理だ。
例えば、
情報履歴はGitで管理
機能はDB構造で管理
関連情報はリレーション管理
図や補足情報を紐付け
するような仕組みだ。
■ 仕様書ではなく仕様データ
理想は、
仕様書を作ることではない。
仕様そのものを管理することだ。
仕様が変更されたら、
関連する図や説明も追従する。
そんな仕組みが作れれば、
仕様書の形骸化は大きく減らせると思っている。
■ まとめ
私は形骸化した仕様書が嫌いだ。
理由はシンプルで、
仕様書が真実ではなくなるからだ。
本来、
仕様書は開発を助けるために存在する。
しかし更新されなくなった仕様書は、
開発を妨げる存在になる。
だから私は、
仕様書の完成度を高めるよりも、
仕様を継続的に更新できる仕組みを作る方が重要だと思っている。
今はまだ試行錯誤の途中だが、
Gitやデータベースを活用した
構造化された仕様管理を実現できれば、
仕様書の形骸化という長年の問題を解決できるのではないかと考えている。
今年中にはプロトタイプを作り、
実際の業務で試してみたいと思っている。
