「NHKがシステム開発中止でIBMを提訴、約55億円を請求」というタイトルのニュースが私のもとに届いた。

２月４日時点ではまだ提訴の段階であり、具体的な内容は不明だ。

だが、思う部分もあり、今回急遽コラムとして出そうと思う。

前提として、どちらが悪いという話をしたいわけではないし、詳細が分からないので断定はできない。

あくまでも今回起きた事例は一般的に問題になっている事例でもあるので、一般例として取り扱うものである。

NHKの要求は妥当か？

という前提を共通認識でお持ちいただいたと思って、これから話を進めていきたい。

 

大きな金額である。

約５４億７０００万円の損害賠償。

IBMの時価総額は２３４兆円３４２０億円なので、IBMからしたら「はした金」かもしれない。

だが、大きなお金であることには変わりない。

 

では、NHKの要求は妥当なのだろうか？

この答えに私は答えることができない。

というのも、まだ裁判が起きておらず詳細が不明であるからだ。

だが、これまでのエンジニア経験で似たようなことを経験したことがあるし、他社事例も知っている。

これらの体験と知識から何が起きたのかを推測しながら、コラムを続けようと思う。

あくまでも「推測」であることを念押しする。

裁判が起きた時にNHK側がしっかり対応していた場合は、下記に書き連ねる内容は違ってくることを承知していて欲しい。

事前準備は万全だったか？

全ては事前準備で始まり事前準備で終わる。

なぜこういうのか。

それはシステム開発の成功率を考えると分かる。

「ソフトウェア開発の予測と記録と資産〜プロジェクト失敗率 69%の壁〜」という記事を見ていただきた。

約７割は失敗するのがシステム開発である。

大半が失敗するのだから、事前準備が如何に大事であるかが分かる。

この事前準備をしっかり完璧にやって失敗したら、IBMの責任だ。

しかし、事前準備がまるでなっていないなら、それはNHK側に大きな責任があると言える。

もちろん、IBMが開発着手前にそこを指摘して、しっかり事前準備を指示する必要はあったとは思うが、多くの発注側はなぜか立場が上だと錯覚して事前準備を適当に済ませようとする傾向がある。

そのため、多くのプロジェクトが失敗するのだろうと思うのは、内緒の話だ。

 

たとえば

• 何を目的としてスタートしたのか
• ゴールは何か
• 現行の業務内容は何か
• 現行の業務フローは何か
• どのような業務フローになればいいか
• どのようなマネジメントができるようになればいいか
• スケジュールはどの程度か
• 発注側と開発側でのコミュニケーション頻度や方法は何か
• 要件定義はいつから始まりいつ終わる予定であるのか
• クライアントの参加はあるのか
• 技術選定はどのように実施するのか

といったことを準備しているのかが大事である。

もちろん、これですべてではない。

だが、事前準備を整えているのかどうかがプロジェクトの可否を決めていることを理解すべきである。

知っている体で話されても困る

また、クライアントは自分たちにとって常識、日常であることをわざわざしっかりと説明しようとしない。

「言わなくても分かっているでしょ？」という阿吽の呼吸を求めてくる。

だが、思い出して欲しい。

クライアントの業務を知っていたら怖くないですか？

情報漏洩しているってことですよ？

 

新人を採用した時以上にしっかりと引継ぎをしないといけない。

言葉の統一も大事だ。

Aさんは「〇〇」

Bさんは「□□」

Cさんは「△△」

でも、みんな一緒のことを言っている。

なんてことは多くある。

統一してください。

マジで統一してください。

分からないから質問したら、「なんだ、こいつ」みたいな顔するの止めてください。

本当に多い。

窓口は１つにして欲しい

発注側とコミュニケーションをとる際、何故か上長とその上長が出てくることがある。

必要か？ってすごく思う。

出てきては決まったことを軽い気持ちで覆してくる。

昨日まではOKでも今日になるとNGになることが多い。

それで開発現場は仕様変更を求められる。

だったら、最初から参加して欲しいし、一番上の人とだけコミュニケーションするので、その他は不要だと思う。

しゃしゃり出てくるんだったら、デモ版とかテスト版ができた時に披露する際に出てきて欲しい。

コミュニケーションの窓口は１人や業務に関係する人など少人数でよい。

多ければ多いほど意見がまとまらない。

まとまらないということは、事前準備がしっかりできていないことを示している。

少人数に任せられないのなら、事前準備からやり直すべきである。

仕様変更をしても締め切りは変わらない、というのは異常

システム開発と似ている業界でいうと、建築である。

たとえば家を建てることを考えてみよう。

土地がある。

そこに基礎を作る。

壁紙や屋根、壁、窓などの素材を何にするか。

レイアウトや水回りをどうするのか。

駐車場をどのように設置するのか。

庭はあるのか。

などなど決める必要がある。

タイル１つとっても、どの柄か非常に多い。

その中から１つ決めるのも大変だろう。

 

では、想像してみよう。

家を建て始めた。

１階に水回りを設置した後に「やっぱ２階で」と言ったら、どうなるだろうか？

キッチンにお風呂にトイレなどは設置済みなのに、それらを全部２階に持っていけと言う。

 

もうお分かりだろう。

作り直しが必要になるのだ。

工数も費用も余計に掛かるのは目に見えている。

 

少しイメージしにくいだろうか。

 

じゃあ、もっと分かりやすい例で行こう。

奥さんがご飯を作ってくれた。

その奥さんに「気分じゃないから、別のを作ってよ」って言ったら、どうなるだろうか？

フライパンか包丁かが飛んでくるだろう。

もし作ってくれたとしても、その分時間がかかるのは当たり前だ。

 

なぜシステム開発はこの当たり前が適用されないのか？

「Aだと思ったけど、やっぱBで」といえば、簡単にAがBになると思っているのだろうか？

盛り付けを変えるレベルではないことの方が多い。

その依頼をするということは、工数や費用の再見積もりが発生することを理解しているのか？

あまりにも簡単に考え過ぎである。

１つや２つならまだいい。

もしそれが１０も２０もあれば、それは発注側の事前準備がしっかりできていないことに原因があるのではないだろうか。

発注側に問題がないとは言い切れないのが現実

プロジェクトが失敗したと述べているのが実に７割いる。

開発会社に責任を求めたい発注側も多いだろう。

しかし、上に挙げた通り、発注側に責任がないとは言い切れないのが現実である。

• 仕様変更が重なっていなかったか
• コミュニケーションは密に取っていたか
• 窓口は少人数であったか
• 仕様変更が発生した場合、再見積もりを適宜とっていたか

などが重要な要素になるだろう。

これらがちゃんとクリアであれば、発注側に落ち度はないと言える。

日本IBMの対応は適切だったか？

では、今度は日本IBM側について見ていきたい。

記事によると、２０２２年１２月から着手して２０２４年３月に大幅な開発方式の見直しが必要だとNHKに申告したとある。

この申告が突然行われたかどうかは記事内で確認することができない。

事実として、見直しが必要だと述べたところNHKが提訴したという結果だけを確認することができる。

裁判となった時に詳細が明るみになると思うが、もし仮に突然行われたことであるならIBM側も問題であったと思う。

どのようにして対策をすべきだっただろうか？

 

その答えは５つある。

１つ目はコミュニケーション。

２つ目もコミュニケーション。

３つ目もコミュニケーション。

４つ目もやはりコミュニケーション。

５つ目も何て言ったってコミュニケーション。

そうコミュニケーション以外ない。

 

何かあった時にしっかり伝えていたのかどうかが大事である。

• 仕様が決まっていないと開発できないこと
• 仕様が変更になると工数や費用が変わること
• 発注者側の業務フローや業務内容を理解していないこと

など多くのコミュニケーションを図り、相手に理解してもらっていたかどうかが大事だ。

大幅な開発方式の見直しなんて、そうそう起きない。

たぶん抜本的に変更しないと開発できないほどの仕様変更が発生しているのだろう。

そこまで行きつくまでの間にちょこちょこした仕様変更は重なっていたはずだ。

「分かりました」

「やっておきます」

はコミュニケーションではない。

発生し得る不条理や不都合、結果として起きるだろう未来を伝えた上で決定していただく必要がある。

判断はクライアント側にあるのだから、その判断をできる情報を提示して決定してもらう必要がある。

そのコミュニケーションをちゃんとしていたのだろうか。

 

もしクライアントに１つ１つ丁寧に説明し、クライアントの決定の元で行動していたとするならば、発注者側の逆ギレと言ってもいいだろう。

だが、コミュニケーションをしっかり図っていなかったのなら、開発者側にも問題があったと言わざるを得ない。

このコミュニケーション部分が争点になりそうだ。

新しい記事によると

このコラムを２月９日に書いているのだが、「IBMがNHKからの提訴を受けて声明、「幾度も協議開始を申し入れた」」という２月７日付の記事を新たに発見した。

これによると、あまりNHK側は褒められたものではないように思う。

旧システムから新システムに乗り換えたいというのが今回のスタートだそうだ。

旧システムが運用し続けていく中で機能の追加や廃止などを繰り返して成長していくのだが、提案時にNHK側から取得した要求書では把握しきれていない仕様を開発着手時に判明したそうだ。

その結果、その把握しきれていない部分については、お互いに協力しながら対応していこうとしたのだが、納期である２０２７年３月までの品質を担保した履行は難しいとして、複数の代替案をNHK側にIBM側が提案したそうだ。

これらの提案を受けたNHK側は契約の解除を決定したとのことである。

そ契約解除の決定後もIBM側は協議の申し入れをしたもののNHK側が応じずに提訴に至ったようだ。

 

これは完全にIBM側の主張のみとなっている。

なので、NHK側の主張が欲しいところだが、よくあることが起きたんだなーって思う。

判明した時点で巻き戻して内容の把握から改めてスケジュールの見直しを行って、納期の変更を行うべきだった。

やりながら協力して事にあたりましょう、で成功した事例は少ない。

とはいえ、NHK側の準備時不足が原因だろうなっていう疑いがますます大きくなった記事だった。

最終的にどうかと言えば

ここまで双方の立場から述べてきた。

私は開発会社を経営しているので、かなり開発者側に有利な立場から話していたと思う。

とはいえ、まだ明らかになっていないことが多いので、「NHKが悪い」や「IBMが悪い」といったことを述べるつもりではないことを改めてお伝えしたい。

あくまでも、今回の事例は一般的な事例でもよく見聞きするので、シェアした次第である。

 

今回のコラムで一番伝えたいことは、仕様変更が発生したら、その分工数や費用、リスクが発生するということは理解して欲しいということである。

なぜかこの当たり前を理解されない方が多い。

仕様変更が昨日決まったのに、「締め切りが明日だから明日までやってね」と平気で言ってくる。

その開発が１日でできるものであればいい。

もしその開発が１週間かかるものだったら、できるだろうか？

その仕様変更が微々たるもので１日で終わるようなものならできるだろう。

だが、その仕様変更がゼロからスタートしないといけないレベルだったら、できるだろうか？

１週間かけて作っているものをゼロから１日で作ることなんて無理な話なのだ。

こんな話がシステム開発では許される。

まずはどれだけのリスクが発生するかを確認してから、仕様変更をするかどうか、するならスケジュールの見直しをしてから依頼して欲しい。

自分が一生懸命作った何かを「気分じゃない」といって違うものにしろと言われたら、どんな気分になるか想像してみて欲しい。

一生懸命ハンバーグを作ったのに、「今日魚の気分だから、鮭にしてよ」と言われたらグリルにその頭を突っ込んでやろうかと思うだろう。

簡単に仕様変更とか言ってくんじゃねー、と思うし、仕様変更を重ねたくせに失敗したとか責めて来てんちゃうぞ、とも思う。

当たり前じゃないのだ。

仕様変更をしたら工数が増える。

工数が増えるからスケジュールも延びる。

これが当たり前なのだ。

何故この理屈が通じないのか全く理解ができない。

 

さて、こういったことが発生する企業に見られる共通点がある。

それは仕組み化がなされていないことだ。

ルール化、テンプレート化、システム化と言ってもいい。

誰がやっても同じ結果を出すことができる仕組みを作っていないから、失敗する。

システム会社に依頼する前に仕組み化をやってみてから発注した方が成功率が跳ね上がる。

もし失敗したくないと思うのであれば、業務の仕組み化に取り組んでみることをオススメしたい。

属人化の解消にも繋がるし、効率的に業務を回せるようになるので、システム開発以外でも中小企業は取り組んでいくべきだと思う。

 

今回のコラムが何か気づきや学びになればシェアしていただけると嬉しい。

それではまた次回のコラムでお会いしましょう。