Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

公共分野のシステム開発調達における上下分離のメリット

日本の公共分野におけるシステム開発の調達では、ときどき「上下分離」による調達が行われることがあります。ひとつのシステム開発を、業務設計 or アーキテクチャ設計くらいまでの上流工程と、コーティングを含む詳細設計~テストまでの下流工程に分けて調達をかけるわけですね。

この上下分離、受注者の立場から見ると、あまり嬉しいことはないように思えます。アジャイル開発の考え方からすると、「上流工程が完了したからって、ドキュメントだけもらって何が嬉しいの?」と、何もメリットがないように見えるし。ウォーターフォール開発の考え方からしても、上流工程からの情報伝達が不十分なために、下流工程で開発効率が落ちたりするし。

数年前までは、大規模なプロジェクトはこの上下分離で調達が行われるケースが多くありました。理由はいろいろ考えられるけど、基本的には「システム開発に関する調達の参入障壁を下げる」みたいな理由です*1。一方で、最近では上下分離で調達がかかってる案件は割と少なくなってきたように見えます。どうやら、2014年に出た「政府情報システムの整備及び管理に関する標準ガイドライン」で、上下分離の原則がなくなったみたいです*2

やっぱりあんまり嬉しいことないし、公平性のためにシステム開発プロジェクトが頓挫したら「角を矯めて牛を殺す」だしなぁ……というのがアーキテクトとしての感想。だけど一方で、別の観点から見ると上下分離のメリットってけっこういろいろあるのでは、という気がしてきました。

なので、基本的には「上下分離は勘弁してくれ」というスタンスのもとで、公共分野のシステム開発調達において上下分離によるメリットがありそうな点を列挙してみました。

システムに独自技術を仕込まれにくい

上下一括の発注の場合、応札者はハード、ミドルも含めたシステム全体を提案書に書くことになります。当然、RFPの範囲もハード・ミドルを含むことになります。すると、応札予定の業者がRFP案を発注者に提示する際に、内容をかなり詳細なレベルまで詰めておいた上で、こっそり「自社製品でないと実現できない機能」を仕込む、という手が使える訳です。上下分離がコレの抑止に使えるのでは、というポイント。

でも結局は、下流工程で同じように特殊なハード・ミドルを仕込まれるおそれがあるので、状況はあまり変わらないように見えます*3

このメリットを狙うなら、上下分離にするよりは、ハードウェア+ミドルウェアとソフトウェアとを分離調達にする方が効果的でしょう。ハード+ミドルの調達を顧客指定品の一般競争入札にした上で、システム開発で使うソフトウェアは許可制にするわけですね。まぁもっとも、それはそれで責任分界点の設定が大変で、発注側も受注側もプロマネがヒィヒィ言うことになるんだけど……。

会計上仕掛でなく(発注元の)固定資産にできる

実は会計はさっぱりダメなんだけど、合ってるかな?

上下一括で上流工程だけ完了した状態では、まだ仕掛なので、開発中のソフトウェアは応札した会社の流動資産になる。一方で、上下分離で上流工程だけ完了した状態では、作成した設計書は発注元の固定資産になる……という理解です。

これをうまく使って、会計的なハックができるのではと思うのですが、会計詳しい方、どうでしょうか?

短期間で入金がある

上下分離している場合、上流工程完了時点で応札者から発注者へ納品が行われ、発注者から応札者へ入金が行われます。つまり、上下一括の発注と比べて、以下のようなメリットがあると言えます。

  • 業者側は手持ちのキャッシュが少なくても応札できる。体力のない業者でも応札可能になり、参入障壁を下げられる。
  • 業者側は上下一括の場合と比べてCCCが改善する。
  • 上流工程と下流工程で年度を分けることで、発注側は単年度予算でもそこそこ大きな開発が行える(年度またがりの予算を組む必要がない)。

ただし、このメリットは予算だけ単年度×複数年の予算にすれば実現できる点も多いので、そこまでクリティカルではないかな。

組織設立を行う時間が稼げる

上流工程で業務設計を行った結果、業務運用のために新しい組織を設立する必要ができたとしましょう。その場合、組織設立の根拠となる法律を調べたり、場合によっては法律を作ったりする必要があるのではと思います(この辺はあまり詳しくない)。

こんなとき、上下一括の場合なら「開発中の代物なのに、何を先走って法律作ってるんだ」みたいな話になりそうですが、上流工程が完了していれば、妥当な説明ができそうです(この辺もあまり詳しくない)。

あと、この場合にアジャイル型で開発してしまうと「受け取る組織がまだないのに、資産となる成果物だけが存在している」という状態が発生してしまいますね。

*1:2007年「情報システムに係る政府調達の基本指針」で規定されています。参考: http://www.soumu.go.jp/main_content/000070266.pdf

*2:参考: https://home.jeita.or.jp/page_file/20160909144856_15BnwUSMol.pdf

*3:どちらにしても、システム更改のタイミングで別製品に切り替えるのは、かなりの体力が必要になる