システム開発でベンダ任せをやめようとした日本、ベンダに任せた米国
う～ん、まあ、相変わらずツッコミドコロがいっぱいあるのだけど、一番肝心なところだけ。
総務省の情報システム調達ガイドラインを読んでないよな
もちろん、政府もこうしたことに深刻な問題意識を持っており、民間から政府CIOを起用し、そのスタッフも充実させるなど更なる改革に取り組んでいる。2015年4月からはシステム調達に関する新たなガイドラインも施行する。
(中略)
だが、あくまでも「この通りに実施できれば」の話だ。ガイドラインでは、システムを導入する際には利用部門の業務改革を行うことを義務付けている。全く正しいが、この手の業務改革は民間企業で軒並み失敗しており、ハードルはさらに高くなる。業務やITに精通するだけではダメで、ベンダーマネジメントや、利用部門を統制する“ユーザー”マネジメントなどをこなせるIT人材が必要だ。
(中略)
そして地方自治体や外郭団体に至っては、その多くがいまだに丸投げ＆ベンダーロックイン状態にある。
政府のIT調達の問題点をもしかしてきちんと理解してないんじゃないのだろうか。
政府のIT調達において、「ベンダ任せをせずに政府側で開発コントロールする」こと、つまり「分離調達」がしばし問題となっております。
分離調達というのは、「要件定義支援」「設計／開発」「保守運用」など、フェーズごとに受託者を分けて受注する方式のこと。要件定義を担当したベンダは保守に入札できないなどの制約を受けることとなっており、特に大規模な案件では、分離調達が必須となっております。
で、この分離調達ってのは少なくともシステム開発する上で問題になることが多い。
この政府調達方針もそうだけど、情報システムにおけるエンジニアリングの知見で、「システム要件が決まらなきゃ、開発手法も契約方式も成立しない」ってのがあります。
分離調達で開発工程ごとに契約を結ぶ、しかも要件定義工程も別途設ける、ということは、「何を」を決める前から「どうやって作る」「お金をどう払う」が決まってしまうこととなります。
分離調達では、ウォーターフォール開発が前提となります。システム開発をよく知らない人が良くする誤解でウォーターフォール開発は手戻りができないってのがありますが、実際は前後工程間のフィードバックを重ねながら品質を高めるコトが必要な開発手法です。
分離調達で要件定義・設計・開発が分離されてしまうと、それらのウォーターフォールのフィードバックを効かせることも困難です。
つまり、通常であれば後工程になればなるほど、リスクが減少するはずのウォーターフォール開発にて、後工程ほどフィードバックできずに積もり積もった品質上のリスクが積もっていくという恐ろしい状態となります。
これを、従来開発しているベンダが請け負うのならともかく毎度契約を結び直すわけで、知見の蓄積もできない。事前にリスクを洗い出すことも、要件を整理することもできない。
もちろん、上記の様な開発計画を立てるための知見を政府内で育成するって考えもあります。ただ、それは「定期異動」によって阻まれてしまいます。知見を育成しても、定期異動で別部署に異動となってしまえば知識は失われてしまう。
定期異動を行わなくすれば？
そうすると、今度は業者との癒着と言った懸念が上がってしまいます。
つまり、構造的にうまくいくようになってないわけです。
これらの指摘は、政府調達の問題点としてしばし指摘*1されております。
これを受けて策定しようとしたのが、２０１５年４月からの新規の「政府システムの整備及び管理に関する標準ガイドライン」です。
これには、以下の様な記述があります。
分離調達の見直し
新ガイドラインでは、合理的な調達の基本単位の考え方を明示するとともに、過去促進していた情報システム設計・開発工程における分離調達を見直し、過度な分離調達を抑制
そう、従来の政府主導の分離調達を見直し、一括調達、要は必要に応じてベンダ任せ（極論すれば丸投げ）を再度認めようって腹なんですよね。
過度の分離調達でうまくいかないのであれば。ベンダのノウハウを使う方式にしてしまおう、ってわけで。
こういう記載を見れば、元記事の木村氏、きちんと政府調達のガイドラインを見てないんじゃないのだろうか。
※まあ、従来から丸投げはいけないって純朴な考えから言っているわけで、丸投げはダメありきでしか考えてないから読み飛ばしているのかもしれませんが。。。
米国では一括発注を活用している
ところで、この方は普段出羽守なわけですけど、今回の記事では「米国政府を見習え」って言ってませんね。
実は米国政府では、システムは一括発注がメインだったりします。
実質的には有力プライム（大手ベンダー）への一括発注がほとんど
図２に示すように、システム構築全体はプライムコントラクター（大手ベンダー）が握っている。ここでは、実質的に有力プライムへの一括発注がほとんどで、プライムが受け、（必要に応じて）入札時・入札後にサブコンに振り分けている。特に、ミッションクリティカルなシステムでは、実績・関係の両面で省庁の厚い信頼を得ているベンダーにしか発注は行われない。
信用力ある大手ベンダーがシステム構築プロセス全体のend to end responsibilityを担保しているわけだが、これは、日本での状況の生き写しである。
ボストン・コンサルティングのレポートで、10年前のモノですけどその時からさほど変化があったと聞いてないので引用してます。
実は米国政府では、システム調達の不達、トラブルが多発したことから、プライムコンストラクタへの一括発注におおよそ20年前、1990年代から切り替えてます。
工程の分割などは原則行わない、プライムベンダの統括責任で行動させる、プライムコンストラクタがサブコンストラクタを必要に応じて招集するなどの、開発を成功させることを再優先にした構造となってます。
また、分割発注自体は0ではないですが、日本のよう工程別分離調達ではなく、要件別の分離調達で実施がほとんど。
日本がベンダをコントロールしようとして工程別の分割調達で失敗している状況とは対比な状況です。
ちなみに、一括調達とはいえ、日本と同じで、発注時にすべての要件を決めきれず、後追いで追加するなんてのもしばし起きうる話です。結局システム開発なんて人間が行う訳で、あまり日米関係ないってわけですね。
元記事で言っているような発注時点できちんと要件を決めきれるなんて米国政府だって実現しきれてない話です。米国ではそういった問題をベンダの権限拡大と契約(実費償還型契約など)で上手くリスクを分け合う形にしているわけ。
※とはいえ、ITコスト削減のため、近年は日本の請負契約と同様の固定費用契約を増やしてきているみたい。
なんで分割調達となったのか
じゃあ、日本のIT業界は米国の10年後追いと言われる中、なんで米国の後を追って一括発注を採用せず、原則分離調達などという無理ゲーに手を出したのか。
元記事にも一部書いてありますけど、「費用の透明化」と「公平な入札機会」が大きな理由としてあります。
費用の透明化は、システム構築コストとして無駄金を使ってないか、不正な取引がされてないかのチェックが必要という世論の高まりを受けてです。
現在の分離調達の検討が行われた時、時の総理大臣は小泉純一郎元首相でした。
うろ覚えですが、財政健全化に向けての構造改革の一環で見直しが行われた記憶があります。
※当時竹中平蔵氏のブレーンで、現民主党の岸本周平氏が「政府調達制度と IT システム―“IT ゼネコン”を育てたの誰か」*2みたいなレポートを書いていた時期ですね。
公平な入札機会は、要は、一括発注だとリスクが大きすぎて大手ベンダだけしか請け負えず、IT業界の多重請負構造を改善できない、中小ベンダも直接入札参加できるよう改善して欲しいという要望を受けてのものです。*3
開発ノウハウが固着してしまい、随意契約に頼らざるをえないと言った問題も指摘されてました。
こういった改善のために、分割調達となったわけですが。。。
結果としてみれば、費用の透明化は実現できたものの、IT調達の不達、失敗により多額の税金をドブに捨ててしまう事となってしまいます。開発の際も余計なリスク＝コストを抱えることとなり、結果としては必要経費が増加へとつながってしまいます。
開発工程を分離したものの、前述したように後工程ほどハイリスクとなってしまい、結果として大手ベンダが開発工程も請け負うようになっている始末。特許庁システム更改の時の開発工程をTSOLが請けたように。
「IT投資の無駄を無くせ」「多重請負を解消しろ」って掛け声の元の改革は、元々の問題を解決するどころか、むしろ新たな問題を発生させるだけになってしまったわけです。
まとめ
えらく長くなってしまいましたが、結局言いたいこととしては
「元記事はきちんと問題理解して記事書いているのかな？」
という疑問です。
少なくとも、JEITAの指摘しているように、分離調達の問題点を指摘することが開発者視点で必要だと思ってますが、それに触れられてません。
実効性のない問題提起は、結果として「新たな問題を発生させるだけ」になるのじゃあ無いのかな、なんて思います。
この極論暴論で語られる問題提起はまあだいたいそうなのですが。
以上
なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術
- 作者: 細川義洋
- 出版社/メーカー: 日本実業出版社
- 発売日: 2013/09/27
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (9件) を見る
