情報システム部門の最も重要な仕事は、ITの全社最適を実現することだ。では“全社最適”とは具体的にどういうことか。IT化にまつわる諸問題を例に、全社最適を実現する仕組み作りを考えよう。
JUAS(日本情報システム・ユーザー協会)の「ユーザ企業IT動向調査?2003年度版」の中で、IT部門の役割についてのアンケート結果に以下のようなデータがある。
|
|||||||||||||||||||||
表 JUAS「ユーザー企業IT動向調査」結果 |
Q1とQ3はどちらかといえば、個々のIT課題についての問題として「経営への貢献、業務課題解決への姿勢」ととらえることができる。この面でのユーザー部門の評価とIT部門の意識にはそれほどの差はない。気になるのはQ2についての両者の差である。つまり、IT部門自身が「統括機能としての役割を果たしている」と意識しているほどには、社内の他部門はそう思ってはいないということだ。IT部門でなくとも対処できるようなITにかかわる仕事は多々あるが、ITの“全社最適”は本社機能としてのIT部門にしかできない重要な仕事である。
さて「全社最適」とはどういうことであろうか?
社内のユーザーにとって、ITは自分の担当する仕事ではないから、日常的にITについて考えているわけではない。ユーザーが全社最適になっていないと感じるのは、どんな瞬間であろうか。
例えば、管理・統制の緩い企業では、こんなことが起こる。
人事異動で部署を変わると、コンピュータの機種やソフトが違うことがある。キーボードの配置やソフトのバージョンが異なるため、メニューの表現や表示の順序が違うだけでもまごつく。その結果、忙しい仕事の合間を縫って説明書を読んだり、周りの人に世話になったり、講習会に参加することになったりする。できることは変わらないのに手間が掛かるのは大迷惑だ。事業部門の人間は、自分の苦労を金額換算してみる。わが身と同じ立場の人の数を掛け算し、全社でいくらのコストに相当するかを試算してみる。そしてお金と手間の何という無駄遣いをやっていることかと、ぶぜんたる思いになるのだ。 ほかの例を挙げよう。ある管理部門のスタッフが、在庫の適正化のため部品や原材料在庫、半完成品在庫、製品在庫、流通在庫などをモノの流れに沿って検討してみた。しかし、購買・製造・販売などそれぞれの部門別に作られたタテ割りのシステムでは、品目コードや品目のくくりの整合性が取れていなかったり、データの把握のタイミングが統一されていなかったりなどの理由のため、コンピュータの中のデータがそのままでは使えないことがあった。「まだできないか」と矢のような催促をする上司に、コンピュータの中身についていくら説明しても理解してもらえなかった。このスタッフは、自分への批判の原因になったコンピュータをうらみ、「IT部門のやつらは何を考えているんだ」となった。
そのほか、広く投資・コスト評価にかかわる問題として、「他社のIT活用に比べ当社は……」といった疑問や、投資の優先度決定のプロセスに対する不満、情報セキュリティ問題が顕在化した場合に事前対策への不備などを感じるかもしれない。経営層は、投資効果に対する明確な手応えがが感じられないまま、この問題が放置されていることにいら立ちを感じている。……などなどが挙げられる。
一方、管理・統制が行き過ぎた企業ではどうであろうか。
ユーザー自身が、仕事に必要なソフトウェア/ハードウェアを苦労の末探し出して導入を検討したとする。しかしIT部門は「社内の標準のソフトにもその機能はあるはずだ」などとカタログに記載された能書きを示し、勝手に(?)決めた社内標準を盾に取り、導入を認めようとしない。あるいは「検討が必要」と称し、無為に時間だけがたっていく。
ユーザー部門は「自分の部門で導入すればすぐ大きな効果が出せたのに、邪魔をされた」と思う。次からは何か別の案件と一式にしてルール逃れをして実現してしまおうなどと考え始める。
あるいは逆に、IT部門の方から「当社の基幹業務はこのERPで行うから、業務をERPに合わせるように」などと無理難題を突き付けてくる。業態が違えば業務のやり方も異なるのは当然だ。ERPのような標準パッケージを使うと、自社の強みを発揮できなくなるリスクや、かえって日常業務の生産性を落とす可能性もあり得る。ユーザー部門は「こうしたことを考えてみたことはないのか」と不信感が募る。「なぜERPか」について聞いてみても、「会社の方針だ」などというだけで納得のいく説明はしてもらえない。
さらに、「技術標準」について考えてみよう。昨今、デスクトップPCやそのディスク容量、ノートPCのメーカー、サーバやPCのOS、データベース、メールソフト、……など、事細かく使用機器やソフトウェアについて社内標準を決める企業が増えてきている。適切な内容の技術標準は必要だし、有用だが、問題はその運用方法だ。
例えば、標準を決めながら事実上“なし崩し”になっている企業もある。その理由は「日進月歩の技術に追従するためだ」という。しかし、数多くの種類の機器やソフトを持てば、それなりに手間もコストも掛かる。「情報システム部門の人的資源は不十分」ということが普通なので、仕事量が増えれば必然的に業務の質の低下は否めない。また、ほかのもっと重要な仕事での機会損失も生じているかもしれない。こうまでして“最新”を追いかける必要性が本当にあるだろうか?
1年前に開発したシステムを、同じ目的でいまの技術で作れば経営上の“効果”は、何がどれほど違うであろうか。3年前のシステムならどうであろうか。こんな検討を粗くでもやってみれば、自社のビジネスにおける“最新技術の追求によるメリット”と“手間やコスト負担”のおおよそのバランス点の見当がつくと思う。時間をかけて「詳細に検討しないとその差が分からないというのは、差が少ないから分からない」ということが多い。自社の情報化はIT業界のスピードに合わす問題ではなく、自社のビジネスのスピードに合わせるべき問題である。
事業形態や、業務プロセスに抜本的な変化を及ぼすような技術は、そう多くはない。技術の新しさや高度さと、業務上の効果との間にそれほどの相関性はないのだ。ユーザー企業が受けているIT技術進歩の最大の恩恵は“価格低下・コスト削減”である。
次に現実問題として、ソフトウェアのバージョン管理の問題、標準外の扱いの問題を考えてみよう。ものによる違いはあっても、手持ちのバージョンが1つ増えれば数割の負担増が発生する。未来永劫バージョンアップはしないというわけにもいかないだろうから、新旧2つのバージョンの存在は仕方がない。バージョンアップ作業負荷の平滑化やコストの問題、切り替えのリスクを考えると、現実問題として新旧2本立ては積極的に認め、その上での運用やサポート体制を考える方が良いように思う。
しかし、3バージョン併存ならどうであろうか。4バージョンになれば標準化は明らかに形骸化状態である。線引きをどこにするかを明確にしておかなければならない。この線を越えた場合には強制的にバージョンアップを迫ることも必要になる。
このシリーズの第2回で「責任と権限」のバランスについて述べてきた。技術標準の問題でいえば、情報システム部門はユーザーに対して「ルール順守を求める権限」があるのに対し、ルールを守る人に対する「十分なサポート・サービス」という責任がある。このバランスが崩れれば、標準化のルールは機能しなくなる。
「十分なサポートもできず、問題があってもほったらかし。結局自分たちで解決しないといけない。それなら最初から自分たちの好きなようにやらせてくれ」と、ユーザー部門に思われないように体制を整えておかなければならない。
そこで標準でないものを使いたいというケースには、「その必要性と効果を明確にすること」と、「標準と同じレベルのサポート・サービスはできない」ことを、ルールとして明示しておくことが大切である。非標準=例外ではないのである。
特にデザインなどアートや研究・技術などの専門分野では、その目的に作られた専門システムを使った場合と汎用システムを使った場合とでは、生産性や仕事への意欲、ひいては仕事の結果に大きな差が生じることがよくある。カタログ上の機能の机上比較で判断し切れる問題ではない。相手はコストより効果、仕事の量より質を重視すべき分野の人たちである。また、将来に変更や拡張の考えられないシステム専用に、非標準になった古いが枯れた(安定した)バージョンを使い続けるという選択もある。
加えて、セキュリティの技術的な仕組みや、ネットワークの構成規準・接続条件を技術標準として決めておく必要がある。この分野は一般ユーザーが介入しにくい分野ではあるが、特に厳格なルールの設定と運用が必要だ。ここでは一切の妥協は無用、強い強制力の行使が必要である。効率性と安全性のバランスに見識が求められる問題である。
しかし現実は、立派なセキュリティ・ポリシーやルール書はできたが、その施策の実施になかなか社内の理解が得られない、お金が出ない、運用面での徹底ができていない、……といった悩みを訴える企業も多い。
ネットワークサービスの単価は年々低下している。「ネットワークの置き換え時に、丼勘定でもいいからセキュリティ対策をやってしまおう」という方向もある。またネットワークのセキュリティ標準があるならば、新ネットワークはこの標準に基づいてやるのが当然という理屈も成り立つ。
あるいは不幸にして、身近でセキュリティ上の問題が起こったとしよう。そこで、後始末をしてほっとしていては駄目である。この問題を社内に啓蒙する絶好のチャンスとして、針小棒大にでもPRし、皆が不安になっている間にやるべきことをやってしまうぐらいの作戦は考えておこう。温めた具体的なプランを懐に、機会は絶対に逃さないようにしよう。セキュリティは“のど元過ぎれば熱さを忘れる”問題である。事が起こってから策を考えるようでは間に合わないのだ。
ここまでは主に、対ユーザー部門の問題として述べてきた。標準を決めながら事実上なし崩しになっているケースの中には、個々のシステム開発をSIベンダに丸投げの結果として生じている場合も少なくない。
ベンダにとっては、1つのシステム開発プロジェクトが商売の単位であるし、そもそも「全体最適」などという問題認識のできない立場にいる。そんなベンダに全部任せてしまえば、自分にとって都合の良い道具立てでやろうとするのが当然だ。モノ作りの専門家にすぎないベンダに、この問題の判断に委ねるようなことがあってはならない。「全体最適を考えてシステムを構築してほしい」と一言いったぐらいでやってくれるなどと甘い期待は一切しないことだ。
技術標準はユーザー企業が自ら設定・管理し、ベンダに対しては厳しく順守を要求すべき問題である。それがユーザー企業のIT部門の重要な責任だ。
このようなシステムごとの発注・開発形態の結果、バラバラの道具立てになってしまっている。そこから発生しているコスト(TCO)は無視できないレベルになっている可能性が高い。そしてそれ以上に、このようなタテ割りのシステム開発の結果、システム間のデータの不整合性が発生し、それに起因する将来の機会損失が懸念される(この問題については次回以降に述べる)。
それにしても、最近の教科書にある「RFP(提案依頼書・システム仕様/定義書)をユーザー企業が作り、数社に競争提案させて……」という案は、現実的な方策なのだろうか。筆者としては、その前にやるべきことがあると考えている。具体的には、倫理感と管理能力を高めてもたれ合いを排する仕組みを築くこと。そして価値観が共有できて信頼が置ける、限られた取引先と長期に付き合っていく方が、全体としてはるかに良い結果が得られるように思う。
では現在、機器やソフトなど、技術インフラがバラバラになってしまっているところはどうすればよいだろうか。このような状況になっている場合、現実問題として短期に是正することは困難であろう。3?5年の中期問題として解決する方策を考えてみる。
まず最初に、“技術標準”を中期の収束目標として位置付けること。標準がいまだに作られていない企業は、現状および中期の自社のIT化を展望してみて、とにかく標準を短期間で作り上げる。時間をかければ理想的なものができるわけではないし、そのうち新しい技術が出てきたりしていつまでたっても決められないといった状況に陥る。できるだけ短期で作ることが大切だ。
すでにルールがあったのに守られなかったところは、なぜ守られなかったかを分析することが特に重要だ。この原因を取り除かずに「やり直しましょう」といっても、ほとんどの場合、同じ結果に陥る。目的や考え方が関係者に十分理解され、実行が徹底されることが必要条件、つまり「運用」が鍵となる。担当者には、個別の要求を押させることができる理論武装と、個々の場合にどう判断するかの見識が求められる。マニュアル頼りというわけにはいかない。なお、標準は定期的に見直しすることが原則である。
標準のガイドラインができ、またうまくいかなかった問題点が確認できれば、次に現在バラバラのインフラが標準に統一された場合のメリットをできるだけ具体的に算出してみる(具体的というのは、精緻ということではなく、どのような面でどのようなメリットがどの程度出るかということで、精度は有効数字1.5ケタで十分)。次に、このメリットを頭に置きながら、具体的な中期の改善施策を考えてみる。
計画検討はこの順序でやることが大切である。そもそも技術標準化とは、全部が標準化されて初めてメリットが出る問題だ。しかし、全体の標準化を一度に実行することは現実問題として難しい。部分ごとに少しずつ標準に直す作業を進めていくことになる。このプロセスの途上では、標準に直すためのコストや手間は発生するが、標準と非標準がまだ混在した状態に変わりはないから、メリットは出ていない。全体(実際には全体の7?8割)が出来たところで、急にメリットが目に見えてくる(図1参照)。
このように、全体をとらえた計画が必須だ。計画検討段階でも、部分積み上げのアプローチでは、その途上ではメリットがなかなか見えず、検討作業そのものが挫折する可能性が高い。あるいは運良く実行に着手できても、実施途上で不安感から挫折する可能性が高くなる。
先述したように、その徹底度や運用方法は別として、技術標準を定めている企業は多い。これを一歩進めて、アプリケーションの目的や用途ごとに、機器やソフトの“組み合わせ方の標準”“機能の使い方の標準”を整理しておけば、個々のシステム設計の効率化や、設計者の個人差に基づくシステム構造の違いの排除、これを通じた品質の安定化や、操作の分かりやすさにつながり、結果的に運用管理や保守面にも効果が期待できる。例えば「こういう目的でこうしたことをやる場合には、××ソフトのこの機能と、○○ソフトの△△機能をこのように組み合わせて使う」というような具合だ。
モノ作りの生産性と品質の向上を同時に実現するためには部品数を減らすことが有効であり、自動車など組み立て産業では部品のモジュール化が進む。
別々のソフトウェア商品を物理的に1つのモジュールにできるわけではないが、組み合わせ方の標準、機能の使い方の標準というソフトなつながりでノウハウのモジュール化を考えてみるのはどうだろか。パッケージプログラムの利用、プログラムの部品化に加えた、“もう1つのモジュール化”である。
第4回で述べた機器やソフトの標準化の問題について、読者の方から「旧・新の2本が標準か?」といった趣旨のご質問をいただいた。「新規投資のための標準はあくまで1つが原則だが、ただし現実問題としてある期間は残ってしまう“旧”に対しても、運用上は標準と同様のサービスを維持しなければならない」というつもりが、誤解を与えた点があったようで、この点お詫びしたい。
さらに細かいことをいえば、OSを別のものに乗り換えるなど、同種の目的の製品を変える場合にはもう少し複雑なことになるが、ここは常識的にご判断お願いしたい。要は、製品でもバージョンでも新しいものを入れれば、古いものは意識的に整理していくということだ。一時的に負担やコストの掛かるが、長期的に見ればコストの低減につながることをご理解いただきたいというのが趣旨である。
公江 義隆(こうえ よしたか)
ITコーディネータ、情報処理技術者(特種)、情報システムコンサルタント(日本情報システム・ユーザー協会:JUAS)
元武田薬品情報システム部長、1999年12月定年退職後、ITSSP事業(経済産業省)、沖縄型産業振興プロジェクト(内閣府沖縄総合事務局経済産業部)、コンサルティング活動などを通じて中小企業のIT課題にかかわる
Copyright © ITmedia, Inc. All Rights Reserved.