Lean Baseball

No Engineering, No Baseball.

CTOになる前・なった後に学んだこと - 「エンジニアのためのマネジメントキャリアパス」を読んで

f:id:shinyorke:20190211162241j:plain

去年からメチャクチャ気になってた「エンジニアのためのマネジメントキャリアパス」、読みました&あっという間に読了しました.*1

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

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

  • 作者: Camille Fournier,及川卓也(まえがき),武舎広幸,武舎るみ
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2018/09/26
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (1件) を見る

エンジニア組織のマネジメントをはじめて正味2年ちょい、CTO歴(やっと)1年の自分としては、

CTO・エンジニアリングマネージャーになる前に読んでおきたかった!!!ってぐらいの名著でした!!!

っていうくらい素晴らしい書籍でした、自信を持ってオススメできます.

このエントリーでは、

この三本立てで感想なりポエムなりしたいと思います.

TL;DR

  • テックリードやマネジメントへのキャリアを考えてる方もそうじゃない方も、「エンジニアのためのマネジメントキャリアパス」一度は読んでおけ
  • ゼロからはじめるエンジニア組織作りは、エンジニアとしてもビジネスマンとしても視座・視野が広がり、仕事を通じて色々と学べる
  • テックリード、エンジニアリングマネージャー、CTO(VPE)目指すなら小さいところからはじめるのオススメ&最後は技術に頼るトコ多いやぞ!

スタメン

私のエンジニア・マネジメントなキャリア

昨年のデブサミでもちょっと触れていますが、改めて棚卸し.

  • 2018年〜今:ネクストベースのCTO.フルタイムのエンジニアは2人(自分込み)、他に学生インターン1人、ちなみに経営陣ではありません*2
  • 2017年1月〜9月:Rettyでテックリード→エンジニアリングマネージャー
  • 2016年(半年程度):ビザスクでインターンのメンターやったり小規模プロジェクトのリードしたり
  • 2014年(三ヶ月ぐらい):SUUMO(リクルート)のとある事業のエンジニアリード
  • 2012年ごろ(これも半年):ベイカレント・コンサルティングのとある顧客チームのエンジニア・リード

途中メンバーに戻ったり色々と紆余曲折ありましたが今は何とかかんとか小さいチームながらもCTOやってる人、そう見てもらえればと思います.*3

「エンジニアのためのマネジメントキャリアパス」の感想

感想をザックリ書くと

技術系管理者のキャリアパスを大局的な見地に立って紹介している本。キャリアの各段階に即したきわめて戦術的な助言や提言が得られる。技術系の管理者は部下に対して、優れた管理術を身につける責任を負っている。本書で管理のノウハウを学んで欲しい。技術系管理者の職責を詳細に紹介、解説している実用的な手引書である。

エンジニアのためのマネジメントキャリアパス」 推薦の声より.

全くもって「推薦の声」どおり、ホントにそのとおりの本でした.

そして私の感想は、

  • 今までテックリードやエンジニアリングマネージャーをやってきた数々の失敗について大いに反省した
  • 何故失敗したか?どうすれば同じ失敗をしないか??、のヒントと指針をたくさん頂いた
  • CTO #とは という、エンジニアの数だけ考え・意見を持っているこの件に対する自分なりの「CTO道」が見えた&登る気になる元気をもらった

このエントリーを書くため、もう一度はじめの章あたりを読んでいるのですが、くしくも及川卓也さんの「まえがき」と同じことを言ってる気がします.

これから本書を読もうとする読者の方々にこんなことを言うのはふさわしくないかもしれないですが、本書を読み終わった後、私はひどく落ち込んでいる自分に気づきました。それは、本書の内容に不満があったり、不快に感じた部分があったということではまったくなく、むしろ逆にその内容が素晴らしい故に、いかに自分が未熟であったかを思い知らされたからでした。

エンジニアのためのマネジメントキャリアパス」 まえがき、から抜粋.

この本を手にとったマネージャーの方々(私含む)、きっと同じ感想なんだろうなと思います(真顔).

目次と概要

章ごとに何が書いてるかという簡単な解説を.

個人的には、

自分がどのフェーズにいようが、最初から最後まで読むとストーリーを十分追えるのでかなりオススメです!*4

推薦の声・まえがき・はじめに

読む前のイメージを掴む意味でもしっかり読んだほうがいいトコでした.

いやこれはホントすごい*5.

1章 マネジメントの基本

名前の通り、「そもそもマネジメントってなんぞや?」という話.

1on1やフィードバック、トレーニングって、、、というところを触れています.

個人的にはこの辺も合わせ読むと理解深まると思いました.

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

実際、1on1本読んでたおかげでこの辺はスッキリと内容が入りました*6.

2章 メンタリング

名前の通り、新人や新規加入メンバーに対するメンタリングについての章.

個人的には今まで複数社で学生さんや新人のメンターをしてきたので、その経験と合わせ、色々と思い出しながら読みました.

3章 テックリード

開発チームの責任者たる、「テックリード」に関する章.

  • 職務時間の3割程度、チームと共にコードを書きつつ
  • 開発チームに対する責任を担う、開発リーダー

たる方々に対する章です.

なお、この本で(特に心に傷負うことなく)スラスラ読めるのはこの辺までかなと思います(真顔)*7

4章 人の管理

こっから心の傷に塩をすり込むような内容が増えてきます(震え)

いわゆる、「部下を持った管理職」に対する助言・考え方が中心です.

自分は読みながらこの辺にブクマしてました.

「継続的なフィードバック」の文化をチームに根付かせる

勤務評価など、「管理職として何かしらのアクションを起こす」前にちゃんと「継続的にメンバーを見てフィードバックしてますか?」と説いててなるほど!と思いました.

  • 部下の基本情報を仕入れる
  • 日頃から部下を見守る習慣を
  • 深刻な話題も日常レベルのフィードバックで「さらり」と

それぞれ何書いてるかは実際に本を手にとって読んでほしいのですが、私からすると色んな思い出が走馬灯のように蘇る内容でした(真顔)

5章 チームの管理

一つのチームに対する課題・問題解決の章.

本の表現としては、

機能不全に陥ったチームの「デバッグ」の基本

というド直球な表現で記載されています.

いろいろと書いてあって学びも深かったのですが、私は特に、

誰しも人に好かれたいのはやまやまだが、管理者は「優しさ」よりも「親切」を旨とすべし

この言葉が一番刺さりました.

6章 複数チームの管理

複数のチームを束ねる職責、「技術部長」「開発部長」みたいな肩書を持ったときの心得など.

この章に書いてること、今の所無縁かなあ?と思いつつも、ここが刺さりました.

部長職を引き受ける前にたっぷり時間をかけてコードを書く作業を十分経験し、最低でも1種類のプログラミング言語を自在に使いこなせるようになっていないと、コード書きの作業からすっかり「足を洗ってしまう」ことの危険ははるかに大きくなります。

私は幸いにも(言うても2名+1名チームなので)バリバリコードは書いてる、Pythonであれば手足のように自在に操れる*8のでこの危険には面してないのですが、

「こいつイケてないなあ」っていうエンジニアリング・マネージャーや部長はこの傾向思いっきり当てはまるのでは?と思い震えました.

7章 複数の管理者の管理

複数チーム管理に加え、「管理者を管理する」という、「ヴァイス・プレジデント見習い」みたいな職責についたらどうしますか?の話.

  • 道を踏み違えてる新任管理者を何とかする
  • ベテラン管理者(会社のカルチャーに合ってない)をどうにかする

...中々震える話が多い印象でした(震え)

その他、技術投資(いわゆるR&Dとか)もこの辺で触れています.

8章 経営幹部

「あなたは経営陣のひとりです!」的なポジションについたら、の章.

こっからいよいよCTO的な内容です.

技術戦略や優先順位、やりにくい仕事(例:レイオフを伝える)をどうする?などに触れています.

9章 文化の構築

会社の文化・思想をどうやってポリシー作ったり、職務・給与レンジに合わせた組織作り(キャリアラダー)どうする?的な章.

横断的なチーム作りや、意外なところでは「コードレビューを通じた文化作り」などにも触れています.

10章 まとめ

まとめというか励ましというか...w

エンジニアリングなマネージャー業ふりかえり

...とまあ、色々と感想を書きましたが、自分の実務体験上どうだったか?のふりかえりをします.

「傾聴」の大切さ

メンバー相手の1on1、インターンくんや新人くんとの会話、経営陣とタイマンをはるetc...

結局何をするにしても、「傾聴」って重要だな!っていう学びがありました.

1on1でのアドバイスがうまく行ったときも、「予算くれ!」と交渉するときも、

  • 相手の立場や仕事だけじゃなく、人柄も把握する
  • 話を聞く、と同時に自分もオープンになる
  • 事によって、モノゴトが少しずつでも前に進む

これらがうまく行くと結果が出ましし、逆に結果に結びついてない時はどれかが欠けてるなあ〜、という印象があります.

「プロセス」の使い所(なんでもアジャイルにすんな)

「process czar(プロセスツァー)になるな!」そういうことです.

エンジニアのためのマネジメントキャリアパス」の3章で、かなりいいことが書いてました.

プロセスツァーの「対極」に位置するのは、「プロセスを完全に排除する管理者」ではありません。そうではなく、「プロセスは、チームのニーズや、チームが進めている作業のニーズを満たさなければならないという点を深く理解している管理者」です。

皮肉なことに、アジャイルは多くの場合、(「機敏な」「素早い」といった本来の意味とは正反対とも思える)「厳格な」方法論に基づいて実装されます。*9

私自身、アジャイルの信奉者ですが、エンジニアリング・マネージャーしたりCTOしながらこれに薄々気がつく→徐々にやり方を変えたことによってよかったことがあった(≒変える前はいくつもの失敗を重ねていた*10)なーっと学びました.

これはCTOになる前はちゃんと言語化出来てなかったのですが、知らない間に行動に移せたので良かったのかなと思っています.

なお、昨年のこちらのエントリーにそのまま直結する話であるとも思っています.

shinyorke.hatenablog.com

「技術アピール」からはじめる人脈つくり

カンファレンスでの発表、もくもく会の主催そしてこのブログを通じて今の仕事にたどり着いた、のもありますが、「この人はリードたる技術とかあるよね」的な信頼を外堀から埋める意味でやっててよかったと思っています.

何かのイベントをするときに登壇してくれたり会場提供してくれたりという支援をもらったり、逆に自分も支援して信頼貯金を稼げたりといい事づくしだったと思います.

っていう話はこの辺にもあるのでご興味ある方はぜひどうぞ.*11

note.mu

ゼロからのチーム作り(まさに今)

これはCTOとして現在進行系のことなのですが、今まで培ってきた人脈やつながり、採用スキルを生かして「世界最強の野球エンジニア・チーム作り」をゼロからやれているのは良いことかと思っています.

11月に一人フルタイムでJOIN、今後ももっと人増やせるように頑張ってる最中(詳細は言えませんが)ですが、ここまでに至る所で今までの経験が生きていて、

「ちょっと遠回りしたエンジニア人生だったけどよかったのでは?*12

と思っています.

テックリード、エンジニアリングマネージャー、CTOを目指す方へ

最近たまにこういう相談受ける&だいたい、いつも同じ回答な気がするのでまとめて書こうかなと.

CTO1年生を終えて2年生の自分が言うのも恐縮ですが、

  • 創業期もしくは資金調達後の1人目エンジニアからはじめようぜ!
  • 「目標とするエンジニア」「憧れのCTO」像を明確に持って自分を鍛える

この二つをオススメします.

創業期もしくは資金調達後の1人目エンジニアからはじめようぜ!

実を言うと、エンジニアのためのマネジメントキャリアパス」に書いてあること、まんまです.

望む望まない関係なく、色んな経験が降ってきますし、途中の採用や、「ブリリアントジャーク*13」対策など、嫌というほど味わえます.

「このチームで働きたい!」っていう所にあったらスッと挑戦すべきです.

なお、大企業出身者の人だと「部課長になってから動けばなれるのでは?」「声かかるまで待つ」的な人もたまに見受けられますが、

  • 確実にアテになる人脈あるならそれでも構わない、時期見て入っちゃおう
  • 人脈が無い(アテがない)場合、何かしらの外部アウトプット・活動が無いとそもそも検索にヒットしない(SEOみたいなもの)

という現実と向き合った上で判断したほうがいいかなと思います.*14

「目標とするエンジニア」「憧れのCTO」像を明確に持つ

これは本に書いてない事です.

CTOになる前・なった後両方共、

「あの人(スーパーなエンジニア)だったらどういう判断・決断するかな?」

という想像と、自分が下した判断・決断のDiffを取る事により、自分の技術・ビジネススキルや判断力・決断力を磨くようにしてました.

その対象がCTOやVPEだったりすると、Diffを取ってる内に自然とCTOやVPEに必要なスキル・判断力・決断力が身につくと思うので、ぜひやってみては!?

以上、今年はじめての書評でしたー

*1:出たのは昨年ですが、昨年は意図的にこの手の本を避けていたので今年に入ってから読み始めましたとさ.

*2:が、エンジニアリングに対する責任は自分が持っていること、決断・判断に必要な権限は有しているのでCTOと名乗っても問題ないと思っています.

*3:出入りが激しいのは転職が多いからってのとやっぱ寄り道と言うか紆余曲折が

*4:私はAction Reading好きで結構飛ばしながら読む派なのですが、この本に関してはそれは該当しないと思い、時間かけて最初から最後まで読みました.

*5:まえがきでここまで読み応えがある本も珍しい.

*6:1on1の是非そのものは別として、Yahooのこの本は名著です、結構好きだし参考にしました.

*7:ここまでは割と大体の人が経験するハズ、何らかの形で.

*8:今までは野球のことがしたくてずっと分析・解析コードを書いてましたが、今は休みの日はちょっとした作業や写経を通じてコード書くようにして腕が腐らないようにしています

*9:厳しいことを言うと、アジャイルコーチやスクラムマスターで結果でない・イマイチな人はこれに気がついてないもしくは気がついてるけど無視してる、のどちらかだと思う.

*10:失敗は成功の母とはよく言うもんだなと、いやホント学んだし当時の関係者には申し訳ないというお気持ち

*11:我ながらよくまとまってると思う

*12:今年でキャリア19年目、40歳でマネージャー業が正味2年ちょい、残り17年は思いっきり回り道してたよ!って意味

*13:意味は本読んで欲しい、実際この対策色々と経験してちょっと強くなった感ある

*14:これも厳しいこと言うと気が付かない人は「大企業病」に罹患してるよきっと