Visualizing Project Management 1章 後半

特別講義がはいったので，朝9時開始になりました．
みんな，疲れているだろうに・・・・

よく集まってくれました．

ありがとう．

さて，一章の後半輪読しました．

＝＝＝＝＝＝＝＝＝＝＝

プロジェクトの成功とは，最適なソリューションを提供すること．
そのためには，初めの一歩に最適なことをしておこう．

本書では，プロジェクトが目指すものとその結果を「ソリューション」と記します．

最適なソリューションで顧客に喜こんでもらうということは，
期待どおりと製品やサービスを提供したり，問題をきれいに解決したりすることだと
言い換えることができます．

”初めの一歩に最適なことをする”と，
担当したチームのメンバーを疲弊させることなく，
意図したとおりに，
製品やサービスを作ることができます．


プロジェクトは，
ビジネスチャンスをものにするためにあります．

従って，プロジェクトを成功させるために，
すべての判断は，business caseの項目と照らして決定します．
（政府関係のプロジェクトの場合は，mission caseの項目と照らします．）


====(嶋津恵子　補足)=======
ゼミナールの席でも，「business case」というタームの意味に関し議論になりました．
的確な説明ができなかったのですが，
再度おなじことを繰り返すと，
ビジネスを円滑に，成功裡におこなうために，
ときどき振り返る基準や目安です．・・・・だとわたしは思ってきました．


ゼミナールの時にお渡しした資料は，出典を失念してしまったもので，
転用の禁止をお願いしました．


後日，これを見つけました．
16ページ以降を参照してください．
用語集も直感的理解に役立ちます．


ただ，このドキュメント，英語を日本語に直訳したものらしく，
「はぁ？」って個所があちこちにあります．・・・・人のことは言えん．(>o<)
正確に理解するためには
できれば，英語のものをよみなおしておいたほうがよいでしょう．




あれっ！！！！！


あんやぁぁぁぁ？？？？


みんな授業で勉強しているではないですか！


「プロジェクトマネジメント」（当麻先生）です．
プロジェクト開始時に，プロジェクト憲章を作成しますよね．
その中に，”ビジネスケース”が必要です．


で，何を書かなきゃならないかというと
ビジネスニーズ
と
費用損益分析
です．


教科書（プロジェクトマネジメント知識体系　ガイド）第４版
７５ページと７６ページにちゃんと書いてあります．

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


プロジェクトを進めるうえで，難しいとされているのが，
ビジネス面と技術面で連携をとりバランスを図ることです．

一旦，うまく連携をとりバランスよく検討したように見えても，すぐに
要求事項の優先順位と，前節に示したような外部環境により変更しならないもので
矛盾が発生します．

======(欄外注)==========
ビジネス上の視点と
技術上の視点で
発生する衝突の解決には，
トレードオフ研究や
交渉術，また同様の手段が用いられます．
================

====(嶋津恵子　補足)=======

systems engineering用語に

trade-off studyというのがあります．

この注は，trade studyですが，

おそらくtrade-off studyと同意でつかっているのだろうと

推測しました．

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

要求をマネジメントすることで，
プロジェクトをマネジメントしよう．

PMI(Project Management Institute)は，
プロジェクトマネジメントの知識体系と資格の認証機関です．
ここでは，プロジェクトマネジメントを次のように定義しています．

プロジェクトマネジメントとは，プロジェクトの要求事項を満足させるために，
知識，スキル，ツールと技法をプロジェクト活動に適用することである．

====(嶋津恵子　補足)=======

この定義の日本語訳は，日本PMIが発行するPMBOKから転載しました．

出典は，みなさんの教科書である，

プロジェクトマネジメント知識体系　ガイド　

(PMBOK ガイド)　第４版

です．

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


プロジェクト活動の経験が豊富なチームは，
要求をマネジメントすることと
プロジェクトスコープをマネジメントすること
が
プロジェクトのマネジメントそのものを抑えることになると
ちゃんとわかっています．

プロジェクトと要求は，
ニーズが提示されたことで始まり，
そのニーズが満足されたとユーザーがvalidationに合格を出したときに終了します．

====(嶋津恵子　補足)=======

いやぁ・・・・個人的に，困っている最適な日本語表現の一つに

Validation と　Verificationがあります．

日本のシステム工学系の人たちは，

妥当性検証と，実現性検証などと表現し，

「２つの検証」といっています．

日本ＰＭＩは，Validationを「確認」，Verificationを「検査」と訳しているのです．

あーーーーーーっ，困った．

なので，そのまま英語を使います．

「文理融合」という前に，システムエンジニアリングとプロジェクトマネジメントで

整理したいですね．

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

9章は，技術開発とビジネス構築を，どのように連携させていくかという視点で
プロジェクトの最初から最後までを説明しています．

一旦ビジネス面での要求と技術面での要求の整合がとられる（以後congruencyと記します）と，
この状態を，維持させていくことが必要になります．

技術的な要求は，決められた予算の範囲内で計画中に達成可能でなければなりません．

最初の段階で，この整合作業をおこなわなったかったプロジェクトは，
早いうちに矛盾点を解消しておかないと
多くの場合，
修正不可能な状態になり，廃止に追い込まれます(図1.1)．

これは，自殺的行為だとも言えます．

プロジェクト活動期間中，一旦取り決めた合意事項を変更したいというプレッシャーは常に発生します．

スケジュールは短縮され，充当されていた資源は削減され，新たな追加機能は増えていきます．

プロジェクトを担当するチームは，常に，どこで重大な不整合が発生したかを確認し，それに対し対応を取らねばなりません．

計画の変更と，予算の変更と，使用技術の変更を行う際，
これらの整合を常にとっておくことが大切です．
そうしないと，プロジェクトは失敗します．

======(欄外注)==========

本質的でない要求や

細かすぎる定義の要求は

計画した予定や

予算の超過を

起こす原因になりやすいです．

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

======(cartoon)==========

”自殺行為的プロジェクト”

「ウオーリ君．

　実は，製品要求を集めておく時間がないんだよね．」

「とりあえず，製品の設計だけはじめておいてくれないかね．

　そうしておかないと，なんにも成果でいないじゃないかと心配だからね．」

「数あるプロジェクトの中で，

　おらっちが一番好きなプロジェクトは，

　こんなふうに，最初っから失敗するってわかっているやつだよね．」

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

要求マネジメント：
プロジェクトマネジメントとシステムエンジニアリングの交差点

なぜ，プロジェクト要求は，重要な論点なのでしょうか．
この問いに対する答えは，要求が拡散していくこと，
プロジェクト・ステークホールダーの興味の多様化と
役割をめぐる混乱をみるとよくわかります．

====(嶋津恵子　補足)=======

ROLEもこまったタームです．

プロジェクトマネジメントでは，多様される表現ですが，

一意に役割という日本語を当てると何だかよくわからない個所がたくさん出てきます．

これもPMIのPMBOKを参照してみました．

9.1.3の中にroleがなんであるか，説明があります．

で，日本ＰＭＩ発行の日本語版をみると・・・・・

やっぱり「役割」です．

だもんで，多少違和感があっても「役割」で通します．

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

ここまでに本書では，
要求に関し，
プロジェクトマネジメントとシステムエンジニアリングで共通する
人や，ものに関し確認することなく，説明してきました（図1.2）．


プロジェクトチームの２人の重要なステークホールダーは，
プロジェクトマネジャーとシステムエンジニアです．

前節では，PMIのプロジェクトマネジメントの定義を冒頭に書きました．
そして要求実現のために多くの知見を利用することであると強調しました．


本書は，これを前提としていますが，
さらに，
プロジェクトマネジメントは，要求を実現させるために
システムエンジニアリングの作業と相互に依存しあうものであるという意味も加えることにします．

すると，次の３つの定義になります．


プロジェクトマネジメント：
特定した結果を実現するために，資金と人的資産と物的資産に対する，
消費と利用の計画をたて，
これら資産を活かしながら，操作していくプロセス．

システムエンジニアリング：
要求をマネジメントするプロセスであり，
このプロセスには

ユーザーと他のすべてのステークホールダーの要求を特定し，

プロジェクトのコンセプトを明確にし，

システムのアーキテクチャを作成し，

要求をトレーサブルナ構造形式に整理し，

機会とリスクをうまく利用し，

システム構成要素を統合し，

verificationを行い，

validationを行い，

学習したことを教訓集として整理する

工程が含まれる．

要求マネジメント：

プロジェクトの３つのベースライン，つまり

ビジネスベースライン，予算ベースライン，技術ベースラインのマネジメント．

要求マネジメントの目的は，この３つのベースラインの整合を保つこと．

要求マネジメントのプロセスには，ベースライン変更マネジメントと承認処理があり，

また，

要求をトレーサブルで，かつ元々の要望に応えていることがわかるような

構造形式に整理する作業が含まれる．

====(嶋津恵子　補足)=======

baselineは，PMBOKでも日本語では

「ベースライン」です．

ただし，PMBOKでは

cost performance baseline

schedule baseline

performance measurement baseline

technical baseline

の４つになっています．

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

ビジネスケースと

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

は

要求マネジメントのフレームワークを提供しています．

前述の定義のとおり，要求マネジメントは，

プロジェクトマネジメントとシステムエンジニアリングの交差する部分になります．

つまり，このフレームワークは，この２つの交差部分に利用できるものです．

プロジェクトマネジャーは，

プロジェクトにおける

予算執行と計画遂行の責任を持ちます．

これは，たとえ，技術的なソリューションを提供する担当者が，

このプロジェクトマネジャの権限の及ばない外部の組織や会社であっても

変わらないのです．

このソリューションを提供する作業で，予算の大部分が消費され，また

計画も決定づけられます．

これは，マネジメント不可能なようにも見えますが，

実は，マネジメントしやすくなってきています．

それは，だんだんプロジェクトマネジャーが，プロジェクト活動の中心におかれ，

プロジェクトマネジャの役割がなんであるか，プロジェクト参画者がよく理解するようになってきたからです．

プロジェクトマネジャが，ソリューションの開発と導入に関し，

責任と権限を与えられているプロジェクトでは，

プロジェクトマネジャーは，

ソリューション開発（つまりシステムエンジニアリング）に関係する

人と組織をうまく調整し，調和させる技術が求められます．

もしくは，そういう権限をもった人と密接にかかわっていく必要があります．

次章では，

プロジェクトマネジメントとシステムエンジニアリングの交差する部分を

プロジェクト活動の中でソリューションをつくるという観点で

解説していきます．

======(図1.2)==========

要求マネジメント：２つのマネジメントの交差部分として定義

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

======(欄外注)==========

最近開催された大規模なPMI会議の中の一つでは

プロジェクトのうち２２％しかリソース管理ができていなかった．

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