■
昨日、M主任が対応した仕様変更でリリース漏れがありました。
しかしM主任は見計らったように熱でお休み。ぜってーねらったろ。(笑)
ただ今回誰が悪いかというと、実のところ私です。(笑) 原因はDBのマスタデータにコードを一つ入れ忘れただけです。
とはいえ、ある企業の業務が数時間とまるわけですから大問題です。
今の現場のリリースはある台帳を元にリリース物が管理されています。
仕様変更依頼が来た時点で、この台帳にこれから直すモジュールと追加されるコード値を記述しておき、リリース時にはデプロイヤがこれを元にリリースします。
今回は、仕様変更依頼が来た時点で、私自身がこの台帳に記述しておらず、リリース時のチェックの際にもまったく気が付かなかったわけです。
ではなぜそのリリースが漏れたか、その対策はどうするかを、現場PMと話していて自分なりに「あー」って思うことに出会いました。
自分としては、今後の対策として2つの案を提案しました。
- 設計書のレビューをする際に、リリース用の台帳も同時にレビューを受ける。(設計書レビューは仕様変更依頼のあとすぐに行われます)
- リリースの際に、前回リリース時のDBの状態と、今回リリース時のDBの状態を比較し差分をリリース対象とする。
前者は自分なりにウォーターフォールにのっとった回答だと思い提案した物です。
設計段階でリリースする物が決まるということは、変更する物を固定するやり方です。
後者はXPの1プラクティスである「日々のスキーマ移行」に対応する為に、有効だと思い提案したものです。
DBのスキーマやマスターデータを常に変更することを許容するのであれば、リリース漏れをなくすために差分をとるのが一番よいと考えたわけです。これなら自動化も出来るし。
XPのプラクティス
http://home.att.ne.jp/gamma/shata/articles/XP_UMLPress.html#2
しかしPMの答えは別のものでした。
後者の案は取り入れるべきだが、世の中それじゃ通らない。上流でそれを把握出来なければ、その為にかかる時間を見積もることが出来ない。
ただし、前もって変更をすべて予測するのは難しい。解決方法としては開発者がDBのスキーマやマスターデータに触ることを禁止し、変更があるたびにDB管理者が必ず変更を加え、DB管理者に台帳を記載させるべきだ。
この答えを聞いて「あー」っと思ったわけです。
管理者をつけるのが、いいやり方とか悪いやり方というわけではなく、責任は明確にすべきだなっと思ったわけです。
自分はいつも、ウォーターフォールであろうと、XPであろうとプロセス(手順)にそれを加えただけでは機能しないことをつい忘れてしまいます。
手順を示せばそれをみんなやってくれるだろう。っという性善説に基づいたアプローチをしてしまうのです。
今の現場では、常に責任を誰かに割り当て、役割を明確にすることで開発を進めようとします。
責任を押し付けあうプロジェクトは良くないですが、開発者に対して責任を明確に示すことは常に必要なんだと思います。
プロセスと責任が同時に必要なんだと改めて思った次第です。
