Redmineの添付ファイルを全文検索するパッチの可能性～Redmineをナレッジシステムにするための要件とは何か？

最近投稿されたRedmineの添付ファイルを全文検索するパッチが興味深いのでメモ。
ラフなメモ書き。

【参考】
Feature #306: Full Text Search of files? - Redmine

MAEDA, Goさんのツイート: "Redmineの添付ファイルの内容を全文検索できるようにするパッチが今朝投稿された。全文検索エンジンは使わずSQLで実現。 Feature #306: Full Text Search of files? https://t.co/eZHH3QRq5W"

akipiiさんのツイート: "このパッチが実現されれば添付ファイルもチケットと同じく全文検索できる。RT @g_maeda: Redmineの添付ファイルの内容を全文検索。全文検索エンジン無しでSQLで実現。 Full Text Search of files? https://t.co/gajeIjh0t6"

akipiiさんのツイート: "しかしDB容量肥大化や検索性能劣化の課題が気になる。@g_maeda: Redmineの添付ファイルの内容を全文検索できるようにするパッチ。全文検索エンジンは使わずSQLで実現。Full Text Search of files? https://t.co/gajeIjh0t6"

【1】(Google翻訳による引用開始)
私はPlanioのためにこれを最近調べており、この機能のコードを提供したいと考えています。
私たちのパッチは、添付ファイルが作成された後、できるだけ添付ファイルのプレーンテキスト表現で満たされている添付ファイルテーブルに全文列を追加します。
XMLベースのオフィス文書（LibreOffice / OpenOffice / MS Office）（RubyZIP / Nokogiri経由）古いバイナリMSオフィス形式（外部catdoc、catppt、xls2csvコマンドを使用）PDF（pdf2textを使用） RTF（外部unrtfコマンドを使用）プレーンテキスト、CSV他のフォーマットを追加することができます。
つまり、imagemagickを使用してイメージメタデータを抽出することができます。
外部コマンドは適切なデフォルトを持ち、configuration.ymlで設定することができます。
すべての機能が同じ場所でオフになっている可能性があります。
添付ファイルの検索が有効なときに検索された列の一覧に全文が追加されます。
また、デフォルトで添付ファイルの検索を有効にすることを選択し、添付ファイルの内容が検索されるという事実を反映するようにオプションの表現を少し変更しました。
Redmineのほとんどのインストールではないにしても、より複雑な外部インデックス作成ソリューションと比較して、これは「十分に良い」ソリューションだと思います。
ほとんどの添付ファイルのアップロードがJavascriptを介して非同期的に行われることを考慮すると、テキスト抽出のための処理時間の増加は、ユーザーにほとんど気付かれないはずです。
さらに、その作業をActiveJobワーカーに任せることで、管理者はテキスト抽出をインラインで実行するか、DelayedJobやその他の遅延処理バックエンドをセットアップするかどうかを判断できます。
あなたの考えを教えてください！
(引用終了)

(Google翻訳による引用開始)
この機能はPlanioの優先順位リストで高い評価を受けていましたので、Redmineユーザーにも人気があると思います。
次のメジャーリリースでこの機能を提案したいと思います。
ところで、テキスト抽出に必要なバイナリの多くはWindowsでも利用できます。
したがって、この機能は主にクロスプラットフォームでなければなりません：pdftotext：http://www.foolabs.com/xpdf/download.html unrtf：http://gnuwin32.sourceforge.net/packages/unrtf.htm catdoc / catppt / xls2csv （docx、ppt、xls）、新しいXMLベースのフォーマット（docx、pptx、xlsx）はrubyzipとnokogiriを使ってサポートされています。
外部のバイナリが必要です。
(引用終了)

【2】Redmineの添付ファイルを全文検索するパッチは、Planioから提供されている。
このパッチがRedmine本体に取り込まれると、テキストだけでなく、Officeファイル(docx、ppt、xls)やPDFファイル、それらを固めたZipファイルも、テキストベースに一旦変換された後、SQLでLike検索されて、検索結果を表示するようだ。
また、Unixだけでなく、Windows上でも利用できるのも良い。

このパッチのメリットは、Redmineに蓄積されたチケットやWikiだけでなく、添付ファイルも検索対象に含まれるようになるので、Redmineがナレッジを蓄積する情報システムに完全に一体化できることだ。

つまり、共有ファイルサーバーに設計書を配置するのではなく、Redmineの文書やファイル(Redmineのタブ)やチケットの添付ファイルにアップしておけば、Redmineに過去の全ての情報が蓄積されているので、必要な時にいくらでも検索できるようになる。

Redmineがナレッジシステムになるために、とても可能性のあるパッチだと思う。
Redmineに全ての情報を集約するキッカケにもなるし、その動機づけを強化してくれるだろう。

また、Planioで既に利用されているので、ある程度枯れた機能であると推測できる点もメリットになる。
初歩的なバグは既に解決済みだろうし、ユーザが使えるレベル程度までの性能要件もクリアしているだろう、と推測できるからだ。
つまり、このパッチは機能要件も性能要件も信頼できるだろうと推測できる。

【3】Redmineをナレッジシステムとして使えないか、というアイデアに関しては、過去に色々考えていた。
その場合、蓄積された情報をいつでも即座に検索できるという要件が必要になってくる。

redmineでナレッジを蓄積していく方法: プログラマの思索

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

Redmineの全文検索を高速化するプラグインfull_text_searchのリンク: プログラマの思索

Redmineをナレッジシステムとして扱うようにするには、幾つかの課題があると思う。

一つ目は、チケットやWikiだけでなく、添付ファイルや設計書などのOfficeファイルも検索対象に含めること。
二つ目は、全文検索のレスポンスが速いこと。
三つ目は、検索の結果がGoogleのPageRankのように、有用な内容が検索結果の上位に表示されるようにソートされること。

【3-1】一つ目の要件に対し、過去のRedmineユーザはいろんな提案を出している。

たとえば、DMSFプラグインはその一つの解決手段だ。
DMSFプラグインは、Redmineの文書機能を拡張して、文書機能にOfficeファイルを添付すれば、申請・承認ワークフローを通したり、検索対象に含めるようにできる。
JAXAの資料では、JAXAで利用中のRedmineにも導入されている。

DMSF - Plugins - Redmine

“CODA” チケット管理システム | JSS2@JAXA

Redmineの文書ファイルを全文検索するプラグインのリンク: プログラマの思索

他には、Subversionに設計書などのOfficeファイルを履歴管理して、ApacheSolrやElasticSearchのような全文検索ツールを使って検索インデックスを生成する方法などもある。
一般に、ファイルサーバーの全文検索を実現する機能とみなせば、いくらでも実現手段があるので、ノウハウも多い。

SVNでOfficeファイルを管理するメリットは、Officeファイルの更新履歴が明示的に残ること、SVNのような構成管理ツールのおかげで版管理が容易になる点があるだろう。
また、チケットNoとSVNにあるOfficeファイルの修正履歴を紐付ければ、成果物のトレーサビリティもRedmineの標準機能で実現できるメリットもある。

【3-2】二つ目の要件は、検索の性能要件に相当する。
Redmineの右上にある検索ボックスで、全てのPJを全文検索すると遅い場合がある、という症状は昔から知られていた。
現在は、特定のPJに絞り込み検索するようにデフォルト設定して、その症状を和らげる方策でカバーしている。

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

しかし、本来は、ユーザが好きなスコープで、好きな検索条件で検索できるようにしたい。
また、ユーザがイライラしない程度で検索結果が応答するように、性能要件をチューニングしたい。

この点に関しては、@akahane92さんのRedmineの性能チューニングが全て。
RubyやMySQLやApacheなどのミドルウェア、SSD導入や仮想環境でのCPUコア数の追加などのインフラをチューニングすることで、Redmineを高速化することは十分に可能。

第8回東京Redmine勉強会の感想 #redmineT: プログラマの思索

第14回RxTStudy勉強会「Redmineの未来を考える - 機能・運用・コミュニティ」の感想 #RxTStudy: プログラマの思索

【3-3】三つ目の要件は、検索結果からノイズが排除されて、有用な結果が表示されるようにしたい要件だ。
普通にLike検索すると、単純に検索条件の単語と一致した内容が大量に表示されてしまい、本来の欲しい情報が埋もれてしまう場合が多いだろう。
たとえば、URLやファイルパスなどが引っ掛かってもあまり意味がない。
チケットの障害内容、過去の仕様変更の内容が検索結果の上位に表示されてほしいのだ。

【3-4】二つ目と三つ目の要件に対しては、クリアコードさんのRedmine全文検索プラグインがその解決手段になるだろう。

第12回東京Redmine勉強会の感想 #redmineT: プログラマの思索

Redmineの全文検索を高速化するプラグインfull_text_searchのリンク: プログラマの思索

redmine.tokyo第12回勉強会：GroongaでRedmineを高速全文検索 #redmineT - ククログ(2017-05-15)

全文検索プラグインのメリットはいくつかある。
一つは、検索機能が非常に高速である点。
Redmineの全文検索が遅い、という弱点は、このプラグインで完全に解決できるだろう。

もう一つは、GoogleのPageRankみたいに、有用な内容を検索結果の上位に表示したり、更新時刻順にソート順を制御できる機能がある点。
「重要なものを見つけやすくする」という要望を強力に実現してくれる点は非常にありがたい。

【4】上記のような課題を考えながら、Planioが提案したパッチを評価してみると、幾つかの課題もあると思う。

一つは、数百万のチケットのような大規模環境で、性能要件はクリアできるか？
もう一つは、検索結果が有用な内容になるようにソートしてくれるか？

この課題は、上記に挙げた課題と同じであり、おそらく、クリアコードさんの全文検索プラグインとを組合せて利用することで、完全に解決できるのではないか、と思う。
つまり、Redmineの添付ファイルや文書・ファイル機能にアップロードされたOfficeファイルは、Planioのパッチとクリアコードさんの全文検索プラグインによって、好きな時に、好きな単語で、即座に有用な検索結果を表示してくれるようになるはず。

すなわち、Redmine本体の機能改善と全文検索プラグイン追加によって、Redmineをナレッジシステムとして実現することは技術的に可能だと思う。

【5】では、なぜ、それほどまでに、Redmineをナレッジシステムにしたいのか？
Redmineにナレッジを蓄積していく情報システムになった場合、Redmineの利用範囲が格段に広がるだろうと思うからだ。

過去の障害や仕様変更の経緯、ソース修正の理由を追跡したい、検索したい、という要件は当然ある。
特に、長年のシステム保守では、障害修正や機能改善の作業内容を一つのRedmineに集約していくことにはメリットはある。

でも、それだけではなく、ISO9001やITIL、ISMSなどのシステム監査の作業軽減に、ナレッジシステムとなったRedmineを使いたいという要望も多いと思う。

たとえば、システム監査で必要な書類の提出を求められた時、Redmineの高速かつ有用な内容を表示する全文検索機能を用いて、即座に必要なチケットとOfficeファイルを検索して、回答内容をリストアップする。
あるいは、組込製品の開発プロセスで必要な成果物が全て網羅できているか、という観点で調査したい時、あらかじめ必要な成果物の資料名やその内容をリストアップしておき、その内容を検索条件として、Redmineの高速かつ有用な内容を表示する全文検索機能を用いて、全ての成果物を洗い出す。

つまり、IT業界のソフトウェア開発におけるナレッジシステムだけでなく、製造業の製品開発におけるナレッジシステムにもRedmineを適用できるはずだ。

特に、日本では最近、製造業でRedmineの利用が広がりつつある。
だからこそ、Redmineを単純な帳票ワークフローシステム、サポートデスクとして利用するだけでなく、ナレッジシステムという本来欲しかった機能として実現できてもいいはずだ。
つまり、Redmineが持つ柔軟なワークフロー管理や成果物のトレーサビリティ、チケットやWikiに記録などの機能を使いながら、作業履歴を蓄積していけば、Redmineに自然にナレッジが蓄積されていく、という仕組みになればいい。

日本の製造業の現場を見ると、さほどIT化されているわけではなく、大量の帳票という紙媒体と、大量のOfficeファイルに埋もれている場合が多いように思う。
そして、ISOやISMSなどの監査作業に、大量の間接作業要員と管理工数が費やされて、IT化によって逆に無駄な作業が増えているのではないか。

そんな現場にRedmineを導入し、上手く運用することで、製造業が本来やるべき製品設計や製品開発に注力するように支援できるはずだ、と思う。

Redmineには色んな可能性が秘められていると思うので、その辺りのアイデアも考えてみたい。

【追記】
先日のRedmine大阪の講演では、@akahane92さんもPlanioのパッチにすごく期待されている。
理由は、チケット入力や添付ファイルの運用は現状通りのまま、全文検索プラグインと組み合わせることで、一元管理されたRedmineがナレッジシステムにそのまま移行できるから。

強力な全文検索機能がRedmine標準機能になったら、Redmineのチケット枚数やWikiが蓄積されるほど、有用な情報システムになるだろうし、重要なプロセス資産になるだろう。

Redmineチューニングの実際と限界 - Redmine performance tuning

(引用開始)
RedmineのFTS (非索引型)
（Redmineは悪くないが）10万チケットを超えた時点で検索が遅くなる。
例 えばCPU４コアで稼働している時に、全プロジェクト横断の検索が４回ク リックされ、並行で実行されるとCPUが占有されてRedmineが無応答になっ てしまう。
→ 今回、 Full Text Search Plugin による対処策が得られた。
十分な性能を確認できたことから、検索に関する懸念要素が払拭さ れた。
数十億文字を記録・蓄積している（ので、）何らかの索引型FTSをRedmine コアに標準機能として組み込んで欲しい。
検索できなくて困っているのは添付ファイル。
先頃、良策がPlanioさ んから提供された。とても期待している。 ( Feature #306 Full Text Search of files )
(引用終了)

【追記2】

前田さんに聞いた所、添付ファイルの全文検索パッチを取り入れるとRedmine本体の品質や性能が悪化する可能性が高いので、取り入れられないでしょう、と聞いた。

しかし、上記の全文検索プラグインによって、Redmineに蓄積されたチケット・Wiki・添付ファイルを高速かつ有用に検索できるので、「Redmineをナレッジシステムにする」課題はほぼ完全に解決できるだろう。

redmine_full_text_search/NEWS.md at master ・ clear-code/redmine_full_text_search ・ GitHub

第19回Redmine大阪の感想 #redmineosaka: プログラマの思索