技術ブログとは——採用広報と技術共有を一つの記事に詰め込まない

例えば、架空のチームでエンジニアがキャッシュ方式を移行した経緯を記事にする。対象の負荷、比較した案、選んだ理由、残った制約まで書いてある。「チーム文化も入れよう」「社員紹介と求人も足そう」という意見が出る。情報は増えたが、技術者は判断の続きを探し、採用候補者は自分が誰と何をするのかを探す。

技術ブログとは、企業や技術組織が、開発で得た知識、判断、手順、失敗と学びを、特定の技術読者が再利用できる形で公開する媒体である。会社の公式発信なので、個人のメモをそのまま出すのではなく、読者に役立つ範囲を選び、技術的な事実と公開可否を確かめる。

技術ブログは、採用候補者が組織を知る材料にもなる。ただし、技術者が解きたい問いと、候補者が知りたい仕事、役割、文化を一つの本文ですべて答える必要はない。元の開発記録と公開できる事実を共有し、技術記事と採用記事を分けて相互に結ぶ方が、読者は自分に必要な答えを追いやすい。

本稿では、一つの開発記録を二つの読者へ分ける企画票、技術確認と公開確認の役割、公開後に見る数字を整理する。採用へ役立つ可能性を捨てず、技術記事の中心を求人文言で薄めないための方法である。

技術ブログとは、技術者の判断を再利用できる公開記録

技術ブログの中心にあるのは、会社が新しい技術を使っているという宣言ではない。ある条件で何が問題になり、どの案を比べ、なぜ一つを選び、結果をどう確かめ、何がまだ分からないかを公開することである。読む人は、その判断を自分の条件へ持ち帰り、試すか、採らないか、追加で調べるかを決められる。

GitLabのBlog Handbookは、同社ブログをDevSecOpsの専門家を中心とする読者へ役立つ情報を共有する場と説明する。社内向けや個人的な内容は合わない場合があるとし、公式な声として内容を慎重に確認すると明記している。[1] これは一社の運用方針だが、技術ブログを「会社が書きたいことの置き場」ではなく「読者が使える情報の公開場所」と見る例になる。

公開する題材は、大きな発表や新規技術に限らない。移行の判断、障害後に変えた手順、性能測定で外した条件、顧客から繰り返し受けた質問も候補になる。技術広報のネタを探す方法で扱ったように、派手さより、読者が同じ場所で止まっているか、根拠を安全に示せるかを見る。

ただし、公開記録は社内記録のコピーではない。顧客名、脆弱性、個人情報、契約上の秘密を除き、前提を知らない読者が使える順番へ直す。数値を伏せるなら、比較が成立する条件まで消していないか確かめる。再現に必要な情報を出せない場合は、結論の範囲を狭めるか、公開を止める判断も必要になる。

技術ブログは媒体名であって、記事の品質を自動で保証しない。開発者が書いたから正しいとも、コードを載せたから役立つとも限らない。対象条件、事実の参照元、確認した人、更新日、対象外を読者がたどれるようにする。技術広報とは何かで整理した「技術を他者の判断材料へ翻訳する」という役割を、記事単位で果たすためである。

採用候補者と技術者では、読みたい答えが違う

同じキャッシュ移行を扱っても、同じ課題を抱える技術者は、自分の環境に当てはめられる根拠を探す。負荷の特徴、比較した選択肢、測定方法、移行の順番、結果、残った限界が必要だ。誰がどんな性格だったかより、どの条件で判断が変わるかが先に知りたい。

採用候補者は、同じ出来事から別の答えを探す。担当者はどの範囲を任され、意見が割れたとき誰が決め、他職種とどう協働し、失敗後に仕事の進め方をどう変えたのか。技術の細部は仕事の難しさを知る材料になるが、候補者が終えたいのは実装の再現ではなく、この環境で働くかを考えることである。

GoogleのTechnical Writing講座は、良い文書を、読者が作業に必要とする知識と技能から、すでに持つ知識と技能を引いたものとして説明する。役割だけでなく、対象への近さや経験差も考える。[2] 技術者と候補者は同じ会社の記事を読めても、既知のことと終えたい作業が違う。両方へ同じ説明を足すだけでは、その差を埋められない。

ここで記事を分ける。一つ目は技術記事で、判断の条件と過程を主にする。二つ目は採用記事で、仕事、役割、協働、意思決定を主にする。二本は元の開発記録、公開できる数値、時期、関係者の確認を共有する。技術記事の末尾から採用記事へ、採用記事から詳しい技術記事へ結べば、興味が重なる読者は続きを選べる。

求人への導線も記事本文と同じ役割ではない。技術記事の途中で突然、福利厚生や募集職種の説明を始めると、技術的な問いが中断される。共通フッターや著者欄の近くに、仕事を知りたい人向けのリンクを置けばよい。技術の続きを読みたい人には、関連する判断や手順の記事を優先して示す。

一記事に一人の読者と一つの作業を置く

書き始める前に、企画票へ「誰が、何を判断できるようになる記事か」を一文で置く。「エンジニア全般へ自社を知ってもらう」では広すぎる。「同じ規模のWebサービスでキャッシュ移行を検討するSREが、自分の条件で三案を比較できる」なら、必要な事実と不要な説明を選べる。

採用記事なら、「中途のバックエンドエンジニア候補者が、移行案件で任される範囲とレビューの進め方を理解し、面談で確かめたい点を決められる」とする。技術記事と同じ出来事を使っても、入れる人物、会話、役割の説明が変わる。技術の詳細は、仕事の難しさを理解するために必要な分だけ残す。

最低限の企画票は、次の六項目で始められる。欄を埋めることより、一つの項目へ複数の読者や行動を書いたときに、記事を分ける合図として使う。

• 主読者：誰が読むか。対象について何を知り、何を知らないか。
• 読後の判断：何を試す、比べる、止める、質問する状態になればよいか。
• 中心の事実：どの記録、測定、発言を根拠にするか。
• 公開範囲：何を出せて、何を伏せ、どこまで一般化できるか。
• 確認者：技術的な事実と公開可否を、それぞれ誰が確かめるか。
• 次の行動：関連する技術記事、採用記事、文書のどこへつなぐか。

DeNAの技術広報チームは2022年の実践報告で、Engineer Blogのガイドに目的、ターゲット、コンセプト、必須と推奨の品質を置いたと説明する。執筆宣言、上長確認、執筆、レビュー、公開、拡散も分けている。[3] これは業界の共通規格ではないが、原稿が完成してから目的や読者を直すのではなく、企画の入口で確かめる運用例になる。

記事を分けても、制作負担を必ず二倍にする必要はない。取材と事実確認は一度行い、共通の事実票を作る。技術記事では条件と選択を深く聞き、採用記事では役割と協働を追加で聞く。図や数値を両方で使うなら、説明、出典、利用許諾、更新担当を共通の記録へ戻せるようにする。

企画の材料が足りない場合は、二本とも薄く作らない。技術的な条件を出せないなら採用記事だけにする。反対に、人や組織の説明に許諾がないなら技術記事だけにする。媒体の空欄を埋めるより、主読者へ約束した答えを出せるかを優先する。

技術確認と公開確認を分けてレビューする

レビューで最初に分けるのは、技術的に正しいかと、会社として公開できるかである。一人が両方を確認できる場合も、問いは分けて記録する。すべてを「問題ありませんか」という一文で依頼すると、誰も担当していない項目が見えにくい。

技術確認者は、対象条件、比較した案、採用理由、測定方法、結果、限界、再現に必要な版を確かめる。事実と意見を分け、変更後に古くなる箇所を示す。数値が正しくても、測定期間や母数がなければ読者は自分の環境と比べられない。出せない条件が結論を左右するなら、表現を狭める。

公開確認者は、顧客や取引先を特定できる情報、個人情報、契約、脆弱性、第三者の画像やロゴ、将来の約束に見える表現を確認する。さらに、主読者が冒頭で分かるか、採用向けの段落が技術説明を止めていないか、関連する次のページへ自然に移れるかを見る。

会社の公式発信では、専門家が自由に書けることと、確認なしで公開できることは同じではない。GitLabも、同社ブログを公式な声として慎重に確認すると説明する。[1] 技術広報の運営体制で整理したように、技術者、編集者、広報の誰か一人を門番にするのではなく、それぞれが止めるべき条件を先に決める。

採用記事では、登場する人が自分の役割と発言を確認し、人事や採用担当が募集条件とのずれを確かめる。個人の成功談をチーム全体の標準に広げない。技術記事では、著者以外の技術者が同じ結論に賛成する必要はないが、事実、条件、異なる案、未解決点が読めるかを確認する。

公開後の訂正窓口も決める。誤りの連絡先、更新日、変更履歴があれば、記事を完成品として放置せずに済む。製品や組織の条件が変わったとき、技術記事と採用記事のどちらへ影響するかを共通の事実票から探す。記事を分けることは、矛盾を増やすことではなく、更新対象を明確にするためでもある。

PVと応募を混ぜず、読後の行動を追う

公開後は、二本の記事を同じ一つの点数で評価しない。技術記事では、対象の検索語で見つかったか、関連する手順や仕様へ進んだか、外部や社内で判断材料として引用されたか、具体的な訂正や追加質問が来たかを見る。PVは到達の量であり、再利用されたことを単独では示さない。

採用記事では、採用ページへの移動に加え、面談で仕事や役割について具体的な質問が出たか、入社後の仕事に対する誤解が減ったかを確認する。応募や採用は、求人条件、報酬、選考、時期など多くの要因を含む。記事を読んだ人が応募しても、記事だけが原因だったとは言えない。

2017年に公開されたMakuakeのエンジニアによる実践報告は、採用を直接のゴールに含めていない。技術的な認知を高めることを主にし、採用を副次的な結果と位置づけていた。[4] 一人と一組織の当時の判断であり、他社の成果を保証するものではない。それでも、採用を期待することと、すべての技術記事を求人文へ変えることを分ける例になる。

技術広報のKPIで扱ったように、公開本数、対象読者への到達、読者の行動、採用への寄与、社内へ戻った学びは距離が違う。月次では、技術記事と採用記事の数字を合算する前に、「届いたが次へ進まない」「質問は出たが文書を直していない」という切れ目を一つ探す。

最初の一か月は、既存記事をすべて作り直さなくてよい。三本を選び、冒頭へ主読者と読後の判断を書き出す。技術説明の途中に採用紹介があれば、独立した記事または共通導線へ移す。逆に採用記事が技術名を並べるだけなら、実際の仕事と判断を追加し、詳しい技術記事へリンクする。

次に、検索、関連リンク、採用ページへの移動、訂正、面談での言及から、各記事の読後行動を一つずつ選ぶ。件数が少ない段階は率で競わず、どの問いが解け、どの誤解が残ったかを記録する。得た質問は次の記事企画へ戻す。

技術ブログを伸ばすとは、求人文言を多く入れることでも、PVだけを増やすことでもない。技術者には再利用できる判断を、候補者には働く判断を渡し、必要な人が次のページへ進めるようにすることだ。一つの開発記録を共有しながら、読者、記事、確認、指標を分ければ、技術共有と採用広報は奪い合わずにつながる。