なんでもパターンにできないか？

もう２０年ぐらい前になるでしょうか・・・

当時、ＡＩ（人口知能）といことがはやし立てられました。今は、あまり聞きませんが、その考え方や手法というのは今でも参考になると思います。

当時は、専門家の知識をルールベース化し、それをルールエンジンを使用して推論を行い、人間の判断を支援しようという考え方だったと記憶しています。

私自身もＡＩプロジェクトに多少参画させていただいたのですが、そのときの経験は今でもいろんなところで役立っていると思います。

専門家の知識をルール化するという考え方は、今も（当時も）不可能であると思われています。
確かに全ての人間の知能・判断を機械化するということは今のところ不可能だと思いますが、その中のエッセンスをルール化するというのは必ずしも不可能ではないと思います。

実際、部分的にではありますが、ＡＩシステムが実用化されたという事例もあります。

前置きはこのくらいにして、私はこの「専門家の知識をルール化する」という考え方は、システム開発にも適用できると考えています。

つまりは、ある特定の状況（条件）を満たせば、ある特定の解（解決方法）が、そこには存在するはずである。と思うわけです。

今、流行の言葉でいう「パターン」というのが、それに該当するのではないでしょうか。

それで、当時のＡＩシステムの開発（ルールベースの開発）ですが、いろんな方法がありました。
その中のひとつの方法として、ある状況を設定して専門化にインタビューを行い、その結果を統計的に評価して、ある特定の解決方法とするということを行ったことがあいます。

もちろん、その解決策が完全に正しいということは誰にもいえませんが、本来であれば、さまざまなプロセスを実行してある解決策に到達するところを、ある一定以上のレベルの専門家は、かなりの確率で正しい答えをいきなり出してくる。

その解決策を導き出すアルゴリズムをシステムで実装するのではなく、どのような条件の時に、どのような解決策なのかということをルール化するわけです。
当然、ルールの数は膨大な数になりますが、膨大な情報を処理するのはコンピュータの得意とするところですから、コンピュータを使えば、専門的な意思決定をサポートすることが可能となるわけです。

問題となるのは、この専門家の知識をいかに収集するかですが、実際、われわれＳＥは、日々の作業の中でさまざまな暗黙知を使用して作業を行っているはずです、それをルール化しておけばいいわけです。

システム開発において、「できる人」よそうでない人の生産性は、数倍～数１０倍になることは珍しくありません。これは個人個人の能力の差もありますが、上記の利用できるパターンの差ではないかと思っています。

私自身は、データ分析やデータベース設計という作業が多いのですが、エンティティの抽出にもパターンがありますし、リレーションの定義や属性の定義についてもパターンがあります。

例えば、「データモデルの作成」を行う場合の作業プロセスとしては

①エンティティの定義
②リレーションの定義
③属性の定義

という作業プロセスがあって、それぞれのプロセスごとにさらに詳細なアクティビティが存在し、その中で繰り返し適用しているパターンというものがあるはずで、そのパターンを整理していけばいいわけです。

例えば、エンティティの定義という場合は、まず、エンティティになりそうなものを抽出するするわけですが、そのパターンとしては

（トップダウン分析）
１．ビジネスルールから名詞を抽出する
２．入力画面から登録されるデータを識別する
３．照会画面、出力帳票に必要なデータを識別する
４．業務フロー上で登場するデータを識別する
（ボトムアップ分析）
５．画面、帳票を正規化する
６．ファイルレイアウトを正規化する
７．バッチ処理に必要なデータを識別する
（リバースエンジニアリング）
８．物理ＤＢをリバースし、テーブルをエンティティとみなす

といった方法が思いつきます。

では、リレーションの定義についてはどうか・・・、属性の定義についてはどうか・・・と考えていけば、そこにはいろんなパターン暗黙知が存在するはずです。

データ分析だけではなく、業務分析にも当然パターンがあるはずです。それらをパターンとして識別し、いかに再利用していくかによって生産性に大きく差がでると思います。

在庫の棚卸ではないですが、自分が使っているパターン・暗黙知を一度棚卸してはどうでしょうか？

そして、それをシステム化するにはどうすればいいか？と考えてもらいたいのです。
システム化するためには、条件と結果を明確に定義しなければなりません。それができれば、それは立派なパターンといえるのではないかと思います。