情報システム部門の戦略部門化とアウトソーシングアウトソーシング以前に利用部門の意識改革をアウトソーシングにより,利用部門が情報システムへの説明責任を持つことになります。直接にベンダーと取引する機会が多くなりますが,この業界の慣行は利用部門が一般に行ってきた慣行とはかなり異なります。利用部門が意識改革をしないと,アウトソーシングは大きなトラブルの原因になります。利用部門の当事者意識が要求される利用部門は情報システムの開発や改訂に関しては情報システム部門に要求し,情報システム部門がベンダーに発注するのが通常でした。利用部門とベンダーの間には情報システム部門が存在していたのです。開発や改訂の費用は,形式的には利用部門が予算化したり実際に要した費用を利用部門に配賦したりはしますが,実質的には予算の見積もりや運用は情報システム部門が行っていました。情報システムに関する責任という観点でも,情報システム部門がバッファになっていました。ところが,情報システム部門が戦略部門になり,日常的な業務をアウトソーシングすると,全社的な情報システムの管理はするものの,部門内のローカルな比較的小規模なシステムの開発や保守改訂は,利用部門が自主的に管理することになります。利用部門が実質的な予算管理をしたり,ベンダーと直接に取引をすることになります。それらを情報システム部門が行っていたのでは,「日常業務は戦略思考を駆逐する」ので,本来の意味での戦略部門には脱皮できません。経理部や購買部業務を兼務する企画部は存在できないのです。これまでは,ややもすれば利用部門は情報システムに関して要求はするが責任の矢面に立つことがない立場にありました。それが逆に戦略部門になった情報システム部門への説明責任を持つことになります。情報化投資は一般的な投資と比較して費用対効果の把握が困難であり,この業界の取引慣行はいわゆる日本的な商慣行とはかなり異なっています。そのためにベンダーとの間でトラブルが発生しやすいのです。部門間格差が拡大する各部門間には貧富の差がありますし金銭感覚の違いもあります。以前の情報システム部門ならば,いかに利用部門が予算を取ったとはいえ,それの実行には何らかの規制をしていました。必要な情報化予算が取れない部門に対しては,情報システム部門がプールしている予算を(内緒で)流用することもできました。情報システム部門が戦略部門になると,こまごまとした日常的な情報化は,各部門の自主運営に任せることになります。利益を上げている事業部や1回の取引が数億円単位の部門では,パソコンを数台購入するとかちょっとしたローカルシステムの開発を外注する費用などは,担当者レベルの要求がすんなりと決済されるでしょうし,その結果を厳しく問われることはないでしょう。このような部門では,小姑的な情報システム部門がなくなったために,自分たちの意のままに情報化投資ができます。スーパーユーザにとって能力と好奇心を最大限に発揮できる環境になります。これは情報ガバナンスの面で大きな危険をはらんでいます。このような部門はベンダーにとって上得意です。するとベンダーはうるさい情報システム部門よりも,気前のよい金持部門のほうとの付き合いを好みます。アウトソーサーとしての義務を忘れて,利用部門の代弁者,極端にはスーパーユーザの私兵となってしまうこともあり得ます。それに対して,出張費すらままにならない貧乏な部門では,ちょっとした費用すら部門長の厳しい審査にさらされます。担当者にとっては,その説明に要する苦労のほうが情報化による改善効果よりも大きいので,よほどの案件でない限り提案すらされないでしょう。これが積もれば,情報化への関心も低くなり,情報リテラシも低いレベルになるでしょう。このように社内でのデジタル・デバイドが発生します。このように部門間での情報に関する成熟度格差が大きくなると,全社的な情報化を推進するのに不都合な状況になります。グループウェアを展開するには,全社の足並みをそろえる必要があります。一方では既に,最新のソフトウェアを搭載したパソコンが1人に1台以上設置されており,ワークフロー管理システムやナレッジ・マネジメント的な利用すらしています。そのような部門では,全社的な統一などで自分たちが進めてきたことの足を引っ張るようなことをするなというでしょう。他方では,数世代以前のパソコンが数台あるだけで,ワープロすら使えない部門があり,パソコンの購入や教育の費用は誰が負担するのか,習得による作業増加のための部員補充を部門採算枠外で認めてくれるのかなどが大きな関心になります。取引慣行の違いによるトラブル情報システムの開発には一般の投資と異なる特有の問題があります。この業界では,一般の日本企業での商取引慣行とはかなり異なる慣行(それの善悪はここでは問題にしない)があります。従来は,情報システム部門が利用部門とベンダーとの間にあってその違いを吸収してきたのですが,それが存在しなくなると,利用部門がベンダと直接取引することになり,とろいろなトラブルが発生する危険があります。日本的商慣行に馴染んできた利用部門(トップも)は,次のようなことにすら疑問を持ち,ベンダーを非難します。自社製品の教育が有料なのか?機械を納入すれば運転員に操作方法を教育するが,それが無料なのは当然であり,お願いして覚えていただいているのだ。ところがパソコンの使い方の講習まで有料なのはどういうことか。教わるのにカネをとるのか?逆にベンダーはユーザから教わることにまでカネを取っている。システムを構築するにはコンサルタントやSEが来てわれわれから業務を教わっている。開発のヒアリングではあまりにも常識なことまで質問する。それならば,われわれに授業料を払うのが当然である。それなのに非常に高額な費用を払うのはおかしいではないか。RFP(提案依頼書)が必要なのか?家を建てるときに,間取りやデザインは注文するが,雨漏り対策や土台の仕様まで指定はしない。こちらは素人でベンダーはプロなのだし,しかも当社の業務をよく知っているというから選定したのだ。本来ならば「販売業務一式」といえば,それなりのシステムをいくつか持ってきて,われわれの注文により手直しをするのが当然ではないか。それなのに事前にPFRを出せという。開発するのにわれわれに参加しろという。これではわれわれがシステムを作っているようなものだ。RFPが不十分だと追加費用を出せという。これは当社業務を知らない証拠であり,ウソをついて受注したのだから,本来ならこちらが賠償を請求したいくらいだ。した依頼に莫大なカネをとるのか?西暦2000年問題を例にしよう。2桁を4桁にして前2桁に19を入れるだけのことではないか。そのシステムは以前そのベンダに外注したものだ。それなのに数億円もとるなどというのは一種の詐欺ではないか。システムがダウンするのか?以前の汎用コンピュータの時代では,コンピュータがダウンして仕事に困ったとい事態はほとんどなかった。それから技術は急速に進歩したはずなのに,CSS環境では頻繁にトラブルが発生する。その原因はいつも不明であり,うやむやな解決になっている。ベンダは自社製品に責任を感じていないのはないか。これまでにも,情報システム部門が忙しいとか利用部門がムキになったなどの事情により,利用部門が直接にベンダに発注したことがありますが,このような業界慣行の違いのために,プロジェクト半ばで揉めてしまい,情報システム部門が介入して調整したという例は,多くの情報システム部門が経験していることですね。戦略部門になった情報システム部門は,もはやこのような低次元の問題に介入する余裕はありません。これを解決するには,利用部門とベンダーの双方が互いの慣習や発想法を学習する必要があります。ベンダー側はともかくとして,情報システム部門を戦略部門にする以前に情報システム部員を利用部門に転出させて,徐々に独自発注をさせるようにすることにより,情報業界の慣習を体験させることが必要になります。