» 【第74号】大手SI企業病

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第74号】大手SI企業病

DRI通信74号「大手SI企業病」      2002.11.1
桜の葉はすっかり落ち、紅葉が平地に降り始めました。流感で1週間低空飛行を
して、やっと治ってきました。今年のはしつこいようですから、ご用心ください。
ことのほか厳しい不況をかみ締めていますが、皆様いかがですか。情報関係、
全般には悪くないとのことですが、膨大なレガシーを抱え、「遅い、高い、ト
ラブル」情報システムの根本問題の解決への道はまだまだのようです。がんばりま
しょう。
■開発の主役は大手SIに
ERP、SCM、CRMなどの3文字英語が象徴するように、対象とすべきシステムの大きさが、ここ10年で1ランク上がったように見えます。そして情報システム部門の弱体化、またそのパッケージやSIサービスに関する調達部門化は、これと軌を一にするものに見えます。となると開発の主体は、SI業、それも大規模プロジェクトのリスクヘッジの観点から大手SI業、にシフトしていくことになります。情報システム開発の主役は大手SIとなる、その大手SIが日本の情報システムのレベルを決める。そんなことから、やや語弊のあるきらいはありますが、今回は「大企業病」ならぬ「大手SI企業病」として問題をとりあげました。


■標準は棚に飾ってある
メーカー系、独立系、コンサル系など、大手SIにもいろいろありますが、歴史も30年を超え、優秀な人材を抱え、先進技術に取り組んでいるところが大部分です。しかし方法論、特に上流の方法論が属人的になっている。「貴社の標準は」と伺えば大方名前は出てくるけれど、使われていない、棚に飾ってある、という場合が大部分のようにみえます。標準化グループがかなりの工数をかけて作ったのでしょうが、現場で十分活用されていない。属人的といっても、同じ釜の飯を食っている仲間の中で、ルーズに共有されている。それはどうも40人を超えない。そんなところが実態に見えます。
■4つの理由
第1の理由は、「方法論は顧客が決める」、「顧客に合わせて仕事をする」、でしょう。永らくこのスタンスでやってきた。だから「今度は貴社の方法論で」と言われても、身についていないから、積極的になれない。実際、各手順や成果物の重要度が感覚的に分かっていないと、マニュアルどおり方法論を使ってみても期待した成果が出せません。
第2の理由は、「この顧客/システム/プロジェクトは特殊である」です。とくに「短期」が錦の御旗になります。手順もドキュメントも省略して、ともかく動かせばよい、となれば標準は邪魔なだけになります。「責任は誰がとるのですか」の一言で、属人的方法が正当化されます。
第3の理由は、第2とも関係する根本的な問題ですが、「孤島システムの開発請負」にあります。他と関係しない孤立したシステムはないはずですから、顧客は各システムを適切に関連させつつ運用しなければなりませんが、そのグローバルデザインのないまま、取り敢えず孤島システムとして発注してしまう、というのが実態ではないでしょうか。運用・保守を開発SIが請けるとしても、それは別途契約ですから、「速く、確実に開発を行えばよい」、そして出来上がったものは、外側に殻のある閉鎖的な孤島システム。これはERPであっても、スケールが大きいだけでスタンスは同じです。他システムとの関連や、業務仕様変更を考えるための業務モデルのドキュメント化は、なおざりにされてしまいます。
第4の理由は、「ノウハウ陳腐化への抵抗」かと思われます。開発に携わり、その後10年も運用・保守を担当したとなれば、業務についてはさておき、ソフトウエアに関しては、スパゲッティはスパゲッティなりに相当のノウハウが蓄積されています。再構築に当たっては、これを「極力陳腐化させたくない」ということから、新しい方法論の採用を避けようとする。これは大手SIに限ったことではありませんが、アウトソーシングを請ける大手SIに多々見られることと思われます。こうして同じソフトウエアおよびソフトウエアドキュメントを共用する仲間の中に、属人的方法論が存在しており、そしてこれはその仲間を超えては広がらないように見えます。
こうして大手SIには、これまでのソフトウエアを核にした文化圏が乱立し、なかなか標準的方法論が育たない。ソフトウエアはIT従属ですから、文化圏はメインフレーム、C/S、JAVAなど下流の影響を受ける。上流は本来IT独立なので、統一可能なはずなのに、性急に下流に合わせようとして、乱立から抜け出せない。こんな状態が続いているのではないでしょうか。
■プラントエンジニアリングの体制
私はこの問題を考えるとき、やはり昔のプラントエンジニアリング会社のときを思い出します。そこには建設工事を担当するプロジェクト組織がありますが、同時にファンクショナルと呼ばれる、化工設計、計装設計、配管設計、機器設計などの組織があります。プロジェクトを縦組織というなら、ファンクショナルは横組織です。ファンクショナルは化学工学、制御工学、機械工学など専門の工学に基づく専門家集団です。
プラントが定型化するにしたがって縦組織が強められていきましたが、ファンクショナルがなくなることはありませんでした。そして上流工程ほどファンクショナルの比重が高く、プロジェクトの仕事もファンクショナルの中で担当する場合−これはおおむねファンクショナル部門長のお墨付きが必要の場合−が多い。またプロジェクトに配属されるとしても一時的で、プロジェクトでの仕事が終わればまたファンクショナルに戻されます。ファンクショナルは技術の共有・教育の場であり、標準化の受け皿となります。プロジェクト組織では、下流の工事の標準化は受け止められても、上流工程の標準化はうけとめられません。研究開発や標準化の成果はファンクショナルが受け止め、間接的にプロジェクトに適用される。これが無理のない体制であったかと思います。
■ファンクショナルが育っていない
これと比較すると、情報システムの場合は、ファンクショナルの力が弱すぎるように思われます。上流に関しては、「ファンクショナルは育っていない」と言ったほうが当たっているのかも知れません。そこで、たたき台レベルの方法論をいきなりプロジェクトに持ち込むわけですが、マニュアルの研修レベルでは身につくはずもなく、また「短期にやっつけ」を得意とするプロジェクトとは肌が合わず、なかなか成功しにくいと言う結果になりがちです。
■処理すべき内容
では、情報システムに関してはファンクショナル組織を作って処理すべき内容がないのでしょうか。私は決してそんなことはないと考えます。ファンクショナルとして切り出すために、業務を列挙してみると、次のようなものが考えられます。
(1) 現状データモデリング(物理ファイル項目との紐付けを含む)
(2) コード設計
(3) データクレンジング
(4) DBアーキテクチャ設計
(5) 新規プラットフォーム設計・導入
(6) バージョン管理・リカバリ方式の設計
(7) RFP(Request for Proposal)作成
   −問題分析・課題整理・解決方針策定
   −新規プロセスモデリング
   −新規画面・帳票概念設計(データ項目確定)
   −新規データモデリング
   −データ定義
   −ソフト化標準策定
(8) DB物理設計・チューニング
(9) 画面・帳票物理(マンマシンインターフェース)設計
(10)開発プロジェクト管理
   −プログラム開発
   −テスト
   −移行
このうち(10)はプロジェクトの業務そのものでしょうが、他はファンクショナルと考えられる技術的専門性を持ったもののように思われます。
■ファンクショナルが育たない理由
どうしてこれらがファンクショナルとして育たないのでしょか。仮説になってしまいますが、次のような点が挙げられます。
・基礎学問が大学などで教えられておらず、専門技術として確立していない
・方法論、とくに成果物形式が決まっていないので分担ができない
・プラントのように専門性が厳しくなく、専門家でなくてもある程度できる
・システムの仕様が形式知として表現しきれないため、プロジェクトに張り付いていないと仕様が共有できない
■解決の方向
だから仕方がないと言って放置しておいて良いはずもありません。悪循環にはまっている部分も多々ありますので、突破口を見つけて悪循環を断ち切れば、思ったより解決は容易かもしれません。
その一つとして考えられるのが、コマーシャルと受け取られるかもしれませんが、プロのコンサルを入れたSwatチームを作り、実プロジェクトにおいて成功例を作っていくことです。一番効果的なのはRFPを固めることかと思います。これにより疑義のないシステムイメージが関係者全員に共有されます。これを突破口にして大手SI企業病が治癒できれば、これはすごいと思っています。皆様のご意見をお聞かせください。