初めまして、株式会社LEAN BODYでCTOとして仕事しております、garuと申します😈
2023年はCTOになり、想像以上に幅広く動くことができました。
もーーこれ以上はないし、ここからは楽していこう！！...とはなりません(´・ω・｀)
僕はCTOという上り坂をこれからずっと登る道半ばに来ただけです、頂上はまだ遥か上にありそうです。
さて、今回は会社の拡大や採用活動にしっかりと目を向けていけるよう、今年の自身を振り返り来年に繋げてみようと思います🔥
2023年はどんな年だったのか
1年の振り返り
1年の振り返りをここに書きましたが、あまりにもつまらなかったので省略しました。興味があればどうぞ😵💫
自分の活動にフォーカスします。厳密に書くなら、マネジメントとして行なったことや、社外との協業で行なったことや、採用活動など本当ーーーーーーに色々なことをしております。
1~3月
エンジニアマネージャー（EM）になりたてで、色々と自分なりに何かしていたような気がしますが、よく考えると当時は目の前のことを色々と進めることに精一杯だったので、そこまでEMっぽくないというか、勢いがメインだったなと今気づきました🤔
なので、自分でやるべき仕事と任せるべき仕事の線引きが上手くできておらず、少し手足をバタバタしてる時期だったような気がします。
4~8月
PMとして仕様を書き、デザイナーを作成してもらい、EMとしてエンジニアメンバーをアサインする仕事をしていました。長いキャリアのどこかのタイミングでPMっぽい仕様を書いたりする仕事をしてみたいと思ってたのですが、まさかこのタイミングだとは思ってませんでした👀
9~12月
CTO兼EMとして動くようになりました。社内でもCTOになった公表があり、より自覚と責任感を感じて仕事を動かす時期になります。こういう記事を書くのも、今後の採用活動の1%でも足しなればという意識から書くようになります。仕事内容としてはPMの業務が外れたので、よりEMとして動くことができるようになり、リファクタリングなど技術レベルで行いたいと思っていたことを徹底的に動かすようになります。
ここまで書くと、CTOだったのって最後の4ヶ月じゃん！という感覚になりますが、これは僕的には少し解釈違いなんですよ。僕はCTOってのをポジションではなくロールとして捉えていて、1月に社内で唯一のエンジニアマネージャーになってから、エンジニアリングから経営を考えた動きを行えるようになる & 経営陣からエンジニアリングに関する相談が発生してる時点で実質CTOだったなと解釈しました。
つまり僕的にはEMのロールでも、採用活動は行えますし、経営戦略会議に出ても基本的には成立する状態にあると思っています。所詮CTOとしてのポジションを置くメリットなんて、採用活動でアピールになるとか社内での動きにメリハリがつくぐらいに（現状では）捉えています。
CTOとエンジニアマネージャーの違いを意識する
僕の解釈なので、どう思うかは人それぞれだと思います。
とはいえ、ロールとしての意識を強めることで権限委譲の明確な線引きができ、権限委譲を行いやすくなることでメンバーの成長につながると僕は思っているので、整理してみようと思います。
↓イメージはこんな感じ
CTO : 経営に関してエンジニアリングから会社の成長を支える
エンジニアマネージャー : プロダクト開発に関してエンジニアリングから事業の成長を支える
経営に関しては、CEOが必ず企業にはいるので、本質的にCTOがいなくても会社は成長すると思います。ここがCTO不在の企業が世の中に多い特徴だと思います。かつ、「経営に関してエンジニアリングから会社の成長を支える」なんてどうすればええねん！ って僕が一番思ってます、普通に難しいです🙁
ですが、どうすれば良いのか次の資産と売上の違いを意識するのセクションで少し深掘りしてみます。
エンジニアマネージャーに関しては、基本的にどの企業でも必要になると思います。開発を外部に依頼するなら必要ないですが、それはもうメリット/デメリットなのであまり深掘りしないです。
資産と売上の違いを意識する
上記の通り、経営を支えるエンジニアリングについて悩んでいた時に、1つの記事に出会います。
ビジョナルのCTOの方が書いたCTOの頭の中：技術を財務で表現するという記事にあった、↓の画像が非常ーーーーーーにしっくりきました
記事の内容を少しずつ抜粋します。
Product Manager：プロダクト資産を有効に活用し、利益を生み出す
CTO：G/P（生産性）を最大化し、アウトプットを最大化する
Product Managerはつまり、Revenue / Profitに責任を持つ代わりに、開発組織に対して要求をしたり、優先順位を変えたりする権限を持ちます。そのためにCTO以下、開発に責任を持つチームは要求に対する結果＝アウトプットに責任は持ちますが、直接的にRevenueやProfitに責任を持つことは出来ません。なぜなら、P/Lへ直接影響させられる権限を有しないからです。
確かに！僕はロールに対する意識が多少強いので、かなり僕の考えるCTO像の解像度が上がりました。このCTO像をベースに今後も考え方を整理していこうと思っています。
生産した結果だけにコミットする開発チームは「外部ベンダー」とあまり変わらないということ。取引コストだけ社内の方がコストカット出来ますが、コストセンターになります。機能提供チームと割り切ればそれもひとつの戦略ですが、コアとなるシステムを開発し続けているチームには生産性の指標も入れて、事業全体のROIに効果をもたらすようなゴール設定をしていくことが強い技術組織を作る要素となるでしょう
難しそう！でも言いたい内容はわかる気がします。今後より意識していきたい
仮説としてProduct Managerの仮説が一定確率で当たりを引くとしたら、出来る限り多くのアウトプット（Deploy）をスピーディに行う開発チームがより強いと考えられます
これはめっちゃそう！
技術負債はあくまでも「B/S」に存在します。負債ですから。負債を返済するべきか、いやいや負債をさらに増やしても突っ込むべきか、こいつは経営判断レベルに難しい話です。少なくともProduct Manager（PLとBSにまたがって責任を持つ）と、CTO（BSとGPにまたがって責任を持つ）が議論してProduct Managerの権限のもと、優先順位を変更するようなプロセスが理想的な状況です
なるほど、技術負債を経営レベルで本質的な負債と考えるのか。僕はどこかエンジニアとして技術負債を自分たちにしか見えないものとして返済するタイミングの差し込みを様子見していましたが、会社として負債をずっと抱えることがマイナスだと考えれば、返済するタイミングの差し込みもより具体的にイメージしやすいと感じました。
他にも金言が多いですが、割愛します。僕は月に1回読んで、暗唱できるまで読もうと思ってます😈
素直かつ謙虚（驕らない、低姿勢）
顔はそうでもないんですが、僕は生粋の日本人なので、こういうのは大事だと感じています。どうしても立場上、自分の発言の方が正しいと思われてしまう可能性があるので、常にメンバーと意見を交換できる姿勢を持ち続けたいと考えております。
そしてこれはLEAN BODYのエンジニア組織でも、マネージャーに求める姿勢として大事にしていきたいと思っております。僕は企業の継続的な成長は人材の成長とセットで発生すると考えており、人材の成長は上司からの吸収と意見交換が最初の一歩だというロジックです。
できない/やりたくない理由を探すよりも、どうすればできるのかを考える思考のスイッチ
なんだかんだあっても人間なので、無理そうだなとか気が乗らないなと思う相談も探せば色々あります。思考回路って単純で、食べたくない野菜は食べたくない！ みたいになってる気がしていて、どうすれば食べられるのか？ が思考として抜けがちな印象があります🥕
僕は少しでもやりたくない/できないと思ったら、思考停止してない？どうすれば実現できるのか考えた？ と自問自答する思考スイッチを発明しました。これにより、より相手とのコミュニケーションで、どうすればできるのか、でも自分はooがネックでやりたくない/できないと考えているという説明を行うことができます。
会社の経営でコミュニケーションは非常に重要な役割を占めており、その精度が生命線に直結しております。少しでも良いコミュニケーション方法をより模索したい考えております。
今後チャレンジしたいこと
会社の拡大、採用活動の強化
当たり前のことですが、声を大にして言いたいですね😎
僕は会社の成長と人材の成長/採用はセットと考えております。人材の採用に関して大きく課題だと思っていることは、とにかく発信が少ないので、候補者にとって魅力に感じる材料が少ない ことだと考えております。なので2024年は色々と発信を増やせるようにしていきたいと思っております！
1%でも採用角度が上がるなら、絶対にやるべきです！
あと、CTOのメンターやってくれる人も見つけられた良いな〜と思っています。正直、まだまだ自走の範囲でチャレンジできることが多く、誰かに相談しなきゃ解決できないことはないのですが、もしかしたら、こんなに泥臭く自分で頑張らなくてもショートカットできる楽な道があるのでは？ とたまに思います。
企業の継続的な成長を支えるエンジニア組織のアップデート
プロダクト開発で成長し続けることが基本的に大前提であり、それを一番に考えているのですが、それ以外にも必要なチームが増える可能性もあるなと思っております。
例えば① : インフラチームの設立
プロダクトが複数になれば、僕が全てのインフラを管理することはできません。ですがインフラコストの整備や改善などに目を向けるインフラエンジニアは必要になる可能性があると考えております。
例えば② : 共通基盤チームの設立
共通基盤の実装を進めることで、認証等の実装を一元化し、新規事業の実装工数を減らし、セキュリティに関しての整備を強化する等の意思決定があっても良いかもしれません。
例えば③ : ライブ配信基盤チームの設立
ライブ配信の基盤にVimeoを使っているのですが、これを内製化するためチームを設立しても良いのかもしれません。ストリーミングの基盤にAWSを使う可能性はあるかもですが、Vimeoよりかは安上がりになるかもです。
例えば④ : AIチームの設立
レコメンド機能の実装などには、機械学習の実装など必要なものがあるかもしれません。またChatGPTのFine-tuningを行なってもらい、LEAN BODYのAIアシスタントを実装しても良いのかもしれません。
どれも急にやることはできないのですが、10~20%ぐらいのイメージはできており、いつでも動き出せるように心の奥にしまっております。
スクラム開発
これは経験がないので、本当にやりたいことなのか、手段と目的が逆転してないか、少し不安になります🥶
ですが、スクラムは大規模開発との相性が良かったり、企業の拡大に向けて必要になるタイミングがあるのかもという感覚もややあります。
色々な記事を読んでみました
- （Sansan）1年で6倍にメンバーが急増したエンジニアリング組織の変遷と判断
- （atama+）スクラムマスターって実際何しているの？
- （ミラティブ）開発組織にはじめてのスクラムを導入する
- （Retty）「全社で大規模スクラム(LeSS)移行して1年間」 #RSGT2021 での質問に、Retty執行役員が全て答えました
- （SmartHR）フィーチャーチームについてまとめてみた
僕の感じたメリット/デメリットは↓こんな感じです
メリット
* 組織の拡大や大規模開発と相性が良い
* それぞれのロールが自明である
* スプリントを意識した開発体制になるので、生産性の指標がKPIにできそう
* エンジニアが開発に集中しやすい
デメリット （になりそうなことを予測して書きます）
* エンジニアが開発に集中しすぎて、アジャイル開発として軸が弱くなりそう
* POと開発チームのコミュニケーション不足がプロダクト全体の生産性を下げそう
* スクラムマスターのロールを作ることが難しそう
* 開発チームは自走する組織図になるので、従来のマネージメントやメンターというロールの役割が弱くなってしまい、人材の成長や評価制度の整備などの観点でボロが出そう
ふむ、険しい道のりになりそう...というか本当に全然やったことないので、イメージできん(´・ω・｀)
総括
って感じでした！
採用活動を引き続き行なっていくので、ぜひ興味がある方ご連絡くださいー！
https://herp.careers/v1/leanbody/aKFjptBHFhUL
ためらうな、押せ！！！！
