コンピュータ・エージ社『コンピュートピア』誌のエッセイコラム「電脳周辺」に数回連載しました。
９６年 ４月号 「情報システム部門論」への疑問
９６年 ５月号 ＣＯＢＯＬプログラマよ、自信を持て
９６年 ６月号 「データウェアハウス論」への疑問
９６年 ８月号 情報共有度の測定尺度はないか
９６年１１月号 情報関連投資の説得論理を求む
コンピュートピア 電脳周辺 1996.4
「これからのＳＥに必要なものは」の質問には、昔も今も決まって「ユーザ業務に関する知識」が第１位になる。それならば、各部門から中高年者を情報システム部門に集めればよい。それなのにどうして、情報システム部門は若い人たちをほしがるのだろうか。「情報技術が高いのは当然」だからあえてあげないのかもしれない。しかしこの回答は、情報技術よりも業務知識のほうが重要であることを証しているようなものである。
また、これからのＳＥは提案型ＳＥになるべきだともいわれる。でも本当にユーザはそれを望んでいるだろうか。大所高所からの提案などをするよりも、自分が頼んだことを、さっさとやってくれる従順型ＳＥのほうが、便利で役に立つと思ってはいないだろうか。情報システム部門も、そのほうが喜ばれると思っているのではないか。だから、ユーザよりも社内的地位の低い若い人を必要とするのだろう。
最近のような環境変化の激しいときに、本当にユーザはニーズを知っているのだろうか。おそらく知っているにしても、当面のニーズであり、システムのライフサイクルからみれば、あまりにも短い期間だけにしか有効ではないニーズなのではないか。さらにいえば、もし現行システムを廃棄したとき、ユーザは手作業でカバーできるだけの業務知識を持っているだろうか。「ユーザ主導」の情報システムであるべきだという。それならば、情報システムの責任はユーザが負うべきであるが、ユーザにその責任を持たせることができるだろうか。
情報は第４の経営資源であり、競争戦略の武器だといわれる。それで情報システム部門はもっと経営の中枢に入るべきだといわれる。ところが多くの情報システム部門では、大量のバックログを背負い、頻繁な要求に追われ、日常のトラブルに頭を悩ませている。情報システム部門は、このような日常的業務を主としてきた部門なのである。このような部門に、戦略的企画的な業務を併存させることが適切だろうか。
だからアウトソーシングすべきだという意見もある。そうすれば日常的業務からは解放されるであろう。しかし、いままで日常業務に追いまくられていた人が、急に変貌できるとは思えない。むしろ、戦略的思考を業務としているゼネラルスタッフ部門が、もっと情報技術動向やその適用技術を習得するほうが現実的なのではあるまいか。これらの習得が困難だとするなら、上記の「これからのＳＥ」と矛盾する。
そもそも、「情報システム」「情報システム技術者（ＳＥ）」「情報システム部門」の３つを混同するから、ややこしいことになるのである。情報システムが戦略的に重要だとしても、それで情報システム部門を戦略的部門だとするのは早計であろう。また、「ＳＥ＝情報システム部門」の図式も適切ではない。なにもＳＥは情報システム部門に所属する必然性はない。とくに、ダウンサイジング環境になればなおさらである。
「だから情報システム部門を解体して、ＳＥをユーザ部門へ異動させよう」という動向がある。そうしたときにユーザ部門は情報システムに責任が持てるのだろうか。ユーザ「部門」ではなく、異動した「元情報システム部員」個人にその責任をかぶせるのではないか。分散して孤立したＳＥをスケープゴートにするのはたやすいが、当人にとってはあまり楽しいものではあるまい。
「情報システム部門よ。変貌せよ」といわれる。では、情報システム部門がその論旨のように変貌しようとしたら、従来からの業務は誰がやるのだろうか。アウトソーシングというのはたやすい。アウトソーシングは一種の増員である。リストラが盛んな状況では、人員整理の数が増えることになりかねない。できれば増員なしに行いたい。すると社内で吸収する必要がある。
ダウンサイジングとは、ユーザ部門で吸収させるための手段である。それを円滑にするには、ユーザ部門が受け入れ体制を整備しなければばらない。それなのに、ユーザ部門は上述のように、未だそのようになっていない。変貌すべきなのは、むしろユーザ部門なのである。
コンピュートピア 電脳周辺 1996.5
ダウンサイジングの進展により、最近のシステム開発は、メインフレーム環境でのそれが減少し、クライアントサーバ環境での開発が多くなってきた。そこで、情報システム部門でも部員を新しい環境に転換を図っている。ところが、「ＣＯＢＯＬプログラマは転換が困難だ」ともいわれる。今回はこれについて考えてみたい。
メインフレーム環境での典型的なシステムとして、ＣＯＢＯＬでの給与計算システムを、ダウンサイジング環境の代表例としてグループウェアを考えよう。
給与計算では、当事者としては異論があろうが、「何をすればよいか」はある程度明確である。ＳＥは、それをいかに効率的に間違いなく運用することを考えればよい。また、その後どう発展するかは別として、一応、給与計算ができれば、それで一件落着になる。足を怪我した患者がきて、手術をして治ったのと同じように、目的、方法、結果が明確である。
それにたいしてグループウェアでは、まず仕様が不明確である。「情報の伝達を円滑にしたい」とか「情報の共有化をしたい」とはいっても、具体的に誰と誰が何を伝達し共有化したいのかは明確ではない。ニーズが抽象的なのである。その結果も、どこまで円滑になり共有化できれば完了するのかわからない。もっと端的にいえば、実際に円滑になったかどうかすら定量的にはつかめない。ちょうど「体の調子が悪い」という患者に、あれこれ漢方薬を処方したところ、「なんとなくよくなった」という感じで、本当の原因は何だったのか、薬が効いたのか自然に治癒したのか、はたして完治したのかどうかもわからない。
給与計算では、内容が複雑でデータ量が多く、コンピュータの性能が低いようなときこそ、ＳＥの腕の見せ所である。しかし、使う道具はＪＣＬとＣＯＢＯＬおよびいくつかのユーティリティに限られる。メスとかピンセットなどの比較的単純な道具の特徴を知り尽くし、それらを使いこなして、複雑な手術ができるのが優れた能力である。
それにたいしてダウンサイジング環境では、パソコンの機種、ネットワークＯＳ、ミドルウェア、アプリケーションパッケージなどが多くあり、それらの組み合わせのうち、患者の体質に合い、副作用のないものを選択することが重要になる。ここでは、世の中にどのような薬があり、相乗効果や禁忌条件を知り、症状と処方の事例を多く知ることが必要になる。
ようするに、ＣＯＢＯＬプログラマは外科医なのである。ところがダウンサイジング環境で要求されるのは内科医の能力である。新環境に適応するには、内科医の能力を修得する必要がある。ところが、外科医と内科医では適性が違う。それが「ＣＯＢＯＬプログラマは・・・」という論拠になるのであろう。
しかし、よく考えてみよう。「患者がくる」のは、情報システムでは「予算がつき具体的な開発に入る」段階である。実際に重要なのは、それ以前の「何が問題か」の発見の段階である。外科医でも内科医でも医学の知識がなければ役立たないように、これはメインフレーム環境であろうとダウンサイジング環境であろうと、あまり違うものではない。その能力を持っているのがよいＳＥなのである。ベテランのＣＯＢＯＬプログラマよりも全然経験のない素人のほうが適しているというのは、どこか間違っている。
実は、新環境で役立たないＣＯＢＯＬプログラマは、医学の基礎も持っていないので、旧環境でも役だってはいなかったのである。ところが、旧環境では「プログラムを書く」という作業が比較的大きな業務だったので、それに埋没していられただけだったのである。
逆にいえば、情報技術とその応用について基本知識を十分に理解しているＣＯＢＯＬプログラマは、新環境においても十分に対応できるはずである。いいかえれば、「ＣＯＢＯＬプログラマは・・・」などと誹謗する人は、その人自身が役立たないＣＯＢＯＬ屋レベルの発想なのだとも想像できる。そんな説にまどわされてはならない。
コンピュートピア 電脳周辺 1996.6
最近、データウェアハウスが話題になっている。この種の話題の特徴として、ことさらに新しさを主張しすぎることが多い。私は、十数年エンドユーザコンピューティングを推進しており、最近はデータウェアハウス構築の検討をしているのだが、どうも手放しで賛成できない点もある。
ＥＵＣの発足では、とかく個別帳票出力メニューでの提供が多い。この方式は便利ではあるが、個々のメニューを情報システム部門が作成するので、ユーザの要望を満たすだけのメニューを提供するには、開発や運営が大変になる。それを回避するために、個々の帳票を提供するのではなく、その元となるファイルを公開し、使いやすいツールを提供することが考えられた。
ところが、この公開ファイル提供方式でも、ユーザにはジョインなどの複雑な処理はさせるべきではないとの意見があり、個別帳票作成寸前までに加工したファイルを提供するようになった。その結果、同じような公開ファイルが乱立し、ファイルの管理が大きな問題になった。その改善のために、公開ファイルはできるだけ正規化して体系化すべきだとなった。すなわち、目的別ではなく汎用な部品としてのデータを提供すべきだとなってきたのである。
ところが最近のデータウェアハウス論では、目的別ファイルを提供せよという。たしかにそのほうがユーザには利用しやすい。しかしややもすると、この種の議論は、正規化は悪だとの議論になってしまう。ＯＬＡＰでは、多様な切り口や項目での情報が要求される。そのたびに既存のファイルを変更すればよいのだが、それが面倒なので新しいファイルを作るようになり、上述の類似ファイルの乱立になる。それがどのような混乱を招くかは、以前にいやとなるほど経験したことである。
データウェアハウス論になかには、正規化を非難する議論がある。それをまともに解釈すれば、得意先マスタや商品マスタを持たずに、それらの属性をすべて売上ファイルに持たせることになってしまう。しかも、情報系システムでは、市町村マスタに人口や自動車台数などの属性が必須であるように、マスタに持たせるべき属性は、基幹系システムにくらべて非常に多い。これでは１レコードのバイト数は数千から万のオーダになる。
そんなファイルを時系列にディテールレベルで持ったとしたら、その容量もアクセス時間もとんでもないものになってしまう。多次元データベースにすればよいという意見もあるが、マスタ情報をすべて入れたらすごいものになる。実際の保管には圧縮するのであろうが、そうするとインデクスが複雑になり、毎日の更新が１夜ではできなくなってしまう。それにたいして、ディスクは安くなったとか、並列プロセサならばというような論調になりやすいが、それは従来の汎用機ＯＳの恐竜化と同じ論調である。
ユーザが実際に困惑するのは、ＳＱＬが難しいなどのこともあるが、それ以上にわからないのは、項目やファイルの内容が理解できないことなのである。たとえば「支店」には本社直売部門は入るのかどうか、３月に１００出荷して４月に１０返品があったら、「数量」の３月が９０になっているのか、３月が１００で４月が−１０なのか、あるいは「仕訳」に返品コードがあり、数量は＋１０になっているのかが不明では、安心して使えない。
それだけならよいのだが、この事情を知らずに使って、結果が自分の知っている値が違うとか、他の帳票の値と違うとなると、コンピュータ不信論にもなるし、それにも気づかないと、誤った意思決定をする危険すらある。
これらは項目説明やファイル説明として、メタデータとして管理すべきものである。それなのに一般的なソフトウェアでは、名称や桁数などは出ても、このような情報を記述して表示する機能が不十分のように思われる。そもそもメタデータは、どこに何があるか、その関連はどうかを管理するものである。この種のソフトウェアでは、メタデータの機能が最大のポイントのはずである。ところが、ベンダの説明も、操作の容易性やグラフの豊富性などばかりが強調され、メタデータに関する説明はほとんどない。これでは困るのである。
コンピュートピア 電脳周辺 1996.8
グループウェアの効果として「情報の共有化」が重視されている。ところが、それを測定し評価する適当な尺度がない。それが、グループウェアの導入を説得するにも、事後の評価を示すにも説得力に欠ける一因にもなっている。効果を金銭的に評価するのは困難だとしても定量的な尺度がほしい。それがあれば、グループウェアの効果測定だけではなく、自社の共有化状況のレベルも把握できるだろうし、他社のコンサルティングにも便利である。
このような目的で、「パソコン１台あたりの人数」のアンケートがよく行われている。しかし、Ａ社が１.３人に１台でＢ社が２.５人に１台だといっても、対象母集団であるホワイトカラーの定義が人により異なるので、適切な尺度とはいいにくい。
社内調査では、電子メールの受発信数や電子掲示板への掲載数を測定できる。しかし、情報共有化の効果は数だけではなく内容の質に大きく関係する。たとえば商談報告を掲示板に載せることにより、ベテランからアドバイスを得たり、他部門の人が大きなビジネスチャンスを得たりする。このような効果を、形式的な報告を狭い関係者間にだけ連絡するのと同等に取り扱ったのでは、適切な尺度にはなりにくい。
開放的な組織では、報告や意見交換が広く行われるが、閉鎖的な組織では、組織内の情報を外へ出すのを明示的暗黙的に規制されることが多い。また、自分に都合が悪いことは公表したくないし、余計なことを書いて他部門から問い合わせなどがあれば面倒だという気持ちもある。すなわち、情報共有度の測定は組織の開放度の測定にもつながるといえる。
従来は口頭や文書で報告していた商談報告を掲示板に載せることを考えよう。載せることは強制できるが、その内容までは強制できない。誰が見るかわからない掲示板には、きわめて形式的な事項だけしか載せない。この結果、直接の上司ですら掲示板化したために、得られる情報量が減少してしまうことすらある。
もっとフランクに発言させるためには、各掲示板にアクセスできる人を制限する必要がある。すると極端な場合には、隣の同僚にも秘密にしたいとか、直接の上司にはしたかないが、その上の上司しは知られたくない、でも他部門の誰それには知らせておきたいなど、かなり複雑なセキュリティを設けることになる。さらにそれが進むと、掲示板ではなくメールだけで連絡しあうようになる。
すなわち、メールがよく利用されているとか、掲示板利用でペーパーレスになったといっても、それが共有化の尺度だとは一概にはいえないのである。
この観点から共有度チェックのリストを作ってみた。できるだけ外部から測定できる項目に絞った。
定量的尺度にはほど遠いが、このようなリストをリファインして、経験による数値化をすれば、所期の目的に近づくと思う。筆者はこのようなことに関心を持っているのだが、不勉強なために文献や資料を知らない。皆様のご指導ご支援を仰ぎたい。
コンピュートピア 電脳周辺 1996.11
日本経済もやや明るさが見えてきて、情報関連投資も上向きになってきたようであるが、まだまだ財布の紐は堅い。今回のバブル崩壊は情報関連投資も直撃した。というよりも、従来の情報関連費用こそバブルの申し子だと指弾を受けた。景気が好転し始めたとはいっても、情報関連投資には厳しいチェックが行われるであろう。
ふだんから情報システム部門は情報化投資の費用対効果の把握に悩んできた。とくに最近のグループウェアやデータウェアハウスなどは、定量的な効果だけでは有効性を示すのが困難であり、情報の共有化とか価値ある情報の発見などのような，定性的あるいは戦略的な側面を強調する必要がある。
このようなことは，多くの識者が指摘しており、評価の方法も示している。しかしどうも現実に経営者を納得させるには不十分なようである。ここでは，情報関連投資に反対する立場から、説得の論旨を否定してみよう。
情報の共有化といっても、誰と誰が何の情報を共有するのかわからない。それがわかれば、その人たちの机を並べるか、専用電話や置いてもよいし、組織を変更してもよいだろう。グループウェアを導入すれば情報が共有化するというのもおかしいし、導入しなければ共有化できないものでもない。
情報共有化の効果の説明を聞くと、もしユーザが積極的に情報を入力し、もしその情報が価値あるものであり、もしそれを理解できる人がそれを見つけ、もしそれが実施できたとしたら、これこれの効果があるということだ。しかし、効果が得られるのは，すべての「もし」が実現したときであり、一つでも欠ければダメである。しかも，その「もし」は不特定多数の人にかかっているのだから、提案者がいかに主張しても実現は保証できない。
データマイニングの効果は、金鉱が存在することとその金鉱を発見できることが前提になる。ところが、それはやってみないとわからないという。しかし、なかったことに気づいたときは、ハードやソフトの投資が完了した後である。しかも、金鉱がないことを証明するのは、あることを証明するよりも困難である。ずるずると費用と時間を浪費することにならないか。
もし、金鉱を発見して，何らかの手段により１０億円の利益が出たとしよう。金鉱発見とはいっても、誰かが経験的に仮説を作り、それをコンピュータで検証しただけだろう。しかも、それを実施に移すには、多くの人間的な努力が必要だったろう。極論すれば、コンピュータは社内の説得資料作成に使っただけではないか。むしろそのために実現が遅れたかもしれない。こう考えると、１０億円のコンピュータの取り分はかなり小さいといえる。
この反対論は、情報技術は人間の行動を支援するだけだとの基本的限界を無視しているのと、未知な事象の定量的測定を要求するという論理的矛盾も持っている。それだけに論理的に論破するのは難しいと思われる。このような反対論を振り回す経営者はいないと思うが、これに対処する論理があれば心強い。どなたかうまい論破方法を教えていただきたい。