developer-case-study

開発者事例

あなたは、誰かのエンジニアリングの取り組みを執筆しています。開発者事例では、エンジニアたちがこのテクノロジーを本番環境で運用し、何が変わり、どれだけのコストがかかったのかを伝えます。読者は、自分のシステムでも同じ選択がうまくいくかを判断しようとしているエンジニアであり、安心材料を求める購入担当者ではありません。

読者は、良いことばかりを語る話を見た瞬間に割り引いて受け止めます。説得力の源は、文章の磨き上げではなく、証拠を厳密に扱い、うまくいかなかった部分についても率直に伝えることです。

対象範囲の確認

着手する前に、成果物が何であるかを確認してください。次の場合は、別のスキルに案内してください。

• システムが自社のもので、外部の導入者が関わっていない場合 → エンジニアリングブログ投稿スキル。
• 自分のプロジェクトの進捗を、進行中に共有する場合 → ビルド・イン・パブリックスキル。
• 読者が何かの学習やインストールを必要としている場合 → チュートリアルまたはクイックスタートスキル。
• 内容が「v2.4でリリースしたもの」または「v1からv2への移行方法」である場合 → 変更履歴または移行ガイドスキル。
• ユーザーが自分の取り組みについてのポートフォリオ記事を求めている場合 → それは個人の事例であり、主役は執筆者です。その旨を伝えてください。このスキルでは、その構図を逆にします。

正確な識別子については、「参考資料」セクションを参照してください。

インタビュー

事例の担当者に、記事に着手する前に以下を質問してください。質問は一度に1つずつ行い、できる限り選択式にしてください。記事を公開できるか判断できる時点で、質問を終了してください。

記憶：現在のタスクやプロジェクトの状況について、いくつか情報を記録してください。記憶をファイルに保存する場合は、devrel-context.mdを使用してください。別の記憶システムを使用している場合は、そちらを利用してください。タスクごとに別のセクションに分けてください。完了したタスクは削除してください。タスクには日付を付け、一般的なプロジェクトの状況には日付を付けないでください。インタビューの回答は、タスクによって異なる場合があります。

1. 導入者は誰ですか。また、現在本番環境で運用していますか、それともまだ評価中ですか？
2. 誰にインタビューしますか。その人は実務でどのような役割を担っていますか？その人のマネージャーやプラットフォームのオーナーにも話を聞けますか？
3. あなたの側には、どのような証拠がすでにありますか。サポートスレッド、移行に関する課題やPR、利用状況のテレメトリー、アカウントの記録、相手側のブログ記事や講演などです。
4. 数字で見て何が変わりましたか。また、その数字をチーム内で裏付けられるのは誰ですか？
5. 会社名、人物名の掲載とロゴの使用について、誰が許可を出しますか。それぞれにどれくらい時間がかかりますか？
6. 相手側でセキュリティ審査や法務審査はありますか。また、すでに誰かがその審査に着手していますか？
7. どこで公開しますか。また、営業用の1枚ものの資料も必要ですか？
8. 読者に、読み終えた後で同僚に伝えてほしいことを一文で言うと何ですか？
9. いつまでに公開する必要がありますか。また、その日に何が起こりますか？月内に締め切りがある場合、法務審査だけでそれを超えるエンタープライズ候補は候補から外し、メッセージひとつで承認できる導入者を優先します。
10. 1件の停滞した商談のための単発の事例ですか。それとも、継続的に補充する事例の蓄積ですか？単発なら、承認に最も近い候補を優先します。事例を蓄積するなら、最も時間がかかる事例でも、カバレッジ表の空欄を埋める候補を優先します。
11. 顧客の時間や協力への負担も含めて、かけられる労力の上限はどの程度ですか？インタビュー1回とレビュー1回だけなら、複数の関係者が関わるエンタープライズ事例は対象外です。アカウントチームが顧客との関係構築にかけた資本を四半期分使う意思があるなら、そうした事例にも取り組めます。

あなたのハーネスに永続的な記憶がある場合は、5、6、7の回答を保存してください。これらは顧客やプログラムごとの慣例であり、その顧客と作成するすべての事例に共通して当てはまります。

ワークフロー

1. 以下のゲートに照らして事例を評価します。 候補となる導入企業が複数ある場合は、どれかに1時間を費やす前に「最初に追うべき事例」で順位を付けます。この段階で却下または優先度を下げてください。ゲートを通過できない事例は、編集で救うことはできません。
2. まず自分で集めた証拠から事例を再構成します。 面談の前にチケット、課題、PR、テレメトリーを確認し、自由回答の質問で情報を埋めるのではなく、具体的な内容を確認するために臨みます。
3. 承認プロセスを並行して開始します。 契約の広報条項を読み、原稿の作成前に、引用、指標、セキュリティ審査の承認者を確認します。その回答によって、執筆可能な事例の形式が決まります。
4. 情報提供者へのインタビューを実施します。 ./references/source-interview-guide.md に従います。本人の同意を得て録音し、文字起こしを保管します。
5. 証拠台帳を作成します。 調査で示す主張ごとに1行作成します。主張、その証拠の分類、その根拠となる測定手段、誰が再検証できるかを記録します。原稿を作成する前に行ってください。
6. 構成の軸と見出しに使う数値を責任者に確認します。今なら簡単に変更できますが、1,200語を書いた後では大変です。
7. ./references/case-study-outline.md の構成の軸に沿って原稿を作成し、引用は文字起こしから一字一句そのまま使用します。
8. 制約事項のセクションを作成します。 インタビューで聞いたコストと未解決の作業に関する回答をもとにします。省略しないでください。詳しくは以下を参照してください。
9. 人間らしさを整える工程を実施してから、公開ゲートを確認します。 すべてのチェックに合格するまで繰り返します。
10. ./references/approval-and-anonymization.md に従い、判断事項を明記したリストと期限日を添えて承認に回します。先方の修正を反映し、その後、派生版を用意します。

呼び出し例

• 「Northwind の請求処理パイプラインをワークフローエンジンに移行し終えました。事例記事を書いてください。」→ ステップ1からワークフロー全体を実施します。
• 「先方のスタッフエンジニアとの通話の文字起こしと、指標のスクリーンショットがあります。原稿を作成してください。」→ ステップ5から開始します。文字起こしをもとに証拠台帳を作成し、文字起こしでは裏付けられない主張をすべて明記します。
• 「法務から社名の掲載を認めないと言われました。どうすればいいですか？」→ 匿名化の段階に進み、次の段階を提案して、その代償を説明します。
• 「この事例は書く価値がありますか？」→ 適格性ゲートのみを実施し、不足しているゲートとともに判定を回答します。
• 「掲載に同意した顧客が4社います。どの事例にすべきですか？」→ 「最初に追うべき事例」の順位付けを4社それぞれに適用します。制約によって候補から外れる企業は、最下位に並べるのではなく除外します。
• 「承認済みの Northwind の調査を営業向けの1ページ資料にしてください。」→ 派生版のみ作成します。まず、既存の承認が新しい掲載形式にも適用されることを確認します。

ユーザーから別の指定がない限り、次の6項目をこの順序で提示します。

1. 判定文 - 公開可能、X の形式なら公開可能、または現時点では公開不可と、その理由。
2. 証拠台帳 - 主張ごとに1行で、主張、分類、測定手段、対象期間、誰が再検証できるかを記載します。
3. 原稿 - 8つのセクションで構成し、引用は一字一句そのまま使用し、制約事項を含めます。
4. 承認パッケージ - 確認すべき判断事項を明記し、推奨期限と、期限までに回答がない場合の既定案を添えます。
5. ゲートレポート - 7つのチェック項目それぞれについて合否と、適用した修正を記載します。
6. 派生版 - 1ページ資料またはその他の依頼された形式。承認後に限ります。

原稿を作成する前に、判定と証拠台帳を提示してください。文章を作成した後に作った台帳は、その文章を正当化するためのものです。

ストーリーの適格性ゲート

5つのゲートがあります。これはこのスキル独自のチェックリストであり、公開された基準ではありません。公開可能なストーリーは、5つすべてを満たします。

• パイロットではなく、本番運用。 実際のトラフィックと、実際の影響があること。評価の段階では、よくても推薦コメントにしかなりません。
• 測定済みの導入前の状態。 ベースラインがなければ、正直な差分は示せず、雰囲気だけになってしまいます。
• 話をしてくれる、名前の明らかな人物。 引用できる人がいなければ、信頼してもらえる人もいません。
• 読者が再利用できる意思決定。 代替案を検討したうえで、明示された理由に基づいて1つを選んでいること。
• 承認を得られる、現実的な道筋。 会社名の使用、または実用的な匿名化版について、実際に承認できる人がいること。

いずれか1つのゲートを満たさなくても、必ずしもストーリーを諦める必要はありません。

• 本番運用ではない場合：待ちます。
• ベースラインがない場合：差分を主張せず、規模やアーキテクチャのストーリーを公開します。
• 承認がない場合：匿名化の段階を下げます。
• 話をしてくれる人がいない場合：これはケーススタディではなく、エンジニアリングパターンの投稿です。体裁を取り繕わず、そう明言します。

最初に追うストーリー

複数の導入企業が調査に応じる可能性がある場合、選ぶべきなのは、どの導入事例が最も印象的かではありません。顧客自身の時間と善意を最も希少な投入要素として考慮したうえで、費やす1時間あたりに最も多くの公開可能な実証材料が得られるのはどれかです。導入企業のタイプから、この比率の分子と分母の両方を予測できます。そのため、候補をこの基準で順位付けし、次の順で追います。

• 効率（追跡にかける1時間あたりの公開可能な実証材料。デフォルトの順序）：スタートアップまたはスケールアップ > 個人開発者または OSS メンテナー > コンシューマー製品のエンジニアリングチーム > エンタープライズ
• 労力（重い順。顧客の時間と善意を含む）：エンタープライズ > コンシューマー製品のエンジニアリングチーム > スタートアップまたはスケールアップ > 個人開発者
• 価値（まだ判断を決めていない読者にとって、最も説得力のある実証）：エンタープライズ > コンシューマー製品のエンジニアリングチーム > スタートアップまたはスケールアップ > 個人開発者
• コンプライアンスコスト（審査が重い順）：エンタープライズ > コンシューマー製品のエンジニアリングチーム > スタートアップまたはスケールアップ > 個人開発者

価値の順序は、企業内のチーム向けに評価している読者を前提としています。製品の導入企業が個人開発者やメンテナーなら、この順序は逆転します。その場合、最も強い実証となるのはインディーの事例で、エンタープライズの事例は無関係に見えます。デフォルトの順序を使う前に、実際に購入する人に合わせて順位を付け直してください。

効率順に、各タイプにかかるコストと得られるもの、そしてそれぞれが求める記事作りの違いを示します。

1. スタートアップまたはスケールアップの B2B 導入企業 — 承認者は1人か2人で、所要期間は1週間です。リスト中で最も比率が高い一方、リスクはエンタープライズの場合と正反対です。数値を誰も確認しないことがあります。公開前に自分で検証し、再利用する前にも再検証してください。小規模企業は事業の方向転換をしたり、別のサービスに移行したりするためです。
2. 個人開発者、インディーハッカー、または OSS メンテナー — 承認コストはほぼゼロで、同意はメッセージ1通で済み、本人がそのままブランドになります。指標は個人の規模に応じたものです（ビルド時間、ホスティング料金、週末の作業など）。その規模なら十分に信頼できますが、決してエンタープライズ向けの表現に誇張しないでください。勤務先を記載してよいか、必ず明示的に尋ねてください。
3. コンシューマー製品のエンジニアリングチーム（B2C 製品、開発者向けストーリー） — 広報部門はありますが、ストーリーは自社のユーザーに触れないため、審査はエンタープライズより限定的です。導入企業のユーザーがこれを読むことはありません。読者は同業のエンジニアです。アーキテクチャや規模拡大の仕組みをより深く掘り下げ、購入者向けのビジネス上の訴求はすべて省きます。
4. エンタープライズの B2B 導入企業 — 四半期単位で進み、審査には数週間かかります。広報チームがストーリーの主導権を握り、絶対値は大幅に伏せられ、セキュリティ審査後にもう一度確認が入ります。草稿を作る前に法務部門と連携してください。先方のエンジニアも読むため、正確性に問題があればアカウントチーム経由で指摘が戻ってきます。 この優先順位付けで後回しになるのは、社名を出せるエンタープライズ本番環境の導入事例です。社内で選定理由を説明する必要がある読者にとって、得られる証拠のなかで最も強力なものであり、法務審査と顧客からの信頼の両面で、リスト内で最もコストのかかる事例でもあります。効率を基準に順位付けすると、この事例は四半期ごとに順位を下げ、事例リストにはエンタープライズの評価を前進させることのない小規模な事例ばかりが増えていきます。この規模の同業他社の事例が不足しているために進行中の商談が停滞している場合、またはカバレッジ表のエンタープライズの欄が空いている場合は、何よりも優先してください。その不足を安価に補う方法はなく、スタートアップの事例を3件集めても、エンタープライズの事例1件にはなりません。

順位を下げるのではなく、候補から削除します。顧客の法務チームが公開事例を承認しない場合は、候補リストの最下位に置くのではなく、候補から外します。匿名化の段階を調整することで、なおかつ適格性の基準を満たせる場合に限り、候補に残します。

それ以外の場合、その候補は対象外です。「来四半期なら」という候補を残しておくと、アカウントチームへの依頼と、それに伴う関係構築のための資本が消費され続けます。本番導入ではなく、まだ評価中の候補も、最初の基準を満たさないため、同様に削除します。その候補を待つことは計画ではありません。

この優先順位はデフォルトであり、絶対ではありません。状況や、誰が事例の獲得に動くかによって変わります。

• あるエンタープライズ顧客とすでに良好な関係を築いているアカウントチームなら、その事例にかかるコストの大半はすでに負担済みです。
• 製品について公に執筆したことのあるメンテナーなら、誰かが声をかける前から、公開事例の完成まで半分進んでいます。

数値の扱い

すべての数値には、次の4つの属性が必要です。これらがそろわなければ公開しません。

• 導入前の値。
• 導入後の値。
• 値を算出した計測手段。
• 計測期間。

証拠の種類	手元にある情報	記載方法
計測済み	同じ計測手段で得た導入前後の値	計測手段と期間を添えて、そのまま記載します
一部計測済み	導入後の値は計測済み、導入前の値は推定値	記載したうえで、推定値であることを明記します
顧客報告	計測されていない顧客の数値	「チームの推定では…」のように、出所を明記します
定性的	定性的な主張しか裏付けが残っていない	数値は削除し、エンジニア自身の言葉を使います

出所の明確な数値2つのほうが、根拠の弱い数値6つより優れています。顧客が絶対値の公開を承認しない場合は、比率のほうが絶対値より伝わりやすく（「インフラコストを3分の1削減」など）、サイクルタイムや信頼性の数値は、単純な処理量よりも伝わりやすい傾向があります。読者は顧客の規模を知らなくても、自分たちのシステムと比較できるためです。

次のことは避けてください。

• 顧客が確認していない数値を算出する。
• 1か月の結果を年換算する。
• 顧客が一度に3つの変更を加えたにもかかわらず、ビジネス上の成果を自社製品によるものとする。それ以外に何を変更したのかも記載してください。

このスキル自体の数値にも、同じルールを適用します。./references/evidence-and-sources.mdでは、このファイル内のすべてのしきい値を、出典に基づくものと独自に設定したものに分けています。独自に設定した基準値を引用する場合は、あくまで作業用の基準値としてのみ扱い、導入企業に業界標準として提示してはいけません。

骨子

公開されている調査では、課題／ソリューション／結果という構成が共通しています。同じ3つの要素を含む事例は独立した4件あり、ベンダーによる調査が2件、汎用的なマーケティングスキルのテンプレートが2件です（出典は./references/evidence-and-sources.md）。この構成は維持し、テンプレートで抜けている3つの要素、すなわち却下した代替案、指標の根拠、制約を加えます。

以下の語数配分は、1,200～1,800語を目標に独自に設定した比率です。この目標語数も独自に設定したもので、測定対象となったベンダーの調査3件（約1,650語、約2,100語、約2,400語）のうち最も短いものをわずかに下回るようにしています。なお、いずれにも独立した制約のセクションはありません。内容に合わせて調整してください。

1. 主な成果 — 数値と変化の形（約60語）
2. 採用企業と対象システム（約120語）
3. 導入前の状況と、そのコスト（約250語）
4. このテクノロジーを選んだ理由 — 比較検討して却下した代替案（約200語）
5. 構築したもの — アーキテクチャ、具体的なコンポーネント、導入の順序（約400語）
6. 結果 — 数値と測定方法（約200語）
7. コストと、未解決の問題（約200語）
8. 次の予定（約70語）

4、5、7のセクションが、これをお客様の声と差別化します。1、2、6、8だけで内容が埋まるなら、それは引用文カードです。その形式で公開してください。

執筆を始める前に、./references/case-study-outline.mdを読み、各セクションのガイダンスと、適切な例・不適切な例を確認してください。そこにある例（Acme、Grafanaの数値）は架空の例示であり、実測事例ではありません。根拠として引用しないでください。

制約が差別化につながる

制約とは、読者が引き継ぐことになるコストであり、計画ではありません。

Roadmap: "We plan to consolidate the two languages."
Cost:    "We shipped the orchestration layer in Go while the rest of the team
          writes Python, and that split is now a hiring constraint."

比較した調査のうち1件では、前者が3つ記載されている一方、後者は1つもありません。このトレードオフを受け入れてはいけません。

このギャップは、ジャンルの制約ではなく、発行者の選択によるものです。比較した4件の調査では、サンプル数が少なく、そのうちベンダーによるものはどちらも同じベンダーによる調査ですが、次の傾向が見られます。

• ベンダーが公開した2件には、コストがまったく記載されていません。
• コミュニティが公開した2件では、コストと失敗が率直に明かされています。そのうち1件は、担当者本人が失敗した導入について詳しく説明しています。

セクションの一覧と出典：./references/evidence-and-sources.md。

インタビューから、以下の内容をこのセクションに盛り込んでください。

• 移行にかかったエンジニアの週数。
• 並行稼働した期間。
• 展開中に発生した問題。
• チームが再トレーニングした対象。
• 意図的に移行しなかったワークロード。
• 現在も機能していないこと。

このアーキテクチャをまねるべきでないのは誰かを明記してください。

• 顧客がセクション全体の削除を求めた場合、調査の説得力は弱まりますが、公開は可能です。
• 顧客がこのセクションに加えて代替案のセクションも削除するよう求めた場合、それは広告を公開することになります。広告として扱えるよう、担当者にはその旨を率直に伝えてください。

承認プロセス

誰かに何かを依頼する前に、契約書の広報に関する条項を確認してください。一般的なセルフサービス型 SaaS の利用規約では、顧客の名前とロゴ、および顧客であるという記述について、すでに使用許諾が与えられていることがよくあります。Vercel の利用規約にもそのような条項があり、./references/approval-and-anonymization.md に原文のまま引用されています。

この条項が許可するのは、それ以外には何もありません。

• 引用は許可されていません。
• 指標は許可されていません。
• アーキテクチャの説明は許可されていません。
• 顧客がシステムをどのように運用しているかについての説明は許可されていません。

条項で対象外となっている内容だけを依頼してください。

多くの場合、次の4つの許可は、それぞれ別の担当者が持っています。

• 引用されるエンジニア本人の同意。
• チームの信頼を使うことについての、そのエンジニアのマネージャーの同意。
• 会社名とロゴに関する広報部門の承認。
• 技術的な詳細に関するセキュリティ部門または法務部門の審査。

最初の連絡時に、それぞれの承認者が誰かを尋ねてください。

セキュリティ審査で間違いなく削除される内容は、あらかじめ伏せておいてください。

• インフラの規模やコストの絶対値。
• 内部サービス名、チケット ID、ダッシュボードの URL。
• 却下した代替案のセクションにある競合他社名。
• 導入前の状態にセキュリティ上の弱点があったと示唆する内容。

どの箇所に判断が必要かを明記した完全版の草稿を、期限の日付と、期限までに返答がない場合の扱いを明示して送ってください。

実名の掲載が認められない場合は、ストーリーを取り下げるのではなく、匿名化の段階を一段ずつ下げてください。

1. 会社名とエンジニア名を公開。
2. 会社名は公開し、エンジニア名は非公開。
3. 会社名は非公開にし、特定につながる説明を添える。
4. カテゴリを示す説明のみ。
5. 顧客を含めないパターンの事例紹介。

段階を下げるたびに信頼性は損なわれ、最後の段階ではもはや導入事例ではありません。

この段階は、労力や効率の順位を示すものではありません。上から2番目以下の段階は、誰かが一つ上の段階を拒否した場合にのみ選ばれるため、互いに選択肢として比較するものではありません。承認された範囲で最も上の段階を採用し、段階を下げることはトレードオフではなく損失として捉えてください。

段階の全一覧、伏せ字の分類、依頼テンプレートについては、./references/approval-and-anonymization.md を参照してください。

ヒューマナイザーによる確認

公開前の審査に進む前に、好みのヒューマナイザーのスキルを使って文章を整えてください。モデルらしさのある冗長な表現はベンダーの宣伝文句のように読めますが、この文書で最も避けるべき文体です。

引用、数値、バージョン文字列、コンポーネント名、アーキテクチャの説明は、すべて原文どおりに維持してください。人間らしく整えた引用は、捏造した引用です。

公開前の審査

7つのチェック項目からなる、実務上の審査基準です。公開基準として確立されたものではありません。7項目すべてに合格するまで、事例の公開を保留してください。不合格となった項目と変更内容を報告し、その後、再審査してください。

1. すべての主張が分類されていること ― 実測値、一部実測値、報告値、またはエンジニアが意見として明示した内容。例外はありません。
2. すべての数値について、計測手段と期間が記載されていること、またはワンクリックで確認できること。
3. 少なくとも1つの制約が公開されていること。読者がその点を理由に採用を見送れるほど具体的であること。
4. 代替案のセクションがあること。却下したものと、その理由を明記すること。
5. すべての引用が文字起こしからの逐語引用であること。確認済みの氏名と役職を付記すること。
6. 会社名、ロゴ、引用、セキュリティ審査に関する承認の証拠が保管されていること。
7. 根拠のない最上級表現が一切ないこと。「シームレス」、「簡単」、「画期的」といった表現は、事例内の数値で裏付けるか、削除すること。

公開前に、さらに2人が内容を確認します。

• インタビューを受けたエンジニアが、技術的な正確性を確認します。
• アカウントの関係者ではない人が、社内用語を知らなくても理解できるかを確認します。

派生版

承認済みの調査から、複数の成果物を作成できます。承認前に必要な成果物を確認し、許可の範囲に含めておきましょう。そして、1時間あたりの再利用効果が高い順に作成します。以下の各段階では、承認済みの調査で確認済みの素材を再利用するため、この順位は作成の手間ではなく、再利用がどこで活きるかを示しています。

1. ドキュメント内の相互リンク - ほぼゼロ：評価者がすでに目を通す関連ページに、「誰がどのように使うか」を示すリンクを設置します。
2. 営業向けの1ページ要約 - 1時間：成果、3つの数値、1つの引用を盛り込み、どのセクションにもCTAを入れません。営業活動が少しでもある場合は4つの中で最も価値がありますが、営業活動がない場合は価値がありません。その場合は順位付けするのではなく、作成を見送りましょう。
3. コミュニティへの投稿 - 1時間とエンジニア本人の協力が必要：本人の名前で、本人の言葉を発信します。あなたの名前で公開するものよりも広く届き、投稿を許可できるのは本人だけです。
4. カンファレンスやウェビナーの資料 - 半日、かつ登壇枠があることが前提：アーキテクチャの変更前後はすでにスライドになっているため、追加コストは低く抑えられます。ただし、登壇が採択されるまでは、どの成果物も役に立ちません。

調査の各要素、つまり各指標、各引用、アーキテクチャ図を、ストーリーとともにパブリック／プライベートの区分を付けてエビデンスライブラリに保存します。後から作成するアセットではこれらの要素を使えるため、誰も1,500語の調査を読み返して数値を探す必要はありません。

有料コンテンツや広告で再掲載する場合、通常は別途許可が必要です。およそ18か月以上前の調査を再利用する前に、必ず再確認してください。これは実測に基づく有効期間ではなく、自分たちで定めた目安です。リリースの頻度が高い、または解約が多い導入企業については、期間を短くしてください。

失敗パターン

症状	原因	対処
お客様の推薦文のように見える	セクション1、2、6、8にしか内容がない	代替案、アーキテクチャ、コストを追加で確認するか、引用カードを公開します
顧客が数値の半分を削除する	指標の出典が確認されていなかった	各指標の測定手段と期間を確認し、再提出します
承認に何週間もかかる	草稿の作成後にレビューの手順を開始した	初回の連絡時に承認プロセスを開始し、期限を定めた既定の対応を設定します
エンジニアが公に異議を唱える	ベンダー側の思い込みに基づいてアーキテクチャを記述した	インタビューを受けたエンジニアに技術セクションを確認してもらいます
引用がマーケティング文句のように聞こえる	逐語記録ではなく言い換えた	録音から正確な発言を復元し、顧客自身による編集を受け入れます
インタビュー後にストーリーが頓挫する	適格性の確認を省略した	通話を予約する前に、適格性を確認します
数値の主張が誇張されている	複数の変更を伴う導入の成果を製品だけに帰属させた	同じ期間に変更された他の要素もすべて明記します
顧客が「承認済み」の調査に異議を唱える	契約のロゴ条項を包括的な承認と解釈した	条項の対象は社名とロゴのみとし、引用、指標、ストーリーはそれぞれ別途許可を得ます
制約事項のセクションに内容がない	ロードマップ項目をコストとして扱った	エンジニアの作業週数、二重稼働、何が壊れたかを改めて尋ねます。計画はコストではありません
解約した顧客の調査が公開されたままになっている	公開時に再確認日を設定しなかった	すべての調査に日付を付け、予定どおりに再確認し、公開し続けるのではなく公開を取り下げます

効果測定

トラフィックではなく、評価の前進につながったかどうかで調査を判断します。開発者を特に対象とした事例研究の効果を切り分けて示す、公表済みの指標はありません。一般的なB2Bテクノロジー購入者調査では、購入判断への影響において、ベンダーが制作した事例研究は製品デモや無料トライアルより大きく後れを取っています（./references/evidence-and-sources.mdを参照）。ただし、これより対象を絞ったデータはありません。以下のシグナルは、達成目標ではなく、評価に用いる要素として扱ってください。

• 商談での利用：営業担当者やソリューションエンジニアが実際に何回送付するか、またどの段階で送付するか。
• 最後まで読まれた割合と、リンク先の成果物（ドキュメント、リポジトリ、アーキテクチャページ）へのクリック数。
• インバウンドでの紹介依頼：その顧客と話したいと見込み客から依頼されること。
• 導入企業自身が事例を広めているかどうか。顧客企業のエンジニア自身が共有するストーリーは、顧客が支持しているストーリーです。
• ストーリーバンクの網羅性：同じプロフィールの事例を5つそろえるより、主要なユースケースと導入企業の規模ごとに信頼できる事例を1つずつ用意するほうが効果的です。

単一の事例研究に収益を結びつけてはいけません。効果を誇張して帰属させることは、その成果物が防ごうとしている信頼性の損失そのものです。

参考資料

• samber/developer-relations-skills@tech-talk-outline - 承認済みの調査をステージでの講演に仕立てる
• samber/developer-relations-skills@technical-video-script - 承認済みの調査を動画で再構成する
• samber/developer-relations-skills@tech-podcast-interview-prep - 承認済みの調査をポッドキャストで再構成する
• samber/developer-relations-skills@devrel-content-calendar - 1四半期にわたってストーリーバンクをスケジュールする
• samber/developer-relations-skills@tech-press-relations - 承認済みの事例研究を報道記事としてジャーナリストに売り込む
• ./references/source-interview-guide.md - 事前の通話準備、質問の段階的な組み立て、引用の記録
• ./references/case-study-outline.md - セクションごとの構成案と作成例
• ./references/approval-and-anonymization.md - 同意取得の流れ、編集区分、匿名化の段階、依頼テンプレート
• ./references/evidence-and-sources.md - 中核となる公開済み調査、出典のある基準値と独自に設定した基準値