保守開発案件に参画して5か月経ちました

それまではバックエンド側の新規開発案件に参画していたこともあり、
勝手が違うなと思うことが多かったのです

私自身が「ここが違う！」と感じた事を紹介していきたいと思います

1. 調査期間が長く、開発期間が短い

調査を2日して半日で開発というものがあることや、

調査を2日して開発はしなくていいやということがある

既存で稼働しているシステムに対して開発するという事になるため、
開発するにあたっての影響範囲調査がとにかく緻密です

簡単なところで言いうと
ある問題を解決するために修正を行ったソースが実は他の機能でも使用されており、
そのほか機能で不具合が発生するというものですね

稼働しているシステムであるため、とても大きな問題となるんですね

なので、調査工程に重きが置かれています

調査工程でミスをしたら終わりって感じですね( ;∀;)

2. あれっ？設計書…？

です（笑）

保守開発案件でよく目にする方も多いと思うのですが

「実装と設計書の内容が違くね!?( ;∀;)」というものです

新規開発時はしっかりと内容が合致しているはずなのですが、
保守改修を進めていくうちに設計書と実装が合致しなくなることがあるようなんですよね

「ちょっと直したところの設計書修正が漏れていた」とか
「設計書の所在が分からずに実装のみを修正した」といった感じでしょうか？

後任者はとても困りますよ（笑）

3. 実装途中で方針が変わる件…

調査 ⇒ 見積り ⇒ 資料修正 ⇒ 実装 ⇒ テストに着手というところで方針転換というのが良く発生するんですね

リリース前に動作確認などのレビューを担当者の方に実施していただいた際に、
「っん？見積り時の2つ目の案のほうが使いやすそうだからその対応方針に変更して！！」と開発に入ってから方針転換というのがあるんですよ…

ここでせっかくここまで開発進んだのに…また一から開発か…となるわけですね

この急な方針転換にストレスを感じやすい人は嫌になるのかなと思います（笑）

いかがでしたでしょうか？

私が参画してみて思った感想の一部ではありますがこんな感じです（笑）

世の中にはさまざまな案件があり、案件によって特徴がありますよね

今回は保守開発案件の特徴を一部を紹介しました

面白そうだなと思った方は保守開発案件に参画してみてください（笑）