要件定義フレームワークを使う
私の今のお仕事は、ひとつのインスタンスを複数のユーザが利用する「ASPサービス」の保守・運用・開発です。
ですが、最近はこの「共用仕様」に飽き足らないお客様のために、個別にインスタンスを立ててカスタマイズする案件が複数並行しています。
そういうわけで、最近は営業やユーザからのヒアリング内容をうまくまとめて、「要件定義」として記述するという作業シーンが多くなっています。
—
そもそも要件定義って、みなさんどうしていますか？プロジェクトが終わった後で、
「要件定義があいまいだったために、多数手戻りが発生した」
なんて反省をしていませんか？
私見ですが、要件定義が失敗しやすい理由としては、
- ユーザからのヒアリングが上手にできない（対機械の作業ではなく、対人間での「情報を引き出す力」が問題）
- スケジュールがタイトで、気づいたら要件定義のフェーズを終了させられた。（まだできてないってば。）
- そもそもユーザ自身が自分でニーズを分かっていない（引き出せないから、書きようがない。あと出しされる）
- というか、そもそも自分自身が要件定義の書き方をよくわかってない（すみません。）
なんて感じではないでしょうか。ちなみにこれらは全て私の実体験なんですけどね。
—
さまざまなやり方や書き方があると思うのですが、私は、RDRAという要件定義のフレームワークをベースに書いています。
RDRA(Relationship Driven Requirement Analysis)
こちらのページにいくと、Enterprise Architectのテンプレートがダウンロードできます。
（うちは、このEnterprise Architectが標準の設計ツールです。）
RDRAの作者が書いた「顧客の要求を確実に仕様にできる要件定義マニュアル」を買ってもよいのですが、無料でダウンロードできるテンプレートの「メニュー」「レビュー」の内容を読む（見る？）だけでも結構いい感じです。
ただ、全部まじめにやろうとすると、「気付いたら要件定義のフェーズを終了させられた」コースに乗ってしまうので、
自分でこの中から書くべき部分をしっかり選ぶことが大事ではないでしょうか。そもそも、「書けないものは書けない」と自覚することが大事です。また、このあとアジャイルな開発手法を用いて不足分をコミュニケートしながら補っていく、なんていう方法もありでしょう。
—
- 全体像が見えてこない
- 顧客との打ち合わせをリードできない
- まとまらない会議
- シーズ中心
- 議論がすぐ袋小路に入る
みなさんには思い当たる節がありますか？詳細はＰＤＦをダウンロードして読んでみてください。
また、「顧客の要求を確実に仕様にできる要件定義マニュアル」では、それぞれの分析シーンでの失敗パターンや成功へのプラクティスが書いてあります。この本はお薦めで、私も持っています。一度買って読んでみるのもよいでしょう。（私はamazonや神崎さんの回し者ではありません。）
こんにちは神崎です。
ご無沙汰しています。
RDRAのサイト（http://k-method.jp/）でRDRAを活用されている方のサイトをリンクすることになりました。
ついてはこの記事をリンクしてもよいでしょうか。
率直な意見が書かれているので初心者の方に参考になると思います。
いかがでしょう？
神崎さん、こんにちは。
リンクの件、了解です。ぜひ、よろしくお願いします。
神崎さんのブログは時々拝見しています。
また遊びに行きますので、引き続き、よろしくお願いします。
神崎です。
快諾ありがとうございます。
ブログはなかなか書けなくて困ってます。
プログラムを書くのは好きなのですが、どうも文章が苦手で…