情報システム学会 メールマガジン 2023.1.1 No.17-09
連載 発注者からみた官公庁情報システムの現状と課題
第 40 回 意外と知られていないフェーズ別の制度・業務の内容の粒度

連載 発注者からみた官公庁情報システムの現状と課題
第 40 回 意外と知られていないフェーズ別の制度・業務の内容の粒度

神奈川県庁 岩崎 和隆
１ はじめに民間企業では当たり前かもしれませんが、官公庁では、情報システム開発や改修におけるフェーズ別の制度・業務の内容の粒度が意外と知られていないかもしれません。私自身も、制度・業務担当にそういう説明をしていないと反省しています。
ここで言うフェーズとは、予算要求前、契約前、受注者作業開始前の 3 つです。
制度・業務担当がこれを知らないことが、制度・業務担当から IT 担当への無理難題になっている可能性があります。そこで本稿では、フェーズ別に制度・業務をどの程度詳細まで決めておけばよいのか、私の考えを説明します。そして、最低限のこととしてこれを守らないと、開発ないし改修プロジェクトの成功を阻害する要因になります。
２ ありがちな誤解
制度・業務担当が、受注者による開発・改修作業前の時点では、制度・業務の詳細が決まってなくてよいと誤解していることがあります。また、制度・業務の詳細は、開発・改修作業期間中に決めればよいと誤解していることがあります。このような先延ばし症候群は、開発・改修プロジェクト成功の阻害要因となります。
開発・改修プロジェクト実施にあたり制度・業務の詳細をしかるべき時期に決めておけばプロジェクト阻害要因にならないことでも、決定時期が遅ければプロジェクト阻害要因になります。神奈川県の制度・業務ではありませんが、ある制度では、制度施行数日前に１件、制度施行から２週間後に１件、制度の詳細が決まったと聞いたことがあります。このようになると、一般的には手戻りどころか業務システムへ実装できないまま制度施行を迎えることになります。
３ 予算要求前において必要な粒度予算要求前の段階では、必要な予算を算定できる程度に、制度・業務の内容が決まっている必要があります。このようなことを説明すると当たり前と言われそうですが、その当たり前のことを、制度・業務担当が見落としていることがあります。そして、IT 担当もそのことを制度・業務担当に注意喚起しないことがあります。本稿は、このような当たり前のことばかりなのですが、実際にはこの当たり前が守られないでプロジェクトが炎上することがあります。
もし、後で追加予算の確保に、金額面で困らない、かつ、追加予算確保に必要な時間も1 / 3

情報システム学会 メールマガジン 2023.1.1 No.17-09
連載 発注者からみた官公庁情報システムの現状と課題
第 40 回 意外と知られていないフェーズ別の制度・業務の内容の粒度

とても短くてプロジェクト成功の阻害要因にならないなら、予算要求前に制度・業務が何も決まっていなくてもよいかもしれません。しかし、そのようなことは例外的と考えられるので、ほとんどの場合は、予算を算定できる程度には決まっている必要があります。
この時点で制度・業務に不明点が残っているときは、予算がプロジェクト成功の阻害要因にならないよう、予算を多く確保します。予算を多く確保することが無駄と考えるな
ら、この時点で制度・業務を精査して詳細を決めておく必要があります。
４ 契約前において必要な粒度
契約前の段階では、契約書を構成する仕様書を作成できる程度に制度・業務が決まっている必要があります。私の経験では契約変更手続きに一定の期間が必要なことがあります。契約変更手続きに要する期間がプロジェクト成功を阻害する要因になることがありますので、後で契約変更が必要にならないよう、制度・業務をある程度詳細に決めておく必要があります。
５ 受注者作業開始前において必要な粒度
受注者作業開始前には、業務システムに関係する範囲で、制度・業務を細部まで完璧に詰めておく必要があります。細部まで完璧に詰めるには、制度・業務において発生する可能性があるすべてのケースを想定し、その想定に対して制度・業務上の取扱いを決める必要があります。制度・業務担当には想像力が求められます。
それでも、一部のケースを見落としてしまうことがあります。開発・改修作業中にそれが判明したときは、速やかに取扱いを決めて、プロジェクト遅延要因にならないようにします。
６ 決定した制度・業務における取扱いを制度・業務の運用マニュアルにまとめる
３から５で制度・業務における取扱いを決めたら、制度・業務における取扱いの詳細を制度・業務の運用マニュアルとして残します。ここで記録しておかなくても、取扱いの詳細は、業務システムのプログラムに落とし込まれているので、取扱いに誤りがしょうじないかもしれません。しかし、それは、リプレースしなければ、という条件付きです。リプ
レースすれば、既存業務システムのプログラムは廃棄されるので、発注者が取扱いの詳細を記録した制度・業務の運用マニュアルがなければ、リプレース後の業務システムにその取扱いが反映できません。そのため、リプレース前後で処理結果の同一性を確保できなくなります。
７ 内製のとき
以上は、現在主流である外注を前提に説明しました。内製のことを説明する前に、最近、企画だけ内製にして実際の業務システム製造は外注しても内製ということがあるの
2 / 3

情報システム学会 メールマガジン 2023.1.1 No.17-09
連載 発注者からみた官公庁情報システムの現状と課題
第 40 回 意外と知られていないフェーズ別の制度・業務の内容の粒度で、本稿の内製の定義を説明します。本稿で内製とは、企画だけでなく製造まですべて組織内要員で行うことを内製と言います。
内製では、予算要求と契約が不要です。しかし、その代わりに IT 部門が開発・改修す
るなら IT 部門への発注が、自らの部門で開発・改修するなら人員要求が必要になります。それができる程度に、制度・業務の詳細を決めておく必要があります。内製による開発・改修作業開始前は、外注のときの受注者の開発・改修作業開始前と同じです。
８ まとめ制度・業務担当が、受注者による開発・改修作業前の時点では、制度・業務の詳細が決まってなくてよいと誤解していることがあります。また、制度・業務の詳細は、開発・改修作業期間中に決めればよいと誤解していることがあります。しかし、実際には、予算要求前の時点では予算を要求できる程度に、契約前では仕様書を作成できる程度に制度・業務の詳細が決まっている必要があります。そして、受注者による開発・改修作業開始前には、制度・業務において発生する可能性があるすべてのケースを想定し、その想定に対して制度・業務上の取扱いを決める必要があります。
なお、以上は外注前提の説明ですが、内製でも同様です。
９ おわりに（１）お断りとお願い
本稿の内容は、神奈川県の見解でなく、私の知見と記憶に基づくものです。
本稿へのご助言、ご異論、ご感想、ご質問や、今後取り上げるテーマのご要望をくだされば、大変幸いです。特に、ご異論やご助言は、私の考えをブラッシュアップしてくださる、貴重なものです。心より、お待ち申し上げております。
（２）私への連絡方法
ご意見、ご感想などは、私の連絡先をご存じの方はその方法で、ご存じない方は次の方法で連絡可能です。
researchmap（国立研究開発法人科学技術振興機構が運営しているデータベース型研究者総覧）の Web サイトで私を検索してください。私のページの「ホーム」タブ（最初に表示されるページ）に私への連絡方法を掲載しています。

3 / 3