「世界一流エンジニアの思考法」に学び、自社の良いチーム文化を再確認した
株式会社immedioのimmedioチームでエンジニアをしています。入社してそろそろ6ヶ月に入ります。
📘 最近読んだ本が自分が所属しているチームにも通じる部分があったのでここにまとめます。
📖 背景
「世界一流エンジニアの思考法」を読みました。
今回触れるのは以下二つの章です。
- 第4章 コミュニケーションの極意―伝え方・聞き方・ディスカッション
- 第5章 生産性を高めるチームビルディング―「サーバントリーダーシップ」「自己組織型チーム」へ
いずれも、自分が所属しているチームにも通じる部分がありました。
🗣️ 「第4章 コミュニケーションの極意―伝え方・聞き方・ディスカッション」
特に印象的だったのは、次の3つです。
- 迷ったらすぐ話す「クイックコール」の文化
- 気軽に質問や相談ができる空気づくり
- 意見が対立したときに否定ではなく“理解”から入る姿勢
📞 迷ったらすぐ話す「クイックコール」の文化
クイックコールとは予定されていないビデオ通話のことです。
書籍では、予定を組むのではなく「今ちょっといい?」というチャットから自然に通話が始まり、画面共有しながら課題を一緒に解決していく「クイックコール」の文化が紹介されていました。
弊社ではslackのハドルやgatherで「ちょっと今いいですか?」とすぐ相談できる環境があります。
💬 気軽に質問や相談ができる空気づくり
総じてイケてる技術者ほど、知らないことは知らないと素直に明かして気軽に質問する。
この言葉が印象的でした。
気軽に聞ける空気を作るには、日頃からの関係構築が欠かせないと思います。
弊社では、月に数回のシャッフルランチや全社定例など、リモート中心でも対面で交流する機会が設けられており、自然と関係性が築きやすくなっています。
また、チーム内でも「トーク会」や「immedio Shares」といった雑談・知見共有の場があることで、日常的に「話しやすさ」が保たれていると感じます。
🧠 意見が対立したときに否定ではなく“理解”から入る姿勢
「相手を否定しない」「相手のアイデアを否定しない」、そして「自分の考えとして意見を言う」と言う鉄則
Githubのコメントでよく見るIMO(In My Opinion)も「自分意見では」と言う柔らかい枕詞です。
こちらの記事で様々な表現を紹介されていました!
弊社の会議では意見の対立はウェルカムで、建設的な話し合いができています。
先日あった会議でも起票した案が通りそうでしたが反対寄りの意見が出ました。
その際にも「意見が出ることは良いこと」と言う声がありました。
🤝 第5章 生産性を高めるチームビルディング―「サーバントリーダーシップ」「自己組織型チーム」へ
特に印象的だったのは、次の2つです。
- 「サーバントリーダーシップ」とは何か
- 納期がなく、マネージャも急かさない
🧭 「サーバントリーダーシップ」とは何か
サーバントリーダーシップとはマネジメントのタイプです。
リーダーは<ビジョンとKPI> は示すが、実際にどのように動くかは、チームが主体的に考えて意思決定していく
サーバントリーダーシップについてこちらの記事でも紹介されていました。表を引用します。
弊社のチームメンバーは上の「サーバントリーダーに従うメンバー行動」のような行動ができる環境があります。
- 機能改善のフィードバックを起票
- 技術負債の解消タスクを起票
- AI活用の知見を共有
- パブリックチャンネルで考えを発信
- 入社してすぐ会社のテックブログに投稿できる
- タスクを受け持つと仕様の調整から実装まで一人で進める
- 1on1や定期的に上司に自分がやりたいことについて話すことができる
- 社内で新しい1on1を組んで定期的に新しい知見を得る
その他、自分次第で挑戦できることは何でもあるなと働いていて感じています。
アジャイル開発宣言の原則について社内で勉強したことがあり、「よいモノはよいチームから」という原則を思い出しました。
この原則もサーバントリーダーシップと重なると思います。
自律型のチームでは、メンバー一人ひとりが常に改善の意識を持ち、お互
いの能力を高めながら共通の目的や目標に対しての取り組みが継続されます。
そこには相乗効果が生まれ、チームとしてメンバー個々の能力以上の成果を発
揮することが可能になります。その結果、自律型のチームから、ベストな成果が生
み出されることになるのです
また、私が転職活動中にサンプルワークでお世話になったHQさんの記事で紹介されていた以下の表現がとても印象に残っています。
一人ひとりが自分の仕事により夢中になれる環境を作っていく
この言葉はまさに、現在の弊社チームにもそのまま当てはまると思いました。
サーバントリーダーシップの対比がコマンドコントロールというか、マイクロマネジメントです。
実は私も過去の職場でマイクロマネジメントを受けたことがあります。
共感することが多かったです。
本書でも紹介されていた、コマンドコントロールについて触れている本の紹介記事がありますのでこちらにリンクを共有します。
⏳ 納期がなく、マネージャも急かさない
本書では以下の言葉が印象的でした。
急いでいい加減なものをリリースするより、自分が自信を持てるものをリリースしよう
マネージャは一度仕事をプログラマに割り振ったら、あとはもう信頼するしかない
弊社でも基本的には納期がないです。
確かに急かされていることはないので集中して実装できるので結果的に実装が早くなった気がします(前職でマイクロマネジメントを受けていた時と比べてみてより感じます!)
📝 最後に
-
「サーバントリーダーシップ」とは何か
の章でも触れましたが、自分は環境には恵まれていると再認識しました、引き続き主体的に動いていきます -
世界一流エンジニアの思考法
で紹介されていたその他内容もしっかり消化して業務に生かします - 本を読みながら自分や自分の環境はどうなのかと考えたりするのは大事だなと思いました
弊社EMの方が書かれている以下の記事も読むと弊社の解像度が上がるのでぜひご覧ください!
🔗 参考
- https://books.bunshun.jp/ud/book/num/9784163917689
- https://zenn.dev/hacobell_dev/articles/code-review-comment-prefix
- https://www.servantleader.jp/about
- https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itssplus/ps6vr70000001i7c-att/000065601.pdf
- https://kawaguti.hateblo.jp/entry/20150211/1423638892
- https://dev.hq-hq.co.jp/articles/how-continuous-kpt-fuels-developer-passion
Discussion