機能はあるのに、なぜ仕事が進まないのか

到達性というと、ナビゲーションへリンクを足す話に聞こえます。しかし業務の入口は、一覧、通知、検索結果、別画面からの戻り、期限超過の表示など複数あります。

日本の職場で「結局LINEで担当者へ聞く」「電話で場所を教えてもらう」が残るとき、機能がないとは限りません。正しい入口や次の操作を、特定の人しか知らないことがあります。その知識まで画面の経路へ移さなければ、システムは仕事を引き受けられません。

状態を表示する画面があっても、担当変更、差戻し、訂正、確定が別の管理画面にしかなければ、利用者はそこで止まります。書込機能は存在していても、その利用者の権限や導線から届かなければ同じです。

業務基盤では、表示できることと、必要な変更を実行できることを分けて確認します。さらに実行後、一覧へ戻るのか、次の担当へ渡るのか、完了として集計されるのかまで追います。

到達性の問題へ、毎回新しいダッシュボードを作ると、入口がさらに増えます。既存一覧の状態表示を具体化する、該当項目へ直接移す、戻り先を保つ、といった小さな接続で解けることがあります。

利用頻度が低く、誤操作の影響が大きい処理なら、あえて日常画面へ置かず、権限を持つ担当だけが明示的に開く方がよい場合もあります。到達しやすさと、誰でも実行できることは同じではありません。

仕様書の機能一覧では、検索、編集、通知、集計が別々に完成して見えます。利用者にとっては、案件を見つけ、判断し、更新し、次へ渡し、終わったと確認する一つの仕事です。

次の改善では、機能の有無を数える前に、代表的な一件を入口から出口まで進めます。「存在する」「届く」「実行できる」「続けられる」「完了する」。どこまで到達したかで見ると、機能完成率では隠れていた問題が現れます。

ある状態を判定する機能があっても、利用者がそこへたどり着けなければ存在しないのと近い結果になります。表示を見つけられるか、内容を理解できるか、必要な記録を書けるか、その後の担当へ渡せるか。到達性はメニューの置き方だけでなく、仕事が一本の経路としてつながっているかの問題です。

ピース・ビズ グループの業務基盤で見たのも、データや判定が欠けているというより、次の操作が画面から見えない、書く場所が読んだ場所から離れている、といった断点でした。機能を追加する前に、利用者が最初に止まった場所を観察すると、より小さな変更で流れが戻ることがあります。

確認するときは、機能一覧ではなく、代表的な一件を開始から完了まで追います。途中で検索、電話、別の表、口頭確認へ戻ったなら、その理由を残します。Exists、Reachable、Executable、Continuable、Completedという順に見ると、どこが足りないかを機能の数ではなく仕事の流れで話せます。