教育・訓練 2016年10月~2017年03月

できるPMの決め手は「リスクマネジメント」
http://www.atmarkit.co.jp/ait/articles/0505/25/news114.html

【要点】
コミュニケーションに問題があるといわれるプロジェクトには、2つの共通点がある。
 ・「自分からいわない」点・・・「気付いているけれど自分からはいわない」こと
 ・「自分からあえて気付かないようにする」点・・・「自分からやっかいなことを見つけてしまわないようにする」こと
つまり、「責任回避」「不要な遠慮」「無責任・無関心」という事
⇒これには何かしらの原因がある。
原因の一例)
プロジェクトの運営方法についての小さな不満がきっかけとなり、不満が積もりに積もったことが原因

問題の発生を未然に防ぐことができるか、それとも、何か問題が起こってから対処するのか。プロジェクトマネージャの力量の差は、この点に集約されるといっても過言ではない

PMBOKはプロジェクトマネジメントの専門用語とガイドラインを提供する書籍である。
国際的に標準とされているプロジェクトマネジメントの知識体系(ガイド、手法、メソドロジー、ベストプラクティス)であり、建設、製造、ソフトウェア開発などを含む幅広いプロジェクトに適用できるプロジェクトマネジメントの基盤を提供している。

 1.リスクマネジメント計画
 「リスクマネジメント計画書」は、個別のリスクに対する計画書ではなく、プロジェクトの計画時点で、プロジェクトで発生するリスクをどのようにマネジメントしていくかを決めること。例えば、リスクを認識したら、誰がどういうシートに何を記述するか、また、そのリスクをどう評価し優先順位付けるかを定めておくこと。

 2.リスク識別
 関係者からの話や、成果物のレビューなどを基にプロジェクトのリスク事象を把握する。ささいな気掛かりがリスクの芽であるケースも多く、これを「トリガー」(リスク兆候)として認識することも重要である。

 2.定性的リスク分析
 認識されたリスクを「現実のものとなった場合の影響度」と「発生確率」の2つの観点から評価する。この評価を基に取り組むべきリスクの優先順位付けを実施する。

 3.定量的リスク分析
 優先順位付けされたリスクを数量的に分析し、おのおののリスクがプロジェクトに与える影響を考慮し、どのリスクにどの程度注力するかを決める。場合によっては必要となるコスト・スケジュールのコンティンジェンシー予備の規模を決める。

 4.リスク対応計画
 個別のリスクへの対応策である。負の要因については、発生しないような対処、あるいは、発生した場合の影響を最小限にする施策を「リスク対応計画書」として取りまとめる。

 5.リスクの監視・コントロール
 いったん識別されたリスクは、必要がなくなるまでプロジェクト期間を通じてモニタし続ける必要がある。これは、プロジェクトの状況が変われば発生確率や影響度が変わるケースがあるためである

実際のプロジェクトは、上記のプロセスではなく「頭の中でのリスクマネジメント」が多いのではないだろうか。

リスクの洗い出しに必要なものは?
⇒リスクへ対応する際は、リスクの大きさ(影響と発生確度)と投入する資源とのバランスを取る。過度に資源に頼らず、対話や折衝、知恵と工夫で対処することが望ましい。

【感想】
「自分からいわない」点と「自分からあえて気付かないようにする」点これに立場や各個人の関係性などが加わればプロジェクトはスムーズには進まないのではとふいに頭を過ってしまった。
このような原因に「責任回避」「不要な遠慮」「無責任・無関心」など上げられている。
私の個人的な経験からスムーズに実施されたプロジェクトは”一つもなかった”と断言できます。
つまり、突き詰めれば世の中の人全て「無責任・無関心」なのかなと考えれるかもしれません。
悲しい現実ですね

また、リスク管理については、リスクの種別、リスクの大きさ、投入する工数などをバランスに取るという事が一番大事だという事。
そのバランスを取るためにリンクの分析力、リンクの予想する力(リスクの兆候、懸念事項の明確性、システムの理解)などを強化する必要があると実感しました。

即活用!企業システムにおけるプロジェクト管理
https://thinkit.co.jp/free/project/1/8/1.html

【要点】

・業務フロー – 担当部門(ロケーション)
 業務担当者の役割分担が明確にわかるようにすること
 →業務処理の行われる場所を欄で分け、業務の流れに沿って記載すること

・業務フロー – 主なデータ
 ”データを書く派”と”データを書かない派”がいる
 →”デーユーザ自身が業務フローを書くような場合は、データを書かないケースが多いでしょうタを書く派”と”データを書かない派”が多い
 →我々のような開発サイドが業務フローを作成する場合は、主なデータを記載した方がわかりやすい
 業務の流れをデータの流れと対比させて見る目的さえ達成できれば十分である。

・業務システム開発の各工程におけるドキュメント成果物の種類について、弊社の開発ドキュメント標準DUNGEONをベースに説明。
 システム化の対象となる画面や帳票を業務フローに漏れなく記述すること、記述するデータ(テーブル)については理解を深めるための主要なものでかまわないということを覚えておくこと。

【感想】
この記事を見て感じたのは、全てドキュメントは一度フロー図にしたほうが良いのでは?
人は言葉だけのものを完璧に理解するということはできません。だから、言葉を”自分が理解した形”つまりフローにして見せる
そして、そのフローを第三者に見せ、その第三者が理解した時、初めて自分も理解しているという証明となります。
どのドキュメントも”まずは図解”という考えと持った方が良いのかもしれません。

教育課題図書「最強の働き方」第四章

第四章 一流のリーダーシップ

◎誰に対しても丁寧に接する
 ◆タクシーで偉そうにしない
   順位で対応を変える人は大成しない。
 ◆謙虚に頭を下げるから稲穂が実る

◎信頼を大切にする
 ◆信頼を失うリスクにナーバスになる
   どれほど人に信頼されているかが、リーダーシップのサイズを決定する。
 ◆賢い嘘つきより、バカ正直が出世する。
   失敗した時の対応が透明で正直であってこそ、「信頼回復のリカバリー
   ショット」を打つことができる。
 ◆仕事相手の長期的利益を尊重する
   信頼と人を大切にし、相手の利益を尊重する姿勢が長期的信頼を築く。

◎部下を尊重する
 ◆部下に敬意を表する
   部下を尊重する企業文化は、組織力を強める上で、強烈なパワーを発揮する。
 ◆冠婚葬祭の対応で、人間関係が大きく変わる
   仕事のコマとしてでなく、人間として尊重していることを示そう。

◎部下に得をさせる
 ◆部下の市場価値を上げる
   部下の自己実現を助け、その市場価値を高めよう。
 ◆カネを払ってでも、部下に面白い仕事をさせる

◎部下を成長させる
 ◆日陰の仕事もきちんと評価する
 ◆ザルの上司にならない
   簡単にはごまかせないという緊張感が、部下を育てる。
 ◆成長させてくれた上司への忠誠心は強い
   会社を辞める時、誰が一緒についてくるか?部下と客を連れて辞められる
   かどうかで、勝負は決まる。

◎規範を背中で示す
 ◆上司の背中を見て、部下は育つ
   リーダーのコミットメントが部下のモチベーションの源泉
 ◆先陣を切って出陣しない大将には、誰もついていかない

<所感>
昔、別の会社に居た20代後半の頃、強烈な上司がいて、大きな影響を受けました。
それはたぶん私だけでなく多くの人がそうだったと思います。それは私の直属ではなく、ましてやよその部署の方でした。それを上司と呼ぶのは、自分を育ててくれたと思っているからです。

その人の優れたところを上げるとキリがありませんが、関心したのは、会社問わず、自分のプロジェクトに関わる人全て、その人の成長を考え、そのために労を惜しまない姿勢でした。ですから、こちらも真剣勝負です。個人の成長を促しつつ、大儀であるプロジェクトを完遂する、それはどれほど大変なことだろうと思います。

しかし強烈なカリスマゆえに、耐えられず辞めていく部下もいました。また、そのカリスマを軽く操るそのまた上もいたようです。長い会社生活の中で、いろんな人と巡り会い、いろんな上司も部下もいます。その中で「この人と一緒に仕事がしたい」という上司に巡り会うのは運だと思いますが、そう思われるのは、努力できることではないでしょうか。