前回のコラムでは、ホロニックなソフトウェア開発、つまりプロセスよりもイノベーションに重きを置く開発方法について議論を始めました。前回の声明書で述べたように、ホロニックなソフトウェア開発は開発者が並外れた成果を達成できる可能性を秘めていると私は確信しています。だからといって、私はプロセスを全面的に撤廃するよう提唱しているわけではありません。プロセスに関する私の信条は、次のようにまとめることができます。

プロセスの数が少なすぎると、通常の作業を行うのにも、大勢の人が必要になります。
プロセスの数が多すぎると、大勢の人がいても、それに見合った成果を上げることはできません。

今回の記事は、ホロニックなソフトウェア開発とプロセスの適用についての議論を中心に進めていきます。特に、次の2点について焦点を当てます。1つは、ソフトウェア開発サイクルの基盤となる要件収集、もう1つは、ホロニックなアプローチ (これは開発サイクル全体を通じて、多くのプロセスと方法をダイナミックに実践させます) が、いかに皆さんの要件収集の手続きを強化できるかについてです。

ソフトウェアの不可視性という問題

新たなソフトウェア・アプリケーションを概念化するにあたっての難しさは、プロジェクトによってさまざまです。あるプロジェクトの要件は単純明快で、おそらく新規テクノロジーを周知のドメインに適用する場合と同程度に簡単かもしれませんが、他のプロジェクトの要件はより困難なものであるかもしれません。我々は未知の分野にソフトウェア・テクノロジーを引き続き適用していくので、ソフトウェア・システムの要件を整備するという行為は、概念にまつわるイノベーションを行うこととなります。このイノベーションは、個人にとって難しい知的な訓練であるばかりでなく、大規模な開発グループに対して伝えることが困難なものでもあります。

Frederick Brooksは、概念化し規定することを困難にする新規ソフトウェア・アプリケーションの特性をソフトウェアの不可視性と名付けました。ハードウェアのような他のドメインには形のあるものが存在しますが、ソフトウェアにはそうしたものがありません。ソフトウェア・アプリケーションの処理結果は、目に見える、あるいは測定できるものかもしれませんが、システムを表現するということは本質的に観念的なものです。我々がソフトウェアのモデルを作成してそれを拠り所とする理由はいろいろありますが、これはその理由の1つです。モデルは、ソフトウェアにはっきりと理解できる概念を与え、そのソフトウェアの方向付けについて、より深く理解して伝えられるようにしてくれます。

ソフトウェア・モデリング作業の中心には、要件収集があります。実施すべき要件収集プロセスの選択は、開発プロジェクトのより大局的なコンテキストによって変わってきます。このコンテキストなるものは、要件収集プロセス自体、あるいは別の補完的モデル中に見出されることがあります。場合によっては、コンテキストが予定成果物のなかに見出されることさえあります。要件が潜んでいると思われる様々な箇所を調べることで、システム要件のコンテキストとなっている箇所を探り当てることが、いつでも可能です。要件のコンテキストとは、我々がソフトウェアの不可視性に取り組むことになる分野です。

上に戻る

ジョブに最適なプロセスを選ぶ

実施すべき要件収集プロセスの選択は、皆さんのソフトウェア開発プロジェクトの成功に大きな影響を与える可能性もあります。要件収集は、開発サイクルの基礎となるものですから、効果の上がらない、あるいは選択を誤った要件収集プロセスは、皆さんのプロジェクトが失敗に終わる確率を大幅に高めることになります。これは、一般に定評ある1つの開発方法に関連づけられた周知のプロセスにかたくなに固執するという状態を招くおそれもあります。

ここで我々が探ろうとしている（複数の）要件収集プロセスは、Rational Unified Process (RUP)、Feature-Driven Development (FDD)、Extreme Programming (XP) という3つの主要ソフトウェア開発方法から導かれます。それぞれの方法は、優れたツールを豊富にそろえ、要件収集作業を支えます。ホロニックな開発方法に沿う形で、各方法そのものの全体像に焦点を当てるのではなく、各方法の要件収集プロセスという今回の議論で必要とされる部分に焦点を絞っていきます。そこから、さらに動的で変えやすい要件収集手順を組み合わせることができるかどうか検討していきます。話を先に進める前に、ここで少し時間をとり、サイドバーの「Ten best practices for holonic software development」を読んで、すでに我々が理論上知っている事項の多くをホロニックなアプローチがどのように取り扱っているかお確かめください。

4つの最も一般的な要件収集プロセスとは、従来のソフトウェア要件仕様 (SRS)、ユース・ケース、フィーチャー、ユーザー・ストーリーです。以下のセクションでは、要件のコンテキストに特に注意を払いながら、各プロセスを検討していきます。すなわち、どのような環境で各方法が最大の効果を発揮するのか、そして、各方法が開発プロジェクトにもたらす独自のダイナミックスについて、特に注意を払っていきます。以下に概説する各プロセスの適用の詳細については、参考文献をご覧ください。

上に戻る

ソフトウェア要件仕様

ソフトウェア要件仕様 (SRS) は、要件収集プロセスの中で最も古くからあるものの1つです。俗に「shall statement」として知られていますが、これまでSRSは多くの形態で存在し、今日なお多くのフィールドで外注契約の作業に必要とされています。SRSは、長年にわたって最も有力な要件収集方法でした。

SRSの背後にある考えは、ソリューション・スペースを作り出すことにあります。つまり、開発チームが目標を設定した空間ですが、こうした目標を達成する際の活動の順序と本質にかなりの範囲の自由裁量を伴うものです。その結果、SRSは通常、単一のソリューションを規定しようとするものではなく、可能なソリューションの一群の定義を目指すものになります。したがって、開発チームは、作成されるシステムが目的とする問題の効率的な解決方法を創造するのに十分な柔軟性を備えることになります。

柔軟性は、SRSの強みでありながら、また同時に弱点でもあります。ソフトウェア開発チームがシステムを作成しているドメインに堪能であれば、SRSを使用してそのドメインで最大限のイノベーションを発揮することも容易です。しかし、開発チームが不慣れなドメインで決められた手順で作業をするような時期には、従来のSRSは要件収集プロセスとしては力不足となる可能性もあります。チームは、ある所定のドメインにおいて標準的な条件を扱う通常のユーザーがとるようなステップを理解できないかもしれません。その結果、チームはそのユーザーのコミュニティーにとって最適とはいえないシステムを仕様化して構築してしまうことになるかもしれません。

従来のSRSは、十分に理解されたドメイン、そして取り組むドメインに精通しているチームにとって、あるいは外部の該当ドメインの専門家に容易にアクセスできる開発環境にとって最適なものです。SRSは、システム中の変更に対処するようにソリューション・スペースを調整するような技法についてはほとんど考慮されていません。

上に戻る

ユース・ケース

従来のSRSに採用されてきたソリューション・スペース・アプローチとは対照的に、ユース・ケースはユーザーがシステムと対話を行う際に実行する一連のアクションを記述するものです。ある意味で、ユース・ケースはパス（経路）または目標をベースにするものといえます。これは、ユーザーがシステムを使用して問題の解決にあたる際に開始すべきアクションの順序を伝達します。たとえば、ビデオ・レンタルのユース・ケースでは、ユーザーがビデオ・レンタル・システムと対話する場合にどのようなことが行われるのか説明しています。

ユース・ケースは、ソフトウェア・システムを使用して目標の達成を目指す場合に発生し得るすべてのイベントを反映します。ソフトウェア・システムの多くは多数の目標をサポートするので、ほとんどのユース・ケース・モデルは多くのユース・ケースから構成されています。たとえば、Pay Late Feeユース・ケースは、ビデオ・レンタル・システムのユーザーが延滞料に該当する場合どのような処理が行われるか示しています。

ユース・ケースにおける適切な情報のレベルとは、アプリケーションの構築を成功させるために必要とされるレベルです。これは状況によって異なります。ドメイン専門家が開発プロセスに属している場合には、ユース・ケースはシステム全体を通じてパスの概略を描くだけにとどまるかもしれません。ドメイン専門家がプロジェクトの一員ではない場合には、ユース・ケースはさらに多くの情報を提供するために必要とされます。ユース・ケースは、要件を伝達するための最高のプロセスです。ただし、従来のSRSと同様に、ユース・ケースは十分に理解されたドメインにより一層適しています。ユース・ケースは、一定の変化に何とか対処することが可能ですが、他のプロセスのほうが変化の影響を吸収するのにより適しています。

上に戻る

フィーチャー

フィーチャーは、システムの望ましい機能を簡潔に説明するものです。フィーチャーには次のような形式があります。

<action> the <result> <by|for|of|to> a(n) <object>

フィーチャーの例には次のようなものがあります。

Forecast the total of quarterly sales.

フィーチャー・ベースのアプローチは、各フィーチャーの規模を小さく抑えてある場合に機能を発揮します。理想的なフィーチャーは、チームが2週間以内に実装できるようなものです。

フィーチャーは、フィーチャー・セットと呼ばれるグループに編成されます。フィーチャー・セットには、所定の目標または分野について説明するフィーチャーが含まれています。フィーチャー・セットとそのフィーチャーは、単に要件の概要をまとめたものに過ぎません。要件を記述するためのメカニズムとして、フィーチャーは補足的なコンテキストと組み合わせる必要があります。

Feature-Driven Development方式においては、コンテキストはフィーチャー・セットとドメイン中立コンポーネントと呼ばれる色分けされたクラス・ダイアグラムの2つを用いて詳述されます。ドメイン中立コンポーネントは、複数のドメインを超えて共通にみられる関連を示すセマンティック・テンプレートです。ドメイン中立コンポーネントは、モーメント・インターバル、役割、サブジェクト (関係者、場所、あるいは事物)、説明から構成されます。モーメント・インターバルとは、注文調達システム (Order Fulfillment System) におけるオーダーのような、ドメインの一時的な要素です。役割とは、システムと対話を行い、システムに認識される必要のあるユーザーです。サブジェクトとは、ドメインを形成する要素のことです。説明とは、こうしたオブジェクトに関するメタ情報を収集する抽象概念です。図1は、ビデオ・レンタルのシナリオのドメイン中立コンポーネントを示しています。

要件収集プロセスとして、Feature-Driven Developmentは非常に柔軟性に富み、開発サイクル全体にわたる変更管理の用途に適しています。このプロセスにより、プロジェクトの進行に応じて多くの新規、変更、そして削除されたフィーチャーを容易に検討して追跡することができます。フィーチャーは一般に小型であるため、既存のフィーチャーへの変更や新規フィーチャーの追加によりプロジェクト・レベルで大幅な手直しが必要になることはほとんどありません。さらにフィーチャーは、ソフトウェアの不可視性に取り組む際にも役立ちます。これは、ドメイン中立コンポーネントのシステム・エンティティー間の対話を追跡した結果、新規フィーチャーが明らかになることがあるからです。

フィーチャーは、所定のドメインに精通している個人の間で要件を伝達するために使用することができます。このような方法で使用されると、フィーチャー・ベースのアプローチはおそらく最も無駄のない要件収集プロセスとなります。ただし、フィーチャーはドメイン専門性に負うところがあまりに大きすぎる可能性があり、ふつうの開発チームはそのような専門性を持てないかもしれません。

上に戻る

ユーザー・ストーリー

ユーザー・ストーリーは、図2に示すようにインデックス・カードに記述された小型の説明です。

ユーザー・ストーリーは、フィーチャーよりも多くの情報を含む傾向がありますが、それは要件ではありません。Extreme Programming方式のもとでは、ユーザー・ストーリーには部分的なコンテキストを説明してくれるオンサイト（現場参加の）のカスタマーが必要です。オンサイト・カスタマーは、理想的なシステムについて開発チームに説明します。次いでチームは、少しずつ段階的にシステムを構築し、カスタマーが定期的に成果を確認できる十分な機会を与えるようにします。カスタマーは、成果物を「その目で確かめ」、新たなユーザー・ストーリーを通じてシステムに変更を提案することもあります。完全なコンテキストは、オンサイト・カスタマーからのフィードバックと漸進的進捗状況と成果物の組み合わせにより達成されます。

ユーザー・ストーリーは、ソフトウェア不可視性のリスクが高いプロジェクトに取り組む場合に最適といえます。フィーチャーと同様に、十分に小型で容易に変更することができます。それらのコンテキストは実際に機能するシステムとカスタマーを基にしているので、ユーザー・ストーリーは、いったん実装されるか、あるいは有効ではなくなると廃棄されます。ただし、すべてのプロジェクトにオンサイト・カスタマーが含まれているわけではないので、すべてのプロジェクトがユーザー・ストーリーに適しているわけではありません。このアプローチでは、カスタマーとの対話がなければその利点の多くを失うことになります。

上に戻る

結論

この記事で扱ってきた要件収集プロセスは、それぞれ適切なコンテキストで使用された場合、その利点を発揮します。ただし、ここでの説明で示しているように、すべてのコンテキストに対して理想的な要件収集プロセスというものは存在しませんし、それ自体、必ずしも完全なものではないのです。単一のプロセスまたはアクティビティーだけでは本質的には完全ではないことを認識し、その不完全さを緩和するために利用可能なソリューションの幅を広げることが、ホロニックなソフトウェア開発方法の核心になります。

サイドバーの「Ten best practices of holonic software development」では、モジュール性について説明しています。モジュール性によって、2つのアクティビティーが同一の目的にかなう場合には一方のアクティビティーがもう一方のアクティビティーに取って代わることができるようになります。1つの要件収集アクティビティーを別の要件収集アクティビティーで代用する場合には、要件のコンテキストを考慮することが重要になります。開発サイクルの途中でアクティビティーを変更すると、容易に新たな一連のダイナミックスをプロジェクトにもたらす可能性があります。コンテキストを考慮しなければ、この動きは破滅的なものになるおそれもあります。しかし、実施にあたって慎重を期して計画するのであれば、新たなアクティビティーを導入することは、新たなダイナミックスを生み出す効果もあり、その結果プロジェクトを成功に近づける可能性も高めることになります。

次回は、Webサービス・インフラストラクチャーのモデル化についてお話しましょう。ソフトウェア開発のこの新興分野の探求をさらに進めていくにあたり、この2回の連載記事で扱ってきたテクニックとベスト・プラクティスをさらに具体的に示す例をご覧に入れる予定です。どうぞご期待ください。

参考文献

• ユース・ケースの詳細については、Frank ArmourとGranville Millerが作成し運用しているAdvanced Use Case Modelingホーム・ページをご覧ください。
  
  
• Jeff De Luca氏は、その記事The original FDD processes でFDDの起源を非常に分かりやすく説明しています。
  
  
• XP初心者の皆さんは、Roy MillerとChris Collinsによる徹底的な概説XPの真髄(developerWorks、2001年3月) から始めるのもよいでしょう。
  
  
• Extreme Programming.org はXPファンにとってすばらしい参考文献であり、XP開発プロセスにおけるユーザー・ストーリーの役割をやや拡大させて紹介しています。
  
  
• ユーザー中心設計 (UCD) は、ユーザー・ストーリーと非常によく似た要件収集およびフィードバック・プロセスですが、適用範囲は幅広くなります。いかにして安価で低オーバーヘッドのFly on the wall アプローチ(developerWorks、2001年8月) を用いてユーザーの要望を知ることができるのかご覧ください。
  
  
• 前回の記事も含めて、Javaモデリングコラムの連載記事を全てお読みください。
  • UMLワークブック: 第1回 シーケンス・ダイアグラムへの招待
  • UMLワークブック: 第2回 シーケンス・ダイアグラムの条件付きロジック
  • UMLワークブック: 第3回 ユース・ケース・モデリングにおけるユーザー・インターフェース・ロジック
  • ホロニックなソフトウェア開発 声明書
  
  
  
• developerWorks Javaテクノロジー・ゾーン で他のJava参考文献もご覧ください。
  
  

著者について

Granvilleは、オブジェクト指向コミュニティーで13年間の経験を積んでいます。彼は Advanced Use Case Modeling シリーズの共著者であり、世界各地で開催されるさまざまなオブジェクト指向テクノロジーのコンファレンスでチュートリアルを提供しています。オブジェクト指向開発に関する彼の実践的なアプローチは、設立まもない企業から確固とした地位を築いているソフトウェアの巨人たちまで、さまざまな企業で仕事をした経験に基づくものです。
現在は、アジャイル・プロセス、方法論、およびJavaテクノロジーに関するセミナー、チュートリアル、および講習で教えるほか、積極的なプロジェクトの推進を指導および支援しています。Granvilleの連絡先は rmiller@togethersoft.com です。

この記事を評価する

コメント

上に戻る

目次

• ソフトウェアの不可視性という問題
• ジョブに最適なプロセスを選ぶ
• ソフトウェア要件仕様
• ユース・ケース
• フィーチャー
• ユーザー・ストーリー
• 結論
• 参考文献
• 著者について
• コメント