Zenn
📅

スタートアップのCTOに就任して1年経ったので振り返ってみた

2022/06/19に公開
4件
マネジメント
ポエム
プロジェクト
リファクタ
idea

はじめに

平下CTO@sweeepです。sweeepにフリーランスとして関わったのが2021年5月、CTOに就任したのがその年の6月半ばでした。CTOに就任してちょうど1年経過したのでこれまでを振り返ってみます。

開発チームパフォーマンスの変遷

以下、時系列で開発チームのパフォーマンスを振り返っていきます。

  • Before（6-9月）：タスクファーストとモノリスアーキテクチャでゆるやかな死へ
  • After（10-12月）：チームファーストとマイクロサービスアーキテクチャで新サービス立上げ
  • Now（1月〜現在）：プロダクトファーストでプロダクト価値向上
  • Future（将来）：よりパフォーマンス向上へ

会計指標で抽象化

また、開発のパフォーマンスとプロダクト価値の関係を会計指標で抽象化します。

  • G/P（Gross/Productivity）：開発チームの生産性
  • B/S（Balance/Sheet）：プロダクト価値。開発チームの生産性を上げプロダクト価値を高める
  • P/L（Profit/Loss）：プロダクト価値を高め利益を上げる

こちらに関してはROXX松本さんのスライド、プロダクトを中心に考える#とはを参考にさせていただきました。

Before（6-9月）：タスクファーストとモノリスアーキテクチャでゆるやかな死へ

Before：タスクファーストで社内受託状態

就任当初はBizからDevへ直接要望や修正を依頼するという、タスクファースト状態でした。BizチームからNotionに積まれた要望や修正のタスクをこなす日々。

Before：モノリスなアーキテクチャ

また、プロダクトもローンチから3年経過し、技術負債がかなりたまっていました。

  • モノリスなアーキテクチャを同時修正でコンフリ
  • 単一DBでデータの肥大化。マイグレーションなど大変
  • 凝集度が低く修正箇所漏れ

少人数で開発していた時は問題なかったのですが、開発人員増・開発規模増につれてツラミがましていました。

Before：チームは属人的

以前のチーム構成です。

Before（2021/06）：
- Web x 5
- Mobile x 2
- インフラ x 1
合計：8名

以下の様な業務委託メンバーやCEOに依存するという課題を抱えていました。

  • プロパーリソース中心
  • インフラは業務委託メンバーに依存
  • リリース日はリリースできた日
  • PdM/PjMはCEOが兼務
  • 定例やファシリはCEOが実施

Before：タスクファーストで何が起こっていたのか？

タスクファーストの状態ではG/P、B/S、P/Lはそれぞれ以下となっていました。

  • G/P：社内受託状態とアーキが組織構成にあっていなかったので技術負債がたまり低下
  • B/S：G/P低下のため拡大できない（むしろ個別最適≠全体最適ではないためB/S減）
  • P/L：ゆるやかにP/Lも下がる

After（10-12月）：チームファーストとマイクロサービスアーキテクチャで新サービス立上げ

After：チームファーストへ変更

まずはチームファーストに変えました。
BizとDevの間にPdMを配置し、Biz ↔ PdM ↔ DevとしてPdMに交通整理をしてもらいしました。

PdMが全体最適の視点で、プロダクトの価値をTotalで上げるもの、対応が必要な修正など取捨選択するように変更しました。

Point： Biz ↔ Devなどの関係だと対立関係になりやすい。間に交通整理の窓口を立てる。

After：アーキテクチャーの刷新

先日、文書のオンライン受け取りと電子保管などの新サービス ー クラウドキャビネットAI sweeep Boxを立ち上げました。
アーキテクチャーを以下のようにマイクロサービスへ刷新しています。

アーキテクチャの刷新によりBeforeの課題が以下のようなりました。

  • Before：モノリスなアーキテクチャを同時修正でコンフリ → After：マイクロサービスを少人数で各service修正
  • Before：単一DBでデータの肥大化。マイグレーションなど大変 → After：マイクロサービス毎にDBをもつ
  • Before：凝集度が低く修正箇所漏れ → After：適切なドメインで凝集度上げる
Point： 組織の成長にあわせたアーキテクチャにすることで、スケーラビリティを確保する。

After：サービス立上げのため開発にコミット

この時期はCTOの自分だけ土日/早朝/深夜も稼働し。9-12月はほぼ毎日草生えてます。0→1のスクラッチ開発で必要だと思ってやりました。よっぽど危機的状況で必要ない限りもうやりたくはないですね。。

もちろんメンバーへは要求しないですし、基本スタンスはメリハリつけてWorking Time内で開発しようぜ、です。

今は自分も基本10時〜19時で、年明けたまに土日草生えているのはテックブログ書いてZennへのコミットです、確か。

Point： CTOも場合によっては開発にコミットする必要がある。
       ただし常態化すると組織やサービスがスケールしないので常態化してはいけない。

After：チームファーストで開発しているsweeep Box

sweeep Boxはチームファーストのスクラムで開発しG/P、B/S、P/Lは以下変化しました。

  • G/P：チームファーストと組織構成にあったアーキ選定でアップ
  • B/S：G/Pがアップすればプロダクト価値は蓄積される
  • P/L：プロダクト価値が上がれば、売上はついてくるはず

Now（1月〜現在）：プロダクトファーストでプロダクト価値向上

Now：チームファーストからプロダクトファーストへ

sweeep Boxはリリース後、開発スプリント→QAスプリントの流れでスクラム開発しています。

アジャイル開発とウォーターフォール開発の違いは何？アジャイル開発の手法や意味も要チェック | Backlogブログ

A機能開発スプリント　
→　A機能QA後デプロイ　&　B機能開発スプリント
→　B機能QA後デプロイ　&　C機能開発スプリント
→　C機能QA後デプロイ　&　D機能開発スプリント
...

次の開発スプリントとQAスプリントを並行実施することでアジリティを高め、週次での新機能リリースを続けてプロダクト価値を高めています。

Point： スクラム開発ではスプリント期間を定め、定期的に新機能をリリースする。

Now：続々と追加される新機能

sweeep BOXのLPにあるように年明けのリリース以降続々と新機能の追加・更新を続けています。

https://lp.box.sweeep.ai/

  • 受取機能
  • AI-OCRで自動入力
  • 支払漏れ・支払ミスを防止
  • どんな書類も保管
  • 電子帳簿保存法に対応

最近は採用による開発メンバーの増員も進み、さらなる機能追加が進んでいますのでお楽しみに！

Now：sweeep×会計freee

また、技術リーダーがCore AI開発し、freeeさんの請求書OCRエンジンとして採用されました。読み取り精度や処理スピードが評価されています。

Point： 自社だけで完結せずに、他サービスと連携し経済圏を作っていく。

Now：品質強化 ー Validationの強化

バグが発生すると、調査、修正、テスト、関係各所とのやりとりなど膨大なリソースを消費し、本来やりたいことへ費やす時間が削られます。

そこで、正しいもの（Verification）を正しく作る（Validation）という考えを導入しました。料理に例えると設計などのプロセスがレシピ（正しいもの：Verification）、テストなどのプロセスが実際にレシピ通りできているか、という味見になります（正しく作る：Validation）。

とくに短期的に効果の出やすいValidationサイドの強化としてQAチーム構築しテストなど強化しました。

バグの報告やデグレなどぐっと減少し、新機能開発に集中できる環境が構築できたと感じています。

Point： 不具合は後工程になるほどツラミが増すので、工数かけてでもリリース前に不具合を捕まえる。

Now：チーム構成の変遷と成長

開発と並行して、CTOとして採用へコミットし、チーム構成は以下のように倍以上となりました。

Before（2021/06）：
- Web x 5
- Mobile x 2
- インフラ x 1
合計：8名

After（2022/08）：
- CTO x 1
- Web x 9
- Mobile x 3
- QA x 2
- デザイン x 1
合計：16名

開発体制の強化、増員により、Beforeの課題が以下のようなりました。

  • Before：プロパーリソース中心 → After：業務委託/副業の方もWork (8名：50%)
  • Before：インフラは業務委託の方に依存 → After：FE/BE/インフラなどプロパーメンバーは対応可能
  • Before：リリース日はリリースできた日 → After：スクラムで毎週新機能リリース
  • Before：PdM/PjMはCEOが兼務 → After：PdM(CEO)とPjM(CTO)分離
  • Before：定例やファシリはCEOが実施 → After：定例やファシリもメンバーが実施可能に
Point： CTOとして採用や組織の成長にもコミットする。

Now：新たなITツールやベンダーの活用

弊社はMVVのValueで仕組み化を定めていることもあり、ITツールの活用に積極的です。以下のツールを導入し、非常に開発効率を高めてくれたと実感しています。

  • gather.town：バーチャルオフィス
  • Backlog：プロジェクト管理ツール
  • Qase：テストケース管理ツール

また、ベンダーさんも新たに活用し、自社で足りないリソースを補っていただいています。

  • GCPパートナーサポートとGCPコスト6%off
  • 脆弱性診断のベンダー活用

その他、クラウドベンダーの以下のStartupプログラムへ採択され、とくにクラウドのクレジットはこの円安環境下で非常に助かっています。実はGoogle for Startupsは一度rejectされたのですが、Googleさんへ何度か説明した結果、採択されました。

  • Google for Startups：$10,0000のGCPクレジット
  • Microsoft for Startups：$2,5000のAzureクレジット、Free GitHub/MS Office for 1 year

Point： 自社のリソースだけで解決しようとせず、ITツールやベンダーさんの力で開発をレバレッジする。

Future（将来）：よりパフォーマンス向上へ

Future：今後の展望

開発体制の強化とアーキテクチャの刷新により、生産性を上げる仕組みは整いました。今後はG/Pをさらに倍増させる仕組みを作り、仮説・検証を繰り返すことでプロダクト価値を高め、サービスの成長曲線を描いていきます。

  • G/P：プロダクトファースト・増員で2〜3倍
  • B/S：G/P拡大させ、仮説・検証を繰り返すことでプロダクト価値も拡大
  • P/L：成長曲線を描く

今後の課題としては以下があるかな、と思っています。

  • 増員しても品質やG/Pが下がらないようにする
  • 技術負債の随時解消
  • 誰の（Who）、どんな課題を（Pain）、どう解決するのか（Solution）

Future：UX別のチーム構成

採用が進み、1つのチームで開発を進めることにより非効率な部分もでてくるようになりました（全員で会議するだけで倍の時間がかかったり）。
そこでUX別のチーム構成を検討しています。各自得意領域があるものの、FE/BEなど縦割りの技術で分担するのではなく、あるUXをフルスタックで開発できるような体制です。合わせて権限委譲をすすめています。

UX別のチーム構成はメルカリShopsの開発を支える組織を参考にさせてもらいました。

Future：技術負債との戦い

アーキテクチャを刷新しましたが、下記の引用した図のように開発が進むと技術負債は段々と蓄積されていき、ある時点で許容できないレベルに到達します。


CTOの頭の中：技術を財務で表現する

許容できるレベルのうちにリファクタリングなど実施し、技術負債の蓄積を随時解消していく必要があります。

Future：技術負債との戦い ー Verificationの強化

開発メンバーも増えるとシニアメンバーもいればジュニアメンバーもいますし、スクラッチ開発当初からいるメンバーもいればリリース後の機能改善フェーズから入ったメンバーもいます。

当初は設計書も作成していましたが、スクラッチ開発期間では開発が忙しくメンテナンスは間に合っていませんでした。最初からスクラッチで開発したメンバーはそれでも実装しながら理解していますが、途中から入ったメンバーは全体が見えなかったりして、適切でない実装をしてしまう可能性があります。そこで1週間かけて設計書を更新し、ツールからドキュメント自動生成やCI化などメンテナンスしやすい環境を構築しました。

先にのべた、正しいもの（Verification）を正しく作る (Validation）のVerificationサイドの強化です。料理でいえば職人の秘伝のタレをレシピ化し、前提知識やレベル差があってもレシピどおりに作ることで再現性を高め、技術負債の蓄積を抑える効果があります。

Future：誰の(Who)、どんな課題を(Pain)、どう解決するのか？(Solution)

これまでサービスの仕様やPRD（Product Requirements Document：製品要求仕様書）はPdM兼任するCEOに任せきりでした。CEOの豊富な経験・知識やこれまでのプロダクトでの実績などからCEOのサービス仕様を信頼しています。

しかし、これからは実現しようとしているサービスの世界観から、サービス仕様はCEOの経験や知識を頼り切りにせず、開発者自身も探求していく必要があると思っています。そのためにユーザインタビューなど積極的に私や開発者自身も参加するようにしました。

その際に、以下の図にあるように、ユーザ自身も適切に自身の欲するものを表現できない可能性がある、ということを理解しておく必要があります。


顧客が本当に必要だったものから学ぶこと | キャスレーコンサルティング株式会社

誰の（Who）、どんな課題を（Pain）どう解決するのか？（Solution）、ユーザの言った通り受け取るのではなく開発者自身で探求していく必要があると思います。

おわりに

今回はCTOに就任して1年経過したので振り返ってみました。たった1年ですが、数年分経過したような怒涛の毎日でした。
これまではある意味発展途上のプロダクト、開発チームへ自分の経験やリソースを投入することで成果や成長を達成することができた1年だったな、と思います。

しかし、これからは自分の経験やリソースを超えて、
個々のメンバーの成長 → 開発チームの成長 → プロダクトの成長 → 会社の成長
とつなげるフェーズに入ってきたと感じています（まだ道半ばです）。

参考サイト

文中で引用させていただいたROXX松本さんのスライドです。

https://speakerdeck.com/kotamat/focus-on-the-product

また、以下のnoteの記事も秀逸です。

https://note.com/singtacks/n/nb7a63ad40c17

ここまで読んでいただきありがとうございました！

GitHubで編集を提案

Discussion

iwaseshiiwaseshi

ちょうどスタートアップにJoinしたところでこの記事に出会えてよかったです。良記事でした！

hirachirac

コメントありがとうございます！少しでもお役に立てればよかったです(^^)