最初のプロジェクトで、コードレビューで指摘された内容をすべて修正し終えた後、ふいに気が付いた。「自分、本当にエンジニアなの？」と問うた自分の声が、いつも通りの軽快さではなく、いやだよねというトンチのない不安に覆われていたのだった。それから数年、同じようなシーンが何度かあった。新しい技術を学ぶときの不安、他人のコードを読むのに苦手さ、プルリクエストを送る前のドキドキ感。そんな中で、だんだんと変わった気付きがあった。「自分はただの素人ではないのかもしれない」「学ぶ姿勢自体が正しいのではないか」という気持ちになるまで、いろいろなマインドセットを意識してきた。今ではその時の自分に返してやりたい、「成長するための正しい考え方」を、同じように悩むかもしれないあなたに伝えたい。
1. 「わからないことは必ずしも自分の失敗ではない」という視角
最初の印象として、多くの駆け出しエンジニアは「わからないことを訊くのは恥ずかしい」と感じるのではないだろうか。自分が新米のとき、フレームワークの基本的な設定で詰まったまま、数時間費やしてしまった経験がある。Stack Overflow を見回ったり、Google 検索をかけまわしたが、自分の状況と合致する回答が見つからず、ますます不安が深まった。
ある日、そんな状況で属人の先輩に助けを求めたとき、彼は冷 calm に言った。「わからないことを調べるのはエンジニアの仕事だ。自分が素人だというのを認めるのは、むしろ賢いことだ」。その言葉は自身の中で大きなシフトを引き起こした。
その後、自分は「わからないことを訊く」ことを、「自分の知識を広げる活動」として捉えるようになった。質問をする前には、少なくとも 30 分はネットで調べる習慣をつけた。見つからなければ、後で調べるノートをつける。そうすると、質問する回数は少し減ったが、確実に解決できるまで続けられるようになった。
特に覚えているのは、あるプロジェクトで非同期処理のロジックにつまずいたときのこと。当時は「コールバック地獄」と呼ばれる構造に頻繁に出くわい、自分の書いたコードはエラー処理がまったくできていなかった。同僚に相談したとき、「コールバックよりも Promise を使った方が、エラーのハンドリングもしやすいよね」とアドバイスしてもらった。その後、Promise の概念を学ぶまでに、公式ドキュメントや YouTube のチュートリアルを 5 つ以上消費した。
結果として、単に「直す」ことだけでなく、「なぜその方法が良いのか」を理解することができた。それから数ヶ月後、同僚から「成長しましたね」と褒めてもらえたのは、間違いなくその学習の成果だった。
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
スイカゲームとにゃんこ大戦争のようなタワーディフェンス系ゲームを組み合わせたゲームを作成しました！
遊んでみていただけると嬉しいです🙇♂️
ハジメル.dev: https://hajimeru-dev.vercel.app/
「ひとりで続けるのは難しい」「何から学べばいいか分からない」という方向けに、
プログラミングのマンツーマンレッスンサービス「ハジメル.dev」も運営しています。
未経験OK・オンライン完結・月額制/違約金なしなので、気軽に無料相談してみてください🙇♂️
海外テックニュースを追いたいけど、英語や情報量の多さで大変…という方向けに、
Hacker News の話題を日本語でサクッと追える「HackerNews 日本語まとめ & AI要約」
を個人開発しました！
技術トレンド収集に使ってもらえると嬉しいです🔥🙇♂️
→ HackerNews 日本語まとめ & AI要約: https://hn-matome-2ht.pages.dev/
「ニャンパイアサバイバー」というヴァンパイアサバイバーリスペクトのゲームを作成しました！
もしよろしければ遊んで頂けると嬉しいです😭
習い事教室の先生向けに、SNS 投稿・生徒募集・保護者通知の文章を AI で生成する Web サービス「おしらせAI」を個人開発しました。Next.js + Supabase + LLM で構成しており、無料で月 10 回まで試用できます。よければ触ってみてください。
→ おしらせAI: https://oshirase-ai.vercel.app/
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
2. 「質問をする」ことが、チームの負荷を減らすことだと知る
質問をするのが恥ずかしくて、わざわざ独力で問題を解決しようとして、チーム全体のスピードを遅らせてしまうことがあった。あるメンバーが言っていたのは、「一人で悩んでいる間に、他の人がすでに解決していた問題があるかもしれない」ということ。
実際の話をすると、ある週、フロントエンドのバグを修正しようとして数日間を費やしたことがある。自分の環境では再現しないバグがあり、デバッグにも失敗してしまった。最終的にたどり着いたのは、「ブラウザのキャッシュが原因」という、非常にシンプルな原因だった。それまで自分はその可能性を消去できていなかった。
その後、チームの定期ミーティングで、「質問のベストプラクティス」について話した。具体的には、次の 3 つのポイントを意識するようにした。
- 質問する前に、少なくとも 30 分は独力で調べる
- 質問する際には、「試したこと」と「期待する結果」を明確にする
- 質問後は、その回答をチーム全体に共有する
これらのルールを導入してから、チーム内の Slack でのやり取りがはるかにスムーズになった。例えば、あるメンバーが CSS のグリッドレイアウトで困っていたとき、彼は「以下の 2 つのサイトを参考にしているが、なぜか IE で表示が崩れる」という形で質問した。すると、別のメンバーが「IE ではグリッドの書き方が異なる」という即答を提供した。
このように、適切に質問することは、たんに自分の問題を解決するだけでなく、チーム全体の知識を共有する手助けにもなる。最近は、質問をした後に「解決策」をまとめてチームの Wiki に書き残す習慣もつけている。
3. 「小さな成功を積み重ねる」ことの重要性
成長を感じるためには、目に見える成果を積み重ねることが大切だ。しかし、駆け出しのうちは、大きな仕事を任されることは少ない。そんな時、私は「小さな成功」を意識するようにした。
例えば、JavaScript のイベントリスナーを使ってボタンクリックを処理する機能を実装したとする。その機能が動作すれば、それは「小さな成功」だ。あるいは、CSS で要素を配置するとき、意図した通りに表示されるとしたら、それも「小さな成功」だろう。
あるプロジェクトで、私は「ユーザー登録フォームのバリデーション」を担当することになった。当時の自分には、フォームの入力チェックすら難しく感じた。しかし、段階的に進めることにした。
- まずは入力フィールドに値が入っているかだけチェックする
- 次に、メールアドレスの形式チェックを追加する
- 最後に、パスワードの強度チェックを実装する
各ステップが終わるたびに、チームメンバーに進捗を報告した。すると、「確かに段階的に成長しているね」と褒めてもらえた。その小さな達成感が、より大きな課題に挑む勇気を与えた。
ちなみに、その後のバリデーション機能は、他のフォームで流用されるほどの品質になった。最初の「小さな成功」が、後の「大きな成果」につながったということは、今でも覚えている。
4. 「時間を惜しむより、学ぶ時間を大切にする」 mindset
駆け出しのうちは、「早く仕事を終わらせる」ことに集中しやすい。しかし、その結果、「いつも同じやり方でしか仕事をしない」という問題があった。
ある日、新しいフレームワークを導入することになった。当時の知識だけで対応しようとすると、かなりの時間がかかりそうだった。そんなとき、マネージャーから「早く対応してほしい」というプレッションがかかったが、代わりに「正しく学ぶ時間を与えてほしい」とお願いした。
すると、その提案は快諾してくれた。「確かに早く終わらせるのは大事だが、正しく理解してしまえば、次のプロジェクトでも役立つよね」という返答だった。
その時間を活用して、公式のチュートリアルやドキュメントをじっくり読んだり、メンターに相談したりした。結果、フレームワークのベストプラクティスを理解でき、後の開発で非常に役に立った。
ある年の後半、別のプロジェクトで同じフレームワークを使用することになった。当時の知識を持っていれば、数週間を費やしていただろう。しかし、事前の学習のおかげで、わずか 2 日でスムーズに導入できた。
この経験から、「時間を惜しむより学ぶ時間を大切にする」というマインドが、長期的な成長につながることを実感した。今では、「早く終わらせる」ことよりも「正しく理解する」ことを優先するようにしている。
5. 「完璧を目指さず、続けることを目指す」
完璧主義が、自分の仕事や学習を妨げていたことがあった。ある開発作業をする際、コードの品質を保証するために、何度も修正を繰り返していた。すると、他の作業が後ろになり、全体のスケジュールが狂ってしまったことがあった。
ある日、 mentor の一人が言ったのは、「完璧は敵だ。いいものを出すこと、それ自体が完璧だ」。その言葉は衝撃的だった。確かに、「完璧」を目指すことは、先に進めないほどハンデになる。
そんなわけで、「Good enough」な産物を出すことを意識するようにした。具体的には、次の 3 つの基準を設定した。
- ユーザーが問題なく使える機能が備わっていること
- 他の開発者が理解しやすいコード構造であること
- 将来的なメンテナンスがしやすいこと
これらの基準を満たす限り、「完璧」でなくても良いという発想は、開発スピードを大きく上げた。
あるインターンシップで、私は「シンプルなタスク管理アプリ」を作ることになった。当時の自分は、UI のデザインやアニメーションまで完璧にしようとして、かなりの時間を費やしていた。しかし、mentor のアドバイスで、「機能が正しく動作すること」を優先するようにした。
結果、2 日後には基本機能が完成した。その後の改善で、だんだんと品質が上がっていった。最終的には、他のメンバーも「すごく良い」と言ってくれた機能だった。
6. 「他人のコードを読む」ことで、自分の考え方を広める
駆け出しのうちは、他人のコードを読むのが苦手だった。「なぜこんなにもっともしない書き方をするのか」「なぜクラスを分けていないのか」と感じることが多かった。しかし、ある日、その考えが通じなかったことがあった。
あるメンバーが書いたコードを修正する仕事が回ってきた。当時の自分は、「こんなにもっともしない」と感じる部分がたくさんあった。でも、修正をしようとすると、そのコードがどうしてそう書かれているのかを理解するまでにはどれだけの時間がかかるかを知った。
それから、他人のコードを読むのをやめることはしないようにした。ただ、読む方法を変えた。「なぜこの書き方をしているのか」を考えるのではなく、「どのような問題を解決しているのか」を考えるようにした。
ある日、React のコンポーネントを読んでいた時、あるパターンに気付いた。「このコンポーネントは、状態管理をローカルで保持しているのではなく、コンテキストを使っているな」。その発見は、自分のコードにどのように活用できるかを考えるきっかけになった。
最近、チーム内のコードレビューで、他人の書いたコードを読むのが楽しくなってきている。「この書き方、勉強になる」と思うことが多い。そんな風に、他人のコードを読むことは、自分の考え方を広める非常に貴重な機会だと考えるようになった。
7. 「自分のペースでいい」という安心感
駆け出しのうちは、「早く成長せよ」「他の人と比べてはいけない」と、いつも勉強している人と比べていた。結果、自分のペースに不安を覚え、ストレスを貯めることになった。
ある日、同僚の一人が言っていたのは、「成長は誰にも真似できない。自分のペースでいいんだ」。その言葉を聞いて、ようやく肌で感じた。
確かに、同じ本を読んでも、同じチュートリアルをこなしても、「誰にも真似できない」のは自分の学び方だ。ある人は視覚的に学びやすい one、ある人は聞き手で学ぶタイプだ。
自分の学び方を見つけるまで、いろいろな方法を試していた。動画で学ぶ、記事を読む、手を動かす、友人に説明を聞く、などなど。ある方法が自分のペースにより合っていることがわかると、学習がはるかに楽になった。
最近、同僚の一人が「自分も勉強中だよね」と言っていたとき、「私もです！」と共感した。そんな風に、「自分のペースでいい」という気持ちを持つことが、ストレスフリーな成長へつながると実感している。
まとめ
駆け出しエンジニアのうちは、「わからないことを訊くのは恥ずかしい」「完璧を目指す必要がある」「他人のコードを批判する」といった考えが、自然に浮上する。しかし、それらのマインドを「正しい姿勢」に転換することで、怖がっていたことをやり遂げることができる。
自分が意識していただいたのは、5 つのキーポイントだ。
- 「わからないことは必ずしも自分の失敗ではない」
- 「質問をする」ことがチームの負荷を減らす
- 「小さな成功を積み重ねる」こと
- 「時間を惜しむより学ぶ時間を大切にする」
- 「完璧を目指さず、続けることを目指す」
これらのマインドを身につけることで、自分は怖がっていたことをやり遂げることができた。同じように悩んでいるあなたにも、「自分のペースでいい」という安心感を届けたい。成長は、必ずするであろう。