シンプルにいこう

ステークホルダーは必要以上に事態を複雑にするものです。これはソフトウェアプロジェクトでよく見られる失敗の原因のひとつです。チームメンバーはプロジェクトの目的と実際の作業全体を可視化する必要があります。ところがステークホルダーは自分の頭の中で、魔法のようなステップによってプロジェクトを完成させてしまいます。彼らはそれがどんなに複雑であろうとも、最終的な解決策にいとも簡単に到達できると思っているのです。

ステークホルダーはソフトウェアプロジェクトを画一的で巨大な怪物のようにしてはいけません。そうではなく、コツを心得た多層的なチーム構成として、各層が互いに成熟度を高められるようにすべきです。本当のところ、これ以外に方法はありません。たとえ要件が完全だったとしても、必ず変更は発生します。もしソフトウェアに柔軟性がなく、要件の変更にすばやく適応できないのなら、始まる前からプロジェクトはすでに死んでいます。シンプルにしておくために、次の2つのことを心に留めておきましょう。

• 要件をシンプルにしておくこと。ビジネスアナリストは頭に浮かんだ具体的な解決策と、ビジネス要求に基づく実際の顧客要求とを混同してしまいがちです。たとえ実際の要件が極めてシンプルなものであっても、ビジネスアナリストとプログラマ/開発者とのあいだにはコミュニケーション・ギャップが生じます。お互いに相手が何をしているのか、本当のところ理解していないのです。ビジネスアナリストはシンプルなツリー構造をイメージして要件を書くべきです。ルートにある要件がプロジェクト全体のシンプルな目的になります。親レベルの要件は子レベルの要件へと分岐することができます。それぞれの要件が明瞭になるまで、このプロセスを繰り返します。このアプローチを使って要件を文書化するときには、マインドマップ用のソフトウェアを使うと便利です。要件の一部が明瞭になれば、そこから開発を始めても構いません。
• アジャイル開発プロセスにしたがうこと。要件の一部が特定できれば、開発チームはすぐにプロトタイピングを開始できます。プロトタイプが動くようになると、ステークホルダーはそれをテストして、フィードバックすることができます。顧客のフィードバックは要件が正確であることを確実にしてくれます。また、実際の顧客からビジネスアナリストを経由してプロジェクトチームへと伝えられるうちに、どんなギャップが要件に生じたのかを特定するのにも役立ちます。顧客にプロトタイプを見せることで、開発者がイメージした解決策が、実際に顧客が思い描いていたものと合っているかをチェックすることもできます。もしギャップがあれば、それを新たな要件として、開発者はプロトタイプをやり直します。このサイクルを繰り返すのです。各サイクルはできるだけ短期間にすべきです。2～3週間を超えてはいけません。要件の一部を定義し、記述された要件を満たすプロトタイプを作り、そのフィードバックを得るというサイクルによって、プロジェクトのステークホルダー全員が常に同じ考えを持てるようになります。このようなシンプルなテクニックにきちんとしたがうことによって、すべてのソフトウェアプロジェクトは最終的に成功するはずです。プロジェクトの成功が、顧客の幸せと有用なビジネス機能を提供する動くソフトウェアを提供することだと定義されていれば、なおさらです。