昨日は伝わった設計書の意図が，今日も伝わるとは限らない。設計書の意図が伝わらない怖さと，なぜ意図が伝わりにくくなっているのかを明らかにする。
信託銀行向けシステムの開発を手掛けるインフォメーション・ディベロプメントの中村辰紀氏（システムインテグレーション事業本部 SI第2部）は，少し前の失敗が忘れられない。設計書の意図がプログラマに正しく伝わらず，1週間の遅延を招いてしまった。
昨年のことだ。協力会社のプログラマに，作ったばかりの基本設計書を手渡した。株主の議決権や請求権など権利の行使に関するものだった。
一つの誤解が1週間の手戻りに
「何だ，これは…」。順調に進んでいたプロジェクトだったが，システムテストになって小さなバグが見つかった。「権利行使区分」と呼ぶ権利の状態を表すデータ項目と「権利行使方法」と呼ぶ権利を行使するための方法を表すデータ項目を，プログラマが同じものと誤解して開発していたのである（図1）。
イラスト：ミオササノッチ
被害は大きかった。該当するプログラムの修正はもちろん，他のデータ項目にも誤解がないか調査する羽目になった。メンバー全員が1週間にわたってその作業に追われた。
プログラマの業務知識不足は否めない。だが中村氏は，自らの設計書の作り方を責める。「ともにデータの範囲は0から2。名前も紛らわしい。今考えれば誤解されても仕方なかった。データ項目の意味を用語集などで補足していれば，初めて参加するプログラマでも正しく理解してくれたはずだ」（中村氏）。失敗を反省し，中村氏は用語集の整備に着手した。
“行間”はいらない
中村氏のような苦い経験を持つITエンジニアは多いだろう。たった一つの解釈ミスでも，重大な品質問題につながる恐れがある。NTTデータの木谷強氏（技術開発本部 ソフトウェア工学推進センタ センタ長）は「多くの人が勘違いしている。設計書の品質が悪くなる原因を要件のあいまいさや前例のないサービスのせいにしているが，必ずしもそうではない。設計書の作り方を工夫すれば，解決できる問題は多い」と指摘する。
作り方に起因する問題はいろいろある。例えば，情報の不足があると，読み手を迷わせる（図2左上）。プライドの中嶋健一郎氏（システム・コンサルタント）は，画面レイアウトを作成し，東京，九州，インドの各協力会社にプログラムの作成を委託した。九州の協力会社からはきちんとしたプログラムが上がってきたものの，東京の協力会社から納品されたプログラムはデータの入出力やボタンを押したときのイベントの動きが意図したものと違っていた。インドの協力会社からは，問い合わせが殺到した。
中嶋氏は振り返る。「これぐらいは理解してくれるだろうと過信してしまった。設計書に“行間”はいらない。必要な情報を漏れなく記述すればよかった」。
設計の背景が分からなくなることも多い（図2右上）。保守開発案件を数多く手掛けてきたバイトルヒクマの長谷川亨氏（顧問）は「設計の背景が書かれていない設計書からは，なぜその構造や実装方式になっているのかを読み取れない。プログラムを修正したくとも，その前に現状調査に追われる」と指摘する。
