みんな辞めたいけどもう止まれない！基幹刷新プロジェクトの裏側[1]

トップダウンで始まった基幹刷新プロジェクト

東証1部上場の大手で始まった基幹刷新プロジェクトに僕はアサインされた。鶴の一声で始まった案件だったため、現場からの反発がものすごく、「仲良くするには」的な議題が上がることもあったくらい現場はギスギスしていた。

20年近くメインフレームのシステムを利用し、情報システム部は脆弱でITゼネコンがあまい汁を吸うという典型的な日本のITの構造になっていた。さらに、数年前そんな状況から脱出しようと一度基幹刷新を試みるも失敗してきたという経緯があった。その古傷をえぐり全否定するのだから反発は当然といえば当然なのだが・・・。

他ベンダーの３分の１の金額で受注

実績が欲しかったのと、カットオーバー後は継続開発もありドル箱案件になるため、他者の３分の１程度の金額で受注した。これが後々大きなしこりになった。今だから思うが決して赤字でプロジェクトを受けてはいけないし、そもそも値引は良くない。適正な価格で提供しなければ発注サイドも疑心暗鬼になってしまうと思う。

激甘な見積もりと序盤の進捗管理

そもそも緻密に見積もれないくらいに誰も知らない業務とか埋まっていたりする。プログラムの仕様が間違ってたり、想像だにしない問題が大量に発生するのが基幹刷新なので、工数管理はかなり難しい。

とはいえ、序盤から進捗が悪化した時のリカバリー方針がリスケリスケで問題先送りスタンスだったため、週次MTGの度に負債が積み上がっていくプロジェクトだった。そもそも積み上げられる問題は放置できることが多いのでわざと放置してカットオーバー判定対象から除くことを最初から決めていたのかもしれない。

やったことがないから肌感覚がない刷新メンバー

テスト工数が圧倒的に短すぎるスケジュールになっていて、エンジニアだったら肌感覚でわかることがPMとかコンサルあがりにはまるでわからないことが多々ありました。開発にかかる時間軸でのコストは開発１：テスト２くらいが妥当なところで、開発の中もざっくり動くレベルが０．２で細かい仕様を実装するのが０．８でパレートの法則に近い。（個人的な見解です）

とにかく「テストには開発の倍くらいコストがかかる」というのを覚えておいてもらいたい。バグが発生すれば調査して単体テスト書いて修正してコミットとか作業が多い。テストが楽なコードでなければ調査も大変だし、修正によるデグレが発生するリスクもある。

だから開発５００人月のプロジェクトで５０人月くらいの内部結合テストは明らかにスケジュールがおかしい！

そんなこんなで基幹刷新プロジェクトがキックオフ

ギッスギスしたまま始まったプロジェクト、PM以下はだれも喜んで進めたくないような雰囲気を漂わせながら。

学んだこと

ビジョンの共有と目標設定、それをベースにした意思決定の基準について初めに握るか共通の認識を持ち、それを常に意識することが大事だと実感した。いつ終わるか分からないマラソンにはだれも参加しない。

＞＞つづき（怒涛のプロトタイプ開発とスタート失敗）