このプロジェクトでは基本計画から基本設計にフェーズが変わる時が山場だったと思いました。山場というのは、このまま続けてシステム開発はうまく終わるのかどうかという見極める最後のチャンスだと思いました。しかしなすすべを思いつかない顧客のプロジェクトマネージャーは当初の計画を進める道が普通だと感じていて、そのまま続ける道を選択したのでした。一時中断して、再度ベンダーを選択しなおせるチャンスだとも思いましたが、全くそういう風には感じていなかったのが不思議でした。
システム開発を請負った事業部のプロジェクトマネージャーの力不足で見積もりは遅れる、毎日の仕事はミスだらけで顧客担当者からは不信が出るというような状態でした。こういう状態を見れば、この先本当に大丈夫かというような確認が必要であったと感じていました。
しかしシステム開発を続けたい仕事の無い事業部の連中はごり押しして早く注文をよこせと、顧客の案山子同然のプロジェクトマネージャーに迫って脅したのでした。顧客側のプロジェクトマネージャーは外見は真面目そうに見えるのですが全く何も分かっていないので、プロジェクトを計画通り進めて終わればよしとしか思っていなかったようでした。この御仁、自分ではプログラムを書いていたと言っていましたが、システムについては何も理解をしていないと思いました。システム云々よりもシステム開発を計画通り進めることが自分の仕事だと思っていたのが大きな間違いであるというのを最後まで気づかなかったようでした。
相手が善意の人間ならばそういう選択も間違っていないと言えるかもしれませんが、金のためには何でもやってしまうとう集団であるというのを半年の間に気づかなかった事にも大きな問題があったのだと思います。
ごたごたしながら基本設計というフェーズを始める頃には、顧客の担当者からは「次のシステム開発ではお宅は選択しません」という様な事も語り始められました。担当者は基本計画での資料レビューで散々な目にあわされたので、これ以上はごめんだと感じていたのかも知れませんでした。しかし、その後の基本設計では同じことが繰り返され、もっと大変なレビューをすることになったのでした。
そういう部内の雰囲気を全く意にも介さなかったプロジェクトマネージャーへの反感もあったのかも知れませんでした。
この基本設計見積もりのごたごた以来、順調に進んでいたとしか報告を受けていなかった情報システム部長は自身もプロジェクトの中身を監視しなくてはいけないと感じたのか、週次のプロジェクト会議にも顔を出すようになりました。しかし部長もシステム開発の経験があるわけでもなく、会議の中身よりもきちんと事が運んでいるかどうかというような事しか理解ができないと思いました。
これから以降は私が情報システム部長に会議での論点を解説するようになり、毎週のように起きる様々な事についての解説をしたのでした。しかし問題の本質は殆どがシステム開発を請負った事業部の問題に帰結してしまうので、未だ社員であった私も少しはオブラートに包んで言わざるを得ないような事もありました。
この基本設計でシステム開発を請負った事業部が示した設計こそが始めてシステム開発というか、プログラム開発仕様書とでもいうべき代物でした。業務仕様書とプログラム仕様書が一体になったもので、中国での開発もできるような体裁になっていました。
ここで私は、情報システム部長に業務仕様は基本計画で書いた筈なので作業費用の二重取りですと解説したのですが、システム部長は相手から「少しは意味合いが違います」とシステム開発を請負ったプロジェクトマネージャーから説明されたと言って納得していましたが、私は全く納得のできない事だと思っていました。
費用の二重取りなので減額すべきだと思いましたが、システム開発を請負った事業部は外注丸投げなので当然そういう話には乗れないという事情もあって、適当に顧客に屁理屈を言って後は知らん顔をしていたという事だと思いました。こういう風に理解が不十分なままに仕事がどんどんと技術レベルの低いシステム開発を請負った事業部のペースで進んで行くのに不安は誰も持っていなかったというのも、このシステムがまともにできなかったという事の証だったかもしれないと感じています。