この度「エンジニアがビジネスリーダーをめざすための10の法則」という本を読みました。
要約すると、この本は「エンジニアが目線を上げて、マネジメント層と生産性の高い会話をするためには？」という観点で、マインドの変え方やノウハウがまとまっている本です。
本記事では、この本を読んで得られた感想、気づきをまとめてみます。
この記事はこんな人向け
- エンジニアとして働いているけど、マネジメント層との会話に自信がない
- より上流で仕事をするためにコミュニケーション力を磨くための土台を作りたい
内容の要約
詳細には書きませんが、以下にこの本で伝えられている「エンジニアがビジネスリーダーを目指すための10の法則」を載せておきます。
- Googleに答えを求めるな
- 右脳を叩き起こせ
- 仮説で語りきれ。非難を恐れるな
- プロセス志向から抜け出せ
- 不正確への恐怖に打ち克て
- 変更アレルギーを治療せよ
- クライアントに会いに行け
- 自分のことを話すな
- 守りから攻めへ転じよ
- 自分の母親にもわかる言葉で話せ
以下、山根が読んで持ち帰った感想・気づきを書いていきます。
エンジニアは「技術屋」ではなく、技術に精通した「課題解決屋」
この本に書いてある細かいノウハウを吸収する前に、そもそも持っておかないといけないマインドとして大事だと思ったため、最初の気づきとして持ってきました。
「新しい技術に触るのが楽しい」とか「バグが直ってシステムが動いたのが気持ちいい」等のモチベーションで動くエンジニアは一定数いると思いますが（自分も当てはまります）、本来仕事として求められているのはそういった技術的な成功体験ではないことに改めて気づきました。
- 応援したい（応援すべき）ビジネス領域がある
- そこには技術を使って解決できそうなペインがある
- だから技術に詳しくなって、課題解決できるようになる
といった順番で、課題解決できた時にこそ気持ちよくなるべきなんですよね。
すぐにでも取り入れられそうなこと5選
1エンジニアが、この本に書いてあること全てを実践するのは難しい気がしています。
エンジニアとしての業種/職種/階級などによっては手を出せること/出せないことが決まってきそうな気がしているからです。
ただ、以下の5つについては業種/職種/階級関係なく仕事に取り入れられると思いました。
課題設定が第一
これは過去に何度かやらかしている自覚があるので、過去にやった「課題設定第一ではない提案」と、どうすればよかったのかの例を以下に示します。
過去の悪い例
山根は過去に
「他社の〇〇でもやってるから、このADR（Architect Dicision Records）っていうフレームワーク使ってみたい！」
とか
「このモジュールに単体テストが足りない気がするから、増やしたい！」
という提案をしたことがあります。
結果的にはどちらの提案も受け入れられたのですが、提案としては課題ファーストで始まっていない、下の下のやり方だったな...と思ってます。（反省）
良い例
より良い提案にするためには、
- コードにどう変更を入れていいか悩むメンバーが何人かいるらしい
- ヒアリングしたところ、「現在の設計を崩すような変更を入れたいが、現在の設計になった背景や理由がわからないため、崩した時のデメリットがどれくらいあるかで悩んでしまう」とのこと
- 設計の理由/背景が議事として残っていないのが課題だ！
- 今後は設計理由をこのADR（Architect Dicision Records）っていうフレームワーク使って記録していこう！」
とか
- デプロイ後に出てくるバグが多い...
- 品質分析したら、単体テストで検知できるものばかりだ！
- 単体テストを増やして、デグレ対策をしよう！
の方が、よりロジカルで、より良い未来が待っていそうな気がしますよね。
報告の過度な詳細化をやめる
エンジニアからマネジメント層への報告は可能な限り簡潔に、必要最低限に抑えるべきだ、という話です。
本の内容でより興味深かったのは、以下の部分でした。
実施したプロセスと結果を詳しく伝えていたのでは、（中略）些細な詳細についてまでマネジメントの手を煩わせることになり、不信感も増幅していきます。（中略）消極的な印象を持たれてしまった上で、詳細な報告を行うと、報告内容そのものに対する不安が大きくなり、マネジメントには「すべての内容を把握しなければ」という心理が働きます。すると、詳細な報告内容がより詳細化を求められ、マネジメントレベルで把握しなくても良い内容まで提示することになり...
引用元:「エンジニアがビジネスリーダーを目指すための10の法則」第5章
「詳細化が詳細化を呼び、マネジメントもエンジニアも本来やるべき仕事を見失っちゃうかもしれないよ」、という内容です。
今までよりも一層、マネージャーへの報告には内容の精査が必要だなと気付かされました。
攻めの姿勢で語る「できます。ただし...」
これは正直「言い方」とか「言葉選び」の問題です。
「技術的には可能です（=無限にお金と時間があればできます）」という言葉が代表するように、エンジニアは「できます」と言い切るのを嫌う傾向にある、と本では書かれています。
そのような話し方ではなく、前向きに「できます！」と言い切って、続けてリスクや検証観点を話す方がマネジメントや顧客からの印象は良いよ、という内容です。
ただこれ、「できます！」といった後にちゃんと期待値調整をしておかないと、面倒な「あの時できるっていったじゃん」問題を引き起こしそうな気がするので、高度なテクニックのような気がしますね...
依頼に対して「わかりました」という返事と共に質問してみる
マネジメントに「〇〇して欲しいんだけど、できる？」と依頼された時、本当にその解決策で良いのかどうか聞き返してみて、課題は何なのかを確認しよう、という話です。表面的な捉え方だけで手をつけ始めるとあんまりよい提案ができない、とのことです。
本の中では、具体例として「外国人に日本の観光地を聞かれた時、自分の知識や経験だけで"六本木がいいよ"とか"浅草に行こう"とか言っても良い提案にならない。 "日本でどんな体験がしたいの?"等、要望を深掘りした上で提案しないといけない」例が書かれています。わかりやすい例だと思いました。
誰にでも理解できる言葉を使う
本の中では「マネジメントとの会話で横文字を使いすぎるエンジニア」というやや極端な例が挙げられていましたが、「自分の中にしかない前提知識を共有せずに説明していたら、なんか全然相手に伝わってなかった🥺🥺🥺」 ぐらいであれば日々頻発する事案かなと思いました。
相手の理解度を確かめつつ話すのも大事
これは山根の持論ですが、「誰にでも理解できる言葉を使う」のも大事な一方で、「会話の中で相手の理解度を確かめつつ話す」も同じぐらい重要なことです。「理解できる」かどうかの判断は相手にやってもらうしかないですからね。
山根がマネジメントと話す際は、適度に話を区切って「ここまで大丈夫ですか？」と聞きながら話を進めることが多いのですが、これは個人的にお勧めできるアクションかなと思っています。
参考:今の山根のレベル感
この本は、読者の勤務する立場や階層によって、読んだ時の気づきが違うだろうなという印象を受けました。
なので、参考までに山根のエンジニアとしての勤務情報を載せておきます。
「こんなレベル感のやつが読むとこういう感想になるんだな〜」とご理解ください！
- 2023年で満29歳
- バックエンドエンジニアとして経験5年目
- 年収560万円
- 若手チーム内では年次高めの方ではあるものの、リーダーとかマネジメントは未経験
↓以下プロフィールです
まとめ
この本を読んで持ち帰れたもの
- 【大事なマインド】
- エンジニアは「技術屋」ではなく、技術に精通した「課題解決屋」である
- 【ノウハウ】
- 「課題が何か？」を第一に考えよう
- マネジメントへの報告は簡潔に
- 「できる」と言い切ってみよう
- 人の悩みを聞こう
- 人にわかる言葉遣いをしよう（理解度を都度確認しながら）
もし皆さんも興味があったら、手に取って読んでみてください！