休日返上で頑張ります！→頑張れませんでした――残酷な発注者にならないために、ユーザー企業が押さえるべきポイントとは：夏休みSpecial 山本一郎×細川義洋対談 発注残酷物語（1/4 ページ）
「開発残酷物語」の夏休みSpecial、今回は「発注残酷物語」と題して、残酷なプロジェクトを生み出さないために発注者（ユーザー企業）が気を付けるポイントを、山本、細川両氏に語っていただいた。
＠ITの人気連載「開発残酷物語」のナビゲーター山本一郎氏と、「IT訴訟徹底解説」の筆者細川義洋氏が語り合う「開発残酷物語夏休みスペシャル」。第2弾は、発注側であるユーザーと受注側であるベンダーが炎上や訴訟に至らないためにはどうすれば良いのかを、ショッパイ表情で話し合った。
開発残酷物語夏休みスペシャル第1弾 「キャリア残酷物語：RubyやPythonができるからって何？――エンジニアがパーツに成り下がらずに生き残る方法」
細川氏は、NECソフト、日本アイ・ビー・エムでエンジニアやコンサルタントとして活躍した後、日本国内に数十名しかいない、IT事件担当の民事調停委員に推薦され着任。2017年春まで数多くのIT紛争事件の解決に寄与してきた。＠ITでは『「訴えてやる！」の前に読む IT訴訟 徹底解説』『コンサルは見た！ 与信管理システム構築に潜む黒い野望』など、IT紛争回避指南の記事を執筆している。
訴訟に至った悲惨なプロジェクトを数多く目の当たりにしてきた細川氏と、「開発残酷物語」でベンダーへのインタビューを通じてIT業界の「残酷物語」をコレクションしてきた「IT業界のヤコペッティ」こと山本氏。両氏がプロジェクトを成功に導くポイントについて、発注側の立場から考察していく。
よくもめるのは要件定義
さまざまな炎上事例、裁判事例を見てきた細川氏。中には「これってどうなの？」と思えるような、ほんの少し気を付けてさえいれば、もめ事を避けられた事例もたくさんあったはず。そこで山本氏はまず、「ユーザーがベンダーに発注する際、どういうところに力点を置けば良いのか」を細川氏に尋ねた。
「よくもめるのは要件定義ですね。ここは基本的にはユーザーが決めなければいけない」と、細川氏。
しかし、ユーザーに十分なスキルがない、あるいは何をどういう段取りで決めていけば良いのかよく分かっていないというケースは多い。そういう場合はベンダーが、「要件には機能要件と非機能要件がある」、それぞれを定義する際は「こんなことに気を付けなければいけない」などガイドしてあげなければならない、と細川氏はベンダーの役割を説明する。
発注側は、現在の業務の課題を解決するためにシステムを導入したいと考えているはずだ。そのためには、自動化あるいは効率化したい「業務」を洗い出し、整理しなければならない。
職場には、定型の処理もあれば不文律もある。システム化によってワークフローに新たに押し込まなければならない業務や、「ここをはがして、こっちに付け替えなければならない」業務も発生するはずだ。こうした業務は本来、ユーザーが知っていて当然のことだ。
ところが、細川氏は必ずしもそうではないという。
関連記事
RubyやPythonができるからって何？――エンジニアがパーツに成り下がらずに生き残る方法
＠ITの人気連載「開発残酷物語」の山本一郎氏と、「IT訴訟徹底解説」の細川義洋氏がエンジニアのキャリアについて、超真剣に話し合った
最低限の知識も理解もないユーザーと渡り合うには？
「出荷管理をシステムを発注したにもかかわらず、勘定科目を把握していない」「意見を社内でまとめず、五月雨式に投げてくる」「モックを本番と勘違い」――こんなユーザー、あなたならどうする？
ユーザーが資料をくれないのは、ベンダーの責任です
ユーザーが要件定義に必要な資料を提供しなかったため、システム開発が頓挫した。責任を取るべきはユーザー、ベンダー、どちらでしょう？
ソクラテスになれ――無知なユーザーとの仕事の進め方
ユーザーの知識が不足していたり、担当者が十分な引き継ぎもなく交代したりするのは、ままあることだ。それでもプロジェクトを成功に導くために、ベンダーは何をすべきだろうか？
ベンダーよ、シェルパの屍を越えていけ 〜 細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか？」
リスペクトなきプロジェクトには死が待っている―― 山本一郎さん（やまもといちろう a.k.a.切込隊長）と、東京地方裁判所 民事調停委員 細川義洋さんによるDevelopers Summit 2014の最終セッションは、雪の寒さとは違う意味で会場を震え上がらせた
Copyright © ITmedia, Inc. All Rights Reserved.