 |
|
|
|
前のページ 1 2 3 次のページ
|
|
| 「定義」ではなく「開発」
|
ここで、「要求定義」や「要件定義」ではなく、なぜ「要求開発」と呼ぶのかを考えてみましょう。「定義」という言葉を使ってしまうと、いかにも「要求」や「要件」がすでにクライアント側でしっかりと確立されていて、それを開発チームに「このように作ってください」と伝えるだけのようなニュアンスであると筆者は感じています。
まさに、今までSIベンダーに代表されるシステム開発者が、お客様の要求に向き合ったときにとってきた受動的な姿勢をそのまま象徴している言葉だという印象があります。そうではなくて、本来の要求とはシステム開発者であっても、お客様と一緒に業務の改善から考えて、一緒に作り上げていくもです。「開発」という言葉には、そういう能動的な意味が込められています。
開発者が要求に向き合うときのパラダイムを根本から変えていきたいのであれば、まずは言葉から変えるべきではないかということです。そこで、筆者が参加している「要求開発アライアンス（ReDA）」の発足メンバーたちは「要求開発」と呼ぶことにしたわけです。「開発」という言葉を使うことで、「システム開発者側もお客さまの側にさらに一歩踏み込んでいこう」という姿勢に変えていこうという想いがこめられています。
もともと欧米では「Requirements Development」という言葉が要求工学の世界で使われていましたが、日本では一般的にあまり使われていませんでした。「要求開発アライアンス（ReDA）」は、もともとビジネスモデリングを考える研究会からスタートしたものです。ただ、活動を続けていく中でビジネスモデリングの品質を向上するためには、もっとクライアントの業務の戦略からきちんとビジネスの要求を識別したり、そこからITの要求を導き出したりというプロセス、つまり正しい要求を導き出す手法の確立が必要だということに気づかされました。そこから「要求開発」というコンセプトが生まれたわけです。
|
| 信頼を築く
|
では、なぜ「要求開発」という考え方が今まで浸透してこなかったかというと、システム開発業界の契約スタイルや商習慣が大きな原因の１つだと思います。システム開発の主作業を担うのはSIベンダーである場合が多いのですが、SIベンダーというのは、「顧客からでてきた要件定義に対して請け負う」というスタイルでこれまでやってきたように思います。だから、お客様と一緒に要求を正しくしていこうという発想になりづらいのです。
逆に余計なことを提案して要件が膨らんだり仕様が変わったりしたら、自分たちがリスクを負わなければならないので、なるべく要件は変えたくない。あるいは、「要件が膨らむことによって、自分たちの工数が増えてしまうのは嫌だ」とか、守りに入ってしまう。そのような契約でやっている限り、どうしても一緒に要求を開発していきましょうという攻めの姿勢にはなりません。
ただし、そんな中でも自分で創意工夫をする人はしています。「お客様にはこのようにいわれたけど、よく考えてみたらもっとこうした方が良いんじゃないか」と考える人もベンダー側にも当然いるわけで、このようなアイデアが浮かんだら積極的にお客様に相談して要求をもっとよいものに変えていくことでもっとよいシステムができる可能性が高まります。今後SIベンダーがこのような意識を全面的に打ち出していくことが、業界のさらなる発展のためには必要ではないかと感じています。
一方で発注者側の意識も変えていく必要があります。開発途中であってもベンダーからの良い提案があればそれを積極的に取り入れ、その結果もっと費用がかかるのであれば、追加の費用を払ってでも自社のためによいのだからやろうという意識がないかぎり、ベンダー側がいくら頑張ろうとしても要求開発には取り組めません。クライアントとベンダーがお互いを信頼して「一緒に良いシステムを作っていこう」という関係にならないと、要求開発を実行するのはなかなか難しいと思います。
|
前のページ 1 2 3 次のページ
|
|
|
|
|
著者プロフィール
ウルシステムズ株式会社 河野 正幸
山口大学経済学部経済学科卒業後、SIerにて製造業向けシステム開発プロジェクトマネジャーとして従事。2002年8月から現職。得意な分野として、オブジェクト指向分析／設計、開発方法論、プロジェクトマネジメント、製造業の業務などがある。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
