エンジニアのひよこ_level10

【毎日更新!】新卒2年目エンジニアブログです! プログラムだけじゃなく、マネジメントとかも書いていきたい!

『仕様書に書いてないから』という設計の問題を軽減しよう【215日目】

『だって仕様書に書いてなかったんで』

プロジェクトにおいて、こんなケースありませんか。

これから作るプログラムの仕様書を渡したら、
部下が動かないプログラムを提出してくる。

『だって仕様書に書いてなかったんで』

仕様書に書いている通りに作っただけでは動かなかった。
だが、どう見てもこのプログラムでは目的のものが作れない・・・

詳細設計に問題があったのか?

一見、詳細設計に不足があったことが問題に見えます。

ですが、詳細設計で『100%完璧な仕様書』が作れるか。

作れるなら、きっとその人が作った方が早いし、きっとロボットに作らせる未来も簡単だと思います。

『100%完璧な仕様書』が作れないなら、どうするべきか。
私達は、『仕様書が正しく書けていない』というリスク管理をするべきなのです。

対策は何か

『仕様書が正しくかけない』というリスクに対して、2パターンのアプローチがあると思います。

『起こる前に対応する』
『起こった後の対処を用意する』

起こる前:『1人で設計しない』

『起こる前に対応する』のは非常に難しいです。
『100%に限りなく近い仕様書』を作る必要があるからです。

これに対する対応の1つが、『1人で設計しない』こと。

  1. 設計をレビューしてもらう
  2. プロジェクトに関わる人に共有して、意見をもらう

見落とし、見逃しを避ける。

設計を分担した際は、お互いの設計をレビューするのもいいです。
分担する以上、お互いに概要を知っているのでレビューもスムーズに行えると思います。

起こった後:『目的』を共有する

『仕様書に書いただけのプログラムでは動かない仕様書』
それでも動くプログラムが出来上がることがあります。

それは、プログラマーが自分で考えて、いい感じに作る時です。

『熟練者じゃないと出来ないだろう』
という一面はあるかもしれませんが、1つ工夫すると、
プログラマーがいい感じに作る可能性が増えます。

それは、『このプログラムは何のために作るか』を知っている時です。

各パーツを何のために作るかを共有する、目的を共有することが大切です。

『ネジを作る』のではなく『ネジのように固定するものを作る』

『ネジ』を作ってみましょう。  
この設計書通りに作ってください。

これでは、設計書通りにしか作ることが出来ません。

この机を作るために、この板を固定するものを作りましょう。
そのために『ネジ』を作ってみましょう。  
この設計書通りに作ってください。

すると、プログラマーが作ってみようとしたら、あれ?これじゃ固定出来なくないか?
と気がつくかもしれません。

じゃあどうすれば固定出来る?と考えて、プログラマーは『いい感じに作る』かもしれません。

私達は『ネジ』を作ることが目的ではなく、
その先の『机』を作ることが目的ではありませんか。

仕様書も『机を作る』ために作るためにあって、『ネジを作る』のはあくまで手段です。

リスク軽減は難しい

今回の主題は、目的を持った仕様書を作ろうというお話でした。

目的書くことも手間かもしれませんが、結果的にかなり詳細に書くよりも、
より部下に伝わって、工数削減に繋がる可能性もあると思うので、
目的を書くことを忘れないようにしたいと思いました。