はじめに

カスタム開発の改修内容、リリースのたびに顧客へどう伝えるか悩んでいませんか。

この記事では、日々の改修メモをGoogleスプレッドシートに書き溜めておき、本番リリースのタイミングでGeminiに読ませて顧客向けの案内文を自動生成する運用を紹介します。

Salesforce公式のリリースノートを要約する話ではなく、自社カスタム開発側の変更履歴を扱う運用です。

改修のたびに1行、スプレッドシートに残す

やることはシンプルです。改修や新機能を作るたびに、スプレッドシートに1行追記します。列は次の5つで十分です。

対応日
機能名
対象画面・オブジェクト
変更内容(技術詳細)
顧客向け備考

技術詳細はチケットの内容をそのまま転記すれば構いません。ただし備考欄だけは、「これによって顧客が何をできるようになるか」を一言でいいので自分の言葉で書いておきます。ここをサボると、あとでGeminiに要約させても薄い文章しか出てきません。

たとえば、承認申請の差し戻し理由を必須化する改修であれば、備考欄には「差し戻し理由の入力必須化。申請者が修正点をすぐ把握できるようになります」くらいのメモで十分です。どのフローを触ったか、どのバリデーションルールを追加したかは技術詳細の列に書けばよく、備考欄には混ぜません。

この1行を書く習慣がつくまでは面倒に感じるかもしれません。ただ実際にやってみると、1機能あたり数十秒で終わります。あとからまとめて思い出す作業のほうが、よほど時間を食っていました。

リリース時にGeminiで顧客向け文面へ変換する

本番リリースの直前になったら、対象期間の行をまとめて範囲選択し、スプレッドシートのGeminiサイドパネルに指示を出します。ポイントは、技術詳細の列は読ませず、備考欄だけを渡すことです。そうしないと専門用語だらけの文章が返ってきます。

実際に使っているプロンプトの例を載せておきます。

あなたはSalesforceのカスタム開発を行う会社の担当者です。
以下の「顧客向け備考」列の内容をもとに、顧客向けリリース案内メールの本文を作成してください。

# 条件
- 読み手はSalesforceの技術に詳しくない、業務部門の担当者です
- 専門用語(オブジェクト名、フロー、バリデーションルールなど)は使わず、業務上何が変わるかを中心に書いてください
- 1機能につき1〜2行、箇条書きでまとめてください
- 文末は「〜できるようになりました」のような形に統一してください
- 冒頭に「いつもご利用いただきありがとうございます。」の一文を入れてください
- 全体で10行を超えないようにしてください

このように読み手・文体・分量・冒頭の挨拶まで具体的に指定しておくと、毎回の出力のブレが小さくなります。逆に「要約して」とだけ指示すると、その日の気分のような出力になりがちなので、条件はできるだけ細かく書いておくのがおすすめです。

行ごとに要約を自動化したい場合はGemini関数(セルに=AI()と書く機能)も使えます。ただしこれはGoogle WorkspaceかGoogle AIプランの契約が前提で、無料のGoogleアカウントだけでは動かない場合があります。導入前に管理者権限で確認しておいたほうが安心です。

出典:Gemini in Google スプレッドシートを活用する

Salesforce公式のリリースノートとは別物

ここで整理しておきたいのが、この運用が管理しているのはあくまで自社のカスタム開発の変更履歴であって、Salesforce公式のリリースノートではないという点です。

Summer '〇〇のような年3回のプラットフォームアップデートは900ページを超えることもある別ドキュメントで、そちらはそちらで管理者が別途目を通す必要があります。

両者を1つのシートにまとめてしまうと、公式アップデートと自社改修の見分けがつかなくなります。シートは分けておくべきです。

つまずいたポイント

Geminiの出力をそのまま顧客に送るのはおすすめしません。あくまで下書きとして扱い、社内の言い回しに合わせて手直しする前提で使います。「できるようになったこと」と「今後の対応が必要なこと」を混同した文章が出てくることもあるので、送信前に必ず読み直してください。

もう一つ、備考欄を書くタイミングを改修直後からリリース直前まで先延ばしにすると、結局何を書いたか忘れてしまいます。面倒でも、改修が終わったその日のうちに1行残しておくのが、結局いちばん早い方法です。

プロンプトについても、一度作って終わりにせず、実際に出てきた文面のクセを見ながら少しずつ条件を足していくと、だんだん手直しの量が減っていきます。私の場合も、最初は箇条書きの粒度がバラバラだったのですが、「1機能につき1〜2行」という条件を足してから、かなり安定するようになりました。

まとめ

改修のたびにスプレッドシートへ1行、特に「顧客向け備考」は自分の言葉で書く
リリース時に備考欄だけをGeminiに渡し、読み手・文体・分量まで指定したプロンプトで下書きを作る
自社のカスタム改修とSalesforce公式のリリースノートは別物として管理する
Geminiの出力は下書きとして扱い、送信前に必ず手直しする

現場での気づきをnoteで発信しています。

→ note