無駄について
寝付けなかったので、ちょっと追加。
以前、プロジェクトの中で無駄は省かなくてはならない、と書いた気がします。
省かなくてはいけない無駄とは何か、を考えないと正しいものは見えてきません。単純に「作業していない時間=無駄」とするのは大変危険です。いざという場合に対処するバッファを持たないだけでなく、見えている作業以外の事について考える時間が無いからです。
たまに、何もしていない時間をただの暇と捉えて、更に負荷をかけようとする管理職がいますが、こういった人の存在はたいていの場合、そのプロジェクトにとって有害となりそうです。もちろん、その隙間の時間でソリティアをしているなら話は別ですが、そうでない場合、現場の人間には一度キーボードから手を離し、スクリーンセイバーを起動して、今までの自分の仕事が妥当かどうか思い返す時間の方が、無理して作業を作り出すより全然意義があります。
もしかしたら、見過ごしているリスクがあるかも知れません。そういったものに気づくのには、リスクが欠陥として露見するのを待つという他に、チームの過去の仕事を振り返り検証するという選択肢があります。隙間の時間を埋めようとすると前者の選択肢を選ばざる得なくなります。
それは、仮にそれが他人からミッションとして過去の仕事の検証をしていたとしても、見過ごされるか意図的に見過ごされる可能性があるからです。チームの中で自分のミスを告白するのは、なかなか勇気のいることです。それが、仕事として自分の仕事を振り替えろ、と言われた場合、よほど強気な人間でなければなかなか自分の過去生んでしまったリスクを発表するのは辛い事だからです。
一人で勝手に振り返り、リスクを見つけたら告白する覚悟を決める時間を与えてやり、更にそれを受け止めて精神的なフォローまで出来る時間の隙間があったら、今まで見つからなかったリスクより多くのリスクを見つける事が出来るでしょう。リスクという単語を欠陥、バグ、不具合といった単語に置き換えても、同じ事が言えると思います。
欠陥を見つける為には精密なテストケースの作成が不可欠です。その為のテストを設計する時間、ケースとして記述する時間、ケースを検査する時間、実施する時間、結果を分析する時間を確保できるようなテスト工程のスケジュールが得られれば、今身の回りで起こっている障害を減らす事が出来ると思います。
「デッドライン―ソフト開発を成功に導く101の法則」を読み終わりましたので、次の本を悩んでいますが「ゆとりの法則」も選択肢として非常に有意義かも知れませんね。