設計の落としどころ （前編）〜J2EE金融基幹システムの構築現場から〜：開発現場の天国と地獄（5）（1/4 ページ）

[佐藤大輔，オープントーン]

（1）プロローグ

失敗か成功か

　今回紹介するプロジェクトは、納期、予算、顧客満足度までは十分に満たしたものの、開発者の満足度は低く、それ故開発者にとっては非常に負荷が高かった案件です。私は、近年のプロジェクトの短納期化には、金額以上に多くのリスクが潜んでいると感じています。もちろん、今日のビジネス環境が「急がざるを得ない」状況にあることは理解しています。提案の際に短納期は大きなポイントになることも理解しています。しかし、すでにいままでの連載で書いていますが、短納期を実現するには、単に実装作業を行う人、あるいはそのリーダーたちが“地獄プロジェクト”を覚悟すればよいというものではありません。

［プロジェクト概要］
名称	プロジェクト5 「半年以下で金融基幹連携システムをJ2EEで構築」
案件	MQ汎用機連携、Web画面機能
言語など	ASP、VB、Oracle
プロジェクトの規模	6カ月以内、30名（サブシステム）全体では100名
結果	予算納期とも順守。現場への負荷、強め
予算	2億（全体は10数億）
経費	1億5000万
顧客満足度	○

［問題点］
作業者の管理	○
開発プロセス（UP）	○
開発能力	◎
分析設計	◎
チーム全体のコミュニケーション	○
コメント	短納期のJ2EE基幹プロジェクトの成功例。多数の汎用機の基幹システムとの連携を実装。短納期でのプロジェクト運営と設計実装の手本としてもよい。ただし、メンバーの負荷は高め、土日出勤、徹夜あり。ミッションクリティカルな場面でのMQ基幹連携や、短納期な大型プロジェクトにおける運営方法などの実績の場として最適。今後基幹（汎用機）システムのマイグレーション案件が多数出てくると予想される中で、先鞭的な案件。プロジェクトメンバーも良質、顧客もシステム理解・経験は豊か。
［凡例］ ◎＝良（問題なし） ○＝やや良（ほぼ問題なし） △＝やや難（やや問題あり） ×＝難（問題あり）

　実は、システム開発という作業はツールやフレームワークの充実、IT業界自体の錬度の上昇により、かなり効率化されており、「短納期でお願いします」という要件に対して、以前より大分応えやすくなっています。ただし、そこには大きな誤解があります。ツールが充実したことで、「顧客が欲しいものを作る」時間が速くなったわけではないということです。プロジェクト＝プログラミングではありません。

　確かに、コーディングやテストはツールによって随分と効率化されました。では、要件定義は？ 設計はどれだけ効率化されましたか？ 「作る」部分（実装作業）だけに焦点を当てて「（開発作業が）速くなった」という説明をするのは非常に無理があります。多くの実装者は「もし、完全な設計が存在し、その設計によって実装作業が行われるのであれば、 どんな短納期でも、ほとんどリスクにはならない」と感じています。「非常に短納期になった」＝「その分、設計が揺らがなくなり、要件定義が速く行われるようになった」わけではないです。

　この誤解は多くのプロジェクトをいわゆる「デスマーチ」に追い込んできました。では、「短納期＝デスマーチ」なのでしょうか。もちろん、そんなことはありません。実は、この案件もデスマーチ気味であったことは否めません。ただし、設計したとおりのアーキテクチャに沿って最後まで開発作業を進めることができ、結果的に納期内の稼働を迎えることができました。

　近年、特にJ2EEは、安価なWebシステム構築での採用という局面から抜け出し、金融業の基幹システムなど、ミッションクリティカルなシステム構築で多用されるようになりました。基幹システムを構築する場合、汎用機との連携、巨大なバッチ、現行システムの運用との兼ね合い、そういったトータルなシステムとしての問題を検討する必要があります。これらの問題をJ2EEのシステム構築できちんと、実現できるかについては、いつも手探りの状態でした。しかし、現在さまざまな状況に対応したJ2EEでのシステム構築事例が増えたことで、J2EEの信頼度も向上し、基幹システムへの適用も当たり前の状況になってきました。

　今回の案件はそんなJ2EEを用いた大手金融機関の基幹連携システムの構築事例です。ミッションクリティカルなJava案件プロジェクト運営の事例と「基幹システムなのに短納期」なJ2EEでのシステム構築の現場についてお話しします。チームの構成と実装者へのタスクの与え方がこの短納期を無事に済ませた鍵です。

図1 システム概要図