仕様変更との戦い

SEの勤務時間が普通ではないくらい長くなる理由は、

障害と仕様変更だと思っています。

私が現在参画している開発プロジェクトは今月末の現場運用開始に向けて

もう切替準備フェーズに差し掛かっていますが

プロジェクトとして設定した仕様変更の締切を超えてもまだ

ユーザー側から変更要望が複数発生しており、滑り込みで対応に追われています。

このような場合、プロジェクトマネージャ、リーダなどの管理チームとしてどう対応するかをまとめました。

お金を貰えても時間は貰えない

追加要望に伴う追加金額の請求はよく揉める場面ではありますが、

滑り込みの対応はそんな調整もする時間がなく、

ユーザーは「お金は払うからとにかく納期までにやってくれ」というスタンスになります。

ただし、期間がかなり厳しいものになります。

リスクを取ることになる

期間が無い対応には、品質面でのリスクが伴います。

• 間に合わせるためにテストが省略される
• 切替準備と並行している事による資源管理のトラブルの可能性

これらを説明しても、そんなのは開発側の問題だろうと思われますが、

開発側がそのリスクを抱えて作業をするという事をよく認識し、
出来るならユーザー側にも伝えます。

人をどう確保するか

時間も体制も無い所から、仕様変更を対応する体制を取らなければなりません。

しかし、全く新しい人を入れても時間がかかりすぎて間に合いませんので、

今いる人にお願いする事となりますので、何か作業を剥がしてあげる必要があります。

変更作業が出来るスキルがあり、自分以外でも出来る作業をしているという人を探してお願いするように調整します。

デグレードのリスクをどう回避するか

資源の変更状況をしっかり把握することが何より大事です。

誰がいつ何を修正するのか、

構成管理ツールに頼らずプロジェクトとして変更管理を綿密にします。

管理チームだからといってプログラムの修正箇所を把握しておくことで、

少しの変更でも対応できる柔軟性を持つことが出来ると思います。

信頼を高められるチャンスである

このような、プロジェクトにおいて想定外な変更はユーザー側も、無茶を承知で依頼しています。

ここで開発側が頭から拒否するのではなく、リスクを取りつつも確実に対応し、成功に導くことで

ユーザーからの信頼、感謝を勝ち取ることが出来るのだと思います。