エンジニア転職でQiitaの記事を生かすコツと見せ方

Qiitaに書いた技術記事は、経験者のエンジニアの転職で、職務経歴書に書いた実績を裏づける材料になります。採用する側が記事から読み取るのは、いいねの数よりも、課題をどう捉えてどの案を選んだかという判断の過程と、それを他人に伝わる文章にできる力です。

Offers に掲載された正社員のエンジニア求人を読むと、技術ブログ・Qiita・登壇といった社外への発信は、多くが歓迎条件の項目として書かれていました。記事が無いと応募できないわけではなく、記事は評価を上積みする材料です。応募先の仕事に近い記事を数本に絞り、職務経歴書と面接で業務の実績と結びつけて見せるのが近道になります。

Qiitaの記事は転職で職務経歴書の実績を裏づける材料になる

経験者のエンジニアの選考で中心になるのは、職務経歴書に書いた業務の実績です。Qiitaの記事は、その実績を裏づけ、書類の短い記述だけでは伝わらない技術の理解の深さや考え方を見せる材料として働きます。

Qiitaは、運営会社のガイドラインで「エンジニアに関する知識を記録・共有するためのサービス」と位置づけられています（Qiita「Qiita コミュニティガイドライン」）。記事は誰でも読める場所に残るため、書類選考や面接の前に、採用する側が応募者の書いたものを確かめられます。

成果物全般が選考でどう扱われるかは「エンジニアの転職に成果物は必要か｜経験者の実績の示し方」で、求人票の必須条件・選考の流れまで含めて確かめています。

Offersの求人票では技術発信は歓迎条件に書かれることが多い

Offers に掲載された正社員のエンジニア求人の必須条件と歓迎条件を1行ずつ読むと、技術ブログ・Qiita・登壇といった社外への発信に触れる求人の多くは、歓迎条件の項目として経験を挙げていました（Offers（株式会社overflow）調べ・正社員のエンジニア求人 n=1,503・2022年3月〜2026年10月公開）。

歓迎条件の書き方は「Qiita等、エンジニア活動、技術情報発信経験」「GitHub、Blog等での技術情報の公開経験」「技術ブログ・登壇等、外部へのアウトプット経験」のようなものです。Qiitaを名指しする求人でも「Qiita等」と書かれ、Qiitaに限らない書き方です。どの場所に書いたかより、社外に技術の知見を出してきた経験そのものが見られていると読めます。

必須条件の欄で発信に触れる求人は、「公私問わず、日常的にブログや登壇等でアウトプットを出している方」「技術的な情報発信が得意な方、興味がある方」のように、求める人物像として姿勢や習慣を書くものが中心でした。記事の本数や評価の数を応募の条件にする書き方ではありません。

応募先の歓迎条件や人物像に発信の項目があれば、関係する記事の URL を職務経歴書に添えておくと、読み手がその場で確かめられます。必須スキル・経験と歓迎スキル・経験は、Offers Jobs のエンジニアの求人一覧から開く求人詳細で確認できる項目です。

Offersでは連携したQiitaの記事を企業が確認できる

Offers では、プロフィールに Qiita のアカウントを連携すると、候補者を探す企業がプロフィールの画面で技術的なアウトプットを確認できるようになります。Offers のヘルプセンター（企業向け）は、候補者が任意で連携した SNS（ソーシャルネットワーキングサービス）がプロフィールに表示され、GitHub と Qiita は技術的なアウトプットを確認できる SNS だと案内しています（Offers ヘルプセンター「候補者のプロフィール詳細画面を確認する」・2025年6月更新）。

同じヘルプセンターによると、企業が見る候補者のスキルのスコアは、連携した SNS の公開情報をもとに、記事やリポジトリがどれだけ注目・評価されているかを偏差値にしたものです。Qiita から使うのは、総投稿記事数・コントリビューション数・フォロワー数と、投稿記事のタイトル・タグ・いいね数とされています（Offers ヘルプセンター「スキルとは何ですか？」・2024年8月更新）。

記事やリポジトリが無く判定できないスキルは、スコア50点と表示される仕様です。スコアは平均との差を示す偏差値で、Qiita では投稿へのいいね数を基準値に算出されるため、連携した記事への評価が平均より少なければ50点を下回ることがあります（Offers ヘルプセンター「スキルの点数(スコア)の算出方法について教えて下さい」・2023年9月更新）。

評価を集めた記事があれば連携し、記事が無い・少ないときは職務経歴書の記述で実績を示せば十分です。Offers に登録すると、プロフィールで Qiita や GitHub のアカウントを連携できます。

転職で見せるQiitaの記事は応募先の仕事に近いものから選ぶ

転職で前に出すQiitaの記事は、応募先の求人票に書かれた技術や業務に近いものから選びます。読み手は「この人に何を任せられるか」を知りたいので、職務経歴書の実績の裏づけとして読まれるのは、応募先の仕事と結びつく記事です。

応募先ごとに、求人票の必須条件・歓迎条件に出てくる技術名と自分の記事のタグを並べると、前に出す記事が決まります。合う記事が無い応募先では、記事より職務経歴書の業務の記述を厚くするほうが得策です。

いいねの数より業務とのつながりで選ぶ

前に出す記事は、いいねやストックの数より、業務の実績とつながるかで選びます。広く読まれた入門記事より、読者は少なくても自分が担当した課題を掘り下げた記事のほうが、面接で深掘りされたときに経験の裏づけとして話せるからです。

評価の数が多い記事は、技術の説明が多くの読者に役立った証拠として添えれば十分です。数そのものを職務経歴書の主張の中心に置くと、記事の中身より数字の話に面接の時間が流れてしまいます。

Qiita以外に書いた記事も同じ材料として添えられる

技術記事を書いた場所がQiitaでなくても、転職では同じ材料として扱えます。Offers の求人票の歓迎条件でも「Qiita等」「GitHub、Blog等」のように場所を限らない書き方が見られ、問われているのは書いた場所より、社外に知見を出してきた経験のほうです。

Zenn や個人のブログ、登壇の資料に分かれて記事があるなら、職務経歴書の「技術発信」の欄に場所ごとに並べ、応募先に関係するものに印を付けておくと読み手が迷いません。Qiitaに同じ内容を書き直して1か所に集める必要はなく、それぞれの記事の URL を添えれば足ります。

投稿の数を増やすためだけの記事は書かない

転職のために短期間で記事の数を積み増すのは避けます。Qiitaのガイドラインは、Contribution（記事が受けた評価などから決まる Qiita 上の数値）を増やすだけを目的にした投稿をやめるよう求めています（Qiita「Qiita コミュニティガイドライン」）。

採用する側も、似た内容の短い記事が短期間に並んでいれば、転職の直前に整えたものだと受け取られがちです。本数を増やすより、すでにある記事の誤りを直し、今の理解で追記したほうが、学び続ける習慣として伝わります。

職務経歴書ではQiitaの記事を関係する実績の横に添える

職務経歴書では、Qiitaの記事を関係するプロジェクトの記述の横に URL と1行の説明で添え、末尾に「技術発信」の欄を設けて主な記事をまとめます。プロフィールの URL だけでは、どの記事が応募先に関係するのかを読み手が自分で探す手間が残るからです。

■プロジェクト：決済基盤の刷新（2023年4月〜2024年3月）
・役割：テックリードとして外部向けの API（Application Programming Interface）の設計と移行の計画を担当
・関連する記事：旧システムと並行稼働させて差分を照合した移行の進め方
  https://qiita.com/<ユーザー名>/items/<記事の識別子>

■技術発信
・Qiita：https://qiita.com/<ユーザー名>
  ・非同期処理のキューを選んだときの比較の観点（応募先の業務に近い記事）
  ・本番で起きたメモリリークの切り分けの記録

添える記事は、応募先に関係するものを2〜3本に絞ると読まれやすくなります。記事ごとに「何の課題を、どう解いた記録か」を1行で書いておけば、読み手は開く前に読む価値があるかを判断できます。職務経歴書の全体の構成は「エンジニアの履歴書・職務経歴書｜52人調査と書き方」を参考にしてください。

記事とプロジェクトの記述の食い違いをなくしておく

職務経歴書に添えた記事と、プロジェクトの記述の時期・役割・技術がずれていないかを確かめておきます。記事では個人で検証した内容なのに、職務経歴書では業務で導入したように読めると、面接で確かめられたときに説明が苦しくなります。

業務の話を個人の検証として一般化して書いた記事なら、職務経歴書の側に「業務で得た知見を、固有の情報を外して記事にしたもの」と一言添えておくと、読み手が混同しません。

会社の技術ブログに書いた記事は担当した範囲を添えて示す

在籍中の会社の技術ブログに書いた記事も、すでに会社が公開しているものなので、職務経歴書に URL を添えて実績の裏づけに使えます。会社の名義で公開された記事は、共著や編集の手が入っていることもあるため、自分が書いた範囲や担当した検証を一言添えておくと、面接で確かめられたときに説明がぶれません。

会社の記事は会社が公開を決めたものなので、面接でも記事に書かれた範囲であれば業務の中身に触れて話せます。業務の実績を示す記事が会社の技術ブログにしか無い場合は、その記事を職務経歴書の中心に置き、Qiitaの記事は学び続ける習慣を示す補足に回すとよいでしょう。

面接ではQiitaの記事を題材に判断の理由を話す

面接でQiitaの記事に触れられたら、記事に書いた結論を繰り返すより、背景・比べた案・選んだ理由・結果・今ならどうするかの順で話します。面接官が記事から確かめたいのは、書かれた手順そのものより、その判断に至った筋道と、そこから何を学んだかです。

数年前に書いた記事は、今の理解とずれている箇所を読み返して把握しておきます。「当時はこう判断したが、今は別の方法を選ぶ」と自分から言えると、記事の古さが学び続けている証拠に変わります。技術的な質問への準備は「エンジニア面接の技術質問｜4種類の準備と答え方」も参考にしてください。

業務で得た知見を記事にするときは会社の情報と権利を確かめる

業務で得た知見をQiitaに書くときは、社名・サービス名・顧客の情報・公開前の機能・非公開の数値を外し、構成や手順を一般化して書きます。業務のコードや資料をそのまま貼るのは避けてください。

経済産業省は、営業秘密として法的に保護される条件に、秘密として管理されていること、事業活動に有用であること、公然と知られていないことの3つを挙げています（経済産業省「秘密情報の保護ハンドブック」・最終改訂2024年2月）。社内で秘密として扱われている情報を記事に書けば、転職の材料どころか、在籍中の会社との問題になりかねません。

権利の面では、著作権法の職務著作の定め（第15条）があります。会社の企画のもとで社員が職務として作った著作物は、要件を満たせば会社が著作者になり、プログラムは会社の名義で公表するという要件を満たす必要がありません（文化庁「著作権テキスト －令和7年度版－」）。業務で書いたコードは、記事のために書き直した最小限の例に置き換えます。

Qiitaのガイドラインも、他人の書いたソースコードなどを権利者の許諾なく複製して掲載しないよう求めています（Qiita「Qiita コミュニティガイドライン」）。判断に迷う内容は、就業規則や秘密保持の誓約書、社外発信のルールを確かめてから書いてください。

これからQiitaに書くなら業務の課題を一般化する

転職を考え始めてからQiitaに書くなら、題材は業務で解いた課題を、固有の情報を外して一般化したものにします。業務の実績と結びつけて説明でき、応募先の仕事に近い記事が自然に増えるからです。

• 直近の半年で時間をかけて解いた不具合や性能の課題を、再現できる最小の例にして書く
• 技術選定で比べた案と決めた理由を、比べた観点の表にして残す
• 応募したい職種の求人票に出てくる技術のうち、触ったことはあるが説明できないものを検証して書く
• 公開済みの記事の誤りを直し、今の理解で追記する

書いた記事は、ポートフォリオの一部として職務経歴書や GitHub のプロフィールからたどれるようにしておきます。職種ごとのポートフォリオのまとめ方は「エンジニアのポートフォリオ一覧｜職種別の中身と作り方」が詳しい内容です。

エンジニア転職とQiitaの記事の要点

エンジニアの転職でQiitaの記事は、応募の条件ではなく、職務経歴書の実績を裏づけて評価を上積みする材料です。Offers の正社員のエンジニア求人でも、技術ブログ・Qiita・登壇などの発信は多くが歓迎条件に書かれ、必須条件の欄では求める人物像として姿勢や習慣を書くものが中心でした（Offers（株式会社overflow）調べ・正社員のエンジニア求人 n=1,503・2022年3月〜2026年10月公開）。

見せる記事は応募先の仕事に近いものを数本に絞り、職務経歴書では関係するプロジェクトの横に添え、面接では判断の理由と今ならどうするかまで話せるようにしておきます。業務の知見を書くときは、会社の秘密情報と職務著作に触れない範囲に一般化してください。応募先の歓迎条件に発信の項目があるかは求人ごとに違うので、Offers Jobs のエンジニアの求人一覧で条件を確かめながら、前に出す記事を選んでいきましょう。