はじめに

Voicyで技術部門の責任者をやっております。@yamagenii です。先日 ROSCA さんの主催するイベントで「今、CTO / VPoEに求められる事とは？」というタイトルで発表をしてきたため、その内容を記述します。

rosca.connpass.com

伝えたかったこと

教科書は存在せず、コト=事業を最大化していく気概が大事

テクノロジー業界は若くて(CTO/VPoE、Google の創立が1998年)、専門性が高いにも関わらず、昨今のビジネスにおいてのなくてはならない、重要度の高い位置にいます。

このような市場もあるからこそ、CTOやVPoEの向かうべき難易度が上がり価値は高まっていると言えるでしょう。技術の移り変わりや進化が早い中で、技術で駆動して事業を最大化する事は、ポテンシャルが高い反面、再現性高く実行することは難しく技術のリーダが機能しないと事業が大きく後退するのは想像に容易くもあります。

その中でCTO/VPoEの教科書を作れるかでいうと、枝葉の情報は参考にはなるけど、再現性は難しいと考えられます。

今回の発表では「CTOやVPoEに求めたいマインド」をベースにしつつ、そこから今のVoicyのフェーズでの考えてきたことを発表しました

今回はスタートアップと、スコープを切って話していきます。 Voicyの場合は経営と執行と社内のリーダが両方仕切っているため、この境界を曖昧に話すケースがありますが、今のフェーズで必要とされていることと理解をしてください。

今、スタートアップでのCTO / VPoEに求められる事とは？

事業家として技術を使う存在になる

事業家=事業を成功させる人

技術のリーダはエンジニアの経営者ではなくて、事業家のエンジニアになる必要があります

具体的にはスタートアップの事業推進において、必要な事は「理解〜経営戦略作り〜執行」までやれる覚悟を持つということです。

スタートアップにおいて事業を成長させるために必要な項目は様々あります。

自分はstartup balance score card を用いて整理をしていたのですが、この分け方自体はどんなフレームワークでもいいでしょう。

その中で、全体最適な事業戦略を作るには、会社に必要な項目を理解し、経営チームやボードメンバーなどのリーダ陣のケイパビリティを考慮しながら、戦略についてはお互いにフィードバックをしあい、必要とあらば戦略作りから執行までする必要があります。その時に、技術の専門性が生きるところがあれば、活用していくというスタンスで技術をとらえるべきです。

技術と経営をつなげる

技術は専門性も高く、目新しい概念が飛び交うため、技術の専門家でない人にはわかりづらく、非技術者の経営者もその一人と言えるでしょう。

そういった経営者に技術がもたらす事業価値を理解・納得してもらうことも技術リーダの責任です。

CTOが見るべき領域は抽象的で複雑度が高い領域といえます。簡単にいうなら「プロダクト」と「組織」があって、その内部には何をしてもいい権限が与えられ、それに対して経営バリューの責任が伴っています

その中でよく世の中の話題に上がる「データドリブン」「スクラム導入」「アーキテクチャ」「技術的負債の解消」「セキュリティ」「品質」「DevRel」「採用」など、何を戦略を置くかを意思決定していく形になります。

その際、投資した分だけの効果を出す責任もあり、しっかり経営に説明できることが大事です。

技術の専門家でない経営陣に理解をしてもらうための工夫

自分は以下の3つを意識して話しています

例え話

技術を知らない人に技術の大切さを理解してもらうには、同様の目線で理解させることが大事で、その手法としては例え話を用います。

例えば技術的負債の解消やリアーキテクトはどのように説明するか？

自分がよく引き合いに出すのは渋谷駅です。

渋谷駅を一つのプロダクトとしてみなします。そう考えると渋谷駅は1885年に完成してから、街の変化に伴う人の需要に応えながら、最適化を繰り返していたといえます。

一つ渋谷駅のプロダクト的開発の例を上げると、埼京線のプラットフォーム開発があげられます。

埼京線の延長開業にあたり、山手貨物線にホーム設置を検討したところ、駅東側に東急東横線の地上駅舎と東急百貨店東横店東館があり、山手線ホームに隣接してホームを設置するスペースがなかったことから、1996年（平成8年）に山手線ホーム南端よりもさらに南側の貨物ホーム跡地（北緯35度39分20秒東経139度42分13.5秒）に旅客ホームを新設した。山手線ホームとの連絡通路には動く歩道が設置されていた[注釈 3] ほどで、山手線を含む各線への乗り換えには最低でも5分程度はかかるため「南渋谷駅」と揶揄されたこともあった[新聞 8]。この問題は、東横線と副都心線の相互乗り入れ開始に伴う東横線の地下ホームへの移転後、2020年（令和2年）に東横線旧地上駅舎および東急百貨店東横店東館を取り壊した跡地を活用して埼京線・湘南新宿ラインのホームを移設したことで解消された。

埼京線の乗り入れをしたいという要求があり、制約があったため、理想的ではないが駅としてはギリギリに機能する遠い埼京線のプラットフォームを作った。これ自体は負債と認識しつつ、プラットフォームが拡張可能になった段階で駅を移設したという経緯。こういったソフトウェア開発は世の中どこでも行われていると考えられます

今のソフトウェアの状態を抽象的に可視化する事で、要求が何で、制約が何で、どの点が複雑で困難かを建築とのアナロジーをつなげて、確かにそうだな思ってもらえるかはこの例え話にかかっていると思います

定量化

技術がもたらすバリューを無理矢理にでも定量化をする事で、それが叶った時の解像度を上げることも大事です。

例えば一番わかりやすいのは経営数値で、PLのどこに効くか、KPIとしてAU,MRR,ARPU,LTVなどのどこに効くかなど、そこに寄与できるかが重要です。その時のROIを計算して出すのが良いでしょう。

実際はそんな簡単に計算できない技術戦略もあります。それでも想像の範疇で定量化することが大事です。

例えば負債解消をしようとなった時に、エンジニアが嫌だと思う箇所をリファクタリングするケースが多いと考えられますが、「エンジニアが嫌だと思う」理由を突き詰めて、経営の数値のバリューで何が生まれるかを考えることが大事です。

もしエンジニアが嫌だと思っている理由が、仕様が複雑でコードも複雑になっていて、開発するたびにデグレが起きる時を考えましょう。その時、「バグの発生した時のデグレによるリードタイム」「バグの発生確率」「開発の頻度」で企業にもたらすエンジニアコストは分ります。正しく数値で出す事は難しいと思いますが、フェルミ推定などを用いて、初めは仮説で置いて、後にファクトを集めていけば良いと思われます

実際このコードはリファクタリングをしてテストコードを入れる事でデグレの発生発生確率を抑えられると考えられるので、エンジニアコストがどれだけ少なくなるかを明記できるでしょう。

こういった形で全ての戦略に置いて定量化はできる前提で考えるべきです。