コーディング課題は作り終えた。でも、GitHubのどのURLを送ればよいのか、公開してよいのか、READMEには何を書くのか分からない。自分のパソコンでは動くものの、そのまま提出してよいか迷っていませんか。
GitHubで課題を提出するときは、応募先が指定した公開範囲に合わせ、採用担当者が提出した版のコードを開き、READMEの手順で動作を確認できる状態にします。リポジトリURLを送るだけで完了するかは、提出要項によって異なります。
この記事では、課題を作り終えた人向けに、公開範囲・README・動作確認・秘密情報・未実装部分を確認する順番を整理します。GitHubの初歩的な操作や、履歴書で作品を紹介する方法ではなく、企業から指定された課題を提出する直前の作業に絞って説明します。
最初に提出要項を読み直し、必要なURLと資料を書き出す
まず、案内メール、課題ページ、添付資料にある「提出事項」を確認します。コードの要件を満たしていても、別途求められているURLや説明が抜けていれば、提出物がそろいません。
公開課題の一例として、ゆめみのフロントエンドコーディング試験には、GitHubの公開リポジトリURLとデプロイ先URLに加え、取り組みに要した合計時間やプログラミング歴などの提出事項があります。評価観点にはドキュメンテーションも含まれています。これは同社の公開課題の例であり、どの企業でも公開やデプロイが必要という意味ではありません。
自分の案内から、次の項目を抜き出しましょう。
- 提出先：指定フォーム、メール、GitHub上の操作など、どこで提出するか
- 提出物：リポジトリ、公開アプリ、説明資料、所要時間など、何が必要か
- コードの指定：リポジトリ、ブランチ、タグ、Pull Requestなど、どの形で渡すか
- 公開範囲：公開指定、非公開指定、指定アカウントへの共有などの条件
- 期限：締切日時と、提出後の変更を認めるか
リポジトリを作る場所が指定されている場合は、自分のアカウントに新しく作ればよいとは限りません。指定リポジトリへの提出と、自分のリポジトリURLの提出を区別します。案内に指定がなければ、勝手に形式を変える前に採用担当者へ確認してください。
GitHub提出前の確認表｜URL・README・動作をまとめて点検する
次の表を手元の課題に当てはめて、「確認済み」「修正が必要」「応募先への確認が必要」を付けます。確認済みにするときは、実際に開いたURLや実行結果も残すと、提出文に必要な情報を拾いやすくなります。
| 確認項目 | 見るところ | 提出前の完了判断 |
|---|---|---|
| 提出先と提出物 | 指定フォーム・メール、リポジトリURL、アプリURL、追加資料 | 要項の提出事項がそろい、指定された方法で送れる |
| 公開範囲と権限 | Public／Privateの指定、共有先アカウント、招待の状態 | 指定範囲に合い、評価する人がアクセスできる手続きが済んでいる |
| 提出する版 | ブランチ、タグ、コミット、GitHub側の最新ファイル | 評価対象が分かり、ローカルだけに残った修正がない |
| README | 環境、導入・起動・テスト手順、設定、実装状況 | その課題に合う説明があり、実行した手順と一致する |
| 新しい環境からの起動 | 提出した版を別フォルダーへ取得し、READMEどおりに実行 | 必要なファイルがそろい、起動と指定機能の確認ができる |
| テストとビルド | 指定された確認方法、実行コマンド、成功・失敗・未実施 | 実際の結果を記録し、確認していないことを成功と書かない |
| 秘密情報 | 設定ファイル、コード、履歴、ログ、画面画像 | 共有できないキー・認証情報・個人情報を含めていない |
| 未実装・既知の問題 | 要件との対応、発生条件、影響、残っている作業 | 未完了部分を隠さず、確認できる形で説明している |
| 公開アプリと提出記録 | 要求されたアプリURL、アクセス条件、送信完了表示 | 提出する版を確認でき、送信した内容と完了の記録が残っている |
全部を同じ方法で確認する必要はありません。例えば、非公開リポジトリはログアウトした画面から開けなくても正常です。公開指定ならログアウト状態から閲覧を確かめ、非公開指定なら指定された相手への共有手続きを確かめます。
公開・非公開は応募先の指定に合わせる｜URLだけでは権限を渡せない
GitHubのPublicリポジトリはインターネット上の誰でもアクセスできます。Privateリポジトリは、所有者や明示的にアクセスを共有された人などに閲覧が限られます。非公開のURLを送っただけで、採用担当者が読めるようになるわけではありません。
公開指定なら、公開してよい内容かを確認してから切り替える
Publicの指定がある場合は、提出するコードや資料に共有できない内容がないかを先に確認します。企業から渡された課題文、データ、画像などに公開の制限がある場合は、その条件も守ります。別の企業の課題が公開されていることを、自分の課題を公開する根拠にはできません。
公開範囲の確認では、リポジトリ名の近くにあるPublic／Privateの表示と、送信するURLを確認します。公開指定なら、ログアウトしたブラウザーなどでURLを開き、READMEと指定した版のファイルが見えるかも確かめましょう。
非公開指定なら、指定された相手へのアクセスを確認する
個人所有のリポジトリへ共同作業者を招待する場合、GitHub公式案内では、相手が招待を承諾するとアクセスできるようになると説明されています。招待を送った状態と、承諾された状態を区別してください。
共有先のGitHubユーザー名や管理方法が案内されていなければ、採用担当者へ確認します。自分のログイン中の画面で開けることだけでは、相手のアクセス確認になりません。必要に応じて、指定アカウントから閲覧できるかを先方へ確認しましょう。自分のパスワードやアクセストークンを渡す方法で共有しないでください。
公開範囲が不明なときは、「課題のリポジトリはPublicとPrivateのどちらで提出する指定でしょうか。Privateの場合、共有先のGitHubアカウントと必要なアクセス設定をご教示ください」と聞くと、確認する条件が伝わります。
リポジトリの公開と、アプリの公開は別に確認する
リポジトリURLはソースコードを見るためのURL、デプロイ先URLはアプリを使うためのURLです。コードを公開していても、アプリがインターネット上で動くとは限りません。両方を求められている場合は、両方を開いて確認します。
公開アプリにサービス側のログインが必要な状態になっていないか、指定された機能をそのURLから使えるかも見ます。認証が課題の要件なら、企業の指定に沿って評価用のアクセス方法を案内してください。
コーディングテストのREADMEは、評価者が起動・確認できる順番で書く
GitHub公式資料でも、READMEはプロジェクトの内容や使い始める方法などを伝えるものと説明されています。課題提出では、長い自己紹介より、評価する人が迷わず起動し、実装内容を確認できる説明を先に置きます。
応募先がREADMEの項目や書式を指定している場合は、その指定を優先します。指定がなければ、次の構成例を自分の課題に合わせて使えます。括弧内は記入欄です。実際の値・コマンド・確認結果へ置き換えてから提出してください。
# 課題名
（何を作ったかを1〜2文で説明）
## 実行環境
- 言語・ランタイム：（確認した名前とバージョン）
- パッケージ管理ツール：（名前とバージョン）
- 動作確認環境：（OS・ブラウザーなど、必要なもの）
## セットアップ
1. （指定した版を取得する手順）
2. （依存関係を導入するコマンド）
3. （必要な環境変数・初期データの設定手順）
※ 秘密情報の実値は記載しない
## 起動・確認方法
- 起動コマンド：（実際に実行したコマンド）
- 起動後のアクセス先：（URLまたは操作方法）
- 確認する操作：（入力・操作と期待される動作）
## テスト・ビルド
- テスト：（コマンドと実行結果。未実施ならその旨）
- ビルド：（必要な場合のコマンドと実行結果）
## 実装した内容
- （要件と、それに対応する機能）
## 未実装・既知の問題
- （対象機能・発生条件・影響。なければ確認範囲を書く）
## 設計・参考資料
- （判断した理由や、指定に応じた参考資料・利用ツール）
- （所要時間など、応募先が求める追加項目）例えば環境に「Node.js」とだけ書くより、実際に確認したバージョンを記載すると、相手が環境を合わせやすくなります。ただし、Node.jsを使わない課題にこの項目をそのまま残す必要はありません。言語や構成に合う情報へ置き換えます。
セットアップには、「起動前に必要なこと」を順番に書きます。依存関係の導入、環境変数の設定、データベースの初期化などが必要なら、その手順が抜けていないか確かめてください。起動するディレクトリがプロジェクト直下ではない場合は、その場所も示します。
設定の見本として.env.exampleなどを用意する場合は、変数名とダミー値で構成し、必要な値をどのように設定するかを説明します。実際の秘密情報をREADMEや見本へコピーせず、評価用の値の受け渡しは応募先の指定に従います。
参考コード・ライブラリ・AIについて、利用可否や報告事項の指定がある場合は、実際に使った内容をその条件に沿って記載します。READMEに書けば禁止された利用が認められるわけではありません。使用ルールに不明点が残っている人は、検索・資料・AIを別々に確認する方法も見てください。
「自分のPCで動く」から進めて、提出した版を新しいフォルダーで確認する
作業中のフォルダーには、まだGitHubへ送っていないファイルや、以前に作った設定が残っていることがあります。提出前は、GitHubにある評価対象の版を別の空のフォルダーへ取得し、READMEだけを見て導入・起動すると、手順の抜けを見つけやすくなります。
- GitHub側で提出対象のブランチ・タグなどを確認し、その版を新しいフォルダーへ取得する
- READMEに書いた順番で依存関係や設定を準備する
- 起動コマンドを実行し、指定された主要機能を試す
- 要求されたテストやビルドを実行し、結果を記録する
- 手順を補ったらREADMEを更新し、更新後の内容をGitHubで確認する
この確認は、別のOSや採用担当者の環境での動作を保証するものではありません。それでも、ローカルにしかないファイルへ依存していないか、コマンドや設定の説明が欠けていないかを確認できます。指定環境がある課題は、その環境でも必要な確認を行います。
依存関係の管理ファイルや、使用するツールで必要なロックファイルなどが、提出した版に含まれているかも見ます。一方、生成物やキャッシュまで何でもアップロードするのではなく、課題の指定とプロジェクトの構成に合わせます。
テストは「実行したコマンド」「対象」「結果」を分けて記録しましょう。起動確認だけで「すべてのテストが成功」と書いたり、実行していないビルドを「問題なし」と書いたりしないことが大切です。失敗が残っている場合は、その結果と影響を説明します。
公開アプリの提出もあるなら、デプロイした内容が提出コードと対応しているか、画面に最新の修正が反映されているかを確認します。ブラウザーで画面が出ることに加え、要件にある操作を試してください。
秘密情報と未実装部分は、送信前に確認する
秘密情報は最新ファイルだけでなく、履歴や画像にも注意する
課題で使ったAPIキー、認証情報、個人情報が、コード・設定ファイル・ログ・スクリーンショットに残っていないかを確認します。公開予定なら公開前に、非公開提出でも共有してよい内容かを見ます。
.gitignoreに書けば、すでにGitで管理されているファイルも自動的に消える、とは考えないでください。GitHub公式資料でも、すでに管理されているファイルを無視するには、別途管理対象から外す必要があると説明されています。
さらに、最新のファイルからキーを削除しても、過去のコミットに残っている場合があります。GitHubへ送ってしまった秘密情報を見つけた場合は、GitHub公式資料に沿って、まず該当する認証情報の失効・再発行などを検討し、必要な履歴の対応を確認します。企業から提供された情報なら、扱いについて先方にも連絡してください。
未実装は「何ができないか」と「どこまで確認したか」を書く
未実装部分がある場合は、完成したように見せず、対象の要件と現在の状態を対応させます。例えば「一部未実装」だけでは、評価する人がどの機能を試せばよいか分かりません。
書き方の例は、「一覧表示と検索は実装済み。並び替えは未実装。検索結果が0件の場合の表示は確認済み。通信失敗時の画面は未確認」のように、機能と確認状況を分ける形です。これは記事用の例なので、自分の課題の事実へ置き換えてください。
未実装を明記すれば必ず受理される、合否に影響しない、ということではありません。要件未達のまま提出してよいか迷う場合は、締切前に状況を伝えて確認します。説明には、できていること、残っていること、必要な対応を具体的に書きましょう。
提出メッセージの例｜URLと評価対象の版を短く伝える
指定フォームがある場合は、その欄に必要な情報を記入します。メール提出なら、応募職種・氏名・課題名を示したうえで、URLと必要な追加事項をまとめると、採用担当者が提出物を確認しやすくなります。
次はメールの構成例です。アプリURLやブランチ・コミットなどは、指定がある場合や評価対象を示す必要がある場合に記載し、不要な項目は削除してください。
件名：コーディング課題提出／応募職種／氏名
採用ご担当者様
お世話になっております。応募中の〇〇です。ご案内いただいたコーディング課題を、以下のとおり提出いたします。
・課題名：〇〇
・リポジトリURL：（指定した提出URL）
・評価対象：（必要に応じてブランチ・タグ・コミットなど）
・アプリURL：（提出が必要な場合）
・起動・テスト手順：READMEに記載
・追加事項：（所要時間など、指定された情報）（未実装・既知の問題がある場合は、対象とREADME内の記載箇所を簡潔に説明）
ご確認のほど、よろしくお願いいたします。
氏名
非公開リポジトリを共有する場合は、指定アカウントへの招待など、実際に済ませた対応も必要に応じて伝えます。承諾を確認していないのに「アクセス確認済み」とは書かないでください。
送信直前に、メッセージへ貼ったURLを開き直します。プロフィールURLや別の課題のURL、編集途中のブランチを送っていないかを確認し、送信後は完了画面や送信メールを残します。提出後の修正は案内に従い、勝手に評価対象を入れ替えず、変更が必要なら扱いを確認してください。
コードがあること、相手が読めること、手順どおりに動かせることは、別々の確認です。提出要項から必要なものを拾い、公開範囲、README、提出した版の動作を順番に確認すると、何を直してから送るべきかが分かります。
参考資料
- ゆめみ：フロントエンドコーディング試験 — 公開リポジトリ・デプロイ先URL等の提出事項と、ドキュメンテーションを含む評価観点の例。
- GitHub Docs：About repositories — Public／Privateのアクセス範囲。
- GitHub Docs：Inviting collaborators to a personal repository — 個人リポジトリへの招待と、相手の承諾後のアクセス。
- GitHub Docs：About the repository README file — READMEで伝える内容と、プロジェクトを使い始めるための説明。
- GitHub Docs：Ignoring files — .gitignoreの役割と、すでに管理されているファイルの扱い。
- GitHub Docs：Removing sensitive data from a repository — 秘密情報の失効・更新と、履歴に残った情報への対応。
公式資料の確認日：2026年10月3日。実際の提出形式・公開範囲・期限は、自分に届いた選考案内で確認してください。
