連載
» 2008年02月12日 12時00分 公開

情シス部門の地位向上(2):IT戦略は情シスが立案するものです (3/3)

[營田(つくた)茂生,@IT]
前のページへ 1|2|3       

鳥の目でIT戦略立案を

 まず、「全社のIT最適化」という言葉をEA(Enterprise Architecture)というすでに定義された言葉に置き換えてみます。EAとは、中長期的な視点で、IT戦略/IT投資のムリ・ムラ・ムダを省き、ビジネスやビジネス環境の変化に対応しやすいITシステムを作るための取り組みです。

ALT 図1 IT戦略の立案にはEAのフレームワークが手掛かりになる

 EAは情報システムを4つの階層で整理しています(図1)。複雑・つぎはぎだらけのITシステムも、1つ1つの要素は単純なはずです。エンハンスを繰り返すことで、それぞれの要素が複雑に絡み合ってしまうのです。

 前ページの最後で、「最適化されたIT」について、中長期的な視点で図を描けと提案しました。ここでは、「全体最適」「中長期的な視点」のイメージの膨らませ方について、実際のやり方を示します。まずは下の表をご覧ください。

    第1列 第2列 第3列 第4列 第5列 第6列
    WHAT
(データ)
HOW
(機能)
WHERE
(場所)
WHO
(組織・人)
WHEN
(時間)
WHY
(動機)
第1行 領域全体像(計画立案者の視点) ビジネスに影響を及ぼす要素の列挙 ビジネスプロセスの列挙 ビジネス拠点の列挙 組織の列挙 ビジネスの周期、重要な
イベントの列挙
ビジネスの目標と戦略
第2行 ビジネス・モデル(経営者、利用者の視点) 意味的モデル ビジネスプロセス・モデル 拠点間の物流システム 組織間のワークフロー・モデル マスタ・スケジュール ビジネス・プラン
第3行 システム・モデル(設計者の視点) 論理データモデル アプリケーション・アーキテクチャ 分散システム・アーキテクチャ 命令指示係数や協業体制 作業スケジュール ビジネス・ルール・モデル
第4行 技術モデル(開発者の視点) 物理データモデル システム設計 テクノロジ・アーキテクチャ 画面インターフェイス 進行管理システム ルール設計
第5行 詳細(作業担当者の視点) データ定義 プログラム ネットワーク・アーキテクチャ セキュリティ・アーキテクチャ(認証システム) 処理タイミング ルール定義
第6行 稼動システム データ 機能 ネットワーク 組織 スケジュール 戦略


 これはザックマン・フレームと呼ばれるものです。EAを設計・構築・評価するためのガイドラインです。組織=enterpriseという複雑な構造物を要素の範囲や関係で分類・整理しています。ザックマン・フレームワークは、企業階層・関与者の観点を縦軸、5W1Hの観点を横軸に取った6行×6列のマトリクスで表現します。各項目が抽象化されているので、業種・業界を問わずさまざまな組織構造を整理・分析するのに便利です。対象とする組織やシステムの規模も問いません。

 図1に示すEAのフレームワークに従い、現状(AsIs)モデルと理想(ToBe)モデルも整理しておく必要があります。これらを体系化しておくことで、現状のどこに問題があるのか、現状?次期モデル?理想モデルへはどのように進んでいけばよいのか、頭の整理ができるのではないかと思います。

 続いて、情報システムにおける「先行投資」の範囲のイメージを考えましょう。図2は、プロダクト・ライフサイクルプロダクト・ポートフォリオ・マネジメント(PPM)の図です。

ALT プロダクト・ポートフォリオ・マネジメント
図2 ITシステムの「ライフサイクル」を考える

 プロダクトにはライフサイクルがあります。企業のITシステムにも、さまざまな企業が納入したハードウェア、ソフトウェアが使われています。オープンソース・ソフトウェアを使用するケースもあるでしょう。情報システムに対する中長期的な視点をアシストするため、プロダクト・ライフサイクルの考え方とプロダクト・ポートフォリオ・マネジメント(PPM)を使ってはどうかというのが、筆者の提案です。通常、プロダクト・ライフサイクルやPPMは、自社の製品およびライバル社の製品の分析・検討に用いることが多いのですが、これを自分たちが使っているIT技術や採用を検討しているIT技術に応用してみようということです。

 いま使っている技術は数年後も使えるものなのか? 漠然と予想してもなかなか当たりません。しかし、プロダクト・ライフサイクルのグラフを思い浮かべ、いま使っている技術/これから使おうとしている技術が今どのライフサイクルにいるのかを考えれば、別の手を仕込んでおくべきか、あるいは、しばらくそのままで行けるのか、を考える材料になるのではないかと思います。

 衰退期を迎えているIT技術/ITシステムがある場合、早めに手を打っておく必要があります。2000年問題が好例です。2000年問題として騒がれる前から、西暦が2000年を迎えることは分かっていました。年情報を2けたで持っているプログラムが多いということも分かっていました。早い段階でアプリケーション・プログラムやデータベース、データファイルの年情報の4けた化に取り組んでいた企業があった一方、1999年になってから高いコスト(いわゆる特急料金)でシステム更新を行う企業がありました。企業としてどちらが得なのか、自明ではないでしょうか?

パレートの法則で手を抜く

 パレートの法則は、「ビジネスにおいて、売り上げの80%は全顧客の20%が生み出している。よって売り上げを伸ばすには顧客全員を対象としたサービスを行うよりも、20%の顧客に的を絞ったサービスを行う方が効率的である」といった説明がなされている法則です。イタリアの経済学者、社会学者、哲学者だったヴィルフレド・パレートが、統計分析によって理論化したものです。

ALT 図3 とりあえず20%の項目を検討してみる

 パレートの法則が当てはまるのは、売り上げだけではありません。厳密に20:80ということではありませんが、障害発生や仕事の成果など、多くの事象がパレートの法則に当てはまります。

 「手を抜く」といってしまうと言葉が悪いのですが、EAとしての主要検討項目の20%を達成することで、残りの80%をサポートできる可能性があります。枝葉末節にこだわって時間を浪費するよりは、主要な20%に注力する方が効果的です。

 ここで大切なのは、何を「主要」とするのかということです。企業によって何が「主要」なのかは異なりますが、以下の複数の視点から組み合わせて選択するとよいでしょう。

  • 利用者数
  • コスト(システム開発、運用、移行など)
  • ボトルネック
  • (そのシステム・関連部門)が稼ぎ出す売り上げ・利益
  • 複数システムで共通利用されるリソース
  • 複数システムで共通適用されるアーキテクチャ
  • データのライフサイクル

 今回は、IT戦略を情報システム部門に取り戻してはどうか、という話をしました。次回は、少し視点を変えて、ITガバナンスとコンプライアンスについて、情報システム部門の役割の重要性を明らかにします。

著者紹介

▼著者名 營田(つくた) 茂生

日立ソフトウェアエンジニアリング株式会社

セキュリティサービス本部 シニアコンサルタント

大学時代は構造化プログラミングを学ぶ。日立ソフト入社後、 主として保険、証券会社システムのシステムエンジニアリングに従事後、現在は「セキュア・プロジェクト・オフィス」コンセプトの展開を推進中。


前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ