構築メンバーと保守メンバーは仲が悪い？
システム更改を経験したことがある方なら分かるかと思いますが、更改機を用意するプロジェクトに所属する更改チームと、現行機の保守を行う現行チームが分かれていることは多々あります。
理由は単純で、更改作業を行おうが現行機の保守は続くから。業務切り替えを行うまでは、現行機が本番機です。
で、業務切り替えを行うと更改機が本番機。そして更改チームは現行チームに引継ぎをして去っていきます。
そういう構図なので現行チームからは「設計書のここが足りない埋めろ」「ここの作りが足りない、これじゃ引き継げない」などクレームが入り、対立構造になってしまう。
なので、更改した人が保守まですればそういうことなくなるのにな～と前々から思っていました。
更改チーム＝保守チームであることのデメリットもある
例えば、更改に伴いミドルウェアのバージョンを上げるとします。
で、バージョンの違いにより新しいバージョンには新規機能がある。普通はメリデメを整理して使った方がよければそれを使う設計にするはずです。
が、保守を自分でやることが分かっていると、「今動いているんだからこのままでOK」というバイアスが働きます。
要は、めんどくさいことは無理してやらなくていいじゃん、現行で問題なく動いてるんだし現状のままの方がよく分かっているし、という感じ。
更改と保守が切り分けできていないと、保守のことを考えすぎてむしろ全体として見ればマイナスな方に舵が切られることもあるんだな～と実感した話でした。
