官公庁におけるシステム開発仕様書の作り方です。新しいシステムを開発するときには、ほとんどの場合、高額な契約が予想されるため、一般競争入札になります。実際に入札で使う仕様書を、どのように作るのか、作成手順や注意点などをわかりやすく解説します。
システム開発に向いている官公庁の業務
この解説での「システム開発」とは、コンピュータを用いてデータを処理するシステムを新しく構築することです。手作業で処理するよりも効率的になるためのシステム化です。国や地方自治体などの官公庁の業務は、多くの住民を対象とするサービスです。多数の個人データを管理したり、一定の基準で判断して処理し、決められた手順で進めるような業務は、システム開発に向いています。官公庁における、ほぼ全ての業務がシステム開発可能といえます。
逆に、システム開発に向かない業務は、その都度ケースバイケースで判断しなければならないものや、処理件数の少ないものです。わざわざコンピュータで処理するよりも手作業の方が効率的な業務です。特に、同じ内容（処理手順）のものが、ほぼ存在しない業務は、システム化には向いてません。例えば、入札手続きに必要な「仕様書や入札説明書の作成業務」などです。官公庁では、たくさんの入札を実施していますが、同じ内容のものは存在しません。（そもそも同じ内容であれば、１件にまとめて入札しますし・・）
なぜシステム開発を外注するようになったか
昔（ 1993年頃まで）は、「システム開発を外注する」という考え方はあまりなかったです。システム開発をコンピュータ専門会社へ依頼する場合、開発にかかる契約金額が、今よりも相当高額だったことが影響しています。多額の外注費を毎年払うなら、システム開発できる人員を新たに採用し、自前で育成した方が良いと考えられていました。1993年当時は中堅職員(30歳くらい）の月給が30万円くらいでしたが、専門会社へ依頼すると3倍の月額100万円以上の人件費が必要でした。定員ポストの制約はありましたが、採用の方向で考えていたのです。
インターネットも普及していない時代で、システム自体も単純だったので、自前でプログラミングしてシステム開発が可能でした。また当時は、システム開発を外注してしまうと、プログラムの著作権の関係から、修正が必要になった際に、永遠に特定の開発会社へ外注し続けなければならない、というデメリットの方が心配されていたのです。
現在は、システム開発の入札説明書や仕様書などへ、プログラムに関する著作権の取扱いを明記することで、プログラムの修正を自由に行うことができます。契約条件として、システムが完成した後に、「プログラムの著作権を官公庁側へ譲渡すること」、「著作者人格権を行使しないこと」という条項を入れるのが一般的になっています。プログラムを渡すという条件に見合う契約代金を支払うことになります。著作権を官公庁側へ譲渡すると、その分、契約金額が高くなります。ただプログラムを自由に使える権利を官公庁側が保有していれば、その後のシステム修正では、入札を行ったり、他の会社へ依頼させることもできます。
システム開発の外注契約が多くなってきたのは、パソコンやインターネットの普及が影響しています。1995年に登場したWindows 95 によって、だいぶ安定して業務にパソコンが使えるようになったのです。それ以前のWindows 3.1では、いきなりパソコンが落ちる（OSが動かなくなる）ことが頻繁にありました。作成中の重要な文書が一瞬で消える、とてもスリルのある時代だったのです。2000年には Windows 2000 がリリースされ、かなり安定して業務に使えるようになりました。この頃になると、一人一台のパソコンが当たり前になり、インターネットのWEBを使わないと業務ができないようになってきたのです。パソコンとインターネットの普及によって、システム開発を専門とする会社が多数出現し、システム開発の契約代金も安くなってきました。
官公庁では、公務員の定員削減という大きな方針があり、定員ポストを必要とする自前のシステム開発よりも、専門会社への外注の方がメリットが大きいと考えられるようになってきました。実際に中小企業によるシステム開発は、かなり安くなり、プログラムの著作権を譲渡することも問題ありませんでした。そのため次第に、システム開発を外注化するようになってきたのです。
官公庁の契約方式は、原則として一般競争入札です。専門会社が開発したプログラムの著作権は、その後も官公庁側が自由に使えるように保有しなければなりません。もし著作権を官公庁側へ譲渡せずに、システム開発企業が保有したままにするのであれば、将来的にプログラム修正が必要になった場合、システム開発企業と永遠に随意契約することになってしまいます。他の安い会社と契約できなくなり、外部から随意契約を常に批判されることになってしまいます。国民の貴重な税金を、永遠に特定企業のために払い続けるのは、公平性の観点からも大きな問題です。
システム開発の契約方式
官公庁の契約方式を大きく分けると、一般競争入札と随意契約になります。システム開発の多くは数百万円規模です。契約の種類としては、製造契約に該当します。国や都道府県の場合は250万円以上、市町村の場合は130万円以上から入札になります。
予算決算及び会計令
第九十九条 （略）随意契約によることができる場合は、次に掲げる場合とする。
二 予定価格が二百五十万円を超えない工事又は製造をさせるとき。
地方自治法施行令
第百六十七条の二 （略）随意契約によることができる場合は、次に掲げる場合とする。
別表第五（第百六十七条の二関係）
一 工事又は製造の請負
都道府県及び指定都市 二百五十万円
市町村 百三十万円
随意契約の中には、上記以外に、競争性のない随意契約もあります。競争性のない随意契約とは、「見積もり合わせ」ができない状況、つまり契約の相手方が一社に限定される場合です。典型的なのは特許製品で、法律で販売を独占することが認められており、製造販売する会社が一社しか存在しないケースが該当します。プログラム開発における著作権も該当します。ライバルが存在しない状態であれば、競争性がない随意契約が可能です。
システム開発は、実際の業務内容に合わせてプログラミングします。業務ごとに内容が異なりますし、中心部分の処理が同じだとしても、必ずシステムの一部を使用者に合わせてカスタマイズします。そういう意味では、システム全体を捉えた場合、ライバル製品は存在しません。そしてシステム開発で完成したプログラムには著作権が発生します。
こう考えると、システム開発の契約方式は、著作権に基づき「競争性のない随意契約」に該当するように思うかもしれません。しかしプログラムの著作権が生じるのは、システム開発が完了した後です。完成したプログラムに著作権が発生します。すでに完成しているプログラムを改修するときには著作権が問題になりますが、まだ開発していない段階では著作権が発生していません。初めてシステム開発を行うときに、著作権が発生するので「競争性のない随意契約」ができると判断してしまうのは誤りです。
2023年現在、プログラミング技術は急速に発展しつつあり、これまでにも様々な言語が開発されてきました。 C 言語や Python 、Java、PHP 、perl など数え切れません。そしてプログラマーたち技術者は、あらゆるテクニックを使ってシステムを開発します。プログラミング言語のほとんどが、英語ベースになっているため、世界中の技術者がプログラミングできるのです。日本人によるプログラミングよりも、海外のプログラマーの方が安く早くシステムを構築できるかもしれません。
つまり初めてのシステム開発の場合、世界中のあらゆる企業が対応できるのです。近隣国の中国や韓国、台湾、少し離れたインドなどもプログラミング技術が非常に高いです。日本人が作成するよりも、優れたシステムを安価に開発できてしまいます。
日本だけでなく世界中のあらゆる企業がシステム開発に対応できるということは、逆に、それだけ多くのリスクも存在することになります。一般競争入札を実施し、海外の知らない企業が落札したときに、品質の低いシステムができてしまうかもしれないのです。日本と海外の生活習慣の違いがあるため、日本人は当然のように考えていたとしても、外国人にとっては当然とは考えていないかもしれないのです。そうなると、システム開発を行うときには、仕様書を丁寧に綿密に作らなければなりません。必要な内容を、全て仕様書の中へ盛り込まなければならないのです。
システム開発仕様書は独自に作成できない
システム開発の仕様書を、官公庁側の職員だけで独自に作成するのは不可能です。 そもそも完全な仕様書を作成できるほどの知識やスキルを持っているのであれば、外注しなくても自前でシステムを開発できてしまいます。むしろプログラミング技術の高い職員が在籍しているのであれば、システム開発を外注すべきではありません。官公庁側に、システム開発のスキルを持つ職員がいない場合のみに外注することになります。官公庁の業務を、民間企業がシステム化するときには、個人情報や機密情報の漏洩リスクが常に存在するからです。当然のことながら、どの業務をシステム化すべきかも慎重に検討しなくてはいけません。デジタル化が政府の方針だからといって、やみくもにシステム化すべきではないのです。
システム開発の仕様書は、プログラミングを経験している視点から作成しなければなりません。実際にプログラミングを経験していないと、「できること、できないこと」がわからないからです。例えば、あるデータを処理するのに、プログラミングできない手法を仕様書に記載してしまうと、入札へ参加できる人がいなくなり、契約できなくなってしまうのです。実現できる手法を仕様書に記載しなければならないのです。WEBを利用するシステムであれば、サーバー側で動かすプログラムなのか、クライアント側で動かすプログラムなのか、過去の経験から効率的な方法を記述する必要があります。そのためにはプログラミングの豊富な実績を持つシステム開発の専門会社へ協力を依頼することになります。
仕様書を作成するときの注意点
最初に覚えておきたいことは、システム開発の仕様書は、「作成に時間がかかる」ということです。初めてのシステム開発なら、最低でも3ヶ月以上の作成期間が必要です。その後に入札を実施するので、契約を締結する5ヶ月ぐらい前から仕様書を作り始めることになります。
これは、官公庁の契約方式が一般競争入札であるため、多くの人が参加できる公平な仕様書を作成するためです。
もしシステム開発の仕様書を作成する期間が十分に確保できないのであれば、リスクのある契約手続きになってしまいます。たとえ一般競争入札を実施したとしても、特定の民間企業しか参加できないような仕様書と批判され、「業者との癒着」を疑われることになります。やはり特定の会社しか対応できないような仕様書を、官公庁は作成すべきではありません。
初めてのシステム開発では、複数の会社が対応できる仕様書を作成することが絶対条件です。
システム開発の仕様書作成手順
初めてのシステム開発では、専門会社の協力を得ながら仕様書を作成していきます。仕様書の主な作成手順は次のとおりです。ただし、「政府調達に関する協定 WTO」 対象の入札は除きます。（ 2023年現在、国は1,500万円以上、地方自治体は3,000万円以上の高額な入札では、意見招請などの特別な手続きが必要なので、ここでは除外します。）
１．仕様書の作成に協力してもらえる専門会社を探す
２．最初の打ち合わせ
３．次回以降の打ち合わせ
４．仕様書の原案作成
５．他社の意見を取り入れる
仕様書の作成に協力してもらえる専門会社を探す
専門会社は、最初に、自分の職場の取引先から探します。現在すでにシステム開発専門会社と他の契約を締結しているのであれば、とてもラッキーです。協力してもらえる可能性が高いです。もし現在契約している専門会社がなければ、過去の取り引きを調査します。過去の取引実績から専門会社が見つからない場合は、入札参加資格者の名簿、例えば「全省庁統一資格」の名簿などから探します。官公庁の入札参加資格を保有していれば、財務状況が既に審査されているので安心です。なるべく官公庁と契約実績のある会社を探します。会計法令に基づく契約手続き（入札が前提）であることを理解できる会社でなければなりません。
システム開発会社を2社探します。最初は2社で十分です。数が増えるとそれだけ仕様書の作成が大変になってしまうからです。最初は2社から始め、時間的に余裕があれば会社数を増やします。2社は、できればライバル関係にある会社の方が良いです。同じ系列の会社にしてしまうと、片方が遠慮して正確な情報を得られなくなってしまうからです。
会社が見つかったら、最初に1社を選び、次のことを電話で確認します。
◯ 一般競争入札を実施するための仕様書作りに協力してもらえるか、システム開発の作業手順や作業内容のアドバイスを頂きたいこと。
◯ 仕様書が完成した後は一般競争入札になるので、落札できるかわからず、契約できる保証がないこと、協力しても徒労に終わる可能性があること、儲けにならない仕事になるかもしれないこと。
〇 個人情報などの機密情報の保持もお願いしたいこと。
◯ 他の会社へも同じように声をかけていること、競争性を確保するため他社の名称は伏せたいこと、無理する必要はなく、協力しなくても不利に扱うことはないこと。
もし仕様書作りに協力してもらえそうであれば、早速、打ち合わせを始めましょう。打ち合わせは、最初は１社とのみ行います。ある程度の仕様書が出来上がった段階で、他社の意見を聞き、複数社が対応可能になるよう修正していくことになります。
最初の打ち合わせは、システム開発の概要から
最初の打ち合わせでは、官公庁側でイメージしている「システムの概要」を口頭で丁寧に説明しながらアドバイスを受けます。ひとつひとつ教えてもらう姿勢が大事です。実際にシステム開発を行うときに、どのような作業手順、作業内容になるのか、「後で具体的な資料をWORD形式で欲しい」ことを最初に話しておきます。どのようなシステムが欲しいのか、インプットとアウトプットの部分をなるべく細かく伝えます。
どのデータに基づいて、どのような処理を行い、結果として何をどこへ出力するのか、データ量も含めて詳しく伝えます。実際に現在、手作業で行なっている資料や、写真や動画などを用いるとわかりやすいです。
システム開発会社からは、「できること、できないこと」、「より効率的になること」などをアドバイスしてもらいます。後日WORDで提出してもらう情報ですが、打ち合わせの場でも、なるべく細くメモしてまとめておきます。システム開発会社は、後日提出する資料では、内容が変わる場合があります。特にライバルが増えそうな部分は、記載を変えてくる可能性があります。口頭での打ち合わせの際は、こまめにメモして、後日まとめておきます。契約担当者としては、自分のスキルアップにつながることなので、面倒でも必ず打ち合わせ内容を整理しておきましょう。
打ち合わせの最後に、実際に想定される「作業手順と、具体的な作業内容を、WORD形式で提出してもらいたい」ことを再度お願いしておきます。
また、プログラムの著作権は官公庁側へ譲渡してもらいたいこと、将来的なプログラム修正等も考慮して、著作権法２７条及び２８条の権利譲渡と、著作者人格権は行使しないという契約条件が可能かも併せて確認します。（つまり、システム開発で完成したプログラムは、その後、官公庁側の判断で自由に使えることを意味します。官公庁では必須の契約条件になります。）
次回以降の打ち合わせ
初回の打ち合わせでは、システムの概要を打ち合わせしました。そして、その概要に合わせて、具体的な作業手順と作業内容を、書面として専門会社から提出してもらいます。次回以降の打ち合わせでは、提出してもらった作業手順と作業内容の確認作業になります。自分で具体的にイメージできるまで掘り下げて、細かくしていきます。
ここで、打ち合わせの際に注意したい点があります。専門会社の負担にならないよう、無理のない打ち合わせ日時を設定することです。官公庁側が急ぐあまりに、次回の打ち合わせ日時を早急に設定したり、 2時間を超えるような長時間の打ち合わせは避けた方が良いです。専門会社としては、契約できるかわからない状況で、リスクを負担して協力しているわけです。無理に打ち合わせさせるような行為は絶対に慎むべきです。当然ながら高圧的な言動はもってのほかです。低姿勢で打ち合わせするのが基本です。常に「ペコペコ頭を下げる」くらいの姿勢で打ち合わせします。繰り返しますが、「教えてもらう」のです。
打ち合わせでは、次の点を重点的に確認します。
複数のシステム開発会社が対応できる内容か、 もし特定の専門会社しか対応できない内容であれば代替手法があるか。
内容を確認するときは、ひとつひとつ丁寧に行います。まず自分で具体的にイメージできなくてはなりません。記載してある内容が、自分自身で理解不能であれば、理解できるまで尋ねます。あるいは理解できるように、表現の方法を変えてもらいます。 仕様書に記載する文言は、誰もが理解しやすい、誤解しない表現にしなくてはなりません。作成する契約担当者本人が明確にイメージできなければ、見た人は意味不明です。理解できない仕様書になってしまいます。
ひとつひとつ内容を確認していくので、ものすごく時間がかかります。専門用語なども全て理解しなくてはなりません。2回目からの打ち合わせでは、打ち合わせ時間を1時間半とかに制限した方が良いです。その時間になったら、無理をせず終了して、また次回の打ち合わせを設定すべきです。じっくり丁寧に打ち合わせしないと、良い仕様書が完成しません。全ての内容を確認し終えれば「仕様書の原案」が完成します。
仕様書の原案作成
作業手順と作業内容の確認を終えたら、仕様書の原案を作成します。仕様書の原案を作成した後に、別の会社へ対応可能か確認することになります。
仕様書の原案では、聞き取りを終えた作業手順と作業内容の他に、契約条件を追記します。一般的には、入札参加資格、提案書の提出期限、入札書の提出期限、入札方法、システム開発の完了期限、著作権の取り扱い（官公庁側へ譲渡すること）、無償保証期間、開発完了後の操作説明などを追記したものになります。日時は予定で記載し、無理のない提出期限を設定します。仕様書の原案が完成したら、専門会社へも再確認のために渡しておきます。
他社の意見を取り入れる
仕様書の原案が完成したら、２社目の専門会社へ内容の確認を依頼します。依頼するときは、原案を作成した会社名は伏せて、最初の会社へ電話確認したときと同じ内容をまず伝えます。入札を前提に協力してもらえる専門会社を探していること、仕様書の原案で対応可能かアドバイスして欲しいことを伝えます。
仕様書の原案を確認してもらっているときに、「この部分は対応できない」という意見があった場合は、代替手法があるか確認し、どのような表現に修正すれば対応できるか、具体的に教えてもらいます。仕様書の原案を修正したときは、最初の専門会社へも、再度内容を確認してもらいます。このときも他社の社名は伏せておきます。仕様書の原案作りに協力してもらっている会社名は秘密扱いにします。（ただ、業務内容の書きぶりから、業界内では自然と専門会社がわかることが多いです。協力している会社がわかってしまっても、複数の会社が参加できる仕様書であれば問題ありません。）
専門会社２社の意見を取り入れつつ、相互に内容を調整しながら仕様書を完成させていきます。この作業に、とても時間がかかります。相手に検討してもらう期間が必要なので、かなり長期間の調整になります。もし入札手続きに余裕があるようなら、３社目の専門会社から意見を聞いても良いでしょう。しかし意見を聞く専門会社の数を増やすと、比例して作業負担が増えてしまいます。一般競争入札を実施するのであれば、競争性を確保した２社で十分です。実際に入札すれば、他の会社も参入するかもしれません。
仕様書の修正を行うときは、必ず、修正経緯を残すようにします。赤字で修正を加えて、修正日や理由を追記して残しておくのが基本です。どのような判断で修正したのかわかるようにしておきます。
複数の会社が対応できる仕様書の原案が完成すれば、正式な入札手続きへ移行します。
なお、仕様書の原案が完成しそうな段階で、参考見積書も依頼しておくと手続きが効率的になります。
コメント