京都市基幹系刷新の2度の失敗でPOは何を意思決定したのか

20歳までと言うのは綾だが、でも実際にそうだ。正論や手法をそのままやれって言うのは、守破離の種の段階か、身につけるときの話であって、実際の運用に入れば正論なんてなんの役にも立たないし、邪魔にだけにしかならない。

技術で商売をしているエンジニアは意思決定の連続でものを作っているのだから、それをわかっていればなさなければならないことは正論を言うのではなく、意思決定だとわかるだろう。

 

tech.nikkeibp.co.jp

 

この京都市の基幹システム刷新プロジェクトは、一度失敗してやり直しをしたものだ。そもそも、この仕切り直しの案件をC社が応札したことに驚いた。てっきり、どこも手を挙げないか、大手コンサルがいいようにするのかと思っていた。

それはさておき、現行システムがあり、新システムがある。失敗したプロジェクトの成果物はあり、現行システムのドキュメントも官庁だからあるだろう。ドキュメントがないとしても、コストを掛ければ現行システムをコードからドキュメントに起こすこともできるし、実際、やっていただろう。

ちょっと調べたところ、失敗した最初のプロジェクトでは、新旧照合で不一致だったところが合意できなかったらしい。仕切り直しのプロジェクトも同じなのだろう。

でも、おかしいと思わないだろうか。稼働している現行システムと稼働しているコードがあり、そこには業務ロジックも存在するのである。どうせ現行システムと同じにとしか言わないだろうから、それを仕様とすればロジックは再現できる可能性が高い。

それでも完全な再現は無理だろう。

ここまで相当の時間とお金を使ってきた。これは事実で、これからもコストを受け入れられるなら今のままズルズルと何度もエンドレスサマーハルヒのように繰り返せばいいのだが、多分保守切れか特別延長しているACOSのHWの方が根をあげるかもしれない。

どんな規模のトラブルプロジェクトでも、最重要なのは意思決定である。

どうしても現行システムと新システムとの現新照合を一致させたければ、一致しない処理のロジックを現行システムは市の担当部局に説明させる指示を意思決定すれば済む話だ。この意思決定により、結果的に担当部局に要件を説明させることになる。新システムの仕様は明らかだろうから、机上で、同じデータを使い、同じ結果になる説明をさせれば良い。説明できなければ、根拠のない主張だから退け、新システムを採用するかを判断すればいい。

現新照合で一致ない→要件を出せ、ではなく、進めるための意思決定をプロジェクトオーナがせよ、である。

多分に、POは名ばかりで、全部下々に押し付けているような気がして現場が不憫に思えてしまうのだが。