「年金システム開発が1年以上停滞 受注企業がギブアップ、違約金を払う」

http://itpro.nikkeibp.co.jp/article/COLUMN/20120312/385822/
ちょっと古いネタだけどメモ.

「制度も決まってない段階で三社に分割発注」,しかもお役所仕事と聞いた段階で死亡フラグとしか思えないのが業界人.

つかね,この「分割発注メソッド」を言い始めたのはどこのバカだよ.

 次期年金システムの開発プロジェクトが、発注の失敗をきっかけに1年以上停滞していることが本誌の取材で明らかになった。設計作業を受注したIT企業の1社が役目を果たせず途中でギブアップし、再発注がなされないままの状態になっている。税と社会保障の一体改革をめぐる政治の混乱もあり、再開のメドは立っていない。

 ストップしているのは、オープン化を目指す次期年金システムのプロジェクトだ。厚生労働省年金記録問題」が表面化した後、既に着手していた基本設計の一部をやり直す「補完工程」を3社に分割発注した(図)。3社のうちシステム基盤設計を3億8640万円で受注したユーフィット(現TIS)が、契約を履行できなかった。

 アプリケーション設計を担当したNTTデータと工程管理支援を受注したTDCソフトウェアエンジニアリングは、それぞれ「契約どおりに作業を進めた」(厚労省年金局)。一方、システム基盤設計の進行は遅れた。その理由について、厚労省年金局は「発注側が求めていた業務と、受注側の認識との間で食い違いがあった」と説明する。ユーフィットが業務の難易度について過小評価していた可能性があるわけだ。

 厚労省ユーフィットが協議した結果、最終的にユーフィットが「継続は難しい」と同省に告げた。これにより厚労省は契約を解除し、さらにユーフィットから違約金約3000万円を受け取った。

 システム基盤設計が終わっていないため、今に至るも詳細設計に着手できない状態が続いている。厚労省はシステム基盤設計の再発注について検討しているものの、具体的な時期は決まっていない。「制度改革の内容が固まってから、改めて発注すべきだとの声もある」(厚労省年金局)。

 確かに、プロジェクトが停滞する直接の原因は、制度改革の遅れにある。制度が決まらない現段階で開発を再開するのは無理がある。だが、厚労省のシステム調達能力に問題があるのも事実だ。

 ITコスト削減のために分割発注の手法を取り入れ、安値で入札したITベンダーに発注した結果、ITベンダーの経験不足が露呈し、プロジェクトの成功が遠のく――。この構図は、1月に中止を決めた特許庁のシステム刷新と同じだ。政府はシステム調達の仕組みを抜本的に見直す必要に迫られている

  • 厚生労働省年金記録問題」が表面化した後、既に着手していた基本設計の一部をやり直す「補完工程」を3社に分割発注した(図)。」って,これだけで死亡フラグが三つくらい立ってる気が.
  • 「工程管理」ならまだわかるけど,「工程管理支援」って具体的にはなんの話をしてるんだろう?厚労省用語?
  • 「システム基盤設計」も具体的には何やってるか意味不明だなあ.やっぱり厚労省用語なんだろうか.
  • 「アプリケーション設計」という単語は分かるけど,システム基盤が作られる前に完了するアプリケーション設計は謎だな.以下同文.
  • 消えた年金問題」って,制度的な問題でもあったからなあ.まずは社会保障番号を決めないことには,システムの改訂もくそもない気が.なんで見切り発車したんだろう.
  • そもそも分割発注した理由がわからん.たとえスキルが最高でも,分割発注した段階で難易度が桁違いにあがるだろうに.厚労省に(というかお役所に)それを管理できる能力があるとも思えないし.

http://b.hatena.ne.jp/entry/itpro.nikkeibp.co.jp/article/COLUMN/20120312/385822/

  • id:qaz76 『アプリケーション設計 = 所謂普通の基本設計』『システム基盤設計 = SSO、レガシー連携、サブシステム間連携、マスタ統合とか。。公共系でよく言う、SOA担いだテンコ盛りの"共通基盤"ってヤツ』だと思う。。たぶん。

うわ,なんか危険な臭いがプンプンと.

なんつーか,貧乏くじ引かされた形?*1

  • id:yoiIT アプリ設計完了してるということは…。 N●Tデータ「アプリはこうするんでシステム基盤はこう作ってね」 → ユーフィット「無理無理無理無理無理」厚生労働省「じゃぁ違約金な」
  • id:obata_hiroshi あの辺の世界のことはよーわからんが、NTTDのアプリ設計完了って、基盤からアプリに提供するAPIの仕様だけは出来ていたということではないかな。で、周りや個別のパーツは出来たけど中枢とか全体像ができてないとか。
  • id:ka-ka_xyz ”「制度改革の内容が固まってから、改めて発注すべきだとの声もある」”みたいな状態でシステム作ろうとしたことが問題で、分割発注のせいでユーフィットが一方的に泥をかぶらされてるような印象。
  1. NTT-D:「ミドルウエアのAPI仕様書だけは書きました.実現方法は知りませんし,実現可能かどうかも検討つきません.あとはよろしく.」
  2. ユーフィット:「うん,それ無理.仕様変更を要求する.」
  3. NTT-D:「実現不可能であることを証明しない限り変更要求は却下する(悪魔の証明).我々は契約内容に書かれてることはやったので,われわれの仕事はこれで完了です.」

みたいな展開だろうか.

よほど実装経験豊富な人間が作った仕様でないと,実現が極めて困難,或いは不可能な仕様は容易に発生する.むしろそれを避けるためにこそ高度なスキルが求められる.NTT-Dにはそれほどのスキルがないわけだから,失敗のツケはミドルウエアの実装へと押しつけられるだろう.*2

利害の対立する三社があれば,そのうち一番弱い会社が割を食う.だからこそ「分割発注」が失敗する可能性は極めて高いと思うんだ.

  • id:reachout 基盤設計出来てないのにどうやってアプリ設計をやったんだ。しかし表面上公正な競争入札になってから官庁系システムの品質落ちている気がするんだよな、談合してた方が良かったんじゃ、とか

談合が良いとは思えないけど,競争入札がITシステムの発注方式として非常に良くないのは同意.まして分割発注は狂気の沙汰.

  • id:FunnyBunnyDizzy データさんは防衛線張りまくって、契約上の「設計作業の完了基準」を最大限緩めさせたんではないかと推測。実質なんもできてないけど、「契約通りの作業を完了させた」のでは。邪推とかではなく、たぶんそれが限界。
  • id:mkusunok あちゃー、これどうするんだろう?設計工程がギブアップしたのに工程管理支援は契約通りに作業を進めたといわれても。素朴な疑問として基盤設計なしにアプリケーション設計って完遂できるのか?
  • id:tamtam3 官公庁は古いシステムと整合性を求めるあまり、絶句するほどトンデモ系な注文が入るから、付き合いが浅い所がうっかり入札するとデスマーチ化。ボロボロなシステムを改めようとせずそのまま次世代に持ち込む悪い癖も

*1:もしこの予想通りなら,TISに同情するレベル.

*2:ましてその失敗のツケを被るのが他社であるならば,NTT-D側としてはAPI設計を悪くすれば悪くするほど自社の負担は減り,他社の負担は増える.つまりは,分割発注によってプロジェクトを失敗させてでも設計を悪くするインセンティブが働いているわけだ.これについてはNTT-D側を悪くいうつもりはない.そのような利害対立を助長し,プロジェクトが失敗するようなインセンティブを課した,発注者側が愚かなのだ.