ソフトウェア開発プロジェクトは、ちょっとした問題によって打ち倒されてしまう事がある。少しずつ状況が悪化し始めると雪ダルマ式に問題が山積して、最後には破産する。立て直すことも可能だけれども、できれば破産させないほうがいい。破産する前にやれることは、ある。
Bob Hartman氏のAgile antipattern: Target fixationより抜粋して適当翻訳。
ありがちな話。日本でよく言われるのが、「期日までに使わない(と思われる)機能も全部作れ、契約だから」とか。限られた時間軸の中で変化を受け入れながら進めている中でこういうのを要求されると、品質やチームのモチベーションやコラボレーションを犠牲にしはじめてしまう。このような状況が続けば焼畑農業のようにチームには何も残らなくなる。結果として顧客にとっても幸せな結果にならない。
ゴールを決め過ぎてしまうことによって陥る罠 | Ryuzee.com
ソフトウェア開発プロジェクトで、仕事量や問題・不安が一定量を超えると「問題の先送り」が始まり、多重連鎖的に問題の総量が増えてしまう事がある。メンバー各人が少しずつ品質を端折り始めたり、問題を先送りしていく。本来は今やるべき事をやらなくなる。メンバー間のコミュニケーションが減っていく。他人にかまっている暇がなくなる。プロジェクトの「あそび」が無くなってしまう。許容量を超えた問題が最後に吹き出して、プロジェクトを打ち倒す。
負債を管理する
上記の記事の元ネタでは「正しいことをする」という結びになっているが、それは最終的な判断だと思う。決断をする前に、状況を整理した上でメンバーが直面している「問題」や「プレッシャー」をいったん棚上げするのが良い。単なる棚上げなので解決するわけではない。プロジェクトの「負債」としてメンバーから取り上げてあげる。例えば、
- 製造中に判明した影響範囲の大きな不備
- 不可能ではないがリカバリには困難を伴う作業の遅れ
- 顧客からの変更要求
などがこれに当たる。真正面から受け止めると大きな痛みを伴うこれらを「負債」として一旦メンバーから切り離してしまう。
- 不備の対応は保留して、当初の認識で製造してしまう
- 遅れを解消する為に、レビューやテストの一部タスクをスキップする
- 仕様変更を留保する
もちろん「負債」も残るが、プロジェクトの健康状態が回復する。絶えかけていた目配りが戻る。課題の見落としやミスが減る。リズムが戻る。
プロジェクトの倒産を防いだら、あとは計画的に「負債」を返済すればいい。ウォーターフォール形式の開発プロセスであれば、後続の計画を見直す事によって解決を図ることができる。
- 結合テストの段階で広範囲の一括改修を行う（または、改修漏れをブロックするようなテストケースを組み込む）
- 割愛したプロセスを補完する活動を実施する（たとえば強化レビュー）
- 旧仕様で顧客にデモをした上で仕様変更を行う
ウォーターフォールのような計画駆動のアプローチなら、リリースまでの期間が数ヶ月以上あるのが一般的なので、負債のプロジェクト期間内の返済も十分可能だ。アジャイルアプローチの場合は、イテレーションの期間が短い為にリリースまでに負債を返すことは難しい。リリースを延期するか、制約事項として持ち越した状態でリリースするという判断になるのだろうか。
コストオーバー？それについては何とも言えない。しかし、誰かがどこかの段階で失敗しているのだから、その責任を取らなければならないのだろう。
