Tokyo to Saigon ― デスマーチから抜け出す、たったひとつの方法

ベトナムに会社を作った話は - 1通のメッセージから海を越え、理系男子6人のチームと出会い、まだ仕事のない会社で手探りの日々を過ごす——その顛末は「仕事納めの日の、一通のメッセージ」に書いた。

しかし、私がベトナムでの日々から体験したのは、始め方だけではない。どこで止め、何を終わらせるかを決めることだった。それを突きつけられたのが、これから書く現地案件の一件である。

三度目の現地案件

会社は3倍の大きさになったが、まだ3倍の仕事が来ているわけではない。日本でもベトナムでも、自分たちの力を発揮できる新しいプロジェクトを探して奔走する毎日だった。

そんな中、ベトナム側にメンバーの知り合い伝てで新しい案件の相談が来た。実はこれまでも現地から2件問い合わせがあったのだが、1件は見積もりがフィットせず立ち消え、もう1件はヒアリングのうちに「まずシステムを作るより別の方法でProduct Market Fitを試そう」となり、契約には至らなかった。二度あることは三度あるのか、三度目の正直か——。

顧客はベトナム全土に店舗を展開するリテール企業だった。ヘクターたちの初回打ち合わせの感触は良く、以降はZaloのグループでやり取りが続いた。私もそのグループに入れてもらったが、ベトナム語のメッセージが高速で飛び交い、内容のキャッチアップは不可能。ただ「Cảm ơn anh（ありがとう）」やハートマークが飛び交っているのを見て、いい方向に進んでいるんだろうと見守っていた。

ここに、後から効いてくる落とし穴があった。

ヘクターたちは当初、「まずは小さく、顧客が一番困っている部分だけを解決するものから作りましょう」と提案していた。ところがZaloでやり取りしているうちに、顧客のほうが盛り上がっていったらしい。依頼内容は、どんどん大きなスコープへと膨らんでいった。3〜4週間の打ち合わせを経て要件がまとまった頃には、最初の「小さな一機能」は、フロントエンドもバックエンドもインフラも一から作る、1年がかりの巨大システムになっていた。

オレンジ色の見積書

見積もりで難儀したのは金額だ。私もヘクターもベトナムの相場感がまるでない。海外のクライアントと働いた経験はあっても、ベトナムの顧客から受注するのは初めて。手探りで慎重に開発費を計算し、印刷して会社印を押し、スキャンしてヘクターに送った。

「ちょっと “dark” だね」と返ってきた。光量が足りなかったかと思い、「これ以上明るくすると表の項目名が読みづらいけど、いい？」と聞くと、「オレンジ色は使えない？」と来た。……色が、dark？

どうやらスキャンの品質ではなく、見積書の表のヘッダーがネズミ色なのが味気ない、ということらしい。ベトナムの正式な請求書（レッドインボイス）は模様や黄色が入っていて、日本の表彰状のような華やかさがある。その感覚からすると、確かに私の見積書は素っ気なさすぎた。急いでヘッダーの背景をオレンジに変えて送り直すと、「much better」。文化の違いは、こんな細部に宿る。

見積もりにOKが出たとき、正直「今回も成約まではいかないだろう」と思っていた日本チームは驚いた。契約書は、以前ヘクターと苦労して作った日越二言語の開発委託契約書をベースに用意した。ベトナム人は契約書を本当によく読む。リリース後のサポート費用をどうするか、細かい条件のやり取りが延々と続いた。

そして署名の段になって、もうひとつ「ベトナムらしさ」が現れた。コミッションである。 今回クライアントを紹介してくれた人物に、成約額の1%を支払う商習慣があるという。当然その人も期待している。そういえば、今や1500人規模の開発会社を経営する友人も、創業期は会うたび「いい客を紹介してくれたら売上の一部をお支払いしますよ」と言っていた。あれは大げさでも社交辞令でもなく、ベトナムの商習慣そのものだったのだ。

この案件を受けた狙いは、売上以上に「ベトナムでのつながりを作ること」にあった。コミッションを払えば、その人がまた別の縁を運んでくれるかもしれない。習慣に合わせて払おうと決めた。

二倍

ところが、始まったプロジェクトが、とにかくうまくいかない。

計画よりはるかに多くの人員を割いても、毎月のマイルストーンに届かない。詳しく調べていくと、最初の見積もりの2倍以上の工数がかかることがわかった。

独立して15年、見積もりを誤ることはある。それでも、実工数が2倍を超えたことはなかった。1つのiPhoneアプリなら2倍でもなんとか終わらせられる。だが、フロントもバックもインフラも一から作る1年がかりのシステムが2倍となると、差額を自社の持ち出しで埋めるのは、ほぼ不可能だ。

私にも責任があった。現地クライアントはベトナム語しか話せないので、私はやり取りを現地チームに全部任せてしまっていた。それがいけなかった。間に入っていれば、スコープが膨らんでいく段階で歯止めをかけられたかもしれない。

「機能を極限まで削るしかない」

このとき頭に浮かんだのは、大学時代のある先生の言葉だった。

私は学部生のとき、ソフトウェア工学の研究室にいた。ソフトウェア工学とは、プログラミングのような”作る技術”そのものではなく、要件定義・工数見積もり・品質管理といった、ソフトウェア開発をもう一段メタに捉える学問だ。

選んだ研究室の教授は、学科で唯一、博士も修士も持たない、現場からの叩き上げの人だった。当時の日本のコンピュータエンジニアの最高峰が集まっていたNECで、いくつもの巨大プロジェクトを経験してきた人で、誰も持っていない知恵があった。当時の私は”作る技術”ばかり学びたくて、先生の話をあまり聞いていなかったので、覚えていることは多くない。

ただ、ひとつだけ、ずっと頭に残っている言葉がある。

ソフトウェア開発プロジェクトがデスマーチになったときには、機能を極限まで削るしか、そこから抜け出す方法はない。

人員を追加しても、予算を積んでも、スケジュールを後ろ倒しにしても、抜け出せない。抜け出す道は、削ることだけ。ベトナムの現地案件は、まさに先生が言っていた、その状況だった。

削れない

私はベトナムチームに伝えた。クライアントに現状の問題を包み隠さず伝えること。仕様を削れる箇所がないか、とことん話し合うこと。もちろん、あの先生のセオリーも。

1週間後。状況は改善していなかった。「これ以上、削れるものはない」という説明が返ってきた。

仕様を削るのは、意外にも創造的な作業だ。創造力を働かせれば、思わぬ代案が見つかり、実装コストが何分の1にもなることがある。ただ、それにはクライアントの助けがいる。開発側が「絶対に必要」と思い込んでいるものの中に、「実はこれでも良い」という別案が、クライアント側から出てくることがあるからだ。信頼関係が築けていて、相手の創造力を借りられれば、そこに辿り着ける。だが今回、事情はそうなっていなかった。

次に私は、削る議論は続けつつ、開発費を上げてもらう交渉を頼んだ。しばらくして報告が来た。「開発費を2倍、開発期間も2倍にしてはどうかと提案した」と。

開発期間を2倍にするのは悪手だ。 まさに先生が「期間を延ばしても抜け出せない」と言っていたことに当てはまる。期間はそのままのほうがいい、と助言したが、「エンジニアが疲れているから期間も2倍あったほうがいい」と返ってきた。嫌な予感がした。

しばらくして、クライアントからの回答が届いた。「開発期間は2倍にしてもいいが、予算はそのままにしてほしい」。展開は、さらに悪くなった。

決断

2年間もデスマーチを続けたら、会社は潰れる。

私はここで決断した。このプロジェクトをキャンセルしてもらうよう、先方と交渉してほしい。

まだ始まって2ヶ月半。どうせ終わらせるなら、早いほうが双方のダメージが小さい。突っ込み続ければ、損をするのは作り手だけではない。計画の2倍の規模を当初の予算で作らされる——それは一見クライアントにお得に見えて、実際にはスケジュールも品質も、その後のメンテナンス性も拡張性も崩れる。要件定義や検収の負荷も2倍になる。どちらにとっても得にならない。

「やめる」と決めることは、逃げではない。デスマーチという、誰も幸せにならない未来から、両者を引き剥がす判断だ。

反省会

後日、ホーチミンの行きつけのクラフトビールの店で、あの案件を紹介してくれた男——THさんと、ばったり会うことになった。前夜の飲み会でこの案件の話になり、彼に申し訳ないと口に出したのを聞いたメンバーの一人が、彼を呼んでくれたのだ。

まずはみんなでビールを頼み、乾杯してしばらくして、私は「うまくやれなくてすまなかった」と切り出した。

THは、少し悲しそうな、悔しそうな顔で、ゆっくり話し始めた。 「元々あの人たちが欲しかったのは、すごく小さなシステムだったんだ。なぜあんなに大きな話になってしまったのか、理解できない」 と。

確かに、そうだった。私が最初にヘクターから聞いたのも、システムというより「システムの一機能」のようなものだった。それが初回の顔合わせ以降、Zaloの熱の中でどんどん膨らんでいった。THは言った。元々必要だったのはその小さなものだけで、あとは今あるもので足りていた。なんとか、その小さな要件に抑えられなかったのか、と。

この話を聞いて、私はますます後悔した。最初から、私自身ががっつり間に入って進めていれば。 言葉の壁を理由に現地に任せきりにしたことが、スコープの暴走を止められなかった本当の原因だった。

作り切るとは、終わらせること

新規事業の話は、たいてい「始め方」であふれている。でも、長くプロダクトを作ってきて本当に難しいと感じるのは、始めることではない。どこで削り、何を終わらせ、何を残すかを決めることだ。

アイデアを完成まで運ぶ力は、「何を作らないか」を決める力と、分かちがたく結びついている。スコープが膨らみそうなとき、間に入って歯止めをかける。デスマーチの気配がしたら、始まる前に仕様を削る。それでも削れないなら、受けない、あるいはプロトタイプで区切る。そして、走り出した後でも——潰れる前に、終わらせる。

私たちが「作り切る会社」でいられるのは、最後まで根性で走り抜けるからではない。どこで止めるべきかを、知っているからだ。 ベトナムでの日々は、そのことを、もう一度、私に突きつけた。

——この現地案件の物語には、実はまだ続きがある。反省会からしばらくして、あの男THが、再び別の話を持ってくるのだ。その顛末は、いずれ改めて書きたい。