かつて、私がコンサルタントとしてベンダー企業を支援していたとき、世界的に有名で、かつ外注の品質に厳しいことで有名な自動車会社（どの会社かすぐにわかってしまったかもしれませんが）に開発プロジェクトを実施したことがありました。
実は当時、このベンダー企業は非常に忙しく、主要なメンバーは、他のプロジェクトとの掛け持ちになっていたのです。掛け持ちの場合、それぞれのプロジェクトが予定通りに進んでいればよいのですが、どちらかがトラブルになると、もう一方への影響は不可避です。トラブル対応に時間がかかれば、もう一方の作業が遅れることもあるということです。
私は、ベンダー側のプロジェクトマネージャーに、そのことをリスクとして発注者に提起するよう伝えました。そして、そのプロジェクトマネージャーは、それを躊躇しました。「こちらの都合で作業が遅れる危険があることなど、お客様の反応を考えれば非常に言い出しにくいことだ」と言うのです。
気持ちはよくわかります。それでも私は強硬に、そのリスクを発注者に対して開示させました。そしてその時、その自動車会社が口にした言葉は、今でもよく覚えています。
「これで、おたくも、本当の意味でウチのパートナーになったね」
自らのリスクを提示してこそ、本当のチームであり、パートナーだと言ったのです。
もちろん、発注者としてこれほどすんなりと受け入れるのは難しいかもしれませんが、やはり、ベンダーは言うべきことを言い、発注者には、それを受け止める度量が必要なのです。
ベンダーには頼まれた仕事を完遂させる責任があります。しかし、それを全うするために必要なことを、すべて自分たちだけで行なう必要はなく、発注者の協力を仰ぐべきなのです。
システム開発プロジェクトにおいて、「責任分担」と「役割分担」は必ずしも一致しないのです。
経済産業省CIO補佐官。ITプロセスコンサルタント。立教大学経済学部経済学科卒。元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員。大学卒業後、NECソフト株式会社（現NECソリューションイノベータ株式会社）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エム株式会社にて、システム開発・運用の品質向上を中心に、多くのITベンダと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行なう一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。
これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は9割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年より経済産業省の政府CIO補佐官に抜擢され、政府系機関システムのアドバイザー業務に携わる。著書に『システムを「外注」するときに読む本』（ダイヤモンド社）、『なぜ、システム開発は必ずモメるのか！』『モメないプロジェクト管理77の鉄則』（ともに日本実業出版社）、『プロジェクトの失敗はだれのせい？』『成功するシステム開発は裁判に学べ！』（ともに技術評論社）などがある。
