本記事では、かつてない「システム発注者のための入門書」として注目を集め、現在5刷のロングセラー『システムを「外注」するときに読む本』の著者で、経済産業省CIO補佐官の細川義洋氏が、システム開発における「経営者の役割と責任」を、裁判例や実例をベースに問うていきます。
「知識ゼロ」からでも、自社に貢献するＩＴ企画や要件定義ができて、失敗率の高いＩＴ導入を無事成功させることができる実践的な知識とスキルをお伝えしていきます（構成：今野良介）。
失敗プロジェクトの責任は誰にあるのか？
私は、裁判所でIT紛争解決の手伝いをしてきたことから、自身の担当する事件以外でも、さまざまなシステム開発プロジェクトの失敗案件を見聞きしてきました。
その中でも印象的だったものに、ある清涼飲料水メーカーの生産管理システムプロジェクトの破綻に関する紛争がありました。
この清涼飲料水メーカーでは、工場の在庫管理システムの刷新を行おうとシステムベンダに開発を依頼したのですが、発注者であるメーカー側の担当者が、プロジェクト実施中に交代してしまいました。
それだけでもプロジェクトにとって致命的な出来事だったのですが、さらに悪いことに、担当としてやってきた3人の課長はいずれも本社からの異動組で、工場の在庫管理についてまったくと言って良いほど知らなかったのです。
たとえば、原材料の在庫が底をついている状態で、それを上回る所要が発生したとき、この工場ではこれを「マイナス在庫」として記録して管理するのですが、この3人の課長たちは、ベンダからこの管理方法について質問をされたとき、「そんな言葉は知らない。管理する必要もない」と突き返したというのです。「マイナス在庫」という考えはこの工場でも当然に必要な項目であり、それを無視したシステム作りなど出来ないはずのところを、そんな形で押し切ってしまったのです。
これは、明らかに発注者側担当者の知識不足であり、不勉強です。そんな調子ですから、プロジェクトは発注者側の要件定義不備、情報提供不足のために失敗に終わり、それでも費用を払わないとする発注者に対して、ベンダが支払いを求めて裁判になりました。結果は当然、ベンダ側の勝訴です。
正直、ここまでひどい発注者というのは私もあまり見ないのですが、担当者に十分な知識がないために破綻してしまうプロジェクトというのはよくあります。この事件の場合は、自身の会社の業務に関する知識すらなかったことになりますが、これがITに関する知識ともなれば、もっと多くの発注者が知識不足ということになってしまうでしょう。
発注者にどんな知識が必要かということについては、本連載の別の回で説明させていただくとして、少なくとも、たとえば「自分たちが要件を◯月×日までに決めないと、ベンダは納期を守れなくなるだろう」とか、「気軽に画面表示項目を後から付け加えてほしいと言っても、それが実はシステムの大改修に繋がってしまう可能性があるだろう」など、発注者自身の、ベンダー任せで身勝手な振舞いがITプロジェクトに深刻な影響をもたらす可能性があるということくらいは、発注者も理解しておくべきでしょう。その意味で言えば、この事件の発注者企業の3人の課長も、もう少し自社業務のこと、ITプロジェクトのことを勉強しておくべきだったと言えます。
しかし、です。
掛け声だけはデカい。あとは現場に丸投げ。
私の考えを申し上げるなら、悪いのは彼らだけではありません。むしろ、3人の課長も”被害者”と言えるのではないかと思うのです。
ちょっと、彼らの立場に立って考えてみてください。
ある日突然、本社から工場への異動が言い渡された。言ってみたら、よくわからないITの導入をしろと言われ、ベンダからは要件を早々に定義してほしいと言われた。システムのことがよくわからないままもたもたしている間に、どんどんプロジェクトが壊れていき、上司からも「一体どうなっているのか」と責められる中、打ち手も分からない間に契約解除、そして紛争へと移行してしまったわけです。
3人の課長からすれば、「なんで素人の自分達がこんな目に遭わなければいけないのだ！」と、恨み言の一つも言いたくなるでしょう。
では、本当に悪いのは誰なのでしょうか？
端的に申し上げれば、素人同然の彼らにシステムを担当させた経営陣です。
もちろん、彼らをアサインしたこと自体は、さまざまな都合から致し方ないことなのでしょう。しかし、経営陣は彼らにIT開発プロジェクトに参加するに十分なスキル教育をしたでしょうか？ 彼らをバックアップしてくれるユーザ側のIT人材を準備したでしょうか？ あるいは、彼らがシステム作りに十分な意欲を持ち、自ら学習したり、積極的にプロジェクトを動かそうとするような仕組み（業績評価やキャリアパスの明確化など）を作ったでしょうか？
いずれも、応えは「No」であるはずです。経営陣たちは、工場に彼らを異動させ、その時に始まっていたITプロジェクトに彼らの職位だけを理由に担当させ、彼らが知識を得る場も自ら知識を獲得する意欲をもたせる仕組みも作らなかった。そうした、悪い意味での現場任せが、こうした事件を招いたのではないかと、私は思っています。
アジャイル開発やDEVOPSなど、IT導入における「発注者の参加」がこれまでより一層求められるようになった昨今、非IT人材である社員に十分な教育とバックアップ体制を整え、彼らのモチベーションを高める仕組みづくりを行わない企業は、今後の生き残りが難しいのではないでしょうか。そして、それができるのは、各企業のトップだけなのではないでしょうか。
『システムを「外注」するときに読む本』では、発注者企業が、ＩＴベンダーに発注する前に最低限の知識を得て、トラブルを回避してプロジェクトを成功させるためのポイントを凝縮しています。是非ご一読され、使い倒し、貴社のプロジェクトの成功に寄与できることを、心より願っています。
