仕様書の作り方

解説（テキスト版）

はじめに

情シスには、こんな相談が届きます。仕様書は、前回の更新のときのものを、写せばいいですよね、と聞かれる。

あるいは、事業者から、非機能要件が書かれていないので、見積が出せません、と言われる。

どちらも、仕様書に何を書くのかが分かっていないと、困ります。第4回は、仕様書の作り方をお話しします。

一言で言うと

先に、一言でまとめます。仕様書は、何をしてほしいのかを、どの会社が読んでも、同じ意味に受け取れるように書いた文書です。

書き方があいまいだと、会社ごとに違う前提で見積を出すので、比べられなくなります。

流れのどこか

調達の流れの中では、仕様検討と、仕様調整の段階です。

予算要求の前に、大まかな仕様を作って、予算が決まったあとに、細かいところを詰めます。RFIで集めた意見が、ここで生きてきます。

書き始める前に

書き始める前に、まず確かめることがあります。そのシステムが、標準化の対象かどうかです。

住民記録や、税、福祉などの、20の業務は、国の標準仕様書に合ったシステムを使うことになっています。機能は、標準仕様書で決まっているので、自由に書くものではありません。

一方で、それ以外のシステムは、自分たちで仕様を書きます。今日の話は、主に、こちらの場合です。

仕様書の3つの柱

仕様書の中身は、大きく3つに分けられます。

機能要件、非機能要件、そして、データの移行の要件です。

このほかに、導入の日程や、体制、研修、保守の範囲なども書きますが、まずは、この3つを押さえます。

機能要件

1つ目は、機能要件です。システムで、何ができればいいのかを書きます。

書くときは、業務の流れに沿って書くのが、こつです。申請を受け付ける、内容を審査する、通知を出す、といった順番に、必要な機能を並べます。

画面の配置や、ボタンの位置までは、細かく指定しないのが一般的です。細かく書くほど、合う製品が減って、費用が上がります。

そして、必ず要るものと、あればうれしいものを、分けて書きます。全部が必須だと、選べる製品が少なくなります。

非機能要件

2つ目は、非機能要件です。何ができるかではなく、どのくらいの質で動くのかを書きます。

たとえば、止まらずに動くこと。何人が同時に使っても遅くならないこと。障害のときに、どのくらいで直すのか。セキュリティの対策。保守の時間帯などです。

情報処理推進機構の、非機能要求グレードという資料では、可用性、性能と拡張性、運用と保守性、移行性、セキュリティ、システム環境の、6つの大きな項目に分けて整理されています。自治体向けに項目を絞った版もあります。

非機能要件を書かないと、会社ごとに、違う前提で見積を出します。安い見積が、実は、障害のときに何日も直らない前提だった、ということもあります。

データの移行の要件

3つ目は、データの移行の要件です。見落とされがちですが、いちばんもめやすいところです。

今のシステムのデータを、誰が、どんな形で取り出すのか。新しいシステムに、誰が取り込むのか。何年分のデータを移すのか。

データを取り出すのは、今のシステムの事業者です。その作業に、別に費用がかかることもあります。今の事業者に、早めに相談しておきます。

移したあとに、件数や金額が合っているかを、誰が確かめるのかも、書いておきます。

次の更新に向けた、データの取り出し

データについて、もう一つ書いておきたいことがあります。次の更新に向けた、データの取り出しの要件です。

今回、今の事業者からデータを取り出すのに、苦労したかもしれません。形式が独自で読めない。項目の意味が分からない。取り出すだけで、高い費用がかかる。

同じ苦労を、次の更新で繰り返さないように、今回の仕様書に書いておきます。契約が終わるときに、すべてのデータを、CSVなどの一般的な形式で渡すこと。

あわせて、項目の名前と意味をまとめた、データの定義書も渡すこと。費用がかかるなら、その金額も、契約の時点で決めておきます。

入れるときに、出るときのことも決めておく。これが、特定の事業者から離れられない、という状態を防ぐ、いちばん確かな方法です。

書き方のこつ

書き方のこつを、3つお伝えします。

一つ目。製品名を書かないことです。特定の製品の名前や、その製品にしかない機能を書くと、ほかの会社が参加できなくなります。

二つ目。言い切ることです。できれば望ましい、のような書き方は、必須なのか任意なのかが分かりません。必須なら、できること、と書きます。

三つ目。前回の仕様書は、参考にとどめることです。前回のまま写すと、今は使っていない機能や、古い前提が、そのまま残ります。

現場でよくある誤解

現場でよくある誤解を、3つ挙げます。

一つ目。前回の仕様書を写せば安全だ、という誤解です。業務も、技術も変わっています。前回の課題の記録と合わせて、見直します。

二つ目。細かく書くほど、良い仕様書だ、という誤解です。細かく書きすぎると、合う製品が減って、費用が上がります。業務として何が必要かを書きます。

三つ目。データの移行は、新しい事業者がやってくれる、という誤解です。データを取り出すのは、今の事業者です。費用と役割を、仕様書に書いておきます。

異動してきたら最初に確かめること

では、仕様書を作ることになったら、まず何を確かめればいいでしょうか。

一つ目。そのシステムが、標準化の対象かどうかです。対象なら、標準仕様書と、国の手順に沿って進めます。

二つ目。今のデータの形式と、取り出す方法です。今の事業者に、取り出しの費用と期間を聞いておきます。

三つ目。必須と任意の区別です。担当課と一緒に、本当に必ず要るものはどれかを、一つずつ確かめます。