見出し画像

「約2年かけた開発を停止」そのときCTOが考えていたこと

スタートアップでは、既存製品とは別の新製品を開発したり、既存製品をリプレースしたりすることは珍しくありません。しかし、その過程で開発スケジュールの大幅な遅れや予想外の市場変化などの困難に直面し、時には開発を中止せざるを得ない状況に陥ることもあります。その際、開発中止の判断基準やタイミングについて悩むCTO・エンジニアの方も多いと聞きます。

そこで今回、スタートアップの各技術領域で働く方同士の交流の場である「GB Tech Meetup」では「プロダクトの『やめ方』」と題した勉強会を開催。「プロダクトをあきらめる」というハードな意思決定を乗り越えたCTOをゲストにお迎えして、トークパートとパネルディスカッションを実施しました。

前編となる本記事では、自身の開発停止の経験を語ってくださった、株式会社HataLuck and Person 執行役員CTO 千葉 茂氏によるトークパートの様子をお伝えします。

千葉 茂:2022年に業務委託として株式会社HataLuck and Personにジョインし技術基盤の選定、開発を担当。2024年1月に執行役員CTOに就任。ヴィンテージギター愛好家。アーキテクチャ設計が好き。

ローンチから2年、新プロダクトに踏み切る

千葉 茂(以下、千葉):HATALUCKの千葉です。新卒でサイバーエージェントに入社し、前職ではHRテックスタートアップでエンジニアをやっていました。HATALUCKには2022年に業務委託として関わり始め、2023年に正社員になりました。現在は執行役員CTOを務めています。

弊社は、飲食などのサービス業の法人向けに「はたLuck」というサービスを提供しています。はたLuckは、店舗の運営に必要な情報共有やシフト管理、マニュアルなどの機能をひとまとめにしたシステムです。店舗で働くシフトワーカーと、企業の本部、店舗をつなぎ、サービス業で働く方たちの労働生産性を高めることを目指しています。

はたLuckは2019年にローンチされたんですが、リリースから2年ほど経ったころに技術的な課題が顕在化してきました。経営陣からも「基盤から作り直した方がいいのでは」という話が出てきたんです。

当時は「既存のプロダクトでは機能が足りず、顧客を獲得しきれていない。このままでは事業計画の達成は難しい」と思い込んでいました。また既存プロダクトでは不具合をなかなか減らせていなかったこともあり、実装がどんどん複雑になってインフラのコストも高くなってしまっていたんです。

こうした課題を解決するために、基盤から作り直した新しいプロダクトを開発し、既存プロダクトから移行していく計画が持ち上がりました。

当初想定していたスケジュールはこちらです。

2021年9月から新プロダクト用の人材採用を始め、翌月から技術選定と要件定義を行い、2022年9月にはお客様向けにクローズドβ版を出す予定でした。その翌年には正式公開して、既存のプロダクトからの移行も始めようと。

技術面では、FlutterやReactなど流行りの技術を積極的に採用しました。

なお、本プロジェクト開始時のチーム体制は社員8名、業務委託のメンバー12名の全20名。業務委託の方はほとんどが月の勤務時間が60時間以内の副業メンバーでした。

3度の遅延、そして開発停止へ

千葉:ロードマップに沿って開発を始めたものの、徐々に問題が発生してきました。途中で遅延が3回も起き、予定していた開発完了の時期になってもリリースの目処が立たない状態になってしまって。

最終的に、これ以上新規プロダクトに投資しきれないと判断し、2023年6月に開発を完全に停止。2021年から約2年かけたプロジェクトをクローズしました。

遅延の要因はいくつか考えられます。

まず、既存プロダクトで解決したい課題をすべて新プロダクトに詰め込もうとしてしまっていました。そもそも新たに獲得したい顧客層のニーズを正しく把握できておらず、適切な開発スコープを設定できていなかった

また要件定義を作りながら同時に全部のレイヤーの開発を進めてしまっていました。そのため設計がなかなか定まらず、開発しながら設計を変更する状況になってしまったことも要因です。

技術面でも難しさがありました。FlutterやGOなどは流行りの技術ではあるんですが、社内に知見のある人材が少なくて。技術のベースを作るのに予想以上に時間がかかってしまいました。

遅延を取り戻すために人員を増やしたんですが、それも裏目に出てしまいました。副業の方も多いチームだったこともあり、バラバラな稼働時間をまとめるマネジメントをやりきれなかったことも反省点です。

「やめる」意思決定のポイント3つ

千葉:プロダクトの開発を止めるという意思決定において、鍵となった観点もお話できればと思います。ポイントは主に3つありました。

1つ目は、投下した資産の回収可能性を考えることです。

今回に関しては、回収可能性はほとんどありませんでした。新プロダクトのソースコードは既存のものとまったく異なる技術で作っていたのでそのまま流用できません。また一番コストがかかっていたのは開発外注費で、業務委託メンバーを残すのも難しい状況でした。

結果、サンクコストは高いものの、泣く泣く捨てるという判断に至りました。

2つ目は、会社を存続させる打ち手を立てることです。

投下資産の回収可能性はほぼゼロという状況で、ただ開発をストップさせるわけにはいきません。なにかしら会社を続けるための代替手段を考える必要があります。

ここで1つポジティブな発見がありました。既存プロダクトの技術基盤を改めて調べてみたところ、思っていたほど悪い状態ではなかったんですね。

実は、新規プロダクトの話が持ち上がった当時、経営陣にエンジニア経験者がおらず、適切な診断ができていませんでした。

そこで改めてfour keys(※開発チームのパフォーマンスを測る指標)なども使って診断した結果、既存プロダクトの課題を解決する機能追加・改善することで開発ROIが良くなるとわかりました。既存プロダクトをアップデートするという方向に会社存続の活路が見出せたわけです。

タイミング良くコロナも収まり、サービス業の市場環境が回復。受注率が上がってきたのも追い風となり、既存プロダクトの改善を推し進められました。

最後のポイントは、ステークホルダーへの説得です。

いくら新規プロダクトの開発を止める合理的な理由があっても、きちんとステークホルダーに納得をしてもらえなければハレーションを生んでしまいます。

導入を検討していただいていたお客様には、新規プロダクトはβ版として説明していたので、開発停止に対する大きな反発はありませんでした。ただ、期待を寄せていただいていたので、歯がゆい気持ちでいっぱいでしたね。

もっとも難しかったのは社内への説明です。技術課題があった既存プロダクトに開発対象が戻ることで、「品質は大丈夫なのか」と不信感が高まっていました。ちゃんと納得してもらえるよう何度も質疑応答の場を設け、品質改善や成長が見込めると丁寧に説明し続けましたね。

HATALUCKが学んだ、プロダクト開発の流儀


千葉:経営陣としての観点と、技術的な観点から、一連の経験を振り返ってみます。

まず、経営の観点では3つの課題がありました。

1つ目は、当初の計画と前提条件が変わっていたことに気づけず、早期に開発を止められなかったことです。本来であれば定期的にチェックポイントや撤退条件を決めて、必要なら計画を停止したり、元に戻れる方法を用意したりしておく必要がありました。

2つ目は、既存プロダクトの課題を浅く捉えすぎていたこと。今後は開発課題を経営陣もしっかり理解して、対策や改善を徹底的に議論する必要があると考えています。

3つ目は、一次情報の仮説が足りなくて、要求スコープが大きくなりすぎたこと。PoC段階であれば、システム開発以外の成果物を出して顧客からフィードバックをもらうようにするという手もあります。システム開発を急ぎすぎず、仮説立てにしっかり向き合うのが大切ですね。

技術的な側面でいうと、技術基盤を全面的に入れ替えるには、資金や開発体制が整っていることが何より大事であると痛感しました。

技術的に引き返せる選択肢を持つことも重要です。たとえば、画面の一部分だけをVueからReactに置き換えたり、SwiftやKotlinのコードベースを活かしてKMPを使ったりして段階的にアプローチするなどですね。

根本的な課題を読み違えないためには、トップダウンの意思決定だけでなく、メンバーからの意見を吸収できる体制も大切だと気づきました。プロダクトのビジョンをしっかり示して、みんなで同じ方向を向いて開発できると良いと思います。

最後に、改めて新規プロダクトの開発と、今回のテーマである「プロダクトのやめ方」のポイントをまとめます。

新規プロダクト開発をやりきるには、圧倒的な熱意を持った人が引っ張っていかなければいけません。そして、既存事業以上にコミットする覚悟が大事です。新規プロダクトが成果を上げるという蓋然性が高まる前に全面的に投資するのではなく、投資可能な期間を考慮する必要もあります。

やめる決断をする際には、計画を見直して再投資の可能性や次の一手を押さえておくと良いです。関係者との期待値の擦り合わせをしっかりと行うために、丁寧なコミュニケーションにつとめる必要もあります。

そして最後は意思決定者がきちんと決めきる必要があります。

実は私は、この新規プロダクトを作るために業務委託でHATALUCKにジョインしました。技術選定や初期設計など0→1の立ち上げを行うメンバーとして参画しましたが、最終的には開発停止の決断も下しました。0から携わった開発をやめるのは辛い決断ではありましたが、必要な行動だったと思っています。

今日この場には開発の意思決定を行うCTOクラスの方も多くいらっしゃっているかと思います。私たちの学びが、少しでも皆さんの参考となっていれば幸いです。ご清聴ありがとうございました。

※後編のレポートはこちら

プロダクト開発に伴う、難しさと醍醐味

プロダクト開発をやめるという、難しい意思決定の経験を語ってくれた千葉氏。しかし今回の話からは、よりよいプロダクトを目指して社内と協働しながら開発を進める醍醐味も感じさせてくれたように思います。

GB Tech Meetupでは今後も、エンジニアの皆さんに向けたキャリアや業務に関する勉強会を開催予定です。ご興味のある方はこちらへご参加いただければ幸いです。

なお本イベントを主催したGBHR株式会社は、独立系VCグローバル・ブレインの子会社であり、スタートアップの人材採用支援を専門に行う企業です。今回のようなイベント開催だけでなく、ネクストキャリアを考える方に向けた無料のキャリア相談サービス「GB Innovators Lounge(GBIL)」も運営しています。

GBILは求職者に対する中長期的な機会の提供を目指しており、ご希望のキャリアや働き方などを伺った上で、300社を超えるスタートアップネットワークから求職者のニーズにマッチした求人のみをご紹介いたします。詳細は公式サイトをご確認ください。