「上流工程で成功する人、つまずく人」 [提案・要件開発]
本書でも書かれていますが要求・要件について
「ユーザーが決めてくれない」
「ユーザーがはっきりしない」
と”ユーザーが決めて”くれる”ものと考えている方はつまずく人に入ります。
そもそもユーザーは要求をまとめたり仕様化する(=要件)ことを本業とはしていません。基本的に要求・要件を決めて”くれる”と期待するのは無理なのです。
ではそうした要求・要件を決める能力を持つべきなのは誰なのか?それはそれを必要とする人、それを生業とする人、つまり(IT)ベンダー側となります。
このように要求・要件はユーザーは決められないものだ、ITベンダーが「開発」していくものだとしているのがOpenThologyの要求開発。上流工程で成功するためには要求開発のような考え方が必要だと思います。
また、ユーザーの要求・要件をまとめる上で参考になるのがコンサルティングファームが活用している手法ではないでしょうか。そんな理由からこのブログではコンサルティングに関する書籍を取り上げることが多くなっています(例えば『マッキンゼーのテクニックを盗め』)。
『要求仕様のまとめ方』、『ソフトウェア要求』なども参考になります。
さらにBPMなども活用するとよりよいのではないかと最近は思っています。
「ユーザーが決めてくれない」
「ユーザーがはっきりしない」
と”ユーザーが決めて”くれる”ものと考えている方はつまずく人に入ります。
そもそもユーザーは要求をまとめたり仕様化する(=要件)ことを本業とはしていません。基本的に要求・要件を決めて”くれる”と期待するのは無理なのです。
ではそうした要求・要件を決める能力を持つべきなのは誰なのか?それはそれを必要とする人、それを生業とする人、つまり(IT)ベンダー側となります。
このように要求・要件はユーザーは決められないものだ、ITベンダーが「開発」していくものだとしているのがOpenThologyの要求開発。上流工程で成功するためには要求開発のような考え方が必要だと思います。
また、ユーザーの要求・要件をまとめる上で参考になるのがコンサルティングファームが活用している手法ではないでしょうか。そんな理由からこのブログではコンサルティングに関する書籍を取り上げることが多くなっています(例えば『マッキンゼーのテクニックを盗め』)。
『要求仕様のまとめ方』、『ソフトウェア要求』なども参考になります。
さらにBPMなども活用するとよりよいのではないかと最近は思っています。
コメント 0