公開後の業務アプリを何から直すか、問い合わせ・利用データ・不具合から決める改善の優先順位

業務アプリや自社 SaaS を公開すると、問い合わせ、利用状況の数字、不具合の報告が一度に届きはじめます。どれも直すべきことに見えますが、開発に使える時間と予算は限られています。何から直すかが決まっていないと、声の大きい依頼から順に対応することになり、公開後の数か月が過ぎてしまいます。

この記事では、公開後の改善の優先順位を決める材料を 3 つに分けて整理します。想定する読み手は、自社の業務アプリや SaaS を運営する事業責任者と、開発を外部に頼んでいる発注側です。

1. 改善の入口は 3 つあり、性質が違う

公開後に届く情報は、大きく次の 3 つに分けられます。

• 問い合わせ・要望は、利用者や社内の担当部署から、電話、メール、フォームで届く声です。
• 利用データは、ログイン数、機能ごとの利用回数、途中で離脱した画面など、アプリが記録している数字です。
• 不具合の報告は、エラー、表示の崩れ、動作の遅さなど、期待どおりに動いていないという連絡です。

プレジデントオンラインの記事（Progate COO の宮林卓也氏、2023 年 10 月 9 日公開）では、リリース後の改修の多くは利用者のフィードバックが発端になると述べられています。同じ記事では、「何もしていないのにおかしくなった」という声の多くは、想定されていない使い方によるもので、バグの場合もあるとされています（出典）。

つまり、届いた声をそのまま「不具合」として積むと、直す必要のないものまで開発の予定に入ってしまいます。入口を分けて受け取るだけで、優先順位の議論がしやすくなります。

2. 問い合わせは「件数」ではなく「誰の何が止まるか」で見る

問い合わせが多い項目から直したくなりますが、件数だけでは判断できません。私たちは、次の 3 点を一緒に記録しておくことを勧めます。

• 誰が困っているか（部署、役割、取引先の種類）
• 何ができなくて困っているか（業務の何が止まるか）
• 代わりの手段があるか（手作業や別の画面で回避できるか）

たとえば、受注担当者が毎日使う画面の入力ミスが多い、という声と、月に 1 回しか使わない出力帳票のレイアウトの要望があるとします。件数が同じでも、業務が止まる度合いは違います。「代わりの手段がない」「毎日の業務が止まる」ものを先に置く、という並べ方が基本になります。

3. 利用データは「使われていない場所」を見つける材料にする

利用データは、直す場所を探すのに向いています。たとえば、次のような見方です。

• 公開時に想定していた主要な操作が、実際に使われているか
• 途中の画面で止まっている人が多くないか
• 使われなくなった機能が、思ったより早く出てきていないか

ソウゾウのアプリ改善ガイドは、データで現状を確認するステップの例として、先月のアクティブユーザーが 30 人から 12 人に減ったケースを挙げています（出典）。

私たちは、利用者が数十人の段階では、割合ではなく人数で見るほうがよいと考えています。数字が動いた理由は、数字だけでは分かりません。そこで、利用が減った部署に短く聞き取りをして、理由を確かめる手順をセットにします。

4. 不具合は「影響の広さ」と「データが壊れるか」で先に分ける

不具合の報告は、問い合わせとは別に扱います。最初に見るのは、次の 2 点です。

1. 影響が及ぶ範囲は、特定の人だけか、全員かです。
2. データが壊れる、または失われるかは、表示が崩れるだけか、保存された値が誤るかで見ます。

受注や在庫のように、業務の記録そのものに関わる不具合は、利用者数が少なくても先に直します。表示の崩れのように、業務の結果に影響しないものは、他の改善と同じ土俵で並べます。この線引きは、公開前に開発チームと文書にしておくと、公開後に慌てずに済みます。

5. 3 つの材料を、影響と手間の 2 軸で並べる

材料がそろったら、改善の候補を 1 つの表に並べます。ソウゾウのガイドは、各項目を「インパクト（どれだけ改善されるか）」と「実装の難易度（自社でできるか、費用がかかるか）」の 2 軸で整理しています。

外部の開発会社と進める場合は、次のように並べます。

影響	手間	扱い
大きい	小さい	今月に入れる
大きい	大きい	見積もりを取り、予算を確保して計画に入れる
小さい	小さい	空きがあれば入れる
小さい	大きい	保留にして、次の見直しで再確認する

「影響」は、2 の問い合わせの 3 点と、4 の不具合の 2 点で決めます。「手間」は開発会社に概算を出してもらいます。数字は正確でなくても、大・小の判断ができれば十分です。1 か月に直す数は、開発の枠に合わせて決めておくと、先延ばしが減ります。

6. 直したら、結果を見て次の周期に入る

改善を入れたら、直す前と直した後を比べます。ソウゾウのガイドでは、2〜4 週間後に変更前後を比べるとしています。比べるものは、直す前に決めておきます。

• 問い合わせの件数と内容が減ったか
• 該当する操作の利用回数が増えたか
• 同じ不具合の報告が止まったか

比べる数字を決めずに直すと、「直した」という事実だけが残り、効果は分かりません。比べる数字の決め方や計測の設計は、SaaS の「使い始めた」をどう定義するかとGA4 のイベント名を決めて壊れていないか確かめる手順で扱っています。

公開後の改善を、最初から計画に入れる

公開後の改善は、公開前に枠を決めておくと進めやすくなります。月に何件まで直すか、誰が優先順位を決めるか、見直しを月に 1 回行うか。この 3 つを、開発会社との契約や運用の取り決めに入れておくことを勧めます。

Urchin&Company では、SaaS・業務アプリ開発で、要件定義から設計・開発・公開後の改善まで一貫して支援しています。公開後の改善の進め方に悩んでいる場合は、サービスのページをご覧ください。