Loading
|
|
＠IT｜＠IT自分戦略研究所｜QA＠IT｜イベントカレンダー＋ログ |
|
Loading
|
| ＠IT > ソフトウェア開発4つの課題（2） |
 |
企画：アットマーク・アイティ
営業企画局 制作：アットマーク・アイティ 編集局 掲載内容有効期限：2004年12月31日 |
|
|
|
 ソフトウェア開発4つの課題第2回 反復の企画・運営の仕方 方向づけ／推敲／作成／移行、 何をどこまでやるか？ 日本IBM 藤井智弘 反復型開発プロセスとは、「方向づけ」「推敲」「作成」「移行」という4つのフェイズを繰り返しながら成果物を最終段階まで運んでいくソフトウェア開発の方法論の総体を指す。このこと自体を理解するのは簡単だが、繰り返される各フェイズの詳細について把握するのはなかなか難しい。つまり、何を、どこまでやればいいのだろうか？ フェイズのさじ加減は、経験者のみが知っている。（アットマーク・アイティ編集局）
第1回「反復型プロセスの導入RUPはカボチャを馬車にできるか？」では、“反復”を巡る誤解を俎上にあげた。
今回は、これらを踏まえて、反復を実際に“回す”ために何をすべきか、「反復の企画・運営の仕方」を俎上にあげたい。
計画の重要性は、反復型開発に限った話ではない。限られた制約（時間、人員、コスト）の中で、所定の結果を得ようとするなら、計画なしでは立ち行かない。反復型プロセスにおける計画について一般的なお話としては、次のことが語られる。
反復しようとしているプロジェクトの多くで見受けられるのが、「計画の節目に（いつ）、なにを、どこまで（詳しく、あるいは深く）、決めればいいのか分からない」というケースである。 反復型プロセスの前提が「要求変更に積極的に対処する」ことである以上、作るシステムの仕様が、固定化されないという不安感を持つ方が多いのは理解できる。Rational Unified Process（以下、RUP）では、フェイズという概念を導入して、プロジェクト進行上の大きな節目を明示している（図）。基本的なフェイズは以下の4つである。
各フェイズには、マイルストーンと呼ばれる、成果物が定義されている（詳細はRUPに譲るが）。ここでは、「何をどこまで決めるか」という視点で、各フェイズの意味を見直してみたい。 ■ 方向づけの「何を、どこまで」 このフェイズの目的は、開発するシステムの方向性を定義することにある。では、“方向性”を明示するためには何が必要か？
方向づけは“投資に値するプロジェクト”か否かを判断する時期である。言い方を変えれば、「無駄な投資をするリスク」を減じる時期である。そのためには、解決対象である問題が、結果が判断できるよう、明確に定義されている必要がある。 また、この議論の過程では、多くの利害関係者が関与することになるが、最終的にシステムとしては、誰にサービスを提供し、誰を対象外とするのかを明確にする必要がある。そして、具体的にどのようなサービスで解決を図るのかが重要である。 この時期で決めておくべきことは、「投資対効果」の観点からシステムの売り口上となるユースケースで十分である。間違っても「全ユースケースを洗い出す」なんて考えてはいけない。 ■ 推敲の「何を、どこまで」 方向づけが“投資対効果”リスクへの対処だとすれば、推敲は“技術（特にアーキテクチャ）”リスクに対処する時期である。この時期の主眼は、方向づけでの「こうやりたいな」を、「こう、できる」という技術的裏付けを取ることである。そこで必要なモノは次の2点である。
アーキテクチャについては次回以降で取り上げる予定なので、ここでは、2番目の“仕様”という観点に注目する。 方向づけのユースケースとは、「○○が実現するなら投資してもいいな」という売り文句が主体になるので、当然ながらそれだけではシステムの仕様として不十分なことが多い。特にシステムの管理者やデータの保守といった方面のユースケースは、ユーザー部署との会話では議論されないことも少なくない。しかし、これらは、システムが「システムとして動く」ために必要である。 推敲フェイズ終了時点でのユースケースは、これら管理系のモノも取り込んだ、「稼働するシステム」としてのユースケースととらえておくことが必要だ。では、どの程度まで決めていればよいのだろうか？ RUPに触れた書籍の中で、よく「完成度80％のユースケース」などと書かれているが、これが分からないという方も多いと思われる。そこで、私個人は次のガイドを提示することとしている。
ここでのキモは、「大きなリスクが解決されていて、システムの使用イメージも明確になったから、見積もりも精度高くできる」という状態になることである。つまり、この時点で、仕様としての全体感（実現すべきことの全体像）が明確になる。だから、機能面での網羅性が重視される。個々のイベントフローは、後々の反復の結果を受けて変わりうる。 ■ 作成の「何を、どこまで」 作成フェイズでは、淡々と作り込むので、仕様の何をどこまで決めるか？ という議論の対象にはなり難い。作成フェイズでの計画の主眼は、変更依頼（機能追加や、拡張要求も含む）をどう扱い、反復の計画に結びつけるかにある。顧客から出てくる変更依頼をすべて受け入れていれば当然終わらない。かといってすべて断っていては、従来型開発スタイルと変わらない。であれば、なにを基準として判断するかのルール作りにポイントがある。このあたりは、後述の「変更を意識しつつ反復を運用する」のところで述べたい。 ■ 移行の「何を、どこまで」 移行フェイズは、「作ったけれども使えない」というリスクを解決することに、労力を投入すべき時期である。計画の主眼も、ユーザーへの教育、運用に供するための準備に費やされる。仕様面では特に議論すべきモノはない、というよりこの時点で大きな変更が出るのであれば、別プロジェクト化するなどの検討が必要である。
「推敲フェイズの終わりで仕様はFixです」……。この文言は、システムインテグレータさんがよく口にする言葉である。が、反復型の場合には、次のようになる「推敲フェイズの終わりで同意された仕様がお見積もりのベースとなります」。……つまり、金科玉条の”Fix”ではないのだ。作成フェイズに入った後で出た各種の変更要求は、次の観点からふるい分けられる。
ここでのポイントは、時間／コストの制約がある中で、提示された変更依頼が、方向づけ（推敲フェイズではない）でコミットした問題解決に意味があるかどうかを、常に意識することにある。言葉を換えれば、些末なことを決めるのに時間を掛けないという点。実は、これは、受注側のシステムインテグレータではなく、発注側の意識の問題であることが多い。反復型とは、「変更を受けること」を目的としているのではない。「問題解決のよりベターな方法を探りながら、最終的に満足度の高いシステムを実現する」ための方策である。 つまり、
の意識があるかないかによって、変更依頼の優先順位判断があてにならないモノになってしまうリスクが常に存在する。その意味で、「推敲フェイズでの仕様はFix」ではないのだ。
「そこで今回は、反復を“回す”ために何をすべきか、「反復の企画・運営の仕方」を俎上にあげたい（冒頭から引用）。 冒頭の文言、なぜ「反復の計画」ではなく、「反復の企画」なのか？ それは反復を運営していくためには、方向づけで議論された“問題と効果”の認識が、利害関係者間で共有されているか否かが、非常に重要な意味を持っていると思うからである。 反復が回らない理由には、プロジェクト運営上の問題に負けず劣らず大きいモノとして、「反復できるようなシステムの作り（構造）になっていない」がある。次回は、「アーキテクチャ」をキーワードにいろいろ考えてみたい。 ところで、私が所属する日本IBMでは、開発者向けのカンファレンス「IBM Rational Software Development Conference」をこの10月に企画している。オブジェクト指向やら開発プロセスやら、UML 2.0やら、とにかく開発者の参考になるようなネタてんこ盛りで皆さんのご来場を待っている。この記事がアップされるタイミングに前後して、無料ご招待のキャンペーンが貼られているので、ぜひご応募いただきたく思う。当日は私も会場をうろうろしているで、もし気が向いたら声をかけてほしい。
|
|
