表の列ではなく、仕事の流れを書き出す
最初に既存の表をそのまま画面へ写すことを考えると、使っていない列や、担当者だけが知るルールまで持ち込むことがあります。「相談を受ける→担当を決める→対応する→完了を記録する」のように、作業の順番を先に書きます。
それぞれの段階で、誰が何を見て、どこへ入力するかを確認します。同じ情報を複数の表へ転記している場所や、メールから表へ手で移している場所を記録すると、見直す対象が具体的になります。
表計算の改善で足りる場合もある
| 困りごと | 先に確認すること |
|---|---|
| 入力の表記がばらつく | 選択肢や入力ルールをそろえれば改善できるか |
| 必要な行が見つからない | 列の整理や絞り込みで探せるか |
| 担当ごとに見せる情報を変えたい | 共有範囲と操作権限を細かく設計する必要があるか |
| 状態によって次の操作を制限したい | 更新ルールを画面とサーバー側で管理する必要があるか |
表計算でも実現できる内容と、専用の画面や仕組みが必要な内容を分けます。便利そうな機能を増やす前に、今の方法を少し整えるだけで困りごとが減らないか検討します。
最初に試す範囲を、一つの業務に絞る
架空の相談管理を例にすると、初回は「相談の登録」「担当者の設定」「未対応・対応中・完了の更新」「一覧の絞り込み」までにできます。請求、顧客向け画面、自動メールなどは、必要性を確認して別の段階に分けます。
使える状態の確認例
担当者がテスト相談を登録できる。別の担当者が許可された範囲だけ閲覧できる。完了にした相談を一覧で区別できる。必要な項目を出力できる。
「管理が楽になる」だけでなく、実際の操作で確認できる条件を書きます。どの画面で何ができれば初回の目的を満たすかを、制作前にそろえます。
権限・例外・戻す方法を忘れない
- 閲覧できる人、編集できる人、削除できる人は誰か
- 間違った入力を、誰がどのように直すか
- 同じ相談を二重に登録した場合はどうするか
- 担当者が変わったときに引き継げるか
- 元データの保存、出力、障害時の連絡方法をどうするか
画面でボタンを隠すだけでは、権限の確認が十分とは限りません。扱うデータに応じた確認をサーバー側でも行う設計が必要です。既存データを渡す前には、個人情報を除いたサンプルで、項目と業務の説明ができないか検討します。
依頼メモには「今の方法」と「困る場面」を書く
相談用メモの例
今の方法：相談をメールで受け、管理表へ転記している
利用者：管理者と担当者。必要な閲覧範囲を分けたい
困る場面：更新担当がわからず、対応漏れを確認しづらい
最初にできるようにしたいこと：担当と対応状況を一つの一覧で確認する
引き継ぐ情報：項目名と、個人情報を除いたサンプル
このメモがあれば、最初から詳細な設計書を作らなくても相談を始められます。KSCでは現在の作業と条件を確認し、対応できる範囲を検討します。常時監視や即時対応が必要な業務は、その運用条件も先に共有してください。