» 【第21号】アウトソーシングへの課題

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第21号】アウトソーシングへの課題

DRI通信21号 「アウトソーシングへの課題」  1998.6.1
山の雪が早く消え、尾瀬の水芭蕉が終わり、季節は半月ほど早く進んでいるよう
ですが、CO2とか環境ホルモンもあって、この先どうなるかいささか心配にな
ります。
前回は、「動かないコンピュータの根本原因」として、「開発対象を皆で正しく
共通認識できる図面と部品表の不備」を指摘いたしました。これに対して、
「リーダーが開発スタッフの力量を超えて技術指向に走ってしまうことがある」、
また「開発に当たる人(管理者、ユーザ、SE)が、開発は始めてとか、経験の
少ない人が多く、大局的におかしなものができたりする。にもかかわらず外部の
専門家をうまく活用しようとしない」といったご意見が寄せられました。たしか
にここ数年ツールが進歩し、情報リテラシーが叫ばれて、システム開発にかかわ
る人口が増加しているわけですが、その分素人が増え、企業全体での位置付けな
どには無頓着な開発も増えているように思われます。


さて今月は、21世紀の大きなテーマ「アウトソーシング」について考えて見ま
す。アウトソーシングについては、最近の日経コンピュータ(5月25日)にも
特集が組まれていて、3つの理由として(1)経営トップからのコストダウンの要求、
(2)経営戦略に追い付けるスピード、(3)情報技術への対応、が挙げられています。
アウトソーシングには運用と開発がありますが、主に(1)と(3)は運用に、また(2)
は開発に重点があるように思われます。
日経コンピュータによるとアウトソーシングはすでに「本番」とのことですが、
一般的にはやはり21世紀のテーマと考えられますので、直近というより、もう
すこし先に焦点を当てて考えてみます。
まず運用環境ですが、
 ・マルチベンダー環境で多種多様の技術が必要
 ・情報技術が多岐にわたりかつ高度専門化している
 ・システムが大規模化して信頼性が重要になっている
などにより、社内での対応が難しくなっています。実際メインフレーム、UNIX、
NT、さらにはAS/400まであって、DB2、ORACLE、ADABAS、ESSBASE、を理解し、
ネットワークもからむとなると一体だれがどう対応すればよいのでしょうか。
運用環境は、すでにPCインターフェースになっているため、マシンはブラック
ボックス化し、どこにあっても良い状態にあります。したがってコンピューティ
ングパワーは電気、ガス、電話と同様のユーティリティになりつつあります。し
たがって運用のアウトソースは必然の方向であり、ただ「どのような形態でか」
が今後の課題かと思われます。
アウトソーサーは、コストと信頼性・安全性を売り物にしなければなりません。
情報技術の専門家をそろえなければなりませんが、一人でカバーする範囲には限
度があります。そこで情報技術もある程度は絞り込み、からみの少ない極力独立
性の高い仕組みが求められます。いまは「はしり」であり、企業数も限られるこ
とからなんでもかんでも一式引き受けるアウトソーシングになっているようです
が、将来はできるだけ少ない情報技術で、多くの顧客をサポートしようと、アウ
トソーサーも特色を出すようになってくるでしょう。特定のERPパッケージを
用い、ハード環境も限定して、何社もの運用を串挿しにサポートできれば、かな
りのコストダウが実現できるものと思われます。
さらに高品質で安いサービスを提供するためにと、企画・開発段階からかかわる
アウトソーサーが増えてくると思われます。ビジネスモデルは違っても、実装方
式を統一標準化して合理化・コストダウンをねらうわけです。しかし当初は、顧
客側に評価力がないと却って高いものを買わされる心配があります。アウトソー
サーは、一般にSIのときから、いかに速く安く造るかは考えても、いかに信頼
性の高い安い運用保守を実現するかまでは考えてこなかったからです。実際保守
に手間が掛かるほうが売上が確保できる意味もあったわけですから、開発のなか
でこれを減らす配慮は難しかったと言えるでしょう。したがってその技術は未開
拓のはずです。開発と運用・保守のバランスの取れたシステムを造るための、顧
客とアウトソーサーの協力形式は、今後の課題となってくるでしょう。
アウトソーシングが確立するとき、ユーザはもはや実装方式は問わなくなるはず
です。それが独自開発であるか、ERPパッケージを活用するものであるかを問
わず、情報要求が安く、速く、確実かつ安全に満たされればよいのです。ただし、
このときその情報要求は、お互いに行き違いなく正しく理解されていなければな
りません。そのためにはビジネスモデルが、目に見える形で分かりやすく表現で
きなければならないでしょう。建築における平面図相当のエンジニアリングドキ
ュメント−−すべての部品が記載され、その相互関係が個人差なく明示されてい
るため、抜けや矛盾が一目で分かるドキュメント−−が求められることになりま
す。
現在は現物の現行システムによって、情報要求を表現しているのが大方かと思わ
れます。しかし動かしてはじめて「これでよかった」ことの分かる方式では、大
規模化に向かう今後のニーズに耐えられなくなるでしょう。契約内容を明示する
手段を持たずに、単に情報システム部門が楽するための「弱者の戦略」だけで、
アウトソーシングビジネスが、発展できるとは考られません。
ちなみにDRIではPLANシリーズにおいて、ビジネスモデルを4種の図
 (1)概念DB構造図(THD)
 (2)SPFチャート
 (3)IPFチャート
 (4)IOイラスト
をベースに記述していますが、これによってエンジニアリングドキュメントとし
ての上述の要求がほぼ満足されているように思われます。一般には、「詳細は実
装従属にしか記述できない」といった思い込みもあるようですが、データ定義書
などと合わせて、ユーザ要件はすべて書き尽くすことができます。
情報システムとは、サーバーにストアした「原材料=データ」を組み立てて、
クライアント(ユーザ)の要求する「製品=画面・帳票」を造る仕掛けである、
とするならば、上の4つの図はそれぞれ次のような役割を持つものと考えること
ができます。
 (1)概念DB構造図 原材料と原材料の関係を表わす(サーバー側)
 (2)SPFチャート 原材料と中間品(加工データ)の関係を表わす(サーバー側)
 (3)IPFチャート 製品と製品の関係を表わす(クライアント側)
 (4)IOイラスト  製品と原材料の関係を表わす(クライアントとサーバー間)
したがって、図としてはこれでほぼ尽くしているかと思われます。
このような組み立て図をベースとするエンジニアリングドキュメントによりアウ
トソーサーはユーザの情報要求を正確に把握できますが、同時に情報技術の専門
家は、他と最大限独立にその専門に特化することができ、ひとりで何もかも分か
るというスーパーマンがいなくてもよくなります。すなわちエンジニアリングド
キュメントにより有効な分業が可能になり、高度情報技術を実現できる体制がで
きるわけです。
さきの日経コンピュータ(3月30日)では、情報システム子会社が論じられて
いましたが、委託内容がシステム企画か作業依頼かを問わず、「親会社との契約
内容の明示」、「ビジネスモデルとソフトウエアの分離」、「客観的分解モデル
による管理対象の明確化」といった技術のバックアップが、経営方針の刷新に加
えて、ここでも必要になるものと思われます。
こうして造られるエンジニアリングドキュメントに加えて、これをを忠実に反映
したデータベースとして「ビジネスモデルリポジトリ」が造られますが、さらに
これをベースに造られる「ソフトウエアリポジトリ」とハードウエア・ネットワ
ーク環境を反映する「プラットフォームリポジトリ」が運用に活用されることに
なります。これらは、より少ない要員で、信頼性の高い運用を行うために、アウ
トソーサーにとって不可欠のツールとなるに違いありません。
紆余曲折を経ても、ユーザは、ついにはオートマ車を運転するように、実装の詳
細を意識せず、ビジネスモデルのみを意識してコンピュータリソースを使うこと
ができるようになるでしょう。そしてそのときのユーザインターフェースは、大
部分イターネット/イントラネット経由のブラウザーになってしまうと予測して
いるのですが、皆様如何がお考えでしょうか。
追記
先の20号において、「動かないコンピュータ」の事例として、日経コンピュー
タから住友銀行の事例を引用いたしましたが、日経コンピュータ4月14日号に
訂正記事が出ているように、事実と異なるとのことで、お叱りをいただきました。
お詫びして訂正いたします。