先輩からの教訓
部品総合販売会社の情報システム部門に属する SE の A 君は今、入社当時に先輩諸氏からしつこいほど言い含められた教訓を身に染みて味わっている。
「コンピュータシステムで業務機能を実現するとき、その正確性は当然のこととして、要する時間、いわゆる性能を忘れるな」
CPU 性能、ディスク性能、通信性能が昔に比べて 10 倍にも 100 倍にも向上している現在、ソフトウェア開発部門では、ほとんど死語と考えていたこの“性能”が突然、 A 君の前によみがえったのである。
今回、 A 君をリーダーとする情報処理システム部門では業務遂行の電子化と情報の高度活用を目ざしたクライアント / サーバーシステム ( CSS ) を設計し構築した。この CSS ではすでにメインフレームで実現している基幹システム 「販売総合管理システム」の情報の多目的利用とグループウェアやワークフローの導入による業務の効率化、ペーパーレス化を図ることが目的である。
A 君達は出来うる限りアプリケーション開発を避けるよう商用技術ベースの構築を推進した。ハードウェアの選定と LAN の構築によるインフラづくり、データベース ( DB ) や通信などの業界標準ミドルウェアの採用、さらにグループウェアやワークフローについては勢揃いしている各社メーカの商用パッケージを決定すれば良い。これによりシステムは選定とインストール及びチューニングで完成するはずである。
現実には現場への説明の過程でパーケージのサポートしていない要望が出され慌てはしたが、公開されているパッケージのデータ構造から A 君の部隊でアプリケーション開発することで対処することとした。
システム構築にあたって性能については特に無視した訳ではなく、メーカ提示のベンチマーク結果や各種デモを通じての応答性能を見る形で評価したつもりである。
突然の性能低下
しかしシステムは失敗したのである。
当初の 1 〜 2 ヶ月は社員の興味も加わり順調のうちにスタートできた。日報 / 週報や個人スケジュール、顧客情報共有化などの電子化を目ざした会社制度の改変も打ち出され、現場の習熟度も向上した。
3 ヶ月目ごろから急激な性能低下が発生しはじめた。クライアント PC への応答が通常でも 3 分、運用が集中する夕方には 10 分かかることも珍しくなくなった。運用してみた結果の改善要求も頻繁である。
しかも各部門の情報価値の違いからくる運用のアンバランスで情報の不整合が生じほとんど手がつけられない状況である。現場からの日増しの強いクレームとトップからの痛いほどの不信感を背に、毎日が身の縮む思いである。
OS 、 GUI 、データベースアクセスツール、通信、パッケージなど肝心な部分は他社商用製品で、自分達で作ったものなどほとんどない。データベースチューニングもほぼ限界である。何をどう調べればいいのか。メーカは売ってしまったものには冷淡であり、著作権に守られた商用製品のソースリストを取り寄せることもままならず。何を、どう改善するのか、ほとんどパニック状態である。
状況を探る
情報システム部では A 君をリーダーとする特別プロジェクトを編成し、性能低下原因究明に着手することとした。冷静さを取り戻した A 君は性能低下の原点である、
・データ量 ・負荷 ・処理のしくみ
の点から次の方法でアプローチすることとした。
| 各現場でよく利用する業務処理機能をピックアップする（ヒアリングとアンケート）。 | |
| 業務処理機能個々の性能を、データベースのデータ量を変動させつつ評価する。 | |
| 業務処理機能の相性の点からいくつかを組み合わせて、同時走行して性能を評価する。 | |
| 負荷（同時に利用するクライアント数）とデータ量を変動させ、各クライアントの性能を評価する。 |
運用時間外となる深夜や休日しかも現場部門の有志の協力を得て調査した結果、次のことが判明した。
| 単一の処理機能でも、データ量がある一定以上を越えると極端に性能が低下するケースが多々ある。 ・・ある業務アプリケーションではデータ量が２倍になると応答性能が10倍も費やされる。 |
|
| ある業務処理機能が複数動作すると排他制御の関係で極端に性能が低下する。 | |
| 同時利用のクライアントが一定数を越えると性能低下が著しくなる。これにデータ量の増大が加わると、とても運用できるシステムとは呼べない状況となる。 |
皆が良く利用すると言えばそれまでだが、オープン化、クライアント・サーバー、汎用パッケージ、 RDB 、グループウェアという 「新しい波に乗り遅れるな」のメーカの言われるままのシステム構築、あればいい式の PC クライアントの増設や情報の電子化、現場に言われるままに作成した効率の悪いアプリケーションソフト群、実状からくる改善や改良がほとんど無理なパーケージ、さらに無秩序な運用体系も加わりシステムを目前にして A 君は何か大きな読み違いを痛感せずにはいられなかった。
失敗の原因
今回のシステムは、事務作業の効率化、ペーパーレス化、情報の電子化というおおまかな目的で出発したシステムである。
具体的に何をどれだけシステム化するかは現場ヒアリング主導で進めた。
しかしこの現場ヒアリングがくせもので部門の論理先行、思いつき、あれもこれもが声高々に発せられる。
この手のシステムは運用を積み重ねることにより本質が見えてどんどん成長、進化すべき現場主導型システムである。
あるべき姿をイメージしトップダウンで推進する基幹系システムとは根本的に違うのである。
現場主導型システムは最初からすべてを予測したパーフェクトなシステムを構築すること自体が無理、無意味なことであった。
システムコンセプトを明確にし業務に優先度を付け、できるもの、成果が見えやすいものからシステム化し運用しながら、そして効果や性能を確認しながらシステムを成長させるべきであった。
・・・小さく生み出し大きく育てる・・・このアプローチこそが重要であった。
この変化が激しい時代、変化を生み出すべき時代のシステムは 3 年先、 5 年先まで見通して一発勝負で仕上げることはコスト的にも業務遂行上も自分の首を絞めるようなものである。
解決のためのアプローチ
A 君は問題解決のために次の改善策を上司に答申した。
とりあえず現行システムで運用する業務を絞り込む。それ以外はシステムで運用しない。
そして新たに以下のコンセプトで新しいシステムを再構築する。
| 成長の妨げ、性能のネックとなっているグループウェア / ワークフローパッケージは利用を中止し業務機能はオープンソース製品あるいは自社開発で実現する。これによりシステムを可視化し、どんな成長にも対応できるようにする。 | |
| 主要な大規模部門 ( 営業部、調達部、運輸部など ) には、部門ローカルのサーバーを設置し、データ分散と負荷分散を図る。そのためのロイヤリティ契約を DB ベンダーと締結する。 | |
| 先端的でオープンソースに強く、システムを永続的に面倒見る IT パートナーを確保する。 | |
| 成果が確認できるしくみを取り込む ( 時間、コストなど ) 。 | |
| 運用を継続しながら今後の各部門の追加業務、改善及び運用体系を全社的にオーソライズするチームを社長直属で編成する。 |
幸いにも従来のコンピュータメーカや SI ベンダーとは異なるシステムの一生のソリューションをコンセプトとする先進的 IT パートナーも見つかりコラボレーションができた。
結果として新システムが動作するまでさらに 5 ヶ月を要したが、コストは以前の半分、今はスムーズに運用されている。
さらに皆で進化させるこの新システムがもたらした最大の成果は、各人が部門セクショナリズムから脱し業務遂行を会社全体で考えるようになったこと、新しい会社文化の誕生である。会社も一歩前進である。
A 君は今、個々人に眠る様々なノウハウ、ナレッジを組織知 ( 会社知 ) として顕在化させデータベース化してみんなで活用するナレッジコミュニティの導入を IT パートナーと企画中である。
いまの会社の雰囲気、文化から確かな手ごたえを感じている。