高度午前 - システム戦略

「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る

目次 †

概要 †

システム戦略（高度：午前Ⅰ、午前Ⅱ）

システム戦略 †

システム管理基準 †

• システム管理基準 - 経済産業省
  https://www.meti.go.jp/policy/netsecurity/downloadfiles/system_kanri_h30.pdf

情報戦略 †

• 全体最適化計画
  • 組織全体の情報システムの、あるべき姿を明確にする計画。
  • 例えば、投資効果やリスク算定の方法を明確にする。

企画業務 †

• 分析
  • パッケージ・ソフトウェアとユーザ・ニーズの適合性を評価

• 開発計画
  • 目標達成のための実現可能な代替案の検討
  • ユーザ部門と情報システム部門の役割分担を明確にする。

情報戦略 †

• 事業継続計画

運用業務 †

• 運用計画（運用管理）

IT投資 †

評価 †

標準化されたものは無いが、

• 「IT投資価値評価ガイドライン」（経産省委託調査、日本情報システム・ユーザー協会）
• 「IT投資マネジメント・ガイドライン」（日本情報処理開発協会）

などがある。

• 事前評価
  目標設定とフィジビリティ・スタディ

• 中間評価
  • 達成状況（計画・実績の差異・原因）の分析・評価
  • 改善策の検討や、投資額・目標の変更の実施

• 事後評価
  投資効果の実現時期にデータ収取して評価を行う。

KPI区分 †

• 戦略的投資のKPI
  • 競争優位の確立
  • ビジネスの導出

• 業務効率投資のKPI
  • 業務の効率の向上
  • 業務の生産性の向上

• 情報活用投資のKPI
  • ナレッジの共有
  • 管理精度の向上

• IT基盤投資のKPI
  ITコスト削減
  • 障害件数減少
  • システム性能向上

投資対効果の評価 †

• 費用便益分析（BCR :Benefit-Cost Ratio）
• 正味現在価値（NPV : Net Present Value）
• 内部収益率（IRR : Internal Rate of Return）
• 投下資本利益率（ROI : Return on Investment）
• 自己資本利益率（ROE : Return On Equity）
• 総資産利益率（ROA : Return On Asset）
• 投資回収期間（PBP : Pay Back Period）

• 経済的付加価値（EVA : Economic Value Added）
  アーンド・バリュー分析（EVA）ではなく。
  • 企業が生み出す経済的価値を測定する指標のひとつ。
  • 比較的新しいが、利益から資本コストを差し引くという概念は古典的
  • 経済的付加価値
    • = 税引後利益 - ( 資本コスト * 投資資本 )
    • = ( 純資産利益率 - 資本コスト ) * 投資資本

参考 : PMP：利益測定法（意思決定モデル）

CPとBCP †

• 事業継続計画（BCP : Business Continuity Plan）
• 事業継続マネジメント（BCM : Business Continuity Management）
• 緊急時対応計画（CP : Contingency Plan）

BCPのRXO †

Recovery XXX Objective

• 時間（RTO : Time）
  最低限必要な業務を復旧させるまでの時間（期間）

• ポイント（RPO : Point）
  最低限必要な業務を復旧させるまでの時間（時点）

• レベル（RLO : Level）
  復旧（最低限必要な業務）のレベル

エンタープライズ・アーキテクチャ（EA） †

エンタープライズアーキテクチャ
（EA : enterprise architecture)

• 概要

• 社会環境や情報技術の変化に素早く対応できるよう
  「全体最適」の観点から業務やシステムを改善するフレームワーク

• モデリングにより
  • 業務とシステムの現状（As-Is）とあるべき姿 （To-Be）を整理し、
  • あるべき姿（To-Be）の実現を目指して業務およびシステムの改善を図る。

• 以下を含む、事業構造の厳格な記述
  • 構成要素(事業エンティティ）、
  • 構成要素の外的に見える特性、
  • 及びそれらの間の関係

• エンタープライズの進化のための原則・ガイド

• コンテンツ
  • 用語
  • 構成要素(事業エンティティ）
  • 外的環境とのそれらの関係
  • 要求分析、設計

• 対象
  • 事業体の目標
  • 事業プロセス
  • 役割
  • 組織的構造
  • 組織的振舞
  • 事業情報
  • ソフトウェア・アプリケーション
  • コンピュータ・システム

• モデリング

• 事業：ビジネスアーキテクチャ（政策・業務体系）
  • 政策・業務の内容、実施主体、業務フロー等について、
    共通化・合理化など実現すべき姿を体系的に示したもの。
  • 構成要素…業務説明書、機能構成図、機能情報関連図、業務フローなど

• 情報：データアーキテクチャ（データ体系）
  • 各業務・システムにおいて利用される情報すなわちシステム上の
    データの内容、 各情報（データ）間の関連性を体系的に示したもの。
  • 構成要素…情報体系クラス図、エンティティ・リレーション図、データ定義表など

• 処理：アプリケーションアーキテクチャ（処理体系）
  • 業務処理に最適な情報システムの形態を体系的に示したもの。
  • 構成要素…情報システム関連図や情報システム機能構成図など

• 技術：テクノロジアーキテクチャ（技術体系）
  • 実際にシステムを構築する際に利用する諸々の技術的構成要素
    （ハード・ソフト・ ネットワーク等）を体系的に示したもの。
  • 構成要素…ネットワーク構成図、ソフトウェア構成図、ハードウェア構成図など

• その他
  • EA参照モデル
    政府が公開しているEAのひな型

• 現状（As-Is）モデル
  あるべき姿 （To-Be）モデル

• ザックマンモデル
  EAの基礎となっているフレームワーク
  以下の5-6行6列マトリクスで表現される。
  ・企業階層の観点を縦軸（5-6行）
  ・5W1Hの観点を横軸（6列）

FEAF †

連邦エンタープライズアーキテクチャ
(FEA : Federal Enterprise Architecture)

• 米政府のEAフレームワーク
• 情報技術の取得、利用、及び廃止の共通の方法論を提供。
• 良い説明が無い（参考書とWikiの説明が乖離している）。

モデル †

• TO-BEモデル
  業務と情報システムの理想を表すモデル。

• EA参照モデル
  効率的にEAを策定できるようにしたEAのひな型。

• ザックマン・モデル
  EAの提唱者であるザックマンによるEAモデル

業務プロセス †

問題解決技法 †

• TRIZ

• ソ連発の技法
  • 問題解決理論
  • 全体最適化理論
  • システム思考
  • クリエイティブシンキング

• Teoriya Resheniya Izobretatelskikh Zadatch
• 英語
  • Theory of solving inventive problems
  • Theory of inventive problems solving

• PMP：品質マネジメント
  品質管理活動の手法・TTが含まれるもよう。

要求分析、設計技法 †

• BPMN
  グラフィカルな記法

• BPEL
  • XMLに基づいた言語によりビジネス・プロセスを定義
  • 根本的な違いから、BPMNとのマッピングは困難

• 状態遷移図
  • グラフィカルな記法
  • UMLなど、いくつかの異なる形式のものがある。

• その他、ツール的なモデル
  • DFD
  • ER
  • UML
  • 各種ブレークダウン・ストラクチャ
  • モジュール・構成図

BPR †

• Business Process Re-engineering
• ビジネス・プロセスを見直し抜本的に設計しなおす。

プロセス改善 †

IDEALモデル †

CMMIで標準的に活用される。

• 開始フェイズ（I : initiating）
  • 改善活動の背景を明らかにして改善の動機付けを行う。
  • 主催者の態度を固め、支援体制・活動体制を確立する。

• 診断フェイズ（D : diagnosing）
  • 評定や診断などを実施して改善活動の対象である組織/プロジェクトの現状を評価する。
  • 改善後の状態（ゴール）と比較して、ギャップや改善ポイントを明らかにする。

• 確立フェイズ（E : establishing）
  • 診断結果から優先順位と取り組み方を策定する。
  • 具体的なプロセス改善活動の計画を作成する。

• 行動フェイズ（A : acting）
  • 改善活動の計画に従って解決策を作り、実施する。
  • プロセス中心アプローチと問題中心アプローチの2つがある。

• 学習フェイズ（L : learning）
  • ココまでの活動を分析してその妥当性を確認し、次のサイクルの準備を行う。
  • 継続的改善を定着させる（レベル向上の計画、効果・効率的な方法の整理・提案）

PDCAサイクル †

典型的なマネジメント・サイクルの1つで

• 計画（plan）
• 実行（do）
• 評価（check）
• 改善（act）

のプロセスを順に実施する。

OODAループ †

元々は軍事行動における指揮官の意思決定を対象としていたが、
後にこれに留まらず、ドクトリン、そして創造的行動哲学となった。

• Observe （観察）
• Orient （状況判断、方向づけ）
• Decide（意思決定）
• Act （行動）

のプロセスをループさせる。

システム化 †

SOA †

サービス指向アーキテクチャ
SOA : Service-Oriented Architecture

• 大規模なコンピュータ・システムを構築する際の概念あるいは手法。
• 業務上の一処理に相当するソフトウェアの機能をサービスと見立て、
  そのサービスをネットワーク上で連携させてシステムの全体を構築していく

データ活用 †

• データ・サイエンティスト

• ビジネス力
  ビジネスの理解

• データ・サイエンス力
  人工知能や統計学の理解

• データ・エンジニアリング力
  ビッグデータ基盤の理解

システム企画 †

システム化構想・計画 †

構想 †

システム化構想の立案プロセス

• プロセス開始の準備
  • 企画作業の組立て
  • 必要なプロセスの組込み
  • 企画環境の準備
  • プロセス実施計画の作成

• システム化構想の立案
  • 経営上のニーズ，課題の確認
  • 事業環境，業務環境の調査分析
  • 現行業務，システムの調査分析
  • 情報技術動向の調査分析
  • 対象となる業務の明確化
  • 業務の新全体像の作成
  • 対象の選定と投資目標の策定

• システム化構想の承認
  • システム化構想の文書化と承認
  • システム化推進体制の確立

計画 †

システム化計画の立案プロセス

• プロセス開始の準備
  • 企画作業の組立て
  • 必要なプロセスの組込み
  • 企画環境の準備
  • プロセス実施計画の作成

• システム化計画の立案
  • システム化計画の基本要件の確認
  • 対象業務の内容の確認
  • 対象業務のシステム課題の定義
  • 対象システムの分析
  • 適用情報技術の調査
  • 業務モデルの作成
  • システム化機能の整理とシステム方式の策定
  • 付帯機能，付帯設備に対する基本方針の明確化
  • サービスレベルと品質に対する基本方針の明確化
  • プロジェクトの目標設定
  • 実現可能性の検討
  • 全体開発スケジュールの作成
  • システム選定方針の策定
  • 費用とシステム投資効果の予測
  • プロジェクト推進体制の策定
  • 経営事業戦略，情報戦略及びｼｽﾃﾑ化構想との検証

• システム化計画の承認
  • システム化計画の文書化と承認
  • プロジェクト計画の文書化と承認

全社データモデルの作成 †

• エンティティは業務上の機能や処理ではなくデータ。
• AS-ISだけではなくTO-BEも含めて全体計画を作成する。

IT投資ポートフォリオ †

• IT投資に関するポートフォリオで、金融ポートフォリオを応用したもの。
• 目的は、戦略的目標を達成することにあるが、単体の意味合いとしては、
  価値・リスクなどで分類したIT投資（企業レベルのリソース配分）

投資対効果の評価 †

要件定義 †

要件定義プロセス †

• プロセス開始の準備
  • 要件定義作業の組立て
  • 必要なプロセスの組込み
  • 要件合意及び承認ルールの決定
  • 要件定義環境の準備
  • 要件定義プロセス実施計画の作成

• 利害関係者の識別
  • 利害関係者の識別

• 要件の識別
  • 要件の抽出
  • 制約条件の定義
  • 代表的活動順序の定義
  • 利用者とシステム間の相互作用の識別
  • システムの使用が周辺に及ぼす影響への対処

• 要件の評価
  • 導出要件分析

• 要件の合意
  • 要件の問題解決
  • 利害関係者へのフィードバック
  • 要件の確立

• 要件の記録
  • 要件の記録
  • 要件の追跡可能性維持

要求分析技法 †

• KAOS法
  • ゴール志向の要求獲得手法
  • 要求獲得手法には、以下のモノがある。
    • ユースケース分析法
    • オブジェクト指向分析法

• CRUDマトリックス
  • データとプロセスの対応関係を検証する。
  • 機能（プロセス）の実装漏れを防ぐ効果

• 要求の分類・整理の技法

• FURPS＋モデル
  • ［F］機能性（functionality）
  • ［U］使いやすさ（usability）
  • ［R］信頼性（reliability）
  • ［P］性能（performance）
  • ［S］保守性（supportability）
  • ［+］プロジェクト上の制約（plus constraints）

• MoSCoW法
  要求を重要度や優先度によって以下に分類して
  • Must（必須）
  • Should（妥当）
  • Could（願望）
  • Won't（不要）

各種要件 †

• 業務要件
  アクティビティ図などを用いて、業務フローを記述する。

• システム要件
  業務要件を満たすため、ITシステムが持つべき機能要件や非機能要件を定めたもの。

• 利用者要件
  利用者の観点から、ソフトウェアに対するニーズ。
  この要件は、機能要件と非機能要件の両方が対象になる。

• 機能要件
  • 前提は、構想計画から、業務・運用上、実現すべき要件。
  • 業務の観点からソフトウェアが何をするか？
  • システムで実現して利用者の業務・サービスに提供する機能。

• 非機能要件
  性能面やセキュリティ面等において実現するべき要件。

• 非機能要件要求仕様定義ガイドライン(JUAS)
  • 機能性
  • 信頼性
  • 使用性
  • 効率性
  • 保守性
  • 移植性
  • 障害抑制性
  • 効果性
  • 運用性
  • 技術要件

• 非機能要求グレード
  （システム基盤の発注者要求を見える化する非機能要求グレード検討会）
  • 可用性
  • 性能・拡張性
  • 運用・保守性
  • 移行性
  • セキュリティ
  • 環境・エコロジー

BABOK †

• BABOK（Business Analysis Body Of Knowledge）
• 「IIBA（International Institute of Business Analysis」により制定
• ビジネスアナリシスの
  • 計画とモニタリング
  • 引き出し
  • 要求アナリシス
  • 基礎コンピテンシ
  • などの七つの知識エリアから成る。

• ちなみに

• PMBOKは九つの知識エリアから成る。

• その他、以下の様なBOK（Body Of Knowledge）がある。
  • ソフトウェア品質知識体系 SQuBOK（日本科学技術連盟）
  • ソフトウェア工学知識体系 SWEBOK（IEEE & ACM）

調達の計画・実施 †

入札文書 †

• RFI：Requset For Informattion / 情報提供依頼書
• RFP：Request For Proposal / 提案依頼書
• IFB：Invitation for Bid / 入札招請書
• RFQ：Request For Quotation / 見積要求書

契約関連 †

• 契約タイプ

• 多段階契約
  段階的詳細化で生じる各種前提条件の変更により、
  工程開始前のタイミングで再見積もりを可能にする契約。

環境関連 †

• グリーン購入法

• 持続可能な発展による循環型社会の形成を目指し、供給面だけでなく、
  国等が自ら率先して環境物品等を優先的購入することで需要面からも
  環境物品等の市場を促進することを目的に、2000年5月制定された。

• 環境物品とは、環境負荷の低い（若しくは負荷を低減する）原料、部品、製品、役務。

• グリーンIT

• 地球環境への配慮の思想を情報通信技術に適用した思想

• はっきりとした定義はないが、アメリカの環境保護庁（EPA）の、
  「IT機器の導入、運用、廃棄に至るまでを含めた環境への
  負荷を減らすための包括的な考え方」が一般的な定義とされる。

• 企業イメージの向上や、場合によってはコスト削減にもつながるため、
  投資に余裕のある先進国の大手企業が中心となって広く導入されつつある。

• マーケティング関連

EMS (製造業) †

参考 †

共通フレーム 2013 †

共通フレーム 2013 のテクニカル・プロセス辺り

• システム企画は、テクニカル・プロセスに含まれる。
• テクニカル・プロセスはシステム開発に関する内容。

• テクニカル・プロセスには、各プロセスが規定されている。
  • 企画
  • 要件定義
  • システム開発
  • ソフトウェア実装
  • ハードウェア実装
  • 運用サービス
  • 保守