業務システムの検索条件は、登録項目をすべて並べるのではなく、利用者がどの作業のために記録を探すかから設計します。今日対応する案件を探す場面と、過去の処理を調べる場面では条件が違います。よく使う条件を見つけやすくし、抽出された範囲を利用者が説明できることを優先してください。
探す場面を具体化する
利用者へ、何を探すかだけでなく、その後に何をするかを聞きます。未処理を確認する、担当を変更する、請求の対象を照合するなど、次の作業が分かると必要な条件が見えます。画面にある項目すべてを選択できることが、検索の使いやすさとは限りません。
実際に使っている表や一覧から、並べ替え、手作業の絞り込み、検索後の確認を観察します。複数の条件を毎回組み合わせているなら定型の検索として用意する候補です。まれな調査用条件は詳細条件へ分け、日常の画面を複雑にしない方法を検討します。
条件の意味を揃える
状態に「未完了」を設けるなら、保留や取消を含むかを定義します。担当者が未設定の対象をどう扱うかも決めます。利用者によって同じ言葉の意味が違うと、検索結果を見ているのに認識が合いません。登録側の項目定義と検索側の条件を対応させます。
日付は登録日、更新日、対応予定日などを区別します。開始日と終了日の端を含めるか、時刻をどの基準で扱うかも確認します。「最近」のような相対条件は便利ですが、保存した条件を後日開くと対象が変わります。固定期間と相対期間を画面で分かるようにしてください。
条件の組み合わせを決める
複数の担当者を選ぶ場合は、いずれかに該当する対象か、すべての条件を満たす対象かを確認します。項目をまたぐ条件では、意図せず対象を狭めることがあります。選択肢や補足で意味が分かるようにし、特殊な条件式を利用者へ過度に求めない設計にします。
空欄の扱いも重要です。入力しないことが「指定しない」なのか、「未入力の記録を探す」なのかを区別します。自由文検索では、完全一致、部分一致、複数語の扱いを用途に合わせます。記号や表記揺れが多い識別子は、名称検索とは別に確認したほうがよい場合があります。
検索シナリオの想定例
対応待ちの案件一覧を想定すると、「目的:自分が次に確認する案件を知る」「状態:対応待ちと再確認」「担当:自分、または未設定」「期限:指定日まで」「除外:取消済み」と記入します。どの条件を組み合わせるかを業務の言葉で整理する例です。
この場面では、期限が未設定の案件を除外すると見落とす可能性があります。未設定を含める選択肢か、別の確認一覧が必要かを判断します。検索結果に出ない対象が正常に除外されたのか、条件の不足で消えたのかを確認できることが大切です。
初期条件と保存条件を扱う
初期条件は、最初に作業する範囲に合わせて選びます。前回の条件を残す場合は、利用者が気付かず狭い範囲を見ていないかを確かめます。適用中の条件を表示し、解除や初期状態へ戻す操作を見つけやすくします。条件を消したあと何件が対象になるかも分かると確認しやすくなります。
検索条件を共有する場合は、自分を示す条件や権限の違いで結果が変わることを考慮します。条件を保存しても、その時点のデータ一覧を保存したわけではありません。後から同じ結果を証跡として必要とする業務では、出力時点と条件を別に記録する方法を用意します。
権限と結果表示を検証する
検索条件を変えても、閲覧できない対象が表示されないことを確認します。画面で選択肢を隠すだけでなく、直接の要求や出力にも制限が適用される必要があります。件数や集計だけから非公開情報が推測されないかも、情報の性質に応じて検討します。
結果がない場合は、条件が厳しいのか、対象の記録がないのかを確認する助けを示します。すぐ条件を広げる案内が適する場合もありますが、権限がないことを不用意に説明しない配慮も必要です。正常例、空欄、境界の日付、複数選択を使い、期待した対象が抽出されるか確かめてください。
検索条件設計のよくある質問
条件は多いほうが便利ですか。利用する場面が分かる条件を優先し、日常と調査用を分けます。項目数の多さより意味の明確さが重要です。
検索結果を集計に使えますか。条件、権限、基準時点が揃っていれば利用できますが、画面の絞り込みと正式な集計の定義が同じかを確認します。
関連サービスと基礎資料
システム・アプリ開発の対象範囲もご確認いただけます。
本記事の手順・確認項目は一般的な検討のための提案です。AIを使って草案を作成し、構成・表現の点検を行っています。個別の契約・運用条件は実際の環境に合わせて確認してください。