Hatena::ブログ(Diary)

サンフランシスコ出羽守手記(masayangの日記 このページをアンテナに追加 RSSフィード

2007-12-13

[][]迷ったら狩野さん!...狩野分析法による優先度付け

追記

id:discypusさんから、狩野分析法の出典に関するコメントをいただきました。

狩野法って、

狩野 紀昭 氏 http://www.sangakuplaza.jp/page/134499

http://www.yahoo-vi.co.jp/method/b10.html の手法かと

思うのですが、合ってますでしょうか?

まさにこれですね。http://www.yahoo-vi.co.jp/method/b10.html にある日本語のほうがすっきりしてます。

お詫び

分析用配列に誤りがありました。修正してあります。

要旨

先日受講したScrum Product Owner Trainingで印象に残った分析法を紹介。

Agile開発では「優先度順に要件(フィーチャ)を開発していく」のが基本だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的に優先度を決めてくれるというのは理想的ではあるが、その指導者の能力がイマイチな場合にはリスクが増大する。

大抵は利害関係者間の調整で物事が決められることになるが、これも時間がかかる話でありAgile的ではない。変に決着をつけると、後々人間関係で尾を引くという問題もある。

かといって、「必要なものに○をつけてください」などとアンケートをとっても、全部に○がつくのがオチであろう。

狩野分析法は、優先順位がうまく付けられないときに有効な手法である。客観的なので、利害関係者も納得いきやすい。

二つの質問

まず対象となるフィーチャが実現された場合と、実現されなかった場合について5者択一の質問をする。こんな感じ。

  • ホテルの部屋に無料のミネラルウォーターがあったらどう思いますか?
    1. ◎とても嬉しい
    2.  それって普通でしょ
    3.  特になんとも思わない
    4.  別にそれでも構わない
    5.  それは困る
  • ホテルの部屋に無料のミネラルウォーターがなかったらどう思いますか?
    1.  とても嬉しい
    2. ◎それって普通でしょ
    3.  特になんとも思わない
    4.  別にそれでも構わない
    5.  それは困る

回答の分類

得られた回答から、そのフィーチャの属性を決める。具体的には下記行列に、回答をあてはめる。

 非実現時1非実現時2非実現時3非実現時4非実現時5
実現時1QEEEL
実現時2RIIIM
実現時3RIIIM
実現時4RIIIM
実現時5RRRRQ

ミネラルウォーターの例では、実現時=「1」、非実現時=「2」なので、分類は「E」となる。

その分類って何よ

こういうこと。

  • M...Mandatory(基本)
    • なくてはならないもの。外せないもの。
  • L...Linear(性能)
    • なくてもよいが、あればあるほど良い。
  • E...Exciter(魅力)
    • いわゆる差別化ポイント。
  • Q...Questionable(不明)
    • 回答がおかしい。
  • R...Reverse(逆行)
    • あっては困る。つまり作ってはいかん。
  • I...Indifferent(不問)
    • どうでもよい。作ってもいいが作らなくても良い。

例えば携帯電話で考えるとこうなる。

  • かつてはカメラ機能は「魅力」だった。
  • 今は画素数を競う「性能」もしくは、なくてはならない「基本」のどちらか。

分類したら集計する

この調査を利害関係者を相手に実施し、結果をまとめる。結果から、自ずと開発優先度は見えてくる。

  • M(基本)は、点数が高いものから順次開発していく
  • L(性能)は、点数が高いものから順にイタレーションに一フィーチャ」を目安に-取り込んでいくと良い
  • E(魅力)は、点数が高いものから順に「3イタレーションに一フィーチャ」を目安に取り込んでいくと良い
  • R(逆行)は、作ってはいけない。
  • I(不問)は、作る必要はない。

手間はかかるけど

狩野法は手間はかかるけど、関係者の主観や思惑抜きで要件(フィーチャ)の優先度が決まっていく所が合理的だと思った。

discypusdiscypus 2007/12/14 09:00 狩野法って、
狩野 紀昭 氏 http://www.sangakuplaza.jp/page/134499 の
http://www.yahoo-vi.co.jp/method/b10.html の手法かと
思うのですが、合ってますでしょうか?

masayangmasayang 2007/12/14 12:53 >>dyscypusさん

ご指摘ありがとうございます。
まさにこれです。

qualityquality 2008/04/22 11:57 まさか,一人からの回答だけで,意思決定するわけじゃないですよね.あなたの言う「狩野法」というのは,欠陥だらけの「魅力的品質論」に根ざしたものと思われます.狩野紀昭の原著論文を読むべきでしょう.欠陥が理解できなければ,あなた自身にも欠陥があると思ってください.

masayangmasayang 2008/04/22 12:39 >>EATcf-270p25.ppp15.odn.ne.jpから書いてきた人
集計して点数が高いものから...って書いてあるだろうに。

impressedimpressed 2008/04/30 12:13 >>quality さん
原著論文を読むべきって,さすが・・・
実は,あれって,欠陥あるっていうのを他の人も分かってるんですね.耳学問はやはり恐ろしいってことか!

PolynomialPolynomial 2009/06/29 05:13 かなり昔に書かれた記事に対して、たいへん恐縮とは存じますが、
quality さんのコメントを補足してみます。

回答者によって、一意的な解釈がなされないような質問は、よくありません。
回答者が「無料であること」に関心があるのか、あるいは
「(たとえば緑茶でなくて)ミネラルウォーターであること」に関心があるのか
回答者に対し、質問の意図を誤解されないように、注意が必要です。

一方「とても嬉しい」という気持ちも、回答者によって、一つとは限りません。
例えば「満足」と「歓喜」の違いを明確に区別する必要があります。

こうした品質論には、他にも、欠陥があるらしく、上記のような内容が、
"Obstacles to the creation of attractive quality" という論文に
詳しく書かれています (Thanks to Dr. A.O.)。

masayangmasayang 2009/06/29 12:24 >>Polynomialさん

コメントありがとうございます。学術的にはそういうものかもしれませんが、要求定義の現場では既に結構使われているようです。現場は完璧なものを待てないのです。

qualityquality 2009/08/14 10:52 要求定義と,狩野流の「品質分類論」とは,直接的にはほとんど関係ないですね.狩野は「要求」について語っていません.せいぜい,「品質要素」と「機能の有無」程度でしょう.
要求定義で最低限大事なことは「何をもって要求と見なすか」です.これが分らなければ,ずっと間違った要求を定義していくことになるんでしょう.Good luck!

masayangmasayang 2009/08/14 11:13 あーまたわかってない馬鹿がきた...

qualityquality 2009/08/15 11:36 ほー,「馬鹿がきた」とは失礼な.たぶん,おたくが,二番目に「馬鹿」なんじゃない?もちろん,一番目は狩野紀昭ですけど.
学問の場での馬鹿を「馬鹿」として明らかにしていくことが重要なので,現場の馬鹿はほっとくことにします.

ScrumScrum 2009/08/15 16:38 masayangさんのTwitterから来ました。たしかに粘着ですねこれは。

学問の場で正すのなら、せめて本名くらい晒したら?
匿名で批判するってことは、あなたの学説はろくなものではない、ってことでは?

qualityquality 2010/11/07 10:42 馬鹿は以下も勉強してみるとよいでしょう.
http://elsur.jpn.org/mt/cat25/

masayangmasayang 2010/11/07 12:00 anon proxy+tor使わないとコメントも書けないヘタレ