「エンジニアリングマネジャー入門」を読了した
先週はエンジニアリングマネジャー入門が発売されて、即読み始めて読みやすくて二日で読み終えた。
この本はマネジメントしないエンジニアでも読むべき入門書だった。
マネジメントはやってはいないけど、考えてるところは当てはまることが多い。
本書を翻訳した岩瀬さんは、一ヶ月前にエレガントパズルも翻訳されて出版されてたので、普通にすごい。
自分も少しだけど執筆した経験はあったけど普通に一冊書くのも大変だった。技術書と翻訳では異なる部分はあるかもしれませんが、2冊も同時期に書けるのがすごいと思った。
エンジニアはタスクの集中しがちな職業だけど、アジャイルやスクラム、ウォーターフォールにいたるまで作業だけではなく論理的に考えてチームと話し合うことは当たり前に行われる。
どのように進めるか。それらを話し合いときには議論して日々のデイリーやウィークリーを進める。
エンジニアにも採用から1on1や同僚に至るまで、コミニュケーションスキルも重要になる。
ジュニアのオンボーディングからプロダクトやプロジェクトで要求される。
マネジャー入門書ではあるけども、1エンジニアでも読むべきな書籍だった。
その要求に応えるべき、この本を読むきっかけになった。タイトル買いなところはあるけど。
この本はパートは4つに分かれています。
自分のチーム
自分のチームを大切にする
価値観の価値
信頼と弱さ
自分のチームは彼らではなく私たち
幸せとやる気と原動力
長期的な従業員のケア
キャリアラダー
重要な1on1
コラボレーション
マネジャーとしてのコミュニケーション
チェンジマネジメント
フィードバックの与え方
フィードバックを受け取る
良いミーティング
対立のマネジメント
クロスチームとオープンソースのコラボレーション
チームが最高の仕事をできるように支援する
チームの仕事の優先度付け
プルリクエストのスコープを絞る方法
実行の速度
プロダクトとエンジニアリングの時間配分
自分の仕事
ハイレベルでの優先度付け
日々の優先度付け
境界線を設定する
まず自分を大切すること
自分を信じること
自分のチーム
パート1は、自分のチームのことから始まる。
価値観や境界線といった部分について深く知ることができた。
まず、自分のチームを大切にすること。ここは基準にしていく。
どんなチームでも大切にして、信頼築き時には弱さもみせつつ、同僚との関係性を高めることがチームにとって良い方向に進む。
信頼と弱さ
信頼は水滴のように積み上げられるが、バケツでこぼすように失われる
この言葉の通り、信頼を得るには時間がかかる。近道というものはない。
チームではなおのこと信頼は避けて通れない。
顧客の信頼も同様だなと昔、営業やってたときに先輩にも言われた気がする。
スパイダーマンとバッドマンの仮説が良かった
スパイダーマンの映画はどんどん評価されていって、逆にバッドマンの評価は悪くなっているのは弱みをモデリングしているからという仮説。
スパイダーマンは弱みの部分がストーリーに組み込まれていて、人としての共感を得てる。
バッドマンは対照的に理解したり共感する部分から遠ざかってる。
主人公が強すぎてすっきりできる部分はあるけども、強すぎるがゆえに共感を得られない。
人間味てきな要素は人は求めるのではないだろうか。
弱みのモデリングは難しい。
チームに置き換えていくと、強すぎるチームだと気にかける暇もなく終わることも、弱みを見せ合うことでチームとしての助け合いができる状態を作ることが必要になる。
まずは自分が最初の行動として動く必要がある。
過去にひどい目にあった人を支援したい場合・・・
このケースは過去にあった。
そのときにどのような対応が良いのか。考えたことがある。
ひどい目にあったかどうかわからないが、やはりチームにとってギクシャクは良くない。
そんな信頼や関係がゼロ・マイナスの状態のときにどのようにすればよいかが書かれてた。
今の状態を尋ね、真摯に耳を傾ける
これはやったことがある。心を開かなければ何も始まらない。
経験的に調子や雑談からまずは潰していくことがチームメンバーにとっての関係性の改善に繋がる。
このパートでは、チームとしての人と人の関係づくりから個々の価値観をどのようにしてチームや組織に合わせていくかが書かれていた。
チームとしてのケアなども1on1についても書かれてたので、参考にしていきたいと感じた。
コラボレーション
このパートでは、上司とのコミュニケーション・適切なフィードバックの与え方・受け取り方などが書かれてた。
マネジャーとしてのコミュニケーション
押し付けずリードする。マネジメントするチームが大きくなると成果に集中する必要がでてくる。
チームにおろすよりも自分が動いたほうが早く終わるかもしれない。
自分でやるという短絡的な方法はやめること
ペースが落ちるが魚の釣り方を教えたほうが、チームとしてのメリットは大きい。
自分がリードしたことはどんどん社内にもアウトプットしていくことが必要。
魚の釣り方を教えるのはたしかにと感じた。
エンジニアだから自分でやったほうが良いとは若い頃はこれだった。
読み手や聞き手の視点から考える。
自分が書いた文章・チャットでの何気ないやりとり・自分が聴きたい情報を正確に書くことが求めれる。
つねに以下を考えて読み手や聞き手の視点になる。
何もしらない状態で、これを読んだら？どう思うか
すぐに知る必要があるものはなにか
聞き手や読み手が疑問に思うところ・重要視している部分はどこだろうか。その場で答えれるか準備する
テキストコミュニケーションがほとんどになることから、書式を明確にすることを意識したい。
チームが最高の仕事をできるように支援する
チームがより良くするためのどのようにすればよいか。手法についてこのパート3では書かれている。
チームの優先度付け
チームにタスクに対して優先度付は、規模感によって変わってくる。
しかし、基本となるのはタスクをどれくらい細かく切っていくことが重要になる。
そのうえでチームとして、会社の方針やプロダクトのビジョンによって優先度を決めていく。
ここ最近はこのタスクに対しての優先度などは意識しているところだった。
個人としての優先度をきちんと整理して、優先度ごとに進めていくように心がけている。
前まではあれこれ手当たり次第なところからやっていたが、それではタスクに対しての計測が難しくなる。
このタスクのリードタイム（作業開始からマージまでの時間）をしっかりと把握していくことが、次の見積もりの時間の基準が生まれる。
一週間でどの程度生産性を出すか。これらをしっかりとチームにおろしていく必要がある。
本書では、OKR（Objectives and Key Results）を利用すると書かれている。
OKRとは、高い目標を達成するための目標管理方法のことを指します。
Objectives は 達成目標 、KRは 主要な結果 を意味します。
目標設定とそれに対する結果をしっかりと管理することがチーム開発にも必要になる部分です。
チームでもOKRを利用することで、優先度付けが理解しやすくなる。
よくある会社のビジョン・プロダクトでなにを提供していくのか。しっかりとした形で定義することで、個々のタスクの理解度・優先度が漬けやすくなるのかなと感じた。
目標はいかにしてシンプルであるかもチームの優先度付けも変わってくる。
また、結果に対しての計測もしっかりと振り返ることで次のアクションを議論しやすくなる面をもつ。
ほかにもエンジニアではよくあるプルリクエストのスコープについても書かれていた。
スコープを小さくすることを常に意識している。
スコープが小さいとメリットが大きく。スコープが広いとデメリットが多くなっていく。
広い分はやく終わらせることができるように思えるが、大きいとデグレやテストが難しくなり見えにくくなる部分でバグが発生するためスコープを小さく絞る形が結果として手戻りのリスクを抑えることができる。
自分の仕事
最後のパートでは、自分の仕事での優先度付や境界線の設定などが書かれている。
ハイレベルでの優先度付け
「決断疲れ」という言葉を知りました。
決断疲れとは、明確な決断ができないときに不適切な選択をしてしまうことです。
日々の業務は決断の連続です。
明確ではないときに不適切な選択になるケースは大いにある。
ToDoリストから離れて、タスクの優先度を俯瞰することが大事だと感じた。
ときに休憩をしたり自分ひとりで考える時間を適切にあてることを意識していく。
境界線の設定
ちょっといいか？という形でMTG三昧になったり、ノーといえなくて抱え込むことでストレスが起きる。
仕事に対しての価値観はそれぞれ違うので、明確に自分の中で境界線をひくことも大切だと感じた。
まとめ
本書は、エンジニアやマネジャーじゃなくても、チームに対しての考えなどを学べる一冊だった。
手法についても一部書かれているが、基本は自分のチームを大切にして業務を円滑に進めるためのコミュニケーションの取り方をしっかりとしていきたい。
明日から仕えるテクニックよりも抽象的な形で、取り入れるところは仕事で活かしていきたいと思えた一冊だった。
この記事が気に入ったらサポートをしてみませんか？