情報システムの開発において、利用部門が主体になって取り組む必要があるのは、要件の取りまとめのプロセスと、テスト・検収のプロセスですが、それに関しては別項にまわします。プログラミングなど情報システムの実装にかかるプロセスはベンダが行いますが、このプロセスでも利用部門が行わなければならない作業があります。しかも、これら作業は、ベンダ側の作業に先立って行う必要があります。
用語の統一
「自社の常識は他社の非常識」といいます。あまりにも当然なので要件として明記しなかったとか、互いに確認したことが、後になって全く誤解していたことがわかり、それが大きな手戻りになることがよくあります。
誤解の原因で最も大きく深刻なのが用語の違いです。
同じ名称なのに異なる意味を持つものをホモニム（同名異義語）といい、同じ意味なのに異なる名称を用いることをシノニム（異名同義語）といいます。このホモニムとシノニムがバベルの塔になり、要求での誤解を生んでいるのです。「売上」や「得意先」などは日常的に使われている用語であり、お互いに正しく理解しているつもりで作業を進めてしまうことが多いのです。
- 「売上」？
一般にはモノとカネの交換取引のことでしょうが、サンプルを無料で提供したときは、その数量は売上数量に入るのでしょうか？ 事業部制をとっているとき、事業部間での取引は売上に入るのでしょうか？
また、４月に１０個売り上げたのに、５月になってから何らかの事情により２個を買い戻した場合、４月の売上個数は１０個、５月の売上個数を－２個とするのでしょうか。それとも４月の売上を８個とするのでしょうか？ - 「出荷」？
モノの在庫移動に関する概念ですが、客先に出す以外に、社内の別の倉庫に移動することも含むのでしょうか？ - 「得意先」？
顧客である「量販店○○電器」には、＜△△店舗＞や＜□□店舗＞があり、商品は各店舗に納入し、代金は本社にまとめて請求するとします。そのとき、得意先とは本社と各店舗のどちらを指すのでしょうか？ - シノニムでの誤解
例えば、商品の購入者のことをＡさんは「顧客」といい、Ｂさんは「得意先」といいます。「取引先」「ユーザ」などという人もいいます。これを同じものだと理解できるでしょうか？ 「出荷」「移動」「デリバリー」などが同じ意味で用いられることもあります。
ホモニム・シノニムをなくすことは、単に発注者とベンダの誤解を減らすだけではありません。次のような観点でも重要なことなのです。
- 利用者とのヒューマンインタフェース
データ入力画面、帳票などの表示での項目名が、実業務での用語と異なると、誤入力をしたり、誤判断をしたりすることになります。また、社内利用では得意先名や商品名を正式なフルネームではなく、略名を使うほうが便利なことが多くあります。その略名についても統一する必要があります。これらは、データウェアハウスなどのＥＵＣには特に必要です。 - 実業務での部門間の壁
情報システム構築に必要なだけではありません。実業務でも誤解を生じているのです。もっと重要なことは、部門間で用語が異なるのは、部門間で業務の連携がなされていないことであり、企業での共通認識が欠けているからなのです。 - 合併時での勢力闘争
同じ業種・業態の企業が合併するとき、どちらの情報システムを残すかがパワーバランスの問題になります。情報システムは仕事の仕方を規制しますが、その情報システムの基盤になっているのが用語です。これまで用いてきた用語を捨てるのは、仕事の仕方も組織文化も捨てて相手の軍門に下ったように感じます。
業界・業務常識の誤解
- 業界慣習の誤解
自分の常識は他人の非常識なために、要求時に明示しなかったことが後になって大問題になることがあります。
Ａ社では、得意先からの注文に一括納品するよりも、生産した分を逐次納品することにしており、得意先もそれを歓迎しています。また、代金は注文時までには決まらないことが多く、納品後になっても交渉が続くことがあります。Ａ社の担当者は、販売とはそのようなものだと信じ切っています。 ところがベンダの担当者は注文書と納品書は１：１の対応になるし、納品書と請求書は同時に発行され請求書には金額が記載されるものと信じています。それで、このことについては確認しないままにシステム開発が開始されました。誤解に気づいたときには、データベースの設計からすべて振り出しに戻ることになりました。 - データ入力チェック
Ｂ社は証券会社です。ある担当者が１０万円の株を１株売るのを間違えて１円で１０万株売ると入力してしまい大騒ぎになりました。
ＧＩＧＯ（Garbage In, Garbage Out）という用語があります。間違ったデータを入力すると間違った出力になるという意味で使われます。手作業と異なり情報システムでは、いったんデータがコンピュータに入ると、その誤りをなかなか発見できません。しかも、その誤りが多くのファイルに波及するので、修正するのも困難になります。
それで、誤ったデータが入らないように、データ入力の段階で厳重なチェックを行うことが求められます。ところが、どの程度までチェックするかにより、プログラム開発工数が極端に変わります。また、数値の項目に文字が混入していないか程度の形式的なチェックをするのはベンダでも気づきますが、ある得意先からある商品を受注する数量は○○個から△△個の間だというような業務に密着しているチェックは、利用部門が指摘しないとわかりません。
コードとマスターファイルの作成
得意先名や商品名は一般に長く不定長で漢字や英字が混在しています。これでは取り扱いにくいので、情報システムでは数字列のコードを用いるのが一般的です。コードは、次のように用いられます。
- データ入力時でのコードの重要性
利用者が入力のたびにコード台帳を見ることはできません。主な得意先や商品のコードは利用者が暗記しておく必要があります。それにはコードの長さを短くし適切な体系になっている必要があります。
タイプミスをチェックするために、他のものと混同しない数値列にするとか、例えば各桁を加算した下１桁をコードにつける（チェックデジットという）などの工夫が必要です。 - 出力時でのコードの重要性
一般に売上一覧表などはコードの小さい順に出力されます。それが業務での慣習に一致していないと使いにくくなります。
商品を商品グループ別に集計するとき、商品コードの頭○桁が商品グループになっていると便利です。しかし、そのグループ分けが変更になるとか、多様なグループ化が必要な場合には、商品コードで対処するよりも、商品区分コードなどの項目を設定するほうが適切です。 - コード体系の維持
コードの付け替えはシステムの大規模改訂になるし、過去データの扱いが困難になるので、絶対に避けるべきです。例えば、ある商品が廃止になったので、そのコードを新しい商品に割り当てるのは困ります。それで、新しい商品が発生しても体系が崩れないようにコード体系を設定する必要があります。 - 他システムとの連携とコード
例えば、販売システムでの得意先と購買システムでの仕入先をまとめて相手先として統一したコードにしておけば、自社商品をどれだけ仕入先に販売しているかを調べるような、他システムと横串にした情報が得やすくなります。
他社とのデータ交換が多くなりました。例えば府県コードはＪＩＳになっているし、食品や日用雑貨にはＪＡＮコードがあります。できるだけこのような標準コードを用いるべきです。
例えば得意先マスターファイルは、販売システムでも会計システムでも用います。それぞれのシステムで個別の得意先マスターファイルを用いたのでは、更新が重ねられるうちに整合性を失いますので、可能な限り唯一の得意先マスターファイルにするべきです。そのために、得意先マスターファイルには住所や電話番号など当然な項目以外に、上得意などの得意先区分や信用限度など多様な項目を設定する必要があります。
マスターファイルはデータベースにするのが通常なので、項目の追加は比較的容易なのですが、それでも大きな変更はシステムに大きな影響を与えます。
コードは業務に密接に関係しているので、利用部門がコード体系を設定しコードづけをする必要があります。しかも、多くの部門が関係しているので、それらの部門が共同して作業するべきです。さらに、新商品などが発生したとき、担当者が勝手にコードをつけると体系が崩れてしまいます。それを防ぐために、全社的なコード管理組織が必要になります。マスターファイルについても同様です。
ところが、情報システム開発で、なかなかコードやマスターファイルが決まらないし、後になってから変更することが多いのです。それはシステム開発の費用や納期に大きな影響を与えます。