IT経営戦略バイブル

前回はＥＥＭ（Ｅｎｔｉｔｙ　Ｅｖｅｎｔ　Ｍａｔｒｉｘ）の設計の考え方を取り上 げました。
今回はＥＥＭの中で紹介されている抽象化のためのモデルである「ＥＥＭ２」を取り上げます。

　前回取り上げましたＥＥＭモデルはＥＥＭ１といい、業務プロセスにおけるイベント情報（＝トランザクション情報）とスタンディング情報（＝マスター情報）の情報フローの関係をそのまま記述する手法でした。
このEEM１に対して、EEM２はＥＥＭ１の発展系で、イベント情報の抽象化とトランザクション処理の抽象化を図った設計モデルです。
こう申し上げても何のことやら分りませんので、まず、“抽象化”の概念を掴んでみましょう。

　（１）データ属性の抽象化
　 抽象化ですから、より観念的な捉え方ですので、人を例にとって説明を加えてみま しょう。
“松井秀樹”、“鈴木一郎”という名前の捉え方は具体的な捉え方ですが、“野球選手”といえば抽象的になります。この表現を“人”という名称で括るともっと観念的な上位レベルの抽象化が出来ます。

この考え方を受発注業務に適用してみましょう。
受注業務の処理は受注伝票を受付け、承認する受注担当者があり、在庫がない場合に商品を発注承認する発注担当者、仕入商品の受入・検収の承認をする検収担当者というように、それぞれの事態としての承認者がいて、職務として配置されているわけです。
情報システムで捉えますと、マスターファイルであるスタンディング情報にこれらの担当者名である“受注担当”、“発注担当”といった属性名（＝フィールド項目名）が組み込まれています。この属性名を抽象化すると“承認者”という属性名称で抽象化すれば1つのフィールド項目で整理でき、スタンディング情報の属性項目は非常にシンプルに設計できます。

具体的なマスターファイルの構築の観点では“承認者”の項目テーブル作り、各業務の承認者を登録しておき、担当の業務処理をするとき、“承認者”テーブルから該当の業務承認者を取り出すようにすれば良いわけです。この業務処理とはトランザクション処理のことですので、トランザクションシャリの抽象化と関連付けてみましょう。

　（２）トランザクション処理の抽象化
　トランザクション処理は受注、発注、検収といったイベント、すなわち人の介入（＝入力）によって発生します。このときのイベント情報の承認者属性名には“受注担当者”、“発注担当者”、“検収担当者”がそのイベント毎にスタンディング情報から抽出されてくる必要があります。
ということは、イベントによって具体的な属性が決まるのですから、トランザクション処理のタイプ毎に存在する属性を抽象化し、スタンディング情報のレコードとして持てば良いことになります。
たとえば、イベント情報として、「組織番号」、「組織名」、「承認者」が必要としますと、スタンディング情報としては「イベントコード」、「組織番号」、 「組織名」、「承認者」の形式でイベントコード毎の具体的属性を持ったレコードがあれば、イベント情報との連携が取れることになります。
このようにして設計されたシステムは“ワンライティングシステム”を構築できます。

というのは、イベントが発生するとき、イベントコードと追加項目を入力または自動認識するシステムにしますと、スタンディング情報から必要とする具体的な項目は自動的に抽出することが可能になるからです。
少し、ソフトウエアエンジニアリング的思考の強い話になりました。

経済産業省の電子政府の設計ではこのＥＥＭが取り上げられていましたので紹介しました。
第６０回はここで終了します。ＥＥＭの抽象化設計の考え方を取り上げました。
次回は、最近の世界のシステム設計の中心的存在であるオブジェクト設計を取り上げます。

Comments(0)

　前回はＥＥＭ（Ｅｎｔｉｔｙ　Ｅｖｅｎｔ　Ｍａｔｒｉｘ）の設計モデルの考え方を取り上げました。
　今回はシステム設計手法として世界のデファクトスタンダードである「オブジェクト
　設計の考え方」を取り上げます。

　１０年以上前になりますが、私が始めて「オブジェクト設計」のセミナーを受けまし
　たとき、さっぱり全体像がつかめず、“情報システムに使うには程遠い思考法だ
　な・・・・”と思ったものでした。

　３、４年前にUML（Unified　Model　Language）が翻訳されて発売され、至るところの
　書店にこの関係の本が展示されました。
　UMLはオブジェクト指向設計を分り易く表記する手法として開発されました。この表記
　法を携えてオブジェクト志向設計を捉えると自分なりに良く理解できるようになりま
　した。今回はこの理解できるようになった経緯を追って、オブジェクト指向設計の話
　をしてみようと思います。

（１）オブジェクト指向設計の要素
　オブジェクトは“実体”と日本では翻訳されています。実体ですから、人間、自動
　車、犬も猫もみんなオブジェクトとなります。
　さて、“実体を設計するとはどういうことでしょうか？”
　実体として、自動車を取り上げ設計してみましょう。自動車を自動車足らしめるため
　には“その構成要素”と“その働き”を定義しないと設計できません。
　“構成要素”には「車体」、「ハンドル」、「エンジン」、「タイヤ」、「シャー
　　シ」、「ラジエター」などが上げられますし、
　“働き”には「加速・減速が出来る」、「曲がる」、「走る」、「止まる」、「ガソ
　　リンを動力に変える」などがあります。
　自動車は自分の構成要素を持って、自分の働きが出来る実体となっています。
　ただ、この働きは人間が外から加速するためにアクセルを踏んだり、曲がるために
　ハンドル操作することでこの働きが出来ます。すなわち、自動車という実体へ人間が
　“加速しろ”や“曲がれ”という指令があり、実体の構成要素のアクセルやハンドル
　を操作する自動車の機能を果たしています。

（２）オブジェクト間の関係
　実体は外から指令を受けることで自分が持っている実体の働きを遂行しています。
　これは人間社会も同じです。セールスマンという実体に対して、上司は“売って
　来い”という指示しか出しませんし、それで指示されたセールスマンは十分理解でき
　ます。
　SEに対しても“納期どおりシステムを稼動させてくれ”という指示を出すだけです。
　なぜなら、セールスマン、ＳＥという実体はその指令を受けてその指令を実行できる
　知識（＝構成要素）とその実行能力（＝働き）を持っているからです。
　ということは、知識を持っている実体を中心に考えて、そのオブジェクトに対して
　“指令”を出して、オブジェクト間に“指令”の関係を作ると一つのシステムが出来
　上がることになります。
　すなわち、「人間社会のオブジェクトの関係はそれ自体で指令を完結できる働きを持
　ち、指令で関係付けられている社会です。」　
　このような関係性を持ったシステム化の設計志向がオブジェクト指向設計なのです。

　オブジェクト指向設計ではこの実体、たとえば前項の例の自動車を例に取ると、自動
　車を“クラス”、構成要素を“属性”、働きを“操作や機能”と言います。
　情報システムの観点で考えますと、
　・知識（＝属性）とはデータです。もっと正確に言うと、顧客マスターの“顧客
　　名”、“顧客住所”、“社長名”、“売上高”等のデータ項目、すなわち属性は
　　データ項目となります。
　・働き（＝機能）とは処理きのうですから、“顧客データ検索”、“顧客リスト一覧
　　作成”、“仕切値検索”などは機能となります。

第６１回はここで終了します。オブジェクト指向の概念を取り上げました。
次回は、情報システムにおけるオブジェクト志向設計を「オブジェクト設計―その２」として取り上げます。

Comments(0)

　前回はオブジェクト指向の考え方、すなわちその概念を取り上げました。
　今回は情報システムにおけるオブジェクト指向設計の考え方を取り上げようと思いま
　す。
　オブジェクト指向設計の基本は“知識を持っている実体を中心に考えていく”ことで
　した。
　情報システムに置き換えますと、知識（＝属性）はデータでしたから、顧客データ
　項目、商品データ項目、在庫データ項目、受注データ項目等が相当することになり
　ます。実体としては顧客マスター、商品マスター、在庫ファイル、受注ファイル等で
　すので、これらのマスターやファイルをオブジェクトと考えれば良いことになり
　ます。

（１）オブジェクトの関係
　　さて、“このオブジェクトの働き（＝機能）は何でしょうか”
　　オブジェクト指向では指令（＝操作）がオブジェクトに対して与えられます。それ
　　はそのオブジェクトがその機能を果たすことが出来るからでした。
　　ということは、他からの指令を機能として取り込めば良いことになります。顧客
　　オブジェクトであれば、「顧客与信情報検索」、「顧客住所検索」、「顧客リスト
　　一覧」、「顧客情報更新」などがあります。
　　受注オブジェクトですと、その機能は「受注情報検索」、「受注登録」、「受注
　　更新」などが可能です。
　　オブジェクト指向設計ではこれらの機能を属性と合わせ、オブジェクトの設計図と
　　してのクラスを構成します。たとえば、顧客クラスや受注クラスがそれに該当し、
　　属性と機能で設計されます。このクラスは他からの指令を与えられて働きをし、
　　成果を出す実体、オブジェクトとなります。
　　従って、このクラス間は他のオブジェクトからの指令（＝機能）によるオブジェク
　　トとの関係を作ることになります。
　　たとえば、受注入力を受注クラスに対して行うと、受注オブジェクトは在庫クラス
　　に対して在庫引当の指令を出します。在庫オブジェクトは引当を行い、出荷指示を
　　出すという流れになります。
　　このような、クラスに対するオブジェクトに対する指令の関係設計がオブジェクト
　　指向設計です。
　それでは、“何故、このオブジェクト指向設計が必要とされているのでしょうか？”

（２）なぜオブジェクト指向設計が必要か
　　従来のシステム設計をオブジェクト設計と比較しながら見てみましょう。従来の
　　システム設計ではデータベースと処理を分離しています。すなわち、受注処理は
　　顧客ＤＢ、在庫ＤＢ、受注ＤＢ等を参照し更新します。オブジェクトで言う属性と
　　機能をまったく分離して設計していることになります。いわゆるデータベース中心
　　のデータオリエンテッド設計です。この設計は機能（＝処理）と属性（＝データ
　　ベース）が複数の相互関係を持つことになります。そうしますと、ＤＢの一部が
　　変更になると全ての処理を変更しなければなりませんし、処理の変更が発生し、
　　ＤＢの一部変更が生じますと同様に全ての処理変更となります。
　　一方、“オブジェクト指向設計したシステムはどうでしょう。”
　　属性と機能が一体となっていますから、そのクラスの機能変化です。
　　すなわち、システム機能の変更に対し、その対応のクラス変更のみになりますから
　　最小の変更で対処できることになります。
　　オブジェクト設計が大きく騒がれている意味がご理解できると思います。

　インドや中国の大勢はこの設計が中心となり、オブジェクト指向設計大国である米国
　のソフト産業の2割の労働力がシフトされているようです。
　
第６２回はここで終了します。オブジェクト指向設計の重要性を取り上げました。
次回は、このオブジェクト指向設計を効率的に具現化する「ＵＭＬ―その１」を取り上げます。

Comments(0)

　前回までの２回はオブジェクト指向の概念を取り上げました。
　今回からはこのオブジェクト指向を具体化する表記法であるＵＭＬ（Ｕｎｉｆｉｅｄ
　Ｍｏｄｅｌ　Ｌａｎｇｕａｇｅ）を取り上げようと思います。
　まず、ＵＭＬの起源から始めます。ＵＭＬは1980年代後半から1990年代初めにかけて
　登場し、ＯＭＧ（Ｏｂｊｅｃｔ　Ｍａｎａｇｅｍｅｎｔ　Ｇｒｏｕｐ）が標準化を行
　っている表記言語で、方法論でなく、モデリング言語とプロセスにより構成されてい
　ます。
　ｃｆ：モデリング言語とは設計を表現するための方法論で使われるグラフィカルな
　　　　表記法をいう。
　この表記法が発表される前のオブジェクト設計はオブジェクト設計の考え方を具体化
　するＪＡＶＡやＣ＋＋といったプログラム言語で使っていました。この表記法が出た
　おかげで、オブジェクト指向をプログラム言語へ置き換えていく橋渡しができ、オブ
　ジェクト設計が急速に広まりました。
　ここでは、ＵＭＬの代表的な表記としての「クラス図」、「クラス関連表記」、「シ
　ーケンス図」を取り上げようと思います。

（１）クラス図の構造
　オブジェクト指向設計でオブジェクト（＝実体）を表現する構造として、クラスと
　いう考え方を取り上げました。クラス図とはオブジェクトの設計図の位置づけになり
　ます。
　ＵＭＬではクラス図は角を丸めた長方形で表し、その中を3つの区画に分割して表現
　します。
　その区画は上から下へ「クラスの区画」、「属性の区画」、「操作の区画」に区分
　され、オブジェクトを表現していきます。
　・「クラスの区画」ではそのクラスをあらわす名称を記述し、クラス名を表します。
　　　たとえば、顧客クラス、商品クラス、在庫クラスなどはクラス名です。
　・「属性の区画」ではクラスのデータ項目を記述します。
　　　たとえば、顧客クラスですと「顧客名」、「顧客住所」、「担当者名」など顧客
　　　マスターのデータ項目を想像すれば良いでしょう。
　・「操作の区画」ではこのクラスが実行する機能を記述します。
　　　たとえば、顧客クラスでは「顧客マスター登録」、「顧客一覧表作成」、「顧客
　　　情報検索」などが記述されます。この機能はオブジェクト設計でお話しました
　　　ように他のクラスや外部からこのクラスに要求される指令が定義されます。この
　　　指令とその処理の実行の設計は後段の「シーケンス図の項」に譲ります。
　クラス図の構造と記述の概要はご理解できたと思いますが、情報システムを設計する
　開発工程において、“このクラス図はオブジェクト設計のどのフェーズに位置づけら
　れるのでしょうか” これを次のテーマとしましょう。
　　
（２）クラス図の位置づけ
　ＵＭＬに基づいた設計ではクラス図は全設計工程で継承して使用されていきます。
　従来のウォータフォール型設計で言いますと、要件定義、基本設計、詳細設計まで、
　クラス図が各フェーズで段階的に詳細化されて継承されるということです。
　ウォータフォール型設計では各設計フェーズで異なった仕様書を用い継続性を保つ
　のはかなり困難でしたので変更の管理が大変でした。
　顧客クラスを例にとって、クラス図の要件定義、基本設計、詳細設計の各フェーズに
　おける使用をイメージ的に見ていきましょう。

　◆属性の仕様の変化
　　顧客クラスの顧客名称を例にとって、それぞれのフェーズでの表示を例示して
　　みますと
　　（要件定義）　　　　（基本設計）　　　　　　　　（詳細設計）
　　　顧客名　　　→顧客名（Chara10桁）　　　　→Custname　char（10）
　◆操作の仕様の変化
　　　（要件定義）　　　　　　　　（基本設計）　　　　　　（詳細設計）
　　　顧客マスター更新（）→顧客マスターを読む（引数１）→Read　 customer（ａ）
　　　　　　　　　　　　　　顧客マスターを更新（引数２）→Write　customer（ｂ）

　クラス図の各設計段階における変化イメージ記述しました。お分かりのように従来の
　記述法と違って仕様が継承されているのがお分かりになると思います。
　　
第６３回はここで終了します。ＵＭＬのクラス図を取り上げました。
次回は、このクラス図の関係を「ＵＭＬ―その２」として取り上げます。

Comments(0)

前回はＵＭＬのクラス図を取り上げました。今回はこのＵＭＬのクラス図の関係を
取り上げようと思います。
この関係の表記にはいくつかありますが、その中で代表的な関係表記である“多重
度”、“汎化”、“集約”を取り上げようと思います。この関係表記はクラスを体系
的に整理するために使用されます。

クラスには属性の定義と操作（＝機能）の定義がありました。従来の情報システムで
いえばデータベースサブシステムのようなものです。データベースですから、クラス
の属性であるデータ項目にはキーデータ項目が含まれています。情報モデルの項でも
述べましたように、データベース間にその含まれるレコードの関係が成り立ちまし
た。クラスも属性を有するレコードがたくさんあると考えて良いわけですから、クラ
ス間の関係が存在することになります。

（１）多重度の表記
この表記はクラス間のキー項目属性の関係を表すものです。
たとえば、受注伝票の項目属性を持つ受注クラスと顧客レコードの項目属性を持つ
顧客クラスの関係は、受注伝票には顧客ＮＯキーが必ず１つありますので、受注クラ
スと顧客クラスの関係は“１”、同様にして、顧客クラスから受注クラスの関係を見
れば、１つの顧客は複数の注文を発行もしますし、1回だけの注文で終わっている顧客
もあるでしょうから、“１”から固定できない複数の値としての“Ｎ”の関係、
１からＮの関係が成り立っています。
　この関係をＵＭＬでは１個の関係を“１”と表記し、1個からＮ子の関係を
“１．．Ｎ”という表記をして関係を明示的にします。

（２）汎化の表記
　汎化とは汎用化のことです。何を汎用化するかというとクラスの属性です。
よく例に引かれていますのは動物と人間、犬、猫との関係です。動物をスーパクラス
といい、人間、犬、猫をサブクラスとして位置づけます。この関係は動物としての
共通属性、食べる、動く、見る、声を出す、目、足など共通属性が多くあります。
これらの属性を動物クラスとすると、人間、犬、猫のそれぞれのクラスは動物クラス
以外の独自属性を持てば良いことになります。
　この動物クラスに共通属性をまとめて持たせることを“汎化”といいます。一方、
人間、犬、猫のサブクラスは動物クラスの下位として存在し、サブクラスを参照する
ときには上位の動物クラスの属性も共有できる構造にすればそれぞれの特徴を生かし
たクラス構造が出来上がります。
　このサブクラスを参照したときに上位のスーパクラスの属性も共有できるようにする
ことを“継承”といいます。
　情報システムのデータベースに置き換えますと、業績予実クラスなどがスーパクラス
に該当します。サブクラスとしては受注クラスや出荷クラスなどが該当します。業績
予実クラスは部門や、営業員、商品、顧客に対する受注目標や出荷目標といった計画
情報と実績サマリー情報を有することになります。サブクラスはそれぞれの計画値に
対する個々の実績項目を有しています。ＵＭＬで言う汎化の関係にあります。

（３）集約の表記
　集約の関係の例は自動車クラスです。自動車はエンジン、車体、ハンドルタイヤ、
シャーシといった部組（＝部分組立品）から構成されます。これらの属性を見ます
と、汎化の例と違って共通の属性がありません。ただし、自動車はこれらの部組が
あって初めて機能する実体となります。この関係が“集約”です。
　情報システムに置き換えますと、商品クラスと商品カテゴリークラスがこの関係に
あります。
商品カテゴリー毎に異なるサブクラスの属性が存在することになります。

第６４回はここで終了します。ＵＭＬのクラスの関係性を取り上げました。
次回は、クラス図の機能を決めるシーケンス図を「ＵＭＬ―その３」として取り上げます。

Comments(0)

　前回はＵＭＬのクラス図の関係を取り上げました。今回はこのＵＭＬのシーケンス図
　を取り上げようと思います。

　クラス図ではオブジェクト（実体）を設計するために、まずマスターファイルやトラ
　ンザクションファイルのデータ項目を属性として定義しました。属性の次に定義する
　のは、“このオブジェクに何が出来るか”の機能を定義することでオブジェクトが
　設計できます。オブジェクト設計で述べましたように、属性というデータ項目があっ
　て、このオブジェクトで出来る機能が定義されて始めて、オブジェクト単独で機能で
　きるサブシステム的な構造が出来上がります。
　この機能はこのクラスで独自に定義するのではなくて、外部や別のクラスからの指令
　によって定義される独自機能でした。
　この機能設計を効果的に進める手法として、ＵＭＬではシーケンス図を活用していま
　す。
　シーケンス図は横軸にクラスを並べて置きます。縦軸には“アクター”と言われる
　受注業務機能の外に置き、クラスに影響を与えるオブジェクトを配することから始め
　ます。
　たとえば、顧客は“注文”という指令を出すアクターです。
　同様に商品の出荷処理をする商品管理課も出荷要求が受注業務のあるオブジェクト
　から指令が出される受注業務の外のオブジェクトですので“アクター”といいます。
　それでは、受注処理のシーケンス図を作って見ましょう。

　◆ステップ１：注文登録
　　受注業務ですから、アクターの顧客から注文伝票が発行されます。まず、この注文
　　伝票を登録する必要がありますので、行先は注文登録の属性を有している注文クラ
　　スです。アクターである顧客から“注文登録”という指令が注文クラスに出ている
　　ことになります。
　　すなわち、注文クラスは“注文登録”という処理機能が必要であり、その機能を
　　このクラスで持つことになります。

　◆ステップ２：顧客取引条件照合
　　注文登録しますと、顧客によって取引条件が通常変わりますので、その情報の入手
　　が必要になります。たとえば、顧客の仕切値であったり、在庫割り当て優先順位な
　　どです。注文クラスにはこのような情報はありませんので、その情報を持つ顧客
　　クラスにその情報の取得の指令を出します。
　 したがって、顧客クラスは“顧客取引条件取得”の機能を持ち、その情報を注文
　　クラスへ返す設計をすれば良いことが分ります。

　◆ステップ３：在庫引当
　　また、注文書登録後、注文品の引当をしなければなりません。注文クラスの中で
　　その機能は持てません。注文品の数量を引き当てることの出来るクラスは在庫クラ
　　スです。注文クラスから在庫クラスに対して“在庫引当”の指令を出すことになり
　　ます。在庫クラスは在庫の引当をし、引当／不足情報を注文クラスに返す処理にな
　　ります。在庫クラスでは“在庫引当”の処理機能を持つ必要があります。
　 以下、同様にして受注業務システムを設計して行きます。
　
　シーケンス図に基づいたクラスの機能設計の概念がお分かりになったと思います。
　従来のデータ中心設計と違って、データと機能を一括するオブジェクトを対象として
　いるところにオブジェクト設計のシンプルさがあり、ＵＭＬはそれをより設計し易い
　表記としました。
　第６５回はここで終了します。ＵＭＬの設計を３回に亘って取り上げました。
次回取り上げますテーマはプロジェクトマネジメントのデファクトであるＰＭＢＯＫの代表的手法から取り上げてみようと思います。

Comments(0)

　前回までは情報戦略および情報化設計のメソドロジーを述べてきました。今回から、
　ＩＴガバナンスに沿って情報システム構築していく上において必要となるプロジェク
　トマネジメントの主要メソドロジーをＰＭＢＯＫから引用して取り上げようと思いま
　す。

　ＰＭＢＯＫ（Ｐｒｏｊｅｃｔ　Ｍａｎａｇｅｍｅｎｔ　Ｂｏｄｙ　Ｏｆ　Ｋｎｏｗｌ
　ｅｄｇｅ）は米国のＰＭＩ（Ｐｒｏｊｅｃｔ　Ｍａｎａｇｅｍｅｎｔ　Ｉｎｓｔｉｔ
　ｕｔｅ：プロジェクトマネジメント協会）が提唱しているプロジェクト管理の知識体
　系です。現在、世界で最も活用されているプロジェクトマネジメントの知識と言って
　よいでしょう。
　その知識はプロジェクトを実行する上でのプロジェクト管理プロセスを「立上げプロ
　セス」、「計画プロセス」、「遂行（実行）プロセス」、「コントロール（制御）プ
　ロセス」、「終結プロセス」の“５つの管理プロセス”として整理し、そのプロセス
　を実践する上において必要な知識エリア（＝知識分野）を定義しています。
　その知識エリアとは「スコープマネジメント」、「タイムマネジメント」、「コスト
　マネジメント」、「クォリティマネジメント」、「人材マネジメント」、「コミュニ
　ケーションマネジメント」、「リスクマネジメント」、「調達マネジメント」そして
　「統合マネジメント」の９つの知識エリアです。
　この知識エリアの重点は５つの管理プロセスでの「計画プロセス」とそのモニタリン
　グである「コントロールプロセス」に重点が置かれているところに特徴があります。

　たとえば、計画プロセスの中核となる知識のプロセスを取り上げてみましょう。ここ
　のプロセスはプロジェクト立ち上げ後、プロジェクト計画策定までのプロセスです。
　◆スコープの計画と定義
　　計画プロセスの最初のプロセスです。プロジェクトの目標、範囲、機能を定義し、
　　プロジェクトの活動計画とコスト見積りにつなげるプロセスの知識です。

　◆アクティビティ定義
　　定義されたプロジェクトの範囲とその機能をもとに、この機能を完成するためのア
　　クティビティの定義、その順序、アクティビティ工数見積を作成し、プロジェクト
　　のスケジュール作成につなげるプロセスの知識です。

　◆コストの予算化
　　定義されたプロジェクトの範囲とその機能とアクティビティ定義での工数見積とか
　　らコストを算定し、プロジェクトスケジュールに合わせて各フェーズ毎のプロジェ
　　クト予算を策定し、プロジェクト計画のコスト目標とするためのプロセスの知識で
　　す。
　
　◆リスクマネジメント計画
　　情報資産に対するリスクの識別をし、そのリスク度合いの重大さに応じてリスク対
　　応計画を作りスケジュールと予算の設定へつなげるプロセスの知識です。

　◆プロジェクト計画の策定
　　アクティビティ定義で作成されたスケジュールと予算設定を下に各フェーズ毎のQ
　　（＝Quality：品質）、C(=Cost：予算)、T（＝Time：納期）目標を設定しプロジェ
　　クト計画とするプロセスの知識です。

　この「計画プロセス」の中で、代表的なメソドロジーである「WBS（Work　Breakdown
　Ｓｔｒｕｃｔｕｒｅ）」、「ＰＥＲＴ／ＣＰＭ（Project　Evaluation　Technique／
　Critical　Path 　Method）」、「EVMS（Earned　Value　Management　System）」の
　３つのメソドロジーを取り上げて進めていこうと思います。

第６６回はここで終了します。PMBOKの計画プロセスを取り上げました。
次回は、ＰＭＢＯＫの代表的メソドロジーの１つである「WBS」を取り上げてみようと思います。

Comments(0)

　前回はPMBOKの計画プロセスを取り上げました。今回から、ＰＭＢＯＫを引用してその
　計画プロセスで重要といわれるプロジェクトマネジメントの主要メソドロジーを３つ
　取り上げようと思います。まず最初に、そのメソドロジーの1つである「WBS(=Work　
　Breakdown　Structure)」を取り上げます。

　ＷＢＳは言葉のごとく、本来は“作業の展開”を意味するのですが、ＰＭＢＯＫでは
　ＷＢＳをもう1つの“機能の展開”の手法としても紹介しています。
　すなわち、ＰＭＢＯＫでは作業のＷＢＳと機能のＷＢＳの活用法が定義されていま
　す。
　いずれにしても、ＷＢＳは細分化の手法ですから、適切な応用が可能となります。
　ＰＭＢＯＫの９つの知識エリアで言えば、機能ＷＢＳは「プロジェクトスコープマネ
　ジメント」に属し、作業ＷＢＳは「プロジェクトタイムマネジメント」に属した手法
　として位置づけられています。
　それぞれのＷＢＳの意味と役割について、まず整理しておこうと思います。

　（１）機能ＷＢＳの意味
　　この手法は「プロジェクトスコープマネジメント」の知識エリアで使用されると申
　　し上げました。
　　この知識エリアでは、まずプロジェクトの目的と範囲を決めなければなりません。
　　機能ＷＢＳはこのプロジェクトの範囲を定義するために使用されます。
　　すなわち、プロジェクトをサブプロジェクトに分解し、そのサブプロジェクトを
　　主要機能へ分解し、さらにサブ機能へと細分化し、今回のプロジェクトの対象機能
　　抑えることで、プロジェクトの範囲を捉えることが出来ます。
　　例を、サプライチェーンシステムを構築するプロジェクトとしましょう。
　　サプライチェーンシステムですから、主要機能は「販売システム」、「生産システ
　　ム」、「物流システム」等が主要なサブシステムとしてあります。
　　この主要機能である「販売システム」をサブサブシステムの機能に展開しますと、
　　「受注機能」、「在庫機能」、「出荷機能」などに展開できますし、「受注機能」
　　はさらに「受注入力処理」、「在庫引当処理」、「発注依頼処理」等の機能へと
　　展開できます。
　　この業務機能の展開は今回のサプライチェーンシステムで適用する機能を選定する
　　ことで、当該システムの範囲を定義できることになります。
　　この展開された機能に成果物を対応させて定義することで、より精度の高い範囲と
　　機能目標を設定することが出来ます。

　（２）機能ＷＢＳの役割
　　機能ＷＢＳはこのように対象システムの範囲を定義することに使用しますので、
　　プロジェクトマネジャーの観点から見ますと、プロジェクトを始める前に“その
　　機能範囲の定義漏れ”を未然に防ぐ効果があります。
　　お分かりのように、目的のシステムを階層型に展開していき分り易い機能構造図と
　　なりますのでプロジェクトマネジャーに限らず、プロジェクトメンバーや顧客から
　　のレビューを受けることも容易になり、“機能範囲の定義漏れ”が最小化できる
　　ことになります。
　　機能ＷＢＳについてお話しましたが、もう一方の作業ＷＢＳにも同様な効果があり
　　ます。
　　作業ＷＢＳはＰＭＢＯＫの知識エリアで言えば、プロジェクトスケジュールを作成
　　する「プロジェクトタイムマネジメント」に属します。

　第６７回はここで終了します。ＰＭＢＯＫの「プロジェクトスコープマネジメント」
　の知識エリアの手法である“機能ＷＢＳ”を取り上げました。
　次回は、「プロジェクトタイムマネジメント」の知識エリアの手法である“作業ＷＢ
　Ｓ”を取り上げます。

Comments(1)