炎上しないプロジェクトマネジメントをやりましょう

on


システムエンジニアの皆さんはどうやらMぞろいなのか、炎上案件ばかりご披露されますが。さますが、炎上案件を自ら起こしていたり、炎上案件になりそうなのに、メンバなのに放置や見過ごしていたり、気がつかなかったりしていたら

「共犯」


なんですから。


なので、炎上させないプロジェクトマネジメントをするプロジェクトマネージャやチームになるのが良いのは誰もがわかっていることです。


じゃあ、やれよ、って話です。「やっているよ」と即答する人はやっていないね。自分の手の届く範囲でしか。もうちょっと頑張ってチームメンバが全員で手を伸ばして隙間を埋めないといけない。手を伸ばすチームはステークホルダーもね、入っているからね。プロジェクトはSIerばっかりが頑張るんじゃないんだから。


計画は変わることが大前提
ウォーターフォールは計画駆動型のシステム開発手法だけれど、基本的に変化する前提のシステム開発です。変化することの対応押し方は多分、あなたが思っているより柔軟です。柔軟ですが、労働集約型に向いているシステム開発手法なので、生産性が高い工程前に仕様凍結や派生線表のマージなど管理面で高度な技が必要になるので普通のプロジェウトマネージャや頭のいいPMOが確保できない場合はシンプルな工程管理をモットーにしたほうがクレバーです。


工程の柔軟性は工程管理の難易度とイコールになるので、ちょっとずつ経験値を上げていくのがいいです。いきなり多重線表のプロジェウトマネージャをするのは難しいよ、ということです。


分担はしても隙間を作るな
チームで役割分担や、チームごとに役割分担をするんだけれど、それは主担当＝主な推進上の責任者でしかないのです。何かことが起きたら最後はプロジェクトマネージャなり、マネージャが腹を切ればいいんです。


メンバは、自分の分担＝サイロを守るのではなくて、チームの他のメンバと守備範囲が重なるように仕事に氣を配ることが大事です。そうしたちょっと余計に気にかけていると、周りも気づいてくれてアドバイスをくれるようになるんです。これ、どっちでやろうか、とか、ここインタフェースが変わったけど知ってた？とか。


成果は独り占めしない
成果というより成果物や中間生産物は独り占めしないことです。チームメンバ全員にアクセスできるようにしたり、自分のサブになる人を設けたりすることはリソース的なSPOFやトラックナンバーを予防する観点で必要なことです。


また、要件を整理したり、仕様を検討する際に適当に周りを巻き込み、考え方を共有することはとても大事なことです。独りよがりのアーキテクチャーや考慮漏れを第三者に見つけてもらえるから。


ソースコードだと、技術的負債の発生も低減できるでしょうし。


それ、プロジェクトにとって最適なの
今やっているプロジェクトの作業をするとき、要件の整理とか仕様の決定とかする際に、プロジェクトのためなんだっけ？、と問いかけてみよう。怪しいんですよ、以外と人の考えていることは自分の感情がベースになっていることが多いから。


客観的な顔をして、自分のやり方が少なくともプロジェクトの要件の実現になっていなければプロジェクトはうまく進まないんですから。



とこれらのことは当たり前なことですが、当たり前なことを当たり前にやることは難しいことを炎上させないでプロジェクトマネジメントをするプロジェクトマネージャは知っているものです。


ここで取り上げたことは炎上しない為の当たり前のことの一部ですが、炎上しない案件のほうが数百倍楽ですから、炎上さねないプロジェクトマネジメントをしましょう。