検索速度を機能とは別の価値として考えた日
検索の速さは便利な付加機能ではなく、営業担当の方が集中を切らさずに仕事を続けるための価値だと私は考えました。
この考えがはっきりしたのは、2026年6月24日に受信メール一覧の試作画面を見ながら話していたときです。
もともとの話題は、受信メールが増えたときの費用と動作時間でした。
メールが増えれば処理する量も増え、利用するPCによっては同じ画面でも動き方が変わるかもしれません。
その話から、単に検索できるかではなく、検索するたびにどれだけ待つのかへ関心が移りました。
受信メールの量と件数上限について考えた経緯は、開発日記#1で振り返っています。
【開発日記#1】受信メールが「とんでもない数」になる問題とどう向き合っているか
短い待ち時間ほど作業を奪う
検索待ちは長時間でなくても、繰り返すたびに判断の流れを止めるため、営業の仕事では大きなストレスになります。
打ち合わせで出たのは、待っている間に何か別の仕事へ移れるほど長くはないという感覚でした。
私はその時間について「絶妙に何かをするってほどの作業でもない」と話しています。
別の作業を始めるには短い一方で、検索結果を待つには長く感じる時間です。
案件を探し、次に人材を探し、条件を変えてもう一度検索するたびに、この小さな中断が挟まります。
一度の待ち時間だけを見れば小さくても、検索を重ねる仕事では、そのたびに考えていたことから意識が離れます。
だから私は「死ぬほどストレスだと思うんだよ」という強い言葉を使いました。
問題は待ち時間の長さだけではなく、短い中断が何度も仕事の間へ入り込むことでした。
GmailとOutlookで感じていた遅さ
身近なメール検索で感じていた遅さが、検索体験を重視するきっかけになりました。
打ち合わせでは、Gmailの検索が遅いという実感が話題になり、私も「アウトロックだってめちゃくちゃ時間かかるからね」と応じています。
これはGmailやOutlookの性能を測定して比較した結果ではありません。
日常的にメールを探すなかで感じていた、検索のたびに少し待たされる体験についての会話です。
SES営業では、メールを一度見つければ終わりとは限りません。
案件名やスキル、商流、単価など、見る条件を変えながら候補を確かめていきます。
そのため、一回の検索だけでは目立たない遅さでも、探す回数が増えるほど使い心地に影響します。
使える検索と繰り返し使いたくなる検索は、同じではないと感じました。
利用者のPC性能差を無視できない
開発側のPCで速く動くだけでは、営業担当の方にとって速い検索だとは言い切れません。
打ち合わせでも、開発に使っているPCでは速くても、利用者のPCでは遅くなる可能性があるという話が出ました。
同じ件数を扱っても、端末の性能や利用環境によって体感は変わります。
だから試作の速さを見たときも、その場のPCで動いたことをそのまま製品全体の性能として扱うことはできませんでした。
私のPCでも動かし、どのくらいの速さに感じるかを確かめようという話になりました。
これは厳密な性能試験ではなく、実際に使う環境へ近づけて体験を見るための確認です。
検索速度は開発環境の数字だけではなく、利用者が普段のPCでどう感じるかまで見なければ判断できません。
試作で手元にデータを持たせた理由
当時の試作では検索のたびにサーバーから取得せず、PC側に約1000件を持たせることで、すぐに絞り込める体験を確かめていました。
ここでいう約1000件は、2026年6月24日の打ち合わせ時点で試作に持たせていた件数です。
現在の正式な保存件数や検索上限を示す数字ではありません。
また、この試作で感じた速さも、計測済みの性能値や保証された応答時間ではありません。
手元にあるデータを条件に応じてすぐ絞り込むと、入力や選択に合わせて結果が変わる感覚を作りやすくなります。
打ち合わせでは、この動きを「リアルタイム検索みたいなの」と表現しました。
重要だったのは技術方式そのものではなく、営業担当の方が条件を変えたときに待たずに次の判断へ進める感覚でした。
サーバー検索と手元検索の体験差
検索のたびにサーバーへ取りに行く方式と、手元に持ったデータを絞り込む方式では、同じ検索機能でも待ち方が変わります。
打ち合わせでは、サーバー側で毎回処理する場合、操作のたびにデータを取りに行く流れになるという話が出ました。
一方で、試作のようにPC側へ一定のデータを持たせれば、条件を変えた直後に結果を返す体験を考えられます。
ただし、手元に持たせれば常に正解という話ではありません。
扱う件数、端末性能、データの更新方法、処理負荷をどこへ持たせるかによって、適した設計は変わります。
この日の会話も方式を確定したものではなく、速いと感じる検索体験をどう作るかという設計検討でした。
処理する場所そのものを見直し、ローカル処理案を一旦見送った経緯はこちらで紹介しています。
【開発日記#2】ローカル処理という発想｜検討して一旦見送った理由
1万件でも爆速は理想の言葉
「1万件でも爆速」は実測や現在仕様ではなく、検索体験の理想を話すなかで出た仮定の言葉です。
打ち合わせでは「1万件でも爆速みたいなできたら」と可能性を話しました。
それに対して私も「それすごいけどね」と答えています。
この会話から、現在のDot Linkが1万件を高速検索できると受け取ってほしいわけではありません。
当時確認していたのは約1000件をPC側に持たせた試作であり、1万件での実測はしていませんでした。
リアルタイム検索のような体験についても、当時のアイデアであって、現在の正式機能や性能保証を示すものではありません。
それでもこの言葉が残ったのは、件数が増えても検索のたびに思考を止めない体験が作れれば、それ自体が製品の優位性になり得ると感じたからです。
機能を増やすだけでなく、今ある機能を気持ちよく繰り返せることにも価値があると考えました。
速さだけで探しやすさは完成しない
検索が速くても、条件の並び方や絞り込み方がわかりにくければ、営業担当の方は必要な案件や人材へたどり着けません。
速度は重要ですが、検索体験を支える要素の一つです。
何を検索できるか、どの順番で条件を選ぶか、結果のどこを見ればよいかも一緒に考える必要があります。
同じ打ち合わせでは、案件と人材を領域、工程、役割の順で分けるフィルタ設計も話していました。
そこでは検索項目を増やすだけでなく、営業担当の方が自然に条件をたどれる順番を考えています。
速さと探しやすさを別々に整えるのではなく、条件を選んで結果を確かめる一連の流れとして見ることが大切です。
領域、工程、役割から探すフィルタ設計の背景は、開発日記#3で振り返っています。
【開発日記#3】案件と人材を「領域・工程・役割」で分ける発想はどこから来たか
まとめ｜速さは営業の集中を守る
検索速度にこだわる理由は、短い待ち時間でも繰り返せば営業担当の方の集中を削り、次の判断へ進む流れを止めるからです。
GmailやOutlookで感じていた遅さから、検索のたびに待たない体験そのものが価値になり得ると考えました。
試作ではPC側に約1000件を持たせて速い絞り込みを確かめましたが、これは2026年6月24日時点の検討であり、現在仕様や性能保証ではありません。
「1万件でも爆速」という言葉も実測ではなく、件数が増えても思考を止めない検索を目指したいという理想でした。
私が大切にしたいのは、検索できるという機能の有無だけでなく、営業担当の方が集中したまま何度でも探せることです。
