（1）プロローグ
失敗か成功か
今回紹介するプロジェクトは、納期、予算、顧客満足度までは十分に満たしたものの、開発者の満足度は低く、それ故開発者にとっては非常に負荷が高かった案件です。私は、近年のプロジェクトの短納期化には、金額以上に多くのリスクが潜んでいると感じています。もちろん、今日のビジネス環境が「急がざるを得ない」状況にあることは理解しています。提案の際に短納期は大きなポイントになることも理解しています。しかし、すでにいままでの連載で書いていますが、短納期を実現するには、単に実装作業を行う人、あるいはそのリーダーたちが“地獄プロジェクト”を覚悟すればよいというものではありません。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
実は、システム開発という作業はツールやフレームワークの充実、IT業界自体の錬度の上昇により、かなり効率化されており、「短納期でお願いします」という要件に対して、以前より大分応えやすくなっています。ただし、そこには大きな誤解があります。ツールが充実したことで、「顧客が欲しいものを作る」時間が速くなったわけではないということです。プロジェクト＝プログラミングではありません。
確かに、コーディングやテストはツールによって随分と効率化されました。では、要件定義は？ 設計はどれだけ効率化されましたか？ 「作る」部分（実装作業）だけに焦点を当てて「（開発作業が）速くなった」という説明をするのは非常に無理があります。多くの実装者は「もし、完全な設計が存在し、その設計によって実装作業が行われるのであれば、 どんな短納期でも、ほとんどリスクにはならない」と感じています。「非常に短納期になった」＝「その分、設計が揺らがなくなり、要件定義が速く行われるようになった」わけではないです。
この誤解は多くのプロジェクトをいわゆる「デスマーチ」に追い込んできました。では、「短納期＝デスマーチ」なのでしょうか。もちろん、そんなことはありません。実は、この案件もデスマーチ気味であったことは否めません。ただし、設計したとおりのアーキテクチャに沿って最後まで開発作業を進めることができ、結果的に納期内の稼働を迎えることができました。
近年、特にJ2EEは、安価なWebシステム構築での採用という局面から抜け出し、金融業の基幹システムなど、ミッションクリティカルなシステム構築で多用されるようになりました。基幹システムを構築する場合、汎用機との連携、巨大なバッチ、現行システムの運用との兼ね合い、そういったトータルなシステムとしての問題を検討する必要があります。これらの問題をJ2EEのシステム構築できちんと、実現できるかについては、いつも手探りの状態でした。しかし、現在さまざまな状況に対応したJ2EEでのシステム構築事例が増えたことで、J2EEの信頼度も向上し、基幹システムへの適用も当たり前の状況になってきました。
今回の案件はそんなJ2EEを用いた大手金融機関の基幹連携システムの構築事例です。ミッションクリティカルなJava案件プロジェクト運営の事例と「基幹システムなのに短納期」なJ2EEでのシステム構築の現場についてお話しします。チームの構成と実装者へのタスクの与え方がこの短納期を無事に済ませた鍵です。
Copyright © ITmedia, Inc. All Rights Reserved.