【IT】京都市とIT企業がシステム裁判に、基幹系刷新の完了は3年延期
■ このスレッドは過去ログ倉庫に格納されています
2014年から81億円を投じ進めている京都市の基幹系システム刷新プロジェクトは、稼働遅延を経て、ついに訴訟に発展した。バッチ処理のマイグレーションを請け負ったITベンダーのシステムズ（東京・品川）が、未払いの作業費の支払いを求めて2017年11月8日、京都市を提訴した。京都市は反訴も辞さない姿勢を見せる。
システムズの訴えは2017年4〜7月の作業費の未払い分とする1億9900万円を支払えというもの。提訴した翌日に弁護士名で京都市に内容証明郵便を送り、提訴を通知した。訴状の写しも送った。
システムズの提訴に先立ち、京都市は10月11日に同社との設計・開発等業務委託契約を解除した。「遅延の根本的な原因に対する見解に大きな乖離がある」というのが理由だ。原因と打開策を探るために京都市が立ち上げた第三者委員会は6月に報告書を公表し、その後に両者は2度面会したが溝は埋まらなかった。
関連記事：システム刷新に失敗した京都市、ITベンダーと契約解除で訴訟の可能性も
解除の2日後にはシステムズに7億5024万4003円を請求した。内訳は既払金5億662万5000円とその利息2318万7307円、遅延による現行システム維持などに関わる損害賠償金2億2043万1696円である。京都市は2度にわたって支払いを求めたが、システムズは応じていない。
関連記事：関係が泥沼化、京都市が7億5000万円請求するもIT企業は支払い拒否
京都市の情報システム部門に当たる総合企画局情報化推進室はシステムズからの訴状の写しを受理。11月15日に問い合わせると「今後の対応は検討中」と話したが、約7憶5000万円を求める反訴を起こす可能性が高い。
10月24日の京都市議会で京都市の米谷英剛情報化推進室長は、システムズからの支払いが無い場合の対応を市議に問われ、「支払われなかったら行財政局や弁護士と相談・協議し、法的措置も含めて対応を検討する」と答弁している。一方でシステムズの栗尾執行役員は「京都市から、第三者を介した調停はしないと告げられている」と明かす。訴訟合戦は不可避だ。
京都市は2017年1月から順次稼働するはずの刷新が遅れており、遅延の原因はシステムズにあると断定している。「作業品質の問題。プロジェクトマネジメント能力も問題がある」（京都市議会での米谷室長）。
一方システムズは「京都市が実施すべき現行システム分析の不備と、これによる基本情報の不足が原因。契約解除は不当」（栗尾執行役員）と主張する。
仕切り直しで8億円増
契約解除により、バッチ処理プログラムの移行は宙に浮いたままだ。京都市はプロジェクトの仕切り直しに動き出し、11月6日の市議会で今後のプランを明らかにした。
新たなスケジュールでは基幹系システムのうち福祉系の稼働時期を当初計画より3年遅れの2020年1月、住基・税系を3年2カ月遅れの2021年1月と決めた。開発費は合計で8億円増える。
元号の変更を含めた大規模改修がいくつか控えており、バッチ処理の移行対象プログラムそのものの量が増えるほか、オンライン処理を含めたシステム全体のテストを実施するので増加したという説明だ。ただし、移行が完了しているオンライン処理プログラムを大規模改修する費用は別途かかるという。
京都市は仕切り直し後もバッチ処理プログラムをマイグレーションで刷新する方法を引き続き選択した。NEC製メインフレーム上で30年来稼働するCOBOLプログラムを、業務ロジックを変更せずにオープン系COBOLにマイグレーションする「リホスト」を進める。
新たな委託先は2018年3月までに一般競争入札で選ぶ。京都市は一般競争入札での選定方式を、前回（2015年）調達の低価格方式から今回は総合評価方式に変える。総合評価方式では自治体への納入実績や、「プロジェクト管理能力を持ち企画から運用までを担える」実績などを評価項目に新たに盛り込む。
京都市は前回調達では、「移行方法をマイグレーションに特定したため、技術的な評価に差が付きにくい」と考えて低価格方式を採用した経緯がある。予定価格13億9719万6000円に対し、システムズが11億376万円（予定価格の約79％）で、キヤノンITソリューションズが12億3442万2666円（同約88％）で、ソフトロード13億1819万760円（同約94％）でそれぞれ応札。最も安かったシステムズが落札した。
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/111601207/
関連
【IT】京都市､開発遅延で7億5000万円請求もIT企業支払い拒否 言語はCOBOL 京都市「元号の変更もある(ので損害賠償はもっと増える)」
http://egg.2ch.net/test/read.cgi/bizplus/1509778114/ >>138
設計書が残ってないから、単体テスト結果が正しいかどうか判断出来ない。
そして要件が分からないから、結合テストのテスト項目が抽出出来ない。 >>143
うむ。これで品質を上げろと要求すると、意味合いがかなりおかしなことになる
現行システムに、より似通った動作を実現するソースの生成、それを可能とするソース変換の追求、かな
修正の度にデグレもあることだろう
設計ありきじゃないからひたすら大量のトライ&エラーが必要なんじゃ？ いったいいつから渡されたソースコードが最新だと思った？ 難易度というより、手間の問題だから、その気になれば大手ならどこでもできるでしょ。
あとは、開発費が折り合うかという問題。 >>147
大手だろうが現行の仕様が不明なシステムのリプレイスは不可能。 >>148
仕様が不明なら確定させるだけ
安上がりかつ短期間でできると思って、リプレース選んだだけだから
大手がこの状況になったんなら結構な額の人件費を垂れ流すことを引き換えに、客を巻き込んで仕様を一部確定させたりして
人海戦術で進捗だけは進むようにやり方を修正する
それが大手(に限らない？)の責任の取り方
今回、システムズの続きを引き受ける大手がいるかどうかは不明 >>149
客を巻き込んで
って京都市はそれを全面拒否したんだけど。 >>150
先が見えないから追加の払いや労力を拒否したんだよ。良いか悪いかは別にして
終わらせられるとなったら、多少の赤字や追加予算を出して終わらせるのがおしごとというもの
訴訟したって得するわけじゃないからな >>151
そんなのは理由にもならんな。
出すべきものを出さなかったことで被る不利益は発注元にあるのは明白だ。 京都市の報告書読んだけど、仕様が不明確な状態で進めることについて、
システムズが工数の観点で「京都市の言うとおりにはできない」と主張してるのであって、
赤字覚悟で、力押しでいけば解決する種類の問題に見えたけどね。 >>153
赤字でもやりきることができるのは大手だけ
安値で引き受けた弱小には無理な相談
やったらつぶれるもん
なぜ仕事引き受けたんだレベル 大手はいざという時の奴隷会社キープしてるしな。
システムズの配下で喜んで契約してくれる会社なんて、まずいないだろうな >>149
仕様を知ってる人も作り出せる人もいないのに、どうやって確定させるんだ？
京都市は「その方法を考えるのはベンダーの仕事。でも俺たちが気に入る方法じゃないと駄目だよ」って言ってるんだが。 大手にはシステムにまったく影響を与えず現行サーバから情報を抜き出して
瞬時に内容を読み解き、新システム用のプログラムに書き換えることのできるスーパーハッカーがいるとでも思ってんじゃね？ >>156
単にすべての仕様を把握してる人間や資料が存在しないだけだよ
システム使ってる人と現行システムのソースがあるんだから、必要なことは大雑把に分かる
双方がカネと労力を費やしさえすれば、費やした分だけ仕様を固めることができる
あとは「現行通り」をどこまで追求するかフトコロと相談するだけ >>159
現行通りより使い勝手のよいシステムあるよと売り込み >>158
>>159
最近は炎上案件の噂たった案件にはどこも人を出さなくなってる。 まあ好き好んで手を出すところがあるわけないわな。何より京都市側の態度が透けて見える
現行の仕様の把握がいいかげんなのに、「現行通り」の置き換えなら時間もカネも浮かせられるだろう、とか考えてるあたりがどうしようもない
ろくに自分ら側は労力も割かず、難航してるのは相手の水準が低いから、とか言い放つのに躊躇がないとか
仮に水準低いのが本当だったとしても酷い
ドブさらいみたいな面倒して片付けても絶対感謝されないよ、これ >>159
大雑把に分かっても仕方ない。
細かく厳密に正確に完璧に再現しないと駄目。
でないとバグだから。 >>163
そこから仕様を詰めるってことだろ
大雑把に分かったことから、客に仕様を最低限決めさせるしか、着実に泥沼を抜ける目処がつく方法はないよ
現行通りの動作でないことをバグと呼ぶのではなく、客に決めさせた仕様を満たさないことをバグと呼ぶように改めてこそ、人海戦術が解決法になる
現行通りーの案件で火を吹いたのをゴリ押し解決する場合によくやる >>164
客は仕様を決めれない。
システムは昔の人が作ったブラックボックスだから、誰も仕様なんて知らない。
なので、どんなテストすれば良いか分からず、ベンダーに「俺が正しいと納得出来るテスト方法を考えろ」と投げるんだ。 役所のシステムは法改正ごとに屋上屋を重ねて作られてるから
仕様書やソースを見てもさっぱり分からんだろうな
作った時は政令指定都市の巨大システムだからエース級を投入しただろうけど… >>165
仕様書を書いて、客に承認させるんですよ >>167
どんなスーパーマンでもそんなことは不可能。 >>165
炎上した案件を鎮火させる場合の話だから、大抵は事情が変わる
客側も、ベンダーが持ってきた仕様不明点を精査するか、既払い費用とシステム開発を諦めるか、どっちかなんだから
絶対に絶対に客側が仕様を決めないなんてケースを話してもしょうがない >>169
既存のバッチを同等に動かすことが目的なんだから仕様を決めるとかの話じゃない。
既存のバッチの詳細情報を耳揃えて京都市が出さない限りは実現そのものが不可能でどこも引き受けない。 >>170
「同等に動かす」では仕様と呼べないから、仕様を確定させるんだよ
普通は客が本当に必要としてるのは「同等に動かす」ことじゃないから、システムの刷新が本当に不可欠ならそこなら妥協するのは確実
炎上するまでその踏ん切りがつかないだけ
同等のものは原理的に作れない、とかいう尤も理屈は、実際の仕事では役に立たないよ とはいえ、京都市はまだまだ危機感なく失敗を繰り返しそうですがね
誰も近付きたくないだろ >>171
京都市が一切の妥協をしなかったから炎上したんだけど。 >>174
委員会つくって「俺はなにも悪くない」といっているし そんなのは、ベンダー側に覚悟があれば、いくらでも交渉できる。
私の勤務先の場合だと
現状、仕様が不明確なので、仕様確定のための追加作業が発生します。
当初、予定しなかった作業になりますが、費用の追加請求は行いません。
現行のシステムを解析して、仕様を確定させますので、京都市側にもご協力頂く必要があります。
もし、受け入れられない場合、弊社では対応しかねますので、開発費について全額返却しますので、
契約の解除をさせて頂きたく思います。
てな感じ。 >>176
見たところ追加費用ゼロは厳しすぎね？
ベンダーの手を借りずに仕様の確定を京都市だけで速やかに行えた場合と仮定でもしないと、帳尻が合わないだろう ✕ベンダーの手を借りずに
○ベンダーの手を借りるとしても >>178
京都市の報告書を読む限り、京都市側が一方的有利な契約になってしまっているので、その前提です。
まともな法務部門がある会社なら、契約する前に法務部門の確認が入るはずなので、こんな契約書は、あり得ないけど >>176
契約解除時に違約金払わされそうだな。
倒産の覚悟が無いと、その手は取れないな。 海外だと機会損失の賠償を求められるというのを聞いたことあるけど、
国内案件で、何もまだ納入していない段階で違約金を払わされたというのは聞いたことない。 >>181
大抵契約解除時の違約金の上限を設定してるはず... >>183
設定してなくて、受注費の何倍もの支払いを命じられたベンダーが有ったな… んと、京都市規模だとこのてのゴタゴタやまほどこなしてるだろうからなあ。
まず負ける戦はしないだろうと。
あと、法令の世界もIT業を特別扱いはしないから、土建業と同じく単なる請負業だし相手に致命的過失があると指摘出来ない限りは、出来ますやれますと引き受けた方の負け。 コラコラｗ
こんな底辺IT土方のガス抜きスレで、
大人の社会の道理説いてもしゃーないだろ？ 大人の社会の道理w
単に京都市のシステム刷新が滞ってて、
すでにシステムズに税金からカネを一部払ってるのに完成の目処も立たないだけだろ。
あと、システムズももう切られた、と。
バカが雁首揃えてバカを晒して、おまけに京都市民の住民税が使い込まれただけ
どこに大人がいるんだよw >>188
京都市が無能なお役所仕事してシステム更新失敗して、どうせ税金だからそれでも構わないあたりが大人の道理なんだろ
市民に何億円ぶんの責任取らされる訳じゃなし
担当者は内部で少し責任取らされるだろうけどなー
京都市がすでに払った何億円かは、戻って来るはずもないしー 京都市「あのー....」
NEC「なにかぁ」
京都市「ひーなんでもないですぅ」
京都市「あのー（市民税上げてもいいかな）」
市民「なにかぁ」
京都市「ひーなんでもないですぅ」 >>190
お役人様が、たかがベンダーやたかが市民に、そんな低姿勢になるわけが無い >>191
まったくだ。必死になるのは責任取らされる場合の担当者だけに決まってる。
今回は、数億円ドブに捨てただけだから、市民に責任追求されることもないだろうし、
担当者がちょっぴり注意されるくらいか？ ■ このスレッドは過去ログ倉庫に格納されています
