エンドユーザーの要求は間違っている？
ムラウチドットコムの橋本昌巳氏（取締役システム担当）は，自社のECサイトの構築で，かつて次のような経験をした。 ある業務担当者に新機能が欲しいと言われて開発した。しかし，その機能を使うのはその人だけで，他の人は使わない。業務改善に寄与したかどうかも結局，分からなかった。担当者が異動すると，また「違うものを作ってくれ」という要求が出てきた。要求通りの機能を追加するうちにシステムはどんどん複雑化し，保守性が悪くなった。改修のコストも徐々にかさむようになってしまった…。 。 現場を取材していると，こうした要求定義（注1）にまつわる話は事欠かない（図1）。IPA（情報処理推進機構）のアンケート調査（注2）によると，9割の企業が「失敗プロジェクトの原因は要求定義にある」と考えている。野村総合研究所の堀崎修一氏（ITアーキテクチャーコンサルティング部 主任テクニカルエンジニア）は「業務要件の詰めの甘さ
要求開発でマインドマップを活用する(1)---参加型意思決定にぴったりのツール
要求開発の難しさは，「要求」という「柔らかいもの」を作り出すプロセスを定義することにある。後工程に当たるソフトウエア開発でさえ，現在確固たるエンジニアリング・プロセスが確立されているとは言い難い状況のなかで，それよりもさらに「ソフト」な要求を開発しようとしているのである。そう簡単には問屋が卸さないのもうなずけるだろう。 要求開発の成果物である「要求」は，世の中にまだ全く同じものが1つも存在しない，という状況のなかで開発が始まる。それを作り出すプロセスを完全に定義するのは無理と言える。しかし，何らかの手順や，過去の同種の問題解決においてうまくいった例などの「ベスト・プラクティス」と呼ばれるものを参考にすれば，「なんとかやれるだろう」という程度には手ごたえのある「プロセスらしきもの」を抽出できるかもしれない。要求開発アライアンスでは，これを「プロセス・キャビネット」と呼ぶ。そこに賢人の知恵，過
いまさら聞けない要求管理の基本
なぜ、要求を管理する必要があるのか なぜ、要求を管理するのでしょうか？ 一言でいうと、要求を管理することが、プロジェクトの成功を大きく左右するからです。まず、一般的なプロジェクトのゴールを考えてみましょう。次のような定義を見てください。 「顧客の真のニーズを満たす」「高品質」「期間内」「予算内」という4つのキーワードが出てきますが、どれも要求管理と大きくかかわってきます。まず、「高品質」な製品を作るためには、要求管理において、信頼性やスループットといった製品の機能面以外の要求も確実に把握することが重要です。また、「期間内」「予算内」で製品を開発するには何が問題でしょうか？ プロジェクトは、時間と予算とリソースが制限された状態で製品を開発しなければなりません。与えられた時間、予算、リソースを用いてどれくらいの作業ができるか考慮して、製品の要求仕様の範囲を、作業が可能である範囲に抑えねばならな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
必修講座100 ＜ ITpro SkillUP ： ITpro
要求工学:Requirements Engineering(月刊ビジネスコミュニケーション)
