変更されない仕様とスケジュールは危うい

今の部署では、
１案件あたり２〜３週間の制作・開発期間で、
月に４、５本の案件をリリースするわけです。

その期間で、矢継ぎ早に
「デザイン〜開発〜テスト〜リリース」を繰り返すので、
開発が予定通り進められない場合や、
不具合を見つけられずにリリースに至る事があったりします。

これだけ頻繁にリリースを繰り返すので、
企画をまとめ仕様書に落とすのも大変ですから、
開発に必要な情報が全てそこに集約されることは皆無です。

それでも、基本的にはリリース日が決まっていて、その日程変更はごく稀です。

このような
・不確定要素がふんだんに盛り込まれた仕様書
・変更できないリリース日程
という状況で、うまく仕事を進める方法を模索中ですが、
まずはメンバーに以下の３つを意識付ける事をはじめました。

・(リリース日以外の)スケジュールは変更されるもの
・想定から変化があれば、すぐに相談すればよい
・リリース後に、うまく進められなかった事を振り返る

そもそも不確定要素の多い仕様書なので、
正確なスケジュールは出せるはずがなく、
変更のないスケジュールは非常に危うい。

「変化をいち早く察知できる仕組み」の導入と、
「仕様やスケジュールに変更するもの」という意識付け
が非常に大事になってくると思います。

そして、うまく進められなかった案件のときは、
必ずそのメンバーで振り返りミーティングを行い、
そこで判明した課題や解決策を
次のリリース案件へ活かすことがとても重要です。

この振り返りミーティングを、
案件のリリースの度に繰り返すことで、
頻繁にメンバー間に課題の共有がなされ、
メンバーそれぞれが開発ライン全体を俯瞰する視点を養い、
おのずと最適なやり方に近づいていく…

それが今の私の狙いです。
アジャイルっぽいですかね。

逆に、例えばテストが不十分で毎度バグをリリースしてしまう場合を想定すると、
解決策として「障害報告書を書かせる」ようなやり方を取っていては、
この課題を「点」でしか見ていないため、
いつまでたっても、良い方向には向かわない気がします。