初めまして、株式会社LEAN BODYでCTOとして仕事しております、garuと申します😈
昨年に引き続き、今年も自分の成長ログを書いていこうと思います！今年も目一杯成長できて「やばい!!このまま成長したら10年後の40歳になったらどうなっちゃうんだ!?」と思う日々です。冗談です。
良ければ昨年もどうぞ。
2024年はどんな年だったのか
三行サマリで書くとこんな感じ
- 書いたことない言語をマネジメントするということ
- 経営は得意分野のパズル
- CTOとして知っているべきセキュリティの話
書いたことない言語をマネジメントするということ
今年は大きくSwiftをKotlinとFlutterを勉強しました。CTOとしてエンジニアリングに責任を持つということは、書いたことないからわかりませんでは成立しないということだと思っています。常に勉強し、自分で環境構築し、レビューに参加し、自身の言葉で他者に説明することができる状態にする必要があると思っています。
僕はこれまでずっとWebエンジニアとしてのキャリアを作っていて、正直ネイティブの言語はまっったく馴染みのない世界で大変でした。とはいえREST APIを使ったアプリケーションである以上、挙動はwebとある程度同じ流れなので何とか喰らいついて理解することができました。
ネイティブ言語への不満（webにはある痒いとこに手が届く書き方）は色々感じましたが、まあそのうち解消されそうだなとか思ったり、こういうもんかー！と思うようにしてここでは書かないです。長くなりそうだし🫥
さて、色々自分なりにやったことない言語をやることが今年の目標で大達成できたのですが、全く同じことに対して記事にしている方がいたので、参考にしてみます！
技術的に設計開発などの観点で自分にできることは無いため、「何かエスカレーションがあれば声をかけてね」、といった態度を取ってしまいたくなります。
ヒアリングを通して、タスク分解が上手くできていないことも多くあります。
あるいはタスク同士に依存関係があり、先回りして進める必要があるとか、スケジュールを利害関係者と調整する必要が早期に分かることもあります。
ですね！EM業務で一番大事なのは関係者との整理をどこまで事前にキャッチできるかが重要になります。エスカレーションがあるかどうかは常に自ら取りに行く、取りこぼしたら声をかけてもらう。こういう姿勢がエンジニアの生産性を最大化できる環境を作る状態になると思っています。
どこかで説明可能にする必要がある
不都合があるなら何かしらの認識齟齬があるので、理由を整理して明文化し、ハレーションしないようにする
これは最初に考えた説明責任をしっかり持つことで自然と不都合に気づき、解消してあげることができます。大事ですよね。
何かしらの技術について1領域でも秀でているのであれば、技術的に支援できる余地があることも多いです
得意領域に比べて効率が最大で無いだけで、タスク分解などを通して全体感を把握して動ける分、エントリーレベルより有利
これもイメージ通りで良かったです。
「最悪自分がやれば良い」という選択が取れない
知っている領域だと内部と外部品質の両面から、何かしらの悪い予兆を察せるところが、限定的になる
リスクヘッジは厚めに取るしかない
スケジュール上のバッファー確保、利害関係者への期待値コントロール、不確実性が高いタスクの見極めとその着手を早める
これは気づいてなかったのですが、確かに自然とそうやってました。 不確実性を最前線で理解し、バッファーを持たせ、リリースするアウトプットを利害関係者にしっかり共有することを自分なりに意識してます！もしかすると、ここの部分が一番大事まであるかもしれないです😈。言語化されていて嬉しかったです。
細かい箇所は省きましたが、概ね自分が考えていたことが言語化されていたので助かりました！
経営は得意分野のパズル
ドヤ顔でタイトル書いてますが、ふと気づいただけのことです。弊社ではマネジメント層の能力に被っている箇所がほぼなく、各々が各々の得意分野に関してしっかりと任せる & 信頼しているように状況をしっかりと作れていてパズルのようにハマっていると感じました。
具体的には、弊社では経営を支えるチームとして以下の4名が大きく関わっています。
- CEO（経営、財務）
- CCO（プロダクトマネジメント、コンテンツ制作）
- COO（マーケティング、アライアンス）
- CTO（技術）
これがすごい良いバランスで、各々一定の経験の上でLEAN BODYに集まっているため、自分のできる最大の力を発揮しているように感じています。パズルのようにしっかりハマっていて、誰が何をするべきなのか色々と自明だなと感じています🧩
だからと言って何もかも成功しているわけではなく、むしろ苦労の方が多く、まだまだ自分ももっと成長する必要があるし、知らない知識が多すぎる & 勉強し続ける必要があると思うことが多いです。
CTOとして知っているべきセキュリティの話
CTOになるということは技術に関しての責任を負うことになります。なので、インフラに関する知識は当たり前のように必要ですが、これまた学ぶタイミングがない。。。
2024年はtoBの売上も上がってきて、外部の上場企業と取引をする際は監査が入りました。
私は技術の責任者として監査の条件を満たす証明を作成する必要があります。知りません、わかりませんでは許されません。
必然的にインフラを学び、整理する必要があります。かつ、セキュリティのインシデントが発生した際のシナリオを対応方法を整理し、事前に対応が必要な箇所は対応する必要があります。
セキュリティ対策として学び/整理した箇所は下記3点。
- インフラ構成図
- 現状の整理
- 実装を全て確認
- 現状の課題と理想を作成
- セキュリティ対策を全て洗い出し
- アラートの不足があれば追加
- アクセス権限の整理
- ログの出力場所の確認/整理/不足があれば追加
- ログの確認方法の整備
- インフラ請求書の監視体制を整備
- セキュリティのケーススタディ
- 勉強
- シナリオと対応方法を作成
余談ですが、監査等が入る際に重要視された箇所は下記2点です。セキュリティ対策とは別で対応しました。
- PMS組織図の作成
- 個人情報の取り扱い方法の整備
- アクセス権限の整理
- 誰がどのレベルでアクセス権限があるのか把握
- いつでも制限を変更ことができる状態にする
生産性を最大化し、アウトプットを最大化する
改めて、昨年引用した記事を今年も引用します。これは今後もずっと飽きるまで引用したいです。何度読んでも大事だなと思ってます。
・Product Manager：プロダクト資産を有効に活用し、利益を生み出す
・CTO：G/P（総生産力）を最大化し、アウトプットを最大化する
よく、この一気通貫の人材を探している経営者がいますが、まずは落ち着いて欲しくて。その人は多分「CTO」ではないです。
作ることと稼ぐことは元来違うフィロソフィーがある。
Product Managerはつまり、Revenue / Profitに責任を持つ代わりに、開発組織に対して要求をしたり、優先順位を変えたりする権限を持ちます。
CTO以下、開発に責任を持つチームは要求に対する結果＝アウトプットに責任は持ちます。
CTOや開発チームが優先順位をコントロールできる、要求に対してアウトプットの責任がゆるやか（期限を守らなくても良さげ、バグが沢山混入してても仕方がなさげ）、そういう場合は責任と権限のバランスが破綻している可能性がある。
100回声に出しても良いですね🙂↕️。僕が最初にCTOになった時のモヤモヤが全部言語化されています。
G/Pとは「流量」のようなもの、どれだけでっかい「水道管」なのか？みたいなイメージ。
G/Pの構成要素は「ピンのエンジニアのアウトプット力」みたいなもの（Velocity）から、チーム開発プロセス、カルチャー、外部要因による摩擦（μ）、自己組織化における改善係数（k）など、色々あります。
総生産力（G/P）を高めるためにエンジニア人数、それぞれのエンジニアのスキルの高さ、チームとしての出力、リテンションなど、わかりやすく言えば採用、研修、文化形成、開発プロセス改善など、G/Pを向上するために必要なロールは数多くあります。
CTOの大きな業務として、生産性を最大化するためにできることを色々考えつつ、人数も少ないので現場を動かしたり色々頑張ろう！と思う次第です。
2025年チャレンジしたいこと
MLチームの設立
実は2024年は1回だけ業務委託で機械学習エンジニアの募集をかけて市場感を調査した時がありました。
自分が大学院でMLの論文を多数読んでいたので一通りの挙動は把握していて、かつ社内でもレコメンドの実装をMLで行う場合の想定を色々検討してました。
ある程度探せばいるんですが、期待してる感じではないのが事実なのと、立ち上げを依頼できるクオリティの人は見つからなかった印象でした。
もちろん弊社の採用力の問題もあるんですが、それを棚上げしても見つからないなと感じました。
多分狭いコミュニティで流動的というか、採用力高い企業（MLエンジニアを新卒で採用できるレベルの企業）に吸収されている印象がありますね。
最初に記載した話と通ずるのですが、やっぱマネジメントしたことない領域の立ち上げなので一定任せる必要があって、そこのクオリティの担保が問題なんですよね。
難しいです！
メンター見つけたい
去年も書いたんですが、メンターを見つけられた良いのかもしれないと思うことが稀にあります。
僕個人としては悩んでる時間こそ成長しているのでメンターに答えを出してもらうのは長期で見たら成長を阻害してるだけだなとやんわり考えてる節があります。
僕自身頼るのが下手とか、メンターなんて結局責任を取らないので何でも言いたい放題やろとか、プライドもあるし全否定されたら嫌だなとか、色々余計な感情もあるんですが、何とも言えないですね。
一方でメンターがいると、近道があるかもとは思いますね。マネジメント、エンジニアチームの成果の出し方、データ分析基盤の方向性、組織拡大のイメージ、生産性の評価や向上するためのアイデア、MLエンジニア採用戦略、新卒採用のイメージ、など聞こうと思えば無限に聞きたいことはあるんですよね。
なので、メンターがいなくても成立するのは現状のポテンシャルで乗り切ってるだけでどこかで限界が来そうだなという印象はやっぱりずっとあります。
限界とは、、、楽しみですね😈
総括
ということで2024年も振り返ってみました！飽きるまでやります。
目安は5年目までやりたいと思ってます🫡
最近はWebアプリケーションエンジニアの採用頑張ってます！！
webアプリケーションエンジニアはがっつりマネジメントしたことある領域なので、多少経験あればめちゃくちゃ成長する環境を提供できる自信ありまくりです！
ためらうな、押せ！！！！
