『だって仕様書に書いてなかったんで』
プロジェクトにおいて、こんなケースありませんか。
これから作るプログラムの仕様書を渡したら、
部下が動かないプログラムを提出してくる。
『だって仕様書に書いてなかったんで』
仕様書に書いている通りに作っただけでは動かなかった。
だが、どう見てもこのプログラムでは目的のものが作れない・・・
詳細設計に問題があったのか？
一見、詳細設計に不足があったことが問題に見えます。
ですが、詳細設計で『100%完璧な仕様書』が作れるか。
作れるなら、きっとその人が作った方が早いし、きっとロボットに作らせる未来も簡単だと思います。
『100%完璧な仕様書』が作れないなら、どうするべきか。
私達は、『仕様書が正しく書けていない』というリスク管理をするべきなのです。
対策は何か
『仕様書が正しくかけない』というリスクに対して、2パターンのアプローチがあると思います。
『起こる前に対応する』
『起こった後の対処を用意する』
起こる前：『１人で設計しない』
『起こる前に対応する』のは非常に難しいです。
『100%に限りなく近い仕様書』を作る必要があるからです。
これに対する対応の１つが、『１人で設計しない』こと。
- 設計をレビューしてもらう
- プロジェクトに関わる人に共有して、意見をもらう
見落とし、見逃しを避ける。
設計を分担した際は、お互いの設計をレビューするのもいいです。
分担する以上、お互いに概要を知っているのでレビューもスムーズに行えると思います。
起こった後：『目的』を共有する
『仕様書に書いただけのプログラムでは動かない仕様書』
それでも動くプログラムが出来上がることがあります。
それは、プログラマーが自分で考えて、いい感じに作る時です。
『熟練者じゃないと出来ないだろう』
という一面はあるかもしれませんが、１つ工夫すると、
プログラマーがいい感じに作る可能性が増えます。
それは、『このプログラムは何のために作るか』を知っている時です。
各パーツを何のために作るかを共有する、目的を共有することが大切です。
『ネジを作る』のではなく『ネジのように固定するものを作る』
『ネジ』を作ってみましょう。 この設計書通りに作ってください。
これでは、設計書通りにしか作ることが出来ません。
この机を作るために、この板を固定するものを作りましょう。 そのために『ネジ』を作ってみましょう。 この設計書通りに作ってください。
すると、プログラマーが作ってみようとしたら、あれ？これじゃ固定出来なくないか？
と気がつくかもしれません。
じゃあどうすれば固定出来る？と考えて、プログラマーは『いい感じに作る』かもしれません。
私達は『ネジ』を作ることが目的ではなく、
その先の『机』を作ることが目的ではありませんか。
仕様書も『机を作る』ために作るためにあって、『ネジを作る』のはあくまで手段です。
リスク軽減は難しい
今回の主題は、目的を持った仕様書を作ろうというお話でした。
目的書くことも手間かもしれませんが、結果的にかなり詳細に書くよりも、
より部下に伝わって、工数削減に繋がる可能性もあると思うので、
目的を書くことを忘れないようにしたいと思いました。
