78
46

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

はじめに

この記事はこれまで私がIT企業での15年ほどの社会人経験の中で感じてきた体験談を元に記載していますのであくまで参考としてお受け取りください。
また私は「非エンジニアの上司」側の立場での経験がほとんどであるので、逆説的にエンジニアのみなさんの参考になればと思い記事を書いております。

みなさん、会社の組織の中で「非エンジニアの上司」にあたったことは無いですか?

  • 前提知識が違うためコミュニケーションが難しい
  • 技術の事を分かってないのにちゃんと評価してくれてるのだろうか
  • 技術や開発に関する悩みや相談が出来ない
  • 技術的な部分で上司から学ぶことが出来ない

などなど
日々思うこともあるのではないでしょうか。

そのような中で、「非エンジニア上司」側からの経験から、どのようなスタンス、コミュニケーションをとることが効果的なのかをいくつかご紹介したいと思います。

非エンジニア上司の攻略方法

目次

①専門用語はあえて使う

注意!これは上司との関係性や上司の心構え次第なところがあります。

開発に関する専門用語ありますよね。
エンジニアからすると当たり前の用語でも多職種からすると知らない、または単語は分かるけど何か分かっていない。そういうことあると思います。

例えば私が社会人2年目くらいのことにエンジニアと仕事をした際に「デプロイ」という言葉が出ましたが何を指しているかわかりませんでした。
数年前にSREチームと話をしていたときに「SLOを◯◯%に〜」のような話が出たときに何のことかわかりませんでした。

基本的には他職種にも分かる言葉に置き換えて話すのが丁寧であるとされていることもありますが、個人的にはそれをやっているとお互い理解し合わないままで終わると思っています。

なので、私は基本的に「専門用語は使ってもらって良い。その変わり分からないときに聞くから教えて欲しい」というコミュニケーションをとっています。
もちろん自分でも調べます。会議中にこっそりググったりよくしています。

上司との関係にもよりますがあえて普段使っている専門用語を普段のコミュニケーションに入れていくことで、上司側の理解を深める、上司が何を知らないか?を発見すること出来る、そういう感覚で取り入れてみるのはオススメです。

※「こいつ何も知らないな〜」とか「全然勉強してないな〜」とかは一旦心に留めておいて優しく教えてあげましょう。

②定量的な伝え方を意識する

これはどの職種においても職種を跨ぐ際にはもっとも効果的な話かと思います。
同職種同士であれば、共通理解、共通知識があるため定性的な話でもスムーズにコミュニケーションが取れることもあると思います。

一方で異業種間の場合、それが無いことによってうまく伝わらない(というよりも温度感が同じにならない)ことが多いように思います。
なので、基本的には誰から見ても同じ指標である定量的な数字を交えて置き換えて話すと効果的です。

例えば、技術的な課題に対して上司に報告をするとき。
「◯◯のシステムが△△のような状況なのでリスクが高く、対処するための人員が必要」と伝えるとします。
これがエンジニア同士であれば◯◯のシステムがどういうものかを理解しており、△△のような状況がどれくらいヤバいのかをある程度感覚的に理解が出来ます。

しかし非エンジニアの上司からすると同じ感覚での理解が難しい場合があります。

なので
「◯◯のシステムが△△のような状況なのでリスクが高く、このままにするとxx円(または開発の遅延日数等)の損害が出る可能性があります」
のような伝え方をしてみます。

ここの「xx円の損害〜」についてはすごく正確では無くてもある程度概算でも良いです(もちろん精緻な方がベスト)

このような定量的な話を入れ込むことで、そこから会話に発展が生まれます。

上司:「このxx円というのはどういう算出をしたのかな?」
エンジニア:「◯◯のシステムが不具合を起こした場合にサービスの稼働が□□止まったと仮定した場合です」
上司:「サービスの稼働が止まる不具合とは具体的にどういう場合に起こる?その可能性は?」
・・・などなど

こういうコミュニケーションが発生して相互に理解を深めていくことで、相互にリスクに関する解像度を高めていき、上司側の判断軸も共有したうえで対応について結論をつけることが出来ると良いと思います。

③エンジニアが得意なことを巻き取ってあげる

これは非常に効果的な場合があります。
例えばSlackなどの設定、社内サーバの権限設定、集計ツールの設定などなど。
あえてエンジニアがやる仕事では無いけれど基本的にはエンジニアの方が得意(早い)な仕事ってありませんか。
上司からするとそういうことをさらっとやってくれるエンジニアはとてもありがたいです。

そうすると、逆にエンジニアが苦手な社内調整(あくまで例なので人によります)などを代わりにしてあげようという気持ちが芽生えます。上司と部下もあくまで人間対人間なので、助けてもらったことは今度は自分が助けてあげようと思うものです。

例え上司部下であっても「強み同士のギブアンドテイク」が成立することが最も効率が良いはずです。

  • 上司がやれば10かかる仕事をエンジニアが5の労力でやる
  • エンジニアがやれば10かかる仕事を上司が5の労力でやる

そうすれば本来20かかる仕事が10で出来るかもしれません。

そして、この労力を技術力で最大限まで小さくすることが出来るのはエンジニアの強みの1つだと思います。

何か画期的な業務改善のようなものではなくても日々の仕事にある部分でこのような価値発揮をすることで必ず自分に返ってくるはずです。
どんどん上司に貸しを作っていきましょう。

最後に

今回「攻略法」と書きましたが、相手を倒すわけではありません。
相互理解を深める、それによって自分の仕事がよりスムーズになる、結果として組織チームが機能する。そのようなヒントになれば幸いです。

78
46
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
78
46

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?