休日返上で頑張ります！→頑張れませんでした――残酷な発注者にならないために、ユーザー企業が押さえるべきポイントとは：夏休みSpecial 山本一郎×細川義洋対談 発注残酷物語（3/4 ページ）

ユーザー企業側が押さえるべきポイント

　では、要件定義をしっかりと行い、自社のシステム開発を成功させるために、発注側であるユーザー企業は、どのようなポイントを具体的に押さえておけばよいのだろうか。

　前述の細川氏がコンサルタントとして参加している企業では、各ユーザー部門、情報システム部門、コンサルタント、ベンダーの担当者が一堂に会して、要件定義の段階で「ウォークスルー」を行っているそうだ。

　「この画面にデータを入力する人は、どんなスキルレベルにあるのか、この画面には同時に何人のユーザーがアクセスする可能性があるかなど、紙に描いたシステム構成図に、要件で気になるところがあれば付箋を貼っていく。元の絵が見えなくなるぐらいやる」（細川氏）

　そして要件定義の段階で、貼った付箋の気になるところを徹底的に解決していくのだ。

　「地雷原で地雷を一つ一つ除去していく感じですね」（山本氏）

　2週間ぐらい、1日丸まるつぶして、集まっては話してを繰り返していく。ただし「集めるのは職場のキーになる人でなければならない」と細川氏は強調する。

　「とあるプロジェクトでメンバーを集めたら、最初は各職場の暇な人ばかりが集まって来た（笑）。社長が『何で、このメンバーなんだ、中心メンバーを集めろ！！！』と一喝し、ようやくちゃんとした人が集まったんです」（細川氏）

　「ただし、中心メンバーではないと社長に言われてしまった社員には同情を禁じ得ませんね」（山本氏）

　要件定義で各部門の中心人物を集められるかどうかが、システム開発の成否を握っている。システム開発にかかわる業務はユーザー企業の社員にとって、どうしても本業の合間に行う「ついで仕事」として位置付けられがちだ。しかし、システム開発の成否がその後の会社の命運を大きく左右することもある。システム開発プロジェクトは本業と同じぐらい価値を生み出す仕事だということを認識しておくべきだ。

　細川氏がコンサルを務める従業員500人規模の企業では、社長がそこをしっかりと理解しており、システム開発プロジェクトを成功させることを人事上の評価項目にも組み入れ、さらにボーナスに反映させる仕組みを作った。こうした処遇が、実は大切だ。

「特別ボーナスも支給したんですよ」（細川氏）「え、マジで！？」（山本氏）

休日返上で頑張ります！→頑張れませんでした

　そして「ユーザーとベンダーはワンチーム」という気持ちを持つことも大切だと細川氏は語る。

　「あるプロジェクトで、ベンダーから『担当者が1人、病気で1週間ほど休みます』と連絡が入り、ユーザーの担当者が『そうですか、それは大変ですね。頑張ってください』と応じたんです。いや、それは違うでしょう（笑）。チームのメンバーが病気で休むというのは一大事ですよ」（細川氏）

　その後、休んでいたベンダー担当者は復帰したが、スケジュールは1週間分遅れている。そこでベンダーから「土日も出勤して頑張りますから」と申し出があり、ユーザーは何となく納得してしまう。

　「普通なら、病み上がりの人を休日返上で働かせても大丈夫なの？　と心配になりますよね」（山本氏）

　「ユーザー企業はあまり考えていないと思います。ベンダーも『後は俺たちが裏で頑張るしかない』と考えている。本当はユーザーへの作業分担、例えばテストデータ作成をお願いするなど、いろいろあるはずなのですが……」（細川氏）

　そうして、「お任せください」→「頑張ります」→「頑張ります……」→「やっぱりダメでした」という典型的な失敗パターンに陥ってしまう。プロジェクトの雲行きが怪しくなり始めたら、できる限り早い段階で状況を共有し、お互いに対策を練ることで、少なくとも訴訟沙汰になることは避けられるはずなのに。

　「本来ならば『Earned Value Management上のSPI（※）が1.1です』『0.9です』といった客観的な指針がある。でもベンダーは、ユーザーからの求めがなければ、そうした数字があっても教えません。ユーザーは、そうした数字をきちんと把握しておくことも大切です」（細川氏）

　ベンダー、ユーザー両者が数字で定量的、客観的に状況を把握すれば、適正値に戻すにはどうすれば良いのかを冷静に「判断」できるし、責任のなすり合いや感情論になりにくくなるといった効果があるという。