0→1を走り切れるエンジニアは会社の未来を拓く。事業立ち上げで学んだ４つのこと

エンジニアとして技術的な成長は確かに感じる。
でも、自分の仕事が事業成長につながり、会社の利益を生み出している実感が持てない。

新卒3年目の当時の私は、そんな悩みを抱えてベンチャー企業に転職し、新規事業の立ち上げに関わり始めました。
しかし立ち上げは、誰も知らない正解を追い求める日々です。成果が出ないまま走り続けるのは、やっぱり苦しい。

それでも走り切れた経験は、自分のキャリアを確実に前に進めてくれました。 PMFを目指すチームが前に進むにはどうしたらいいのか──過去の自分が欲しかったその答えを、4つの学びとしてまとめます。

【プロフィール】上久保　竜輝（かみくぼ　りゅうき）
東京大学卒業後、ソフトバンク株式会社に新卒で入社。その後、株式会社LabBaseにてソフトウェア開発に従事。フロントエンドからバックエンド、インフラまで幅広く手を動かしながら、0→1フェーズのプロダクト開発を多く経験。2024年4月より株式会社estieに入社。現在はリードエンジニアとして、新規事業立ち上げに参加し、プロダクトの価値最大化のために連携する社内APIや関連システムを巻き込みながら開発を推進している。

目標がチームを導く

前提として何を達成したらPMF (Product Market Fit)したと言えるのか、誰も正解を持っていません。

新規事業立ち上げチームがまず取り組むべきことは、売上の目標を立てることそのものではなく、限られたリソースの中で価値検証を行い、「リソースを投入すれば、売上を伸ばせる」という仮説の蓋然性を高めていくことだと思います。
そしてこれは、特定の職種に閉じず、チーム全員が意識すべきことです。

あるとき、私のチームが来期の開発計画を説明した場で、他チームのマネージャーから「その開発は売上につながるのか？」「そもそも今は何を明らかにしたいのか？」と質問を受けました。ところがそのとき、チーム内で意見がまとまっておらず、はっきりと自信を持って答えることができませんでした。この経験から痛感したのは、目標はまず「今いちばん明らかにすべきこと」を置き、それに対して全員が納得している状態をつくるべきだ、ということです。認識が揃っていれば、目標からブレイクダウンしたアクションをそれぞれで自信を持って実行できます。

PMFを目指すうえで、「成功したかどうか」だけを目標に置いてしまうと、現在地がわからないまま走り続けることになり、消耗しやすくなります。また、他チームが立てた目標をそのまま基準にしても、証明したい仮説が違えば目標も変わるため、うまくいきません。目標はチームの存在理由であり、目標が定まることでチームに活力が生まれ、取り組みと学びが加速していく。私はそう捉えるようになりました。

もちろん、目標は未達成に終わることもあります。しかし、その失敗から学び、次の目標を再設定してまた走り出すサイクルこそが重要です。社内でも過去に、仮説検証の取り組みで得た学びを起点に、次の事業が立ち上がった例を何度も見てきました。
失敗を客観的に判断し、学びとして捉える。悲観的になりすぎるべきではない——それもこのフェーズで得た大きな学びです。

苦しい時こそチームを盛り上げろ

苦しい状況で踏ん張るためには、モメンタムが必要です。

売上につながる前の段階は、どうしても手応えが見えにくい。すると、チームの士気は下がりがちです。

ここで言うモメンタムは、から元気で無理やり乗り切ることでも、苦しい状況から目を逸らすことでもありません。「これから良くなっていきそうだ」という変化の兆しを、チームで感じられている状態だと思っています。

そのために、私が大事だと思うのは次の3つです。

小さな前進をきちんと拾って共有する
メンバーの貢献に対して感謝と称賛を伝える
詰まっていることは1人で抱え込まず、早めに相談して解決する

こうした小さな行動の積み重ねが、個人の動きを変え、チームのモメンタムを作ります。
そして生まれた盛り上がりは、チームの外にも伝播していきます。周りに人が集まり、困りごとがあれば協力してくれる人が現れる。そうした助けが入ることでチームはさらに前進して、目標に近づく——この好循環が回り始めます。（estieでは困っていたら助けてくれる人が本当に多いと日々感じています）

以前の私は、特に3つ目が苦手でした。「これを聞いたら迷惑かな」「自分で解決すべきかな」と考えてしまい、どうしても人に頼るのを躊躇してしまう。
けれど目標に向かって全力で走っていると、そういう悩みは本当につまらないことだと、あるときハッと気づきました。そんなことで悩んでいる時間は、本当にない。

頼ることは甘えではなく、前進するための技術です。そして頼りやすいチームは、頼られる側の余裕も生みます。結果的に、チーム全体がより強くなるのだと学びました。

負債はチームを蝕む

チームでモメンタムを作れても、走り続けるほど別の壁が出てきます。

それが、負債です。

「PMFを目指しているうちは機能開発に集中して、負債の解消は後回しでいい」——よく言われる言葉だし、私も基本的には正しいと思います。立ち上げ期はとにかく価値検証のスピードが重要で、完璧を目指して立ち止まるほうがリスクになることも多いからです。

ただ一方で、立ち上げから時間が経ち、関わる人数が増えてきたプロダクトでは、負債の影響を無視できません。
私のチームも、休止期間を挟みながら3年近くPMFを目指して走ってきました。プロダクトを管理しているレポジトリのContributorは数十人規模になり、異動や退職などメンバーの入れ替わりも経験しました。こうなると負債は「技術的なもの」だけではなくなります。仕様の背景が共有されないまま人が入れ替わることでコンテキストが失われ、属人化が進む。これが本当に、価値検証において大きなハードルになりました。

変更が怖くなる。背景や設計意図の理解に時間が溶ける。影響範囲の確認に手間がかかる。
結果として「試したいのに試せない」「改善したいのに進まない」状態になり、検証のスピードそのものが落ちてしまう。走れば走るほど、チームのエネルギーが別のところに吸われていく感覚がありました。

さらに厄介だったのは、負債を解消しようにもロードマップの都合上、どうしても局所的な改善にスコープを落とさざるを得なかったことです。大きく手を入れたい気持ちはある。でも今それはできない。だから「ここだけ直そう」と部分最適の修正を重ねる。
すると、負債が複雑に絡み合っている分、見落としが起きやすい。実際、負債が原因の取りこぼしから不具合が発生してしまったことも何度もありました。

不具合が起きると、負債解消に対してチームがより慎重になります。「また壊したらどうしよう」「いまは触らないほうが安全では？」という空気が強くなる。そうして負債解消が後ろ倒しになり、さらに負債が積み上がっていく——この悪循環が生まれます。ここは本当に、立ち上げを走り切るうえで痛いポイントでした。

今思うと、勇気を持ってプロダクトを作り直すべきだったタイミングが何度かあったように思います。特に、チーム体制が変わった直後や、再始動したタイミングです。短期的には遠回りに見えても、長期的にはそのほうが早くPMFを達成できたかもしれない。

そして、機能開発よりも優先して取り組むべきだと感じる場面では、それを「なんとなく」ではなく、チームに説明して納得してもらう責務が、私のようなSWEにはあると思っています。

幸い、負債や属人性の課題については組織としても学びが活かされていて、複数のチームが同時に事業立ち上げに挑戦できるように、共通の仕組みや基盤を整える動きが進んでいます。負債が生まれること自体は避けられない。でも、なるべく生まれない仕組みがあるだけで、PMFを目指す開発チームは大きく後押しされます。

チームは次の挑戦へ

めでたくPMFを達成したとして、その次にやるべきことは何でしょうか。

売上の蓋然性が示せたとしても、負債や属人性を抱えたままでは、開発リソースを投入してもスケールしません。また、別の事業立ち上げのためにチームが解散する可能性もあります。私自身、いま関わっているプロダクトに愛着はかなりあります。でも、いつかは離れる時が来るかもしれません。チームが変わって新しく入った人がやってきても、開発が継続されるにはどうしたら良いでしょうか。

それは単に負債を解消しておくことにとどまりません。過去の意思決定の背景や学び、目標を共有して、「このチームで前に進める」と思ってもらうこと。言い換えるなら、次に走る人たちの魂に火をつけることなのではないかと私は思っています。

そしてこれは、1つのチームの話にとどまらないとも感じています。会社全体で複数の新規事業立ち上げを目指すためには、得た学びを組織で共有し、モメンタムが途切れない引き継ぎの仕組みをつくることが欠かせません。熱狂が継続する状態を設計できれば、オーナーシップのバトンは自然に渡っていき、次のチームも自信を持ってスタートを切れるはずです。