シス開発：システム開発に役立つ様々な視点 |
ビジネス関連の情報システムを構築する場合、データベースを利用するのが一般的だ。しかし、情報システム化の対象を深く分析すると、データベースの利用が適さない業務もある。データベースを利用すべきかどうかは、対象業務をきちんと分析し、本当に適合する場合だけに限るべきである。
この問題を考える際には、業務改善と情報システムとの関係を考慮しなければならない。普通に考えると、情報システム化することイコール業務の改善だと思いがちである。確かに、情報システム化を進める初期の頃にはそうであった。システム化しやすい業務が対象となり、そのほとんどは同じ作業を繰り返すので、データベース化が適している。
ところが、情報システム化の範囲が広がるにつれ、同じ作業を繰り返さない業務も対象として検討される。そうなると、データベースが向かない作業も含まれる。もっとも適さないのは、作業の中身が常に変化し続ける仕事である。
ただし、こういった仕事がシステム化に向かないとは限らない。表計算ワークシートで作業し、利用者が自由に変更しながら使う方法で、対応できる業務も多い。表計算ワークシートの場合は、一般の人でも処理の様子が把握できるため、データベースよりは理解しやすく、自分で全部を作れることが多い。当然のことだが、ワークシートの式を作れる程度の能力は必要である。
以上のように、業務の内容をきちんと分析して、適切な方法で情報システムを構築しなければならない。ところが、仕事がほしいだけの業者だと、データベース化を大前提として考え、無理矢理にデータベースを使ってしまいがちだ。現実に存在したひどい業者の例だと「データ項目とキー項目さえ分かれば、簡単にデータベースが作れますよ。やっちゃいましょう」などと言って、強引に受注してしまう。業務分析をきちんとしてないため、出来上がったシステムは使いものにならず、開発費をドブに捨てる結果となってしまった。
仕事の内容を固定化できない業務では、無理してデータベース化すると、業務を変更できなくなる。必要だから変更するわけで、業務を進歩させるための要素でもある。その意味で、データベース化が業務の進歩を妨げているといえる。最悪の状況だ。
可能性だけを考えると、常に変化し続ける業務でもデータベースを利用可能だ。実現方法としては、変更可能な構造でシステムを作る方法と、常に変更し続ける方法の２種類がある。
変更可能な構造の場合、少しの変更に対応できるぐらいでは役立たない。もっと大きな変更に対応できるようにと、かなり凝った方法で実現する。具体的には、実データと一緒に定義データも持つ。そして処理内容を変更する際には、まず定義データを変更する。システムは、最新の定義データを参照しながら動作し、実データを入出および出力するわけだ。定義データを好きに変えることで、システムの機能を対応させようと言う仕組みである。
このまでの話を聞いただけで、システム構築の経験を持つ人なら、その大変さが理解できるだろう。システムの構造は複雑になり、開発自体がかなり難しい。利用可能な定義データの全部で正常に動くかどうか、テストするだけでも大変だ。おまけに、定義データで対処できない変更が発生したら、複雑なシステムを修正しなければならない。こんな仕組みなので、実際に作らないほうが賢明だろう。
もう１つは、システムを常に変更し続ける方法である。外部の業者だと応答が悪いので、内部に専任の担当者を置くしかない。また、システムの変更は時間がかかるため、優れた技術やツールを用いるのに加え、最新の設計技法で設計して、変更にかかる速度を上げる必要もある。そうなると、本当に優秀な技術者を抱える必要があり、コストが非常に高くつく。そのため、採算が合う業務でしか適さないだろう。一般の業務では無理である。現実には、期待したほど短時間でシステム変更が終わるわけではない。分析からテストという何段階の工程が必要で、どんなに優秀な技術者でさえある程度の時間がかかる。
どちらの方法も、あまり変更しないシステムよりは、トラブルが多く発生すると予測する。ソフトウェア開発の場合、非常に優秀な技術者でもミスをするし、急ぎの作業を求められるとミスはさらに増す。総合的に考えると、どちらの方法もデメリットが大きく、通常はやるべきでない。
情報システムが業務の進歩を邪魔する現象は、データベースに適した業務でも発生する。それは、一度構築したシステムが古くなって、現在求められている業務内容に合わなくなった場合だ。
たいていの組織では、情報システム化の候補業務がいくつもある。いくら要望が上がっても、システム開発に投入できる資源は限られていて、優先順位の高い業務しか対応できない。そうなると、業務内容に適さなくなっても放っておかれるシステムが出てしまう。
この問題だが、実はかなり前から存在していた。多くのバックログを抱える情報システム部門は、優先度の高いシステムだけをメンテナンスして、それ以外には手が回らない状況である。そうなると、古いまま取り残されたシステムでは、業務方法を改善しようと思っても、自分たちだけではどうにもならず、お手上げ状態だ。
業務が情報システムに深く依存しているほど、手作業だけを勝手に改良することはできない。システムと一緒に変更しなければ、効率的な運営は難しい。運が良ければ、手作業のほうだけ何とか工夫して改良できる場合もある。しかし、手作業側が無理なしわ寄せを受けるために、トラブルが発生しやすい。あくまで苦肉の策でしかない。
以上のように、一度構築した情報システムも、適切なメンテナンスをしないと、業務の進歩を邪魔する結果となってしまう。また、現在のように情報通信技術の発達によって仕事の方法が急激に変換する状況では、邪魔する可能性がさらに高まる。
では、以上のような問題をどのように解決すればよいのであろうか。実際、非常に難しい課題である。１つの有効な対処方法として、「利用者に多少の手間がかかってもよいから、利用者が自分で変更できる箇所を増やす」という考え方がある。この場合、変更が容易な機能を、“どの部分へ”“どのように”組み込むかを考えなければならない。
どのようにのほうは、既存のアプリケーションをできるだけ利用する。その中では表計算ソフトを用いるのが最適であろう。式を入力するだけで様々な計算ができるし、一覧表で整理したりソートしたり、グラフを描いたりも可能だ。こういった処理だけならプログラミングが不要なため、利用者が自分だけで作れる点が魅力となる。また、初心者向けのカード型データベースも、利用者が何とか使えれば、最低限の機能だけ利用する形で役立てられる。当然、プログラミングをしないのが大前提だ。
対象箇所の１つは、データの最終出力である。画面表示や印刷で、一覧表やグラフを自由に作ってもらう。昔は、データベースから必要なデータだけを抽出してファイルとして保存し、それをアプリケーションで加工していた。今では、ダイナミックにリンクできる仕組みが容易に作れるため、抽出条件の指定機能などを使いやすく仕上げて用意すれば、利用者にとって自由度が広がる。この部分は一般的になり、もはや目新しくない。
もう１つの対象箇所は、元データの入力である。主要データベースへ直接入力させる代わりに、表計算ソフトやカード型データベースなどで簡単に作ってしまう。その部分は業務に直結するため、利用部門が一番使いやすい形で作る。当然、全社的に見て重要でないデータも、数多く含んで構わない。
このような小さなシステムで得られたデータのうち、企業にとって重要なデータだけは、本格的な主要データベースへと登録する。その接続部分をきちんと作って、可能な限り自動化するのがミソだ。大変なのは表計算ソフトだが、重要なデータが入ったセルに重複しない名前を付けて、それを手がかりに抽出するプログラムを用意すればよい。その名前さえ変更しなければ、ワークシートを自由に変えてよいルールにしておく。こうすると、利用者が変更する自由度を制限しにくい。
主要データベースへ登録したデータを使って加工し、その結果を別な主要データベースへ戻すような処理でも、同様の考えで作れる。加工処理の部分だけユーザーが変更できるようにして、主要データベースとのデータの受け渡し部分だけきちんと用意すればよい。
どの方法でも、主要データベースへ入力する前のデータ検査だけは、かなり厳しくやるべきである。ただし、データ検査は、データの内容も業務に影響を受けやすい。部品タイプの値として新しい文字列が加わったとか、意外に多く起こるだろう。その点も考慮し、値の細かな検査に関しては、データベースへ簡単に登録できる方式とか、独立して入れ替えられる形での構築などが望ましい。
ここで紹介した方法は、基本的に基幹業務を対象としていない。基幹業務であれば、それなりに資金を投入して、どんどんと変更することができる。そこまで手間をかけられない業務が対象で、自由度を少しでも高めるための方法である。
以上のような方法は、あまりスマートな実現方法とは言えない。しかし、現在のシステム技術を用いる限り、きちっと作ったシステムを柔軟に変更するのは無理だ。技術が大きく進歩するまでは、ここで紹介したような方法による実現も仕方がないだろう。業務の進歩を妨げるよりは、ずっと良い。
ソフトウェア技術にとって期待の星であるオブジェクト指向も、こういった要望にはほとんど役立たない。あくまでプログラミングの改良技術の１つであり、その効果も劇的と言えるほどではない。今回のような改善対象には、別な新しい技術が必要だ。残念ながら、それはまだ登場していないようである。
ここで紹介した方法は、最初のシステム設計時に実現しておくのがベストだ。既にあるシステムでも、大きなシステム変更の機会に加えるとよい。それが無理なら、一部だけでも良いから少しずつ改良するしかない。
世の中の変化が大きい時代なので、業務の改善にもスピードが求められる。そんなときに情報システムがネックとならないよう、システム設計では十分に配慮したい。システム改良の速度向上という新しい時代の要求が、情報システムには加わったのだから。
（2000年６月５日）
業務の進歩を邪魔しない情報システムに |
