システム開発を請負った事業部からの報告内容は、基本設計での出鱈目な報告ぶりから想像できるように、顧客に提示される資料がシステム開発をしている実態に対して正確なものではなく、自らに都合のいいような内容にねつ造されているというのが何となく分かってきたような気がしていました。其の証拠は、私が嘱託を解任されてこの顧客に派遣社員として仕事をしていた時に私自身がシステム開発を請負った事業部から提出される資料を解析して改ざんの証拠を見つけました。その内容は後ほどに書く事にして、基本設計は９月末に終了して１０月から半年も掛けてプログラムの製造が中国で行われたのでした。その中国でのプログラム製造についての仕事振りについては一切開示もされず説明もされなかったので、毎週プロジェクト会議で報告されるプログラムの製作本数が唯一のものでした。
先回お話ししたように、１０月以降はプログラムの製造フェーズなので顧客との会話はない筈でしたが、毎週のプロジェクト会議では基本設計書の間違い・訂正が毎週のように行われて、基本設計書の訂正が殆どなくなったのは年を明けてのことだったと思います。
何が不思議化と言えば、毎週のように設計書の修正が入るのに、それがプログラムの製造変更にどのような影響があるとか、製造の遅延に影響するかが全く説明がされないことでした。システム開発を受託した事業部では顧客の情報システム部担当者から基本設計書の間違いや訂正の指摘があると「はいはい」と生返事をして、後日設計書を修正して顧客の担当者に送り返すという作業が繰り返されるだけでした。顧客の担当者も基本設計書が修正・訂正されてやれやれと思っているだけで、その先の事には全く思いも及ばないと見えました。
基本設計書の変更があるならば、当然ながらプログラム仕様書も変更されるはずであり、そのプログラムに関わるデータも修正するかどうか検討をしなくてはいけないはずなので、基本設計書の少しの修正でもプログラム製造には大きな影響を与える大きな要素です。それ故に、システム開発ではフェーズを切って、仕様を確定してから次のフェーズに入るということを原則をとしているのです。
金魚の糞よろしくぷちぷちと基本設計書の修正が１０月以降も発生しているにも関わらず、同時に重要なサブシステムの基本設計書は１２月末に何とか完成にたどり着いていたので、プログラム製造は全く問題なく進んでいるという報告に違和感があったのは当然でした。当然ながら、違和感を持ったのはプロジェクト関係者では多分私だけで、顧客はそんな疑問を微塵ももたず報告通りに順調なのだろうと理解をしていたと思います。プログラム開発の手法を理解している人には、上記のような状態であれば、プログラムの製造が順調なはずであるわけがない事は自明の理だと思いますが、素人集団の顧客には全くそういう意識はなかったと思います。
このシステム開発で新規に開発するシステムの範囲が小さくて割合に平易なものだと分かって、システム開発を受託した事業部では顧客に報告をしても理解出来ないからと、自らに都合の良い理屈をつけて適当な報告をこのプログラム製造の時期に行っていたのではないかというのが結論です。基本設計のけじめもつけられないで、プログラム製造を開始すること自身がシステム開発を理解していなかった証と理解しています。そういう連中を陰で支えて放置していた役員も同様の技術レベルで、顧客から受託した仕事に責務を果たしていなかった罪は重いのではないかと思っています。