登壇・OSS・執筆で案件獲得｜コード以外の実績の作り方と見せ方

コード以外の実績が案件獲得に効く理由

結論として、業務コードだけでは実力の外部証明が難しい場面が存在します。特に現場のコードがNDA下にあるフリーランスは、GitHub上の個人リポジトリだけでは説得力が伸びません。

登壇・OSS・執筆は、いずれも第三者の目に触れる形で公開された成果物であり、コードそのものを見せなくても実力を裏付けられます。エージェントと直接契約の両方で、参画前の面談時間で伝えきれない情報を補います。

スキルシートの実績欄で差がつく場面

エンドクライアントが直接読むスキルシートでは、案件名がイニシャル表記になりがちです。「大手SIer案件（案件名秘匿）」だけの記載よりも、そのプロジェクトで得た知見を登壇や記事に転じた実績が並ぶと、経歴の解像度が上がります。

スキルシートの粒度そのものの改善はスキルシートで単価を上げる書き方で整理しています。

単価交渉で「時給換算」以外の材料になる

単価は、相場に加えて本人の希少性、商流、稼働条件、上流経験など複数要因で決まります。登壇や執筆で扱ったテーマは、そのまま希少性の説明材料として使えます。交渉の現場では、「Kubernetes経験3年」より「Kubernetes運用の登壇実績3本」の方が具体像を伝えやすい傾向があります。

自分の単価レンジがどのあたりか気になる方は、フリーランスエンジニア単価診断で市場感を掴んでから交渉に入るとブレが減ります。単価の底上げ方針はフリーランスエンジニアの単価相場と単価の上げ方にまとまっています。

NDA下で業務コードが出せないときの代替になる

多くの常駐案件では、コミット権限つきのリポジトリを外部に見せられません。ここが業務外アウトプットが最も効く場面です。GitHubの公開活動、登壇スライド、寄稿記事のURLをまとめておくと、面談冒頭でひとつのフォルダとして提示できます。

GitHub本体の整え方はGitHubポートフォリオの作り方側で扱っています。

登壇・OSS・執筆の効果を比較｜案件獲得にはどこから始めるか

3つは相互補完なので、最終的には全部やるのが理想です。ただし、時間投下が限られる中でどれから着手するかは変わります。以下の比較表で判断してください。

迷ったらまず「使っているOSSへのドキュメントPR」から

最短で1件の実績を残すなら、OSSのドキュメント修正が取り組みやすい方法です。現業で日常的に使っているOSSのREADMEやチュートリアルにある小さな誤記・古い記載を直すPRなら、規模が小さいプロジェクトでは早ければ数日〜数週間でマージされることがあります。コードのPRは要件把握とテストで時間がかかるため、初回はドキュメント側から入るのが現実的です。

ミニFAQ: GitHubの草（コミット履歴）だけでは足りないのか

補足として、コミット履歴の連続は「毎日手を動かしている」証拠にはなりますが、内容の質までは伝わりません。案件応募の場では「何を作ったか」「誰の役に立ったか」まで見えるものが優先されるため、Public Repositoryのメンテナンス実績や外部OSSへのPRとセットで見せる方が効果的です。

OSSコントリビュートで実績を作る

結論として、案件に効くOSS実績は「規模」より「他人が読んで再現できる貢献の説明性」です。数千スターのプロジェクトへの1コミットより、中規模プロジェクトの継続コミッタの方が読み手には伝わります。

貢献の3段階｜Issue報告→ドキュメント→機能PR

以下の順で段階を踏むと、詰まりにくくなります。

1. Issue報告：バグや挙動の疑問を、再現手順つきで登録する

2. ドキュメント修正PR：READMEやコメントの誤字・古い記載を直す

3. バグ修正・小さな機能追加PR：Issueで拾ったものを自分で直す

いきなり機能追加PRを狙うと、要件のすり合わせで数週間止まることが多く、初回の成功体験が遠のきます。最初の1件はマージまでの心理的コストが低いドキュメントPRにするのが実務的です。

案件につながるOSSの選び方

「自分がそのOSSを使う案件で提案書に載せられるか」を基準にすると、選定を外しません。案件で使っているフレームワークやライブラリのエコシステムに寄せるのが最も効率的です。関連する案件例はフリーランス案件一覧から技術別に絞って眺めておくと、貢献先の選定精度が上がります。

参考として、GitHub公式のContributing to open sourceは、初回コントリビュートの実務手順をコンパクトにまとめています。

GitHubに残す見せ方

面談担当者は短時間で判断するため、プロフィール上部に主要情報を集めておくと読まれやすくなります。以下の情報が並んでいると、案件担当者が判断しやすくなります。

• Pinnedにコントリビュート先のリポジトリを1〜2枠

• READMEに主要PR・Issue解決の一覧をリンクで整理

• Contributionsのグラフから、直近1年の活動量が見える

GitHubの詳細な整備はGitHubポートフォリオの作り方を参照してください。

副業・掛け持ち時の判断基準

現案件のクライアントと利害が対立するOSSへの貢献は避けます。以下は事前にチェックしておく観点です。

• 現案件の競合サービスが利用しているOSSのメイン機能への大幅なPRは事前に相談

• 業務時間中のコミットは、業務委託契約書の「成果物の帰属」条項を確認

• 副業として業務時間外に取り組む場合も、就業規則で禁止されていないか

契約書の確認観点は業務委託契約書の確認ポイントで整理しています。

ミニFAQ: 業務時間中にOSSを触っていい？

補足として、準委任など時間稼働を前提とする契約では、稼働時間の使い方に制約があることが多く、OSSへの対応可否は契約条項とクライアント確認が前提です。業務で使うOSSのバグ修正PRは、業務改善の一環としてクライアントが歓迎するケースもあります。事前に「業務時間中に上流OSSへのPRを出す可能性がある」と共有しておくと後々の摩擦を防げます。

技術執筆（寄稿）で実績を作る

結論として、案件面談で効くのは「編集の手が入った媒体」への寄稿です。個人ブログは無編集で世に出せる代わりに、案件面談での希少性は伸ばしにくい面があります。

個人技術ブログの運用は技術ブログの始め方側で扱っており、本記事では媒体寄稿・雑誌・書籍を対象にします。

個人ブログとの違い｜寄稿・雑誌・書籍の位置づけ

3種類の違いを整理します。

寄稿にはCFP（企画公募）型の媒体と、編集部への直接持ち込み型があります。

寄稿を狙う媒体と提案

技術媒体には、著者側から企画を持ち込める編集部が複数あります。エンジニア向けメディアの多くは、記事末尾の運営情報に「著者募集」「企画持ち込み歓迎」の記載があります。

提案時に用意する要素は次の3つです。

• 企画タイトル（想定読者と、その読者が抱える具体的な悩み）

• 目次案（H2レベルで5〜8個）

• 執筆サンプル（過去のブログ記事や登壇資料）

技術媒体では、テーマの新規性だけでなく読者の悩みへの解像度が重視されることが多いです。抽象度の高い企画より、「自分の案件で3ヶ月詰まった話」の方が採用されやすい傾向があります。

執筆実績のクレジット化

掲載時に自分の名前で残るか、匿名になるかは事前に確認します。筆者クレジットが残る形での寄稿でないと、実績としての使い勝手が落ちます。掲載後は以下を控えておきます。

• 媒体名・掲載号・URL・ISBN（書籍の場合）

• 公開日と掲載期間

• 編集担当者名（次回企画持ち込み時の窓口として）

勉強会・カンファレンスの登壇で実績を作る

結論として、登壇は「登壇まで」よりも「登壇後」の資産化で実績としての価値が変わります。1回登壇するだけでは1年で賞味期限が切れるため、スライド公開・記事化まで1セットで組みます。

登壇機会の探し方

段階を踏むと採択率が上がります。

• LT（5分〜10分）：connpassやTECH PLAYで開催中の勉強会に応募

• 社外勉強会（20〜30分）：関連コミュニティのDiscordやSlackで枠に立候補

• カンファレンス（30分〜45分）：各カンファレンスのCFP（Call for Proposals）に提案

大規模カンファレンスでは、開催の3〜6ヶ月前にCFPが募集されることが多い傾向があります。年度前半に狙う場合は、前年秋には応募情報を集め始めるのが目安です。小規模勉強会は募集期間がより短いため、コミュニティのSNSを個別にフォローするのが実務的です。

CFP採択される話題の選び方

採択されやすい話題には共通点があります。

• 実案件で詰まった具体的な事例（成功談より、失敗と回避策）

• 数値がある（規模・スループット・削減率など）

• 聴衆が明日から試せる粒度

「AIの未来」のような大きな話題は、著名エンジニア以外では通りにくい傾向です。自分の案件の一部分を切り出す方が採択率は上がります。

登壇後の資産化

登壇直後の熱量があるうちに、数日以内に以下を残すのが理想です。

• スライドをSpeaker Deckに公開（登壇日を記載）

• 登壇内容を記事化してZennやQiita、または媒体寄稿に転載

• 動画が公開される場合はプロフィールにリンクを追加

登壇1回を、スライド公開＋記事化＋動画リンクの3成果物に増やすと、1テーマから3件の実績が残ります。

ミニFAQ: 登壇資料に会社の情報をどこまで出せる？

補足として、常駐先のクライアント名・システム名・実際の数値は原則NGです。一般には「金融系の勘定系」「月間◯千万リクエスト規模」といった業界カテゴリと桁感までに抑えるケースが多いですが、実コード掲載や具体表現の可否は契約書・秘密保持契約・クライアントの公開ポリシーを確認したうえで判断する必要があります。詳細はエンジニアがXで案件獲得につなげる発信術の機密管理セクションが参考になります。

3つを掛け合わせて相乗効果を出す

結論として、1トピックを3チャネルに展開する回し方が、時間対効果を最大化します。同じ知見を1回だけ発信するのはもったいない、というのが継続してきた人の共通見解です。

1トピック→複数チャネル展開の流れ

以下の順序で回すと、後工程ほど作業時間が短くなります。

1. 登壇（20時間）：資料作成が最も重い。ここでネタを固める

2. スライド公開（1時間）：登壇後にSpeaker Deckへアップロード

3. 記事化（10時間）：スライドを地の文と図に展開して寄稿

4. OSS PR（5〜20時間）：発表内容の中で「本当は上流で直せる」箇所を検出してPR化

登壇のネタが固まっている状態から派生させるので、記事化の作業時間は登壇の半分程度で済みます。

6ヶ月ロードマップ｜週次アクションの目安

0→初実績までの週次アクションを示します。実務経験3年前後で、平日夜と週末に週5〜10時間を確保できる人を想定した構成です。家庭状況や本業負荷が異なる場合は、期間を1.5〜2倍に伸ばすと現実的です。

案件・単価につなげる見せ方

結論として、実績はスキルシート・面談・営業DMの3箇所で使える形まで整えて初めて効きます。ただ残すだけでは案件担当者の目に触れません。

スキルシート「実績」欄への記載粒度

数値と成果物URLをセットで書くのが基本です。次のような書き方が読まれます。

• 「◯◯Conf 2026登壇（40分・録画公開あり・[URL]）」

• 「OSS ▲▲▲ に継続コントリビュート（マージPR12本・[Contributionsのリンク]）」

• 「技術書『□□□』第3章執筆（ISBN・出版年）」

成果物URL・時期・規模の3点セットを書くと、書類選考通過率が変わります。関連する記載パターンはスキルシートで単価を上げる書き方で詳しく扱っています。

エージェント面談での話し方

面談冒頭で経歴を語る際、業務経歴を語り終える前に「加えてコード外の活動として、◯◯を継続しています」と一言添えると、そこからの深掘りで自然に強みを伝えられます。エージェント側は単価交渉の材料を探しているため、公開されている数値や実績があると内部の推薦文にも書きやすくなります。

DM・直接営業での引用

エージェントを経由しない直接契約では、営業DMや初回メッセージに実績URLを1〜2本添えます。全部貼るとかえって読まれないので、案件テーマに合うものを厳選します。直営業のルートはフリーランスエンジニアの直案件の取り方、LinkedIn経由はLinkedInでフリーランスエンジニアが案件獲得で扱っています。

よくある失敗と対策

3つ挙げます。いずれも実際に発生した相談パターンです。

数を追いすぎて質が落ちる

対策として、四半期ごとに1〜2本を丁寧に残す方が結果として効きます。年間8〜10本の中途半端な実績よりも、年4本のうち1本を「代表作」と呼べる水準まで仕上げる方が、面談で語れます。

会社の機密・NDA違反

対策として、投稿前に必ず一晩置く運用が有効です。書いた直後は「これは大丈夫」と思っても、翌朝読み返すと業界名・数値・システム名が残っていることがあります。特に登壇資料は事前に契約担当者にレビューを依頼するのが安全です。

現案件クライアントとのコンフリクト

対策として、貢献先OSSの選定時にクライアントの競合サービスと関連が薄い領域を選びます。案件内で得たノウハウを、抽象化した一般論として発信するのは問題ありませんが、クライアント固有の仕組みを推測される粒度の情報は避けます。トラブル化した場合の対処はフリーランスエンジニアの直案件の取り方の契約リスクセクションも参考になります。

まとめ

コード以外の実績は、業務コードが出せない場面での代替証拠として最も効きます。登壇・OSS・執筆はいずれも他人の目に触れる形で残るため、面談・スキルシート・営業DMの3箇所で使えます。

要点は以下です。

• まずは使っているOSSへのドキュメントPRから着手。マージまで1〜3週間が目安

• 6ヶ月で1トピックを3チャネル展開すると、1テーマから3〜4件の実績が残る

• スキルシートにはURL・時期・規模の3点セットで書く

• 常駐先の機密・競合コンフリクト・副業規定の3点は事前に確認

• 単価交渉の材料としての希少性を、公開された成果物で裏付ける

自分の実績に合う案件のあたりをつけたい方はフリーランス案件一覧を、単価の目安を掴みたい方はフリーランスエンジニア単価診断を試してみてください。市場価値そのものの見立て方はエンジニア市場価値の診断5ステップで扱っています。