生え抜きでなくても活躍したい
前口上
日本企業の雇用形態は伝統的メンバーシップ型雇用から、ジョブ型雇用に変わったと言われることもありますが、割合歴史の浅いIT企業においても移行は完璧にはできておらず、とりわけ管理職やシニアポジションの募集をしていないという企業はちらほらみかけます。そういった企業では一担当として入ってからの昇進が基本的キャリアパスです。
管理職の評価が難しいというのもあるのですが、アメリカのTech業界では数年での転職が普通かつそれでも回っているということもあり、日本が技術立国するためにはそういった人材の互換性というか、シニアメンバーを受け入れる土壌が必要になってきます。他社で十分活躍している人を現在のロールより低いロールで雇うのは普通に考えて厳しい。
企業再生の案件ではプロ経営者が経営のうまくいっていない企業にジョイン後100日以内に具体的な事業再生の計画を建てます(100日プラン)。それにならってCFOがスタートアップにジョイン後100日プランを企業ブログに書いていることもあるのですが、CTO、VPoEが100日プランを提示する例はあまりなく、今回自分だったらどう動くかをまとめておきます。
全ての人から話を聞く
PEファンドが不採算企業を買収する際、立て直しのスキームとしては、元いた経営者が続投するというよりは、ベテランCEO、プロ経営者を外部から連れてきて経営陣を入れ替えるというのが一般的なスキームになります。
CTOが仮に取締役CTOだとするならば技術的な強みをいかして事業を推進するのはもちろんなのですが、会社を経営する経営者としてのマインドも重要になるように思います。そういった意味で昇進でなく転職で参入する際の動きとしてプロ経営者の動きは一つのレファレンスとなります。
プロ経営者の最初の動きとして有効なのは今まで働いていた人にヒアリングするということです。会社規模にもよるのですが、働いている全ての人と1on1するという方もいます。少なくとも全てのレイヤーの人の話を聞くことは重要で、それにより解像度が上がることもあるでしょう。
エンジニア全員にアンケートをとってみるといいかもしれないですね。項目としては以下のような感じでしょうか
- 担当している仕事内容
- 会社の技術面で良いと思っているところ
- 会社の技術面で悪いと思っているところ
- 技術面での改善提案あれば
- 会社の非技術面で良いと思っているところ
- 会社の非技術面で悪いと思っているところ
- 非技術面での改善提案あれば
- その他コメント
アンラーニングする
事情聴取しながら、会社のカルチャーだったり、誰がどのようなロールで働いているかを確認しましょう。
同じIT企業でもエンジニア比率だったり、働いている人の出身会社の偏りなんかで仕事の進め方や、会社のカルチャーが全然違うことはよくあることです。まずはアンラーニングすることが肝要で、今までの経験でうまくいったやり方を押し売るというよりは、その会社のやり方を学んで信頼を勝ち取っていくのが最初は大事なように思います。
一般にプログラムをガシガシ書いていくような仕事より、管理職に近い方がローカライズ性の強い仕事だと思います。SaaSの王様Salesforceは創業時に人材領域も検討したそうなのですが、ローカライズ要件の高さからCRMの方に舵を切ったそうです。アメリカのマネージャーと日本のマネージャーがやることは違う。
日本で働いている限りにおいては、国をまたぐほどショッキングな差分は出ないかもしれないですが、管理職ほどお国柄や会社のカルチャーによって仕事の進め方が変わる感覚はあってもいいように思います。
技術的負債の把握
とはいえCTOに期待されていることと言えば、やはり技術面でしょう。普段の開発の進め方やシステム構成の把握をします。ドキュメントがなければ聞きながら押し進めるくらいの気概はあってもいいかもしれないですね。
Webやモバイルアプリのサービスならテーブル定義やAPIの仕様を聞いてみると大体のつらみのポイントがわかるように思います。ドキュメントの育て方については以前別記事にまとめました。
CTOのいなかった会社というのはそういったアーキテクチャーの負債だったり、ライブラリーのアップデートだったりが黙殺されていることもしばしばあり、まずはそういった負債の返却を交渉して勝ち取っていったり、負債が自動的に解消されるような仕組みを作ります。
Googleでは使える言語が絞られているのですが、各人が好きなように好きな技術を使っている場合もあるので、技術スタックのサポートコストを下げるために、似たような言語やライブラリーを重複して使っているなら、統合の意思決定をするのも大事かもしれないですね。
プロダクトマネジメント
そういった地盤を固めた上で次に期待されている役割は往々にして機能開発の速度向上なのかと思います。
開発機能に関しては基本PMを尊重するのですが、最近はCTOからCEOになるパターンやCTOがPM兼務している企業もあるので必要に応じ意見を述べます。Webサービスネイティブというか普段からC向けのサービスを色々と触ってみたり、ビジネスコンペに出た経験があれば何かしら言えることはある気がします。
自分は仕様考えるのが好きでよくやっています。競合他社のIRの資料読み込んでみるのもいいですね。上場企業で単一サービスならクリティカルな値が開けっ広げにのっていることもよくあります。
機能以外だと開発チームの役割の整理や仕事の進め方の最適化、バグを出さないような仕組み作りでしょうか。技術者にあるまじきと批判されることもあるのですが、凡庸な技術を使って儲かるならそれにこしたことはないように思います。
すでに活躍されている方の足を引っ張ることはないですが、自分でモックを作って仕様調整してコード書いてみたいなスーパーマン前提でまわっている会社があるならば、それを市場から獲得できるロールの人材の組み合わせで回るような開発体制に移行していくのも大切だと思います。
チーム人数が極端に少なかったり多かったりするなら整理していくのもよいです。
バグは全く出ないようにするのは大変ではあるのですが、例えば難しい機能だけレビューやテストを手厚くするようにしたり、ペアプロや共有会を開いて全体の理解をあげたりでしょうか。起きてしまった際の切り戻しを速くできるようにしたり、振り返りを実施するのも大事です。
評価制度、採用活動
最近は株価も下がってきて採用に消極的になった企業もあるのですが、開発生産性を最大化しても開発項目が山積みなら人を雇うことになるかと思います。
採用のアクセルを踏む前に評価制度を整えるのも大事ですね。前職年収前提でカオスな評価制度になってしまっている企業もありますし、そういった歪みや市場との乖離をまず正してから採用に移行しないとトラブルが起きがちです。
例えばインドだと新卒エンジニアの求人倍率が0.33倍という世界もあるのですが、日本においてはIT系全体なら10倍でWeb系なら12倍程度いくのが現状かと思います。東京23区では大学定員増の制限がかかっていることもあり、IT人材の需要が増えても10年間そのバランスが解消しないよう国によるバフがかかっています。
企業は基本選ばれる側なのでどこまで歩みよれるか話し合いつつ、地道な技術広報をやっていくのが基本的な戦略になります。
セキュリティー、法令遵守、知財戦略
会社のフェーズにもよるのですが、年々個人情報の取り扱いの法律が厳しくなっており、システム的に扱いの甘いところがあればリスクを下げていきます。仕様レベルでガバガバで個人情報の観点から一発退場したWebサービスもあります。
弁護士ではないので最終法規チェックはプロに任せますが、Webサービスやアプリでよくある法的制限の引き出しで潰せるところがあれば潰していきます。新しい領域なら国のチェック制度を積極的に使っていくのも良いですね。
ソフトウェア特許は否定的派も多いですが、資金調達面で特許があると有利なこともあり、必要に応じ社内特許制度についても整備していきます。
ファイナンス
資金調達だったり、社債の発行だったりは基本的にCFOがいるならCFO、いなければCEOが行うのが通例だと思います。以前に資金調達しているなら前のラウンドの投資家のツテを頼ったりですね。
企業評価額を上げていくストーリーを立てる上でアクティブユーザー数だったりのKPIが必要で、計測基盤がなければ作る算段を立てます。個人的に投資家のリストを日々メンテしているのでそういう手札があれば提示したりでしょうか。
無形資産の適時開示の流れもあるので、技術的な部分で語れることがあるならIR資料も作成しますし、ソフトウェア資産の計上が必要なら対応します。
所感
以前書いたように、日本からGAFA相当の会社が1社でるだけでも日本の税収は改善されると思っています。
日本のIT企業に厚みが出ると自分が安定した老後がおくれる気がするので、参考にしていただけると幸いです。
