かつてない「システム発注者のための入門書」として注目を集め現在5刷のロングセラー『システムを「外注」するときに読む本』。本記事では、その著者であり元東京高等裁判所IT専門調停委員、現在は経済産業省CIO補佐官の細川義洋氏が、システム開発における「経営者の役割と責任」を裁判例や実例をベースに問うていきます。
知識ゼロからでも、ＩＴ導入を無事成功させることができる、実践的な知識とスキルをお伝えしていきます（構成：今野良介）。
「それをやっちゃマズイでしょ」
ITシステムを導入しようとする発注者（ユーザー）には、自分自身で身につけておかなければならない基本的な知識があります。プログラムの内容やデータベースの構造のような、技術知識が必要なわけではありません。
ITシステム導入を行う際の基本的な段取り、その中での自分達の役割・責任、これをやったらマズイだろうというNG対応の例。それくらいは押さえておかないと、いかに優秀なシステムベンダーに仕事を頼んでも、結局、使い物にならないシステムに何千万円、何億円というお金を払う羽目になります。もっとひどい時には、プロジェクトが途中で破綻して、裁判になったりもします。実際、IT紛争は日常茶飯事といってよいほど頻繁に発生しているのです。
今回は、そうした紛争の中から、特に発注者のNG行動、「それをやっちゃマズいでしょ」という話を、ある裁判の例を元にご紹介します。なお、この事件については学ぶべきポイントが多いため、今回と次回の2回に分けてお話しします。
「他人の作りかけ」を引き継がせる危険
これは、大阪地方裁判所に提起されたある訴訟の事例です。
ある発注者企業が、経営情報システムの開発を企画して、どんなシステムを作ったらよいかを検討する基本設計（要件定義）をコンサルタント会社に、実際にシステムを作る作業（詳細設計・プログラミング等開発・テスト）をITベンダーに依頼することにしました。
ところが実際に仕事を始めてみると、基本設計を行うコンサルタント会社が期待通りの働きをしてくれず、発注者企業が望む要件定義をやってくれません。本当に業務に役立つシステムの要件を抽出することができずに、時間だけがどんどん過ぎていく。それ以降も作業は遅々として進まず、業を煮やした発注者企業は、途中でコンサルタントとの契約を打ち切ってしまいました。
そうなると、基本設計を受けて後続の開発をしようとしていたITベンダーは困ります。そこでベンダーは発注者企業に対して「自分達がもう一度、基本設計からやりましょうか？」と提案しましたが、発注者企業の経営層の判断は「No」でした。「コンサル会社が残していった基本設計書にも少しは役立つ部分があるから、それを引き継いでやってほしい」と告げたのです。
お客さんからそう言われてしまえば、ベンダーも従わざるを得ません。やむなくコンサル会社の作った資料を見ながら、それを加筆・修正する形で作業を進めました。ベンダーは、他人の作りかけを引き継ぐという「やりにくい状況」の中で作業を進め、一応完成はしたのですが、やはり出来上がったモノには多くの不具合が混入していました。また納期も遅れていたため、発注者企業は費用の支払いを拒み、そのベンダーと裁判になってしまったのです。
「1＋1＝2」にはならない
システム開発において、誰かが中途半端に作ったものを他社の人間が引き継ぐやり方は非常に成功率が低く、ほぼNGと言ってよいくらいです。
たとえばシステム化対象の業務を表す「業務フロー図」を書くとき、世の中には、「BPMN」や「DFD」などいろいろな書き方があるだけでなく、完全な我流で書いてしまうエンジニアやコンサルタントも少なくありません。普段、BPMNしか書かない人が、DFDや我流で書いたものを正しく理解するのは、そうとう困難です。
また、ある技術者が「これは当たり前のことだから」とわざわざ書かなかったことが、他の人が読むときには実は重要なことだったりします。「今どき、インターネットを使うなら暗号化は当然」と記述しなかったがために、引き継いだ人間が「暗号化不要」と解釈して脆弱なシステムを作ってしまう、という危険もあります。
「だったら、最初から全部書けばいいじゃないか！」と思われるかもしれませんが、それをやると、設計書が10000ページになっても終わらないといったことにもなりかねず、ある程度のところで抑えておかないとキリがない、というのも事実です。そして、そのように理解しにくい文書の中には、通常、数多くのヌケ・モレ・間違いが混入しており、引き継いだ人間を混乱させます。
他の仕事でも似たところがあるかもしれませんが、ITの場合、その文書量の多さ、モノの細かさ、複雑さ、人による言葉の解釈のバラつき具合、求められる専門性の高さなどが他の業界に比べて格段に高く、その分、他人が理解するのが困難なものです。
無論、こうしたことは設計書などの文書に限りません。他人が途中まで作ったプログラムを完成させろというのは、例えていうなら、「誰かが途中まで書いた抽象画を、その意図通りに完成させろ」と言われているのに近いところがあり、「この変数はなんのためにあるのか」「この処理は一体どこでどう使われるのか」などがまったくわからないまま作業を引き継ぐわけです。
誰かが1の工数を費やして作ったものに、1の工数を足しても2にはならず、1.5になるか、悪くすると0.5くらいに減ってしまうことだってあるのです。だからこそ、このITベンダーは当初、コンサルが途中まで作ったものを引き継ぐのではなく、「自分達で最初からやり直したい」と申し出たのです。
「こっから続きやっといて」は無理筋 Photo: Adobe Stock
「無知の無知」は身を滅ぼす
しかし、発注者企業の経営層は、こうしたITシステム開発の特性を知らず「1＋1は2になるはずだろう！」と、ベンダーの申し出を却下しました。「ベンダーに最初からやり直させたら、コストが1＋2＝3になってしまう」というサンクコスト（埋没費用）の思考があったのでしょう。しかし、その結果は、おそらく3以上のコストがかかった挙句の裁判沙汰です。
経営層の人間達は、システム開発に関して必要な知識がなく、作業者を途中で変更することの危険も予測できずに「No」と言ってしまった。知らなければ知らないで、誰かに客観的な意見を求めるなどするべきだったところを、それ自体行わなかったということは、発注者として自分達に欠けたるモノがあるということ自体を知らない、つまり、ソクラテスの言う「無知の知」ならぬ「無知の無知」だったということでしょう。
実際のところ、「システム開発に関する作業をどこかの会社に頼んだけど、その働きが期待を下回るので途中交代させたい」と考えることは、よくあることです。そういう時には、まず作りかけのドキュメントは諦め、「一応出来上がった」とされるものについても、第三者に見せて理解可能であるか、誤りがないかをよくよく見ることでしょう。
そして、それよりも最も安全なのは、時間とお金がかかりますが、新しいベンダーに最初から作り直してもらうことだというのが、私の数多くの訴訟案件に携わった経験から言えるレコメンデーションです。
『システムを「外注」するときに読む本』では、発注者企業が、ＩＴベンダーに発注する前に最低限の知識を得て、トラブルを回避してプロジェクトを成功させるためのポイントを凝縮しています。是非ご一読され、使い倒し、貴社のプロジェクトの成功に寄与できることを心より願っています。
