はじめに

今から３年前、北海道から三重県に引っ越し、エアコンに感動していた男がいました。

（３年経った今でも冬にスニーカーを履ける喜びは健在）

3年前の今頃は、何もかもわからない状態で本当にやっていけるか不安でしたが、気づけば3年が経過していました。

ちょうどこの時期は、新入社員として働き始める第一歩を期待と不安を胸に心待ちにしている人や、企業の情報解禁により本格的な就職活動に取り組もうとしている人も多いことでしょう。

このブログでは、文系未経験で入社し、子犬のように初々しかった頃から現在までの3年間を振り返り、成長の過程や経験、そして当時抱えていた悩みについて赤裸々に綴っていきたいと思います。

まずは、簡単にこの３年間を総括したいと思います。

〜０年目：大学の専攻は生粋の文系な文学部、パソコンは課題のレポート作成とYoutubeをみるためのもの。

０〜２年目：AWS インフラエンジニアとして設計〜運用保守業務まで担当

2024 Japan AWS Jr. Champions　受賞

2024 Japan AWS All Certifications Engineers 受賞

３年目～：プロジェクトにおける品質管理チームのリーダーとしてリリース・納品業務を中心に担当

振り返ってみると、何もわからなかった小犬時代から、AWSという専門性を身につけ、今ではチームを率いる立場へと成長できました。順風満帆に聞こえるかもしれませんが、この道のりは決して平坦ではなく、苦しい時期もありました。ただそんな日々の積み重ねが今の自分を形作っていると思っています。

このブログは新入社員としてIT業界に飛び込もうとしている人、IT業界で働きたいけど自信がない就活生、そしてすでにIT業界で働いているものの何か今の自分に満足できずにいる人など、さまざまな方に向けて書いています。

このタイトルをクリックしたということは、何かヒントを探しているのかなと思ってます。このブログを読んでなにか皆さんの心に響くものがあれば嬉しいです。

３年間を振り返る

何が分からないかが分からない１年目

Windowsのコマンドプロンプトも触ったこともなく、インターネットとネットワークの違いもわからない状態で、のんきに4月から桜を拝めることに感動していた１年目の春。技術研修で一通りインフラからフロントエンドバックエンドまで一通りアプリの作り方を教えてもらいましたが、内容が全く理解ができず、ただ言われる通りにキーボードとマウスを操作して人生初めてのアプリを作りました。

そこからすぐ、プロジェクトに配属されます。そのあとすぐ別のプロジェクトに配属されますが、そこから約３年間はこの移ったプロジェクトとともにキャリアを形成していくことになります。

今の自分の社会人人生のほぼ全てを彩ったと言っても過言ではないこのプロジェクトがどんなプロジェクトかをざっくり説明すると、古いものを新しいものに作り変えるというプロジェクトです。

もう少し具体的にいうとオンプレミスに構築されたシステムをAWSというクラウドサービス上に構築しつつシステム上で動かすアプリケーションも改修するというクラウドリフト＆シフトと言われるプロジェクトとなります。

※世の中では、クラウド化が進んでおりますが、必ずしもオンプレミス＝古いわけではないです。

１年目にやっていたことの流れはざっくり以下3つに分類できます。

オンプレミスでやってたものをクラウドでどう再現できるか（設計）
ある程度再現できそうになってきたから実際に作ってみよう（開発）
作ってみたものを使って実際に動くか試してみよう（テスト）

3つに分類できます。なんてドヤ顔で言ってますが、今こうやって改めて振り返ればこんな感じで進めていたんだなと理解できているだけで、当時はただ先輩や上司に言われたことをやってみる日々でプロジェクトの全体像なんてものはよくわからなかったです。

特に設計の段階では、完全な正解がない中で手探りにオンプレミスでやっていることをクラウドで再現できるか検証を行っていました。ここでの1番しんどかったポイントは再現できるのか・はたまた再現できないのかを検証するにしても、どこまでなにをやったらこれは再現できないから違う方法を考えるしかないと判断いいのかが分からないところでした。

技術的な引き出しがない自分からすると、なんとなく先輩がこうやったらできそうと言われたことに対して調べながらやってみてできなかったとき、次の一手がでてきません。これは不可能なのか。。？それとも他の方法があるのか。。？そもそも今できなかったこの作業って本当にやり方合ってるのか。。。？全てが謎です。

それ以上に１年目に抱えてた最大で最恐な悩みがありました。それは「何が分からないかが分からない」です。

先輩に聞こうにも何を聞けばいいのかわからない、そもそも自分が何をしてるのかわからない。先輩に言われたことをただ言われた通りにやろうとすると陥りやすい感覚だと思ってます。分からなさすぎてもはや眠くなってきます。

「新入社員なのに寝てるやついないっっっ！？」と思ったら分からなすぎて脳のメモリが溢れてダウンしてる可能性も疑ってあげましょう。もう少しタスクを細かく分解してあげたり、ヒントをあげるだけでまた走り出すことができると思います。想像以上にこういう人いると思います。

自分の経験則上、この「何が分からないかが分からない」に陥る根本的な原因は、何の為に今そのタスクをやってるかが分かってないからだと思っています。

ゴールが分かってない状況で、よく分からない整備もまともにされてない道を走るのってだいぶ怖いと思うんですよね。脳がアラートをだして眠くさせる成分を分泌させたくなる気持ちもわかります。

ってことで、何が分からないかが分からない状況に陥って困ってる人へ、次の一手は、タスクをお願いしてきた先輩にこう聞いて見ましょう。

「これってなんのためにやってるんでしたっけ？」

自分の武器を見つけて、全能感に浸る２年目

ちょっとでも残業すると財布の紐が緩くなり、すぐに家の近くのすき家に駆け込んでしまう２年目の春。1年目と比べて自分は今何をやってるのか、何の為にやってるのかが分かってくるようになりました。

プロジェクトとしては、引き続きテストを行いながら、「もっとこうした方がいいんじゃない？」とか、「こういう場合ってどうするか決まってなくない？」みたいに、より設計・構築したものをより良いものに改修していく時期となりました。

そんなこんなで、１年も経つと少し自分の業務の身の回りの技術であるAWSの知識が身に付いてきました。

それでも自分の業務の分野から一歩外にでるだけで、未開の海が広がっており、自分の無知さに幾度となく平伏す、そんな時期でもありました。

この辺りから、全部知ることは不可能だし、最強に見えてたつよつよエンジニアと呼ばれる人たちにも知らないことはあって当然なんだと気づいてきます。同時に、ある分野では一番自分が詳しい状況ってのも生まれてきて徐々に自分もプロジェクト内で必要な人間なんだと気づき始めて自信がついてきます。

エンジニアとしてのアイデンティティーが確立されていく一方で、自分の武器は技術的な専門知識ではなく、業務知識の豊富さだと気づいていきました。

ここでいう業務知識とはどのプロジェクトでも通用する汎用的な知識ではなく、参画しているプロジェクト特有の知識を指します。

例えば、「この設計になった背景には前の会議で〇〇にする方針になったから」だったり「〇〇さんに技術的な説明をするときに、公式ドキュメントをソースとしたエビデンスを出しながら説明すると安心して聞いてくれる」とか「〇〇さんに相談するときは、まず概要をざっくり伝えてから相談しないと、最後まで聞いてもらえない」みたいなある種の処世術みたいなところまで指します。

これも今振り返ってみれば気づいたことではありますが、自分の主たる戦い方はこの業務知識を使った戦い方だったと思います。時に自分とは直線的に関係ない会議を盗み聞いたり、他のプロジェクトメンバー同士のやりとりを見たりして、プロジェクト全体としていまどういう状況なのかをなんとなく把握するような立ち回りをしておりました。

上司から「これやっといて」とタスクを受け取ってそれをこなす日々だと、なんでこんなことやるんだろと不思議に思うことが多々あります。

それに対して、「それは〇〇との会議でこんな質問があったからそれに答えるために検証が必要になった」という経緯を知ってるかどうかでそのタスクに対するモチベーションとタスク終了後の状態のイメージが合致してきます。

自分は技術的知識の獲得以上にこの業務知識の獲得を無意識的に集めるようにしていました。そうなると、自然に「なんでこの検証必要なんだっけ？」とか「なんでこの設定値になったんだっけ？」みたいな質問が自分に集まってくるようになります。そんな質問が集まってくると、なんだか自分がプロジェクトを回しているような全能感が自分の中で芽生え始め、自分がいないとプロジェクトが回らないぐらいの気持ちになってきます。

そうやってプロジェクト内の自分の地位を確立させていくうちに、１年目に抱えていた自分にできるだろうかという不安はなくなり、その分過剰に自信を持つようになっていきました。

この時期がこの３年間の中で、一番よろしくない時期だったと思っています。全能感と自信に溢れていますが、自分自身の実力は素人に毛が生えた程度である、という現実を見て見ぬふりしてました。

そんな状態が数ヶ月続いたある時、突如自分の中で「自分は他のプロジェクトで活躍できるだろうか」という不安が増していきました。自分が身につけた業務知識は、非常にクローズドな知識で汎用性がなく、一過性なものが多かったのです。

驕りから始まる怠慢によって、技術的な進歩も感じられなくなった自分に対して悩みを抱えてた時にAWSで社会人歴3年未満の人が対象の表彰プログラムがあることを知りました。

当時見たブログ記事

2024 Japan AWS Jr. Champions クライテリアと申し込みサイトのお知らせ

自分もこのAWS Jr.Championに応募したいと思い、まずはAWSの資格を全部取ってしまおうと思いました。2023年の11月末から応募を決意し、そこから約４ヶ月間の間に11個のAWS資格をとり、なんやかんやで当初目標にしていたJr.Championと全ての資格を取得した人に表彰されるAll Certificate Engineerになることができました。この勉強期間はすごく充実した期間でした。

2024 Japan AWS Jr. Champions 選出発表後の集合写真（※AWS公式サイトから拝借）

※表彰された時にはたらく人図鑑にも出演しました。その時のインタビュー記事はこちら

ちなみに資格勉強で大事なことは「資格勉強は、やるかやらないか。」です。同じくJr.Championになった後輩の言葉ですが、本当にその通りだなと今でも思ってます。自分には資格なんて難しくてできそうにないな。。。なんて気持ちはとっととゴミ箱に入れましょう。

ということで２年目を総括すると、業務知識を身につけて全知全能になる→調子に乗る→引き締め直して表彰って感じで、振り返ると自分ととにかく戦った１年でした

個人的にどの業界においても、2年目は1年目に比べると自分のできることが格段に増えたことによって、色々勘違いしやすい時期だと思ってます。

どきっとした人もいるんじゃないでしょうか。

リーダーとしてチームを率いながら葛藤する３年目

資格勉強を理由に１年ぶり２度目のチョコザップを解約した３年目の春。これまでの活動が評価されたのかチームリーダーに任命されることになりました。

業務内容は、これまでのAWSを扱ったインフラ業務ではなく、お客さんとやりとりしたり、品質管理を担うPMOに近いもので、エンジニアというよりはビジネスパーソンとしての力が求められる業務に変わりました。

業務内容の変更に伴い、お客さんと直接やりとりする機会が格段に増えました。時にはお客さんと上司との意見が対立したときの仲介役として絵に描いたような板挟みに遭ったりしました。両側から差し迫ってくる壁を必死に両腕で押さえる日々で、心なしかこの時期から筋トレしてないのに腕の筋肉が増えた気がしています(?)

また、社外とのやりとりだけではなく、チームリーダーとしてチームメンバーのマネジメント業務もありました。チームメンバーは入れ替わりが多少発生したものの4〜5人で、仕切りたがりな自分にとってはありがたい抜擢でした。

ただ、それと同時に悩みはこれまで抱えていたものとは全然種類が異なるようになり、2年目までは自分との戦いって感じだったのが、3年目からは悩みに他者が付きまとうチームを抱える人ならではの悩みが増えた気がします。

当時の悩みを思いつく限り並べてみるとこんな感じです。

自分自身が抱えるタスクとチームのマネジメント業務の比率はどれくらいがベストか
チームメンバーのモチベーションを保つにはどうすればいいか
チームメンバーとの適切な距離感はどのぐらいか
チームメンバーにどのぐらい任せるのがよいか
チームメンバーが自発的に業務に向かうようにするにはできることはなにか
お客さんと上司の意見が対立したときにどうすればよいか
能動的に動いてくれるチームメンバーとそうでないメンバーへの接し方は変えるべきか、同じにすべきか
自分より能力が高い後輩へはどう接したらよいか

etc…

などなど、増えては忘れてといろんな想いが頭を巡ってたと思います。すべての悩みに対して真摯に向き合えたとは思えませんし、どれも明確な正解がない悩みだとは思ってますし、今後もこういう悩みは減らないのではないかと思ってます。

でも「チームメンバーにどのぐらい任せるのがよいか」については、割と自分の中で答えを見つけた気がしてます。

それは、「一旦任せてみる」です。

元々自分自身マネジメント業務のみを行いタスクは人にお願いするというやり方があまり好みではないので、自分も同じようにタスクも行う、いわばプレイングマネージャー的な立ち回りをしたがるのですが、そのせいで自分自身のタスクを抱え込みすぎてマネジメントがないがしろになり、思い通りに進まず悩んでいた時期がありました。

結論導き出した答えが「自分じゃないとできないと思ってたことをメンバーに一旦任せてみる」

当時自分が決意を決めるきっかけになった2つの書籍があるので参考にしてみてください。

ここで大事なのが、いざという時は見捨てないことです。時に自分も怪我をするのが完全に見えてる状況でも決死な覚悟で飛び込ばないといけない時がやってきます。メンバーが「助けて」と目でSOSを出した時、足がすくみます。膝がガタガタ震えます。それでも行かないといけない時がきます。

偉そうに言ってますが、何回も飛び込まなかったことが自分もあります笑

「こういうことも経験しないと成長しないから…」と必死に頭で言い訳しながらその時が終わるのを待ちます。

メンバーよ、その節はごめんよ

ということで自分で何もかも背負わず、仲間に任せるというのはすごくおすすめですが、放っておきすぎるのはよくないし、とはいえ過干渉するとメンバーのためにもならないし、、、絶妙なラインを見つけるのが難しいなと思う今日この頃です。

将来の自分よ、答えは見つけたかい？