アジェンダ

これだけは覚えていってね

要求の変更やインシデントに対し、
変更管理することでプロジェクトへの影響を最小限にして対応する。

プロジェクトマネジメントの領域では、
プロジェクトの進行において、変更は起こりうるものと認識されています。
変更管理という行動はプロジェクト開始したときから行われます。
ニュアンスとしては、準備と考えてもらうとよき。

ちゃんとPMBOKにも載っているかんね。
※PMBOK=プロジェクトマネジメントの知識体系

プロジェクトの進行は立ち上がりの時ほど、
コスト(見積もり)と結果の乖離が大きくなる可能性がある。

計画、リスク洗い出し、振り返りがあっての変更管理。

そのようにしてプロジェクトのチームを強化していかなければ、
何度となく変更管理が発生しプロジェクトの失敗に繋がることになる。

WBSや見積もり、変更を管理するには変更を監視するための計画が必要。
作業者が迷いなく進められるくらいに詳細であること。
抜けがちな作業としては、異常系や非機能系。
見通しが立たない範囲は別途計画を立てるようにするほうがオススメです。

インシデントにたいして予め対策を立てておく。
Bプラン。

次、同様の変更管理が発生しないように、
原因の追求と対策をしっかり行う必要があります。

主に、変更を要求する者がプロジェクトマネージャーに対して変更を要求する。

主に3点くらいは押さえておくとよきかと。

プロジェクトを成功させるために詳らかにする。
これらの情報をもとに変更の決裁を行う。

変更管理"だけ"の話なので
｢何かあれば変更すればいいや!｣｢変更してよかったんや!｣とみえてしまっていたらすみません。
それは文章の書き方がまずいか認識の間違いです。

プロジェクトの管理者は、変更管理が発生しないように
計画、リスク洗い出し、振り返りなどを実施する必要があります。
そして、もし変更管理が必要になった場合は、詳らかに情報を共有しながら、
プロジェクトの成功へ向けて最小限の影響でおさまるよう努力しましょう。
それがプロジェクト管理者の義務です。

変更管理が発生しなければしないほどプロジェクトの成功の可能性が高くなってくると思います。
プロジェクトは変更が発生するものですが、その変更に柔軟に対応出来るよう常に準備して進めましょう。

ということで明日はyou1933さんで
『Unity　ちょっとシェーダーで遊んでみた』のお話です。
you1933さんのシェーダーテク楽しみっす!
では、よろしくおねがいします!