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

「開発残酷物語」の夏休みSpecial、今回は「発注残酷物語」と題して、残酷なプロジェクトを生み出さないために発注者（ユーザー企業）が気を付けるポイントを、山本、細川両氏に語っていただいた。

[竹内充彦，＠IT]

　＠ITの人気連載「開発残酷物語」のナビゲーター山本一郎氏と、「IT訴訟徹底解説」の筆者細川義洋氏が語り合う「開発残酷物語夏休みスペシャル」。第2弾は、発注側であるユーザーと受注側であるベンダーが炎上や訴訟に至らないためにはどうすれば良いのかを、ショッパイ表情で話し合った。

開発残酷物語夏休みスペシャル第1弾　「キャリア残酷物語：RubyやPythonができるからって何？――エンジニアがパーツに成り下がらずに生き残る方法」

　細川氏は、NECソフト、日本アイ・ビー・エムでエンジニアやコンサルタントとして活躍した後、日本国内に数十名しかいない、IT事件担当の民事調停委員に推薦され着任。2017年春まで数多くのIT紛争事件の解決に寄与してきた。＠ITでは『「訴えてやる！」の前に読む IT訴訟 徹底解説』『コンサルは見た！　与信管理システム構築に潜む黒い野望』など、IT紛争回避指南の記事を執筆している。

　訴訟に至った悲惨なプロジェクトを数多く目の当たりにしてきた細川氏と、「開発残酷物語」でベンダーへのインタビューを通じてIT業界の「残酷物語」をコレクションしてきた「IT業界のヤコペッティ」こと山本氏。両氏がプロジェクトを成功に導くポイントについて、発注側の立場から考察していく。

残酷ナビゲーター 山本一郎氏（左）、IT訴訟回避請負人 細川義洋氏（右）

よくもめるのは要件定義

　さまざまな炎上事例、裁判事例を見てきた細川氏。中には「これってどうなの？」と思えるような、ほんの少し気を付けてさえいれば、もめ事を避けられた事例もたくさんあったはず。そこで山本氏はまず、「ユーザーがベンダーに発注する際、どういうところに力点を置けば良いのか」を細川氏に尋ねた。

　「よくもめるのは要件定義ですね。ここは基本的にはユーザーが決めなければいけない」と、細川氏。

　しかし、ユーザーに十分なスキルがない、あるいは何をどういう段取りで決めていけば良いのかよく分かっていないというケースは多い。そういう場合はベンダーが、「要件には機能要件と非機能要件がある」、それぞれを定義する際は「こんなことに気を付けなければいけない」などガイドしてあげなければならない、と細川氏はベンダーの役割を説明する。

　発注側は、現在の業務の課題を解決するためにシステムを導入したいと考えているはずだ。そのためには、自動化あるいは効率化したい「業務」を洗い出し、整理しなければならない。

　職場には、定型の処理もあれば不文律もある。システム化によってワークフローに新たに押し込まなければならない業務や、「ここをはがして、こっちに付け替えなければならない」業務も発生するはずだ。こうした業務は本来、ユーザーが知っていて当然のことだ。

　ところが、細川氏は必ずしもそうではないという。

関連記事

• ユーザーが資料をくれないのは、ベンダーの責任です
• ソクラテスになれ――無知なユーザーとの仕事の進め方