今回から数回にわたってCTOに求められる「マネジメント」をいかに身につけるか、という話しをします。
エンジニアやCTOの方と話をしていてよく出てくる話題は、
「エンジニアリングの追求とマネジメント、どちらに進めばよいか」
「CTOは技術だけじゃなくマネジメントも必要か」
などです。
エンジニアとはいえキャリアを進めていく中で「マネジメント」を意識する機会は増えてきます。しかし、この「マネジメント」とはどういうものなのでしょうか。それは、人・組織の観点の話しであることや、プロジェクトマネジメントの話であったり、CTOクラスになると会社経営の話しなど、多岐に渡ります。漠然と「マネジメント力を付けなければ」と言っても何をすればよいかわからないことも多いのではないでしょうか。そこで、今回のコラムでは、CTOに具体的に必要だと思われる「マネジメント」とは何なのかを挙げ、次回コラムでそれらを身につけるコツについてご紹介したいと思います。
CTOに求められる「マネジメント」とは？
「マネジメント」とは何か、という一般的・学術的な話しは置いておき、具体的にCTOがマネジメントとしてどういう事が求められるのか、について考えてみましょう。
私個人の経験から、日々の業務の中でCTOがマネジメントとして求められるものを次のように分類してみました（あえて技術的なものは除きました）。
- 経営・事業戦略
- 人・組織
- プロダクトマネジメント
- プロジェクトマネジメント・タスク管理
- イノベーション
これらについて１つずつ紐解いてみましょう。
経営・事業戦略
会社経営は、社長及び役員がチームで行っていることが多いと思います。技術的な事に関してCTOが責任を持つのは疑いありませんが、技術以外の事に関しては他の経営メンバーとの分担によって変わる、とOCTOPASSのCTO養成講座では、いつもお話しています。たとえ技術以外の事を他の経営メンバーに任せられる環境だったとしても、CTOは全く関わらなくても良い、ということはありません。技術を担当するにしても、その大前提として会社はどのような戦略でゴールを達成しようとしているのか、という所からしっかりと関わり、腹落ちをもって理解しておく必要があります。
例えば戦略の観点で言うと、経営戦略・事業戦略を議論し策定する中では、CTOが積極的に関与することが望ましいです。昨今ではIT/IoTやデジタルトランスフォーメーション（DX）が経営に与えるインパクトがどんどん大きくなっているはずです。むしろそれを中心に据えて経営戦略を考えるべきです。そこでは、技術を深く理解しているCTOの役割は非常に大きいはずです。
戦略を元に、実行計画を立てる段階になって始めてCTOが呼ばれて、社長や他の経営メンバーから「あれとこれをいつまでにやってくれ」と言われるだけの立場では十分ではありません。仮にそういう状態だったとしたら、戦略を策定する議論から参加させてもらうように強く求めるべきですし、そのためにCTOもしっかりと経営・事業戦略を学んでおくべきです。CTOに求められるものは、単に自分の知っている技術の話をするだけではなく、幅広い技術への知見と経営のフレームワークを一通り理解しておく事が大事です。
人・組織
人に関する点、特にチームビルディングに関しては
「CTOが０から開発チームを作る前にかならず考えておきたい”5W”のコツ」、
「『チーム憲章』で開発チームを確実に作るコツ」
のコラムの通り非常に重要な点です。チームビルディングの延長として育成やリテンション、また制度設計という観点で評価制度、報酬制度、ストックオプションの設計なども重要です。特にエンジニアは、昨今かなり弾力性のある報酬設計が増えてきています。成長するテック企業やデジタル化に成功している企業は、エンジニアの確保・リテンションを非常に重視しています。その中でCTOが果たす役割は、チームビルディングや制度設計にとどまらず、いかに魅力的な組織、職場にするか、という所まで考える必要があります。
組織に関しては、10人程度までのチームであればあまり難しく考える必要はありません。断続的に人数が増えるフェーズ、複数のプロダクトやサービスを運営している場合、ゴールやスピード感の違うチームがいくつか存在する場合には、非常に重要になってきます。いわゆる伝統的な組織論は一定の参考になります。
- 機能別組織か事業部制組織かプロジェクト型組織か
- クロスファンクショナルチームか
- レポートラインはどうするか
- ルールをどのように設けるか
- どのように自発性を誘発するか
考えることはたくさんありますが、経験上思うのは、プロダクトやサービスの種類、事業運営の特性によって有効な組織設計は異なるということです。これらは事例を交えながら次回以降のコラムで解説します。
プロジェクトマネジメント
プロジェクトマネジメントやタスク管理については、特に小さなチームの場合には、よくCTOにこの役割が求めらます。開発すべきプロダクトや機能に対して、次のような管理が求められます。
- 誰をどのようにアサインし、どのようなスケジュールでデリバリーするか
- 品質保証はどこまですべきか
- タスクが遅延した場合にどのようにリカバリするか
など。
チームが大きくなってくるとCTOとは別の役職が代替することが多くなります。
一般的なPMBOKなどのプロジェクトマネジメントのメソッド、アジャイル・スクラムなどの手法がもちろん参考になりますが、やはりこれも現場の状況や特性に合わせてカスタマイズしていく事が重要です。ただし、日本と海外（又は日本人とそれ以外）では事情が大きく異なることもありますので、その点を次回以降のコラムでご紹介します。
プロダクトマネジメント
CTOがプロダクトマネジメントと聞くと違和感があるかもしれませんが、要はビジネスとテクノロジを結びつけてプロダクト開発の実行計画に落とし込む作業です。組織が小さな段階では往々にして技術サイドの人、特にCTOがこの役割を担うことが多いと思います。テクノロジの知見なしのビジネスだけの視点では、技術的な実行可能性や、開発に要する期間、異なる機能やサブシステム間の共通性などを考慮できないので、プロダクトのロードマップを策定したり、仕様を定義したりすることは難しいためです。
成長企業によくある「何も考えずにスピード重視で作ったプロダクト」が後で取り返しがつかないくらいカオス、誰も全体の仕様がわからない、技術的負債もたっぷり、というケースはよくあることです。これは初期からしっかりプロダクトマネジメントの考え方を持つことで避ける事ができます。トップスピードでプロダクトを作りながら、中長期でも困らない作りにする、というのはかなり難易度が高いですし、特にスタートアップでは将来のことより短期的なメリットを優先したくなります。こういったケースでは、CTOがある程度バランスよく短期と中長期のバランス調整しながら開発を進めることが１つの解決方法となりますので、CTOがプロダクトマネジメントをよく理解しておくことはやはり重要なのです。
イノベーション
少し唐突かもしれませんが、「イノベーション」もCTOが意識すべき重要な点です。イノベーションとは技術そのものがイノベーションであることの他に、ビジョンや目標を達成するために想像もしなかった手法でそれらが達成できた状態だと私は理解しています。この「想像もしなかった手法」というのは、技術によって成されることが多く、そのためには、様々な技術を学び、試し、試行錯誤するプロセスが必要です。
昨今ではディープラーニング、ブロックチェーン、IoTなど新しい技術トピックが次々と出てきています。これらのスペシャリストになる必要は必ずしもありません。それらの技術を活用して非連続の成長を創り出すことは、経営メンバーの中でまさにCTOがリードすべき領域ですし、まさに冒頭で話した経営戦略に直結するトピックです。
これらの「マネジメント」をどのように身につけるか
かなり幅広くマネジメントのトピックを分類しました。すべてがCTOに求められるわけではありませんが、１つでも多くこれらをカバーすることで経営者としての幅が広がりますし、それは会社の成長にとっても重要なことです。
以前起業した際、「経営者の器が会社の器、経営者が成長しない限り会社は成長しない」と言われたことがあります。CTOとしてこれら「マネジメント」を少しでも多く身につけ、実践し、現場に合わせ、自分流にカスタマイズしていく事が重要です。次回のコラムでは、いかにこれらの「マネジメント」を身につけるかについてお話しします。
