- 要求が満たされている事
- 実現可能である事
- システムの動作が要約されている事
しかし、設計書は時として嫌われ、役立たずの烙印を押される。
そんな嫌われる設計書とは、こんな感じのものだ。
- 要求が漏れていたり、追加された要求が反映されていない事
- 実現可能性が薄い仕様が記述される事
- しばしばシステムの動作とはかけはなれた内容が記述されている事
そもそも設計書がこのような状態に陥りやすいのは何故か。
まず設計書が参照される「可能性のある」タイミングを見てみよう。
これが、時間軸上で見るとかなり広い。
顧客が要望を確認する時
設計書は頻繁に更新される。
この時は、顧客は要望が全て盛り込まれている事に注視する。
また、顧客はたいがいシステムの事は知らない。
その為に、システムの動作的検証は棚上げになる。
プログラムを書く時
設計書はある程度は更新される。
この時、設計書ははじめて動作可能かという厳しい査定を受ける。
動作不可能な場合、即座につき返される。
しかし、仕様に障害が含まれていても、複雑度によっては発見されずに残る場合がある。
プログラムを修正する時
設計書はなかなか更新されない。
たいがいは仕様の追加や障害の修正。
この時、設計書段階で盛り込まれた仕様障害も取り除かれる。
ただしこの段階では開発者の頭に仕様が入ってしまっている為、往々にして設計書は振り返られ無い。
プログラムを改造する時
何を行っているかを解析する為、設計書が再び日の目を見る。
しかし、設計書はすでにプログラムとはかけ離れていて、すで役に立たない事が多い。
こう見ていくと、なぜ設計書が「悪化する」のか、いくつかマイナスの特性というような点が見えてくる。
- 設計書は、それ自身が動作可能ではない。
- 最終成果物たるプログラムとは別オブジェクトである。
- 人は、同じ修正を複数個所に行う事が苦手であり、その対象が増えていくと重要でない部分から無視される。
良い／悪いの判断は別として、プログラムは納品されてじっさいに運用された時点で、その動作が全て「正」とされる。
その為、何重もの厳しいテストを経て厳しくチェックされてから納品される。
対して設計書は動作しない為、プログラム納品時に再度チェックされる事はほぼ皆無だ。
また、最終成果物とは別媒体という事が、一種独特の「面倒さ」を演出している。
これは、プログラムが判読可能なものである、という事実がさらに拍車をかけている。
コードからの距離に対して、更新しようとする意識が薄くなる、という話もある。
そして、プロジェクト中に様々な設計書が存在すると、重要度が一番低いものから徐々に更新されなくなる。
この場合に一番重要度の高いものがプログラムである。
そして、プログラムを基準にして抽象度の低い資料から順に更新されなくなる。
コードはプログラム内にすでに書かれているし、頭にも入っている為に、記述不要に思えてしまうのだ。
この現象はプログラム修正の頻度が一番高い段階で爆発的になる。
これらが複合し、やがて改造が必要な時点で設計書が役に立たなくなっている事が発覚、あげくに「前のプログラムを参考にして欲しい」といった仕事もよくある。
しかし前述のとおり、コードだけではシステムの概要が掴みにくい。
では、どうするべきなのか。
しかしここへ未知夢の事へ追加したかも。