あらすじ
【内容紹介】
エンジニアからエンジニアリングマネジャーになる――
エンジニアリングが好きでエンジニアになった私たちが、
「チームをサポートしたい」という一心で引き受けたその瞬間に
扱う対象が「コード」から「人」へと変わります。
それは突然、職種がまったく変わるようなもので、
その大きな違いにはじめは戸惑いを隠せないでしょう。
人的プロセスは構築された設計の通りにはいきません。
コミュニケーションは個人の価値観、動機、力関係、スキルと結びつき、
メンバーの関係性は不安定です。
日々の仕事によるさまざまな経験は、そこに感情の波で揺らぎを与えてきます。
正解がなく、答えを出してもそれが良かったのかもすぐにはわからない。
これまでの経験を活かしたくても活かせないもどかしさ。
そんな誰も教えてくれなかったマネジメントについて、
Googleのマネジャーが共感と内省によるエンジニアリングマネジメントの実践知を解説します。
しかしそれはそのまま実践してもらうためではありません。
エンジニアリングマネジャーに求められていることと
リーダーシップの発揮について自身で考えられるようにするためです。
「人と関係性」に焦点をあてた本書は、
エンジニアリングマネジャーが困惑しやすいトピックを解説し、
メンバーと協力して一緒に共通の目的に向かうために読むべき一冊となっています。
【目次】
Part 1 自分のチーム
Chapter1 自分のチームを大切にする
Chapter2 価値観の価値
Chapter3 信頼と弱さ
Chapter4 自分のチームは「彼ら」ではなく「私たち」
Chapter5 幸せとやる気の原動力
Chapter6 長期的な従業員のケア
Chapter7 キャリアラダー
Chapter8 重要な1on1
Part2 コラボレーション
Chapter9 マネジャーとしてのコミュニケーション
Chapter10 チェンジマネジメント
Chapter11 フィードバックの与え方
Chapter12 フィードバックを受け取る
Chapter13 良いミーティング
Chapter14 対立のマネジメント
Chapter15 クロスチームとオープンソースのコラボレーション
Part3 チームが最高の仕事をできるように支援する
Chapter16 チームの仕事の優先度付け
Chapter17 プルリクエストのスコープを絞る方法
Chapter18 実行の速度
Chapter19 プロダクトとエンジニアリングの時間配分
Part4 自分の仕事
Chapter20 ハイレベルでの優先度付け
Chapter21 日々の優先度付け
Chapter22 境界線を設定する
Chapter23 まず自分を大切にすること
Chapter24 自分を信じること
感情タグBEST3
Posted by ブクログ
エンジニア向けのマネジメント本。そうそう、と納得する部分がかなり多いし、参考にもなる。
橋を建てるのがとても上手になったら、、パン屋に昇進させられた
メンバーが活躍できるようにすることがマネージャーの仕事
個人の価値観をメンバーと共有、確認する
信頼は以下の基礎となる
お互いの傾聴
間違いの中の人間らしさを見つける
創造性
仕事をもっと楽しむ
毎週チームの時間をとる
チームメンバー間含め、それぞれの信頼関係が構築される
雑談を促す、くだらない冗談を言う
チームについて語る時、発言に自分自身を含める。が、チームが成功した時、自分自身を含めずメンバーを褒める。失敗した時、自分だけの責任としてメンバーは含めない
弱さを見せて手本を示す
リーダーが最初に行動する
チームの文化と士気を良い状態に保つ
価値観ワークショップをする
一緒に食事する
個人的な話をする
ロサダ係数
ポジティブな相互作用の量によるパフォーマンスへの影響
キャリアラダー
5年後どうなりたいか
自己レビュー
30.90日目標
繰り返しと振り返り
プロダクトとエンジニアリングの時間配分
Posted by ブクログ
読者の皆さんがこの価値観に同意するか、あるいは実際に取り入れるかどうかは、特に重要ではありません。重要なのは、チームとともに価値観を作り上げる機会を設けることです。そうすることで、チームで価値観を支持する方法や、問題があれば異議を唱える方法を見つけられるようになります(実際に問題に巻き込まれてからより、今議論しておいたほうがよいでしょう)。チームで価値観が遵守されていれば、特にキャリアラダーのようなことで慌てる必要はありません。また、私がここで推奨している支持的で協力的な資質は、私がプリンシパルエンジニアを評価する軸とも一致しています。
これらの価値観がしっくりこない人もいるでしょう。その人たちにとっては他のチームを見つけるほうが有意義かもしれません。でも、それでいいのです! 価値観の興味深い点は、必ずしも正解が存在しないことです。自分たちが作り上げたいチームに適した価値観と、そうでない価値観があるだけです。
私は、誰もが自分の価値観に反しないチームでの仕事を探すべきだと強く感じています。理想的には、自分にとって完全ではなくとも大体は価値観が合致していると感じる場所がいいでしょう。異なる視点を持つ同僚から学ぶのもまた、良いことだからです。一握りの主要な、基本的な価値観は合致しているべきでしょう。そうでなければ、目の前の仕事がさらに大変になりかねません。価値観が合っていないと、燃え尽きてしまうのは避けられません。
チームの価値観の大部分が自分の価値観と合致しているチームで働くのは良いものです。なぜなら、チームの文化の本質を深く掘り下げられるからです。こおで私たちが目指しているのは明確さです。明確さが鍵となるのです。
あなたと各メンバーの間だけでなく、チームメンバー同士の信頼をどうすれば築けるのでしょうか?
一つの方法は、すぐには明確にわからないかもしれませんが、チームメンバー同士が信頼構築をどのように避けているかに注目することです。 それを評価するために、信頼関係のあるチームの特徴を見ていきましょう。
・お互いに気兼ねなく、率直に問題提起できます。
・お互いに個人的なことを共有しています。調子が悪い日には、他のチームメンバーにそれを明かしています。他のチームメンバーにとってそれは、大きな負担ではありません。
・良い結果を出すためにお互いに議論できます。
・お互いのニーズに柔軟に対応できます。
信頼関係のあるチームの特徴がわかったところで、今度は信頼関係のないチームがどのように見えるか考えてみましょう。
・問題が起きたら、チームメンバーにではなく、あなたに個別に伝えにきます。
・閉鎖的であり、お互いのことをあまりよく知りません。大変な目にあっていても、気軽にそれを明かせません。だから、状況が悪化しても、誰もそれまでの経緯を把握していません。
・問題が提起されると、すぐに議論が打ち切られます。そのため、誰であっても最初に話した人が「勝つ」という状態になります。
・グループに確認することなく、主に自分のニーズについて考えています。
考えてみてください。同僚と直接顔を合わせるような職場で働いているとして、チームでランチに行くとしたら、会社の全員を連れて行くわけではありませんよね? チームだけで雑談をする時間と場所を持っているわけです。もし会社全体に自分たちが監視されていると感じていたら、心理的安全性の獲得は難しいでしょう。チームだけの時間と場所によって、心理的安全性が生まれます。この心理的安全性が信頼ある雰囲気を築くために重要です。
話し合うことで解決できるような大したことのない対立や問題が、 チーム内で持ち上がることがあります。もしチームメンバーがこういった対立や問題を公の場で話そうとすると、チームに大きな支障をきたしかねません。突然、無関係な他のグループの誰かや地位の高い誰かが、決断に影響を与えるために「介入」してくるかもしれません。
このような状況下では、グループ内で最も内気な人の意見を聞く機会を失ってしまうでしょう。私が今あなたに伝えられることは、内気な人というのは、見落としたくない鋭い観察力をしばしば持っているということです。しかもこの種のオープンな場での議論は、チームの包括感、 信頼感、そして自律性を阻害します。
もちろん、時と場所によっては、オープンな場で会話をすることもあります。私はオープンなコミュニケーションや書面での記録をすべてやめなさい、と言っているわけではありません。オープンな会話と、チームメンバーが少しリラックスできる場所とのバランスをとることが良い方法だと言いたいのです。個人的には、チームのためのプライベートチャットグループを作ることをお勧めします。すべての雑談やチャットをオープンにしたがる企業もたくさんありますが、私は多くのリモートチームをマネジメントしてきた経験から、チームが自分たちだけの場所を持つことが重要だと考えるようになりました。
チームチャットを始めたばかりの頃は、しばらくの間、話しているのは自分だけかもしれません。気まずい感じですね。しかし、すぐ終わります。約束します。前にも述べたように、あなたが先陣を切らなければなりません。私は、軽い感じで物ごとを始める傾向があります。たとえば、馬鹿らしいネットミームを使ったり、あちこちで「良い週末を! (Have a great weekend!)」と書き込んだり、チームの小さな勝利や個人の頑張りを称えたりします。しばらくすると、他のメンバーが追随し始めます。
皮肉なことに、このような外部からのイメージを保ち続けようとするほど、そのイメージは滑り落ちていくのです。なぜでしょうか? それは、マネジャーとして解決し続けている問題は、実のところ「あなた自身のもの」ではないからです。
あなたのチームは「私たち」です。組織内の序列でどれだけ地位が高かろうと、あなたはチームの原動力なのです。チームで何が起きようと、 それはあなたの責任です。チームについて語るときは、発言に自身を含めてください。
とはいえ、チームが何かで成功したときは、チームのメンバーを褒め、 あなた自身は除いてください。あなた自身を含めないことにより、チームがそれに値する評価を受けられます。自分を含めてしまうと、自尊心を高めるために話を誇張していると受け取られかねません(しかもそれにより、チームの働きへの評価が下がってしまうかもしれません)。
一例を示しましょう。
「彼らはスケジュールが非常にタイトだったにも関わらず、プロジェクトを成功に導いてくれました。プロジェクト全体を通して意欲的に取り組み、素晴らしい仕事ぶりでした」
しかしあなたには、プロジェクトの成功に向けて相応しいチームを組織する責任があります。だから、もしチームが何かで失敗したら、そのときの主語は「私」になります。
「私はこのスケジュールの厳しさを認識できておらず、チームの時間の優先付けを誤りました。みんなでもう一度集まって、計画を考え直す必要があります」
そこでは決して、「彼ら」と言ってはいけません。たとえば、次のようにです。
「彼らはタイトなスケジュールを守れませんでした。ただ期間内にプロジェクト完了できなかったのです」
最後の例で、責任をどのように人に押し付けているかわかったと思います。あまりにも頻繁に、窮地に立たされたマネジャーが責務から逃れるのを耳にしますが、本当はそういうときこそマネジャーは前に立ち、 自らの責任である問題に取り掛からなくてはいけません。
私が伝えたいことがわかってきたかと思います。リーダーシップチームについて話すときも、主語は「私たち」です。同僚や上司と会議で決定したことに対してあなた自身が賛成でない場合でも、「彼らが(自分は賛成ではない何かを) 決めたんです」とは言ってはいけません。あなたはそこにいたのですから、理想論的に言えばあなたもその決定に加わっていたはずです。だから、そのチームについて話すときに「私たち」と表現することは、自分がマネジメントしているチームの場合と同様に重要なのです。なぜでしょうか? なぜなら、マネジャーとしての私たちの仕事は、バランスと明確さをできる限り作り出すよう努めることだからです。
マネジャーが、リーダーシップチームに属していないかのように話したり、そこで起こったことに対して責任を取らないように話したりしたら、チームは混乱し方向性を見失うでしょう。あなたの直属の部下は、 リーダーシップのレベルで変化をもたらすことはできません。だから、 もしあなたがリーダーシップチームへの関与を放棄したら、自分のチームを落胆させ、会社全体への信頼を失わせかねません。他のチームやその取り組みを悪者扱いする風潮が生まれ、それは(すでに述べたとおり) 非常に不健全です。
「私たち」と言うことは、自分のチームに対して、自分が一端を担っているリーダーシップの説明責任を負うことであり、それがあるべき姿です。もしリーダーらが向かっている方向性に対して自分のチームメンバーらが懸念を持っているなら、橋渡し役として、コミュニケーションをとり次のステップへと主導することもあなたの責任です。
しかし、特定の状況では、リーダーシップチームの決定を守ることが適切ではないかもしれません。もしリーダーシップチームの決定が、あなたの核となる価値観に極めて反する場合、それは断固として戦うべきときです。このような状況は、理想としては稀であるべきです。頻繁にあるならば、残念ながら他の組織での職を探す必要があるかもしれません。
フロー状態のもう一つの素晴らしい利点は、不満への耐性が高まることです。このことは、情熱に関する議論でよく耳にする懸念に回帰します。つまり、困難な状況になったときに、どうやってそれを続けるか、 ということです。フロー状態に入ると、通常であれば不安や負担と知覚されるような障壁が別の形で認識され、その課題を乗り越えるための意志が強まります。
しかし、あなたはリーダーです。チームの文化の強さは、チーム内で許容される最悪の行動によってのみ決まります。声を上げるのはあなたの仕事なのです。
私が最初にしたことは、人が学びの最中に持つべき価値観について考えることでした。その結果、「好奇心」と「謙虚さ」にたどり着きました。この価値観を備えているように見える人に徐々に気づき始め、できるだけ彼らと知り合うようにしました。私たちは、未来について熱く語り合うようになりました。みんなで協力し始め、この価値観を表すプロジェクトを集めて推進し始めました。また、みんなで、なぜ進化が必要なのかを力説し始めました。
大きなスピーチや小さなチームミーティング、1on1の場でも行いました。TPM(テクニカルプロジェクトマネジメント)、PM(プロダクトマネジメント)、戦略的パートナーや顧客の中から仲間を見つけました。そして文書を作成して、フィードバックを得ました。
ここではまとめて書いていますが、これは難しく、何カ月にもわたる一貫した取り組みを要することを理解しておくことが重要です。自信が打ち砕かれたときもありました。諦めて、グループに現状をただ維持してもらえればいいと思ったこともあります。そんな時、チームの他のメンバーが仕事の目的を思い出させてくれたことには、とても感謝しています。
時間が経つにつれて、否定的な意見を持つ中核グループを抜きにして、 みんなが進化的なゴールを提示し始めました。それは小さく、ほとんど気づかれないようなものでした。しかし次第に、多くの人がこれらの概念を中心に将来のデザインを構成し始めました。最終的に私が組織の研究開発部門を提案したときには、みんなが賛同してくれました。これはトップダウンによる組織再編ではなく、私たちみんなが実行していた全体戦略にちょうど合致していたように思えました。
私たちは、プロダクト、OKR、さらには組織構造まで変更しました。 しかし、何よりも最初に起こったのは文化の変化だったのです。
また、チームが同じ目標に向かって一緒に働けるように、周りの人とフィードバックを受けたり与えたりする必要があります。誰も独立して働いているわけではありません。私たちはみんな、職場環境を、幸せで、 敬意がある、生産的な場所にするために、お互いのコミュニケーションスタイルに少しずつ合わせなければなりません。
フィードバックに関して言えば、自分自身のエゴの中に小さく自然な葛藤が存在します。私たちは学び、成長したいと考えていますが、一方で受け入れられたいとも思っているのです。より成長するために、 を絞り、自分自身に挑戦するためにはフィードバックが必要となります。 しかし、このフィードバックを本当に受け入れるためには、自分を守るように設計された体内のシステムを回避しなければなりません。これがやっかいです。
私の提案は、すべてのフィードバックのやりとりをできるだけパートナーシップのように扱うことです。完璧で誤りのない立場からアドバイスをするのではありません。むしろ、共通の目標に向かって一緒に働く二人が、パートナーシップを健全で生産的にするための一貫としてフィードバックを行うのです。「ねえ、歯に何か挟まっているよ」というような感じです。このような信頼できる注意喚起であり、相手が耳を傾ける必要があるかもしれないが、その人自身が気づけないことを伝えるのです。このプロセスでは、あなたが相手を判断しているわけではないことを伝えるようにしてください。
Posted by ブクログ
原題は『Engineering Management for the Rest of Us』である。
本書は専門領域としてのエンジニアリングに触れることはほとんどなく、一般的なマネジメントについて記述している。邦題に含まれている「エンジニアリングが好きな私たちのための」という表現は対象を狭めているようにも捉えられるが、逆説的にむしろそのような人に手に取ってもらいたいという気持ちの表れなのではないかという気がする。
平易な文章で書かれていて、読みやすい。
全体的に同意できないような内容の記述はない。啓蒙的な内容も多く網羅的ではないが、著者がマネジメントにおいて大切だと思う要点はよくまとまっている。
評価や採用など本書ではカバーされない領域があり、それらの話題については他の情報源に頼る必要がある。本書は、例外的でない日常のマネジメントのサポートとなるような助言を提供する書籍と言える。
本書は大きく4つのパート、自分のチーム/コラボレーション/チームが最高の仕事をできるように支援する/自分の仕事、に分かれている。
Part1「自分のチーム」では、チームを作るためのツールが紹介される。
> リーダーとしてあなたが最初に行動しないといけません。あなたは自ら信頼に値することを示すと同時に、他人を信頼することも必要です。これは、チーム内では弱みを見せても大丈夫なことを意味します。（chapter3 信頼と弱さ 弱みのモデリング）
> 企業は複数のグループから構成されますが、それらのグループは共に働いてこそ成功できるのであり、いかなる犠牲を払っても自分たちのグループだけ守ればいいという訳ではありません。...組織の健全性は、互いに協力して働けることにかかっています。（chapter4 自分のチームは「彼ら」ではなく「私たち」 より広範囲の組織）
Part2「コラボレーション」では、マネージャーとメンバーのコミュニケーションの仕方や効果について書かれる。
> あなたは、ただ現状を維持するためにこの役割にいるのではありません。組織（文化、プロセス、システム、プロダクト）を改善するためにそこにいるのです。...「物ごとをより良くすること。それが仕事なのです」（chapter10 チェンジマネジメント）
> フィードバックは、二人の顔の重要な議論や、ドキュメントへのコメント、また情報を伝えるときに人の顔に現れるほとんど気づかないような感情として現れます。（chapter11 フィードバックの与え方）
> ミーティングの目的の一部は、議論そのものなのです。（chapter13 良いミーティング）
> 「自分の好みをよく理解しておかなければなりません。なぜなら、何をしようとも、あなたは間違っていると誰かに言われるからです」（chapter14 対立のマネジメント）
Part3, Part4 では、チームや自分の仕事に対する優先度付けやエンジニアリングに近しい領域の話題について触れられている。
