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

https://gyazo.com/bacf24c800ef810b76faf36139cf1d0a

読書の進捗

✅ 推薦の声

✅ まえがき

✅ はじめに

✅ 1章 マネジメントの基本

✅ 2章 メンタリング

✅ 3章 テックリード

✅ 4章 人の管理

✅ 5章 チームの管理

✅ 6章 複数チームの管理

✅ 7章 複数の管理者の管理

✅ 8章 経営幹部

✅ 9章 文化の構築

✅ 10章 まとめ

読書メモ

PDF から文章をコピーするとき、改行の位置に半角スペースがひとつ入ってしまうのだよな

推薦の声

まえがき

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

はじめに

1章 マネジメントの基本

「できる上司」は「管理のされ方」も心得ています。これには「上司との良好な関係 の構築」が含まれてはいますが、この 2 つは同義ではありません。職場で自分が経験 することに対して当事者意識や主体性をもち、上司との関係づくりにおいても上司任 せにしないことこそが、職場で充実した日々を送り、満足のいく形でキャリアを積ん でいく上で重要な姿勢なのです。

章末の質問リスト

「できる上司」と思える人のもとで働いた経験はありますか。「ある」と答えた人にお尋ねします──その上司のどのような行動や業績をすばらしいと思いましたか。

ある

ぼくがなにを言っても (ときには筋の通っていないことを言っても…) 聞いてはくれた

ぼくが思う存分に挑戦できるように、責任を負ってくれた

ぼくの「できていること」も「できていないこと」も教えてくれた

ぼくにどんなことを期待しているか言葉にして教えてくれた

上司との1-1の頻度は? 議題は上司が提案していますか。1-1が現況確認会議となっている人にお尋ねします──他の手段で現況報告をすることはできませんか。

最近はあんまりやっていない！

私生活で重大な出来事が発生した場合、それを上司に抵抗なく話せますか。あなた個人に関する何かを、上司は理解してくれていると思いますか。

上司が相手の場合に限らず、わりとなんでもパブリックにしちゃうタイプだと思う

「じゅーんさんの前でこの話題はタブー」みたいな領域をつくりたくない気持ちがある

上司から適切なフィードバックをもらえていますか。不十分だったり不適切だったりしませんか。それともフィードバックなどまったくもらえない関係でしょうか。

ぼくからの「フィードバックくれ！」という要求が弱いせいで、あんまりもらえていないと思う

活動に対してのレビューはカジュアルにもらえているので、そういう面では心配していない

あなたが仕事上の今年度の目標を立てる際、上司は手助けをしてくれましたか。

2章 メンタリング

健全な組織では新人研修 におけるこうしたメンタリングを「メンティーとメンターの双方にとっての好機」と 捉えています。

ぼくもそう捉えている

人的管理において基本中の基本とも言えるのが「傾聴のスキル」です。

はい

新入社員のメンタリングは非常に大切です。そうしたメンタリングをあなたが命じ られた場合、指導内容としては、新人のための研修、スムーズに会社に溶け込んでも らうための支援、あなたと新人の社内での人脈づくり、などがあげられます。

ところで、時折どこかのオフィスで(メンターであるか否かに関係なく)「アルファギーク(最先端の技術に異様に詳しく、ものすごくとんがったコンピュータおたく)」 に出くわすことがあります。こういう人は「常に正解を言うことができ、難問という 難問を片端から解いてしまう、チームで一番優れたエンジニアでありたい」という思 いに駆り立てられています。

偏見がありそうw

最後にもう 1 点。メンタリングは自分のチームの有望な若手の能力や功績を認め、 未来のリーダーとして育成する好機としても活用してください。

これは実体験から得られた感触ともマッチする

3章 テックリード

プログ ラムの作成作業に思う存分没頭したいと望む人はテックリードの適任者ではありません。テックリードがそういう作業に没頭しているとすれば、その人はテックリードの職務を果たしているとは言えないのです。

ソフトウェア業界の肩書きにはありがちですが、「テックリード」にも業界共通の定義がありません。

ワッハッハ

ところで、他の業界だと共通の定義があったりするのかな？実例を知りたい〜

このような方針を採ったのは、「チームの変化や進化に応じて、さまざまな階級のエンジニアがテックリード役を引き受けられること、また、新旧テックリードが必ずしもエンジニアとしての階級を変えることなくテックリードの座を明け渡したり引き継いだりできること」の価値を認め、実現したかったためです。

「テックリード係」みたいにして着脱可能にしている、と理解した

テックリードとは(ソフトウェアの)開発チームに対する責任を担い、最 低でも自身の職務時間の 3 割はチームと共にコードを書く作業に充てている リーダーのこと。

やがて、本を執筆したり、講演をしたり、オープンソースとして公開したり、と粘り強く努力を重ね、多少の運にも恵まれて、業界ではちょっと知られた存在になります。たとえ口下手でも内気でも、そうした資質が問題視されることは一切なく、「この人は自分流の伝え方をだんだんに編み出していくタイプなのだ」と好意的に解釈してもらえます。私の語る事柄には、それほどの重みがあるのです。社内で私を知らない者、私の仕事の価値を理解しない者、私の意見を尊重しない者はひとりもいません。

要するに私は「やりがいのある面白い仕事」と「名声」と「長年培ってきた専門知識」のすべてをきわめてバランスよく掌中に収め、類まれな存在として周囲の敬意を集め、高給を得、強大な影響力を及ぼす立場へと登り詰めたのです。

妄想すごい

「プロセスツァー(process czar=手順に異常にこだわる開発手法の信奉者)」とは、アジャイルでも、かんばん方式でも、スクラムでも、リーンでも、はたまたウォーターフォールでも、とにかく特定のプロセスや手順、手法を崇め奉り、その手法を正しく実践しさえすればチームの抱える難題は漏れなく解決できると信じて疑わない人のことです。

あなたの会社(組織)ではテックリード(に相当する職位)を設けていますか。「設けている」と答えた人にお尋ねします─ テックリードの職務内容を規定した職務記述書も用意されていますか。「用意されている」と答えた人にお尋ねします─ その内容はどのようなものでしょうか。「用意されていない」と答えた人にお尋ねします─ 貴社のテックリードの職務を、あなたはどう定義します か。テックリードを引き受けている人自身はどう定義するでしょうか。

テックリードの役割を引き受けようかと考えている人にお尋ねします。今すぐ引き受ける準備ができていますか。プログラミング以外の仕事にも抵抗なく自分の時間を割くことができそうですか。今後チームをうまく率いていくためにはコードベースを熟知していなければなりませんが、その点であなた自身はどうだと思いますか。

テックリードにどのようなことを期待するか、上司に訊いてみたことはありますか。

今までのテックリードの中で最高だと思えるのは誰ですか。その判断の理由となった、その人の言動をいくつかあげてみてください。

あなたに不満や苛立ちを抱かせるようなテックリードのもとで働いたことがありますか。その判断の理由となった、その人の言動をいくつかあげてみてください。

4章 人の管理

管理者になりたての適応期に重点的に取り組むべき課題として「自分なりの管理スタイルを見つけること」があげられます。

それはそうかもね

「なにをヨシとするか」の価値観を見つめ直す機会にはなると思う

ここで効果的な戦略のひとつは「相手を理解するための質問─ 中でも、その人の管理をやりやすくしてくれる質問─ をする」というものです。

具体例が 7 つ載っている

なんで Git じゃなく SVN を使ってるんですか

急に dis られる Subversion

今後 1ヵ月/ 2ヵ月/ 3ヵ月の計画を立てさせる

新人研修用のドキュメントを更新させてチームに対する理解を促す

自分の流儀や要望をはっきり伝える

新人からもフィードバックを得る

5章 チームの管理

「直属の部下がひとりか 2 人いる管理者」から「チーム全体の責任を負う管理者」までは職位で言えば 1 段階上がるだけですが、だからといって職務内容も「個々の部下を管理する仕事」の総和に過ぎないかというと、そうではありません。

新任の管理者はとかく人的管理に過度に重点を置く嫌いがあるので、チーム管理という観点からも、もっと技術、戦略、リーダーシップにまつわる領域にも目を向けてほしいのです。

木ばかりを見ずに森を見ろ、ってことかねぇ

「インポスター症候群(自分の成功を内面的に肯定できず、自分の実力によるものではないと思い込む自己評価が異常に低い心理状態)」

結局、この一連の出来事で私が身をもって知ったのは「優れた管理者になる上で何よりも大切なのは、最強の技術力の持ち主であることではない」という点でした。

ふーむ

そしてその際にモノを言うのが、長年現場での実務で培ってきた「技術者の勘」です。

技術系の管理者としての成功を視野に入れて努力を重ねる場合、IT スキルの価値を甘く見てはならないのです。

「IT スキル」というか「技術力」がないとなあ、と思う

いったんコードを書く作業から遠ざかってしまうと遅れを取り戻すのが大変です。機が熟する前に離れてしまうと、中間管理職より上に昇るのに必要な技術力を十分身につけられずに終わってしまう恐れがあるのです。

なるほどなあ

エンジニアリングのスキルがチームの管理にも役立つ、ってのはあるよね

チームの管理をもっといい感じに進めるためにコードを書く、ってのはいい気がする (ウェブ系だと特に)

ブリリアントジャーク(brilliant jerk)。「エンジニアとしては格別に優秀だが、実に嫌なやつ」のことです。

それでプロジェクトに悪影響が出るなら「優秀」って評価も怪しくなってくるよなあ

これほどひどくはないものの、管理者としてやはり扱いにくいのが、チームに波風を立てる部下、マイナスの経験にいつまでもこだわる部下、噂話の度が過ぎる部下、「我々 vs. ほかのみんな」という排他的な思考パターンに陥っている部下などです。

ふーむ、なるほど

「噂好き」と「排他的な思考」は、たしかにやりにくいかもなあ

「波風を立てる」は慎重に読みたくて、まともな批判であれば受け止めるチームでありたいし、誹謗中傷であれば止めてもらいたい

「波風を立てる」だなんて曖昧な表現で濁さない方がいいと思う

ただ、チームのエネルギーを吸い取り枯渇させてしまいかねないこうした「エネルギーバンパイア」たちが巻き起こす有害な「人間ドラマ」は、辣腕管理者でさえ頭痛の種となるはずです。

アジャイル開発では 2 週間程度の反復が完了するたびに「振り返り(反省会)」を開くのが普通です。

英語原文では Retrospective かしらね…？

「反省会」という日本語を当てるの、けっこう反対なんだよな

6章 複数チームの管理

私がこの職務記述書でとくに明確にしたかったのは「技術部長はコードを書く作業に必ずしも毎日携わらなくてよい」という点です。

毎日じゃなくてもいいけど、ちゃんと関わった方がいいよ、というメッセージになっていると思う

私は常々「人を管理する道へと舵かじを切る前に、まずは十分時間をかけてプログラミングを完全にマスターしましょう」と声を大にして説いています。

プログラミングを完全理解、一生かかっても無理では？プログラミングチョットデキル…

こうしてソフトウェア構築のリズムを体得していないと、チームの問題を解決しつつ、常に質の高いソフトウェアをスムーズに作り出せるよう作業を推進するという技術部長としての重要な職務でつまずく恐れがあります。

せやな…

技術部長になったからにはコードはもうあまり書くつもりがないという人も、最低でも週に半日は(会議などの予定をまったく入れていない自由な)まとまった時間を作り、その一部分でもよいですから何か創造的な活動に使うことを強く推奨します。技術系のブログに書き込みをする、カンファレンスで行う講演の準備をする、オープンソースプロジェクトに参加するといった、創造力を高め、発揮できる活動です。

時間管理の究極のツボ、それは「重要と緊急の違いを見抜く」です。技術部長の職務の大半は、「重要」と「緊急」で 4 つの枠に区切った表(表 6.1)のどれかひとつの枠に分類できるものです。

https://gyazo.com/4be97ad1f9506ffc7b522625e107b949

この章で扱っているレベルの管理者とそのすぐ下のレベルの管理者とを比較した場合のおもな相違点のひとつが「前者は自分自身も直属の複数のチームも独力で管理できるだけの腕をもっていると上司から期待される点」です。つまり「重要だが緊急でないこと」が「緊急」になってしまわないうちに──とくに上司にとって「緊急」になってしまわないうちに─ 先を見越した形で対処できると上司から信頼されているわけです。

重要な問題に立ち向かうの大変だよね、でもやった方がいいってのは感覚的にわかる

新任の技術部長は、以上のような職責の数々を何とかこなしつつ先へ進むために、こんなふうに自問することを始めてください─ 「今私がやっている事は、どの程度重要なのだろうか」「それは『緊急』だから『重要』だと思えるのか」「今週私は『緊急』な仕事にどの程度の時間を費やしてきたか」「私はこれまで『緊急でない』仕事のために十分な時間を捻出してきただろうか」。

便利自問

さて、この項のタイトルは「意思決定と委任」としましたが、技術部長はどういった場面で「委任」をするのでしょうか。実はこの「委任」こそが、「一度に回さなければならない皿の枚数が多すぎる」感覚を何とか脱するための秘訣なのです。仕事が自分のところへ回ってきたら、こう自問してみてください──「私がこの仕事を受け持つ必要はあるのか」。その答えを決める要因はいくつかあります(表 6.2 を参照)。

https://gyazo.com/4e94183394b452c2e3b3b4976fc56e03

便利な表

言い換えれば「コードリリースの頻度」「コードへのチェックインの頻度」「インシデントの発生頻度」の 3 つが、そのチームが職務をしっかりわきまえ、その職務を遂行するのに必要なツールを備え、その職務を毎日遂行する時間を有するかを調べる際の重要な指標となります。

計測やっていきたいね〜

「無精」「短気」「傲慢」はエンジニアの三大美徳─ これはラリー・ウォールが著書『Programming Perl』で紹介している考え方ですが、私はこれがいたく気に入っています。これはあなたが管理者になってからも長く威力を発揮し続けてくれる美徳ですから、これを有効に活用するコツをどのレベルの技術管理者にもぜひ身につけてほしいものです。

自分が楽をするためなら、どんな苦労も厭わない！

7章 複数の管理者の管理

このレベルの管理者に特有の「隔靴掻痒状態での舵取り」に失敗して、自分なりの安易な道に逆戻りしてしまったりするのです。

この章では、以下のものも含めて、部署全体を監督する上で外せないコツを紹介、 解説します。

● 2 ランク以上離れた部下から情報を得るコツ

● 直属の管理者たちに責任を課するコツ

● 新任の管理者、ベテランの管理者を管理するコツ

● 管理者を新たに雇い入れるコツ

● 組織の「機能不全状態」の根を突き止めるコツ

● チームの技術戦略を調整するコツ

便利そう

私は直属のチームに「これからは門戸開放のポリシーで行くから」と告げました。何か問題が生じて話し合いたい時にはいつでも来てくれて構わない、と。部下の側であらかじめスケジュールを組めるよう、相談に応じられる時間帯さえ設けて知らせました。それなのに誰も来ず、相変わらず「誰からも報告を受けていなかった問題点を私自身が見つける」という状況が続いています。なぜこの点でチームのメンバーの協力が得られないのでしょうか。

これな…

「いつでも相談してね」に対して実際に相談してきてくれるのは 3 割くらいかな、という感触はある

では具体的にスキップレベルミーティングとは何かですが、ひと口に言えば「直属の部下の直属の部下との面談」です。

8章 経営幹部

ただ、我々は「汎用の」企業幹部ではなく、技術系の幹部です。しかもこの本は、エンジニアとして何年かコードを書く経験を積んだのちに経営の道へと舵を切り、以後、順調にキャリアアップを果たし、晴れて幹部になった人たちについて書いたものです。エンジニアである我々はテクノロジーの専門家ならではの責任を─ 絶えず変化を続けるテクノロジーの世界でキャリアを積んできた者ならではの責任を─ 担っているのです。

大変すぎ

…と思ったけれど、どの系統の幹部にしてもそれぞれの専門分野で求められること・期待されることがあるだろう

幹部はいずれにせよ大変なんだろうなって想像した (雑)

情報が十分に得られていない状況でも難しい判断を下し、結果に対しても責任を負う覚悟

自社の事業の現況を把握する能力と、将来のさまざまな可能性を想定する能力

組織の構造とそれがチームの作業に与える影響、さらには会社の組織を弱体化させるのではなく強化する管理体制を敷くことの価値に対する理解

組織だけでなく事業をも前進させるために建設的な駆け引きをする能力、非技術系の同僚たちとも協力して仕事を進める能力と、そうした同僚の視点を借りて広い視野に立ち、多岐にわたる問題に対処する能力

個々の部下に対しても担当の部課に対しても責任を課し、責任を問うコツ

めちゃ大変だ！

『High output Management』による 4 分類

情報の収集・共有

注意喚起

意思決定

ロールモデル

経営幹部の役割を成分で見てみると…

研究開発 R&D

技術戦略・ビジョナリー

組織化

執行

技術部門の対外的な「顔」

社内の技術インフラとその運用

事業化

さて、企業が成長し規模が拡大するにつれて、技術担当 VP の役割も「組織志向」から「事業戦略志向」へと変わっていくのが普通です。各部署のいわば「ミニ CTO」として、戦略と組織管理の仕事を天秤にかけつつ遂行していくことが多いのです。最終的には、技術担当 VP の役割を複数の人が分かち合う形で、技術チームに対する責任を共同で担うようになる場合もあります。

ペパボにて Chief Technical Lead という役職が誕生したときも「ミニ CTO」と言われていたように思う

CTO と技術担当 VP の 2 つのポストを設けている会社では、CTO が「より広範な戦略」と「社内での技術部門の位置付け」に、そして技術担当 VP が「アイデアの実現」に、それぞれ焦点を絞っているのが普通です。

ペパボもそんな感じかもね〜

ある朝 CEO が爽やかな朝日を浴びて目覚めると、すばらしいアイデアがひらめきます。

なんか怖い

しかし私の場合は、あの CEO からも、CTO 専門のコーチからも、助言や指導を受けることができました。また、幹部仲間にも意見や情報を求めたほか、技術チームのベテランメンバーに理論的な質問をして細かな問題を浮き彫りにする手法も実践しました。このように多くの人の支援と協力があったからこそ戦略を無事策定できたのです。

私は常々、製品を重視している会社の技術戦略を「その会社について思い描ける数々の将来像を可能にするもの」と好んで形容しています。

これはいい整理だと思うな〜

上層部入りを果たした直後に私が学んだことの多くは、幹部仲間との関係構築を迫られる中で気づいたり教えられたりしたものでした。技術部門以外の各種部門を率いる指導者たちと共に働く好機でしたが、とくにレント・ザ・ランウェイの経営陣は大勢の多様な幹部で構成されていたため、ひと口に「幹部」と言ってもとりわけ多種多様なタイプの人を知るきっかけとなりました。

ぼくは CTL になってから他の CTLs やマネージャのみなさんとの接点が増えて、視野を広げてもらっているな〜という感覚はあります

経営幹部じゃないけど、ここで言われているような体験を部分的に味わっているといえそう

あなたはもはやチームの一員ではありません。今のあなたにとってのチームは首脳陣であって、あなたの直属の部門は「次なる存在」となったのです。こういう視点の転換に成功すると、あなたは組織全体を一歩退ひ いて眺めるようになるはずです。たとえば「帰りに飲み屋へ」という場面ではチームと共に飲みに行きはするものの、途中で皆を残して一足先に帰ります。最後まで同席することには、チームにとってもあなた自身にとっても好ましくない結果を招く傾向があるため、ごくごくたまにする程度に控えるべきです。「チームの面々と終業後も親しく付き合う」というのはあなたにとってはもはや過去の事となったのです。

決め付け過ぎじゃない？

9章 文化の構築

私はこうした「構造」を疑問視する人を相手に議論する時には多少攻め手を変える ようにしています。「構造」そのものではなく「学習」を、「プロセス」そのものではなく「透明性」を前面に押し出して話を進めるのです。私たちがシステムを構築するの は、構造そのもの、プロセスそのものに価値があるからではなく、成功も失敗も引っ くるめて経験から学びたいから、また、成功例を共有し、失敗例から得た教訓を色眼 鏡を通さず素直に表現し共有したいから、といった具合です。長期的に見て、こうし た学習と共有を抜きにしては、組織の安定も規模拡大も望めません。

この観点はおもしろいな

スタートアップの人々が構造やプロセスに悪い印象を持っているというのも、感覚としてわかる

へぇ、おもしろい

フリーマン は、組織構造を嫌って「無構造」を装う集団には隠れた権力構造が生じがちで、その 要因は人間のコミュニケーションの本質と、そのコミュニケーションの規模拡大にま つわる諸問題だが、その実、無構造の集団でもうまく機能し得る状況がある、として、 次の 4 つをあげています。

1. タスク指向の集団

2. 比較的均質なメンバーから成る比較的小規模な集団

3. コミュニケーションが密な集団

4. スキルの専門性が低い場合

オン・フロイトさんによる企業リーダーの職務の比喩

草創期のスタートアップを率いる仕事「レーシングカーの運転」

少し会社が大きくなると「旅客機の操縦」

もっと大きくなると「宇宙船」

乗り物の大きさを見定めるための要素

社員数

創業からの年数

既存のインフラの規模

リスク許容度

正常に作動する複雑なシステムはどれも、正常に作動していた単純なシステムから進化してきたものである。(中略)複雑なシステムをゼロから設計しても決して正常には作動せず、修正して正常に作動させることもできない。まずは正常に作動している単純なシステムから取りかからなくてはならない。

小規模なチームが順調に機能している段階で、その構造やプロセスをいじり過ぎるのはあまり得策ではないとは思いますが、やがてどこかの時点で不都合が生じ始めるもので、まさにそこが組織構造の要修正箇所を見きわめる絶好の機会となります。

同意で〜す

なにもしなくてもうまくいくならそれがいくて、なにか起きたら手を打てば

新人研修のプロセスが確立されていないため、新人が加わるたびにチームの作業が何ヵ月も遅れる。これは構造の欠落による不具合です。昇進や自己啓発の目標や目安となるキャリアラダーが確立されていないため、社員が次々に辞めていく。これも構造の欠落による不具合です。チームの誰かがデータベースに直接アクセスし、誤って重要なテーブルを削除してしまったせいで生産がストップするのがこれでもう 3 度目だ。これも構造の欠落による不具合です。

共感する考え方です

構成員が、意識しなくても自然に仕事をこなせる、そんな行動原理や行動様式が組織にあれば、それこそがその組織の「文化」である。

フレデリック・ラルー

文化を理解し育てる 3 つのコツ

担当部署の文化を定義すること

会社やチームの価値観をプラスの形で体現している社員をほめることによって文化を強化する

コアバリューを採用面接のプロセスに組み込む

チームのメンバーにも応援を仰ぐ

実例をさらに集める

細部の表現を大切に

「詳細な説明」と「要約」とを併用する

ラダーと給与の関連性を考える

キャリアの初期段階では昇進の機会を増やす

キャリアの初期段階の給与幅は狭くする

ランク数の少ない層では給与幅を広くする

「ブレークポイント」に当たるランクの設定も検討する

実績報奨の手段としても

途中で管理系と技術系のパスを分ける

人的管理のスキルを中堅社員の必須要件にするという選択肢も

経験年数

最初から完璧なラダーなどない

こうした図式を論じる際によく引き合いに出されるのが「コンウェイの法則」です。米国のコンピュータ草創期のプログラマー、メルヴィン・コンウェイが提起した原則で「どのソフトウェアのアーキテクチャも、それを作った組織の構造を反映したものとなる」というものです。

アーキテクチャレビュー

10章 まとめ

私自身、身をもって学んできた中で何より大事だと思っているのは「人の管理がうまくなりたければ、自分自身を管理できるようにならなければならない」という点です。自分がどのように反応しているのか、どんなことからインスピレーションを受け、元気をもらい、どんなことに苛立ったり怒ったりしているのかなど、自分自身を理解することに時間を投じれば投じるほど、人的管理の手腕も磨かれていくのです。

もうひとつ、エゴと距離を置くために私が頼りにしているのが「好奇心」です。私には毎朝、自然に浮かんでくる考えを 1、2 ページほど書きつけ、頭を整理してその日 1 日に備えるという習慣があるのですが、書き終えると必ず「今日も 1 日、好奇心を絶やさずに」という「おまじないの言葉」を唱えるようにしています。