失敗プロジェクトは、要件定義フェーズに問題があることが多い。解決には「反復」や「優先度付けしたプロダクトバックログ」のプラクティスが有効。アジャイル開発の手法を取り入れ、効果的に要件定義をする方法を紹介する。

今回のポイント
  • 企業情報システムは複雑化が進んでおり、当初から全ての要件を完璧に定義することは難しい。
  • 要件を固めにくいケースでは、アジャイル開発の「反復」の考え方を応用する方法が有力である。
  • 「 優先度付けしたプロダクトバックログ」というプラクティスを要件定義フェーズで行えば、後のフェーズでスコープ調整に利用できる。

 本連載は、ウォーターフォール型の開発プロセスに、アジャイル開発のプラクティスを部分的に組み込む「ハイブリッドアジャイル」を提案している。従来型のプロジェクトに潜む様々なムダを排除するのに適した手法だ。

 前回は、開発プロセスの改善には、アジャイル開発のプラクティスが有効なことを説明した。今回は、要件定義フェーズに必要なハイブリッドアジャイルの勘所を、ユーザーの立場から解説する。

要件定義がプロジェクトの成否を分ける

 失敗プロジェクトの多くは、要件定義フェーズに原因がある。要件定義とは、ユーザーの業務目的を達成するのに必要な機能要件と、システムの性能や信頼性などの非機能要件を明確にすることだ。プロジェクト成功を左右する重要なフェーズである。

 要件定義フェーズで発生する主な問題は、(1)要件の漏れ・間違い、(2)設計できるレベルで要件を伝えられない、(3)要件がよく分からない、の3つが挙げられる(図1)。

図1 ユーザー企業側から見て要件定義で起こりがちな問題
[画像のクリックで拡大表示]

 (1)の要件の漏れ・間違いは、文字通り必要な機能を要件に盛り込み忘れていたり、間違えていたりするケースだ。手戻りによる時間のムダが発生する。

 (2)設計できるレベルで要件を伝えられないという問題は、ユーザーが要件定義の作業に必要な手法を知らない、もしくはスキルが不足しているときに発生する。そのままでは設計できないため、システムエンジニアは要件を再確認せざるを得ない。再確認の時間はムダである。

 (3)の要件がよく分からないは、ユーザーが要件定義のスキルを身に付けていても、まとめきれないケースだ。特に、新ビジネス向けのシステムを企画する場合や、ブラックボックス化した既存システムを刷新する場合に散見される。要件がまとまらないので後工程に進みにくく、作業が停滞してしまう。3つのうち最も厄介な問題だが最近増えている。

どちらも一長一短

 これら3つの問題を解決するアプローチは、大きく2通り考えられる。1つは、事前にできる限り要件の精度を上げておくこと。もう1つは、開発しながら要件を確定していくことだ。前者はウォーターフォール型、後者はアジャイル開発のアプローチである。

 前者のアプローチを取れれば理想的だろう。完璧な要件定義を作成できれば、ウォーターフォール型の開発プロセスに従って、開発を進めていけばよい。完璧な要件定義なので、手戻りや再確認の時間は省ける。

 しかし、要件を“完璧”に定義するのは、ほぼ不可能に近い。最近の企業システムは、複雑化の一途をたどっているからだ。

 例えば、マルチデバイスなどの様々な利用形態を考慮しなければならない。ほかにも、セキュリティ対策やユーザビリティーの向上、複雑化した業務への対応、他システムとの連携、なども考えなければならないだろう。これらを全て網羅し、要件定義に落とし込むのは非常に難しい。いくら要件定義のスキルを磨いても、要件漏れや変更は避けられないし、要件はまとめきれない、と考えた方が無難だ。

 また、完璧を求めれば求めるほど、要件定義に作業時間を費やしてしまう。時間がかかれば当然コストも膨れ上がる。つまり、ウォーターフォール型のアプローチでは、いくら要件定義の精度を向上させようとも問題の解決は難しいというわけだ。

 一方、開発しながら要件を確定していくアジャイル開発のアプローチはどうだろうか。アジャイル開発では一般に、要件定義、設計、製造、テストを短いサイクルで繰り返してシステムを作り上げていく。こうした繰り返しをアジャイル開発では「反復(短いイテレーション)」のプラクティスと呼ぶ。1回の反復期間は手法によって異なるものの、おおむね1~4週間程度である。

 アジャイル開発であれば、プロジェクトの最初から要件定義が完璧である必要はない。少しずつ形にしながら、要件を加えていくからだ。開発中に要件を確定したり変更を受け入れたりしやすいという利点がある。また、問題を短いサイクルで解決しながら進めるので、手戻りのリスクを低減しやすいというメリットも得られる。

 ただし、ウォーターフォール型の開発に慣れたユーザーからすると、アジャイル開発のプロセスには受け入れにくい欠点がある。それが、ユーザー側の拘束時間が長くなりやすい、という点だ。

 要件定義、設計、製造、テストを短いサイクルで繰り返すには、要件を確定するユーザーと設計・実装を担当するシステムエンジニアが、歩調を合わせて開発を進めなければならない。歩調が合わなければ開発が途中で止まり、待ち時間が発生してしまう。このようなムダを減らすためには、ユーザー側の担当者が開発プロジェクトに常駐するのが理想的だ。

 しかし、要件を確定するユーザーの多くは、自部門の通常業務を抱えている。プロジェクトの最初から最後まで開発現場に常駐するのは難しいと言わざるを得ない。

 さらに、コストや法律の壁もある。アジャイル開発のアプローチは、開発しながら要件を確定していくので、予想以上に要件が増えてしまい予算を大幅に超過してしまう、といったリスクも考慮しておかなければならない。

 また、委託開発では特有の問題が発生する。指揮命令系統などに関する法律に抵触しないように作業しなければならない。つまり、委託開発のケースでは、アジャイル開発の手法をそのまま適用するのは難しいといえる。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら