事例で解説する、超高速開発に向く案件と向かない案件：本当はうさんくさくない、超高速開発のリアル（2/4 ページ）

[堀井大砂，ITmedia]

ケーススタディー2：　要件定義の重要度、比率を高くする

　超高速開発のプロセスは基本的にウォーターフォール開発をベースとしています。^※4

課題1：　要件定義の手戻りが発生しやすい

　超高速開発では、開発が容易という点を生かしてプロトタイピングを行い、利用者に画面を動かして見せながら要件を定義します。この「要件定義の見える化」で手戻りを防ぐことができるのです。

　以下に、私たちが支援した超高速開発案件の事例を紹介します。

・事例1：　リロ・フィナンシャル・ソリューションズ

　「モックアップで実際の画面イメージを確認しながら要件を定義できるため、実務を担当する現場の声を反映させながらシステムを作り込んでいくことができた」と好評でした。しかし、確認できるがゆえに“あれもこれも”と注文が増えてしまうことがあります。そのためSEには、利用者の要望の中から、「本当に今、必要な画面や機能」を見極め、それ以外は“必要になったら作る”という優先順位付けをする力量が求められます。

　超高速開発では、画面や機能を具体的に決めていくシステム要件定義の前の段階で、業務の要件定義に集中できるため、本来の目的である「業務効率化につながる機能」を着実に作り込んでいくことができます。このユーザー事例では「請求書業務にかかる時間が2日から1時間に短縮し、ミスも大幅に減らす」というシステム化の目的を達成できました。

・事例2：　三井不動産リアルティ

　早い段階から超高速開発ツールを導入した同社では、ツールの特性を見極め、それを生かした開発を自社で行っています。「モックアップを作って実際に動かしながら要件定義できる点を生かして、業務部門の要望をその場で反映しているので、開発したシステムに対する満足度も高く、導入後の改善要求もほとんど発生しない」と高い評価を得ています。

課題2：　開発工程で開発要員を急増させる必要がある

　ウォーターフォール開発の場合、要件定義から開発工程にかけて開発要員を大きく増やす必要があります。超高速開発の場合、実装・単体テストの工程を省略し、要件定義工程の比率を高めることで、工程間の比率を平準化します。また、実装技術が不要なため、要件定義から開発・テストまでを同じメンバーで担当することも可能です。

超高速開発事例の工程比率とスクラッチ開発の平均的な工程比率の推移

	事例A	事例B	スクラッチ開発の場合
要件定義	32％	22％	10％
開発	23％	22％	25％
	23％	22％	32％
テスト	22％	34％	28％

---

※4：　超高速開発ツールはアジャイル開発にも対応可能です