エンジニアの発信の使い方｜書類に書ける形にする【2026年版】
エンジニアの転職で「技術ブログを書いたほうがいい」「コードを公開したほうがいい」とよく言われます。ただ、何を書けば評価されるのかは、あまり具体的に語られません。
結論から言うと、評価されるのは「自分が詰まって、調べて、解決した記録」です。技術の解説記事ではありません。解説はすでに大量にあり、そこで差はつきません。
この記事では、書く内容の型と、それを職務経歴書にどう載せるかを整理します。
1. 結論：書くのは「詰まって解決した記録」
評価される記事の型
- 何をしようとしたか
- どこで詰まったか（エラーメッセージ、想定と違う挙動）
- 何を調べたか（検索した語、読んだドキュメント）
- どう解決したか
- なぜそれで解決したのか
この5つが揃っている記事は、書いた人の仕事の進め方が分かります。
評価されにくい記事の型
- 技術の一般的な解説（公式ドキュメントの要約）
- 教材の内容をなぞったもの
- 環境構築の手順だけ
これらが悪いわけではありません。自分の学習の記録としては有効です。ただ、選考の材料としては弱くなります。
差が出るのは3番目の「何を調べたか」です。ここが書いてある記事は、他の人の記事と明確に違います。
2. 発信の種類と使い分け
| 種類 | 向いている内容 | 選考での使われ方 |
|---|---|---|
| 技術ブログ | 詰まって解決した記録、設計の判断 | 書類に載せる。面接の話題になる |
| コードの公開 | 制作物、業務外で作ったツール | 実際に見られることがある |
| 技術系SNS | 学習の記録、日々の気づき | 継続の証拠になる |
| 勉強会での発表 | まとめた内容の共有 | 継続と対外的な活動の証拠 |
第二新卒の段階では、1行目と2行目を優先してください。3行目と4行目は、あれば加点ですが、なくても問題ありません。
すべてをやる必要はありません。ブログを月1本、または制作物を1つ。どちらかで十分です。
数より、1つあたりの中身です。10本の薄い記事より、1本の詳しい記事のほうが評価されます。
3. 編集長が相談を受けた話：ブログ1本で話が続いた
未経験からエンジニアに転職した方から、選考の話を聞きました。
相談者「ブログを3本しか書いてなかったんですが、面接で1本だけ深く聞かれました」
私「どの記事ですか」
相談者「文字コードでハマった話です。CSVを読み込むと文字化けして、原因が分かるまで2時間かかったという」
私「なぜその記事だったんでしょう」
相談者「面接官が『この記事、調べた過程が書いてあるのが良かった』と。他の2本は技術の解説だったので」
3本のうち、評価されたのは1本だけでした。
その1本には、第1章の5要素が入っていました。何をしようとして、どう詰まって、何を検索して、どう解決して、なぜそれで直ったか。
技術の解説記事は、書いた人が理解しているかどうかしか分かりません。一方、詰まった記録は、その人が問題に当たったときにどう動くかが分かります。
採用側が知りたいのは後者です。入社後に必ず詰まるからです。
4. 書く内容の見つけ方
「書くネタがない」という人が多いですが、探す場所は決まっています。
| 探す場所 | 出てくるネタ |
|---|---|
| 直近1週間で検索したこと | 検索履歴を見れば出てくる |
| エラーで止まった場面 | エラーメッセージをメモしておく |
| 公式ドキュメントを読んだ箇所 | なぜそこを読んだかが記事になる |
| 思った通りに動かなかった場面 | 期待と実際の差が記事になる |
| 人に聞いて解決したこと | 聞く前に何を試したかを書く |
1行目が最も簡単です。ブラウザの検索履歴を1週間分見れば、詰まった箇所が全部出てきます。
書くタイミングは、解決した直後です。時間が経つと、何に詰まっていたかを忘れます。「あんなに悩んだのに、今見ると当たり前」と感じるようになるためです。
その「当たり前になる前」の記録に価値があります。
メモの取り方
解決した時点で、次の3行だけメモします。
・やろうとしたこと：
・詰まった点：
・解決方法：
3行あれば、後から記事に展開できます。
5. 職務経歴書への載せ方
書いたものを、書類に載せる形にします。
載せる場所
職務経歴書の末尾に「その他の活動」または「技術的な取り組み」という欄を作ります。
書き方の例
【技術的な取り組み】
■ 技術ブログ（2025年11月〜、12本）
学習および業務の中で詰まった内容を記録しています。
直近では、CSVの文字コードの扱い、非同期処理の
エラーハンドリングについて書きました。
URL: （リンク）
■ 個人制作
前職の書店業務で手作業だった発注リストの集計を
自動化するスクリプトを制作。CSVを読み込み、
店舗別・分野別に集計してファイル出力します。
使用技術：Python、pandas
URL: （リポジトリのリンク）
書くべき3点
| 項目 | 内容 |
|---|---|
| 期間と本数 | 「2025年11月〜、12本」 |
| 内容の傾向 | 何について書いているか |
| 直近の内容 | 具体的なテーマを2つ |
「期間と本数」が最も効きます。継続していることが、そこで示せます。
URLを載せる場合の注意
中身が空、または教材のコードをそのまま置いているだけの場合、載せないでください。逆効果になります。見られる前提で載せてください。
6. 逆効果になる場合
1、更新が止まっている。最終更新が1年前だと、「続かない人」に見えます。載せるなら、直近3か月以内に更新があることが望ましいです。
2、内容が正確でない。技術的に誤った内容を公開していると、そこを指摘されます。自信のない内容は「調べた範囲では」と断りを入れてください。
3、前職や特定の企業の批判が書かれている。技術ブログでも、業務の愚痴が混ざっていると読まれます。
4、機密情報が含まれている。業務で得た情報を記事にする場合、社名、顧客名、内部のシステム構成は書かないでください。これは選考の問題ではなく、秘密保持の問題です。
| やってはいけないこと | 理由 |
|---|---|
| 業務のコードをそのまま載せる | 会社に帰属する資産 |
| 社内システムの構成を書く | 機密情報 |
| 顧客名や案件名を書く | 秘密保持義務 |
| 前職の批判を書く | 転職先でも同じことをすると思われる |
業務で学んだことを書く場合、一般化してください。「前職のシステムで」ではなく「あるWebアプリケーションで」のように、特定できない形にします。
制作物のREADMEに書くこと
コードを公開する場合、README（説明のファイル）の中身が評価を分けます。コードだけ置いても、意図が伝わりません。
書く6項目
| 項目 | 内容 |
|---|---|
| 何をするものか | 1〜2行で用途 |
| なぜ作ったか | 前職の業務での困りごとなど |
| 使った技術 | 言語、ライブラリ、ツール |
| 使い方 | 実行の手順 |
| 詰まった点と解決 | 最も読まれる部分 |
| 今後やりたいこと | 改善の余地を理解しているか |
5行目が本体です。ブログと同じで、詰まった記録が最も評価されます。
書き方の例
【作った理由】
前職の書店業務で、複数店舗の発注リストを
手作業で集計していました（週2時間）。
これを自動化するために作りました。
【詰まった点】
CSVの読み込みで文字化けが発生しました。
ファイルの文字コードがShift_JISで、
既定のUTF-8で読もうとしていたことが原因でした。
encodingを明示的に指定して解決しています。
【今後】
現在は1店舗分ずつ処理していますが、
複数ファイルをまとめて処理できるようにしたいです。
6行目の「今後」を書くと、現状の限界を理解していることが伝わります。「完成しました」で終わるより、判断できる人だと見られます。
7. 面接で聞かれる3問と答え方
Q1「ブログを書いている目的は何ですか」
回答例：「自分の記録として始めました。同じことで2回詰まるのを避けるためです。結果として、書くために調べ直すので、理解が深まる効果もありました。」
「アピールのため」と言わないでください。自分のために書いているという理由のほうが、継続の説明として自然です。
Q2「この記事について詳しく教えてください」
書いた内容は、必ず口頭で説明できるようにしてください。
回答例：「CSVを読み込むと文字化けする問題です。最初は読み込み方が悪いと思っていましたが、エラーメッセージに文字コードの記述があったので、そこから調べました。ファイルの文字コードがShift_JISで、既定のUTF-8で読もうとしていたことが原因でした。encodingを明示的に指定して解決しています。」
Q3「業務の内容は書いていますか」
回答例：「業務の内容そのものは書いていません。技術的に一般化できる部分だけを、特定できない形で書いています。社名やシステムの構成は書かない方針にしています。」
この質問は、機密情報の扱いを確認するために聞かれます。方針を明確に答えてください。
8. 続けるための時間配分
| 頻度 | やること | 目安時間 |
|---|---|---|
| 詰まったとき | 3行メモを取る | 3分 |
| 週1回 | 溜まったメモを見返す | 10分 |
| 月1回 | メモから1本記事にする | 1〜2時間 |
| 3か月ごと | 職務経歴書の記載を更新する | 15分 |
月1本で十分です。年12本になります。継続の証拠としては、これで足ります。
週に何本も書こうとすると続きません。続かないと、更新が止まった状態で残ることになり、第6章の1番目の状態になります。
3行メモを取る習慣が全部です。メモがあれば記事は書けますし、メモがなければ「何に詰まったか」自体を忘れます。
9. よくある質問
技術ブログは必須ですか
必須ではありません。あれば加点になりますが、なくても書類は通ります。制作物のほうが優先度は高いです。
どこで公開すればいいですか
技術記事の投稿サービスでも、自分で用意した場所でも構いません。継続しやすい場所を選んでください。
何本くらい書けばいいですか
期間と本数のバランスです。「6か月で6本」なら継続していると伝わります。1か月で10本書いて止まるより評価されます。
内容が初歩的でも書いていいですか
構いません。むしろ、第二新卒の段階では初歩的な内容のほうが自然です。重要なのは、調べた過程が書いてあることです。
業務で学んだことを書いていいですか
一般化できる範囲なら書けます。社名、顧客名、システム構成は書かないでください。
コードの公開だけでもいいですか
構いません。ただし、README（説明）に「何のために作ったか」「使った技術」「詰まった点」を書いてください。コードだけだと意図が伝わりません。
更新が止まっている場合は
載せないほうが無難です。または、再開してから3か月経ってから載せてください。
発信を始めるタイミングは
学習を始めた直後からで構いません。むしろ、初期の詰まった記録のほうが、後から書けない貴重な内容になります。
10. まとめ：今日やる3つのこと
エンジニアの発信で評価されるのは、技術の解説ではなく、詰まって解決した記録です。
1つめ、詰まったときの3行メモを始める。やろうとしたこと・詰まった点・解決方法。この3行があれば、後から記事にできます。所要3分。
2つめ、直近1週間の検索履歴を見て、ネタを3つ探す。「書くことがない」と思っていても、履歴を見れば出てきます。所要15分。
3つめ、1本書くなら、第1章の5要素を入れる。何をしようとして、どこで詰まって、何を調べて、どう解決して、なぜそれで直ったか。所要1〜2時間。
月1本で十分です。続けることが、そのまま材料になります。
この先、読むべき記事
- 未経験エンジニアのポートフォリオ｜第二新卒が評価されるのは「何を作ったか」ではない（制作物の作り方）
- エンジニアの職務経歴書｜書く順番と3つの必須欄（書類への載せ方）
この記事を書いた人
木戸 悠介（きど ゆうすけ）／なぜキャリア？運営者。
23歳で上場企業子会社に新卒入社し、飲食・宿泊・レジャー領域のメディア広告営業を担当。25歳で第二新卒として障がい福祉領域のSaaS企業へ転職し、営業から営業企画へ職種を変えた経験を持つ。2ヶ月で10社に応募し2社から内定。現在は自分の会社を経営している。