見出し画像
Photo by kei_okazaki

小さな会社のCTOの存在意義

かずへい

こんにちは、M&AクラウドでCTOをしていますかずへいです。
CTOA Advent Calendar 2020 の4日目に参加させていただいています。
錚々たるメンバーのアドベントカレンダーに枠を頂いて大変恐縮です。


はじめに

つい最近以下のツイートを見てまさに自分のことだよな〜と思って考えていました。

ここで書かれているたくさんのCTOですが、ここ最近のスタートアップ投資の増加によってたくさんのスタートアップが立ち上がっており、会社の数だけCTOと名乗る人が増えているという話ですね。自分もその一人です。

上の記事を見る限り、実際にスタートアップへの投資は社数、金額共に伸び続けているので、これからもCTOと名乗る人はどんどん増えていくでしょう。このようにして増えたCTOがCTOという肩書をつけて働く意義は何なのかという私見を書きます。

自己紹介

私はM&AクラウドというM&Aのマッチングプラットフォームを運営している会社にいます。

買い手企業が掲載して売り手が売却の交渉を申し込むという、M&A版のリクナビのようなサービスです。事業承継問題の解決策として、また、増加するスタートアップの出口戦略として、これからM&Aは更に注目される業界になります。そして、そこをテクノロジーの力で改革していきます！

会社のメンバーは全社員28名、開発チームは7名なので、先日のDMM松本さんの記事でいうところのスタートアップ期からグロース期に当たる組織に属しています。2018年1月に3人目のメンバーとして入社してから大体4年くらい経ちます。

CTOとしてやっていること

私の会社のフェーズだと、そもそも全ての時間CTOとしての仕事をしているわけではありません。やっていることは大別して以下のような感じです。

・ITのなんでも屋としての仕事
・エンジニアとしての仕事
・開発マネージャーとして仕事
・CTOとしての仕事

サービス最初期は本当になんでもやりました。サービス作ったばかりの頃はCSの部署もなかったので、自分でユーザーさんに電話をかけて、パスワードの再設定のやり方を説明したりしていました。
また、エンジニアもまだ5名なので、今でもバリバリコードも書いてますし、メンバーとの月に1度の1on1もやっています。

そしてCTOとしての仕事ですね。次から書いていきます。

CTOとしての仕事は決まってないことを決めること

いきなり結論になってしまうのですが、CTOの仕事は、技術視点で会社が成長できるようにあらゆることを決めることだと思います。

創業まもなくから入った場合は特にそうです。大きな会社であれば、既にいるメンバーが作り上げてきたいろんなルールだったり、会社、部署、チームの方針というものができていると思いますが、それがありません。

会社レベルでいうと、どういう会社にしたいのか。どういう人材の構成にするのか。社員中心なのか、業務委託中心なのか。どれくらいのスケジュールで人を採用していくのか。どういう人を採用するか。どれくらいの給与レンジで採用するのか。

プロダクトレベルでいうと、どうやって事業を数字として分解するのか。どこの数字から攻めていくのか。プロダクトのロードマップをどうやって敷いていくか。どうやって数値を計測していくか。

開発チームレベルで言うと、どうやってチームを分けるのか、技術で分けるのか、追っているKPIで分けるのか。何の開発言語を使って、ブランチ戦略はどうで、リリースフローはどうなっていて、一週間に何回リリースするのか、どれくらいのサービス停止や不具合が許されるのか。

こういったまだ決まっていないことを見つけ出して決めていくことが、後々自社の文化だったり、強さだったり、魅力だったりにつながっていくということを最近強く感じています。

違和感を大事にする

CTOという肩書で仕事をする以上、開発マネージャーとして以上の仕事を期待されていると考えるべきです。

それはずばりテクノロジーの血を自社に入れることだと思います。

社内で何らかの議論や決定が行われているときに、技術視点で自分が違和感を覚えていたら異を唱えることです。

その違和感というのは、長期的に見てもシステムでスケーラブルにすることができないような煩雑で再現性のないオペレーションが社内で行われている事かもしれません。

その違和感というのは、情報をクローズドにするような、社内で情報格差を生みメンバーの自律的な意思決定を阻害するような事かもしれません。

そういう違和感を感じ取ったときに意見し、意思決定に介入することで、自社にテクノロジーを浸透させていくことが大事だし期待されていると思います。

実際に自分が決めたこと

実際に私が入社してから決めたことの中で思いつくことをざっと上げてみます。
・どういう開発組織がよいか
・採用要件の策定
・採用フローにコーディングテストを入れること
・採用フローのコーディングテストをやめて技術ディスカッションに変えたこと
・会社で導入しているツール類(Slack、esa.io、Zapierなど)
・Slackの使い方
・メンバーのパソコン等の機材
・サービス初期のインセプションデッキ
・理想的な開発フローの文書化
・サービスのKPI分解ツリー
・Redashのサーバーを立ててデータ可視化
・1on1用のドキュメントテンプレート作成
・アプリケーションの技術選択→AWS/PHP/Laravel
・アプリケーションの設計方針→3層+ドメインモデル
・アプリケーションの技術選択の変更→AWS/PHP/Laravel+TypeScript/Nuxt.js
・週1で設計の勉強会をやること
・レビューのルール
・リリースフローをGitFlowからGithubFlowに
・技術ブログを開設して当番制で回すこと
・Qiitaの投稿を推奨すること
粒度もバラバラで雑多ですが、上から下まで決めていくことで組織が理想的な状態に近づいていくと思います。

一つの例として、どういう開発組織がいいかというのを自分が初期に図にしたものがあります。

画像1

この図は良い仕組みで良いチーム、良い成果物、良いプロダクトを作り発信していけば組織が成長していけるという図です。

実際に、私の開発チームは「良い仕組みを作ろう」「発信しよう」という意識が強いなと感じていますし、その結果、弊社から4名がPHPカンファレンスで登壇することになりました🎉

こうやって、決めたことが後から入ってくるメンバーの手で実現されていくということがあると、感動しますし、それがやるべきことなんだなと実感します。

小さな会社のCTOの意義

ここまで書いたとおり、CTOの仕事は技術視点でものを決めることなので、小さな会社のCTOの意義というのは、会社が小さなころから技術視点での意思決定が必要かどうかということになります。

これはテクノロジーで会社を成長させようと考えている場合には絶対必要だと考えています。組織の力学は多数決だと思うからです。

例えば開発チームの誰もテストを書いていない状態から、全員がテストを書いている状態にまで持っていくには相当な時間が掛かると思います。そこには既にテストのないコードがあるはずなので、既存のテストコードを追加していくところから始めないといけませんし、他のメンバーにもテストの有用性を教え、納得して手を動かしてもらわないといけません。

逆に最初から常にグリーンになっているテストが書かれたソースコードがそこにあり、メンバーみながテストを書いていれば、当たり前のように新入りのメンバーもテストを書くよう努力するでしょう。

これと同じで、組織の考え方や行動様式は多数決で決まるところがあり、メンバーが増えるほど覆すことが難しくなります。

より早い段階から、意思決定に技術的な視点を入れていくことが必要です。

また、CTOが増えるということはエンジニアの思想が入った会社が増えるということです。それはたくさんの素晴らしいITサービスを生み出すことに繋がり、エンジニアの働きやすい会社が増えることにもつながると思います。

このように考えると、もっとCTOという肩書を持つ人が増えれば良いなと思います。

まとめ

小さな会社のCTOの存在意義について私見を書きました。

自分の結論としては、小さなときからCTOいたほうが良いし、もっと増えれば良いんじゃないかな、ということです。

もちろん「小さな会社の」なんて言わずに大きい会社にも増えたほうが良いと思ってますし、自社も大きくしていくぞ〜と思っております。

この記事が自分と同じような小さな会社のCTOの励みになったり、これからキャリアの一つの選択肢としてCTOを考える方の参考になればと思います。


この記事が気に入ったらサポートをしてみませんか？