最速でエンジニアとして戦力になるためにやったこと

DWS 2人目の大島です。

今回は、エンジニアとしての力を伸ばすために、自分がやっていること・やってきてよかったな、と感じたことを4つほど棚卸ししてみました。

私自身は、エンジニアとして社内では下から数えたほうがいいくらいにキャリアが浅く、まだまだ学ばせてもらうことばかりです。
ただ、この二年ほどで経験のない中から、AWS, Azure 双方の大規模案件を任せていただき、ありがたいことに、自分で技術的な判断をしたり、人に技術を教える機会も増え、ようやく貢献できるようになってきたなと思っています。

そういった中で周りからキャッチアップのスピードを評価いたただくことも多いため、今回言語化をしてみました。

※当記事は、あくまで一つの見解です。

人を納得させる説明をゴールとする

まず、一つ大事にしていることは、「何のために技術を勉強するのか」という意識です。

月並みも月並みですし、私自身も人から言われるのは好きではないですが、それでも、この意識・目的の部分は結局とても大事です。
仕事で触らざるを得なくなった技術の学習って、自分でとても早いですよね。これは自分が「こういう目的のために必要」だと、最後のアウトプットの形を意識して覚えていることが一つあると思っています。

では、技術を学んでいく上でどこをゴールとして意識したらいいのか？
ここは「人を納得させる説明ができるかどうか」を意識すべきだと思っています。
なぜなら、組織の中でエンジニアとしては働く以上必ず、技術を人に説明する、ということは避けては通れないからです。

エンジニアとして働いている人であれば、当然の感覚ですが、IT業界において設計して作って終わりなんて仕事はありません。
設計して作った技術が、なぜ正しく動作するのか？、なぜ安全であると保証できるのか？、これを説明・担保し、納得してもらわなければなりません。
むしろこの説明が最も大事なポイントと言ってもいいまであります。

当社のような顧客へ技術力を提供することで価値を上げる会社であれば、顧客に対してきっちりと説明する必要があります。
自社でサービスを開発・提供するような会社であっても、技術的決断をする場面で、必ず上司・部下・同僚にその判断がなぜ正しいのかを説明する必要がありますよね。

だからこそ、組織で働くエンジニアである以上、アウトプットの最終系は「人に説明して納得してもらえる」ことです。
相手を納得させることができなければ、どれだけ正しく素晴らしい設計をしようとも無意味です。
普通の人は決断をするときに、自分が納得できる材料がなければ安心できません。
大事な局面で裏取りなしに生成AIの出力を鵜呑みにできないように、人が責任を負う判断にはその人が納得する理由が必要です。

では具体的に「人に納得してもらうための説明」ができるように技術を意識すると、何が嬉しいのか？
それは、技術の学習をするときに頭の中で具体的に質問をしてくる顧客を想定するようになることです。

例えば、Ubuntu のパッケージ管理ツールでにはaptとapt-getの2つがあります。
この2つ、特に差分を意識しなくてもふんわりとした理解で使えてしまいますが、
仮に顧客にコードを納品する場合、「どうしてapt（あるいはapt-get）を選択したのか？」という設計の理由が必要になるケースはあると思います。

もちろん、どちらも大差ないから、という理由で適当に選ぶのもOKではあります。
でもそれが許されるのはきっちりと差を理解した上で、だと思います。
どちらでも大きな差はないが、aptはエンドユーザーに向けたツールで、バージョンによって動作に変更がある可能性がありますが、　apt-getは後方互換性を意識しているためスクリプトではapt-getを使う方がメンテナンスコストを削減しやすい、といった細部まで喋れる方が、自分が顧客であれば安心感がありますよね。※1

こういう細部の積み重ねが最終的に提供できる価値に差を生み出しますし、
また、自分の学習においても知識的に深みを出したり、様々な知識が点と点でつながってより強固な知識を生み出し、他のエンジニアとの差になると思っています。

どうせ覚えるのであれば、より実践で使えるような知識として覚えられる方が得ですから、
「人を納得させられるレベル」を時たま意識してみるといいかもしれません。

技術のストーリーを意識する

技術は基本的に何かの課題を解決するために設計されているものなので、必ずその設計の背景や理由があります。
この理由はなるべく具体的なストーリーで覚えましょう、人間はとにかくストーリーの方が覚えやすいです。（ストーリーは、ユースケースと言い換えても問題ないです）

ストーリーで覚えるというのは、暗記の世界大会などで利用される技術としても最近は有名なくらいですね。
技術を学ぶときもこれと同じで、ただ情報を暗記するだけでなく、背景やストーリーを意識することで、記憶に定着しやすくなります。

例えば、IT初心者に「ローカルインストール」と「グローバルインストール」の違いを説明するとします。単に「ローカルはプロジェクトごと、グローバルはシステム全体」なんて説明しても、ピンとこないかもしれません。具体的な説明を加えてあげると初心者でもぼんやりとイメージがつくようになります。

たとえば、PC上のあるプロジェクトAでoutputというコマンドをインストールして使っているとします。
その中で、別のプロジェクトBで、たまたま同じoutputという名前の全く別のライブラリをインストールしてしまったら、PCはoutputというコマンドの実行を受け付けた時に、どちらのコマンドを実行すれば分かりません。
突然、outputコマンドが動かなくなるかもしれませんし、プロジェクトBでプロジェクトAのoutputコマンドが動いてプログラムをめちゃくちゃにするかもしれません。
こういったトラブルを避けるために、ローカルインストールを使って、プロジェクトごとにoutputというコマンドを特定のプロジェクトの中のスコープだけにとどめることができる、わけです。
このように具体的なストーリーを説明されれば、「なぜローカルインストールをするのか」はIT初学者でも何となく腑に落ちます。

また、技術の具体的なストーリーは人が理解しやすい構造ですから、自分がその技術を他の人に説明するときにも役立ちます。
特に、顧客や同僚に説明する場面では、「なぜこの技術を使うべきなのか」を納得してもらう必要がありますが、ストーリーがあれば、それをそのまま使えるので、アウトプットのハードルがぐっと下がります。

さらに、背景やストーリーを知ることで、技術の間違った使い方を防ぐこともできます。
単なる情報として技術を学習するだけだと、「この技術って、こういう使い方をしてもいいんだろうか」と迷ったり、誤った方向に進んでしまうことがあります。
でも、具体的な背景やストーリーを知ることで、技術の正しい使い方を認識できます。
正しい使い方を理解しておくことで、技術を応用するときに、「この使い方は本当に正しいのか？」という点を意識できます。

たとえば、JWT（JSON Web Token）とセッショントークンの話がいい例でしょう。※2
JWTは、有効期限とデータの署名を持つデータ構造のため、サーバー側で有効期限などをDBで管理する必要がない、自己完結型のトークンです。
つまり、サーバーで管理する必要がない = ステートレスな認証や情報のやり取りに向いているもので、SSO や OAuth などでよく使われる技術です。
SSO や OAuth は、IdP と呼ばれる IDを中央管理する仕組みを用いるわけですが、セッショントークンで管理をしようとすると、毎回様々なシステムがセッションの有効期限の確認のために IdPのサーバーにリクエスト送らなければならないため、膨大なリクエストが飛んできますし、非効率なため、JWT という有効期限をトークン自身が持つ形で作られているわけです。
ただ、検索してみるとそういった事情がない状況で、 JWT をセッショントークンの完全な代替として利用しようとするような誤解がよく見られます。

セッショントークンは、本来ログイン状態や権限をサーバー側が管理するための仕組み（＝ステートフル）です。
しかし、JWT は上記の通り、ステートレスなので、一度発行したらサーバー側で状態をコントロールできません。
たとえば、「強制ログアウトさせたい」と思っても、サーバー側で JWT を無効化する仕組みがないとどうにもなりません。
その結果、失効しないトークンが残ってしまったりして、セキュリティ的に非常に危険な状況を招くことになります。

こうした誤った使い方を避けるには、JWT の使われ方・ステートレスな特性を理解し、その背景やストーリーを知ることが大事です。
ステートレス認証や情報の一時的なやり取りには最適だけど、「セッション管理に使うべきではない」というのが自然とわかるようになります。

このようにストーリーを意識すると、技術の正しい使い方が自然と見えてきます。
一般的なユースケースを理解していれば、応用的な使い方を見たときにしっかりと違和感を感じられるからです。

技術をただの情報として覚えるのではなく、ストーリー・ユースケースを意識して学んでみると、正確な理解につながりますし、最終的なゴールである「人を納得させる説明をする」ことがよりスムーズに行えるようになるでしょう。

インプットの犬にならない

知識がそのままビジネスにおける力に直結しやすいエンジニアにとっては、とりわけインプットは大事です。

ただ、インプットばかりしていても、それだけでは意味がないです。
インプットに取り憑かれてはいけません。
結局、インプットは基礎トレみたいなものです。
スポーツで言えば、筋トレや動きの練習のようなもので、実際の試合とは少し違います。

先ほど話したように、「人に説明する」というスキルは、どこに行っても必ず必要になります。
この「人に説明する」のはまさしく「アウトプット」なわけで、「インプット」とは型が違います。
「インプット」は脳の中に知識をしまい込む作業ですが、引き出して活用する「アウトプット」とは別物です。

「アウトプット」が大事なことは世間でもよく言われることなので、今更という感じがありますが、私が思う問題はなんとなく勉強していると「インプット」だけに傾倒しがちなことです。

インプットをしていると、インプットしかしていないのに「自分は正しく頑張っている」と錯覚してしまいます。
試験勉強に全力を注いで資格を取るとか、本を読んで技術を学ぶとか、確かにそれは価値があるし、必要なことではあります。
でも、それだけに時間を費やしているのが、市場におけるエンジニアとしての価値を伸ばせるのか？というと甚だ疑問です。
どれだけ基礎トレをしても、実践で活躍できるかはまた別の話で、大半のスポーツは筋トレの時間よりも実際に試合に近い練習をする時間が長いのが普通です。
でも、自分の勉強になるとなかなかそれに気づきづらく、インプットに偏りがちです。

いろんなことを幅広くインプットするのは正直楽しいです。
SNSが流行っているのと同じで、新しく簡単に手に入る情報の方がどうしたって人は面白いですから、いろんなインプットをしてしまいがちです。
でも、自分が曖昧な理解しかしていない・触ったことのない分野の知識を少し触ったところで、記憶には残りません。そのインプットを組み込むだけの下地が一切ないからです。
いろんなインプットをしてみるのも大事ですが、それよりも下地を作ることのほうが大事だと思っています。
一度下地を作って仕舞えば、ちょっとしたインプットでも下地となる知識と絡み合って覚えていられるからです。

では、この下地をどうやって作るのか？それがアウトプットだと思っています。
仕事で使ったような知識は、自然と様々な形のアウトプットをしているから強固な記憶となって忘れません。
特に駆け出しのエンジニアであれば、なおさらアウトプットで、様々な知識の下地を広げていくことが大事です。そうでないと、何も頭に残りません。

だから、なるべくアウトプットに時間を割くようにしましょう。
インプットとアウトプットを比較したときに、アウトプットの方が確実にエネルギーが必要です。どうしてもインプットに流れがちです。
だから、自分の中の意識としてアウトプットの比重を増やしましょう。

特に、アウトプットの練習は、できるだけ多くの人の目に触れる形でやるのがベターです。
もちろん、一人でアウトプットするのもありです。自分なりの理解に落とし込んでメモを書いたり、ノートをとるのも立派なアウトプット。
ただ、その場合はどうしても気が緩みがちで、適当に書いてしまうことも多い。

人目に触れるアウトプットは、それなりに時間がかかるので、時間だけを考えるなら個人でやる方が楽で効率は良いのですが、それでも、人に共有するアウトプットには適度なプレッシャーがあります。
人に伝わるように説明しなければならないし、間違いがないように裏どりをすることも必要です。
また、社内などで共有すれば、他の人から意見やフィードバックをもらえるので、正確な知識に仕上がります。
そこから、誰かと会話などに発展すれば、より質の高いアウトプットの練習になります。

最初は他人にアウトプットするハードルは高いと感じる人であれば、スモールスタートを意識して、最初は社内チャットツールなどに情報を無造作に垂れ流す形などでもいいと思います。
少しずつ人の目に自分のアウトプットが触れる、ということに慣れていきましょう。

メモを雑多に共有する → 他の人に意見を求めてみる → 技術メモをパブリックに公開してみる → ブログに書いてみる → 登壇してみる、などのようにステップアップしていくイメージが良いかもしれません。

特に最初はアウトプットの内容を整理するのにも時間がかかりますし、抵抗感もあります。
それでも最終的には、エンジニアとして働くのであれば「人に説明する」というアウトプットが必ず付随します。
早いうちに慣れておいた方がいいですし、普段から本番に近い練習をしている人の方がいいアウトプットを出しやすいのは間違いないでしょう。

人を使い倒す

仕事でも・自己学習の中でもどちらでもですが、技術的にわからないところ・悩んでいるところがあれば、人を使い倒すような気持ちで臨みましょう。

会社に所属することの大きなメリットの一つは、社内のリソースを自由に自分が使えることです。
自分より長くIT経験を積んできた先輩は言わずもがな、同僚や後輩でも自分とは全く異なるIT経験を積んできた人たち、いわば情報の塊です。
しかも、単なる情報の塊ではなく、こちらの意図を正確に汲み取って、適切なアドバイスをくれたり、こちらを積極的に支援してくれる情報の塊です。
圧倒的にスピーディかつホスピタリティのある超高性能AIのようなものです。（もちろん、他人をそういう扱いをしていい、というわけではなくて）

会社にいれば、そのリソースにアクセスできるわけで、他の案件で培われた知識や、自分より長く経験を積んできた人の知恵を直接借りることができるなんて、これ以上の時間節約はありません。
エンジニアで、今の時代に検索エンジンや生成AIを利用してない人はまずいないと思いますが、社内の人を使わないのはそれと同じことです。

さらに、人を使い倒すことが当たり前になれば、単にお悩み相談として会社の人の情報を得るだけではなく、そもそもその情報を自分の能力の一部とできます。
困ったら人に聞けばいいわけで、他の人が持っているケイパビリティを自分のケイパビリティとして言い張れるわけです。
自分ひとりで解決できることなんて限られています。
どんだけ勉強しようが、2人・3人と人を集めたときに持つ知識に勝てません。
だからこそ、周りの力を借りることが鍵になるわけです。

そして、もう一つ人を使うことには大きなメリットがあります。
それが、インタラクティブに会話をするため、強く記憶に残りやすいことです。
人に相談をする時には自分の考えをまず話したりしますから、自分の思考を整理できます。頭の中で「これはこういうことだな」と自然と情報がまとまります。
それに対して、相手から応答（リアクション）が返ってきて、自分の話した内容が間違っていることを認識したりするので、記憶に残ります。
対面での会話であれば、視覚なども総動員ですから、なおさらです。
ただ自分一人で記事を読むよりも圧倒的にタイムパフォーマンスが良いですし、人と会話するほうがシンプルに楽しいですよね。

だからこそ、人に嫌がられるくらい質問してみるべきです。
実際にはほとんどの人は嫌がらないです。むしろ頼られることを嬉しく感じる人が多いはずです。
自分だって、誰かに頼られると「必要とされているな」と感じて嬉しいと感じないでしょうか。
仮に行き過ぎて迷惑をかけてしまったとしても、そのときは相手がちゃんと教えてくれます。そのときに謝って、少し修正すればいいだけの話です。
最初から完璧を目指すよりも、ちょっと失敗しながら修正していく方がずっと効率的なんてことは陳腐化するほど言われていますが、人と人とのコミュニケーションも同じです。
頼るべきときに頼らず、自分ひとりで抱え込む方が、結果として大きなロスになります。

終わりに

長くなりましたが、以下まとめです。

色々と大事だと思ったこと整理して書いてみましたが、
最も大事なことは、単純に他の人より時間を注ぎ込めるか、だと思っています。

特にエンジニアとしてまだ歴の浅い方の参考になれば、と思います。

補足など

※1 apt とapt-getの違いは以下の通りマニュアルに記載があります。

The apt(8) commandline is designed as an end-user tool and it may change behavior between versions. While it tries not to break backward compatibility this is not guaranteed either if a change seems beneficial for interactive use.

All features of apt(8) are available in dedicated APT tools like apt-get(8) and apt-cache(8) as well. apt(8) just changes the default value of some options (see apt.conf(5) and specifically the Binary scope). So you should prefer using these commands (potentially with some additional options enabled) in your scripts as they keep backward compatibility as much as possible.

https://manpages.debian.org/bookworm/apt/apt.8.en.html#SCRIPT_USAGE_AND_DIFFERENCES_FROM_OTHER_APT_TOOLS

※2 JWTがセッショントークンの代替にはならない理由は、こちらの記事がわかりやすいです。
また、JWT でセッショントークンをラップするような使い方はあるようですが、ややこしいので割愛します。

参考

JWTでセッション管理してはいけない

tak