![見出し画像](https://assets.st-note.com/production/uploads/images/72746986/rectangle_large_type_2_5fea04ed1d44c38ec9b6ec4a69c6ea55.png?width=1200)
将来のCTOを迎えるために エンジニアリングマネージャーが半年でやったこと
カミナシでEM(エンジニアリングマネージャー)をしている宮本と申します。
カミナシには現在CTOがいません。
ただ、採用活動は進めておりますので、近い内に採用活動が花開くことを切に願っております。
本記事では、将来のCTOを迎えるにあたり、EMである私が直近半年で何を考え、どんな対応をしてきたかについてまとめました。
カミナシが求めるCTOとは
CTOを採用したいという話が挙がった際、カミナシは具体的にどういった方をCTOとして迎えたいのか議論になった事があります。
ここでよく議論の分かれ目になるのが、実務者のTOPとしてのCTOか、経営者としてのCTOか、という2つの観点です。
当然、両方の性質を備えているのが望ましいのですが、究極的にどちらの要素しか満たさざるを得ない場合、どちらを選択すべきか関係者の認識を揃えておく必要があると思います。
結論、カミナシでは経営者としてのCTOを優先したいという話になりました。
この結論から、最終的にWant部分は実務側である自分の管掌範囲になる可能性もあったため、現状の組織・体制を踏まえ、1. 将来の開発リソース確保対応、 2. 技術負債・リスク管理対応、3. エンジニア組織課題対応、の3点についてCTOが入社する前に少しずつ整備し始めようと思いました。
※カミナシには既にPdMがいるため、上図の内「プロダクトマネジメント」に関しては、技術負債の返却以外は自分の職務範囲外と切り捨てました。
1. 将来の開発リソース確保対応
現状の採用計画を見た際、「多少の増減はあるとはいえ、必死に頑張れば、計画に近しい状態は達成できるかも?」と考えると同時に、問題となるのは3年後以降の見えない採用計画の方だろうと思いました。
というのも、SaaSは巨大な開発組織が必要と言われており、カミナシに投資いただいているALL STAR SAAS FUNDの前田ヒロさんのブログでもSlackの開発への投資を例に挙げて言及されています。
そこで、各社の動きを調査し、3年後以降の世界についてどういう施策を今取るべきか検討しました。
・関東近郊以外の地域にある開発会社の調査
・新卒採用
・SIerへの発注による対応
などなど、様々な観点から調査したのですが、調査の過程で、マネーフォワード様、freee様、キャディ様のブログやニュースを見て、海外開発拠点の設立や外国人エンジニアの配属などグローバルでの開発体制構築の気運が高まっているのでは?という仮説が自分の中で生まれました。
グローバルでの開発体制構築は、個人的には3年後くらいに検討したいなと考えていたのですが、気運が高まっている時にこそ検討を開始すべきではないか?という考えに至り、経営陣に提案しました。
本件については、どこかで経過情報を公開したいなと思います。
2. 技術負債・リスク管理対応
私自身は、技術負債はどんなサービスにも必ず存在しているものと考えています。カミナシのプロダクトにも例外なく存在します。
サービスリリース直後には見えなくても、サービスが成長してデータ量やユースケースが増えると、自然と技術的な課題は顕在化します。
カミナシのプロダクトはtoB向けのSaaSですが、リリースして1.5年にも関わらず利用社数が急激に増えているため、早いタイミングで歪みが出始めようとしています。
技術負債を考える上で重要な観点は、各所で語られているように、それにどう対処していくかです。要は、どう付き合っていくかが重要で、今すぐ負債解消すべきなのか、機能開発を優先して負債解消を先延ばしすべきか、はたまた長期間負債を抱えるべきか、その判断が求められます。
金融機関からお金を借り入れると、B/S(貸借対照表)の負債の部に計上されるかと思いますが、プロダクトの技術負債も似たようなイメージです。
(負債が大きくなり過ぎて今の組織で返せなくなるとアウト、負債を早く返し過ぎて投資に向ければ稼げたであろう売上を上げられないのも組織にはマイナス)
負債解消のタイミングは、ビジネスの状況だったり、開発チームの技術力やアウトカムの上限値だったり、プロダクトの状態(動作速度やエラー発生頻度など)だったり、様々な要因によって変わってきます。
上記のような背景から、ビジネス側とプロダクト側で技術負債に伴うリスクについて管理・コミュニケーションが取れるよう、プロダクトリスク管理シートというのをnotionで準備しました。
(ある方からCTO業務の1つであると伺ったのも準備した背景の1つです)
上記のプロダクトリスク管理シートは、四半期ごとに開催する会社の戦略会議で、次の四半期以降で開発速度を落としてでも解消に向けて対処するなどを可視化・議論する材料として使っていきます。
3. エンジニア組織課題対応
本当は、エンジニア組織課題対応として、未来の組織拡大に耐えられるようにEM候補の採用・育成に注力したかったのですが、本件は他の2つの項目とは異なり、未来というよりは今にフォーカスした対応に終始しました。
というのも、昨年2021年の夏、新規プロダクト開発を開始する事になり、1つしかなかったエンジニア組織を2つに割る事になった所から話は始まります。
新規プロダクト開発に着手する云々は私が入社する前に決まっていて、どういう開発チーム・体制にするか私は関与していなかったのですが、既存プロダクトを0から開発したメンバー全員が新規プロダクト開発チームの方に行き、既存プロダクトは新参者ばかりという体制になってしまったのです。
チーム分割当時、正社員6名 + 業務委託2名といった開発体制でしたが、これを2チームに割り、更に、既存プロダクトに深い開発知見を持つメンバーが全員いなくなったので、既存プロダクトの開発が難航し始めます。
私は既存プロダクト側をメインで担当しましたが、チームを割った直後は、リリースする度に不具合を起こし切り戻しする、解消までに時間がかかる、その結果メンバーが疲弊する、といった状態で、お客様に価値を届けるどころかご迷惑をおかけしてしまうような状態に陥っていました。
そのため直近半年は、既存プロダクト側の開発チームの立て直しに注力しました。いくつか実施した施策の内、具体的に効果があったのは以下です。
(1) 不具合対応全般の巻き取り
(2) リリース回数の増加&リリース単位の細分化
(3) QA体制の構築
3-(1) 不具合対応全般の巻き取り
ここは力技感がありますが、とりあえず、私自身がほぼ全ての不具合問い合わせを受ける形を取りました。
私が全て1次受けする事で、基本は私で問題に対処しつつ、状況に応じてメンバーに依頼して問題対処にあたっていただく、といった体制にしました。これにより、不具合問い合わせ対応を適切にコントロールできる状態まで回復させました。
また、ここで大きかったのは、カスタマーサクセス&カスタマーサポートの方々の存在です。皆さんが適切に顧客とコミュニケーションを取っていただけるお陰で何度も助けられました。
開発体制的に、また、不具合の対応難易度的に時間を要する瞬間が都度あったのですが、そういった時も嫌な顔もせずに助けていただいて、本当に感謝の気持ちで一杯です。
3-(2) リリース回数の増加&リリース単位の細分化
チーム分割直後、当然ながらリリース回数が極端に減り、週1リリースされるかされないか、みたいな状態になりました。他部署から見ても、既存プロダクトを開発しているエンジニアは何をしているんだろう?みたいな印象も多少あったようです。
また、リリースして切り戻しする事が頻発していましたが、個人的に分析した限りでは、検証不足以外にビックバンリリース(全て出来上がってからリリースする事をここでは指してます)する傾向にある開発スタイルが原因と見受けられました。
以上を踏まえ、まずは毎週2回リリースする、リリースは小まめに行う、の2点を開発チームに依頼しました。結果、新規に開発する物については目に見えて不具合が減りました。
ちなみに、週2回リリースするようになった当初、稀に1つもリリースするものが無かった時があったのですが、そういう時は、私が無理やり実装してリリースするものを作り、リズムを途切れさせないようにしたりしていました。
3-(3) QA体制の構築
リリースして切り戻しする要因として検証不足がありましたが、開発体制的にそこまで大きく時間を割けないという側面もあり、早々にQA体制の構築を決めました。
ただQA体制の内製化は難易度が非常に高いため、PdM 兼 執行役員 兼 VP of カスタマーサクセスの宮城さんの支援の下、外部の専門企業に依頼する事にしました。
動き始めたのが2021/9からでしたが、実際に契約を交わして専門企業からQAのスペシャリストの方々に来ていただけたのは2021/11からでした。その間の約2ヶ月間は、カスタマーサクセス&カスタマーサポートチームの方々にリリース前の検証作業をご対応いただき凌いでいました。
2021/11からはQAのスペシャリストの方々に来ていただき、リリース前とリリース後と2回検証stepを設ける事ができたおかげで、リリースして慌てて切り戻しする現象はほぼ発生しなくなっています。
最後に
ここ半年を振り返りましたが、将来のCTOが入社されて立ち上がりやすいようEMとして対応できた事もあれば、現状の課題に追われて全く進められなかった事もあった半年でした。
ただ、開発チームを2つに割った当初の混乱期は収まり、CTOが着任しやすい状態にはなったと思います。
とりあえず、2022年も粛々と自分の役割を果たして参ります。
P.S.
Meetyやっておりますので、少しでもお話ししても良いよという方がいらっしゃれば面談しましょう!
この記事が気に入ったらサポートをしてみませんか?