CTOの頭の中：技術と組織と牽制関係

うちの会社には技術的なCXOとして、CTO、CIO、CISOの3パートがあります。何が違うねん、という話なのですが、ここにはのっぴきならない事情と仕組み化の流れがあって、3つのロールに分けました。このあたりの話を今日はつらつら書いてみたいと思います。

CTOの責任

昔はCTOこそ全てのバランスを有し、社長よりも俯瞰したロールであれ、的な思想を持っていました。というのもマーケットを理解し、P/L、B/Sも理解しながら先日書いたG/Pを最大化しろ、また負債をいつどのようにどうやって減らしていくのかを考え、説明責任を果たし（その間機能開発力が落ちるかもしれないし）、実行しなければならない。これらは、短期的な収益と中長期的な投資をバランス良く、柔軟に判断しなければならない、という意味で、できりゃいいのですが簡単ではありません。特に簡単ではないのが、結局社長なり、トップの視点、視野にこの広大さと深さが無い限り、CTOのやることなすことの意味が究極的に理解できない。もっと簡単に言えば「評価されない」わけです。例えばRevenueにコミットした経験が長い営業系社長の場合、多くの方がP/Lにヒットするような機能開発を優先してくれるCTOを評価しがちです。負債の返済という行為は短期的なP/Lに効いてこないので、これを理解できる社長は少ないでしょう。

以前は、トップの評価など気にせず、孤高にも美徳と信念を持つ技術トップ人材を採用しようと頑張りましたが、いないという結論に達しました。いない、というのは本当にいないということではなく発生率、出現率を鑑みると仕組み化するには現実的な要件ではないという考え方です。我々はホールディングスとして、事業会社をこれからもどんどん増やしていくならば、それぞれの事業会社のCTOを確実に育てられたり、採用できるような仕組みにしなければならないので、天才を探していてもいけないわけです。

CIOの責任

我々の会社ではCIOに「非機能要件」に対する責任を持たせています。非機能要件を英語のwikiで確認すると大きく以下の2つに区分されることがわかると思います。

・Execution qualities, such as safety, security and usability, which are abservable during operation (at run time).
（実行時品質、安全性やセキュリティ、ユーザビリティなど、実行時に観察可能なもの）

・Evolution qualities, such as testability, maintainability, extensibility, and scalability, which are embodied in the static structure of the system.
（発展性品質、テスタビリティや保守性、拡張性など、実装されたシステムの静的な構造）

この通り、実行時に観測可能な品質を上げることと、システムアーキテクチャのアップグレード（発展性はコストやG/Pなどで価値転換可能）の責任を持つことで良さそうです。

我々は現在「あたりまえ品質シート」みたいな感じで、それぞれの非機能要件毎に定量化して表現できるようなメトリクスを持って観測していますが、シンプルには「レスポンス時間」「Slow Query系」など、見えやすく影響範囲の広そうなものからモニタリングして、一定以下に抑える活動をするだけでも大きな意味があると思います（何のメトリクスも無いよりは）。

もうお分かりだと思いますが、CIOの大きな責任のひとつは「技術負債」となるB/Sのようなものだけに閉じます。そのため、ここでしか評価されない力関係を生み出すことで、CTOとの牽制関係が働き、一方的に技術負債が溜まっていく状況に、組織構造的に楔を打っています。

組織構造で言えば、縦は「P/L寄り」、横串は「B/S」よりのチーム編成にしていて、短期施策と中長期施策が別人格で重要視されるような構造にすることで、常に意思決定がどちらかに寄り過ぎることを牽制する構造にしています。究極的には一人の人格が高次元でバランスを取ることができれば、意思決定から実行までのスピードは格段に早くなると思いますが、そのメリットを捨てても、未来永劫仕組みとして維持しやすい縦横システムを、大きな事業においては、現在推しています。

CISOの責任

CISOはこと「情報」において全事業全業務を串刺しする立法府の機能を持ってもらっています。我々ITを基盤に事業展開している会社において、情報は最も大事な経営資源であり、資産、そしてリスクでもあります。日々変わる事業やシステムに対して、スピーディにルールメイクして危機を未然に防ぎます。究極的にはシステムに転換されるべきですが、ヒヤリハットが発生したからといって次の日にシステムが完璧に改善されているとは限りません。例えばAさんが貰ったBさんの名刺の情報は、誰まで、どの部署まで、どの事業部まで共有して良いのか？そんなルールが無い限りシステム化すらできません。多くの場合、ルールが曖昧な場所にヒヤリハットが生まれ、そしてルールが曖昧だからこそ何度も繰り返しています。このルールを、いち早く作り、展開し、啓蒙するところが何よりもCISOの大きな責務です。

それ以外にも事業を超えたシステム基盤の設計、実装なども担当しているため、CISOには視野の広さが要求されますし、ルールメイカーとして事業の価値や知識、柔軟性と表現力が求められます。CISOのルールひとつで、事業が円滑に回らなくなる可能性も考えると、非常に重要な役割です。

意思決定と説明責任

このように3つのロールで全体の均衡を取るような組織構造になっていますが、最終的な意思決定と説明責任は社長に取って貰うようにしています。当たり前ですが、ホールディングス側への説明責任を、社長自らが取ることによって、究極的に事業会社全体の対技術の重さ、視野、視座が全て上がると考えています。

社長がCSRFの意味や内容、対策と実装期限を説明したり、プロダクトロードマップに対して僕からツッコミが入った時に自分の言葉で説明したり、セキュリティ問題が発生した時にどう予算達成にコミットするのか、またはそれ以外の方法で説明責任を取るのか、これら広範囲でかつ専門的な知識も必要とされる責任を全て取るのは大変だと思います。が、これなしに、またCTOやCIO、CISOの価値を認識することも難しいでしょう。

まだ、この仕組みが完璧だとは思っていません。PDCAの後、次のバージョンにアップグレードした時は、またここで。