日本通運はなぜアクセンチュアを訴えたのか？ IT部門が「124億円の訴訟」から学ぶべきこと：日本独特の商習慣が招いた「124億円の訴訟」【前編】（2/2 ページ）

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

本プロジェクトの「失敗」はいつ決まったのか？

　今回問題になっているプロジェクトの規模は約123億円で、アクセンチュアの受託規模は約35億円だ。当初のスケジュールでは開発期間は2017年4月〜2020年7月の間となっていた。契約形態は、受託契約を前提としたいわゆるSI（システムインテグレート）契約となっている。

　そもそも受託契約は、SIerにとって極めてリスクが高い契約形態だ。SIerは成果物をスケジュール通りに完成させる義務だけでなく、契約で定められた通りに成果物が機能することを保証しなくてはならない。また、SIerは要件定義が詳細化する前に概算見積を出すことになる。概算見積がユーザー企業のプロジェクト予算となり、プロジェクトの事実上の上限額となる場合が多い。もし、予算が超過した場合はSIerとユーザー企業の間で厳しい交渉が実施されることになる。

　しかし、この時点で分かっている範囲で、正しい見積を作成するのは難しい。注文内容が不明確な状況で値付けするようなものだ。ユーザー企業が予算を確保しなくてはならないため、このような商慣習となっている。

　こうした話を同業者である米国のIT企業に話すと、「アンビリーバブル（信じられない）」と言われる。米国では委任形態の契約が主流で、日本の受託契約という概念は存在しない。委託契約でIT企業に義務付けられるのは開発業務の遂行だけである。いわゆる「人貸し」、あるいは日本で言うところの「準委任の工数型」に近いと考えられる。工数が増加すれば、通常はユーザー企業が費用を負担する。

　SI型の契約形態（受託契約）は日本独自のものであるため、米国など海外で開発経験をいくら積んでもそのまま国内で通用するわけではないというのは本件を考える上で重要なポイントになるだろう。

ユーザー企業にとっても、SIerにとってもリスクが大きい「受託契約」

　受託契約は、SIerにとっては上記で説明したようなリスクがあり、ユーザー企業にとっては、「SIerに丸投げ」というリスクがある。つまり双方にとって極めてリスクが高い契約だ。こうした契約が主流となるような商習慣は、性善説によって成り立っているのだと筆者は考えている。

　つまり、SIerは陰日向なく顧客のために全力を尽くし、ユーザー企業はプロジェクト成功のために要望を飲み込み、頑張るSIerを決して悪いようにはしない――。財布を拾えば交番に持っていくような不思議の国・日本ならではのものではないか。

　かつて、日本における仏教の一派である曹洞宗を開いた道元禅師は、「一切は衆生なり、悉有は仏性なり（森羅万象全てに仏性がある）」と言った。一方、キリスト教の教えでは、人は生まれながらにして「原罪」を背負う。キリスト教徒の多い欧米諸国はこうした性悪説を取るからこそ契約にこだわるのではないかと筆者は考えている。特に米国では裁判が頻発している。日本的な商習慣を前提とする場合、SIerの選定は極めて慎重に考えるべきだ。

　本プロジェクトの規模をどう推測するかという話に戻ると、全体の約2〜3割は、ハードウェアやネットワークなどのインフラストラクチャにかかる費用と仮定した場合、ソフトウエア開発の規模は90億円〜100億円程度だと考えられる。そうすると、全体規模は「超大規模プロジェクト」に準ずる規模で、極めて難しいプロジェクトだということになる。

　この規模のプロジェクトをコントロールするためには、SIerの極めて有能な人材（PM）を獲得しなければならない。技術的に難易度の高い問題を解決できる人は極めて少ないが、解決できない人をいくら集めても難易度の高い問題は解決できない。

　おそらくこのレベルのプロジェクトをコントロールできる人材はユーザー企業には存在しないだろう。そこで筆者が最も優れた対処方法だと考えるのが、超大規模プロジェクトにはせず、オブジェクト指向型開発で再構築し、最終的には、中小規模システムに分割し、大規模システムをなくすことだ。つまり、マイクロサービスアーキテクチャーの採用だ。

　次に、本プロジェクトの工程を推測してみよう。アクセンチュアの受注金額から逆算すると、116万〜175万steps相当になる。既存のシステムやデータを開発後のシステムに移し替える移行などにかかる工程を除外すると、100万steps程度になる。この工程で開発されるのは機能システムに相当する。かなり優秀なPMが担当するレベルだ。

　また、本プロジェクトの受託範囲に「移行専用機能」「顧客連携現新変換機能」の文言が含まれていることから、現行機能保証が組み込まれた機能システムであることが推察される。既存システムを再構築する場合、SIerはその程度はともかく現行機能保証から逃れることはできない。つまり、アクセンチュアの担当部分は、機能システム相当の大規模プロジェクトであり、かつ現行機能保証を求められる、極めて高い難易度の案件だといえるだろう。

　なお、本プロジェクトは2020年6月頃からテストが遅延していたという情報がある。これが事実だとすれば、当初のスケジュールでリリース時期として予定されていた2020年7月の1カ月前ということになる。マスタースケジュールはこれよりも前に見直されていたはずだ。つまり、本プロジェクトの品質不良は、相当以前に発覚していたのではないか。

　おそらく品質問題が何度か発生し、対策を繰り返す中でスケジュールが見直されたのではないか。2020年6月時点で、発注側である日本通運はアクセンチュアに対して品質対策が不十分だという不信感を抱きながら最悪のケースを想定した対応を模索し、受注サイドであるアクセンチュアは、リスクの最小化を優先するという状況に陥っていた可能性がある。

　つまり、プロジェクトの致命的な「失敗」は、この時点でほぼ確定していたと筆者は考える。もしそうであれば、この時点で「プロジェクトを成功させよう」という意識が双方で失われていたのではないか。

　次回は、大規模プロジェクトにおける現行機能保証がなぜ失敗を招くのかという視点でさらに深堀りしたい。

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

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

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

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

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

（注6）日本で開発されたプロジェクトマネジメントのフレームワークで、プロジェクトおよびプログラムの成功を目指して体系化された理論と実践手法を指す。個別のプロジェクトだけでなく、複数のプロジェクトをまとめたプログラム全体を管理するための包括的なアプローチを提供する。

著者紹介：室脇慶彦（SCSK顧問）

むろわき　よしひこ：大阪大学基礎工学部卒。野村コンピュータシステム（現野村総合研究所）執行役員金融システム事業本部副本部長などを経て常務執行役員品質・生産革新本部長、理事。独立行政法人　情報処理推進機構　参与。2019年より現職。専門はITプロジェクトマネジメント、IT生産技術、年金制度など。総務省・経産省・内閣府の各種委員など、情報サービス産業協会理事などを歴任。著書に『SIer企業の進む道』『プロフェッショナルPMの神髄』などがある。