});第1回「“完璧な設計”がプロジェクトを失敗に導く!?」では金融系システム開発を事例に、最新技術導入によるメリットとデメリットを考察しました。プロジェクトの各段階で、開発者たちがシステム全体の姿を見失い、右往左往し、休みもなく、食事もままならない状況はまさに「地獄」といっても過言ではなかったのですが、1人1人のエンジニアの高いスキルが結局はプロジェクト全体を救った形となりました。今回の案件は、エンジニアの作業負担や労働時間の超過という観点からみれば、前回に負けず劣らず「地獄プロジェクト」の名に恥じないものです。1.0)フレームワークを導入した初めての事例でもあります。それゆえ、これからWebアプリケーション開発に取り掛かるチーム、あるいは、「いかに開発効率を向上させるか」に頭を悩ませるマネージャクラスのエンジニアにとってはとても参考になる事例だと思います。チーム全体のコミュニケーション◎[凡例]◎=良(問題なし)○=やや良(ほぼ問題なし)△=やや難(やや問題あり)×=難(問題あり)[コメント]チームのモチベーションは高い。スケジュールはハードだが効率は高かった。費用・期間があまりなかったにもかかわらず高度なシステムが作れた。以下、この開発プロジェクトを時系列で検証していきます。3カ月間は、要件定義、画面とER図を中心とした設計、開発後半のひな型となるシステムの開発が行われました。この時点ではまだ3名体制です。ひながた作成の主な作業は、フレームワークの基本的な動作や使い方の検証、プロトタイプの作成でした。この段階では、機能や画面を大量に実装するというよりは、リスクの高い機能のプロトタイプを作成したり、プライオリティの高い機能を先行して実装し、プロジェクト後半に効率よく開発を進めるための「ひな型」となるシステムを構築していました。開発効率を向上させた最大のポイントは、顧客が画面項目を1枚1枚真剣に考えてくれたことでした(もちろん、業務要件をまとて、おおよそのサイトマップを作成したのは設計者です)。業務に照らして1枚1枚検証し、「必要な画面/機能」と「不要な画面/機能」の切り分けを(顧客が)行ってくれたおかげで、プロジェクトのリスクは飛躍的に低くなりました。顧客の詳細設計への積極的な参加はプロジェクトのリスクを極端に低下させることを実感しました。顧客のこのような尽力のおかげで、設計担当者は、仕様をどのようにしたら実装できるか(あるいは、どうして実装できないのか)といった課題を検討することに集中できました。今回のプロジェクトでは、MVCの3つの領域に1名ずつ作業者を割り振っていました。実は、この時点では、MVCの各領域とチームのメンバーを明確に適合させようと思っていたわけではなく、各人が「得意分野から手を付けた」結果、たまたま作業領域が「M」「V」「C」に分かれていたのです。結果的にこのときの「適材適所」が、チーム全体をMVCへ適合する要因となりました。実装作業はチームを5名体制にして進めました。この際、MVCチームの構成を拡張したのですが、基本構造はそのままです。実装チームの構成は以下のようにしました。具体的には、M=データベース周り(Entity)、V=ブラウザ周り(JSP)、C=フレームワーク周り(Struts)に割り当てました。IT業界は多彩な才能の集まりです。DB設計やE-Rが得意で、DBパフォーマンスチューニングができたり、複雑なSQLをすらすらと書く人がいるかと思えば、フレームワークを丁寧に構築し、アーキテクトの中心になれる人、画面の体裁を丁寧に整え、複数のブラウザで丁寧にテストをする人や、複雑なJavaScriptを顧客の希望に沿って作成できる人などまさに多士済済です。Webシステムの構築はこのようなさまざまな才能が集まって行う複雑怪奇な作業の集積ともいえますが、それぞれのスタッフが得意な領域に作業を特化し、さらに互いの作業の影響を最小限に抑えられれば、複雑化が引き起こす作業効率の低下を抑えることができます。MVCアーキテクチャに沿って、実装レベルで「分業」化されている場合、その考え方は開発現場に非常に適合しやすいといえます。広告に関するお問い合わせメールマガジンSpecialインデックスRSSfacebooktwitter利用規約ITmediaはアイティメディア株式会社の登録商標です。