はじめに
ITには「デスマーチ」という言葉があります。
システム開発プロジェクトで過酷な状況が続くことを言います。
一般にネガティブな意味で使用されますが、私のチームが体験した、関係者全員が報われた話をしようと思います。
ある日の一本の電話
ある日のこと、私のもとにクライアントから一本の電話が入った。
クライアントのA社は某金融グループのIT戦略を担う企業である。
関係会社3社の統合により従業員数は4,000名を超える規模になる。
業務プロセスの統合を全社を挙げて進めており、そのうち全く手付かずの基幹業務プロセスの統合を手伝って欲しいとのことだった。
経営陣から示されたシステム統合の期日まであと5ヶ月。
一番難易度の高い業務プロセスが手付かずで残されていた。
示された条件は、他社参考見積額の半分のコスト。
引き受ける側からすれば非情なまでの低コスト。
常識的に不可能な納期であった。
尋ねると声をかけたITベンダーからは期待できる返事がなかったという。
リスクヘッジよりもリスクテイク
クライアントも四面楚歌に追い込まれていた。
仕事を請ける側も苦労することが最初から分かっている案件であった。
どう転んでも難しい方向にしか行かないだろう。それが明らかなだけお互い気詰まりであった。
引き受けるべきか気持ちが揺らぐが、そのうち「リスクテイクしないと前には進まない、やるだけやってみよう」という気持ちに変わっていた。
クライアントも同じ気持ちだった。
「結果はどうなるにせよ、とにかくあなたのところと組んでやってみよう」
と判断を示してくれたことで、取組みが始まった。
決意を凝縮したプロジェジェクト憲法
仕様2ヶ月、開発2ヶ月、テスト1ヶ月で全てをやり遂げるという異例のスケジュール。
もはや人海戦術が効く領域ではない。お互いに深い危機感を持っていたので、絶対にあと戻りしないやり方を求めて、プロジェクトにおける憲法のようなものをつくって文章化した。
(1)プロジェクトに携わるメンバー全員が危機感を持つこと
(2)「自分の範囲ではない」とか「他の件で手が一杯」といった考え方を各自一切捨てること
(3)お互いに合同ミーティングと社内ミーティングを兼ねないこと
この要綱は考えに考え抜いて固められた、我々のプロジェクトリーダーの思考のエッセンスだった。決断があと戻りしないということが一番大切だった。
「もうあと戻りしないぞ」という気迫で提示した要綱は、クライアントのいくら古参の役員といえども、おろそかにはできない。このような気迫を、プロジェクトチーム（クライアントと私たち）及びクライアントの役員と共有することから、仕事が始まった。
難局につぐ難局
この日を境にプロジェクトが軌道に乗った。
新システムの仕様は、3社のうち一番統制の厳しいX社の業務フローが基本となる。つまりX社の業務に極力合わせるということだ。加えてリアルタイムでデータを可視化することで経営判断への貢献を果たしたい、それが今回のシステム開発のミッションとなる。
X社の業務に一番精通しているメンバーを要請し、仕様についての責任はA社のプロジェクトリーダとする、といった態勢を作った。
それでも仕様はたびたび転び、早くも遅れが生じる。仕様が決まったところから随時開発に手を付けるも、いつ納期遅れを宣言してもおかしくは無い。
A社のスポンサー、プロジェクトリーダー、開発リーダの三つ巴の緊張した日々が続く。
それでも誰もあきらめなかった。
仕様がほぼ確定したのは計画よりも1ヶ月半遅れ。
開発チームに一気にしわ寄せが来る。しかし彼らもまた兵であった。
開発チームが織り成す共有連絡のメールリングリストは明け方に収束し、朝の9時頃から再び動き出す。最後の2ヶ月は朝も夜もないことを物語っていた。
開発が佳境に入って1ヶ月半目「間に合わないかも知れない」から「計画どおりにいけるかも知れない」状況に転じた。遅れをリカバリできたのだ。
しかし次の難関があった。本番テストで某社DBMSのロック挙動に悩まされる。原因はDBMSのバグであることが分かった。
バグの解決を待たずアプリケーション側で対応することで解決を図った。
開発が多少前倒しで進んでいたことがここで幸いした。素晴らしい追い込みだった。
システムリリースその後
経営陣から示されたカットオーバー期日ぴったりにシステムが稼働した。
データベースのバグにも悩まされたがそれを理由に納期をずらすことはしなかった。
画面数250個、プログラム本数は実に600本。
開発ボリュームの大きさを物語る。この仕事はクライアント内でも語り草となった。
そしてその後も重要な基幹業務として、度々のシステム更新を重ねつつ定着している。
文 オーシャン・アンド・パートナーズ http://www.ocean-ap.co.jp/ 谷尾 薫
