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