トクメイキボウ

(33歳/会社員)

カレーライスが食べたい

こんにちは、トクメイキボウです。

 

仕事してて思った事

 

要件定義を行う際は要件定義の限界がある。

あなたの欲しいものは、私にはわからない。

だからわかる言葉で記録しますね 

→これが要件定義であり、要件定義書となる。

 

お仕事で、システムを構築するときに、その無限の要件を定義することができないため、概念から少しずつ工程に従い定義していく。要件定義の限界とは、ほしいものを言葉や図で表現しきれない事だと思う。

 

カレーライスを作って欲しい。

→これは要件か?

カレーライスという共通認識があって初めて要件になりうる。しかし、後から、ユーザーに注文したはずだと言われないためにも、共通認識というレベルで終わらせてはいけない。

 

あなたのカレーライスは、私のいうところのカレーライスか確認させて欲しいと、突っ込むべきだと思う。

カレーライスは、カレーとライスで構成されている事を定義する。知識のある人なら、見えていない要望として福神漬けは、必要かどうかを聞き出す。

 

また、食べるシーンも想定して、器、スプーン、水、ナプキンなども隠されたニーズとして存在している事を忘れてはならないと思う。

 

作るもの

  • カレー
  • ライス
  • 福神漬け

用意するもの

  • スプーン
  • ナプキン

大きな方針はこんなところだろうか。
 

はて、ユーザーは立ったまま食べるんか?器は手に持ったままか。このレベルの問いは際限ないため、提供しないものも念押ししておく。

  • 椅子、机はじぶんの物を使ってね
  • 辛い調味料などは含まれず、別途有料になるからね

ものづくりなら、ここの程度にしたい。

 

これで要件定義完成か?

この程度で進められたら世界は平和だと思う。
システムの世界だと恐ろしいことにこれ以上の細かい定義とちんぷんかんぷんな説明を求められる。

 

「ライスと定義書に記載があるが、ライスとは米ですか?」

「米と言うのは、炊いたものでも固いままでもいいでしょうか?」

「米はありませんが、コシヒカリならあります。」

「カレーはありませんが、ビーフシチューが近いので代替します。」

 

話をしていくと更に、気になるところはいろいろでてくる。

  • いつ食べる?
  • 食べる量は?
  • 味は辛口?甘口?
  • ルーはかけていいの?セパレート?
  • 具は?
  • and so on...

これらは、フレームワークなどを利用して聞くべき一覧を用意しておき、もれなく聞き出す。普通の茶色のカレーをイメージしていたけど、ドライカレーでしたわ、グリーンカレーでしたわとならないように。

 

アレルギーなどのリスクの観点も忘れてはいけない。

  • エビカニは食べれない

カレーライスを作って欲しい。から深掘りして、要件がちらかった。

面倒なのでこの件はここまでにする。

何がいいたかったかというと、そもそも「カレーライス」というものを知らない人では、「あなたの欲しいものは、私にはわからない。」というスタンスになるため、要件を切り刻んでヒアリングを繰り返すも「カレーライス」にたどり着かない。
作るものを明確にしたら、ここから先はこちらのさじ加減で作るからテストで細かいところを確認してねと後続工程に送るしか無いのか。
 

共通認識を持てない前提で、要件定義はできないんじゃないかな。

 

 

 

今まさに、こういう現場で揉めている。
某ベンダーの魂が抜け、担当者も変わり、何を作っているかわからない状態。 

 

じゃあどうすりゃいいのか。

カレーライス屋さん揉めないのは、カレーライス屋さんがカレーを売っていて客がそれを選びにくる。システムでいうとある程度出来ているパッケージシステムを買うこと。

私はパッケージ推進派

 

 

金払えばなんでもオーダーメード型で作りますという料理屋はない。ハマれはピカイチなんだろうけど失敗リスクが高すぎて、私はココイチのカレーでいいかなと思う。