若手エンジニアはベテランと比べて経験はもちろん知識も不足していることが多いと思います。

「Github Actionsに新しいワークフローを定義したいんだけどどうやるんだろう」とか、「新しくLambdaを立ち上げてWebhook経由で実行させるにはどうすればいいんだろう」とか、「このロジックってどのクラスに書くのがベストプラクティスなんだろう？」とか、「ここの仕様ってどうなってるんだろう？」とか。

また、「あー、これ以前やったことあるのに忘れちゃってるなぁ。」みたいなものってめちゃくちゃありますよね。

そういう時に私たちは実現する方法を検索します。特に若手エンジニアの場合はこの方法を調べるという時間が結構多いのではないでしょうか？

この調べるという時間がタスク完遂（アウトプット）までにかかる時間を延ばしています。つまり若手エンジニアの生産性を下げている原因の一つとして「経験や知識が不足していること」があります。

個人的な感覚では、若手エンジニアの生産性低下の原因の一つでは飽き足らず、大部分の原因がここにあるのではないかと思います。特に「以前もやったことあるのに覚えていなくてまたゼロから調べ直す」みたいな状態には注意が必要です。方法論だけその場しのぎでキャッチアップして、次回もまた調べればいいやというマインドの人は尋常ではないくらい生産性が下がっていると思います。（過去の自分がそうでした。）

また、方法を調べる時間に労力を持っていかれるとクリティカルな部分に意思決定リソースを割く前に疲れてしまいます。さらに、知らないことに着手する時は腰が重たくなるのでそれはそれで生産性を下げてきます。

若手エンジニアが生産性を高めるためにやるべきただ一つのことは「理解すること」である

若手エンジニアの生産性を下げている大きな原因が、経験・知識不足だと仮定してもう少し分解してみる。

自分が持っている情報が少ない場合に、タスク完遂するために調べなければならないことが増える。さらに「自分が持っている情報」をもう少し分解して、生産性が高い順に並べてみる。

この整理で考えると、生産性を高めるには「自分が理解している情報」をいかに増やすかが大事である。理解すれば定着する。定着すれば調べなくて良い。万が一足りない情報があっても調べる検討がつく。そして、知識とは複利で増える。

理解とは何であるか？

IT業界でよく聞く「理解とは構造化である」という説明は、主に認知科学的・情報処理的な観点から理解という現象を説明したものだ。ただ、この説明だけでは「理解したという状態に遷移したかどうか」という判断に揺れがある。

人によっては「動くものが作れた」=「完全に理解した」という判定をしてしまう。まだダニング・クルーガー効果の絶望の谷に落ちて「全然わからん」というFatalエラーを吐いてくれたほうがマシだ。

「理解とは何か？」を理解していない状態では、「理解すること」に適切なリソース配分ができなくなってしまう。

この問題を解決するために、ここでは「理解」を「相対的な理解」と「絶対的な理解」の2軸で捉え、かつ具体的なレベルまで掘り下げて整理をしてみた。

「理解にかける時間」が現実的に適切な配分になるような整理になっていれば幸いです。

相対的な理解 ーー 境界を明確に説明できること

一般的に境界を理解しにいくとしたらよくやるのは、「類似する概念や仕組みの境界を明確化すること」だ。例えば「webhookとAPIの違い」だったり、「APIリクエストのうち非同期処理を使う部分と普通にWebhookで実装する部分はどういう違いがあるのか？クライアントから見たら同期処理ではないし、その処理のレスポンスも帰ってこないから、境界はどこにあるんだろう？用途かな？とか」だ。

エンジニアであるならば全体のシステムに対して、サブシステムがどのように協調し合って機能しているかといった、コンポーネントやレイヤごとの役割の境界を明確にすることも相対的な理解と言えるだろう。

OSI参照モデルのレイヤごとの役割の違いだったり、MVCのレイヤごとの責務の違いだったり、クライアントサイドとサーバサイドの役割の違いだったり。

こんな感じでシステムを構成する要素の境界を説明できることが相対的な理解だと考える。システムは境界にこそ複雑さに溢れている。

絶対的な理解 ーー 頭の中にマインドマップを描くこと

境界を明確に説明するというのは「相対的に理解すること」と定義した。一方で絶対的に理解するというのは「頭の中にマインドマップを描く」と定義する。そして絶対的な理解の状態を例を挙げて説明してみる。

こちらはマインドマップ自動生成AIのMapifyに、「webhookとは何ですか？」と聞いた時に返ってきたものだ。

webhookと聞いた時に、関係がありそうなサブトピックを数個ピックアップでき、それぞれの項目を深掘りできる状態が絶対的に理解した状態と言えるだろう。

例に挙げたマインドマップだとサブトピック（2階層目のノード）としてこのあたりが挙げられていた。

• webhookの基本概念

• webhookの利用例

• webhookの設定方法

• webhookの利点と課題

• webhookの未来

こんな感じである概念や仕組みやワードに対するFAQの解答集みたいなものをセットでイメージつく状態が絶対的な理解だと考える。

ちなみにこの絶対的な理解は情報処理的な観点での理解の説明（理解とは構造化である）に近い。

何を理解すれば良いのか？

「理解」という概念がわかったところで次の疑問は、「若手エンジニアは何を理解していけば生産性が上がるのか？」だ。ここでは大方針を述べてみる。

システムのコンポーネントを理解する

システムコンポーネントと言っても抽象度のレイヤでさまざまな分け方がされる。

一般的なクラウドのインフラレベルでのコンポーネント（ネットワーク、サーバ、ストレージ）なのか、一般的なアプリケーションの構成要素（クライアントサイド、サーバサイド、データベース）なのか、よく議論されるソースコードレベルのアーキテクチャのレイヤ（Model・View・Controllerとか）なのか、コンピュータの構成要素（制御装置、演算装置、主記憶装置、入力装置、出力装置）なのか、具体的なアプリケーションのAWS上のアーキテクチャの構成要素（ECS, NLB, RDS, S3等）なのか。

それぞれのコンポーネントに対して、相対的な理解と絶対的な理解の2軸で理解していくことでタスク完遂に必要な情報収集量が劇的に抑えられるはずだ。理解に時間をかけずに短期的にタスクをこなす日々を続けた人と比べて、中長期のどこかでアウトプットの生産性は逆転するだろう。

また様々な抽象度のシステムコンポーネントを理解していると、システムの挙動を説明する際に抽象度を意識した会話ができるようになったり、抽象度で問題空間や調査空間を切り分けることができるので生産性が上がる。

組織のコンポーネントを理解する

自分や自分が所属するチームのことを会社のミッション達成という目的を持った大きなシステムのコンポーネントだと考えてみる。

自分や自分のチームにどういった役割が与えられていて、どういったリソース（情報）を持っているのか。また、隣接するコンポーネントはどういう役割で（どのメトリクスをどのようにコントロールしていて）、どういったリソースを持っていて、どんなシステム（チーム）と通信していて、どういうインタフェースでリクエストを投げればどんな情報が返ってきうるか。

若手エンジニアにとっては自分ではわからなくても組織の誰かに聞けば一瞬でわかることは多い。組織のコンポーネントを理解して、どのチームの誰にどんなリクエストを投げれば良いかが瞬時に判断できると生産性が上がる。

少し前に出した「タスク完遂に必要な情報収集量」を、拡張したバージョンで考えるとわかりやすい。

こんな感じで自分を取り巻く組織というシステムを把握しておくと、より好ましい形で自己組織化されるし、限定合理性による制約からも解放される。

欲を言えばビジネスのコンポーネントも理解したい

プロダクトの構成要素やそれを届ける仕組みとか、ステークホルダーの関係性（顧客とサービスと会社と株主と社会）とかをいろんな抽象度のレベルで理解してくと、アウトプット = アウトカム = ビジネスインパクトの意思決定ができるようになるのかな。

理解には時間がかかるが、絶対に時間をかけよう

ここまでで説明した大方針を満たすために具体的にどうやっていくかを提案する。

世界一流エンジニアの思考法でも書かれていたが、理解には時間がかかる。だが、理解には時間をかけるだけの価値があるということだ。そして、そのために必要なことは、そのことへの理解と習慣化だ。

時間をかけて理解することを習慣化する

まず、デイリーで振り返る等で、理解ができていないシステムコンポーネントを抽出する仕組みを作る。そしてそのシステムコンポーネントの勉強をする時間を毎日とるようにする。もちろん優先度をつけて勉強をしていくし、時には手を動かしてアウトプットもする。理解できたら次のトピックに取り組む。

これを前提として毎日の時間の使い方を設計する。

ちなみに工学的な観点からの理解で言うと「実現した時」になるので、ITエンジニアとして手を動かすというのはこの観点において必須ということになる。

エンジニアとは、工学（エンジニアリング）に関する専門的な知識やスキルを持った人材のことなので工学的な観点は重要。

勉強の優先度は毎日の内省で決まってくる

内省や振り返りを通じて見えてくるタスククリティカルな勉強トピックの優先度を高くして進めていく。

例えば、自分が担当している領域が主に外部SaaSのインテグレーション部分だとしたら、そのSaaSの仕様や癖、SaaSでできること・できないことの境界を理解するために割く時間は長期とは言わず中期的にpayする（採算がとれる）だろう。

この辺は簡単な次のようなマトリクスを使えば生産性にレバレッジが効く群と効きにくい群に整理できる。

• タスクで接する頻度（多い or 少ない）

• 理解度（よく理解している or 理解していない）

また、土台となる知識をキャッチアップすることについては、理解生産性（理解した内容/理解に費やした時間）に対して効くので、長期戦略を立てるとしたら基礎の勉強に投資する時間も数割は必要だ。

理解するための時間は絶対に業務とは別でとる

業務では生産性が大事だ。時間をかけすぎないアウトプット（レベルによってはアウトカムやビジネスインパクト）が求められる。そのため、業務時間中では「理解に時間をかける」という視点を持ちにくい。

そのため、どうしても方法論だけサッとキャッチアップして実装するという状態になってしまう。これはせっかちな自分の経験則だが、理解にかける時間を最小限にしようとしてしまうと一生理解はできないで終わる。

もっと言えば、その日に見つかった理解が浅いコンポーネントをその日の業務後から就寝までで理解しようとかも思わない方が良い。「理解すること」に対して時間的制約を加えると逆効果になるからだ。

時間的制約を設けずとも、これまでの議論で目指すべき理解の状態が明確になったはずなので、「理解に対して割かれるリソース」は適切にコントロールされるはず。

やるやらじゃなくて、やったほうがいいからやる

ここまで記事を読んだあなたが次に考えることは、この理解に時間をかけるという習慣をやるかやらないかだろう。

大事なのは、意思決定のレイヤをやりたいかやりたくないか（感情）のレイヤではなく、必要かどうか（理性）のレイヤにフォーカスすることだ。

人によっては、「今の自分にとって必要な行動変容リストにこの習慣を加えてどの優先度でやろうか？」を考え始めてしまうだろう。そちらについても「必要かどうか」、「やるなら今日から始める」としてしまおう。

選択の科学で言うと、人は選択肢が少ないほうが決定しやすいので基本的に2進数的に（やる、やらない）考える。何ならやったほうがいいからやるの一択にして脳内リソースは習慣を続けるための環境構築や勉強に費やそう。

やった方がいいからやるという意思決定の助けになるために、若手エンジニアにとって「理解に時間をかけること」は人生において最高レベルで優先度が高いものであると考えている理由を挙げておく。

社会的にも良い ーー 生産性を向上させることが事業活動の継続性に貢献する

企業が社会に良い影響を与え続けるには、事業活動の継続が不可欠だ。そのためには事業資金を集め続ける必要があり、その代表的な方法が「投資」である。投資という形で資金を集め続けるには、継続的な業績の向上が求められる。

その理由は投資家（株主）へのリターン（配当）が、企業の業績向上によって生まれる当期純利益から支払われるからだ。当期純利益を増やしていけば、企業活動継続のための資金が集まりやすくなり、社会により良い影響を与え続けられる。この好循環によって、私たちの生活に必要なものが満たされ、さらに選択肢も増えてきた。

では「当期純利益を生み出す人とは、どんな人なのか？」

簡単に言えば、会社がその個人に投資した資本（人件費）以上の価値を生み出せる人だ。ここで重要なのが「期待アウトプット量」という概念で、これは会社があなたに期待する成果の量であり、それに応じて給与という形で資本が投下される。

実際のアウトプット量の評価は年に数回行われる。そして、その結果に基づいて来期の期待値が調整される。ここで注目したいのは「余剰アウトプット」、つまり実際のアウトプット量から期待アウトプット量を引いた差分だ。この余剰を生み出せるかどうかが、当期純利益への貢献度を測る重要な指標となる。

ところで当期純利益というレベルで生産性を考える場合は、アウトプット（仕事量）の生産性ではなく、ビジネスインパクト（実現付加価値）の生産性を考える必要がある。

だが、若手エンジニアの場合はそこまで考えることは現実的に難しい。大抵の場合は上司が事業インパクトへの影響が大きそうな仕事を割り当ててくれるはずだ。

だから若手エンジニアは与えられたタスクに対するアウトプットを生産性高く出し続けるのが良いだろう。（そうして経験を積み、徐々にビジネスインパクトへの責任も担えるようになっていきたい。）

まとめると、期待アウトプット量以上の成果（余剰）を創出することに価値があり、そしてこの「余剰」を生み出す鍵となるのが「生産性向上への投資」なのだ。

生産性が向上すると、期待アウトプット量が上がり、それに応じて投入される資本（＝年収）も増えていく。これは個人の幸せにもつながる重要な循環だ。つまり、生産性向上への投資は、資本主義社会において各個人が価値観レベルで持っておくべき戦略といえるだろう。

自分的にも良い ーー シンプルに理解は楽しい

わからなすぎて手がつけられない状態がない。未知の領域についても仮説が立てられる。あとはシンプルに基礎というのは積み上がっていくものなので成長が感じられる。

こんな感じで、エンジニアとしての視点を極めると良いメンタルモデル（システム思考や情報学的な視点）ができあがる。そうなるとアナロジー的に世の中のいろんなことが説明できるようになってくる。

どんどん理解が進むし、より大きくて複雑なものをコントロールできるようになってくるので楽しい。

40代でブイブイ言わせるためにやっていき！

20代前半でキャリアの積み上げ方を模索するフェーズは終わったと思う。あとは変わらない習慣を積み重ねていくだけ。

私が憧れるラッパーの呂布カルマのバトルのパンチラインを引用しておきます。