ソフトウェア開発プロジェクトは定形化しにくい。常に進化する技術、物理的な制約をほとんど受けないソフトウェアの特性などが原因の一つだ。定形化できないので個別に計画を立てる必要がある。そして計画時に「本来は必須の作業」の考慮を漏らして、あとで後悔することになる。後悔先に立たずの果て。
5．作業を計算に入れ忘れる
テストのような必要不可欠な作業を計算に入れずに決められたた めに、破られた締め切りがいくつあったことか。これが、作業を部分的なタスクに分割しないままスケジュールが決められた仕事を決して引き受けてはならないもう1つの理由だ。そのスケジュールの見積もりには、なにか重要なことが抜けている可能性がある。
ソフトウェア開発プロジェクトを蝕む10の典型的な過ち - CNET Japan
最悪な作業洗い出し方法
作業の洗い出し方法で最悪だと思うのが以下の3つ。
- 過去の計画を参考にして洗い出す方法
- 詳細は以前に書いたこの記事を参照。過去の「計画」が正しいと思うのは間違いだ。「実績」を見るべきだが、往々にして「実績」は再利用可能なように記録されていなかったりする
- 社内標準のテンプレートを使う方法（もしあれば）
- そのテンプレートに「間違いがあったら死をもって償います」という作成者の署名があれば使ってよい
- だいたいこの類は情弱向けの罠であることが多いので注意
- 過去の経験を元に見様見真似で考える方法
- 経験はブラスアルファであって土台にするものじゃない。まずは「知識」に基づくべき
作業を漏らさないために
自分ではいくつかのチェックリストを隠し持っていて、それをもとに作業が漏れないように注意している。たとえばソフトウェア見積りでは「見積りから一般に見落とされる機能要求と非機能要求」「見積りから一般に見落とされるソフトウェア開発アクティビティ」「ソフトウェア開発アクティビティ以外で見積りから見落とされがちなもの」のリストが載っていて参考になる（よく参照する）。
ソフトウェア開発アクティビティ以外で見積りから見落とされがちなもの
- 休暇
- 祝日
- 病欠
- トレーニング
- 週末
- 全社ミーティング
- 部署ミーティング
- 新しいパソコンのセットアップ
- パソコン用の新しいバージョンのツールのインストール
- ハードウェア問題およびソフトウェア問題のトラブルシューティング
あとは、出来上がった計画をプロジェクトメンバーにレビューしてもらって精度を上げていく。ただ、完成した壮大なリストやガントチャート図だと「見ただけで嫌になる」人も多いので、レビューする際には箇条書きにまとめたものを使うとか、ブレスト形式でホワイトボードを活用してやるというのも手だ。Manage It! 現場開発者のための達人式プロジェクトマネジメントでは付箋を使って計画する方法が載っていて、けっこう参考にしたこともある。
そもそもソフトウェア開発プロジェクトの計画は「設計の一種」だと考えている。事務的な作業として安易にやってしまうのは失敗への近道。
