2025-03-24 18:17

第31回「IBMとNHKの開発トラブルは何が問題だったのか?」

spotify apple_podcasts

第31回目のテーマは「IBMとNHKの開発トラブルは何が問題だったのか?」です。

今回は、NHKがIBMに発注したシステム開発プロジェクトで発生したトラブルについて取り上げます。ぜひ、最後までお聴きください!

▼ホスト:島田徹

▼MC :鴨志田怜

▼ゲスト:辰巳純基

------------------------------------------------------

▼お便りメール

メッセージをお待ちしております!

Googleフォーム: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://forms.gle/DCema6crfoux1ZAR9⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

------------------------------------------------------

▼株式会社プラムザ のホームページ

 システム開発などでお困りの事があればお問合せ下さい。

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.plumsa.co.jp/⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

------------------------------------------------------

▼𝕏アカウント

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠♯ふてはな⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ 』で番組の感想、ご意見、質問など、ポストしてくれた投稿には返信することもあるのでぜひフォローお願いします!

 ・番組𝕏: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠@futehana⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ 

------------------------------------------------------

サマリー

IBMとNHKの開発トラブルは、システム開発における要件定義と見積もりの不一致が主要な問題となっています。NHKは既存のシステムをリプレイスする際、新しいベンダーとしてIBMを選定しましたが、開発の過程で多くの課題が浮かび上がり、訴訟に至るまでの経緯が語られています。この開発トラブルでは、契約の形態や要件定義に関する問題が明らかになりました。特に、開発会社と顧客間の認識の違いが、見積もりや予算に影響を与え、トラブルの原因となったことが議論されています。

開発の背景と契約の経緯
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが、赤坂より、開発現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、賑やかし枠の辰巳です。よろしくお願いします。
今回のタイトルは、IBMとNHKの開発トラブルは何が問題だったのかというタイトルになります。
ざっくり、鴨志田から概要をお伝えさせていただければと思います。日経さんからの引用になりますが、
日本IBMは、2025年の2月7日、NHKから営業機関システムの開発プロジェクトに関して提訴されたことを受けて、ウェブサイトで声明を発表したということです。
ざっくり言いますと、NHK側からIBMに約55億円の支払いを求める訴えを起こしているというところです。
これ、今どういう状況になっているか、辰巳さんお伺いしてもよろしいですか。NHKからIBMに訴えを起こしたということになると思うんですが。
少し僕もニュースサイトだったり、Twitterでこの事件を軽く追っかけて気になっていたので、簡単にちょっと解説をもう少し噛み砕いてしていきますと、
アクセンチュアと日通のエピソードを前回お話ししましたけど、それとはまたちょっと違う経路の内容かなと思っています。
あの時は納品したつもりでいたけれども、できていないでしょうという話だったと思います。
システムの開発を始めようとしている時の話です。
なるほど、今回のIBMとNHKが開発前の話になるんです。
始めぐらいの話ですかね。
研究としてはNHKの営業機関システムを富士通がやっていたそうなんですね。担当開発というか保守担当。
どこかのタイミングでリプレイスしたいなと思っていて、そのタイミングでベンダーを変えるという選択をしたんですねNHKが。
なるほど、なるほど。富士通さんからIBMさんに。
他にも候補が多分いたと思うんですけど、それこそアクセンチュアとかの候補として出ていったかもしれないですけど、NTTデータとか大手のベンダーですよね。
その中で今回日本IBMが選ばれました。
その中で当然リプレイスするにあたってこういうリプレイスをしたいという要望の定義書がNHK側から出されていました。
それに応じて入札して最終的に提案が通った会社がそれを案件獲得受注して始めていくって話だと思うんです。
その上でIBMが受注しましたと。その上で業務を解析していって、要件の要望の定義書の内容を見て見比べていると結構乖離があるぞと。
あれこれ、要件最初に聞いていたのと違くねっていう風になってました。
その上でこれをそのまま進めていくとヤバいねっていうのが日本IBMから分かったんですよね。
その上でNHKさんにこういう提案、こういう方法で進めませんかっていう話をしていたら、いやそんなこと許されません。
なるほど。
ちょっとごめんいいですか。
まずなんか多分ね違うところがある気がするんでね。
本当にありがとうございます。
多分2022年に契約を締結してるんで、だからもう始まってると思うんだよね。
了解です。
途中で開発の方式を変えるとかって言い出して、IBMがね。
NHKの資料を見ると途中からそういうこと言われて、抜本的になんか開発方式変えるって言われて、で伸びたと。
なるほどですね。改めて整理すると。
だからアクセンチュアと日通の時は納品時、開発が終わって納品するタイミングでの話だったんですけれども、
今回のIBMとNHKに関してはシステムの開発がある程度進んでいる段階で起きた。
2022年から着手を開始して2024年ぐらいに揉め始め、2025年に訴訟がNHK側から起こされたというような状況ですね。
要件定義の重要性
そうですね。
なるほどですね。これは一体どこまで進んでいたのかというところが大変気になるところではあるんですけど、
すみません、一般的にシステムを開発する上でおそらくこの流れからしたらこういう開発していったんじゃないかという開発の流れと言いますか。
ちょっと一旦整理していただきたいなと思うんですが、お願いしてもよろしいですか。
そうですね。もうすでにNHKの方は使っている機関業務システムがあったと思うんですよね。
でもそういうパターンで、普通最近の開発ってゼロから開発するって言ったら多分なくて、
すでにあるものをリプレイスするというか作り変えるということが普通ですよね。
それを新しいベンダーに乗り換えるのであれば、新しいベンダーのシステムエンジニアを見てもらって、
よく解析してもらって、やりたいこともしっかり理解して、
それで新しいベンダーさんの方から要件定義という、こういうことをやればいいんですねという要件定義書とともに見積書を出すんですよね。
これをやるのであればこういう金額ですよという見積書を出すので、
じゃあお願いしますってNHKの方は言ったんだと思うんですよ。
だからは流れとしてはそういうことだと思うんですよね。
普通NHKの方が要求を出して、分かりましたってどんぶりで54億とかって、もっとだろうか、3倍くらいするのかな。
分かんないけど、何百億ですって言うことはないので、
必ず文書で、じゃあ分かりました、こういう作業をしますっていうことを出して、
それを基にして見積書を出して、それで契約に至っていると思うんですよね。
一般的にはそうですね。
なるほど、ありがとうございます。
この件に関しては一般的にこれはいわゆるリプレイスの案件、
富士通さんからのリプレイスの案件だと思うんですが、最初にどの段階になるんですかね。
流れとしては要件定義をして、それに対して見積りを出して、
ちゃんとした契約を進みましょうっていう流れになるのかなと思うんですが、
NHKが2022年の12月にIBMに発注をしているというふうに記事に書いてあるんですが、
これはどの段階になるんですか。
なってそうですか、多分明確には分からないと思うんですけど、
要件定義で見積り出した段階なのか、
そもそも要件定義の段階からなのか、これはどっちになってそうですかね。
一般的にはこれは要件定義が終わって、正式発注だと思うんですよね。
なるほど、なるほど。
だいたいある程度の要件定義を済ませて、
だいたいこのくらいの金額ですよっていったものは出して、
それでOKを出しているものが変わったっていうのが問題なところになってるんですかね。
そうですね、よくシステム開発のリプレイスがあるあるなんですけど、
既存のシステムが見切れないので、例えばすごいデカかったりすると、
そうすると営業が適当などんぶり勘定で見積って、
あとはやりながら契約をまずもらったら進めていきながら解析していきますみたいなことをやるわけなんですよね。
そういうスタイルでやっているのかもしれないですね。
きっちりとした要件定義を出さずにですね、
要件定義を出しているかもしれないけど非常に曖昧なもので、
今処理されている機関業務システムと同等の機能は必ずやるみたいなね、実現するみたいな。
たぶんなんですけど、要件定義をするタイミングでリプレイスであれば、
既存のシステムの解析をある程度やっておく必要があると思うんですけど、
それをたぶん2022年の12月以降に始めちゃったから、
こうなっているのかなとちょっと思ったりもしていますね。
それである程度の解析終わり、かつNHK側からこれもやりたい、あれもやりたいというのが出てき始めて、
ちょっと進めていくうちに2024年3月に入って、
いやこれはもう無理だよっていう話になって、新しい提案がIBMから出てきたのかなと。
開発トラブルの実態
なるほど、ありがとうございます。
これは主にそこの要件定義と見積もりがすごく争点になりそうな気はしていまして、
開発会社からしてみたら、おそらくちゃんとした要件定義を作るにあたり、
ソースコードをしっかり解析する必要がある。
ただそれに関してはかなりコストもかかってしまうので、
現実的にはそこそこのところで落とし込んで、
ある程度のところで見積もりを出さないと仕事にならないというところだと思うんですよね。
そこら辺の双方の認識の違いっていうんですかね、
ソースコードを解析して見積もり、要件定義書いたんじゃないのかっていうところと、
ある程度で大体の見積もりを出していますっていうところも何でしょうかね。
そこらのすり合わせとかどうだったんだろうなというのを聞いていて思いましたね。
他のメディアにも書かれているのが、
現行システムの解析を進める中で提案時に出色した要求仕様書では把握できない、
長年の利用の中で複雑に作り込まれた構造となっている。
というのがやっぱり判明したんです。
解析のタイミングでやっぱりこういうのが出てきたのかなというところですかね。
なるほど。ある程度の要件定義を書いて見積もりを書いて、
あとに実際やってみよう、さらに解析してみようという中で、
かなり入り組んだものが見つかったと。
そうですね。あるあるですね。
やっぱりあるあるなんですね。
あるあるです。
どんなことがありました?
これは前にも言わなきゃいけない。
ポッドキャストの初めの方でも話したんですけど、
まともな見積もりを書いたら通らないんじゃないみたいな回があったと思いますけど、
しっかり解析して細かくやって、要件定義作ってやってもめっちゃ高くなってしまったり、
要件定義を書くためのコストもバカにならないんで、
なのでどこの業者も割と適当などんぶり勘定の見積もり書を出すんですよね。
それで実際に契約を取って、その後何とかしようと。
わからないことが発覚したらお客さんと交渉して、
追加のお客さんをもらいたいなとか。
そういうようなことをやったりする業者がいるので、
うちはそれをやらないんで、本当に辛いんですけど。
バカ正直にやってるんでね。
うちの場合、同じようなケースの場合は、
見積もりと要件定義の問題
これ金額出しますけど仮なんで、仮契約させてもらって、
その後3ヶ月とか半年かけてみっちり要件定義やって、
その段階で正式見積もりまた変えますよって言ったりするんで、
嫌われるんですよね。
多分そうしないと無理ですからね。
そうですよね。
なので現場の流れとか現実的なところを考えると、
最初にざっくりで終わらせてしまうか、
要件定義をする段階でしっかり予算をもらって解析していくか
というところしかこの流れを考えるとないんじゃないかな
というふうに思うんですが、その認識はあってますかね。
この流れで言うと、一番いいのは要件定義は要件定義で
ちゃんと費用をもらってしっかり解析して見積もりを出すと。
ただお客さんとしてはアクセンチュアとかNTTデータとか
みんなにやってもらうのかっていう、全部見積もり出してもらうために
要件定義代みたいな感じで払うのかっていうと
それもなかなか納得しがたいところがありますよね。
他の記事にも書かれてたのが、
富士通が現行担当しててリプレイスするにあたり
コンペ形式でエリアで入札金額を入れるみたいな感じだったと思うんですけど
それかちょっとここの辺もよくわかってないですけれども
富士通が既存のベンダーとしてやる前提だったんだけれども
こういうふうな状況でリプレイスしてもなかなかしんどいねってところで
富士通が見積もりを高く積み上げて
これじゃもう無理だから他の業者に頼もうって形で
依頼して低く出してきた IBMがやることになったっていう説も出ているんで
それぐらい見積もりって本当適当というか
なるほどですね
基本的に既存ベンダーは一番システムとわかってるんで
どんだけ複雑かもよくわかってるんですよね
後からでも出すほうがそれはわからないんで
もうエイヤで出しやすいんですよね
低く出しやすいんですよね
実際要件定義をするにあたって
予算をいただくってことって一般的だったりするんですか
聞いてると難易度高そうだなと思ってるんですけど
なかなか通らないですね
たまには通ります
なるほど
これは先ほどこの流れだとなかなか厳しいんじゃないかっていう風に
話があったと思うんですが
これをうまく解消する流れとあれば聞きたいんですが
っていうのはプラムザの中である程度
こうしたらいいんじゃないかっていうものはできてるっていうところの話を
ちょっとお伺いしてもよろしいですか
これは島田さんのほうがいいですかね
私ですかいいですよ
お願いします
これはもうはっきりしてるんですよね
もう毎回うちもですね
この間もこういう見積もりを書いて
さっき言った通りですね
一生懸命やろうと思って仮見積もりを書いてですね
その後じっくり解析して正式見積もりを出して
そこからまだご納得いけるようだったら発注してくださいみたいな流れを引いてみたんですけど
やっぱりうまくいかなくてお客さんの時間がいらなかったわけですよね
これはやっぱり大規模なシステムになると無理なんですよ
一括請負のスタイルは
それはもう始め私なんか業界長いので
もうずっと昔に諦めてこれ無理だなと思って
始めたのがこの国内ラボ型開発っていうね
国内ラボ型開発っていう名前はあんまりメジャーじゃないですけど
いわゆるアジャイルとかですね
どちらの準委任契約でやっていかないと
これは無理だと思いますよ
必ず取られます
なるほどありがとうございます
国内ラボ型開発の話に関しては各回ちょこちょこ出ていると思うので
そちらを参照していただきたいのですが
そもそもこれは開発の形態っていうんですかね
開発の流れに問題があるっていうところですよね
開発会社側から見るとそういった観点っていうところでしょうか
そうですね契約の形態がですね
お互いにはっきり分かってないものをですね
作業を定義して金額を見積もるってそこがまず無理ですよね
無理がありますよ
お客さんも何を作ったらいいのかって分かってないわけなんですよね
契約形態の重要性
全体を把握してないわけですし
開発会社の方ももちろん分かってないので
もうとりあえず戦場に出てみようみたいなね
そうなんでうまくいくわけないですよね
なるほど
なかなかあれですよね
開発の形態から相談できるシステムの開発会社ってないんじゃないですか
最近でも増えてきましたよねこの準委任契約でやるっていう内容ですね
もしシステム開発にお悩みの場合であれば
開発の形態から相談いただくっていうのが良いかもしれないですよね
そうです一括契約でもですねできるパターンもありますので
それは基本的にはシンプルなシステムであったり
やることが決まっているという時は普通に見積もれますのでね
ただこれぐらいの大きいシステムになってきて
お客さんの方も何やっているか分からないと
ベンダーも分からないというものは
一括契約は無理なのでその辺の切り分けもですね
うちの方でできますからね
ありがとうございます
IBMとNHKの開発トラブルの何が問題だったのかというところに関しては
開発の形態だったんじゃないかというところがあったというところですかね
そうですね
開発の形態から弊社では相談させていただきますので
ぜひ気軽にお問い合わせいただければと思います
こんなところでよろしいでしょうか
はい ありがとうございます
本日はいかがでしたでしょうか
楽しんでいただけましたらフォローや評価をお願いします
またXでも最新情報を随時発信していますのでよろしくお願いします
システム開発に関するご相談がございましたら
公式ホームページからお気軽にお問い合わせください
それではまた次回お会いしましょう
ありがとうございました
18:17

コメント

スクロール