先に結論
- READMEは「何を作ったか・どう動かすか・自分が何をしたか」を短く伝える説明書です。
- 未経験IT転職では、使用技術の羅列より、本人の担当・工夫・検証・未対応の範囲を示します。
- このページの7項目テンプレートを自分の事実で埋め、秘密情報と動作手順を確認してから共有してください。
GitHubに成果物を置いたものの、READMEに何を書けばよいか迷っている人向けの記事です。作品の選び方は未経験転職のポートフォリオの作り方、面接全体の準備は未経験IT転職の面接対策で扱っています。ここでは、選んだ一作品の説明書を完成させます。
READMEで伝わること・伝わらないこと
GitHub公式ドキュメントは、READMEをプロジェクトの内容や使い始め方などを伝えるファイルとして案内しています。リポジトリのルートにREADME.mdを置けば、通常はリポジトリ画面に表示されます。ここで扱うのは作品のREADMEで、自己紹介用のプロフィールREADMEとは別です。GitHub公式：READMEについて
説明を整えるメリットは、読む人が目的・操作・本人の担当を探しやすくなり、面接でも同じ材料を使えることです。一方、書く時間が必要で、作品を更新したら説明も更新する手間があります。READMEがあるだけで採用されたり、実務能力が証明されたりするわけではありません。提出物の形式や評価方法は応募先によって異なります。
まだ作品がない人、コードを見せない職種の応募者、勤務先の非公開資料しか用意できない人には、まずGitHubへ公開する方法は向きません。自作の検証記録や架空データの手順書など、公開してよい材料を先に選び、応募案内に合う形式へ整理してください。
成果物を説明する7項目
| 項目 | 書く内容 | 確認する質問 |
|---|---|---|
| 1 目的と利用者 | 誰のどんな困りごとを想定したか | 学習用の想定と実際の利用を分けたか |
| 2 主な機能 | 確認できる機能、画面例、デモ | 未実装の機能を混ぜていないか |
| 3 動かし方 | 前提環境、設定、起動、確認操作 | 他の人が同じ順で試せるか |
| 4 使用技術 | 言語・主要ライブラリ・確認したバージョン | 使っただけの技術を得意と書いていないか |
| 5 自分の担当 | 教材・共同制作・AIの利用と本人の変更範囲 | コードと説明の対応を示せるか |
| 6 工夫と検証 | 課題、変更理由、試した条件と結果 | 結果を再確認できる記録があるか |
| 7 制約と次の改善 | 未対応、既知の不具合、改善予定 | 予定を実績として書いていないか |
最初の画面で概要が分かる順番にする
冒頭は作品名と目的を数行で示し、画面例やデモへの案内を続けます。長い学習日記から始めず、詳細な試行錯誤は後半へ置いてください。スクリーンショットは実際の機能と一致するものを使い、画像が見えなくても内容が分かる説明を添えます。
「動く」と「検証した」を具体化する
「正常に動作」だけでは範囲が曖昧です。たとえば、正常入力・空欄・不正な入力で何が起きたか、どの環境で確認したかを書きます。速度改善を述べるなら測定条件と比較値を残し、計測していない効果は数値化しません。教材どおりに動かした範囲と、自分で追加したテストも分けます。
コピーして埋めるREADMEテンプレート
以下は編集部が整理した応募準備用の型で、GitHubの必須書式ではありません。角括弧を自分の事実に置き換えます。起動コマンドは構成ごとに異なるため、汎用のコマンドをそのまま転記せず、実際に確認した手順だけを書いてください。
# [作品名]
[想定する利用者]の[困りごと]を想定した学習用の[アプリ／ツール]です。
実際の利用状況：[未利用／試してもらった範囲]
## 主な機能
- [実装済みの機能]
- [画面例への案内／デモURLと利用上の注意]
## 動かし方
確認環境：[OS、言語や実行環境のバージョン]
1. [必要な準備・依存関係の導入]
2. [設定方法。値の実物は書かない]
3. [実際に確認した起動手順]
4. [起動後に試す操作と期待する結果]
## 使用技術
[主要技術、バージョン、採用した理由]
## 自分の担当・参考にしたもの
教材・参考：[出典、利用条件]
本人の変更：[変更した機能やファイル]
共同制作：[担当範囲]
AIの利用：[使った工程、自分で確認した範囲]
## 工夫と検証
課題：[困った現象]
対応：[変えた内容と理由]
確認：[試した条件、結果、残った問題]
## 制約と次の改善
未対応：[できないこと、既知の問題]
改善予定：[次に試すこと。実装済みと分ける]教材を参考にした作品の書き換え例
説明用の架空例：「Pythonでタスク管理アプリを開発」だけでなく、「教材の追加・表示機能を参考にしました。自分で空欄の入力を拒否する処理を追加し、空欄・通常の文字・前後に空白がある文字を試しました。データは手元だけで保存し、複数人の同時利用は未対応です」と説明します。これは実体験ではなく書き方の例です。
AIがコード案を出した場合も、生成を依頼しただけの部分と、自分で理解して修正・確認した部分を分けます。「なぜこの処理か」「どこを変えると結果が変わるか」を説明できないなら、独力で実装したと書かず、理解を補ってから担当欄を更新します。
公開前は秘密情報・担当・動作を確認
- 秘密情報：APIキー、パスワード、個人情報、勤務先や顧客のデータがコード・設定ファイル・画像・過去の履歴に含まれていないか。
- 公開許可：教材、画像、共同制作物の利用条件と公開の許可を確認したか。勤務先の資料は無断で公開しない。
- 担当：作品全体と本人の変更を区別し、面接で一つの変更理由を説明できるか。
- 動作：記載した環境と手順で再確認したか。外部サービスの費用やアカウントが必要なら明記したか。
- 共有：リンク先を読み手が開けるか。公開リポジトリは一般の人にも見えるため、提出相手だけが見ると考えていないか。
もし鍵やトークンを公開してしまった場合、ファイルを消すだけで解決したと判断しないでください。GitHub公式は、まず該当する秘密情報の失効・更新を行う必要性を案内しています。履歴の扱いには共同作業への影響もあるため、GitHub公式の機微なデータの対処手順に沿って対応します。
公開してよいか判断できないときは、無理に公開せず、応募先の案内に従って提出方法を相談します。非公開リポジトリのURLを送るだけでは、権限のない相手は内容を確認できません。
面接はREADMEの一例を60秒で説明する
READMEを丸ごと読み上げる必要はありません。作品の目的、本人の変更、確認結果、残る課題を一つずつ選びます。60秒は練習用の目安で、面接の指定があればそちらを優先します。
説明の型
［利用者と目的］を想定して作りました。［教材等の利用範囲］を土台に、私は［変更］を担当しました。［理由］からその方法を選び、［条件］で［結果］を確認しました。まだ［制約］があり、次に［改善］を試す予定です。
応募先への接点は、求人の具体的業務を読んで補足します。作品で触れた技術が同じでも、業務経験と同等だと断言しません。書類へ整理する場合は職務経歴書の書き方、学習の理由と結び付ける場合は志望動機の作り方を参照してください。
まとめ：まず一作品の7項目を埋める
- READMEは概要・動かし方・本人の担当をつなぐ説明書。
- 教材・共同制作・AIの利用は、自分の変更と検証に分けて書く。
- 未対応や未計測は隠さず、改善予定と実績を分ける。
- 秘密情報・公開許可・リンク・動作手順を確認して共有する。
今ある一作品について、目的・機能・動かし方・技術・担当・検証・制約を一行ずつ書いてください。書けない項目は文章で埋めず、実物や記録を確認します。これが応募用READMEの最初の下書きになります。
最終確認日：2026年10月3日。GitHubの基本仕様と秘密情報の扱いは上記の公式資料で確認。7項目の構成、テンプレート、説明例、60秒の練習目安は編集部の提案です。READMEの提出だけで採用や選考通過を保証するものではありません。
