このシステム開発を受託した事業部が本当はシステム開発について無知であることが最後になって判明したのは保守体制についての話が出た時に明らかになったと思いました。同時に、この事業部はシステム開発業務を全て外注業者に丸投げするような仕事しかしてこなかったのではないかという事も浮かび上がったものと思いました。１０月に本番テスト（受入テスト）が始まっても障害だらけで計画した２ヵ月で終わる気配もなく、とうとう５月まで継続して受入テストが行われたのは以前に述べた通りですが、その時に話題になったのが本番以降の保守費用問題でした。
システム開発を受託した事業部のプロジェクトマネージャーは開発費用の何パーセントとか言うのを盾にして最初は８人必要ですとか、最後でも５人は必要という様な体制と費用を主張していました。この話を情報システム部員から聞いた時、このプロジェクトマネージャーは顧客の業務やシステム内容を全く理解していないのではないかと思いました。システム開発後のシステム維持や保守体制というのは、基本となる顧客の情報システム部員支援に、システム開発をしたベンダーからどの程度の負荷が必要であるかを考えるのが基本です。システム開発を受託した事業部では、そういう観点ではなく単に開発費用のパーセンテージで提示してきたのでした。年間数億円という数字を提示されて情報システム部員も驚かされました。私は元々開発費用が市場よりも倍もする開発費用であると試算していたので、この保守体制検討についても当然ながら反発を感じたのでした。
システム開発のプログラム製作が終わるあたりの時期から、私はシステムの本番後の運用分担について整理が必要と思いついて、顧客である情報システム部とシステム開発をした事業部とで行う運用業務の分担表を作業ごとに整理するサンプル表を作成しました。保守体制の話が出てきた時期には、この分担表も毎週の情報システム部とシステム開発を受託した事業部との打ち合わせでほぼ出来上がっていました。その分担検討途上で、アプリケーションプログラム運用業務も追加されたのは前回お話した通りです。
過大な保守工数を要求するシステム開発を受託した事業部に対抗する措置として、私は情報システム部員に対して、この表に工数を入れて合計すれば必要な工数が出ることを説明しました。その後、システム開発を受託した事業部と情報システム部員で数字を入れていくという作業を行いました。その結果を情報システム部員から聞くと１人月以下でしたという結果を聞いて、私の予測よりは小さいものだったので少しは驚きました。又、この時に情報システム部の課長が提案書には保守費用は数億円どころかもっと小さな数字が書いてあることも発見してシステム開発を受託した事業部に示すという事もありました。
私は保守契約については全く関わっていないので、実際の契約工数については知りませんが、システム開発を受託した事業部のプロジェクトマネージャーが主張していた人数よりは少なくできたと思います。
業務に複雑性は少なく、データ量も極端に少ないシステムで、システム開発を受託した事業部のプロジェクトマネージャーが大人数の保守要員が必要という発想をしていたのは、プロジェクトの最後の最後まで業務実態を理解していなかったと言われても仕方のないような主張をしていた事だったと思いました。この時、システム開発を受託した事業部では、プロジェクトマネージャーに加えて、統括プロジェクトマネージャーに副事業部長という幹部も揃って会議に出席していましたので、プロジェクトマネージャー自身というよりも事業部としての主張であったと思います。