会社のフェーズに合わせた”CTOの役割の変化” への向き合い方

by miraoto@mybest

Slide 1

Slide 1 text

会社のフェーズに合わせた ”CTOの役割の変化” への向き合い方 ROSCAFE TECH NIGHT #1 update Oct 31, 2023

Slide 2

Slide 2 text

渡邊直登 Naoto Watanabe 取締役 CTO 兼執行役員｜プロダクト開発部部長 SIerにてエンジニア/ディレクターの経験後、事業会社で正社員向けサービスの開発に携わる。その後、医療系の新規事業の立ち上げを経験を経て 2017年にマイベスト入社。現在は、業務委託を含めたエンジニアのマネジメント、マーケ・営業系施策の開発サポート、Enablingミッションのリード、データ分析基盤の運用を担当。来月1歳になる息子がいます。日本酒が好きです。プロフィール

Slide 3

Slide 3 text

人生は選択の連続でできています。 mybestは選択をよりよくすることで、ユーザーの生活を豊かにすることに貢献したいと考えています。最高の選択体験を実現する。私たちのミッション

Slide 4

Slide 4 text

月間利用者数 3,000 ユーザーの“選択”をサポートするサービス万人以上（2023年7月時点）

Slide 5

Slide 5 text

mybestはユーザーの選択行動をサポートするサービス自社で商品を実際に購入・検証した情報と、それをユーザーフレンドリーに選択できる機能、購入先の商品情報を鮮度の高いものにするデータで構成されています。自社検証商品比較価格比較

Slide 6

Slide 6 text

購入して実際に検証モノやサービスを大量に購入売れ筋のもの、名前が知られているものは網羅、ジャンルによっては知る人ぞ知るものすごくニッチな商品を買ってくることも。購入予算の上限はありません。そして検証するための設備にも上限はありません。累計検証回数約 207,886 回 ※2023年7月時点月間検証数月平均 8,210回 ※2022年5月-2023年4月実績過去購入した商品・サービス数 30,190個 ※2021年1月-2023年4月実績月間商品平均金額 10,214,033円 ※2022年度実績

Slide 7

Slide 7 text

選択に資するデータベースを作るために、ユーザーニーズや利用シーンに合わせて各領域で専門性を持ったメンバーが唯一無二のデータベースを制作しています。専門人材が検証し、データベースを制作雨傘の検証。送風機を使って「耐風性」を比較防水カメラの検証。プールを貸し切り、実際に潜って撮影縦型洗濯機の検証。主要メーカー7社の中から人気18商品を購入して検証ヘアアイロンの検証。全商品を担当者の自毛で検証チェーンソーの検証。片道2時間ほどかけて、山奥にこもって検証電子レンジの検証。実際に主婦にお願いして使い勝手などをリアルに検証

Slide 8

Slide 8 text

テスト環境も自社で整備自社内に倉庫やテストラボ、撮影スタジオまで設備。スティックのりから洗濯機までが自社内にあります。大掛かりなテストは第三者機関の富士総研などの研究所をお借りします。

Slide 9

Slide 9 text

これまでは、選択肢のデータベース作りに最も注力してきました。現在は、選択プロダクトとしての体験設計やインターフェースの開発に注力しており、今後は、ユーザーデータを活用したパーソナライズにも取り組みます。 2017 2018 2019 2020 2021 2022 2023 2024 2025 Phase 3 パーソナライズによる最適な選択肢の掲出提供できる選択体験のよさ Phase 1 選択肢のデータベース作り Phase 2 選択プロダクトとしての UI/UX フェーズを3つにわけて、PMFに向けて取り組む。

Slide 10

Slide 10 text

有益な情報があるだけの “メディア”ではなく、それらの情報を元にして自分にとって最適な選択ができる “サービス”へと昇華させ、より深くユーザーの選択をサポートしていきたいと考えています。 mybestの独自情報を“自分に最適な選択ができること”へと昇華データベースサービスメディアパーソナライズプロダクト Web アプリ信頼性最適な選択ができるどこにもない情報があるこれからこれまで

Slide 11

Slide 11 text

検索流入以外の選択体験を追求するためにアプリをリリース 2023年3月にモバイルアプリをリリース。マイベストの膨大な商品データベースを活かしつつ、検索流入ではニーズが薄かったパーソナライズ体験をたちあげていく。

Slide 12

Slide 12 text

生成系AIを用いた選択体験も模索中 ChatGPTを利用した選択体験の PoCも実施。X（旧：Twitter）やChatGPTプラグインをリリースしています

Slide 13

Slide 13 text

改めて...今回は、今CTO/VPoEに求められる事とは？というテーマなので、 1人の時から現在に至るまで、会社のフェーズに合わせた ”CTOの役割の変化”への向き合い方の話をしたいと思います

Slide 14

Slide 14 text

創業期 Index 1 成長期 2 拡大期（現在） 3 まとめ 4

Slide 15

Slide 15 text

創業期画像創業期成長期拡大期これから開発チーム人数1名から4名まで

Slide 16

Slide 16 text

創業期求められていたのは自身のアウトプットの最大化とバケツの穴を塞ぐこと開発負債はすでにあった認知・推しがない採用組織暗黙知の多いチーム

Slide 17

Slide 17 text

創業からの入社ではなく、既に運用されているサービスがある状態でのスタートだった（副業メンバーだけでの開発体制）ため、まずは最低限の守りの施策を実施。合わせて、当時の 0→1施策の開発も平行して行う開発 Day1から負債との向き合い方を考えるやったことやらなかったこと開発環境の整備テスト・staging環境など開発にレバレッジが効くものを整備プロダクトグロース施策サービスの方向性が定まっていないため新技術の選定・導入初期に技術選定をする余裕はなかった負債解消の仕組み化負債解消の動きが属人的にならないように

Slide 18

Slide 18 text

毎月1日コワーキングスペースに行き、負債解消だけを実施する日をつくる。この時の仕組みや文化が現在も残っているので、ここでの意思決定はとても重要だった負債解消の仕組み化 Spark Joy Dayで負債を解消 0 → 1 0 → 1

Slide 19

Slide 19 text

デザイン・フロントエンド・インフラの課題をサポートしてもらえるようなメンバー探し採用・広報自分の弱みを補う人をリファラルで採るやったことやらなかったことリファラル正社員・業務委託採用自分やメンバーのつながりを頼る転職顕在層向けのアウトプットチーム紹介、業務紹介などエージェントを利用した採用認知やセールスポイントがなかったため 10 → 100 ダイレクトリクルーティング継続的な対応リソースを充てることができなかったため 1 → 10 0 → 1

Slide 20

Slide 20 text

転職顕在層向けのアウトプットチームやメンバーをイメージしやすい情報を中心に投稿どのポジションでも 1人目となる採用だったので、ギャップが出ないようにできる限り情報の透明性を意識

Slide 21

Slide 21 text

暗黙知が多く、チーム状況も見えなかったので各種ツールを導入。言語化する文化が定着するように推進組織言語化から始めるやったことやらなかったこと JIRAの導入タスクと開発フローを整備 Conﬂuenceの導入開発ドキュメントの整備ふりかえりの導入チームとしての課題を発見しチーム練度を上げる業務・ドキュメントの型化変化が大きいフェーズなので形骸化すると思ったため

Slide 22

Slide 22 text

成長期画像成長期創業期拡大期これから開発チーム人数4名から10名まで

Slide 23

Slide 23 text

成長期求められていたのは非連続な成長のための種まきと技術戦略の作成・組織づくり開発非連続な成長へのTRY 成功パターンを模索採用組織評価・チーム組成

Slide 24

Slide 24 text

開発のボトルネックが解消され、事業成長とそれにレバレッジの効く技術的な強みの模索に比重を上げる開発開発戦略の格子の作成と技術的な強みの模索やったことやらなかったこと 0→1の機能開発選択イシューに関する理想の解決策を逆算して考える技術的強みの模索モダンではあるが尖りのない技術スタックでどうするか 10 → 100 1 → 10 開発効率への投資 Chat Opsや開発環境のコンテナ化などデータ分析の推進定量より定性を大切に。スケールしないことをするプロダクトグロース施策引き続きサービスの方向性が定まっていないため

Slide 25

Slide 25 text

自社検証が選択体験の１つのイシューの解決になりそうだったので、それを生かし提供したい価値について組織として目指すべき方向性を定義するプロジェクトを発足しメンバーに権限を移譲 0→1の機能開発ユーザー体験の理想を定義するプロジェクトを立ち上げ

Slide 26

Slide 26 text

開発戦略の格子が見えつつある状況になってきたので、競合優位性・開発生産性・技術優位性を軸として技術的な調査・導入を開始技術的強みの模索いくつか軸を据えて技術選定を実施 Backend Frontend GraphQLの採用当時は各社が導入開始直後ぐらいで運用知見が乏しかったモダンJavaScript フレームワークの導入今後インタラクティブなUXになることを想定して決定 10 → 100 Infra 開発環境コンテナ化・全世界 ECS化 Chat Opsによる開発生産性・堅牢性

Slide 27

Slide 27 text

過去の経験に囚われず利用できそうなものはすべて使ってみる採用・広報自社の特徴を生かした媒体・業務形態を見つけるやったことやらなかったことほぼ全ての経路を利用母集団や会社との相性を見極めて精査会社説明スライドの作成チーム紹介、業務紹介など開発ブログ継続的にアウトプットできる体制にできなかった

Slide 28

Slide 28 text

ベストプラクティスに飛びつかず、その時点で一番ニーズに近い母集団を持つ媒体を探す。妥協できる点を持つほぼ全ての経路を利用自社の特徴を生かした媒体・業務形態を見つけるダイレクトリクルーティング採用媒体エージェントリファラル SES ヘッドハンティングダイレクトリクルーティング副業

Slide 29

Slide 29 text

チームが自律的に動くために、組織と役割を整理組織権限移譲し課題への主体性をもたせるやったことやらなかったことミッション制の導入課題別にチームを組成することで権限を移譲横断課題の導入技術的な課題に対するリソースを確保し、計画的に解消/導入業務・ドキュメントの型化変化が大きいフェーズなので形骸化すると思ったためスペシャリスト職の採用事業が安定していない状態のため業務委託の方との協業計画的な役割分担をトライ

Slide 30

Slide 30 text

重要な事業課題単位でチームを組成し、チーム内だけで課題を解決できるように権限を移譲組織課題別にチームを組成

Slide 31

Slide 31 text

業務委託・正社員の役割と募集ペルソナ言語化することで、期待値を明確化組織業務委託・副業の方との関わり方を整理

Slide 32

Slide 32 text

スキル評価として、専門性評価シートを導入専門性評価シートエンジニア・デザイナーが、半期に実施した施策の中で自分の専門性を用いて解決した課題を、「解決したい課題」「アプローチ」「解決したときの価値」というフォーマットでまとめたもの組織

Slide 33

Slide 33 text

拡大期(現在) 画像開発チーム人数10名から30名まで前夜これから拡大期成長期

Slide 34

Slide 34 text

拡大期開発イシューの具体化専門採用認知拡大採用組織開発生産性の改善特化チームの組成求められているのはアジリティの高い組織から堅牢な組織への移行

Slide 35

Slide 35 text

プロダクトロードマップで全体像を可視化しつつ、横断的にレバレッジの効くアクションを中心に対応開発プロダクト戦略の言語化とそれに合わせたプロダクト体制の整備やっていることプロダクトロードマップ作成プロダクトの中長期的な展望の可視化プロダクトグロースのナレッジ共有ルール作成やナレッジ蓄積の仕組み化

Slide 36

Slide 36 text

プロダクトロードマップで全体像を可視化しつつ、横断的にレバレッジの効くアクションを中心に対応開発プロダクト戦略の言語化とそれに合わせたプロダクト体制の整備

Slide 37

Slide 37 text

ルールを作る仕組みの整備や属人的なオペレーションの汎用・ドキュメント化などを推進プロダクトグロース組織としてのルール整備やナレッジを蓄積

Slide 38

Slide 38 text

採用・広報自社の活動を対外的に共有し転職潜在層も含め認知をとるやっていること EMの採用ピープルマネジメント＆採用にコミットするメンバーの配置他社との交流・認知の獲得勉強会、自社イベント、ブース出展など

Slide 39

Slide 39 text

採用・広報自社の活動を対外的に共有し転職潜在層も含め認知をとる

Slide 40

Slide 40 text

組織横断的な課題をサポートする特定の専門技術に特化したチームを組成やっていること特定の専門技術に特化したチームの組成データ分析や機械学習など高度な手段をサポートする体制スキル評価の導入専門性を相対的に評価し社内キャリアと揃える

Slide 41

Slide 41 text

組織 Enablingチームによる開発生産性の改善 Four Keysの改善開発フローやルールの改善・運用をサポート技術ドキュメントを整備＆利用をサポート事業課題を推進するチームが課題にフォーカスし続ける事ができる状態を担保するために、 EnablingチームがFour Keysの改善や開発ドキュメントの整備などを通して開発活動をサポート

Slide 42

Slide 42 text

タスクフォースという形で、専門技術と事業イシューがマッチするか様子を見つつ立ち上げ組織特定の専門技術に特化したチームを組成

Slide 43

Slide 43 text

自社のスキル評価軸を言語化し、マイベストらしいエンジニアを形成組織スキル評価の導入

Slide 44

Slide 44 text

ここまでのふりかえり画像

Slide 45

Slide 45 text

創業期：プレイヤー同じ役割（CTO）でも求められることが全然違う... 1 成長期：プレイングマネージャー 2 拡大期（現在）：マネージャー 3

Slide 46

Slide 46 text

うまくいったうまくいかなかった技術負債を継続的に解消する仕組み SparkJoyDay→横断課題→Enablingとバランスよく横断課題の導入技術的な課題に対するリソースを確保し、計画的に解消/導入ホラクラシー組織の導入仕組みの理解と浸透ができず頓挫... Large-Scale Scrum (LeSS)の導入仕組みの理解と浸透ができず頓挫... 業務委託の方との協業計画的な役割分担をトライひとつ先というのが肝。組織やプロダクトは一足飛びで成長はしない（特に自律性を求めるような施策）過去を振り返ると現状の理解とひとつ先のアクションが求められていた

Slide 47

Slide 47 text

ひとつ先のアクションがありたい方向じゃないこともあるので、その場合は向き直す判断が必要過去を振り返ると現状の理解とひとつ先のアクションは必ずしも連続した改善ではないふりかえりとむきなおし理想に向かって突き進む。ではなく、ありたい方向性を見定めつつ状況変化に合わせてありたい方向自体を向き直すほうが上手くいった

Slide 48

Slide 48 text

ふりかえりのまとめ現状理解した具体的なアクションの提案・実行 HOWにはこだわらないむきなおしのタイミングを決めるフェーズが変わるタイミングでは連続した成長に無理が出る。フェーズに身を任せてむきなおし一気に変える。課題に合わせて人ではなく組織を変えるメンバーが少ないフェーズでも人に依存する仕組みは長続きしない

Slide 49

Slide 49 text

ご清聴ありがとうございました