プロジェクトマネジメントと働き方を考える①

システムエンジニアの仕事が多量で、過労死や精神的な病気に至ったというニュースを聞くたびに思うことがある。

他の業界はわからないけど、IT業界におけるシステム開発プロジェクトでのSEメンバーの仕事量過多は、単純にPM(マネージャ)にプロジェクトマネジメントスキルがないから発生すると考えている。

プロジェクトがうまく行かないのはPMの責任?

見積りが小さすぎた、要員が調達出来なかった、仕様が拡大していった、顧客が無理難題を言ってくる、など切っ掛けになる原因は色々あるけど、プロジェクトを健全に遂行させるスキルが不足していることにより、適切な対処がなされないから、メンバーの作業量過多に繋がる。

1週間や2週間の一時的な作業量が増えることによる残業や休日出勤は、已む無いところがあるが、数ヶ月から1年単位で、多忙状態が続くとしたら、完全にPMとマネージャのスキルの不足が問題である。

では、どうしたら良いか。3つの要素から考えてみる。

《第1部・PMの意識改革》

まず、そもそもプロジェクトは成功しないものだという認識をしなければならない。

一般的に、プロジェクトの成功率は50%だという。PMがプロジェクト管理をしっかり行って、この確率なのである。

つまり、何もしなければ確実に失敗すると思って良いし、四苦八苦しても、50%の確率しかないということ。

その認識がまず大事。
ただし、これは『頑張っても五分五分なら、しょうがない』といって手を抜いても良いということではない。
リスク管理をしっかりしようという認識をして欲しいということ。

プロジェクトの成功とは?

そして次に、何が出来たら成功かをしっかり定義しておくことである。

Costは少しオーバーしても良いとか、Delivalyはもう少し遅れてもバッファがあるから平気とか。

犠牲にして良いものと、絶対に守らないといけないものは何か?を、改めて認識をしっかりするのが大事。
だって、PMのあなたがどんなに頑張っても、1/2の確率で失敗するので、最初から、もう最悪な事態のことを考えておいてしまうことである。

《第2部・プロジェクトマネジメントスキルの更なる向上と、マネジメント方針》

プロジェクトの遂行にあたっては、PMBOKで定義されている10個の観点を常に念頭に置いて進めていく。
プロジェクト管理の経験が少ないうちは熟練者に度々プロジェクトレビューを頼むと良い。

ここではPMBOKの説明は割愛する。

事前にマネジメント方針を決める

また、PMBOKでは10個の定義がされているけど、プロジェクト管理での究極のポイントは、QCDの3つ集約すると考えやすい。

例えば、Qが最も大事なら、品質重視で管理をし、もしやばそうなら追加コスト、もしくは、稼働の延期がすぐに発動できるようにしておく。
特に、結合試験のあたりで品質の状態が確認できる。ここで更なる試験や不具合修正の要員追加が必要になるかもしれないので、準備しておくのも良い。

Dが最も大事なら、日程が延びないように段取りを重視しつつ、障害は稼働後に取り除けるようにして、確実にリリースするための準備を優先する。場合によっては一部の機能を制限してリリースを行えるようにする。
欲張って、全部稼働させようと思ってはいけない。

Cを重視するというのは、D重視と密接で、いつでも機能を落とせるように優先度を付けて開発し、リリース直前にどれもこれも中途半端にならないようにする。
最悪なのは、どれも中途半端になってしまい、追加投資しないと、稼働できない状態になることである。
ミニマムな形でリリースして一定期間の稼働を実現させ、その後、機能拡張の追加投資を判断できるようにする。

このように、PMは、常にプロジェクト管理スキルの向上に尽力し、持っていきたい方向にハンドリングし続ける役割にある。

(続く)

《スポンサー広告》