ＩＴ　そして人間、社会

情報分析に関し、具体的な方法に入っていきたい。ここでは主に統計的な情報分析について見てみたい。

■目的をもって仮説を立てる

前のエントリー「情報の二面性、事実と解釈」で、情報を分析するに際して、前提となっている文脈を意識することが重要であることを書いた。ここがまず出発点である。目的は何なのか。つまり、何をするために、どのような意思決定をしなければならず、そのためにどのような情報が必要なのか、そうした目的―手段連鎖を明確に捉えておく必要がある。

たとえば、新商品販売において、販売数量が目標を大きく下回っているとする。回復のためにはまずはその原因がわからなければならない。かくて原因を明らかにする情報が必要となる、というわけである。

で、はじめにすべきことは仮説を立てることである。仮説なしでは情報を抽出することもできない。過去の知識や経験の蓄積などからある種直感的に導き出される仮説は、単に恣意的な思いつきというわけではない。いまだ論理的（根拠付けられている状態）ではないが、いわば暗黙知に支えられている限りにおいて、一定の方向性を示していると見なすべきである。ただ、その論理性が顕在化されていないのであり、だから情報分析で検証することが必要なのである。

たとえば上の例で言えば、「販売数が伸びない原因は商品自体にあるのではなく、顧客ニーズの取り違えにある。都市部の２０代をターゲットに大都市圏を重点に展開したが、実は地方にこそニーズがあるのではないか」。そういう仮説を立てたとする。

それを検証するために必要な情報は何か。それを考える。顧客関係のテーブルに蓄積されたデータのうち、何を使えば検証できるのか。顧客の住所と年齢および購買品目だ、としよう。そこでそれらの項目を抽出する。（たぶん、ＢＩツールで直接データを取り出すか、情報システム部に言って、データを出してもらうか、といったところだろう）。

■個体と集団の区別、クラス値と特性値の区別

そこで情報分析ということになるのだが、はじめに次のことを区別しなければならない。それは個体と集団の区別である。個体を分析するとは、たとえば一人の顧客を取り上げて、その人のさまざまな側面を明らかにすることである。それに対し、集団を分析するとは、顧客全体の集団としてのさまざまな特性を明らかにすることである。後者は通常、統計分析と呼ばれる。

たとえば、競合分析をする場合、特定の競合企業を分析するのが個体分析、競合全体（競争環境全体）の特性を分析するのが集団分析である。前者であれば、一つひとつの情報の収集や整理や考察がポイントとなる。後者であれば、統計手法を使って集団としての特性を浮き彫りにすることがポイントとなる。ここでは、個体分析はおいておいて、集団分析、つまり統計分析を取り上げたい。

とは言っても、わたしは統計の専門家ではないので、基本的な考え方だけ見ておきたい。以前のエントリー「情報分析とは何か？　まずデータとは？」で見たように、データ設計においてデータは、エンティティ（実体）を特定するためのプライマリキーと、そのエンティティに属する属性（アトリビュート）に分けられるのであった。たとえば、「顧客コード：0001」がプライマリキー（これで特定の顧客が名指しされる）で、その顧客の住所、年齢、購買品目等が属性である。

次に、この属性がさらに、クラス（階級）値と特性値に分けられる。中学生のときに数学で度数分布表というのを習ったことがあると思うが、そのときよく出てきた例に身長別の人数分布というのがあった。150ｃｍから155ｃｍまでは何人、155ｃｍから160ｃｍまでは何人・・・、というやつである。この場合、身長がクラス値で人数が特性値である。

何がクラス値で何が特性値かはあらかじめ決められているわけではない。分析の目的によって、そのつどクラス値になったり、特性値になったりする。先の例で言えば、新商品の購買数が問題で、それを住所や年齢といった属性ごとに見たいのであった。であれば、住所と年齢がクラス値となり、購買品目（購買数）が特性値となる。一般に、ある集合単位で特定の数値を見たいというとき、集合単位がクラス値となり、特定の数値が特性値となる。いまの場合、住所や年齢単位に購買数を見たいのである。住所や年齢がクラス値になり、購買数が特性値になるのはそのためである。

■いかにして原因を明らかにするか

というわけで、これによってとりあえず住所・年齢別の購買数という統計数値が得られることになる。が、こうした分析が単発で終わることはあまりない。さらにいろいろな角度から分析を繰り返すのがふつうであろう。なぜか？　意思決定と行動に結びつくような分析が必要とされるからである。

確かにこうした分析は「事実」を明らかにする。しかし、「事実」は通常、原因―結果連鎖という構造を持っている。販売数が目標を大きく下回っている場合、原因は何か？　ということになるが、それはつまり、何らかの原因があって、その結果として販売数が伸びないからである。それゆえ、この原因と結果の総体が、「事実」ということになる。結果だけ捉えて、原因が捉えられていないような「事実」は不完全である。原因と結果の連鎖全体が捉えられて初めて「事実」なのである。

分析が繰り返される理由は、まさにここにある。結果は比較的容易に明らかになるが、なかなかわからないのは原因である。そして、原因がわからなければ手の打ちようがなく、意思決定も行動もできない。というわけで、原因の究明を目指してさまざまに分析が繰り返されることになるのである。

では、原因はいかにして究明していけばいいのか？　ごく簡単に触れておこう。クラス値と特性値とで方法が異なる。まず、クラス値については、クラス値のくくり（セグメント）を細分化していくことによって原因を明らかにしようとする。そのためにわたしがよく使う方法は３つある。ひとつは、単純に特定のクラス値を細分化することである。都道府県単位をいくつかのブロックに分け、さらに市部と郡部で分けていくことによって、他とは違う傾向を示す地域（そこに何か要因となるものがある）を見つける、といった方法である。これは、一般にはドリルダウンと言う。

二つ目は、いわゆるクロス集計である。たとえば、地域と年齢を縦軸と横軸にとり、地域、年齢、それぞれだけではわからない特性を組み合わせによって洗い出すのである。三つ目は、いわゆるダイス＆スライス（多次元分析）である。これはクロス集計の拡張版と言っていい。クロス集計は２つの属性で行なうが、ダイス＆スライスはさらに属性を付け加え、組み合わせをさまざまに変える。たとえば、地域と年齢に年収という属性を加えたとしよう。すると、地域と年齢だけでなく、地域と年収、年齢と年収という組み合わせでもクロス集計を試みることができる。こうして組み合わせを変えていくことによって、よりいっそう背景を浮かび上がらせることができるのである。

次に、特性値について。ひとつは、もともと因果関係が明らかであるような特性値を取り上げるという方法がある。たとえば、住宅を購入する人は家具も購入する可能性が高い。住宅を買ったから家具も新しくするというわけだ。とすれば、家具の販売予測をするために、住宅の販売推移を見るといったことが可能になる。２つ目は、必ずしも因果関係が明らかでない場合である。この場合には、仮説を立て、相関分析をすることになる。たとえば、商品Ａは年齢層が高いほどリピート率が高くなるという仮説を立てた場合、縦軸に年齢、横軸にリピート数をとって、対象顧客すべてをプロットすることにより、相関を見る。（この場合、年齢もリピート数も特性値と見なす）。相関係数が一定以上であれば、相関があることになる。つまり、両者には因果関係がある。そこで、上の年齢層をターゲットに商品Ａの販売戦略を練り直すといったアクションに繋がるのである。

とりあえず、これぐらいにしておこう。以上で主に集団としての分析（つまり統計分析）を見てきた。しかし、これとは別に個体としての分析もある。また、もうひとつ重要な区別がある。ここまで属性（クラス値と特性）を中心に見てきたが、それに対し、遇有性を中心とした分析もあるのである。あわせて言えば、個体にかかわる遇有性の分析、それがさらに重要な領域と言える。それについては、また別のエントリーで取り上げたい。

情報分析についてもう一歩踏み込んで見ていこう。情報の元はデータであり、データは、少なくともビジネスの文脈では、データ設計として定義されるのであった。そして、定義されたデータの全体は「事実」としての機能を果たすのであった。（「情報分析とは何か？　まずデータとは？」）。

■特定の文脈に基づき抽出されたデータ、それが情報

さて、ここでようやく情報について語ることができる。データ設計はテーブル設計とも言うが、論理設計の後、物理設計となって、最終的にはデータベースとなる。要するに、データはデータベースの中に蓄積されるのだ。顧客データも売上データも、それぞれ顧客テーブルと売上テーブルに格納され、データベースのかなに貯まるのである。しかし、貯めただけではどうしようもない。取り出さなければ使いものにならない。かくて、蓄積されたデータを取り出すことになるのだが、それがすなわち情報なのである。

では、なぜそれを情報と呼ぶのか？　たとえば、顧客テーブルから顧客氏名と年齢と最新商品の購買履歴を取り出すとする。（実際には購買履歴は「顧客購買テーブル」といった別テーブルに格納されているだろうか、そうした細かいことは今は省略する）。具体的にはＳＱＬでｓｅｌｅｃｔ文を実行して、抽出することになる。その場合、前提として抽出の目的があるはずだ。たとえば、マーケティング部が新商品で想定したターゲット顧客の年齢が妥当であったかを検証して、次の商品のマーケティング精度を上げるため、などである。

で、情報の定義を思い起こそう。データが一定の文脈の中で意味づけらるとき、それを情報と呼んだのであった。いまの例では、「マーケティング精度の向上」が文脈である。その文脈の中で意味あるものとして、特に顧客氏名と年齢と最新商品の購買履歴が取り出されたのである。この点でまさに抽出されたデータは情報なのである。

データベースには多数の種類と膨大な数のデータが蓄積されることになる。それを全件取り出したところで何の意味もない。特定の文脈にとって意味があるように特定のデータを取り出してくる、そこに価値がある。

たとえば、次の商品開発のために今回の新商品の購買顧客の年齢別構成比を出すとする。実はこの新商品は２０代後半から３０代をターゲットに開発した。にもかかわらず、４０代、５０代の構成比が高いとすると、この世代のニーズを再調査する必要がある。次の商品をヒットさせるためである。

こうした文脈があればこそ、膨大なデータの中から特定のものを抽出して、「今回の新商品は４０代、５０代に買われている」という「事実」を浮かび上がらせることができる。次の商品をヒットさせるという一連の文脈がなければ、この「事実」を浮かび上がらせることはできない。どのデータを抽出していいかわからないからである。

■情報の二面性。「事実」と解釈

このことから、情報の性格について見えてくることがある。それは、情報のもつ二面性である。

まず、情報がデータに基づき、データが「事実」としての機能を持っていた以上、情報も「事実」としての機能を持っていると言える。それは幻想でも、虚構でも、主観的な思い込みでもない。データとして蓄積された顧客の年齢と購買履歴が「事実」である以上、そこから正当な手続きで導き出された「今回の新商品は４０代、５０代に買われている」という結論はやはり「事実」という以外ない。

が、他方で、この「事実」はむしろ解釈だ、とも言えるのである。なぜなら、それは特定の文脈において始めて意味を持つからである。そもそも蓄積されたデータ自体がビジネス等の特定の文脈のフィルターを通っていた。顧客と言っても無数の属性がありうる中で、特定の視点のもとに有限個の属性を収集・蓄積しているはずだからである。情報はさらにその中から特定の文脈の視点によって限られた数の属性を抽出するのである。抽出する情報によって、顧客のさまざまな側面が浮かび上がるであろう。文脈の視点によって、顧客の姿はさまざまに変貌する。そこには常に「特定の文脈から見た」という意味での解釈が入る。情報はそれ自体一つの解釈なのである。

家族単位の消費を見る視点からは、顧客の家族構成が浮かび上がるであろう。余暇のライフスタイルという視点からは、顧客の趣味や嗜好品の購買状況が浮かび上がるであろう。スキルアップという視点からは、顧客のネットでの資格講座受講状況が浮かび上がるであろう。どれもすべて「事実」である。が、同時に、どれもすべて特定の視点というフィルターを通っているという意味で、解釈である。唯一絶対の事実などない。どれもその時々の文脈によって多様に姿を現す個々の「事実」に過ぎない。「事実」でありながら解釈、解釈でありながら「事実」、それが情報の特性なのである。

■情報分析における複数的「事実」の重要性

このことは情報を分析する上で重要である。なぜなら、一つの「事実」だけにこだわるとき、情報は硬直化し、かえって「事実」を捉え損ねるからである。特定の「事実」に注目しつつも、常に異なる視点から別の「事実」の可能性に留意する。それが、情報分析にとっては基本的に重要なことである。そうしてはじめて、さまざまな角度から「事実」を検討し、妥当な意思決定の背景を露わにすることができるからである。

さらに、情報を分析する文脈は常に変化する。極端な場合、時々刻々に変化することもありうる（たとえば、株価の変動とリンクしているような場合）。それだけに、一つの「事実」にこだわることは致命傷になりかねない。今の「事実」は、次の瞬間には「虚偽」でありうる。常に文脈を忖度しながら、今この状況でのもっとも適切な「事実」を浮かび上がらせなければならない。つまり、解釈が重要なのである。

「唯一絶対の事実」は虚構である。「事実」とは、あくまで情報のもつ、わたしたちの行動を方向付ける機能に過ぎない。情報を分析する上では、そのことを基本的に理解しておく必要があると思う。

さて、次のエントリーで、さらに具体的な情報分析の内実に入ろうと思う。

ここまで情報システムに端を発して情報について書いてきたが、ここでさらに踏み込んで情報分析について書いてみたい。わたしたちは仕事のさまざまな局面で情報を活用するが、その際、情報を分析する、という言い方をする。確かに、実際、情報を分析している。それには違いない。が、そもそも情報を分析するとは何をすることなのか？　

■情報の元となるデータの設計

それについて考えるために、まず情報というものの構造について一瞥しておきたい。データが一定の文脈の中で意味づけらるとき、それを情報と呼んだ（「情報は業務にとってどのような役割を果たすのか？」）。言ってみれば、データが情報の元である。そこでまずデータについて考えてみよう。

その際、話の発端としてデータ（テーブル）設計を取り上げよう。システム設計をする人間ならデータ設計は本来業務に属するが、その基本的な考え方は情報の本質を知る上で重要である。もとをただせばコッド博士のＲＤＢ理論（正確にはデータ関係モデル）が基礎であるが、ここでは難しいことは置いておいて、エンティティとアトリビュートだけに注目しよう。

エンティティとアトリビュートはそれぞれ実体と属性と訳される。言うまでもなく、アリストテレス以来の哲学用語である。たとえば、ある花があって、赤色をしているとき、その花が実体で赤という色が属性である。論理学に変換すれば実体が主語で属性が述語となるので、「この花は赤い」という命題になる。フレーゲが現代論理学を創出して以来、主語と述語という考え方は対象と概念という考え方に大きく修正されたが、いずれにせよ共通しているのは、世界は論理的構造により成り立っているという思想である。世界が論理的だから、そこから実体と属性とを明瞭に取り出すことができ、主語―述語形式で論理命題として表現できる。そして、だからこそまた、そこからデータを取り出すこともできる。情報というものの基礎はまさにここにある。

■エンティティ（実体）と属性からデータを定義する

データ設計をするとき、まず行なうのはエンティティ（実体）の定義である。この場合のエンティティとは、ビジネス上の重要要素とでも考えればいい。たとえば、顧客、商品、従業員、生産、売上、等々である。要するにそれがなければ当該ビジネスが成り立たない、最も重要な要素群のことである。

それが決まったら、次にそのエンティティを特定する（アイデンティファイする）ためのデータを決定する。たとえば、顧客コード、商品コード、従業員コードなどがそれである。通常これをプライマリキーと呼ぶ。マスタ系はこんな感じであるが、トランザクション系はこんなに簡単ではない。たとえば、「売上」の場合、売上コードなどというものはふつう使わない。売上年月と勘定科目をセットにしてプライマリキーにする、といった形になる。こうしたプライマリキーをふつう複合キーと呼ぶ。これらのプライマリキーの決定を持って、エンティティが確定する。

エンティティが確定したら、次に属性を決める。たとえば、「顧客」であれば、氏名、住所、電話番号、性別・・・、等々である。これにより、特定の顧客に対しその事実特性を一義的に認識できるようになる。たとえば、「顧客コード001（の顧客）は男である」といった具合である。（これが上の「この花は赤い」と同じ構造だということに注意してほしい）。顧客とは何なのかが細部にわたって明確に定義されるわけである。同様にして商品も従業員も売上・・・も、明確に定義される。これによってビジネスにかかわる必要領域が細部にわたって一義的にデータ認識される土台ができるのである。

が、ここで注意しなければならないことがある。上でマスタ系とトランザクション系の区別をしたが、マスタ系とは不変的な属性によって構成されるエンティティのことであり、トランザクション系とは可変的な属性によって構成されるエンティティのことである。（不変、可変はある程度相対的である）。「顧客」の場合、氏名、住所、電話番号などは相対的に不変的であるのに対し、「売上」の場合、日次や月次のタイミングで絶えず発生し、締め日まで幾度となく更新されるので、本質的に可変的である。で、注意なければならないというのは、マスタ系であっても、トランザクション的データを十分に考慮しなければならない点である。

「顧客」の場合、氏名や住所は相対的に不変的である。住所などは変更されうるが毎月変わるようなものではない。しかし、たとえば顧客の購買履歴などは高度に可変的である。それは時々刻々に追加され、変化していく。この変化を捉えることがビジネスにおいては戦略的重要課題となる。したがって、「顧客」のように一見マスタ系と見えるエンティティについても、トランザクションデータを明確に定義しておくことがビジネス上不可欠なのである。

■「事実」として機能するデータ

さて、ここまで来ればあとは正規化を行うということになるが、現在のテーマには関係ないので割愛する。いずれにせよ、こうしてビジネスに必要なデータの全体が定義されたことになる。（厳密に言えば全体ではないが、とりあえずそう言っておく）。言い換えれば、これらが情報分析の対象となる情報元のすべてなのである。これらのデータ群から文脈に応じて取り出されたものが情報であり、それが分析されるのである。その意味で、情報および情報分析にとって、以上のデータ定義（データ設計）は、根本的な土台となるのである。

データ定義だけで大分長くなったので、情報を取り出すこと、さらに分析することについては別のエントリーで続けたいと思う。その前に一点だけ確認しておきたい。データはそもそも「事実」でなくてはならない。そうでなければ、そもそも使い物にならない。しかし、上で見たように、エンティティも属性も「事実」の中から一定の選択によって決定される。あくまで当該ビジネスの文脈の中で必要と見なされたものが取り出され、整理され、定義されるのである。したがって、定義されたデータの全体は決して事実そのものではない。それはすでにビジネス上の文脈というフィルターを通っているのである。そして、わたしたちはフィルターを通してはじめてデータを手にするわけだから、フィルター以前の事実そのものに直接アクセスすることはできない。

では、事実とは何なのか？　（この事実とは上で言った「論理構造を持つ世界」に該当する）。それはある種の共同了解だと言ったほうがいい。データを定義するとき、わたしたちは確かにこれは事実だという共通の了解の下にそれを行なう。もし、「これって、本当に事実か？」ということになれば、その段階で検討がなされ、取捨選択しなおされるであろう。そのようなコミュニケーションによる共同の了解をつねにとりつつ、データ定義はなされねばならないし、事実、使い物になるデータ定義ならそのようになされているであろう。このようなコミュニケーション上の手続きを経ることによって、定義されたデータは、事実それ自体ではなくとも、少なくとも「事実」という機能を果たすことになる。重要なのは、この「事実」としての機能なのである。この機能さえ果たせれば、データは情報および情報分析の資源となりうるのである。

戦略的情報についてさらに考えてみたい。先のエントリー「業務と情報、5つの視点」で、こうした情報は主に触発的なものであると書いた。触発的情報とは新たなアイデアや創造的な発想を誘発するような非定型な情報で、コミュニケーションなどによって得られるタイプのものであり、それに対して規定的情報は業務行動を規定するための定型情報で、情報システムからアウトプットされるタイプのものであった。（「そもそも情報とは何か？その大枠の見取り図」）。

■情報における文脈の重要性

この２つの違いは、情報それ自身の内容にかかわるのではなく、その機能にかかわるのであった。つまり、まったく同じ情報が文脈によって触発的にもなり、規定的にもなる。一つの経費科目が、経理課の人間にとっては決算処理時にチェックすべき一項目に過ぎないのに対し、現場のマネージャーにとっては、経費削減策の重大なヒントになるかもしれない。同一の情報が文脈によって機能を変えるのである。

そこで、情報にとって文脈というものがいかに重要かがわかる。情報は文脈によって意味を変えるのである。規定的情報は固定的な文脈を前提とする。それが情報システムからアウトプットされたり、使用されたりする場合、業務プロセスは定義されており、使用されるべき情報自身も定義されている。つまり、文脈は固定化されており、さしあたって変化しない。

それに対し、触発的情報は文脈の変動と深くかかわる。ある経費項目を見て経費削減策を思いついたなら、当然それを実行しようとするだろう。それまで潤沢なリソースで業務を動かすことが当然とされていたところに、ムダを徹底的に削減するという新たな視点が導入され、業務前提が大幅に変わるであろう。その意味で、一つの情報が触発的に機能し、文脈を変えてしまうのである。そして文脈が変われば、規定的情報の意味も変わる。それまで見向きもされなかったような費目がにわかに注目を集めるようになったりするのである。

■文脈を形成する定性的情報

規定的情報が文脈の固定化を前提とし、触発的情報が文脈の変動を引き起こすとするなら、ここでさらにもう一つ別の視点が必要になる。それは、文脈を形成するのに資する情報とはどのようなものか、という視点である。触発的情報が文脈の変動を引き起こしたとして、では、そのあと新しい文脈を形成していくのに、情報は何らかの機能を果たすのであろうか。それとも、何の機能も果たさないのであろうか。果たすとすればそれはどのような情報なのだろうか。

そこでもう一つ情報の別の分類軸を導入しよう。それは定量的情報と定性的情報の区別である。これまでわたしは情報システムとの関連で情報について書いてきた。その限り、イメージされていたのはほとんどが定量的情報、つまり数値であったと思う。しかし、もう一つ別の情報がある。定性的情報である。一般に定性的情報とは数値にはならない情報全般を指し、文字、画像、音声等によって表される。そして、この定性的情報が、文脈形成に大きな役割を果たのある。

たとえば、経費削減しようというとき、まずはどのような方針と方法で経費削減を進めていくのか考えねばならない（目的設定とPlanning）。その場合、もちろん定量的情報も必要である。どこにコストがかかっているのかは正確な数値情報を見なければわからない。しかし、本当に効果的な経費削減策を考えようと思えば、数値だけでは到底無理である。実際に現場に行って担当者から日々の業務内容を聞き取ったり、経費削減で成果をあげている企業のやり方を調べたり、そこに赴いて話を聞いたり、従業員から意見を吸い上げたり、等々、多くの定性的情報が不可欠なのである。

そうした定性的情報を分析したり綜合したりすることによって、あるものは触発的に働いて新しいアイデアを生み、あるものは参考となってそのまま流用され、次第に新しい経費削減の方針と方法が見えてくるのである。かくて新たな業務上の文脈が形成される。そして、ひとたび文脈が形成されると、意味構造が変わり、これまで重要とみなされていなかったような情報が重要と考えられるようになったりする。つまり、その新たな文脈に応じて業務プロセスが定義されていき、それに対応して、情報が定義されていくのである。これについては、業務分析と情報との関連でこれまで書いてきたとおりである。（「業務分析の本質は情報定義」）。

■情報のほとんどは定性的情報

考えてみれば、情報のほとんどが定性的情報と言っていいくらいである。情報システム構築にかかわっていると、情報と言えば定量的情報と思いがちであるが、世の中、定性的情報の方がはるかに多い。定量的情報など、定性的情報という大海に浮かぶ島のようなものだと言える。

このことを自覚しておくことは重要である。情報システムからアウトプットされるような定量的情報はほんの一握りにすぎず、むしろ、自分で歩き回り、コミュニケーションし、アンテナを張って多くの定性的情報を把握しなければ、ビジネスや事業を進めていくことはできないからである。これは情報システムに携わる者の落とし穴と言えるであろう。

先のエントリー「業務と情報、5つの視点」でＰＤＣＡサイクルをもとに業務で必要となる情報を５つに分類した。すなわち、目的設定のための情報、Plan（手段設定）のための情報、Do（手段遂行）のための情報、Check-Action（スモールサイクル）のための情報、Check-Action（ラージサイクル）のための情報の５つである。これらの情報について、もう少し踏み込んで考えてみたい。

■戦略的情報から見た情報システムの限界

そもそも目的設定のための情報などは、つまるところ事業目的を見極めるためのものと言ってよく、きわめて戦略的である。企業全体として何を目指すべきか、それに基づき各部門は何をなすべきか、そうした戦略課題の決定にかかわる情報である。そのため、定型化された情報では到底役に立たない。言い換えれば、情報システムからアウトプットされるような情報だけではどうしようもない。触発的な情報が必要で、そのためには流動的で鮮度の高い情報を社内だけではなく市場からも鋭敏に感受することが不可欠である。

これは、Planのための情報についてもある程度言えるし、Check-Actionのための情報も、ラージサイクルについてはやはりそうである。ラージサイクルのCheck-Actionにおいては、業務プロセスそのもの、さらには目的そのものを見直さねばならないのだから、広範な情報を柔軟に収集する必要がある。

こうして考えると、実は情報システムで扱える情報など知れている、とも言えるのである。情報システムの開発に携わる者は、このことをよくわきまえる必要があるとわたしは思っている。何でもかんでも情報システム構築に結び付けようというシステム担当者がいるが、それは見当はずれである。情報という広大な領域から見れば、システムでできることなどわずかだ。最も重要な情報は、それこそ特定の人脈から入ったり、ＳＮＳのようなネットで入手したり、休憩時の会話から得たりといったことはいくらでもあるのだ。情報システムを過信すべきではない。

また、情報マネジメントがＩＴマネジメントの上位に来るのもこれが理由である。企業戦略にとって重要な情報を常にタイムリーに手に入れるためには、ＩＴがすべてではない。電話でも、ＦＡＸでも、直接会うのでも、何でもいいのである。情報マネジメントは戦略的情報を確実に流通させるための仕組みを定義しなければならないが、ＩＴはいろいろある手段のうちの一つであるに過ぎない。

■情報システムにはCheck-Actionのための情報が不可欠

というわけで、限界を自覚した上で、ここでは情報システムに固有な情報について一つだけ見ておきたいことがある。

５つの分類の中で、特に情報システムが扱うのはDo（手段遂行）のための情報とCheck-Action（スモールサイクル）のための情報である。まず、Doのための情報は当然である。顧客の購買情報から品目や金額が請求書となってアウトプットされたり、請求書の内容について顧客から問合せが入ったとき受付担当者がそれを画面で参照したり、業務遂行に必要な情報の扱いは情報システムの中心機能である。

問題はCheck-Action（スモールサイクル）のための情報である。ラージサイクルのCheck-Actionが目的やプロセスにまで遡って大きな視点で見直しを行なうのに対し、スモールサイクルのCheck-Actionは当該業務がうまくいっているかどうかのチェックが主な機能となる。そのためには、何をもってうまくいっているというのかを定義し、それを定量的に示す情報をアウトプットする必要がある。ふつうこうした情報を指標とかＫＰＩ（key performance indicator）と言う。

たとえば、販売担当者が顧客からの問合せに対し３日以内にアポイントをとらねばならないという場合、ＣＲＭシステムでは各担当者のアポイントまでの平均日数、さらには部署ごとの平均日数などがアウトプットされねばならないであろう。管理者はそれを見てチェックし、目標に達していない担当者、部署に指導を入れねばならない。

実は、このようにシステムにCheck-Actionの機能が不足なく盛り込まれているということは、必ずしも自明ではない。ＣＲＭのような高度に標準化されたシステムや、生産管理のように品質マネジメントといった背景思想が明確であるシステムは別であるが、各業務固有の要件にしたがってスクラッチで構築されるようなシステムの場合、Check-Action機能がきわめて不十分なことが多いのではないかとわたしは思っている。

その原因は、きわめて単純であるが、主管部門にも情シス部門にもベンダーにもそうした発想があまりないということがあげられる。特に担当者ベースで仕様確定が進むような場合は、マネジメントの発想がないので、ほぼ確実にCheck-Actionの機能は漏れる。よしんば気づいていたとしても、担当者としては管理されたくないので、そうした機能はあまり入れたがらない。仮に情シス部門がCheck-Actionの機能を入れるべきと主張しても、「なんでそこまでしなければならないのか」風の反応になることが多いように思う。

しかし、情報システムにCheck-Action機能は不可欠である。なぜなら、情報システムは業務に基づいており、その業務はそもそもマネジメントされていなければならないからである。マネジメントされていない業務などありえない。そしてマネジメントされるためには、うまくマネジメントされているかどうかを示す情報が不可欠なのである。

■業務分析・設計においてＫＰＩも定義されるべき

ということは、そもそも業務分析・設計において、ＫＰＩが定義されていなければならないということなのである。「業務分析の本質は情報定義」というエントリーで業務分析における情報定義の重要性について書いたが、それを補足するなら、ＫＰＩの定義もそれに含まれる。業務遂行（Do）に必要な情報だけでなく、Check-Actionに必要な情報（ＫＰＩ）も定義する、それが業務分析・設計において重要なポイントとなるのである。

ベンダーのＳＥにそこまで要求するのは酷かもしれない。しかし、情シス部門の者は、自社の業務をよく考え、何をもって業務プロセスをチェックするのか、そのとき必要となるＫＰＩは何か、そうしたことを主管部門に投げかけ、提案できることが必要なのである。

「業務分析の本質は情報定義」というエントリーで、業務分析においていかに情報を定義することが重要かを書いたが、それはそもそも、わたしたちが業務を行なうときに情報が不可欠だからである。誰も情報なしで仕事をすることなどできない。こう言うと、当たり前と思われるだろうが、実際には業務の中で情報だけに焦点をあてて意識することはほとんどなく、そのくせ思っている以上にさまざまな情報を使いながら業務をこないしているものなのである。では、わたしたちは、実際の業務においてどのように情報を使っているのか。情報システム部門にいて情報システム構築にかかわっているのであれば、業務と情報の関係について常に頭に入れておく必要があると思う。

■ＰＤＣＡサイクルから整理できる業務と情報

情報と業務の関係を整理するときに、わたしは常々ＰＤＣＡサイクルを利用する。Plan、Do、Check、Action、それぞれで必要となる情報を考えることで、業務で必要な情報をけっこう網羅的に洗い出すことができるのである。

その場合、ＰＤＣＡサイクルの理解のために、業務行動が目的・手段系列から成り立っているという基本構造を捉まえておく必要がある。たとえば、Planはそもそも目的設定がなされていることを前提としている。目的が不明なのに計画などできはしない。また、計画とはその目的を実現するための手段を設定することと言える。Doすなわち実行はその手段を目的へ向けて実際に遂行することであるし、Check-Ａｃｔｉｏｎは遂行の妥当性と同時にその手段の有効性を検証し必要に応じて修正を加えることである。

というわけで、目的・手段系列を中心に、ＰＤＣＡサイクルの視点から考えるとき、業務と情報の関係について、５つの視点から見ることができる。

■目的設定のための情報

まず、出発点は目的の設定である。業務は目的の設定から始まる。あるいは、大前提として目的が設定されているはずである。目的がなければ、Planなど立てようないし、Planがなければ、DoもCheck-Actionもありえない。ＰＤＣＡサイクルをまわすには、そもそも目的の設定が不可欠である。何の目的もないのに業務をするはずないのである。

それゆえ、第一に必要となるのは目的設定のための情報である。目的設定は一つの業務自体を創設する。たとえば、戦略上、新規に事業展開をする必要が生じたとする。これにより新たな業務が生まれる。しかし、そもそも何のために、何を目指して、どのような事業を立ち上げるかが最重要事である。適当に事業選択をするわけにはいかない。市場環境やターゲットとする顧客の特性、自社の強みや財務状況など、種々の情報に基づいてもっとも適切な事業を選択しなければならない。

これは、定型的に定義された情報を見れば自動的にわかるというものではなく、自分なりにいろいろな情報に当たってみて、気づきや新たな発想、アイデアといった創造的な触発を大切にしながら考えを形成していくべきものである。その意味で、目的設定のための情報は、触発的情報であることがほとんどである。（規定的情報と触発的情報の区別については「そもそも情報とは何か？その大枠の見取り図」参照）。

いま新規事業の例を取ったが、部門内の新たな施策立案や業務改革におけるゼロベースの見直しなどにおいても同様のことが言える。

■PlanとDoのための情報

さて、目的が設定されたら、次はPlanである。つまり、目的実現のための業務プロセスの立案である。たとえば、新規事業における商品開発業務プロセスの設計などである。これは、この新たな事業の目的を達成するための手段の設定と言ってもいい。したがって、ここで必要となるのは、手段設定のための情報である。

この場合まず、既存業務など、他の業務プロセスのノウハウやデータを活用できる。あの商品開発プロセスがこうで、これぐらいの期間で開発完了することができるから、今回の商品開発もかくかくのプロセスを踏むことで目標は達成できるだろう、等々。次にもう少し広く言えば、ベンチマーキング情報も重要になる。自社だけでなく、他社も含めてベストプラクティスを参考にしながらあるべき業務プロセスを設計していくのである。いずれにせよ、ここでも触発的情報は重要であるが、少なくとも、目的設定よりも定型的な情報が使える可能性が高い。

業務プロセスを定義していくとき、同時にやっておかねばならないのが、各業務で必要となる情報の定義である。「業務分析の本質は情報定義」で見たように、業務プロセスを基に実際の業務行動をとろうとするときに不可欠となるのが情報である。具体的状況を明らかにする情報がなければ、一般的な業務プロセス定義をいまここでの行動に変換することはできない。

それぞれの業務はどのような情報がなければ行なえないのか。また、その業務において新たに発生するデータは何なのか。そのデータはどのように処理すべきなのか。スプレッドシート処理でいいのか、システムを必要とするのか。その処理の結果、どのような情報がアウトプット可能で、それはその後のどの業務プロセスで必要となるのか、等々。そうしたことが仔細に検討された上で、各プロセスごとのインプットの情報やアウトプットの情報が定義されねばならないのである。

目的と手段が設定されたら、次は実際にそれを行なうことになるが、その際必要となるのはこうして定義された情報なのである。顧客からの問い合わせ受付業務を行なうとしよう。そのとき、個々の顧客の属性、買った商品、その時期、問合わせ履歴などの情報が即座に参照できなければならない。その情報項目は問合せ受付業務を設計するときに同時に定義されているはずのものであるが、それが顧客情報のシステムなどの画面で簡便に見られるといった仕組みが必要なのである。

■Check-Actionのための情報

こうして、目的設定のための情報、Planのための情報（手段設定のための情報）、Doのための情報（業務行動のための情報）の３つの種類の情報が必要であることがわかるのである。そこで次は、Check-Actionのための情報である。

たとえば、問合せ受付業務を例に取るならば、受付すること自体に必要な情報だけではなく、その受付業務がうまくいっているかどうかを確認するための情報も必要である。業務は、ただやっています、というだけではダメである。業務Planどおりいっているか、さらには所期の目的が達せられているか、それに常に眼を光らせなければ、何のためにやっているのかわからなくなる。そこでうまくいっているかどうかを明らかにするための情報が必要となるのである。

いわゆる、見える化である。問合せ受付業務の場合には、たとえば、問合せを受けてから顧客への回答を完了するまでの時間（リードタイム）が何分かとか、回答に対する顧客の満足度は何％かとか、そうした指標である。それが目標を達成しているか、低下していないか、定期的にチェックされ、問題が発見されたら解決行動をとるわけである。その意味では、このCheck-Actionのための情報は、問題発見、問題解決のための情報と言うこともできる。

Check-Actionのための情報には、実は二種類ある。いま見たのは、Doに対するCheckである。それに対し、さらに根本に帰って、Planまたは目的に対するCheckがある。何か問題がある場合、日々の受付業務ではなく、そもそも、受付業務プロセス自体に原因があるという場合がある。日々の業務をいくら改善しても、設計されたプロセス自体に原因があるなら、どうしようもない。そのときにはプロセスの設計自体を改める必要がある。さらには、そもそも設定した目的自体が誤っていたということもあるかもしれない。このようにPlanないし目的に対するCheck-Actionという次元があるのである。Doに対するCheck-Actionをスモールサイクル、Planないし目的に対するCheck-Actionをラージサイクルと呼んでおこう。

たとえば、受け付けてから回答までのリードタイムはそこそこなのに、顧客からのクレームが絶えないとしよう。調査してみたら、顧客は回答だけでなく踏み込んだフォローを望んでいた。ところが、受付業務プロセスの中にはフォローのために適切な部署へエスカレーションする仕組みがそもそも組み込まれていなかった。とすれば、このプロセスに基づいてどれだけ一生懸命やってもダメだということになる。業務プロセスを再設計しなければならないのである。これがラージサイクルで、ここでキーとなった情報は、クレーム件数であり、クレーム内容なのである。

さて、こうして目的、Plan、Do、Check-Action（スモールサイクル）、Check-Action（ラージサイクル）の５つのフェーズにおいて、それぞれに業務に必要とされる情報があることがわかる。ここからさらにいろいろなことが見えてくるのであるが、それについては、別にエントリーしようと思う。

システム仕様は要件に基づき、要件は業務行動に基づかねばならないと以前からのエントリーで何度も書いてきた。（たとえば、「システム開発は仕様ではなく、要件を中心に進めよう」）。ということはつまり、仕様および要件の定義は、業務行動の定義、すなわち業務分析に依拠すべきということである。システム構築の要諦は業務分析にある。このことは当たり前と言えばあまりに当たり前なのであるが、これを明確に意識しているＳＥは極めて少ないとわたしは思っている。業務分析がまともにできなければＳＥは本来勤まらない。業務分析こそがシステム構築のすべての出発点なのである。

というわけで、業務分析について少し書こうと思うが、ここでは、ユーザーヒヤリングでいかにして網羅性を担保するかとか、５Ｗ１Ｈをいかに駆使するかといった個別ノウハウの話は置いておいて、業務分析における情報定義の重要性について書きたいと思う。

■情報は業務標準を具体的行動に転化する

「情報は業務にとってどのような役割を果たすのか？」で書いたように、情報とは、業務標準（つまりマニュアル）を実際の行動に転化するときに不可欠な機能を果たす。少しだけ再説しておこう。たとえば、流通、特にコンビニなどでは、売れ筋の商品をどのように陳列し、それをどれぐらいのサイクルで変更し、それをどのような要因（たとえば天候など）で行なうかといったことがマニュアル化されているのがふつうである。おそらくフランチャイジーへの研修指導などにおいて教えられるもののひとつに、こうしたノウハウがあると思われる。

しかし、こうしたノウハウを習得したからといって、それだけでうまく商品を回転させられるわけではない。なぜなら、このノウハウを実行に移すためには、そのための具体的情報が、たとえば、実際何が売れ筋か、現実に天気はどう変わるのか、そのとき商品の優先度はどうなるのか、等々の情報が不可欠だからである。何が売れ筋かわかって初めて、売れ筋商品を並べることができる。売れ筋商品を並べるべしとだけ言われて、何が売れ筋かわからなければ、行動の取りようがない。いまこれこれが売れ筋だという情報があって初めて、具体的行動を取れるのだ。

このように情報は業務標準を実際の行動に転化する際に不可欠の役割を果たすのである。

そもそもビジネスは実際の行動に転化されることによってはじめて成り立つ。実際に人が動かなければ、どんな指示も、計画も、理念も、ノウハウも、無に等しい。最後は具体的に人が動いてビジネスが回るのである。ビジネスとは、結局のところ、人をいかに動かし、その動きをいかにコントロールするかにかかっていると言っても過言ではない。

■業務分析は行動だけでなく情報も定義する

業務分析とはこの人の動きを明確にすることである。とすれば、いま見たところからして、業務分析には２つの要素があることがわかる。ひとつは標準的な行動定義であり、いまひとつはそれを具体化するための情報の定義である。この二つがあって初めて業務分析は具体的に人を動かすことを担保できる。行動標準の定義だけだとそれを具体的行動に転化する術が見えない。そのとき必要となる情報が定義されていて初めて具体的に人が動けることが見えてくるのだ。

たとえば、顧客からのクレームを受け付けたとき、受付担当者がそれを聴き取り、上司に報告し、上司は必要な判断をして、必要部署に指示を出す、という業務フローがあるとしよう。この場合、業務としては、担当者による聴き取り→上司への報告→上司による判断→必要部署への指示という流れになる。しかし現実には、こう分析しただけではどうしようもない。具体的なクレームの内容、つまり情報が不明確だからだ。実際、担当者は何を聴き取ればいいのか、聴き取ったうちのどのデータを上司に上げればいいのか、上司はそのデータの何をどのように解釈して判断すればいいのか、そうしたことが明確になっていなければ、担当者も上司も動きようがない。

この業務フローの最終目的は、クレームに対して担当部署が適切な対応をして顧客満足度を維持または向上させることである。そのためには上司が適切な判断をすることが不可欠である。そのためには、その判断のための必要十分な情報が上司のもとに上がってこなければならない。さらにそのためには担当者がその必要な情報を顧客から確実に聴き取っておかねばならない。

だから、まず上司が適切な判断をするための情報が明確に定義されている必要がある。次にそのために担当者が顧客から聴き取るべき情報項目が明確に定義されていなければならない。これらの情報が抜けなく適切に定義されていて初めて、担当者による聴き取り→上司への報告→上司による判断→必要部署への指示という業務が具体的な行動となることが担保される。

■業務分析における情報定義の重要性

というわけで、業務分析においては業務定義と共に情報定義がきわめて重要である。確かにふつう業務内容のヒヤリングの際に、インプットする情報やアウトプットする情報を聴き取るのがふつうだから、そんなことは当たり前だという向きもあろう。しかし、多くの場合、単に「いまどんな帳票を使っていますか」という実態確認のレベルに留まっていると思う。さらに踏み込んでその業務のために本来どんな情報が必要とされるべきかを確認しようとするＳＥはそんなに多くない。しかし、それがなければ本当に使い物になる業務分析は望めないのだ。

情報システムを考える場合、ひとつ本質的な問題がある。情報と業務の関係である。情報は業務とどのように関係するのであろうか。そもそも、業務において情報とはどのような役割を果たすのであろうか。

■データと情報はどう違うのか？

「情報システム構築ではまず行動が定義されねばならない」で書いたように、業務行動は定型化され知識化されなければならない。まあ、簡単に言えばマニュアル化されねばならないということである。そのような一連の業務行動の中で情報システムが使用される。どのように使用されるのか？　これも簡単に言うなら、データ（情報）のインプットとアウトプットで使用されるのである。

情報システムはまずデータを入力するためにある。次にそれを出力するためにある。と言うか、何らかの形での出力を前提として、入力するのである。入力したデータが情報となって出力される。それが情報システムである。もちろん、その間にシステム内でデータが処理される。

とりあえず言葉の区別をしておかねばならないが、情報は業務文脈において意味を持つ限りでデータと区別される。情報とデータの区別は人によって異なるし、そもそも区別しない人もいる。わたしは、業務文脈に帰属していれば情報、していなければデータと考えている。

たとえば、ある営業所の今期の売上が１０００万円である、というだけでは、良いのか悪いのか判断できないし、施策の打ちようもない。つまり業務上意味がない。その点でそれは単なるデータである。しかし、そこに昨期の売上は１１００万円だったというデータが加われば、今期の売上が悪化していると判断でき、営業所長としては早急に営業施策を検討する必要があるということになる。この場合、今期売上１０００万円という数値は昨期の売上と合わせて、業務上意味を持つ。その点それは情報と言える。

とすると、重要なのは単なるデータではなく、情報である。情報こそが業務と関連性を持つからである。では、それはどのような関連なのか？　業務にとって情報とはどのような役割を果たすのか？

■マニュアルを具現化するのが情報

一定レベルで業務を続けるために定式化（マニュアル化）がなされる。しかし、定式化しただけで業務が実際にできるようになるのか？　答えはノーである。単に業務行動を定式化しただけでは業務を遂行することはできない。定式化はそれだけでは、単なる一般論に過ぎない。標準化である以上、マニュアルは誰がいつやってもできるように抽象化されている。しかし、実際の業務はいまここで特定の人が遂行する。だから、マニュアルはいまここでの状況へと具体化され、適用されねばならない。

この具体化の役割を果たすのが、情報なのである。

営業所の業績を伸ばすための方法論は多くの場合社内で定式化されているはずである。しかし、そのような一般的方法論だけで実際に有効な施策が打てるかと言えば、ノーであろう。なぜなら現状の問題を認識し、その問題を生んでいる原因を突き止めなければ手の打ちようがないからである。現在の売上が前期比９０％であり、その原因はアフターサービスへの顧客満足度の低下にある、といった情報をつかんではじめて、一般的方法論をいまここの状況へと適用できるのである。一般的方法論は、現状の事実と原因の認識を通過することによって、はじめて具体的施策として結晶するのである。

だから情報は業務において不可欠である。ではこの情報はどのようにして得られるのか？　今日では多くの場合、単なる手作業だけでそれを得るのは不可能である。コンピュータで処理される必要がある。コンピューターで処理するためには、処理対象となるデータを入力しなければならない。何らかの仕方で得たデータをコンピューターに入れ、そのデータが加工処理されて業務の一定のタイミングで情報として出力され、活用されて、それが業務上の成果に結びつく。情報システムはこのようにして業務の中で使われるのである。

■システム設計の核心は業務と情報の関係

システム設計においてまず業務分析がなされるのは、このためである。業務分析の手法はいろいろあろうが、わたしはもっともオーソドックスに、フローチャートを使う。フローチャートもいろいろあるが、わたしはごく単純に業務と情報の２つの要素からなるフローチャートを描く。なぜなら、業務と情報の関係、それこそが情報システムの要件と仕様を決定するからである。

情報システムが、データを入力し、処理し、それを情報として出力するものであるなら、データ入力、データ処理、情報出力の３つのフェーズの仕様を決めればシステムは設計できる。その仕様を決めるためには、それぞれのフェーズの要件を決めなければならない。その要件はデータ入力周りの業務行動と情報出力周りの業務行動の定義によって初めて明らかになる。

たとえば、そのデータは毎月月末の締め後に本社に集まってくるので、大量データを一括・迅速に入れる必要があるといった業務上の必要性から、データ入力における要件が決まる。次に、売上情報は管理職が次月の施策を立案するためにエクセル形式で出力し、請求情報は窓口担当者が顧客からの問い合わせに答えるために画面参照するといった業務上の必要性から、入力されたデータをどのように処理し出力するかの要件が決まる。

入力においてはデータをどう入れるかが問題になる。それに対し出力時にはその情報を使って業務をどう具体的に遂行するが問題になる。したがって、もう一度繰り返すが、業務の一般的方法（マニュアル）をいまここでの個別ケースで具体的に実行することを可能にするのが情報であり、その情報を適切にアウトプットするために、必要なデータを入力し、処理するのが情報システムなのである。

業務をそのつどの具体的状況で首尾よく実行するためにどのような情報が必要か。それを明確にするこそが、情報システム設計の核心なのである。

先のエントリー「情報システム構築ではまず行動は定義されねばならない」において、情報システム構築は行動定義に基づかねばならないこと、その行動定義は最終的には知識化に至ることを述べた。

だが、システムと行動定義（知識）の間には、もう一つ、重要な要素が介在する。情報である。情報システムなのだから、情報が重要なのは当たり前であるが、だが、そもそも情報とは何なのか、ビジネスにおいてどのような役割を果たしているのか、必ずしも自明ではない。

そこで、情報とは何かについて見て行きたいのだが、そのために、いくつか整理しておきたことがある。

■ＩＴマネジメントと情報マネジメント

まず、ＩＴマネジメントと情報マネジメントの区別である。ＩＴは字義通りに訳せば「情報技術」であるが、それゆえ、ＩＴは情報を前提としている。情報あっての情報技術である。ビジネスにおいて情報が重要であり、その活用が不可欠であるからこそ、それを効率的に流通させるための技術（つまり情報技術）が必要となる。だから、ＩＴをマネジメントする前に、まず情報をマネジメントする必要がある。自社のビジネスにとって、どのような情報が重要でかつ不可欠なのかを定義し、活用し、たえず見直していく。それがあって初めて、そのために必要な技術インフラ（ＩＴ）のマネジメントが問題となるのである。

■情報マネジメントにおける規定的情報と触発的情報

その情報マネジメントにおいて、さらに２種類の情報を分けておく必要がある。規定的な情報と触発的な情報である。前者は、行動を規定する情報という意味であり、マニュアル化され標準化された行動を取るときに決まって必要となる情報のことで、情報システムで取り扱われるのは主にこの情報である。それに対し、後者は、思いもよらない発想や行動を生み出すような情報、すなわち、その情報に触発され、ひらめいて、新たなアイデアが生まれるといったタイプものである。これはふつう、情報システムにはそぐわない。

ビジネスにおいては両方とも不可欠である。規定的情報と触発的情報は車の両輪であって、どちらがなくてもビジネスは成り立たない。コンプライアンスや品質管理の観点からは、規定的情報がきわめて重要である。しかし、それだけでは新たな価値を生み出すことはできない。一定品質の製品を生産し続けることはできても、市場を創造するような斬新な製品は生み出せない。それでは、企業として未来はないであろう。新たな発想やアイデアを触発するような情報を社内に供給し続けることが、企業の未来を開くのである。

規定的情報と触発的情報は、情報内容によって区別されるのではない。まったく同じ内容の情報が、ある人にとっては規定的で、別な人にとっては触発的ということがありうる。決まりきった経費項目の情報が、人によっては劇的なコスト削減のアイデアを生み出すきっかけになるかもしれない。内容が必然的に規定的か触発的かを決めるのではなく、むしろ、それを受け取る人（感性、問題意識、文脈等々）の違いによって、規定的にもなり、触発的にもなるのである。

このことから見えてくるのは、触発的情報のマネジメントのしにくさである。上に見たように、触発的情報は偶発性をもつ。どの情報が誰のもとで触発的な機能を果たすかは、なかなか見通しがたい。それは偶然の僥倖のように新たな着想を生み出すように見える。また、このような情報は、ビラミッド型組織における上下伝達にはあまりそぐわない。むしろ、横方向のネットワーク的な伝達によく合う。休憩室でタバコを吸いながら喋り合ったことで新たなアイデアがひらめくということもありがちなことだ。正式な組織よりも、非公式なグループでのやり取りが自由な着想のもとになることもあるのである。となれば、さらに触発的情報の全体は見通しがたくなる。

実際、触発的情報のマネジメントには限界がある。それは、偶発的であるがゆえにマネジメントすることが難しい。しかし、まったく不可能なわけではない。企業において触発的情報は価値創造と結びつく。それゆえ、価値創造と関りのある企業領域は触発的情報と親和性が高いということになる。たとえば、顧客の声やマーケットの情報は新製品や新規事業と結びつく。あるいは、他社のベンチマーキング情報などは自社の業務改善のアイデアに繋がる。こうした情報領域に豊富な情報が入ってくる仕組みが触発的情報のマネジメントにおいては重要になろう。これについては、また、別の機会に書きたいと思う。

それに対し、規定的情報は、はじめに見た行動定義（知識）に密接にかかわる。触発的情報が偶発的要素を持っているのに対して、規定的情報は行動定義に基づいてフィックスされている必要がある。それぞれの業務行動は必ず何らかの情報に基づき、かつ何らかの情報を生み出す。業務行動定義には情報定義が必ず伴う。規定的情報はあらかじめ定義され、誰が、いつ、どのように活用し、どのような行動に結びつくかが設計され、その通り運用され、また改善されねばならない。その意味で、規定的情報こそが、情報マネジメントの主要な対象となる。

■ＩＴマネジメントにおける情報システムとコミュニケーションプラットフォーム

情報マネジメントのこうした区別に対し、ＩＴマネジメントも２つの領域に区別される。情報システムとコミュニケーションプラットフォームである。ふつう、ＩＴマネジメントは情報システムを主要モデルとして展開される。システム監査も情報システムを念頭においているし、情報セキュリティも情報システムにおいて扱われる情報が主な対象である。Ｊ－ＳＯＸにおけるＩＴ全般統制もＣＯＢＩＴも、ＩＴ戦略から、システム開発、運用全般、すべて情報システムが基本前提となっている。

しかし、企業のＩＴを考えるとき、情報システム以外に重要な領域がある。それがコミュニケーションプラットフォームとしてのＩＴである。情報システムが、インプットされる情報、アウトプットされる情報が定義されており、それが使用される業務行動も設計されているのとは対照的に、コミュニケーションプラットフォームは、字義通りプラットフォームしかない。その上をどんな情報が流れるかは完全には定義されない。大枠はあるものの、決まった情報が必ず流れるわけではない。だから、その情報からどのような発想や行動が生まれるかも事前に決めることはできない。

メールにしろ、社内掲示板にしろ、ある程度の枠はあるにしても、基本的には発信自由である。そこでは思い思いに情報がやり取りされる。インプットもアウトプットもふつう定型化されない。メールシステムもグループウエアも、それ自体が情報を生み出すのではなく、あくまで情報が流れる土台に過ぎない。

そもそも、一つの業務を進めていく上で、コミュニケーションは不可欠の要素である。どれだけマニュアル化され、行動定義がなされていても、実際に人と人とが協力して業務を進めていこうとすれば、そのつどの状況に適応するためにさまざまなコミュニケーションをとらねばならなくなる。各人の業務習得の度合いも違うであろうし、個性や性格も違う。当該業務の置かれた社内、社外の環境も違うし、顧客の要求レベルも違う。その違いに適合するためには相談し、連絡し、教え合い、議論等々する必要がある。そのとき対面だけでなく、メールやグループウエアが重要な役割を果たす。

さらには、いろいろなアイデアを出し合ったり、そこから新しい着想を得たりすることも、コミュニケーションの重要な役割である。ブログやＳＮＳ、wikiなどのWeb2.0のツールを社内で立ち上げるケースも見られる。グーグルが社内の日報にブログを使っていることは知られているが、これによって、新しいアイデアが提案され、そこに他の人が新たな着想を付け加え、大きなプロジェクトに育っていくのである。

上で見た規定的情報と触発的情報で言えば、情報システムが主に規定的情報を扱うのに対し、コミュニケーションプラットフォームは主に触発的情報の流通に資する傾向が強い。それだけに、コミュニケーションプラットフォームはＩＴマネジメントにとって重要である。先にも触れたように、ＩＴマネジメントはふつう情報システムばかりに目をやる傾向が強い。しかし、コミュニケーションプラットフォームを計画的に導入していくことは、それに劣らず重要なのである。

最後にまとめておこう。

◎情報マネジメント　：　規定的情報と触発的情報の区別

◎ＩＴマネジメント　：　情報システムとコミュニケーションプラットフォームの区別

◎そして、規定的情報≒情報システム、触発的情報≒コミュニケーションプラットフォーム

それから、もう一つ付け加えておきたい。規定的情報と触発的情報の区別は、情報マネジメントやＩＴマネジメント（つまり、企業という枠）から完全に離れて、インターネットの領域においても妥当する。たとえば、Web3.0で言われているパーソナライゼーションとリコメンデーションについて言えば、前者は主に規定的情報に、後者は主に触発的情報に親和的である。なぜなら、パーソナライゼーションは、自分が欲しい情報をピンポイントで求めるが、そのときその情報を必要とする行動が事前に想定されていると考えられるからであり、また、リコメンデーションは、思わぬ情報との出会いの側面が強く、そのつど新たに考えや行動を誘発すると考えられるからである。

「情報システムと「行動」」というエントリーで、業務行動が明確に定義されて、はじめてシステム仕様が固まると書いた。しかし、情報システムが行動に基づかねばならないのはなぜだろうか？

それは、そもそもビジネスにおいて行動は定義されているはずのものだからある。そのつど行き当たりばったりで業務が行なわれるなどということはありえない。特に、今日のビジネスは、組織的に行なわれる度合いが高く、しかも、一定品質の安定したアウトプットを必要とするからだ。組織的であるということ、安定した品質ということ、この２点のために、業務において行動は一定の定型をもたなければならない。とすれば、情報システムもその定型に基づかなければならない。

■ビジネスにおける行動定義の必要性

まず、組織で行なうとは、個人の思いつきで成果は出せないということだ。１９６０年代ぐらいまでなら、スーパービジネスマンが孤軍奮闘してビジネスプロセスを回すといったことがあったかもしれない。しかし、そんな時代はとうに過ぎた。市場ニーズの把捉から分析、商品企画、設計、製造、プロモーションに至るまで、商品を産み出して売るプロセスはきわめて複雑なものとなった。もはや、それぞれ専門的な組織が自らの機能を果たしつつ相互に連携することによってしか、ビジネスプロセスは回らない。たとえ斬新なアイデアがあったとしても、商品の形にして最終顧客に届ける全プロセスを考えると、個人ではどうしようもないのである。

また、安定した品質という意味でも、そのつどの思いつきはゆるされない。ましてや各機能が相互に連携してはじめて最終的なアウトプットが可能となるのであれば、なおさらである。ビジネスプロセスにおいては、各機能は連接する次の機能に対して必要とされるアウトプットを確実に渡さねばならない。商品企画の品質が低ければ、まともな設計はできないし、設計が一定品質に達していなければ、製造に入れない。リレーのバトンのように、確実な品質で手渡していかねばならないのである。そのためには各プロセスが常に一定の品質でアウトプットを出せるよう、同一の手続きで運用されねばならない。「今回たまたま出来が良かったんですよ」では、通用しない。

だから、行動は、もっとも安定したアウトプットを組織的に出せるように標準化され定義されていなければならないのである。実際、各機能プロセスを構成する最小単位は、各個人の行動である。個々の行動が繋がってはじめて各プロセスが成り立つ。この各個人の行動がそのつどの思いつきやその時々の都合でたえず変動していたのでは、各プロセスのアウトプットが不安定化し、それゆえプロセス間のバトンリレーは成り立ちようがない。それは、基本的な点では常に同一の手続きでなされねばならないし、そのように定義されていなければならないのである。

■業務行動定義の４段階

では、もう少し踏み込んでみよう。行動の定義にはどのようなものがあるのだろうか。実際、それにはいくつかの段階がある。

まず第一に、そもそも業務行動には何らかの定型がつきものである。私たちが仕事をするとき、さしあたって何をどのようにするか、決まっているのがふつうである。一から十まで全部新たに自分で考え出さねばならないなどということは通常ない。引継ぎがあったり、先輩から学んだりして仕事を覚えるのである。確かに明文化されていないといったことはあろう。しかし、たとえ暗黙知であったとしても、一定の方法がある。この意味で仕事にはすでに暗黙裡の定義が備わっていると言える。

次に、その暗黙知が明文化されるという段階がある。マニュアル化である。業務が複雑になってくると、単なる口頭了解では各人の業務にばらつきが出てきて、同一のアウトプットが出せなくなる。その場合に、手続きを整理し、確定し、明文化すると同時に、学習という明確なプロセスを経ることによって、それを習得し、一義的な行動を取れるようにする。こうして行動は明示的に定義される。

さらにその上に、知識化がある。専門性が高くなってくると、マニュアルとその学習では必要な手続きが習得できなくなってくる。なぜなら、手続きの背後にある前提的知識が不可欠になってくるからだ。表面上の手続きを理解するだけでは、業務上のさまざまケースや変化に対応できない。背景にある原理や原則に遡ってはじめて複雑な判断が可能になる。その場合、一連の行動は背景にある根拠にまで遡って知識化されなければならない。行動は背景の深みに至るまで定義されるのである。

最後が学問（知識体系）化である。マーケティング理論や経営理論、ＩＴの世界ではＰＩＭＢＯＫやＩＳＭＳなどもそれに相当する。知識をさらに一般化し、想定されるあらゆる場合に適用可能なように高度化することである。これに則ることにより、行動はきわめて複雑で変化する環境の中でも常に同一のアウトプットが出せるようになる。これが行動定義の最も高い段階である。

■情報システムにおける業務行動定義

さて、４段階の知識定義を見てきたが、情報システムは第２段階のマニュアル化の水準で構築されるのがふつうであろう。つまり、暗黙の定義を顕在化し、整理し、明文化する（業務分析）ことに基づいてはじめてシステム構築が可能となるのである。実際問題として、最低限、このレベルで行動定義がなされていなければ、情報システムは作れない。

ありがちなのが、ろくに行動定義もできていないのに、システム化の話だけが先走るというケースである。新しい部署を立ち上げたばかりで、とにかくその事務処理手続きをシステム化したいというような場合である。この段階では事務処理も試行錯誤で、いまだ定型化の水準にまで至っていない。そういう場合にはわたしは「とにかくExcelか何かで処理をしてみてください。それが軌道に乗り、処理プロセスが固まったらシステム化を考えましょう」と言うようにしている。すでに業務行動が定義可能な状態になっているか、それを見極めることは、システム開発者にとって基本の基本なのである。

システム設計の世界では、他のエンジニアリングの世界とは異なり、用語があいまいな部分がある。要件と仕様という言葉もその一例である。この２つを同じ意味で使う人もいる。が、私は厳密に区別している。仕様はシステム開発者の側から出すべきものである。しかし、要件はユーザーから出てくるものである。

■仕様を中心に進められるシステム開発

たとえば、「申込書はこういうように集めてくるので、それを一気に入力したい」というのが要件である。それならばと、「グリッド形式で複数レコードを一挙に入力し、更新ボタンで入力された全レコードを一度にコミットするというように画面を作ろう」というのが仕様である。前者がユーザーから出てきて、後者がシステム開発者から出てくる。

この区別はふつう思われている以上に重要である。

私も情シス部門の人間として繰り返し経験してきたが、システム開発はふつう仕様を中心に進む。開発プロジェクトの会議は実質的に仕様検討会である。会議の資料は画面設計書や帳票設計書である。少し気の利いたベンダーだとプロトタイプ画面が出てくる。それをプロジェクターなどで映して、この画面はまずこのボタンを押して、こう検索して、こう入力して、最後にここのボタンを押して云々とＳＥが説明し、「これでいいでしょうか？」となる。

ユーザーはボタンの位置をもう少し上にしてくれとか、検索条件にこれも加えてほしいとか、入力項目にはこれも必要だとか、いくつか注文をつける。で、ＳＥは「わかりました。ではこれでいいですね。」となって、決定である。

話されている内容はすべて仕様である。決定されたのも仕様である。「そもそもこの入力をしなければならないのはどんな業務をしているからか」、「その業務でどんな情報が発生しているのか」、「その情報のうちシステムとして管理しなければならないのはどの情報で、それはなぜか」、といった話はあまりされない。（というか、多くの場合しないであろう）。つまり、要件を主題として議論がなされないのである。

■行動→要件→仕様と進むのが本来

しかし、少しそもそも論に立ち返って考えてみよう。仕様と要件とどちらが前提であろうか。もちろん、要件である。要件があるから、それを実現するために仕様が決まる。逆ではない。にもかかわらず、プロジェクト会議ではユーザーもＳＥも情シス部門の者も、よってたかって仕様の話をする。仕様をどうすべきかわからなくなったときだけ、「そもそも要件はなんだったけ」となる。逆である。

前のエントリーでも書いたが、根本にあるのはユーザーの行動である。行動から要件が導き出され、要件から仕様が導き出される。行動→要件→仕様である。この基礎付け関係は変えようがない。とすれば、仕様を中心に検討が進むことはいささか異様であると言わざるを得ない。

そうしたことが可能なケースは考え得る限りひとつだけである。プロジェクトの関係者全員が当該業務に実際に携わっている場合である。よく、部門の中でＩＴに強い人がAccessなどを使って簡単なシステムを作るケースがある。こうした場合は、そのＩＴに強い人も含め全員が当該業務に携わっているので、日々の業務行動も、要件も、自明である。つまり、全員が間違いなく共通の業務理解をもっていて、その理解にブレがない。（あるとすれば個人差だが、それは今は省略する）。だから、あとは仕様をどう決めるかだけがポイントとなる。それなら、仕様を中心に話を進めて何の問題もない。

しかし、通常のプロジェクトの場合、ユーザーだけが業務に精通していて、ベンダーのＳＥはもとより、情シス部門の人間も業務の詳細はわかっていないというのが前提である。にもかかわらず仕様を中心に話しを進め、よくわからなくなったときだけ、「そもそもここの業務はどうなってましたっけ」と思い出したように訊くのは奇妙である。まるで、要件や業務の理解が全員で正確に共有されているかのようである。

■要件中心に進めるのがプロジェクト成功のポイント

しかし、実際には共有などされていないことは指摘するまでもない。にもかかわらず、仕様を中心に話しを進めるなら、当然コミュニケーションギャップが生じる。思いついたように要件を訊くのはいいが、思いつけなかったら訊かれないまま流れてしまうからだ。しかも、それに誰も気がつかない。それがテスト工程ぐらいになって発覚する。源資はもうない。つまり仕様変更のためのお金がない。いまさら追加コストは発生させられない。それで、運用カバーといった話になる。ユーザーにも不満が残り、実質的には失敗プロジェクトとなる。システムの品質の悪さはこうしたことにも起因するのである。

もちろん、プロジェクト会議を仕様中心に進めるのはやむを得ない面がある。私も散々そうやってきたからよくわかる。（とても人のことが言えた義理ではない）。しかし、だからこそ、ＳＥも情シス部門の者も、常にユーザーの要件と背後の業務行動に意識的に注視し続ける必要があることを痛感するのである。仕様を中心に進めていても、その意識を持ち続け、常にユーザーに背景にある業務行動を問い続ける姿勢だけは失いたくないと思うのである。

使える情報システムを構築しようとするとき、重要なのはユーザーの行動にまできちっと遡ることである。実際、情報システムは業務プロセスに基づく必要があるが、その業務プロセスは相互に関連する諸行動からなる。だから情報システムは最終的に、定義された行動にまで遡ってはじめて意味のあるものとなる。

■ユーザーの行動にまで遡るＳＥは少数

こう言えば、そんなことは当たり前じゃないか、という向きもあるかもしれない。しかし、私の知る限り、この当たり前のことを体で分かっているＳＥは本当に少ないのである。

販売管理という業務プロセスを考えてみよう。たとえば、ある販売管理プロセスが、「顧客獲得」、「受注」、「納品および売上計上」、「請求および入金」という４つのアクティビティからなるものとしよう。

それに基づいて販売管理システムを構築するとする（ふつう、パッケージで済ますだろうが、いまは議論のためそう仮定しよう）。これらのアクティビティは、それぞれ「顧客登録」、「受注入力」、「納品入力および売上計上処理」、「請求処理および入金入力」という４つのシステム機能に置き換えられるだろう。こうした場合、多くのＳＥはシステムを作ることしか念頭にない。とりあえずシステムに置き換えることに集中する。そこで、たとえば、まずは受注入力画面の設計書を作り、ユーザーに、「この画面で何か問題はないですか？」などと訊くことになるのである。

■システム構築リスクを高める業務行動の軽視

しかし、こんなことではシステム構築のリスクを高めるだけである。そもそも行動には３つの要素がある。why、what、howである。（who、when、whereは割愛する）。何の目的で、何を、どのような方法で行なうか、それで行動は定義できる。whyは今はおいておくとして、問題はwhatとhowである。上の例ではwhatは捉えられているが、howが完全に抜け落ちている。何をするのかは、顧客獲得、受注、納品などとして明確になっているが、それらをどのように行なうかということにはまったく注意が払われていない。

たとえば、受注に関して言うなら、受注自体はどのようなタイミングで発生するのか。時期的特性はなく随時発生するのか、それとも月末などに集中して発生するのか。もし、随時発生なら、入力も随時になろう。時期的に集中発生するなら、入力も一時に集中してすることになろう。すると、これによって画面の作りも変わるのである。

随時ならランダムに顧客を抽出し、１レコード単位で入力するような画面展開が必要となる。一時に集中するなら一定のまとまった単位で、たとえば地域や業種といった処理上意味のある顧客特性ごとにまとめて入力するといった画面のつくりが有効となる。さらに定期的に受注がある場合は、定期顧客だけ一覧形式で入力できる画面が必要といったことにもなろう。

しかし、多くのＳＥは、まずはユーザーの業務行動を中心に据え、その上で画面や帳票を考えるということをしない。とりあえず画面・帳票等のシステム機能を中心に考える。そしてある程度の業務知識が得られれば、さっそく設計書を作って「この画面でどうですか？」と訊くということになる。そう問われればユーザーはいろいろ言うであろう。ここはまとめて入力したいとか、ここはかくかくしかじかの条件で抽出したいとか、思いつくままにほしい機能の話をするであろう。それでいいではないか、ユーザーの要件を聴き取っているのだから、というのが大方のＳＥの言い分であろうか。

■要件漏れを防ぐ業務行動の聴き取り

しかし、このやり方には致命的な欠点がある。網羅性が担保されないのだ。網羅性が担保されなければ要件漏れが出る。要件漏れこそがテスト工程から本番稼動に至るまでもっとも厄介なシステム構築の阻害要因であることは言を待たない。

問われれば思いつくままに答える、これこそがユーザーの特徴である。ＳＥの中で、ユーザーは筋道を立てて網羅的に要件を語ってくれるものだ、などと思っている人がいるだろうか。一人もいまい。思いつきで話されたことを全要件と思い込んで（あるいは思わざるを得なくて）、それで痛い目にあったことのあるＳＥも多いであろう。だからこそ、ＳＥの側が主導権をとって、徹底的に網羅性が担保できる聴き取りをしなければならないのである。

そのポイントは、まずは画面や帳票のことは置いておいて、ユーザーの業務行動それ自体に集中することである。たとえば受注業務においてなら、そもそも営業は顧客とどのような接点を持つのか、その接点のどこで受注が発生するのか、受注の諸条件はいつどのようにして決定するのか、発注書や契約書などの書類はどのタイミングで手に入るのか、入手した書類はどのように整理されるのか、最終的に誰が承認チェックするのか、受注情報の入力は営業か事務アシスタントか誰が、またどの書類を原帳票にして行なうのか、等々。こうしたことを順序だてて網羅的に聴き取るのである。

画面･帳票はあとだ。まずは業務行動を徹底的に訊く。そうすれば、「そんなことをやっているのか」、「そんな例外的なことがあるのか」、「そんな独特な業務文化があるのか」などなど、思いもしなかったことが出てくるであろう。その中には聞き漏らしていたら設計にとって致命傷になったかもしれない要件もあるはずである。一通り知っていたつもりが、何もわかっていなかったのである。一見迂遠に見えても、まずユーザーの行動に徹底的に定位することが、後の手戻りを防ぐのである。