システムを統合するために必要な事前知識――必須となる技術要素の整理と整合性について戦う現場に贈る分散システム構築−情報部門編(2)(1/2 ページ)

SI会社からあるユーザー企業に転職した豆成くんは、入社早々点在する複数のシステムを統合する大役を押し付けられてしまった。これまで経験したのは独立したシステム開発だけで、業務知識もシステム統合技術も持たない豆成くんは、無事成功できるのだろうか?

» 2008年11月07日 12時00分 公開
[岩崎浩文,豆蔵 BS事業部]

豆成くん、苦悩する

 入社早々に任された大きな仕事に覚悟を決めた豆成くんだったが、自社の業務内容やこれまでの部門内の慣習を知らないため、まずは年長で先輩格の蔵田に相談に行くことにした。蔵田は「ああ、あれを遂に押し付けられたのか」と苦笑しながら、どこから手を付けてよいか苦悶する豆成くんへアドバイスを始めた。

 「おれにも正しいやり方は分からないが1つ確実にいえることは、おれたち情報システム部門はもちろん、いまわが社と取引しているSI会社の連中に、この手の複雑な設計をこなす能力を持つ人材はいない、ということだ。このプロジェクトを遂行するには、いまいる以外の人間??つまり外部から設計能力を調達しないと無理だな」

 「取りあえずSIベンダを選定して、そこに丸ごと設計してもらうというのは無理なんですか? いま出入りしてる数社のベンダなら相談に乗ってもらえそうですが……」

 「それは契約上無理だな。うちの部署はRFPを出して、相見積もりを取ったうえで契約を取り交わすことが数年前に義務付けられたんだ。前任の部長とお付きのベンダとの怪しいなれ合いが発覚して大問題になってね。それで禁止令が出たんだ。システム監査部から散々いじめられた経緯もあるしな。それに契約の話を抜きに考えても、わが社で稼働している各システムは、それぞれ別々のSI会社が作ったもので、各社はいまもうちに出入りしながらシステムの面倒を見てくれている。連中はお互いの既得権益を守るのに必死だから、けん制しあってシステム間調整を嫌がるんだ……」

 「じゃあ、主要ベンダに相談に入ってもらいながら一緒に作っていくという方法は……」

 「それも難しい。いまのような政治的な理由もあるが、ベンダ側から見ると、現状の厳密な契約形態では赤字覚悟の泥まみれプロジェクトはリスクが大き過ぎる。昔なら、将来に期待してまずは受注というやり方もあったけど、いまは契約ごと、プロジェクト単体で黒字を出すモデルじゃないと乗ってこないな。つまり“設計”の仕事でキッチリ回収できるか、ちゃんと要件が決まった後の“構築”の仕事でガッツリ回収するか、だ。従来のやり方じゃ無理だ??ってのは、部長以下みんなの共通認識だよ」

 「……」。事の重大性と困難さに、豆成くんの顔は青ざめていた。

設計するのはどこの誰?

 さて、上記の話は実際のユーザー企業によく見られる状況である。既存システムを統合するプロジェクトでは、社内のシステムをすべてを自社で賄っているのでなければ、必ず既存システムを改修・運用管理を担当している外部のITベンダが登場する。規模の大きな会社であれば、そうしたベンダは複数社となる。

 分散システムを構築するということは、それら複数のシステムを統合・連携させることだが、プレーヤーが多くなって利害が錯綜(さくそう)するため、技術論の議論をするずっと前段階、つまりこのような政治的な話に巻き込まれることが多い。

 これを乗り越える具体策はいくつかあると思われるが、まず最初に着目したいのは、システム設計時には外部の能力が必要であり、何らかの依頼が必要であるという点だ。

 従来の(泥くさい)やり方の典型としては、構築を担当するSI企業が設計から構築までを丸ごと請負うという方法があった。しかし、この手法では請け負った段階ではプロジェクト範囲(スコープ)が明確でなく、場合によっては要求事項や作業量、そして費用が後からどんどん増えていくことになりかねない。納入時には予算をオーバーし、その費用を発注企業が負うか、SI企業が負うかで訴訟問題にまで発展する例も見られる、ある意味で前近代的なやり方である。請負契約時に明細が不明という点も、ガバナンスやコンプライアンスの観点から好ましくないといえる。

 これに対して、比較的近代的なやり方としてRFP(提案依頼書)を利用する方法がある。すなわち、構築対象のシステムを事前に設計(システム要件定義やソフトウェア要件定義を作成)してRFPを出し、それに対するプロポーザル(提案書)と見積もりを複数社に提案してもらい、中身と価格を見ながら発注先を決める方法である。もちろん構築だけではなく、その前工程(要件定義など)にRFPが適用されることも多々ある。この豆成くんの会社も、そうした流れを受けて数年前にやり方を改めた会社の1つである。

 分散システム構築プロジェクトにおいて、特に後者のやり方が好ましいと考えられる。その理由は何といっても、発注側が誰にどの範囲の仕事を委任したのかが明確になる点である。しかも、既存の複数システムを複数社が別々に運用しているような場合、それらを統治する上位チームとしてある業者を選任するときにも、既存チームの「仕事を取られるのでは」という疑念を払しょくし、連携作業時に公平性を持って接することが可能となりやすい。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ