概要
こちらの本を読んだのでまとめようと思います。
300ページ程の本でしたが、かなり内容的にはボリュームのある、ずっしりとした本という印象を受けました。
これまで読んだマネジメント系の本と部分部分で被るところはあるにせよ、かなり一つ一つが細かく、細かいのに内容としては広範囲を網羅していました。
テックリードといった階層からVP、CTO(ここら辺はコンテキストによって意味が分かれます)と呼ばれる層の人に向けての内容が多く、自分としてはまだ先の話だなと思いながらも、やはり知っておくことに意味があると思い読んでいました。
本の中でも、管理者、とりたて技術系に関わる管理者にとって一番大事なことは、「好奇心を絶やすな」ということが一貫して書いてあったので、そういう意味でも知っていくという気持ちは大事にしたいなと再確認できました。
では、まとめを書いていこうと思います。
# マネジメントの基本
第一章ではマネジメントの基本について書かれています。
マネジメントする側になる前に必ず人が通る道として、マネジメントされる側になることです。
マネジメントの基本として、マネジメントされる側の視点からこの章はできています。
他の本でも書かれていたことが多かったのですが
- 1on1について
- フィードバックについて
- 人間性
について書かれています。
やはり、上司との1on1といっても、何を話せば良いか分からなかったり、意味のない1on1になってしまうことがあります。
それを避けるための改善方法や心持ちを書いてあります。
## 1on1の意味
1on1は、人間的なつながりを作ることに一役買うものです。
上司といえど、人間なのでいろんな理由で感情が揺れる時もあります。
また合う合わないといった人間的なところでのコンフリクトも起こりやすくなります。
そういった中で、自分の今のやりたいことや、気になる言動などの面から上司を見て、フィードバックをするということも大事になっていきます。
1on1では、自分の考えてることを伝えると同時に、上司に自分の考えるキャリアについてアドバイスをもらう場として活用することが良いです。
エンジニアとして有能で尊敬できる人が上司になった途端、自分と合わなくなるといったこともあります。
そういったことがある時、チームを変えてもらうなどの相談をすることも必要になってくるでしょう。
## フィードバック
気がついたらその場ですぐに行うことが大事になります。
しかし、誉める時はみんなの前で、注意をする時は1on1などで個別に行うということを心がける必要があります。
# メンタリング
第二章では、メンタリングについて書かれています。
初めてマネージャーとなる前に、インターンなどの研修を任されると流れ的には良いです。
新卒1、2年の方がメンターをやる際には、まだ自分がメンティーだったことが新鮮な記憶としてあるうちにやることで良いことを引き継げるという利点もありますし、シニアエンジニアであれば技術力や経験を伝えることもできるという利点があります。
しかし、インターンの研修と言えど、細心の注意を払う必要はあります。
これからインターンを受ける人にとって、そのインターンが良いものであったかどうかによって自分達の会社の見え方も変わってくるでしょうし、良いこと悪いことの広まり方にも大きく関わってくることだからです。
## インターンシップ
学生であることが多いと思うので、学業などにも時間が割かれてしまっています。
その中でインターンとして選んでいただいているので、無理な要件を提示することは良くないです。
### インターン中のプロジェクト
プロジェクトは自分なら、2、3日でできるようなタスクをしてもらうのが良いでしょう。
特に納期が迫っていないものを選んであげるのが良いです。
### 最初の2,3日程度はインターンに付きっきりの気持ちで取り組む
インターンの最初の活動は新入社員とほぼ変わらないです。
会社概要など説明を受けたりなど。
その期間は付きっきりで
- IDEの設定
- コードの説明
- また、タスクによって圧倒されていないか様子を見る
などでそばにいるように心がけます
### 傾聴する
ひたすら自分だけ喋りっぱなしではなく、インターンからの言葉を理解することです。
ここでの理解というのが、言葉上だけのものではなく
- 表情
- 言葉
- 仕草
など、その所作全てを注意しながら見て聞くことが重要になります。
特に相手にとって自分は「強大な力のある人間」に見えてるはずなので、相当の緊張とプレッシャーがあるはずです。
そのため、まずは自分自身がゆったりと構え、質問しやすい雰囲気を作ってあげることで言葉を引き出すようにすることが特に重要になります。
### プレゼンテーション
最後にはプレゼンテーションをしてもらうのも良いでしょう。
自分がやり遂げたインターンの集大成を先輩社員に見てもらうのでも良いです。
達成感や、プレゼンテーションのやり方を学ぶ機会にもなります。
それにより、良いインターンができたと思ってもらえたら最高です。
## 新入社員
新入社員は、まず会社の文化についてはほぼ知らない状態で入ってきます。
それは、休暇の取るタイミングや、質問の仕方、この時期は繁忙期といった背景の部分の知識です。
そのため、自分自身がもう雰囲気の中に浸かっている場合、気づけない点があるので新入社員が入ったタイミングでメンタリングを通してリフレッシュさせる良い機会になります。
### ドキュメント
環境構築は誰もが行うことですが、その資料というのはすぐに変化が起こりうるものです。
その変更に対応するためにも、新入社員が入ったタイミングで洗い出し更新していくことが必要になります。
### アルファギーク
アルファギークとは、チームのまとめ役にはもっとも優秀な人がなるべきという思考の人のことを言います。
どういう弊害があるかというと、ヘマをした部下などに対してけなしたり、部下の仕事を勝手に作り替えたりしてしまったりすることになります。
しかし、短所ばかりだけではなく、良い面もあります。
気が向きさえすれば、素晴らしいことを山ほど教えてくれます。
画期的なシステムを設計できる腕もあるので、部下としてそのプロジェクトに参加するのは楽しいものだそうです。
そういったこともあり、上記にあるような短所に目をつぶるようなエンジニアもいるようです。
## メンターの重要な心得
### 常に好奇心を絶やさずオープンな心で
メンターにとってメンタリングは、新人のフレッシュな目を通して世界を見つめ、好奇心を刺激してもらう絶好の機会です。
自分では不明点なことなど一つもない状態から、質問されて初めて実は外から見たら不明な点だらけだったということに気付かされることも多いです。
新人を指導することで隠されたパターンが見えてきて、普段思いつかないような方法を導き出すということにも結びつけることができます。
### 相手の言葉をよく聴き、相手の言葉で話す
これはメンターだけに留まらず、全ての人にいえることですが、コミュニケーションスキルにおいて重要なことになります。
特に上記にもある「傾聴」のスキルが重要です。
しっかり、メンティーの言葉面だけではなく、その所作や声色、表情などからも聞き入れることが大事になります。
そして、シニアエンジニアの中には悪い癖として、反論されたりするとお説教などをしてしまう人もいますが、チームとして一緒に仕事をする上で相手が理解できるやり方で傾聴し、意見を伝える必要があります。
# テックリード
よくある誤解として、テックリードはプログラムを書くことに没頭していたい人や没頭してしまう人がなるべきものというものです。
プログラムに没頭したい人はテックリードにはなるべきではありません。
つまり、誰よりも経験豊富なエンジニアや、誰よりもすばらしいコードが書けるエンジニアがなるべきというわけではないということです。
では、テックリードにはどんな責務が定義されるでしょう。
これの答えとして、厳密には定義はありません。
この本では、コードを書くことももちろん責務の一つにはなりますが、主に
- 経営陣との連絡や話し合いの場でチームの代表を務める
- 昨日をデリバリするための計画を練る
- プロジェクト管理の大部分を細部まで担当する
といったことが説明されています。
そして、多くの場合スキルとリーダーシップの両方が求められるため、「1人が長期にわたって就く職位」ではなく、「複数の人が順次一時的にそのすべてを担う職責群」として定義された方が良いです。
ここにThoughWorks社のプリンシパル・テクニカル・コンサルタントのパトック・クアが提唱したものを引用しています。
テックリードとは、（ソフトウェアの）開発チームに対する責任を担い、最低でも自身の職務時間の3割はチームと共にコードを書く作業に充てているリーダーのこと。
非技術系の相手との協業する際には重要な役割を演じることも責務になります。
人的な管理を望んでいないエンジニアにとっても、プロジェクト管理のスキルはシステムを設計する作業と類似点は多いので、有意義なスキルになります。
## テックリードなら必ず知っているコツ
実際のプログラミングの作業からあっさり一歩引き、技術面での貢献とチーム全体のニーズへの対応のバランスを取る努力を惜しまない ということです。
これは、これまで得意としていたプログラミングという領域から出て、不慣れな新しい仕事を覚えていかなければならないといった面においてかなり辛いことです。
会議などが増えることにより、コードを書く時間が減ったりや、細切れ作業になることによりガッツリプログラムに向き合う時間が取れないという点において、時間のバランスを取るスキルが求められます。
しかし、他のメンバーにはしっかりプログラムに向き合って作業してもらう必要があるので、それを可能にするスケジュールを組むことも重要になってきます。
## テックリードがコードに触れるということ
上記で、「実際のプログラミングの作業からあっさり一歩引き」と書いたのですが、「職務時間の3割はチームと共にコードを書く作業に充てている」と矛盾していると感じた人もいるかと思います。
では、これの意味するところは何なのか。
例えば、何か問題があったとして、すぐに自分でその原因を掴みたいと思ってもそこに自分が注力しすぎてしまうのは良くないです。
まずはチームにその問題を伝える必要があります。
プロダクトマネージャーや技術管理者にも伝える必要はあるでしょう。
そして、任せられるメンバーに適任を見極めるということも重要になります。
その上で自分が取り掛かるかどうかを判断します。
## プロジェクト管理
アジャイル開発が流行っている今、プロジェクト管理は不要では？という問いもあるかと思います。
これについては、そんなことはなくアジャイルを通して、タスクを分割し、それに基づいて計画を練り、価値を「全部一度に」ではなく「徐々に追加していく」ため、プロジェクトを検討する上で大変有用になります。
詳細がはっきりしない中でのタスクの分割などを行うことは恐ろしいことです。
また長期にわたるプロジェクト管理を好んでやりたいと思う人は少ないでしょう。
しかし、キャリアラダーを登るにつれて、自分1人がこなせる範囲を超えた複雑な仕事をする上でこの分割作業をするコツというのを身につける必要があります。
## 管理者としての日々
この本では、管理者となる前のイメージと、実際に管理者になったあとのイメージとを比較して書いてくれています。
実際になったあとのイメージだけまとめておきます。
- 人は言葉で伝えるだけでは動いてくれないということ。
- 何もしなくてもあなたの意見に賛同し、ついてきてくれるというのは幻想
- 昇格や昇進についてネガティブなことを伝えないといけない時の士気を高めることの難しさや、自分の無力さを感じることへの辛さ
こういった大変さがあることに、管理者になった後に気づいたとしても
進路変更が可能ということは忘れてはいけません。
また技術畑に戻ることも可能ということを念頭に置きつつ、自分には何が向いているのかを常に目を開いておく必要はあります。
## 優秀なテックリードとは
ざっくりとまとめます。
- アーキテクチャを把握している
- チームプレイの大切さを心得ている
- 技術的な意思決定を主導する
- コミュニケーションの達人である
# 人の管理
## コミュニケーションにおいて大事なこと
信頼感と親近感を作るために1on1などで聞くと良いこと
- 褒められる時は人前がいいか、個別がいいか
- フィードバックの伝え方
- 不機嫌な時どんな仕草をするか。もしくは、不愉快な気分にさせる要因はどんなのがあるか。
- 耐え難い上司の振る舞い
- チームにきてから良いこと悪いこと、なんでも言ってもらう
こうしたことを質問し、把握しておくことで幾分かコミュニケーションをしやすくしたり、その人の状態を知ることができます。
## 1on1のスケジュリング
標準的には、週に1回とされています。
一度週に1回で運用し、多すぎる少なすぎるの判断を見極めるのが良いかと思います。
また、時間に関しては午前中が良いです。
午後はあれこれ忙しくなることも多かったりするため、お互い午前に出社し、スタンドアップミーティング（朝の定例のような）ものがない場合は午前に設定するのが良いでしょう。
しかし、部下の抱えてる対顧客のスケジュールがある場合は、そちらを尊重すること。
## 1on1のやり方はそれぞれの部下によって変わる
部下によっては、TODO形式でやりたい人もいるでしょう。
Google Driveなどで事前に話すことを共有するのもいいでしょう。
フィードバック型（非公式なフィードバックやコーチング）が必要な人もいるでしょう。
どのように報告したり、共有するかはチームメンバーによって変わると思うので、一貫してこれといったものを貫くプロセッサーにはならないようにしましょう。
# チームの管理
エンジニアリングリードは、シニアエンジニアであった時と同じようにコードに触れるという時間は圧倒的に少なくなります。
しかし、そうとはいえ、小規模な技術成果物の作成や、バグ修正や機能の作成といったことについては携わることが必要です。
エンジニアリングリードは、独立した管理者であり、自分とは異なるスキルセットをもつメンバーから成るチームを管理する権限と能力を有します。
優れた管理能力に加え、製品に関する技術的ロードマップを管理するリーダーの役割を持ちます。
## ITスキルの維持
コードを書くことから卒業してしまった後も、技術面においての意思決定を行い、責任を負います。
この時、システムのアーキテクトや、細部の責任を負うシニアエンジニアに対しても自分の下した決定に責任を負う必要があります。
そのを可能にするのが、「技術者の勘」というもので長年培われるものです。
しかし、そうとしてもコードを少なからず書くということをする必要がでてきます。
それは、ボトルネックや作業工程の問題点のありかをすばやく察知するために、コードに従事しておく必要があります。
それが上記でも書いた、ちょっとしたバグ修正や小機能開発などになります。
そのおかげで、コードのデプロイに時間がかかるなどの問題点にも当たり、改善点といったことも見えてきます。
## データ重視の文化
チームの生産性に関するデータ（機能の完成までの所要時間など）や、品質の測定に関わるデータに基づき、機能開発や技術的改変についての意思決定を評価するように慣れてもらう必要があります。
## 将来を見据える
「今、ここ」より2歩先を見据えて考えていく必要があります。
プロダクトロードマップに描かれている今後の展開を把握することで、テクニカルロードマップをベースにした管理がやりやすくなります。
また、新しいJavaScriptフレームワークなどによって、よりインタラクティブな体験を作るなどのためにも、現在に対する見方を変えてしまう可能性のある新技術を常に把握しておけるように情報収集の時間も設ける必要があります。
## 納期間近にはノーという務め
上からも下からも要求の中に、相当複雑な実装作業が必要なものもあります。
その場合には、しっかり実装作業のコストを提示し、ノーと断る判断をしなくてはいけません。
本当に期限内に完成させなければならないものをチームと共に厳選しないといけないです。現実的に何なら実装可能か、すべてを完成させるにはあとどれくらい時間が必要なのかの選択肢をチームに提示することもあり得ます。
### ノーの言い方
ただ、ノーと言うのだけでは良くないのは、これまでにもコミュニケーションの大事さから分かったと思うのですが、ではどう言えばいいかです。
「はい、それでですね」
といった表現を使うテクニックがあります。肯定系で受けつつも、その後に問題となる点を論うことで、優先度を見据えた現実的な交渉に持ち込めることが多くなります。
### ポリシー
自分が何に対して、どの基準を超えたらノーと言うかという基準のポリシーを持っておくことが良いです。
そしてそれをメンバーが認識することで、メンバーや上司からの要望があった時にそのポリシーに満たしているかどうかをメンバーから説明があったりすることで自分がイエスと言いやすい状況を作ってくれます。
もしくは自分自身が決定を下す際の武器となりえます。
また、低リスクで影響の小さな意思決定に対して、即座にノーと言えるように慣れることも大事になります。
# 複数チームの管理
複数のチームの管理となると、技術部長レベルになってきます。
つまり、外部との間にも入っていき、関係を築いたり予算編成をするような立場になります。
そういった役職になると、さすがにコードを書く作業は全くなくなってきます。
週に2日は丸々コードを書く時間に充てられない限り、コードでの作業生産ができないからです。
## それでもコードに追いつくことは必要
そんな状況でも、コードレベルで追いかけないといけない場面もあります。
そのために何ができるか。
- コードレビューを（少なくとも副レビュアーとして）引き受ける
- インシデント時に必要に応じてペアプログラミングを行う（デバッグが苦手なメンバーに対しての教育の一環として）
- 全くコードを書くつもりがない人でも、週に半日でもいいのでまとまった自由な時間を作り、何か創造的な活動に使う。
- 技術系のブログを書く
- カンファレンスで行う講演の準備
- オープンソースに参加するなど
## クイックウィンはない
コードを書くと、その場でバグがなくなったり、新しい機能が追加されたりとクイックウィンがありますが、管理系には新米時代には早々そういったものがないです。
そのため、自分の生産性に対して不安であったり、せっかく身につけたプログラミングのスキルを失うという不安が生まれてきます。
しかしこれはしょうがない話で、トレードオフとして「あちらを立てれば、こちらが立たず」といったふうに諦めるしかありません。
どちらかを選ばざるをえないです。
エンジニアとしてのヘマであれば、自分のバツの悪さですみますが、管理者でのヘマは、チームのみんなに迷惑がかかるため、管理者としての仕事をお座なりにしてクイックウィンのためにコードに向き合ってしまうのは良くありません。
しかし、そんな時でも管理者として自分が1日にこれだけの仕事をやり遂げたのだと振り返ることが大事です。
それだけでも1日の仕事としては十分になります。
## 委任する仕事、しない仕事
1. 頻繁で単純な仕事
直属のチームのテックリードやシニアエンジニアなら訓練なしで任せられます。
- スタンドアップミーティングを開く
- 週毎のチームの作業の進捗状況の要約を書く
- 小規模なコードレビューを行う
2. 頻繁でない単純な仕事
自分で行う方が手っ取り早い
- カンファレンスのチケットを予約する
- 四半期報告書を生成するアプリケーションを実行
3. 頻繁でない複雑な仕事
あなた1人でこなすべき仕事ではありますが、後輩の有望な管理者に伝授していく必要があります。
- 勤務評価の要約を書く
- プロジェクト支援要因を新たに何人雇う必要があるかについて意見を言ってもらう
4. 頻繁で複雑な仕事
チームの有望なメンバーを育成と同時にチーム全体の運営力を強化する機会になります。
- プロジェクトの計画立案
- システムのデザイン
- システム障害の復旧作業のまとめ役
## エンジニアはせっかちであるべき
管理者としての地位が上がってくると、部下から模範行動を求められるようになる。
その時に教えることが、「焦点の絞り方」になります。
「せっかちに重要なことを見極める」ということと「帰宅する（無精になる）」という2つを実践するのが良いです。
ろくに考えもせず時間ばかり費やすのではなく、重要なことを見極めて自動化を推進し、効率をよくすることで、面白い仕事ができる環境を作る必要があります。
面白い仕事というのは、脳を広範囲に使う仕事で、何時間も何日もぶっ続けでやれる類の仕事ではないです。
そのため、せっかちになることで重要なことをできるようにし、面白い仕事をしていきましょう。
# 複数の管理者の管理
最大限のテコ入れができるようになるまで、自分が「本当に重要かどうか確信はもてないが、何となく怪しいと感じること」を最後まで見届ける必要があります。
そうでない時は、いつどこで介入するか直感的に判断するための経験則や勘を十分に身につけられていないということなので、十丁だと思える時でも顔を出すことが推奨されます。
## スキップレベルミーティングは一つの手段
上記のようなことを判断するために、一つの有効な手段としてスキップレベルミーティングがあります。
これは、2つ以上ランクが離れた部下との関係を維持することために行われます。
2つ以上離れた部下となると、人的リソースとしてしか見れなくなってしまいます。
そうならないために、1人の生身の人間として見る必要があり、そのために時間を割くというのは必要なことになります。
ただし、1on1のような形式ばったミーティングだと40人、50人レベルの部下になってくるとそれだけで時間はなくなってしまいます。そのため1on1ではなくとも、お昼に行くであるとか、チームの人たちとちゅ食をとりながら近況を話すなどでも効能が得られます。
## 新任管理者の管理
管理者の最初のころというのは自分が何を知らないかも分からない状態です。
新任管理者を統率する管理者にとって、自分の職務時間の一部を部下達のために有意義に使うのは非常に大事なことです。
長期にわたって自分の組織に利益をもたらす上で欠かせない初期投資とみなすべきです。
そういった新任管理者の中には、自分が経験したことのない大変そうな職責を前にし、「知らんぷり」を決め込む人もいます。
そうなると問題が潜在化し、大きくなったあとに発覚するということもあり、そのせいで新任管理者が辞めてしまうといったことも起こり得ます。
そうならないために、十分な指導ができるようにスキップレベルミーティングを設定するなどを行うと良いです。
## ベテラン管理者の管理
新任管理者と違って、何をすべきかを心得ていて、あなたのてを借りなくてもきちんと遂行するので、良いこと尽くめと思われるかもしれません。
しかし、マネジメントは会社や組織の文化に根ざした仕事です。
あなたが採用した人材が社風に合わない人材であったりすれば、あなた自身が問題を抱え込むことになります。
草創期からいるメンバーを経営チームに参画させたがるのは、その会社のDNAを理解しているからというのがよくある理由になります。
そう言うわけで、ベテラン管理者が入ってきた時にあなたが取り組むべきことは、「チーム全体に合う人物であるかどうかを確認すること」になります。
管理者はサブカルチャーを生み出す存在なので、今のカルチャーにそぐわないサブカルチャーを生み出すことは問題になってしまいます。
管理者も人ぞれぞれで、どんな文化を持った管理者であるかは人によることが多いです。
そのため、新たな人材を採用する際にも、信奉する文化を判断基準の一つにする必要があります。そぐわない人を採用してしまった場合
1. 管理者がチームを掌握できず、あなたはその管理者を辞めさせざるを得なくなる
2. チームメンバーの大半が辞めてしまって、やはりあなたはその管理者を辞めさせざるを得なくなる
といった状況に陥ってしまいます。
## チームが機能不全になってしまったら
- 仮説を立てる
- データをチェックする
- チームを観察する
- 質問をする
- チームの人間関係をチェックする
- 支援する
といったことをする必要があり、常に好奇心を失わずチームのデバッグをしていく必要があります。
## 技術力の点で時代遅れにならないように
- 情報収集のための質問をする
- 勘の拠り所に
- コードを読む
- 自分が疎い領域に詳しいエンジニアに解説を仰ぐ
- ポストモーテムに同席する
- 業界のトレンドを常に把握する
- 社外での技術系の人脈作り
# まとめ
ここでまとめられなかった部分（経営管理についてや、採用の詳細、キャリアラダーについてなど）の部分もありましたが、一先ず今の自分に必要なところをまとめたような感じになります。
まとめの割に1万字を超えてしまったので、もう少し厳選すべきかと思いましたが、今の自分には再び理解するために読み直すには、それだけ書かないといけないほど中身の濃い本だったということです。
かなり内容的には濃い本だったので、これからマネージャーになるという0からベースの人にはかなり内容的に重たいかもしれませんが、読んで良かったと思います。
