こんにちは、Hです。
皆さん、日々のプロジェクトはいかがですか？
スケジュールの遵守に加えて、成果物の品質を求められるソフトウェアエンジニア。
コストコントロールに加えて、各種調整や上位層への説明に奔走されるプロジェクトマネージャ。
なかなかゆったりとした中で開発プロジェクトを進められないのが現実だと思います。
でもあまりに急ぎすぎると、結果として手戻りが多くなってしまうのではないでしょうか？
今日はそんなお話です。
計画・目標を立てるには？
皆さんの現場ではプロジェクト計画や各工程の計画はどのように立てられていますか？
計画書のひな形が用意されているのでしょうか？
それともこれまでの経験からWBSやガントチャートを用意して実施しているでしょうか？
いろいろなやり方があってよいと思います。
また毎回作成するよりは過去のものや日々利用しているものを使うほうが効率も良いと思います。
ただプロジェクトの特徴は下記の通り。
- 有期性：期間が限定されている
- 独自性：個別にユニークで同じものはない
- 相互関連性：相互に関連する作業の調整がなされる
計画書をコピー・ペーストで使うのはやめたほうがよさそうですね。
プロジェクトや工程のゴール設定から始まり、下記のようなことを検討して決めていかないといけません。
- 作業スコープの定義
- 成果物の定義
- 成果物に対する品質保証
- 作業スケジュール
- 要員計画・体制作成
- コミュニケーション計画
- ファシリティ
そのため計画書をコピーしたとしてもそこから対象プロジェクトの内容に応じて
カスタマイズする必要があるわけです。
最終的には作成したものを顧客と合意して、作業を進めていきます。
現場が疲弊する計画の立てさせ方！？
計画を立てさせない、もしくは超短期で計画を立てさせることが
現場を疲弊させるにはとても効果があると思います。
※プロジェクトマネージャはこれをしてはいけません。
上位のマネージャの方は日々いろいろなプレッシャーがかかるのでつい早く計画書を
確認したがる傾向にあると思います。ですが、適当な計画は計画作成のために
徹夜をしたりとか精神的・肉体的なコストがかかるうえ、
作業の出戻りも発生して結果として大きな工数を取られることになりかねません。
少なくともある程度は練ったうえで微調整しながら進められるレベルにはしておく必要があります。
具体的な例として、、、下記のような指示が出されることで現場は追い込まれていきます。
・明日までにガントチャートを作成してきてくれ
・こんな作業は不要だからさっさと計画を出してくれ
・どうして計画を作れないんだ
昔のことわざにある通りです。
急いては事を仕損じます。
ただ常にプレッシャーはかけられます。
ですのである程度のひな形、標準形は自分の中で用意しておいたほうが良いと思います。
計画と進捗管理は分けておく
さて、なんとかして立てた計画。
こちらの計画に作業開始予定日や終了予定日が入ってくると思いますが
進捗管理の資料とはきちんと分けておいたほうが良いと思います。
計画書の中でWBSを作成したりするとそれをそのまま拡張して
スケジュールを作成されたりしますが、計画はあくまで計画。
場合によっては進捗管理のためのスケジュールがそのまま計画とイコールというところもあるかもしれませんね。
実際に作業を始めてみると計画外の作業が出てくることも多いと思います。
計画に比べてどの程度予定外の作業が出てきたのかを確認するためにも
計画とスケジュールは別にする必要があります。
これをしておくことで作業遅延の理由も明確になりますし、
計画の精度を後で振り返る時の参考にもなります。
さらには別の計画をレビューする時のヒントにもなります。
私の場合はWBSを作成したら、それは原本としてとっておいて
WBSをコピーしたのちガントチャートを作成するようにしています。
最後に
プロジェクトマネージャは最終的にはそのプロジェクトが目標を
適切に（QCDのバランス）達成できたかで評価されます。
目の前のプレッシャーとはほどよく向き合いつつも、
常に先のことを考えて今の作業を進めないといけないと思います。
私もよく陥ってしまいます。
世の中のプロマネさん、頑張っていきましょう！
