改善を止めずに利用者の混乱を減らすには、変わる日を決めて知らせる

要望に応えて業務システムをこまめに直すほど、使う人は「昨日と画面が違う」と戸惑います。改善の速さは本来うれしいことのはずなのに、使う側の混乱につながってしまう。改善を止めずに混乱を減らすには、変更そのものではなく、変更の伝え方を設計する必要があります。

弊社が開発・運営している「SkillPort」（エンジニアの経歴書＝スキルシートを一か所で管理するサービス・ベータ提供中）でも、この悩みにぶつかりました。2026年10月に、本番への公開を毎週月曜にまとめ、変わった場所に印を付け、利用者へのお知らせは人が読んでから送る形に改めました。その実例をもとに、変更の伝え方の考え方をお伝えします。

改善は止めずに、「変わる日」を決める

SkillPortはベータ版として数社に使っていただいていて、いただいた要望をもとに画面やメニューを毎日のように直していました。利用者に話を聞くと、直ること自体は助かっている一方で、変化が速すぎて混乱している、という声がありました。

変更は止められません。そこで、一般的なサービスがどう変更を伝えているかを踏まえて、伝え方の方針を決めました（10月20日）。

まず、画面・メニュー・操作が変わるものは、毎週月曜にまとめて本番へ出すことにしました。平日に仕上がった改善は、確認用の環境（検証環境）までに留めておき、月曜にまとめて公開します。「毎日少しずつ変わる」より「月曜に変わる」ほうが、使う人は慣れやすいと考えたからです。

ただし、障害の復旧、セキュリティの修正、データが壊れる不具合の修正は、曜日を待たずに出します。その場合も、利用者の操作が変わらないものに限ります。画面が変わる修正は月曜に回します。「いつ変わるか」を決めておくことと、急ぎの直しを遅らせないことは、こう線を引けば両立できます。

何が変わったかは、使っている場面で知らせる

変わる日を決めても、どこが変わったのかが分からなければ、使う人は探し回ることになります。そこで、知らせる場所を画面の中に用意しました。

ひとつは、メニューの印です。名前・場所・中身が変わったメニューの横に、公開の月曜から14日間、橙色の小さな点を出します。メニューを開いた人には、それ以降は出しません。件数を知らせる赤い印と見分けがつく色にし、文字ではなく点にしたのは、文字を足すとメニューの名前が折り返して読みにくくなるためです。

もうひとつは、ログインしたときに出す「今週の更新」の小窓です。目玉になる変更がある週だけ、その人に関係する目玉を最大3件出し、いつも使っていただいているお礼と、変更が続いていることへのお詫びを一言添えます。毎週必ず出すと、読まずに閉じるだけの習慣になってしまうので、出す週を絞りました。閉じれば既読になります。あわせて、ログイン後の画面に「ベータ版」と表示し、まだ変わりうる段階であることが分かるようにしました。

小窓は、見本を実際に見て直してから出しています。最初の形では幅が狭く、説明の折り返しが多くて読みにくかったため、幅を倍にし、目玉の説明がほぼ1行に収まるようにしました。

一方で、ページごとの使い方の説明を作るのは後に回しました。変化が速い今は、作ってもすぐに古くなるからです。

知らせる中身は、受け取る人に合わせて絞る

最初の月曜に向けて、前回の公開以降に入った利用者向けの変更を洗い出したところ、24件のうち半分以上が営業向けの機能でした。営業向けの機能は、使える組織にしか見えない作りです。全員向けのお知らせに書くと、見ることのできない組織にも、その説明が並んでしまいます。

そこで、全員向けのお知らせ（画面のお知らせ・小窓・管理者宛てのメール）には営業以外の変更だけを載せ、営業向けの機能を使う組織には別に伝えることにしました（10月21日）。

変更を漏れなく並べることが、親切とは限りません。受け取る人が「自分に関係ない」と感じる項目が増えるほど、大事な知らせも読まれなくなります。

利用者に届く文面は、人が読んでから送る

組織の管理者には、その週の更新をまとめたメールも送ります。このメールは、本番へ出した後に自動で送る作りで準備していました。10月21日、送る前に私が確認する手順を挟むことに決めました。本番へ出した時点で自動で送られるのは危険で、確認が要ると判断したためです。

毎週の公開と、管理者へのお知らせメールの流れ

1平日の改善は検証環境まで
2月曜にまとめて本番へ公開
3お知らせメールの見本が運営にだけ届く
4私が見本を読んで承認する
5承認の後に、各組織の管理者へ送る

承認しなければ1通も送られない。出典：SkillPort 開発記録（2026年10月20日・21日）

承認するまでは、1通も送られません。直したいところがあれば、承認せずにお知らせを直し、見本を送り直させます。送り始めた後に問題が分かったときも、まだ送っていない分は止められます。承認を待つ時間を見込んで、送れる期間は公開から6日間にしました。運用を始めた最初の回も、見本を読んでから承認して送っています。

自動で送る仕組みは便利ですが、一度送ったメールは取り消せません。利用者に届く文面には、人が読む関門を1つ置くことにしました。

改善を続けるシステムを発注するときに役立つこと

「いつ変わるか」を先に決めておきましょう

公開後も改善を続けるシステムでは、変更を出す曜日やまとめ方を、開発会社と先に決めておくことをおすすめします。いつ変わるかが決まっていれば、使う側は備えられますし、社内への周知も段取りしやすくなります。急ぎの修正だけは例外にする、という線も一緒に決めておくと安心です。

変更の伝え方も、作るものに含めて考えましょう

どこが変わったかを画面の中で知らせる仕組みは、後から足すより、最初から作る範囲に入れておくほうが手戻りが少なく済みます。改善が速いシステムほど、変更の伝え方も設計の対象です。

自動で届く文面には、確認の関門を置いてもらいましょう

利用者や取引先に自動で届くメールは、便利な反面、間違いを取り消せません。特に一斉に送るお知らせは、見本を誰が読み、誰が送ってよいと決めるのかを、作る段階で決めておくことをおすすめします。