(部下目線) 理想のエンジニア上司ってどんな人?【人柄、仕事ぶりなど】

(部下目線) 理想のエンジニア上司ってどんな人?【人柄、仕事ぶりなど】

 

 

本記事では、SEとして3年半ほど勤務した筆者が、部下目線ではあるが、
「理想のエンジニア上司ってどんな人?」と言うタイトルで、自論を語っていこうと思う。

特にスポットライトを当てて書こうと思っている上司の役職・立場は以下のような方たちだ。

  1. プロジェクトマネージャーの方
  2. ある程度の規模の開発チームリーダークラスの方

 

もちろん、筆者のえこひいきや偏見が意見の中心にならないように記事を執筆する。

あくまで実体験を元に、客観的な視点で、
「この人(上司)はこう言う理由で評価されていているんだな」と言う理由や根拠をピックアップしていく。

また反対に、部下目線で、
「こんなところは上司として望ましくない、できれば改善して欲しい」と言う点もぶっちゃけていこうと思う。

では早速紹介していく。

 

理想のエンジニアの上司像

先に結論をまとめると、以下のような人が理想のエンジニアの上司像だと筆者は考えている。

 

①全体を広く見ることができ、かつ判断・指示の提示ができる

一番ありきたりな理由だがやはり、
「全体を広く見ることができ、かつ判断・指示ができる」と言う能力があることは、理想のエンジニア上司として最も重要な要素だと筆者は考える。

と言っても抽象的で具体性がないので、以下に「全体を広く見ることができ、かつ判断・指示ができる」ことの例を紹介する。

全体を広く見れて判断・指示を出せるエンジニアの例
  • 決められたゴールに対し、チーム全体で何を、いつまでに成し遂げなければいけないか判断することができる。
  • かつそれらのタスクを適切にチームメンバーに配分することができる。
  • 振ったタスクに対して、チームメンバー毎の稼働率、それに対する進捗を把握できる。
  • 把握するだけでなく、進捗に遅れが出ている場合などは、リスケの検討や改善点などを提示するなどの適切なフォローができる。
  • お客さん(クライアント)とのやりとりがある場合、お客さん側の都合や希望に対しての対応も気を配れる。
  • etc

 

などなど、これができたらOK!なことを上げ始めたらキリがないが、重要なこととしてお伝えしたいのが、常に状況を俯瞰し、広い視野を持ってチーム及びお客さんとの状況を取りまとめることができるかと言う点が重要だと言うことをお伝えしたい。

なぜ筆者が上記能力を最も重要な位置づけにしているかと言う理由を説明すると、「どこかいつも全体に気を配る・視野を広く持つ、かつ問題が起きた時には柔軟にソリューションを打ち出す」と言う能力は、「①全体を把握する」と言う能力 +「②エンジニアとしての経験に基づいた裏付けある解決策」の二つの能力が合わさって初めて成立するからだと考えている。

「どこかいつも全体に気を配る・視野を広く持つ、かつ問題が起きた時には柔軟にソリューションを打ち出す」 = 「①全体を把握する」と言う能力 +「②エンジニアとしての経験に基づいた裏付けある解決策」

要は「PM的な管轄能力」+「技術者としての知見・経験値」という、エンジニアとして必要な必要な2大能力を自分は兼ね備えていますよ、ということの裏付けが、「全体を広く見ることができ、かつ判断・指示ができる」と言う行動から取れてしまうということである。

やはり理想を語る上で、まずは他を納得させる最もな理由(=実力)が最上位に来るべきと考えて、本理由を一番目に持ってきたが、もちろん「理想」にはまだまだ遠いので、どんどん他の条件も紹介していく。

 

②小さな溝をうめることができる

優秀なエンジニアの条件として、開発業務の最前線で戦い大きな戦果を上げるということも重要なことだとは思う。

一方で非常に対照的に、
「一歩引いたところから、チームの状況の問題を察知し、早期に修復・改善へと舵を取れるかどうか」が、筆者が考える理想のエンジニア上司像の一理由だ。

言い方は悪いが、つなぎやく、潤滑材のような役割と言えば良いだろうか。

個々の持ち場は、部下が専門家として全うすれば良く、それを活かすように立ち回れるかどうかは、上司の手腕にかかっていると筆者は考えている。少なくとも、筆者が尊敬していた上司の方は上記のような立ち回りが常にできている方だった。

というのもチームで作業をしている場合、大抵、チームメンバーは各々のタスク(=持ち場)をこなすことが目の前の最優先タスクであり、その分野を任されている以上、最低限のアウトプットや成果を求められるし、他の誰よりもスペシャリストであることを求められる。こうなると、個々の一分野での専門性の高さは身についても、個々人が、チーム全体を見るというような目線、及びその心がけというのは通常業務では定着しづらい。すなわち、スペシャリストとしては成長できても、リベラリストとしては成長しづらいということだ。

上記が悪いと言っている訳ではなく、経験の浅いうちは自分の持ち場を守ることだけで精一杯だったりするのが当たり前で、そういった状況では、チーム連携が機能しないことに起因する、思わぬアクシデントが出るのは至極当然の話だ(例:仕事ができるAさんにだけいつも仕事が集まりすぎてしまい雰囲気が悪くなった。Bさんがいつの間にかメンタルを病んで仕事を休みがちになった、いつも穏やかなお客さんのCさんが珍しくブチ切れている、etc、、)。

そんな予期せぬアクシデント、問題がまだ小さな溝である内に、問題であると察知し対策を打ち出すことができるエンジニア上司の存在は、部下目線で見ていてとても心強いというか、とても安心感があり尊敬できる。

実際にあった筆者のお話をすると、筆者が仕事のキャパを超えてしまい、ストレスから仕事のパフォーマンスを発揮できない状況にいた際は、相談などしていなかったが、いち早くその異変に気付き、状況の改善のためチームメンバーに呼びかけてもらったおかげで、環境が改善され、その後の仕事のパフォーマンスを取り戻すことができたという経験がある。

このように、単純に自分の仕事のみに集中するのではなく、周りのチーム状況を見て、柔軟にチームに生まれた小さな溝を埋めることのできるということは、エンジニアの理想の上司像たる理由として妥当なのではないだろうか。

 

③小さな矛盾、疑問、不透明さを見逃さない、許さない

ちょっと強めな言い方だが、経験上、
「小さな矛盾、疑問、不透明さを見逃さない、許さない」という特徴を、尊敬できる理想のエンジニア上司は必ず持っていた。

例えば、

小さな矛盾、疑問、不透明さを見逃さない、許さない例

進捗を曖昧に書いている
→なぜ曖昧にしているのか、何か隠そうとするような理由があるのではないかと疑う。

見積もり工数が厳しめ
→楽観的な工数ではないか、見込み工数が妥当だと説明が付くか、問いただす。

エビデンスに不備があった
→チェック者もいたはずなのに、体制、手順に欠陥がなかったか、再発防止のために再検討を試みる。

まあ当たり前のことを書いているようにも見えるが、重要なことは、通常の人なら今のは聞き流すよなあ、見逃すよなあというような状況でも、必ず一言一句まで精査し、考え、矛盾点に気づくことができるという点である。

部下目線からすれば、その上司の前では、一言一句まで常に気を使わなければならないし、手を抜いたのが分かる資料を作成しようものならば漏れなくダメ出しをもらうという状況なので、仕事をする上ではこの上なく緊張感があり、場合によっては業務に必要以上のストレスを感じることもある。

しかし、これらは誰かを問い詰めてやろうなどという心理からここまで厳しく当たっているのではなく、上司いわく、「ミスや遅れがあるのは誰でもあること。ダメなのは、それを隠蔽または自分の力だけで解決しようとしたり、そもそも自己管理がなっていないせいで、問題がもっと悪い方に向かってしまうことにある。そのような事態を防ぐためにも、状況を客観的にかつ正確に知っておくことが何より大事だ」とのこと。そうしておけば、問題が問題になる前に、妥当な回避策を講じることができるからだと言っていた。

つまり、まとめると、「小さな矛盾、疑問、不透明さを見逃さない、許さない」という姿勢が、筆者の経験上、尊敬できる理想のエンジニア上司の共通点である。またそれが重要たる理由としては、物事や状況を正確に把握しておくことで、問題が問題になる前に、妥当な回避策を講じることができるからということだ。

 

④変に臆病にならず、意思表示、策の提案ができる

筆者は、「変に臆病にならず、意思表示、策の提案ができる」人が理想のエンジニア上司の条件だと考えている。

仕事上お客さんやチームメンバーと仕事をする上で、最もやってはいけないことは、変に下手に出たり、相手主導で物事の進捗を図る(=受け身になる)ことだ。理由は、上記は一見愛想が良いように見えるが、実際はその場しのぎの対応でしかなく、相手に「都合の良い存在」と思われて逆手に取られてしまうからだ。これは長期的な目線ではメリットが一つもない。だが、人は誰しも嫌われたり怒られたりするのは嫌なので、無意識のうちにやってしまいがちな行動の一つである。

しかし、だからこそ筆者が経験上「この人は尊敬できる」と感じたエンジニア上司は、「変に臆病にならず、意思表示、策の提案ができる」人であったと思う。例え、それがベストと言える判断かどうかは問わず、自分の中で、根拠を持って、自信を持った上で「これが正しい」と臆せず意思表示・策の提案ができるかという点が重要である。

やはり部下目線というか、まだ自分に自信が持てないうちというのは、業務経験が未熟だったりスキル不足に起因して、「意思決定」をすることが難しい、もしくはハードルが高いと感じるケースが多々ある。そんな中で、自身の経験測や根拠に基づき、かつ相手の立場や人間関係に左右されることなく自分の意志を発信できる姿というのは、非常に心強い存在であると実感させられる。

また、「この人は自分で考えて判断を下せる=仕事を任せても大丈夫そう」という印象を抱きやすい。実際に、仕事も評価も集まっている上司というのは、漏れなくこの変に臆病にならず、意思表示、策の提案ができる」人であったと思う。

ポイントとしては、「根拠のない自信で常に堂々としている」のではなく、「ある程度根拠を持った上で、自身の意見・策を相手に自信を持って伝えることができる」という点である。

 

⑤人間関係・ストレス度合いに気を配れる

「人間関係・ストレス度合いに気を配れる」という能力は、理想のエンジニア上司として必要な1能力であると筆者は考えている。

上記理由を肯定させてもらう上で、筆者はエンジニアという仕事は経験上、概ね下記のような仕事であると認識している。

 

エンジニアという仕事
  1. チーム開発が主であり、自身のチーム以外のことは管轄外(人間関係なども含め)という考え方がある。
  2. 物事を論理的に捉える人が多く、特に仕事上、成果や進捗はアウトプット主体で判断し、その人個人の人間性や特徴、理由は考慮に含めたがらない。

 

①、②の内容について詳しく議論する気は全くないが、①②を挙げた論点として注目してもらいたい理由は、「人間関係・ストレス度合い」について、エンジニアという仕事の性質上、また、それに携わる人の統計上、比較的無頓着だったり無神経だったりするケースが多いということである。

ここで言う「無頓着だったり無神経だったり」と言うのは、勘違いしないで欲しいが、パワハラめいたことをするような人が多いと言うことを言っているわけではない。むしろ、一見大人しそうで真面目そうな見た目の人の方が多く、そのような人に限って、コミュニケーションが苦手、あるいは(悪気なく)デリカシーのない発言をすると言った行動が多く見られたと言う話である。

結果として、上司にその気が無くても、言われた側(=部下)目線では、必要以上に傷付いたり、萎縮、緊張と言ったストレスから思うようなパフォーマンスが出せない、最悪は転職や休職に追い込まれるといったことに繋がりかねないということである。

まあ、あまり差別的な発言はしたくないが、、分かりやすく言うとエンジニアというお仕事は性質上、どうしても「理系脳タイプ」の人が多いよってことである(伝わるだろうか、、)。

前置きが長くなったが、そんなエンジニアという業界だからこそ、「人間関係・ストレス度合い」について気を配れるエンジニア上司というのは、ひときわ尊敬に値する存在だと部下目線では感じている。

理路整然と正しいことを述べたり、あくまで公正で客観的な評価を下すことは、上司としての重要な役目であることは明らかだ。一方で、みなその前に等しく人であるので、上記で述べたような、「人間関係・ストレス度合い」について、気を配れるというのは、それ以上に理想のエンジニア上司として重要な要素だと筆者は考えている。

 

⑥タイムスケジュールへの意識が高い

PMクラスの方でなくても、優秀な先輩エンジニアは皆、
「タイムスケジュールへの意識が以上に高い」と言う共通点を持っていたと思う。

「意識が高い」と言うとちょっと抽象的なので、どんな点で意識が高いなあと感じたかを述べると

 

ここにタイトル
  1. まずはどんな作業をするにしろ、どのくらいでこなせる作業なのか「スケジュール」を必ず立てる
  2. スケジュールが妥当か、無理はないか、精査する
  3. 進捗スケジュールに対して今どれくらいなのか、報告のタイミングで必ず全メンバー確認する
  4. ②に対して、遅れが発生している事象に関しては、「なぜ遅れているのか」「遅れは問題あるのか、ないのか」を確認する
  5. 「問題ありの場合、リカバリーの見込みは、方法は」「リカバリは妥当か、無理はないか」、、(この辺から①に戻る)

 

とまあ、とにかく時間に対して、「なんとなく」で作業を進めることを絶対に許さない雰囲気があった。何をやるにしても、時間とセットで作業完了への「根拠」を持って仕事に取り組むようにするよう、常にチームメンバーの動きに目を配る(オーラを放つ)と言う特徴があったと思う。

時間(締め切り、納期など)は、仕事をする上でどんな時もついて回るものだ。そのため、時間に対する意識というのは、上に立つものが絶対に持っておかなければいけない資質の一つということだろうか。

もちろんスケジュールというのは完璧である必要はないし、そもそも完璧というは100%無理なことである。もしかすればスケジュールを立てることがそもそも不可能とか、反対にその時間が無駄と思う場面もあるだろう。

だが肝心なことは、繰り返しになるが、「なんとなく」とか「直感」だけで作業を進めることは結局は結果オーライであり、チームとしては絶対に許されないということだ。上に立つものとして、そのようなことで何かあった場合、お客さんやチームメンバーに説明がつかないし、そのような仕事は例え結果うまくいったとしても周囲の人間は誰もその上司を尊敬もしなければ評価もしないだろう。「この人はここまで抜かりがないのか」という姿勢こそが、上司としての信頼を獲得しうる必須条件なのだと、部下である筆者の目線にはそう写ったのである。

裏を返せば、「時間に対する意識が低い」と言うことは、エンジニアとして致命的だと言うことでもあるので、注意が必要だ。

「仕事ができないエンジニアの特徴」と言う記事も別記事にて執筆してあるので、参考に読んでもらいたい。

 

細かいところには気を配れる、でも大雑把に見ると楽観主義

「細かいところには気を配れる、でも大雑把に見ると楽観主義」という、ある意味相反するような性質を、筆者の経験上、理想とするエンジニア上司の方は持っていたと思う。

どういうことか説明をする。

まずは「細かいところには気を配れる」と言うことだが、これは分かりやすく言うと
「一つ一つの目の前の仕事・出来事に対し、繊細かつ注意深く対応できる」と言うことである。信頼が置ける人物の共通条件として、何か一つ仕事するにしても、注意深く、ミスや考慮漏れが無いかを常に考えて行動できると言う特徴がある。目の前のことを丁寧に積み重ねることが、結果として、そつが無く大きな成果を上げられると言うことを理解しているからだ。

次に、「大雑把に見ると楽観主義」と言うのは、目の前の仕事に非常に繊細である一方で、全体的なスケジュール感に対する達成見込みや自信に関しては、「まあなんとかなるでしょ」と言う、楽観的な思考で仕事に臨んでいる人が多いと言うことである。もちろん何も考えず、ただ楽観的なのではなく、上述の繊細さと、ある程度スケジュールに対して納得のいく勝算・段取りが想定できている前提で、「あとはやるだけだよね、まあ後はやってみなきゃ分かんないよね」と良い意味で開き直れることが良いと言っている。

このように、狭いスケールでみると繊細だが、大きなスケールで見ると楽観的という相反する特徴が、仕事ができる理想の上司の方には多かったなあと筆者の経験上では感じるところだ。

反対に、仕事ができない人は、細かいところに気を配れなかったり、「このくらいは良いや」という妥協が仕事内容に散見されたりと、目の前の一つ一つの仕事に対する注意力の欠如や(悪い意味での)楽観性が見て取れることが多い。一方で、大雑把に見ると「こんなの自分にできる訳ないじゃん、、」とすぐに根拠無くネガティブループに陥ることが多い。つまり、仕事ができる人とは対照的なマインドや取り組み方をしがちであるということだ。

 

悪いことは悪いとはっきり伝えることができる。なあなあにしない。

「悪いことは悪いとはっきり伝えることができる」という能力は、理想のエンジニア上司として必要なことだと筆者は考えている。

ある日、普段は温厚な大先輩Aが、仲の良い先輩Bに対して「〇〇をしたのは間違っている」と怒っている場面があった。(口調はおだやかだが目の色変えて「怒っています」オーラを出している)

普段のAさんBさんはランチとかよく一緒に言ってるし、仲良い関係なのだと思っていたので、正直あんなにはっきりと「あなたの行動は間違っている」という怒りの態度を前面に出したAさんは意外というか、単純に驚いた。なぜなら、いくら上司の役目とは言え、わざわざ人に嫌われるようなことはしたくないだろうし、加えて普段仲良さげに話ている間柄で起きた出来事だったので、なおさらだった。反面、「悪いところははっきりと悪いと伝える人なんだ」と信頼たる行動であるとも思った瞬間だった。

上記の出来事に関しては、怒られた先輩Bには気の毒だが、大先輩Aの行動をリスペクトせざるを得ないと思った。まあよく言う「なあなあにしない」と言うことが言いたいわけだが、これができる人は意外と少ないのではないだろうか。誰だって人に嫌われたくないだろうし、嫌われないにしても、きつい態度で当たった後は少なからず気まずい雰囲気が残るだろう。

それでもあえて「はっきりと伝える」ことの重要性を貫き通せる上司と言うのは、それなりに自覚と覚悟を持って「上司」と言う役目を全うしていると言うことなので、これはリスペクト集まるだろうなと言うのが筆者の意見である。

勘違いしてほしくないのは、「間違いを正す」のが目的であって、「腹いせに怒る・鬱憤を晴らす」のが目的ではないということだ。AさんはBさんに対して、必要以上のプレッシャーをかけることなく、事件以降、二人の仲に全く変化はない。

 

逆に、、いやだったこと

ここまで理想のエンジニア上司論を語ってきたが、反対に、「こんな上司は嫌だった」ということもいくつか書いておこうと思う。

自分の感情で態度・当たり具合をかえる、気分屋

感情でものごとを判断する上司は基本的にマイナスイメージだった
論理的に、私情を挟まず、意見してくれる人が良い。

もちろん気持ちはわかるんだが、部下目線で見た時に、どうしても
「あーハイハイ、そうなんですねー分かったわかった」→その人のお株が落ちると言うか、
良い歳で良い立場なんだから自分の「わかって欲しい」を態度に出すなよ、と筆者の場合思ってしまう。

理不尽な理由・態度で部下に当たることは、部下に恐怖感を与え、いざというときに萎縮させてしまう。結果として、パフォーマンスに影響を与え、問題解決に繋がらない。

恐怖政治は一見すれば「なめられない、力づくで統率できる」といった側見から、部下の交感神経を刺激して、ある程度のパフォーマンス向上効果はあると思うが、長期的に見た時には絶対に破綻へ向かうと筆者は確信している。

反対に、ずっと付いていきたいと思う上司は、「ほどよいあめとむち」の感覚を身につけていると感じる。

 

関連記事

ここまで読んでいただき大変ありがたい。もし当記事を面白いと思っていただけたならば、他にもエンジニアの仕事論に関して記事を書いているので、是非読んでもらいたい。

 

 

 

 

記事が気に入った方はシェアをお願いします!

コメントを残す

メールアドレスが公開されることはありません。