Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
事業フェーズごとに変化する CTO の思考 / DERTA GIG 04
Search
Shoya Tsukada
October 26, 2022
Technology
0
1.5k
事業フェーズごとに変化する CTO の思考 / DERTA GIG 04
2022-10-26 DERTA GIG vol.4 でお話したスライドです。
イベントページ:
https://ddd-ng.connpass.com/event/262318/
Shoya Tsukada
October 26, 2022
Tweet
Share
More Decks by Shoya Tsukada
See All by Shoya Tsukada
SPACE フレームワークで振り返るモニクル GraphQL リプレース
gabu
1
240
Other Decks in Technology
See All in Technology
MobileActOsaka_250704.pdf
akaitadaaki
0
150
United airlines®️ USA Contact Numbers: Complete 2025 Support Guide
unitedflyhelp
0
330
赤煉瓦倉庫勉強会「Databricksを選んだ理由と、絶賛真っ只中のデータ基盤移行体験記」
ivry_presentationmaterials
2
370
United Airlines Customer Service– Call 1-833-341-3142 Now!
airhelp
0
170
AI専用のリンターを作る #yumemi_patch
bengo4com
6
4.3k
ネットワーク保護はどう変わるのか?re:Inforce 2025最新アップデート解説
tokushun
0
210
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
6
13k
ビギナーであり続ける/beginning
ikuodanaka
3
780
20250707-AI活用の個人差を埋めるチームづくり
shnjtk
6
4k
開発生産性を組織全体の「生産性」へ! 部門間連携の壁を越える実践的ステップ
sudo5in5k
3
7.4k
Sansanのデータプロダクトマネジメントのアプローチ
sansantech
PRO
0
170
OSSのSNSツール「Misskey」をさわってみよう(右下ワイプで私のOSCの20年を振り返ります) / 20250705-osc2025-do
akkiesoft
0
170
Featured
See All Featured
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
Bash Introduction
62gerente
613
210k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Adopting Sorbet at Scale
ufuk
77
9.5k
It's Worth the Effort
3n
185
28k
Navigating Team Friction
lara
187
15k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Rails Girls Zürich Keynote
gr2m
95
14k
Transcript
事業フェーズごとに変化する CTO の思考 株式会社モニクル 塚田 翔也 / @gabu 2022-10-26 DERTA
GIG vol.4 @新潟
自己紹介 ・塚田 翔也 / TSUKADA Shoya ・札幌から来ました! ・名古屋出身、札幌に移住して2年目 ・高卒でエンジニアになり現在37歳、エンジニア歴19年... ・7歳と3歳の子育て中
現在は、お金の診断・相談サービス「マネイロ」を開発している 株式会社モニクルで執行役員 CTO をやっています。 @gabu
昔取った杵柄
よろしくお願いします
事業フェーズごとに変化する CTO の思考
事業フェーズごとに変化する CTO(1人目エンジニア)の 思考
事業フェーズとは?
本スライドでは以下のフェーズに分けて説明します ・フェーズ0:入社前 ・フェーズ1:PMF 前 ・フェーズ2:PMF 後 これから皆さんが1人目エンジニアとしてスタートアップに誘われる、もしくは、経営者の方 が1人目エンジニアを採用する可能性を考え、入社前にもエンジニアとして考えるべき大事な ことがあるのでフェーズ0としてご用意しました。 PMF(プロダクトマーケットフィット)については次のスライドでご説明します。
PMF プロダクトマーケットフィット とは?
PMF(プロダクトマーケットフィット)とは? プロダクト(製品)がマーケット(市場)にフィットしている状態 ・口コミやネットの情報でユーザーや顧客が増え続ける、どんどんダウンロードされる ・契約がどんどん取れる、有料プランへのアップグレードが止まらない など 「なかなか芽が出ない」「苦戦している」「手探り状態」という感覚よりも「ビジネスが勢 いよく成長している」という感覚です。逆にそうでない場合は、あの手この手でとにかく資 金が尽きるまでに PMF を目指します。
つまり、PMF 前後で見える世界や課題・問題がガラッと変わります。 なので、この PMF 前後でフェーズを分けました。
PMF までの道のり https://speakerdeck.com/tumada/pmf-nidao-rumadefalsesutezibie-zhi-zhen-ji
フェーズ0:入社前
CTO/1人目エンジニアとして スタートアップに誘われたら 何を考えますか?
ビジネスモデル? ミッション・ビジョン? 解こうとしている イシュー(社会課題)? お給料やストックオプション?
私が最も重要だと 思っていることは 「編成」です
編成?
None
「編成」重要 「編成」って重要ですよね。自分1人がどれだけ頑張っても「編成」次第でどうしても苦しい 戦いってありますよね。一方で「編成」が良ければ余裕で勝てたりします。 苦しい or 楽(らく)という話だけではなく、その「編成」によって自分が活躍できるかどう かがかなり変わりますよね。他のメンバーとの相性というのもありそうです。 つまり、自分のパフォーマンスを最大化するためにも「編成」は重要なのです。
では過去の編成を ふりかえってみます
私の経験 ・上場ベンチャーの新規事業(生活系アプリ) ・BtoC スタートアップ(AR アプリ) ・BtoB スタートアップ(IR・証券業界向けコミュニケーションプラットフォーム) ・BtoC スタートアップ(お金の診断・相談サービス「マネイロ」)
上場ベンチャーの新規事業(生活系アプリ) 成功:iOS/Android 合わせて300万DLを超え、マネタイズにも成功 エンジニア 開発全部 PdM を半分 Sさん マーケター 特にアプリマーケ得意
PdM を半分 企画段階で企画の精度がかなり高そうだったので「勝てる戦(いくさ)で勝った感」があり ました。
BtoC スタートアップ(AR アプリ) 失敗:コアなファンしか獲得できず、マネタイズに失敗 CTO 開発全部 開発チームのリード Sさん Co-Founder ビジョナリー
企画・BizDev・PMが強い Nさん Co-Founder 元GS、ファイナンス・業界や著 名人のネットワークが強い マネタイズよりも作りたい世界を優先した結果、後でとてもとても苦労することになりまし た。
BtoB スタートアップ(IR・証券業界向けプラットフォーム) 個人的には失敗:業界で幅広く使われ無料サービスとしては成功、マネタイズに苦戦するな か退職 CTO 開発全部 エンジニア採用 PdM Nさん Founder
/ CEO 元証券アナリスト 企画・BizDevが強い マネタイズよりもユーザー獲得を優先した結果、ユーザー獲得後のマネタイズで苦労するこ とになりました。
BtoC スタートアップ(お金の診断・相談サービス「マネイロ」) 現在進行系で成長中!マネタイズも・・・😊 CTO フェーズごとに必要なロー ルを転々と、初期のPdM マーケティング 採用(全職種) 開発全部、エンジニア組織 マネジメント
Co-Founder / CEO 元アナリスト・バンカー 営業・マーケティング ピープルマネジメント プロダクトマネジメント ファイナンスが強い Co-Founder / CCO 元機関投資家 著書多数 コンテンツ・ライティ ング・クリエイティブ ファイナンスが強い COO 元営業・経営者 営業・ピープルマネジメ ント・プログラミングは できないけど設計まで出 来てしまうITコンサル
累計サービス体験者数推移 2022年9月時点で5万人突破!
「編成」が強すぎるんよ・・・ (私を除く)
Aパート完
フェーズ1:PMF 前
創業フェーズの CTO は実質1人目エンジニア 創業フェーズの CTO は2人目以降のエンジニアを雇うまでは実質1人目エンジニアとしての 動きが求められます。 では、創業フェーズの1人目エンジニアがやるべきことは何でしょうか? PMF を目指し、MVP
を作ります。 MVP(Minimum Viable Product)とは、顧客に価値を提供できる最小限のプロダクトのこ とを指します。 完璧な製品・サービスを目指すのではなく、顧客が抱える課題を解決できる 最低限の状態で提供します。 資金が尽きるまでに PMF しないと次の調達が難しく、売上がなければ事業が継続できず、最 悪の場合このフェーズでゲームオーバーになるので、とにかく PMF を目指します。それ以外 のことは考えません。
PMF するために1人目エンジニア(私)が考えたこと 資金が尽きるまでに PMF するためにはスピードが命、つまりプロダクトを最速で開発し、さ らに高速に変更を加え続ける必要があります。 では、速くつくるためには何をするべきでしょうか? ・不慣れな流行りの技術よりも、自分が最速で開発できる言語やフレームワークを選ぶ 2人目以降のエンジニアを雇う前に会社が潰れるかもしれませんので、自分が最速で使える 武器を迷わず使いましょう。
・技術的負債は考えない 同上。むしろ負債と引き換えにスピードを得ましょう。 ・無駄なものを作らない とても重要なので次ページにて。
無駄なものを作らない = フォーカスする 「限られた開発リソース(エンジニア俺ひとり)で最大の成果を出すためにフォーカスしま しょう。優先度の高いものは何だと思いますか?」 経営陣に対して、この呪文を毎日毎日唱えます。 非エンジニアの人は「これも簡単にできるんじゃない?」「エンジニアは魔法使い」「塚田 さんなら余裕っしょ」と思っても仕方ないぐらい開発のことが分かりません。ただしそれは 決して悪いことではありません。僕らが営業やマーケティングの真の部分が理解できないの と同じです。
フォーカスする文化を根付かせる 「限られた開発リソース(エンジニア俺ひとり)で最大の成果を出すためにフォーカスしま しょう。優先度の高いものは何だと思いますか?」 この呪文を創業フェーズから唱え続けることで「フォーカスすることの重要さ」が時間とと もに経営陣に根付いていきます。そして、その根付いた思想は PMF 後も活きます。フォーカ スできる経営陣の元であれば、開発チームは安心して納得感をもって社として重要な開発に だけ取り組めるはずです。 これはもはや
CTO として会社に対する戦略です。
PdM の役回りになることが多い 優先度の高いものを経営陣とすり合わせるのと同時に、自分なりの工数イメージと照らし合 わせて、最終的な着手順序を決めます。もちろんその着手順序も経営陣とすり合わせます。 優先度 高い 普通 低い 工数 大
3: 簡単に実現できないか考える 思いついたらやる 思いつかないなら4へ やらなくても良いかも 無視 中 2: やる 5: (4)の後にやる 小 1: 一番美味しい=最優先 4: (3)が終わるかスキップに なったらやる
これって完全に プロダクトマネジメント なんですよね
このフェーズは特に 開発工数や 開発効率の良い順序の イメージを持てる エンジニアが イニシアチブをとるべき
MVP の育て方 何をどの順番で作るかまで決まれば、あとは楽しい楽しい開発タイムです。この時には作る ものに関する迷いはなくなっているはずなので、作るべきものをガッと作って、さっさとリ リースすることだけ考えます。そして定性・定量のフィードバックを何らかの方法で得て、 次の手を考え改善を繰り返します。 PMF するまで、これをただただ高速に繰り返します。 Build Learn
Measure
このフェーズは 思いっきり リーンスタートアッ プ そのままです
Bパート完
フェーズ2:PMF 後
PMF 後に考えること 試行錯誤を繰り返し、めでたく PMF したら次はスケールですね。PMF の前後でいくつか変 化があります。 ・2人目以降のエンジニアを採用する エンジニア採用やチームビルディングの時間を確保するため、PdM を引き継いでチーム開発
にフォーカスしたい。 ここでもフォーカスの重要さです。その時々に重要なことにフォーカスする、もしくは フォーカスできるように他の要素を戦略的に動かしていきましょう。 たまに CTO or VPoE 兼 PdM の人がいますが(最近立て続けに2人会いました)とてもとて も大変そうでした・・・
PMF 後は向き合うべき課題が変化する PMF 前はプロダクトを PMF させることが最優先事項だったので、顧客とプロダクトに向き 合い続け、プロダクトマネジメントにフォーカスしていれば良かったのですが、PMF 後の最 優先事項・フォーカスするべきポイントは何でしょうか?
人です! 採用です! 組織開発です!
1人目エンジニアはエンジニアリングマネージャーに そういう意味だと CTO(1人目エンジニア)って大変ですね〜。PMF 前は PdM(プロダク トマネージャー)をやり、PMF 後は EM(エンジニアリングマネジャー) をやるんですね〜 。
逆説的には、プロダクトマネジメントができて、エンジニアリングマネジャーもできる人が CTO や1人目エンジニアになるのが良いのですかね...このスライドを準備しながらふと思い ました... さて、そんな時でもこの2冊だけ読んでおけば大丈夫だと思える個人的な推し本を紹介しま す。
None
自信を持ってやっていきましょう(自分に言い聞かせてる) 幸いにもビジネス的には PMF しているので、その点は心配がなくなっていて、ビジネスより もエンジニア組織にフォーカスできる状態になっているはずです。 個人的には前者の不安やプレッシャーの方が桁違い(資金が尽きるまでに PMF できなかった ら会社が潰れるかもしれませんからね)だったので、このフェーズは会社やビジネスという 基盤がしっかりした状態で臨めるので、自信を持ってやっていけると思います。
さらにその先について、例えばエンジニアが10人、20人、30人以上の世界線は経験したこと がない(エンジニア50人ぐらいの会社にいた経験はありますが、マネジメントではなく平社 員だったので特に学びがない)ので私からお伝えすることはできません。 このまま弊社が成長して、来年・再来年にお話できたら嬉しいです!!
Cパート完
まとめ ・CTO(1人目エンジニア)が事業フェーズごとに考えてきたことについてお話しました ・入社前には、経営陣の「編成」を見極めましょう ・入社後 〜 PMF 前は、リーンスタートアップそのままに、資金が尽きるまでに MVP を PMF
させることだけを考えて突っ走ります ・PMF 後は、芽が出たビジネスを大きくスケールするための仲間集めと組織づくり、これま た大変ですが頑張ってやっていきましょう <= ただいま挑戦中 CTO や VPoE や1人目エンジニアの方、これからそういうポジションや経験に興味がある方 がいらっしゃいましたら、ぜひ懇親会でお話聞かせてください〜。
宣伝 株式会社モニクルでは、はたらく世代・子育て世代がお金の不安を手放せる手助けをするた めの金融サービス業をより広めるために、ソフトウェアエンジニアを募集しています。