教育・訓練 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をベースに説明。
 システム化の対象となる画面や帳票を業務フローに漏れなく記述すること、記述するデータ(テーブル)については理解を深めるための主要なものでかまわないということを覚えておくこと。

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


コメントを残す