経営戦略の策定や情報化の方針が決まったら,情報システムの構築をベンダに依頼することになります。システム開発で必ず行う作業のうち,自社でできることは事前に自社で行っておけば,期待したシステムを少ない費用,短い時間で得ることができます。
ここでは,情報化を具体的に検討する以前に,どのような作業をするべきかを取り上げます。
ここで強調したいのは,この作業は必ずしも情報化のためだけでなく,業務の合理化にも必要な作業だということです。すなわち,情報化をするかしないかに関係なく,これらの作業はしておくべきなのです。
複数の関係者が共同作業するには,そこで用いられる用語(概念)があいまいだと,互いに誤解を生じる危険があります。特に情報化では他社ベンダとの共同作業になりますが,自社内では常識であることがベンダにも常識だとはいえません。バベルの塔になるのを防ぐためにも,用語の標準化が必要になります。
同じ名称なのに異なる意味を持つものをホモニム(同名異義語)といいます。「売上」や「得意先」などは日常的に使われている用語であり,誰でも同じように理解していると思いがちですが,案外,人により異なっていることが多いのです。
逆に,同じ意味なのに異なる名称を用いることをシノニム(異名同義語)といいます。例えば,商品を在庫しておき出荷する場所のことを,「倉庫」「出荷基地」「デポ」などいろいろな名称で呼んでいます。
このように,ホモニムやシノニムが存在すると多くのトラブルが生じます。特に情報システムの開発では,社外に依頼することが多いのですが,「自社の常識は他社の非常識」であることを認識していることが重要です。
システム開発では,まずこのシステムに要求される事項を明確にすることです。それが不十分なままに開発を進め,後になってから仕様変更により手戻りが発生すると,膨大な費用と時間がかかります。
それを防ぐためには,要求を出す側と開発をする側が,要求事項について十分に理解することが必要になります。ところが,用語の定義があいまいなために誤解が生じることが多いのです。それが発注者と受注者の間で大きなトラブルの原因になります。
例えば,要求を出す側は「得意先」とは○○電器だと思っており,受ける側では「得意先」を店舗だと思っていると,誤ったシステムになってしまいます。「売上」では,サンプル提供や返品をどう取扱うのかが明確でないと,誤った納品書や請求書になってしまいます。
また,現状業務の確認や将来の改善について,ベンダが担当部門の担当者にヒアリングをします。このとき,経理部門では「倉庫」,流通部門は「デポ」という異なった用語で説明すると,ベンダがそれぞれ異なる概念だと誤認することにもなります。
逆にいえば,用語の標準化が社内で徹底されており,用語定義集として文書化されているならば,ベンダもその定義で用語を用いるので,つまらない誤解を防ぐことができます。そして,要求分析の時間がかなり短縮されるので,システム開発の期間短縮や費用削減に効果があります。
個々の処理で「売上」の意味が異なったり,「支店」に本社販売部門を含むかどうかがあいまいだったりすると,「支店別売上一覧表と商品別売上一覧表の合計が一致しない」というようなことが発生します。個々の帳票に「売上」や「支店」の定義を表示することはしないので,その事情を知らない人は「コンピュータはあてにならない」という不信になることもあります。しかも,誤った解釈をされて重要な意思決定を誤らせることすらあります。
一般にこのような配慮が欠けていることが多いのです。後述の標準化へのアプローチで,既存の帳票類から項目を列挙する場合,帳票項目の定義を再確認することが必要です。
経営環境は激変しますので,情報システムへの改訂要求は頻発します。改訂作業では,改訂対象となるプログラムの特定,プログラム内の改訂個所の特定,改訂後の確認作業などがあります。そのときに用語が標準化してあれば,比較的簡単に修正個所の特定ができますが,あるプログラムでは「倉庫」,他のプログラムでは「デポ」としているのでは,探すのに多くの労力を費やしてしまいます。
利用部門の人たちが,公開されたファイルから任意な切り口で検索加工する利用形態を情報検索系システムといいます。そのとき,売上ファイルでの項目では「得意先コード」なのに,マスタファイルは「得意先マスタ」ではなく「顧客マスタ」であり,顧客名称項目が「名称1」(フルネーム)「名称2」(略称)だというのでは,利用者は戸惑ってしまいます。
また,売上の意味がわからないと「出力情報の整合性」で述べたようなトラブルが発生します。特に情報検索系システムでは,情報システム部門が知らない環境で,多様な人が多様な処理を行うので,このトラブルはさらに深刻なものになります。
このようなトラブルを避けるためにも,用語の標準化が必要です。そもそもホモニムやシノニムが多く存在するのは,業務の標準化ができていないこと,縦割り組織になっており部門間の連携が不十分なことの証拠だといえます。
そのような環境では,効果的な情報システムを構築することは困難です。むしろ業務改革の第一歩として,用語の標準化を進めることが必要です。
標準化のアプローチは,大きく帰納的アプローチと演繹的アプローチに分けられます。
既存の帳票類や現行の情報システムを調べて,個々の項目について,用語とその定義を再見直しするアプローチです。わかりやすく着手しやすいので,まずこれを行うのが通常です。
例えば,売上,出荷,転送などを個々に取扱うのではなく,モノの動きという上位概念で把握して,例えば(これに「仕入」を加えることもできます),
社外への流出 代金を伴うもの(売上) 伴わないもの (見本提供など) 社内での移動 管理単位間移動(支店間での移動など) 管理単位内移動(工場内置場間の移動など) 社外からの流入 代金を伴うもの(買戻しなど) 伴わないもの (返品など) 保管中増減のように,論理的に分解していくアプローチです。
このアプローチは,
どちらかのアプローチの一方で行うではなく,まず帰納的アプローチで項目名を列挙し,それらを眺めてを行い,それを帰納的アプローチで確認するというように,両者を組み合わせて行うのが適切です。
ここまでは「売上」や「得意先」のことを「用語」と呼んでいましたが,ここからは情報システム用語に合わせて「項目」ということにします(エンティティとか属性ということもあります)。
項目は次のように区分できます。
帰納的アプローチや演繹的アプローチを進めながら,用語定義集とでもいうべき項目辞書(項目一覧表)を作成します。それには,次のような内容を記入します。当面は Excel文書でよいでしょうが,将来的にはデータベース化して社内の誰もが参照できるようにする必要があります。
外部項目名(日本語での名称。帳票での項目,日常業務でも共通語とする) 内部項目名(プログラムやデータベースなどコンピュータでの名称) 型(数値桁数,マスタファイルの有無など) 定義(業務,利用者からの視点で説明。例外に留意) コード項目ならばコード体系 創成・更新・削除のトリガーとタイミング 上位項目(納入先であれば得意先や府県など) 創成・更新・削除を行う業務機能(「受注業務」や「請求書発行業務」など) その管理部門(業務担当部門)
例えば,得意先(○○電器)には,いくつかの納入先(△△店舗や□□店舗)があり,各店舗は唯一の得意先に属するという1:Nの関連があるとき,得意先を上位項目(親),納入先を下位項目(子)といいます。もし,府県別集計をするとき,店舗の存在する府県を用いるのであれば,府県が店舗の上位項目になります。すなわち,下位項目を(「△△店舗」と)特定すれば,一意的に定まる項目(得意先や府県)を上位項目といいます。
これらの項目の名称が,得意先コードがtokui-code,商品コードがshouhin,得意先名称がkokyakuname,商品名称がsyohin_nなどとバラバラなのは不都合です。また,商品には名称があるのに,商品区分には区分名がないというのも,利用者にとって不便です。体系的な項目の命名基準を設定するべきです。
その基準は,自社のこれまでの慣習,業界での慣習に従うのが適切です。また内部項目名では利用するOSや言語による制約もあります。それで一概にはいえないのですが,一例を示します。
コード項目の例 得意先コード tokui (コードを代表とする) 得意先名(正式名称) tokui_n (名称にはnをつける) 得意先略称 tokui_r (社内資料などに用います) 得意先カナ tokui_k (これがあると便利です) コード項目は原則としてこれらの項目を持たせる (略称やカナは不要なこともある)。 得意先マスタファイルを tokui とするようにコード名とファイル名を一致させる。 年月日項目 得意先取引開始年月日を tokui_kaishi_ymd のように最後を ymd とする。 年なら y ,年月なら ym とする。 数量,金額など計算項目 これは同じような項目が非常に多いので基準化することが困難である。 これが明確でないとトラブルの原因にもなるし,複雑にすると使い勝手が悪くなる。
得意先や商品などにはコードをつけますが,そのコード体系が適切でないと,使いにくいものになってしまいます。
スーパーやコンビニなどで扱っている商品の大部分にはJANコードというバーコードがついています。府県では,北海道=01,青森=02,・・・,沖縄=47がJISで定められています。自社で特別な理由がない限り,このような標準コードを採用するのが適切です。
これに合わせておけば,他社とのデータ交換では,データの変換をしないで済むことが多くなりますし,市販のソフトを利用する場合では,これが標準仕様になっていることもあります。
一般に表示順序はコードの昇順になりますが,出力帳票や画面の表示順序が社内での慣習に合っていないと使いにくいものです。
また,データを選択・集計するときに,コードの範囲で指定できると便利です。それで,1桁目を大区分,2桁目を小区分というように,コードの桁に意味を持たせると便利です。
しかし,あまりこれにこだわると,桁数が大きくなって使いにくくなります。ある部分のデータが多くなり000から999までを使い切ってしまい体系が崩れることになると,かえってわかりくいものになります。選択や集計のキーは商品区分のような項目を設定すればよいのです。
例えば社員番号を「所属部門+役職+通し番号」とすると,人事異動や昇格などがあるたびにコードの付け替えが必要になりますし,人事記録のような継続した情報を取扱うのが困難になります。「入社年+通し番号」のように,状況が変化しても変更する必要のない体系にするのが適切です。
いくつかの項目を持つデータをレコードといい,そのレコードをまとめたものがファイルです。これから情報化を進めるのですから,この時点でファイルのことを持ち出すのは時期尚早だと思われるかもしれませんが,そうではないのです。
売上ファイルのように,取引が発生するたびにデータが発生するファイルのことをトランザクションファイルといいます。
それに対して,得意先や商品は,新しい得意先との取引が発生したり,商品の取り扱いをやめたとき以外では,あまり変化がありません。手作業の時代でも,得意先台帳や商品台帳がありましたが,それに相当するのがファイルをマスタファイルです。得意先マスタや商品マスタなどといいます。
売上ファイルには,得意先コードや商品コードを項目として持ちますが,得意先名称や得意先住所,商品名称や商品区分などは項目にしません。それらはマスタファイルに持たせます。入力のときに得意先や商品が登録されているかどうか(入力ミスがないか)は,得意先マスタや商品マスタをチェックすれば可能です。また,商品区分別一覧表を出力するときには,売上ファイルと商品マスタを組み合わせればよいことになります。
それぞれのファイルにどのような項目が必要かは,ある程度常識的に列挙できます。
例えば,得意先マスタでは,当然キーとなる得意先コードが必要です。そして,そのキーとなる項目が決まれば自動的に決まる項目である得意先名,得意先住所,得意先区分,取引開始年月日などが列挙できます。得意先区分も業種で区分したり,過去の取引でのランク付けをしたり,例外的な処理が必要なこともあります。それで,「業種コード」「取引ランク」「例外区分」などの項目が必要であることがわかります。商品マスタでは,もしどの得意先にも同一価格で取引をするのであれば「単価」を項目として持つことになりますし,仕入先が商品ごとに唯一に決まっているのであれば「仕入先コード」を持つことになります。
システムへの要件では,「得意先区分別・商品区分別の売上数量集計表がほしい」というような出力情報に関係するニーズが多くあります。売上ファイルに得意先コード,商品コード,売上数量の項目があり,得意先マスタに得意先コード,得意先区分,商品マスタに商品コードと商品区分の項目があれば(注),適当な手段(それはここでは問題としません)により,この集計表が得られることは理解できるでしょう。
(注)ファイルに含まれる項目を示すのに,次のような表現をすると便利です。
売上ファイル=得意先コード+商品コード+売上数量+・・・
得意先マスタ=得意先コード+得意先区分+・・・
商品マスタ=商品コード+商品区分+・・・
このように,必要となる出力帳票を列挙して,それにはどのようなファイルが必要で,それらのファイルが持つべき項目を設定します。
項目辞書と同様に「ファイル辞書」を作成します。その内容は次のようなものになります。
未だシステムができていないのですから,ここでのファイルとは仮想のものです。しかし,これが整備されていると,システム開発が非常に容易になります。
ここで示したファイル群を作成すれば,必要な情報が入手できることになります。すなわち,極端にいえば,情報システムとはこれらのファイル群を作成し維持する仕組みであるともいえます。
「定義・解説」と「創成・更新・削除のトリガーとタイミング」を慎重に分析すれば,情報システムの(データとしての)仕様が理解できるはずです。このファイル辞書が矛盾のない完璧なものであれば,これだけでも十分なくらいです。
ここまでは「情報そのもの」に関する観点でしたが,情報システムでは,その情報をどのように収集するのかというプロセスの観点も必要です。また,情報システムが業務の仕方を規制します。逆にいえば,優れた業務の仕方にするには,それに合致した情報システムにする必要があります。
横軸に項目,縦軸にファイルと業務機能を並べた表を作ります。ファイルが持つ項目に「○」を付けます。そして,業務が創成する項目には「C」,入力する項目に「I」,参照する項目に「U」の記号をつけます。これにより,どのファイルのどの項目がどの業務で入力され,どの業務で参照されるのかがわかります。
現実には巨大な表になり作成は困難ですが,観念的なものと考えてください。
業務機能とは受注業務とか請求書発行業務のようなものです。それらの業務は営業部や経理部のような組織が担当しています。業務機能と組織は似ていますが,業務は論理的なものですし組織は物理的なものです。ここであえて組織ではなく業務としたのは,次の理由があるからです。
しかし,業務機能と組織とは密着に関係しており,組織を改訂することが情報化の効果を得るのに大きな要因であることが多いので,その対応表を作ることも必要です。
業務機能をどの程度まで分解するかは,最終的には画面入力のレベルまで分解することになりますが,当初からそこまで詳細にするのは困難かもしれません。当面は「受注」や「請求書発行」程度で十分です。
「項目と業務機能の対応表」までの検討により,ファイルの作成・維持を行う論理がわかりますが,これだけでは,受注業務をしてから在庫引当が行われるというような各業務の前後関係がわかりません。動的なプロセスとして,業務間でのデータの流れを示す必要があります。
その記述方式としては,最近急速に普及してきたUMLのなかのユースケース図(業務機能全般を記述)やアクティビティ図(業務機能間でのプロセスの流れを記述)が適当でしょう。この図法を理解しておくと,ベンダとのコミュニケーションが円滑になります。
これらの正確な図を作成するのにはそれなりの訓練が必要ですが,私たちはあくまでも素人なのですから,あまり規則にとらわれず,記述しにくいところは文章で補足することにして,わかりやすい図にする程度でよいでしょう。
業務機能と組織を対比することにより,現状の組織の問題点と改善の方向が見つけられます。例えば,
このような事前作業の意義や進め方について,重要な事項を列挙します。「項目」に限定した表現になっていますが,「ファイル」や「プロセス」についても同様です。
項目の標準化は,自社独自の事項ですので,自社がやらなければなりません。コンサルタントやベンダに依頼しても,自社の説明を聞いてまとめるだけのことですから,大した効果は得られません。
またこれを行うのに,特に情報関連知識を必要としません。簡単な手ほどきを受ければ,誰でも容易に理解でき実施できます。
項目の標準化は情報化を検討するのにあたり重要なことですが,情報化には関係なく行うべきことなのです。そもそもホモニムやシノニムが多くあることは,個々の業務が統制なしに行われてきたことが原因です。標準化をすることは,業務の見直しをすることにもつながることを認識するべきです。その観点から,全社的な業務改善・改革運動の一環として進めることが大切です。
とかく「辞書は作ったが,誰も見ていない」ような状況になりがちですが,それでは存在しないのと同じです。「この概念にはこの用語だけを使う。この用語はこの概念だけにしか使わない」ことを徹底周知させるために,情報関係だけでなく一般の社内共通語としての位置づけにすることが必要です。
それには,これらの設定に各部門から参加して草案を作り,それを全社に示して意見を募り改訂するといった,全員参加の運動にするのが適切です。
用語の統一というと簡単なように思われますが,実際にはかなり労力がかかるものだし,定義や上位項目などを厳密に記述しようとすると,なかなか難しいことがわかります。それで,ちょっと手がけてみたのだが途中で挫折してしまうことが多いのです。
むしろ,あまり厳密なことにはこだわらないで,「とりあえず」暫定的であっても記入していき,逐次改善するのが適切です。
半永久的な作業だといってもよいでしょう。ですから,当初はプロジェクトチームとして全般の骨組みを作成し,ある程度まで進んだら,定期的な見直しをする委員会にするといった体制作りをするべきです。