休日返上で頑張ります！→頑張れませんでした――残酷な発注者にならないために、ユーザー企業が押さえるべきポイントとは：夏休みSpecial 山本一郎×細川義洋対談 発注残酷物語（3/4 ページ）
「開発残酷物語」の夏休みSpecial、今回は「発注残酷物語」と題して、残酷なプロジェクトを生み出さないために発注者（ユーザー企業）が気を付けるポイントを、山本、細川両氏に語っていただいた。
ユーザー企業側が押さえるべきポイント
では、要件定義をしっかりと行い、自社のシステム開発を成功させるために、発注側であるユーザー企業は、どのようなポイントを具体的に押さえておけばよいのだろうか。
前述の細川氏がコンサルタントとして参加している企業では、各ユーザー部門、情報システム部門、コンサルタント、ベンダーの担当者が一堂に会して、要件定義の段階で「ウォークスルー」を行っているそうだ。
「この画面にデータを入力する人は、どんなスキルレベルにあるのか、この画面には同時に何人のユーザーがアクセスする可能性があるかなど、紙に描いたシステム構成図に、要件で気になるところがあれば付箋を貼っていく。元の絵が見えなくなるぐらいやる」（細川氏）
そして要件定義の段階で、貼った付箋の気になるところを徹底的に解決していくのだ。
「地雷原で地雷を一つ一つ除去していく感じですね」（山本氏）
2週間ぐらい、1日丸まるつぶして、集まっては話してを繰り返していく。ただし「集めるのは職場のキーになる人でなければならない」と細川氏は強調する。
「とあるプロジェクトでメンバーを集めたら、最初は各職場の暇な人ばかりが集まって来た（笑）。社長が『何で、このメンバーなんだ、中心メンバーを集めろ！！！』と一喝し、ようやくちゃんとした人が集まったんです」（細川氏）
「ただし、中心メンバーではないと社長に言われてしまった社員には同情を禁じ得ませんね」（山本氏）
要件定義で各部門の中心人物を集められるかどうかが、システム開発の成否を握っている。システム開発にかかわる業務はユーザー企業の社員にとって、どうしても本業の合間に行う「ついで仕事」として位置付けられがちだ。しかし、システム開発の成否がその後の会社の命運を大きく左右することもある。システム開発プロジェクトは本業と同じぐらい価値を生み出す仕事だということを認識しておくべきだ。
細川氏がコンサルを務める従業員500人規模の企業では、社長がそこをしっかりと理解しており、システム開発プロジェクトを成功させることを人事上の評価項目にも組み入れ、さらにボーナスに反映させる仕組みを作った。こうした処遇が、実は大切だ。
休日返上で頑張ります！→頑張れませんでした
そして「ユーザーとベンダーはワンチーム」という気持ちを持つことも大切だと細川氏は語る。
「あるプロジェクトで、ベンダーから『担当者が1人、病気で1週間ほど休みます』と連絡が入り、ユーザーの担当者が『そうですか、それは大変ですね。頑張ってください』と応じたんです。いや、それは違うでしょう（笑）。チームのメンバーが病気で休むというのは一大事ですよ」（細川氏）
その後、休んでいたベンダー担当者は復帰したが、スケジュールは1週間分遅れている。そこでベンダーから「土日も出勤して頑張りますから」と申し出があり、ユーザーは何となく納得してしまう。
「普通なら、病み上がりの人を休日返上で働かせても大丈夫なの？ と心配になりますよね」（山本氏）
「ユーザー企業はあまり考えていないと思います。ベンダーも『後は俺たちが裏で頑張るしかない』と考えている。本当はユーザーへの作業分担、例えばテストデータ作成をお願いするなど、いろいろあるはずなのですが……」（細川氏）
そうして、「お任せください」→「頑張ります」→「頑張ります……」→「やっぱりダメでした」という典型的な失敗パターンに陥ってしまう。プロジェクトの雲行きが怪しくなり始めたら、できる限り早い段階で状況を共有し、お互いに対策を練ることで、少なくとも訴訟沙汰になることは避けられるはずなのに。
「本来ならば『Earned Value Management上のSPI（※）が1.1です』『0.9です』といった客観的な指針がある。でもベンダーは、ユーザーからの求めがなければ、そうした数字があっても教えません。ユーザーは、そうした数字をきちんと把握しておくことも大切です」（細川氏）
ベンダー、ユーザー両者が数字で定量的、客観的に状況を把握すれば、適正値に戻すにはどうすれば良いのかを冷静に「判断」できるし、責任のなすり合いや感情論になりにくくなるといった効果があるという。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
RubyやPythonができるからって何？――エンジニアがパーツに成り下がらずに生き残る方法
＠ITの人気連載「開発残酷物語」の山本一郎氏と、「IT訴訟徹底解説」の細川義洋氏がエンジニアのキャリアについて、超真剣に話し合った
最低限の知識も理解もないユーザーと渡り合うには？
「出荷管理をシステムを発注したにもかかわらず、勘定科目を把握していない」「意見を社内でまとめず、五月雨式に投げてくる」「モックを本番と勘違い」――こんなユーザー、あなたならどうする？
ユーザーが資料をくれないのは、ベンダーの責任です
ユーザーが要件定義に必要な資料を提供しなかったため、システム開発が頓挫した。責任を取るべきはユーザー、ベンダー、どちらでしょう？
ソクラテスになれ――無知なユーザーとの仕事の進め方
ユーザーの知識が不足していたり、担当者が十分な引き継ぎもなく交代したりするのは、ままあることだ。それでもプロジェクトを成功に導くために、ベンダーは何をすべきだろうか？
ベンダーよ、シェルパの屍を越えていけ 〜 細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか？」
リスペクトなきプロジェクトには死が待っている―― 山本一郎さん（やまもといちろう a.k.a.切込隊長）と、東京地方裁判所 民事調停委員 細川義洋さんによるDevelopers Summit 2014の最終セッションは、雪の寒さとは違う意味で会場を震え上がらせた