企業内のシステムにパッケージソフトを導入して、いろいろなことをさせようとするのは良くあることです。会計計算用のソフトなど、店で売っているようなものではなく、例えばSAPのような大規模なソフトについてのことです。

こういうパッケージソフトを使用することは新しいものを全く一から構築するよりも効率的でしょう。でも、勘違いしやすいのが、そのパッケージソフトを買ったら、ソフトもメーカーが、こちらでちゃんと使えるようにあとはやってくれるだろう、なんて思ってしまうことです。

システム構築の上で難しいのは、ソフトメーカーが行うことよりも、受け入れる側が準備しなければいけないもろもろの仕事にあります。大抵の会社は社内の伝票にその会社独特のものを使ってたりします。また、仕事の仕方も古いシステムの合うようなものだったりします。

システムを変更するためには、今までの伝票類、仕事のやり方全てを見直す必要が出てきます。また、これらを一切、見直さないというのも、一つの判断ですが、それはそれで、社内の合意を取り付けるのに苦労したりします。

高いお金を払って、システムを構築しようとしても、ソフトメーカーは結局はこちらからいろいろな指示を出し、具体的な資料を出さないと何もやってくれません。受け入れ側にそのシステムが対応する関連業務全般について、熟知しているかその関連部署に言うことを聞かせるだけの人がいないと、システムの開発は袋小路に入っていってしまいます。

ソフト開発費用というのは人件費です。開発期間中、ソフトメーカーは顧客に人員を派遣しますが、大手だと、１か月に一人当たり、２００万、３００万という費用を請求されることもあります。

そういう人間が顧客の指示を待って長期間ブラブラしているということも起こりかねません。

コンピューターで扱うデータは正確でなければなりません。また、抜けがないようにする必要があります。

生産管理システムなどの場合、この必要なデータをどうやって入手するか、というのが難しい問題になる場合が多いです。

例えば、自動化されていない生産ラインで、加工品の進捗管理をするシステムの場合、ある加工場所に到着した時、出発した時に計算機に情報を上げる必要が出てきます。その為、人が加工品に取り付けられているタグやバーコードの情報を読み取る必要が出てきます。それが面倒ならば、自動で読み取れるように機器を改造する必要が出てきます。この時、加工時間が非常に短いものの場合には、この読み取り時間の追加による生産性の低下が問題になったりします。

人手によるデータ入力の場合には明らかにその時間が新たに必要になるわけですから生産性は下がってしまいます。その今までやっていなかった作業を新たに追加してまでやる価値があるのかどうかを判断しなければなりません。

有力なソフトウェアは海外メーカーのものが多いです。その為、日本国内で販売するためには、日本語化対応の処置をしなければなりません。そして、国内の販売価格は外国での販売価格の３割増しぐらいになっています。

外国のソフトは日本語が使えない、と思っている方が多いのでは無いかと思いますが、そんなことはありません。表示がみんな英語のソフトでも、日本語の入力は普通にできます。よって、日本人向けの日本語の資料、図面を作成することはできます。

表示自体は日本語化できない場合が多いですが、英語版は元々多言語対応になっているものが多く、日本語にも対応しているものがあります。高額なソフトを購入される際には、日本語にも対応している英語版ソフトも調べられてはいかがでしょうか。

私が新入社員として入った会社は、ＱＣサークル活動が盛んでした。自動車部品メーカーだったこともあり、トヨタ自動車などの指導もあったと思えます。

しかし、最近はあまりQCサークルのはなしは聞かなくなりました。ＱＣサークルは定時後に、自主的に行う活動とされていましたが、定時後のＱＣサークル活動に対して残業代を支払わない7のは、違法であるとの、判決が出て、一気に白けてしまった感じがします。

また、海外でも日本のＱＣサークルに似た活動がいろいろ行われていて、世界的にみれば、そちらの方がメジャーだったりします。

ＱＣサークル活動を行う上での基本的な方法というのは、仕事全般に適用できるものでそれを新入社員の頃に教えてもえない、というのは非常にもったいないことだと思います。

昔は、ＱＣサークル活動等で、問題発生時の対応のしかたというものに、社内で一定の共通認識が
がありました。

それは、やり方の問題点を改善し、人は責めない、ということでした。
最近は、そういうことは共通認識としてはありません。

合併時のシステム統合の悪い例として有名なのが、みずほ銀行発足時のシステム統合です。各社のシステムをそのままににして、統合前の各社のシステムのデータを変換するようなシステムを作って対応しました。その結果、余計な処理が増えて計算機の負荷が増大し、数々の重大なトラブルを引き起こしました。

私も以前企業、在籍していた企業の合併時のシステム統合の様子を見てきました。最初は、合併前のシステムを廃棄して、新たなシステムに乗り換えようとしていましたが、結局は、従来のシステムを完全に廃棄することができず、他に中途半端なシステムがもう一つできて、何だか訳の判らないような状況になってしまいました。同じような働きをするいろんなシステムがあって、社内のシステムの全体を把握している人間は誰も居なかったのではないか、と思っています。

　システム統合を阻んだ最大の問題は、合併した２社の製品の番号体系の違いでした。しかし、製品の番号体系を統一することは、顧客にも影響することなので、システム部門だけではなく、会社全体で対応すべき問題でしたが、システム関係の課長に丸投げされて、進展していきませんでした。

計算機に入力するデータが信頼できるもの、例えば、データベース中の製品のデータなどの場合には問題がないのですが、人が手で打ち込んだようなデータの場合には入力ミスがどうしても避けられません。その場合、計算機がエラーとして跳ねてしまったり、間違って解釈して、誤った指示を出したりしかねません。

その為、そういうデータを発見したら、そのデータに関係する作業を中止させ、データの修正をしなければならなくなります。関係者に連絡を取って、適切な処置を依頼するような作業が必要になりますから、監視員をつけておく必要があります。

計算機というのは、主にデータの箱として使用するものと、複雑なロジックが売りのものがあるような気がします。

データの箱として使用する場合、データの構成をどうするかで、処理速度が大幅に変わってきます。

メンテナンスしやすく、判りやすいように、きれいな形でデータベースを作っても、処理速度が遅くなってしまって、少しでも処理速度を上げようと、試行錯誤しているうちに、データベースの構造が複雑なものになってしまうこともあります。

複雑なロジックが売りのシステムでは、肝腎の部分がブラックボックス化されていたりします。昔、担当していたＳＣＭ関係のシステムは、中核の部分がＩＢＭ製でブラックボックス化しており、手を加えることができませんでした。複数のシステムから情報をもらい、あるロジックに基づいて処理します。そこでは、データベースの構造などではなく、どういう計算式を使うかが問題になってきます。