アクセンチュアに責任を問えるのか？ 「124億円の訴訟」に学ぶ、システム開発失敗の原因：日本独特の商習慣が招いた「124億円の訴訟」【後編】（1/2 ページ）

「124億円の訴訟」からユーザー企業のIT部門は何を学ぶべきか。SIer側からシステム開発に長年携わってきた筆者が、本件における「開発失敗の真の原因」と「開発失敗がユーザー企業に与える、コスト以上のダメージ」を考察する。

[室脇慶彦，SCSK株式会社]

本稿について

　日本通運は2023年7月12日、アクセンチュアを相手取って東京地方裁判所に提訴した。日本通運が求める損害賠償額が124億円と膨大な額であることで注目を集める本件（注1）には、「ITシステム開発で起こりがちなトラブルを回避するために知っておきたいポイント」が幾つか含まれている。

　そこで、SIerのプロジェクトマネジャー（PM）としてシステム開発に長年携わってきた室脇慶彦氏が、本件の根底にあるシステム開発における日本独特の商慣習や、SIerとユーザー企業との関係について自身の見解を述べる。

　本件はともすれば124億円という請求額の大きさが目を引きがちだが、システム開発の失敗がユーザー企業に与える影響について、筆者はコスト以外の部分の方がむしろ大きいと踏んでいる。

　同様の失敗はおそらく今も起きており、今後も起こり得る。背景にあるのが日本独特のSIビジネスの課題であることから、誰もが当事者になり得るのだ。

プロジェクト失敗の「真の原因」は？ 　“開発の鬼門”とは？　　

　前編でも見たように、日本通運がアクセンチュアに開発を委託したプロジェクトは、開発の難易度が高い「超大規模に準じる大規模プロジェクト」だ。それに加えて、開発の鬼門とも言える「ある要素」がただでさえ高い難易度をさらに高めたというのが筆者の見立てだ。

　また、本件ではテスト工程や検収に関する両者の言い分の違いが目立つが、筆者は開発失敗の真の原因は別にあると考えている。

　考察を進める前に改めて断っておきたいのが、本稿は、報道や裁判記録で明らかになった情報を基に考察している。ただし、執筆段階で裁判の判決はまだ出ておらず、両者の主張は真っ向から対立しているため、「実際に何が起きたのか」を正確に知ることは難しい。以下の考察があくまでも推測の域を出ないことを了承いただきたい。また、くどいようだが、本稿には訴訟の当事者である両者を非難する意図はない。読者が同じようなトラブルの当事者にならないためにどうすべきかを本件から学ぼうというのが本稿の趣旨だ。

　まず、両者の主張の隔たりが目立つ、テスト工程について話を整理しよう。

　プロジェクトが大規模であるか中小規模であるかによって、テスト工程の在り方は異なる。今回は超大規模に準じる大規模プロジェクトだったため、ST（総合テスト工程）（注2）を経なければ、作り手としては品質を保証するのは困難だろうと一般的には考えられる。

　今回のプロジェクトの場合、「ITb」を最終テスト工程としている。ITbは、通常は「結合テスト」（注3）の一環であると解釈される。つまり、本件は大規模プロジェクトであるにも関わらず、中小規模プロジェクトレベルの結合テストで終了し、STは実施されなかった可能性がある。

　さらに、アクセンチュアは今回のプロジェクトに関して大規模プロジェクト全体を統括できるPM（プロジェクトマネージャー）を配置していないか、あるいは社内でのチェック機能が適切に働いていなかったと推測される。同社とユーザー企業である日本通運がどのような責任分担で契約したかによって、アクセンチュアに対して責任を問えるかどうかが決まるだろう。

　厳しいようだが、「STそのものが抜けている本件が失敗するのは当然だ」というのが筆者の考えだ。中小規模プロジェクトと大規模プロジェクトでは各工程におけるPMの“振る舞い”が大きく異なり、特に大規模プロジェクトはあらゆる工程で問題が発生することになる。詳しくは、筆者の著書『PMの哲学』（日経BP）、『失敗しないITマネジャーが語る　プロフェッショナルPMの神髄』（日経BP）をお読みいただきたい。

「打鍵テスト」で発覚した不具合件数が示唆するもの

　ここまで今回のテスト工程について考察してきた。プロジェクトのテスト工程としてITbだけが実施され、本来大規模プロジェクトで実施されるべきSTは、アクセンチュアの責任としては実施されなかったというのが筆者の考えだ。

　この場合、アクセンチュアにとってSTが「検収テスト」になり、ユーザーの指摘のみに対応することになる。自ら開発していないサブシステム間の整合性を確認することは、ベンダーにとって極めて困難であり、失敗する可能性が高い。

　もっとも、「ITbにST相当の内容が含まれている」というケースもあり得るかもしれない。

　その可能性を踏まえて、今回実施されたSTにおける品質レベルを分析してみよう。本件ではITbで日本通運が「打鍵テスト」（注4）を実施し、「1487件の不具合を検出した」とされている。当然、日本通運のテストに先立って、アクセンチュアでもテストを実施して不具合に対応していたと推察される。

　日本通運による打鍵テストで発覚した不具合件数「1487件」（アクセンチュア資料では「2031件」と記載）という数字の真偽はどうか。ソフトウェア開発では似たような状況や原因によって他の場所でも同様のバグが発生するため、こうした同様のバグもカウントされていると考えて、仮に半分の「700件」（アクセンチュア資料では907件）のバグを発見して対応していたとする。さらに、アクセンチュアが少なくともこれ以外に約700件バグを見つけて対応したとすると（普通は受託者が多くバグ出しをするのが常だが）、全体で少なくとも1400件以上のバグが検出されたと推測される。

　筆者の長年の経験やこれまでのデータから考えると、STにおけるバグ密度は、1000steps 当たり0.2〜0.3件だ。前編で今回のプロジェクトでは開発規模を100万stepsと推計しているので、これに置き換えると、STで発生するバグの総数は200〜300件程度となる。

　仮に本件におけるITｂをST相当とした場合、アクセンチュアが想定した5倍以上のバグが発覚することになり、品質としては「極めて悪い」ということになる。これは品質対策後にSTを再実施するレベルだろう。つまり、「今回実施されたITbがSTに相当する内容」というのは疑わしいと言わざるを得ない。

　さらに、今回実施されたITbが結合テスト（IT）であると想定しても、今回のバグ密度のレベルは上限ぎりぎりだと筆者は考える。バグの件数をかなり少なめに見積もっているため、今回想定したバグよりもさらに多くのバグが潜んでいる可能性が高い。結合テスト（IT）としての品質も不十分だと考えられる。

　報道によると、アクセンチュアは「もっと後に予定されている『ユーザー受入テスト』（注5）ではなく、ITbから顧客サイドが参加するのは過剰だ」と指摘したようだが、これはどう考えるべきだろうか。筆者の経験からすると、むしろ歓迎したい。プロジェクト成功のためには、早く問題を把握して早く対応することが必須条件になるからだ。

　前編でも触れたとおり、大規模プロジェクトの場合、方式設計（注6）などのシステム基盤の設計と開発が必要だ。本件では、データの排他制御が問題化している。アクセンチュアは「データベースの特定エリアをロックすることは一般的でない」としている（注7）が、筆者は自身の経験からこの主張に反論したい。データベース側だけに排他制御を依存するのではなく、アプリケーション側で「同一ユーザーが同時に複数の操作を実施する」といった、あり得ない状況をチェックして排除するのは当然だからだ。

　さらに、データベースを更新するプログラムが異常終了した場合、更新されたデータベースを復元する処理は、オンラインシステム向けに基本的な仕組みとして提供されている。ロックをかけない場合は、異なるプログラムがデータベースの復元前に更新する可能性があり、データベースの整合性が取れなくなる可能性がある。従って、データベースをロックすることが必要になる。

　いずれにしても、基盤SE（ITアーキテクト）が業務仕様から必要な仕組みを洗い上げ、過去の経験を踏まえて必要な処理方式を設計する必要がある。この基盤SEは、一般のSEとは異なりデータベース、あるいは基本ソフトなどに精通していることが求められる。今回のような大規模プロジェクトには必須の人材だ。

　また、ユーザー企業サイドが本件で排他処理を問題としている理由が、業務処理として仕様と異なる結果が出たことにあるのであれば、これはバグであり、その原因が排他処理の不正とも考えられる。方式設計の工程と基盤技術者も、この規模のプロジェクトではやはり必須なのだ。

　この設計工程が省かれると、システム自体が使い物にならなくなる。ビル建設に例えると、基礎工事が不十分である場合、工事が進んで階数が高くなるにつれて基礎部分が傾き、倒壊するリスクが発生し、工事続行が不可能になるケースに似ている。

　ここまでの想定が正しいならば、本件ではそもそも動かないシステムが出来上がっていた可能性が高い。

　契約内容自体が不明で裁判の行方も分からない現在、プロジェクトの全貌を推測するのが難しいというのはこれまでも繰り返し書いてきた。ただし、大規模プロジェクトであることを踏まえると、受注側に十分なケイパビリティが備わっていたかどうかは疑問が残るところだと言わざるを得ない。発注側が、受注側の諸条件をどこまで認識していたかも問われることになるだろう。日本的な商習慣であるいわゆる「丸投げ」を前提に発注していたとしたら、致命的な条件を発注側が受け入れていた可能性もある。

（注1）基幹システムの開発が頓挫、124億円の賠償巡り日本通運とアクセンチュアが激しい応酬（日経クロステック）

（注2）各サブシステムを結合して、機能システム全体が正しく稼働するかどうかを確認するテスト。サブシステム間の接続に関して、想定できるケースをもれなく確認する必要がある。通常、STの段階で初めてサブシステム間のデータ接続をテストするため、サブシステム間の仕様バグなどが多く検出される。

（注3）個別にテストされたモジュールやコンポーネントを組み合わせて、正しく連携、動作するかどうかを確認するテスト。個々のモジュールが単体テストで問題なく動作することを前提として実施される。

（注4）実際にキーボードを「打鍵」してシステム動作を検証するテスト工程。自動化されたテストでは検出できない、ユーザビリティやデザイン、システムの異常なふるまいなどがないかどうかをユーザーの視点から確認する。

（注5）システム開発の最終段階で実施されるテスト。ユーザー企業の従業員がシステムを実際の業務環境で使用して、機能や性能が要求仕様を満たしているかどうか、問題なく動作するかどうかを確認する目的で実施される。最終的な受け入れ判断を行うための重要なプロセスとなる。

（注6）システム開発の初期段階におけるプロセスで、システム全体のアーキテクチャや主要な技術的要素を要件定義に基づいて設計する。システムがどのように動作し、どのような技術によって構築されるかを決定する。

（注7）日本通運のシステム開発訴訟、指摘多数の原因は「特殊な検収」とアクセンチュアは反論（日経クロステック）