ID:396さん

チーム、プロダクト

チーム 事業計画上のロードマップを継続的に開発・リリースし続けられる開発組織をつくり、維持することに責任を持っていました。採用・オンボーディング・評価の仕組みを整え、特定の個人に依存せず一定の開発速度と品質を保てる状態にすることが責務でした。 プロダクト 事業要求に対して実現可能性・コスト・スピードのバランスを取り、安定して稼働し続けるプロダクトであり続けさせることに責任を持っていました。障害やセキュリティリスクを許容範囲に抑えつつ、機能追加の速度が落ちないアーキテクチャと技術的負債の水準を保つ状態にすることが責務でした。

1人目のエンジニアとして参画したため、当初は自分の開発量がそのまま事業の速度でした。しかしCTOに就任した時点で、事業計画に必要な開発量に対して自分が書けるコード量では到底足りないと判断し、「自分が動く」から「チームが動く状態をつくる」へ役割を切り替えることを最優先に考えました。 具体的には、自分の稼働の約3割を採用に固定で確保し、残りを技術選定・設計とチームマネジメントに充てました。目先の開発は遅れますが、人員体制が整わない限り同じ問題が毎期繰り返されると考えたためです。結果として採用目標は在任中毎期100%を達成し、最大10名の体制まで拡大しました。 最も苦しかったのは、フォロワー70万人規模のYouTuberにオーガニックで紹介され、想定を大きく超えるトラフィックが流入してDBが張り付き、サービスが停止した時です。事業にとっては二度とない露出の機会であり、復旧の速さがそのまま機会損失の大きさに直結する状況でした。ただ、社内の知見だけで原因を特定できる保証はなく、自分たちだけで抱えることが最大のリスクだと判断しました。そこで技術顧問に相談し、紹介いただいたサーバーサイドエンジニアの方と並走する体制をすぐに組みました。2〜3日かけて原因調査を行い、書き込みと読み取りが単一DBに集中していることがボトルネックだと突き止め、リードレプリカの導入という結論に至りました。読み取りAPIをリードレプリカに寄せたうえでAPIのパフォーマンスチューニングを行い、流入トラフィックを捌ける状態まで復旧させました。 この経験から、負荷は事業が伸びる局面で必ず来るものと捉え直し、以降は成長を見越したインフラ構成を前提に設計するよう方針を変えました。 また、チームが大きくなるにつれ、経営会議での決定をそのまま共有するとメンバーには「なぜ今これをやるのか」が見えず、納得のないまま手が動く状態になっていました。スタートアップで方針が頻繁に変わる以上、背景が共有されないと変更のたびに納得感が削られると考え、決定事項だけを伝えるのをやめ、どんな議論を経てその判断に至ったかまでセットで伝えるようにしました。あわせて、チームの不調はアウトプットに表れてからでは手遅れになるため、違和感を覚えた段階でこちらから1on1を入れ、必要に応じて経営メンバーに早めに相談する運用にしていました。 結果として、3つのサービスの立ち上げを進めながら、開発を止めずに継続できる体制を維持できました。