CTOのお仕事
CTOの役割は会社によってもマチマチですが、自分が2年やってきて見えてきたことを言語化してみます。
責任分解のツリー
仕事を任せるほうは結果責任（accountability）を負い、任せられたほうは執行責任（responsibility）を負うそうです。
会社の持ち主である株主は会社のすべてに対する結果責任を持ち、その執行責任をCEOに負わせます。CEOはそのうち技術的な部分の執行責任をCTOに負わせて、自分は結果責任を負います。
CTOは技術全体のうちの一部をまた別の誰かに任せます。
というふうに、会社って責任分解のツリーで成り立っています。
責任は権限やゴールとセット
何かを任せるときには、権限も一緒に渡します。やっていいこととダメなこと、使っていいお金やリソース、何は相談が必要か、等々。これらは敢えて明示されないかもしれませんが、必ず存在するのです。
それから、任せる側と任される側には、共に達成したいゴールが存在するはずです。
結果がゴールから遠ければ責任はまっとうできていませんし、権限を逸脱してゴールを目指しても疎まれますよね。
CTOの誕生
会社でビジネスをやっていく上で考えないといけないことは、どこに市場があって、何をどう作って誰にどう売って、パートナーやライバルとはどう付き合って、どういう人を雇って、どういう法を守って、…きりがありません。
このうち技術的な部分以外の部分にCEOが集中したいときに、CTOが作られます。
特に技術が重要でなければCTOを置かないでもなんとかなりますし、逆に技術が占める割合が大きすぎて、敢えてCTOを置かないGoogleみたいな例もあります。
技術的な部分とは
何をどう作って、どのぐらいの期間で作れて、どういう人が必要で、そして自分でも手を動かして、…まだまだ全然多いですね。
技術組織が小さければCTOがコードも書いて採用もして何でもできるかもしれませんが、ある程度の組織規模になったら、このうちのどれかは責任分解するしかありません。
例えばVPoEという役割を作って組織づくりの部分を任せるとか。別にVPoEが組織づくりを担当するべきと決まってるわけではなく、任せる側との分担によって相対的に決まるのです。
CTOのお仕事とは
CTOのお仕事は、すなわち設計です。
与えられた権限の範囲で達成するべきゴールをどう達成するかを考え、適切に分解して人に任せます。
必要であればコードを書いたり採用の現場に出ていったり評価制度を作ったりサーバントに徹したりするかもしれませんが、それが仕事だと思ってしまっては本末転倒です。
大きな設計ミスは後々まで響いてきちゃうので、今の会社が見通せる範囲で一番クリティカルな部分の設計に一番頭を使いましょう。
