Loading
|
|
＠IT｜＠IT自分戦略研究所｜QA＠IT｜イベントカレンダー＋ログ |
|
Loading
|
| ＠IT > ソフトウェア開発4つの課題（1） |
 |
企画：アットマーク・アイティ
営業企画局 制作：アットマーク・アイティ 編集局 掲載内容有効期限：2004年12月31日 |
|
|
|
 ソフトウェア開発4つの課題第1回 反復型プロセスの導入 RUPはカボチャを馬車にできるか？ 日本IBM 藤井智弘 ソフトウェア開発の複雑性を解消する“魔法の杖”は果たして存在するのだろうか？ 反復型プロセスを導入することで複雑性を緩和できるという意見がある。本当にそうなのか、反復型プロセスの代表格「RUP（Rational Unified Process）」で検証してみる。
「RUP（Rational Unified Process）」において1回の反復とは、ビジネスモデリングから始まり、要求→分析設計→実装→テストという一連の手順、すなわちウォーターフォールそのものにすぎない。従来型（本稿で従来型とは、RUPと比較して、という意で用いる）の開発プロセスが、顧客と同意された“全要求”（この“全”というところがミソですな）を満たすために、基本的にはウォーターフォール・プロセス一度で消化することを目標とするのに対し、RUPでは短期間のウォーターフォールを複数回繰り返し、システムそのものは、反復の度に段階的に成長していくという形を取る。 この結果、一般論としては次のメリットが謳（うた）われる。
（2） 要求の変更に柔軟に対応できる （3） リスクを早期に解決できる
最近あちこちで耳にする“反復推進派”や“反復否定派”双方の見解には、これらの “メリット”のみが1人歩きした誤解と思われるモノも少なからずある 。ここでは、上記3つのテーマに関して、よくある誤解（あるいは誤解とおぼしきモノ）を解くべく、今一度その意味を確認しておきたい。
従来手法からすれば短期間でのリリースを求められるWeb系のシステムで、Javaが脚光を浴びたことの影響からか、RUPやXPといった反復型プロセスを論じるときに、「短期開発が可能」と謳われることが多い。 ところで、「短期開発」とは、何を意味するのだろうか？ 反復の本来の効果を知るためには、反語的だが、「プロジェクトを長期化させていた要因は何か？」を考える必要がある（注1）。 ［注1］ 実際、短期での開発案件で効果を実感している方もたくさんいらっしゃるので、本稿では短期プロジェクトにおける効用は議論しない。 代表的なモノは、以下のものではないだろうか（注2）？
［注2］ もちろんこれ以外にもいろいろあるとは思うが、字数の制限もあるので、これくらいで勘弁してください。 短期開発を期待する人の中には、システムの複雑や高度な機能という話とはまったく関係なく、絶対時間の短さ（「××カ月でできるか？」）のみに関心を持つ人が決して少なくない（特に、管理者層に）。 しかし、期間の長短はシステムの満たすべき要件とそれを実現するためのシステムの複雑さが左右する話であり、「反復するから短期」や「短期じゃないから反復しない」という類の議論はまったく無意味だ。 反復開発の価値は、本来リスクをヘッジすることにある（これについては後述）。その意味で、 「反復開発→短期開発」 ではなく、 「反復開発→不安定要因を排除することで、長期化を避ける」 であるといえる。すなわち、前述の長期化要因でみれば、「1、そもそも構築しようとするモノが複雑であり、そんな短期（3カ月〜数カ月）ではできない」や「5、予算も期間も外的な要因（例えば、政治的、経営判断など）で決まっているので、がんばって短期化する理由がない」は直接的なメリットを受けることがないモノである。 誤解のないように申し上げておくが、「1、そもそも構築しようとするモノが複雑であり、そんな短期（3カ月〜数カ月）ではできない」の場合には、複雑＝リスクととらえて、反復の効果を期待できることはいうまでもない。しかし、それは「長期化を避ける」という意味で効果があるのであり、抜本的な「短期化」を考えるのであれば、パターンやフレームワークの適用、再利用が重要になる。 反復型プロセスを導入しようとする組織によくみられる、社内向けガイドラインで「短期開発のプロジェクトに適用」というような話は、なにかを勘違いしている証拠である。反復を適用すべきか否かは、プロジェクトの規模の問題ではなく、「自分たちがプロジェクトの進行を妨げる不安定要因をどの程度把握しているか？ 制御できるか？」で決定されるべきなのだ。それが次項の「反復とリスク」の話へとつながる。
「石橋を叩いて渡る」は、物事に慎重な人をたとえて使われる表現ではある。反復型プロセスの標榜する「リスクの早期解決」は、「“石橋を叩いて渡る”進め方」と見ることができる。 企業間の買収／合併が珍しくなくなった昨今、「システムの統合」がリスクの1つとして当たり前のように挙げられるようになった影響か、システム構築のリスクに目を向けるエンジニアが増えてきている。オブジェクト指向技術に懐疑的なエンジニアでも、リスクの解決手段としての“反復というアプローチ”には、一定の理解を示す人が少なくない（だからといってすぐに反復信奉者になるわけでないのだが）。 リスクを早期に解決するためには、当然、解決すべきリスクを早期に把握しておかなければいけない。しかし、多くのエンジニアはこれまで、約束した機能を実現することを優先するばかりで、いざ、リスクを挙げてみろといわれると、「リスクってなんですか？」という状況になることが多い。私たちは反復型のメリットを享受するために、そもそも「リスクにはどんな種類があるのか」を把握することから始める必要がある。ただし、それには次のような視点を持つことが重要である。 ［“はずだ”／“べきだ”は当てにしない］ 「石は硬い“はず”で、それゆえに、渡れる“はず”だ」。確かにそうかもしれない。だが、ソフトウェア開発で、このような“はず”や“べき”に泣かされた経験をお持ちではないだろうか？
はっきりいって、“はずだ”／“べきだ”の多くは、「論理的な帰結」というよりは、「単なる気合い」であり、「単なる期待」でしかない。そこには目で見て分かるような客観的な結果としての“解決”はない。“はずだ”／“べきだ”がその通り実現されているというのなら、結果としてみせればいいだけの話なのだ。 ［“ToDo”ではなく“できない”リストを作ること］ WBS（Work Breakdown Structure）やToDoリストは、やることが明確にあったうえでの消化状況を把握することが目的だ。しかし、そのバックグラウンドにある問題意識は見えない。さまざまな要素技術が急速に発展している現状では、ある問題に対して、解決策が複数ありえるし、そのすべてをフォローしていくことは不可能である。WBSも必要だが、リスクを洗い出すという観点からは、「できないこと」「不可能と思われること」「不安に思っていること」を、まずそのまま出すことが大事である。同時に、それへの対処プランを提示するようにしよう。 ［まず予測すること。予測がはずれたらそれは“幸せ”だと思うこと］ “できないこと”リストは、「できないことが分かっている」という意味で、安心感がある。問題は、予想の範疇（はんちゅう）外のリスクである。そこで重要なのは、分かっている範疇で立てた計画と、ずれた結果との対比／分析を通じて、隠れたリスクを洗い出すことである。要員の生産性、スキル面での不足、認識していなかった技術面でのリスクなど、予定よりも（開発作業が）遅れたということは、リスクが顕在化した結果であり、これは実は歓迎すべきことなのである。
前出の議論でもお分かりいただけるように、反復型の開発のメリットは本来「リスクを早期に対処する」ということが主であり、“要求の変更”もリスクのうちの1つである、ということができる。しかし、この“要求の変更に強い”というフレーズもいろんな意味に解釈されており、各々の立場で期待値が違っているようにみえる。結果として、その期待値のずれが、「思ったほど柔軟ではない」とか「強いといいながら、予算がオーバーした」などの負の評価に結び付いている。 要求の変更に対する期待値は、立場によって大きく以下の2つに分類できる。
同じコストを支払うなら、最終的にはより満足度の高いシステムを手に入れたいというのは当然の欲求である。だが、どうすれば満足度が上がるのか。反復型プロセスを導入すれば、（機能限定ながら）システムを実際に目にすることで、要求が明確になり、また要求を変更しても受け入れられる余地が増える。 ［2］ 受注側にとっての要求変更 受注する側にしてみれば、要求変更はリスク以外のナニモノでもない。反復型プロセスは、発注側が反復の意図をよく理解し、システム化の本来の目的を踏まえた上で、変更要求の取捨選択ができる限りにおいて有効である。 気を付けなければいけないのは、受注側にとっての要求変更とは「コミットされ、予定していたことから変わる」ことをいうのであって、それには、
◇ 発注側の意識として要求事項自身は変わっていない。しかし、これまでは不明瞭あるいは隠れていたものが顕在化したために、受注側にとっては要求変更時と同等の対処が必要になる という、やや様子の異なるものが同レベルで語られているという点は要注意である。 Webシステム開発の初期、「Webを使ったビジネス」は、みんな未経験だから要求変更は当然として思われている節がある。しかし、適用分野が基幹系や業務系システムに広がってくると、その業務に関しては牢名主みたいな人がよく登場する。この手の人は、多くの知識を持っていながら、それを他人に伝達することに関しては消極的な人が多い（俗に、暗黙知などと称されるものが生まれる）。ある程度システムができあがった段階でこの人のレビューを受けると、事前のインタビューでは出なかった例外ケースが出ることは当たり前である。ここに、異なる立場による「顕在化」対「要求変更」という見解の相違が発生するのである。 結論として“複雑なモノは、やっぱり複雑なのであって、「カボチャを一瞬のうちに馬車にするようなプロセス」などは存在しないのだ……”では解決の指針にも何にもならないので、次回は RUP(Rational Unified Process)をベースに、「反復の企画・運営の仕方」について議論したい。
|
|
