CTOの大切な役割の一つ

Matsumoto Yuki

久々に記事を書いてみました。スタートアップの経営者やCTOというポジションを今担っている人、これから目指す人向けに私見をまとめた乱文です。直近はCTOというよりも、もはやポジション名もわからないなにかになってしまい、人事や総務、マーケティング、各事業の経営管理など職責を広げすぎてしまいましたが、今回は自分にとってのCTOの職責として重要なものとは何かを考えてみました。

要点

事業をスケールさせるためには、まず組織とプロダクトの設計が相互に影響し合うことを理解する。その上で事業構造の理解から、より素早く改善すべきレバレッジが効くポイントを見出し、その改善が最も素早く進む組織とプロダクトのアーキテクチャを同時に設計する。こうしたプロダクトと人、事業の3つを理解しながらアーキテクチャ設計することがCTOとして重要な職務の一つだと考えています。

事業とCTO

先日、スタートアップ界隈を見ていて下記のもやもやが発生したので、自分なりのCTOという仕事の意味について記したくなりこの記事を書いています。

どうしても、テクノロジーを事業のスケールの鍵と本気で考えられている経営者が少ないのでは、というのはCTO協会的な動きの中でも感じるところで、ではCTO（ないしテクノロジーで事業を牽引する立場）とは何なのだろうかという今時点での私見を記すことは一定の価値があるのではないかと考えています。自分の狭い経験の中からではありますが自分個人として捉えているCTOの仕事というものを考えてみました。

コンウェイの法則とその逆

MicroservicesやCloud Nativeが重要視された昨今、皆さんの中でもコンウェイの法則について見聞きした方は多いかと思います。多くの方には釈迦に説法となってしまいますが、先日経団連の会合の中でもコンウェイの法則について触れるタイミングがあり改めて掲載しておくと、下記のような表現となっています。

「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」 (原文: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.")
Wikipediaより引用

例えばチーム間でも密に結合したコミュニケーションを要する設計となる組織では、生まれるプロダクトも似たようにモジュール間の密な結合が見られる、絡み合った複雑なソフトウェアになる、というようなことを示す法則になります。

このコンウェイの法則は、逆に組織設計として活かしていくことができます。特に直近のMicroservicesは、まさにプロダクトの分解、システム間の通信プロトコルの設計などを通じてチーム間の疎結合化を図る事ができるという考え方も可能なものであり、Cloud Nativeな時代の組織とアーキテクチャのスケーラビリティに大きな影響を与えています。

実際、例えば中国などの急速に成長しているスタートアップに対してヒアリングを行うと、日本では考えられない速度での組織成長を達成している会社に出くわします。例えばBytedanceなどが好例かと思います。こうした組織ではプロダクトを構成するMicroservicesを適切に設計することで急速な人員拡大を支えており、その設計の妙に感心する次第です。

組織のスケーラビリティは、プロダクトのアーキテクチャが大きく影響を与える、そういった考えを念頭に置きながら、では現実的にどう活かしていくのか、ということを考えてみます。

SoRとSoE、事業のスケーラビリティ

ほとんどのプロダクトには、その可用性を重視すべき領域、および競合優位性の礎となる改善領域が存在します。前者をService of Record(SoR)、後者をService of Engagement(SoE)と表現することもありますね。

この2つの境界はプロダクトの不確実性が大きい状況、大抵はスタートしたばかりであるほど曖昧で切り分けができない部分もあります。しかし、事業をスケールさせよう、競合に対する優位性を確保していこう、より素早く仮説検証していこうと考えていくに従い、可用性と改善速度が衝突をし始め、想定しているほどプロダクト改善が回らなくなる状況が到来します。

ここに至り、Microservices、ないし適切なアーキテクチャ上の分離は事業の実際の改善に威力を発揮し始めるのではないかと考えています。初期からいたずらに・原理主義的にMicroservicesを実践する危険性は語られている通りで、自分も過去苦しみました。（参考）ただ、適切な粒度を段々と分離していく、また予め分離可能な設計を取っておくという保険的な措置は事業がスケールするタイミングになって、その効用を発揮します。分離を考慮されたコードベースやアーキテクチャとそうでないものでは、その後のMicroservices化的な取り組みに大きな差がでます。これはテストを書きやすいコードとそうでないコードという議論にも近いのかなと思っています。

話を戻しますが、事業をスケールするタイミングにおいてはプロダクトの中で特にレバレッジのかかる、つまりより少ないリソースでより大きな改善につながるような集中せねばならないポイントが発生します。例えばそれはトップページのレコメンドアルゴリズムかもしれませんし、特定画面のユーザービリティかもしれません。こうした改善の重要なSoE部分に対して、SoR的な領域を含む部分から独立したシステムにしていくことで、改善部分の可用性をその他部分から独立させ改善していくことが可能になります。（下のツイートも、こうした考え方を反映したものです。）

事業の要所に組織として集中する

また、分離された重点的改善箇所に対してコンウェイの法則で語った組織とアーキテクチャの関係が重要です。独立した重点改善ポイントに対してより集中して開発チームを割り当てることで、その事業のレバレッジが効くポイントに大きな成果を上げる可能性が高まります。顧客体験を改善でき競合優位を確立するポイントを、可用性を意識せねばならない領域から独立したシステムにすることで多くの改善が実行可能となるためです。

よりよい改善は、完璧なプロダクトづくりではなくより素早い施策の実行と検証から生まれます。この考え方についてはLeanやAgileといった様々な文脈で語られていますね。（余談ですが直近のIoTやRoboticsなども関係するプロダクトのより重要な価値はこの実験主義的事業推進にあると考えています。）

ソフトウェアと人、事業：CTOの組織における役割

コンウェイの法則やMicroservicesとSoE/SoRの話から事業のスケーラビリティについて話をしてきましたが、このスケーラビリティと事業優位性をまさに設計し組織を構築することの責任がCTOの大きな役割の一つだと考えています。組織も含めて一つのプロダクトであり、それを如何に設計するか、これは事業自体のスケーラビリティに大きく関係し、また組織自体の拡大にも大きな影響を与えます。密結合なプロダクトに人を集めたところで（これは最近メンバーから聞いた表現で感心したものなのですが）「狭いキッチンにぎっちりとシェフを詰め込んだ」状態になります。適切にキッチンを分割しましょう。

そのために必要なのは、事業を理解し、事業のKPI構造や改善すべきレバレッジの効くポイントを見出し、適切なソフトウェアアーキテクチャを常に模索し続け、それを組織構造と共に現状に合わせて適用し続けることで、その将来計画を持つことはCTOの職責です。

今の自分を振り返り思うこと

直近ではDMMの中で40を超える事業に対してこうした考えをベースに組織づくり、事業のスケールに向けたKPI構造の理解とその時点でのレバレッジの効くポイント探し、それに合わせた技術面含めたアドバイスを繰り返しています。全てのプロダクトに対してMicroservices的に理想的な進め方というのは不可能ですが、組織とプロダクトがどこに向かうのか、その仮説とそこから来る予測、実際の状況と予測の比較から事業を更に理解する過程はさらなる事業のスケーラビリティを模索する重要なプロセスです。

実際にいくつかの事業では数値を伸ばすところまで辿り着きまして、現在は更に多くの事業の改善に取り組みつつより実効性の高いデータドリブンな経営管理をソフトウェアで実現できないか模索しています。

CTOというポジションはここまで述べてきたプロダクト設計以外にも事業の性質に応じた様々な責務があるでしょうし、セキュリティや、また組織内の情報システム系の設計なども自分は大切な役割として関わっていくべきだと考えています。また、明確に規定されない多くの経営的課題に向き合っていくこともしばしばです。CxOという職位は、その会社の経営を前進させステークホルダーに報いる、そのために何でもやろうという意味合いが正直なところで明確な職責というのは定義しづらいものです。

ソフトウェアが事業のスケーラビリティに大きな影響を与えるようになった事自体は紛れもない事実で、そこに対してCTOは経営者として責任を持って推進していくことが必要です。また、ソフトウェアが事業のスケールの鍵の一つであり、それがCTOの職責であるということを組織の大小に関わらず多くの経営者が理解していくことが肝要と考えています。

最後に

小難しく長々と書いてしまいましたが、こうしたソフトウェアと事業の関係について手っ取り早く現状を知り対応していく上でDX Criteriaという便利なツールがあります。（宣伝です。）ぜひぜひご利用ください。


この記事が気に入ったらサポートをしてみませんか？