ベンチャー企業のCTOはコードを書くべきか？ - 有事と平時のマネジメント判断

法人・団体専用のパーティー会場検索サイト「会場ベストサーチ」を運用する株式会社アイデアログの取締役CTOの松川と申します。

今回はベンチャー企業のCTOが開発現場にどれくらい深く入るべきか、というテーマについて私見を書きます。会社の規模、ステージ、開発プロダクトの種類、プロダクトのフェーズによって考え方様々なので、前提条件としては

• 社員数20〜30名
• 開発組織　5名〜10名
• マーケット投入済みで事業として成立しているプロダクトを1つ以上保有
• 新しい事業を生み出すために新規のプロダクト開発を実施している
• 中長期の成長戦略があり、実現のために投資を行っている

という背景です。これにそれる場合は、本記事でお伝えする「私見」から外れることは往々にしてあるかと思います。うちと状況似ているな、という方に考え方の1つとしてご参考になればと思います。

「有事」と「平常時」を見極め、有事は迅速に現場に入る

いきなり結論で、ありきたりな内容ですが、これに尽きると考えます。前提条件であげた状況であれば、中長期の成長を見据えて、CTOは組織が事業の成長に耐えれるように、仕組みの整備、人材の確保、マネジャーの育成、社内の基準を高くしていくような組織づくりに専念すべきで、これらの仕事は「緊急性が低く、重要度が高い」ものだと言えると思います。
対して、現場で発生する軽度のインシデント対応、機能改善などのエンハンス開発、バグ修正作業など、「緊急性が高く、重要度が高い」タスクは最小にするべきだと考えています。
ただし、これは平常時に限った話で、「有事」が発生した際には別の話になってくると思います。

では、「有事」とは何かということを見ていくと、

• 重大なインシデント対応（セキュリティーリスク、情報漏洩事故など）
• 売上減少に直結するような重大なシステムの欠陥の対応（システム停止や外的リスクへの対処など）
• 組織内で発生している問題への対処

などが挙げられるかと思います。上２つは、会社規模に関わらず、責任者は現場に出ていくことが多く、会社規模に関わらず問題解決にあたってリーダーシップを発揮していくべき、ということに異論は少ないのではないでしょうか。
3つ目の「組織内で発生している問題への対処」については、他のものほどわかりやすく緊急度が目に見えないので見落としがちなのかな、と思います。
（というのも、今月、私自身が大きな反省と学びがあった部分でもあります）
組織内で発生している、何らかの問題・違和感を正確にキャッチして問題解決に対してフットワークよく動く「有事」の見極め能力と課題解決力が、前提条件で上げた規模のCTOには求められるのだと思います。

「組織内の問題」は例えばどのようなパターンが考えられるか

では、どのような事例を有事と見極め対処に動くべきかということを見ていくと、下記のようなシーンが考えられると思います。（想定の話であり、実際に弊社の現場で起きた事実とは関連はありません。）

• ネガティブな発言が多くなっている
• 表情が暗い
• 離職が連続している
• 基本的な挨拶ができなくなっている
• 理想・目標とのギャップが埋まらない状態（目標未達）が続いている
• 攻撃的な言動が見られる
• 責任の押し付け合いが発生している
• 意思決定のスピードが落ちていると感じる
• 会議の準備不足や目的意識が低下している
• 経営陣との間で認識がずれ始めている
• 会社批判の愚痴が聞こえてくる
• 他のチームとの対立が発生している

などなど、管理職の方からすると、見ただけで頭が痛くなるような場面ばかりだと思います。
上記のような「現象」には必ず「原因」があるわけで、その「原因」もっといえば「メンバーが抱えている悩み・課題・迷い・恐れ」といったものが何か必ずあるのだと考えています。

では、どうするのか

基本方針：現場に降りて解像度を上げる

これはこれまでの失敗経験を踏まえての私見・持論であり、マネージャーの個性によっても対処が分かれると思います。私が、自分の個性や本領を踏まえた上で、今回改めて再認識した答えとしては、

「メンバーが抱えている悩み・課題・迷い・恐れをくっきり解像度が高く捉えられるまで、愚直に現場に降りていく」

ということです。もっとスマートに解決できるマネージャーもいるかと思います。この決定にあたって、本当にこれでいいのか？と迷いはありましたし、マネジメント理論においては、このような動きをよしとしない考え方があることも知っています。やってみた結果、やってみて良かったと今は思っています。

「有事」の際には我々のような規模の組織（マネジャー職の人数が少なく、育成中）においては、フットワークこそが機動力であり、それを生かすべきと考えています。
解像度高く問題を捉えた結果、メンバーの成長につながる打ち手が見つかったり、課題を解決するような抜本的なアイデアが見つかったり、信頼関係が深まったりという、なんてことも過去の経験上結構あったりします。

技術キャッチアップの重要性

ということを踏まえると、いざという時にすぐに機能するように、技術のキャッチアップは当然必要ですし、当社の場合であれば、いざとなればコードを書く、読む、レビューする、改善策を議論するくらいの機動力を発揮する必要があると思いました。
プロダクト開発の技術スタックについてCTO自体がリードしているというケースはその限りではありません。当社では技術の採用や開発基準・ガイドラインの策定は私が指名したメンバーに委譲しています。このような状況で当然、採用技術の本質・コアな部分の理解・概要を押さえている方は多いかと思います。私もそのように進めております。

次のステージに向けた人材育成

今週、実際にプロダクトコードに触れてみて、技術書や公式ドキュメントを読み漁り、実際に書いてみるということをやってみたのですが、これまで口頭で報告を受けていた課題や悩みについて解像度よく鮮明に捉えることができました。
また、副次的な効果として誤解していた部分も発見することにもつながりましたので、大きな学びを得ることができました。

会社のステージが進行すると、また関わり方が変わってくると予想していますが進む方向性は見えていて、上記のような動きができるマネジャーを育成していく、ということになると思っています。

一般的なマネジメント理論で言われる「資質」は求められるとして、私がマネジャー育成にあたって強く育成していきたいと考えている要素は「胆力」です。ここでいう「胆力」は、困難な課題を迅速に手を打ち、有事と平時を見極め、何度失敗しても根気良く、諦めない姿勢のような、泥臭さを指しています。

ビジネスの世界でプロダクトを制作している以上、「理想と現実とのギャップ」はどこまでいっても発生します。このギャップの程度によりますが、そのことによってストレスや葛藤が生まれることはある種、受け入れざるを得ない原理原則といっても良いのかもしれません。
世の中的に良いと言われている、あらゆるツールや手法や理論を用いて、このギャップに立ち向かってゆく努力も止めることなく実施していくということになりますし、経営層から求める要求と現実を擦り合わせて、決して交渉や対立をするのではなく、どうすればギャップを埋められるか、という議論を恐れなく活発に行ってゆくのが健全な状態ではないでしょうか。心理的安全性が高い職場の実現につながるのでは、と考えています。

仕事で壁にぶつかることはしんどいことです。これはエンジニアだけではなく、他の職種でも同じだと思うのですが、壁を乗り越えられる力強いメンバーに育てたいですし、仕事で得た力をプライベートにも活かし、人生を力強く行き抜く「人間力」を育てたいですし、全力でその達成を支援したいと本気で考えています。

今回の記事は私のマネージャーとしてのまだまだ未熟な部分から生じたことから勉強させていただく機会があったので記念として書きました。少しでも同じような立場のCTOや技術部門の管理職の方へ「考え方の一例」として参考になればと思います。