画面を作る仕事と、データを扱う仕事を分ける
フロントエンドはブラウザに表示する画面と操作を実装し、バックエンドはデータの保存や認証などサーバー側の処理を扱います。どちらも設計やテストが必要です。『Web制作』がサイト更新を指す求人と、『Web開発』がサービスの機能追加を指す求人を一緒に比べないでください。
求人では、使用技術だけでなく、既存機能の改修、新機能の開発、テスト、保守の割合を確認します。『フルスタック』と書かれていても、入社時に一人で広く担当するのか、チームで学ぶ前提なのかで準備は変わります。コードを見てもらえる人とレビューの方法を聞いておきます。
表は横にスクロールできます
| 目指す仕事 | 作品の例 | 確認される内容 |
|---|---|---|
| フロントエンド | 検索・入力・編集ができる画面 | 状態変化、スマホ、操作性 |
| バックエンド | データを登録・検索するAPI | 入力確認、権限、エラー処理 |
| モバイルアプリ | 端末で動く小さなアプリ | 画面遷移、通信、保存 |
| ゲーム開発 | 遊べる短いゲーム | ルール、操作、処理の説明 |
Java・JavaScript・Ruby・PHP・Pythonは求人の用途で選ぶ
JavaとJavaScriptは別の言語です。Javaの求人ではサーバー側の業務システム等、JavaScriptの求人ではブラウザの画面やサーバー側処理等、何を作るかまで読みます。名前が似ているから置き換えられるものではありません。使用するフレームワーク、データベース、テストの書き方も求人で確かめます。
RubyとRailsは言語とフレームワークの関係です。PHP、Pythonも、それぞれ利用する枠組みや担当業務が違います。Pythonという一語でもWeb開発、分析、AIでは作品の評価点が変わります。学習する技術を決める前に、通える地域や希望勤務形態の求人に、その技術を使う未経験向け業務があるか調べてください。
- Java：業務の入力・更新・照合を行う小さな機能で、処理とテストを説明する
- JavaScript：画面の状態、入力エラー、通信中の表示を確認する
- Ruby／Rails・PHP：データ構造と権限、保存できない場合の扱いを説明する
- Python：Web開発かデータ処理かを決め、再実行できる手順を残す
SwiftのアプリとUnityのゲームでは提出物が違う
Swiftを使うアプリ開発を目指すなら、画面の見た目だけでなく、端末での操作、データの保存、通信が使えない場合の挙動を試します。求人が求めるプラットフォームや開発環境を確認し、提出先が実行できない場合にも、操作動画と起動手順で作品を確認できるようにします。
Unityを使うゲームの作品では、短くても最初から最後まで遊べる状態にし、担当したスクリプト、ルール、当たり判定やUIなどを説明します。素材ストアや教材の素材は出所を明記し、キャラクター画像の質を自分のプログラミング実績と混ぜないでください。ゲーム企画とプログラミングのどちらの募集かも区別します。
作品は完成画面・コード・説明の3つをそろえる
応募作品は、使い方が分かる画面、読めるソースコード、自分の判断を説明する文章を組み合わせます。READMEには、誰の何を解決する作品か、主要機能、使用技術、起動方法、本人の担当、残る課題を書きます。公開できない部分があれば、その理由と確認できる範囲を伝えてください。
教材を写しただけの部分を減らすために、利用者の条件を一つ変え、自分で機能を追加します。たとえば一覧を作ったら、検索、入力の検証、編集、削除まで追加し、誤入力や空データを試します。AIが出したコードを使った場合も、どの処理か説明し、実行して問題を確認した範囲を話せるようにします。
テストと説明で、作って終わりにしない
編集部の準備例として、応募用の予約管理アプリを想定します。予約を登録できるだけでなく、日付が空、同じ時間が重複、通信が失敗、といった場合を試し、期待した結果と実際の結果を記録します。テストで見つかった問題をどう直したかまで残すと、作品の画面だけでは見えない作業が伝わります。
公開前には、別の端末とログアウト状態で開き、READMEの手順どおりに起動できるか確認します。秘密情報や実在顧客のデータを入れず、説明用のデータを使います。未完成の機能は未完成と記載し、利用できるように見せかけないでください。採用担当が短時間で確認できる入口を一つにまとめます。
開発に関われる条件を面談で確かめる
未経験歓迎でも、学習済みであることや作品提出を条件とする求人があります。必要な言語数だけに注目せず、最初に担当する改修例、テストと実装の比率、レビューを受ける頻度を尋ねます。入社後の職種変更を期待する場合は、変更の条件を確認し、確約された仕事内容と希望を分けて考えます。
フルリモートを希望するときも、研修中の出社、質問できる時間、開発環境の提供、端末の費用を確認します。学習が終わるまで無期限に応募を待つのではなく、作品を求人の要件と照らし合わせ、足りない機能を一つずつ修正します。相談先にはリポジトリと作品URLを渡し、応募条件との違いを具体的に聞きます。
作品を見直す例：機能の数より、動作を説明できるか
ログイン、検索、投稿などを多数付けた作品でも、なぜその構成にしたか説明できなければ、自分が担当した範囲が伝わりません。逆に、機能が少なくても、入力の確認、権限、失敗時の表示を自分で考え、テストした記録があれば、その部分の理解を説明できます。採用条件を満たす保証ではなく、作品を伝わりやすくするための考え方です。
提出前に作品を一度閉じ、READMEだけを見て動かします。初めて見る人が迷った箇所、エラーになった箇所、設定が必要だった箇所を直してください。面接用には『困ったこと→調べたこと→変更→確認結果』を一つ用意し、技術名を暗唱するより自分の作業を具体的に話せる状態にします。