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

2022年の仕事納めの日、ベトナムの友人から届いた1通のメッセージから、私たちのホーチミンでの挑戦は始まった。やがて直面した現地案件の頓挫と、大学時代の先生が遺した「機能を極限まで削るしかない」という言葉。プロジェクトを終わらせる・削る力について、ベトナムで改めて思い知った話。

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

2022年12月30日。私は大晦日の前日まで働いていた。

社員もパートナーもみんな休みに入っていて、Slackも静かだ。集中してプログラミングに没頭できるな——そう思っていたところに、ベトナムの友人、ヘクターからメッセージが入ってきた。

ヘクターと私は10年前、シリコンバレーの有名なベンチャーキャピタル 500 Startups のアクセラレーションプログラムで出会った。彼はベトナムから選ばれたスタートアップのリードエンジニアで、私は友人のスタートアップに後半だけディベロッパーとして参加していた。プログラマー同士、アジア人同士、テーブルもすぐ近く。すぐに仲良くなった。

そのヘクターからのメッセージは、彼の会社の投資元が破綻し、会社をクローズしなければならなくなった、という知らせだった。ただ彼は、自分のチームの精鋭5人と、これからも一緒に仕事をしたいと考えていた。みんなで開発できる案件があれば、それをやってチームを維持したい。何か案件はないか——と。

私はコロナ前の数年間、ずっとベトナムに会社を作りたいと思っていた。調査をしたり、ベトナム人のインターンを受け入れたりして、そのことはヘクターにも話していた。だから話は一気に進んだ。ベトナムに法人を作り、Goldrush Computing が日本でやっている案件を、海を越えて手分けしてやる体制を作れないか。

仕事納めの日。家に帰ってビールでも飲もうと思っていた私にやってきた、まさかの人生のターニングポイントだった。

500 Startups の Demo Day の後の記念写真。この縁が10年後に再びつながることになるとは

まだ仕事のない会社

即決できたのには理由がある。振り返れば10年も前から、私はベトナムのエンジニアやデザイナーと何度か組んで、「この人たちとはスピード感もコミュニケーションも合う」という手応えを重ねてきていた。いつかホーチミンにオフィスを開いて、彼らと一緒に働きたい。その思いはずっと温めていた。

とはいえ、現地に会社をつくれば仕事が回り出す、なんてことはない。立ち上げの頃は、正直、ベトナムチームがやる新規案件がない状態が続いた。

初めてメンバーと顔を合わせた日のことはよく覚えている。Goldrush は女子ばかりの職場だが、ホーチミンのチームは理系男子×6。その対極みたいなメンツが、オフィスのドアを開けると全員笑顔で出迎えてくれた。

alt text

オフィスにはまだ机しかなくて、みんな家からモニターを持ってきたり、Macを小さな木箱の上に置いて視点を高くして作業していた。法人登記が済むまでは会社が存在しないので、その間に買ったものは経費にできない——だから外付けモニターも私の自腹だ。仕事もまだないから、週1の定例ミーティングには議題もない。若手のLさんが提案した「今まで食べた食べ物で一番ひどかったものは?」なんて質問をみんなで答え合って、英語のスピーキングの練習も兼ねていた。

トンネルの中を手探りで進むような日々。それでも、少しずつ光は見えはじめていた。

現地案件が頓挫する

しばらくして、大きな判断を迫られることになる。

ベトナム現地のクライアントから受注して始めた、大きなプロジェクトがあった。それが、とにかくうまくいかない。計画よりはるかに多くの人員を割いても、毎月のマイルストーンに届かない。詳しく聞いていくと、最初の見積もりの2倍以上の工数がかかることがわかった。

独立して15年この仕事をしてきた私でも、見積もりを誤ることはある。それでも、実際の工数が2倍以上になることはなかった。今回は作るものが大きく、フロントエンドもバックエンドもインフラも一から作る1年がかりのシステムだ。それが2倍となると、こちらが費用を持ち出して穴埋めするのは、とても難しい。

正直に書けば、私にも責任がある。現地クライアントはベトナム語しかできないので、現地に全部任せてしまっていた。それがいけなかった。

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

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

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

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

正直に言うと、当時の私はソフトウェア工学に興味を持てず、“作る技術”の方ばかり学びたくて、先生の話はあまり聞いていなかった。覚えていることも多くない。

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

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

人員を追加しても、予算を積んでも、スケジュールを後ろ倒しにしても、抜け出せない。抜け出す道は、削ることだけ——そういう意味だ。

ベトナムの現地案件は、まさに先生が言っていた、その状況だった。

削る力、終わらせる力

この教えが頭にあったから、私はデスマーチになりそうなプロジェクトに出会うと、始まる前にクライアントと時間をとって話すようにしてきた。仕様を削れないか。もっとシンプルにできないか。分割して、別のフェーズにできないか。

それでも削れないなら——プロジェクトが小さければリスクを取ることもあるが、大きければ、受けるのをお断りしたり、プロトタイプのフェーズだけを担当して、あとは抜けることもある。

冷たく聞こえるかもしれない。でも、デスマーチに突っ込むと、損をするのは作り手だけではない。結局はクライアントにも損をさせてしまう。だから「やらない」「削る」「ここで区切る」と決めることは、相手のためでもある。

新規事業の話は、たいてい「始め方」であふれている。でも、長くプロダクトを作ってきて本当に難しいと感じるのは、始めることではない。どこで削り、何を終わらせ、何を残すかを決めることだ。アイデアを完成まで運ぶ力は、「何を作らないか」を決める力と、分かちがたく結びついている。

ベトナムでの日々は、そのことを、もう一度、私に突きつけた。

―― サイゴンで学んだこの話には、まだ続きがある。その顛末は、いずれ改めて別の記事で書くつもりだ。

#ベトナム#新規事業#完成させる力