CxOたるもの構想力と実現力が求められる。 未来を構想し、方向性を示すことと、それを実現することの両方に責任を追うものだということだ。 その上で、特にCxOとは、特にxの観点から全社の構想と実現に責任を持つ経営陣の一角ということになるだろう。
つまり、CTOとは、Technology（software企業では、プラスengineeringも責任範囲になることが多い）の領域に深く根ざし、全社を導くべき存在であると言える。
ここでは、構想力 ✕ 実現力をもう少し分解してみて、考察してみようと思う。
（言語化自体は練りきれているわけではないので、ニュアンスだけ掴んでいただければと思います。）
- 構想力
- 技術によるビジネス価値最大化力
- 技術理解力：その技術の何がすごく、何ができるようになり、どのように使うことでユーザー価値につながるのかを理解する力
- ビジネス ✕ 技術ロードマップ構想力：技術を使ってどのタイミングでどのように顧客価値を創ることが、どの程度のモートを築き得るかを構想し、最速で高い山に登る道筋を立てる力
- 技術的制約条件充足力
- 技術的制約条件理解力：正しく技術的制約条件を認識する力
- 技術的制約条件 ✕ ビジネス ✕ 技術ロードマップ構想力：制約条件をどのタイミングで満たすことで、成長を妨げず、むしろ成長に寄与するかを判断する能力
- 実現力
- 実現できる組織・チームを創る力
- チーム構想力：適切なチームの構造（人員配置やチーム分割の単位）を決める力
- 文化形成力・育成力：正しい文化を形成し、正しく人が成長していく環境を創る力
- 採用力：不足している能力を正しく見極め、才能を集める力
- 課題分解力：各チーム・各技術者が正しく実行できる粒度に分解し与える力
構想力について
構想力という意味では、技術を使って「将来的にこんなことや、あんなこともできる。」というのは、CEOやその他CxOクラスの人は大体構想できる。
10年後にAIが、自分のビジネス領域にどのように活用できているかは、ある程度成功しているCEOならば、専門家（例えばPFNの経営陣とさえ）と同等に議論することも可能だろう。
一方で、今何がどのレベルでできて、数年後には何ができているのか、 自分たちのビジネスの山登りにどのタイミングでどの技術をどう入れ込むことで、誰よりも高い山に登れるのかの判断は、技術を深く理解している者にしかできない。
その上で、今見えている顧客の課題を解決するために、どのような技術的チャレンジをすることが最適かを判断する必要がある。どのような技術でその課題を解決するのかの選択を誤れば、モートを築けないだけではなく負債にもなり得る。
一方で、どれだけ顧客課題があろうとも、そのタイミングで技術的に不可能なこと（例えば今この時点での不老不死の実現）はできないので、どの課題をどの順番で解決していくべきかが重要な問題と言える。
また、ビジネスというのは、制約条件を満たしながら、顧客価値・売上/利益などを徐々に最大化させていくゲーム。
医療業界の技術的制約条件でいえば、3省2ガイドラインなどのセキュリティ要件回り、厳しい品質要件、法律によるオペレーションの規定やレガシーかつ謎のシステム規格の存在、エビデンス（医学的根拠）への準拠の必要性などが制約条件となる。
ただし、制約条件と言っても、満たさなかった場合に一発アウトになるようなものは、通常の事業運営を行っていれば、引っかかることはあまりないとも言える。
法的拘束力のないガイドラインや倫理規則のような制約条件は、どちらかと言えば、きちんと満たすことが競争力になるような場合もあり得る。 その制約条件を満たすためにどの程度の負荷がかかり、満たすことでどの程度のリスクを低減する&競争力を得ることができるのかを考える必要がある。
このように、制約条件を加味した上で、どのタイミングではその制約条件を無視し、どのタイミングで取り込んで行くのかを、技術的観点から判断し、制約条件に足をすくわれることなく、山登りのスピードを最大化できるかが求められる。
実現力について
構想が実現できるかは、一重に構想したロードマップを実現する組織を創ることができるかにかかっている。逆に組織としての技術力が、取りうる構想の選択肢・パターンを制限するといっても過言ではない。
さらに、組織としての技術力が高ければ、技術的判断を誤った場合にも素早い手戻りが可能なので、リスクを下げることができ、組織に取ってより背伸びなチャレンジも可能になる。
そして、スタートアップのように成長が早い組織では、ビジネス的な成長も実現しつつ、技術的にも新しいチャレンジにも取り組むには、今ない能力を持つ人の採用が何よりも重要になる。
どのような能力を持つ人が必要なのかを正しく把握し、構想を成し遂げるためになぜそのような人が必要なのかを社内外に発信していく必要がある。
また、チームが自律して素早い意思決定と実行が可能となるように、適切な単位でのチームの区切りが重要になる。
どのようにチームを分割すれば、それぞれのチームが他のチームに依存することなく、自律した状態でロードマップをどんどん実現していけるのかを考えなければならないということだ。
当然、このチーム構想力は、一つ一つの課題やチャレンジをチームが実行できる単位に分割する課題分解力と相互依存関係にある。
（ついでに）責任力について
誰がどのような判断に責任を追うのかは、その判断をするに足るスキルがあるのかも重要だが、失敗からの回復力＝失敗した時に尻を拭い、次に活かすことができるかも重要。
技術力があるか？は、所詮スキルの一つの構成要素でしかない。
判断が正しかったかどうかを評価するには、一定の時間がかかる。
数年に渡って影響を及ぼしうる判断や、判断を誤ると会社に取って致命的になり得る判断は、会社に長期にコミットする or 会社に長期の影響力を及ぼす可能性の高い人間が判断すべきとも言える。
これらを踏まえた時に例えば、今のPharmaXでは、使用言語や技術基盤などの技術選定などの大きな判断は、うまく行かなかった場合、半年〜数年先のビジネス進捗や採用などあらゆるものに負の影響を及ぼす。
実際、数ヶ月〜半年の開発のディレイを引き起こした場合、PharmaXのようなスタートアップにとっては致命傷になりかないため、このレベルの判断はCTOが行うしかない。
PharmaXの開発チームがもう少し大きくなり、全体の技術力、組織力が上がった未来では、チーム単位である程度の技術選定などもし得るようになっていくだろう。
例えば、今でもライブラリの選定などは十分任せうる。
また、例えば、複数のバックエンド言語を扱える開発者が増えて、どの言語を選択しても妥当な技術的判断と実装ができるようになった未来では（失敗した時の負の影響が金銭的にも時間軸的にも小さくなるので）、Rubyを使うのかGoを使うのかといった言語選定もある程度チームに任せ得る。 このように組織のステージが上がれば、CTOが判断すべきことのレイヤーも高くなっていき、それ以下のレイヤーのことは任せられるようになっていくだろう。