利用中のソフトウエアを改造する動機はいくつかある。第1回で見たように，改造作業にはリスクがある。不必要な改造はできるだけ避けたい。案件の種類を押さえた上で，選別するための作業フローを確立しよう。
案件は大きく，二つのタイプに分けられる。一つは，バグの修正に代表される「無条件で行うべき改造」である（図1の上）。法改正や税率変更といった，対応しなければ業務が成り立たなくなる環境変化も，このタイプに入る。
 |
| 図1●改造案件の種類 改造案件の種類改造案件には，バグの修正や法改正への対応といった，たとえ多大なコストがかかろうと避けて通れない案件がある。一方，利用部門からの要望の中には，「部門最適」や「趣味」などが混じっていることも多い。そのため，費用対効果の観点から案件を選ぶ仕組みが欠かせない [画像のクリックで拡大表示] |
バグは，あるとき急に出てくることもあるが，多くはシステムを稼働させた直後にまとまって出てくる。住友林業で基幹システムの構築に携わってきた情報システム部の宮下氏は，「バグなのか仕様変更なのかグレーなものを含め，初期のバグ対応は稼働開始して3カ月から半年で落ち着く。これらは新規開発後に必ず出てくるものとして，あらかじめ対応コストを見込んでおくべきだ」と話す。
一方，システムが安定した後に利用部門から出てくる要望は，「選別すべき改造案件」と言える（図1の下）。「新商品/新サービスの追加」「ユーザー・インタフェースの改善」「業務フローの変更」など様々な要望が上がってくる。しかも，“システムを利用中”であるため，寄せられる要望は経験に裏打ちされている。新規開発に比べて案件は具体的だ。こうした案件をうまくさばくことが，ソフトウエア改造を成功させる第一の仕事である。
