連載	企業システム戦略の基礎知識（15）

システム構築に潜む4つのリスク

青島 弘幸
2006/1/27

-	「技術的リスク」を取る場合は、事前の技術検証を

　近年は、ITの高度化・複雑化によりシステム構築における技術的リスクが高くなっている。さまざまなコンピュータがネットワークでつながれ、搭載されるソフトウェアも種々混在している。さらに、これらを接続するためのミドルウェアと呼ばれるソフトウェアが複雑さに拍車を掛け、ブラックボックス化を増長している。

　そのため、新しい技術や製品を採用した場合、カタログどおりにつながらない、動かないという事態が発生する。特に複数ベンダの製品を組み合わせて採用した場合は、解決が困難になる傾向にある。こういったリスクを避け、実績のある、枯れた技術だけを採用してシステムを構築できれば、信頼性や安定性などの技術面だけでなく、コスト・期間でも有利であることは間違いない。

　しかし、それだけでは満足できないほどビジネス側からの要求も高度化している。例えば、既存の汎用機上のシステムを、インターネット経由で社外から利用したいなどの既存の技術だけでは実現できない要求が増えており、新しい技術を採用しなければならないことがあるわけだ。

　また、新ビジネスを短期間に立ち上げ、同業他社より競争優位に立ちたいと思えば、技術的なリスクを覚悟で新技術を採用し短期構築に挑まなければならない。システム構築コストを削減するためには、オープンソース・ソフトウェアの採用も必要だろう。

　このような場合には、できるだけ早めに技術的な検証を目的とした実験を行うことだ。たとえ、開発初期に一定の費用を払っても技術検証を依頼した方が、システム構築が本格化してから「できない」という事態になるよりはましだ。

　最悪「できない」という事態になったら、その理由が費用的か、時間的か、それとも純粋に技術的に不可能なのかをよく見極める必要がある。

　費用的・時間的にできないという場合は、その影響を分析し、投資対効果を見極めたうえで実施の可否を判断する。また、技術的に不可能な場合は、高度な技術者や代替品を採用すれば可能なのか、一般的に不可能な要求なのかを見極め、あきらめるか否かを決断する。時間と費用を掛ければ大抵の技術的課題は解決すると思われるが、ビジネス上の目的や目標に照らして、その技術を採用することの有用性を経営的観点から判断しなければ、単に技術的興味でコスト・納期に影響を与えることになる。

　業務パッケージを採用する場合、技術的リスクを移転できるが、自社の業務がパッケージソフトにロックインされないように、製品の市場シェアやサポート状況を常にウオッチしたい。特に大型の業務パッケージでは、経営的なリスクにつながるので、その製品の10年先、15年先を見極めることが必要になる。

-	「組織的リスク」では、システム構築をしないという手も

　システム構築は、業務やシステムとかかわる“組織”を切り離して考えることはできない。目的やビジョンの策定に始まり、要件定義や要求仕様の作成、運用試験、実用展開とあらゆる段階において、組織的なリスクが存在する。ITのあるべき姿に組織を導く能力を、ITガバナンスという。近年、ITガバナンスは組織経営においてコーポレートガバナンスの一部として重要視されるようになっている。

　システム構築の目的やビジョンを明確に定義し、それを関係者に周知するに当たり、経営者がリーダーシップを発揮することができる組織であるか。要件定義以降の運用試験、実用展開まで、先頭に立って活躍すべきキーパーソンを選出し、システム構築に当たらせることができるだけの組織力があるか。システムの運用に伴う業務上の変革などを受け入れる柔軟性が組織に備わっているか。

　利害関係者が協調して前向きに物事を進めていくことができるか。いずれの場合にも、“組織力の有無”がシステム構築から実用までの成功を左右するケースが少なくない。全体最適を目指してプロジェクトを立ち上げても、プロジェクトリーダーにリーダーシップがなく、経営者のバックアップもなく、メンバーは自分の業務や既存の組織に固執するのでは、結局、個別最適の寄せ集めになってしまう。あるいは、利害関係者が対立しシステムの運用がとん挫してしまい、使われないシステムになってしまう。最悪は、抵抗勢力がシステムや業務を妨害するというケースもある。

　組織的リスクの存在は、システム構築以前の問題でもある。もし、組織的リスクが大きいならば、あまり大上段に業務改革とか全体最適化などを目指してシステム構築プロジェクトを始めない方がよい。「同床異夢」「船頭多くして舟山に上る」となるのは必至だ。

　まずは、身近な業務の効率化など、できるだけ小さい組織だけでクローズするようなシステム構築から手掛けるのがよいだろう。全体を個別に最適化するようなムダな投資をするくらいなら、焦点を絞って、徹底的に個別最適化を図った方が、かえって全体最適になる。

　あるいは、リスクを承知のうえで、先に業務パッケージなどでシステムを入れ替えてしまって、強制的に業務改革を断行するという荒療治も考えられる。ただし、その場合には、火の粉を一身にかぶっても貫徹できるだけのリーダーシップと信念と覚悟が、経営者と推進チームに要求される。途中で、現場からの突き上げにたじろいで現行の業務に合わせるようにシステムを改造するような方向転換をするくらいなら、組織的リスクが緩和されるまで業務パッケージによる業務改革は見合わせた方がよい。ただし、体力のあるうちに行動を起こさないと瀕死の体には大規模な手術は命取りになるので、改革はタイミングを逃してはならない。

　最小の投資で最大の成果を上げるシステム構築では、組織力を問われるのである。

　次回は、企業システム戦略を考えるうえで重要な「企業の中を情報が流れる、3つの川」について解説する。

	関連記事
		連載：ERP導入プロジェクト失敗の法則（＠IT情報マネジメント）
		【できるPMの決め手は「リスクマネジメント」】連載：プロジェクトマネジメントスキル実践養成講座（8）（＠IT自分戦略研究所）

2/2

第16回へ

index 連載：企業システム戦略の基礎知識（15） 　システム構築に潜む4つのリスク 　 Page 1 「認識的リスク」は、見える化で防ぐ 「人的リスク」は、リーダーがポイント Page 2 「技術的リスク」を取る場合は、事前の技術検証を 「組織的リスク」では、システム構築をしないという手も

この記事に対するご意見をお寄せください

managemail@atmarkit.co.jp

■要約 システム構築は、極めてリスクの高い投資である。その主なリスクは、「認識的リスク」「人的リスク」「技術的リスク」「組織的リスク」である。 システム構築は、認識に始まり認識に終わる。特に目的設定段階で誤認しては、それ以降をいかに正しく行っても意味がない。早期に誤認を発見するには、誰もが分かる地図を用意すること、そして適切なチェックポイントで確認しながら進むしかない。 人的リスクには、質的なリスク（技術的能力／人間性）と量的なリスクがある。技術的能力は他人が補強できるため、人間性のリスクの方がより影響が大きい。また、技術的能力のリスクは作業者のメンタルな部分に関連する。この場合、リーダーの人間性がリスク要因となる。 技術的リスクを回避するには実績のある技術だけを採用すれば有利だが、それだけではビジネス側の要求に応じられないかもしれない。技術的リスク覚悟で新技術を採用する場合、できるだけ早めに技術的な検証・実験を行うべきだ。 組織的リスクはシステム構築以前の問題だが、もし組織的リスクが大きいならばあまり大上段に業務改革や全体最適化を目指してプロジェクトを始めない方がよいだろう。

▲記事の先頭<Page1>に戻る

profile

青島 弘幸（あおしま ひろゆき） 「企業システム戦略家」（企業システム戦略研究会代表） 日本システムアナリスト協会正会員、経済産業省認定　高度情報処理技術者（システムアナリスト、プロジェクトマネージャ、システム監査技術者） 大手製造業のシステム部門にて、20年以上、生産管理システムを中心に多数のシステム開発・保守を手掛けるとともに、システム開発標準策定、ファンクションポイント法による見積もり基準の策定、汎用ソフトウェア部品の開発など「最小の投資で最大の効果を得、会社を強くする」システム戦略の研究・実践に一貫して取り組んでいる。趣味は、乗馬、空手道、速読。 「システム構築駆け込み寺」を運営している。 メールアドレス：hiroyuki_aoshima@mail.goo.ne.jp

「企業システム戦略の基礎知識」

■記事の「要約」がメールで読めます■ 記事の「要約」を毎週水曜日にメールでお届けしています。 下の「＠IT情報マネジメント メールマガジン」からお申し込みください。 サンプルを見る

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）