読書メモ。
- エンジニアのためのマネジメントキャリアパス
- https://www.oreilly.co.jp/books/9784873118482/
本書は、技術系マネージャーとそれを目指すエンジニアに向けて、IT 業界の管理職に求められるスキルを解説する書籍です。テックリードから CTO になった経験を持つ著者が、管理職についたエンジニアが歩むキャリアパスについて段階をおって紹介します。インターンのメンターから始まり、テックリード、チームをまとめるエンジニアリングリード、複数のチームを管理する技術部長、経営にかかわる CTO や VP と立場が変わることによって求められる役割について、それぞれの職務を定義しながらくわしく説明します。
さらに管理職の採用や評価、機能不全に陥ったチームの立て直し、管理職についてからの技術力の維持など、様々なハードルを乗り越えるための考え方やテクニックを多数紹介。技術系管理職の全体を視野に入れ、各段階で必要なスキルを学ぶ本書は、マネジメントのキャリアを志すエンジニア必携の一冊です。
目次 #
- はじめに
- 1 章：マネジメントの基本
- 2 章：メンタリング
- 3 章：テックリード
- 4 章：人の管理
- 5 章：チームの管理
- 6 章：複数チームの管理
- 7 章：複数の管理者の管理
- 8 章：経営幹部
- 9 章：文化の構築
- 10 章：まとめ
はじめに #
私の経験では、技術系管理者が直面する難問の大半は「技術的な仕事」と「管理の仕事」の交差点で発生しているようです。人的管理も気の抜けない仕事で、人間関係にまつわる問題を見くびってはならないとは思いますが、人の管理は業種や職種の垣根を超えたスキルですから、その方面の腕を磨きたい人は『First, Break All the Rules』(＊) などの経営術の優れた指南書を参考にしてください。
＊邦訳『まず、ルールを破れ：すぐれたマネジャーはここが違う』（日本経済新聞社、2000 年）
ただ、技術系管理者の職務は人的管理だけではありません。管理の対象が、技術者のグループなのです。大抵の技術系管理者は、現場で専門知識を駆使して働くエンジニアとしての経験を積んだのちに管理者の役割を引き受けており、まさにそうあるべきだと私も思っています。管理者の信頼度を高め、意思決定やチームの統率で頼りになるのが、現場の実践で身につけた専門の知識と勘だからです。本書では随所で技術的専門分野のひとつとしての管理の職務にありがちな難問を取り上げて解説します。
1 章：マネジメントの基本 #
１対１のミーティング #
そこで具体的に、上司に求めるべきことの第１ですが、それは「１対１で行うミーティング（以下「1-1」）」です。これは直属の上司と仕事上、良好な関係を保っていく上で不可欠な要件です。にもかかわらず、これを怠ったり、「そんなミーティングは部下の時間を無駄にするだけ」と部下に思い込ませたりする上司がすくなくありません。1-1 が部下のしてから見てどのようなものなのか、考えていきましょう。
1-1 のミーティングには目的が２つあります。
ひとつはあなたと上司との間に人間的な「つながり」を作ること。なにも、いつもいつも自分の趣味や家族の話をしろとか、楽しかった週末についての「よもやま話」をしろとかいっているわけではありません。そうではなくて、自分の私生活を上司にほんの少し明かすことにも意味はある、と言っているのです。たとえあなたが（家族が亡くなった、子どもが生まれた、恋人と別れた、住宅ローンが重荷になっている、など）ストレスのたまる状況に陥ってしまったとしても、上司があなたを一個の人間として気遣ってくれるような関係にあれば、上司に休暇を願い出るなどの頼み事をするのもはるかに楽になります。もっとも、有能な上司なら部下の気力や活力が落ちたことに気づくはずですが（こうした時に「どうしたのか」と訊いてくれるほど気配りのできる上司なら申し分ありません）。
私自身は、職場では「お友達の関係」を望まないタイプの人間です。だからといって「内気であること」を言い訳に、職場で接する人々を人間扱いしなくてよいかというと、そんなことはありません。強力なチームの基盤となるのは人間同士の絆であり、それが信頼の源となるのです。そして信頼関係 ー 真の信頼関係 ー を構築するには、相手に堂々と弱みを見せられる度量が求められます。というわけで、部下は上司からは「一歩職場を出たら自分なりの暮らしがある一個の人間」としてあつかってもらいたいものですし、1-1 ではそうした部下の私生活にもちょっとは触れてほしいわけです。
さて 1-1 の第２の目的は「要検討事項について上司と１対１で話し合う定期的な場を設けること」です。議題を決めるのは別に上司でなくても構いません。もちろん上司が決める時もあるでしょうが、何を話し合いたいのか事前に多少考えてみることもあなたにとっては有益です。上司と責任を分かち合って 1-1 を有意義なものにしてください。上司と膝を突き合わせて話し合いたいテーマや問題を引っ提げて 1-1 に望むのです。
2 章：メンタリング #
傾聴 #
人的管理において基本中の基本とも言えるのが「傾聴のスキル」です。傾聴は、相手に共感をもつ上で必須の要件であり、かつまた「できる上司」になるための基本スキルです。今後のキャリアがどう発展していくにしても常に必要なスキルです。直属の部下をもたないエンジニアでさえ、相手の言葉を間違いなく理解することは不可欠です。
「自分が次に何を言いたいか」だけを考えていませんか。自分の仕事のことで頭がいっぱいでは？あいての言葉に耳を傾ける以外のことをしていませんか。「イエス」であれば、あなたは「聞き上手」とは言えません。
とにかくリーダーシップを身につけたい人がまず心得ておくべき点のひとつが「自分の言いたいことを相手にきちんと伝わる形で話すのが下手な人が多い」という事実です。おまけにエンジニアという人種は微妙なニュアンスの表現や理解といった言語系の能力に関しては平均以下という人が多いのです。ですから肝に銘じておきましょう ー 「傾聴」とは、相手が「口にする言葉だけを耳で捉える行為」ではないことを。相手が言葉を口にする際の調子や仕草にも気を配らなければなりません。相手はあなたの目を見つめながら話していますか。ほほ笑んでいますか。眉をひそめていますか。ため息をつぎながら話していますか。こういうちょっとしたシグナルが、あなたにどれくらい理解してもらえていると相手が感じているのか、その度合いを知る手がかりとなるのです。
あなた自身の話し方にも気をつけなくてはいけません。複雑なことを告げる際には、必要なら、表現を言い換えて２、３度繰り返してあげましょう。また、相手の質問したことがわかりにくいと感じたら、その質問を、表現を言い換えて相手に返してみてください。それが相手の意図したことと違っていれば、訂正してくるはずです。図表を描いて説明する必要が生じたら、ホワイトボードを活用しましょう。自分の言葉を相手がきちんと理解した、相手の言葉を自分がきちんと理解できたと納得できるまで、たっぷり時間を取って話し合ってください。
3 章：テックリード #
テックリード（tech lead）とはプロジェクトに携わるエンジニアチームの「技術上のリーダー」のことです。テックリードの役目をうまく果たせずに四苦八苦する人たちの姿を目の当たりにしてきました。コードを書かせたらピカイチの腕前を見せる、あるエンジニアがテックリードを勤めた際の苦労です。この人は人と話すのが大の苦手で、おまけに技術的な細部にこだわって脱線してしまうことがたびたびありました。
「テックリードには、誰よりも経験豊富なエンジニアを任命するべきだ。最高に複雑な機能でも難なくコード化できるエンジニア、誰よりもすばらしいコードが書けるエンジニアを」という勘違いが、ベテラン管理者の間でさえ珍しくありません。プログラムの作成作業に思う存分没頭したいと望む人はテックリードの適任者ではありません。では、テックリードの職務とは一体どういうものなのでしょうか。私たちはテックリードに何を期待するべきなのでしょうか。
企業によって、または企業内のチームによって、テックリードの役割は多少異なるでしょうが、「tech lead」という呼称からもわかるように、これは専門のスキルとリーダーシップとが共に求められる役割であり、多くの場合「ひとりが長期にわたって就く職位」というよりはむしろ「複数の人が順次一時的にそのすべてを担う職責群」なのです。
テックリードとは何なのか、私たちが以前の職場で明文化した定義を以下に紹介しておきます。
テックリードはエンジニアの階層におけるランクのひとつではなく、シニアのエンジニアに達したエンジニアが担うことのできる職責群である。管理職がテックリードの役割を引き受けることもできるが、その場合も含めてテックリードは以下にあげる基準を守ってチームのメンバーを管理するものとする。
- 各メンバーと定期的に（週１回）１対１のミーティングを行う。
- 各メンバーにキャリアアップや作業の進捗状況、改善点、報酬などについて、権限内で定期的なフィードバックを与える。
- 各メンバーの研鑽を要する領域を、そのメンバーと共にみきわめ、その領域の能力強化を、プロジェクトでの職務遂行、外部での学習、メンタリングを介して支援する。
テックリードは、技術的なプロジェクトの管理者としての職務を習い覚える立場であるため、細部まで厳しく管理して部下に裁量権を与えないマイクロマネージングに陥ることなく、部下に効率良く仕事を割り振って自身の負担を適宜軽減するよう心がける必要がある。そしてチーム全体の生産性に照準を定め、しかるべき成果を上げるよう全力を尽くさなければならない。また、チームのために自主的な判断を下す権限を与えられ、管理やリーダーシップに関わる難局を打開する方法と、製品、分析など社内の他部門と効率良く協働する方法とを習得することが求められる。テックリードは、技術的なプロジェクトのリーダー役を果たし（個人ではなくチームという）より大きなスケールで自身の専門知識を駆使してチーム全体の向上を図る、という立場にあります。自主的な判断を下す権限をもち、非技術系の相手と協働する際には重要な役割を演じます。テックリード役を初めて任された人にはるかに求められるのは対人能力の強化なのです。またプロジェクト管理のスキルも必要になります。
優秀なテックリードになるための最大のコツは「実際のプログラミングの作業からあっさり一歩引き、『技術面での貢献』と『チーム全体のニーズへの対応』のバランスを取る努力を惜しまない」というものです。あなたに必要なのは、時間を適宜分割して上手に活用する「時間管理」のコツを試行錯誤で身につけていくことです。スケジュリングで最悪なのは、あらゆる会議に、求められるままに出席してしまう、というやり方です。のべつ幕なしに会議への出席要請に応じていたら、コードを書く時間を確保するのが難しくなってしまいます。
テックリードのおもな役割 #
- システムアーキテクトとビジネスアナリストとしての役割：「プロジェクトを完遂しデリバリを実現するにはシステムのどこを改変すべきかやどの機能を構築すべきかを見きわめる」というものです。これを首尾よく行うためには、対象システム全体の構造の十分な把握と、複雑なソフトウェアを設計するための方法に関する理解が欠かせません。また、ビジネス要件に対する理解と、そうした要件をソフトウェアに織り込む能力も求められるでしょう。
- プロジェクトプランナーとしての役割：「作業をデリバリ可能な単位に大まかに分割する」というものです。あなたはチーム全体が作業を迅速に行えるよう、業務を分割し並行作業が可能な部分をうまく抽出することです。
- ソフトウェア開発者兼チームリーダーとしての役割：「自らプログラミングの作業をこなしつつ、メンバーに課題を伝えたり作業を任せたりする」任務を果たします。テックリードになってからもコードを書く仕事は続けるべきですが、やり過ぎは禁物です。まずは他のメンバーに任せられる作業を見つけましょう。とくに、システムのうちあなたが自分で作ろうと思っていたものの時間不足で手を付けられずにいる箇所があれば、それを任せてください。
4 章：人の管理 #
（省略）
5 章：チームの管理 #
盾になる #
「盾」になれるのが「できる上司」 ー これは新米管理者に管理術を伝授する本やサイトでよくあげられる秘訣です。つまり管理者は、社内のチーム外で起きている気の散る問題から保護し、チームがなすべき仕事に注力し完遂できるよう後押しすべきだ、ということです。
管理者は時と場合によってはたしかに「盾」にもなり得ますが、「親」とは違います。自分のチームをまるで親のような目で見るようになってしまう管理者が時にいるのです。チームのメンバーを、まるでか弱い子どもであるかのように扱って、守り、育み、教え諭そうとするわけです。しかしあなたはチームのメンバーの親ではありません。チームのメンバーはしかるべき敬意をもって対するべき大人なのです。この「敬意」は、あなた自身にとっても部下たちにとっても、精神衛生を保つうえで重要な要素です。部下を自分の小さな分身のように考えて、部下の失策をすべて自分自身のせいにしてしまうとか、部下に対する思い入れが激しすぎて意見の不一致が生じた場合に個人攻撃と受け取ってしまうといった落とし穴にはまらないようにしましょう。
6 章：複数チームの管理 #
部長職を引き受ける前にたっぷり時間をかけてコードを書く作業を十分経験し、最低でも１種類のプログラミング言語を自在に使いこなせるようになっていないと、コード書きの作業からすっかり「足を洗ってしまう」ことの危険ははるかに大きくなります。私は常々「人を管理する道へと舵を切る前に、まずは十分時間をかけてプログラミングを完全にマスターしましょう」と声を大にして説いています。私自身は学部と大学院も含めて 10 年ほどかけました。もっと短期間でマスターできる人もいるでしょうが、どうぞ自分の能力を慎重に見極めてください。仮にあなたが最低１種類のプログラミング言語に十分精通しているとして、標準的な時間内にその言語の基本を復習すれば、その言語で書かれたコードベースに関わる作業に貢献し、しかるべき成果を上げられると思いますか。ある言語を誰よりも深く理解している人の場合でも、そのスキルはいつの日にか時代遅れになってしまうのが「この業界の定め」ですが、（標準的なツールやライブラリ、ランタイムを自在に操れる能力も含めて）ひとつのプログラミング言語に精通しているというのは、長年にわたって頼みの綱となる「強み」なのです。
現場での実用に耐える優れたプログラミング言語能力を身につけるためには、「その言語を駆使して、しかるべき成果を上げるのがどういうことなのか」を（できればプロダクションソフトウェアを構築しているチームで）自ら体験し、深く理解しなければなりません。こうしてソフトウェア構築のリズムを体得していないと、チームの問題を解決しつつ、常に質の高いソフトウェアをスムーズに作り出せるよう作業を推進するという技術部長としての重要な職務でつまづく恐れがあります。
CTO に訊け：コード書きの仕事が恋しくてたまりません #
現場のエンジニアから管理職に転じた人はほぼ例外なく「この進路変更は間違いだったんじゃなかろうか？」と自問を重ねる過渡期を経験するものです。おまけに「こんなことしてたら、エンジニアとして身につけた貴重なスキルをすっかり忘れてしまう」と不安に駆られる人も少なくありません。しかしまずは「人やチームの管理なんて仕事じゃない」と思い込んでいないか、自分の心に訊いてみてください。IT 業界には「コードを書く仕事のほうが重要だ」として管理の仕事を見下す人が山ほどいます。しかし管理もれっきとした仕事、必須で重要な仕事です。それに何より、それが今のあなたの職務ではありませんか。
コードを書く作業では「クイックウィン（素早い成果）」をいくつも上げることができます。たとえば、自分の作った機能がテストにパスした、新機能を始動させることができた、ソースプログラムのコンパイルにこぎつけられた、問題を解決できたといった、目に見える成果です。これに対して管理の仕事にはクイックウィンがそうそうありません。ですから「技術畑にいた頃はシンプルでよかったなあ、相手といったらコンピュータだけ。ややこしくて面倒な人間様のお世話なんかしなくてよかったんだから」と思うのも無理はないのです。これに似た「昔を懐かしむ気持ち」を、社会人になって大人の日々がどういうものかが分かり始めた頃に、学生時代を振り返って抱きませんでしたか？「学生時代は自由気ままでよかったなあ」と。こうしたノスタルジックな気分に浸ったり、従来身につけてきたものを手放すことに不安を感じたりしても、おかしくはないのです。
「できる上司」になるためには管理のスキルを集中的に磨かなければならず、そのためには技術系の作業もあきらめなければなりません。これは「あちらを立てればこちらが立たず」のトレードオフの状況で、あなたはどちらかを選ばざるを得ないのです。
意思決定と委任 #
部長レベル以上の管理職が味わっている感覚を表現するとしたら、「皿回し」が最適です。回転速度が一定レベル以下に落ちた皿は棒から落ちてしまうため、どの皿にも注意を払っていなければなりません。こうした皿回しの「皿」が、技術部長であるあなたにとっては監督対象である部下たちでありプロジェクトであって、どのタイミングでどの部下なりプロジェクトなりにどの程度注意を払うかを見定めるのがあなたの務めです。
「委任」こそが、「一度に回さなければならない皿の枚数が多すぎる」感覚を何とか脱するための秘訣なのです。仕事が自分のところへ回ってきたら、こう自問してみてください ー 「私がこの仕事を受け持つ必要はあるのか」。その答えを決める要因はいくつかあります。仕事の複雑さと頻度が、委任すべきか否かと、委任するとすればどう任せるかとを決める基準になり得るわけです。
- 「高頻度かつ単純」な仕事は委任：適任者を見つけて任せましょう。
- 「低頻度かつ複雑」な仕事は自分で：部下に説明するより自分でやってしまったほうが手っ取り早くできるような仕事は、たとえ「部長クラスより下の者がやるべき仕事だろう」と思ってもあなたが自分でやってしまいましょう。このカテゴリーに入るのは、チームのためにカンファレンスのチケットを予約する、といった仕事です。
- 「低頻度かつ複雑」な仕事は有望な管理者の訓練機械として活用：「勤務評価の要約を書く」「人材募集の計画を立てる」などは、あなたがひとりでこなすべき仕事ではありますが、後輩の有望な管理者に「伝授」する必要もあります。そこで、見習いとして同席させるとか、意見を言わせるといった工夫をするとよいでしょう。
- 「高頻度かつ複雑」な仕事は委任してチーム全体の態勢を強化：プロジェクト計画の立案、システムのデザイン、障害の復旧作業まとめ役といった仕事は、チームの有望なメンバーを育成すると同時に、チーム全体の運営力を強化する絶好の機会となります。こうした機会を逃さず、十分に時間を割いてチームメンバーを育成するものです。目標は、管理者があまり命令や助言をしなくても高水準の仕事ができるチームを育て上げることです。
どうぞ有能なメンバーを育成し、意思決定を任せてください。そうやって空いた時間を活用すれば、あなた自身は新たな面白い「皿」を見つけて、回す練習にいそしむことができるというものです。
7 章：複数の管理者の管理 #
CTO に訊け：「オープンドア」は的外れ #
たしかにオープンドアを良しとする人もいます。「管理者がオープンドアを宣言し、部下からの相談に応じる時間帯を設けて、いつ来てもかまわないと告げれば、自然と部下が問題点を持ち込んでくるようになるから、管理者は自分で問題探しをする必要がなくなる。というのも、チームの面々は管理者を信頼しており、腑に落ちないことが生じれば必ず知らせに来るからだ」という考え方です。
ただしそうそううまくは行かないのが現実です。オープンドアは理屈の上では素晴らしいポリシーですが、リスクを承知で上司（やそのまた上司）に問題を知らせに出かけていくなんて、よほど勇気のある部下でなければできません。それに「上司に説明できるほど問題を熟知している」という前提条件も満たさなければなりません。
オープンドアのポリシーに頼ることのリスクは、あなたとチーム管理者とのランクが離れれば離れるほど大きくなります。昔からよくいるのが、部下との１対１のミーティングやチームミーティングの代わりにオープンドアポリシーを取っているせいで現場に疎い経営幹部です。上級管理者であるあなた自身が時間を割いて調べようとしない限り「蚊帳の外」に置かれかねません。
チーム管理者の中途採用 #
管理者の採用面接で確認を要する事柄は２点 ー エンジニアを採用する場合とあまり変わりません。まずは「あなたが求めているスキルの持ち主であるかどうか」、そして「あなたの率いる組織の文化に合った人材であるか」を確認してください。
具体的に、まずは 1-1 について。すでに述べましたが、 1-1 は管理者にとっては、自分のチームの「健康度」を見定め、重要な情報を収集、伝達する上で不可欠なツールです。ですから管理者の採用面接では応募者に「模擬 1-1」を２つ３つやってもらってください。その際、こんな手法が効果的です ー 「この管理者の直属の部下となる予定のチームメンバーに模擬 1-1 の相手役を務めさせ、今チームが抱えている問題や解決したばかりの問題を提示し解決の支援を仰がせる」というものです。「シニアエンジニアに対して、上司が自分自身で解決したばかりの問題を提示し、どういったアプローチでデバッグすればよいかを尋ねてみる」という手法の場合と同様に、採用面接の応募者が優れた管理手腕の持ち主であれば（たとえその問題に実際に関与している人々やプロジェクトをよく知らなくても）どのような質問を繰り出して部下に考えさせるべきか勘を働かせ、事態を改善するための次なる手を示唆することができるはずです。
もうひとつの重要な要件があります。それは「管理者はチームそのものに内在する『バグ』を解消できなければならない」という点です。これについては「過去にあなたのチームのプロジェクトで遅れが出た時、どう対処しましたか」と尋ねてみたり、辞めようかと思っている部下を想定した模擬 1-1 をやってもらったり、勤務成績が良くない部下にどのようなコーチングをしたかや、成績優秀な部下をどう後押しして昇進させたかなどを話してもらったりするとよいでしょう。
さらに、自身の経営哲学についても語ってもらいましょう。「経営哲学なんてありません」と答えるようなら、危険信号と見なしてよいかもしれません。経験の浅い管理者ならいざ知らず、ベテラン管理者が明確な経営哲学を持ち合わせていないというのは懸念材料となり得ます。その人は、管理の仕事をどう捉えているのでしょうか。どのようにして現場の最新の状況を把握しているのでしょうか。仕事の委任はどのようにやっているのでしょうか。
ちなみに、採用面接で（何人かの聴衆を前にしての）プレゼンテーションをしてもらうという手法もあります。その狙いはプレゼンテーションの内容の善し悪しを判断することではなく、応募者が聴衆にどう向き合い、その注意をどう引き付け、受けた質問にどう答え、考えをどう組み立てるかを観察することにあります。これは上級管理職に必要なスキルで、応募者がこれを欠いている場合は、採用の判断材料のひとつとして記録する必要があるでしょう。ただしこの点を重視し過ぎるのは禁物です。聴衆を前にしてのプレゼンテーションの出来不出来がすべてではないのです。他の点で非常に優秀な管理者でも、見知らぬ顔ばかりの聴衆を前にして話すのは苦手という人は大勢います。
技術的スキルについてはどうでしょうか。まず、これから管理するチームのメンバーから信頼されるレベルの技術的スキルを応募者がもっていることをある程度まで確認する必要があります。コード書きもその管理者の職務に含まれる場合は、あなたが普段やっている標準的な技術的面接の短縮版をやってみるとよいでしょう。コード書きが職務に含まれない場合は、その応募者の経験を勘案した上で、これなら答えられるだろうと思われるレベルの技術的質問を投げかけてみましょう。たとえばその応募者がこれまでに構築または管理してきた類のシステムのデザインやアーキテクチャに関する質問をしてみる、といった具合です。また、過去に遭遇したトレードオフの状況を説明してもらい、その時どう対処し、なぜそのように対処したのかも必ず話してもらいましょう。さらに、模擬ミーティングを開き、ある問題の解決法について意見が異なるエンジニア同士の仲介役を演じてもらい、技術的な議論を進めてもらうという手法も選択肢のひとつです。腕の良い技術管理者なら、どんな質問を繰り出せば中核となる問題点をあぶり出し、賛成反対の両派の確固たる意見の合意へと導けるかを心得ているはずです。
以上、管理者の採用面接で確認を要する事柄のひとつ目、すなわち「あなたが求めているスキルの持ち主であるかどうか」について説明しました。
続いて２つ目の確認事項、「あなたの率いる組織の文化に合った人材であるかどうか」に移ります。すでに述べたように、会社の組織の文化はチーム全体にとって大きな意味をもちますが、管理者の中途採用においてもきわめて重要で、ここでしくじるとはるかに大きな問題の種となりかねません。ではこうした文化的な相性を判断するふるい分けはどのようにしたらよいのでしょうか。ひと口に言えば「まずはあなた自身が会社の価値観をきちんと理解しなければならない」です。管理者に関しては文化的相性が重要な役割を演じます。というのも、管理者は信奉する文化に即したチームを育て上げるものですし、新たな人材を採用する際にも自分が信奉する文化を判断基準のひとつにするからです。
結果はどうあれ、チームや会社とは異なる新たな文化の担い手が入って来ると、辞めていく人が出るのが普通ですから、あえてこの手の人材を採用する際には事を慎重に進める必要があります。
最後に、管理者を中途採用する際の要件をもうひとつ。これを忘れたら手抜かりと言えるほど重要な要件で、それは「身元照会」です。採用候補者の前の職場での働きぶりは徹底的に確認しなければなりません。推薦者や信用照会先に、成功も失敗も含めて候補者の勤務状態を問い合わせて、いろいろ訊いてみてください。この人物と共に（あるいはこの人物のもとで）もう一度働きたいか、この人物のどこに好感がもてて、どこにイライラさせられるか、等々。候補者が慎重に選んだ推薦者や信用照会先であっても、今後の参考となる事実をかなり明かしてくれることが多いのです。不可欠の作業ですので、これを省いてはなりません。
明確で詳細な要求を #
部長ランクの管理者は、チームのシニアエンジニアを質問攻めにしなくても明確で詳細な要求ができるよう、（管理者とはいえ、依然）自分の組織の技術を十分把握しておくべきです。チームの作業の進捗状況やプロジェクトの内容、ボトルネックの有無などをしっかり把握しておけば、技術的に実行不可能なアイデアをふるいにかけて除き、進行中のプロジェクトに新たな構想を組み込む要求もできるはずです。こうした明確で詳細な要求は、チームの生産効率を高く維持し、技術的なリスクと事業目標のバランスを取るために行うべきなのです。
技術スキルの点で時流に取り残された管理者は、上層部とチームの間を行ったり来たりする役割しか果たせなくなってしまうことがあります。上からの要請をふるい分けできず、チームに丸ごと伝え、それに対するチームの回答を上に返すだけなのです。これでは何の付加価値ももたらせない管理者に成り下がってしまいます。
経験で培った独自の勘を拠り所に #
技術部長の職務は、ソフトウェア工学やテクノロジーにまつわる何台やトレードオフを理解していなければできない非常に専門的な仕事です。チームの時間の投資のしかたがまずければ、スケジュール立案の段階でより良い決断を下せるよう支援しなかった指導者であるあなたの責任が問われます。チームが時間と労力をつぎ込む対象を決定するのを支援する際には、あなたがこれまでに培ってきた勘を頼りにしてください。組織や人の管理でてんてこ舞いだからといって、そうした技術的な勘を働かせることを怠ってはなりません。
こうした「技術的な勘」を磨くための時間的投資のコツを紹介しておきます。
- コードを読む：時々でよいですから時間を割いて、自分たちのシステムのコードを一部分でも読むようにすると、コードの概要や感触を再確認できます。またコードレビューやプルリクエストにざっと目を通していくと、変更の内容や経緯を把握できます。
- 自分が疎い領域を選び、その領域に詳しいエンジニアの解説を仰ぐ：あなたが理解できていない事柄に関する作業を担当しているエンジニアに２、３時間割いてもらって、その領域のことを説明してもらいましょう。ホワイトボードを使っても、ペアプログラミングをやってもらうのでも構いません。一緒に小規模な修正作業をやってもらう、といった具合に、教えを請うのです。
- ポストモーテムに同席する：システム障害が発生してしまったら、ポストモーテム（事後検証）の報告の場には優先的に同席しましょう。こうしたミーティングでは、あなたのような立場の人（もう毎日のレベルではコードの作成に関与していない人）は行わないような、ソフトウェアの作成とデプロイのプロセスに関する詳細が多く扱われるものです。障害が発生した時というのは、問題が蓄積してしまった箇所の掘り起こしの好機です。機の逃さずに要改善点を突き止めてください。
- ソフトウェア開発のプロセスに関する業界のトレンドを常に把握する：管理者のおもな弱点のひとつが「現場でコードの開発、テスト、デプロイ、監視に使われているツールやプロセスに疎くなってしまうこと」です。いずれも、最新式のものを取り入れればチームの作業効率を大幅にアップできる工程です。自分のチームに常時「進化」を促せるよう、他チームが作業をどのように進めているかなど、時間を割いて把握しておきましょう。
- 社外でも技術系の人脈作りを：最良の話は、信頼のおける人々からこそ得られるものです。人脈を活かして、ブログや公演、セールストークとはまたひと味違った、現場での実際の使用体験を聞かせてもらいましょう。
- 「学び」は決してやめてはならない：技術に関する記事や論文、ブログの投稿を読み、講演の動画を視聴しましょう。チームや会社に直接関連しないものでも構いません。興味が持てて、掘り下げてみたいと思えるものを選んでください。「学び」のスキルを磨きましょう。
8 章：経営幹部 #
CTO とは #
CTO の定義はかなりあいまいです。千差万別の事例を踏まえた上で最良の CTO の定義を下すとすればこんな定義になります ー 「CTO とは、その会社が現在の成長段階で必要としている戦略的技術系幹部」。
「戦略的」という表現を加えることによって表したかった CTO の重要な職務とは「長期的視点に立って考えを巡らし、事業の未来と、それを可能にする要素とを計画する作業を支援する仕事」です。一方、「幹部」という表現を加えることによって表したかった職務は「（上記の）『戦略的な思考』の成果を実現、実用可能にする作業を支援する（そのために問題を細分化し、その対策を部下に実行させる）仕事」です。
では具体的に CTO の職務とは、どういったものなのでしょうか。
まず何よりも、CTO は会社のためを思い、事業を理解し、技術というレンズを通して事業戦略を立てられるようでなければなりません。CTO は第一に経営幹部たるべきで、エンジニアであることは二の次です。「CTO は『コンピュータおたくのボス』として純粋に技術的な問題に焦点を当てるべきだ」という見方は違います。取締役会のテーブルに席がなく、会社の直面する事業上の難問を把握していない CTO に、技術部門を手動してそうした難問を解決することなどできるはずがありません。CTO は会社にとって最大の技術的な好機とリスクのありかを把握し、それをプラスに利用することに焦点を絞らなくてはいけません。「何よりも事業戦略に関わる仕事を最優先すべし」です。
戦略の策定 #
「戦略が欠くべからざる要素であること」を務めて強調するようにしています。経営幹部になって戦略の策定を迫られたものの、どこから手を付けたらよいのかも分からない人がほとんどなのです。私自身もそうでした。技術戦略の策定が具体的にどういう作業なのか、私が経験した例で見ていきましょう。
広範な調査と熟慮
私はまず、技術チームと、チームがこれまでに構築してきた技術、そして会社について考えるところから始めました。技術チームには「ペインポイントはどこか」という問いを、また、種々の領域の経営幹部には「将来、我が社のどの領域が伸びると期待できるか」という問いを投げかけてみました。また、自分自身にも問いかけをしました ー 現在、規模の拡大に関わる問題を抱えているのはどこか、将来、そうした問題が生じそうなのはどこか。さらに技術チームについて調べてみると、生産性に影響するボトルネックが複数見つかりました。加えて、IT 業界全般を見渡し、近い将来の変化を ー とくにパーソナライゼーション（個人化）とモバイル開発に関わる変化を ー 自分なりに予測してもみました。
調査の結果と自分なりのアイデアのひも付け
このようにして既存のシステム、チーム、ボトルネックに関する調査と熟慮を重ねて私なりの結論を出し、チームやシステムの効率化や機能の拡張、事業の改善が実現できそうな領域も推測した上で、調査で手に入れたデータをもとに、可能性のある将来像を頭の中で大まかに書いてみました。ひとり部屋にこもりホワイトボードや神を前にして腰をおろし、会社の現在の体制をスケッチし、共通する要素を基準にしてシステムやチームを分類、分解していきました。たとえば顧客対応のシステム（カスタマーサービスツール）と社内業務対応のシステム（倉庫関連ツールなど）、バックエンドとフロントエンド、といった具合です。このように業務で扱うデータをモデル化しているうちに、気がつくとデータのフローや変遷に対する独自の洞察と、成長の軸となりそうな要素とを見つけ出すことができていたのです。
技術戦略の草案作り
データのマッピングができてしまえば、経営効率を向上させ、機能を拡張し、事業を発展させるためのアイデアを絞ることができます。まず、システム間の情報共有を制限したり、逆に拡大したりするべき箇所を探ってみました。パーソナライゼーションシステムは、常にリアルタイムの状況を反映させるよう動作させるべきか、それともビューをリアルタイムの状況のサブセットに限定する形で動作させるほうがよいのか。各種の製品やさまざまな操作の特製を、データフローに各パートにおいてどのように活用すれば、顧客の体験をより好ましいものにできるのか。こういった事柄を検討する際には、会社の組織構造、（社内業務に関するものも対外業務に関するものも含めて）顧客のニーズ、起こりうる将来的な展開も当然考え合わさなければなりません。最終的にはこうした要素にも対応した技術戦略を練り上げることができました。
経営陣特有の流儀
的を射た経営戦略は、押さえるべきツボをきちんと押さえているものです。押さえるべきツボとは、たとえば「技術的なアーキテクチャ」「組織の構造」「事業の基盤と今後の針路」など。わたしは常々、製品を重視している会社の技術戦略を「その会社について思い描ける数々の将来像を可能にするもの」と好んで形容しています。現在直面している問題に対処しようとする受け身の戦略に終わらず、将来の成長を予測し可能にする戦略でもなければなりません ー あなたが製品に焦点を絞っている会社の経営幹部なら、この点こそがあなたの技術戦略の核心部分となります。肝心なのは製品の今後の方向を決めること自体ではなく、成功裏に展開する、より大規模なロードマップを実現させることなのです。
「完全とはとても言えない情報に基づいて将来を予測する作業に慣れなければ」なりません。この過程で「既知の環境を見つめ、それに必要なものを提供するための計画を立てるという後手後手の統率」ではなく「将来を見越しての統率」ができるようになります。
9 章：文化の構築 #
反響 #
組織の頂点に立つものとなった今、周囲のあなたに対する注目度はかつて経験したことのないほど高まるはずです。あなたの存在が皆の関心を呼び、誰もがあなたに認めてもらいたい、あなたから批判されたくないと躍起になるのです。ですから特に叩き上げてチームとともに成長してきた人が上層部入りすると、「チームの一員」から「総責任者」への視点の転換で苦戦を強いられることが少なくありません。
あなたはもはやチームの一員ではありません。「チームの一員」から「総責任者」への視点の転換が必要です。
たとえば「帰りに飲み屋へ」という画面ではチームとともに飲みに行きはするものの、途中で皆を残して一足先に帰ります。最後まで同席することには、チームにとってもあなた自身にとっても好ましくない結果を招く傾向があるため、ごくごくたまにする程度に控えるべきです。「チームの面々と終業後も親しく付き合う」というのはあなたにとってはもはや過去の事となったのです。
あなたがチームとの間に距離を置くことに成功すればするほど、社員を生身の人間ではなく「歯車」としてしか見られなくなる危険性も高まります。あなたが個々の社員を気遣うことをやめ、歯車扱いするようになってしまうと、社員の側でもすぐにそれを感じ取ります。たとえ表面的と思えるレベルであっても絆を育む努力を怠らなければ、「メンバーひとりひとりのことも気にかけている」「どのメンバーにとっても会社だけが人生ではないということを十分わきまえている」といったメッセージを発することはできます。個々の部下と必要以上に深く付き合わなくても、指導者としての地盤は固められるのです。
今やあなたは社員のロールモデルとなりました。どのような手本を示して後継者を育てていきたいですか。会社にどのような文化や伝統を遺したいですか。
自分の役割の見きわめ #
会社が成長し、年齢を重ねるにつれて、その構造も成長していくもので、この現象にまつわる経験則を提唱した人もいます。米国人のシステム理論化ジョン・ゴールが著書『Systemantics』で提唱したもので、のちに「ゴールの法則」と呼ばれるようになりました。
正常に作動する複雑なシステムはどれも、正常に作動していた単純なシステムから進化してきたものである。（中略）複雑なシステムをゼロから設計しても決して正常には作動せず、修正して正常に作動させることもできない。まずは正常に作動している単純なシステムから取りかからなくてはならない。
企業リーダーへの私のアドバイスは至っていシンプル ー 不都合が生じたら、その要因となった現実のあらゆる側面を徹底分析するべし、です。それで何らかのパターンが見つかれば、それが（構造化の推進、別の構造の創出、構造の廃止など）構造の創出や改善の好機となるはずです。不都合の発生頻度とそれが生む損失をよく考え合わせ、何をどう考えればよいのか、慎重に判断してください。「不都合の発生」とう失敗を糧にして発展の方向を見定めれば、構造を創出もしくは改善するべきレベルも特定できます。たとえば不都合がシステムの一部（特定のチーム）だけに起こっているのであれば、より大きな範囲の構造は必ずしも変えずに、そのチームの構造だけを検討してみるわけです。
コアバリューの活用 #
文化的相性を論じる際には「明確」を期することが大切です。具体的に検討してください。自分のチームが重視しているのは何か、それとどういった点で勤務評価の対象者や面接の応募者の価値観が合致しているのか（あるいはズレているのか）、といった具合です。たとえば「独立独歩が性に合う卓越したエンジニア」は「どのプロジェクトも全員が一丸となって取り組むチーム」には合わないかもしれませんし、「もっとも分析的な主張こそが常に議論を制する」という信念の持ち主は「純粋な分析スキルよりも共感と直感を重んじる社会」では芽が出ないかもしれません。以上２つの例をあげた理由は「どちらも例の価値観も状況次第でプラスに働いたりマイナスに働いたりするから」です。だからこそ価値観は優れたチーム作りの強力な尺度となり得るのです。
10 章：まとめ #
というわけで、最終章 ー メンター役から、さまざまなランクの管理者を経て、経営幹部に至るまで、エンジニアのキャリアパスを私と共にたどっていただき、このまとめの章へとたどり着きました。その過程で役に立ちそうな手がかりや秘訣を多少なりとも見つけ、要注意の落とし穴を確認し、何であれ現在の職務で直面している課題に積極的に立ち向かおうという気になってくださったのなら嬉しいことです。
私自身、身をもって学んできた中で何より大事だと思っているのは「人の管理がうまくなりたければ、自分自身を管理できるようにならなければならない」という点です。自分がどのように反応しているのか、どんなことからインスピレーションを受け、元気をもらい、どんなことに苛立ったり怒ったりしているのかなど、自分自身を理解することに時間を投じれば投じるほど、人的管理の手腕も磨かれていくのです。
「すごい上司」は、意見の相違や争いを解決する名人です。意見の相違や争いを解決する能力を磨くというのは「話し合いに自分自身のエゴを持ち込まないコツを身につける」ことにほかなりません。複雑な状況を正確に見抜くには、自己流の解釈や筋書きに目を曇らされないことが必須です。相手にとって耳の痛いことでも敢えて告げ、相手にきちんと耳を傾けてもらうためには、自己流の筋書きで事実を粉飾しない能力が必須です。管理者志望の人たちはよく「〇〇はこうあるべき」という強い信念をもっているものです。揺るぎない信念がもてるというのは優れた資質ではありますが、「対象となる状況に関する自分なりの解釈は、解釈のひとつにすぎない」という点を押さえられていないと、そうした資質が足枷ともなりかねません。