この記事は 開発でチャレンジして、失敗・成功したことをシェアしよう by 転職ドラフト Advent Calendar 2024 のシリーズ 2 21日目の記事です。
私からは0→1プロダクトを1年超作り続けたことについて、その失敗と成功について語ります。
自社プロダクトやりたいと思っている未経験エンジニアの方、スタートアップに興味があるエンジニアの方、新規事業担当のプロダクトマネージャー・プロジェクトマネージャー、経営者（CEO、CTO）が読者対象です。
MVPは存在しないかもしれないを念頭に置く
当事者がイメージできないプロダクトを当事者たちが作れるわけないという話です。加えて顧客の「あったらいいね」もたいして価値がないかもしれません。
それに顧客と見込んだ人も、自分たちの状況を正しく把握できてなくて適当に回答してる可能性もあります。
まずはプロダクトを自分ごととして100%信じるか、特定の顧客と徹底的に会話して100％誰かに刺さるプロダクトをMVPにしましょう。
失敗パターン1: 過大な課題への挑戦😭
顧客と会話してもMVPできなかった失敗談としてはダイニーさんの事例がありました。
ダイニーさんの場合は「行政・公共という大きなマーケットは自分たちだけじゃどうにもできない部分があったので、自分たちが自分ごととして取り組めるプロダクトをその後数ヶ月でリリースした」という内容です。
失敗パターン2: ユーザー置き去りのオレオレ仕様😱
逆のパターンとして「俺たちの考えた最強のXX」が受け入れられないパターンもあります。
例えば本格1人RPGスマホゲームのアナザーエデンの初期開発がそうでした。
以下の発表の後半で言及されているとおり「自分たちが作った最高のバトルシステムに対して、ユーザーからコレジャナイと言われたのでユーザー投票で決めてもらった。その結果をそのまま採用し、作り直した」という流れです。
これらから言えることは以下です。
- 自分が信じられる課題に集中する
- 「本当にMVPとして検証したい課題」とは
- これは絶対に自分が解決したいこと
- 一番簡単に検証する方法を考える
- ユーザー投票、既存サービスの利用、手作業など
- 顧客と深く対話し、本当に刺さる価値を見つける
- フィードバックを柔軟に反映する
特に最後については「こう決めたんだから」という思考回路に陥ると、本当の価値を見失いがちです。かといって「やっぱこうかも……」とフワフワし続けるのも問題です。難しいところです。
温度差は軋轢を生む。鉄は熱いうちに打つ&伝搬させる
pmconf2024でも登壇のあった他社の事例からの内容です。
PMやプロダクトの責任者が孤独に一生懸命立ち回っても「そもそも論」や「あの人が勝手にやってるし」という感じでプロダクト作りの空気が悪くなっていく現象に覚えがある方もいるのではないでしょうか。
この話はフォロワーシップとも似ている部分はあります。リーダーは1人の強烈なファンを作り、そこから横展開させていくことが重要といわれています。
また、次章で詳細は書きますが鉄は熱いうちに打つのが大事です。同人ゲーム・同人誌や一般書籍などを会社や人脈を通じて知り合った仲間と共同で作るときと、学生時代から慣れ親しんだ仲間と作るのとでは雲泥の差があります。これはおそらく 熱量と信頼度 に影響されるものだと私は思ってます。
なので、熱が冷めないうちに 「とりあえずの完成形」 を目指しましょう。そしてそれを次の完成形へと更新し続けていきましょう。
失敗するなら2週間。夢を見るなら3年
MVPが存在しないかもしれない、間違えてるかもしれない。熱が冷めるかもしれない、本当に作るべきものがこれなのかわからなくなってきた……という情熱の火が消える瞬間はどのようなチームにもやってきますし、個人単位でタイミングは異なります。
これをなるべく同期的に問題としてあぶり出し、改善として取り組むための仕組みを2週間で設定する方法こそスクラムやXP、カンバンなどのアジャイル開発です。
2週間という単位が明確に必要かどうかは場合によりますが、少なくともエンジニアリング側と事業側という役割の分担があるのであればそこは2週間と言わず毎日でも同期したほうが良いと思います。
また、夢（ビジョン）は数ヶ月先と言わず数年先を見据えて語り合ったほうがモチベーションも高まりますし、自分たちの登る山（プロダクト開発）の全体像を把握したうえで「今どの位置にいるのか」をイメージできます。そうしないと、眼の前の断崖絶壁を回避して登るという選択肢を取れなくなるし、あと1時間もしないうちに頂上なのに、傾斜のゆるい砂利道でテントを貼って休んでしまおうと考えてしまいます。
数年先、3年くらいの夢と「こうありたい」世界を共有し続けましょう。
「今までこれでできたから問題ない」を疑え
今と昔はチームやプロダクト、置かれた立場もぜんぜん違うことが多いです。
0→1フェーズでは「今までよりこれから」を考えられる効果測定を検討したほうが健全です。
例えばベロシティ。例えば見積もりと工数の差分、日々のPR数、コーディング量の偏り、ドキュメントの増加数、ミーティングでの有益な議論の時間・数など、Four Keysみたいにかっちりしたものでなくともそのへんに大量に変数は転がってます。
「汝自身を知れ」と昔の哲学者も言ってます。
「これで昔できたし」とか「これが普通でしょ」という会話が議論中に出始めたら、一旦0ベースで議論できるように立て直すファシリテーション力も必要かもしれません。
0→1はほぼトップダウンで進めてOK
ベン・ホロウィッツ氏の「HARD THINGS」にも記載がある通り、0→1フェーズはスピードと集中との狭間にあるようなものと捉えると、「戦時のCEO」のほうが適用されやすいと個人的に思います。
記事中のCEOくらい暴れる必要はないかもしれませんが、意思決定が鈍りそうなとき、なんだか結論が分からんときなどお、誰かが盛大なダメージを追うにしても決めるところは決めるのが役職者の仕事となるでしょう。
もちろんメンバー側もこれを必要な痛み（成長痛）として捉え、口じゃなく手と頭と体を動かして切り替える敏しょう性は必要です。
別にすべてをCEOが決めるという必要もなく、むしろ 「決める人を決める」 ということも最初にやってたほうが良いと思います。
相反する役割を兼務させない（決定権だけ渡す）
例えばエンジニアが経営数値もやってるパターンをイメージしてください。それぞれの目標設定はほぼ利益相反します。
エンジニアを販管費や売上原価と捉えたら、エンジニアの稼働はコストになりますので、経営としてはなるべく抑えたいものになります。
逆に研究開発費やソフトウェア開発の費用を資産計上すると、経営としては投資と判断できるのですが、この場合はエンジニア側に多大な責任が発生します。「すまん、やっぱできんかったわ」は許されません。ストレスに弱いエンジニア（または経営に興味がないエンジニア）はここで脱落します。
このような反目する物事の狭間で担当者が心を病まないようにするため、相反する役割は兼務させないことが大切です。これはエンジニアリング内での役割も同じです。たとえばデザインとフロントエンド、バックエンドとインフラみたいな部分。前者はデザインとコンポーネントの概念を考えるうえでどうしても競合しがち。後者は実装にインフラが引きずられたり、逆だったりする場合が多いと個人的に感じます。
「そんなこと言っても人が足りないねん……」という場合は、主担当・副担当を分けて相互評価させると良いでしょう。このパターンだとお互いのコミュニケーションも発生するので、相互理解と合意形成も進みます。
「副担当って結局兼務じゃないの？」と思われるかもですが、兼務と違うのは決定権が主担当、方向性の決定には副担当にも責任があるという点です。小さなスタートアップの0→1では全員が何かしらの役割の副担当という可能性も普通にあり得る話です。
「知らない」を放置しない
0→1のプロダクトは誰も答えを知らないことが当たり前です。お互いを補完・支援しあえる関係性を作ることが大切です。「知らないから一緒に考えよう」という姿勢で、 「私は知ってるけどあの人は知らない」 をなくすことも重要です。
知をチームに周知・共有する方法としてドキュメントを書くことがあると思います。しかし「ドキュメント書いてる時間があるなら実装したい・企画したい・要件定義したい」という場面もかなり遭遇しますし、「ドキュメントめっちゃ詳細に書いたのに要件変わって意味なし。終了！」という場面も多いと思います。
このような場合は 「わからないとこだけ、決まったことだけを一緒に書く」 というのが良いと思います。
ただし、それらを書いて満足しないようにしましょう。0→1フェーズはみんな忙しいので、1度では伝わらない・忘れることもあります。覚えてもらうまで何度も繰り返し伝え続ける。伝えられた側も感謝する。このギブアンドテイクがなにより大事です！
ここからは技術的なエンジニアリングの話です。全体の話と重複する部分もあると思いますが、大目に見てください。。。
初期の技術レベルはチームの上限に合わせず、中の下に設定する
技術的なチャレンジ枠を残しておくことはパッションを継続させるために必要かもしれませんが、それでプロダクトのロードマップに影響が出ては本末転倒です。
参加メンバーの技術レベル（プログラミングスキル、モデリングスキル、アーキテクチャの理解など）を計測したうえで、それぞれの中央値と平均値で最も低いレベルに合わせるほうが良いと個人的には思います。
歴史は証明しています。大抵はPMFあたりで「負荷に耐えられないのでリファクタリングします」「このままでは技術的負債が貯まるのでアップデートが必要です」となってリアーキテクチャプロジェクトが立ち上がるので遠慮なく速度と品質を確保できる技術レベルを選定しましょう。
もちろん最初から高いレベルで技術が組み込まれているほうが望ましいですが、理想は理想です。割り切りましょう。
やらない勇気を持つ
エンジニアだと課題やバグが出てきたときそれを解決・解消しようと思って頑張りすぎることがあいります。「木を見て森を見ず」というように、眼前の課題やバグに集中していると本来やるべきだったプロダクト開発が停滞してしまうということもあります。
0→1フェーズでは実装した要件が明日には「この仕様はなかったことに」となることもあるし、汎用化したオブジェクト・コンポーネントが「UI・処理フロー変えます」となることも多々あります。
まずは課題とバグだけを起票し、スプリント内（週1、隔週など）のミーティングや事業全体のミーティング内で都度優先度と対応方針を共有・スケジュール調整という風に、全体最適とチーム開発を優先する割り切りが重要です。
「優先度高くやる課題」となったときにのみ、覚悟を持ってやり切りましょう。
また、課題やバグ対応と同様に、実装内容についても「やらない勇気」は必要です。
わかりやすい例だと「これ何度も同じこと書いてるから共通ロジックにしてしまおう」とか「ドメインとして同じ内容っぽいから共通コンポーネントにしてしまおう」というやつです。
個人的には共通化はロジックのみに抑えるほうが無難で、後者のドメイン部分は放置するほうが良いと思ってます。
なぜなら0→1プロダクトの場合、プロダクトで作り込んだドメインは、おそらくリリース後ユーザーフィードバックを受けたり実際の業務プロセスの変更と突合したりしたときに、初めて「これじゃない」が明確になると思うからです。
設計と実装はある程度相互レビューする
スピードを優先させたいからと「これ見といてください」というメッセージをサラッとコミュニケーションツールやPull Requestでメンション飛ばすだけという場面、あるあるじゃないでしょうか。
0→1フェーズではこれを極力やめたほうがよいです。前述通り「あの人がやってることはあの人の担当だからあとは知らん」という自己マインドになりやすいためです。
たとえ時間がないとしても、週1か毎日どこかで同期を取るタイミングを作りましょう。お互いを励まし合う、お互いを貢献し合うこともこの時間に実施することができます。
「ある程度」と前置きしているのも前述通り0→1フェーズだと議論やフィードバックの流れで仕様変更の発生が普通にありえるからです。全体の方向性と決定事項、TODOくらいを連携する感じで、あとは「お互い頑張ってるよな、いい感じだからこのまま波を乗り切ろう」という気持ちの面での同期を図るというのが理想だと考えてます。
仕事量の調整 も相互レビューで対応すべき点かもしれません。0ベースで設計・実装を進めていると途中で「思った以上に難解で考え直したほうが良さそう」というのもよく発生します。
その後の解決や方針決定についてすべてを当人に任せてしまうと、そこがプロダクトリリースのボトルネックになる場合もよくあります。できるだけ早いタイミングで検知・解決できるようにするためにも、日々の相互レビューは重要です。
お金がない前提でアーキテクチャを考える
初期フェーズのランニングコストは馬鹿になりません。SSOしたい、監視を強化をしたい、クラウド使いたいからといって最初から他社サービスをぶっこんでしまうとそれにロックインされた状態が長く続くことになります。
従量課金のサービスの場合、思った以上に費用がかさむということも発生します。
自分たちのプロダクトで「これは自社開発する必要ない」とか「これは判断を後に遅らせても大丈夫」、「規模が大きくなったときリプレースできそう」という判断軸を作っておくことは大事です。
いちばん簡単な指標はやはり お金 です。例えば「月1万円以内で開発と本番環境を並行稼働できるか」というような指標を作り、まずはお金を基準に開発のデリバリーコストや保守性を考慮していくと良いと思います。
使うライブラリ（OSS）を制限する
アーキテクチャ選定と同じように、ライブラリ（OSS)も最初から大量投入するよりはプロダクトに必要十分なものを逐一選択するほうが無難だと思います。
というのもOSSは頻繁にアップデートされますし、Githubスターの少ないものは開発者・コントリビューターのモチベーション次第で停滞・更新終了となる場面もあります。
そうなると初期フェーズで大量投入したライブラリに依存したコードをすべて修正・リプレースする必要が出てきます。加えて多くのライブラリのバージョンアップにも追随していかなければなりません。
できる限り絞り込みましょう。
例）
- 状態管理はRecoil「だけ」を使う
- フォームはreact-hook-formでなんとかする
- Date型はdayjsのみで管理する
- ライブラリ入れるときは一言共有してみんなのレビューする
アーキテクチャを決める・理解し合う
ここまで何度も擦り切れるほど述べてますが、チーム全体で使うアーキテクチャについても合意と理解し合いましょう（決定権は誰か1人が握っていても問題ないです）。
アーキテクチャを合意しておかないと「バックエンドはREST API前提で作ってるけど、なんかフロントエンドはGraphQLとか聞いてないんだけど？BFF作るの？」とか、「スキーマ定義はDB設計も含むのでバックエンドで巻き取ろうと思ってるけど、フロントエンドでPrisma使い始めてる……」とかいう状況になり得ます。
また、「よくわからんけど選んだ人に任せちゃお」という状況も起きてしまいがちなので、勉強会やコードリードする会みたいに選定技術についてチームで学ぶ機会を設けたり、外部講師や外部講演、外部イベントにみんなで参加したりという施策も有効です。
できない理由ではなく「どうすればよいか」を考える
エンジニアは「できない・やらない理由」より「どうすればできるか、何を捨てれば可能か」を考えましょう。ちょっとした要件の変更や「できません」「やれません」を連呼すると空気がとても悪くなります。不確実性が高い0→1フェーズでは、できない理由よりもどうすればできるかを提案できるスキルを普段以上に求められる気がします。
実装のアルゴリズム・モデリングや課題の山で頭がパンクしそうなくらい悩んでいる状態だとは思いますが、「今は深く考えなくても問題のない方針を探す」というのもすごく重要です。
そしてここでの判断は、将来の技術的負債や現在〜未来の生産性とのトレードオフになる場合もありますのですごく難しい部分です。
この記事がどこかのプロジェクトが同じ道を辿らない他山の石となれば幸いです！
参考書籍やイベント：