曖昧な要望を、
仕様に変える

受託開発の現場で最初に渡されるのは、たいてい完成した仕様書ではない。「もっと使いやすくしてほしい」「とにかく速く」——一言の要望だ。気持ちは伝わる。でも、これだけでは何も作れない。

要望は「気持ち」であって、要件ではない。要件とは、何がどうなっていれば「満たされた」と言えるのかの条件のことだ。「もっと速く」は要望、「月末の締め処理を、現場の担当者が3秒以内に終えられる」は要件。両者のあいだには、まだ大きな溝がある。

この溝を埋めないまま実装に入ると、できあがってから「思っていたものと違う」が必ず起きる。手戻りは、要件定義をサボった分の利息として、あとで必ず払うことになる。

自分はインフラから受託のWeb開発へ移ったとき、最初に苦労したのがここだった。コードは書ける。けれど「何を書くべきか」が曖昧なままでは、手が止まる。要件定義は、実装の前にある、いちばん地味で、いちばん効く工程だ。

問いを立てても、要望は一度の打合せで全部は出てこない。出てくるのは「持ち帰って確認します」という宿題の山だ。この宿題をどう扱うかで、要件定義の質が決まる。

自分のやり方は単純で、宿題を全部チケットにすること。曖昧な要望のかたまりを、追える単位まで割る。一枚のチケットが「誰の・どの場面の・何を決めるか」になっていると、打合せのたびにチケットが減っていく。要件が「見える在庫」になるのだ。

ある業務システムの改修では、4ヶ月のあいだに80枚ほどのチケットを起こした。一枚ずつが小さな決定の単位で、宿題が決定に変わるたびに、システムの輪郭がはっきりしていった。チケットの束は、そのまま要件の地図になる。

振り返ってみると、これまで自分が起こしたチケットを種別で見たとき、最も多かったのは「要望」だった。全体のおよそ4割を占める。実装そのものより、要望を要件へ翻訳する作業のほうが、仕事の中心だったということだ。これは数えてみて初めて自覚した。

引き出して整理した要件は、仕様書という形で残す。これまで20件以上は書いてきた。ただ、仕様書の本質はドキュメントを納品することではない。「ここまでは作る、ここからは作らない」という線を、両者が同じ絵で見るための合意の証跡だ。

UMLのクラス図やER図、画面遷移図も同じ役割を果たす。文章で説明すると擦れ違うものが、図にすると一瞬で揃う。「この四角がこのデータで、ここからここへ線が引かれている」——絵は、解釈の幅を狭めてくれる。設計の合意は、言葉より図のほうが速い。

「ちょうどいい」を見極める——これは設計そのものと同じ感覚だ。過剰な作り込みが、後でどう負債になるか。それは別の記事（失敗から学んだ設計判断）で正直に書いた。仕様も設計も、足りなくても、多すぎても、後で痛い目を見る。