PR

渡部 直人
Naoto Watabe
IBMビジネスコンサルティング サービス
ADソリューション・コンサルティング
シニア・マネージング・コンサルタント

「日本版企業改革法」が求める「ITへの対応」は、ITガバナンスとほぼ同じ概念であり、IT部門の活動そのものだ。IT部門の活動の一つであるシステム開発における「ITへの対応」では、開発プロセスの見直しを求められる。そこでは、CMMI(能力成熟度モデル統合)が参考モデルになる。

 システム開発において、「ITへの対応」、すなわちITガバナンスが整備できていないと、財務報告にどんな影響を与えるだろうか。そこでの課題には以下のような例が考えられる。
(1)システムの設計や使い方の問題、あるいは潜在的なバグにより、在庫管理システムの在庫数と会計システムの在庫数が一致しない
(2)必要な機能をITベンダーに伝えきれず、導入した売り上げ管理システムの一部しか利用できない
(3)未承認のプログラム変更により不具合が発生し、承認されていない発注が行われた
(4)保守契約を結ばずに会計システムを導入していたところ、ハードを新機種に切り替えたら会計システムが動かなくなった
 2005年末、証券取引の誤発注が発生し、取り消し処理にかかわる問題で誤発注を取り消せないという事故が起きたことは記憶に新しい。取引システムに問題があったことや、緊急時の対応手順が不明確だったために、結果的に大きな損害を発生させた。ITへの対応が不十分だったために、会社の財務状況や信頼に多大な影響を与えてしまったケースである。

ソフト開発のガバナンスはCMMIで


▲図1 COBITと主なITマネジメント・モデルの位置付け
[画像のクリックで拡大表示]

 前回、ITガバナンスの整備には、COBIT(Control Objectives for Information and related Technology)(注1)などが有効であり、「企業改革法」が求める成熟度としては「組織としての手続きが定義されているレベル3相当が求められる」ことを説明した。

 COBITは、戦略策定から調達(開発)・運用・監査までのITマネジメント・プロセスを、「計画と組織化」、「調達と導入」、「デリバリとサポート」、「モニタリング」の四つのドメインに分け、さらに34個のプロセスに分解したビジネス・モデルである。

 しかし、COBITは、“What”である「達成すべきコントロール項目」を明確に定義しているのに対し、“How”である「組織としてどのように実現するか」については、あまり言及していない(注2)。そのため、組織にCOBITを導入し活用するには、さらに手続きや手順として落とし込む必要がある。そこをCMMI(能力成熟度モデル統合)で補う。CMMIは、システム開発の側面からITガバナンスを実践的に整備する際に有効なモデルだ。

 CMMIでは、ソフトウエア開発組織において、進ちょく状況や成果物に関する情報が、どれだけきちんと目に見える形で管理されているかを5段階で評価する。採用した多くの組織がシステム開発における品質と生産性向上に効果を上げている。

 図1に、COBITと主なITマネジメント・モデルの位置付けを示す。CMMIが、COBITの「調達と導入(AI)」ドメインを中心に、Howに当たる手続きや組織体制などをカバーしていることが分かる。

 COBITとCMMIを組み合わせて活用している企業の一つに、米ロッキード・マーチンがある。同社はCOBITを品質管理のフレームの傘に位置付け、チェックリストとして活用。それにCMMIを加えることによって開発プロセスを改善した。生産性は、CMMI導入前と比較して140%以上向上し、50%以上のエラー削減を達成している。ITに対する内部統制を整備する(主に守り)だけでなく、CMMIを組み合わせることで、大幅な生産性と品質向上(主に攻め)を実現している。

運用委託先を含めたプロセス改善を


図2 CMMIの成熟度レベルとプロセス領域(PA)
[画像のクリックで拡大表示]

改善を進め、開発組織の成熟度を向上させる。

 CMMIの成熟レベル(ML)2のプロセスは、プロジェクト管理のプロセスを中心に、要件管理や構成管理、品質保証など、IT部門が本来マネジメントすべきプロセスを中心に定義している。ML3が定義するエンジニアリング・プロセスは、日本の多くのIT部門が、情報システム子会社やITベンダーに委託している部分だ(図2)。

 つまり、IT部門がシステム開発分野におけるITガバナンスを整備するためには、CMMIのML2のプロジェクト管理プロセスを中心に整備すると同時に、情報システム子会社やITベンダーと共同で、CMMIのML3のエンジニアリング・プロセスを整備する必要がある。

 ここで注意すべきは、システム保守を踏まえたうえでエンジニアリング・プロセスの開発標準を整備することだ。最近、マルチベンダー化が進んだ日本企業のIT部門では、開発を担当したITベンダーが使った開発標準をそのままシステムごとに採用し、組織としての開発標準が明確でない場合が多い。

 しかし、システム保守を情報システム子会社などに一括委託する場合、さまざまな開発標準で開発されたシステムを維持していくことは、品質上のリスクが高く、生産性も期待できない。組織のアーキテクチャ方針を踏まえた上で、保守を委託する可能性が高いITベンダーとの協調も必要になる。

プロセス改善における六つの観点


図3 IBMのコンサルティング手法ADEにおける六つの視点
[画像のクリックで拡大表示]

 システム開発プロセスの改善を支援するコンサルティング・サービスを提供していると、「改善活動が現場に徹底できない」、「開発支援ツールを導入したが効果が上がらない」、「苦労して作成した開発標準が陳腐化してしまう」といった声が聞こえてくる。

 その原因としては、利用方法(要件)を明確に定義しないまま開発手法や開発支援ツールを導入したり、導入した結果(目標)を数値で評価していなかったりといったケースが散見される。ユーザー部門には、「要件を決めないとシステムは構築できません」、「目標は何ですか」と問いかけることが多いIT部門にしても、いざ自らのプロセス改善においては「手法やツールさえ導入すれば品質や生産性が向上するのではないか」という錯覚に陥っている。

 システム開発プロセスにおけるIBMのコンサルティング方法論にADE(Application Development Effectiveness)がある(図3)。ADEは、(1)カルチャー、(2)方法論、(3)技術、(4)スキル、(5)組織、(6)評価の六つの観点から課題を分析し、プロセス善を進めるための解決策を検討する。

(1)カルチャー:企業・組織の目標・計画の明確性、取り組み姿勢、部門内・部門間のコミュニケーションなど、組織文化の問題
(2)方法論:システム開発・保守の手順や技法、標準化、文書化などソフトウエア・エンジニアリングやプロジェクト・マネジメントの問題
(3)技術:開発支援ツールや管理ツール、ハード/ソフトのプラットフォームなどのテクノロジの問題
(4)スキル:開発方法論や技術の教育・訓練といったスキル育成の問題
(5)組織:組織・人の役割、責任や体制、人材配置、チーム構成、チームワークの問題
(6)評価:アプリケーションの品質や開発生産性、見積もり、満足など管理指標の問題

 これら六つの観点のうち、カルチャー、組織、スキルの三つはいずれも、人やチーム、組織に関する問題を取り上げている。システム開発におけるITガバナンスの確立には、技術的な側面だけでなく、システム開発に携わるスタッフの業務プロセスそのものの分析・見直しが重要なことが分かる。ADEを活用した企業の中には、重大障害がゼロに、通常障害を80%削減できた例がある。

 最後に、筆者のコンサルティング経験に基づくCMMI導入における考慮点を挙げる。

(1)導入する目的と適用範囲を明確にする
(2)CMMIに対して「食わず嫌い」も「丸のみ」もいけない。組織に合わせて適用する
(3)整備したプロセスを棚上げするのではなく、常に見直しを行い現場で生きたものにする

 もちろん、CMMI導入が目的ではなく、手段であることは言うまでもない。

 次回は、システム運用における「ITへの対応」について解説する。

次回へ

渡部 直人
Naoto Watabe
IBMビジネスコンサルティング サービス
ADソリューション・コンサルティング
シニア・マネージング・コンサルタント

1986年横浜国立大学卒業。大手製造業の情報システム部門で、営業支援や生産管理を中心にシステム企画・開発を担当。2000年10月より日本IBMのビジネス・イノベーション・サービスのITコンサルタントとして従事。金融機関や官公庁などのITガバナンス導入やシステム開発の品質と生産性向上支援、システム監査などのコンサルティングを担当。02年IBMのPwCC買収により現職。『社長でもわかるIT−社長のためのやさしくわかるIT経営入門』(日本能率協会マネジメントセンター)の共著がある。ITコーディネータ、CISA、システム監査技術者、経済産業省情報処理技術者試験委員、ISACA東京支部理事