VPM: pp.12-

VPM： Identifying the project stakeholders


次の作業は,ソリューション方法を決定する範囲に存在する
重要なステークホールダーや団体の特定です．
プロジェクト活動に必要なステークホールダは，次のようなカテゴリに分かれます．


カストマーとユーザ
プロジェクト担当者
市場
専門組織やコミュニティ，標準化団体，立法関係組織


カストマーとユーザは同一のステークホルダーであることもあり得ます．


カストマーとユーザが別のケースは，
プロジェクト活動の資金を提供している会社内のマーケティング部門が，
カストマーである場合です．
プロジェクトの成果となる製品やサービスのエンドユーザにとって，
マーケティング部門は媒介者の役割を担います．



プロジェクト担当者には，重要なステークホールダーはすべて加えます．
プロジェクトチーム，出資企業，内部カストマー（マーケティング部門や販売部門），関連する機能組織の代表者です．


市場には，主に2つのステークホールダが存在します．
販売網担当者と，競合です．


専門組織やコミュニティ，標準化団体，立法関係組織は，
プロジェクトを実施メンバーや，コミュニケーションする際の用語や，ソリューション方法を検討する範囲に大きな影響を与えます．
これらの代表的なものを，リストしておきます．
特に大きな影響を考慮すべきものは，本書のappendix Bと
別冊のCommunication Project management のパート３に詳しく述べています．

（団体リスト表記省略：教科書を見てください．）












VPM: The professional atmosphere


SEIの役割は，実社会のソフトウエア工学者に助言をおこなうことであり，

具体的には

ソフトウエア中心に要求開発や，システム開発をおこない，さらに

維持継続を考えた時，

システムの企画段階から実際に利用する段階までのとおして

何がおこるか，何をすべきか予測できるようにすることです．

1987年までSW-CMM(Software Capability Maturity Model)が

ソフトウエア工学専用に使われていましたが，

2000年の夏にハードとソフトを包含した

つまりシステムエンジニアリング用のフレームワークが

CMMI　Product Suitとして提案され

こちらが，使われるようになりました．

SEIは，システムエンジニアリングの分野における

3つの実務専門家のコミュニティのうちの一つです．

SEIは，

プロジェクトが対象とするスコープが，どんどん広がり，

影響する範囲やコミュニケーションを必要とする対象も拡大していくような状況下でも

プロジェクトメンバーがプロジェクトを成功させる専門家集団となるような

組織環境のありかたを検討しています．

また，

PMI (Project Management Institute)と

INCOSE (International Council on Systems Engineering)は，

それぞれ

プロジェクトマネジメントとシステムエンジニアリングの

実社会で仕事をしている専門家のコミュニティです．

===(嶋津恵子コメント)=====

「専門家」を示す語の使い分けをゼミでも説明しました．

Expert

Professional

Specialist

Authority

など，

意味を使い分けられるようにしましょう

===(嶋津恵子コメントここまで)=====

1995年に

INCOSEは，コミュニティの範囲を世界規模に広げ，

2004年に

CSEP（Certified Systems Engineering Professionals）の

資格プログラムを発足しました．

The INCOSE Systems Engineering Handbookは，

この資格の中身を案内するものです．

この本のパート２とパート３では，

欄外に"INCOSE"と表記して，関連する説明を記載しています．


PMIの発行するPMPの資格を持っていると，
特に米国におけるプロジェクトマネジメントの基本レベルを有していると判定することができます．


プロジェクトマネジャーとシステムエンジニアが，資格を取ることは
個人のキャリアアップを短期間に実現する良い方法です．


自己啓発に取り組んでいる実践者は，
資格取得を，取得そのものが目的ではなく，
自身のスキルを向上させ維持していく方法の一つとみています．


資格取得を推奨する企業や組織にとっては，
プロ意識や自己啓発を意識づける材料になります．

VPM 2章 p99.10-

Visualizing Project Managementの解説，
途中で中断していてごめんなさい．

どーーーにも，こーーーーにも，ほんとーーーーに，もうっ！

「・・やめちゃったんですかぁ？」の質問に，
あいててててて・・・となったので，
続きをやおら始めます．

どこからでしたっけ？．


読んだら，コメントしてくださいね．
わからない点，
おかしいなと思った点，
気づいた点，
感想・・・・

なんでもいいです．

わたしのMotivationをあげてくださいませ．

なお，以前の記事に書き忘れましたが，
"performance"に""実績"という日本語をあてているのは
PMBOKに準じています．(この場合は，based on)

いきなりの・・・

===(嶋津恵子コメント)=====

Trade-off studyに関し，日本語で適切に表現するとどうなるか．

何回か前に，議論になったと思います．

先日の，夏季特別集中凝縮圧縮（・・ん？）研究会でも申し上げましたが

あまりにもシステムエンジニアリング用語の日本語が貧弱です．

Trade-off studyもそのひとつ．

この用語は，欧州のシステムエンジニアリングの世界では

要求開発の分野の重要なtermとして広く知られています．

ここの説明が一番わかりやすいかな・・・・

まぁ，VPMと同様の説明ですね．

要求開発用語であれば，BABOKには必ずあるなと思って調べてみました．

ありました．

9.8.3.3です．

で，日本語版を参照してみると・・・・

”トレードオフ”！！

なんじゃい．(#｀Д´)ｫﾗｧｧｧｧｧｧｧｧｧｧｧｧｧ!!!!

でももうひとつわかったことがあります．

同様の解説をどこかで読んだぞと思いました．

お勉強熱心な皆さんはすでに気づかれているかもしれまん．

そうですっ！

INCOSE handbookの5.3.2です．

205ページにBABOKと同じ図が出てきます．

要は，"意思決定"方法ですね．

===(嶋津恵子コメントここまで)=====

さぁて，やるか・・・・

10ページです．

問題解決の対象領域に焦点を当ててみよう

最適な問題解決策を選択するには，

問題解決後の状態と

それを実現する主たる方法を

それぞれ，複数候補を挙げ，

いくつかの評価項目に照らし，総合的に決定していきます．

これを，トレードオフ研究もしくはトレードオフ分析と言います．

この作業は，特定の決められた領域内で行います．

プロジェクト活動や，問題解決方法に矛盾が生じないように概念上区切ったものです．

図2.3を参照ください．

=============================

図2.3　トレードオフ分析の対象領域

想定される環境の中核部分に相当

ー想定されうるすべての環境ー

過去の教訓を元にした採択判断

業界標準やベストプラクティスを元にした採択判断

プロジェクト憲章に記載されたビジネスケースとCONOPSを元にした採択判断

トレードオフ分析をするホントの対象領域

=========================================

モデルとフレームワークとベストプラクティスは，

いずれもトレードオフ分析に利用されます．

この3つの用語は，よく，混同して利用されていますが，

違いを理解し，最適に利用されてこそ，最大の効果を発揮します．

プロジェクトマネジメントとシステムエンジニアリングの文脈では

次の定義が適用されています．

モデル：

モデルは，実態を表現しなおしたものです．

プロセスを描いたり，

チャンスとリスクを調べ上げたり，

特長的な点を評価する際に利用します．

正しく構成されたモデルは，道具としての利用価値が高くなります．

正しく構成されたモデルは，決定的に重要な意味を持つことだけを扱い，

本質を理解しマネジメントする際にわかりにくさを発生させてしまう，

本質以外のことを表現から省いています．

複雑な状況を取り扱うために，

異なる表現方法の複数のモデルがを使って，同じ状況を表現します．

使い勝手のいいモデルは，単純に表現されていますが，

必ず，マネジメントするべき本質が残されています．

この本質は，次の章で定義するプロセスモデルに展開されます．

フレームワーク：

トレードオフ分析をおこなう対象領域では，

フレームワークは，

実現性の高さを示す

や

選択可能な候補のリスト

や

基本構想のリスト

や

価値レベルのリスト

や

実作業のリスト

です．

ソフトウエア工学研究所(SEI: Software Engineering Institute)の

SEI-CMMI(Capability Maturity Model integrated)は

SEI フレームワークの根幹をなすものであり，

組織が持つ実績を挙げる能力を

評価し，ランク付けし，継続的に成長させるためのものです．

このフレームワークに関しては，21章で詳しく述べています． 




Best Practice:
Best Practiceは，
何がプロジェクトを成成功裡に終結できた際の￥の
活動を通して一貫して実証することができた
作業方法，つまりプロセスや手順や技法
です．


Best Practiceは，ドキュメントに残されていることが必要です．
これを使って，共有し，再利用し，また清廉化していきます．


Best Practiceは，一般にプロジェクトマネジャの教訓（Lessons Learned）を基に，
実践された結果です．
この方法で，PMBOK(A Guide to the Project management Body of Knowledge ) guideは開発されました．


PMBOK guideは，実践の現場からのフィードバック情報を参照し，
定期的にアップデートされています．



 プロジェクトマネジメントにおけるbest practiceは，
PMBOK guideの内容ですが，

Visualizing Project Management 中の
Behavior-based process modelは
システムエンジニアリングとプロジェクトマネジメントの
両方のbest practiceを統合したものです．






図2.4は，図2.3を，別の視点で描いたものです．
図2.5は，対象領域としてとらえていたスコープを，
価値駆動型でトレードオフ分析を行いながら，
スコープを限定している様子をしめしています．

===(嶋津恵子コメント)=====

solution space > trade space

===(嶋津恵子コメントここまで)=====

図2.5のAからFは次のそれぞれに対応しています．

A.    ステークホールダーが要求を提示するときに，架すべき制約範囲

B.    従来のシステムで満たしている範囲

C. 技術上の限界点

D. トレードオフ分析の対象範囲：　この対象範囲内でトレードオフ分析を行いその結果，選択された解決策の基本構想で，要求を満たすことになる．

E.　理想的な解決策基本構想は，トレード分析のいずれの結果も優位を示す．

F.　実施した時に価値が小さい解決策基本構想を，候補から外していく．

トレードオフ分析で理想的な基本採用技術構想を選ぶと，縮退した分析対象領域は非常に明確になります．ところがさらに，ビジネスケースの観点でも熟考すると，システムの機能や性能に対する価値にバイアスがかかり，別の候補領域が浮上します．この後の操作である，価値が小さい解決策基本構想を候補から外すことが価値駆動型の本質です．図2.5のFのステップに相当します．広く知られている実践的技法であるCAIV(Value Engineering and Cost as an Independent Valuable)は，この方式を推奨しています．

図2.4　プロジェクトで取り扱う範囲の境界を決定する

―プロジェクトで取り扱う範囲―

プロジェクトで取り扱う範囲の境界は，最適に教訓を反映させることから始まります．そして，プロセス作成用フレームワークや，ベストプラクティス，それに業界標準は互いに重なっている部分があります．

組織内のベストプラクティス

産業界のベストプラクティス（PMI, INCOSE, Agile Alliance）

フレームワーク (SEI-CMMI，シックスシグマ)

産業界標準　（ISO，EIA，IEEE）

各ユーザの要望は交錯しています．また事前に定義した問題解決を検討する範囲を超えて，つまり，教訓やベストプラクティスに反していることもあります．

ユーザ1の要望と期待と解決策提案

ユーザ2の要望と期待と解決策提案

ユーザ3の要望と期待と解決策提案

ビジネスケースとCONOPSを基準として決定したプロジェクトで取り扱う領域は，3ステークホールダの要望を取り込んでいますが，決してすべてを包含してはいません．

図2.5　価値駆動型で解決策の基本構想にたどり着く方策

エンジニアリングとはまったく関係ないですが・・・

米国太平洋時間7月27日に伊良部秀輝さんが逝去されました．

彼の，代理人をしているのが，わたしの古い友人です．

この友人が，先日ブログに伊良部秀輝さんの件を記事にしていました．
はじめ日本語がアップされていましたが，
直感的に”これはオリジナルは英語だな・・・”と感じていました．

2日後，案の定，英語のオリジナル文が付け足されました．

英文の方を読んでみてください．

とても読みやすい英語です．
それでいて，心にずんとくる内容です．

最後の段落を読んで，わたしは涙が止まりませんでした．

わたしの友人は，日本の文化を壊してでも，新しい世界（ビジネス）を作ろうと努力してきた人です．
敵もたくさんいます．
とても力強く，時には荒々しさもあらわす人です．

でも，
もう一つの彼の一面は，
繊細で，
人の心を大切に思う
優しい気持ちの持ち主です．

彼が，最初にメジャーリーグに送り込んだ選手は野茂英雄さんです．

当時，日本中がヒステリーをおこしました．

日本球界全体を敵に回しても，平然としていたわたしの友は，
ある日，
わたしを自宅兼オフィスによんでこう切り出しました．

「恵子さんからみてどう見える？　俺のしていること．」

おどおどした少年の瞳のようにも見えました．


その後の，この友人の活躍は，わたしが語るまでもありません．


新しい世界を切り開く人は，
皆，
不安と闘いながら
前に進んでいるだということを
彼から教わりました．


ほーーーんと，システムエンジニアリングとは，
まったく関係ないですが・・・・・・(^^;;