社内SE、特に少人数やひとり情シスだと、「上司への説明」が仕事の中でもかなり大きな比重を占めている気がする。
サーバをどうするとか、ネットワーク構成がどうとか、セキュリティがどうとか。
技術的な話はいくらでもできるけど、正直それをそのまま話しても、ほとんど伝わらない。
むしろ、
「何をしたいのか」
「それで何がどう変わるのか」
「普段の業務のどこが楽になるのか」
この辺をちゃんと噛み砕いて説明しないと、話自体がスタートしない。
自分が一番意識しているのは、サービス名や技術用語をできるだけ使わないことだったりする。
技術の話をすると、だいたい止まる
昔は、ついそのまま説明していた。
「VPSを使ってサーバを分離して…」
「DNSを冗長化して…」
「バックアップ構成を二重化して…」
今思えば、完全に自己満足な説明だったと思う。
上司側からすれば、
「それで、結局何が良くなるの？」
「今と何が違うの？」
この状態になるのは当然で、話が途中で止まってしまう。
結果、「よく分からないから、今回はいいや」となってしまい、せっかく考えた改善案も流れていく。
このパターン、何度かやって、ようやく気づいた。
「業務のどこが変わるか」から話す
それからは、説明の順番を意識的に変えるようにした。
まずは技術の話を一切せず、
- どの業務が
- どう楽になるか
- どのトラブルが減るか
ここから話す。
たとえばサーバ構成の見直しでも、
「今は障害が起きると全員止まる構成になっているので、ここを分けると、止まる範囲が小さくなります」
とか、
「月に1〜2回、軽いトラブル対応で30分ずつ取られているので、年間で見ると結構な時間になります」
みたいな言い方をする。
そのあとで、
「そのために、こういう構成にしようと思っています」と、技術の話を少しだけ足す。
すると、理解度がまったく違う。
サービス名・製品名は最後に出す
もう一つ意識しているのが、サービス名や製品名は、最後に出すということ。
最初から、
「Xserver VPS を使って…」
「クラウドWiFi を導入して…」
と言ってしまうと、どうしても「それって本当に必要？」という話にズレてしまう。
なので、
- 業務上の課題
- それによる困りごと
- 改善したときの効果
- その手段としてのサービス
この順番。
結果として、自分の場合は社内のサーバ基盤に Xserver VPS を使っているけど、それも「安定して運用できて、障害時の切り分けが楽」という文脈の中で説明しているだけだったりする。
サービスを売りたいわけじゃなく、業務を止めないことが目的なので、その手段として選んでいる、という位置づけ。
予算の話は「金額」より「影響」
上司への説明で、避けて通れないのが予算の話。
ここも、金額から入ると失敗しやすい。
「月◯千円かかります」と言った瞬間に、
「高い」「今じゃなくていい」となりがち。
なので、
- これが止まったら、何人の業務が止まるか
- 何時間分のロスになるか
- お客様対応に影響するか
この辺を先に説明してから、最後に金額を出す。
そうすると、「その金額なら安いね」という反応になることが多い。
正直、これは何度も失敗して学んだ。
正直、今でも迷う
とはいえ、毎回うまくいくわけじゃない。
説明している途中で、「あ、これ伝わってないな」と感じることもあるし、
「そこじゃなくて、別のところを突っ込まれるか…」と思うことも多い。
結局、相手次第な部分も大きいし、正解があるわけでもない。
それでも、
- 技術の話をしすぎない
- 業務目線で話す
- 目的 → 手段 の順で説明する
この3つだけは、ずっと意識するようになった。
ひとり情シスは「説明力」も仕事
サーバを組む力、ネットワークを作る力、トラブルを直す力。
どれも大事だけど、ひとり情シスの場合、説明力も同じくらい大事だと思っている。
説明できなければ、
- 予算が取れない
- 構成改善できない
- 結果、トラブルが増える
という負のループに入りやすい。
だから最近は、「どう説明するか」まで含めて設計するようになった。
正直、エンジニアっぽくない仕事だなと思うこともあるけど、
中小企業の情シスでは、これも立派な実務の一部なんだと思っている。
今の正直な感想
上司への説明って、面倒だし、気を遣うし、疲れる。
でも、ここをサボると、後から自分がもっと大変になる。
そう思って、なるべく丁寧に、分かりやすく、業務目線で話すようにしている。
たぶん、ひとり情シスを長く続けるには、
技術力よりも、この「翻訳力」みたいなものの方が大事なのかもしれない。
似た立場の人なら、きっと分かってもらえると思う。
