はじめに
Voicyで技術部門の責任者をやっております。@yamagenii です。 先日 ROSCA さんの主催するイベントで「今、CTO / VPoEに求められる事とは?」というタイトルで発表をしてきたため、 その内容を記述します。
伝えたかったこと
- 教科書は存在せず、コト=事業を最大化していく気概が大事
テクノロジー業界は若くて(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を計算して出すのが良いでしょう。
実際はそんな簡単に計算できない技術戦略もあります。それでも想像の範疇で定量化することが大事です。
例えば負債解消をしようとなった時に、エンジニアが嫌だと思う箇所をリファクタリングするケースが多いと考えられますが、「エンジニアが嫌だと思う」理由を突き詰めて、経営の数値のバリューで何が生まれるかを考えることが大事です。
もしエンジニアが嫌だと思っている理由が、仕様が複雑でコードも複雑になっていて、開発するたびにデグレが起きる時を考えましょう。 その時、「バグの発生した時のデグレによるリードタイム」「バグの発生確率」「開発の頻度」で企業にもたらすエンジニアコストは分ります。 正しく数値で出す事は難しいと思いますが、フェルミ推定などを用いて、初めは仮説で置いて、後にファクトを集めていけば良いと思われます
実際このコードはリファクタリングをしてテストコードを入れる事でデグレの発生発生確率を抑えられると考えられるので、エンジニアコストがどれだけ少なくなるかを明記できるでしょう。
こういった形で全ての戦略に置いて定量化はできる前提で考えるべきです。
目標コミット
目標はなんとしてもコミットしていく事、その結果としてイニシアチブを得ていくこと。
採取的に技術の専門的な実装部分は他の経営者には理解をしてもらうことが難しいです。そのため「あなたが言うなら」大丈夫という信頼とイニシアチブを得る必要があります。
戦略でおいた目標は、やり方には言及せずに、とにかくコミットすることが事業家として求められるスタンスです。 技術で解決することを想定してた戦略でも、技術で解決する必要はないと思っています。 常々、その目標をコミットをする姿勢が重要です。
経営は時にロジカルではない領域の意思決定が必要な中で、「何を言ったか」より「誰が言ったか」という基準でも合意のグラデーションを濃くすることができます。
もちろん実績を積み上げていくことが一番で、そのための目標コミット。たとえ実績が出せなかったとしても信頼を勝ち取るための目標コミットだったりもします。
注力ポイントを特定し戦略を作る
- 注力ポイントをフレーム等駆使して整理する
- 書き出した項目に対して、今ある現状のイシューや課題を書き出す
- イシュー量の多いものはさらに分解をして整理をする
- 2番と3番を繰り返す
- 整理されたものをまとめて中長期的なストーリを作り、実行する
注力ポイントをフレーム等駆使して整理する
現在世の中には様々な方がフレームワークとして、注力する箇所の整備をしてくれています。 こういった一般的に利用されている考え方には乗っかっていきましょう。もしそれが理解できてない場合はバイアスの強い判断をしてしまう可能性があるので注意です
まずはそのフレームに沿って、現状をまとめていくといいでしょう。
自分の場合は「エンジニアリングマネジメントの4象限」をベースに整理をしていきます
書き出した項目に対して、今ある現状のイシューや課題を洗い出す
それぞれのフレームで現在存在する課題を整理していきましょう。
例えばプロジェクトマネジメントの課題であれば、「スクラム開発がなんとなくうまくいってない」、テクノロジーマネジメントの課題であれば、「技術負債が貯まっている」などあると考えられます。
現場の課題も含めて、イシュー出しをしましょう。エンジニアのリーダたちを集めてワークショップ的に課題を洗い出すのも良いと思います。
イシュー量が多いものはさらに分解をして整理をする
イシューを洗い出していくと、イシューの事業のインパクトの総量が多い箇所があると思います。 それが、今の開発組織やプロダクトのウィークポイントとも言えます。
そういった項目は抽出するために、整理をしましょう。
その後、再び「書き出した項目に対して、今ある現状のイシューや課題を洗い出す」をに戻って、洗練を繰り返していきます。
整理されたものをまとめて中長期的なストーリを作る
イシューを正しく列挙して整理ができている前提に立つと、それが組織にとっての大きいウィークポイントになり、適正化をしていくことがバリューを大きく出すポイントになります。
最後に大きな戦略として、イシューを解決する中長期的なロードマップとストーリーを作成します。
Voicyの場合は、「ソフトウェアの負債」「組織崩壊に伴うチーム力の低下」が大きいイシューとなりました。 これらに対して、
チーム力を向上させる -> チームのケイパビリティをあげてソフトウェア負債に立ち向かう
というような形で一つ一つ1年くらいの時間をかけて解決をしていきました。
全てのイシューを一気に解決することが難しいからこそ、レバレッジの高い選択肢を先に持ってくる意識も重要です。
まとめ
以上、Voicyで技術部門の責任者としてのマインド面で必要な項目を洗い出しました。 CTOはカオスの領域で認知負荷も高い領域だからこそ、原理原則で動くことが大事です。 枝葉の話は無限にできるのですが、その中で、紹介した3つは自分の中での指針にしている考え方になります。
シリーズA〜シリーズBのフェーズのまだまだ事業モデルを模索しているスタートアップの一つの事例として参考になれば幸いです。