アットマーク・アイティ @IT@IT自分戦略研究所QA@ITイベントカレンダー+ログ
 @IT > ソフトウェア開発4つの課題(2)
 
@IT[FYI] 企画:アットマーク・アイティ 営業企画局
制作:アットマーク・アイティ 編集局

掲載内容有効期限:2004年12月31日

 
ソフトウェア開発4つの課題
第2回 反復の企画・運営の仕方
方向づけ/推敲/作成/移行、
何をどこまでやるか?


日本IBM
藤井智弘

 反復型開発プロセスとは、「方向づけ」「推敲」「作成」「移行」という4つのフェイズを繰り返しながら成果物を最終段階まで運んでいくソフトウェア開発の方法論の総体を指す。このこと自体を理解するのは簡単だが、繰り返される各フェイズの詳細について把握するのはなかなか難しい。つまり、何を、どこまでやればいいのだろうか? フェイズのさじ加減は、経験者のみが知っている。(アットマーク・アイティ編集局)

   いつ、なにを、どこまで? 反復型プロセスにおける“計画”?

 第1回「反復型プロセスの導入RUPはカボチャを馬車にできるか?」では、“反復”を巡る誤解を俎上にあげた。

(1) 「反復と短期開発」の誤解
(2) 「リスクを早期に解決できる」の誤解
(3) 「要求の変更に強い」の誤解

 今回は、これらを踏まえて、反復を実際に“回す”ために何をすべきか、「反復の企画・運営の仕方」を俎上にあげたい。

ソフトウェア開発者ギルドへ

 計画の重要性は、反復型開発に限った話ではない。限られた制約(時間、人員、コスト)の中で、所定の結果を得ようとするなら、計画なしでは立ち行かない。反復型プロセスにおける計画について一般的なお話としては、次のことが語られる。

(1) 早期の反復は、リスクの高いモノ、重要度の高いモノに焦点を当てる
(2) 各反復では、(機能が限定されてはいるが)あるシナリオ(注)が実行できる“ミニ”システムを作ること


注:シナリオと呼んだり、ストーリーと呼んだり、プロセスによって、まちまちではあるが……。

(3) 各反復の計画時には、当初認識していた要求、リスクだけでなく、反復の過程で見い出された新たな要求、要求への拡張、リスクも勘案し、全体的に俯瞰(ふかん)して優先づけを行う。

 反復しようとしているプロジェクトの多くで見受けられるのが、「計画の節目に(いつ)、なにを、どこまで(詳しく、あるいは深く)、決めればいいのか分からない」というケースである。

 反復型プロセスの前提が「要求変更に積極的に対処する」ことである以上、作るシステムの仕様が、固定化されないという不安感を持つ方が多いのは理解できる。Rational Unified Process(以下、RUP)では、フェイズという概念を導入して、プロジェクト進行上の大きな節目を明示している()。基本的なフェイズは以下の4つである。

図 フェイズと反復

方向づけ
推敲
作成
移行

 各フェイズには、マイルストーンと呼ばれる、成果物が定義されている(詳細はRUPに譲るが)。ここでは、「何をどこまで決めるか」という視点で、各フェイズの意味を見直してみたい。

方向づけの「何を、どこまで」

 このフェイズの目的は、開発するシステムの方向性を定義することにある。では、“方向性”を明示するためには何が必要か?

  • 解決対象となる問題
  • 誰にとっての解決策か?
  • どう解決するか?

 方向づけは“投資に値するプロジェクト”か否かを判断する時期である。言い方を変えれば、「無駄な投資をするリスク」を減じる時期である。そのためには、解決対象である問題が、結果が判断できるよう、明確に定義されている必要がある。

 また、この議論の過程では、多くの利害関係者が関与することになるが、最終的にシステムとしては、誰にサービスを提供し、誰を対象外とするのかを明確にする必要がある。そして、具体的にどのようなサービスで解決を図るのかが重要である。

 この時期で決めておくべきことは、「投資対効果」の観点からシステムの売り口上となるユースケースで十分である。間違っても「全ユースケースを洗い出す」なんて考えてはいけない。

推敲の「何を、どこまで」

 方向づけが“投資対効果”リスクへの対処だとすれば、推敲は“技術(特にアーキテクチャ)”リスクに対処する時期である。この時期の主眼は、方向づけでの「こうやりたいな」を、「こう、できる」という技術的裏付けを取ることである。そこで必要なモノは次の2点である。

・技術的裏付けを形にし、機能を限定したシステム(“アーキテクチャベースライン”。なお、アーキテクチャについては次回以降取り上げる予定なので、ここでは、仕様という観点に注目する)

・システムとして成立するために必要なユースケース

 アーキテクチャについては次回以降で取り上げる予定なので、ここでは、2番目の“仕様”という観点に注目する。

 方向づけのユースケースとは、「○○が実現するなら投資してもいいな」という売り文句が主体になるので、当然ながらそれだけではシステムの仕様として不十分なことが多い。特にシステムの管理者やデータの保守といった方面のユースケースは、ユーザー部署との会話では議論されないことも少なくない。しかし、これらは、システムが「システムとして動く」ために必要である。

 推敲フェイズ終了時点でのユースケースは、これら管理系のモノも取り込んだ、「稼働するシステム」としてのユースケースととらえておくことが必要だ。では、どの程度まで決めていればよいのだろうか? RUPに触れた書籍の中で、よく「完成度80%のユースケース」などと書かれているが、これが分からないという方も多いと思われる。そこで、私個人は次のガイドを提示することとしている。

[ガイド1] その時点で、十分なユースケースがリストアップされていること。すなわち、方向づけで提示された問題点および解決策が、(複数の)ユースケースによって過不足なくカバーされること。言い換えれば、「(その時点では)ユースケースの追加がない(あるいはなさそう)と思えること。

[ガイド2] ほとんどのユースケースにおいて、イベントフロー記述や事前条件・事後条件などの作成が完了していること。ただし、プロジェクトの規模・内容によっては、次の基準を適用することがある。

  • 優先度および難易度が低いユースケースについては、完了を求めない

  • ユースケース数が多い場合には、基本フローのイベントフローは完了。代替フローのうち、処理が複雑なモノは、イベントフローを作成し、それ以外は、処理の方針を記述する(イベントフローには落とさない)

[ガイド3] もちろん、アーキテクチャベースライン作成の対象になったユースケースについては、設計なども完了していること。

 ここでのキモは、「大きなリスクが解決されていて、システムの使用イメージも明確になったから、見積もりも精度高くできる」という状態になることである。つまり、この時点で、仕様としての全体感(実現すべきことの全体像)が明確になる。だから、機能面での網羅性が重視される。個々のイベントフローは、後々の反復の結果を受けて変わりうる。

作成の「何を、どこまで」

 作成フェイズでは、淡々と作り込むので、仕様の何をどこまで決めるか? という議論の対象にはなり難い。作成フェイズでの計画の主眼は、変更依頼(機能追加や、拡張要求も含む)をどう扱い、反復の計画に結びつけるかにある。顧客から出てくる変更依頼をすべて受け入れていれば当然終わらない。かといってすべて断っていては、従来型開発スタイルと変わらない。であれば、なにを基準として判断するかのルール作りにポイントがある。このあたりは、後述の「変更を意識しつつ反復を運用する」のところで述べたい。

移行の「何を、どこまで」

 移行フェイズは、「作ったけれども使えない」というリスクを解決することに、労力を投入すべき時期である。計画の主眼も、ユーザーへの教育、運用に供するための準備に費やされる。仕様面では特に議論すべきモノはない、というよりこの時点で大きな変更が出るのであれば、別プロジェクト化するなどの検討が必要である。

   変更を意識しつつ反復を運用する

 「推敲フェイズの終わりで仕様はFixです」……。この文言は、システムインテグレータさんがよく口にする言葉である。が、反復型の場合には、次のようになる「推敲フェイズの終わりで同意された仕様がお見積もりのベースとなります」。……つまり、金科玉条の”Fix”ではないのだ。作成フェイズに入った後で出た各種の変更要求は、次の観点からふるい分けられる。

(1) 方向づけフェイズで対象とした問題点の解決方法(システムの本来の目的の実現手段)として適切なのか?

(2) それは、以前にコミットした解決方法の置き換えなのか? 新規追加(=新ユースケース)なのか?

(3) その変更を受け入れる意味(例えば「もっと効果が高い」とか)があるか?

(4) 受け入れるにあたり掛かる工数は、残工数&予算で収まる範囲か否か?

 ここでのポイントは、時間/コストの制約がある中で、提示された変更依頼が、方向づけ(推敲フェイズではない)でコミットした問題解決に意味があるかどうかを、常に意識することにある。言葉を換えれば、些末なことを決めるのに時間を掛けないという点。実は、これは、受注側のシステムインテグレータではなく、発注側の意識の問題であることが多い。反復型とは、「変更を受けること」を目的としているのではない。「問題解決のよりベターな方法を探りながら、最終的に満足度の高いシステムを実現する」ための方策である。

 つまり、

  • 何を解決すべきか?
  • どういう効果を実現するか?
  • そのためには、何を改善すべきか?

の意識があるかないかによって、変更依頼の優先順位判断があてにならないモノになってしまうリスクが常に存在する。その意味で、「推敲フェイズでの仕様はFix」ではないのだ。

   “計画”ではなく“企画”

 「そこで今回は、反復を“回す”ために何をすべきか、「反復の企画・運営の仕方」を俎上にあげたい(冒頭から引用)。

 冒頭の文言、なぜ「反復の計画」ではなく、「反復の企画」なのか? それは反復を運営していくためには、方向づけで議論された“問題と効果”の認識が、利害関係者間で共有されているか否かが、非常に重要な意味を持っていると思うからである。

 反復が回らない理由には、プロジェクト運営上の問題に負けず劣らず大きいモノとして、「反復できるようなシステムの作り(構造)になっていない」がある。次回は、「アーキテクチャ」をキーワードにいろいろ考えてみたい。

 ところで、私が所属する日本IBMでは、開発者向けのカンファレンス「IBM Rational Software Development Conference」をこの10月に企画している。オブジェクト指向やら開発プロセスやら、UML 2.0やら、とにかく開発者の参考になるようなネタてんこ盛りで皆さんのご来場を待っている。この記事がアップされるタイミングに前後して、無料ご招待のキャンペーンが貼られているので、ぜひご応募いただきたく思う。当日は私も会場をうろうろしているで、もし気が向いたら声をかけてほしい。

 

第1回 反復型プロセスの導入

第2回 反復の企画・運営の仕方

第3回 アーキテクチャ基礎講義

第4回 アーキテクチャの記述方法

[オープンソース・コミュニティ]
Apache
JFS(Journal File System)
GNOME Foundation
KDE League
Open Source Development Lab
Linux IA‐ 64

[標準化団体]
Web Services Interoperability Organization(WS-I)
Object Management Group
OASIS
World Wide Web Consortium
The Internet Engineering Task Force

[そのほか]
developerWorks
The Rational Edge
UML Resource Center
eclipse.org


@IT 関連記事
オートノミック・コンピューティング、3年間の成果、IBM (2004/12/7)

IBMフェロー、「いまはアーキテクチャ・パターンに興味がある」 (2004/10/9)

ソフトウェアITアーキテクト3倍増計画、日本IBM (2004/9/7)


開発ツール、統合化の傾向あり (2004/7/24)

2031年、ソフトウェアの旅 (2004/7/22)

IBMがEclipse 3.0基盤のモジュラー型開発環境を発表 (2004/7/21)

男女9人IBMエバンジェリスト物語 (2004/5/12)

意外に知られていないEclipseに対するIBMの貢献 (2004/4/14)

ソフトウェア開発におけるリスク回避の最適解? (2004/2/10)

日・中・韓、モデリング技術の標準化という壮大な夢 (2003/11/19)

モデラー拡大、業務モデルの共有化を目指すNPO (2003/5/20)

良いユースケースを書くコツを伝授 (2003/1/22)

失敗体験の積み重ねがオブジェクト指向開発スキルを向上させる (2002/10/26)

学生にもオブジェクト指向開発の実践スキルを、日本ラショナル (2002/9/26)

ソフトウェアの重要性が増す中でUMLに大きな関心が (2002/6/29)

Rose伝導師、「将来、モデリングは開発者の必需品に」 (2001/11/10)

オブジェクト指向開発を啓蒙するコミュニティを設立 (2001/11/8)


</comment> <tr> <td bgcolor="#EEEEEE"><font size="2"><a href="javascript:KeepIt();"> <img src="/club/keepoint/images/ico_kpt.gif" alt="kee&lt;p&gt;oint保存" border="0" align="absmiddle" width="24" height="18">kee&lt;p&gt;ointで保存</a></font></td> </tr> <comment>

 
@ITトップ@IT Special インデックス会議室利用規約プライバシーポリシーサイトマップ