|
[2005 年 3 月号] |
[技術講座]
この連載では、代表的なソフトウェア開発プロセスである UP のライフサイクルモデルについて解説しています。前回は UP の最初のフェーズ、方向づけフェーズの範囲と計画のサンプルを解説しました。
今回は次の推敲フェーズの範囲と計画について解説します。
UP ではソフトウェアを開発し、正式なリリースするまでの期間を 4 つのフェーズに分けて計画を立て、コントロールします。前回は 4 つのフェーズのうち、一番初めのフェーズである方向づけフェーズについて解説しました。今回は、次の推敲フェーズについて解説します。
UP で定義されているフェーズには、それぞれに達成しなければならないマイルストーンがあります。推敲フェーズのマイルストーンは、「重大なリスクに対応する」ことです。このマイルストーンが示すように、推敲フェーズでは「リスク」を特定して対応することが重要になります。
それでは、「リスク」とは何なのでしょうか？
そして、推敲フェーズで対応しなければならない「重大なリスク」とは何なのでしょうか？
ソフトウェア開発プロジェクトに限らずすべてのプロジェクトには達成すべき 4 つのプロジェクト目標があります。
プロジェクトでは、これら 4 つのプロジェクト目標を達成できるように、計画を立案するわけですが、4 つのプロジェクト目標を考慮するだけでは問題があります。なぜなら、プロジェクトには計画通りに進まない不確実性、つまりリスクが常に付きまとうからです。そのため、リスクに対して計画を立案し、実施し、コントロールすることが必要です。推敲フェーズの計画では、特にリスクをマネジメントすることが重要になります。
では、「株価が下がる」というリスクの例を使って、リスクの特徴をもう少し詳しく説明しましょう。
まず、リスクにはリスクが発生してしまう何らかの根本原因があるはずです。「株価が下がる」の例では、そもそも「会社の業績が下がる」ことが根本原因です。
次に、リスクとは必ず起こるとは限らない不確実な事象です。「株価が下がる」の例では「株価が下がる」ことが不確実な事象です。
そして、リスクであったことが実際に起こってしまうことによって、マイナスの影響が出てしまいます。「株価が下がる」の例では「株主の資産が減る」ことがマイナスの影響です。
図 1 リスクの例
このように、リスクには、「根本原因」と「不確実な事象」と「マイナスの影響」の 3 つの特徴があります。この 3 つを適切に識別してリスクをマネジメントすることには、次のような利点があります。
では、プロジェクトでリスクに対応しないとどうなってしまうのでしょうか？
例えば、プロジェクトの期間として 1 年間を想定しているプロジェクトがあるとします。このプロジェクトにはスケジュールに影響を与える以下の発生確率と影響度を持つリスクが 4 つあります。
表 1 リスクの分析
| リスク ID | 発生確率 | 影響度 | 発生確率 × 影響度 | 対応策実施にかかる期間 |
|---|---|---|---|---|
| リスク 1 | 50 % | 2 ヶ月の遅れ | 1 ヶ月の遅れ | 1 ／ 4 月 |
| リスク 2 | 50 % | 1 ヶ月の遅れ | 半月の遅れ | 1 ／ 4 月 |
| リスク 3 | 25 % | 2 ヶ月の遅れ | 半月の遅れ | 1 ／ 4 月 |
| リスク 4 | 25 % | 1 ヶ月の遅れ | 1 ／ 4 月の遅れ | 1 ／ 4 月 |
もしこれら 4 つのリスクに対して何も対応しない場合には、平均 2 ヶ月と少しのスケジュールの遅れ（すべてのリスクの発生確率 × 影響度の合計）が発生してしまいます。そのため、何らかの対応策を立案し、実施しなければなりません。だからといって、すべてのリスクに対応しなければならないかというとそういうわけでもありません。
リスク 3 のように発生確率が低いリスクは、実はリスクが発生しないかもしれません。そのようなリスクに対して、早期からリスク対応策を実施する必要はありません。その代わり、あらかじめリスク対応策を立案して、リスクの兆候を監視し、必要なタイミングでリスク対応策を実施に移すのです。
また、リスク 4 のように、リスクの被害（発生確率 × 影響度）と対応策にかかる期間がほぼ同じようなリスクについては、対応策すら立案せずにリスクを受容することも重要です。
このように、プロジェクトでは、リスクを識別して、リスクの特徴を理解し、リスクに適切な対応をして、ソフトウェアを完成させなければなりません。
では、プロジェクト目標の達成を阻むリスクにいつ対応しなければならないのでしょうか。少し遠回りすることになりますが、4 つのプロジェクト目標を達成するための戦略にどのようなものがあるか考えてみましょう。
スコープのプロジェクト目標を達成するための一般的な戦略は、要求を定義し、その要求が実現可能なことを検証することです。このような戦略のもとで、安全にプロジェクトを進めていくためには、業務の知識や機能外要求に詳しいエンジニアや、機能外要求の実現方法であるソフトウェアアーキテクチャに詳しいエンジニアを確保しなければなりません。
タイムのプロジェクト目標を達成するための一般的な戦略は、大勢のエンジニアをプロジェクトに投入して開発を行うことです。このような戦略のもとで、安全にプロジェクトを進めていくためには、大勢のエンジニアがソフトウェアアーキテクチャなどの難しいことを考えないで作業できなければなりません。
コストのプロジェクト目標を達成するための一般的な戦略は、低コストのエンジニアをプロジェクトに投入して開発を行うことです。このような戦略のもとで、安全にプロジェクトを進めていくためには、低コストのエンジニアがソフトウェアアーキテクチャなどの難しいことを考えないで作業できなければなりません。
品質のプロジェクト目標を達成するための一般的な戦略は、安定した開発プロセスやソフトウェアアーキテクチャのもとで開発を行い、適切なテスト計画のもとでテストを行うことです。このような戦略のもとで、安全にプロジェクトを進めていくためには、安定した開発プロセスやソフトウェアアーキテクチャや要求仕様がなければなりません。
これらの 4 つのプロジェクト目標に対する戦略には明らかな順序関係があります。タイムの戦略、コストの戦略、品質の戦略は、要求仕様やソフトウェアアーキテクチャが安定していないと有効ではありません。そのため、タイムの戦略、コストの戦略、品質の戦略を実施する前に、スコープの戦略を実施して要求仕様やソフトウェアアーキテクチャを安定させないといけないわけです。
この戦略の順序関係を UP のフェーズに当てはめて考えると、それぞれのフェーズで行うべきことも明らかになります。つまり、UP の推敲フェーズはスコープの戦略を実施する時期であり、作成フェーズや移行フェーズはタイム、コスト、品質の戦略を実施する時期であると言えるわけです。
図 2 戦略を実施するフェーズ
このように、推敲フェーズでは主にスコープのプロジェクト目標を達成するための戦略を実施していくことになります。そのため、スコープに影響するリスクに重点的に対応していかなければなりません。ただし、スコープに影響するリスクに対応することがすべてかというとそういうわけでもありません。作成フェーズの計画に大きな影響をおよぼしてしまうようなタイム、コスト、品質のリスクにも対応します。
では、推敲フェーズで対応しなければならないリスクとは具体的にどのようなものがあるのでしょうか？
スコープに影響を与えるリスクは、要求そのものに関するリスクと、機能外要求を実現するためのソフトウェアアーキテクチャに関するリスクに分けられます。
プロジェクトの目的は、要求を実現したソフトウェアを完成させることです。もし、適切な要求を定義できていない場合には、不適切なソフトウェアが完成してしまいます。もし、開発者やテスト担当者が理解できないような要求を定義してしまうと、やはり不適切なソフトウェアが完成してしまいます。もし、要求の変更が頻繁に発生してしまう場合には、必ずとは言えませんが不適切なソフトウェアが完成してしまう可能性が高くなります。このようなリスクが起きてしまわないように、そのプロジェクトごとに適切な対応をしなければなりません。
近年のソフトウェア開発では、求められる要求の種類も多くなり、要求の水準も高くなっています。また、選択できる技術要素にも幅が増えています。そのために、一部の職人のセンスと経験に頼るような昔ながらの方法でソフトウェアアーキテクチャを開発してしまうと、機能外要求を満さないソフトウェアアーキテクチャができあがったり、期限までにソフトウェアアーキテクチャを完成できなかったり、ソフトウェアアーキテクチャをプロジェクトで共有できなくなる可能性が高まってしまいます。このようなリスクが起きてしまわないように、そのプロジェクトごとに適切な対応をしなければなりません。
タイムやコストの見積もりは、重要で難しい問題です。困難な機能外要求や新しいソフトウェアアーキテクチャを採用するプロジェクトの見積もりであればなおさらです。作成フェーズの詳細見積もりが不正確にならないように、推敲フェーズで適切な対応をしなければなりません。
高品質のソフトウェアを開発するためには、開発者が要求を正しく把握し、テスト計画者が綿密なテスト計画を立案する必要があります。そのためには、推敲フェーズから品質を考慮した計画を立案しなければなりません。
推敲フェーズで行わなければならない作業分野の一つに「要求」があります。作業分野「要求」では、プロジェクトの要求に関するリスクに対応するために、ソフトウェアの機能的な要求をユースケースとして定義し、ソフトウェアの機能以外の要求を機能外要求として定義します。
ユースケースとは、ユーザーがソフトウェアを使ってできることを定義したものです。
ユースケースをどうやって見つければ良いのでしょうか。その鍵は前回に説明した作業分野「ビジネスモデリング」で作成する業務フローにあります。前回は業務フローを作成して、ソフトウェアの利用者がどのような業務を行っているのか定義しました。この業務フローで定義した各作業からソフトウェアで支援できるような作業や、自動化できる作業をユースケースとして定義していくのです。
例えば、業務フローの中に「注文受付担当」ビジネスワーカーが「受注」作業しているとします。「受注」作業では、顧客から注文書を受け取ったり、その顧客の与信審査を行ったり、在庫を引き当てたり、出荷担当に出荷を指示したりします。このような作業で行わなければならないことから、ソフトウェアはソフトウェアの利用者に何を提供できるのか考えます。今回の「受注」作業の例では、顧客の与信審査を行うこと、在庫を引き当てること、出荷担当に出荷を指示することを、ソフトウェアが支援するような「注文を登録する」ユースケースを定義します。
図 3 ユースケースを定義する
また、ユースケースの定義と一緒に、ユースケースを利用するユーザーをアクターとして定義します。先ほどの例では、「注文受付担当」ビジネスワーカーが「受注」作業を行っていたので、「注文受付担当」をアクターとして定義します。
図 4 アクターを定義する
UML のユースケース図では、ソフトウェアの利用者であるアクターとユースケースの関係だけしか定義できません。そのため、ユースケースのより詳細な定義として、事前条件や基本フローや代替フローなどのユースケース記述を定義します。
事前条件とは、対象のユースケースを開始するための必須条件です。
基本フローとは、ユーザーが期待した通りにユースケースが完了するまでの、ユーザーとソフトウェアの対話を定義した文章です。
代替フローとは、基本フロー以外のユーザーとソフトウェアの対話を定義した文章です。
図 5 ユースケース記述
これまでのオブジェクト指向開発プロジェクト、UP を適用したプロジェクトでは、ソフトウェア要求の機能的な側面である、ユースケースに焦点が当てられ過ぎてきました。しかし、ソフトウェア要求は、機能的な側面だけではなく、機能外の側面もあります。この機能外の側面を定義する機能外要求をおろそかにしたままソフトウェアを開発してしまうと、最終的にできあがったソフトウェアは運用や保守に耐えられないものになってしまいます。
UP では、機能外要求を定義するための指針として、FURPS （ Functionality; 機能、Usability; 使いやすさ、Reliability；信頼性、Performance；パフォーマンス、Supportability；サポートしやすさ ）を利用することを推奨していますが、私は ISO9126 で規格化されているソフトウェアの品質特性を利用することを推奨します。ISO9126 では、ソフトウェアを外部の視点から評価するための特性として、6 つの品質特性と、品質特性をより詳細化した 27 の品質副特性が定義されています。これらを利用することにより、機能外要求を漏らすことなく定義することができます。
表 2 ISO9126
| 品質特性 | 品質副特性 |
|---|---|
| 機能性 | 合目的性、正確性、相互運用性、セキュリティ、機能性関連適合性 |
| 信頼性 | 成熟性、障害許容性、回復性、信頼性関連適合性 |
| 使用性 | 理解性、習得性、運用性、魅力性、使用性関連適合性 |
| 効率性 | 時間効率性、資源効率性、効率性関連適合性 |
| 保守性 | 解析性、変更性、安定性、試験性、保守性関連適合性 |
| 可搬性 | 環境適応性、設置性、共存性、置換性、可搬性関連適合性 |
これらの定義した機能外要求は、ソフトウェアアーキテクチャを開発するための主要なインプットとなります。
作業分野「要求」では、ユースケースモデルやユースケース記述を作成することによって、機能的な要求を大まかに定義しました。しかし、ソフトウェアに求められる要求には、より詳細で、より具体的な要求として、ユーザーインターフェース仕様や、ビジネスルールが残っています。これらを定義するために、作業分野「分析／設計」の作業として、ユースケースを分析します。
ユースケースの分析に関する話題は、オブジェクトの広場で連載中の記事、『実践ロバストネス分析』を参照してください。
UP には、ソフトウェアアーキテクチャを開発するための単独の作業分野はありません。ソフトウェアアーキテクチャに関する話題は、作業分野「分析／設計」や作業分野「実装」や作業分野「テスト」にまたがってしまいます。作業分野を意識してソフトウェアアーキテクチャを説明すると分かりにくくなってしまうため、これらの作業分野にとらわれずに解説します。
ソフトウェアアーキテクチャとは、様々なユースケースに共通して適用できるソフトウェアの仕組みです。ソフトウェアアーキテクチャには、プロジェクト内で自作するフレームワークやクラスライブラリなどの動作するプログラムが含まれることもありますが、そのほとんどは設計の方針や規約などの抽象的な設計情報であるため、その内容をソフトウェアアーキテクチャ説明書（Software Architecture Document）という文書にまとめる必要があります。
ソフトウェアアーキテクチャを開発するためには、まずソフトウェアアーキテクチャにどのようなメカニズムが必要なのか特定しなければなりません。メカニズムとはソフトウェアアーキテクチャに求められる機能で、オブジェクトの永続化、トランザクション管理、ログ出力、例外処理などがあります。
そして、特定したこれらのメカニズムごとに、どのような技術要素を使えば機能外要求を実現できるのか判断し、選定します。そのために、ベンダーに提案させたり、調査用のプロトタイプを作成したりすることもあります。場合によっては、プロジェクト内で使用するフレームワークやクラスライブラリを作成することもあります。
例えば、ログ出力というメカニズムのための技術要素を選定する場合には、様々な技術要素を調査し、その中から機能外要求を最も満たす技術要素を選定することになります。
図 6 メカニズムの特定・選定
どの技術要素を使ってメカニズムを実現するのか決定することだけが、ソフトウェアアーキテクチャの仕事ではありません。開発者がそのメカニズムを使ってどうやって設計をし、実装をするべきか方針や規約を決めて、ソフトウェアアーキテクチャ説明書にまとめなければなりません。
ログ出力の場合であれば、どのような種類のログ（エラーログ、稼動ログ、デバッグログ、etc ）を、いつ（どのクラス、どの操作、どこで）、どのクラスのどの操作を使って、どのような情報を出力して、どのような設定をする必要があるのか、などの方針や規約を決めなければなりません。
推敲フェーズをどのように計画し、実施するかは、そのプロジェクトにあるリスク次第で変わります。例えば、ソフトウェアアーキテクチャのリスクが高い場合と低い場合では計画の内容は変わりますし、要求のリスクが高い場合と低い場合でも計画の内容は変わります。
そこで、今回はプロジェクトにあるいくつかのリスクを例示して、それぞれのリスクごとにどのように推敲フェーズを計画するべきか示します。
経験不足の技術要素を採用することが決まっているプロジェクトがあるとします。ただし、このプロジェクトは納期も予算もそれほど厳しくはなく、開発対象の業務知識も十分に持っています。このようなプロジェクトは、以下のようなリスクがあると言えます。
これらのリスクへの最も根本的な対応は、これらのリスクの根本原因である経験不足の技術要素の採用を取りやめることかもしれませんが、この技術要素の採用自体がプロジェクトの目標であったり、制約条件である場合にはそうもいきません。
そのため、どうすればこの技術要素を使って機能外要求を実現できるのか調査したり、開発者が技術要素を使いこなせるように教育をする必要があります。
図 6 経験不足の技術要素を採用する場合の推敲フェーズ
この推敲フェーズでは、3 回の反復を繰り返して推敲フェーズのマイルストーンを達成するように計画しています。
リスクへの対応として、推敲フェーズの早い時期に経験不足の技術要素を使うメカニズムの設計を行ったり、推敲フェーズの最後には作成フェーズのコアメンバーとなる開発者を集めて一部のユースケースを開発したりしています。
業務知識に関するリスクはないため、推敲フェーズでは 60 % のユースケースを定義し、分析するだけで、残りのユースケースの定義、分析は作成フェーズで行うように計画しています。
経験不足の技術要素を採用し、かつ納期が短いプロジェクトがあるとします。ただし、このプロジェクトは予算はそれほど厳しくはなく、開発対象の業務知識も十分に持っています。このようなプロジェクトは、以下のようなリスクがあると言えます。
前述のプロジェクトのリスクと比べると、「納期までに機能外要求が実現できない」可能性が高くなっています。
そのため、機能外要求や技術要素に詳しいコンサルタントを雇ったり、開発者が技術要素を使いこなせるように教育をする必要があります。
図 7 経験不足の技術要素を採用し、かつ納期が短い場合の推敲フェーズ
この推敲フェーズでは、2 回の反復を繰り返して推敲フェーズのマイルストーンを達成するように計画しています。
リスクへの対応として、推敲フェーズの早い時期にコンサルタントが機能外要求を定義し、メカニズムの設計を行ったり、推敲フェーズの最後には作成フェーズのコアメンバーとなる開発者を集めてコンサルタントの支援を受けながら一部のユースケースを開発したりしています。また、ユースケースを定義し、分析する要員を通常のプロジェクトより多くアサインします。
業務知識に関するリスクはないため、推敲フェーズでは 60 % のユースケースを定義し、分析するだけで、残りのユースケースの定義、分析は作成フェーズで行うように計画しています。
チームに業務知識が不足しているプロジェクトがあるとします。ただし、このプロジェクトは納期も予算はそれほど厳しくはなく、機能外要求の実現方法（ソフトウェアアーキテクチャ）も大体見通しが立っています。このようなプロジェクトは、以下のようなリスクがあると言えます。
業務知識がないことに起因するリスクに対応するために、業務知識があるコンサルタントを雇ったり、精度が高い見積もりをするためにすべてのユースケースを定義して分析しています。
図 8 業務知識がない場合の推敲フェーズ
この推敲フェーズでは、3 回の反復を繰り返して推敲フェーズのマイルストーンを達成するように計画しています。
リスクへの対応として、推敲フェーズの間、業務知識があるコンサルタントを雇ってユースケース定義・分析の支援を受けたり、推敲フェーズですべてのユースケースを定義し、分析しています。
ソフトウェアアーキテクチャに関するリスクはないため、推敲フェーズでは 80 % のメカニズムを設計するだけで、残りのメカニズムの設計は作成フェーズで行うように計画しています。
納期が短い、または予算が少ないプロジェクトがあるとします。ただし、このプロジェクトはチームメンバーは業務知識に精通し、難しい機能外要求もほとんどありません。このようなプロジェクトは、以下のようなリスクがあると言えます。
納期が短い、予算が少ないことに起因するリスクは、推敲フェーズの計画だけで対応することは困難な場合が多く、その場合には作成フェーズや移行フェーズの計画をあらかじめ立案しておかなければなりません。このプロジェクトのリスクに対応するために、現行システムで適用しているソフトウェアアーキテクチャを再利用し、ユースケースの定義だけを行います。推敲フェーズの最後に、優先度の高いユースケースと低いユースケースを決定し、優先度の高いユースケースだけを作成フェーズで開発することを決定します。
図 9 納期が短い、予算が少ない場合の推敲フェーズ
この推敲フェーズでは、1 回の反復だけで推敲フェーズのマイルストーンを達成するように計画しています。
このプロジェクトのリスクに対応するために、現行システムで適用しているソフトウェアアーキテクチャを再利用し、ユースケースの定義だけを行います。推敲フェーズの最後に、優先度の高いユースケースと低いユースケースを決定し、優先度の高いユースケースだけを作成フェーズで開発することを決定します。
ユースケースの分析は作成フェーズで行うように計画しています。
今回は、推敲フェーズの範囲と計画について説明しました。次回の記事では、作成フェーズと移行フェーズについて、深く掘り下げて解説します。
どうぞ、お楽しみに。
[1] 『UMLによる統一ソフトウェア開発プロセス―オブジェクト指向開発方法論』Ivar Jacobson・James Rumbaugh・Grady Booch／著, 藤井 拓／訳, 翔泳社
[2] 『ラショナル統一プロセス 第 3 版』Philippe Kruchten／著, 藤井 拓／監訳, 株式会社アスキー
[3] 『ラショナル統一プロセス〈 RUP 〉ガイドブック ― RUP 実践者を成功に導く』Per Kroll・Philippe Kruchten／著, 杉本 宣男・落合 修・永田 葉子／訳, エスアイビー・アクセス
[4] 『ラショナル統一プロセスによるJ2EEアプリケーション構築』 Peter Eeles・Kelli Houston・Wojtek Kozaczynski／著, 堀井 未来／訳, 新紀元社
[5] 『プロジェクトマネジメント知識体系ガイド 第 3 版』 Project Management Institute, Inc
| © 2005 OGIS-RI Co., Ltd. |
|
