第6回（2023／1／19）デジタル座談会
テーマ「『ITプロジェクトの失敗学 ～なぜ同じ失敗を繰り返すのか？』～失敗事例を紐解く～」
今回は、ITプロジェクトの失敗学と題して、世の中に公開されている裁判事例を取り上げて、その内容を分析する。
そして、その裁判事例は日本IBMと野村HDのものとなる。
この両者の紛争は、特殊なものではなくよくある事例であり、その内容を掘り下げユーザ企業として何をしなければならなかったかを議論した。
＜背景＞
◆ ITプロジェクト失敗の原因
ITプロジェクト失敗の原因は、上流の要件定義にある。そして、日経コンピュータによると、ITプロジェクトの約半分は失敗しているとのことだ。
その中で最も大きな原因は、システムの仕様変更が相次いだというものになっている。
では、要件定義は誰が行うのか？それはもちろんユーザ企業である。しかしながら、それができない、決められない。そもそも何が必要かわからない企業もある。
◆ 日本IBMと野村HD（日経コンピュータ2022年1月6日の記事参照
以下、概要。
2010年11月 プロジェクト開始
2012年9月 遅延・テスト不具合が頻発、野村証券が日本IBMに改善要求
2013年11月 改善要求に対して十分な回答が得られなかったので、プロジェクトの中止を通達。野村証券・野村HDが日本IBMに損害賠償請求
2019年3月 東京地裁判決は野村側が勝訴
2021年4月 東京高裁にて野村側が逆転敗訴
2021年12月 野村側の敗訴確定
以上のような流れで、最終的に野村側が敗訴した。日経コンピュータによると、ユーザ企業が「発注者」の強い立場に乗じ、仕様変更の頻発などでITベンダーに強硬な態度を取ったことが裁判に不利になる可能性がある、と論じた。
◆ 過去のIT裁判を振り返る
日本IBMと駿河銀行の裁判では、駿河銀行の勝訴となった。その時代においては、ITベンダーはプロフェッショナルであるということが大きな前提であった。そして、ユーザ企業は高額な費用を支払い、そのプロの技術を買っているという考え方が主流であった。結果、プロジェクトの失敗の原因はベンダーに帰した。
＜ディスカッション＞
・ ユーザ企業においては、やはり上流における企画・要件定義の力をつけなければならない。しかしながら、なかなかそのようなスキルや人材が育っていない点もある。そこをベンダーに補佐してもらいたいという気持ちはあります。
・ ユーザ側の法務部門の認識も古かったのかもしれないです。つまり、過去の判例ではユーザ企業に有利なものであったので、警戒心が薄かったということです。
また、日本の会社の責任者はITについてプロでないという背景もあるのかもしれません。
・BA（ビジネス・アナリシス）が重要でしょう。また、トップダウンのフォースが弱いとだめですね。特に、DX時代という何が正解かを模索するようなシステムでは、組織横断的な意思決定機関が重要になるでしょう。
・ベンダーの立場としては、お客さんのほうが強いという日本の風潮に違和感があります。ITベンダーも、元は技術に特化したものでした。そこからユーザ企業と足並みを揃えてプロジェクトを推進するような仕事に変わってきたということは言えます。そして、ユーザ企業にもっとエンジニアリング力をつけてほしいと強く思っています。また、エンジニアの人口バランスも日本においては偏っておるのも問題でしょう。大学でITを学び新卒で入社する人員は、やはりITベンダーのほうが多いです。
・日本IBMと駿河銀行の係争においては、ユーザ企業である駿河銀行が勝訴しました。その後、時が経ち、ちょうどこの日本IBMと野村HDの裁判において、その潮目が変わったのかもしれません。つまり、2019年において地裁では野村側の勝訴でした。そこから日本IBMの逆転勝訴が2021年です。この時期に裁判においてユーザ企業の責任の大事さというものが重視され潮目が変わったのでしょう。
＜総括＞
グッドプラクティスとしてのPMBOKについて、総括として振り返ります。
そもそもですが、このPMBOKの「主語」はユーザ企業なのであります。
その中で、ステークホルダーマネージメントが重要になります。これは、早い時点でステークホルダーを巻き込み組織の意思決定を早めるためのものです。
実は、PMBOKの第4版くらいまでは、ステークホルダーマネージメントというものはありませんでした。その後の5版以降においては、最も重要なマネージメント因子であると認識されています。
また、ウォーターフォールプロジェクトにおいては、変更管理プロセスが重要で、これは科学的な手法で行われます。
リスクマネジメントは、日本において弱いと言えるでしょう。リスクの想定が甘いわけです。なんとかなるだろうという雰囲気で突っ走ることもあります。欧米においては、リスクを想定し、その対応策が十分でないならそのプロジェクトそのものを実施しない、という意思決定もあります。
日本と欧米では、ITプロジェクトの考え方や体制、文化など大きく異なります。しかしながら、グッドプラクティスであるPMBOKを日本流にしてなんとか使いこなすことが重要と考えています。
＜全体を通しての意見＞
・日本においてのITエンジニアの立場を上げることも重要です。具体的には収入であってもいいはずです。でないと、優秀な人材は外国や外資系企業に流れていってしまいます。
・ユーザ企業に入社したITエンジニアも、その後のキャリアパスが問題です。下手をすると、企業の中の便利屋になってしまいます。企業がITを戦略的に使うということを目指すならば、そこにキャリアパスがあるはずです。それが無い企業が多いのなら問題でしょう。
・個人の視座に立つと、会社のキャリアパスと自分自身が考えるキャリアパスの2つがあるでしょう。つまり、自分自身の思うキャリアパスと齟齬があれば、会社を渡り歩くということになる、ということですね。
・リスクマネジメントの話がありました。ほとんどリスクを洗い出していない現場を多く見ています。人員そのものの病気や怪我のリスクを言うに及ばず、人事異動で重要な人員が外れるということもあります。近未来を想像する力が重要でしょう。
・そもそも、プロジェクトという言葉は「先を」「見通す」という言葉が語源です。日本はどうしても「管理」という言葉で捉えがちなのです。
・PMBOKにおける可視化、数値化さえできていない現状で、アジャイルに進めるのだろうかと思います。PMBOKという基本をもっと押さえるべきだと思います。この話で最も問題なのはベンダー丸投げです。アジャイル開発は、QCDよりも価値を優先します。価値とはユーザ企業自身のそれです。自分たちの価値を定義できず、ベンダー丸投げアジャイルは、たいてい失敗するでしょう。
以上、ITプロジェクトの失敗学としてデジタル座談会を開催しました。
（ファシリテータ 熊野憲辰）
