プロジェクトの失敗と「要求管理のまずさ」の関係
2004/9/15
 |
| 米IBMで要求管理のエバンジェリストをつとめるジム・ヒューマン氏 |
開発期間に1〜2年もかけられた時代なら、顧客の要求を把握し、仕様書にまとめる作業、つまり要求開発にも十分な時間を割けた。開発期間全体が長かったため、要求の変更や追加を明確に判断することができたし、対応することもできた。
しかし、いまやWebシステムの開発を中心に、開発期間は平均3カ月程度と大幅に短縮された。要求開発に十分な時間はとれず、仕様変更や追加仕様の区別もつかないまま、納期に間に合わせることだけを目標にするケースは後を絶たなくなった。納期と引き換えにされるのは品質である。結果的に失敗プロジェクトの山が次々と築かれていった。
「短納期の開発プロジェクトに適する要求管理手法の導入はいまや必須である」とボーランド SE部 富山義明氏は「実例に学ぶプロジェクト管理改善のコツ」（主催：ボーランド、マーキュリー・インタラクティブ・ジャパン）というセミナーで話した。富山氏によると、要求管理の重要性が重視され始めたのは2004年に入ってからだという。このことは米IBMで要求管理のエバンジェリストをつとめるジム・ヒューマン（Jim Heuman）氏も同じように指摘した。
要求管理の重要性を訴えるアピールは2004年以前から行われていた。それは米IBM Rationalや米ボーランドに限らず、開発ツールを販売するベンダやコンサルティング・ファーム、あるいは一部の開発者の間で。だが「誰も信じていなかった」とヒューマン氏はいう。つまり、要求管理のまずさが開発プロジェクトを失敗に導く大きな要因である、という“事実”をソフトウェア開発者およびソフトウェア開発企業が信じ始めたのが2004年に入ってから、ということである。なぜ、それ以前には誰も要求管理の重要性に耳を貸さなかったのか？ 結局、失敗プロジェクトの数が足りなかったのだろう。このことについても、富山氏とヒューマン氏の意見はほぼ同じである。
では、最近の短納期開発プロジェクトに適した要求管理のアプローチとはどのようなものなのか。富山氏は大きく3点を挙げた。すなわち、「要求を構造化でき、不備を発見しやすくすること」「要求のセットを明確にし、合意を得ること」「変更による影響範囲を正確に把握できること」の3つだ。ドキュメントやスプレッドシート主体の従来型の要求管理の方法では、度重なる仕様の変化要求に的確に対応することは困難である。綿密に要求を管理しようすると、人的資源の傾注は避けられない。しかし、それは現実的な解決策とはいえない。文章で記述するのではなく、できるだけ視覚的な形で保存し、なおかつシステマチックに要求を保存し、管理し続けるには専用ツールを導入するのが妥当な解決策だ。そういう意味で、富山氏、ヒューマン氏の主張は明快である。「プロジェクトを成功に導くには、要求管理をしっかりと行う必要がある。そのためには専用のツールを導入した方がいい」。違いは、彼らの扱う製品が違うというだけだ。
要求管理は「ソフトウェア開発の最大の問題」ともいわれており、「要求管理のまずさが開発プロジェクトの失敗を招くのか？」という議論は世界各地で行われている。9月6〜10日まで、立命館大学で要求工学の世界統一国際会議「第12回 要求工学国際会議」（主催：IEEE Computer Society、情報処理学会ソフトウェア工学研究会）が開催された。日本で開催されたのは今年が初めてのことである。2003年は米カリフォルニア州モントレーで開催された。2005年はフランスのパリで開催予定。
2004年のテーマは「革新」だと同会議でスピーチを行ったヒューマン氏はいう。「往々にして、顧客は自分の求めているものを把握していない。しかし、われわれが構築したシステムを顧客に“素晴らしい”と感じてもらうには、顧客が求める以上のもの、つまり、顧客の要求以上の要求がそこに盛り込まれていなければならない。革新的なシステムを構築するには、いかにベターな要求開発を行い、管理していくかが重要なのである」（ヒューマン氏）。
（編集局 谷古宇浩司）
[関連リンク]
日本IBM
ボーランド
マーキュリー・インタラクティブ・ジャパン
[関連記事]
「要求は変化するものだ」、だから…… （＠ ITNews）
ROIを考えるエンジニアがしてはいけないこと （＠ ITNews）
良いユースケースを書くコツを伝授 （＠ ITNews）
IBMがEclipse 3.0基盤のモジュラー型開発環境を発表 （＠ ITNews）
Visual Studio .NETでUMLモデリングをする （＠ ITNews）
情報をお寄せください：
最新記事
 |
|
|
|
|
