はじめに

以前、参加したセミナーでのメモになります。
詳細については以下の記事をご覧ください。

sansanはまだやることあるの？と質問をよくもらう

プロダクトの開発は機能を追加していくだけではない。
コンセプトを変えて行っている。コンセプトを変えるというのは

プロダクトの世界観
ドメインのモデル
DB
アーキテクチャ
が変わること。

これらを変えていく上で行ったので開発組織を変更したこと。
これまでは事業部組織だったが、2022/6/30に変更をした。
マルチプロダクトな状態だとプロダクト間でのコラボレーションがあり、事業部を跨ぐと大変になるため機能別組織にした。

開発組織の規模感は、sansanで5,60人、Eightは3,40人ぐらいになっている。

事業別から機能別に変わったらどのような変化があったのか？

sansan事業部は200人ぐらいおり、メンバーには不安があったと思う。
レポートラインが変わり、自分の上司が違う人に変わった。
初めからガラッと変えるのではなく、これまでと変わらないやり方でやってほしいとお願いをした。「徐々に変化させるところは変えるから慣れてほしい」とお願いし、ソフトランディングをしていった。
その後に開発プロセスを統一したり、レポートのやり方とかフォーマットを統一したり、開発のパフォーマンスを統一したりを今やっている。

CTOについて

「マネジメントとは何か？」「実際どんなことをされて今いますか？」
会社の規模感、役員からの期待によるが...

開発力の最大化と効率化に尽きる
- 採用することでヘッドカウントを増やす
- エンジニアの戦闘力を上げる
- それをどうやって測ってレポートして評価するのか

これがマネジメント。

開発のどのレバーをやれば上がると思う？

エンジニアの生産活動を図るのは答えはないと思う。でもなんらかの評価をしないといけない。
そうしたら、メンバーの手応えになるし何に努力をしたらいいのかわかる。
完璧な数値にするのは無理なので近似値を出すしかない。

例えば見積もりに対してどうだったか振り返りをする。
でも、その時に見積もりの精度がとなるが、精度が重要ではなくて常に同じ精度であることであれば測れる。
誰か1人がやるとか、固定の複数人とか。
そうすると、その見積もりより早く終わるチームや遅いチームが出る。
そこで何ができるから早いのか遅いのかが傾向がわかってくる。
この測定で成長につながる。

開発以外のタスクが出てくるが、開発以外の時間も含めて1日の時間をつけてもらっている。
そこで、開発に時間が避けていない時は減らせないか調整したり、運用が30%になると多くないかとアラートを出したり、それは困難なアーキテクチャだったらそこを変更したら全体でコスト下げられるとか手を打つ。

CTOに期待されることとは？

CTOはメンバにとってどんな存在？

経営に対して技術で結果を出すこと。
課題を自ら設定して、解決するのが役割です。

技術以外で関わることってある？

sansanだと今年(2022年)にVPoEを立てた。
BtoBを営むとエンタープライズの顧客に売りにいく時、技術の責任者を連れてこいというのがあるのでセキュリティの話とか安定した運用体制についてとか説明することはある。

組織拡大のタイミングはいつがいい？

エンジニアリングに関していうと、採用は常にアクセルをベタ踏みで採れるんだったらとりたい。
カルチャーフィットなどはあるから全員は無理だが。
開発って先行投資になる。投資をしないと後続のビジネスグロースにつながっているのかはPdMの責任で、グロースに繋がったのかどうか振り返っていく必要がある。

どういったことをやってきて採用がしやすくなったとかあるか？

BtoBサービスはエンジニア界隈だと知名度が本当に低いです。
エージェントを使っているが、エージェントに直接会って何がしたいのが何を実現したいのかを熱量持って伝えて協力を仰いぎ、泥臭く努力の積み重ねをした。
外部への露出も増やしてsansanを知ってもらったり、金髪だから顔を覚えてもらってりとか。
採用のKPIは初めはなかったです。

CTOが採用のOKRを持った方がいいのかどうか？

CTOは生産力を上げることがミッションだから人を採用することも方法一つだと思うから必要だと思う.
人事のOKRと自分のOKRをガッチリ合わせてやっている。

組織拡大後のメンバーとの最適なコミュニケーション方法とは？

なんのためにコミュニケーションが必要なのかによる。
健やかに開発できるかな？心理的な安全性があるかなとは重要ではある。
一方で組織、経営という感点でいうと、エンジニアがガンガン開発できていてメンバーが成長するステップがあって、人がやめないであればいい。極端に言えばそこには心理的安全性は無くたっていい。
そこで、人がやめているとかエンジニアの成長がないといった時にはコミュニケーションをとったりする。

ハイパフォーマーは外から持ってくるより中が育てた方がいいと思っている。
成長のためにはチャレンジとフィードバックをするコミュニケーションが必要だと思う。ツールは1on1が使うことが多い。
マネージャー視点で、ここはいいんだけど、ここはもっと伸ばしてほしいんだけどなを言語化して、成長するイメージを持ってもらえるようにする。
例えば「設計の能力をあげてください」だとできなくて、こういった場合にこういうことができるようにしてください。n回の場を用意するのでその中で1回でもよくできたら成長したって判断できるとまで分解してあげないと。

当時は2~30人と1on1やっていて、その人との関係性によるが隔週だったり月一だったりその人とどれくらいしたいの認識があった頻度。
プレイヤーの1on1では技術ごとが多くなるし、マネージャーの1on1はなんで判断したんだけってマネジメントについて、一貫して成長することに対してフィードバックをする。

マネージャー候補の育成法　

マネージャー候補へマネジメントの権限委譲

セーフティーネットを貼って上げることが大事。
委譲された立場からは今までやったことないことをチャレンジしてもらうこと。レイヤーが上がると抽象度が上がる。
トライをして失敗して成長する。答えがないものだし。そこで最悪失敗しても最後に自分が責任取るからを作る
事前にレビューをしてgoを出すとか、不安なら事前にレビューなげとか。

CTOが開発からマネジメントへ回るタイミングは？

開発にいられるだけの時間がないくなったら離れたらいいと思う。
CTOが離れると問題がある状態ならその体制自体が改善するべき。

エンジニア組織ならではの

評価で注目すべき点

会社がエンジニアに何を求めているのかを整理する必要はある。
評価はキャリア形成と一緒のもので、より大きな影響を与えられるようになってほしいだと思う。

例えば、より大きな設計ができるようになってほしい、意思決定できるように、多くのマネジメントできたりなど広さ、深さ、とか
どの深さだとこのグレードだよと明確にすることが必要だと思う。

フィードバック方法

目指すところを言語化して本人と握って、途中経過を細かくフィードバックする。
できるているね、できていなければなぜできていないのかを伝える。

SaaS事業のエンジニアとして、顧客目線で考えられることの大切さ

顧客目線もそうだが≒で事業、ビジネス目線が必要。これがないと意思決定ができないと思う。
コンビニバイトのように決められたことをやるのではなくて、判断して意思決定をすることがサラリーだと思う。

技術的なa,bのどっちがいいかの判断は技術的なものは判断が簡単。実際どっちでもよくて、ただなぜ難しいかは事業的な効果や期待などの変数が増えるから判断が難しい。難しいから給料も多い。
エンジニアでもビジネスの背景を知らなければ判断もできないと思う。
仕事をしてくださいってだけの話。

スケジュール案を作ってきて「ダメです。これが抜けている。考慮できてますか？」というフィードバックをして問答をする。
考慮できていてクリアしたらグレードがアップするとか。

組織への事業戦略コンテキストの浸透方法仕組みかの最適なやり方は？

なんで浸透させたいんだっけによると思う。
仮に浸透させてなくてもガリガリいくならそれでもいい。
例えば、これが問題なんですとかをより解像度あげると、それを解決したらいい。