不良の検出を組み込む為に必要な工程管理とは?
フォレンジック調査の工程を、少し引いて、または丸の中に立って考えて見た場合に、品質を維持するための不良チェックなどが正しく組み込まれているか?という疑問についてどう考えれば良いでしょうか。
- 作者: ジェフリー・K・ライカー,稲垣公夫,デイビッド・マイヤー
- 出版社/メーカー: 日経BP社
- 発売日: 2005/11/11
- メディア: 単行本
- 購入: 1人 クリック: 11回
- この商品を含むブログ (4件) を見る
第8章「ラインを止めて問題解決を図る文化をつくる」P222には下記文がありますので引用します
不良が発見されたときにそれをラインの後工程で手直しするのではなく、生産を止めて不良の原因である問題をその場で直すというやりかたのおかげである。
フォレンジック・ツールに限らず、ボタンを押せば自動的に一括して処理してくれる製品やツールは多数存在します。しかし、これは一種大量生産に似た考え方で、上記引用部分でいくところの、問題については後工程で手直しをする、または最初からやり直すという無駄を多く発生させるケースはないでしょうか。
例えば、ある一連の処理を自動的に行わせる方法として、工程ごとに分離して実行させるやり方と、それらの工程を一括して処理する事ができる場合、感覚としては工程を一括して処理する方が効率が良いように思えてしまいます。
しかし、もし最初の段階で工程に問題があり、不良が発生すると後工程はその不良をベースにした結果を引き出す事になります。
例えば、Indexを利用したキーワード検索を例に考えてみたいと思います。
- 検索対象ファイルからテキストを取り出す
- 取り出したテキストをインデックス処理する
というのが一般的な流れですが、この工程において1の段階でデータの取り出し方法などに問題があった場合や、テキストの抽出処理に問題があり文字化けが発生したなど不良が発生すれば、取り出したテキストのインデックス処理も影響を受けます。
上記工程をもう少し分離しています。
- 収集データからIndex対象を選択する
- Index対象ファイルの形式を調べる
- Index対象ファイルの形式に応じてテキストの取り出しを行う
- 取り出したテキストの言語を識別する
- 言語に合わせてインデックスを作成する
先ほどより少し上流工程の収集データの扱いも含めてみました。
デジタルデータの保全段階において、例えばデータが暗号化されていたり、そもそもIndexすべき対象からデータが漏れてしまうという可能性が上流工程には存在します。それらの不良が存在した場合に、上記1~5までを処理した後で、どの様に確認すれば不良を発見できるでしょうか?
また、それぞれの工程でも不良が発生する可能性が十分にあります、例えば2の部分ですが、Index対象ファイルがWordなのかPDFなのかにより、テキストの取り出し方法は異なってくるはずです。テキストの取り出し対象ファイルがどの様な形式なのかの識別を間違えた場合、誤った取り出し方をしてしまいます。(結果的に取り出しされたテキストが正しくない状況になる)
一般的にはこの手の処理は拡張子で判断するのではなく、ファイルの内容を確認した上でファイルタイプを識別する方法を取っているはずですが、この識別部分が完璧ではないはずです。
実際には誤検出した事をIndexの処理エンジンは検知しません、誤検出したと分かるくらいならそもそも問題を回避できるのではないでしょうか。ファイルの識別を誤検出したと報告してくれるシステムを見たことがあるでしょうか?
ファイル識別が正しく行われたとしても、3の段階で文字コードの影響を受けて文字化けが発生する事があります。対象ファイル形式を正しく識別できているのに、テキスト取り出し段階で文字コードをミスする事があるのか?と素朴な疑問を持つかもしれませんが、実際には発生します。
基本的な仕様は決まっているとしても実装が正しく行われていないケースが多く存在するように、ファイル識別が正しく行われても取り出されたテキストが正しいとは限りません。
誤ったデータは、誤った結果をもたらしますので、以降の4と5においてもそれぞれ影響を受けることはお分かりいただけると思います。
残念ながら、フォレンジック調査で利用するツールは一般的にいって、この不良を検出する仕組みが備わってないように見受けられます。道具を使うのは人間ですから、ここは人間が工夫しなければいけないという事でしょうか。
では、上記の処理においてどう流すのが良いでしょうか?工程を細かく分け、それぞれの工程で不良を発見していくのが、結果的には品質を向上し、時間的にも価値がある使い方ができると考えられます。
ただし、この不良の検出を行う仕組みがあまり存在してないと感じているのは私だけでしょうか?
Index対象のファイル形式をインデックスエンジンが正しく認識したか、そこから取り出したテキストが化けてないか、をチェックする工程をいま使っているツールで組み込むことができますか?
ボタンを押せば自動的にIndexを作成し、時々よく分からないエラーをログに出力するが、検索は可能になる、そんな状況が思い浮かびます。
インデックス段階のエラーはファイルが壊れているかなど、プログラム的に判別しやすい項目に限定されており、ファイルの形式を誤検出した、テキスト取り出しが正確でなかった、言語識別を間違えた、をログには出力しないと思います。
この段階でエラーになったであろうファイルのパーセンテージは、恐らくかなり低いので無視できる、と考える方法もあると思います。実際、どれくらい間違えている、不良があるのかを計測するのは現実問題として困難ではないでしょうか。
最悪なパターンとしては、本来事前にデータ形式の変換が必要であった重要なファイル形式があったにも関わらず、それらの前処理をしないままにIndex処理させたケースはどうでしょうか?例えば電子メールソフトは世の中に数多く存在しますが、Indexエンジンが全てに対応しているわけではないはずです。サポート外のデータをIndexエンジンに入れた場合、Indexエンジンは可能な限りそれを処理してくれるはずですが、正しい結果を出力する事はあまり期待できません。
とはいえ、ここで簡単にあきらめたのでは、知恵がない、だけで終わってしまいます。
もう一度、上流工程から流れを見直してみましょう。
Index対象を選別する、の工程を考える際に、Indexエンジンに正しいデータを入力する事を考えた仕組みを導入できないでしょうか?
面倒だから、または良く分からないからと、何でもIndexに投入するのではなく、正しい結果が得られると考えられるデータをIndex処理し、その結果に不良がないかをチェックする仕組みを構築していくのはダメなのでしょうか?。
実際には使っているツールによっては、範囲選択によるIndex処理ができない、という問題があるかもしれませんが、ツールが範囲選択できないのであれば、与えるデータをそもそも絞ったものだけにしてツールに与える方法もあると思います。
前述同書、P238から引用
1、前工程から流れてくる製品に不良がないことを確認する
2、自分自身の作業に不良がないことを確認する
3、次の工程に、知っていながら不良を流すことは絶対にしない。
最近は製品やツールが、顧客やユーザーの要望に応じて高機能化し、一見すると便利そうになっています。結果、機械に振り回され、不良の発生による無駄な時間が発生していないか、工程を見直してみる必要が出てきているのではないかと感じています。