システムを使い続ける間にビジネス環境は目まぐるしく変わる。この状況に対応するには、主戦場を稼働後に移して改革すべきだ。開発担当、運用担当、利用部門の3者が一丸となる新たなプロセスを確立しよう。
システムの開発・運用現場には不満の声があふれている。開発担当から運用担当への不満、運用担当から開発担当への不満、利用部門から開発担当への不満などだ。
以下では、取材を基にまとめた、現場でよく起こっている四つの不満パターンを紹介する。個人や企業は架空のものだが、個々のエピソードは、現場の証言に基づいて作成している。
開発担当の不満：保守開発に必要な情報が足りない
大手SIerのX社に勤める開発担当のAさんは、過去に構築したユーザー企業のシステムに関する依頼を受けた。その企業のシステム部長の依頼はこうだ。「大幅な機能追加をしようと思っているが、その前に既存システムの問題を解消しておきたい。稼働後5年経ってもたびたび障害が起こっている。システムのアーキテクチャー的な問題があるからだと思う。これまでに起こった障害内容を分析して根本的な原因を究明し、解消してほしい」。
該当システムはAさんらが5年ほど前にスクラッチ開発したもの。その運用は、X社の子会社であるY社が担当している。AさんはY社の運用担当に、過去の障害傾向に関するデータを提出してもらった。しかし、Y社には障害対応履歴しか存在せず、その内容は表面的なもの。根本的な原因を分析するには情報不足であった。そこで、実作業を実施したY社の運用担当に協力を依頼したところ、「分析のための工数は取れない」と断られた。Aさんは、運用担当が子会社とはいえ別会社であることに壁を感じた。
結局、既存システムの根本的な問題を解決できず、Aさんは顧客に全面刷新を提案するしかなかった。IT部長からは「同じX社グループなのに、なぜ運用の情報が開発担当に伝わらないのですか」と厳しく言われた。Aさんはシステム部長の信頼をなくし、そのシステムは別ベンダーにリプレースされてしまった。
