「アウトプット」「フィードバック」「気づき」とエンジニアの成長
昨年末あたりから、イベントやカンファレンスでの登壇や、採用面接、社内のメンバーへのアドバイスなど、さまざまなシーンで「アウトプット」について話す機会が増えました。自分の考えをどこかにまとめておいた方が、今後も説明しやすいと思い、まとめてみます。
ここに書く内容は、私の経験に基づくものです。もちろん、人によって成長の仕方やタイプは本当に千差万別で、一概に断言できるわけではありません。ただ、私自身が多くのエンジニアを見ている中で「再現性がある」と感じられるパターンであり、ある程度「こうすると成長を加速させやすい」と考えています。
前提として、アウトプットに関しては、過去に「アウトプットの中でも『外部発信』にフォーカスして書いた、以下の記事があります。
上記の記事では、LIFULLの社是である「利他主義」のエンジニア的体現 という技術のコミュニティへの貢献文脈にも触れていますが、今回は成長文脈にフォーカスして書きます。
私が大切だと考えているのは、「アウトプット」し、それに対して「フィードバック」が返ってきて、そこから新たな「気づき」を得る――この3つのステップを回すことです。そのうえで、成長観点で、よく聞かれたりする「自己学習」と「業務」の違いやなどにも触れながら、なぜアウトプットとフィードバックが重要なのか、特に「アウトプット→フィードバック→気づき」という成長のサイクルに焦点を当て掘り下げていきます。
アウトプットの重要性
多くの方は、まず「インプット」に力を入れていると思います。新しいプログラミング言語の文法を覚えたり、生成AIなど新しい技術の論文を読んだり、動画サイトを使って学習してみたり。日々のキャッチアップに追われているのではないでしょうか。インプットは大切です。しかし、インプットした知識は、ただ頭の中にしまい込んでいるだけだと活用しきれません。
成長には、自分が得た知識や試してみた結果を「アウトプット」することが欠かせない考えています。アウトプットの形としては、たとえば以下のようなものがあります。
人に話す
ブログ記事を書く
SNSで学んだことや実践したことを共有する
個人開発プロダクトをリリースしてみる
OSSにPRを送ってみる
社内勉強会やコミュニティでLTをする
所属チームのメンバーにコードを見せる
カンファレンスやミートアップで登壇する
ポイントは「自分の理解や考えを、外の世界（自分以外）に向けて“見える化”する」ことです。単に「こういう機能を作りました」という事実を並べるだけでも、まずは立派なアウトプットになります。
特に、学んだことを他者に向けて説明する行為は、自分の理解を深める一番の近道だと感じている方も多いのではないでしょうか。人に教えるときに自分の理解が曖昧だと、思わぬところで説明が詰まる、といった経験は多くの人が持っているでしょう。
そうした「言葉にしようとすると詰まるポイント」が、自分自身を成長させる入口になったりします。
このように、「自分が持っている知識や経験を言語化・可視化する」ことが、成長の原動力になると考えています。
フィードバックが生む学び
アウトプットを行うと、様々な形で「フィードバック」が返ってきます。エンジニアとしての成長を考えるうえで、実はこのフィードバックこそが学びの宝庫だと感じます。ここでは、フィードバックを以下の三つの視点から整理します。
1.自分自身からのフィードバック
前述のように、アウトプットをしようと試みた瞬間に、言葉がうまく出てこず「理解が曖昧だった」「ここは意外と説明が難しいな」と感じた経験はないでしょうか。たとえばプレゼン資料を作成するときや、ブログなどの記事を書くときに「説明の順序が合わない」「論理が飛躍している」と気づくこともよくある話です。
この「自分で気づく曖昧さ」は、頭の中だけで完結しているうちは顕在化しにくいものです。いざ人に伝えようとする段階で「ここがうまく説明できない」と、はっきり認識できるようになります。アウトプットしようとしたからこそ得られる、いわば内面的なフィードバックです。
2.他者からのフィードバック
「フィードバック」と聞くと、多くの方はまずこちらを思い浮かべるかもしれません。たとえば、ブログやSNSに投稿した記事へのコメント、カンファレンスや勉強会の登壇後に受ける質疑応答、ソースコードに対するレビュー、あるいは人事評価や面談でのアドバイスなど、多岐にわたります。
他者の視点や知識は、自分にはない発想をもたらしてくれます。同じテーマを扱っていても、異なる経験や専門性を持つ人から見ると「そこはもっとこうしたほうがいい」というアドバイスが得られるかもしれません。ときには厳しい指摘やコメントが寄せられることもありますが、それも大きな学びのチャンスだと考えています。自分の見落としや想定外の問題点を指摘してもらえるのは、成長への大きな一歩につながりますよね。
3.環境の変化や、時間の経過によって起こった事象から得るもの
行動後の環境変化や時間の経過によって生じるフィードバックです。システムや組織を構築・運用して一定期間が経ったあとに、「あれ、こんなはずではなかったのに……」と気づくことがあるのではないでしょうか。たとえば、次のような事例が挙げられます。
ユーザーが少ないときには問題なく動いたシステムでも、利用ユーザーが増えてくるとデータベースの同時接続などがボトルネックとなって、障害が多発するようになってしまう
システムを長年運用してる中で時間が経つにつれ、機能の重複など増えてのシステム費用が肥大化してしまっていった
システムのアーキテクチャにおいて、8人で開発するには全く問題ないシステムだったが、50人で開発しようとするとオンボーディングで時間がかかりすぎるようなシステムになって統一感がなくなってしまっていった
経年変化による技術的負債（ライブラリのサポート切れなど）などが起こったときに、アップデートしにくいシステム構造になってしまっていた
こうした事象は、当初の設計や運用方針の“選択の結果”が、組織やサービスの成長とともに顕在化したフィードバックと言えます。自分が過去に行った施策が、年月を経てどのような状態になっているのかを観察することは、システム面でも組織面でも、極めて大きな学びにつながっている経験があります。
気づきと行動変化
アウトプットを行い、上記のような視点でフィードバックを得ると、初めて「気づき」が生まれます。たとえば、1年前にリリースしたコードが、別の人に改修され、複雑さによって障害が起きたるかもしれません。そのとき、「あの実装はもっとシンプルにできたかもしれない」「過剰な抽象化が運用を煩雑にしていた」といった反省点を得ることもできます。
「気づき」を得ることで、以前の自分状況では考えきれなかった部分がみえてきます。「気づき」として言語化することで、自分ができていなかったところ、至らなかったところが「埋められる差分」として具体的に見えてきます。つまり、どこが足りていなかったのか、何を改良すべきかに気づくことで、その差分を意識できます。そして、その差分をそれを埋めるための具体的な行動への第一歩になると感じています。
以前、デイビット・コルブの「経験学習」についての触れた記事を書きましたが、まさにそのサイクルですよね。
このように、フィードバックを通じて得られた「気づき」は、反省や振り返りを次の行動に活かすための具体的な改善点に変わり、成長を加速させます。実際には、同じ事象を見ても「改善点を見つけようとする人」と「そのままスルーする人」では、得られる学びに大きな差が生まれます。成長を促進するためには、大小、直接的間接的、様々なフィードバックに感度を上げ
「気づき」を得ることが大切だと考えています。
上記の成長観点での「自己学習」と「業務」の違い
こうした「アウトプット→フィードバック→気づき」の成長サイクルを意識するときに、次に考えたいのは「どのような場で学ぶか」という点です。
よく、自己学習と業務どちらが良いか？などの質問を受けるこ泊まります。
ここでは、個人で知識やスキルを深める「自己学習」と、実際の案件やチーム開発を通して経験を積む「業務」の二つを考えてみます。この二つは同じように学習の機会を提供してくれますが、得られるフィードバックの量や質、そして成長の仕方に違いがあると感じています。
ここで表現する「業務」は「多人数のチームで開発するもの」というものという前提で記載しています。
自分自身からのフィードバック
自己学習
1つめは、自分の頭の中だけで「分かったつもり」になっている部分を、アウトプットの過程で改めて認識する機会です。自己学習では、好きなテーマや新しい技術を自由に選べるため、興味を深掘りしやすい一方、すべてを自分で管理するぶん「いつの間にか理解が曖昧なまま進めてしまう」というリスクがあるかもしれません。
ただ、学習記録やサンプルコードをブログやSNSにまとめるなど、自分の作業プロセスを外に見せる工夫をすれば、曖昧な部分に気づきやすくなります。自分のペースで試行錯誤した内容を振り返るうちに、「ここが自分の弱点だな」と明確に把握できるようになるのも自己学習の強みです。
業務
プロジェクトの要件や納期、品質基準が明確に設定されていることが多いです。仕様を把握しきれていなかったり、要件に合わない実装をしていたりすると、レビューやテストの段階で即座に問題が表面化し、自分自身の認識のズレに気づきやすくなります。
また、「この機能は必要かどうか」「どの程度のパフォーマンスが求められているか」といったビジネス面の要件も明確なため、自分勝手に進められない分だけ、曖昧さが残りにくい点が特徴です。結果的に、自分が理解している部分と不足している部分を早い段階で把握できるのは業務環境ならではのメリットといえます。
他者からのフィードバック
自己学習
個人ブログやSNSを通じて発信する際は、最初は読者が少なかったり、コメントがほとんどつかなかったりすることもあります。それでも、うまくテーマ選びをして注目を集めたり、定期的に発信を続けたりすれば、思わぬ形でフィードバックをもらえる場合があります。さらに、作ったプロダクトが人気になりユーザーが増えたり、OSS活動でコントリビューターとやり取りしたりすると、業務以上に多面的なフィードバックを受けることも可能です。
また、コミュニティや勉強会などで他人のコードレビューやアドバイスを受けることもできますよね。
業務
業務では、チームメンバー・上長・ステークホルダーなど、多方面からレビューや指摘が入る環境が整っていることが一般的です。そこでは単にコードの品質だけでなく、プロジェクト全体の進行やビジネス上の影響など、多角的なフィードバックを受け取ることができます。
さらに、ユーザーからの問い合わせやサポート要望といった、実運用に基づくコメントがダイレクトに届くこともあります。「実際に使ってみたらこういう問題が起こった」「操作性が分かりにくい」といった生の声は、より具体的かつリアリティのあるフィードバックだと感じます。
環境・時間の変化によるフィードバック
自己学習
個人で作ったアプリケーションや学習プロジェクトは、基本的にはユーザー数や共同開発者が少ないことが多く、大規模運用や長期メンテナンスのフェーズを体験しづらい側面があります。ただし、うまくSNSで拡散されたり、特定のニーズを掴んだりすると、想定以上にユーザーが集まるケースもあります。そうした場合、大量トラフィックを捌くためのスケーラビリティや、運用コストを抑えるための自動化など、より実践的な課題と向き合う機会が生まれます。
また、個人開発でもOSS化したプロジェクトが多くの開発者に利用され始めると、バージョンアップや機能追加の要望、バグ報告に追われる日々が続くこともあるでしょう。結果的に長期的なメンテナンスの難しさや、大人数での意思決定プロセスを疑似体験できるなど、環境変化を通じた学習機会を得られる可能性があります。
業務
会社やサービスが急成長している場合、わずか数か月でユーザーが何倍にも増え、開発メンバーも拡大し、組織体制が目まぐるしく変わることがあります。こうしたダイナミックな環境変化は、当初の設計や運用方針がどのような結果をもたらすかを短期間で突きつけてくれるため、学びのインパクトが非常に大きいです。
さらに、サービスが長期にわたって運用されている企業では、レガシーなシステムとの共存や、バージョンアップに追従できないライブラリの扱いなど、経年変化特有の問題が顕在化する場面も多いでしょう。そうした課題をチーム全体で解決していく過程で、スケールする設計や拡張性の担保、組織面での協調がいかに重要かを学ぶことができます。
自己学習では「自分のペースで体系立てて習得する」強みがある一方で、業務では「より厳しく多面的なフィードバックが得られる」メリットがあります。実践的な学習が重要だとはいえ、自分のペースや興味に従って深掘りできる自己学習も、業務にはない自由度の高さが魅力です。成長の加速を狙うなら、自己・他者・環境 の 3つのフィードバックを意識しつつ、自己学習と業務の両輪で経験を積むことが効果的だと考えています。
まとめ：成長のサイクルを意識する
以上のように、「アウトプット→フィードバック→気づき」というサイクルを回しながら、自分自身・他者・行動結果の三方向からフィードバックを得ることが、エンジニアの成長を加速させるポイントだと考えています。
アウトプットによって、自分の理解を明確にし、他者とのコミュニケーションを生む。
フィードバックによって、見落としていた点や新たな発見、思わぬ問題に気づく。
気づきを行動に反映し、さらに実践を積むことで、次のアウトプットの質が上がる。
これらを組み合わせれば、「どこでどう学んで、どうアウトプットし、どんなフィードバックを得て、どう次へつなげるか？」がより明確になりると感じています。
成長の仕方は人それぞれですが、多くのエンジニアを観察していると、意図的にアウトプットの場を作り、フィードバックを受け取り、そこから気づきを得て行動を変えるという人が、結果的に大きく成長しているように感じています。自分の中だけで完結する学習も価値がありますが、他者や環境からのフィードバックを取り込んでこそ、「使える知識」へと深化していくのではないでしょうか。
たとえば小さな一歩として、Pull Requestの説明を少し詳しく書く、社内チャットに学んだことをまとめて投稿してみる、短いブログ記事やドキュメントに整理して公開する、といった行動を習慣化するだけでも良いと思います。自分で試してみたことを他人に教えているうちに、今までぼんやりとしていた概念がクリアになってくる。
エンジニアという仕事は日進月歩ですが、そのぶん常に学び続けられる「面白さ」や「やりがい」も大きいと感じています。ぜひ「アウトプット→フィードバック→気づき」を意識しながら、自分なりの成長ルートを築いていくことが大事だなと改めて思っています。
長文にお付き合いいただきありがとうございました。