概要
テックブログとは、企業が自社のエンジニアリングに関する知見を記事として社外に公開する技術メディアです。記事は個人の名前で書かれますが、読者には「その会社の見解」として受け取られます。 このページでは、テックブログを組織として運営する側と、記事を書く側の両方の視点を扱います。まず運営の仕組みと執筆フローを定め、テーマの選び方、表現と情報のリスク管理、記事の書き方、公開と拡散を順に説明し、最後にファインディでの具体的な運用を紹介します。テックブログの位置づけ
テックブログは、発信の形式のうち「判断とその理由を分量をかけて説明し、後から読める形で残す」役割を担います。登壇やイベントと異なり、記事は検索から長期にわたって読まれ続けるため、1本の記事が組織の技術的な水準を示す資料として残ります。 個人ブログとの違いは、責任の所在です。個人ブログでは許容される比喩や断定、他社製品との比較も、企業の公式メディアでは会社の立場として読まれます。そのため、テックブログの運営では「書きたいことを書く」だけでなく、公開してよい内容かどうかを組織として確認する仕組みが必要になります。 一方で、確認の仕組みが重すぎると書き手が減り、発信が続きません。運営の目的は、記事の品質と安全性を保ちながら、書き手が継続して書ける状態をつくることです。運営の仕組み
役割を分担する
テックブログの運営には、少なくとも3つの役割があります。
編集部をチームとして指定し、メンバーのうち1名の承認で通過とすると、特定の人にレビューが集中しにくくなります。
執筆フローを決める
記事の内容は、書き始める前と書き終えた後の2回確認します。書き始めてから方向性のずれが見つかると、大幅な書き直しが必要になるためです。1
企画を登録する
タスク管理ツールに記事の企画を登録し、初稿の期日・レビューの期日・公開予定日を決めます。期日を先に決めておくと、レビューの担当者が予定を確保できます。
2
企画の全体像をレビューしてもらう
仮のタイトル、書こうとしている内容のサマリ（箇条書きで構いません）、結論をまとめ、上長と編集部にレビューを依頼します。この段階では文章の品質ではなく、テックブログで公開してよいテーマか、結論が明確かを確認します。
3
企画の価値を審査する
執筆を始める前に、企画が読者にとって新しい知見を含むかを審査します。審査の観点は次の節で説明します。
4
下書きを書き、セルフレビューする
執筆ガイドラインとチェックリストに沿って下書きを書き、レビューを依頼する前に自分で品質を確認します。
5
記事をレビューしてもらう
上長と編集部に下書きのレビューを依頼し、指摘を反映して承認を得ます。
6
公開日時を設定して公開する
タイトル、読後の導線、アイキャッチ画像を確認したうえで、公開日時を予約します。
7
公開した記事を拡散する
社内のチャンネルや個人のSNSで記事を共有し、より多くの読者に届けます。
執筆の前後で企画審査と品質レビューを行う
執筆前の確認を企画審査、執筆後の確認を品質レビューと呼びます。2つは確認する対象が異なります。企画審査は「この記事を書く価値があるか」を、品質レビューは「この記事を公開できる状態か」を判定します。 企画審査では、次の観点をすべて満たすかを確認します。
品質レビューでは、「記事を書く」で説明する構成・表記・セルフレビューの観点で記事を確認します。
テーマを選ぶ
推奨するテーマ
テックブログに向いているのは、自社の具体的な経験に基づくテーマです。
テーマは企業のブランディングにも関わるため、推奨テーマであっても公開できない場合があります。リストにないテーマも、企画の全体像のレビューで相談できます。
避けるテーマ
次のテーマは、企業の公式メディアとして扱うリスクが大きいため避けます。表現と情報のリスクを管理する
表現の倫理
表現のリスクで判断の基準になるのは、書き手の意図ではなく、読み手がどう受け取りうるかです。炎上したときに「そういう意図ではなかった」という説明は通用しません。 企業の公式メディアでは、次の表現を避けます。- 人を動物・モノ・機械に喩える表現（非人間化）。
- 「配属」「マネジメント」「部下」といった職場・人事の語彙に、動物や架空の存在を当てはめる表現。
- 動物・宇宙人・ロボットなど極端な設定を使った思考実験。本文で「比喩です」と断っても、タイトルや見出しだけが切り取られて拡散されます。
機微情報
スクリーンショットや写真には、意図しない情報が写り込みます。社内チャットやドキュメントのスクリーンショットでは、アイコン・個人名・時刻・プロジェクト名をぼかします。ぼかしが薄いと判読できることがあるため、十分に塗りつぶします。デスクの写真では、モニタに映った画面や卓上のメモも確認します。 ソースコードは、変数名や数値から内部の構造や脆弱性が推測される場合があります。サンプルコードを載せるときは、自社固有の変数名・関数名・クラス名を汎用的な名前に置き換え、APIキー・トークン・内部URL・IPアドレスを含めないようにします。記事を書く
構成
記事の種類によって、読者が期待する構成が異なります。
体験談・考察と詳細なチュートリアルは、決まった構成を定めず、文字数の目安だけを示しています。
文章量よりも、主張が明確で根拠があることを優先します。ただし、極端に短い記事は内容が薄い印象を与え、長すぎる記事は読者が離脱しやすくなります。長くなる場合は、シリーズ記事への分割を検討します。
見出しはh2から順に使い、「1つ目」「2つ目」ではなく内容を示す言葉にします。各h2だけを読んで記事の全体像がわかる状態が目安です。自己紹介の直後、本文に入る前に目次を置きます。
タイトル
タイトルは、記事の中身と同じくらい読まれるかどうかを左右します。結論が伝わるタイトルにし、先頭にツール名や技術名など具体的なキーワードを置きます。 AIが生成しがちなパターンは避けます。たとえば「〜の3つの教訓」「失敗を成長に変えた〜」「〜完全ガイド」「〜を徹底解説」「〜への道」「〜の秘訣」です。短いタイトルは印象に残りやすいものの、内容が伝わることを優先します。導入とまとめ
導入では、読者が「自分に関係がある記事か」を判断できるように、次の内容を冒頭で明らかにします。- 何のツール・技術・イベントについての記事か
- 想定する読者と、読むと何がわかるか
- 記事を書いた背景や動機
数値と根拠の示し方
改善を主張するときは、Before/Afterを数値で示します。「処理が高速化しました」ではなく「2時間から5分に短縮しました」と書き、「カバレッジはほぼ100%」ではなく「90%超えを維持」のように確認できる値を書きます。 数値には、計測した環境（本番・ステージング・ローカル）、サンプル数や期間、比較の基準を添えます。外部の情報を引用するときは、本文中に番号付きの参照を付け、記事の末尾に参考文献として公式ドキュメントやイベントページへのリンクを載せます。トーンと表記
文体は、固すぎずカジュアルすぎない調子にします。「〜では価値が出しにくくなっています」のような不安を起点にした書き出しより、「〜に加えて、より〜が求められるようになってきました」のように次につながる表現を選びます。課題を書く場合も、先にそのツールや手法の良い点に触れます。 表記は記事内で統一します。- 製品名・技術名は正式な表記で書く（GitHub、JavaScript、Cloud Runなど）。
- 英単語と日本語の間にスペースを入れない。
- 「以下」ではなく「次の」を使う。
- 太字は1つの見出しにつき1〜2か所までにし、斜体・下線・色・水平線は控える。
- 段落の中で1文ずつ改行せず、段落の区切りに空行を入れる。
セルフレビュー
レビューを依頼する前に、記事を3回、視点を変えて読み直します。1回の通読では見落としが残るためです。
あわせて、目次と採用情報へのリンクがあるか、「TODO」などの仮テキストが残っていないか、リンクが切れていないかを確認し、プレビュー画面で見た目を確かめます。
公開と拡散
公開前の確認
公開の前に、レビューの指摘がすべて解消されていること、タイトルを見直したこと、読後の導線（採用情報や関連記事へのリンク）があること、アイキャッチ画像が設定されていることを確認します。アイキャッチ画像は共通のデザインで作成すると、ブログ全体に統一感が出ます。タイトルを変えた場合は、画像も作り直します。公開のタイミング
公開日時は、自社ブログの閲覧データから読まれやすい曜日と時間帯を把握し、それに合わせて予約します。公開と同時に、公式SNSアカウントからも告知します。拡散と分析
公開後は、書き手が社内のチャンネルと自分のSNSで記事を共有し、社内のメンバーにも拡散を依頼します。社内のメンバーが記事を読み、反応することが、社外に届くきっかけになります。 記事の閲覧状況は、アクセス解析ツールと検索パフォーマンスの計測ツールで確認します。発信の効果は個々の記事に帰属させにくいため、1本ごとの数値で書き手を評価するのではなく、十分な期間の蓄積で活動全体を評価します。公開済みの記事を修正する
公開後に誤りが見つかった場合は、記事を修正します。修正の前に、ブログサービス上の最新の状態を手元に取り込みます。ブログサービスの編集画面で直接更新した内容が手元に反映されていないまま修正すると、その更新が失われるためです。ファインディでの運用
ファインディでは、テックブログを「はてなブログ」で公開し、記事の原稿をGitHubのリポジトリで管理しています。記事のレビューをコードと同じくプルリクエストで行うことで、エンジニアが普段の開発と同じ流れで執筆・レビューできるようにしています。 はてなブログとGitHubリポジトリの同期には、はてなが公開しているHatena-Blog-Workflows-Boilerplateを使わせてもらっています。下書きの取得・同期や公開記事の反映といったGitHub Actionsのワークフローは、このボイラープレートをもとにしています。執筆から公開までの流れ
1
GitHub Projectsで企画を管理する
テックブログ用のGitHub Projectsにタスクを作成し、記事テンプレートからIssueを起票します。Issueには記事タイトル（仮）、サマリと結論、初稿期日・レビュー期日・公開予定日を記入し、ステータスを「Todo」にします。
2
Issueで企画のレビューを受ける
直属の上長と、編集部のGitHubチームをレビュアーとしてメンションします。編集部はチームとして指定し、メンバーのうち1名の承認で通過します。
3
Claude Codeで企画を審査する
企画審査用のClaude Codeのコマンドで、企画を非自明性・独自性・実務転用性・想定読者・So What?の5観点で審査します。Issueの内容を読み込んで審査するほか、対話形式で企画を聞き取って審査することもできます。PASSを受けてから執筆を始め、審査結果をIssueにコメントします。
4
はてなブログで下書きを作り、GitHubに同期する
はてなブログの編集画面で、
ユーザー名-日付のような一意のタイトルで下書きを保存します。GitHub Actionsの下書き取得ワークフローにそのタイトルを渡して実行すると、下書きを含むプルリクエストが自動で作成されます。5
プルリクエスト上で記事を編集する
下書きのプルリクエストにプッシュすると、GitHub Actions経由ではてなブログの下書きに同期され、プレビューで表示を確認できます。画像はリポジトリの年月別ディレクトリに追加して記事から参照すると、はてなブログにアップロードされます。
6
Claude Codeで品質をレビューする
品質レビュー用のClaude Codeのコマンドで記事をレビューします。90点以上になるまで修正と再レビューを繰り返し、結果をプルリクエストにコメントします。
7
上長と編集部のレビューを受ける
プルリクエストのレビュアーに上長と編集部のチームを指定し、承認を得ます。
8
予約投稿で公開する
下書きであることを示す
Draft: trueの行を残したままプルリクエストをマージし、はてなブログの編集画面で公開日時を設定して予約投稿します。このとき、公開と同時にXへ投稿する設定を有効にし、公式アカウントから告知されるようにします。9
社内外に共有する
公開後、全社や開発組織のSlackチャンネル、自分のtimesチャンネルで記事を共有し、SNSでの拡散を依頼します。
品質レビューのコマンドが行うこと
品質レビューのコマンドは、執筆ガイドラインをもとに次の手順を順に実行します。
ガイドラインはリポジトリ内のファイルを唯一の正とし、Claude Codeのコマンドと、GitHub Copilot ChatのAgentモードによるレビューの両方から参照されます。どちらのツールを使っても、同じ基準でレビューを受けられます。
運用上の決まりごと
公開のタイミング
公開のタイミング
拡散を最大化するため、月曜日か金曜日（祝日の場合は翌営業日）の7:00〜10:00に公開します。予約投稿の場合は7:00に設定します。
記事の末尾
記事の末尾
すべての記事の最後に、採用情報へのリンクを定型文とともに入れます。
製品名の表記
製品名の表記
Findy、ファインディ株式会社、Findy Team+、Findy Tools、Findy Freelance、Findy Conferenceのように、製品名と社名は正式な表記で書きます。「FINDY」「株式会社ファインディ」などは使いません。
アイキャッチ画像
アイキャッチ画像
統一感を出すため、共通のデザインテンプレートのうち決められた配色の画像を使います。
初めて投稿する人の準備
初めて投稿する人の準備
はてなIDを作成して管理者に伝え、はてなブログのメンバーに追加してもらいます。誰が書いたかわかるように、はてなのプロフィールで名前とアイコンを設定します。
関連ページ
DevRelの役割
テックブログを含む発信が、組織にとってどんな役割を果たすかを扱います。
エンジニア育成
記事の執筆を、学習と共有を通じた育成の中にどう位置づけるかを考えるときに読みます。
オンボーディング
入社エントリーを書く新しいメンバーが、組織の中で自律して動けるようになるまでの支え方です。