【読んでみた】エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

以前、こちらの本が話題になってました。

dskst9.hatenablog.com

結構前から読んではいるんですが、なかなかためになることばかりで、集中して読もうとしたら時間がかかってしましました。 IT業界にいる身としては非常に興味深く、感じたことをつらつらと書きたいと思います。

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

エンジニアとしてのキャリアパス

エンジニアといっても千差万別、いろんなエンジニアのキャリアの積み方はあるかと思いますが、なんとなくこんな感じなのでしょうか。

まずは、エンジニア（管理される側）としてキャリアを積みます。 次に、技術的な部分についてリードするテックリードとなります。 その後経験を積んでいくと、マネージャーになり、人を管理する側に回ります。 そして、技術部長になることが技術屋さんとしての最終到達点となるイメージでしょうか。

技術者としてではなく経営者として、技術のレンズを通して経営を見るCTO(最高技術責任者)あるいは技術担当ヴァイスプレジデントになるキャリアパスもその先にあったりして、経営者として技術に向き合うことになります。

本書を読んでいくと、役職が上がるに連れて必要なスキルセットはこんな感じで移り変わっていくようです。

従業員

エンジニア

誰しも管理というものに生まれて初めて接する時には「管理される側」であるのが普通ですが、私達はそうやって「管理された体験」を土台に、自分のマネジメントの哲学を築き上げていくものです。

「管理される側」としてのエンジニアとしては、まずは仕事の仕方や技術的なスキルを身につけることが求められています。

ポイントになってくるのはいかにして上司とうまく折り合いをつけるかだと思います。 上司は完璧ではないですし、自分のことをわかってくれるわけではありません。 自分がどういうキャリアを歩みたいかは自分にしかわかりません。 自分のタスクの状況を含め、上司を味方につけるスキルを身につけることがポイントになります。

1 to 1ミーティングの重要性

これは確かに重要かもしれません。上司との相性にもよるでしょうが、自分のキャリアを上司に正しく把握してもらうことは、キャリアを積んでいくために非常に重要になります。

上司側としても評価に関して密にコミュニケーションを取ることができるので、お互い納得感のある仕事のすすめ方に近づくはずです。

メンター

日本でいうOJTリーダーとかいうやつですね。インターンの世話役社員も似たような感じです。 管理する側としての第一歩は、メンターの場合が多いはずです。新入社員やインターンの学生に技術的な面も含め、仕事の進め方を指導・管理します。

ここでマネジメントをしていく上で最も重要になってくるコミュニケーションについて学んでいきます。 新入社員やインターンといっても、能力は多様でものすごくできる人もいればなかなかうまくいかない人もいます。 どんな能力を持っているかわからない人に対して、最大限のパフォーマンスを出してもらいつつ、自らのパフォーマンスも最大化することが役目となります。

ここのポイントは近すぎず、離れすぎず、メンティー（教わる側）の能力や理解度に応じて柔軟にタスク・支持の回数を調整することです。

テックリード

本書のテックリードは、技術面を中心にプロジェクトチームをまとめる役割になります。イメージとしては、マネージャーの右腕的なポジションでしょうか。注意したいのが、役割であって役職ではない点です。

ここでプロジェクトの進め方について学んでいきます。ロードマップを作成し、作業を出来るだけ分割し、それぞれの依存関係を割り出し、同時進行できる作業を洗い出し、同時にリスクを明確にします。

大変なのは、エンジニアとして開発に携わる傍らでチームの運営も行う、追加の仕事が出てくる点です。

これはもうしょうがないことで、初めは大変だと思いますが慣れるしかありません。 エンジニアリングとマネジメントを同時にこなすという慣れない仕事の多さに耐えることがポイントになります。

一方で、プロジェクト推進に関するタスクはこの段階ですべて身につくはずです。 チームの方向性、運営の方法を頭に叩き込む段階です。

管理職

管理者（マネージャー）

本書で紹介されているマネージャーとテックリードとの大きな違いは、部下を管理・評価する責任を会社から命じられている点です。

大きく２つのポイントがあって、個人の管理・評価する点と、組織・チームを運営して成功に導く点があります。 結構幅が広くて、一口に管理職と言っても、こんな感じに管理する対象や範囲に違いが出ます。 下につく人や組織の規模が変わるにつれ、求められることが変わるようです。

個人的な印象ですが、日本のSIerやITコンサルではエンジニアやテックリードを十分に経ずに、早い段階で人を管理する側に回るケースが多い気がします。 昨今では、なるべく組織をコンパクトにしてスピード感のある開発を行う流れだと思っています。 しかし、本書にもありますが、管理者になってから技術を身につけることは難しく、基本的に技術を十分に身に着けてから管理者に回らないと、目も当てられない管理職になってしまいかねません。 人の管理しかできない人間は、少なくともエンジニアという意味では、これから市場価値は下がる一方だと思いますので、きちんとエンジニアとしてのキャリアを積んで技術力のあるマネージャーが求められている気がします。

人の管理

評価に関する立場が反転するので、かなり勝手が変わります。 "評価"の最終目標は、「自分の部下を昇進させること」でもなければ「反りが合わない部下を淘汰すること」でもありません。 「社員の素質を見極め、必要な成長を適切なタイミングで促し、社員の能力・生産性を向上させること」です。

ポイントは「必要な成長を適切なタイミングで促し」という部分でしょうか。 これをうまく機能させるには、部下との適切なコミュニケーションがポイントになります。

本書で紹介されていたのはやはり1to1ミーティングでした。 日々の1to1ミーティングで、良いことも悪いことも、タイムリーに、継続的にフィードバックを与えることができれば、部下としても常に正しい方向に向かって進んでいくことが可能になります。

これによる、管理者のメリットは、気まずい評価を部下にすることを減らすことができ、評価の材料を集めやすいなどあります。 部下も成長し、評価者も気分良く評価しやすい環境を構築できることがメリットとなります。

スクラムでいうスプリントのようなやり方が望ましいのではないでしょうか。 スプリントは短期間ごとにフィードバックを得られることで、プロダクトオーナーもエンジニアもお互いにメリットがあります。 それと同じですね。

エンジニアリングリード

組織の管理

エンジニアリングリードの主な役目は組織の管理となります。 個人を管理するより、もっと広く、組織について最適化する必要があります。

ポイントになるのは、

• 技術力の維持
• 組織の最適化

でしょうか。

エンジニアリングリードになってくると、もうほとんどコードを書くことはありません。 チームの管理や会議に忙殺されて、コードを書く時間はどんどん減っていきます。 それでも、プログラミングの腕はピンポイントで必要になってきます。 特に、トラブルが起こったときの判断には技術力がものを言います なので、せめて腕を維持するように努めたいものです。

組織の最適化という視点では、問題になるのは扱いにくい部下でしょう。 具体的にはこんな感じです。

• ブリリアントジャーク
• 秘密主義者
• 無礼者

それぞれ扱い方は異なりますが、すべて毅然とした態度で対応する必要があります。 この職階では、チームをいい雰囲気にして全体の生産性を向上させることが求められるので、 これら有害な社員を適切に対応することがこの職位には必要になってきます。

技術部長(テクニカルディレクター)

会社の規模によってはこのあたりの階級もあったりするのかもしれません。 主な役割は複数のチームの管理、ひいては組織の管理です。 複数のチームの管理には、そのチームが順調に開発できているか、できていなければその原因を取り除くことが求められます。

この段階まで行くともう開発の現場に首を突っ込むことはほとんどできません。 しかし、この職位まで上がるためには相当な技術力と経験が求められます。 これはチームの開発の健全性に関し、どこが悪いのかを的確に見抜き、それを改善する方法を示すことが求められるためです。 これには、幅広い知識と経験が求められるため、ほとんどプログラミングに関与しない職階であるのに技術力が求められるのです。

チームの健全性の見抜き方

チームの健全性を見抜くために使用する指標として下記の３つが挙げられていました。

• コードリリースの頻度
• コードへのチェックインの頻度
• インシデント発生頻度

基本的に、開発が健全な状態であれば、コードはどんどん更新されていくし、適切な頻度でリリースされていきます。 インシデントについては、開発の方針によりけりです。 少ないに越したことはありませんが、それに注力しすぎて開発できない状況は正しくないかもしれません。 その辺りのハンドリングを行うことが求められてきます。

自立した組織を作る

自分や優れたリーダーがいなくなってもチームが健全でいられるようにしていくことも、このランクで求められていきます。 そのような「組織」を作り上げる仕事だと考えていく必要があります。 そのためにも、自分の仕事を部下に慎重にシフトしていく必要があります。

管理者の管理

テクニカルディレクターの中でも上の方に位置するようになると、もはや下につく部下は数百人規模になったりします。 自分の下につく複数の管理者に仕事を任せることになるわけですが、プロジェクトが炎上するときは大体管理者から適切な報告は上がらず、気づいたときには大惨事という状況が多いのではないでしょうか。 特に、外面を気にする管理者からは気まずい情報ほど出てこないものです。

炎上の原因は様々です。 上の人間がこれらの兆候を察知するのは難しいかもしれません。 それでも、チームを難局から脱出させ前進させるのは管理者の責任です。 そして、それができるほど会社から権限を与えられているはずなのです。

また、プロジェクトの進捗だけでなく組織の配置や昇進、外部から人員の補充なども担当しなければいけません。 外部から採用する際にポイントになるのは、技術力は当然ながら、組織の文化にあっているかどうかという点です。 これが合致していないと、社員が退職していったり、採用した人が退職したりといった良くないことが起こります。

また、このクラスまで行くと一つの部署全体としてのロードマップについての旗振り役の役割も担います。 とはいうものの、数年単位のロードマップは半年やそこらで修正されていくのがつきもので、役員の決定には従うしかありません。 長期的なビジョンを部下に示しつつ、中止や予算削減などの変化に対しては、きちんと部下との対話しながらプロジェクトをうまい具合に着地させるように計画していくことが求めれられます。

経営者

経営幹部

技術者の最終進化系(?)は経営者です。昨今ではCTOを置く会社も多く見られ、自社の技術について責任をもつことが重要に捉えられているようです。

• CTO(最高技術責任者)
  • 技術関係の経営判断や、会社の顔として外部へアピールする役となります。
• 技術担当バイスプレジデント
  • CTOよりさらに経営寄りで、技術のために組織をどう作るか、社内のインフラをどう整備するかなどを担当します。

両者似ているものの本書では、技術担当VPのほうがより経験を積んだ人が担当するとのことでした。 いずれにしても、会社にとっての技術の代表として振る舞っていくのがこのポジションとなります。

少し横道にそれますが、Developper boost というカンファレンスに行ったときにDMMのCTOの方の話を聞いていました。 その時は、CTOの仕事は、

• 開発方針の決定
• 人事的意思決定
• 広報的活動
• マーケティング
• 経営企画
• 会社のシステムに関する提言
• マネジメント
• 新技術のR&D

と多岐に渡ると話していました。 それでも気をつけていることは、やはりコードを書くことだそうです。 コードを書いていないと、技術に対してポジションを取る（意見を示す）ことができないからだそうです。 あとは、ゲームチェンジャーに対応するだとか、会社としての守備範囲を広げることだとか、経営の視点から技術という切り口でお仕事をされていて、素直にすごいなあと感じました。

戦略の策定

CTOや技術担当VPにとって重要な仕事といえるのが戦略の策定です。 戦略と一口に言っても多岐に渡っていて、自社の社内システムの方向性や自社の主力となるソフトウェアの戦略、さらにはこれから進出していこうとする新規技術領域と様々なジャンルの戦略を立てることが求められます。

また、技術をどのように経営戦略に落とすかのロードマップはさる事ながら、そこに投入する人的リソースにも気を配らなくてはなりません。 新規の事業領域に投資をするということは、そのための人的リソースを他から調達する必要があるわけで、外部から調達しない場合には既存社員の配置にメスを入れることを意味します。 それは、既存の製品やプロジェクトに少なからず影響を与えるので、経営層にも部下である社員にも明確な説明とビジョンを示していくことが必要になります。

単なる青写真を描くだけでなく、経営に対して責任を持ち、ときに厳しい決断を１人で行う覚悟が必要になってくるのです。

文化の構築

最後に、技術者という切り口で経営を考えたときに重要となる、文化の構築についての話がありました。 技術部長のところでも文化の話は出てきましたが、やはり技術系の人間にとって文化は非常に重要のようです。 行動規範とも言える文化によって、エンジニアが何を優先して、どう行動するかが変わり、どんな人間がほしいかという基準になっていきます。 これを示していくことが、経営幹部の大きな役割とも言えます。

技術者集団の文化の方向性を決めるのは、CTOや技術担当VPの仕事です。 これを明確に社員に示し、迷った時の拠り所となる組織の"軸"を設定する事が経営層に求められます。 会社の雰囲気や考え、あらゆる行動の模範を体現し、推進していく責任がCTOや技術担当VPにはあるのです。

こうして築き上げた文化が、同じ文化に対する共感に基づいた採用につながるだけでなく、企業の強力な強みやエンジニアを引きつける求心力につながっていくのです。

感想

良くも悪くも非常に勉強になりました。 若いうちは上司が何考えてるかなんてわかりませんから、上司がどんなことをしていて、どんなことに悩んでいるかを把握することができるのは良かったです。 そんなこんなを考えていると、自分が怒られているみたいで結構心を折られます。 そのへんの自己啓発本なんかより100倍心に響きます。 冗談抜きに心折れます。

それはさておき、ダメ上司は世の中腐る程いますが、なぜダメなのかがなかなかはっきりと言えないものです。 この本は、あるべき上司像の回答例な気がしますので、そことの差分がわかれば上司のどこがだめだかクリアになる気がします。 どんなキャリアがあって、自分がどうなりたいのか、そのハイライトのような本でした。

非常に読みごたえもありますので、年末年始にでもいかがでしょうか？笑

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド