はじめに
いきなりですが、新人エンジニアとして技術力を向上させるため、今年1年はアウトプットを増やす年にしたいと考えています。その際、「質と量のバランス」について少し考えたのでアウトプットしておきたいと思います。
※この記事では、アウトプットとは「Qiitaなどでの技術記事投稿・社内外のLT発表」のことを指します。
この記事は、1年目の新人インフラエンジニアである私が考えたことを整理したものです。読んでいただいているみなさんの状況に合わせて参考にしていただければと思います。特に、同世代（若手）でこれからアウトプットしていこうかなと考えている方の参考になれば幸いです。
本記事の結論
さっそく私の考えを言ってしまいますが、「ひとまず質にとらわれず、いろいろなアウトプットをどんどんしていく」ことがよいと考えています。
そう考える理由について、これから説明していきます。
アウトプットの目的
「どのようにアウトプットするか」を考える前に、「なぜアウトプットするのか」について整理したいと思います。アウトプットの目的は人によって様々あると思いますが、私の場合は以下に挙げる3つをアウトプットの目的とします。
- 理解を深める
- やったことを可視化する
- 学びを習慣化する
それぞれの目的について、具体的に説明します。
理解を深める
よくある話ですが、なにかを学んだり調べたりしてわかった気になっていても、いざ他者に説明しようとすると実はわかっていない・あやふやな部分があると気づくことがあります。アウトプットをすることでそのことに気づくことができ、より深く学ぶことができます。
また、アウトプットするということは、自分の学びや考えを周囲に公開することになります。そのため、「間違っていないか」「本当に理解できているか」を自然と確認する習慣が身につきます。その結果、学びの精度が高まり、より確かな知識として定着させることができます。
やったことを可視化する
アウトプットが、将来の自分への「リファレンス」や「ナレッジベース」になります。一度整理してアウトプットしておけば、同じことに再び悩んだときにもすぐ振り返ることができ、他者と共有することも容易になります。
また、自身がやってきたことを成果として他者に説明する際に、アウトプットがあると具体的な成果物として提示することができます。これにより、「なんか頑張った」ではなく「何をどう頑張った」のかをわかりやすく伝えることができます。
さらに、やってきたことが明確になっていると、次にどんなことに挑戦しようかというステップも見えるようになります。特に、私は新卒ということもあり、まだまだ自身の軸となる技術をしっかり決めることができておらず、興味関心のあること（生成AI関連・AWS）に手当たり次第に取り組むことが多いです。その際、定期的にアウトプットをしていると、今までやってきたことを整理しやすく、これから先、何に挑戦するのかを考えやすくなると感じます。
学びを習慣化する
定期的なアウトプットを意識することで、「学ぶ → 整理する → 書く・話す」というサイクルができ、学びが自己完結しません。
また、習慣化することで情報志向性が高くなると感じます。「何かネタになる情報ないか？」「この情報は学びに繋がるかも？」といった具合で自然に情報をキャッチしようとする意識が高まるということです。言い換えると「自分事として情報と向き合うことができるようになる」ということです。これはとても大事なことで、自分事として捉えられるかどうかで得られる情報の質は大きく異なると断言できます。
（余談ですが、大学院時代はこの観点が不足していて、どんな論文を読んでも「いまいちピンとこない…」という状態が続いていました。恥ずかしながら、自分事として考えることの大切さに気付くまでとても長い時間がかかってしまいました。みなさんは反面教師にしてください。）
アウトプットの目的のまとめ
長々と書いてしまいましたが、再度私のアウトプットの目的を以下に示します。
- 理解を深める
- やったことを可視化する
- 学びを習慣化する
一言でいうと、「自身の理解を深め、学びを習慣化しながら、その記録を見える形で残していく」ことが目的です。
ここから本題の アウトプットの「量」と「質」 についてお話していきたいと思います。
「量」を重視するメリット
私は、「量」を重視することで以下のようなメリットがあると考えます。
- アウトプットに対する心理的ハードルが下がる
- アウトプットのスタイルが身につく
- インプットとアウトプットのサイクルが高速化する
それぞれについて、簡単に説明していきたいと思います。
アウトプットに対する心理的ハードルが下がる
初めてアウトプットする時は、「こんなことを書いてもいいのかな」と不安になり、なかなか行動に移せません。しかし、アウトプットを繰り返していくうちに、「小さな気づきでも誰かの役に立つかもしれない」と思えるようになり、発信に対する抵抗感が薄れていきます。このような感覚を持てるようになることが重要だと感じます。
アウトプットのスタイルが身につく
何度もアウトプットを繰り返していると、「こういう構成だと伝わりやすい」「この説明だと読みにくい」ということが少しずつ感覚的にわかってきます。最初はまとまりが悪くても、回数を重ねることで「自分なりの表現」「自分なりのテンプレ」ができてきます。これは1回の完璧なアウトプットではなかなか手に入りません。たくさんアウトプットするからこそ身につくスキルであると感じます。
インプットとアウトプットのサイクルが高速化する
量を重視してアウトプットを続けていると、インプットもそれに合わせて自然と増えていきます。「発信するために学ぶ」「アウトプットのために情報を集める」というサイクルが回るので、インプットとアウトプットの両方が活性化します。結果として、学ぶスピードや理解の深さもどんどん早くなっていくように感じます。最初はサイクルの流れがゆっくりでも、経験を積むうちにどんどん早くなると感じます。
以上のようなメリットから、まずはアウトプットの「量」を重視するのがよいと考えます。
「質」の観点について
一方で、量だけを追求することは望ましくありません。「質」を軽視しすぎると以下のような問題があります。
-
誤った情報の拡散リスク
- 検証不足のまま情報を発信すると、誤った知識を広めてしまう
-
表面的な理解に留まる危険性
- 深く掘り下げずに次々と記事を書くと、知識が浅いままになってしまう
実際にどんなアウトプットをしていくのか
ここまでいろいろ書いてきましたが、実際にどのようにアウトプットしていくのか、具体的に説明します。業務で使う機会があり、個人的に興味関心があるAWSを例に説明します。
1. 何か動くものを作ってみる
現在私は、AWSのサービスを組み合わせたシステム構築に取り組んでいます。
例えば、LambdaやDynamoDB、S3、EventBridge、Bedrockなどのサービスを組み合わせた「ニュースレコメンドシステム」を試作中です。以下の画像が仮の構成図です。
こういった取り組みは、「とにかく手を動かして試す → 気づきやハマりどころを記録する → アウトプットする」という流れを意識しています。
2. まずは各サービスの理解を深める
ある程度システムが動く形になったら、まずは個別のAWSサービスごとに記事を書くつもりです。（技術的難易度：Lv.200程度のイメージ）
- S3にデータをアップロードするLambdaの実装例
- EventBridgeとLambdaで定期実行のトリガーを設定する方法
- DynamoDB（NoSQL DB）設計のポイント
といった具合に、サービス単位で手を動かして学んだこと・詰まったこと・調べて理解したことをまとめていければと思っています。この時点では、「網羅的に説明しよう」とするのではなく、「今回のケースではどのようにサービスを取り扱ったのか」をまずは残したいと思います。
3. 全体の構成やアーキテクチャについて整理
個別のサービスについて一通り記事を書き終えたら、最後に「なぜこの構成にしたのか」「どんなシステムアーキテクチャを組んだのか」をまとめることができればと思います。（技術的難易度：Lv.200~300程度のイメージ）
例えば以下のようなことが考えられます。
- なぜデータ保存先をS3とDynamoDBに分けたのか
- なぜLambdaを使って実装したのか（EC2やFargateではなく？）
- 今回の要件に対してどこを重視して構成を考えたのか
- サーバーレスにすることで得られたメリットと課題は何だったか
まとめ
以上のように、
- 個々のサービスに対して「手を動かして詰まったこと・解決したこと」を整理する
- その後に全体の設計思想やアーキテクチャをまとめる
という流れにしています。
このような段階を踏むことで以下のようなメリットがあると考えています。
- 個々の記事を書いていく中で、全体像が自然と整理される
- 最後に全体のまとめ記事を書くことで、振り返りや反省点も含めた「自身の体系的なナレッジ」を作ることができる
おわりに
今回は、アウトプットの「質と量のバランス」という観点からいろいろ整理してみました。私の結論としては、まずは「量」を重視し、心理的ハードルを下げながらアウトプットを習慣化していくことが重要だと考えています。しかし、そこには 「質」を高める意識も徐々に取り入れていくことが大切です。具体的な実践として、以下のようなステップを踏んでいきたいと思います。
- 手を動かして小さな成果物を作る
- 個別の技術要素ごとに学びや気づきをまとめる
- 全体の設計思想やアーキテクチャについて振り返る
このような段階的なアプローチを通じて、アウトプットをしつつ、徐々に深い考察ができるようになればと思います。今回、アウトプットは他者のためというよりは、自身の成長のために実施しています。「これくらいのことを書いて良いのだろうか」と悩むよりも、どんどん行動していきたいと思います。
最後に、この記事自体も私のアウトプット実践の一環です。拙い部分も多々あると思いますが、これからも継続的にアウトプットしていきたいと思います。
ありがとうございました。
（おまけ）ブログの技術的難易度について
AWSの技術ブログには、難易度の目安が明記されており、Top Engineersクライテリアページでは以下の4つのレベルがあることが説明されています。
- Level 100 : AWS サービスの概要を解説するレベル
- Level 200 : トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル
- Level 300 : 対象のトピックの詳細を解説するレベル
- Level 400 : 複数のサービス、アーキテクチャによる実装でテクノロジーがどのように機能するかを解説するレベル
これらのレベル感については、以下の記事でわかりやすく説明されているので紹介いたします。