ベンダーよ、シェルパの屍を越えていけ 〜　細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか？」

　2014年2月14日、関東地方は記録的な大雪に見舞われ、各地で交通機関の混乱が発生した。都内の企業が続々と社員に向けて帰宅勧告を出す中、「Developers Summit 2014」の会場は熱気に包まれていた。

　今年14回目を迎えるDevelopers Summitは、「技術者の、技術者による、技術者のためのカンファレンス」で、最前線の技術者による解説や事例発表が主に行われる。しかし、2014年度の最終セッションは少し他のものとは毛色が違った。「なぜ、システム開発は必ずモメるのか？ プロジェクト見積もりから契約作成まで」と題して、東京地方裁判所の民事調停委員として数々のIT訴訟を担当し、その経験を基に執筆した書籍『なぜ、システム開発は必ずモメるのか？』（日本実業出版社）がベストセラーとなった細川義洋さんと、それを実用書なのに涙が止まらない本と評した、コンテンツ制作会社経営者としてデスマーチ経験豊富（？）な山本一郎さんによる対談が行われたのだ。

　セッション会場ではバンバン飛び出す実社名を燃料に会話がメラメラと燃えあがり、雪の寒さとは違う意味で来場者を震え上がらせた。

ケーキがクッキーに大変身！ 仕様変更の怪

山本一郎さん
イレギュラーズアンドパートナーズ代表取締役、投資家、ブロガー
IT企業勤務を経て、2000年コンテンツ開発企業設立。『ネットビジネスの終わり』（PHP研究所）『情報革命バブルの崩壊』（文藝春秋）など著書多数。三児の父。ヤクルトスワローズファン。

ブログ：やまもといちろうBLOG

　セッションは「炎上を感じさせるキーワード」に沿って、山本一郎さん（以降、山本氏）が細川義洋さん（以降、細川氏）に解説を求める形で進められた。

　最初のキーワードは「追加費用・仕様変更」。開発プロジェクトにおいて、最初に決めた仕様通りに開発が進めば、それほど揉めることはない（はずだ）。しかし、なかなかそうはいかないもので、途中で仕様の変更や追加が頻繁に行われるのはよくある話だ。そして、ここが炎上の発火点となることが多いのは、エンジニアの皆さんならご存じのことだろう。

　山本氏は、ユーザーは仕様変更によって追加で費用が発生することに、そもそも理解がないのではないかと勘繰っている。山本氏が携わるゲーム開発でも、「UIを変更して」「色をちょっと変えて」に始まる、さまざまな要望がプロジェクト開始後も次々と発生するという（山本氏「ユーザーは、かーんたんに言うんですよ」）。それを次々とのんでいるうちに、「その変更は全部変えなければいけない、そのためには増員が必要」となることがままある。その際、ユーザーに追加の費用を要求する言い方や、タイミングはどうなのかを知りたいというのだ。

　それに対する細川氏の答えは「裁判所的には—— あくまでも裁判所的にはですが、『追加費用の発生は、都度、都度、言いなさい』というのが正解です」（会場、小さくどよめく）。

　その「都度」があいまいなのだ、と山本氏は不満そうだ。定期的に進捗（しんちょく）会議を開いていても、それとは別に、メールや開発用ツールなど複数のルートトを介していろいろな人から要求が入るために、優先順位が分からなくなることが多いからだ。

　細川氏はその回避策の1つとして「ベンダーは、プロジェクトが始まる最初の段階で、ユーザーのカウンターパート（窓口）の一本化を要求すること」と話す。裁判でよく問われる「ユーザーの協力義務」には、「ユーザーはその組織内で、意見を収集してまとめ、ベンダー伝える」ということが含まれるから、というのが理由だ。そこで食い下がる山本氏「窓口を一本化してもなお、意見が変わることがあってですね」。

　対外的な窓口があっても、それが決定権がない単なる伝令役にすぎない場合だ。窓口がそんな状態で、かつユーザー側の関係者が多いと、社内から出た要望をその窓口が押さえ切れず、要求仕様が二転三転することも多い。それを何度も繰り返すうちに、「最初はケーキを食べていたはずなのに、いつの間にかクッキーになっていたりするんですよ」（山本氏）。

　細川氏は、トラブルを防ぐためには「根回し」が大切だという。ベンダーは、ユーザーが「ちゃんと決めてくれる」かどうか、そして「誰が本当のキモなのか」を見極める眼力が必要だ。キーマンを見付けて、その顔色を見て、泥臭い根回しを続けなければならない。「開発は、きれいな身体ではできないものです」（細川氏）。

　いざとなったら、現場より上のレイヤーで話をまとめてもらうのも、時にはアリだろう。「銀座や北新地という街は、そういうときのためにあるんですよ」という細川氏の発言には、山本氏も「いい話ですねー」と応答。

　「時間を区切る」のも一つの手段だと細川氏は続ける。「期間と工数を区切って、その範囲内でできること（のみ）をする」と、契約書に盛り込む。そうすることで、仕様変更の無限ループを阻止できる（かもしれない）のだという。

リスペクトなきプロジェクトの先には「死」が待っている

　2つ目のキーワードは「プロジェクトの中断」。ダッチロール状態に陥ってにっちもさっちもいかなくなった場合は、プロジェクトそのものを中断せざるを得ない。その中断を勧告する義務がベンダーにはあるという話だ。

　裁判所は、「ユーザー側は受動的に動くもので、能動的に動くべきなのはベンダーである」（細川氏）という考えだ。「ベンダーは中断勧告を出す義務があるし、やらなければ過失」ということだ。理屈上はそうだ。しかし実際のプロジェクトにおいて、ベンダーは物を作る「義務」はあるが、プロジェクトを中断する「権限」もあることが認知されていないのではないか。

　細川氏は「今のベンダーの状況は、かつてのシェルパに似ている」という。シェルパはヒマラヤ登山などのガイド兼荷物運びとして、現地で雇われる専門職だ。彼らの使命はクライアントである登山家を頂上まで連れていくことだが、その前に「人の命を守る」責任がある。ダメだと判断したときには引き返さなければならない。だが……