Developers Summit 2014：事業で成果を出すCTOたちのセッションを見て

セッションの概要

モデレーター：PIVOT株式会社 プロダクトマネージャー 蜂須賀様
株式会社BuySell Technologies 取締役CTO 今村 雅幸様
キャディ株式会社 取締役CTO 小橋 昭文様
エムスリー株式会社 取締役CTO/VPoP 山崎 聡様

セッション情報
https://event.shoeisha.jp/devsumi/20240215/session/4781

事業で成果をだす3人のCTOとモデレーターの方々でパネルディスカッション形式でした。

CTOの定義について

• 「技術に責任を持つ【経営者】として捉えている」。捉えるべき範囲は、技術や開発組織のみならず事業成長や利益追求も多くを占めている

• CTOのTはTechnologyの話だけど、やってるともうわからない（なんでもやってきた）

これはCTOとして行わなければならない意思決定にも大きな影響を与えますし、技術面・組織面だけ見ていればいいわけではないという覚悟が必要だと感じました。

事業で成果を出すための技術的な意思決定をどう進めているか

• MA目線では次のようなものを材料にしている

  • エンジニアや情シスの人数

  • 20年以上前のテクノロジーで「惰性」で開発を続けていないか※

  • 誰が開発を主導しているのか

• シングルプロダクトとマルチプロダクトでは異なる

  • 採用が難しい技術スタックは、新しい技術に置き換えることも検討する

  • マルチプロダクトでは、プロダクトごとに最適な技術は異なるため、CTOが自ら意思決定はしない。現場が判断できるように権限を委譲し、現場で考えてもらう

• 全体的にクラウド化していきましょう！など、全体で決めないといけないところだけCTOとして決定する

  • これを民主主義的にやってしまうと歩みが遅くなる

• 組織が大きくなってきた時はガードレールを作る

  • ガードレール（ルール）内では自由に決定できるようにする

• 短期的には最適でないかもしれないが、長期的な最適化に責任を持つ

• （エンジニアさんが）動きづらそうだなーという雰囲気があったらガードレールを設けて行った方がいいかも

• 意思決定後の周知は何度でも何度でも繰り返し伝える

20年以上前の技術…のところはドキッとしました。
逆に言えばそれだけ敬遠される理由が実際にあるし、新しい技術スタックへの載せ替えができないのはプロダクトを支える屋台骨に問題があるということですからね。

上記でも出てきましたが、やはり権限の委譲は大事ですね。
私は、結果的にマイクロマネジメントになって失敗した経緯があるので、刺さるものがありました。
そのための枠組みの制定など、マネジメントするにあたっては制度作りに徹する必要があるなーと。

最後の「繰り返し伝える」についても、CTOにとどまらず、マネージャーにとっても必要ですね。
意思決定した内容の「何故その選択をしたか」をセットで繰り返し伝え続けたいですね。

事業で成果を出すためのCTOのもっともハードな仕事は？

• そもそも事業で成果を出すってところが最もハード

  • エンジニアを建設業で例えるなら、ビルを設計して建てるのはエンジニアだが、その建てるビルでの収益の可能性について考慮するのは果たしてエンジニアであるべきか？

    • 大勢を収容できるビルであるなら、エレベーターの数は2基でいいのか？→渋滞してビルそのものが使いづらくなる→入居者が減れば収益を上げるのが難しくなる→であれば利用者数や移動者数などから予測してエレベーターを10基に増やしましょうなどの視点が必要

• 経営からしたら全て投資で、確率の掛け算・足し算である

• 一番の不確実性は、本当に作れるの？というExecutionの観点であるが、CTOができます！と答えられるかどうか

  • CTOにとって、誇れるエンジニア組織を作らないといけない

  • エンジニア自身の価値を証明し続けることが必要

  • KPI、ROIをエンジニア自身に出させることも重要

ビルの例え話はなるほど！と思いましたね。とてもわかりやすい内容でしたので、今後使わせてもらおうと思います。

当たり前ですが、私たちはユーザーに実際に使ってもらうために開発を行っています。

ユーザーからしてみたら、業務にフィットしているか（させられるか）や、使いやすいかというのはとても大事です。

単にそういう機能開発をしなければね！という考えにとどまらずに、事業として捉えることで見えてくるもの、できることが変わるなと感じました。