導入事例の一覧では、「作業時間を80%削減」「売上が2倍」といった数字が最初に目に入る。数字は変化を短く伝えられる。だが、その数字だけでは、導入前にどんな問題があり、なぜその製品を選び、誰が何を変え、どの期間と方法で成果を測ったのかは分からない。読者は自社でも同じ結果を期待してよいか判断できない。

導入事例とは、特定の顧客がある状況で何を選び、どう実行し、何が変わったかを、時点・測定条件・残る限界とともに記録したものである。一件の成功を普遍的な正解として見せるのではなく、次の読者が自社との条件差を比べられるところまで示す。

英国政府のケーススタディ指針は特定の時点・文脈で、ある取り組みが一定の効果を持った記述をケーススタディと捉え、それだけで他の状況へ移せる「良い実践」になるわけではないと区別する。[1] 別の英国政府ガイドも、成功だけでなく、制約、リスク、意図しない結果、次回変えることを残す事例に価値があるとする。[2] 企業の導入事例も成果を称賛するだけでなく、条件付きの記録として読むと役割が明確になる。

導入事例は、特定の条件で起きた変化の記録である

製品ページ、顧客の推薦コメント、導入事例は、重なる部分があっても役割が違う。

比較表
形式主に示すことそれだけでは分かりにくいこと
製品ページ機能、仕様、価格、利用条件特定の組織がなぜ選び、どう運用したか
推薦コメント顧客や利用者の意見・経験測定条件、他の説明、再現できる範囲
導入事例導入前の状況、選定、実行、変化、限界一件の結果を他社へそのまま移せるか

製品ページは候補を知り、仕様を比べる入口になる。推薦コメントは実際に使った人がどう受け止めたかを伝える。導入事例はその意見と製品情報を、特定の組織で起きた選択と変化へつなぐ。三つを混ぜると、顧客の好意的な言葉が、測定された成果の証明に見えてしまう。

米連邦取引委員会(FTC)は広告主以外の人の意見や信念を反映していると受け取られる広告メッセージを、endorsementとして整理している。推薦は正直で誤解を招かず、広告主が自ら言えない主張を、推薦者に代わりに言わせてはならない。[3] これは米国の広告実務に関する指針であり、日本の個別案件へ法的結論を与えるものではない。それでも、顧客の発言と、企業が検証すべき事実を分ける編集上の手掛かりになる。

「使いやすくなった」は話者の経験である。「処理時間が平均30分から10分へ減った」は、対象、期間、測り方を確かめる事実主張になる。顧客の言葉を生かしながら、数字や因果まで発言へ預けない。事例の制作主体、取材先との関係、数字を測った主体も読者が追える形にする。

大きな成果値ほど、測り方を近くに置く

成果値を載せるときは、その前後に最低でも五つの情報が要る。導入前の基準、測った対象、期間、計算方法、同じ時期に動いた他の要因である。

AWSが公開するサンフーズジャパンの事例は、年間2,040時間、約350万円の削減という合計を掲げている。本文ではさらに、入庫処理120時間、ピッキングリスト作成640時間、帳票記入320時間、PC入力960時間という内訳を示す。[4] 合計だけより、どの作業がどれだけ変わったかを追いやすい。

一方、公開ページからは測定対象者、基準にした期間、約350万円へ換算した単価、繁閑差や他の改善の影響をすべて確認できない。これは数字が無意味だという話ではない。ページから確認できる範囲と、追加で聞く必要がある条件を分けて読むということだ。

成果値を強く見せようとすると、分母や期間を注記へ追いやりたくなる。しかし、条件は数字の弱点ではない。読者が自社との差を見つけるための情報である。対象が一部署か全社か、試行期間か定着後か、自己申告かシステムログかで、同じ「50%削減」の意味は変わる。

技術コンテンツとは何かで扱ったように、数値には条件、方法、限界を添える必要がある。導入事例でも、測定できた成果、担当者が感じた変化、今後への期待を同じ言い切りにしない。

測定済みの変化には、対象、期間、導入前後の値、測定方法を書く。当事者の実感は誰の経験かを示し、組織全体の成果へ広げない。将来への期待は未達の計画として扱い、現在の効果に数えない。導入と同時に変えた業務、制度、人員があれば、因果を判断する条件として残す。

数字がない事例を、ただちに不完全とみなす必要もない。選定の判断や運用の変更を説明できるなら、読者にとって重要な材料になる。数字を測っていないことは隠さず、現時点で確認できる変化へ範囲を狭める。

選定理由と実行の順番が、読者との条件差を見せる

導入事例で成果の前に知りたいのは、なぜその選択に至ったかである。「高機能だった」「サポートが手厚かった」だけでは、他社にも当てはまる。何と比べ、どの制約を重く見て、誰が決めたのかを具体化する。

AWSの大日精化工業の事例では、当初は別のクラウドサービスを前提に開発していたが、想定以上にコストが膨らむ懸念からAWSへ切り替えたと説明する。既存システムでの採用実績、SAP S/4HANAの稼働実績、一時利用のしやすさ、従量課金を選定理由として挙げている。[5]

実行の順番も具体的である。2016年7月にプロジェクトを始め、標準モデルを構築し、中国の生産拠点を最初の展開先に選んだ。事業領域、人材、システム環境、トラブル対応力を理由にし、2018年1月に中国、同年10月に国内本社とグループ5社、2019年1月にタイで本稼働した。[5]

この記録から、読者はAWSの機能だけでなく、最初の展開先を選ぶ条件や横展開の順番を読める。自社に似た人員やシステム環境があるか、最初の拠点で問題へ対応できるかを考えられる。

同じ事例は直接的な効果をまだ測定できていないことも明記する。その一方で、システムの統合、IT組織の機能別への改組、開発・運用の属人化の解消という確認できた変化を記す。[5] 成果が未測定なら公開できない、とは限らない。測れていない成果を断定せず、実行したことと現時点で起きた変化を分ければ、読者は次の検証点まで理解できる。

導入事例の説得力は成功の大きさだけで決まらない。選定時の制約、代替案、意思決定、導入の順番、役割分担が見えると、成果が生まれた条件を考えられる。BtoBブランディングとは何かで見た「選ぶ理由を社内へ渡す」ためにも、導入事例は強い材料になる。

ノートと資料を挟み、オフィスのテーブルで向かい合って話す二人
導入事例は、顧客の感想を一つ聞いて終わらない。導入前の状況、選定、実行、測定条件を順に確かめる。写真は本文の実在事例とは関係しないイメージ。 — Photo: Gustavo Fring / Pexels(縮小・WebP変換。写真は本文の実在事例とは関係しないイメージ)

一件の事例を、どこまで自社へ移せるか

一件の導入事例から、「この方法ならどの会社でも成功する」とは言えない。業種、規模、既存システム、担当者の経験、予算、導入時期、支援体制が違えば、同じ製品でも結果は変わる。

英国政府のケーススタディ指針は特定の文脈で得られた事例と、異なる文脈へ移せる良い実践を区別する。移転可能な実践として扱うには、外部評価や検証が必要だとする。[1] 一社の導入事例は一般論の完成形ではなく、比較と検証の出発点である。

英国のNIHR研究がまとめた組織ケーススタディの報告基準は、データの収集方法、証拠の出所、分析方法、設計と分析の限界を記載し、主張を過大にも過小にも解釈しないことを求める。[6] 企業の短い導入事例に研究報告書と同じ詳細は要らない。だが、主張を支える証拠がどこから来たかは残せる。

導入事例の証拠が、導入前の文脈、選定理由、実行と役割、確認できた変化、測定条件と限界の順につながる図
成果は文脈から限界まで続く証拠の一部である。 — Diagram: CONTEXT編集部(GOV.UK、NIHR / NCBI Bookshelfのケーススタディ指針を基に作成)

図の五つの要素は別々の箱ではない。導入前の文脈が選定理由を決める。選定理由が実行時に必要な役割と順番を決める。実行した内容に対して、何が変わったかを測る。最後に、測定できなかったことと他社へ移す際の条件を残す。途中が抜けるほど、成果値から原因を言い切りやすくなる。

事例の公開前には、顧客が語る導入前の業務、意思決定、実行、経験と、ベンダーが持つ契約、提供機能、支援範囲、利用ログを分ける。編集部は二つの記録から読める変化と断定できないことを示し、非公開情報、測っていない成果、比較していない代替案は未確認事項として残す。

出所を分けると、顧客の発言をそのまま製品効果に変換しにくくなる。異なる説明があれば、片方を消してきれいな物語へ整えず、時点や対象の違いを確かめる。

公開前に、読者の判断を変える事実を残す

導入事例の基本構成として、「課題/施策/成果」は分かりやすい。ただし三語だけでは、見出しを埋める型になる。読者が候補を選び、社内で説明するには、次の六点まで確かめたい。

  • 導入前の基準:何が、誰にとって、どの程度問題だったか
  • 選定理由:何と比べ、どの制約と基準で選んだか
  • 実行の過程:誰が、いつ、何を変え、どこでつまずいたか
  • 確認できた変化:数字、行動、運用、組織の何が変わったか
  • 測定条件:対象、期間、方法、計算、同時に起きた別の変化
  • 限界と次の検証:未測定、残る課題、他社で答えが変わる条件

すべてを公開できるとは限らない。顧客名、原価、構成、失敗、比較した製品を出せない場合もある。公開できない情報を推測で埋めず、粒度を変えて残す。製品名を出せないなら「既存のオンプレミス環境」など比較の種類を示す。正確な費用を出せないなら、費用のどの部分が判断を変えたかを説明する。

反対に、未測定の成果を数字へ見せかける必要はない。「本稼働した」「利用者が増えた」「担当者が安心した」は別の変化である。何を数えたかを明らかにすれば、運用の進展として読める。因果を確かめていないなら、導入と同じ時期に起きた変化として書く。

製造業のコンテンツマーケティングでは、一つの顧客回答を、記事、事例、動画、営業資料へ広げる流れを扱った。導入事例は、その中でも顧客の固有条件を含む。営業資料の短い要約へ展開しても、元の事例へ戻れば、選定、実行、測定、限界を確かめられる状態にする。

導入事例は成果の数字を大きく見せるための器ではない。特定の状況で行われた選択と実行を、次の読者が比較できる証拠へ変える記録である。成果値が強いときほど、そこへ至る基準、選定、実行、測定を近くに置く。失敗や未測定を含め、どの条件なら同じ判断を試せるかまで読めたとき、一社の物語は他社の判断材料になる。

Sources / 参考資料