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　価値駆動型で解決策の基本構想にたどり着く方策