【改修案件】改修案件なめるなよ！最初が肝心！って話w

今回は大きいシステムの改修案件は大変ですな～って話です（笑）

一般的に
すでに稼働しているシステムのバグを直したり、追加機能を実装したりというのが改修案件ですね

新規でシステム作るより簡単じゃない？と思う方もいるかもしれませんが実は難しい…

軽微な修正であっても思わぬところ（想定外の処理）に問題が発生したという事はたびたび発生するのですよ

何といっても、すでに動いているシステムですからリリース時に問題があると大変です(;’∀’)

たびたびリリースする案件であれば
「さっきまで普通に使えてたのにわけわからんエラー起こっとるぞ！」とクレームになるわけです

問題が発生した際には、原状回復、前バージョンへの切り戻し、根本原因の究明、対応策提示、対応工数の見積り、開発、再発防止…作業が山積みになります（笑）

次回は絶対ミスできませんよ（笑）

緊張感をもって作業をしなくてはなりませんね（当たり前ですけど）

ところで、案件参画初期は大体の概要は案件説明時にわかりますが、内部詳細は全くわからないですよね？

もちろん一番ミスが起きやすいのが案件参画当初という事になります

新規開発時から参画している人であればある程度システムの作りはわかりますが、リリース後の参画者は難度高となりますね

数10個のシステムと連携しているシステムであれば地獄です…（笑）

管理者は最初の頃はとても簡単なところを任せて、徐々に影響範囲が広くなる改修タスクを任せるといった工夫が必要です

よくできるエンジニアだからと言っていきなり難しいのはNGです

急かしてもダメですよ（笑）

修正における影響範囲の調査は非常に重要でここが肝です！時間をかけるべしです（笑）

私が参画したことがある改修案件でよいなと感じたのは

「システムの機能をシナリオテストのように実際に動かしてもらうトレーニング期間を作る」というものです

1週間ほど手順書のようなものを用意してシステムの挙動を確認してもらい、どんな機能があり、どんなシステムと連携していて、どんな業務なのかというのをなるべく理解してもらうというものです

この時の案件はすんなりと改修対応に取り組めましたね

自分がPMとかになった場合はこのような対策を取り入れていきたいものですね

改修案件なめると痛い目会うよ！という話でしたwww

ではっ