半年前にリリースしたシステムが、いつのまにか「要望の寄せ集め」になっていた
半年前に受発注システムをリリースしたある中小企業の話をしよう。稼働開始直後から、現場の声は次々に担当者のもとへ届いた。営業部からは「この画面は入力項目が多すぎて、外出先のスマホでは操作しづらい」。経理部からは「請求書に転記する際に必要な項目が足りない。手作業で毎回別の帳票を見ている」。倉庫部門からは「在庫の反映タイミングが遅れて、二重発注が起きた」。
担当者は誠実な人だった。ひとつひとつの声に向き合い、開発会社に連絡し、修正依頼を出し、リリースし、また次の要望に応じる。この繰り返しを半年間続けた結果、画面には入力欄が増え、設定項目が増え、メニューの階層はひとつ深くなった。そして、あるとき気づく。結局、どの改善が本当に効果を生んだのか、誰にも説明できない状態になっていることに。営業部の要望に応えれば経理部の画面が複雑になり、経理部の要望に応えれば倉庫部門の入力が一手間増える。声の大きかった部署の要望ばかりが通り、静かに困っていた現場は放置されたままだった。
これは特別な失敗談ではない。むしろ、リリース後の業務システムでもっとも頻繁に起きているパターンだ。そして、この状態を変えるために必要なのは、もっと丁寧に要望を聞くことでも、もっと多くの機能を追加することでもない。必要なのは、システムが実際にどう使われているかを見て、改善に優先順位をつける仕組みそのものだ。
なぜ「リリースしたら終わり」になりやすいのか
多くの業務システム導入プロジェクトは、要件定義から設計、開発、テスト、リリースという一本の線で語られる。プロジェクトチームが組まれ、予算が確保され、リリース日という明確なゴールに向かって全員が走る。だからこそ、リリースの瞬間に「プロジェクトは完了した」という空気が生まれやすい。担当者にとっても、経営陣への報告資料にとっても、リリースはひとつの区切りとして扱われる。
しかし、システムにとってリリースはスタートラインでしかない。現場が実際に使い始めてはじめて、設計時には見えなかった使いにくさや、想定していなかった業務フローとのズレが表面化する。ところが、その段階になると開発プロジェクトの予算はすでに消化されており、体制は「保守」というフェーズに移行している。保守フェーズの契約は多くの場合、障害対応や軽微な修正を前提にした最小限の内容で、腰を据えて使われ方を分析し、改善を設計し直すための時間もコストも見込まれていない。
つまり、リリース後にこそ本当の改善が必要になるにもかかわらず、その改善のための予算と体制がもっとも手薄になるという逆転現象が起きているのだ。この構造を理解しないまま「保守契約があるから大丈夫」と考えていると、担当者は個別の要望対応に追われながら、なぜ全体が良くならないのかわからないまま消耗していく。
場当たり的な改善対応が生む三つの実害
要望が来るたびに個別対応を重ねるやり方には、見えにくいが確実な代償がある。
声の大きい部署の要望だけが通る不公平感
頻繁に問い合わせをしてくる部署や、経営層に直接意見を伝えられる立場の人の要望は優先されやすい。一方で、日々の業務に追われて声を上げる余裕のない現場ほど、実は業務上の負荷が大きいことも多い。結果として、本当に困っている人ではなく、声を上げやすい人の要望が反映されるシステムになっていく。これに気づいた現場は「言っても無駄」と感じ、次第に不満を口にしなくなる。声が届かなくなるのではなく、声を上げること自体をやめてしまうのだ。これがもっとも危険な兆候である。
機能が増えるほど、逆に使いにくくなる
個別要望への対応は、多くの場合「既存の画面に項目を追加する」「新しい設定を増やす」という形で実現される。ひとつひとつは合理的な判断でも、積み重なると画面は情報過多になり、本来の主目的である入力や確認のスピードが落ちる。ある機能のために増えた選択肢が、別の業務では迷いの原因になる。機能の総量が増えることと、業務が快適になることは、まったく別の話だ。
本当に困っている箇所が放置される
要望として言語化されにくい問題ほど深刻であることが多い。たとえば「このボタンをどこに配置すればいいかわからず毎回探している」「入力を何度もやり直している」といった摩擦は、当事者が「これが普通」と思い込んでいると、要望としては上がってこない。個別要望への対応に終始していると、こうした声にならない課題は永遠に見つからない。
「使われ方を見て改善する」とは、身構えるほど大げさな話ではない
ここで多くの担当者が誤解するのは、「利用状況を見る」と聞くとA/Bテストのような厳密な統計分析や、専門のアナリストが必要な高度な取り組みを想像してしまうことだ。しかし、中小企業が現実的に取り組める範囲はもっと素朴でいい。
基本の考え方はシンプルだ。アンケートや個別の声だけに頼るのではなく、システムの利用ログという事実を横に置いて判断する。具体的には次のような問いに答えられれば十分なスタートになる。
- どの画面が、どの部署で、どれくらいの頻度で開かれているか
- 入力を始めたのに完了せずに離脱している画面はどこか
- エラーメッセージが繰り返し表示されている箇所はどこか
- ある機能が、リリースから半年経っても一度も使われていないということはないか
これらは特別な分析基盤がなくても把握できることが多い。多くの業務システムには操作ログやアクセスログが標準機能として蓄積されている。開発会社に依頼すれば、月に一度、これらの数字を簡単な表にまとめてもらうだけでも十分な材料になる。専用のアクセス解析ツールを入れるまでもなく、まずは「誰が、どの画面を、どれくらい使っているか」という事実を可視化することから始めればいい。
この事実と、現場からの個別の声を突き合わせたときにはじめて、要望の背景が立体的に見えてくる。「この画面が使いにくい」という声が、実際にはその画面の利用者がごく一部の部署に限られているなら、改善の優先度は限定的かもしれない。逆に、要望としては声が上がっていないのに離脱率が突出して高い画面があれば、そこには言語化されていない大きな課題が眠っている可能性が高い。声と事実、その両方を見て初めて、限られたリソースをどこに投じるべきかの判断ができる。
中小企業でも無理なく回せる改善サイクルの作り方
専任のシステム部門を持たない中小企業でも、次のような小さなサイクルなら十分に回せる。大切なのは、頻度と対象を欲張らないことだ。
月に一度、利用状況を振り返る時間を三十分だけ確保する
開発会社や保守担当者に、主要画面の利用回数、エラー発生件数、直近で寄せられた要望の一覧を簡単にまとめてもらう。これを毎月同じ日に、三十分程度で確認する時間を固定してしまう。分析のための特別な会議を新設する必要はなく、既存の定例ミーティングの冒頭十五分でも構わない。継続できることのほうが、精緻さよりも重要だ。
現場ヒアリングを「個別対応」から「定例の場」に変える
要望が届くたびに個別に対応するのではなく、四半期に一度など、各部署の担当者を短時間集めて「最近使いにくいと感じた場面」をまとめて聞く場を設ける。個別対応をやめるという意味ではなく、緊急性の低い要望は定例の場で扱うと決めておくことで、その場しのぎの対応に振り回されなくなる。ここで出た声を、先の利用状況データと突き合わせて優先順位をつける。
優先順位づけには、影響範囲と発生頻度の二軸を使う
すべての要望に完璧な優先順位をつけようとすると疲弊する。実務的には、その課題が「どれだけ多くの人に影響するか」と「どれだけ頻繁に発生するか」の二つを軸に、要望をおおまかに三段階(すぐ対応する、次回のまとめ改修で対応する、いったん保留する)に振り分けるだけで十分機能する。声の大きさではなく、この二軸で判断すると宣言しておくことが、部署間の不公平感を減らす最も実効性のある方法になる。
改善したら、その効果を必ず振り返る
改修をリリースして終わりにせず、翌月の振り返りで「その画面の利用回数やエラー件数がどう変化したか」を必ず確認する。効果が出ていなければ、なぜ出ていないのかを考える材料になるし、効果が出ていれば、次の改善判断の自信につながる。この一往復があるかないかで、改善サイクルが本当に回っているかどうかが決まる。
発注時・保守契約時に確認しておくべきポイント
この改善サイクルを実現できるかどうかは、実はシステムを発注する段階、あるいは保守契約を結ぶ段階でほぼ決まってしまう。リリース後になってから「利用状況を分析してほしい」と依頼しても、そもそもログが取得できる設計になっていなければ手の打ちようがない。発注時・契約更新時には、次の点を必ず確認しておきたい。
- 主要な画面や機能の利用ログ(アクセス日時、利用者、操作内容)が最初から取得できる設計になっているか
- 保守契約の中に、障害対応や軽微な修正だけでなく、月次または四半期ごとの利用状況レポート作成や改善提案が含まれているか
- 改善のための開発工数が、保守費用とは別枠で、ある程度の規模で確保できる仕組みになっているか(すべてを都度見積もりにすると、小さな改善ほど後回しにされやすい)
- 要望の窓口と優先順位の決定プロセスが、発注側の社内で明確になっているか(開発会社任せにしない)
特に見落とされがちなのが最後の点だ。改善の分析材料をいくら揃えても、社内で誰がどう優先順位を決めるかが曖昧なままでは、結局は声の大きい人の要望が通る構造に逆戻りしてしまう。保守契約の設計と同じくらい、社内の意思決定の仕組みを整えることが重要になる。
よくある失敗パターン
改善サイクルを回そうとして、途中でうまくいかなくなるケースにはいくつかの共通点がある。
- 分析を高度にしすぎて続かない。専用のBIツールや複雑なダッシュボードを導入したものの、更新や解釈に手間がかかりすぎて誰も見なくなる。まずは表計算ソフト一枚で十分だという割り切りが必要だ。
- 振り返りの場が形骸化する。月次の確認を始めたものの、次第に「特に問題ありません」で終わらせてしまい、実質的な議論が行われなくなる。数字だけでなく、必ず一つは具体的な改善アクションを決めて終える習慣が要る。
- 改善の効果測定をしない。修正をリリースした満足感で終わり、その後どうなったかを追わない。これでは何が効いたのか分からず、次の改善判断の精度が上がらない。
- 要望を出した人にフィードバックしない。対応の可否や理由を伝えないまま放置すると、現場は「言っても反映されない」と感じ、声を上げなくなる。対応しない判断をした場合こそ、その理由を丁寧に伝えることが信頼を保つ。
まとめ
業務システムのリリースは、ゴールではなく、現場との対話が本格的に始まる合図に過ぎない。半年前の受発注システムの担当者が抱えていた疲弊は、要望への向き合い方が間違っていたからではなく、その向き合い方を支える仕組みがなかったからだ。利用状況という事実を確認する習慣、現場の声を定例で受け止める場、そして優先順位を公平に決めるための軸。この三つが揃えば、個別対応に追われる日々から抜け出し、限られたリソースを本当に効果のある改善に振り向けられるようになる。
リリース後も現場の声に向き合い続けようとする担当者の努力は、それだけで十分に価値がある。あとは、その努力を空回りさせない仕組みを一つずつ整えていくだけだ。完璧な分析基盤も、専任のデータアナリストも要らない。月に一度、三十分の振り返りから始めればいい。その積み重ねが、半年後には「なんとなく複雑になったシステム」を「使うたびに手に馴染むシステム」へと変えていく。