筆者はITコンサルタントであると同時に、イントリーグという会社の社長を務めて20年になる。以前に、ある中学校で生徒を対象に講演をする機会があった。その時にある生徒から「社長の仕事で一番大事なのは何ですか?」という質問を受けた。それに対して筆者は「決める」ことと回答した。

 「決める」ことはなかなか難しい。判断を下すには情報や知識が必要であるし、結果責任も伴う。だから活力に乏しい、なれ合いの組織では「決める」役割を誰も引き受けたがらず、曖昧なまま物事が進む。それで失敗したとしても、誰も責任を取らない。

 システム構築の現場においても、失敗プロジェクトにおいて同様の現象が見られる。失敗の理由を発注者とベンダー、あるいは発注者内の情報システム部門とエンドユーザーが双方になすり付け合う。それでいて、徹底的に相手に対して責任追及するわけでもなく、双方に都合の良い「落としどころ」を見つけて手打ちにする。

 「大人の対応」と言えばそれまでだが、やはり本質的にはきちんと責任をはっきりさせるべきだろう。その責任というものを突き詰めていくと、必ず「決めるべき時に、きちんと決めたのか」という問題にたどり着く。

 システム構築において「決める」という役割の多くは発注者側にあると認識すべきである。例えば要件定義。要件定義は発注者側の作業であるというのが一般論だが、実際の現場を見るとベンダーに多くを頼っているケースが散見される。それはユーザー側に「要件定義書」を作るスキルが不足しているからである。要件定義を行うことと、要件定義書というドキュメントを作ることは同じではない。業務上の要件を決定することはユーザーにしかできない。ベンダーは定義書という文書の作成支援と、ユーザーが要件を決めやすくするためのファシリテーションなら実施できるが、業務内容を最終的にコミットすることはできない。外部であるベンダーがユーザー側の業務を定義することなどあり得ないはずだ。

ベンダーはユーザーの決定を支援する

 このように書くと至極当たり前のことであるが、現実的にはユーザーが決められないことがとても多い。ユーザーがなかなか決めることができずにスケジュールが遅延する。きちんと決めずに曖昧なまま次工程に進み、やがてテストフェーズでそのツケが回り、問題が噴出し、てんやわんやとなる。そういったトラブルはほとんどすべて決めるべき時にきちんと決めていないことが原因である。繰り返しになるが「決める」のは発注者の仕事なのだ。

 ベンダーは発注者が決断を下すことができるようにするために、提案をする、対案を出す、過去の知見からアドバイスをする、製品情報などを提供する、といった支援を行う。そして「決めた」ことをできる限り正確に実現するようなシステムを作ることが役割である。

 もちろんベンダーにも「何を提案するか」といったことや、進捗遅延が発生した場合の人員計画の見直しなど大事な「決める」べき事柄はたくさんある。発注者とベンダー双方が早め早めにそれぞれの責任範囲の課題を決断できれば、システム構築プロジェクトの成功率は高まるはずだ。

出典:日経SYSTEMS 2016年11月号 p8
記事は執筆時の情報に基づいており、現在では異なる場合があります。