ユーザーの要望を、どう業務の仕様へ変えるか

ここで要望を却下するのは違います。利用者は、仕事が止まっている場所を最も早く見つけます。ただし、困りごとを画面の解決策として表現しているだけかもしれません。

「ボタンがほしい」を「なぜ今は進めないのか」へ戻すと、必要なのは担当変更ではなく、権限の委譲、次の担当への通知、履歴の保存かもしれません。問題の形が変われば、仕様も変わります。

業務基盤では、状態や責任の意味を一つの場所で所有し、各画面はその能力を利用するという設計を採っています。営業のスマートフォン画面と、管理側のPC画面は見た目も操作量も違ってよい。しかし「完了」が何を意味するかは同じにします。

これはすべてを中央集権的に固定するという意味ではありません。現場ごとに追加できる選択肢や表示は残せます。共有すべき業務事実と、画面の使いやすさを別の層にすることで、両方を変えやすくします。

今は共通画面へ操作を置くと決めても、利用頻度や端末が変われば専用入口が必要になるかもしれません。却下した案を消すのではなく、どの条件なら選び直すかを残します。

次の要望が来たら、「そのボタンをどこへ置くか」より先に、「いま何が終わらず、どの事実が足りないか」を一緒に見る。要望を減らすのではなく、要望からより長く使える仕様を取り出す仕事です。

現場からの要望には、必ず実際の困りごとがあります。だから無視すべきではありません。ただ、要望の形は多くの場合、今使っている画面で思い付く解決策です。ボタンを一つ増やしたいという言葉の後ろに、確認に時間がかかる、例外を記録できない、次の担当へ渡せない、といった別の問題が隠れています。

仕様にする前に、誰がどの場面で困るのか、終えたい仕事は何か、システムが持つべき事実は何かを順に分けます。同じ会社名や状態を、画面ごとに別の意味で持たせると、後から集計、権限、通知が崩れます。共通の意味は中央へ置き、各チームに必要な入口や表示は表面で調整する。この分け方なら、現場の使いやすさと全体の一貫性を両立しやすくなります。

採らなかった案も残します。今は不要でも、利用者が増えた、例外の種類が増えた、別の部門が同じ情報を使う、といった条件が変われば、判断は変わります。要望を断ることが目的ではなく、将来も説明できる仕様へ翻訳することが目的です。