本書の読者は、ITに関しては素人であるが、業務をよく理解していること、論理的な思考には慣れていることを前提にしています。そのような企業が、はじめて情報システムを構築するとき、どのように進めればよいかを示したものです。「IT素人集団でもここまでできる」「この程度はやるべきだ」という内容を示しています。独創的な方法論を展開するのではありません。これまでの方法論を「IT知識なしに」「はじめて」取り組めるようにアレンジしたものです。初歩的な内容ではありません。IT活用の経験が長い大企業でも「当初からこのようなアプローチをしていればよかったのに」と思うこともありましょう。ここでは、システム設計をテーマにします。「IT推進にあたっては、まず経営戦略を策定し、それに基づき~」といわれます。それは重要なことなのですが、ここでは、「システムを作る」ことに絞ります。システムを作るには、プログラムを作成する、データベースを実装することが話題になりがちですが、それらは外注するのが適切なので取り扱いません。それ以前の論理的な設計段階を対象にします。一般のシステム設計の方法とやや異なる方法論を採用しています。そのポイントは、情報システムをマスタシステムとイベントシステムに分離すべきこと、そして、ファイルや項目に関する辞書(メタデータベース)が重要であり、辞書の整備をすることがシステム設計なのだという考え方です。一般に事務処理で用いるファイルは、マスタファイルとイベントファイルに区分できます(参照:「マスタファイルとイベントファイル」)。それぞれのファイルを設計し運用することをマスタシステム、イベントシステムといいます。マスタファイルとは、得意先台帳や商品台帳のようなものです。得意先や商品などに関して、あまり変化しない事項を集めたファイルです。商品マスタには商品コードや商品名、メーカー名、商品区分などの項目が入っています。イベントファイルとは、売上ファイルや仕入ファイルのように、売上や仕入れなどの事象(イベント)が発生したときにデータが追加されるファイルです。社員の所属部門や地位のファイルは、現状の情報だけが必要だと考えればマスタファイルだといえますし、人事異動というイベントにより蓄積されるのだと考えればイベントファイルになります。イベントファイルとしてもつが、最新の情報はマスタファイルでもつことも考えられます。このように、マスタとイベントの区別は厳格なものではありません。地位(項目)の参照頻度から「適当に」判断してかまいません。ルーズな方法論なのです。通常の方法論では、販売システムや会計システムなど個別のシステムを設計する段階で、マスタファイルやイベントファイルを設計するのですが、本方法論では、個々のシステムを検討する以前、極端にはIT化を前提とせずに、マスタファイルの構造を決めます。得意先台帳や商品台帳などの整備をすることを先行させるのです。イベントシステムは、販売システムなどの個別システムに該当します。この段階での進め方は一般の方法論とほぼ同じですが、基本的にはデータ中心アプローチという方法論をベースにしています。ほしい情報は何かを調べることにより、イベントファイルの内容を決定し、それを作成するのにどのように入力するかを考えるという手順になります。このイベントシステムを構築するときに、マスタシステムが存在することにより、個別システムの構築が容易になり、他の個別システムと整合性のあるシステムになるのです。辞書(メタデータベース)の構築マスタシステムとは台帳を作ることだといいました。・どのような台帳が必要か(存在するか)・台帳にどのような内容を記載すべきか(記載されているか)を明確にしなければなりません。台帳の台帳(メタ台帳)にあたるものが辞書(の一部)なのです。本方法論では、得意先業種や商品区分など、業務で用いるすべての用語(概念)について台帳化します。IT専門用語では、データの正規化という概念に基づいています。ここで重要なことは用語の定義です。「得意先」とは何かを厳密に定義して、それを社内標準語にするのです。イベントシステムでの「出荷」や「売上」などについても同様です。「辞書」といっているのは、多様な検索ができるからです。得られるのかという検索を容易にするのが辞書の目的です。この辞書は、マスタファイルやイベントファイルがもつべき情報(項目)を整理したものです。辞書が整備されていれば、それに合わせて具体的にファイルを実装するだけになります。具体的な辞書の内容などについては後述します。一般的なシステム設計論と比較して、本方法論は次のような利点があります。いうよりも、これらの利点を追求して本方法論を提唱しているのですが「銀の弾丸」ではありません。実際には、この方法論にも限界がありますし、矛盾が生じる場合もあります。それらを少なくするために、ケースバイケースでの工夫が必要になります。中途半端でも無駄な作業にならない通常のシステム設計論では、そのシステムが完成しないと、それまでの作業が無駄になることが多く、そのため、しっかりした計画をたててから作業に着手することが必要だと説かれています。それは正しいとはいえますが、「ITの素人がはじめて」のときに、そのような計画が策定できるとは思えません。この方法論の最大の利点は「無駄な作業をしない」こと、「中途半端な作業だけでも、それなりに役立つ」ことです。この方法論では、当初から網羅的な大規模作業を要求しません。逐次的に拡大・充実させていけばよいのです。そのとき、手戻りが生じないように、当初からしっかりやるべきこと、順次充実していけばよいことを切り分けることを説明しています。最初の作業である「用語を列挙して定義をする」ことだけでも、社内用語の統一ができ、部門間での誤解を防ぐのに役立ちます。「商品区分などの項目を調べる」などは、商品についてどの部門がどのような切り口での情報を必要としているかを全社的に調べるので、部門間の相互理解に役立ちます。システム化を前提にしなくても役に立つ作業なのです。/li>マスタシステムの構築だけで終わっている段階でも、「○○の条件に合致した社員は?」というような台帳検索的な利用ができます。情報システム開発はベンダに発注するのが通常ですが、この方法論では利用者側でかなりの作業ができます。セキュリティなどを無視すれば、あるいは独力で開発できるかもしれません。辞書が整備されていれば、構築すべきシステムの内容をベンダに誤解なく伝えることができます。外部仕様書どころか内部仕様書の一部まで完成しているのですから、委託すべき作業を少なくできます。マスタファイルは利用者だけで作成できるでしょう(後日更新システムの構築は必要ですが)。ベンダに依頼するのはイベントシステムだけになるので、これも委託作業を小さくなります。辞書を活用することにより、情報検索系システムをエンドユーザ・コンピューティングで行えるようになります。エンドユーザが独力で多くの情報が得られるので、イベントシステムでの出力帳票類を少なくできます(参照:情報検索系による基幹業務系の簡素化」。販売システムでの売上データは会計システムでの売掛金データになるように、各個別システムは緊密に連携しています。このとき、売上ファイルから売掛金ファイルへ容易に変換できる必要があります。「仕入先に自社製品をどれだけ売っているか」を知りたいとき、仕入先コードと得意先コードが異なっていたら名寄せ作業が複雑になります。このような、縦割りシステムの問題点は多く指摘されています。縦割りシステムになるのを防ぐために、全社的なシステム化計画の策定が必要だとか、システム開発に他部門担当者をメンバーに加えるべきだとかいわれています。マスタシステムを先行させることにより、全社的な観点から体系化が行われますので、あまり意識しなくても自動的に縦割りシステムになるのを防ぐ(少なくする)ことができます。「辞書」のイメージこの方法論では、システム設計とは(少なくともその主要部分は)辞書を作ることであるとしています。辞書の内容や留意事項に関して、本書のいろいろな個所で散在して説明しているため、全体像が把握できないと思います。それでここでは全体のイメージを示します。当然ながら、企業環境や目的に合わせて工夫する必要がありますので、ここでは概略的なイメージであることをお断りしておきます。ここでは説明なしに用語や概念を用いていますが、それは本文をお読みいただくうちに理解できると思います。いえば「正規化後のエンティティ及びその属性に関するメタ情報を記録したデータベース」です。得意先や商品など「概念としてのモノ」をここでは項目といいます(専門用語ではエンティティといいます)。企業で用いられているすべて(当然、気づいたものにものだけになるが)の項目を列挙して、商品区分と商品、部門と社員のような親子関係などの関連(リレーションシップ)ににより体系化して(正規化して)、それぞれの項目を一つのデータ(レコード)としたファイルです。・「得意先」とは何かの定義。