技術の意思決定プロセスとCTO（少し）について
はじめに
これは ドリコム Advent Calendar 2014 の23日目です。
22日目は、シモーネことryouichi.horiiさんによる リリース時の負荷対策 - Qiita です。
自己紹介
- @tomofusaです。
- ドリコム入社9年目。
- サーバーサイド出身で、ゲーム/クライアント周りの技術を見るマネージャー。
- 手を動かさない方の部長です。
- CTOを目指しています。
- 最近気になっているのは、ゲーム開発/アドテクです。
※一部の方を除いて目標CTOについては、はじめてパブリックにしました。
もうちょっと詳しく
元々は、学生時代に総合工学部的なところからソフトウェア開発に入りました。C/C++の基礎的なものに触れながらwin32/.NETでツールを作って遊ぶ程度のプログラミング経験でしたが、インターネットの画く世界に魅せられて、興味をもったことからweb業界に入ってきました。
社歴が比較的長いこともあって、様々な経験をさせて頂いております。その中で、マネジメントを任せて頂く機会を得て、色々な技術的な施策に関わってきました。
今回は「技術の意思決定プロセス」と、何かと話題の「CTO」*1について少し、自分の経験を元に書きたいと思います。
この記事を読む上での注意点
ドリコムで技術的に諸々関わってきましたが、個別の事案について言及することはありません。 内容は、あくまで個人的な意見ですが、影響があることは自覚した上で、基本的には一歩引いた目線で書いていきます。
技術組織について
マトリックス組織
技術組織としては、サービス開発・基盤技術・研究開発を担う組織が横串であり、各プロジェクト/アプリに対してアサインの上で事業展開し、全プロジェクト/アプリに影響をあることに関しては横串でみていくようなマトリックス組織をとっています。 その中で、自分はクライアント系技術を中心に担当する部門を任されており「研究開発部」という名前でやらせて頂いてます。
CTO不在の組織
以前CTOの任命があった時期もありますが、事業変遷など紆余曲折を経てCTOと名のる役職の方は現在居ません。 この状態で、技術戦略・技術の意思決定プロセスをどのように行っているかというと、開発/運用を担う部門長を筆頭に意思決定する場合や、横断的な取り組み・導入の場合は各部門から任命＆プロジェクト化し技術導入をしていく形が自然と採られてきました。
意思決定プロセス
まず現在の「技術の意思決定プロセス」について、書きます。
基本的には、技術の意思決定プロセスといっても、経営のそれとあまり変わりが無いと感じています。ただ、ベンチャー企業にとっては、技術の選択によって今後の業界でのポジションや事業の成否を大きく左右する要素になります。
意思決定の技術 (Harvard Business Review Anthology)
- 作者: DIAMOND ハーバード・ビジネス・レビュー編集部
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2006/01/27
- メディア: 単行本
- クリック: 12回
- この商品を含むブログ (2件) を見る
課題設定
経営や事業や技術部門のオーダーを元に課題を設定します。 「○○事業立ち上げ」「○○の実現」など自分たちが成し遂げたいのは何か？を設定します。
フェーズ
一般的な意思決定プロセスとしては、探究型(inquiry)を自然にとっています。
- 調査
- 計画 (より具体的なスコーピング)
- 仮説・検証の実施
- 結果セット
- 振り返り（定点観測）
上記を繰り返しながら、必要に応じてピボットしていく事になります。 アジャイル開発手法にとても近いですが、振り返りの結果によってはドラスティックに課題・実施内容・計画を変化させることもあります。 検証の結果、技術的な障壁(工数・難易度など)が徐々に明らかになってくるからです。
スコープの捉え方
アジャイル開発*2でいうスコープが「選択する技術」ないし、「技術が果たすべき役割」にあたります。 仮にストーリーとして「課題解決」を掲げたとしても、状況によって進むべき方向性を変更します。
一辺倒に考えてしまうと、実現可能な状態が確認できるまで、スコープを検証して探すことになる。あるいは、実現可能な状態が得られ次第意思決定に入ってしまう可能性があります。 アジャイル開発の計画をスコープと言い換えるのは、技術的な意思決定によって決定後の投資規模が変わってくるからです。 課題の実行に適したスコープに落としこんでいき、より明確化していきます。
例：導入内容、導入時期、開発/運用体制、適用範囲など
つまり、ある程度目安のスケジュールをおきながら、基本的には、調査フェーズを継続的に実施する事になります。テクニカルスパイクだらけで、計画とスコープがすり鉢状に落ちていくようなイメージです。その中から、スコープとして期待される候補技術をリストアップし、その中から最良の選択ができるようにバランスを取りにいきます。
簡単なようでとても難しく、重要なことです。
実現できるから〜、今流行っているから〜 で飛び乗ってしまい、あとから後悔することもあるでしょう。後に、「修羅の道」と呼ばれることも。（遠い目）
流行を抑えつつ、技術とその背景を把握しながら課題に対して自分なりのアプローチストーリーを持っていると経験上よりスムーズに決定できます。その際、アプローチストーリーはステークホルダーに事前説明しておきます。いわゆる根回しですが、必要なことです。
以上が、技術の意思決定プロセスについてでした。
技術の意思決定プロセスへの関わり方
昨今話題のCTO*3について自分なりの解釈を深めていて、少しだけ触れたいと思います。
まず、CTOとは？
技術的な観点で経営にコミットすること *4
そうなのだと思います。
経営というと一見遠くに感じるかも知れませんが、技術を扱うエンジニアとして働いている限り、多かれ少なかれ技術の意思決定に関わっていると思います。CTOの仕事の一部である「技術戦略」技術の意思決定プロセスへの関わり方について、自身の体験から時代の変遷とともにを考察してみます。
エンジニア時代：
- 好奇心から
やってみたい。実現したい。という好奇心ドリブン。技術を見つけては、手元で試すだけではなく導入・運用してみたらどうなるのかを見てみたいと考えている状態です。ほぼ、自己満足。
このような状況に陥っていると事業にフィードバックできることも少ないため、評価もついてきません。
マネジメント初期：
- 技術から
技術管理の意識が強く、課題解決よりも技術を選択することに目的がすり替わっている場合がままある状態。 実現可能性を追い過ぎて、実際には運用体制が整わないような非現実的な提案を真顔でしてしまったこともある。
- 経営からくるタスクの実行
同時に経営視点での事業・タスクの優先度を知る。様々タスクを取捨選択・判断しながら「技術＝手段」として応える時期がありました。 経営からのオーダーをひたすら実践することは事業的な大義はありますが、仕事をするというよりは「仕事をこなす」ことになります。
いずれにせよ、短期目線ではタスク実行を達成しているかもしれませんが、中長期的には技術的、構造的な負債を抱えてしまうリスクが増します。
マネジメント中期
ある種の、転換期がありました。
スマートフォンの登場により自分の技術背景・領域を超えた知見・視点を要求されることになった時期でした。
率直に、技術的知見取得の限界を感じるようになっていきました。 また、組織的な変化に伴い組織や上司が変化し続け、マネジメント上の課題克服経験も短期間で複数あり、徐々に視野が広がり、経営意図を噛み砕けるようになったと思います。同時に、技術マネジメントに対する期待を実感できるようになりました。
マネジメント現在
技術的視点に関しては、社内に信頼できるスペシャリストがおり、彼らの意思を尊重し、参考にしながら吟味した上で、決定に運んでいくようになっています。短期的な課題解決をする一方で、中長期的な視点的で、メンテンナンス性、体制構築などのバランスを見ながら、採用計画・組織/技術戦略へシフトさせていく動きが取れるようになってきていると思います。
今後は、ニーズとシーズを掛けあわせながら、中長期的なプランニングをできるようにしていきたいです。 まだまだ、課題はありますが進みつつあると思います。
まとめると、技術的視点、経営的視点の双方を鑑みた上で判断する必要性があります。 それぞれのベクトルが総和となって最大限の効果が発揮できるようにすべきです。 （数学的にはアレですが、あくまでイメージです。）
部長になって
技術部長というと、技術に寄った仕事のイメージを持っていた。しかし、イメージよりももっと経営的な側面の情報・役割が増えたのはギャップでした。（なってみないとわからないものだ。）しかし、やりたいと思っていたことや、変えたいと思っていたことに対して正攻法で進めることが出来る情報を得たというような感覚です。
採用など組織構築に必要な仕事を徐々に任されるようになってきて、経営課題など仕事の幅をもって担う機会が増えており、「今後の会社は〇〇である・べきだ」という命題に対してて技術を見ながら仕事を進めています。
技術的視点の限界：
創業期のベンチャー企業のように技術領域が限定的な場合は、CTO（≒ギーク）でカバーしきれると思います。 ただし、事業規模が大きくなるに従って技術/事業領域の専門性が高まったり、広く見なくてはならない領域が出てくるのではないかと感じています。 スーパーギークでも技術を追い続けなければついていけず、一方で経営ニーズを把握し続けるという酷使は、代えの効かない存在になり、限界を迎えて成長が鈍化するか、期間限定での役割を担うか、いずれにしても、スーパーギークが離れる日が来るのではないでしょうか。
ちなみに、凡人では基本的に破綻します。凡人代表の私がその職責を仮に担う場合、色んな先生(検索)を駆使して調査に没頭しながら経営ニーズを把握し続けることになり、最終的には総合判断となるのですが、技術的な知見・思慮・現場知識が不足している中で判断してしまうことで様々なリスクが高まります。
そういう意味で、組織の中に知見者がいるかどうかが大きな分水嶺になると思います。そして如何に活躍してもらうか？最大限のフィードバックが得られる状況を作れるかが鍵になってくると思います。
もちろんメタ構造は把握する必要がありますが、実体験として、最初は熟知していいない技術に対して判断して良いものかを迷うことが多かったのですが、知見者との信頼関係があることで気にならなくなりました。
CTO組織
最近のCTO議論の中で、気になっている＆考え方が近いと思うのはVP of Engineeringです。
スタートアップ時は、CTOを置いてしかるべきだと感じています。一方で、ある程度の事業規模・範囲になると、CTOの難易度が一気に増してきます。仮に、CTOを置かないのであれば、CTO組織を作るべきだと考えています。これは、CTOが不在となった5-6年前からの持論です。
また、CTO機能組織をとる場合は、自己組織化チーム*5である必要性があり、建設的に物事が進んでいくことが求められます。最終的には、VP of Engineeringによって決定内容が施行されることでうまく組織が動いていくという考え方です。自分もある意味 VP of Engineeringの役割期待されているし、実行しているという意味で捉えています。
目指すべきCTO像：
CTOといってもいろいろな期待役割があると思いますが、CTO像として個人的に思いつくのは下記4つです。
- Technical Chief 現場TOPのイメージ（本来？旧来から言われているCTO）
- Technical Specialist 研究開発を自ら主導していく方のイメージ
- Technical Manager 技術管理監督者のイメージ
- Technical Director 技術的推進のイメージ
どれも似通っているように感じますが、期待役割の違いです。 自分に目指すべき像は「Technical Director」だと思います。個人的にスペシャルティーなコーヒー屋さんではないので、色々なトレンドを押さえながら、適切に技術をブレンド・選択しながら課題に対してアプローチをしていくことが必要だし、自分の経験・バックグランドが活かせる役割だと感じています。
※CTOを目指すからといって、なれなかったらどうかということは無いです。 エンジニアからマネジメントをやり始めた方は、全員目指しているものだと思っています。
まとめ
- 技術の意思決定プロセスとCTOについて書きました。（テキストは難しい。）
- 部長なりたてで、CTOを目指すと宣言することは時期尚早だった。
- 来年の抱負は、rebuid.fmやsushiに呼ばれること。
- 最近気になっているのは、ゲーム開発/アドテクです。
一人では技術組織を運営することはまずできないので、一緒にやって頂いている皆さんに感謝したいです。そして、これからもよろしくお願いします。
24日目
@hayato240さんです。
