【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/ COBOLからCOBOLに移行するんならソース全コピペすればよかったのに NEC自体がACOSのオープン化を始めているのでは？ >>1
注目はどのベンダーが応札するかだ。言い換えれば、失敗した注目プロジェクトを誰が引き取るのか、である。
「応札できるのはNECしかいないのでは」と業界関係者は指摘する。京都市と基幹系システムを通して30年来の付き合いがあり、万が一失敗しそうでも開発者を大量動員してやりきる“体力”があるからだ。
ただ、NECは今回の刷新プロジェクトでは、分析フェーズと新システムが稼働するクラウド基盤のハードのみを落札し、オンラインとバッチの移行案件には応札していない。その理由についてNECは「回答を控える」（広報）ため、真意は不明である。
だが同様に、オンラインやバッチの移行に富士通や日立製作所、NTTデータ、日本IBMといった競合も応札していない。うまみの少ない案件とみたからだろう。
京都市が2017年11月6日の京都市議会に提出した資料（PDF文書）
http://www2.city.kyoto.lg.jp/shikai/img/iinkai/soumushoubou/data/291106souki.pdf
市議会の録画（YouTube動画）
https://www.youtube.com/watch?v=0eUJXhJY5RY > だが同様に、オンラインやバッチの移行に富士通や日立製作所、NTTデータ、日本IBMといった競合も応札していない。
>うまみの少ない案件とみたからだろう。
国内の大手ベンダがそろって応札していないということは
RFPを読んだ段階でそこが地雷源であることが読取れたんだろうな… >>5
> 30年来の付き合いがあり
だからNECは逃げたんじゃ？w こういうことやって一番損するのは自治体側なのにね。
よっぽど価格を上げでもしない限り、どのベンダも入札しなくなる。豊洲市場とかと一緒。 大手だったら自分が悪いと多少赤でもやってくれるのにな
中小に何億も赤出させるのは死活問題だから引けないわな >>11
客からの要求仕様が定まらないんでしょ
最初から全部定まってるケースなんてまずないけど、今回は定まらなさすぎたのだろう >>14
コンバート元データの仕様が分からないんじゃないの？
古いシステムらしいから、ちゃんと資料が残ってないとか、細かい変更がたくさん入っていて訳が分からなくなってるとか >>15
その場合でも発注元は
「俺は悪くない」で開発相手に丸投げだからな >>2
ＣＯＢＯＬプログラムはそれでいいけど、バッチジョブを構成するスクリプトは
ＮＥＣ独自のものが使えないから、別物になる。
それに、スクラッチしたＣＯＢＯＬプログラムはそれでいいけど、ソートや
マージ、年号処理などの一般的な機能は、スクラッチ開発ではなく
ＮＥＣが提供するユーティリティプログラムをコールして使っているはず。
オープン系ＣＯＢＯＬに同じ機能のものが提供されていなければ、
それをイチからスクラッチしないといけない。 >>5-6
うまみとか地雷とかじゃなくて、
リライト（ロジックだけ使いまわし）やリエンジニアリング（全面刷新）ならともかく、
リホスト（プラットフォーム変更）の案件に、そもそもメーカーが参入することはない。
そういうのはＳＩｅｒの仕事だよ。
せいぜいメーカー系列子会社が入る程度。 >>18
実務の話じゃなくて公共の受注なら普通に日立製作所、NTTデータ、日本IBMとかが応札するよ
もちろんフロントに立つだけで子会社とかに丸投げして、実務は子会社から丸投げされたSIベンダがやることになる >>16
それがこの問題の争点かと
確か業者は京都市から必要な情報が提供されていないと主張してたと記憶している
このケースに限らず日本中で同じような問題に当たりそうだけどな、日本のソフトウェアの開発って要求仕様に関してはかなりアバウトだし、メンテナンスや仕様や変更点の管理はさらにいい加減だろ >>20
その時代ではそれが普通というのは
業界の共通認識としてあるから
京都が当時のレベルと比べても極端にひどいと立証出来ない限り
「それを知ってて入札したの自分だろ」になるだろうな。 >>20
管理がいい加減というより対応中に仕様変更が来て輻輳する
やれ、戻せ、やっぱりやれ、ただしここにはやるなってな
受け付ける人、ドキュメント書く人、
コード書く人、テストする人が時間差で別の仕様に対応するという混沌状態
PMが権限持っていて統率出来ればいいが、客が無駄に強くてさらに理解が無いと･･･ 要求仕様をアバウトなまま受注、システム構築を始めちゃう日本のこの業界の体質やろ
顧客が変なところに細かくシステムの作り込みを要求するし、ベンダーもなあなあでそんな要求に応対するからそんな体質になる
アバウトなのを許さないと受注自体が成立しないし、要求仕様なんてきちんと作りようがない
要求仕様を綺麗に作る能力があるならインドにでも外注できるわ
うまく行ってる間だけは、業界自体が持ちつ持たれつといえる >>22
> 客が無駄に強くてさらに理解が無いと･･･
それに加えて役所は定期的に人事異動で担当者変わるから
実務者はさすがに変わらないことが多いけど上が変わると
なんでこんな仕様なんだ？
俺の言う通りの仕様にさせろ
って経緯も知らん奴の思い付きの仕様がいきなり入ってきたりする >>23
>顧客が変なところに細かくシステムの作り込みを要求するし
これも建設的な内容ならまだ良いけどね
文句を言われたくない責任を負いたくないだの、消極的な理由で既存の無駄も残せ再現しろみたいなのも多いしな
捨てる決定をしても蒸し返されたりね
理由付けしたり関係者を納得させたり面倒なのは分かるけど 基本的にやり逃げ業界だからなあｗ
後始末なんて馬鹿のやる事位に皆思ってる。 こんなのどこも受けるところないだろ。
ドキュメントもまともにないリプレイスなんて失敗することがわかりきっている。 >>27
それを >1の会社が受けて予想通りしくじったから問題がややこしくなってる訳で 京都なんだから富士通のスパコン「京」で決まりだろ。 仕様なんてどこでも変わるだろ。
そこを上手く丸め込んでやっつけるのが営業の仕事。
つーかこの件は開発会社が能力ないんか？ どうせ後から後から決定事項を蒸し返して
その当人が「俺は言ってない。議事録が間違ってる」
とか言い出してるんだろ
京都人は証拠を突きつけても平然と、証拠が間違ってるって言い出すからな 提供・作成するきがないんだよ
(自分の仕事以外絶対にやらない)
多分全部necが持ってる
けど渡さないよな、全部自分達で作ったら資料だろうし 公共系以外でも京都と名のつく会社の案件は大概地獄、泥沼化する >>33
ベンダ側が議事録とってないことを認めてるのに何を言ってるんだよ w お上に勝てると思ってるのかな？
どこまでもお子様な会社だなｗ
まあ提訴しないと会社が死ぬから
選択肢無しで提訴したんだろうけどｗ >>37
なんつかな、記録を取る、打ち合わせ簿をつくり承認させる、ってのは仕事受けるときのイロハだろうに。 >>39
でかい会社とか何度か痛い目にあってる会社はその辺徹底してるけど中小で今まで馴染みの会社との仕事しかしてないとかだとビックリするほどいい加減だよ >>40
まあ、「わかりましたあ」で何でも済むなら、そもそも情報工学なんて要らんかったろうにと。
例の、木に吊るしたタイヤの漫画、みてウケてる連中見てると、そこが一番肝心なところなんだけどなと、なに笑い話で済ませてるんだと、そう言う気分になる。 ＩＴって難しいね
やってみないとわからないことが多すぎて魑魅魍魎 京都市側の担当者が威圧的に無茶を押し付けてくるだけの会議だったとかで、
議事録残したくなかったのかもしらんし
無茶振りしたのかしてないのか、どんな要求仕様書だったか確認したらいいんじゃないかなw
要求仕様書がまともにあるとも思えんけどね >>45
いや、それが理由になる、という発想自体がマトモな大人の考え方じゃないしw
吊し上げや糾弾なんかでツライ会議なんて世の中にありふれてるわな、
だからといって、トウフメンタルなんで忘れてなかったことにしだい、なんて通用せん。 議事録なんて自社側が不利にならないためにとるものだよ
自社側に有利な言質をとったなら議事録にして相手に送って、メール返信貰うなりして相手が受け取ったこと証拠残した上で
水掛け論を避けるためのもの
会議の結果内容が自社側に負担が増えるばかりのものなら、わざわざ手間かけて議事録作ってやる義理なんてないよ >>47
議事録がなくて不利になったなら馬鹿だけど
議事録がなくて有利になったなら利口なだけだよな
信頼関係クソ喰らえの相手ならね 裁判で現行システムの詳細な仕様書を提示できなければ京都の負け。 >>47
>>48
作ってやるねえw
作らないで、受注者の有利になることなんてあるのかねえ？ >>49
いや、関係ないよ
そう言う条件で引き受けた、という文書がない限り。 >>52
遊んでほしいなら、
もうちょっと
リアクション速くねw こういう案件の見積書とか見てみたい。
とんでもなく丼なんだろうか。 これ、まともな要求仕様書あるの？
たぶん、無いからNECが逃げたんだろうね プログラミングを1行も書けないような奴が
何もわからないくせに発注する馬鹿な文化どうにかならないかな
土木だったら役所側も専門の技術者雇ってるのに
ITだとSQLやHTMLすら怪しいような奴が発注やってる >>50
ほぼないだろ
水掛け論で揉めて受注側が主張することなんて、書面にない仕事を要求してた場合だろうし >>21
仕様変更がどの程度入ったかにもよるんじゃないの？
出ないと今後はきちんとした仕様書出せ。出さないなら入札しない（できない）になって入札不調が相次ぐだけじゃね
そっちの方が健全ではあるけどな >>49
入札なんだから落札後に「詳細な仕様書がないと出来ない」と言う方が無理筋 >>62
リプレイスなんだからあるのが当然。
なければ京都市側できっちり調べ上げて提出する義務がある。 糞品質のシステムの、「リホスト」ってことは
コードいじらないで移動するだけって目論見だったのだろう。
ふたを開けたら、とてもじゃないがそんな目論見で完工でいる代物ではなかったと。
そういうことはよくあると思うが、問題は工期途中で気がついたときに対策とれないのがなんでかという。
おそらく発注側がお花畑だったんだろ。受注側が無能だっただけなら、もっと早く発覚するわけで。 リホストとかアホなことやらんでACOSのままやったらNECが面倒見てくれるだろうに ちょっとＮＥＣでＡＣＯＳを調べたら、２はＥＸＰＲＥＳＳと４とに分けて最終的に６と統合する
とか昔聞いてたけど、まだ消えてないようだね。 >>63
そういう、オレの都合のいわずもがな、はまず通用しない。 >>64
このての
受注側に優しい世界思想は
先ず、通用しない。
つか、問題点を教えてくれないのがワルイ、的発想がなんで出てくるのかなと。 >>68
妄想乙
要求仕様を言わなくてもやってくれるだろう、なんとかしてくれるだろう
みたいな発注側の脳みそお花畑を擁護したいのかな >>68
要求仕様書に書いていない作業は一切やる必要はない。
現行システムの調査まで含めて全てやれと要求仕様書に書かれていない限り京都市が確実に負ける。 責任という言葉を知らなさそうなID:mngHbMuf
社会人ではないのだろうがね >>70
契約を尊重すると、その通りだな。
ベンダー側の責任は、要求仕様通りにいかないと判明した時点で告知すること。
その際に、追加工数分の費用を請求すること。
その二点さえ守れてれば、ベンダー側に責任はない >>53
バカ決定
そこはレスポンスだろ ...
リアクションって、お前は芸人かよ w >>65
ハードとか基本ソフトでぼったくれるからね
好意的に取ればそう言うお金を頂けるからちゃんと面倒みれてたってことでもある >>70
この手の仕事したことないでしょ？
顧客が出す要求仕様書は顧客がやって欲しいものが書いてある
どうやるかはベンダー側の責任で決めるんだよ
それが請負契約と言うもの
現行システムの調査が嫌なら別にやらなくてもいいけど要求仕様を満足したシステムを納入する責任はベンダーにあるよね？
って言われて終わり
なのでどう言う資料が必要なのかとかテスト環境があれば現行システムの動作を確認させてもらえるかとかこと細かく条件書に書くのが基本 >>75
その要求仕様がはっきり出てくる案件なら、まだずっと良い方でしょうよ
問題はそんな要求仕様すら固まらない案件
今回のだって、やれ元号の対応がどうのとか、最初の要求仕様に明らかに含まれてなさそうな機能も対応を要求してるんでしょう？京都市側は >>50
受注側の得にしかならんでしょ
つーか、受注側の議事録なんて発注側の無茶振りを避けながら決定事項を詰めるためのものだし、
発注側の議事録は受注側に作らせる機能の範囲の言質を取るためのもの
双方に議事録がないなら、京都市側がシステムズから言質を取れなかったか議事録の作成を忘れるバカだったかでしょ >>75
お前アホだろ。
要求仕様書に書いていない作業は発注元が責任持ってやるんだよ。 今回の件は、要求仕様に単体試験段階での網羅テストが謳われていて
それを受託側が拒否したんじゃなかったっけ？ >>79
拒否したということは要求仕様への記載がないと思われる。 >>78
要求仕様書に基本的に作業は書かない。
車のカタログに、エンジンの組み立て方とか書いてないだろ？
書かれるのは要求、欲しい結果のイメージ。
そこから、何をしなきゃいけないのか考えて、業者が見積もりする。 >>81
入札の場合、絶対に役割分担は書くぞ。
こんなこと書く必要ないだろというところまできっちり書く。
なければ見積もり出せないからな。 >>81
必要な機能の列挙は必需だよ。それを基に見積もりするんだから。
揉めるのは普通は、その列挙した機能に当然付属する機能と言えるかどうかの部分。
無茶苦茶に揉めるケースだと、その列挙すら満足にできてないとか、変更をタダでやれとか言うわけだが
それは外道のやること >>76
> 今回のだって、やれ元号の対応がどうのとか
それは今回の件じゃなくて、稼働時期をずらすからそう言う対応も必要だから開発費が増加するって話
>>78
アホか、必要な作業はベンダーが見積もるんだよ
そんなのは常識
>>82
そんなことがきちんとできてるなら日経コンピュータの動かないコンピュータのネタが切れるわ w
そもそも調査は京都市がやると書いてあってもどこまでやるのかまでは書けない
ソースコードとテーブル定義と操作マニュアルでよろしくとかもあるし（他社の実話です） >>84
見積もり作るのはあくまでも入札の要件に記載のある作業についてな。
書いていないことは一切やらないのが常識。 他の市で稼動している最新システムを購入して、
京都市の業務をそれに合わせればいいんじゃない >>85
日本の常識じゃ、行間と忖度が大切。
金くれないならやらない、と明記したSQLインジェクション対応をやらなかったベンダが敗訴するのが日本。 >>60
建築と違って出来上がった後も大規模に改造して使われ続けるから
システム設計レベルだけじゃなく、実装レベルも正しく行われているかの「目利き」の効く人が発注側にいないと
契約を履行しただけの寿命の短い製品渡されるんよ
だから、あながち安価先の人の言ってることは間違いではない
(HTMLやSQLは知らなくていいと思うけど…) >>89
と、建築のケの字も知らないド素人が言ってる >>89
ついでに、
殆んどの建築物は設計図どおりには出来ていないってこともおぼえといてね。 ど素人が勉強もしないで何千万だか何億だかの買い物するのが異常というか、自分のためにもならないってのは当たり前だと思うがねえ >>92
つまり、ぼくらIT土方は一挙手一投足、お母さんのように優しく教え諭してくれるひとがいないとまともに働けませんと。 >>93
逆だろ。あんたの主張は顧客の欲しいものをベンダーが手とり足とりやれってことなんだから >>92
あとこれ、悪徳不動産屋が良く言う台詞のまんまだね >>94
それが世間一般で言うところの技術者＝エンジニア、だよ
お前の言う通りやるから結果はお前の責任な、というのは単なる作業員＝土方 >>96
違うだろ
それはコンサルタント料とか取ってる契約をした場合のコンサルタントの仕事
システムの受注が決定したなら要求仕様書に沿ったシステム開発が、技術者の仕事に決まってる >>96
う〜ん、この職務とか責任とか理解してなさそうな感じ
社会人なら周辺の人らがかわいそう >>88
そんな常識は通用しない。
実際に入札の要求書見てこい。
事細かに書いてあるから。 >>93
入札の要件というのはそういうもの。
記載がなければコストカットのためにとことんまで手抜きされる。 >>97
違うよ、単に要求に沿った作業を行う連中は単なる作業員、重機の操作がいくら上手くても技術者じゃないのと一緒 >>98
たしかに、あんたのように、仕事をしない理屈を並べ立てる自称「センモンカ」はなるべく避けるようにしてるからな。 客が これは簡単 と言いだしても営業は鵜呑みにてはいけない。
大概はトラップが仕掛けられてる。 >>103
PMだけしてきましたってベンダーのやつは
ディベート術だけのゴミがいるからねｗ >>101
入札で仕事するのは単なる作業員以外の何者でもない。
要求の段階ですでにスペックに至るまでガチガチに仕様は固まっているからな。 >>101,103
アホウ。専門技術によって仕事するのが技術者だ
やっぱりあんた、職責とか理解してないだろ。論外だわ >>101,103
職域外に勝手に手を出したら、職権乱用すらあり得る。
職域、職責がはっきりしていてこそ職務権限があるんだぞ？
責任の何たるかを勉強しろ。職業倫理を最低限身につけろ、周りの人間が可哀想だから 技術者は作業員より主体的で偉い存在とでも思ってるのかねえ、 ID:9cQkzOJnは
さらには、職務権限の大きいという意味の「偉い」を人間的価値の高い「偉い」と混同した挙句
誰が誰より偉いかばかり気にしてそう 裁判沙汰になったらどのみち両方が損なんだから、普通は落としどころ探るもんたけど、京都市は未払いで通して新たな業者選ぶんだな
いくらで引き取られることやら >>109
偉い、の混同は頭のおかしい儒教社会でわりと見られる
偉い＝徳が高いこと
職権が強いこと、重要な役割を果たしてること、道徳的振る舞いをすること、宗教的に優れてること、尊敬されてること、優秀であること
その他諸々ごっちゃにするクセがある
徳が高い人間が、あらゆる意味で価値の高い人間
徳が高いと人を口先で動かして生きるのがふさわしいと考える。人に言われて働く人を低く見る。肉体労働とかも低く見る。
古い人間とか半島人とかにけっこういる
これ、もう5億円払ってるんだな、京都市
それでも業者選定からやり直しか >>110
誰も入札してこないんじゃないか？w
俺なら担当者に選ばれたら転職先を探すねw >>63
入札時の説明会(普通やるはず)で「有りますか？」と質問してyesと言わせない限り
「出せる資料はこれだけと入札前に言ってますよね。後はそちらで調べて下さい」と言われたらどうしようもない そういう特殊要求あるなら、それなりの値段をベンダーから提示されるだろうね。 >>114
なければ発注側で調べて出してください
それまで作業は進められません
で終わり
明確な記載がない時点で発注側の負け マイグレーションだリホストだ言っといてこうなったんだから、もう決定的に従来の仕様が分からないんだろうな
整合性のないデータと意図不明な処理が満載なのは確定。さらに、意味が分かるように基本設計書に書き下せとか言われたのかなあ
どこが引き取るか知らないけど、いったい何億円になるんだろうね >>116
そういう態度で開き直った結果、納期守れず契約解除食らったんだろうな。
十中八九反訴されるし、別途存外賠償も起こされるだろう。 >>118
発注側が負けるのは確実だけどな。
契約舐めているとしか思えない。 どっちが裁判で勝つかは、契約内容次第だと思うけど、
次の発注からは、京都市側は、揉めた項目を要求仕様に記載するだろうし、
そうすると、引き受けてくれるところが出てくるか怪しい。
なにせ、既存ベンダーのNECが入札しなかったくらいだから、何も資料残って無いんだろう。 >>119
> 意見が食い違っている京都市とシステムズ。気になるのは、合意した内容を証明するものがあるかどうかだ。これに対してシステムズの栗尾執行役員は、「両社が押印するなどした正式な議事録はない」と話す。
議事録無しに作業進めるとか仕事舐めてるの受注者側だろ。しかも動いてないし >>121
別に合意したことがないなら合意文書がなくても当たり前だろ
だいいち議事録は双方が作るものだぞ >>119
実態知らないなら黙ってろよ
入札でガチガチに仕様が決まってるとかあり得んから
そもそもその仕様書を受注側が書いてるとか普通にあるから 京都市民にとってみれば新システムに移行できないのは京都市の落ち度
税金使っておいて余所のせいにしてるんじゃねーよ そもそもシステムズ以外の会社は自分たちが受けた業務を作業完了してるのにシステムズだけが移行失敗してるんだろ。
他の企業も失敗してるならともかく「京都市が悪いからわが社だけ出来なかった」って説得力無さすぎ そりゃ損失出しても力技で終わらせる企業もあるだろうさ
訴訟になったらどのみち損するんだから普通なら理不尽だろうが赤字だろうが終わらせるよ
そうしない、できない理由があるからこうなったんだろ
結局両方が馬鹿を見るだけ 入札仕様の読み込み不足とリスクの見極めに失敗しただけ。 失敗したのは京都市もだけどな。勝者も成功者もいないよ
馬鹿な発注、見抜けず受注 >>123
国や自治体のサイトに入札の資料あるから見てきなさい。 >>131をざっくり読んだけど京都市が負けそうな気配はないと思う
あると言う奴は具体的な箇所を示してみな 判断３ 受託事業者には契約上の義務（プロジェクト管理）に対する認識に甘さがあった。（第４部／第４／４）
受託事業者は，「納期に間に合わせることがプロジェクトマネージャの義務と書かれておらず，受託事業者が結果責任を負うものではない」と述べているが，仕様書からも納期遵守が受託事業者のプロジェクト管理上の責務とされていることに疑義はない。
↑これとか特に筋が悪い。書いてないからプロマネに納期を守る義務が無いとか常識が通用しない会社と言っている様な物 >>134
別にシステムズの肩持つ気はないけど、
131は京都市が出してるものだからそこは踏まえとくようにね
遅延に関する調査報告書も、京都市が結成させた検討委員会が京都市に提出したもの
元のシステムについての資料がどの程度提供されたのかも全く分からんこともあるし判断つかん
どっちも問題あったよね、とか言いながらシステムズに任せられない結論です、としか言ってない >>136
報告書はいいとして
>>63みたいに仕様書になんでも書いてるって言うアホがいるって話 これ、ひでーな
プログラム変換ツールで既存のソースを変換して使うのか
その部分は単体試験もしないで結合試験レベルの新旧でのデータ比較して、同じ動きを確認することでテストに替える、と
京都市と受託企業が同意してこんな手法でやるってことは、マジで現行の仕様の理解を完璧に放棄してるやん
仕様が分からないのに99.99%以上現行通りの動作を求めてるから、ソースを変換するしかないのか あ、でも納品物にシステムのマニュアルを求めてる。
仕様がちゃんとは分からないのにマニュアルは作るんだ >>139
かなり、無理な内容だと思うけど、書面で取り交わしているようだから、仕方ないよね
システムズには、法務部門は無かったのかな？ >>140
いや、手法は失敗の調査の報告書に載ってるだけだから、最初からこのつもりだったかは分からない
入札の際に手に入る資料が131(失敗の調査報告書を除く)だけなら、こんなのどこで予想するんだ。。
99.99%で気付かないといけないのかな。実際ちょっぴり質問してるし 状況的にホストの仕事なら火消しがはいるジョブに見える。
ボリュームが見えないからよくわからんが、本番まで一年半位じゃ怖くてできんわ >>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
まったくだ。必死になるのは責任取らされる場合の担当者だけに決まってる。
今回は、数億円ドブに捨てただけだから、市民に責任追求されることもないだろうし、
担当者がちょっぴり注意されるくらいか？ ■ このスレッドは過去ログ倉庫に格納されています
