主流であるクラウドの内側で働くエンジニアの声

あるクラウドエンジニアからの私信 第二便

概要

クラウドの内側では、どのようなことが繰り広げられているのかという点をわかりやすく説明することで、ITエンジニア同士の架け橋となることをテーマとして掲げております。

クラウドというと血の気が通わない単語に聞こえるかもしれない。
しかし、そのクラウドの中で働いている人間は血も通い、感情もある人間である。
この仕事に就くにあたり、当たり前だが面接があった。
そこでの質疑応答は今にして思えば形式的だったと思うくらいだ。
談笑たる時間のなんと多かったことか。
クラウドという大きな、世界を覆うシステムに携わるには否が応でもチームとしての振る舞いが求められる。
いわば一匹オオカミの態度は残念ながら通じない。
その談笑は半ば、どのくらいチームプレイに徹するかの試験紙的要素があったように思う。
誇れる技術的なバックグラウンドも第二言語としての英語も完全でないにもかかわらずその職に就けたのは、人間という感情が交差するチームに溶け込めるか否かが重要だった。
基本、世界のどこでもインターネットと神経細胞にさえつながっていれば、このクラウドは無意識でも使える。
ということは、24時間365日のサポートを必要とするのだ。
24時間365日、クリスマスもお正月も関係なく、問題も疑問も苦情も、何もかもが世界のどこからか挙がってくる。
機械的に処理されることばかりではなく、どうしても人間が関与するべきことがある。
サポート、人へのサポート、もっと言えば最終的には人の心によりそうサポート。
コピーアンドペースト気味に書かれていたとしても、その文章の背景にはクライアントたちがこのクラウドに払ってくれる対価以上の思いがある。
この問題よ、早く直れ。
この事象よ、早く直れ。
そして、その共通して持った不安よ、早く消えされと。


このコロナ禍の転職事情を挟みたい
入社式などもなく送られて来た会社用パソコンを立ち上げ、自宅のネットワークにつなげる。
これが最初の仕事だった。
オンラインでつながり、同じ日に入社した人がおり、最初のあいさつがそこで交わされた。
しかし、あちらも同期入社、お互いがしどろもどろ。
お見合いでもしているのか?とツッコミを入れたくなるくらい、お互いの共通項を探している。
遅れてOJTを担当する人間が登場した。
ホッとしたのもつかの間、英語を使った会話は想定内とはいえ、自分の英語力不足には今でも反省している。
そのOJTの内容にも驚いた、ちゃんとパッケージされていたからだ。
笑われるかもしれないが、パッケージ化されたこと自体に「別の会社に来たな」とあらためて実感する。
ただし、そのパッケージの飲み込みができないと、当たり前だが使用期間内にはさようならを切り出されてしまう。
通常であれば出社し、専用の机や会議室で行われるが、このパンデミックでは言うまでもなくオンラインでパッケージ講義が進んでいく。
あくびがでるのはしょうがない、サボろうとするのであればできないわけではない。
そんな誘惑をいとも簡単に選択出来てしまう環境が怖い。
一方、クラウドを提供する側のエンジニアというのが少しずつ理解できて来た。
理解していくのと比例して、ポジティブな疑問も湧いてくる。


(FAQ) このコラムを書こうとしたのか?


まず、クラウドエンジニアといっても、大元なのか? 請負なのか? エンドユーザー側としてなのか? はたまた、エンドユーザーとの間のベンダーなのか? 一概にはいえないであろう。
よって、クラウドエンジニアをここでは クラウドを提供する側のエンジニアという位置づけで話を進めていきたい。


今まで積み重ねてきた仕事における人脈は必ず持っておくべきだ。
どこで、どうその人脈を使い、金脈を掘り当てるか。
エージェントの使用も構わないであろう。
某仕事特化系ソーシャルメディアに登録すると、1日1回はあちらから仕事内容が記載されたメールが毎日送られてくる。(なお、筆者はそのメールを今でも毎日受け取ってはいるが、自分の仕事の価値たる年収についての情報を得ているといっても過言ではない)
そこでまず、会社のIT部門で自社のパソコン管理、例えば、パソコンをドメインに参加する、プリンターの設定をする、エクセルの使い方を教えるといったことが特に好き、というエンジニアはクラウドエンジニアにならないほうがよいであろう。
エンジニアではない一般ユーザーを相手にしたいのであれば、そちらを優先するべきだ。
そう、クラウドエンジニアの相手は同じエンジニアとの間で仕事が進んでいく。


ただし、クラウドの大元に向かえば向かうほど、エンジニアとしては共通しているのは最低3点に絞られる
1. コマンドをたたく、コマンドのパラメータを知っておく
2. 英語を勉強しておく
3. ドキュメントを読む・資格を取る


まず、コマンドをたたく?と笑っている読者もいるであろう。そんなエンジニアがいるのか?とあるいは、今更、GUI以外で設定することがあるのか?と。
そう思われてしまうかもしれないが、笑わないで聞いてほしい。
しかし、Azureでも、AWSでも、GCPでもコマンドは使用される。
Ping -t のコマンドを思い出してほしい。
その延長に過ぎないコマンドだが、それでも、先端を行くクラウドでさえもコマンドという一見、古めかしい方法で使用されることは多々ある。
あとで聞いた話だが、筆者がプログラマー時代に使用していたUNIXでのコマンドはもちろん、viエディターも使用できたというのがプラス評価だったと知った時には、驚いてしまった。


そして、ここでもやはり英語が出てくる。
エンドユーザー側からのクラウドエンジニアであればトラブルシュートがあっても英語が使用できれば基本的に24時間対応が可能だ。
つまり、一人でトラブルと格闘することはない。
しかし、日本語というローカル言語だと日本時間に合わせなければならない。
それ以外の日時になると費用・金額が変わってくる。
また公式ドキュメントもそうだ。
英語版が先にリリースされて、日本語も含む他の言語への正式リリースは結構な時間がたってからだ。
クラウドを提供するエンジニア、そう筆者の場合だが、基本、英語を使用したコミュニケーションである。
時として、日本人だけの社内会議であったとしても英語が使われる。
海外のエンジニアともクライアントとも一緒に仕事をする際には英語が使用される。
ただし、だからこそローカルの日本語が使用できる、という点が逆にポイントにもなってくる。
日本語を母国語としないエンジニアが書く文章は、筆者の英語力を棚に上げていえば、100点満点ではない。


つまり、少なくとも2022年の時点では英語プラス日本語(あるいは他の言語)を使うことができるエンジニアはクラウドを提供するエンジニアになる要素はある。
(そして、英語を使ったOJTにも四苦八苦せずに済む)


ドキュメントを読む・資格を取るという基本的なことも書かせてもらった。
資格については別の機会に触れるとして、このドキュメントにフォーカスを合わせたい。
大概のことは実は公式ドキュメントに書かれている。
この公式ドキュメントをどう解釈するか、筆者はプレイブックだと認識している。
つまり、このクラウドのサービスはこのルールです、と謳われているプレイブック。
(時には公式ドキュメントに書かれているにも関わらず、内部の問題でプレイブック通りにならないのは、人間が介在しているからといって開きなおるしかない。)
ドキュメントを読むということを厭わない、他人任せにしないという態度がクラウドを提供するエンジニアには必要だ。


そういうまだまだ抽象的でぼやけていたクラウドエンジニアのOJTが終わり、教官たる人物から「Good Luck」という言葉を貰った次の日、配置されたチームリーダーからチャットが入った。


「Hello」


2022年4月吉日

連載一覧

コメント

筆者紹介

藤原隆幸(ふじわら たかゆき)
1971 年生まれ。秋田県出身。
新卒後、商社、情報処理会社を経て、2000 年9月 都内SES会社に入社し、主に法律事務所、金融、商社をメイン顧客にSLA を厳守したIT ソリューションの導入・構築・運用等で業務実績を有する。
現在、某大手クラウド運用会社の基盤側でサポート業務に従事。

バックナンバー