「エレガントパズル」を読了した
「人は会社を去るのではなくマネージャーのもとを去る」
先週は、「エレガントパズル」を読了した。
この言葉の出典元ってどこなんだろうと調べてみた。
調べるとこのあたりがヒットしたからリンクを貼っておく。
この言葉自体は、2013年のギャラップ社の調査から出てきた言葉らしい。
最初、この本のAmazonのプレビューで見たときに知り、買いだなと感じたので出版日当日に本屋で買ってきた。
最近はエンジニアリングのマネジメント・組織や文化などの分野に非常に興味があって、楽しみしてた本。
読んだ率直な感想として、参考文献めちゃくちゃ多い！自分は本ばかりだけど論文もしっかり読んでて自分も論文ちゃんと読まないいけないなって思えた。
実践的且つ経験則から成り立つ書籍だった。
著者のウィル・ラーソン（Will Larson） 氏は、去年翻訳本としてできてたスタッフエンジニアの著者です。
この本も去年読了したこともあって、今年も読むことにした。
去年読んだときよりもマネジメントやリーダーシップに対しての考え方が深くなったこともあって、本書の気づきがたくさんあった。（答え合わせみたいな感じがする）
翻訳を担当された 岩瀬さんが出版後に登壇されていた内容のスライドが上がっていた。
こちらも合わせて読むと良いと思う。
この本は、以下の構成になっている。
導入
組織
ツール
アプローチ
文化
キャリア
さらに先へ
自分がとくに気になったところをまとめておく。経験からなる部分は参考になった。
この本は、システム思考で有名な 「世界はシステムで動く」がベースになってる。
この本はまだ、積読になってるからきちんと読む必要がある。
システム思考を理解していく必要がありそう。
著者の出身がフロントエンドエンジニアという立場ということで、親近感と自分もその領域になれるように精進したい。
文中にアイザック・アシモフがでてきたのも嬉しかった。まだ銀河帝国の興亡は読めてないけど。鋼鉄都市は面白かった。
組織：機能する組織を作り、維持をする
チームのサイズを決める。
組織デザインに対して、基礎的な部分はチームのサイズを決めること。
よくあるピザ2枚ルールの部分が役に立つのかなと思っている。
大きすぎ小さすぎず、小さいメリットは管理面で目が届きやすくなる点だと思っている。また、無駄な会議をなくせる。生産性をもっともあげることができる。
指示系統が大きいと役所みたいなことに成りかねない。
組織は伝言ゲームだと思う。指示が大きいと最終的に求めてるものと違うものがかえって来る可能性があるが小さいとそのリスクは低くなる。
今すぐにやってほしいことも小さければ小回りが効く点においてもメリットが高いのだろうと思う。
メリットばかりではなくデメリットも確かにある。
大人数ではアイディア・技術スキルといった部分で、対応できる人が増えるため結果としてはその人がいなくても機能できる点だと思う。
少人数ではオンコールに呼び出せれるケースは多くなることはある。しかし、オンコールを極力少なくできるのは少人数ならではかなと思う。
マネージャーは6人〜8人のエンジニアを支援
チームが大きくなると、マネージャーが管理するエンジニアは増えていく。
自分が思うに6人〜8人が人間が目が届く限界なんだろうと感じている。
チームごとにまとめるサイズ感の話ではあるけども、1チームに多数のエンジニアを抱えるとマネージャーが破綻してしまう。
このケースは自分も見たことがある。エンジニアの数というよりかは案件の持ちすぎや抱えているチームの数も同様なんだろうなと思う。
マネージャーにもエンジニアと同様の時間軸で動いてる。
管理できる数は制限をかけて、少数をうまく使えるようにならないといけないと感じた。
オンコールのローテーションはエンジニア8人が必要
オンコールと呼ばれると病院みたいだなと思うけど、病院もチームだ。
24時間対応しなければならない現場でいえばITでも同じことが言えるだろう。
4人未満はチームではないとあるように、ローテーションするためにも8人が必要になってくる。
少なすぎると、その人に負荷が大きくなっていき、最終的に病院へいくかそのまま退職しちゃうだろうと思う。
3人でもチームだと思ってたけど、これを読んで4人はチームではないなと思った。4人未満だとチームとしての抽象化に漏れが多くて、チーム単位よりも個人で動く見分けができない。
安定した状態のチームを作るには6〜8人。
チームが成長してきたら、分割する。空っぽなチームを作らない。
9人以上をサポートするマネージャーを作らない。
この原則は頭に入れておきたいと思った。
ツール：変化をマネジメントする手法
システム思考入門の章。優れたリーダーの多くはてこの原理のように小さい労力で大きな成果を得ることの才能が長けてる。
ハサミの使い方みたいなところがある。
プログラムでも少ないコードで大きな成果を得るみたいな部分がある。
上から押しつぶすのではなく、視点を変えたら少ない力で多くのことができると自分もおもう。
物の見方が多方面でできる人になっていきたいものだ。
戦略とビジョンを文書化
戦略は課題に対して解決するための行動を記したドキュメントが重要。
理想を目指すためにドキュメントは必要。
ここでは戦略の書き方とビジョンの書き方を説明してた。
良い戦略、悪い戦略という本があるのは知らなかった。この本も読んでみたいと思った。
なにも考えないで進めてるところがあるから、ちゃんと戦略を練るところからなんだけど、悪い戦略は要領が悪い自分には耳が痛いかもしれない。
ビジョンの文書化
ビジョンステートメント：目指す姿
バリュープロポジション：ユーザへの提供価値
ケイパビリティ：異なるニーズを持つ顧客に届けるべきか
将来はなくなる制約：将来のコスト
将来の制約：資金調達・採用
参考資料：参考文献など
ナラティブ：フォーマット
ドキュメントを検証しよう
定期的に更新しよう
現在形を使おう
シンプルに書こう
ケイパビリティという言葉を初めて知った。
企業成長の原動力となる組織的能力や強みのことをさす
ナラティブという言葉も初めて知ったのだけど、検証・更新はドキュメントに対していつも課題のような気がする。
言葉の書き方にも注意が必要で、古臭くなるのは現在形を使わない文書がとくにそうなる。作って終わりではなく定期的にみなすのはどの仕事でも大切なことだと感じた。
最後にシンプルはとくに文書を書く上で、もっとも重要視したいと思ってる。
分かりづらい言葉じりでは、伝えたい部分がスルーされてしまうから。
とくにビジョンは流行語でできるものではないだろうと思った。
タイムマネジメント
タイムマネジメントはマネージャーではなくでも、課題だと思う。
組織的な振り返り、短期的な品質よりも長期的にみての振り返りは大切。
小さいことを終わらせる。これはエンジニアとしてもタスクは小さくして終わらせることで短く早く終わらせることが大切。小さいことを一歩ずつすすめていくことを常に意識したい。いずれ大きなものになると信じたい。
なにかをやめる。これは管理職にも伝えたことがある。
なにをやるために何かを諦めなければならない。時間は有限であり組織においても時間は無限にあるわけではない。
すべてをやめずにできるのは時間軸が違うか。中途半端なものになってるかだけなような気がする。
なにかしたければ何かを辞める。を意識して動きたい。
1on1は積み上げではなく逆算で考える。
逆算で考えることで、1on1を使う時間配分をコントロールしやすくなる。
プロセスよりも人が大事
やり方は、修正できるが人は修正できない。
正しい人材がいれば、どんなプロセスでも機能する。間違った人材がいるなら、どんなプロセスも機能しない
この言葉すごく響いた感じ。
正しい人材がいれば協力しあえる。
色々な職場を経験したけども、プロセスが機能しないのはやはり人なんだと改めて思った。
正しい人を見分ける力は難しいけども、ビジョンの明確化が組織において絶対的に必要なんだと思う。
会社のために正しいこと
チームのために正しいこと
自分のために正しいこと
この3つの思考いいなと思う。この順序を意識する必要。頭でわかっていても身体がこれにしていくのは難しい。
1は社畜感が出るなと思うけど、正しいことという点において社畜ではなく機能するように動くために必要なことだと感じた。
エンジニアリングマネジャーが行き詰まる方法
この記事をマネジャー追求版として紹介してる
エンジニアマネージャーがいくつかの類似点をまとめてる。
部下だけをマネジメントする
上司だけをマネジメントする
上司を一切マネジメントしない
局所最適化する
採用ではどんな問題も解決しないと思い込む
関係構築に時間を費やさない
役割を狭く定義する
上司が人間であることを忘れる
ここに書いてる上司が人間であることをわすれるのは面白い思った。たしかに人間であることを忘れることたまにあるかも。
関係構築はしっかり時間をかけることは大事だと思える。
社内の協力なくしては、市場を良くする前に破綻するよね。
より経験豊富なマネージャーの行き詰まる方法も書いていて学びがあった。
文化：継続的に取り組んで育成する
企業文化みたいなところだけども、文化を育成していく。
会社のあり方みたいなものは常に変化はするし、気になったところがある。
予算を明示する
当事者がまるで自分のお金であるかのように使う会社は多いという点は納得した。ただ漠然と費用を負担するのではなく具体的な予算を明確にすることが大切。中身が重要という点だった。
教育プログラムを作る
マネージャーが受講可能な継続的な研修や学習プログラムを作ること。
マネージャーという職種は、どうするべきかは誰からも教わらずナレッジだけで作り上げられてるケースが多い気がする。
それをきちんとした受講できる研修やプログラムにすることは大切だと感じた。
エンジニアにも学習プログラムはたくさんある。
マネージャー向けの学習プログラムは社内にあってもよいと思った。
まとめ
採用関連にも学びは多かったけど、もう少し整理してnoteにまとめたいと思った。
参考文献がずらっと並んでて、読み応え（参考文献読みできる）ところが個人的によかった。
実践形式や経験則できてる内容のため、自分が経験するときに考えの引き出しとして残せる良い書籍だった。
チーム・組織・採用といったマネージャーが体験するであろう部分を経験則からまとめられている良書でした。
この記事が気に入ったらサポートをしてみませんか？