情報システム部は、もう役割を終えてしまったのか?何かがおかしいIT化の進め方(24)(1/2 ページ)

ITシステムのアウトソーシングが流行しているが、同時にアウトソース先からの情報流出などの問題も多発している。この問題には、どのような背景があるのだろうか? 今回は、情報システム部門の歴史を振り返り、組織の体質形成の背景を考えてみる。

» 2006年03月31日 12時00分 公開
[公江義隆,@IT]

 ITの戦略・企画機能の部分だけを残し、開発や保守運用といった、現業機能を手放す企業が大手を中心に広がっている。その一方で、アウトソーシングした情報システムのトラブルによって、自らの信用を失墜する企業がメディアをにぎわしている。これは人ごとではない問題である。

 権限を手放し過ぎて、結果的に責任を放棄してしまうことになった問題の背景に、情報システム部門に共通する体質(固有の発想法や常識としている価値観や判断基準)に関する問題はなかったのだろうか。

IT組織の体質

 工期遅れや予算オーバーするプロジェクトが多い中で、「最初から無理な計画だった」とこぼすプロジェクトマネージャがおられた。事実はそうかもしれないと思うが、それをいうのであれば「工期はXXで、予算はYYでなら、間違いなく合格点のシステムを仕上げる」といえるようするにはどうすればよいか、を真剣に考えてみてほしいと思う。

 難しい/できない100の理由を説明してくれるより、どうすればできるか、その方法を1つだけ考えてくれる部下やパートナーの方がありがたいはずだ。

 また、問題に手が付けられない理由に“多忙”を挙げる人も多い。しかし、多忙というものは昔もいまも、そして多分これからもずーっと続くものだ。つまり、多忙を理由にしていては、いつまでたっても手が付けられないことになる。

 では、なぜやれないのか? その原因の1つに、「IT組織に共通する自律性の弱い体質」が挙げられると思う。「自分の仕事というより、頼まれて相手の仕事をしているという感覚」「できるだけのことを一生懸命やるから、それで勘弁してほしい」「外因でやむを得ずする」というスタイルを取る、などなど……。そんな甘えの構造や、自ら前向きに決定することを避ける体質がどこかになかっただろうか。

IT組織が各時代に経験してきた環境

 「温故知新」という言葉がある。IT組織の体質の形成や成り立ちを、過去の経過を通じて探ってみるのはどうだろうか。今後の方向性や組織戦略検討の参考にしていただければと思い、筆者自らの反省も含め、以下に組織や人の面から情報システム組織の置かれてきた状況を時系列的に記してみた。

最初から手段が目的化した組織だった?

 日本の企業でコンピュータ活用が始まった1960年代には、いまでいうIT部門は機械計算部や電算室などと呼ばれ、業務は実態どおりのデータ処理(DP:Data Processing)といわれていたが、プログラム作りが組織の目的のような位置付けにあった。システム化の対象は、日常的な業務の機械化が中心であり、このころのコンピュータ技術者=プログラマ(SEという言葉は、当時まだ一般的ではなかった)の多くは、業務内容を熟知していた。しかし、仕事の内容は、コンピュータメーカーに過度に依存した、自律性を欠くものだった。

 また、コンピュータメーカーが提供する業務分析や、業務・システム設計演習、システム構成法などという演習を取り入れた業務指向の教育・訓練コースが、多く整備されていた。

 当時は、情報システム=業務システム+コンピュータシステムであり、各分野のシステムは経理サブシステムや人事サブシステムなどと呼ばれ、少なくとも概念としてはトータルシステムが前提となっていた。

最初の曲がり角―新技術に目を奪われ、業務への関心を捨てた?

 1970年代になると、オンラインシステムやDBMS(DataBase Management System)を用いるシステムが普及過程に入り、コンピュータメーカーはユーザー企業の情報システム部門を、これらのシステムを推進する技術の尖兵として位置付ける戦略を取るようになった。情報システム部と名称は変わったものの、実態はDP部であった。

 このころはオンラインシステムやDBMSなど、新しい技術の利用に興味をそそられたSEにとって、やりがいのある仕事になっていた。そして、組織も人もその多くが技術指向になっていった。当時の大部分のシステム部員は、システム化に必要な業務面の知識や分析手法をすでに過去に修得していたため、その時点では技術に傾注しても業務知識面で支障が生じることはなかった。

 世の中の講習会は、オンラインソフトやDBMSに関する教育に塗りつぶされることになった。そのほかにも情報システム開発方法論、プロジェクトマネジメント手法などが紹介され、多くの企業で導入が進められた。オンラインシステムは、業務形態を抜本的に変えて省力化・効率化・迅速化などに大いに効果を上げ、社内・関係部門からはそれなりの理解や評価を得た。

 しかし、技術中心指向の組織が成果を上げる中で、新しく情報システム部門に加わった人たちには業務面の勉強をする動機が失われていった。これが、現在の「業務仕様・システム要件を決めてくれないとやれない」という体質につながったのかもしれない。その一方で、「メーカーから給料をもらえ!」と社内ユーザー部門から陰口をたたかれるほど、コンピュータメーカー推奨の技術商品に傾注した伝道者が現れたりもした。

 当時は、ハードウェア、ソフトウェア、教育、技術サポート……、一切合財がコンピュータメーカーから提供されるという閉じた仕組みだった。これらの目に見えるもののほかにも、メーカーの文化やコンピュータの故郷である米国のビジネス慣習や彼らの考え方が、お互い無意識のままに持ち込まれていた。これがコンピュータに対する違和感を、一般の人に与える要因の1つになっていたかもしれない。

 そして、1970年代半ばごろには、検索用簡易言語やDBMSなどがサードベンダから提供されるようになり、それまでのすべてをメーカーにお任せという状況から、一部のユーザー企業ではこれらの検討と選択という業務が生まれた。

 オンラインやDBMS活用システムは当時の組織にとっては、それなりにビッグシステムであり、挑戦的なテーマでもあった。1つのシステムの開発に傾注する中で、トータルシステム思考は急速に失われたことも否めない。

“量”を確保するために“質”を捨てた?

 1980年代に入り、銀行システムのオンライン化など大規模システム開発が進む中で、要員確保のために下請け、孫請け、ひ孫受けといったIT業界のゼネコン体制が作られた。階層が1つ増えるごとにシステム開発費が上がり、システム品質が低下した。

 そして、SEが書いた「プログラムコードと同じ詳細レベルで書かれた日本語を、コンピュータ言語に置き換える作業」を専門に行う職種(コーダー)が生まれたのもこのころだ。教育して底上げを考えるより、労賃の安い未熟練労働者でもできるように、仕事を分割する方法が取られた。さらにこれを続けているうちに、常識となったこのやり方に対して、疑問を持つ人はいなくなった。生産性や品質の低下も、システムが変わり、基準がないまま「世の中全体がそうなら、こんなものか」と皆が思うようになってしまった。

 システム開発の需要が膨らむ中で、分析や設計のキチッとした教育・訓練を受ける機会のなかった人も、やがてSEやプロジェクトマネージャと呼ばれるようになり、より上流の仕事をせざるを得なくなった。孫請けの10人のコーディングチームのリーダーなども含めて、「XX銀行のYYオンライン開発のプロマネをやりました」という人が何百人も現れたり、正規化を知らないDB設計者が出現した。このように、名と実の乖離が広がり、質の低下が下流業務からじわじわ上流に広がっていった。

 そして、生産性やスピード、品質の救世主と称するソフトウェア工学なるものが、米国から輸入されてきた。プログラムのスパゲッティ状態が問題だとして、構造化プログラム手法や、DBMSを念頭にしたデータ中心設計やDB設計、DFDERD、生産性向上に

RAD(Rapid Applications Development)・プロトタイプ手法などや、「プログラム開発チームは外科医の手術チームのようであるべき」なる組織問題まで、功罪半ばのうちに救世主にはなり得ないままブームは去った。罪の方の大きなものはRADの置き土産である「ドキュメントはキチッと作らない」であろうか。

 各分野でオンライン化、DBMS利用システム導入が進んでくると、蓄積されたデータを管理の水準向上に生かそうという動きが出てくる。情報システム部門が「情報系システム」と呼ぶ新しいアプリケーション分野である。しかし、組織全体が技術指向に走り、業務面への関心も知識も失われて久しい。ベテラン層の持つ業務知識は基幹業務の作業レベルの内容が中心だ。管理へのデータ活用といわれても知恵が出てこなかった。

 検索用ソフトや簡易言語を道具に、EUC(End User Computing)という概念が輸入された。情報システム部門はデータベースの管理と技術サポートを行い、中身は「ユーザーにお任せ」というコンピュータメーカーお勧めの“情報センター”体制が生まれた。日常業務の多忙さを言いわけに、責任の放棄を始めたが、その意識はなかった。

 その後、統括機能を確立しないまま、業務システムの開発から運用までユーザー部門に任せてしまうケースも出てきた。不作為による分散化が始まった。責任を放棄すれば、権限も狭まり立場は弱まる。その理屈どおりになったのだ。 さらに、背景はいろいろあったが、情報システム部門の分社ブームが起こった。分社後にまた情報システム部門を作った会社もあった。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ