はじめに
本記事では、未経験〜ジュニアレベルのエンジニアが、実務現場で「タスクを前に進める力」を短期間で獲得するための実践的な手法をまとめている。
特に「とにかく試し、動かす」というフィードバックループの起点を作るアプローチに焦点を当て、それを可能にする開発環境や心理的ハードルの克服策について解説する。
このアプローチを習得することで、課題や報告されたバグを自分で調査し、解決策を導き出せる「自走型エンジニア」へと着実に近づくことが可能である。
結果として、より早期にチームへ貢献し、ビジネス視点からも信頼される存在としてキャリアを加速できる可能性が高まる。
前提条件
本記事で書くノウハウは、主に未経験〜ジュニアレベルのエンジニアを対象としている。このアプローチが非常に効果的になるのは、プログラミング等に関して基本的なことは理解しているが、実務経験がこれからという段階のエンジニアに特に効果的なアプローチだ。
要点
結論から言うと、とにかく試すこと、動かすことが大切だ。実務未経験のエンジニアが成長するためのセンターピンは、試行回数を重ねることにある。
筆者について
筆者はエンジニア歴5年目のフリーランスエンジニアだ。現在は企業のSaaSのリードエンジニアとして、バックエンドとインフラを中心に、フルスタック寄りで開発に携わっている。主にRuby on RailsやAWSを使って、様々なビジネス課題の解決に取り組んでいる。
これまでに何人かの新人エンジニアの教育も担当してきた。本記事では、それらの経験から得た「タスクを進められるエンジニアを短期間で育成する方法」に関するプラクティスを共有する。
エンジニアとしての初期キャリアでの課題
初期実務で直面するギャップと不安
実務の難易度は、多くの場合、新人のエンジニアの想像を超えるものだ。初めてプロダクションコード見た時、何が分からないのかすら分からない状態に陥ることがある。
タスクがなかなか進まず、不安を抱えながら「自分にエンジニアは向いていないのでは？」と考えることは珍しくない。正直に言えば、筆者自身もエンジニアを辞めることを何度も考えた。
しかし今振り返ると、これは誰もが通る道だった。そして、この経験は現在、後輩の指導やタスク管理をする際に非常に役立っている。
そのため、今苦しんでいる新人エンジニアの方も絶望せずに成長のため必要なタスクに取り組んでほしい。
先輩エンジニアとの比較で見えた成長の差
新人時代悩んでいる時、ある先輩エンジニアと出会った。彼は自分より1年ほど先輩だったが、その成長スピードはとにかく驚異的で、作成されて年月の経つ既存のWebアプリケーションの機能改修は自由自在に行い、新規開発もインフラからバックエンドフロントエンドまで全てをリードしていた。
一緒に仕事をする期間が長くなるにつれ、彼との技術的な差は開いていった。多くの分野で、成長曲線は徐々に緩やかになっていくのが一般的だ。しかし、私の成長が一定のペース(もしくは停滞していた)だったのに対し、この先輩は加速度的に成長を続けていた。
その成長差分を生む原因を解明するために、私は機会がある度に、彼に話を聞かせていただいた。
成長のセンターピンは「試すこと」
そこで見えてきた答えは、シンプルで、
「とにかく試す」「とにかく動かす」ということだ。
私が本や理論を読み学んでいる間、先輩は実際にコードを書いてテスト的なアプリケーションを作っていた。
結局のところ、私と先輩の差は、圧倒的な試行回数の差だったのだ。
ここで重要な概念を提唱したい。「実行と検証のフィードバックループ」という考え方だ。これは、実際にコードを書いて動かし、その結果を確認して理解を深めるまでの一連のサイクルを、どれだけ素早く回せるかということである。この速度が、特に実務経験の浅いエンジニアの成長曲線を大きく左右する。
先輩が実践していたのは、以下のような高速なフィードバックループだった：
- コードを書く
新しい機能を実装する、または既存コードを改修する。 - すぐに動かす
実装したコードをテスト・アプリケーションなどで即座に実行し、挙動を確認する。 - 結果を確認する
コンソール出力やテスト結果などを見て、意図通り動作しているかを判断する。
- 改善点を見つけて修正する
修正箇所を特定し、再度コードを書く工程に戻る。
このサイクルを素早く、何度も回すことで、驚異的な成長を実現していた。
結論：爆速で成長するには「とにかく試せ、とにかく動かせ」
一度、ここまでの話をまとめよう。
(初期の)エンジニアが爆速で成長するための秘訣は何か？
それは、とにかく試すこと。とにかく動かすこと。そして、試行回数を重ねること。これに尽きる。
書籍等から学ぶのも大切だ。でも、それ以上に大切なのは、実際に手を動かし実行結果というフィードバックをもらうこと。
コードを書いて、動かして、結果を確認する。このフィードバックループを高速で繰り返すことである。
しかし、ここが本当に重要なのだが、まだ経験の浅いエンジニアにはそもそも「試すこと」自体が困難であるパターンが少なくない。
次からはその理由について深掘りしていく。
試行錯誤を妨げる心理的障壁
ここまで「試すこと」の重要性について述べてきた。では、なぜ経験の浅いエンジニアには「試すこと」が困難なのだろうか。
アクシデントへの恐怖
その最大の理由は、アクシデントへの恐怖だ。具体的には以下のような不安を抱えている：
- 苦労してやっと構築した環境を壊すのが怖い
- 何か自力で回復不能な変更をしてしまった際、チームメンバーに迷惑をかけてしまうのではないか
この不安の根底にあるのは「影響範囲や、元の状態への戻し方が分からない」という不確実性である。
ここで重要なのは、この不確実性が新人エンジニアにとって主観的なものだという点だ。これは主に、システムやツールへの理解が不足していることに起因する。
具体的には以下のような例だ：
- 会社支給のPCの環境設定などを自力で修復不可能な状態にしてしまうのではないか
- 他のエンジニアと共有している開発環境や本番環境に取り返しのつかない影響を与えてしまうのではないか
しかし、この不安は適切な環境設定とその理解によって大きく解決できる。
- 簡単に初期状態へリセットできる仕組みがあれば？
- 影響範囲が明確に限定され、かつそのことを理解出来ていれば？
つまり、「安全に失敗できる条件」を整備し、理解することで、「試すこと」への心理的障壁を大きく下げることができる。
爆速成長を促進する環境づくり
新人エンジニアが「試すこと」をためらう背景には、前章で述べた通り、アクシデントへの恐怖や他人への迷惑懸念など、さまざまな心理的障壁がある。ここでは、それらの障壁と対策を一覧で整理したい。
試行錯誤を妨げる障壁と対策一覧
| 障壁 | 原因 | 対策 |
|---|---|---|
| 環境破壊への恐怖 | 復元手順がわからず、元に戻せない不安がある | Dockerを用いた容易なリセット、シードファイルの整備 |
| 他人への迷惑懸念 | 共有リソースに影響を与え、チームに混乱を招く恐れ | 個人用AWSアカウントを用意、Dev環境での自由な改変を事前に合意 |
| 動かし方が分からない | そもそもどうやったら動かせるのか理解、把握できない | テストコードをエントリーポイントとして活用し、binding.pryなどで処理をステップ実行する |
これらの障壁を取り除くうえで鍵となるのが、「安全に失敗できる環境」の整備である。以降は具体的にどのように環境を用意し、スムーズな試行錯誤を行えるようにするかを解説する。
教える際に重要な視点
そもそもの前提として重要なものに、指導する側の認識がある。
経験を積んだエンジニアには避けられない特性がある。
それは、一度習得した知識や克服した課題については、その「分からなさ」や「怖さ」の感覚が非常に希薄になっていくということだ。
これは人間の自然な特性である。
人間は、一度理解してしまうと、そう簡単には理解していない時の感覚には戻れない。だからこそ意識的に初学者の視点や感情を理解する努力が必要となる。
この前提条件の違いに対する認識は、新人エンジニアの教育において極めて重要な意味を持つ。彼らの不安や戸惑いに共感し、適切なサポートを提供するための基礎となるからだ。
具体的な「試す」「動かす」ための手法
以下に、これまでの筆者の経験で重要だと考える新人エンジニアに試してもらうための手法やそれを支える心理的安全性の確保の仕方について紹介する。
Docker に関する理解と活用
Docker は、環境を簡単に構築し、リセットできるツールだ。これを使えば、「壊してしまっても大丈夫」な環境を作れる。
とはいえ、まだDockerに馴染みのない新人のエンジニアが、Dockerの概念を完璧に理解するのは難しい。
筆者が教える際には、「一度で全て完璧に理解する必要はない」ということを伝えた上で、大まかな概念(仮想環境であり、基本的にこの中でやることは本体のPCなどには影響せず簡単にリセットできるということ)を理解してもらうようにしている。
もし「環境を壊してしまうかもしれない」という不安があるなら、一度Docker上で意図的に環境を破壊し、すぐに再構築してみてください。もしそれが難しければ、まずはDockerを使って自分で環境を立ち上げられるようになることを目標にするとよいでしょう。
これにより、『壊しても直せる』という安心感が得られ、思い切った試行がしやすくなるはずです。
個人用の AWS(その他クラウド) 開発環境
可能であれば、個人用の AWS 開発環境を用意することを推奨する。本番環境や他の開発者の使う開発環境とは分離された完全に個人用の開発アカウントである。それらの安全性を理解させることで、アクシデントを恐れずに積極的な試行錯誤が可能となる。プロダクトで使用されている構成と同じ構成で AWS リソースを作成したり 試行錯誤することで、それが担当プロダクトの機能改修を行うための理解促進に大いに役に立つ。
テスト（Rspec）の重視
筆者が教えるときは、とにかくテスト（Rspec）を重視している。なぜなら、これがコードを「試す」「動かす」ためのエントリーポイントになるからだ。
エントリーポイントを作ることができれば後述するデバッグ手法と組み合わせて各変数に入っている値などを理解することができる。
単体テストの重要さ
単体テストは、コードの理解と検証において極めて効果的なツールである。特に以下の観点を強調して教えることで、新人エンジニアの理解を強力にサポートする：
- テストコードが仕様を表していること。
- テストコードを書くことでエントリーポイントが作成されること。それにより、その関数を実際に動かすことができること。
単体テストは、単なる品質保証のツールを超えて、コードの仕様理解から内部的な動作の確認まで、包括的な学習環境を提供する。新人エンジニアが「試す」「動かす」を実践する上で、最も安全で効果的な手段の一つとなる。
エントリーポイントを作ることの意識
「エントリーポイント」とは、コードを実行し始める場所のことである。エントリーポイントを作ることの最大の利点はデバッグが可能になることだ。デバッグが可能になることで実際のソースコードの動きを1行1行を追うことができるようになる。これは新人のエンジニアにとって大きな理解促進の起点となる。
エントリーポイントに対してはAPIならcurlコマンドで叩く方法などもあるが、先に書いたように筆者は単体テストを起点にすることを重視して教えている。
基本的に、タスクとしてアサインされる機能追加改修はテストコードの追加改修とセットであることもその理由の1つだ。
デバッグツールの使い方
経験者には当たり前すぎて軽視されがちだが、デバッグツールの重要性を強調しておくことは非常に重要だ。Ruby on Railsにおいてはbinding.pryの重要性を筆者は非常に強調して教えている。デバッグツールはコードの動きを深く理解するための強力なツールである。
エントリーポイントを作ることもつまりは、デバッグをするためである。
デバッグによって、コードを1行1行みて変数の中身をリアルタイムで確認できるようになる。これにより理解が大幅に進むこととなる。
経験者は、コードを読むだけで変数の中身や処理の流れを追うことができるが、初心者にはそれをやるのはハードルが高い場合が多い。
面倒くさがらずにデバッグをやり手がかりを掴むことの重要性を教える必要がある。
シードファイルの整備
開発用のデータを簡単に生成できるシードファイルを常に整備しておく。これによって開発環境を壊してもすぐにまたシステムが機能する状態に立ち上げ直すことが可能である。そのように壊してもまたすぐに元に戻せるということが心理的安全性を生み試行錯誤を促すことにつながる。
開発環境を触りまくって良いことを強調する
未経験のエンジニアが初めての実務に触れる場合多くの場合が新しい会社に入ってきた場合だ。その場合、程度の大小はあれど多くの場合で彼らは緊張し、他の人に迷惑をかけることを過度に恐れている場合が多い。なのでいわゆるDev環境、開発環境などであったとしても、プロダクトの管理画面などを触ることを書ける場合がある。しかし自分が開発をしていくプロダクトを理解するにあたって画面を隅々まで触っておくことは重要である。開発環境であればデータを作成してもらって構わないし触ってもらって問題ないことを強調して伝えておくことで、より試してもらうハードルを下げることが出来る。
もしあなたが『他人に迷惑をかけるのではないか』と尻込みしているなら、まずはDev環境で管理画面を自由に操作し、データを生成・削除してみてください。これによって、自分が担当するアプリケーションで何を行っているかを直感的に把握でき、迷いが減っていきます。
「試す」「動かす」で得られる具体的なメリット
これまで「試す」「動かす」アプローチの重要性と具体的な実践方法について論じてきた。ここでは、このアプローチを採用することで得られる具体的なメリットについて言及する。
このアプローチがもたらす最も顕著な効果は、エンジニアとしての自走力の獲得である。実践的な試行錯誤を通じて、エンジニアは独力で問題を解決する能力を培うことが可能となる。この自走力の獲得は、個人の技術的成長を加速させるだけでなく、組織全体に対しても大きな価値をもたらす。
特筆すべきは、このアプローチが組織的なリソース効率の向上にも寄与する点である。実際のプロジェクトでは、経験のあるエンジニアが常時、新人の指導に時間を割くことは現実的ではない。自身の開発業務との両立が求められる場合が殆どだ。新人エンジニアが早期に自走力を獲得することで、組織全体としての開発効率が向上する。
殆どの場合、ビジネスには競合が存在する。競合他社による新機能の開発や技術革新が継続的に行われる中、チームの経験の浅いエンジニアが「自分で試せる環境」を整備し、自走力を獲得することは、組織の競争力向上に直結する。
このように、新人エンジニアの早期の自走力の獲得は個人の成長にとどまらず、組織全体のリソース最適化にも大きく貢献する。新人エンジニアの自立は、シニアエンジニアがより高度な開発業務に注力することを可能とし、結果として組織全体の生産性向上をもたらすのである。
まとめ
この記事を書いた理由
本稿を書いた目的の1つには、筆者自身の実務経験と教育経験から得られた知見を、自身の将来のために文書化することもある。
経験を積んだエンジニアには、「知識の呪い」と呼ばれる認知バイアスが存在する。これは、知識や経験を獲得するにつれて、その知識を持たない人の視点に立つことが困難になるという現象だ。この影響により、多くのエンジニアは初学者として直面した困難や不安の感覚を、経験を積むにつれて想像することが難しくなっていく。
実際に、初学者に向けた上達のための思考法や教育方法論を扱う技術記事は比較的少数である。これは、多くのシニアエンジニアが、自身の初期キャリアにおける経験や感覚を十分に言語化できていないことに起因すると考えられる。
そのため本稿では、現時点での筆者の知見と経験を、具体例を交えた形で記録することを試みた。筆者自身も、今後自身が成長していくにつれて、より初学者の感覚を忘れてしまう可能性が非常に高いからだ。
最後に
本稿では、効率的なタスク遂行能力を持つエンジニアの育成方法について論じてきた。しかし、これはあくまでもエンジニアとしての成長過程における初期段階の指針である。
より高度な技術力の獲得に向けては、試行錯誤だけでなく、ソースコードのより深い理解や、アーキテクチャ設計の考察など、さらなる学習ステップが存在する。しかし、それらは本稿で論じた基礎的な「試す」「動かす」という実践を確実に習得した後の段階として位置付けられる。
例えば、近年話題になっている以下の書籍では主に今回の試行錯誤を是する主張とは真逆の意見が述べられている。それはある程度経験を積んだエンジニアにとっては当てはまるが、本当に新人のエンジニアに限っては今回のような試行錯誤をすることが、少なくとも担当プロダクトのタスクを進めるにあたっては最短である。
https://amzn.asia/d/5mOHY7e
ある程度慣れてきたら、”考えること”つまり、なぜそのようになるのかなぜそのように動くのかという部分を重視するようにシフトしていけば次の段階の成長もできるはずだ。
まずは本稿で提示した方法論に基づき、積極的な試行錯誤を重ねることが推奨される。その過程で得られる実践的な経験と理解が、確実な技術的成長をもたらすはずである。
本稿が、次世代のエンジニアの成長の一助となれば幸いである。
筆者へのお問い合わせ・SNS情報
筆者はフリーランスエンジニアとして、Ruby on Rails・AWSを中心にWebサービス開発の支援を行っています。新人エンジニア育成や小規模サービスの効率的な立ち上げに関して興味やご相談がある方は、XのDM等を通じていつでも連絡いただければ幸いです。
- Twitter: @Toku_Web_E
Webシステム等に関する雑談や漠然とした相談でもお気軽にどうぞ。