TechTrainからエンジニアスキルを伸ばすために頑張るみなさんへのクリスマスプレゼント🎄

メンターの平均年間面談実施数約37回のところ、その13倍となる515 回（2024/12/25時点）の面談をしたメンターから、"Railwayのクリア判定面談でこんなキャッチアップをしている人が伸びる"をリアル調査してきました。

Railwayとは...
TechTrainが提供する初学者が自社開発企業でも内定を獲得できるレベルまで着実にスキルアップできる実践型開発ドリル

伸びてるユーザー、筋のいいユーザーの面談の使い方

やはり一番は、”実務を意識してRailwayの問題に取り組めているか？”。

例えば、テストについての問題の面談で「実際に実務ではテストってどれくらい書くんですか？」という質問をしてくる方が一定数います。この場合、テストの問題を解くことだけではなく、実際の現場を意識できているので、そういった質問をする人はのびしろがあるなと感じます。

テストについての問題が掲載されているRailway

面談の中では、実務を意識するならという視点で、クリア条件にないポイントをお伝えすることもあります。その際、「余力があれば、」という温度感でお伝えしていますが、次の面談までにクリア判定と合わせて、実装をしてきて見せてくれる人がいます。そういった人は、やはり力がついている印象があります。

また、一見、「余力があったら」という追加の実装について、取り組むと時間がかかるなと思う人もいると思うのですが、実は、この追加の実装をした人の方が結果的にはサクサク進んでいるような気がしています。

なので、実は遠回りのように見えるメンターからの+αポイントのアドバイスをRailwayに取り組みながら身につけている人の方が、力がついて伸びているのかな、と感じます。

「クリア」すれば良い？！Railwayのクリア判定のリアル

TechTrainの面談クリア判定では、問題文の中でクリア要件が明示されています。もちろん、そのクリア要件を最低限満たした上で、判定に臨むことが必須。ですが、実は現役のエンジニアからの面談でクリアの判定をするからこそのポイントがありました。

実際にRailwayに取り組んでいる方は、まずは自分の手元で、クリアの条件が満たされているかを確認した上で、メンターとの面談に臨むと思います。ただ、面談の中でうまく機能が動かなかったりしてあたふたすることもあるのではないでしょうか？

こんなとき、メンターのみなさんは、「こうしてみたら動く？」とか「ここが少し違いそうだよ」とアドバイスをくれ、なんとか30分の面談でクリアとなることもあると思います。

ただ、その後、そのままになってしまって次のStationに取り組む人は、次のクリア判定でも同じように「うまく動かないな...」と毎度クリアに苦戦していませんか？

メンターは、そこでおまけでクリアにしても、その後もっとうまく動くよう解決のアドバイスを伝えてくれるので、次のStationに取り組む際に、その面談の振り返り、アドバイスの通りに実装し直してみると良いでしょう。

もちろん問題なので、クリアがゴールではありますが、あくまでクリアすることは通過点で、Railwayを通して実際にエンジニアとしてコードを書くことを想定した練習と思って取り組むことが大切です。

TechTrainの面談は、現場に出る前にエンジニアからのリアルなアドバイスを聞くことができる貴重な機会です。準備はもちろん、面談後、現役エンジニアからの具体的なアドバイス吸収もプログラミングのスキルを伸ばす大事な要素になってきます。

一言一句理解しながらコードを「書く」ということ

TechTrainでは、GitHubDisscussionsという質問のヒントがもらえる場を提供していますし、生成AIで調べることを禁止するということはしていません。なぜなら、これらを活用しながら、コードを書くときの調べ方を含めてコツを掴むことを推奨しているからです。様々なツールやテクノロジーを利用して調べ方を学ぶことも大事なスキルの一つ。ただ、その内容を理解せずに「コピペ」をすることは望ましくありません。実際、他の人のコードを丸コピペしたり、生成AIで返ってきたコードを丸コピペをして挙動をしたからクリア判定面談をしているという方はメンターも気づいています。

それは、自分が書いた（はずの）コードを、自分の言葉で説明することができないからです。

調べて得た結果を「コピペ」ではなく、横に映してちゃんと一字一句自分でまずは打ち込みましょう。そのコマンドがどういう意味を持ってそこの位置に書かれてるのか？や、なぜその区切られ方をするのかなど、コードの意味を理解をすることが大切です。

難しいとは思いますが、そのヒントを映して書いたコードを0から自分で書くという工程を踏むようにしてください。イメージでいうと英語の単語帳を使って単語を覚える反復。一度赤シートで回答を隠していたものの答えを見る。その後1日おいてその単語の意味がわかるかをチェック。そして1週間後にまたその単語が出てきた文章が読めるかどうか？その文法が理解できるかどうか？を確認する工程のイメージです。

これは、「何も見ずに書けるように」ということではありません。必要な時に検索したり、引き出しから取り出して自分の頭で組み立てられるようにしてほしいのです。

過去の実装を自分の糧にできるくらいコードの内容を理解をしよう

Railwayの問題について質問をもらう中で、「この機能の実装が難しいです」という相談をもらうことがあります。相談内容を見てみると、実は前のRailwayで実装したことがある機能だったりすることがあります。「これ前にやったな〜」ということに気づくことができるかできないかは、どれくらい理解してコードを書いているかに比例すると思います。

このように、Railway基礎編ではそれぞれ具体的なアプリをイメージした問題となっていますが、実は、過去の自分の実装を反復するような問題構成となっているところもあります。

理解を深めるためには反復は必須です。ぜひ問題を活用しながら理解を深めていってください。

ここで、実際の業務をイメージをしてみてください。TechTrainには正解がありますが、現場では正解は決まっていません。

ある機能を実装するとなったら、ネットや今まで自分の読んだ専門書籍、自分の経験した実装から引き出しとなる複数の情報を検索しながら、実装をすることになります。

そのとき、自分がやりたいことを実現できる情報がそのまま出てくるとは限りません。複数の情報を参考に、実際に自分で書きながら、「これはちょっと挙動の方法が違うから、今のコードをベースに別の記事の一部を参考にしてみよう」や、「AとBを組み合わせたらできそう」というスキルが必要になります。また、エンジニアとしてこのスキルはとても大事なスキルです。身につけるためには、正解があるTechTrainの問題に取り組む中で、調べて意味を理解する練習をし、習慣づけるようにしましょう。

フロントエンドをより理解するためにできること

普段React Railwayの面談が圧倒的に多いKoheiさんからのアドバイスの中で、よく面談で聞かれる「Railway以外に何かやった方が良い勉強はありますか？」について。中でも、フロントエンド初心者の場合は、React.jsまたはNext.jsでも良いですが、補足教材として入門書を1冊並行して学習するのもおすすめ。

Railwayは実践的な内容になっており、座学や基本の概念についてはやはり入門書からキャッチアップするとより理解度が深まります。

ただ、フロントエンドの技術は移り変わりが激しくバージョンアップが速いため、これがおすすめ！という入門書を提示できないのが難しいところ。

補助教材として扱う入門書選びについては、クリア判定面談の中で相談されることが多いため、普段はなるべく新しいもので、本の評価や目次をみながら面談で一緒に探すこともあります。困ったらぜひ相談してみてください。