アーリーステージスタートアップでプロダクト組織のDay1が始まってからの2ヶ月

これはなにか

メルカリの元CTO, VPoEの @sotarokさんが書いたnote、「レイトステージスタートアップにCTOとして 参画しての10ヶ月」を読んで、今自分が力を入れていかねばと思っている領域にピッタリと沿うトピックだったので、思うところを書いてみた。

note（ノート）
レイトステージスタートアップにCTOとして 参画しての10ヶ月｜Sotaro Karasawa

と、いうわけで今日は CTO っぽいアドベントカレンダー書きます。(この記事はスタフェスアドベントカレンダーのトリです!…

今回もPodcastで副音声を配信しているので、こんな長いポスト読む暇ないという人は是非Podcastで聞いてみてください！

共感が生まれたポイント

ほとんど、このツイートに添付した画像のハイライト部分に集約されているのだけど、共感が高かったこれから特に注力したいと思っているポイントは『事業⊃プロダクト=ビジネス×技術』という構造において、“プロダクト開発をするというファンクションをどう組み込んでいくか”についてです。

ドクターズプライムの状況

ドクターズプライムの状況としては先月、先々月あたりから一人目のエンジニアが組織内部にフルコミットし始めたという状態で、それまでの3年間超の期間を内部にエンジニアがいない状態で来ていたので、ものを作ること、プロダクト開発とはなにでどういう性質があるかといったものづくりをする上でのプロトコルが揃っていないという状態になっていました。

関連する記事
創業から3年半続いたエンジニア0の歴史に幕が降りた

これはなにか これまで創業以来3年半、フルコミットのエンジニア0で副業メンバーに協力してもらいながらやってきていた会社に、待望の正社員エンジニアが入社してくれた喜びを綴るポストである。 ぶっちゃけ内部的にはITスタートアップとは程遠かっ[…]

『創業から3年半続いたエンジニア0の歴史に幕が降りた』というポストにもこれまでについて書いているが、週末起業的に並走していたことの問題点の一つがここで、自分らがフルコミットになっていない状態で、フルタイムのエンジニア採用が出来るわけがないということは火を見るよりも明らかであり、その結果事業はスタートしているが、プロダクトはとにかく薄い状態、技術面に関しての蓄積された積み上げ資産は薄いという状態になっていた。

つまり、上図のような『事業⊃プロダクト=ビジネス×技術』という構造があったときに、技術面の積み上げが薄かったため『事業(100)⊃プロダクト(100)=ビジネス(100)×技術(1)』という感じになっていました。
実際、ビジネス面ではペインドリブンの事業開発を進めてこれており、トラクションを感じられる状態になっており、事業としては進捗が見えていました。

ただ、一方で会社というのは事業だけで成り立っているわけではなくて、その構成要素には組織というファクターも存在しています。

内部にフルタイムのエンジニアがおらず、プロダクト開発のファンクションがビジネス開発のファンクションに比べて発達が弱い状態があったため、会社組織全体として考えたときにプロダクト開発に触れている人数が少なく、ものづくりをするというのはどういうことかというのが、組織全体に伝わりにくかったという経緯があります。

ビジネスと技術はプロダクトと事業の両輪

プロダクトを用いて収益を上げていく事業構造を持っており、プロダクト開発をする組織において、ビジネスと技術はプロダクト・事業の両輪です。
この両輪がバランスを取れていることが大切であり、技術至上主義になっても、ビジネス至上主義になってもいけません。どちらかの力が強すぎる状態は不健康です。

このバランスを組織内で整えていく、相互の理解を促し合う、組織内のプロトコルを揃えていく活動がとても大切です。

自社の状況としては、繰り返しになるけど、組織がプロダクト開発に触れる機会が比較的少なかったことからビジネスにバランスが傾いている（どちらかというとそれ以外を知らないというほうが正しい）状態なので、このpH値のバランスを変えていく、組織における理解の変化を促していくことが今組織系のイシューにおいて自分が最注力すべきところだなと考えています。

足元はのらりくらりとやっていけちゃうのですが、文化を作り変えていくことは相当にカロリーが必要になります。あとになればなるほど両輪の歪みは大きくなり、最終的に車はぐるぐるぐると同じ場所で円を描き続け前進しなくなります。プロダクト開発組織が内部で立ち上がったDay1の今から着手すべきトップイシューだと認識しています。

どういう状態を目指していきたいか

ここに対して、どういう状態を目指していきたいかという話になるのですが、大枠の方針は@sotarokのエントリと合致するし元エントリのほうがわかりやすく整理されているのでそっちを見てもらったほうがわかりやすい気がしますが、大きくは下記かなと考えています。

  1. 不確実性のマネジメント
  2. モノリスな開発プロセス（課題発見→企画・開発→フィードバック）
  3. 相違の共通認識

1. 不確実性のマネジメント

『エンジニアリング組織論への招待』などにも書かれていることなので、いまさら私がどうこういうものではないですが、ものを作っていくプロセスの要諦は「不確実性のマネジメント」です。曖昧な状態から具体的な状態へと変化していくこの状態変化の仕組みを理解してそれをマネジメントすることです。

突き詰めると、これは程度の違いはあれどもプロダクト開発のみならず事業開発も組織開発も同じ話で、この3つはすべて『不確実性のマネジメント』をどうやってうまくやるかというゲームルールです。

最初はどういった結末になるかわからない。見通しは立てられども、それが当初の見通しのまま着地することはほぼありません。これはプロダクト開発においては、スケジュール、機能要求、仕様、顧客の要求、デザイン、全部です。事業計画においてもある程度同じことが言えます。事業立ち上げ当初の見立てのまま事業計画を修正せずに上場までいった会社はあるでしょうか？詳しく知らないですが、多分ないです。

これらすべて不確実性が内包されているものをどうコントロールしてマネジメントするかに尽きます。

事業でもプロダクト開発でもフェーズが進めば進むほど、曖昧で抽象的→具体的に変わっていきます。この当初の想像や妄想が具体で変わっていく過程で歪が生まれます。この歪こそが『不整合』と呼ばれるものです。具体的には、スケジュールが間に合わない、人が足りない、当初想定していた顧客は存在しなかった、求められている機能と自社製品がズレていた… etc 上げだすとキリがないですが、これらはすべて、不確実性のある営みを進めていく上で生みおとされる『不整合』です。この『不整合』に整合性を付けていく活動、これこそが不確実性のマネジメントです。

この仕組の理解を組織全体に広げる必要があります。

前述したように、製品開発、事業開発、組織開発、全部にこの不確実性のマネジメントは存在します。それらの違いは製品開発はそのプロセスに不確実性のマネジメントの重心がよっていて、事業開発にはリザルトにその重心が寄っているという違いでしょうか。

大なり小なりコアは同じなので、伝達プロセス、コミュニケーションの初期設定の工夫で解決できるイシューだと思います。

2. モノリスな開発プロセス

いきなり、1つめでめちゃくちゃ長くなったので、あとはサラッと行きます。ここは @sotarokのポストが特に秀逸なので、私から付け足すことはあまりないですが、一枚岩な開発プロセスを取ることが重要ということです。

課題発見→企画・開発→フィードバック→改善という、プロダクト開発のステップが実態として部署や組織別で切り分かれていて、上から落とすという構図になるとプロダクト開発組織は死にます。人体と同じで末端から壊死していきます。もちろん組織だけじゃなくて、プロダクトも死にます。文字通り動かなくなります。

キモになるのは以下の3点だと考えています。

  • オープンで情報と説明の透明性が高い検討・実行プロセス
  • 最終的な実行の意思決定・主体性をプロダクト組織に付与する
  • 相互の性質の基礎理解

具体で説明していくいと結局@sotarokの元エントリとかぶるので、こちらの秀逸なエントリをごらんください！

note（ノート）
レイトステージスタートアップにCTOとして 参画しての10ヶ月｜Sotaro Karasawa

と、いうわけで今日は CTO っぽいアドベントカレンダー書きます。(この記事はスタフェスアドベントカレンダーのトリです!…

3. 相違の共通認識

モノリスな開発プロセスの大前提になるものなのですが、それぞれの特質としてどういうものがあるのか相互理解が超重要です。不確実性のマネジメントにもつながるのですが、これを欠くと「前に宣言してた見積もり以内に何故終わらない？誰かがパフォーマンス悪かってたってこと？」「2倍の人突っ込めば半分の時間でリリースできる？」とプロダクト開発組織が言われるみたいな地獄が待ち受けます。

逆も然りで、ビジネスを主導するチームに対してプロダクト開発組織から聞こえたりする「なんでまだ出来上がってないものを売ってくるの？」とか「すぐできるって安請け合いするなよ」とかそういう感情も相互理解を諦めた結果の産物です。

どっちが悪いとかは無いです。多分どっちも同じです。大事なのは「顧客/ビジネス/プロダクト/ユーザー」という4つのプレーヤー間の期待値の気圧差をなくすことです。期待値の気圧差が存在するからシワ寄せという事象や認識が発生します。そしてそれは不幸でしか無いです。

顧客とのコミュニケーションにおいても「できる/できない」の二択ではなく両者の理解があれば適切に関係者全員の期待値の気圧差を極力0にしたコミュニケーションが取れます。

このへんもプロダクト組織スタートのDay1から投資を続けていけば防げる事態です。

まとめ

プロダクト開発のファンクションがドクターズプライムという組織に備わったDay1のタイミングがいまだと考えています。
このDay1のタイミングから組織カルチャーへの投資を続けていくことが大事です。

負債が溜まっているのでは？という見られ方をされることが多いことがこの前のポストで書いたアンケートでわかったのですが、実態はどちらかというと技術的な負債も資産もうっすーくしかなくて、極論すると負債も資産もこれから作ってくに近い状態らしいです。

プロダクトとしてもプロダクト組織としてもDay1、ビジネス面としての積み上がりは大きいという状態で、ITスタートアップには珍しくプロダクトでの伸びしろが120%残されている環境です。ITスタートアップにおいてはプロダクトは素晴らしいがビジネスが弱いため、ビジネスサイドの伸びしろは大きいが、プロダクト・技術面での伸びしろはそんなに大きくないというケースのほうが比較的多いと思います。

掘れば金脈が見つかり触れば伸びる、技術面での鉱脈が眠る未開拓の荒野があり、技術で事業を伸ばせる幅が大きいスタートアップは珍しいと思うので、興味を持っていただいた方は是非Twitterからでも、リクルートページからでも、カジュアルにお話させてください！

※最後は宣伝
※勢いで書いていたらめちゃくちゃ長くなりました

参考文献

Twitterもやっています。よかったらフォローしてください！

一緒に働くメンバーを募集しています

株式会社ドクターズプライム

「救急車のたらい回しをゼロにする」というビジョンの実現に向けて、病院向けのSaaSプロダクトおよび、医師/病院間の最適なマッチングを提供するマッチングプラットフォームを展開する会社を経営しており、創業期のメンバーを募集しています。採用情報はこちらから。興味を持っていただけた方はフォームからでもTwitterからでもお気軽にご連絡ください！