自分が担当してるアプリケーションはサードパーティと連携する箇所がほとんど。つまりサードパーティ側で仕様変更があるとこっちも仕様変更対応が必要となってくる。しかも仕様変更日より前に対応が終わってる必要があり、緊急度・重要度が高い割り込みタスクとなってしまう。
今年は特に割り込みが多かった（またあるかもしれないが）。対応を前に進めるために気を付けていたことを列挙する。
関係者には早めに連絡する
関係者とはPMやビジネス部門など、スケジュールに関わる人のことを指す。スケジュール変更が必要なんだよと説得する時間を極力短くしたい。
とにかく早めに「仕様変更の影響でうちにも作業がありそう」レベルで第一報を入れる。どのみち対応が必要になるんだから抱えておくメリットがない。
サードパーティ側が説明する場を設けてくれた場合、一緒に聞いてもらえないか打診する。ただでさえ時間が惜しいのだから内容の伝言ゲームによるロスを避ける。
対応リストとスケジュールをすぐ洗い出す
仕様変更内容が明らかになった後、すぐ次のことを実施する
- 自分のアプリケーションで変更が必要な箇所を洗い出す
- 作業量が分からないと既存の仕事と並行で対応する羽目になって倒れてしまう
- データ補正が必要か確認する
- サードパーティ側で保持しているステータスを管理していないか確認する。本当はステータスを都度サードパーティ側のAPI等から取得してくるべきだが、古いアプリと通信する場合それが不可能なときもある…
- ユーザーに直接影響が出る範囲を確認する
- 通知が必要なレベルか
- バリデーションルールが変わる場合はユーザー説明が必要。ユーザーサポートに関わる部署にも展開が必要
担当をすぐ決める
通知はこの部署で担当、仕様変更開発は誰…など、タスク割り振りをさっさとやってしまう。もたつくほど対応に避ける時間が減り、炎上に近づいてしまう。
スケジュールを握っている人と最優先タスクを握り直す
仕様変更対応と既存の対応、どっちが大事ですか？を必ず握っておく。2つ同時は無理なので。残業して対応は論外なので、〇〇の代わりに××の優先度や期限は後ろにずらしますと認識合わせする。
優先度が低いタスクの期限を熟練度が低いメンバーに回し、完了後にリリースとかはありかもしれない。ただ実力が低いメンバーの巻き取りが必要になると苦しくなってくるのであまり言わない方がいいかもしれない。「お願いしてたのができたんで進めますね」とかで良いと思う。
総括
とにかく関係者を集めて対応スケジュールを速く決めるのが重要。やることがわかれば後はやるだけなので。
でも、流石に頻度が多すぎて疲れてきている。あと最近タスクを潰すことに気が行き過ぎて、品質に対する意識が落ちていることを実感して反省している。
仕様変更が多そうなアプリケーションにはアサインを厚くするなどマネジメント側にも工夫してほしいな…とか思っているのでした。
