Reactの「実務レベル」とは何か。チュートリアルとの差は文法ではなく、判断の数

公式チュートリアルは終えた。Todoアプリも作った。useStateとuseEffectも書ける。でも求人に「Reactの実務経験」と書いてあると、自分がそこに届いているのか分からない。

「実務レベル」という言葉が曖昧なのが原因です。定義が無いものは目標にできないし、到達したかどうかも判断できません。

先に結論を書くと、チュートリアルと実務の差は、書ける文法の量ではなく、自分で下す判断の数です。この記事では、その判断を5つに分けて書きます。

チュートリアルのReactと実務のReactは、何が違うのか

チュートリアルが簡単に感じるのは、内容が易しいからではありません。判断がすべて済んでいるからです。何を作るか、どう分けるか、状態をどこに持つか。全部決まった状態で、写すだけになっています。

実務では、その決まっていた部分を自分で決めることになります。

右側の5つは、どれもReactの文法の話ではありません。だから、文法をいくら覚えても右側には近づきません。

実務レベルで求められる5つの判断

1. 状態をどこに持つか

実務でいちばん多く、いちばん差が出る判断です。

同じ「選択中のタブ」でも、そのコンポーネントの中だけで持つのか、親に上げるのか、URLに載せるのか、サーバーから取り直すのかで、まったく別の設計になります。チュートリアルはこれを毎回1画面に閉じているので、この判断が発生しません。

目安は単純で、その状態を誰が読むかです。1つのコンポーネントしか読まないなら、そこに置く。複数が読むなら、読む側の共通の親まで上げる。リロードしても残ってほしいならURLかストレージに出す。この問いを毎回自分に投げられるかどうかが、実務レベルの入り口です。

2. コンポーネントをどこで分けるか

「長くなったから分ける」は判断ではありません。見た目で分けたコンポーネントは、仕様が変わったときに一緒に変わってくれないので、かえって手間が増えます。

分ける基準は変更の単位です。「この部分は一緒に変わる」「ここは別の理由で変わる」という境目で切ると、後から変更が入ったときに触る場所が1箇所で済みます。これは Reactに限らず、設計ができない原因として書いた「判断基準の不足」とまったく同じ話です。

3. 読み込み中・失敗・0件を扱う

チュートリアルの画面は、データが必ず存在して、必ず取得に成功します。実務ではその前提が崩れます。

• 取得中に何を出すか
• 失敗したときに何を出し、再試行できるようにするか
• 0件のときに空の画面を出すのか、案内を出すのか

この3つを毎回考えて実装しているかどうかは、コードを見ればすぐ分かります。逆に言えば、ここが揃っているだけで「実務を意識している」と読み手に伝わります。

4. 型で仕様を表す

実務のReactはほぼTypeScriptです。ただ「anyを減らす」が目標ではありません。

型の役割は、あり得ない状態を作れなくすることです。たとえば「読み込み中なのにデータがある」「失敗したのにエラーが無い」という組み合わせを、型の段階で書けないようにする。これができると、3で書いた3状態の扱いが漏れなくなります。

型を「コンパイルを通すためのもの」と思っている間は、まだチュートリアル側にいます。

5. 変更に耐える形にする

実務のコードは、書いた瞬間より、半年後に別の人が触るときのほうが長い時間を過ごします。

• 初めて読む人が、何をしているか追えるか
• 仕様が1つ変わったときに、触る場所が限定されているか
• 壊したときに、テストが教えてくれるか

「動いた」で終わるのがチュートリアル、「変えられる」まで見るのが実務です。

自分が実務レベルかどうかを確かめる

次の質問に、自分のコードを見ながら答えてみてください。

全部に答えられなくても問題ありません。答えられなかった質問が、次に練習すべき場所です。

「実務レベル」のよくある誤解

新しいライブラリを知っていること

状態管理ライブラリやデータ取得ライブラリの名前を並べられても、それは実務レベルの証明にはなりません。ライブラリは判断を楽にする道具であって、判断の代わりではないからです。「なぜそれを選んだか」を答えられなければ、道具の名前を覚えただけです。

大きいアプリを作ったこと

画面数が多いことと、判断の数が多いことは別です。チュートリアルの型のまま画面を増やしたアプリは、大きいだけで判断は増えていません。

学習時間を積むこと

「実務レベルまで何百時間」という目安をよく見かけます。ただ、判断が発生しない学習を何時間やっても、判断の練習にはなりません。時間ではなく、判断した回数で数えたほうが実態に近いです。

実務に近づくための練習法

チュートリアルの要件を、自分で1つ変える

写して終わりにせず、要件を1つ足します。「Todoに期限をつける」「一覧を絞り込めるようにする」。それだけで、状態をどこに持つか、コンポーネントをどう分けるかの判断が発生します。

チュートリアルを10本やるより、1本に自分で要件を足すほうが、実務には近づきます。

3状態を、必ず作る

自分で作るものは、たとえ個人開発でも読み込み中・失敗・0件を必ず作る。これを習慣にするだけで、コードの印象が変わります。

判断を書き残す

何を決めて、他に何を考えて、なぜこちらにしたか。1つの機能につき数行でいいので書き残します。実務で評価されるのは成果物より、この判断の記録です。個人開発を転職で評価してもらうときにも、この記録が効きます。

自分の判断を、他人に見てもらう

ここまでの練習は1人でできます。ただ、自分の判断が妥当だったかどうかは、1人では分かりません。設計には正解が無いので、テストが通っても、動いても、判断が良かったかどうかは教えてくれないからです。

独学で届く範囲と、届きにくい範囲

正直に書きます。

左側は教材があります。右側は、判断に対してフィードバックをくれる人がいないと進みません。職場にReactの設計まで見てくれる先輩がいれば、それが最良の環境です。いなければ、外に求めるしかありません（外に求める場合の選び方は「Reactが学べるスクール」を比較表では選べない理由に書きました）。

これは「自走できるエンジニア」とは何かで書いた「判断の材料を集める力」の、Reactにおける具体例です。

まとめ

Reactの実務レベルとは、これらの判断を自分で下し、理由を説明できる状態です。文法はその前提にすぎません。次に何かを作るときは、「動くか」ではなく「なぜそうしたか」を1つずつ言えるかを確かめてみてください。