SE(システムエンジニア)はコミュニケーションエンジニアを目指すという生存戦略

SE(システムエンジニア)はコミュニケーションエンジニアを目指すという生存戦略

こんにちは、最近ハワイでフォトウェディングをしてきた、らいかです。 その時の写真とかハワイに初めて行く人の不安を少しでも緩和できる情報を次の記事くらいでお届けしたいなと思いながら下書きに見出しを作成しています。

とてつもなく話は変わりますが、

日本だけに存在している“システムエンジニア”という職業をご存知ですか?
SE(システムエンジニア)と言えば「あぁ~、知ってる。」と思われる方が多いと思います。

とはいえ、「SEって何する人か説明できる?」と聞かれると難しいですよね。
大丈夫です。元SEのわたしでも説明することが難しいのでこの質問は本当に難しい。

SEの仕事はあまりにも多岐にわたるもので、コレ!と簡単に説明出来ないんですよね。たとえば

  • コンピュータの組み立てをするひと
  • コンピューターの初期設定を行うひと
  • ネットワークの面倒を見るひと
  • プログラムの仕様書を書くひと
  • プログラムを書くひと
  • 作ったプログラムの試験をするひと
  • 作ったシステムの運用をするひと

少し、広義だと思いますが全部SE(システムエンジニア)として一括りにされることがあります。(いやほんとに)
ハードウェアをさわる人からネットワークをさわる人、実際にプログラムを組む人だけじゃなく、何なら運用担当者もSEと呼ばれちゃうとシステムエンジニアってますます何する人なのか全然わからない。多分システムエンジニアの本人も自分自身を見失っていく。

一方欧米では、それぞれの仕事内容によって「○○エンジニア」という形に厳密に区別され専門的に特化できるように明確に職域が定められています。

(※厳密に定義すれば細かな職種を挙げれますが、同じIT業界内でしか理解され辛い専門用語のため、結局IT業界外にいる人に対してはSEという大きな括りで説明されてしまいます)

一方、日本ではこれらの仕事をまんべんなく行えることを求められるのでSEの職域は非常に広く
当然のように種類の違う仕事を兼務するためSEの専門スキルは高くないことが現実問題としてあります。

この問題は、わたしもSE時代に強く感じていました。
日々めまぐるしく変化・進化するWebやIT業界。新しいスキルがどんどん生まれては消えを繰り返していくけど、未だに自分はExcelVBAを使って社内ツールを作ったり、オブジェクト指向を使わないJavaの設計書作成。
本当にこのままでいいのかな?このまま20年を過ごして20年後仕事はあるのかな?そんな風に怯えていました。

この記事では、元SEとして高い専門スキルを求められる時代でSEが生きていくためにはどうしたらいいのか?という課題に対して自分なりに考えて結論づけているコミュニケーションエンジニアを目指すということについて紹介したいと思います。結構個人的な主観やNTTグループのSIerでの経験という狭い知見によるものなので、もしかすると世間一般的なSEのイメージと乖離しているかもしれませんが、1人のエンジニアの意見として大目に見てやってくれると幸いです。

SE(システムエンジニア)は何でも屋?

はっきり言ってシステムエンジニアは何でも屋ですよね。悪く言えば便利屋。
社内で発生するコンピュータに関連するトラブルやお悩みをツール開発したり技術的なアドバイスをしたりして解決する。
いわゆる、社内SEと呼ばれるポジションの方はこういったお仕事をしていますよね。
開発者と呼ばれるポジションの方であってもプログラムをバリバリ書く人以外、根底は課題解決なので過程が違うだけ。
だいたい何でも解決方法を知っていて、解決方法に向かうのでSEは何でも屋として見えてきます。

社内からの扱いとしても、何でも屋として扱われるようになり、本人も徐々に何でも屋としての自覚が芽生えてきます(体験談)

でも、いつまでも何でも屋のままじゃダメですよね。本当はモノ作りがしたくてこの業界に入ったんじゃないんですか?プログラムを組みたくてIT業界を選んだんじゃないんですか?いつまでも何でも屋のまま誰かのお悩みを聞き続けることに満足しているなら良いですが、そうじゃないなら考え方を変える必要があります。

特にこれから先を生き残っていこうと考えるのであれば、考え方をしっかりと変化させていかなければ!と思ってきました。

技術分野の分業化・特化が進んでいる

最近、AI(人工知能)やIoTやBigDataやVRやChatBotなど生活を非常に効率的に豊かにする技術が登場し、IT業界でたいへん大きな賑わいを見せていますよね?

この新技術がメインストリームになっていくことは明らかなので、不足することが予想される先進技術者育成に国家レベルで力を注ぐ方針を立てるなど、専門スキル向上を後押ししようとしているではないですか。

この技術って使う側からしてみれば何でもコンピューターがやってくれたり、ボタン1つで複雑な思考を行ってくれたりと便利なのですが、作る側からしてみれば非常に高度で専門性の高いスキルを持っていないと扱えません。
一昔前にスマホアプリゲームを開発できるエンジニアが非常に高給で転職するのと同じで、時代に合った高いスキルを持つ人が重宝される時代にどんどん変化していきます。

さて、

こんな専門性の高い技術が必要となる分野に「何でもまあまあ知ってるSE」は必要でしょうか?
きっと不要ですよね。特に昔の凝り固まった考え方から抜け切れていない人はどんどん淘汰されてしまいます。

「細かい事は分からないけど、なんとなく知ってる」

なんていう人は、これから登場する専門スキルを磨いた若手にドンドン追い抜かされて、淘汰されてしまいます。

マネジメントスキルとかコミュニケーションスキルとか活きてくるスキルはあるんですが、市場価値として評価しやすいスキルとは言いにくいので、露骨に専門スキルをもった若手に抜かされる時代が来ると思います。

しかし、プログラムをバリバリと専門的に行ってきたプログラマーとは違うシステムエンジニアはどうやって専門的なスキルを身に着けていくんでしょう?
毎日の忙しい時間の合間を探して新しい技術を習得する?それもいいでしょう。

でも、システムエンジニアの方には今持っているスキルが実は専門家が持ち合わせていないユニークなスキルなんだ。という事に気づいて欲しいですし、わたしはユニークなスキルであると強く考えます。

I型人材とT型人材について

少し話が変わります。
「I型人材」と「T型人材」という言葉はご存知ですか?分類的には人事用語や人材育成用語に分類されるのかな?

I型人材とは
特定の技術に特化していて1つ特に自信のあるスキルをトコトン追求していく専門家(スペシャリスト)と呼べる人材のことを指します。

T型人材とは
広く浅く様々な分野の技術を習得していて、その中で1つ自信のスキルを持つ総合家(ジェネラリスト)と呼べる人材のことを指します。

一昔前から「T型人材になろう!」という風に教育されています。学校の教育も少しつづ変化していますよね。
1つ得意な専門分野を持ちつつも、その分野と近いところのことも広く知っている。ITに何でも屋を求める日本にとっては使いやすい言葉だし、イメージしやすいので「T型人材」を目指すように指導・教育しているのですが、

わたしの経験からやっぱりT型人材がゴールになってはいけないと強く感じていました。

だって、「T型人材は様々なことについて幅広く知っている」って

いわゆる、”I型人材”の専門家も幅広く知ってるわ!!!と思うんですよ。

そんなことより本当に求められているのは、幅広く多岐にわたる専門技術を最適に効率的に組み合わせる人材なんじゃないかって常々思っています。

―――。

とはいえ、問題があります。

尖った専門技術を最適に効率的に組み合わせるって完全に”言うは易く行うは難し”ですよね。
だから、コミュニケーションなんです。(ココ重要)

ボクは知らない。でも知っている人をボクは知っている

わたしは、SIer時代は典型的な”量産型T型人材”でした。
一応過去形です。今はT型人材ではなくもっと別の具体的な人材に目指して行動をし始めているので過去形です。

「ボクは知らない。でも知っている人をボクは知っている」

これって相当な強みだと思うんですよね。SI企業で働いている時にいつもこういうポジションにいました。
技術に尖った人から見れば、「なんだお前使えないやつだなぁ~」と思われそうですが、チームのリーダーポジションやサブリーダーが必ず高い専門技術を持っている必要はなく、なんなら「あの人に聞いたら分かるだろうから調整してくる」能力の方がよっぽど求められるスキルだと思っています。

当然、最低限の専門スキルを持ち合わせていないと会話が出来ないので勉強は必要ですが。

全く異国の地で言葉が通じない人と、どうしても話をしたい時に通訳が居てくれたら助かりますよね?
しかも、その通訳が「能力の高い人知ってるから教えてあげるよ!」って言ってくれるものなら最高ですよね?

色々な専門家たちの間に立って、目標達成のために日々仕事に勤しむシステムエンジニアは、誰がどんなスキルを持っているのかを把握し、必要な際に専門家のスキルを頼る。

知っている人を知っているだけ。に見えるかもしれませんが、適切にコミュニケーションすればプロジェクトにとって非常に有益なスキルになります。

人と人を繋ぐエンジニアにある十分すぎる価値

これも私の経験則ですが、炎上するプロジェクトの大半はコミュニケーション不足や行き違いがスタート地点です。
当然、意味不明な要求をするクライアントを上図にコントロールできないPMの責任も非常に大きいですが、大きな問題を紐解くと、「あの時言った。言ってない。」や「こう言われたから、これくらい大きなことが出来ると思った。」みたいな簡単なコミュニケーションの行き違いにあります。

もちろん、クライアントと開発サイドで起こるだけでなく、開発者と開発者の間でもミスコミュニケーションが原因での炎上はありますし、たくさん見てきました。

外部設計者と詳細設計者が会社レベルで異なる場合なんかに起きやすい印象ありますね。

Web業界でいえば、プログラミングスキルの高くないディレクターとエンジニアの間。デザイナーとエンジニアの間。

関わる人がそれぞれ何かしらの専門家で、
専門家が専門家同士で話す言葉を使って近いけど別の専門家と話すので、そりゃ細かなニュアンスとか食い違いや意識違いが生まれますよ。

で、

その細かな意識違いが積み重なりまくった結果が「そんなの聞いてない」ってことですね。

いい歳した大人が言葉の行き違いが原因で消耗してめちゃくちゃ大量の時間を使ってリカバリする。バカバカしいと思いませんか?そんなことにならないように円滑なコミュニケーション計画を立てたり調整をする役回りをする人が居るだけで、プロジェクトの炎上率が下がると信じています。

専門的な技術を突き詰めると、他の人と話がしづらくなったり(そもそも通じなかったり)
でも、みんなプロジェクトが炎上せずに良いものを作りたいという共通目標のために努力をしているので、人と人をエンジニアが繋ぎ合わせることって相当大きな価値があります。

プロジェクトマネージャとコミュニケーションエンジニアの違い

当然、こう思われるでしょう。
「それPMの仕事じゃん」「それTLの仕事じゃん」

いや、ほんとはそうなんですよ?

でも、できてる人って少なくないですか?出来ないから炎上しちゃうんですよね。
だから、最初から要員計画としてコミュニケーション計画を集中的に検討・実現するエンジニアを1人確保しておきます。

当然、この作業だけしていてはエンジニアではなく、ただの会議調整担当なので通常のワークフローにも放り込まれます。

コミュニケーションエンジニアは、色々なプロジェクトに顔を出しつつ、他チームと連携しなければならない場面や連携した方がいい「ここぞというタイミング」に威力を発揮するエンジニアになります。

コミュニケーションエンジニアの可能性

色々な可能性があると思います。
まだ、具体的に”これをするべきだ”という風に確立されていない種類のポジションですし。
たとえば、

  1. 非エンジニアが作った仕様書をエンジニア観点で加筆修正する
  2. エンジニアの課題管理票をクライアントに伝え、何をいつまでにどうやって決めなければならないかを教えてあげる
  3. チームをまたぐワーキンググループを設立し、大きな課題解決を成し遂げる

こんなところが、直近イメージできて、行動に移せる点でしょうか。

あとがき

呼び方に関する悩み

呼び方って重要だと思うんです。
人と人を繋ぐエンジニアなので”ブリッジエンジニア”が名前として適切なのかな?と思ったら既にあるし。

ブリッジエンジニアとは
ブリッジSE(ブリッジ人材/ブリッジエンジニア)とは、ITのスキルだけでなく言語や文化など両国間(例えば中国と日本)のビジネス習慣を熟知し、間に立って円滑に業務を進められるよう指示できるSEのことです。 SEの能力に加え、プロジェクトマネージャーとしての能力、そして言語力が求められていることが分かります。

  • コネクションエンジニア?
  • ハブエンジニア?

でも、重要なのはコミュニケーション力を発揮して課題解決していくという点にあるので、今回選んだ「コミュニケーションエンジニア」という言葉が結構マッチしているのかもしれません。

わたしは、コミュニケーションエンジニアとして転職します

超余談ですが、コミュニケーションエンジニアとして転職します。
もちろん、エンジニアっぽい仕事もしますが、”ディレクターとエンジニア”を繋ぐ仕事をします。
その他にも、プロジェクトマネージャーとしても仕事をします。

縦方向に組織やチームの形を変えるプロジェクトマネージャーとして、
そして、横方向に組織内や組織間のコミュニケーションをコミュニケーションエンジニアとして変えていく。

今まで得てきた経験活かして、1つでも炎上案件を未然に防げたらいいな。
そして、もっと効率的にパフォーマンスを発揮できるチームが作れたらいいな。

そんなことを考えながら頑張ります。

SE(システムエンジニア)はコミュニケーションエンジニアを目指すという生存戦略

SNSへのシェアはこちらから!

ABOUTこの記事をかいた人

工業高等専門学校を卒業後、NTTグループのSI企業に就職。数々の炎上案件を鎮火するために日本各地を5年間転々とする。2015年に一般ユーザ向けのWebシステム開発案件のチームリーダとして業務に従事し、改めて"Webのものづくりの楽しさ"に気付きWeb制作会社に転職。Web制作やアクセス解析を使ったオウンドメディアの運用改善などを行っていく中で、もっとユーザー目線でWebをただ制作するだけではなく企画や運用まで幅広い領域で仕事がしたいと感じるようになり、Webディレクターのキャリアを目指す。日本中のビジネスホテルに詳しく、犬や猫よりも鳥派。