今回はリーダー・マネージャーの皆さん向けにエンジニアの生態を理解しようというテーマで記事を書いていきます。
開発においてエンジニアの立場や考え方ひいてはその'生態'を知ることはとても重要です。
この記事が非エンジニア出身のリーダー・マネージャーにとって有益な情報になれば幸いです。
エンジニア出身の方であれば「わかる！」と思っていただけるかもしれません。
エンジニアのプライドを傷つけてはいけない
よくエンジニアは職人気質であると言われます。
多くのことを常日頃から学び続け、コードや画面という作品を作り上げていく。
たしかに物を作る職人と似ているかもしれません。
成果物に対するフィードバックは慎重に
人が専門知識と技術を用いて作った成果物というのは、周りが思っているよりもずっと強い思い入れ、そこに至るまでの労力、長い勉強期間が込められているものです。
苦労をかけた分、否定された時の反動は大きくなりますので巧拙にかかわらずそのフィードバックには慎重さとリスペクトを必要とします。
まずは良いところや及第点の箇所を認め、その上で改善点を「ダメ出し」ではなく「要望」として伝えるようにすると拒絶されづらくなります。
（例）「全体的なデザインは意図通りできていてとても助かるよ。一つお願いがあってここを仕様書の5ページ通りに変えてもらっていい？」など
進捗どう？は逆効果
システム開発は期限がある以上、管理者としては進捗が一番といっても良いほど気になりますね。
ただし、進捗を細かく聞くことはエンジニアにとって多くの場合逆効果となります。
単純な事務作業であれば発破をかけることである程度スピードアップが望めるかもしれませんが、ロジックやデザインのひらめきというのは気持ちに焦りがあるとかえって出てこなくなります。
実際過去に私が参画した開発現場で、PMが数時間おきにエンジニアに進捗を聞きまくるということがあり精神的に追い込まれたエンジニアが辞めてしまったことがあります。
とはいえ管理者が進捗確認しないわけにはいきませんので、進捗報告は1日1回の自発的な報告までに留めることをおすすめしたいです。
エンジニアはドキュメントを書きたがらない
例えばプログラマーならロジックを考え、組み立てていくことが楽しいでしょう。
個人的な感覚でいくと小さい頃に砂場でお城を作ったりプラモデルを組み立てたりすることに近いです。
そこへきて資料作成という平坦な作業というのは基本的にロジック（深さ）を考えることがないため退屈と思われがちです。
しかも「開発時間内に書いておいて」と言われるとモチベーション低下を招きかねません。
ドキュメント作成も仕事の一つであることをきちんと説明した上で、そのための時間を確保しアサインすることをおすすめしたいです。
技術力0は舐められる
非エンジニア畑出身のリーダー・マネージャーには耳が痛い話かもしれません。
著者が見てきた「うまく回っている開発チーム」の多くはリーダーがエンジニア出身でした。
現場のことや技術のことがわかっているリーダー・マネージャーのほうが円滑にプロジェクトを進められそうなのは想像がつきますが、具体的には何がそこまで有利になるのでしょうか？
工数見積もりに強い
これは大きい要因の一つです。
「その機能にどれくらいの工数がかかるのか？」算出手法に頼るだけではやはり外してしまうことは多いです。
過去の似たような開発経験を多く持っている人ほど、ものさしがたくさんありますので必然的に見積精度が高くなります。
技術選定に強い
どんな言語、フレームワーク、DB、インフラ、ツール類を使うか。実際に使った経験があると「あれは使いづらい」「脆弱性を突かれやすい」「逆にあれば使いやすい」など取捨選択するための材料をある程度持っていることになります。
ネットやAIで調べた結果と違い、やはり実際の経験値は大きいと感じます。
部下やメンバーがついてくる
誤解を恐れずに言ってしまえば、やはり技術力の高いリーダーや経歴がピカイチのマネージャーというのは部下やプロジェクトメンバーから尊敬されます。
「この人すごいな・・」という思いがその人についていこうという行動に繋がるのは間違いないです。
私が見た現場でも開発経験なしのPMはもちろんいましたが、エンジニアから曖昧な設計をつつかれる、見積工数がわからないため無茶なアサインをするということが常態化していました。
それが続くと部下や開発メンバーから信頼を失い尊重もなく、とても良い雰囲気とは思えないプロジェクトだったのを思い出します。
こんなリーダーがエンジニアに好かれる
ではどんなリーダー・マネージャーがエンジニアに好かれるのでしょう。
現場のキツさを知っている
「同じ釜の飯を食う」という言葉がありますが、やはり現場のキツさを知っているというのはエンジニアからすると安心感があります。
自分がバグを出してしまったときの焦り、期限に追われる憂鬱感、ハマったときのイライラ、無茶振りされた時の怒りなど。
全ての人とは言いませんがエンジニアはどこかに「開発したことがない奴に偉そうに指示されたくない」という気持ちがありますのでそう言った意味でもプラスに働きます。
エンジニアへの共感力が高い
開発の良いところ・悪いところを知っている百戦錬磨のリーダーほどエンジニアへの共感力は高まっていきます。
それは同じ立場・同じ仕事を経験しないと得られる物ではないと思います。
「この作業は調査に時間がかかるから調査チケットは別で切ろう」
「この大きさの開発だと大きすぎるから分割して2名アサインにしよう」
「もしかしたら外部連携で大きくハマるかもしれないから多めに工数バッファを取っておこう」
共感力がこういった具体的な対策を立てられるのだと思います。
ミスを責めない
ミスを責めないというと誤解を招きそうですが、これは決して「甘やかして野放しにする」という意味ではありません。
今まで出会った優秀なリーダーはエンジニアのミスを単純に責める人はいませんでした。
つまり「原因追求はするが個人の責任追求はしない」という意味です。
何か問題起きた際は、感情ではなく理論で対応する。
淡々と「原因をつきとめ今後の対策をする」ということが大事だと強く感じます。
逆にエンジニアを感情で責めることを続けたら早晩立ち去ってしまうでしょう。
開発の成否はエンジニアを握れるかどうか
例えばリーダーの一つプロジェクトマネージャーが過酷とされる理由は様々ありますが、やはりその中でも大きいのは間違いなく人間関係です。
上司、クライアント、開発チーム、営業チームなど関わるステークホルダーを「うまく握って」調整するハブ役には当然負荷がかかります。
そしてまたクライアントの握り方と開発チームの握り方は当然違うためうまく回るには難易度が高くなります。
開発チームをうまく握って円滑にプロジェクトを進めることを起点にできれば、それをもとにクライアントの信頼を勝ち取っていくことができます。
参考までに実際に私が見た現場の一つですが、最初はPMがクライアントと良い関係で要件定義を進めていましたが、開発チームをうまく握ることができず、納期遅れとバグが重なったことで徐々にクライアントが怒り始め、関係が悪化。まさに大炎上というケースがありました。
くどくなりますがやはり成果物が信頼の起点となる以上、付け焼き刃でクライアントとの関係を構築しようにも限界がありますので開発の成否はエンジニアを握れるかどうか、にかかっていると言っても過言ではないでしょう。
まとめ
今回はエンジニアの生態を理解しようというテーマで記事を執筆しました。
この記事の意図は非エンジニア出身ではリーダーになれないということではありません。
非エンジニア出身でもその後自ら勉強を重ねて現場をうまく回しているPMもいました。
大切なのはいかにエンジニアたちのことを理解し寄り添えるか？がチームワーク向上ひいては開発成否に大きく関わるかということです。
今回の記事がリーダー・マネージャーの皆さんの一助になれば幸いです。
