システム開発の基本設計が１月中旬から開始され、予定の５月末が毎月の様に延伸されて、最後には顧客の情報システム部長が「ええ加減にせんかい」と怒って９月末に止めたという状況でした。８月末には基本設計作業中止指示が顧客の情報システム部長からあり、９月中旬には始末をつけろという顧客の情報システム部長の指示は、システム開発を請負った事業部では対応が出来ずに結局９月末になって漸く終われたというような状況でした。システム開発を外注に丸投げしているので急には止まれないというのが目に見えた時でもありましたが、そもそも計画よりは相当に遅れているという事に関しては鈍感なように思えて、このシステム開発を受託した事業部はまともなシステムを開発した経験がどれほどあるのか甚だ疑問に思えたのでした。
基本設計は元々５月が９月末に延伸したのですが、プロジェクト管理上は基本設計を７月で終了として、８月から９月は詳細設計とするという風にシステム開発を受託した事業部から提示されたのでした。提案では７月から１０カ月間で実施する「詳細設計・製造・試験」というフェーズを分解して、「詳細設計」と「製造・試験」に分けて体裁繕いをしたのでした。システム開発を受託した事業部が行った歪曲行為という事実だけがのこりました。
そして元々の提案にはなかった詳細設計準備とか称した新たな費用も請求するという事があり、顧客は不満気ながらもシステムを作るのが最優先とばかりに、システム開発を受託した事業部の要望を全てのみ込んでしまったのでした。
同時に、詳細設計というのは基本設計フェーズで実施しているので、これを認めると費用の二重取りになりますと情報システム部長に解説をしたものの、情報システム部長はシステム開発を受託した事業部の説明を鵜呑みにして了解したのでした。
システム開発を受託した事業部の基本設計書は、業務仕様書にプログラム仕様書もついていて、その内容は世間一般でいうところの基本設計書と詳細設計書を同時に作成するというものでした。基本設計フェーズに入る時、システム開発を受託した事業部のプロジェクトマネージャーは「これが当社の標準の仕様書です」とだけ説明して、その設計書というものはプログラム仕様書も含んでいますとは説明しませんでした。顧客に基本設計書をチェックしてもらう段になり、顧客の担当者がプログラム仕様書は細かすぎてチェックできませんという事があったのは以前のブログで紹介した通りです。
システム開発を受託した事業部が基本設計書にはプログラム仕様書がついているというのを説明しなかったというのは、自らの仕事のやり方を顧客に説明したくないという理由があって説明をしなかったものと推測されます。この時、プログラムを製作するのは中国の会社なのですが、その発注経路が社内の取引利害があって二手に分かれていたということもあったのかもしれないと思います。最後まで顧客に対してそういう事実は説明されることはありませんでした。
そこには物さえできればいいという安易な考えがあるとしか思えませんでした。品質を考えていないという事の裏返しにもなると思われるものです。
プログラムの製作にあたり標準・試験とかはルールにのっとり行われるものですが、システム開発を受託した事業部では試験することも含めてすべて外注丸投げにしていたので、品質も２つの発注ルートに分かれたので、微妙に違うのではないかと考えるのが普通と思います。一つのシステムに２つの違う品質のプログラムが存在しているとも推測され、そういう製作ルートが分かれたのも障害発生の遠因と考えられます。
システム開発を受託した事業部では、基本設計フェーズの遅れの原因を全て顧客にあるとするのに対して、顧客では情報システム部長一人がシステム開発を受託した事業部の御託の反論を孤軍奮闘して作成するばかりで、情報システム部員は仕様書のチェックに忙しいというばかりで誰も部長を支援する人はいませんでした。情報システム部長は疑問をメールで窓口の営業部長に送付をするものの、営業部長は対応するのが嫌でメールをシステム開発を受託した事業部の関係者に転送するだけに終始したので、基本設計延伸問題はシステム開発を受託した企業としての対応は絶無のまま終わるということになったのでした。