業務用クラウドサービスの画面でボタン名が変わったのに、サイトの機能紹介には以前の名称が残り、ヘルプの画像も旧画面のまま。利用者は説明どおりに探しても操作できず、問い合わせ担当は実際の画面を見ながら説明し直すことになります。変更が小さく見えても、販売ページ、料金表、ヘルプ、告知、サポートの返答が別々に直されると、どれが現在の案内か分かりません。
この記事はSaaS・業務用クラウドサービスの経営者、製品担当、Web担当者に向けて、機能版・画面・ヘルプの変更台帳を基に公開情報を直す方法を示します。製品のリリース手順や社内開発体制を設計する記事ではありません。製品担当が確定した仕様を、Webのどのページ、どの画像、どのリンクへ反映し、どう確認するかに範囲を絞ります。以下の台帳と画面例は架空のSaaSを想定しており、実在製品の機能や更新履歴ではありません。
まず、食い違いが見える場所を並べる
サイト内で同じ機能を説明する場所は、機能一覧だけとは限りません。トップの訴求、用途別ページ、料金やプラン比較、導入案内、ヘルプ、FAQ、更新のお知らせ、営業資料のダウンロード先まで広がります。一つのボタン名や操作手順が変わったとき、どのURLに同じ語があるかを探します。製品内のメニュー名とWebの見出しが違うだけなら言い換えの可能性もありますが、操作できる対象や順番が違えば利用者の判断に影響します。
みやあじよのSaaS・業務用クラウドサービス向けホームページ制作は、機能を仕事の場面に結び付け、実際の画面を確認して公開用のデータに置き換えた画像や操作図を作る方針を示しています。管理者向けガイド、利用者向けヘルプ、問い合わせ窓口、お知らせへの導線と更新方法も制作範囲の例です。本稿では、その更新時に「機能が使える状態」と「サイトでそう説明している状態」を照合する仕事に絞ります。
公開資料を直す前に、製品側で何が変わったかを確認します。新機能、名称変更、操作順の変更、プラン別の提供条件、権限別の見え方、廃止予定などを区別してください。開発予定や一部顧客への先行提供を、全利用者が今使える機能として書かないことが重要です。地域、契約プラン、管理者設定によって画面が違う場合もあります。Web担当者が画面だけ見て一律の説明を作らず、製品担当の正本と照らします。
Microsoftの公開されている変更履歴では、機能の追加、日付の変更、取り下げを分けて記録しています。これは特定製品の例であり、自社に同じ公開書式を採用する必要はありません。ただ、更新のお知らせを「新しくなりました」だけで終わらせず、何がいつ、どの状態に変わったかを確認できる形にする参考になります。予定と提供中を混ぜないことは、サイトの編集でも役立ちます。
機能版・画面・ヘルプを一行で結ぶ
変更台帳を作る目的は、全ての開発チケットをWeb担当が読むことではありません。サイトに影響する変更について、正本の機能情報と公開先を結び、更新漏れを見つけることです。最初は直近の一件で十分です。例えば「申請一覧の操作名が変わった」という架空の変更なら、対象の機能版、実画面、機能紹介、ヘルプ、旧画像、公開予定日を一行にします。
表は左右にスクロールできます。
| 確認する欄 | 架空の記入例 | 決める担当 |
|---|---|---|
| 機能の状態 | 提供中／一部提供／予定／終了のどれか | 製品担当 |
| 対象 | 対象プラン、権限、画面、提供開始時点 | 製品担当 |
| 画面の証拠 | テスト用アカウントで確認した画面と確認日 | 製品・Web担当 |
| 公開先 | 機能紹介、比較表、ヘルプ、告知、画像のURL | Web担当 |
| 作業と承認 | 修正文、撮影し直す画像、確認担当、公開日 | Web・製品担当 |
| 公開後 | リンク、表示条件、旧案内からの移動 | Web・サポート担当 |
一行に複数の機能を詰めると、確認済みの部分と未確認の部分が混ざります。対象プランや権限が違うなら、同じ機能名でも別の行に分けます。逆に、同じ変更が機能紹介とヘルプの両方に影響するなら、台帳には両URLを入れます。台帳に「画面の証拠」がないまま原稿を確定しないようにし、実データが写る画面をそのまま公開素材にしないことも確認します。
台帳の状態欄は「修正待ち」「製品確認中」「公開済み」「画面確認済み」など、Webの作業がどこまで進んだかを表す欄と分けます。機能が提供中でもヘルプが未確認なら、公開情報の作業は終わっていません。反対に原稿を書き終えていても機能がまだ提供前なら、現在の操作手順として公開しない判断が必要です。製品の公開日が変わったときに、台帳からWebの掲載予定を見直せるようにします。
変更の影響を一律の優先順位で処理するのも避けます。画面の色だけが変わる場合と、申込み前に見るプラン条件が変わる場合では、直すべき場所と公開の急ぎ方が違います。台帳に「読者の判断に関わるか」「今の操作を妨げるか」「旧画像だけの問題か」を記し、製品担当とWeb担当が掲載順を決めます。販売ページで誤った条件を出しているなら、そのページの修正を先に進めるなど、影響箇所から作業を並べます。緊急のお知らせが必要かも事業者が判断します。
販売ページには判断材料、ヘルプには操作を置く
機能紹介の読者は、その機能が自分の仕事に使えるか、どのプランで使えるかを知りたい。一方、契約後にヘルプを見る人は、今表示されている画面で何を押し、次に何が起こるかを探しています。同じ変更でも、直す文章の粒度は異なります。販売ページには用途、対象、主な制限と詳しいヘルプへの導線を置き、操作の細かな順序と画面画像はヘルプへ集めます。販売ページに手順を全件転載すると、更新箇所が増えます。
ただし、操作条件が購入前の判断に影響するなら、ヘルプだけに隠しません。例えば上位プランだけで使える操作や、管理者だけが設定できる機能なら、比較表や機能詳細にも対象を示します。ヘルプには権限別の画面差と操作順を示します。どのページが詳しい条件の正本か、文言変更時に誰が承認するかを台帳へ入れます。製品担当の確認を受けずに「全プラン対応」などの強い表現へ変えないようにします。
画像の更新では、画面全体を撮り直せばよいわけではありません。変更した箇所が見えるか、前後の操作が分かるか、端末幅で表示が異なるかを確認します。デモ用の無記名データを使い、顧客名、メールアドレス、社内の設定値を写さないようにします。画面上のボタンの色や位置にだけ依存した説明も避け、ボタン名やその後の状態を本文で伝えます。スクリーンショットが小画面で読めない場合は、必要な範囲の拡大画像や短い手順へ分けます。
公開日と画面確認日を分けて記録する
ヘルプのフッターに「最終更新日」があっても、その日に現行画面を確かめたとは限りません。原稿を直した日、製品担当が仕様を承認した日、公開した日、実画面を確認した日を混同しないよう、少なくとも台帳では別に持ちます。ユーザー向けには必要な改訂日と適用対象を示し、細かな社内履歴を無理に公開する必要はありません。公開日に製品の一部提供が続くなら、対象条件も並べます。
公開前の確認は、編集画面だけで終わらせません。対象のプランと権限でテスト用アカウントを用意し、ヘルプの入口から手順を追い、説明と画面が一致するか確かめます。未ログインの読者が読む機能紹介からヘルプへ進む場合、リンク先が契約者専用で止まるかも確認します。止まるなら、公開できる概要へつなぐか、ログインが必要だと表示します。公開側と契約者側のどちらに直すかを担当者が決めます。
旧URLからの流入にも注意します。機能名が変わってヘルプを移す場合、古いリンクをたどる人が新しい説明へ進めるか確認します。検索やブックマーク、サポートメールから来る読者を想定し、古い手順を残すなら対象版を明記します。古い機能を使う顧客が残る間は、全員向けの新画面だけを出すと混乱する場合があります。削除、案内の分岐、転送の選択は実際の提供状態と製品担当の判断に合わせます。
ヘルプを製品外の別サイトで運用しているなら、販売サイト側の編集権限だけでは更新できないことがあります。台帳には公開先の管理者と依頼方法も書きます。製品側のリリース通知を受けた人、ヘルプの原稿を直す人、公開ボタンを押す人、実画面を確かめる人が異なるなら、誰の確認で次に進むかを決めます。反映を待つ間は、古い説明をただ放置せず、必要な読者へ現在の案内と確認先を示すかを判断します。社内の通知だけで利用者に伝わったと見なさないことです。
Google検索のサイトマップ案内では、ページの最終更新時刻は主な内容が実際に変わったときの値とし、更新していないのに日付だけ新しくすることは勧められていません。ヘルプの改訂日にも、読者が何の変更を信頼できるかという同じ編集上の考え方が必要です。ただしサイトマップの日付は検索への情報であり、利用者に見せる機能の適用日や画面確認日の代わりではありません。三つの用途を分けて管理します。
更新後は入口から操作まで通して点検する
受入確認では、まず機能紹介から対象プランと利用条件を読み、ヘルプへ移り、実画面で操作する経路をたどります。次に更新のお知らせから変更点を読み、旧ヘルプURLから新しい手順へ到達するか見ます。最後にサポート担当が回答に使うリンクを開き、顧客に案内する対象版が合うか確かめます。スマートフォンとデスクトップでヘルプの見え方が違う場合は両方を確認します。
リリース後に「説明と画面が違う」という連絡が来たら、すぐ文章だけを直さず、契約プラン、権限、画面の版、URL、利用した端末を確認します。製品側の表示不具合なのか、ヘルプの記述漏れなのかを切り分けるためです。Web担当の修正範囲は案内の文言、画像、リンク、掲載先です。製品の動作修正や権限設定そのものは担当チームへ引き継ぎます。問い合わせの内容と台帳の行を結び、同じ食い違いが繰り返される場所を優先して直します。
先行するSaaSの利用開始記事は、導入時の準備、作業別ヘルプ、個別支援の置き場所を扱います。本稿は利用開始後も続く機能変更と説明の一致を対象にします。公開後は、台帳に影響URLが空欄の変更や、確認画面が古い行を定期的に見直します。問い合わせ数が減ったという成果を示すには基準と測定が必要です。まず実画面と公開情報が一致したかを確認しましょう。
みやあじよのSaaS・業務用クラウドサービス向けホームページ制作に相談する際は、変更台帳の一例、実画面、現行の機能紹介、ヘルプ、更新のお知らせを並べると、掲載先・画像・リンク・確認方法の改修範囲を決めやすくなります。製品の仕様を決める担当と、Webの説明を直す担当も合わせて共有してください。
画面と説明がそろうSaaSサイトへ
SaaS・業務用クラウドサービス向けホームページ制作では、機能紹介、ヘルプ、更新のお知らせをつなぎ、製品変更後も説明を確かめられるサイト構成を検討できます。現行の画面と変更情報を共有し、掲載・更新の方法をご相談ください。
