2024年9月末、日本通運が基幹システムの開発失敗をめぐってアクセンチュアを提訴、124億円の賠償請求というニュースが報じられた。

日本通運が基幹システムの開発失敗を巡ってアクセンチュアを提訴、124億円の賠償請求 https://xtech.nikkei.com/atcl/nxt/column/18/00001/09779/?n_cid=nbpnxt_twed_it

これほどの規模の事案はそうそうなくても、発注・受注間のトラブルはIT業界の「あるある」だ。会社に大きな損害をもたらすだけでなく、担当したPM個人のその後のキャリアにも傷がつきかねない。

どうすれば訴訟リスクを低減・回避できるのか。東京高等裁判所にて、数多くのIT訴訟の調停委員を務めた実績を持ち、IT紛争に精通する細川義洋さんに聞いた。

IT紛争解決とIT開発プロセスの専門家
ITプロセスコンサルタント
元東京地方裁判所民事調停委員・IT専門委員
元東京高等裁判所IT専門委員
細川義洋さん

国内ソフトウェア企業において金融業向け情報システム及びネットワークシステムの開発・運用等に従事した後、外資系コンサルティングファームITコンサルタントとして、IT関連プロセスの品質向上や企業のIT戦略立案の支援に従事。その後、内閣官房政府CIO補佐官としてITガバナンスやデジタルガバメントの推進に従事。東京地方裁判所、東京高等裁判所にてIT開発・運用に関わる紛争の解決支援を行った経験も持つ。 現在も経済産業省のデジタル化推進に関わり、デジタル庁技術検討会議ガイドタスクフォースメンバーとして標準ガイドラインの策定にも参加する傍ら、著述、講演、ITプロセスに関わるコンサルティング、IT紛争解決の支援を行っている。著書には『システムを「外注」するときに読む本』（ダイヤモンド社）、『成功するシステム開発は裁判に学べ！』（技術評論社）等がある

起こるべくして起こる要件のすれ違い

━━細川さんは裁判所でIT関連の紛争の解決支援経験をお持ちです。IT紛争にはどのようなものが多いですか？

ITに関する紛争にはいくつかの類型がありますが、やはりユーザー側が「頼んだものができてこない」と言って起こす訴訟が最も多いです。

その中には「そもそも要件を満たしていない」というものもあれば、「納品こそされたが、品質が悪すぎて使い物にならない」というものもあります。

いずれにしろ「こんなものにお金は払えない」とユーザーは言うわけです。それに対してベンダー側も「悪いのはうちではなく、そちらがしっかりと要件を示さないからだ」「ユーザーが協力してくれなければ、いいものなどできるわけがない」などと反論することで、事態は泥沼化します。

実際は、ユーザーの要件の示し方が悪いこともあれば、明らかにベンダーの要件理解が足りないこともあります。また、お互いに要件は理解しているのですが、生産性の見積もりが甘く、スケジュールが逼迫した結果、必要な要件やテストが抜け落ちてしまうケースもあるでしょう。

━━要件のすれ違いはなぜ起こるのでしょうか？

業務要件からシステム要件に落とし込む際に起こる、いろいろな抜け漏れや勘違いが原因となるケースは多いです。

業務要件とは、システムのユーザーである発注側が業務で実現したい目標といった人の動きを中心とした流れのことをいいます。

一方、システムの受注側であるベンダーは、どのようなシステムであればこの業務要件を達成できるかを考案し、定義します。これがシステム要件定義です。この詳細化のフェーズに落とし穴があります。

例えば「このデータベースからこういうデータを取ってくればいいだろうということしか決めていなかったら、実際は引っ張ってこれないデータだった」「本来は操作者によってあるべき画面の仕様は違ってくるのに、誰が使うのかを詰めきれていなかった」など。思い込みなども邪魔をして、現実に即して詰め切れていないケースが多いです。

━━システムに落とし込めなかったベンダー側に問題があるということですか？

そうとも言い切れません。ユーザー側の決定の遅れが原因になることもあるからです。

例えば、有名なIT紛争に「平成16年3月10日判決」と呼ばれる裁判があります。保険の申込システムに関するもので、システムの不具合を理由に契約を解除したユーザーとベンダーとの間で発生した、損害賠償請求に関する紛争です。

業務要件としては、エンドユーザーから紙やFAXで送られてきた情報をコンピュータシステムに入力し、登録するというシンプルなもの。ところがこの事案では、その情報を各支店で入力するのか、それとも事務センターで一括入力するのかをユーザー側がなかなか決め切れませんでした。

どちらで入力するのかで必要なシステムもネットワークも個人情報の記録の仕方も変わってきます。それが決まらないままプロジェクトが進み、後になって次々に発覚したことで、プロジェクトはどんどん遅延してしまったのです。

ユーザーもベンダーも、放っておけば自分たちに都合のいいように考えてしまうものです。作り手であるベンダーからすれば、事務センターで一括で入力した方が効率的ですし、コストも安く済むから、そのつもりでいる。ですが、ユーザーの頭の中は、それとはまったく逆。業務が多く、暇がない事務センターで一括で入力するという発想は、そもそもありません。

そのようなすれ違いが起きていることにお互いに気付けないままプロジェクトが進み、発覚したころにはもはや取り返しがつかない、となってしまうケースは非常に多いです。

━━ベンダーの調査不足という側面も、ユーザー側の情報提供不足という側面もあるということですね。

ユーザー側の情報提供が不足しがちなのも、必ずしも怠慢というわけではありません。そこには構造的な理由があります。

提案書類は業務を知り尽くしたユーザーが内部で作成します。ユーザー側はベンダーがシステムに落とし込む上でどこまでの情報が必要か分からない。結果として、重要な情報の連携が抜けてしまうことがあるのです。

トラブル確率を下げる「努力の仕方」

━━最初から何の抜けもれもなく、全てを決め切るのは難しいようにも思えます。解決策はありますか？

すっきり解決できるようであれば、こんなには裁判になっていないでしょうね。ただ、トラブルに発展する確率を下げるためにできる努力はいくつかあります。

━━どんな努力ができるのでしょうか？

必要な全ての機能の詳細をいきなり網羅して考えることはできません。ですから、継続的に議論ができるよう、業務を知るユーザーとシステムを知るベンダーがワンチームになる必要があります。お金をもらう人・払う人という立場の違いはひとまず忘れて、同じ目的に向かって進むチームになるのです。

このチームには、システム担当者だけでなく、実際にシステムを使うことになるエンドユーザーにも入ってもらうことが不可欠。全員が一つのチームになって、最初はユーザー側から示された要件定義書をみんなで理解することから始めるべきでしょう。ベンダー側が定義書を読んで質問をぶつけるというのではなく、ユーザー側も含めてみんなで読み合わせをするのです。

そうすると、ユーザーの内部からも「本当にこういう業務だったっけ？」などと疑問が出てきます。あるいは、ユーザーからベンダーに向けて「こういうことはシステム的にはできるんですか？」という質問が出てくることもあるでしょう。そこから「そういえば画面は？」「そういえばセキュリティは？」……といったかたちで、話は広がっていきます。

そうやって必要な人、もしかしたら必要でない人も含めてみんなで集まる。雑談も交えて話の輪を広げていく。そうした中で、お互いのことを知っていくしかないのだと思います。

これは要件定義書の読み合わせに限らず、その後に続く設計書でもなんでもそうです。そういう意味では、継続的に集まれる物理的な環境として、プロジェクトルームがあるのがベストでしょう。そこまではいかないにしても、ユーザーとベンダーがフランクに会話ができる環境を用意する必要があります。

━━お互いの認識のすり合わせはどの段階までにやり切るべきですか？

要件定義の段階で凍結できれば理想ですが、そうそううまくはいかないでしょう。一方、一度詳細設計に入ってしまったら、技術的な話になるので、ユーザーには理解できません。要件定義から詳細設計に入るまでの間で、お互いの理解をいかに擦り合わせられるかが、成否の鍵を握ります。

多くのプロジェクトでは、要件定義が終わるとすぐにプロジェクト計画、基本設計へと進んでしまいます。ですが、本来はもっとたくさん時間を取るべきなのです。要件定義と基本設計の間、基本設計と詳細設計の間、この二つのタイミングで確認期間をしっかりと取った方がいいです。

どれくらいの期間を設けるべきかは、プロジェクトの規模にもよります。私の感覚で言えば、プロジェクト全体の2割は欲しいですね。全体が10カ月のプロジェクトであれば、要件定義と基本設計の間、基本設計と詳細設計の間、それぞれに1カ月ずつの確認期間を取るということです。この段階ですれ違いが発覚すれば、スケジュール的にもお金的にも余裕がありますし、手戻りも最小限で済みます。

理想論すぎると感じるかもしれませんが、これを徹底すれば、トラブルに発展するリスクはだいぶ抑えられるように思いますよ。

━━ほかにもできることがありますか？

もう一つは、テクニック論ですが、業務フローの形に落とし込んで議論することです。

ユーザーからすれば、自分たちの業務の話になるので、無理なく理解できます。一方のベンダーからしても、フローチャートというのはシステム化するのに相性がいい。お互いにとっていい接点になるわけです。

ただし、書き方にポイントがあります。

━━どんなポイントがありますか？

一つは、「入力」と「演算」と「出力」からなる形を意識することです。「入力」する情報はどういう情報なのか。どういう「演算」なのか。その結果として何が「出力」されるのか。これをロジカルに、具体的に書くということです。

もう一つは「主語」を意識すること。主語というのは、まずは「誰が操作するのか」。操作する人によって生産性やITリテラシー、時間的制約などは異なります。それによって必要なものも変わってくるということです。

次に、業務の結果として出力されたものを「誰が受け取るのか」。さらには「誰が喜ぶのか」。システム化の目的に即していない「誰か」が喜ぶ機能を全て追加していては、要件が膨らみ、失敗の確率は高まります。

逆に「誰が悲しむのか」という問いもあります。目的を果たすためには、社内のどこかに悲しむ誰かがいたとしても、進めないといけないケースはあります。ですが、その分のフォローを考える必要はあるでしょう。そういったことまで含めて業務フローを書けると、ユーザーとベンダーの理解が近づき、要件定義が原因のトラブルが発生する確率は少し減るのではないでしょうか。

あと、ベンダー側のPMには、システムの専門家として「NO」と言えることも問われます。「こういう体制を整えてくれないと、いいものは作れない」などと、しかるべき提案ができるかどうか、ということです。こうした発言を行うことをベンダーの権利、オプション、あるいは親切心からくるアドバイスと認識しているPMが非常に多いのですが、それは間違いです。これは「プロジェクトマネジメント義務」といって、裁判上ではベンダーの義務なのです。こういうことを怠ると、専門家としての義務を果たしていないことになり、裁判には負けます。

と言っても、この義務は決してPM一人が抱える義務ではありません。ユーザーと物事を決めていく過程には、ベンダー側にいるプロジェクト責任者はじめ、技術主幹やリーダー、営業担当とさまざまなプレイヤーがいますよね。決してPMだけが全てを決定しているわけではないのでITベンダー全体が義務を負います。

━━権利ではなく、義務。

そうです。ベンダーはこのことを本当にしっかりと認識した方がいいです。

ユーザーがいつまでも要件を決めてくれなかったら、「いつまでにやってくれないとできませんよ」と言わなければならない。自分たちの生産性が低いせいでプロジェクトが遅れた時でさえ、専門家として「スケジュールを見直しましょう」「要件の一部を落としましょう」と言わなければならない。こういったことを言わずに放置していたら、それはプロジェクト管理義務を果たしていないことになります。

要件凍結後にユーザーが要件外のリクエストをしてくるのは「あるある」ですが、こうした「わがまま」に対して「商売だから」と安請け合いしてしまうのは、最も危険なパターンです。

本来は「そんなことはできません」「代わりにこの機能は落としてください」「次のフェーズでやりましょう」「お金を追加してくれるならできそうです」などと、次善の策を提案しないといけません。ユーザーの言うことに「YES」としか言わないイエスマンは危ないということです。

━━ベンダー側は胸に刻んでおきたい話ですね。

はい、「裁判上の義務」はまだまだ知らない人が多い知識です。

あと、トラブルを起こしやすいPMの特徴で言うと、メンバーに優しすぎるPMも危ないです。プロジェクトを進める上では、メンバーに対して厳しく接し、「腹を括ってやれ！」と言わなければならない時もあります。普段はリベラルでいいのですが、本当にトラブって徹夜しないとどうしようもないという時には、むしろ頭からガツンと言われた方がメンバーとしてもやりやすい。いざという時にそういうことができないPMはきついでしょうね。

「一人で抱え込む」が命取りに

━━万が一、トラブルや訴訟に備えてPMがやっておくといいことはありますか？

まず、日頃からトラブルが発生しないようにステアリング・コミッティーの場*を定期的に設け、そのための情報を逐次上げておくといいでしょう。

現場でベンダーとユーザーの担当者がどれだけ歪みあっていても、プロジェクトの責任者、特にお金の責任を握っている人同士で話したとたんスルスルと解決してしまう「大人の解決」の道があったりしますから。

万が一、裁判に発展してしまった時に役立つこととしては、記録を残しておくことです。メール、議事録、話し合いのメモ、ホワイトボードを写したもの……誰かと話し合って合意したことは全て徹底して記録に残しておく。裁判官は現場で話されたことを2割くらいしか信じません。紙に書かれていることが信頼性のあるものとみなされます。

また、裁判では役割分担で揉めることが多いです。お互いのタスク、成果物、役割分担は明確にし、文書に残しておくべきです。役割分担を決める際に使われがちな「支援」という言葉は、実は非常に危険です。曖昧すぎて、お互いに都合のいいように解釈されることが多く、トラブルにつながりやすいのです。

そして肝に銘じなければならないのは、裁判は長丁場だということ。途中で当事者が退職していなくなってしまうといったこともしばしば起こります。「この時の事情はこの人しか知らない」という状況を作ってしまうと困ることになるので、必ず複数名が関わるようにしましょう。

最終的には裁判は体力勝負になるので、健康には気をつけましょう、というところでしょうか。

━━ちなみに、訴訟に発展して会社に大きな損害を与えてしまったPMの、その後のキャリアはどうなりますか？

会社の体制によるので、一概には言えません。それに、プロジェクトはPMだけでなくさまざまな主要メンバーが介在した上で動いていますから、PM一人が責任を負うケースはほとんどないと思います。

その前提の上で私自身のケースをお話すると、私は大手ITベンダー時代、会社に2億円の損をさせたことがあります。その時はボーナスが1回なくなっただけで、少なくとも形式上はキャリアに傷はつきませんでした。

一方、その後に勤めた外資系IT企業はシビアでした。失敗自体は誰にでもあることとされているのですが、その時に何をしたかがシビアに問われます。周りと相談して、その中でしっかりと次善の策を考え、それでも失敗したのなら、それはむしろ平均より少し上の評価になります。ところが「相談していなかった」「一人で抱え込んでいた」となると、一気にクビ寸前です。

ですから、会社によってもだいぶ違うのですが、一点共通して言えるのは、「困った時には早めに周りに相談するべき」ということでしょうか。それがあなたのキャリアの傷を最小限に抑えることにもなる。この認識はどこも共通しているかもしれないです。

「できれば隠したい」という心理は分かります。結果としてうまくいきさえすればいいのだから、と思うでしょう。ですが、そういう時は恥を忍んで周りに相談し、使える社内のナレッジを頼るべきです。一人で囲い込んで失敗したら、本当にやめるしかなくなってしまうこともあり得ますから。

取材・文／鈴木陸夫　編集／玉城智子（編集部）

書籍紹介

『エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと』
著者：細川 義洋
出版社：ソシム
定価：2420円（税込）

利益拡大、業務効率化、顧客満足度向上……。
いまや企業が「何か」を成し遂げようとするとき、そこに「システム」の存在は不可欠です。しかし、IT企業ではない会社の「システム発注」や「システム導入」の仕事というのは、どうも人気がないようです。

それもそのはず、「欲しいシステムを手に入れる」たったそれだけのことが、「無理ゲー」とでも言いたくなる難しさだからです。
予算オーバー、リリース遅延、ベンダーとの不和、経営陣からのプレッシャー、出来たけど誰も喜ばないシステム……。

1つだけでも厄介なのに、それらが一斉に起きることもザラにある。それがシステム開発です。

本書では、1mmも望んでいないDX室への異動を命じられた主人公が、悪戦苦闘、七転八倒、阿鼻叫喚を繰り広げながら、周囲を巻き込んで「欲しいシステム」を手に入れるまでを8つのストーリーで解説。システムの開発工程に沿って、必要なノウハウと心構えを体得することができます。

>>>購入はこちら