【IT】システム刷新に失敗した京都市、ITベンダーと契約解除で訴訟の可能性も
■ このスレッドは過去ログ倉庫に格納されています
京都市は2017年10月11日、NEC製メインフレームで稼働している基幹業務システムの刷新プロジェクトについて、バッチ処理プログラムの移行業務を委託していたシステムズ（東京・品川）との業務委託契約を解除したと発表した。作業の遅れで京都市は既に稼働時期を2017年1月から2018年1月に延期していたが、それがさらに遅れて2020年になる見込みである。新システムの稼働時期は、当初予定よりも3年以上の遅れとなりそうだ。
京都市は2014年から81億円を投じて、国民健康保険や介護保険といった福祉系のほか、徴税、住民基本台帳の管理など18業務を担っている基幹系システムの刷新プロジェクトを進めてきた。現行システムは30年前に稼働し、COBOLで構築している。
既に京都市は、福祉系のオンライン処理の刷新を予定通りに終了させている。地場のITベンダーなど5社が落札し、COBOLプログラムをポルトガルのアウトシステムズ製の超高速開発ツール「Outsystems Platform」を使って刷新した。
バッチ処理のマイグレーションテストで見解が相違
ところが、福祉系のバッチ処理の移行作業が進まなかった。NECのCOBOLプログラムを英マイクロフォーカスのCOBOLプログラムに変換（マイグレーション）する際のテスト手法などについて、京都市とシステムズの見解が一致しなかったからだ。システムズは2016年1月15日に移行業務を落札。落札額は予定価格の79％である11億376万円だった。
京都市は2016年11月14日に市議会で稼働遅延を報告。2017年1月23日に門川大作市長が稼働延期を説明し、第三者の専門家による「検討委員会」が原因究明と今後の方策検討に当たると表明した。検討委員会は2017年6月に調査報告書を市に提出。現場の移行作業は2017年7月24日に京都市からの申し入れで停止している。
調査報告書を受けて、京都市は「円満な解決の可能性を探るため」（公表資料）に、システムズと2017年8月と9月に面談。だが、作業再開に当たって京都市がシステムズに要請した3条件を合意できなかった。具体的には「現在の契約金額の範囲内で完成させる（追加費用を支払わない）」「遅延による京都市の損害を賠償する（金額は別途協議）」「システムズの負担で、京都市が承認しうるプロジェクト管理業者を選定して開発体制を構築する」というものだ。
京都市は「遅延の根本的な原因に対する見解に大きな乖離があり」（公表資料）、システムズとの協議によって解決するのは困難と判断。2017年9月22日には2週間以内に債務を履行しなければ契約を解除する旨の催告書をシステムズに送ったが、債務が履行されなかったため2017年10月11日に契約を解除した。
以下ソース
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/ 大体役所の案件って、後でいくらでも付け足しできるように「等」とか「付随する業務」とか絶対つくからな
お役所テクニックの一つなんだが。
入札しなきゃいけないし、入札したら基本的には一番安いところを選ばないといけないのは、入札の負の部分
でも、トータルでは競争入札がいいと思うよ
公務員は手抜きだからすぐ業者に丸投げしたがるから。
この前まで、三社見積もりとか入札関係書類業者に作らせてたくらいだから スレタイ見て「はは、まさか現行COBOLじゃないよなぁ」なんて思いながら
スレを開いたら、COBOLだった笑 >>1
民間ではアホみたいな金額を払う役所
だから丸投げ
だから要件未確定
だから後出し
以下ループ 予定価格の79%で落札という時点で失敗しか見えなかったw よくわからん
市役所のシステムなんぞ皆同じだろう
何で 他の市町村のシステム持ってくればいいだけだろ！ こういう失敗増えるだろうから民間と同じように失敗した際に
その行政区域の公務員の給与に反映されるような仕組み作ればいい 普通、ここまで来ると業務から仕様を起こそうとするけど、それも公務員じゃ、
業務を包括的に把握している人間は皆無だから駄目なんだろうな。
で、COBOLで動いているアレを・・・って業社丸投げなんだろうな。
受けた方もCOBOLはよくわかる人間がおらず、「そのまんまコンバートかければ
使えます」的なツールを使ってみましたと
年寄りCOBOLer雇って業務をあぶり出して、それを今風の言語に置き換える・・・
そんなのは、大手じゃ無いと難しいよな。
自治体のパッケージってどっかで作ってなかったかな。
航空業界や銀行みたいなやつ。
日本独自だから難しいか。 売上高27億のITベンダーが約1年開発を11億で落札とか無茶しやがる >ところが、福祉系のバッチ処理の移行作業が進まなかった。
>NECのCOBOLプログラムを英マイクロフォーカスのCOBOLプログラムに変換（マイグレーション）する際のテスト手法などについて、
>京都市とシステムズの見解が一致しなかったからだ。
→京都市側が日立COBOL、Merant Micro Focus COBOL、富士通 COBOL85などの違いを理解していなかった恐れｗ
「現在の契約金額の範囲内で完成させる（追加費用を支払わない）」
→追加予算無し
「遅延による京都市の損害を賠償する（金額は別途協議）」
→遅延した分の金払え
「システムズの負担で、京都市が承認しうるプロジェクト管理業者を選定して開発体制を構築する」
→業者を選べ。ただし俺が許すまで選べ
( ﾟдﾟ) 自治体毎にシステム作るとか税金の無駄にも程があるな 自治体が共同で出し合って統一システム作ればいいのだけれど
それだと都合の悪い利権の人たちがいるだろうね 総務省が主導して全国共通自治体システムを配布すりゃ
なんて無理かな >>53
そのためには、仕事のやり方を各自治体でシステムに合わせて統一しないといけないが。ら
日本では基本逆にシステムが合わせろだから無理 国家公務員はそういう統合システムになってきてる。
もちろんそれも超地雷だったが、不具合が有っても移行しろと命令が出たから移行中だよ。 >>55
後で次から次に仕様変更出してグチャグチャになるからなぁ
上から下までがコレなもんで困る >>23
超高速開発ツールとは、奴隷達が命を削って(時には失い)働くという意味だよ。 >>54
福祉関連は自治体によって制度がちがうから無理だろね 全国で統一すると、大手がとるし自治体ごどのオペレーションの違いを吸収できる汎用性持たせなきゃだし、
開けてみたら凄まじい額でかつ使いにくいシステムを押し付けられるしで最悪なことが起きる可能性 作業毎に別々に発注して
プロマネを素人の職員がやったんだろ できるプログラマは仕様変更があってもプログラムは組まない
設定データを変えるだけで仕様変更にも対応できるプログラムを最初から作っているから >>53
そんなことしたら、都内の天下り団体が死んじゃうだろ オペレーションをシステムに合わせないからトラブルやムダが出まくる テスト「手法」の意見の相違だけで契約がご破算？
他にもなんかあっただろ！ 予定価格の８割未満での落札なんて、安かろう悪かろうじゃねーか
役務系は仕様変更とかの追加が有って当たり前なんだから、こんなに安く受ける方も選ぶ方も悪い ＞NECのCOBOLプログラムを英マイクロフォーカスのCOBOLプログラムに変換
COBOL方言→COBOL方言なんだが
ちなみに、マイクロフォーカスCOBOLはPC-COBOLの最大手 そもそも、どこの自治体も必要なこんなシステム群を個々に作って管理してるのがアホ
政府がクラウドで提供すればいいじゃん >>69
クソ高いNECの汎用機から安価なPCアーキテクチャへ変更したかったんだろ >>71
javaとか別言語へはとか書いてるヤツが、上にいっぱいいるだろ テスト「手法」の意見の相違だけで
契約がご破算になるか？
他にも原因があっただろ
もう少し詳しく経緯を説明してくれないと
問題の所在がわからん そういえば沖縄のシステム大丈夫かな
ここだけの話
なんとかサムソンって会社のソフトが（以下略 >>25
おそらく
開発「要件は満たしてるよね」
や糞「俺の理想と違う!」 >>53
身内のなんちゃってIT企業に発注できなくなるからな >>75
要求仕様書に書いてないことやれとか言われたんだろ。 京都市の再開に向けての3つの条件がこれひどい話だけど、ここまで馬鹿にした条件を出さないといけない程にベンダーのPMが無能過ぎたんだろうな
旭川医大はPMが超絶努力したから首の皮一枚で司法に救ってもらえたけど、ここは何やってたんだろうな
全額返金+遅延で生じるた損害+今後生じる損害まで請求される可能性もあるで 地方のシステムなんかどうせ皆同じ様なものなんだろうし、
まとめて発注しろよ。 >>80
ナマポがらみのおおっぴらに出来ない裏仕様でもあったりしてなｗ OOoの時もそうだけど、詐欺師に騙される奴ら多いよなぁ・・・ >>75
新しい会社だと「全件テスト」の概念すらなくて、品質レベルが低いのよ。
特にスマホのソフト開発上りだと「後から直せば良い」の概念で作るから作り込みが甘いのなんのって・・・ どうせシステム仕様がコボルのソースコードしかなくて
「全く同じにしろ！」とか無茶なこと言ってんだろ
この期間の伸び方は客がバカなパターン >>86
下手に言語を変えて成功する例の方が少ないよ。
こーいったシステム開発では、10年以上かけて安定したシステムと同じレベル以上の品質を最初から実現しなきゃならん。 >>88
システム屋が行程毎の同意を取ってないだけだと思うよ。
責任をユーザーに認識させれてないのは、システム屋のレベルが低い証拠です 損害賠償はSirに付き物。保険で支払っておしまい。 >>81
だよね〜
べンダーの営業もマネージャーも無能過ぎる。
請けた事自体が間違いのレベル >>90
論理破綻が平気で起こるんだよ
特に自分で手を動かさないのに看板頼りでふんぞりかえってる公務員や元国営系なんか
まともに話が出来ないレベルの馬鹿だらけだから NECはわざと分かりにくいシステム作るからな。あいつらが関わった案件に手を染めたら死ぬ 特許庁のシステム云々で
東芝が開発に失敗した騒ぎと似てる 外国なんて 問題外だろ 日本の年金福祉だ
地元の企業にしないから いちいちの手間時間が掛かる
さっさとあきらめて 国民に奉仕しろ＼(◎o◎)／！ >落札額は予定価格の79％である11億376万円だった。
「安物買いの銭失い」やね 普通のカード型データベースソフト買ってくればいんじゃねの？ アホ公務員が無理な仕様変更重ねたんだろ
容易に想像できるわ >>101
ぜってーやってるよね
基本的に仕様変更無しで作成仕上がらないってありえないし >>1
円満解決させる気がなくてわろた
システム側は賠償請求しないとな 裁判では勝つと思うなｗ
アホのお役人が資料なんか残してると思えない
やっちゃえやっちゃえ
二度とシステム化なんて考えないぐらい
滅多滅多にしちゃえ >>104
クラウド馬鹿発見ｗｗｗｗｗ
バッチ処理のマイグレーションテストで揉めてんのにそんな部分が関係するかよ ｗｗｗｗｗ >>94
刷新必要だったのかねスパゲティは放置プレイに限るとはよく言ったものよ >>101
ほんこれ
一般大企業にすらまともに発注できる奴一握りなのに
公務員なんかにできるわけがないｗｗｗ >>104
ジャップの特徴
自分でも良く分からない言葉を見栄のためにわからないまま使っちゃう 30年前のシステムってことは、まともな設計書や仕様書が存在せず、
○○機能は(開発元の)××さんが生きた仕様書って奴だろ。
勘定系の大型システムの更新で何度も食らったわ。
そういうのを大きく更新するときは、まずもとの開発元をガッツリ
指名で抱き込んでやらないと確実に破綻するってのに、どうせ入札で
安いところを選んだんだろうな。
京都市の自業自得だよ。 役人がシステムのこともわからないであれこれ口を出すからごちゃごちゃになるんだよ。
黙って外部の専門家に任せておけ。
それと、役所のシステムなんか、一回リセットして最新の技術で作り直さないとだめだよ。
たぶん運用経費が10分の1くらいになる。 京都ITに力入れてるのにこれはイメージダウンは免れないな ＞「現在の契約金額の範囲内で完成させる（追加費用を支払わない）」
＞「遅延による京都市の損害を賠償する（金額は別途協議）」
この条件に応じられるのは一部大手だけだな。 どうせ、こうなるんだから、仕様を完全に煮詰めて承諾印をトップに貰ってから現場の
担当者の責任が逃れられなくなってから、やればいいのにな。
そこまで詳細な仕様書をつくる力がないとかだな。 こういうのってイチからシステムを作り直して
完成した時点でデータだけ移行ってできないの？ 仕様変更当たり前なのに「追加料金は払わない」ってのも酷い話だ
「仕様書＝設計書」という概念が無いのか >>121
裁判で京都市は絶対負けるよ
これで勝てるとか思っちゃうほど
役人って馬鹿なんだよ >>119
現行システムデータを含む完全な仕様書があれば可能だが、
そんなものが存在したシステムは見たことがない。
だから他社の既存システムからの移行は毎回現場担当者からのヒアリングや
データやログ、バッチジョブシートの解析を延々と行うことになる。 最近はAWKとかいうのが凄いらしいから、それで書き直せばいいのにな 多分漢字がらみのソース・データの変換とテストの問題だな
ポルトガルの会社じゃノウハウゼロだからな
NEC側 JIPS（J)、JIPS(E)、内部コード(J)、内部コード(E)
新ｼｽﾃﾑ シフトJIS、Unicode(UCS-16、utf-8)
一番単純なマイグレーションでも、ざっとこれぐらいの漢字変換を固定長レコード上で行う必要があり、
漢字コードの種類によっは項目幅が変わって来る→COBOLのソースも変わって来る
地道な手法を使わないと、移行なんて無理なんよ >>123
そうなることはわかってるけど
見積りにんなもん乗ってないし
いざとなったらお役所金出してくれんでしょ頼みの開発だからね
無い袖振れないやつに媚びる必要など欠片もないわけで 役人って一般常識からかけ離れすぎなんだよ
逆にアホみたいなぼったくりにも気付かないパターンもあるし >>125
そこにおそらく誰も管理しきれていないほど膨大な外字が存在しているのが
余計に難しくしていると思う。 旭川医大の件もそうだけど、IT業界で働くことのバカらしさがよくわかる事例になるだろう
日本の商習慣のクソさと顧客・IT企業側の営業の低レベル加減は現場の努力で吸収出来る範疇ではない >具体的には「現在の契約金額の範囲内で完成させる（追加費用を支払わない）」
>「遅延による京都市の損害を賠償する（金額は別途協議）」
俺は情報工学系だが、こんな契約を見たらどんな業者でも「ふざけるな」と蹴る事案。
「俺達の気まぐれで仕様書が変更になって延滞しても企業の責任なｗ」と言っているようなもの。
仕様書の変更は発注者側の責任、
その損害責任は発注者側にある。
こんな契約ではデバッグが満足にできず、
バグ発生確率は上昇する。 >>115
アップグレードやアップデートを知らない素人は黙ってろ。 >>120
技術が新しければ良いというものでもない。
ハードウェアやオペレーションシステムとの互換性に問題がない限り、
良いものは何時の時代でも良いもの。
わざわざJAVAにする理由がどこにあるか。 >>18
調べてみたら宣伝は上手そうだったぞｗ
役人は信じ込んでしまったんだろｗ 普通メインフレームのコボルからマイクロフォーカスのコボルのリプレスでそんな面倒なことはないと思うんだけどな、、、 >>132
オワコンに向かってるJAVAに拘る必要はないけど、COBOLのdatasetレコード
管理からDBにデータを移行するのはさっさとやっとけと思う。
まあ、中にはCOBOLからOracleに移行しながらレコードサイズ256バイトの固定
フィールド作ってViewで分割しただけみたいな某社のケースもあるから、
移行しただけじゃ意味ないのだけれども。 >>114
でもそれやると談合だって話になるんだよな ■ このスレッドは過去ログ倉庫に格納されています
