================================================================================
チュートリアル1
セッション　S2-1-2「プロジェクトリスクマネジメント」
議事録(速記録)

講師：好川　哲人（プロジェクトマネジメントオフィス）
席数：F会場(40人)
参加者：約30人
================================================================================

≪自己紹介≫

マネジメントのコンサルティングを主に行う企業，ＰＭＯコンサルティングをやって
います．
今はSIer(システムインテグレータ)が多いが，最近は組込み業界でもコンサル業務を
行っています．
過去に三菱重工で，ロケット関連に従事していました．
高速道路のナンバー識別装置・プラントの制御，組込みシステムの設計などにも従事
しており，プロジェクトマネジメントの重要性を実感しました．


≪リスクマネジメント≫

その意味合いはなにか
経営のレベルでのリスクマネジメントが必要です．
ハード屋さん・ソフト屋さんそれぞれにおいて，リスクマネジメントの意味合いが
異なります．
それぞれに合わせたプロジェクトのリスクマネジメントが必要です．

会場から：
　「現場のプロジェクトは信頼できない　うまいことやってもらわなければ困る」



≪プロジェクトは何のためにやっているのか≫

企業には戦略があります．
この時，プロジェクトというのは重要な役割を握っています．
戦略とは思い描くこと．
戦略を実行しようとした時，プロジェクトで行なうことが多い．

プロジェクトは
　戦略を実行しようとしたときに，プロジェクトで実行する
　プロジェクトの目的　物を作るためだけではない

プロジェクトの目的が大事であって，
ロケットを飛ばすことだけじゃなくて，広い意味でもっと目的がある


経営的なリスクを考えないとだめ．
膨大なリソースを使って，失敗してはごめんなさいではすまない．

≪アクティビティの難易度とリスク≫
リスクが存在するゾーン

リスクはあるものではなく，マネジメントする中で作るものだ
「今回の目標」をどこに持っていくのかを決めなければならないのが，リスクマネジメントの必要な理由．
今回の目標をいかに上手く設定するかが，重要なポイントであって，企業の業績にも影響を与えてくる．

一般的な傾向で言えば，経営者というのは儲けたいわけだから最高点を持っていきたい，
マネジメントする側ではリスクを避けたいから目標を低く設定したい．
ここで，エンジニアがどう思うかが問題．

リスクマネジメントの本質はここにあって，プロジェクトの目標をどこにとっているか，
ビジネスの範囲で言えば，
製品開発の場合では，技術的難易度が関係してくる．

プロジェクトポートフォリオ
ポートフォリオ・マネジメント

縦軸が技術的難易度，横軸がリターン(収益)
左上（技術的難易度が高く，リターンが小さい）をホワイト・エレファント（白い象）といい，全然役に立たないということを意味する．
なかなか，技術者が手を引こうとしない．

右下（技術的難易度が低く，リターンが大きい）が「メシの種」通常の企業だと，６割７割．
中小企業だと９割５分
ここが１番いい．

オイスターは，おいしいけど危ない．
まさに，ハイリスク・ハイリターン

リスク管理は右上の部分でのみ考えられる．
左上はリスク管理以前に，企業として上手くいかない
左下はライン作業でやりましょう．
右下はリスクが低いので，リスク管理の必要性が無い．


≪リスクとは何か？≫
・失敗する確率（Ｏさん）

「課題」と「リスク」の違い（観客に対して）
　　課題というと予め想定している
　　リスクは，想定できない危機に対して考える

では，そもそも「想定する」とはなにか？
このワークショップのプログラムを作った時に，台風が来るなんて思っていなかった
２日間やってて，一日ぐらい台風が来るとは想定していなかったかもしれない．
この季節でいえば，おそらく想定していただろう．
これは，課題ではなく「リスク」だろう．


課題とは，解決しないとその先へ行けない

課題とリスクを取り違えることは多々ある．
商品開発の際に，課題なのに，リスクだといって取り掛かってしまうことがある．

その問題を解決するためのアクティビティに

課題は，常に起きる事象なので，計画に入れておかなければ行けない
リスクは起きるかどうか分からない．
必ずしも，計画の中に入れておく必要は無い．


プロジェクトリスクは計画どおりに実行できないというリスク．
計画を立てられないというのは，プロジェクトを立てられない計画はプロジェクトリスクが無い，ただそのようなプロジェクトはやめろということ．

リスクについて計画しましょう．
リスクを上手くコントロールしていきましょう．


≪リスクを計画するとはどういうことか≫

プロジェクトリスクに限って，大きく分けると，３つのカテゴリがある．
１．技術的なリスク
製品でいえば，品質が達成できないとか
背景には，技術的な裏付けが出来ないとか

２．スケジュールリスク
３．コストのリスク

プロジェクトリスクでは，QCDをクリアしましょうという点で，２，３の方が大事．

スコープ　"Ｓ"ＱＣＤ

Ｓは，技術リスクの結果として表われる．

プロジェクトリスクといって考えた場合，
リスクを計画の段階で見つけられるのは，
プロジェクトの精密さによって変わってくる．

計画に対して，どういうリスクが存在するか，
プロジェクトを見て，納期を達成できない，技術的困難，人が足りないなどを考えていく．


プロジェクトリスクを考える時は，出来てしまうということもリスク．
計画どおりに出来ないことがリスクが１番分かりやすいけども．
なぜ，プロジェクトが早く終わってしまうことがリスクになるのか？

プラスをリスクで考えるのはプロジェクトの中の話ではない．
１ヶ月が２０日で終われば，プロジェクトとしてはおいしい．
でも，組織としては違う．
最初っから２０日だといって欲しい．

組織の中で１番有限性の高いのは「人」
だから，計画どおりにやってくださいということは分かりやすい．
だから，プラスについてのリスクも入っている．

＞納得いかない（観客から）
収益が多く上がって，怒る経営者はいない．
エンジニアと経営者で見てるところが違う．
プロジェクトの評価を考えた時に，これが素晴らしいと評価できるかという議論．

＞リスクの定義が計画とのぶれだというのはわかるが，いいものかわるいのかがあるのではないか
今は，計画の精度が高い．
プロジェクトが早期に終了すると，品質が達成されていないかなどの疑惑が出てくる．
そういった面を含めて，プラスをリスクとしてみている．

＞実際にプラスになるということはあるのか？　現実のことを考えると起こりえないんではないでしょうか？
ある生産性値でやった時に，半年ぐらいのプロジェクトだと，やはり早く終わることがある．
それが必ずしも正常な状態であるとは思っていない．

＞早く終わると要求がどんどん追加されていって，結果，期限を越えてしまうことがある．
スコープを必ず考えることにしている．
ハードウェアの特性に釣られて，スコープがぶれることがある．

＞半年もあれば，途中でスコープが変ることもある．他社がこういう機能を入れたら，わが社もということにもなる．結果，早期プロジェクトは終了しない
スコープを変えないと入っていない．
どうせ変わるんだからといって，スコープを固定せずにやっているのでは？
でも，スコープを固定しないで，計画はありえない．

スコープが変わって行くというのは，よくあること．
スコープが変わること事態はリスクだと思っていない．
スコープの変化についていけないというのはリスクかもしれないが．

スコープは確定しなくても良いけど，固定しなければならない
スコープは一旦固定する．
スコープの固定とは，言い換えれば，仮決め．

＞計画としては，スコープが変わるということで計画を立てなければならない
最初に立てた計画だけが，計画じゃない．
その時点時点で変わった計画が計画だ．

＞スコープが変わった時に，コストが変わるのは，プロジェクトとしては不味いんだが
＞そこまで見て，計画に入れとかないといけない
制約条件として何があるかということで，そのような話は変わってくる．
スコープを小さくしようということもあれば，大きくしようということもある．
それはケースバイケース．


リスクマネジメントの流れというのは，計画の段階でリスクを考えるというのはお話しました．

ＳＱＤＣ
ＰＭＯＣ　人，組織，コミュニケーション，調達，統合
これらについても，全て計画段階に作っておきなさい．
で，計画を作った段階にリスクが発生する．
例えば，いついつに会議をすると決めたとすると，何名かが参加できないかもしれないリスクが発生する．
人が辞めてしまうなどのリスクとして想定する．

リスクに対してはその発生確率から期待値を求める．
期待値はリスクの大きさ．
何らかの対策をとっておけばいい．


≪どのようにリスクの対策をするのか≫
リスクに対する対処の仕方が割と知られていない．
リスクに対する対処としては「回避」だけが考えられてしまう．
しかし，それだけではない．
「緩和」可能性を消し去るのではなく，低くする
　「リスク軽減」人がダウンしてしまうかもしれないというリスクに対して，予備の要員を予め印をつけておく．
　「リスクの発生頻度を軽減」ストレスを和らいであげる．

やろうとしたら，莫大な費用がかかる

リスクに保険を掛けておいて，リスクヘッジする方法もある．

ある会社の社長が，
「うちのリスク対策の必要が無い．全部，外注に『リスクの転換』をしているからいいんだ」と言っていて感動した．

コンティジェンシープランとして，別に持っておく．


取るべきリスク対策が，表のどのエリアに属するかによって変わる
グリーン：ほったらかし
グレー：天災など　→転換，保有
イエロー：予防，軽減
レッド：回避

まず，計画上でリスクの排除を考える．
計画そのものに冗長性を持たせるという対応策．この段階で，大体が対策を取れる．
それでもだめなら，コンテンシェンジープランを立てる．
そして，マニュアル化やトレーニングを行う．

プロジェクトマネージャーがいくら頑張ったところで，メンバの行動に大きく依存する．
例えば，あまり正しくない進捗報告をされると，それは見つからない
メンバが意識しないと，そもそもとして成り立たない．

リスクマネジメントをうまくやろうとすると，どのような要素が必要か
リスクが明確になっていることだ．

そもそも，リスクとは何か，明確になっている必要がある
メンバがリスクとはこういうものだということが共有できてないと，メンバが勝手に適切に行動してくれるということは考えられない

リスクに対する意思決定を，上位の人がきっちり意思決定をする必要がある．
スケジュール，コストが１０％オーバーしたら報告しなさいと決めている会社がある．
１％か１０％かを決めるのは，プロジェクトマネージャー（ＰＭ）だ．
１％ぐらいでやいやい言い出したら，きりが無い．
５％まででたら，そのまま１０％までずるずる行くことがある．
このあたりは，センス．
１番良くないのは，決めないこと．
「うまくやってね」というＰＭが意外と多い．あまり決めたがらない．
スコープは決めない，リスクを明確にしない，１０人いたら５人はそういうＰＭがいる，何のためのＰＭか．
朝令暮改でも良い．

その中で，プロジェクトチームもそうであるし，組織としてもそうであるが，リスクマネジメントということが気になる．
研究開発をやっている組織であっても，すごく大事なことである．
リスクマネジメントとはリスクに対して敏感に反応していくこと．
リスクバインドを高めるというのが，リスクマネジメントに限らず，これからの組織の大きな課題になろうかと思う．


≪リスクマインド≫
３つの原則
１．復帰能力の拡大
何かあった時に早く素早く動いて是正していく

２．原理原則をきっちし決めていく
価値観があって，その上にプラクティスがある．
リスクに対して敏感に感じ取ろうと思えば，ケースバイケースはありえない．こういう場合はこうと決めておかなければ，リスクに対して敏感になれない．

３．単純化をさせない
プロセスを単純化させる，同じ結果が出れば良いだろう，これを絶対に認めさせない．
東海村の原発事故がいい例．あぁいうことをさせていれば，いくらでも事故はおきる．
「この辺で良いだろう」というのが原因．
自分の解釈ではこれでいいはずだ，とメンバがやりだすと困ったことになる．
決まったことを，きっちしやらす．
そうすることで，リスクマネジメントに対する意識を高めていく．


＞効率化のためのプロセス改善を持つということと「単純化させない」ということと相反するのでは？
決めた瞬間，それが「複雑」になる．
みんながこれで良いんだということで決めているのがプロセス．
プロセス改善の意識を削ぐ可能性があるというのはおっしゃるとおり．
兎に角，リスクを考えることを考える組織であれば，そうすれば良いし，
効率化を重視する企業であれば，リスクを多少犠牲にしてもそういう方向に進むだろう．

組織文化をどういう風につくるかということを明確にする必要があるし，学習する組織をもっていく必要がある．


≪質問タイム≫

＞コンテンシープランを．計画とは別に考えるという話であったと思いますが，別のことを予め計画に入れておくことがあるが，どっちが良いのか．

それは，予め計画に入れておくほうがいい．


＞今回の話は，ひとつのプロジェクトか，組織全体の話か
ひとつのプロジェクトのリスクマネジメント．
そのプロジェクトの中で完結するかという問題があって，それはノーだとおもう．組織に影響する．

＞プロジェクトを止めるというリスク回避はあるのか？
ある

＞それはそのプロジェクトの中では判断できないことですよね
プロジェクトをやるという判断は，プロジェクトの初めの方で決まる．
実際は組織のもっと上の方で決まる．

＞次回はその辺の話をもっと詳しくしてほしい．
はい．


＞「１０人中５人は〜」という話があったが，どのような方向性でやればみんなハッピーに
マネージャーを育成するという立場と，組織の話と二つある．
プロジェクトの目的をはっきりさせる．
それで，残り５割の人はよくなる．
２割の人にはＰＭをさせないと．

何を言っても代わらない人が組織に入る．
ＰＭについては，できる人を使って投資する，それが現実的ではないか．


＞欧州では，リスクが０だと判断される企業があるのですが，日本でやっているようなリスク管理と欧州でやっているリスク管理で，コミュニケーションが上手く伝わらないというか，どういう風にすれば伝わるか？

組織の中の責任の明確性が違う．
日本の組織は，責任が曖昧・・・，責任をうまくオーバーラップして上手くやってきている．
日本でそういう方法をずっと続けていくのか，という疑念を抱いている．
それはその組織による．



(了)