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

2023.10.31 (Tue.) ROSCAFE TECH NIGHT #1 〜今、CTO / VPoEに求められる事とは？〜の資料です
https://rosca.connpass.com/event/296573/

Transcript

1. 会社のフェーズに合わせた ”CTOの役割の変化” への向き合い方 ROSCAFE TECH NIGHT #1 update Oct 31, 2023
2. 渡邊 直登 Naoto Watanabe 取締役 CTO 兼 執行役員｜プロダクト開発部 部長 SIerにてエンジニア/ディレクターの経験後、事業会社で正社員向けサービスの開発 に携わる。その後、医療系の新規事業の立ち上げを経験を経て 2017年にマイベスト 入社。 現在は、業務委託を含めたエンジニアのマネジメント、マーケ・営業系施策の開発サ ポート、Enablingミッションのリード、データ分析基盤の運用を担当。 来月1歳になる息子がいます。日本酒が好きです。 プロフィール
3. 人生は選択の連続でできています。 mybestは選択をよりよくすることで、ユーザーの生活を豊かにすることに貢献 したいと考えています。 最高の選択体験を 実現する。 私たちのミッション
4. 月間利用者数 3,000 ユーザーの“選択”を サポートするサービス 万人以上 （2023年7月時点）
5. mybestはユーザーの選択行動をサポートするサービス 自社で商品を実際に購入・検証した情報と、それをユーザーフレンドリーに選択できる機能、購入先の商品情報を鮮度の高いものに するデータで構成されています。 自社検証 商品比較 価格比較
6. 購入して実際に検証 モノやサービスを大量に購入 売れ筋のもの、名前が知られているものは網羅、ジャンルによっては知る人ぞ知るものすごくニッチな商品を買ってくることも。購入予算の上限はありません。そして検 証するための設備にも上限はありません。 累計検証回数 約 207,886 回 ※2023年7月時点 月間検証数 月平均 8,210回 ※2022年5月-2023年4月実績 過去購入した商品・サービス数 30,190個 ※2021年1月-2023年4月実績 月間商品 平均金額 10,214,033円 ※2022年度実績
7. 選択に資するデータベースを作るために、 ユーザーニーズや利用シーンに合わせて 各領域で専門性を持ったメンバーが唯一無二の データベースを制作しています。 専門人材が検証し、データベースを制作 雨傘の検証。送風機を使って「耐風性」を比較 防水カメラの検証。プールを貸し切り、実際に潜って撮影 縦型洗濯機の検証。主要メーカー7社の中から人気18商品を購入して検証 ヘアアイロンの検証。全商品を担当者の自毛で検証 チェーンソーの検証。片道2時間ほどかけて、山奥にこもって検証 電子レンジの検証。実際に主婦にお願いして使い勝手などをリアルに検証
8. テスト環境も自社で整備 自社内に倉庫やテストラボ、撮影スタジオまで設備。 スティックのりから洗濯機までが自社内にあります。大掛かりなテストは第三者機関の富士総研などの研究所をお借りします。
9. これまでは、選択肢のデータベース作りに最も注力してきました。 現在は、選択プロダクトとしての体験設計やインターフェースの開発に注力しており、 今後は、ユーザーデータを活用したパーソナライズにも取り組みます。 2017 2018 2019 2020 2021 2022 2023 2024 2025 Phase 3 パーソナライズによる 最適な選択肢の掲出 提供できる選択体験のよさ Phase 1 選択肢のデータベース作り Phase 2 選択プロダクトとしての UI/UX フェーズを3つにわけて、PMFに向けて取り組む。
10. 有益な情報があるだけの “メディア”ではなく、それらの情報を元にして自分にとって最適な選択ができる “サービス”へと昇華させ、よ り深くユーザーの選択をサポートしていきたいと考えています。 mybestの独自情報を“自分に最適な選択ができること”へと昇華 データベース サービス メディア パーソナライズ プロダクト Web アプリ 信頼性 最適な選択ができる どこにもない情報がある これから これまで
11. 検索流入以外の選択体験を追求するためにアプリをリリース 2023年3月にモバイルアプリをリリース。 マイベストの膨大な商品データベースを活かしつつ、検索流入ではニーズが薄かったパーソナライズ体験をたちあげていく。
12. 生成系AIを用いた選択体験も模索中 ChatGPTを利用した選択体験の PoCも実施。X（旧：Twitter）やChatGPTプラグインをリリースしています
13. 改めて...今回は、今CTO/VPoEに求められる事とは？というテーマなので、 1人の時から現在に至るまで、会社のフェーズに合わせた ”CTOの役割の変化”への向き合い方の話をしたいと思います
14. 創業期 Index 1 成長期 2 拡大期（現在） 3 まとめ 4
15. 創業期 画像 創業期 成長期 拡大期 これから 開発チーム人数1名から4名まで
16. 創業期 求められていたのは 自身のアウトプットの最大化とバケツの穴を塞ぐこと 開発 負債はすでにあった 認知・推しがない 採用 組織 暗黙知の多いチーム
17. 創業からの入社ではなく、既に運用されているサービスがある状態でのスタートだった（副業メンバーだけでの開発体制）ため、まず は最低限の守りの施策を実施。合わせて、当時の 0→1施策の開発も平行して行う 開発 Day1から負債との向き合い方を考える やったこと やらなかったこと 開発環境の整備 テスト・staging環境など開発にレバレッジが効くものを整備 プロダクトグロース施策 サービスの方向性が定まっていないため 新技術の選定・導入 初期に技術選定をする余裕はなかった 負債解消の仕組み化 負債解消の動きが属人的にならないように
18. 毎月1日コワーキングスペースに行き、負債解消だけを実施する日をつくる。この時の仕組みや文化が現在も残っているので、ここで の意思決定はとても重要だった 負債解消の仕組み化 Spark Joy Dayで負債を解消 0 → 1 0 → 1
19. デザイン・フロントエンド・インフラの課題をサポートしてもらえるようなメンバー探し 採用・広報 自分の弱みを補う人をリファラルで採る やったこと やらなかったこと リファラル正社員・業務委託採用 自分やメンバーのつながりを頼る 転職顕在層向けのアウトプット チーム紹介、業務紹介など エージェントを利用した採用 認知やセールスポイントがなかったため 10 → 100 ダイレクトリクルーティング 継続的な対応リソースを充てることができなかったため 1 → 10 0 → 1
20. 転職顕在層向けのアウトプット チームやメンバーをイメージしやすい情報を中心に投稿 どのポジションでも 1人目となる採用だったので、ギャップが出ないようにできる限り情報の透明性を意識
21. 暗黙知が多く、チーム状況も見えなかったので各種ツールを導入。言語化する文化が定着するように推進 組織 言語化から始める やったこと やらなかったこと JIRAの導入 タスクと開発フローを整備 Confluenceの導入 開発ドキュメントの整備 ふりかえりの導入 チームとしての課題を発見しチーム練度を上げる 業務・ドキュメントの型化 変化が大きいフェーズなので形骸化すると思ったため
22. 成長期 画像 成長期 創業期 拡大期 これから 開発チーム人数4名から10名まで
23. 成長期 求められていたのは 非連続な成長のための種まきと技術戦略の作成・組織づくり 開発 非連続な成長へのTRY 成功パターンを模索 採用 組織 評価・チーム組成
24. 開発のボトルネックが解消され、事業成長とそれにレバレッジの効く技術的な強みの模索に比重を上げる 開発 開発戦略の格子の作成と技術的な強みの模索 やったこと やらなかったこと 0→1の機能開発 選択イシューに関する理想の解決策を逆算して考える 技術的強みの模索 モダンではあるが尖りのない技術スタックでどうするか 10 → 100 1 → 10 開発効率への投資 Chat Opsや開発環境のコンテナ化など データ分析の推進 定量より定性を大切に。スケールしないことをする プロダクトグロース施策 引き続きサービスの方向性が定まっていないため
25. 自社検証が選択体験の１つのイシューの解決になりそうだったので、それを生かし提供したい価値について組織として目指すべき方 向性を定義するプロジェクトを発足しメンバーに権限を移譲 0→1の機能開発 ユーザー体験の理想を定義するプロジェクトを立ち上げ
26. 開発戦略の格子が見えつつある状況になってきたので、競合優位性・開発生産性・技術優位性を軸として技術的な調査・導入を開始 技術的強みの模索 いくつか軸を据えて技術選定を実施 Backend Frontend GraphQLの採用 当時は各社が導入開始直後ぐらいで運用知見が乏しかった モダンJavaScript フレームワークの導入 今後インタラクティブなUXになることを想定して決定 10 → 100 Infra 開発環境コンテナ化・全世界 ECS化 Chat Opsによる開発生産性・堅牢性
27. 過去の経験に囚われず利用できそうなものはすべて使ってみる 採用・広報 自社の特徴を生かした媒体・業務形態を見つける やったこと やらなかったこと ほぼ全ての経路を利用 母集団や会社との相性を見極めて精査 会社説明スライドの作成 チーム紹介、業務紹介など 開発ブログ 継続的にアウトプットできる体制にできなかった
28. ベストプラクティスに飛びつかず、その時点で一番ニーズに近い母集団を持つ媒体を探す。妥協できる点を持つ ほぼ全ての経路を利用 自社の特徴を生かした媒体・業務形態を見つける ダイレクトリクルーティング 採用媒体 エージェント リファラル SES ヘッドハンティング ダイレクトリクルーティング 副業
29. チームが自律的に動くために、組織と役割を整理 組織 権限移譲し課題への主体性をもたせる やったこと やらなかったこと ミッション制の導入 課題別にチームを組成することで権限を移譲 横断課題の導入 技術的な課題に対するリソースを確保し、計画的に解消/導入 業務・ドキュメントの型化 変化が大きいフェーズなので形骸化すると思ったため スペシャリスト職の採用 事業が安定していない状態のため 業務委託の方との協業 計画的な役割分担をトライ
30. 重要な事業課題単位でチームを組成し、チーム内だけで課題を解決できるように権限を移譲 組織 課題別にチームを組成
31. 業務委託・正社員の役割と募集ペルソナ言語化することで、期待値を明確化 組織 業務委託・副業の方との関わり方を整理
32. スキル評価として、専門性評価シートを導入 専門性評価シート エンジニア・デザイナーが、半期に実施した施 策の中で自分の専門性を用いて解決した課題 を、「解決したい課題」「アプローチ」「解決したと きの価値」というフォーマットでまとめたもの 組織
33. 拡大期(現在) 画像 開発チーム人数10名から30名まで 前夜 これから 拡大期 成長期
34. 拡大期 開発 イシューの具体化 専門採用 認知拡大 採用 組織 開発生産性の改善 特化チームの組成 求められているのは アジリティの高い組織から堅牢な組織への移行
35. プロダクトロードマップで全体像を可視化しつつ、横断的にレバレッジの効くアクションを中心に対応 開発 プロダクト戦略の言語化とそれに合わせたプロダクト体制の整備 やっていること プロダクトロードマップ作成 プロダクトの中長期的な展望の可視化 プロダクトグロースのナレッジ共有 ルール作成やナレッジ蓄積の仕組み化
36. プロダクトロードマップで全体像を可視化しつつ、横断的にレバレッジの効くアクションを中心に対応 開発 プロダクト戦略の言語化とそれに合わせたプロダクト体制の整備
37. ルールを作る仕組みの整備や属人的なオペレーションの汎用・ドキュメント化などを推進 プロダクトグロース 組織としてのルール整備やナレッジを蓄積
38. 採用・広報 自社の活動を対外的に共有し転職潜在層も含め認知をとる やっていること EMの採用 ピープルマネジメント＆採用にコミットするメンバーの配置 他社との交流・認知の獲得 勉強会、自社イベント、ブース出展など
39. 採用・広報 自社の活動を対外的に共有し転職潜在層も含め認知をとる
40. 組織 横断的な課題をサポートする特定の専門技術に特化したチームを組成 やっていること 特定の専門技術に特化したチームの組成 データ分析や機械学習など高度な手段をサポートする体制 スキル評価の導入 専門性を相対的に評価し社内キャリアと揃える
41. 組織 Enablingチームによる開発生産性の改善 Four Keysの改善 開発フローやルールの改善・運用をサポート 技術ドキュメントを整備＆利用をサポート 事業課題を推進するチームが課題にフォーカスし続ける事ができる状態を担保するために、 EnablingチームがFour Keysの改善や開 発ドキュメントの整備などを通して開発活動をサポート
42. タスクフォースという形で、専門技術と事業イシューがマッチするか様子を見つつ立ち上げ 組織 特定の専門技術に特化したチームを組成
43. 自社のスキル評価軸を言語化し、マイベストらしいエンジニアを形成 組織 スキル評価の導入
44. ここまでのふりかえり 画像
45. 創業期：プレイヤー 同じ役割（CTO）でも求められることが 全然違う... 1 成長期：プレイングマネージャー 2 拡大期（現在）：マネージャー 3
46. うまくいった うまくいかなかった 技術負債を継続的に解消する仕組み SparkJoyDay→横断課題→Enablingとバランスよく 横断課題の導入 技術的な課題に対するリソースを確保し、計画的に解消/導入 ホラクラシー組織の導入 仕組みの理解と浸透ができず頓挫... Large-Scale Scrum (LeSS)の導入 仕組みの理解と浸透ができず頓挫... 業務委託の方との協業 計画的な役割分担をトライ ひとつ先というのが肝。組織やプロダクトは一足飛びで成長はしない（特に自律性を求めるような施策） 過去を振り返ると 現状の理解とひとつ先のアクションが求められていた
47. ひとつ先のアクションがありたい方向じゃないこともあるので、その場合は向き直す判断が必要 過去を振り返ると 現状の理解とひとつ先のアクションは必ずしも連続した改善ではない ふりかえりとむきなおし 理想に向かって突き進む。ではなく、ありたい方 向性を見定めつつ状況変化に合わせてありた い方向自体を向き直すほうが上手くいった
48. ふりかえりのまとめ 現状理解した具体的なアクションの提案・実行 HOWにはこだわらない むきなおしのタイミングを決める フェーズが変わるタイミングでは連続した成長に無理が出る。フェーズに身を任せてむきなおし一気に変える。 課題に合わせて人ではなく組織を変える メンバーが少ないフェーズでも人に依存する仕組みは長続きしない
49. ご清聴ありがとうございました