までは十分に満たしたものの、開発者の満足度は低く、それ故開発者にとっては非常に負荷が高かった案件です。私は、近年のプロジェクトの短納期化には、金額以上に多くのリスクが潜んでいると感じています。今日のビジネス環境が「急がざるを得ない」状況にあることは理解しています。提案の際に短納期は大きなポイントになることも理解しています。いままでの連載で書いていますが、短納期を実現するには、単に実装作業を行う人、あるいはそのリーダーたちが“地獄プロジェクト”を覚悟すればよいというものではありません。短納期のJ2EE基幹プロジェクトの成功例。多数の汎用機の基幹システムとの連携を実装。短納期でのプロジェクト運営と設計実装の手本としてもよい。メンバーの負荷は高め、土日出勤、徹夜あり。ミッションクリティカルな場面でのMQ基幹連携や、短納期な大型プロジェクトにおける運営方法などの実績の場として最適。今後基幹(汎用機)システムのマイグレーション案件が多数出てくると予想される中で、先鞭的な案件。プロジェクトメンバーも良質、顧客もシステム理解・経験は豊か。[凡例]◎=良(問題なし)○=やや良(ほぼ問題なし)△=やや難(やや問題あり)×=難(問題あり)実は、システム開発という作業はツールやフレームワークの充実、IT業界自体の錬度の上昇により、かなり効率化されており、「短納期でお願いします」という要件に対して、以前より大分応えやすくなっています。そこには大きな誤解があります。ツールが充実したことで、「顧客が欲しいものを作る」時間が速くなったわけではないということです。プロジェクト=プログラミングではありません。確かに、コーディングやテストはツールによって随分と効率化されました。「作る」部分(実装作業)だけに焦点を当てて「(開発作業が)速くなった」という説明をするのは非常に無理があります。どんな短納期でも、ほとんどリスクにはならない」と感じています。「非常に短納期になった」=「その分、設計が揺らがなくなり、要件定義が速く行われるようになった」わけではないです。この誤解は多くのプロジェクトをいわゆる「デスマーチ」に追い込んできました。「短納期=デスマーチ」なのでしょうか。そんなことはありません。実は、この案件もデスマーチ気味であったことは否めません。設計したとおりのアーキテクチャに沿って最後まで開発作業を進めることができ、結果的に納期内の稼働を迎えることができました。近年、特にJ2EEは、安価なWebシステム構築での採用という局面から抜け出し、金融業の基幹システムなど、ミッションクリティカルなシステム構築で多用されるようになりました。基幹システムを構築する場合、汎用機との連携、巨大なバッチ、現行システムの運用との兼ね合い、そういったトータルなシステムとしての問題を検討する必要があります。これらの問題をJ2EEのシステム構築できちんと、実現できるかについては、いつも手探りの状態でした。現在さまざまな状況に対応したJ2EEでのシステム構築事例が増えたことで、J2EEの信頼度も向上し、基幹システムへの適用も当たり前の状況になってきました。今回の案件はそんなJ2EEを用いた大手金融機関の基幹連携システムの構築事例です。ミッションクリティカルなJava案件プロジェクト運営の事例と「基幹システムなのに短納期」なJ2EEでのシステム構築の現場についてお話しします。チームの構成と実装者へのタスクの与え方がこの短納期を無事に済ませた鍵です。広告に関するお問い合わせメールマガジンSpecialインデックスRSSfacebooktwitter利用規約ITmediaはアイティメディア株式会社の登録商標です。