検索機能の開発依頼で伝える一致条件と閲覧権限

検索機能の開発要件は、「キーワードで絞り込める」から一段掘り下げ、検収できる条件へ変えます。同じ入力でも、完全一致・前方一致・部分一致のどれを採るかで結果が変わります。さらに、入力が空欄のときの動作、結果の並び順、ページを切り替えたときの扱い、利用者ごとの閲覧範囲まで決めて、初めて期待動作を照合できます。

見積依頼では、検索画面の見た目より先に「どの条件なら納品可とするか」を表にします。一致方法は項目ごとに選びます。管理番号と取引先名では、利用者が入力する文字と探し方が異なるからです。どの項目にどの条件を割り当てるかが、発注者側で残る判断です。

検索機能の開発要件は受入判断表で伝える

小規模な業務システムの検索で、見積前に合意したい内容は次の表に集約できます。記載内容はそのままテスト時の期待結果にできる粒度にします。

表には、見積の前提、納品時の確認、変更依頼の境界を同じ言葉で残します。機能名を並べただけの一覧よりも、発注後の認識差を見つけやすくなります。ほかの画面を含む要件の抜けは、システム要件定義のチェック項目と合わせて確認すると整理しやすくなります。

一致条件は検索項目ごとに選ぶ

2026年9月21日時点のPostgreSQL公式文書では、LIKEのパターンにワイルドカードがなければ等価演算子のように働き、末尾にワイルドカードを置けば前方一致、前後に置けば文字列中の任意位置での一致になります。つまり、完全一致・前方一致・部分一致では、同じ文字を入力しても結果集合が変わり得ます（PostgreSQL公式文書：Pattern Matching）。

そのため、項目と一致方法の組み合わせを指定します。「検索できること」という条件だけでは、期待する結果が曖昧です。以下は社内台帳を想定した運用上の提案です。

管理番号を部分一致にすると意図しない候補まで含む可能性があり、取引先名を完全一致にすると名称の一部しか分からない利用者には探しにくくなります。一致方法は、普段どの情報を手掛かりに台帳を探すかで決めます。その探し方を受入結果へ変換してください。

大文字・小文字、全角・半角、空白、かな表記、複数語の扱いも必要なら別々に指定します。「使いやすく検索」という一文では、今回の範囲が曖昧です。採用する扱いを明記し、未合意の表記変換や曖昧検索を後から求める場合は、追加範囲として見積を確認します。

空欄と該当なしを分ける

空欄は、一致方法とは別の判断です。運用上の提案として、空欄時は次のいずれかを選び、受入表へ明記します。

• 全件表示：検索条件を入れずに実行すると、閲覧権限内の台帳を表示する
• 検索しない：入力前は結果領域を表示しない
• 入力を求める：未入力で実行すると、入力が必要であることを画面上に示す

ここでいう全件の範囲は、その利用者が閲覧できるデータです。「空欄」と「条件を入力したが該当する台帳がない状態」も分けます。後者の受入結果は、該当なしと分かり、以前の検索結果が残らないこと、と書けば確認対象が明確になります。

並び順を固定してからページ切替を検収する

検索結果を複数ページに分けるなら、ページ切替と並び順をセットで要件化します。2026年9月21日時点のPostgreSQL公式文書は、ORDER BYを指定しない行順は保証されず、LIMITで部分集合を取得する場合は一意な順序を定めるORDER BYが必要だと説明しています。また、異なるLIMITやOFFSETで結果を分割するとき、予測可能な順序を強制しなければページ間の結果が一貫しない可能性があります（PostgreSQL公式文書：LIMIT and OFFSET）。

受入条件には、第一の並び順と、値が同じ場合の判定項目をセットで書きます。たとえば次のようにします。

同じ更新日時の台帳には、第二の並び順が必要です。同順位時の判定項目まで固定したうえで、先頭ページから次へ進む場合と、前へ戻る場合を確認します。利用者が列見出しから並び順を変更する機能は、固定順とは別の操作です。必要なら、選択できる項目と昇順・降順の初期値を追加範囲として切り分けます。

閲覧権限は結果一覧の外側まで確認する

権限外のデータ名や存在が周辺表示に出る状態は、検索処理が正しくても受入対象外です。2026年9月21日時点でOWASPは、設計段階に利用者種別、公開するリソース、可能な操作を列挙し、その組み合わせごとに許可操作を決め、権限が実際に強制されることをテストするよう推奨しています。また、明示的な規則に一致しない場合は既定で拒否し、検索経路を含む各リクエストで権限を検証することも推奨しています（OWASP Authorization Cheat Sheet）。

発注時には、「利用者種別×対象データ」で許否を決めます。役職名には、検索結果へ出せるデータの範囲も添えます。次は運用上の提案としての整理例です。

実際の利用者種別と範囲がこの例と異なる場合は、業務上の区分に置き換えます。受入時は、許可される検索と拒否される組み合わせの両方を試します。

権限外データが現れないことは、次の表示面で確認します。

• 結果一覧：権限外の行や名称を表示しない
• 結果件数：権限外データを含めた件数にしない
• 入力候補：権限外の名称を候補として表示しない
• 詳細導線：権限外データへのリンクを表示せず、直接の要求も許可しない

一覧から行を消しても、件数や候補から存在を推測できる余地が残ります。受入条件を四つの表示面へ分ければ、発注者も「見えない」の意味を画面ごとに確認できます。

見積前提と追加範囲を同じ表で確定する

見積依頼には、完成後の希望と今回含める条件を添えます。最低限、検索対象項目、一致方法、空欄時の動作、基本の並び順、同順位時の判定、ページ切替、利用者種別ごとの閲覧範囲が必要です。見積書の確認観点はシステム開発の見積もりで確認したい項目も参照できます。

検収では、受入判断表の各行に対して、入力条件、利用者種別、期待する表示、期待しない表示を対応させます。完全一致から部分一致への変更、検索対象の追加、表記ゆれ対応、利用者が選べる並び替え、新しい権限区分は、当初表との差分として扱えます。不具合の修正か、合意後の追加かは、この記録を基準に判断できます。

管理番号は完全一致、取引先名は部分一致、空欄では権限内の全件、更新日時と管理番号で順序を固定する、といった形まで決めてください。そして一般利用者で検索したとき、他部門の台帳が一覧・件数・候補・詳細導線のどこにも現れないことを確認します。この一続きの条件がそろえば、「検索できる」という曖昧な依頼は、見積可能で検収可能な開発要件になります。

費用、期間、契約、法務・税務上の扱いは条件により異なります。記事の確認日とリンク先の一次情報を確認し、個別判断は専門家へご相談ください。

システム開発・発注ガイドへ戻る