好きなスーパーはライフで、週2回はネットスーパーを利用しています。お気に入りの商品は、ライフプレミアムの「大粒もっちり肉餃子」です。肉も野菜も摂取できて、お腹いっぱいになり、ビールにも合う優等生です。忙しい日に是非買ってみてください。10Xでは創業当初からCTOを務めているのですが、会社のフェーズの変化と共にコードを書く機会が増えたり減ったりしてきました。その過程で起きたことや考えたことを、まとめて紹介しようと思います。仕事でコードを書くとき、書かないときは以下のように変遷してきました。第3次開発期とあるリポジトリへのcontributionは以下のようになっています。グラフのどの部分がどの時期に該当するかは明言しませんが、波があることは察していただけるかと思います。第1次開発期Stailerの立ち上げ期です。会社のメンバーはまだ10名ほどでした。新たなプロダクトの開発に着手するということで、まずは技術選定やアプリケーションの土台となるコンポーネントの実装を完了させる必要がありました。クライアントサイドではFlutterの採用を決めたり、ベースとなるUIコンポーネントをドラフトしたりしました。サーバーサイドでは開発チームの特性を考慮してサーバーサイドでDartを採用し、Firestoreを操作するライブラリを開発したりしました。クライアント/サーバー共に開発に必要なものがある程度揃った段階で、次のフェーズに移りました。PM&デザイン期Stailerの機能開発に着手して、リリースした時期です。事業としての不確実性はまだまだ高く、全社で15名ほどでこのフェーズを乗り越えたようです。事業開発の重要性の高まりに伴って、代表の矢本さんの役割をシフトさせたタイミングでもありました。この時の自分はコードの第一線からは退いて、PMとデザイナーの役割を担うことになりました。事業戦略やプロダクトの位置付けは矢本さんに決めてもらいつつ、プロダクト自体の仕様策定やデザインをしていました。Figmaを使いながら、お客様向けの売場やカートのUIを模索し、現在のプロダクトの原形となるものをつくりました。その後、デザイナーのsuuminさんとPMのuraさんが入社したことや、新たな事業機会がやってきたことによって、再び開発に軸足を置くことになりました。第2次開発期Stailerがネットスーパーの立ち上げに必要なものにすべてを取り揃えるべく、プロダクトの手を広げたタイミングです。30名と増加したタイミングでもありました。データの連携など、多数ありました。この時、自分は1人のSWEとして動くことに決め、いくつかの機能の開発を担当しました。短期で数多くの機能を開発したことによる問題が生じることもありましたし、これらのすべてをこのタイミングで開発するのが最善だったのかは今でもわかりません。紆余曲折を経てプロダクトは上手く機能するようになり、スーパーのお客様やスタッフの皆さんに価値を提供できる状態には辿り着くことができました。担当した機能たちのリリースが完了し、運用もメンバーに引き継げるようになったタイミングで、また開発から離れることになりました。事業機会が広がり、会社の規模も大きくなってきた時期です。複数の企業とパートナーシップを結び、さまざまな地域でサービスを提供できるようになりました。80名に増加しました。この時期は、前のフェーズで事業機会を掴んだことにより、会社に求められることが大きく変化するタイミングでもありました。会社として長期/中期/短期で何を成し遂げるべきか明確にし、計画を実現する体制もそれに合わせてアップデートし、体制を支える採用や人事制度の整備する必要がありました(詳しくは矢本さんのブログを参照)。開発組織としても、目の前の事業機会を掴みながらも、品質や拡張性の獲得といった長期的な課題に取り組む必要がありました。短期的な課題への対処としては体制の変更や開発プロセスの整備を進め、長期的な課題への対処としては開発を変えていく検証を行う組織を組成しました。アップデート、ミドルマネジメント、経営企画、HRなど、さまざまな面で成果が上がってきたことにより、自分によるマネジメントがボトルネックになることは徐々に減ってきました。今はここのフェーズです。プロダクトがこれからの事業機会に応えていくためには、いくつかの面で構造的な変更が必要なのですが、その変更をいかにして実現するかを探索するために今はコードを書いています。開発組織としても規模が大きくなってきており、システムの統治のあり方、進化の方向性の管理も大きな課題となってきました。これに対して、長期的に目指す開発の形に合わせて体制を検討しつつ、進化的アーキテクチャにおける適応度関数のような概念を導入し、プロダクト戦略を各開発チームが再現性高く実装できるようにすることにも挑戦しようとしています。引き続き、マネジメントとの二足の草鞋を履いた状態ではあるものの、マネジメントの委譲を進めることで、エンジニアリングと経営の間をリンクさせる役割にさらに集中していきたいと考えています。コードを書く時期/書かない時期これまでを振り返ると、「CTOである自分がコードを書くことが事業のボトルネックの解消につながるかどうか」が、意思決定のポイントだったように思います。CTOという立場を強調したのは、会社の経営に責任を持っている点や、組織への影響を及ぼしやすいという点など、他の役割とは異なる前提があるためです。今後もこの点を意識しながら頑張っていきたいと思います。この判断は組織にどんな人材がいるかによっても変わると思います。アーキテクト、EM、SWE、HRBPなど、などこれから組織に入ってくる人次第でCTOがやるべき仕事も変わってくるので、一緒にやっても良いかな?と思った方は、是非一度話しましょう。以下のページからカジュアル面談を設定できます。Operationsの川村さんです。