システム開発会社をお探しの企業さんへ。こんなお悩みありませんか？

「全文検索」という言葉をご存知である非エンジニアの方は、 おそらくシステム開発に携わるご担当者さんか、プログラミングや最新技術に興味関心のある方であろうと思います。

本記事は、自社サイトや社内サーバーで下記のような「全文検索機能」を実装したい方に向けて、 「Altus-Fiveの紹介」と「情報提供」を行う記事です。

• 求人情報検索
• 商品情報検索
• 任意のクエリ（検索キーワード）に対する検索

特に、

• 他社に見積もりを取ったところ、ニーズが特殊で要望に応えられない または 十分な性能が出せないと言われた
• 特殊なデータに対する検索なので、既存のパッケージ等では開発できないと言われた
• アクセスするための機器がPC・スマホ・タブレット等の市販品ではない（店頭で用いるディスプレイなど）

という方には、Altus-Fiveの得意とする 「フルスクラッチ型開発」 でお助けができるかもしれません。 もちろん、単に「全文検索ってどうやってるの？」という方にも興味深い内容のはずですので、 ぜひ、この記事を最後まで読んでみてください。

全文検索とは？

全文検索とは、 コンピュータ内の複数ファイルから、クエリ（検索キーワード）を含む行やファイルを全て見つけ出すこと を指します。 ファイル名などだけでなく、ファイルの中身も見て検索結果を取得するところがポイントです。

これだけではイメージが限定的になるので、具体的なシステムの例をあげてみましょう。

こうして並べてみると、色々なサービスや、社内サーバーの機能開発において重要な技術であることが分かるかと思います。 そのため、様々な全文検索のためのパッケージが開発されており、 Altus-Fiveでも多数の全文検索開発実績があります。

さて、本記事は「全文検索」について、システムの発注前に知っておくと役立つ「豆知識」を紹介します。 少し長い内容になりますが、ぜひお付き合いください。

全文検索は、実装方式によってコストと性能が変わる

実は、全文検索にはいくつかの実装方式があります。 単に「全文検索機能」と言っても、 その中で動いているロジックには随分と大きな違いがある ということなのですね。

ロジックの違いが生む違いは 「実装コスト」（≒ 工期と見積額） 、 そして 「実行時間」（≒ 検索に対するユーザーの待ち時間） です。 どちらも依頼をされる側にとっては、重要なポイントになるのではないでしょうか。

もちろん、開発者がこの領域の専門家ですので、全面的にお任せいただくことも良いのですが、 発注をされる方が知っておいて損はない知識かと思います。

ここでは大きく 「grep型」 と 「索引型」 の２種類について、具体例を用いて分かりやすく解説してみたいと思います。

grep型の全文検索とは？

grepとは、データベースから必要な情報を検索する際にエンジニアがよく打ち込むコマンドであり、耳にしたことはあるという方もおられると思います。

例えば grep "毒リンゴ" shirayukihime.txtというコマンドを打ち込むと、 白雪姫の文章（shirayukihime.txt）の中で「毒リンゴ」というフレーズが含まれる行を 全て 表示してくれます。 shirayukihime.txtという指定を除けば、今みているフォルダ内にある全てのファイルを対象とした検索を行います（全文検索）。

grepは、本当は「global regular expression print」（ファイル全体から正規表現一致行を表示）の略なのですが、 「グレップ！」 という語感だけで 「検索したい対象を含む行を鷲掴みにして表示する」 という理解をされても、とりあえず差し支えないと思います（たぶん）。

ともあれ大切なことは、grep ≒ 検索であるということ。 ただし、検索にもいくつかの方式があり、grepでは後述する 索引型 検索とは異なる方法で必要なデータを見つけてきます。

全文検索を開発する際は、 grep型と索引型、どちらで実装するかの選択 が非常に重要になるということです。

grep型検索の実装イメージ

さて、grep型の全文検索はどのように「検索対象」を見つけ出してくるかをご説明しましょう。

ここでは 「人材検索サービス」 を例に解説してみたいと思います。 （某企業さんが提供しているような、求職者を検索出来るサービスを想像してみてください。）

システムを作る際は、「データベース」に必要データを入れておきます。

データベースとは「データを入れておく箱」のようなもので、 氏名・性別・現職・学歴・経歴など、システムによって異なる「必要なデータ」を入れておけるような構造をしています。

今回は人材検索が例ですので、 データベースは「アパート」だ と想像して頂くとわかり良いかもしれません（先ほどデータベースは箱だと書きましたが、アパートの部屋もよく『箱』と呼びますね）。

1. データベースとは、サービスに登録されている人材に、仮想的に住んでもらうためのアパート である
2. 検索とは、 「この条件に該当する人材はいないか？」と聞かれた時、当てはまる人材（の集まり）をアパート内から連れてくること である

と考えると、「データベース」と「検索」の関連性が掴みやすくなると思います。

検索例（grep型全文検索の応答）

ここでデータベースから 「システム開発経験者」 だけを取り出したいというサービス側からの要求（クエリ）があったとしましょう。 grep型検索の手続きは下記のようなイメージです。

1. アパートの入り口で「このアパートにシステム開発経験者は住んでいますか？」と聞かれたら、
2. アパートの全ての部屋のドア を1つ1つ開けて、
3. 『あなたはシステム開発経験者ですか？』と問いかけ、
4. YESならばついてきてもらい、
5. アパートの全室で質問を終えたとき、ついてきてくれた人材の集まりを「検索結果」として提供する

grep型は後述する索引型とは異なり、検索そのものには 特別な準備が不要 。 アパートを巡回する「使いっ走り」（彼の仕事は、専門的にも 『走査』 と呼びます）を用意すれば良いだけなので、開発上の工数は少なくて済む傾向にあります。

注意

ここでは仮に「アパート」としましたが、実際には 道中に猛獣あり、断崖絶壁ありのジャングル から花を摘んでくるような厳しいケースもあり、その場合は実装難度が跳ね上がることになります。（そんな案件もぜひ一度、ご相談ください。）

索引型の全文検索とは？

さて、先ほどの方法とは異なる 「索引型」 の全文検索とはどんなものでしょうか。

索引型の全文検索のポイントは、 「あらかじめ、聞かれそうな質問ごとに、該当する人材のリストを作っておく」 ということです。例えば、

• 「システム開発経験者」は、アパートの0104号室、0103号室、0302号室、0305号室、...に住んでいる
• 「現年収500万円台の人材」は、アパートの0102号室、0103号室、0207号室、0301号室、...に住んでいる
• etc.

といった情報を書き留めておいた「メモ書き」をあらかじめ作っておくようなイメージです。 実はこのメモ書きが 「索引」(index)と呼ばれる もので、索引を作ることは 検索の所要時間を劇的に短くする 効果があります（ただし、全体のデータサイズやデータの性質による）。 索引型の全文検索では、検索のプロセスは下記のように変わり、

1. アパートの入り口で「このアパートにシステム開発経験者は住んでいますか？」と聞かれたら、
2. 手元のメモ書きを確認し、
3. メモ書きに書かれた全ての部屋 のドアを開け、中にいる人材についてきてもらい、
4. ついてきてくれた人材の集まりを「検索結果」として提供する

という4ステップで済みます。

ここでポイントは、先ほどの「grep型」と比べてステップが減っていることではなく、 「システム開発経験者の住んでいる部屋のドア」しか開けなくて良い ということです。

grep型検索では全ての部屋のドアを開けるため、「システム開発経験者の数」ではなく、 「アパート全体の大きさ」に比例した分だけ「使いっ走り」が汗をかかなければなりませんでした。

索引型検索ではあらかじめ「システム開発経験者の住んでいる部屋」をメモしてありますから、 「使いっ走り」は効率的に部屋を巡ることができます。 随分と「賢い」方法になっていることが分かるかと思います。

二つの方式は「ユーザーの待ち時間」が異なる

さて、システム開発者は「使いっ走り」に優しくしたい訳ではなく、 重要なのはその間待ちぼうけを食らう 「ユーザーの待ち時間」 です。

grep型と索引型の検索では、ユーザーの待ち時間が大きく異なります。 さらに 「全体のデータサイズ（登録人材数）が大きいほど、待ち時間の差は大きくなる傾向にある」 ということが分かるかと思います。

索引型全文検索のポイント - どのように索引を作るか

では常に索引型全文検索が優れているのか？というと、そうとは言い切れません。

索引型全文検索には、 データベース作成の段階で、索引をどう作るかを決める という工程があります。

現実的にシステム開発として考えた場合、「どのように索引を作るか？」という考案部分の工程が入ってきますので、工期も費用も大きくなることは否めません。

ただ、 待ち時間を考えると、grep型の検索が使い物にならないケース は多くあります。 その場合は当然、索引型全文検索などの高速な手法を選ばざるを得ないことになります。

さて、この時「索引」をどのように作るか、ということは、いくつかのパターンがあります。

• データベース全文を走査し、実際に「よく出てきた単語」ごとの覚え書きを作っておく場合
• 本物の辞書（シソーラスなど）を参照する場合

今回は一例として「人材検索サービス」を考えましたが、ケースバイケースで「良い索引の作り方」は異なってきます。より詳しい内容については、今後のAltus-Fiveブログで紹介できればと考えています。

いずれにせよ重要なことは、 grep型と索引型、発注者側も二つの方式があることを理解した上で、システムの要件にあった方式を選ぶことが大切 ということです。 以上、長い「留意点」についてお付き合いをいただき、ありがとうございました。

Altus-Fiveの強み

ここまで、システム開発を依頼したいクライアントさんを念頭におきながら、全文検索システムの方式について解説してみました。 最後に、システム開発会社としてのAltus-Fiveの強みを一点だけ、紹介させて頂きたいと思います。

フルスクラッチの開発を最も得意とする。

「フルスクラッチ開発」は、既存パッケージ等に頼らず、技術を組み合わせて０からシステムを作る開発方式。 システムの発注経験の少ない企業さんだと、「システムは０から作るのが当然では？」と思われるかもしれませんが、 実際には「パッケージ」と呼ばれる、プログラムの部品を繋げて作ることが主流です。

全文検索には全文検索のためのパッケージが、もちろん存在しています。 ただし、それぞれのパッケージには導入のための要件があり、冒頭で述べたような事情がある場合には 使えないケースも多い のです。

そんな「既存パッケージが使えない開発のご依頼」を頂いた時が、Altus-Fiveの本領発揮です。 フルスクラッチ案件が得意なので、貴社の要件 あるいは 既存システムを精査し、最適な技術の組を自社で考案・提案することが可能です。

もちろんシステム開発には「餅は餅屋」な側面もあることは確かですので、適宜外部の知見やパッケージを頼ることは検討します。

しかし、ただ「パッケージを繋げるだけ」の開発であれば、自社も他社も「出来ること」は同じになってしまう。 それでは開発会社としての魅力は出せないなぁ…ということで、あえてフルスクラッチにこだわり、１から10まで自社で作るシステムに、技術者魂を燃やして取り組んできました。

パッケージを繋げることが得意な会社と、１から10まで自社で作ることが得意な会社の違い。 その部分を「見える化」することが、実はAltus-Five最大の課題です。 弊社ブログでも長く取り組んできましたが、なかなかエンド企業様にご理解頂くことが難しい領域です。

もし今お困りのことがあるのであれば、まずは開発のご相談を頂くことが、 いちばんわかりやすい形で弊社の強みを感じて頂ける方法かもしれません。

「他社の見積もりでは時間面・費用面から依頼が出来なかった」という方でも、ぜひ一度ご来社頂きたいと思います。

「一度会って、話を聞いてみたい」というお打ち合わせも、大歓迎です。

・お問い合わせはこちら。