リンクを開いた人は何を見るのか
見られているのは量ではありません。1つのリポジトリが「説明できる状態」になっているかどうかです。
よく見られる
- READMEで「何を解決するものか」が分かるか
- 動いている状態が確認できるか（画面・デモ）
- コードが読みやすいか、書き方が揃っているか
- コミットやプルリクエストの粒度と説明
あまり見られない
- 草（コントリビューショングラフ）の緑の量
- スターやフォロワーの数
- フォークしただけのリポジトリ
- チュートリアルをそのまま写した練習用リポジトリ
大事なのは、リンクを開くのは人事ではなく、多くの場合これから一緒に働くエンジニアだということです。その人は短い時間で「一緒に仕事ができそうか」を見ます。だから、数を並べるより、1つを丁寧に説明した方が伝わります。
逆に、空のアカウントやフォークだけが並んだアカウントは、リンクしない方がよい場合もあります。開いた先で何も分からないと、書類の印象まで下がります。
並べるのは3件でなく1件。
「説明できるもの」を1つ作る
業務コードを出せないときに見せるもの
業務で書いたコードは会社の資産なので出せません。代わりになるものは、思っているより身近にあります。
自分の困りごとを解決する小物
毎回手でやっている作業をスクリプトにする。規模は小さくてよい。動機が具体的なほど説明しやすい
技術記事・登壇資料
詰まったことをどう調べて解決したかを書いた記事は、コードと同じくらい伝わる
OSSへの小さな貢献
ドキュメントの修正や小さなバグ修正でも、プルリクエストのやり取りが見せられる
設定・構成のサンプル
DockerやTerraformの構成を、業務と特定できない形に作り直して置く
学習の成果物
チュートリアルの写しは弱いが、そこから機能を足した改造版は「自分で考えた部分」が見える
過去に作ったものの棚卸し
手元に眠っているコードにREADMEを足して公開する。新しく作らなくても1件は出せることが多い
新しく作る場合は、1〜2週間で終わる大きさにしてください。完成しないものを抱えるより、小さく動くものを1つ公開した方が早く効きます。題材は「自分が毎週やっている面倒な作業」から選ぶと、README に書く動機に困りません。
READMEの最小構成
READMEは、開いた人が30秒で「何のためのもので、何ができるか」を掴めれば十分です。
コードの読みやすさよりも先に見られるのがREADMEです。次の6つを上から並べるだけで、説明できる状態になります。
① 何を解決するものか（3行）
誰の、どの手間を、どう減らすものか。技術名から始めない
② 動いている様子
スクリーンショットか短いGIF。CLIなら実行例の貼り付けでよい
③ 使い方
前提（言語のバージョン）、インストール、起動コマンド。上から順に実行すれば動く形にする
④ 構成と選んだ理由
使った技術と、なぜそれにしたか。1〜2行で足りる
⑤ 詰まった点と対処
ここが読まれる。原因の切り分け方を書くと、仕事の進め方が伝わる
⑥ 今後の課題
未実装や既知の不具合を正直に書く。状態が分かると安心して読める
面接では、ここに書いたことがそのまま質問になります。READMEを書く作業は、技術的な質問の準備そのものです。うまく説明できないときの対処は技術の質問をうまく説明できないときにまとめています。
職務経歴書のどこに、どう書くか
置き場所は基本情報の連絡先が確実です。URLだけを置かず、10〜20字の説明を添えます。
| 置き場所 | 書き方 | 例 |
|---|---|---|
| 基本情報（連絡先の並び） | いちばん確実な置き場所。1行で、短い説明を添える | GitHub：github.com/example-user（個人開発のツール3件） |
| 保有スキルの下に「成果物」欄 | 2〜3件を箇条書き。1件につき1行の説明を付ける | 在庫管理ツール（Go / SQLite）：社内の集計作業を自動化する練習として作成 |
| 自己PRの中 | 文章の根拠として1つだけ触れる。並べない | 学んだ内容は小さなツールとして公開しています（github.com/example-user/stock-cli） |
| 案件ごとの経歴 | 業務の案件に個人のリンクを混ぜない。読み手が混乱する | ——（ここには書かない） |
書き方のNG / GOOD
GitHub：https://github.com/example-user
GitHub：github.com/example-user
└ 在庫管理CLI（Go / SQLite）：手作業の集計を自動化。設計の意図と詰まった点はREADMEに記載
短縮URLは使わないでください。飛び先が分からないリンクは開かれにくく、印刷された書類では入力もできません。このツールのPDFは紙面を画像として書き出すため、PDF上のリンクは押せません。読んで入力しやすい短いURLにしておくと確実です。
職務経歴書をMarkdownで管理してGitHubに置く方法自体は職務経歴書をMarkdownで書くで解説しています。書類そのものを公開する場合は、氏名・連絡先の扱いに注意してください。
公開する前の片付け
公開は取り消せません。特に認証情報と会社の資産は、出してしまうと実害になります。
認証情報が残っていないか
APIキー、トークン、パスワード、.envファイル。いま消しても、コミット履歴に残っていれば公開されたままになる
会社の資産が混ざっていないか
業務のコード、社内の固有名、顧客名、社内で使っている設定値。参考にした場合も、そのまま置かない
個人情報の範囲
本名・所属を出すかは自分で決める。コミットのメールアドレスが業務用になっていないかも確認する
READMEがあるか
説明のないリポジトリは、開いた人が2秒で閉じる。最低でも「何をするものか」の3行
動く状態か
書いてある手順で起動できるか、別のマシンで試す。依存のバージョンが固定されているかも見る
見せたくないものを下げる
練習用・放置しているリポジトリは非公開にする。数は少ない方が印象が良い
いちばん多い事故は、過去のコミットに残ったAPIキーです。最新のコードから消しても履歴からは読めるので、心当たりがあるときは新しいリポジトリを作り、必要なファイルだけをコピーして公開し直してください。鍵は必ず無効化して再発行します。
そもそも必要なのか
実務経験がある人の中途採用では必須ではありません。無理に用意するより、書類の中身を厚くする方が効く場面もあります。
効きやすい人
実務経験が浅い、未経験から転職する、職種を変える、業務で使っていない技術を使いたい
無くても困りにくい人
同じ職種で実務経験が積み上がっている。書類に判断と実績が書けている
応募先による違い
Web系の自社開発では見る傾向があり、SIerや社内SEでは重視されないことも多い。求人の書きぶりで判断する
時間がないとき
新しく作るより、書類の案件ごとの記述を厚くする方が通過率に効きやすい
経験が浅いうちは、作ったものが経験不足を補う材料になります。書類側の書き方は経験が浅い人の書き方を参照してください。並行して、書類の骨格は職務経歴書の書き方ガイドで整えられます。
リンクを載せる欄は作成ツールの基本情報に用意してあります。説明を添えた形でそのまま紙面に出せます。
よくある質問
Q.草（コントリビューショングラフ）が少ないと不利になりますか？
草の量そのものを見て判断されることは、実務経験者の採用ではあまりありません。見られるのは、リンク先に「読めるもの」があるかどうかです。逆に、毎日の小さなコミットで緑を埋めていても、中身がREADMEのない練習用リポジトリばかりだと評価にはつながりません。埋めることに時間を使うより、1つを説明できる状態にする方が効きます。
Q.非公開のリポジトリしかない場合、スクリーンショットだけ載せてもよいですか？
自分が個人で作ったものなら、スクリーンショットや画面の録画を見せる形でも構いません。会社の業務で作ったものは、画面であってもコードであっても出せません（社内の画面や顧客名が写り込む恐れもあります）。個人のリポジトリを非公開のままにしたい場合は、READMEと画面のスクリーンショットだけを公開用のリポジトリに切り出す方法もあります。
Q.ZennやQiitaの記事でも代わりになりますか？
なります。とくに「実装で詰まったことをどう調べて解決したか」が書かれた記事は、コードと同じくらい伝わります。技術ブログ、登壇資料、OSSへの小さなプルリクエストも同様です。いずれも書類には1行でリンクを添え、何について書いたものかを短く説明してください。
Q.会社のアカウントと個人アカウントは分けるべきですか？
業務で会社のアカウントを使っている場合、そのアカウントは業務用のままにして、個人のアカウントを別に持つのが無難です。個人アカウントで業務のコードを扱わないという線引きが分かりやすくなります。ただし、会社の規程で運用が決まっていることもあるので、そちらを優先してください。
Q.未完成のものを出してもよいですか？
構いません。ただしREADMEの先頭に「どこまで動いていて、どこが未実装か」を書いてください。状態が書かれていれば、未完成そのものは問題になりません。何も書かずに動かないものを置いておくと、丁寧に作れない人という印象になり得ます。
