見出し画像

エンジニアとして働くということ。(仮)

6月1日から昨日9日まで、ずっとファイアウォールの設定してました。(月曜から通算すると)12連勤ですよ!もー疲れたよ!
写真は幕張メッセのバックヤード。

エンジニアのお仕事

コミーのお仕事は、ITのエンジニアです。エンジニアリングしてないのにエンジニアなのか?ただの物知りじゃない?(煽り)

ITエンジニアといえば、プログラミングする人で「ソフトウェアエンジニア」ですよね。ほかにもフロントエンドエンジニア、バックエンドエンジニア、フルスタックエンジニア、データエンジニア、AIエンジニアなどなど。。他にもハードウェアに関わるエンジニアもたくさんいます。無線や高速通信に関する技術は特殊な印象です。

私は元々はネットワークという非常に狭い分野に特化したエンジニアです。この5年はマーケティング本部で、TME(Technical Marketing Engineer)という、セキュリティ製品を扱うエンジニア的な仕事をしていました。

Interopのインフラ構築

そして9日間、久々にガチでエンジニアしてきました。毎年6月に幕張メッセで開催される、国内最大のネットワークの展示会「InteropTokyo」のインフラを構築する、大変そうなお仕事です。

このインフラは「ShowNet」といい、イベント期間中のすべてのインターネット接続を担います。国内外の最新の製品を縦横無尽に組み合わせ、ありとあらゆる機能をてんこ盛りで構築される、現時点で考えうる最高のネットワーク・インフラです。
ShowNetはイベント終了後、速やかに分解し更地にもどします。

私が今所属している会社は世界最高のセキュリティのベンダーの一つで、毎年ShowNetに協力しています。機器の無償提供・SEを貼り付けてインフラ構築/運用を行います。私もエンジニアの端くれとして、いつかやってみたいと思っていたら、、まさかの参加です。
じつは、去年の参加チームのリーダーに「来年入れてw」って冗談で言ってたのが実現しちゃったんです。言ってみるもんだw

デモ vs. 運用

TMEである私の主な仕事のひとつに、製品のデモンストレーション(デモ)があります。デモの目的は、お客さんの明るい未来を「実機の動作で」見せて、感動してもらう事だと思ってます。「ウチの製品を使うと、仕事がはかどるよ!」って言いふらしてもらうことがゴールです。
便利な機能をわかりやすく見せる使い方を模索し続けていたので、この5年は、製品を導入した後に必要な「運用を前提とした設定」に全く触れてこなかったんです。

ShowNetはそうは行きません。
Interop期間3日間の安定運用は最も重要な要件のひとつで、運用に必要なあらゆる設定を行います。(機器の状態のチェック、通信状態の監視と制御、障害発生時の対策、効果的な構成など)

そういう設定を全然知らないので、いちいち調査しながらの作業になるわけですが、自社のオフィシャルのマニュアルの要約でGPTが大活躍しました。

GPTに雑な質問をすると自然な文章を返してくれますが、しれっとウソが混ざってるので要注意なのは御存知の通りです。リンク先の要約だと知らないことは書かないので安心です。あと、英語のドキュメントを日本語で要約してくれるのは大変ありがたい。
GPTにお願いし、出力している間には別のことができますし、GPTでコマンドの確認も(ある程度は)できちゃいます。便利な世界になりましたね。

ワイはエンジニアなのか

CCIEは、ネットワークエンジニアが目指す最高難度の資格のひとつです。

Cisco Certified Internetwork Expert (CCIE)はネットワーク機器ベンダーであるシスコシステムズによるベンダー資格のひとつである。国際的に通用する資格で、ネットワークエンジニアシステムエンジニアとして最高レベルの技術と知識を有することを表す資格の一つである。

CCIE ウィキペディア

取ったら終わりではなく、2年毎に更新が必要なため、維持するのはそれなりにたいへんな資格と言われています。そして20年継続すると、CCIE Lifetime Emeritusという永世名誉資格を得ることができます。

去年か。

ずっとネットワークやセキュリティデバイスなど「アプライアンス製品」のエンジニアとして過ごした中で、モヤッとしていたこと。

ワイが得たものって、メーカーが提供する機能の有効化とパラメータの入力だけの、極めて限定的なスキルなのでは?

冒頭の煽り

一方、開発エンジニアは、自由にコードを書くことで、必要とする機能すら実装できる。エンジニアを名乗るなら、コード書けてなんぼじゃない?

追い込まれるコミー

ShowNetの構築は、冒険に似ている。(と思った)

毎日「この様な設定をしてください」という依頼司令が届きます。
やり方の指示はないので、実装手段は担当者に委ねられます。

アプライアンス製品にそんな自由度ないじゃん!

頻出

ほとんどの指示は「AをBにしましょう」なので、設定方法を見つけて入力するだけです。でもさ、そんな事ないんだわ。

ある設定で「仕様的に無理じゃ…?」ってのがあって途方に暮れたんです。コミーの担当はインフラのど真ん中なので、ここができないなら、前提をひっくり返して設計変更しなきゃ動かないよね!??!

最終的には同僚メンバーのアドバイスで道が拓け、当初の設計で動作することがわかりました。本当に良かった。

詳細は書けませんが、ある目的のための機能を2つと、別の機能を組み合わせ、インフラを遥かに強靭にすることができる。というものです。

元の設計をしたのはNOCメンバーの方です。
彼はインフラ機器のメーカーエンジニアで、ウチの製品に明るい訳では無いものの、公開されている機能を組み合わせることで、コレが実現できると確信していたのでしょう。私は彼の意図を汲み取ることができなかった。

これが私の生きる道

機能を知って終わりではなく、機能によってもたらされる効果を理解し、それをどのように運用に適用するか想像し、ネットワークを創造する。これこそが、アプライアンスのエンジニアが持つべきスキルなのだと思い知ったんですわ。

ブランク期10年間でなまったのは、スキルじゃなく、思案するチカラ。

雑に結論

この経験は、エンジニア軸を見直すとてもよい機会になりました。エンジニアとしてこれからどう進んでいくか、考える時間だったと思う。今回の気づきを、これからの仕事に活かしていけるかな。。

おしまい。

この記事が気に入ったらサポートをしてみませんか?