プロジェクトマネジメント

リスクってなんだろう(ITプロジェクト)

1.リスクってなんだろう

ITプロジェクトにおけるリスクは、4つにわけて考えられます。

脅威
(プロジェクトにマイナスに働く事象)
好機
(プロジェクトにプラスに働く事象)
全体リスク
(プロジェクト側で対処できない事象)
給料が下がる 給料が上がる
個別リスク
(プロジェクト側で対処できる事象)
作業が予定よりも遅れる 作業が予定よりも早く終わる

2.課題とリスクの違い

課題をリスクと捉えて話す人がいます。課題は現在進行形で起こっている問題で、リスクは未来に起きるかもしれない良いこと/悪いこと(課題になるかも)です。
次のような違いがあります。

リスク 課題
前提 良いこと(好機)、悪いこと(脅威)のどちらもある。 いま、発生していて対処が必要な問題
影響 良くなること、悪くなること、両方ある。
(何も変わらないもある)
悪くなることしかない

 

3.リスク管理

リスクが理解出来たら、リスク管理表を作って管理します。

リスクの特定 事象
担当
想定発生時期
リスク分析 発生確率(低:1~5:高)
影響度(低:1~5:高)
スコア(発生確率×影響度)
リスク対応(計画) 対応戦略(回避/転嫁/軽減/受容)
対処内容
トリガー(リスクが発生したと判断する時期/きっかけ/予兆)

対応戦略の意味は、次のとおり。一般的なリスクの対応戦略はエスカレーション等ありますが、ITプロジェクトでは、次の4つで問題無いと思います。
(少なくとも、自分は、この4つです。もっというと、軽減か受容を使用することがほとんどです)

回避 リスクを無くす(回避)する。
(例)遅れていたので、納期を延ばして再スケジュールする。
転嫁 リスクを他者に引き受けてもらう
(例)ベンダーに引き受けてもらう。
軽減 リスクの影響を小さくする
(例)テストを多く実施し、品質を高める
受容
(能動的受容)
リスクを受け入れ、対応する。
(例)予め計画で見込んでいたリスク予備費を使って対処する。

受容には、受動的受容である「何もしない(なすがまま)」というのもありますが、今まで使ったことが無いので省略します。
(まず、使うことはありえないでしょう)

フィードバックのフレームワーク

本の備忘録です。(「みんなのフィードバック大全」)

プロジェクトマネージャになると、チームメンバのモチベーションをあげたり、仕事のやり方を改善するためにフィードバックする場面が出てきます。
ポジティブなことでも、ネガティブなことならなおさら避けて通りたくなります。でも、チームでパフォーマンスをあげるには避けて通れません。
その際に、使えそうなフレームワークを学んだので書き留めます。

「ソラ・アメ・カサ」のフレームワーク
フィードバック以外にも、問題解決のプレゼンテーションつくりにも使えると思ってます。

ソラ <ファクトの確認>
空を見上げたら、雨雲が多い。
⇒誰もが見ても事実だと思うこと
アメ <課題や問題の確認>
空に雨雲が多いから雨が降りそう(問題)
⇒ファクトを認識して、問題(課題)を推測する
カサ <対処(改善)>
雨が降りそうだからカサを準備する
⇒雨が降りそう(問題)だから、カサを準備する(対処)

フィードバックする際に、これを意識した話を組み立てて、実践すると相手に伝わりやすいそうです。
これは、プレゼンテーションにも言えそうです。

これ以外にも、フィードバックのコツなど、実践する際に役立つ情報が載っていたので、興味がある方は本を読んでみてください。
(読み終えるのに、3.5時間かかりました。普通の人だと、2時間強くらいでないでしょうか。読みやすいので、さらっと読み終えますが、また、読み返したくなります)

プロマネになって考えること(SIer)

ITプロジェクトでプロジェクトマネージャーになったときに考えることを書き留めました。

1.段取りを考える

はじめに、プロジェクトの目標を具体的にかつ明確にする。(段取りを考えるための前提条件や目標を把握する)
そうして、段取り(プロジェクト計画)を考える。
計画を立てる手順として、

WBSをつくる 作業項目を考える ※次の「ゴール設定」を参考に
作業項目ごとに担当決める(複数人で作業するなら責任者を決める)
作業項目ごとに作業時間を見積もる
ガントチャートを作成する WBSをもとに、作業順序を考える
クリティカルパスを確認する
担当の作業負荷を確認して、作業順序を調整する。

の順に作成すると良い。

余談だが、WBS作成時のNGワードを記載する。
次のワードで、作業項目が挙がったら、成果や作業内容が曖昧になっていると考え、見直した方が良い

管理する 監督する 把握する 確認する チェックする
協議する 話し合う 調整する 調査する 研究する
勉強する 実行する 企画する 評価する 協力する

2.ゴール設定

作業項目を考える差に、「SMARTの法則」で目標を設定すると良い。さらに、「やらないこと」を決め、「やるべきこと」に集中する。
できれば、作業項目ごとに、前提条件、制約条件とその根拠を明確にすると良い。

SMARTの法則とは。。。

Specific 具体的で分かりやすい
Measurable 計測可能で数字になっている
Attaninable 達成可能で現実的になっている
Relevant 作業でなすべきことや成果に特化している
Timely 期限が明確になっている

3.コミュニケーション

人を動かすための6つの法則

法則1 味方になると考える 相手を悪く思わずに、誰であっても味方にすることができると考える。
法則2 目標を明確にする 相手の間違いや自分の正しさを証明するのではなく、相手からどんな協力を得たいかという目標に注力する。
法則3 相手の世界を理解する 相手が気にしていること、相手の物事の見方や考え方、価値を置いているもの(カレンシー)を理解する。
法則4 カレンシーを見つける 相手にとって価値のあるもの(カレンシー)は何かを考えて日頃から相手に渡しておく。
法則5 関係に配慮する 相手との関係性や相手の仕事の進め方に配慮し、相手にあわせたコミュニケーションを心がける。
法則6 目的を見失わない プロジェクトの成功や、成果を生み出すことが目的だということを忘れない。

 

プロジェクトを遂行していくと、問題が発生する。その予兆を感じる際に考えるチェック項目を挙げる。

スケジュールに影響する出来事(仕様変更、作業スコープ変更等)はあったか?また、その出来事は以前と比べて増えてきたか?
人員や費用などのリソースに変化はないか?
何をどこまでつくるのか(スコープ、成果、作業範囲等)に変化はないか?
進捗会議は定期的に開催されているか?
また、報告内容が具体的、定量的か?さらに、真実が報告されているか?
プロジェクトメンバーのモチベーションや疲労感はどうか?不平不満が聞こえてな来ないか?
組織(自分の組織、ステークホルダーの組織等)のプロジェクトの優先度は変わっていないか
現実的にプロジェクト目標を達成できる状況か?

 

レビューや進捗報告等の話し合いの場において、意識すると良いこと

話しやすい雰囲気をつくる
・発言を否定しない。
・問題に焦点をあて、作用者のスキル等を対象としない。
助けることに対する価値観をチーム内で持つ
褒め合うルールを持つ
相手に関心をもつ
相手の基準を知り、尊重する
本音を言える

 

話す相手とラポール(信頼関係)を築くために効果がある手法

ペーシング 話し方や呼吸などを相手と合わせる。
ミラーリング 動作や姿勢、表情などのボディーランゲージを相手と合わせる。
バックトラッキング 適度に相槌を行い、相手が話したことを繰り返す(オウム返し)。

(余談)PMBOK

PMBOKは、プロジェクトマネジメントに関する知識体系をまとめた資料であり、プロジェクトマネジメントにおける一般的なベストプラクティスやプロセス、ツール、テクニックについての包括的な情報をが書かれている。

プロジェクト統合マネジメント プロジェクトマネジメントの各作業を統合する 備考
スコープ・マネジメント 「要求されるモノやサービスの成果物」と「必要な作業と範囲」を明確にする
⇒成果物とやるべきことを明確にする
要求事項文書
スコープ記述書
WBS
スケジュール・マネジメント 「スケジュール」を作成し、管理する スケジュール(ガントチャート)
コスト・マネジメント 開発コストの見積作成及び開発時のコストを管理する
品質マネジメント 「成果物の品質」と「作業プロセスの品質」を管理する 品質マネジメント計画書
資源マネジメント 「(プロジェクトに必要な)材料や装置などの物質資源」と「開発メンバである人的資源」を管理する
コミュニケーション・マネジメント 「ステークホルダーとのコミュニケーション」を管理する
リスク・マネジメント プロジェクト活動に対する脅威(リスク)を管理する
調達マネジメント プロジェクト活動に必要なモノやサービスを外部から取得・購入・委託等を管理する。
ステークホルダー・マネジメント プロジェクトに影響を及ぼすステークホルダーの特定・影響分析・対応等を管理する

 

(さらに、余談)初心者PMにオススメの本の紹介

先日、「童話でわかるプロジェクトマネジメント[第2版]」を読みました。
誰もが知っている童話を題材に、主人公がPMとなって考えて行動するストーリーになっています。
自分は3時間くらいで読み終えました。(普通なら2時間くらいでないでしょうか。。。集中力が無くて(汗))