今、私はとある業務システムのリプレース案件に関わっていて、主にそのシステムの技術的な枠組み（フレームワーク）部分の設計、製造を担当している。何のシステムかという話はまだ機密情報やインサイダー情報になるので詳しくは言えないのだけど、とにかく、そのプロジェクトの切り回し方があり得ないので、それをここに書きとどめておくものである。

私は18年ほど、システム開発というものを生業としてやってきた。が、今回ほど酷いプロジェクトは経験がない。何が酷いかというと、その全てを書いていくとキリがないくらい多いので、主な問題をここにあげるとするなら、

1.PM（プロジェクトマネージャ）、PL（プロジェクトリーダー）が不在
2.リプレースの元となるシステムが腐っている
3.一部開発をオフショアに出すのだけど、何を出すのかが明確でない
4.重要物件の変更の周知がされない上、変更履歴も管理されていない
5.本来シリアルで進めるべき開発がパラレルで進められている

まず1。一応、名目上のPM、PLはいるのです。いるのだけど、全然旗振りができてない。スケジュール管理はPMOまかせ、問題が起こっても起こりっぱなしで解決を図ろうとしていない、お客さんの要求を全部のんでくる、現場から無理だといってもお客さん最強の法則で聞いてもらえない。まずもって当事者意識がない。開発は開発チームの仕事であって、自分は知らんよ、できたっていう報告だけ聞くよっていうスタンス。開発チームも国内、オフショア、データ構築、データ移行などいくつかあるのだけど、その各チームのリーダーも、統括がそうだから横の連携が全くできていない。なので、国内開発とオフショア開発の担当が衝突するなんてことが頻繁に発生する。

次に2。リプレースというのは、古いシステムを新しいシステムに置き換えるというものなのだけど、その古いシステムが、ドキュメントからソースコードからとにかく理解を超えた管理になってる。まず、現行システムの基本設計書は一応存在する。存在するのだけど、古過ぎて現状を反映できていない。つまり、作りっぱなしでメンテが全くされていない。そのプログラム構成やデータ構成などが書かれているはずの詳細設計書に至っては存在しない。現状そのシステムやプログラムの中身がどのようなものなのかは、現行運用の担当者が知っていれば知っている、という程度。その担当者もリリースや小さな変更を行うのに必要な知識しか持っておらず、中身がどうなっているのかはほぼブラックボックスという状態。それをこれから直せというのである。しかも短期間で。

中身を見ると、これまた酷い。よくこれで動いてるなというほどプログラムのミスが多く、中にはバグっているために結果的に上手く動作しているなんてところもあった。それも1か所や2か所ではない。例えば、DBから一覧を取ってその件数を判断しているコードがあるのだけど、SQLはリストを返しているのに、コード側はそれを数値にキャストしてる。それでなぜエラーにならないのかは不思議だけど（DAOの型ハンドラが無理やり解釈してるのだと思われる）、結果は必ず1件扱いになり、判定としては常にTrueとなり、そのまま後続処理が動作して結果オーライになっているのである。これ、正しい動作に修正したらどうなるのだろう？そんな心配をしながら修正をかけていくという何とも理不尽な状態なのである。

3。この開発は主に国内とオフショア（海外）の2手で開発を進めているのだけど、その担当振り分けがどうも曖昧。とにかく単純作業、人海戦術でできる修正はオフに回す、という方針だけあって、具体的な機能やモジュール、サブシステムなどの単位で切り分けられていない。なので、国内で修正しているソースコードがオフ側の修正で上書きされたり、その逆もあったりといったことが頻繁に発生し、そのマージ作業に余計な工数がかかるという状況。今はこれがSVN上で起こっていて、コミット時のコンフリクトという形で発覚するのでまだ良いのだけど、少し前はSVNを使わず、お互い全く並行開発して最後にマージしようなどといわれていたのだから恐ろしい。ここは絶対問題になるからと、私を含む技術チームが猛反対してSVN管理に落ち着かせたという経緯もある。それでも、担当が明確じゃない中ではこうした問題は発生する。もう今は半分あきらめモードで、これはこういうものだという認識で日々マージしている状況である。

4。これは仕様やそれを記載したドキュメント、あるいは影響範囲の広いモジュールのソースコードの変更など、各個、各チームで勝手に修正され、その周知がされない。PM、PLが機能してない状況でこれもむべなるかなという感じなのだけど、周知が面倒なら（いや、本当は周知すべきなんだけどね）せめて変更履歴は残して欲しい。いつ、どこが、どう変わったかという情報が全く残っていないのだ。いつの間にかそう決まって、仕様やドキュメントが変わっている。いや、変わっているならまだマシか。その変更を知っているのは担当者、担当チームだけという状況も日常的だったりするから非常に困る。

この影響が著しいのがデータベース。そのテーブル構造や物理名、論理名、キー、制約などが変わったら、それは当然コードにも跳ねる。カラム名なんて変わった日にゃ、DAOからサービスから下手したらコントローラやビューまで影響するのに、その変更が周知されない、どう変わったかのドキュメントもない、いつ変わったかの履歴もないのである。そもそも、テーブル構成なんて、ソースコードの製造が始まる段階ではFIXしていなければならないものである。それが、製造真っ只中、もうすぐ結合テストも始まるという時期に、まだフラフラと変わってたりすることも異常なのだ。その上、変更履歴もないなど、開発担当者はふつうにキレるだろう。せめて設計書やDDLをSVNなどで管理してくれていれば良いのだけど、最新（かどうかあやしいものだけど）がファイルサーバに置いてあるだけという。

5。この最たるものが前述のDBとソースの同時開発である。というか、基本仕様すらいまだに変わる。そのためなのか、DBのテーブルにカラムが増えたり減ったり、カラム名や制約が変わったりしている。本来そんな状況でプログラムなんてできない。カラム名なんて変わったら、DAOが修正され、そのアクセッサーの名前が変わり、それを使ってるコードは昨日通したはずのユニットテストが、今日はNGになったりするのである。というかコンパイルエラーである。ないでしょ。これが日常とか泣くでしょ。

な…　何を言っているのかわからねーと思うが、おれも　何をされたのかわからなかった…

まさにそんな状況。リアルにジャンの気持ちを味わってる感じである。