レイトステージスタートアップにCTOとして 参画しての10ヶ月

と、いうわけで今日は CTO っぽいアドベントカレンダー書きます。(この記事はスタフェスアドベントカレンダーのトリです! メリークリスマス!)

今年2月に、執行役員CTOとして、スターフェスティバル株式会社(スタフェス) にジョインしました。スタフェスは参画時点で11期、今年の7月から12期の始まったレイトステージスタートアップです。

さて、そんなスタフェスにジョインして約1年になるので、2020年の締めくくりとして、この1年やってきたことをざっくり書き起こしていこうと思います。
"CTO" としては3社目、超0→1からのM&A、10→100からのIPO、という経験をもちながらやってきつつも、これまでと全く異なるステージ・環境・ビジネスで、相変わらず試行錯誤を繰り返しつつ失敗をしたりうまくいったりしつつ、それでもこの1年で大きく下地を作ることができたのではないかとは思っています。

そういう意味で、CTO経験者が、次の全く異なる環境のなかでどのように立ち居振舞うのか、あるいは、ビジネスサイドの人材の厚い企業で、どのようにテックサイドの組織を作り上げていくのか(またそれは何のために)、という点においてヒントになるものがあれば、という思もあります。

とはいえ、特にオチもなく、今年やったことをつらつら書いている日記みたいなものなので (かつ、長い)、気軽に読み飛ばしてくださいね。

なお、なぜジョインしたのかというあたりは、社内のインタビューでも話させてもらっているので、興味がありましたら、ぜひ読んでみていただけると嬉しいです。ペタッ

※ さてさて、一応Disclaimerてきなアレでいうと、ここから、課題とそれに対する打ち手という話をするのですが、ここまで積み上げてきたものを否定するものでもなく「この先を作るため」のアクションの話です。
※ まあ、あとから入った人が「おれがやってやったぜ」的なアレは自分も好きじゃないんで、いつでもこういう HRT は大事にしていきたい、という想いを込めての1文です。(自分のことをよく知ってくれている人は、わかってくれる話ではあるのですが)

ジョイン時のスタフェスの状況

前述の通り、スタフェスは現在12期のレイトステージスタートアップです。スタートアップなのか中小企業なのか、と問われると、資金調達をしてIPOを目指しているという意味では、やはりスタートアップの部類に入ると思っています。

さて、ジョイン時 (2月) の状況をざっくりいうと以下のような感じです。10年積み重ねてきたものは大きく、事業も、組織も、文化も、あらゆるものが積み重ねの上にあるものです。

・ 会社全体ではアルバイト含め 350名程度 (シャショクルという販売スタッフのいる事業があるのでそのスタッフがかなりの人数)
・ 事業部(営業/運用) の人員が多く開発組織は10人程度、部として独立している
・ 大小合わせて "事業" の数はかなりあるが、もっとも象徴的な主力事業としては、弁当EC(あえてわかりやすく言うと)のごちクルとその関連事業
・ 取引高では3桁億に届くような規模のビジネスを持ち、それも順調に成長させてきている。

すべての説明をしていると、それだけで1記事になってしまうので事業の説明は超ざっくりですみません。でもまぁそんなかんじです。

前述のインタビュー記事でも話したとおり「これだけのアセットのある中にうまくテックを組み込んでいければ、ビジネスはもっと加速する!」という話をジョイン前からしていて、入社前の1月、代表の岸田さんから全社に「今年はプロダクトファーストでいく！」と宣言のかかった年でした。
このときのことは、入社前だったのでその時の社内の雰囲気までは把握していないのですが、ようするに自分は「その宣言とともに、じゃあやっていくよ」のためにジョインした、という見え方だったのではないか、とは思っています。(し、実際その宣言は、入社時にさせてもらいました)

ジョイン当初の課題感

いまとなっては、喉元すぎれば的な感じですが、当初、入社後すぐに感じたことをまとめます。

経営・マネジメント層の連動性が薄い:
意思決定がどういうレイヤーで行われているのか、社員からすると全然見えない。実際、岸田さん→各部管掌役員、の直接の1on1のなかでほとんどの物事は決められていたように思います。なぜソレをやるのか、何を目指しているのか、どこに向かう中で今どこにいるのか、そういう情報があまり見えないなぁ、と思ったのが正直なところです。

全社の状況が全然見えない:
当時使っていたチャットツール(特定ツールをdisる意図はない)は、Slackで言うところのオープンチャンネル的な概念がなく、全社的に、どこでコミュニケーションが取られているのかの把握が非常に難しい状況でした。
IT関連のものに手を入れるのは最低限にしよう、とは思っていた (でないと色々手と口を出しちゃうからw) のですが、さすがにどうにかしようと思いました。

開発部が社内受託状態:
他部署で決まったことがタスクとして落ちてきて、そのタスクをどう担当してやっていくかが割り振られ、それをこなしていく日々、という感じで仕事が進んでいました。
開発部は前CTOの力もあり、しっかりと開発チームとしての課題は認識していたし「こうなったらいいのに」というものはある程度持っていたがどうすればそうなるのかがわからず、結果、それを実現するだけのリソース (時間も、金も)を捻出できず、その状況からずっと抜け出せない、といった状況でした。(入社直後のメンバーとの1on1から見えてきたもの)
また、それにより、相対的に開発部の発言力の弱い状況、であったと思います。

つまりこれをどうにかするよ、というのがこの1年の具体的なアクションにつながってきています。

経営から動かす

今回、どこから始めるか、と考えた結果、代表との関係性も悪くなく信頼関係が築ける状態だと思ったので、まず上からいこう、というのが最初に決めたことでした。

まず考えたのは「取締役・執行役員の頭を揃えていくこと」。それも「プロダクトファースト」という宣言を実現していくために、自社の「ソフトウェア」がどういったポジションにあるのかを捉え、それをこの先どのような状況を目指していくのか、またソレを実現するためにどういう組織の体制を作り採用し、経営として力を入れなければいけないのか、の認識を合わせ、ソレに必要な箇所に人手と金をかけられる状況を作るのを第一に考えました。

最初の2-3ヶ月は「そもそも自分たちのもつプロダクトとはなにか」の再定義しました。

これがこの先につながる最も重要なアクションであった、と感じています。繰り返し議論することで、自分たちの「プロダクト」を、

・ 飲食店パートナーさんたちに使ってもらうもの
・ 物流パートナーさんたちに使ってもらうもの
・ 喫食者 (食事を求める人たち) に使ってもらうもの
・ 基盤 (社内で使い、あらゆるデータの集まるビジネスアプリケーション)

の4つに分類することができました。またその後の議論の結果、今どうなっていて、今後どうするのか、プロダクト全体の「あるべき姿」を定義し、経営で「それを目指そう」と握ることができました。

(まず自分でザザザっとiPadで絵を書いて、コレをもとに議論された。
... 清書されるまで3ヶ月くらいこの手書き絵が使われたw)

この議論をまとめることができたのは、その先「どこに力をかけ」「どこにかけないのか」をブレずに進めるために最も重要だった、と感じています。

同時に、役員会議体の整理を行い、執行役員以上のメンバーでの横の連携をするための場所を作りました。これにより重要な意思決定をできる限り早い段階でできる状況を目指しました。

・全社で進めるべき案件が1on1のなかに閉じられないように全体で意思決定する
・各部署で上がった問題を直ちに共有する
・各管掌役員から各部署に展開する
・さらに、その議事録をできる限り公開する (人事的なもの等公開できないものはあるものの)

「プロダクト開発部」を作りエンジニア組織を強くしていくにあたり「何をやっているかワカラン部署が偉そうにしている感」みたいなものができないように、きちんとこちらの考えていること共有する、という意図もあります。

最低限のツールアップデート

で、その次の話に移りたいのですが、一旦横道にそれて、とりあえず、お決まりの「全社 Slack 移行」をしました。(実はエンジニアだけもともと (ry など、よくある状況だった)

この辺は、超重要な話なんですが、今回は省略します。コロナによりリモートワークに対応しなければいけない中でもあったので、一気に進めました。多くのメンバーに協力してもらうことができ(アンバサダー的なものを各部署にたて、ススッと)、すんなり進みました (協力、リードしてくれたメンバーありがとうありがとう)。

小さなことなんですが、こういう「たかが・されど」系は着実に積み重ねていくことが重要だな〜とは思っています。

プロダクト開発部への統合

さて、プロダクトのあるべき姿、目指す姿の議論と平行でまず真っ先にやったのは「開発部」(当時は別の名前でしたが、要するに「エンジニアのあつまる部署」) を、「プロダクト開発部」にあらため、プロダクトマネージャー (PdM) (という定義も当初はなく、Webディレクター、と呼ばれていたのですが、それも改め)、デザイナーを大統合させることです。

依頼ベースのタスクをこなすのではなく「プロダクト開発」に関わるメンバーが一体となって共通の目指すものに向かって走れる状況を作るために、まずそれらのメンバーがひとつの統一された意思決定の元やっていく形をつくります。現在CPOであり共にプロダクト開発部を管掌している塩出さんは、スタフェス歴は長くありましたが、当時の課題感を共有できていたため、自分の考えにトータルで同意してくれていて、すんなりとこの形に移行することができました。

でも、これだけでは不十分です、ここからが本番です。

ロードマップとプロジェクト体制

タスク依頼型の開発組織から、プロジェクト体制でPDCAを回していく体制を作るには「なぜやるか」「どこにむかっていくのか」を、全社員の共通のものとして語られる状況を作る必要があります。

組織図上、同じ傘の下に入っていたとしても、そこができていなければ、結局は誰かの考えたものを単発でタスクベースで仕事を進めていく状況から脱することはできないからです。

というわけで、目指したのが↓というかんじ。

ロードマップ策定と平行して、そもそも自分たちは、プロダクトに対して何をやっていくのか、というところを「プロジェクトチーム」とし、部門を横断した人たちが1つのチームに入るという形を作り始めました。

プロジェクトに所属する PdM を中心に「ロードマップ」を作り、そこから、四半期ごとのマイルストーン (そこを目指すなら、3ヶ月後にはココまでできていないといけないよね、的なポイント) を定め、それを更にチケットやタスクに落とし込んでいく、というプロセスで直近のタスクを決めていく、という流れです。

もちろん、当初は、形だけ箱を作ってもそこに人がいない ... なんでこともありましたが、目指すべき姿を先に定めたことで、この半年で、もともと目指そうと思っていた形のロールはほぼ埋まり始め、各プロジェクトが「回り始めたな」と感じています。

実際動き始めるまではそこそこ「どうやればいいのこれ」感はありましたが (また、コロナやリモート化の中の新しい体制で動くことで、メンバーには多くのストレスをかけてしまうことにもなりましたが ...)、全体的には、以前よりエンジニアと、PdMと、話せてチームとして進められるようになった、という声も聞かれるようになりました。
さらに、あるチームでは、メンバーが主導してスクラム開発に移行し、定期的に振り返りをする体制を作ることで、チームの中であまり自分の意見を言わない傾向のあったメンバー同士も、積極的に「このチームはどうするとうまく動くようになるか」を議論し、実践し、振り返りを繰り返し、どんどん上手くなってきている、と実感しています。

・・・

ロードマップは、今では「1年間のものを半年ごとに更新する」という運用でやっています。1年先に実現したいものベースで物を語る、しかし目の前のものは解像度が高く、半年以上先のことはそこまでわからん、という状況が多いので、状況に応じて細やかに対応できるように、1年を待たず、半年ごとに更新するのが良いかな、と思いつつ、まだ2回目の更新なので色々と運用を試しているところではあります。

基盤アプリケーション開発、それはつまり大規模なリファクタリングとリアーキテクチャプロジェクト

さて、そういう体制を作ったことでできるようになったことが2つあります。

それは「直接的に売上に貢献しないかもしれない中長期的な開発に取り組みむこと」、そして「採用」です。

短期的な売上インパクトのない開発に取り組むことは、経営としては、なぜそれをやるのか、を都度都度見極める必要があります。
これは、単発のタスクベースで仕事をしていると「取り組んだものの頓挫」「そもそも取り組めない...」といった状況がよく起こります。

中長期的な取り組みを行うプロジェクトを発足させ、それをロードマップに組み込んでいくことで、軸をぶらさず開発に取り組むことができるようになります。

特に重要視したのは、社内の業務プロセスを担うシステム構築や、横断的な事業に影響のある社内基盤アプリケーションの開発です。
これを、経営の中で度重なる議論の末、しっかりロードマップに組み込み、重要プロジェクトとして位置づけることで、開発メンバーをアサインし、動かし始めることができるようになりました。

現在、年季の入って手がつけられなくなっていた管理システムとKintoneを「今欲しい、そしてこの先も開発を続けていける」基盤システムへと生まれ変わらせるためのプロジェクトが進行中です。

「未来には未来しかない」をスローガンに、もうすぐPhase 1のリリースができる、というところまできています。

採用

ロードマップと体制表を作ることで次に「人」が見えてきます。

・やりたいことに対してどんなプロジェクトを立ち上げれば良いか
・それを実現するためにどんなレベルのどんな役割の人が必要か
・そして何人必要か

このあたりを落とし込んでいくことで、採用計画を作ることができるようになります。

また、やりたいことや作りたい組織に対して足りない人材が明確なので、的確なJob Descriptionを作り、採用後のアサインやプロジェクト概要も含めた話を採用面談時に話すことができます。

メンバーにとっても、ここから1-2年かけて実現していきたいことにしたいて明らかに仲間が足りねェ ... ということが見えてくればリファラル採用にも繋がりますし、そこが具体的になればなるほど「自分の知り合いにこういう人がいるのだけど当てはまるんじゃないか」という話ができるようになります。

おかげで、今年、本当にいいな！思えるメンバーに何人もジョインしてもらいました。楽しい！嬉しい！

と ... まあ超絶うまく言ってる感満載で話していますが、まだまだ道半ばで、JD も書けてないものもたくさんあるし時間のさけていないところも多いので、がんばるぞ〜！という感じですね。

事業部体制の一部統合

さてさて、そんなかんじで、ようやく体制が整ってきてプロジェクトも動いてきてるので、いいかんじじゃねーか〜〜〜というところもありますが、まだまだうまくいってないところ、試したりやめたりしていることがたくさんあり、本当に常に試行錯誤やな〜と思います。

今試しているのは、もともと事業部所属だった運用メンバーのうち、プロジェクト体制の中でシンクロ率を高める必要のあるメンバーをプロダクト開発部の中でに組み込んでレポートラインとPJの動きを一致させること、です。

これは来年あたりにまた、うまくいったこといかなかったことなどを書ければ良いな、と思います。

(いつのまにか自分も事業も見ることになったりして、あれあれ、という感じですが、結構楽しくやっています 笑) 

結局CTOってなんなのさ?

さて、ここまでの話読んで「CTOの仕事とは」と思った人もいるかと思いますし「こういうことをやりたくない」人もいるのではないでしょうか。

で、自分が思うに、特に事業会社としての CTO としての仕事は、会社が「技術を用いてちゃんと結果を出せるようにする」こと、「(広義の) 開発チームが最大の結果を残せる状況を作り、そして結果を出すこと」だと思っているんですよね。だから経営とも話すし、予算も作るし、採用もするし、組織の変革もする。

「技術」を自分たちの思う通りに使い、技術的にも事業的にも新しいことにチャレンジし続けていく状況を作りたいなら、そのために必要なことを全部やるしかない、というだけの話で。

そういえばこのあたりの「CTOどこまでやるか問題」についてはまた別記事でそのうち書きたいと思ってます。

あ、もちろん、この中で書いたことは、もちろんすべて自分がやっているわけではありません。CPOと協力してやったり、エンジニアメンバーと一緒にやったり、経営メンバーで取り組んだりと、とにかく総力戦です。

次の1年へ

と、いうわけで ...

当初の想像通り長くなったんですが 笑、この10ヶ月振り返ると、もっとやれることはあったという気持ちはありつつも、まずまず下地は整ったな、という思いです。

しかし、緊張感もプレッシャーもあり、次の1年、間違いなく、ここまでやってきたことの真価の問われる1年、結果を求められる1年となるだろうな、と感じています。

ますます、気の抜けない感じになるな〜と思いつつ、チームも "いいかんじ" の状況で事業でも結果を出せる、そういうのが一番楽しいじゃないですか。それを目指していきたいですね。

(あ、エンジニア目線で振り返ってくれた記事は、メンバーがアドベントカレンダーにも書いてくれているので、ぜひこちらも。→ 2020年、スタフェスに文化が来た https://lanieve.jp/archives/850)

こんなかんじで、一緒に新しく色々事業を作っていく人募集しているので、興味のある方は、ぜひ、お声がけください！sotarok が仲間になりたそうに(なってほしそうに)あなたをみている！(PdM、フロントエンドエンジニア・バックエンドエンジニア (主に TypeScript, PHP, Go)、インフラ・データエンジニア、QAエンジニア、全体的に募集しています!)

よろしくお願いします！

良いお年を！メリークリスマス！