依頼系の申請は一覧を見ても誰の件か分からない。原因と一覧から逆算するフォーム設計

申請一覧を開くと同じようなタイトルが何行も並んでいる。
申請者も同じで区別がつかない。。。

採用が続く時期には、アカウント発行やPCセットアップの依頼が溢れかえり

今日中に対応しないといけないタスクってどれだっけ。

こんな気持ちになることが日常茶飯事です。
どれが誰の申請なのかは、1件ずつクリックして中身を確かめるまで分かりません。

情シスや総務への依頼業務をワークフローに載せると、この状態は検証段階でほぼ必ず出てきます。
稟議だけを載せていたときには一度も起きなかった問題です。

原因は運用の工夫不足ではなく、一覧の設計そのものにあります。

構造を整理したうえで、一覧から逆算してフォームを組み立てる方法と、設計前に埋めておく一覧設計シートまで扱います。
「台帳をExcelで別に作るしかないか」という半ばあきらめの選択肢を、取らずに済む状態が目標です。

一覧は「誰が申請したか」を映す画面

ワークフローシステムの申請一覧には、たいてい決まった顔ぶれの列が並んでいます。
チケット番号、タイトル、申請者、申請日、ステータス。どの製品でも大きくは変わりません。

この並びは、稟議を前提にすると理にかなっています。稟議では申請者こそが案件の主役だからです。
誰が起案したかが分かれば、どの部門のどんな案件かはおおよそ見当がつく。
承認者への通知も検索も絞り込みも、すべて申請者を軸に組み立てられていて、それで困ることはほとんどありません。

一方、フォームに入力された内容は詳細画面を開いて初めて見えます。
誰のアカウントを作るのか。新規なのか変更なのか。一覧はあくまで、誰が申請したかを映す画面です。

稟議しか載せていないうちは、この設計の輪郭は見えてきません。輪郭がはっきりするのは、依頼系の申請を載せたときです。

依頼系の申請には登場人物が3人いる

例えば、4月入社の中途社員1名分のアカウント発行依頼。申請するのは配属先の営業部長、作業するのは情シスの担当者です。

登場人物を稟議と並べると、1人多いことに気づきます。

稟議は、決裁が下りた瞬間に完結します。ところが依頼系の申請は、決裁が下りてからが本番です。
承認は「この人のアカウントを作ってよい」という確認にすぎず、そのあとに情シスの作業が控えています。

つまり、この申請の主役は申請者ではなく対象者です。進捗を追いたいのも承認者ではなく、作業者である情シス。
「誰のアカウントが今どの段階まで進んでいるか」を確かめたいのに、一覧に映るのは起票した営業部長の名前だけです。

決裁のための画面と、作業管理のための画面。同じ一覧に見えて、求められているものが違います。

備考への追記とExcel台帳が長続きしない理由

この物足りなさへの対処として、現場でよく取られる方法が2つあります。

1つ目は、タイトルや備考に対象者名を手で書いてもらう運用です。 「申請タイトルに入社者の氏名を入れてください」とルールを決めて周知する。

ただ、申請する上長にとって、一覧の見やすさは自分の困りごとではありません。

タイトルに氏名って言われてたっけ。

悪意なく抜けますし、書き方も「山田様アカウント」「アカウント発行（山田）」とばらけていきます。検索の頼りにするには心もとない。

2つ目は、Excelやスプレッドシートで進捗台帳を別に作る方法です。
申請が来るたびに台帳へ転記し、作業が進むたびにステータスを書き換える。一覧で見たい形を自由に作れる反面、システムと台帳の二重管理になります。

転記の手間もありますが、本当に困るのは更新が追いつかなくなったときです。依頼の証跡はシステムに、進捗の実態は台帳に。正が2つに割れます。

どちらも、フォームにすでに入っている情報を人の手で外に書き出しています。
対象者の氏名も、新規か変更かの区分も、申請時に必ず入力されている。情報が無いのではなく、一覧に出てこないだけです。

だとすれば、直すべきは運用ではなくフォームと一覧の設計のほうになります。

一覧から逆算してフォームを設計する

正直に言うと、以前はここを見落としていました。
依頼系のフォームを設計する場面で、入力項目をどう並べるか、必須をどこに付けるか。そういう相談に時間を使い切って、できあがった一覧がどう見えるかは運用開始まで話題にしませんでした。

運用後に「一覧で誰の件か分からない」とご相談をいただいて、考えを改めました。フォームは器の設計で、一覧は運用の設計です。

それ以来お伝えしているのが、逆算の順番です。

1. 作業者が一覧で確かめたい情報を先に書き出す（誰の件か、何の依頼か、期限はいつか）
2. その情報を持つフィールドをフォームに置く（自由記述ではなく、選択式や氏名欄として独立させる）
3. そのフィールドを一覧にどう出すかを決める（タイトルへの織り込み、専用一覧の列）

入力項目から考えると、一覧はできあがったものを眺める画面になります。
一覧から考えると、フォームは一覧に必要な情報を集める器になる。順番を変えるだけで、同じ項目数でも運用のしやすさが変わります。

タイトルに対象者と区分を織り込む

どの製品の一覧にも必ず表示される自由な項目が、1つだけあります。タイトルです。

タイトルは申請者が手で入力するものと思われがちですが、フォームの入力値を組み合わせて自動的に組み立てられる製品もあります。
対象者の氏名と申請区分をつないで「山田太郎のアカウント発行（新規）」の形式で自動生成する。
申請者が何も意識しなくても、一覧がそのまま台帳の目次になります。

手書きルールと違い、表記がばらけることも書き忘れも起きません。

自動生成に対応していない製品では、記入例をフォーム上に示して手入力を補助することになります。ただ前章のとおり、手入力ルールには定着の限界があります。
依頼系を本格的に載せていくなら、タイトルの自動生成と一覧のカスタマイズは製品評価の確認項目に入れておく価値があります。

作業者専用の一覧を用意する

タイトルだけでは足りない情報、たとえば利用開始希望日や依頼の内訳は、一覧の列そのものに出したくなります。
標準の検索画面は列が固定でも、フォームの特定の項目を列として選び、専用の一覧として保存できる機能を持つ製品があります。

ここで作るべきは、全員向けの一覧ではなく作業者専用の一覧です。
対象者、申請区分、希望日、ステータスだけに絞った画面を情シス内で共有する。朝この一覧を開くだけで、今日やるべき作業と滞留している依頼が見渡せます。

Excel台帳が担っていた役割を、転記なしでシステムの中に取り戻せるわけです。

依頼系申請の一覧設計シート

設計前に、次の表を埋めてみてください。左の列は作業者の立場で書き出し、真ん中と右は左に合わせて決めます。
埋まらない行があれば、その情報はフォームにも一覧にも存在しないということなので、フィールドの追加から検討します。

このシートの効き目は、フォーム設計の議論が「項目をどう増やすか」から「一覧に何を映すか」へ切り替わるところにあります。
項目は増やすほど申請者の負担になります。一覧に映すという目的があれば、増やす項目と増やさない項目の線引きに理由が付きます。

1件の申請を最初から追ってみる

4月入社の中途社員1名分のアカウント発行依頼を、もう一度最初から追ってみてください。

営業部長が申請します。フォームには対象者氏名「山田太郎」、申請区分「新規」、利用開始希望日「4月1日」を入力する。
ここまでは、設計を変える前と後で何も違いません。

違いが出るのは、送信された瞬間です。 入力値からタイトルが自動で組み立てられ、一覧に「山田太郎のアカウント発行（新規）」と表示される。
情シスは一覧を開いた時点で、誰の件かが分かります。

作業者専用の一覧を開けば、希望日の列で4月1日が近い順に並び、ステータスの列で作業待ちのものだけを絞り込める。台帳に転記する場面はどこにもありません。

フォームに入れる項目は、設計を変える前とほとんど同じです。
変えたのは、その項目を一覧にどう映すかだけ。依頼系の申請が管理しづらいのは情報が足りないからではなく、持っている情報が一覧に出ていないからだと分かります。

まとめ

依頼系の申請で一覧が進捗管理に使えないのは、運用の工夫が足りないからではありません。
一覧が「誰が申請したか」を映す設計になっていて、依頼の主役である対象者が最初から映らないからです。

手書きルールやExcel台帳でその隙間を埋め続けるのではなく、次の2つでシステムの中だけで完結させられます。

• 対象者と申請区分を、タイトルに自動で織り込む
• 作業者専用の一覧を用意し、必要な項目だけを列に出す

どちらも、フォームに新しい情報を足す話ではありません。すでに入力されている情報を、見える場所に移すだけです。

この整理と一覧設計シートが、依頼業務をワークフローに載せるときの参考になれば幸いです。