要件定義書は誰が書くのか ── 発注側が書くのは「困っていること」まで

「開発会社に相談したら、まず要件定義書を用意してくださいと言われました。何を書けばいいのか分からなくて」。こういう相談を受けることがあります。話を聞くと、Excelに機能の一覧を30行ほど書いたところで手が止まっている。「ログイン機能」「検索機能」「CSV出力機能」。書いているうちに、これで合っているのか分からなくなった、と。

手が止まるのは当然だと思います。その一覧の大半は、本来は開発側が書くものだからです。この記事では、発注側が書くものと、開発側が引き取るものの線引きを書きます。

「要件定義書」には、2つのものが混ざっている

要件定義書と呼ばれる文書には、性質の違う2つの中身が入っています。ひとつは「業務で何が起きていて、何を変えたいか」。もうひとつは「それをどんな画面とデータで実現するか」です。

前者は、業務を知っている人にしか書けません。開発者がどれだけ経験を積んでも、御社の月末に何が起きているかは知りません。後者は、画面とデータの作り方を知っている人の仕事です。業務に詳しくても、データをどう持てばあとで集計しやすいかは、普段考えることではありません。

「要件定義書を用意してください」という依頼は、この2つをまとめて発注側に渡しています。発注側が後者まで書こうとすると、慣れない言葉で機能を並べることになり、手が止まります。

発注側が書くのは、4つ

1つ目は、困っていることです。「業務効率化」ではなく、どの場面で、どれくらいの頻度で困っているか。「月末に作業報告書を回収して、事務が2日かけてExcelに打ち直している」くらいの具体さがあれば十分です。

2つ目は、今の業務の流れです。誰が、何を見て、何に書いて、誰に渡すか。紙の帳票やExcelのファイルが、どの順番で人の手を通っているかを書きます。例外も書いてください。「この取引先だけは別の書式」「雨の日は翌日にまとめて出す」。作ったシステムが使われなくなる原因のひとつが、この例外が画面にないことです。

3つ目は、使う人です。役割と人数と、どこで使うか。「現場の作業員8名がスマホで、事務2名がPCで」。

4つ目は、今回やらないことです。これがあるだけで、見積もりの幅が狭まります。使う人と、作らない範囲を相談の前にどう決めておくかは開発会社に相談する前に、決めておくと話が早い3つのことに書いたので、決め方はそちらを見てください。

書くとこうなる、という例

架空の想定例です。設備の保守点検をしている従業員25名の会社が、4つを書くとこうなります。

困っていること: 作業員が紙の点検報告書を手書きし、週末に事務所へ持ち帰る。事務2名が月末に約200枚をExcelに打ち直していて、月に30時間ほどかかる。取引先から報告書の提出を急かされても、紙が事務所に届くまで出せない。

今の業務の流れ: 事務が点検の予定をExcelで組み、作業員に電話で伝える。作業員は現場で報告書に記入して写真を撮り、週末に紙と写真をまとめて持ち帰る。事務が打ち直してPDFにし、取引先にメールで送る。報告書の書式は取引先ごとに2種類ある。

使う人: 作業員8名（スマホ、現場で入力）、事務2名（PC、確認と送付）、社長（PC、月に1回集計を見る）。

やらないこと: 点検の予定を自動で組む機能。請求は今の会計ソフトのまま。

4つ合わせても、この程度の分量です。機能の名前はひとつも出てきません。それで構いません。画面に落とすのは、ここから先の開発側の仕事です。

開発側が引き取るもの

上の4つを受け取ったら、そこから先は開発側の仕事です。画面をいくつに分けるか、どの順に並べるか。点検報告をどんな単位のデータで持つか、取引先ごとの2種類の書式をどう出し分けるか。どの機能を最初の8週間に入れて、どれを後に回すか。

この部分を発注側が先に決めてしまうと、困ることがあります。たとえば「顧客マスタ」「案件マスタ」と書いてあっても、そこに何を持たせるかは業務の流れを聞かないと決まりません。名前だけが先に決まると、あとで中身を合わせる作業が発生します。

私たちの場合、この部分は画面構成のラフとしてこちらで作ります。初回お打ち合わせ（60分）で4つを伺い、3営業日以内に画面構成のラフとお見積りをお出しします。ここまで費用はかかりません。契約後のW1〜W2で、そのラフを業務の細部と突き合わせて画面構成を確定させます。この2週間は発注側にも週2〜3時間ほど時間をいただきます。何をお願いしているかは発注したあと、自分たちは何をするのかに週ごとに書きました。

持ってきてもらうと助かるもの、なくていいもの

助かるのは、いま実際に使っている紙の帳票とExcelです。記入済みのものが1枚あると、空欄の書式より多くのことが分かります。備考欄に毎回同じことが手書きされていれば、それは項目にすべき情報です。

なくていいのは、画面のレイアウト図、データベースの設計、機能の網羅的な一覧です。作ってしまったものがあれば、何を大事にしているかが分かる資料として拝見します。ただ、そのとおりに作ることは約束しません。業務の流れとつながらない画面は、使い始めてから作り直しになることが多いからです。

最初の問い合わせのメールに何を書くかは、また別の話です。数行で済む書き方を開発会社への最初の一通に、何を書くかにまとめています。

「全部書いてください」と言われたら

開発会社によっては、詳細な仕様書を発注側が用意する前提で動いているところもあります。仕様が固まった状態で一括で請け負う形なら、それも筋の通ったやり方です。私たちも、要件が完全に固まっていて変更の余地がない案件は、そういう会社に一括で発注したほうが早いと考えています。

迷ったときは、相手に2つ聞いてみてください。業務の説明から画面に落とすのは誰か。要件定義を有償の工程として別に見積もっているか。答えによって、発注側がどこまで書くべきかが決まります。要件定義を誰がやるかは、契約が請負か準委任かにも関わるので、契約書のどこを見るかはシステム開発の契約書で、発注側が読むべき5つの場所を参考にしてください。

私たちに相談される場合は、4つが書けていれば十分です。4つが埋まらなくても、1つ目の「困っていること」だけで始められます。