【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/ nのゴミなんて移行できないだろ
全ていちから作り直せばよいものを >>316
このベンダーが請けたアプリケーションが利用する範囲のデータを調査・特定して、
ベンダーが「これでいいですよね？」と聞いたら
京都市側が「分かりません！」って、これもうお手上げなんじゃ…
「調査」と「最終確認」の責任区分が裁判で明確に分別されるかどうか… 判断できない、判断できない
うちの役所の客も言いますね。
今ある情報で判断師でリスクを負えよ！おまえの首かけてやれよ！と。 この京都のやつ、次にどこか請け負ってくれるところあるのか？？
超地雷ってばれてるじゃん。 >>322
あー、絞り込みに不備がある恐れもあるのか
こなした上での話だと思った >>322
322も言うように、機械的にファイル一覧出力して並び替えただけで「これでいいですね」と
言ってもそりゃわからんとしか言われないだろうね。
中間ファイルの除去をはじめたのはその数ヶ月後、京都市に散々指摘されてから。
これで調査したとは裁判でも認められると思えない。
これ全部報告書に書かれてるから、書かれてることだけ読むとベンダーはかなり不利だよ。
なのでベンダー側は報告書自体に不満を表明してるわけだが。 役所のシステムなんかを必死で受注しようとするからさｗ NECはIDL2という独自の言語
既存のツールでは変換できない >>308
あるあるｗｗｗｗｗ
「うちの承認を得ないと先に進むなんてとんでもない！」と言うのにその承認得るために資料を提示すると「良くわからないから承認できない」とか「忙しいからもう少し待って」で延々と引き伸ばすやつな 設計書に不備あってもあいつら判子押すよ。
で、その不備な設計書通りに開発してバグ出て遅延しても
責任は100％開発側にかぶせるよ。
｢判子の意味なくね？判子しなくてもよくね？判子欄消せや｣って気持ちになる。 >>305
＞受託事業者は，検討委員会からの質問事項に対して，「受託事業者の受注業務が現行システムの分析ではない以上，大半が不明といった状況を前提としておりません。」
ｗｗｗ こういうの統一してくのが
地方創世なんじゃまいかね？安倍成長戦略にもりこんじゃえよ >>182
スマホ対応していないページなので読みにくい
技術レベルが低すぎる >>310
(*ﾟ∀ﾟ)ハハハ、よくあるやつだね
これを読み込めばいいんだけど
内容がわからなくて全部でどのくらいやればいいのかわからないよ
ってよくあるやつだろ
見積りなんか取れない完全なブラックボックス
資料もなんもないな
やるべきこともこれを全部解析しないと出てこないな
そもそも最後どうなったらOKなんだろうな？コレ >>335
なるほどね
っていうかこれもう本番データでやるしかねぇよな
なんでテストデータなんかでやる必要あるんだ？
本番データじゃなきゃわかんないって言ってるのは京都市の方じゃんな >>145
銀行系、医療系、公共系のIT系は全て避けるようにしてる
超ブラックな匂いがﾌﾟﾝﾌﾟﾝするわ ああ、よく読んでみてわかった
これ前工程が終わってないからデータを渡さないんじゃなくて
京都市側が本番データの準備ができてないから渡せないんだ
んで開発に難癖つけて自分らの作業遅延を開発会社の品質のせいにして誤魔化そうとしてるね ちんけなIT派遣業社に委託したさ時点で
予想できた事態だよ。 京都市側のミスだよ。 んなもんわかるわけねぇだろ
バグ仕込んでんじゃねえ >>293
自由度持たせると
まず大規模自治体に合わせて
金のかかるのオラクルDBに
中規模や小規模の多くの自治体には
税金の無駄遣いなほど
非常に高価なシステムになるけど
自由度のためだからね！
各自治体でカスタマイズの名の元
新たなシステム開発することに
カスタマイズなんて極力避ける
パッケージメリットが無くなるから
アップデートに対応できなくなるから >>121
役所に限った話じゃないけど、予算上限だけ決まってるのはよくある話
馬鹿なのは予備費を持ってなくて想定外のことが起きたら即破綻するような体制の方 ソフトウェアはそのままでハードウェアの寿命を延ばす方向で行こう せめて VM ACOS on Windows とか作っといてくれれば、
「少しずつ移行」がし易くなるんだがなあ >>351
NECにそれができる技術者がいないんだろ
せめてもっとソースが追いやすくなればな >>349
根拠のない予備費なんて
まず予算が下りない
「失敗するかもしれないから金が欲しい」
と言ってるようなもの >>275
ポルトガル製インチキツール売りたいだけや(^。^)y-.。o○ >>353
そこを何らかの名目で確保するのがその組織テクニカルな部分なんだけどね
まあ一度通ったはずの要求を無理やり1割カットして予備費に充てるとか言い出す糞PMOを真似ろとは言わないけど(私怨) 京都は悪くあらへんがな(^。^)y-.。o○
インチキツール 適用範囲は?
京都 そこもわからないので調べて
他のベンダーは
対応しとる
インチキツールが調査開発する能力もなく、ただインチキツール売りたい >>355
ITベンダーから見積出させるから
ベンダー側が見積出す段階で
予備費とやらを仕込んでおかないとな >>182
見たけどACOSなんてまだ使ってたのかw >>272
自治体ごとに微妙に制度がちがうのは
小規模政党の運動成果です 制度としては同じでも
役所のなかの回覧ルートがちがうから
ある役所では月曜日にまとめて課長の承認をもらうとか
地区の相談員にもコピー渡すとか 価格ありきの入札は止めるべき
安かろう悪かろうの典型だろ >>346
なんで、サーバーやDB分けるの？
同じサービスで運用すりゃいいだろ 京都は勝てない。
もちろんベンダーにも責任があるのは確かだが100%の勝利が得られないなら京都は完敗と同じだ。
長い時間と労力をかけて役人のためだけの仕組みを入れ替えようとして、失敗した。
古いシステムのメンテナンス費用がかさみ、新しいシステムの費用もこれから必要だ。
完敗だ。 役人は民間人じゃない。
各自治体で別々のシステムを持つ資格がない。
だから最大公約数的なものに集約していく義務がある。
給与システムは納税者のための仕組みじゃないのだから >>363
いいえ(^。^)y-.。o○
京都は悪くあらへんがな(^。^)y-.。o○
インチキツール 適用範囲は?
京都 そこもわからないので調べて
他のベンダーは
対応しとる
インチキツールが調査開発する能力もなく、ただただインチキツール売りたいだけ >>365
京都府は府民に責任を取らねばならない。
相手業者じゃない。
府民は失敗した事実、その業者を選定した府の責任のみで判断する。
役人の給与システムに金を使うな、計算間違えてもいいだろ！と発言する。 COBOLコード自動変換は各所でトラブってる
自動変換後、膨大な修正・テスト工数が発生することを多くの人が認識しておらず、
自動変換でうまくいくと勘違いしてた IT業界に行くやつなんて、他に行くあてのないカスばっかだろ
就職活動でも、誰でもウェルカムなIT業界なんて無い内定の最後の砦だし
そらそんな奴らに仕事任せたら失敗するよ そりゃCOBOLの変数の使い方からしたら自動でやったらバグりますよね >>359
市長さんも自分が思う市の行政を円滑にするためには、
市議会を味方にして、予算案や関連条例を通さないと出来ませんからね
そして、円滑な市議会運営には主流派与党だけでなく、
野党議員の顔もときどきは立ててやるのが重要
そんな訳で、大勢には影響しない程度に、余所とは一寸だけ違う
野党の条例修正案を呑んでやるのです
その結果として、余所とは一寸だけ違うカスタマイズが増えていくｗ >>370
システムに運用を合わせてください
以上、終わり
できなきゃ、首ね プログラム6330本のマイグレーションを一年で達成。
移行対象と要件の洗い出し。デッドコードの洗い出し。全ての移行対象プログラムに単体テストを行い
テスト報告書はタスク棚卸ごとに提出することを明記。
こんな案件、無名中小IT企業じゃ不可能だろ。
事前にわかってるのによく入札する気になったもんだ。 >>310
> 京都市「マイグレだけの話だけど、うちじゃ移行対象が分からないから調査もやって。そっちの自費で。」
>
> これがマジだったら凄いな
レガシーシステムのマイグレーションって
発注者側も全貌を把握していないことが多いらしいよ
何十年にも渡る機能追加やら改造やらが積み重なった上、当時それをやった人がもういないとかで
ワケわからん状態になる事が多いんだと >>367
入札前に入念にテストして、
｢よし、上手く行く｣と判断したかもしれないけど
テストデータと本番データがかなり特異に違うとか？
上ﾙとか下ﾙとか変な住所あるじゃん。
あと日本人じゃない名前とか。 >>375
入札前に
どこでACOS COBOLのテスト出来るのや？(^。^)y-.。o○ どんどん失敗してください
懲りたらちゃんとお金払ってください >>362
自治体にとってのクラウドコンピューティングのメリットとは http://www.itmedia.co.jp/enterprise/spv/0907/21/news057.html
クラウドコンピューティングは各地方自治体にとっても重要にキーワードだ。
しかし共同でシステムを活用して「割り勘にすれば安くなる」となればいいが、
参加者全員が満足・納得するようなシステムは複雑かつ高額でしかなく、
「割り勘にしても安くならない」のが現実だ。 京都市の言い分(費用全額返金)は通らないにしても
ベンダーが入札仕様書の内容をナメてたようだし
契約通り11億払うでおしまいかな。 >>280
ああシグマ計画とか言うのの第二次かなw 外部の人間にやらせようというのが誤り。内部の問題だろ？ でも結構上手くやったんじゃね？
京都市側の主張だけみても
京都市が必要な資料なかなかくんないとか
京都市が想定する作業だけじゃ完了しねーよコレ
的なことだけが遅延理由だって
言ってるし
実際その通りなんだろうと思う
これでなんで喧嘩すんのかね？ そこそこ使えるものが、ある程度の期間内に出来上がらなかったり
契約金額が結構変わったりすると、関係者の出世に影響するとか
そんな理由では? コンなのに従事してきちんと動かなかったら現場開発としてはがっくりくるわ >>387
他のベンダーは成功(^。^)y-.。o○
無能はインチキツールだけ >>387
前のベンダーにはたっぷり払ってたから、なあなあで済んでたけど
今回は安く受けてるからムリと言ったらムリってことだろ >>390
担当部分と担当者・責任者が違えば結果も違うだろが >>391
安いか高いかは関係なく、契約書に書いてある範囲のことはやらなきゃならない。
それを単純にムリと言うなら、相当密なコミュニケーションと説明責任が要求される。
この手の案件の入札仕様書なんて、杓子定規に要件を満たそうとすると
請け負える企業なんて限られてくる内容なのも確かだが
「非現実なことはやらなくていいのが当然」なんてナアナアな考えで入札した
ベンダーは役所と100%揉める。 >>392
キチガイの相手しても仕方ないだろ
>>393
そうじゃなくてマージン見てたっぷり払われてりゃ客が多少ゴネたり余計な作業増やしてきても「まあ仕方ないな」ってなるけど、シビアな見積もりしてるのに
新たな見積もりの機会もなくただただ無駄な作業を思いつきで増やされそうになったらそりゃあお断りするだろって話でしょ 入札案件だからマージン設けたければマージン込みの価格で入札したらよかったんじゃ？
しかも担当範囲はざっくりとは言え入札前にオープンになってるのにそれを拒否ったんでしょ。
報告書によればだけど。 >>395
他の企業とかなら受け入れる水準のものを京都市側の能力の問題でリジェクトした可能性もあるのでない
一般的な社会人向けの資料を作ったのに小学生にでも分かる資料になるように作り直しを求められても困るだろ？ みんな自分の体験に照らして書き込むから
発注側が悪くて当然みたいなポジショントークになっちゃうんだなあ >>393
揉めて、裁判で買ってもシステムは出来上がらない。
つぎも揉めてまた買ってもシステムは出来上がらない。
ベンダーのせいじゃない！発注元のせいなんだよ。 公務員はあまりにシステムを舐めすぎてる
下らない書類、いきなり担当がいなくなる
コストが税金なのに浮かそうという気がないし
頑張ってるアピールすらせず
足引っ張る、人数も少ないし金もださない
世界最低のITスキルかも、、 せめて情報システム部に外部からの受け入れ出向が何割かいれば、、、 官公庁案件に慣れた大手にしとけば炎上しつつも出来上がってたと思うよ
もっと揉めそうなフルスクラッチ部分が予定通り終わってるのが面白い 官公系はスキルにならんどころか
金にもならんからな、、
しかも訴えてくるとかw超絶な
クレーマーだぜw
やりたいこと言えば出来るとでも
思ってんだろうね
そんなんじゃ出来るわけないんだよ だいたいシステムつくるのに入札してるのが
バカなんだよ、二つの業者に頼んで出来た方に倍
払うシステムでやっと出来るかというのが
システム開発、いいのつくったら囲う
普通の先進国なら当たり前にしてることを
してない、だからダメなんだよ これからは共通化して、共通化できないところは手作業になっていくんだろう。
コストがかかるがシステム更新費用の先払いだ。しかたない。 >>399
他の業者に出すだけや(^。^)y-.。o○ >>403
インチキツール以外のベンダーは出来たが?(^。^)y-.。o○ >>401
自分の経験では、そんなのがいても、そいつら次々と鬱病になって辞めるよ。 COBOLからMF-COBOLにするだけやろう
簡単
１本１本、丁寧にｺﾋﾟﾍﾟ修正したらええやん
手作業でできるわ おそらく京都市のシステムは例外が多すぎるのだと思いますね(;^_^A・・・
一般庶民には罰金を科すところでも寺社仏閣はスルー、部落民はスルー、共産党員はスルー、創価学会はスルーなど、
そのような「特殊なフラグ」があまりにも多く、内容が内容だけにベンダーにも仕様をそのまま伝えづらいのでしょう。
まともな行政してない癖にシステムを刷新しようなど文明人みたいなことは考えないことです。所詮、京都人なのですから。 >>410
素人の社内SEが大昔に作成したスパゲティプログラム＆仕様書・修正履歴なしの恐ろしさを知らないのか？
構造化プログラムなんて概念は まず無い >>407
大昔のCOBOLは構造化じゃないんでは？
そしてトリッキーな変数の参照してると思うのでやっぱり誰が作っても難問だと思うよ。 京都は歴史を伝える街だからコンピューター無しで仕事した方がいい。 >>414
それ以外にも、2000年対応の時に苦労したとおり、昔のメインフレームは高価だっため
メモリ（磁気コア含）・ディスク（磁気テープ含）使用量を極力抑えようとした作り。
西暦下2桁がスタンダードになっていたのも、その要因が大きい 人月商売やめて成果に支払うようなスキームが良いと思うんだが、これがなかなか難しい >>417
成果主義の現状見てたら無理ってわかるだろ >>416
西暦下2桁ならまだかわいい。
古いCOBOLのプログラムは内部が昭和○○年で持ってたりするのもある。
平成の時はやっつけで表示だけ変換、内部昭和のまま…という恐ろしいコードを
見たときは自分の目を疑った。
あのシステム、内部昭和で2桁で持ってたけど、2025年には破綻するのだが大丈夫だろうかw >>402
むしろそのフルスクラッチ部分がコードレスのツールで作られてるから
しわ寄せがデータやバッチ処理部分に全部来てるんじゃないかという気が
すごくする。 ■ このスレッドは過去ログ倉庫に格納されています
