※ ポエム記事なので、全て私個人の主観です🙏

概要と結論

今回の記事の内容は、要約すると以下です。

Q.「エンジニアの成長に一番必要な要素って何でしょうか？」
A.「エラーを解消すること」です。それが全てだといっても過言ではありません。

エラーは嫌ですよね。特に初心者は 大量のエラーメッセージ を見るとアレルギー的に避けてしまいますよね。わかります。「でも、エラーに立ち向かえ！それが必要なんだ！」 という理由をまとめた記事です。

対象者

IT エンジニア初心者の方
IT エンジニア初心者に質問などをよくされる方

前提

「解消」と「解決」は厳密には異なるのですが、ここでは一旦、同様の意味として記載します。予めご了承ください🙏

定義すべきこと

前提として、❶「ここで言う "成長" って何？」と ❷「そもそも何のために成長するんだっけ」の二点を明確にしておきます。

そのために、以下について順に考えていきます。

成長には向かうべきゴールが必要であり、どのようなゴールを設定すべきかを決める必要がある
ゴールの考え方を決めた上で、自分にとっての「成長」の定義を考える
「成長」の定義を決めたら、「成長した・成長できた」の定義を考える

ゴール設定

エンジニアとして「何のために成長したいか」は、"目的" と "目標" に分割できます。

例えば👇

私は、モバイルアプリが作れるようになりたい！（目的）
そのためには、まず、Flutter でモバイルアプリ開発の手法を身につけ、リリースまでできるようになりたい（目標）

上記のように、「成長したい理由（＝目的）」は人それぞれですが、「成長したと言えるかどうかの具体的な指標（＝目標）」を、一旦のゴールとした方がわかりやすいと思います。

つまり、ここでいう成長のゴール設定は、"目標設定" のことです。

目標に設定すべき水準はどこか

では、どれくらいの目標を最低限に掲げれば良いのかというと、以下の4つ全てを目指せば OK👇

「作れる」を目指す: 作りたいプロダクトが作れるようになること
「応えられる」を目指す: 要求されたものを提供できるようになること
目指すべきレベル（＝最低限の水準）: せめて自分が一人称できるようになること（他人に教えられるレベルまでは求めない）
考慮すべき対象範囲: 「今、関わっている業務」「今、作っているもの」において上記が達成できること

※ 「作れる」「応えられる」の程度は自分が今思うレベルで一旦、大丈夫です。絶対的な定義がないので、やりながら調整すれば OK

つまり、具体例で表現すると、
これからプログラミング覚える人なら 「自分で Web サイト立ち上げてネット上に公開して、スマホとかから閲覧できるまで作れる」（Web系）などが該当しますし、
実際にどこかの開発案件の現場にいる人なら 「"この機能作って"と言われたら、一人で実装して、テスト含めて完了できる」 などが、【目指すべき目標設定の水準】に該当します。

「成長」の定義

この記事でいう "成長 is 何？" とは以下👇

成長 Lv.1: 知らなかったことを、知ること（知識の獲得）
成長 Lv.2: わからなかったことが、わかるようになること（理解する）
成長 Lv.3: 出来なかったことが、出来るようになること（再現可能になる）

一言で成長とは何かを説明するのはわかりにくいので、
設定した目標に向かって、段階的にステップアップすることを指します。

「成長した」の定義

では、「成長した」という評価・判断はどうやってするのでしょうか。

　『こなせるタスク量』？
　『扱える言語やツールの幅』？
　『フレームワークへの深い知識』？
　『コーディングの正確さやスピード』？
　『話し方や醸し出すオーラ』？

いいえ、違います。ずばり👇

今、関わっている業務範囲内で、成長 Lv.3（出来なかったことが、出来るようになること）の数 が増えることです。Lv.3 に到達するまでは「成長している最中」だと言えます。

つまり、成長したいなら「成長 Lv.3」をゴールまで積み上げる

「成長する」という抽象度が高い表現を、ここでは 「成長 Lv.3 の数を増やし、設定したゴールに到達すること」 と定義します。

例 1） モバイルアプリ開発なら、環境構築〜アプリのリリースができるまでの成長 Lv.3 ができれば「成長した」と言えると思います
例 2） 現在、参画している案件が Java/Spring 案件なら、その現場で求められる業務や開発知識の成長 Lv.3 が増えれば「成長した」を言えるし評価もされるはずです
例 3） プログラミングを覚えるために Web アプリ開発を目標にした初心者なら、概念理解・環境構築〜画面表示〜Webサーバに公開して外部デバイスから表示確認できる、くらいまでできたら「成長した」と言えます

最初の二点に戻って、改めてまとめると以下です👇

❶「ここで言う "成長" って何？」
- 設定した目標に向かって段階的に達成していくこと
- 達成した目標を増やし、自分ができることを増やす
❷「そもそも何のために成長するんだっけ」
- 目的に近づくため、いずれは目的を達成するため
- そのために、抽象的な「目標」を、具体的な「目標設定」にブレイクダウンする

「エラーを解消すること」こそが最も成長に必要な理由

成長する理由が「エラー解決能力」に帰結すると言えるから

あらゆる「エンジニアとして成長するには？」の質問の根っこにコレが共通するからです。
かつ、「エラー解決能力」より更に分解すると細か過ぎるため、この要素にまとめることが最も丁度良いと思うからです。

どうすれば成長するか？の回答例

（こじつけっぽくなりますが）

「実際に作ってみることが一番です」
👉 実際に作れば、理解度が上がるからですが、その意図の中には「エラー発生と試行錯誤」が実践経験に期待されることが多いと思います。つまり、エラー解決能力の話に帰結できます
「詳しい先輩に教えてもらうのが一番です」
👉 成長のためにという話題からなら、この "教えてもらう" は「同じことが起きても対処できるようになる＝エラーが解決できるようになる」に繋げるためです
「常に新しい挑戦を続けることが一番です」
👉 新しくないこと（＝同じこと）を繰り返すとエラーが発生しないので、適応力がつかないからです。つまり、エラー解決能力が成長しないことを意味します
「スパルタ（厳しい）環境に飛び込むのが一番です」
👉 これはそのまんま「エラー解決能力の向上」をするからです
「人に教えるのが一番成長します」
👉 これは、教える対象者が想定外の行動やエラーを起こすことが期待する体験に含まれます。つまりこれも、エラー解決能力の向上が期待値に含まれています
「いろんな事例をたくさん知るのが一番成長します」
👉 つまり「こういう場面ではこう言う方法があるのか」をたくさん知れると言うことです。これは、エラー解決能力の向上そのままです
「自分の書いたものをレビューしてもらうことが一番成長します」
👉 これは、一見エラーではなく「より良い書き方」を指摘されているのでエラー解決には直結しません。しかし、「なぜより良い書き方」を指摘するのかというと、それによって引き起こされるエラーやトラブルが過去にあったか、想定されるエラーやトラブルがあるからです。つまり、これも帰結します

※ これらは意見なので、これ以外の事例の中には帰結しないものもあるとは思います。

エラー解決ができないと「成長した」とは言えない

成長するからには「成長した」を目指すべきです。「成長した」の具体例と、目指すべき理由を以下に述べます。

※ ただし、「成長しなきゃダメ」「成長中でもダメ」という意味ではありません。

お勉強中の状態は「成長した」とは言わない

「別に実践的なことまでしなくとも、インプットだけでもいいんじゃない？たとえば、資格取得でも成長じゃん」という意見もあるかもしれません。
もちろん問題はありませんが、今回の定義だと、「成長中」 に該当しますが 「成長した」 には該当しないという意図です。

例えば、"Java Gold" の資格を取った後に、「実際に Java で開発したわけじゃないから不安だな」なんて言う人は結構多いです。
これは、実体験が伴わないと、実際に現場で使えるのか、自分の知識が有用なのかに自信が持てないからです。

実際にエラー解消まで含めた体験をした時に、やっと本人が「ワイ、成長したなぁ」と実感するのではないでしょうか。

現場で使えない

例えば、Ruby on Rails や Next.js の公式ドキュメントは、チュートリアルも細かい資料も連携できるツール情報もかなり揃っています。昔では考えられないほどに充実した情報です。
しかし、それらを網羅して読破する人は多くないでしょう。特に初心者はチュートリアルとかしか見ない方が多いと予想します。

では、「チュートリアルを見ながらアプリケーションを作った人」や「会社の研修や YouTube で紹介してた ToDo アプリを作った人」が、現場で使える人か？ というと、これは厳しいのです。

なぜなら、チュートリアルでは "アプリが正常に動く手順" のみを紹介するからです。エラーのパターンなんて無数にあるので、いちいち公式で紹介してキリがないので当然ではあります。

しかし、エンジニアを採用する時は、「現場で発生するエラーに対応ができそうか？」と問われた時に "Yes" と応えらる人が求められます。

エラー解消をした実績が多ければ、「現場でも使えるエンジニア」 である可能性が上がります。だからエンジニアは面談などで、過去のトラブル経験などを聞かれることがよくあります。

例《新人採用の面談やりとり》
採用：「Rails をされてるようですが、具体的にどのようなことされたんですか？」
新人：「ハイ！公式のドキュメント等も参考にして、ToDo管理アプリを作りました！！！」
採用：「・・・」

個人開発の場合

個人開発なら、なおさらエラー解決能力が必須です。単純に「チュートリアルに無いエラーを対応ができるか？」と問われた時に "Yes" でなければ、そもそも開発作業自体が 詰んでしまう からです。

生成AIを活用する場合

今は、生成AIのツールやエージェント等を利用すれば、知識が無くとも、理解度が低くてもプロダクトを生み出すことは、以前に比べて実現しやすくなりました。

しかし、生成AIは常に成長途中で、エラー発生は付きものです。また、生成AIは "責任" を取れません（責任を果たすのは個人・法人となります）ので、「何かあった時に対応できるのか」が非常に重要です。

生成AIは、入り口のハードルをグンと下げてくれる素晴らしい存在ですが、その先・その奥には「人間」相手の様々な課題が待っています。

そのためには、活用する人自身が成長していなければいけませんし、技術進歩が早いものほど、利用者はそれに対応するために、やっぱり成長が必要です。「技術進歩」と「技術理解」は、反比例ではなく比例の関係にあります。

顧客はエンジニアの「解決能力」にお金を払う

マーケティングの世界には、「顧客はドリルが欲しいのではなく、"穴"が欲しいのだ」 という商売の本質を説く有名な例え話がありますが、
エンジニアの世界に置き換えるなら、「顧客は技術力が欲しいのではなく、"動くプロダクト"が欲しいのだ」 といった感じでしょうか。

つまり、エンジニアとして成長し市場価値を上げるなら、あなたに必要なのは、個人開発への挑戦でもなく、メガベンチャーやビッグテックを目指すことでもなく、英語力を上げることでもなく、"エラー解決能力"を上げることだという事です。それさえわかっていれば、アプローチ方法は何でも良いです。

なぜなら、「問題解決をし、その対価でお金をもらう」のが商売の構図であり、エンジニアに仕事を依頼する（＝お金を出す）人は、「エンジニアの問題解決能力にお金を払っている」からです。
資格や肩書き、職務経歴やバックグラウンドは、そのための "参考情報" に過ぎません。

新卒採用やポテンシャル採用等で「お勉強してもいいから、やる気あればいいよ」とか「教育コストかけてもいい」みたいな現場でなければ、採用側はエンジニアとしてその人を採用しません（大人の事情で採用するケースを除く）。
「解決したい問題があって人探してるのに、なんであなたのお勉強のためにこちらがお金を払わなきゃいけないの」とさえ内心思うかもしれません。

また、お金を欲しがるのも、お金を支払うのも、結局は人間です。
生成AIの存在があってもこの事実は変わりませんので、上記の内容は、技術が進歩しても有効な考え方です。

「エラー解決能力」を上げる方法

「成長するチャンス」を見つけ、それに「取るべき行動」をとってください。

成長するチャンス

エラーが発生する機会は成長チャンスです。
自ら起こすアクションで発生することもあれば、外的要因で発生して自分に対処が求められたりするケースもあります。

エラーが発生する機会

新しい技術を採用する、新言語に挑戦する
ローカルで環境構築をする
ソースコードを書く
アプリケーションを実際に起動・動作する
アプリケーションをデプロイする/運用する
サーバやネットワークに想定以上の負荷がかる
自分の作ったアプリに、ユーザが様々なアクションをして予期せぬ動作を引き起こした時
GitHub のリポジトリを公開したら、Issue を発見される
採用技術のバージョンアップをせずに放置する
SNSやネットで発見した新しい技術的な情報を、自分のローカル環境でも再現してみる

具体的なエラー事例

環境構築でエラーが出る
ビルド・コンパイルでエラーが出る
起動しようとしたら動かない
Web ブラウザコンソールで見たらエラーが出てる
画面表示したら 404 とか 502 とか表示される
デプロイしたら他の機能が動かなくなってしまう
動いてたアプリが、ある時突然「落ちてます」「止まってます」って言われる
ローカル環境でやってみたら、ネットで見ていた説明内容の通りにはならない

取るべき行動

つまるところ「エラーに対処する」のが取るべきアクション

エラー対応フロー

エラーを切り分ける（無関係な場所を除外する、関係ある場所を絞る）
エラーに関連するキーワードを特定する
キーワードや事象をもとに、エラーの概要を検索・知る
一般的な事象要因と対策を調べる
わからないことは有識者に相談（オフラインの有識者、オンラインの有識者、AIエージェント）
- ただし、身近な仕事仲間以外には、機密情報は言えないので注意
対処できない場合、できる人に引き継いで任せるが、後で「どう解決したのか」を訊く
解決後、一連の概要を明文化して残す
- 同じことが発生しても対処できるレベルの内容なら OK

成長しないアクション

目の前のエラーを対処をしない
- 「なんかエラーが出ちゃうんですけど」という漠然とした相談
- エラーのキーワードを選定して検索しない
- PC をそっと閉じる
- 白馬の王子が声かけてくれるのを待つ
エラーが発生する機会に出会わないようにする
- 過去の経験と同じ作業しか挑戦しない
- 単純なタスクをとって面倒を避ける
- 自分の関わる業務・技術の隣接領域には触れない

つまり

「自らエラーを作れ」とは言いませんが、既に発生しているエラーがあるならそれは「機会」なので避けてしまうと成長しません。

実際、成長するひとは、「エラーが発生する機会」を自ら作っています。"ネットワークエラーや例外を意図的に起こせ！" という意味ではなく、新言語や新技術に挑戦したり、見直しや改善を提案したり、おおよそ課題が発生するであろうチャレンジを継続しているということです。

しかし、柔軟に対応できるようになるので発生頻度は収束するし、レベルも上がっていきます。ノウハウを貯めるようになってくると、自分だけでなく周囲の人間も楽にしてくれますし、現場としての技術対応力が向上します。

個人開発ではない場合、無責任に大きなエラーのリスクを提案するのも主旨とは違うので、まずは現場でできる小さいことから積極的にすくい上げることです。いわゆる 「球拾い」 みたいな小さなことから初めてみてください。現場でも、結構これをちゃんとやってくれる人は貴重です。

結論

世の中には色んな自己啓発や教育的哲学や成長理論があります。

ただ、あなたが IT エンジニアなら、「ひたすらエラーを解消すること」 だけが最もわかりやすい、具体的な成長方法です。

難しい心理学的な知識やコーチングの教えよりも、「どれだけエラーを解消したか」「エラー発生要因と解決策のパターン」の数の蓄積だけ意識すればいいです。

エラー解決力が強いとわかると、周囲の人は勝手に頼りにし、「つよつよエンジニア」だと勝手に評価してくれるでしょう。
そこに謙虚さや腰の低さが合わさると "現場の神" になるかもしれません。

「筋肉が全てを解決する。だから筋トレをしろ」みたいな理論 かもしれません。

ベテランの刑事さん、カリスマ料理人、顧客から信頼絶大な職人さん…。いずれもエラーパターンに強い人たちのことです。
ITエンジニアという職業は、ありがたいことに、「エラーと対策」のパターンが Web 上に大量に蓄積されており、簡単にアクセスでき、しかも多くは再現可能（＝確認可能）です。これほど成長しやすい業界もなんじゃないでしょうか。

世に言われてる、学習方法、成長方法、キャリアパスの考え方はたくさんありますが、「結局、全てはこの１点に帰結しますよ」という "意見" でした。

補足

「開発」とか「構築」は華形の仕事に感じるかもしれませんが、その結果何が起きるのか、どういう対処をすべきなのか、どういう考慮をして改善すべきなのかは「保守・運用」フェーズで初めてわかります。

開発経験しかないエンジニアではなく、運用・保守の経験も積むことをおすすめします。