投稿日：2009-06-17 Wed
と導入 | 環境 | トラブル | 雑談 |
以前の記事「ロータスノーツの掲示板検索エンジンの改造(No.67-2009/02/19)」で書いた「ノーツ文書に添付されているファイルに書かれている文字列が検索対象にならない」という問題を解決するため、簡易プログラムを作ってみました。
泥臭い方法ではありますが、行けることが確認できたので、報告をします。
簡易プログラムは次のような処理をしています。
（１）Notes文書にアクセスして、文書のフィールドのテキスト情報を、ファイルに書き出します。このファイルは、検索用インデックスを作るためファイルで、ここでは、”file-A"とします。
（２）同じNotes文書から、添付ファイルを抽出して、一時フォルダに保管します。抽出された添付ファイルを、ここでは、"file-B"とします。
（３）一時フォルダに入れた抽出された添付ファイル（file-B）から、文書フィルタリングソフト（注1）を使って、添付ファイル（file-B）の内容であるテキスト情報をファイルに書き出します。添付ファイル（file-B）から取り出したテキスト情報のファイルを、"file-C"とします。
（４）更に、一時フォルダに入れた抽出された添付ファイル（file-B）から、文書フィルタのソフトを使って、添付ファイル（file-B）の文書属性をファイルに書き出します。添付ファイル（file-B）の文書属性を書き出したファイルを、"file-D"とします。
（５）Notes文書そのもののテキスト情報（file-A）と、添付ファイルのテキスト情報（file-C）、添付ファイルの文書属性（file-D）の3つ情報を結合して、Notes文書と添付ファイル（file-B）の、全体の情報ファイルとして書き出します。この全体の情報ファイルは、”file-E”です。
（６）このNotes文書の全体の情報ファイル（file-E）から、検索エンジンのインデックス作成ソフトを使って、インデックスを作成します。
この手順でやれば、できることまで確認ができました。
簡易プログラムで試すに当たって、使用した文書フィルタリングソフトについて、書いておきます。
文書フィルタのソフトは、xdoc2txt.exe というソフトを使いました。
http://www31.ocn.ne.jp/~h_ishida/xdoc2txt.html
一般のビジネスでは、とりあえず、Microsoft製品とPDFからテキストデータが取り出せればことが足りると思います。また、私たちのようにメーカであれば、これら以外のファイルは、測定データなどであり、そういったファイルはファイル名、作成日など、ファイルの属性が取得できれば事実上問題はありません。
機能的に追加してほしいところは、ファイルの属性情報を書き出す機能で、対象にファイル名を入れてほしいということでしょうか。
それ以外では、テキスト抽出の処理も早いですし、今回の確認では、機能的な問題は見つかっていません。
注１：Wordや、Excel、PDFからテキストデータを取り出すソフトウェアを文書フィルタといいます。
投稿日：2009-04-22 Wed
と導入 | 環境 | トラブル | 雑談 |
今まで、ファイルの検索にnamazuを使ってきたのですが、もっと機能がほしいなぁ、という思いがあり、検索エンジンの仕組みを勉強するために、自分で簡易的にプログラムを作ってみました。
参考にした記事はこちらです。
検索エンジンを開発する連載記事です。
技術評論社 連載 検索エンジンを作る
http://gihyo.jp/dev/serial/01/make-findspot
検索エンジンの見出し語の切り出し方というのは、N-gramと形態素解析という2つの手法があるのですが、namazuは形態素解析を使っています。
形態素解析というのは、いってみれば、辞書を使って見出し語を切り出すという方法で、N-gramというのは、テキストをN文字単位の文字列片に分解するものです。
設計開発、製造に関わる用語というのは、特殊な用語が少なくなく、辞書方式の検索エンジンでは限界がありそうだとおぼろげながら感じていましたし、検索結果を返すときの重み付けも、独自の基準を追加できるとよいとも思っていました。
後者は、実際的に意味があるロジックが作り込めるのか、今のところ見通しが立たないので今後の課題としました。
今回の試作は、検索エンジンの仕組みを理解するのが目的なので、データベースやファイルは使わずに、Excelを利用しました。データとインデックスはExcelのシートに入れて、ロジックはVBAで書きました。
プログラムは、インデックスを作るプログラム（N-gram方式）と、検索結果を返すプログラムの２本です。
投稿日：2009-04-17 Fri
分析 | → | ニング | → | 設計 | → | 設計 | → | → | → | 移行 | → | → |
案件管理の業務調査をしていたときに、現場の人と話がかみ合わないことが何度もありました。
最初はなぜ話がかみ合わないのか、さっぱり見当がつかなかったのですが、案件管理は３層構造で管理するとやりやすいんですよ、という考え方を絵（下図参照）にして、それを見せながら話をすることで、話がかみ合わなくなることが、あまりなくなりました。
開発設計をやっている人は、顧客から現在受けている要求に応えることで頭がいっぱいになるらしくて、案件というと第２層目の管理の話をしてくれることが多かったように思います。
今回の顧客からの要求内容は○×で、納期は△□だから、試作はこんな段取りでやっていかないと、間に合わないなぁ、というのをマネジメントしているわけです。上の図でいうと詳細スケジュールのレベルです。
一方で、営業担当や、私のようにシステム要件を決めるためにインタビューをする側は、案件管理は、”当然”、顧客から注文を頂いて出荷するところまで見通してするものでしょう、という思い込みで話にのぞんでいる。
これでは、話がかみ合わないわけです。
これに気がつく前、業務調査のインタビューをしたときや、システムの要件を決める作業のときのことを振り返って見ると、お互いに、それぞれがどこのことの話をしているのかを確認もせずに、話をしていたことも少なくなかったです。
販促と製品開発進捗管理システム（通称：SDMS）のシステム構築の場合、業務要件を確認し、システム要件を決めるときに、何となくわかったようなつもりで、感じていた違和感を曖昧なままにして、結局、そのまま構築まで進んでしまいました。
特定の誰かが理解していないのが悪い、というものではなくて、違和感を感じながら、それを放置してきたことに問題がありましたね。
結果として、SDMSはどうなったかというと、システム上には必要な項目は網羅されているし、案件の登録・削除・変更など、必要と思われる機能はあるが、機能が中途半端で使えないというものになっています。
たとえば、総合スケジュールと、詳細スケジュールの管理では、時間スパンが違うので、ユーザ側の業務のスピード感がまったく違います。詳細スケジュールは日々起こったことをスケジュールにフィードバックをかけますが、総合スケジュールではそいうことはありません。
総合スケジュールの変更頻度を想定して作ったシステムは、詳細スケジュールの変更頻度、内容の組み直しの大きさ（ガントチャートの組み換え）には、合いません。結局、SDMSは使わずに、Excelにガントチャートを書いて、詳細スケジュールを管理する、ということが起こっています。
ポストSDMSは、３層構造を踏まえた要件となります。
参考記事
・営業案件の進捗管理〜管理体系 (No.35-2008/03/04)
投稿日：2009-02-19 Thu
ロータスノーツの掲示板のフィールドからテキスト情報をファイルに書き出して、掲示板の検索エンジンのインデックスを作り、掲示板検索システムを作ったのですが、問題がありました。これは、検索エンジンの問題ではなく、ノーツで検索するときでも、抱えていた問題なのですが、「ノーツ文書に添付されているファイルに書かれている文字列が検索対象にならない」というものです。
ノーツでは、添付ファイルは文字列として認識されていなくて、バイナリーデータとして認識されているだけなので、当たり前といえば、当たり前です。
かつて、掲示板が作られたころは、そういったことを理解して、対処がなされていました。例えばWordファイルを添付したら、そのテキスト部分をコピーして、ノーツのフィールドに貼り付けすように指導がされていました。
過去に作られたノーツ文書には、そういったものも残っていますが、今はそういうことを誰もやっていません（自分もやってませんし、身近にやっている人は見かけません）。そういった指導も業務規定に書かれているだけで、誰も指導はしていません。
なぜ、やらなくなるのでしょう？
考えられる理由が３つあります。
（１）指導がなされていない
掲示板の利用が普及してくると、いろんな人が使い出して、指導が行き届かなくなります。また指導する立場の人も自分で実行していないため、指導ができなくなります。強制力がないと次々にやらない人が出てきます。
（２）二度手間であるため
全く同じ内容の繰り返しは、誰しもやりたいとは感じません。やったとしても、無駄だった、とか面倒臭いという気持ちが出てきます。
文章の内容を改定するなり、バージョンアップして少しでも内容が違っていれば、例えば、前のバージョンがテキスト、現行のバージョンがWordというようになっていれば、違和感は感じませんが、同じバージョンのものを、テキストとWordで2つ置いておくとなると、よほどの理由がない限りは、この繰り返しは無駄なことのように感じます。
野球の素振りなんかも、自分の成長が見込めるから繰り返しするのであって、うまくならないと思えばやらないでしょう。
そこには、少しでも違いがある、という心理があるのだと思います。
（３）必然性の欠落
ある程度組織が大きいと作業分担がなされます。例えば、文書を作っている人は、「その文書」を発行する、残す、ことが役割です。
分業化によって作成・発行のみで、後で使うことがないという人が出現すると、その人にとっての必然性はありません。
現実的に、文書の発行後のことを意識できる人は、少ないでしょう。自分一人でやったとしても、他の人が作る文書もそうなっていないと、検索はうまくできません。自分一人がやるだけでは、効果は小さいのです。そうなると、ますますやらなくなるでしょう。
こういうのは、これを読んでくれている方にも、思い当たることはあると思います。
そして、今では、ろくな検索もできない掲示板になっています。
でも、これを何とかするのが、技術を持つソフト屋の仕事ですよね。
ノーツ6からは、ロータススクリプトで添付ファイルを外部から取り出すことが可能になりました。
ノーツは内部的には添付ファイルを分割して複数のフィールドに入れていて、それを取り出すことが難しかったのですが、COMを使うことで、PHPでもできるようになりました。
また、namazuにはWord・Excel・PowerPoint・PDFのフィルタ機能を持っていて、これらで作られたファイルを読んで、テキストファイルを出力することができます。
何か、やりようはあるみたいです。
ということで、ノーツ文書から添付ファイルを抜き出して、検索エンジン用インデックスに突っ込むプログラムを作ることにします。
投稿日：2009-02-14 Sat
と導入 | 環境 | トラブル | 雑談 |
先日、サーバパソコンのディスプレイを見てみたら、画面がロックされていて、それを解除したら「メモりが不足しています」というメッセージボックスが出ていました。
ログを調べてみると、タイムスタンプをノーツ文書のタイムスタンプに合わせる処理ができていないようです。
このときは、気が付いた時点で、コケていたこの処理を流し直して、当座の措置をしました。
翌日以降の処理は失敗せずに実行されました。
処理が失敗する条件を特定するために、いろんな条件でやってみたのですが、画面がロックされた状態で、処理を実行するとこの現象が起きることがわかりました。
（現象がよくわかるように、ここに画面がロックしたところを入れたかったんですが・・・）
さて、プログラムについて説明します。
タイムスタンプを合わせるプログラムは、Excel VBAを利用して作られています。
Excelが起動したときに、この処理が実行されるように、autoexecをトリガーにExcel VBAを仕込んであります。これを毎朝、Windowsのスケジューラで起動する仕組みです。
ところが、Excelはメモリ食いのようで、人がExcelを操作できるようなログインされた画面の状態でなければ、「メモリが不足しています」とエラーを出して止まってしまうのです。ウィンドウを出してWindowsの表で動くプログラムはこの現象が起きるみたいです。
これが起きた原因として、考えられることですが、WindowsXPの場合、別のパソコンからリモートログインをすることができますが、これをするとパソコンはログイン画面がロックされた状態になります。
先日、保守作業のためにサーバパソコンにリモートログインしたのですが、このときにサーバパソコンの画面がロックされた状態になっていました。恐らく、ここです。
プログラムに関しては、プログラムのメンテナンスができる人を増やすために、出来る限り容易で多くの人が知っている言語、つまり、VBAやWSHを使うのを方針としてきました。
しかし、こういう現象があると、すべてに適用するのは無理がありそうです。
タイムスタンプを合わせるプログラムは、Windows APIを使うのですが、WSHではWindows APIを利用できないので、そのためやむなくExcelを使うことにした、という経緯があるのですが、このプログラムはCUIで動くものに替える必要があるようです。
△ PAGE UP