ayumu_aoの日記

SIerから事業会社に転職したエンジニアが技術についてや組織論、本の話、今までの体験談などなどを個人的に垂れ流しています。

要求定義ってなにするの?

要求定義ってなにするの?

要求定義とは

やりたいことを明確にする事です。

  • 誰に
  • なにを
  • どうしてもらうのか? or 提供するのか?
  • いくら儲けたいのか

これはよく言うことなのですが、要求定義は詳細の機能の話などはせずにこのプロダクトをどうしたいのかを定義するフェーズだと考えてゴールを明確にします。

間違ってる要求定義・要件定義

上に書いたのですが、こういう機能がほしい・こんな感じの見た目で!などの細部の話からはじめてしまうのが一番まずい状態です(体験談)

なぜ細部から話してはいけないのか

それは、細部から話して進めていくとある程度開発したあとに(ないしは終盤で)「さあ、できてきたぞー。どれどれ」と全体像をみたときに

「思っていたものと全然違う!」ということが往々にして発生するからです。

細部をそれぞれ確認するとたしかに最初に出した要求通りなのですが、全体を俯瞰してみるとチグハグだったりなんとなくコレジャナイ感というのが出てきます。

それは最初に全体像の話をしていないまま進めたため全員の中にある全体像が少しづつ違ってくるから発生する事件です。

こうならないために、最初に全体像としてのゴールを決めてしまうことが大切になります。

ではどのように要求定義をするのがおすすめかというと

こんなテンプレートがおすすめ

個人的なおすすめはリーンキャンバスになります。

これは「書類とか苦手なんだよなーでも企画を考えたからつくりたいんだよなー」って人にも書きやすいのでおすすめです。

なんといっても箇条書きですむのですから(笑)

↓リーンキャンバス f:id:pergere:20170914152015p:plain

  • 課題⇒解決したい課題や、やりたいこと
  • ソリューション⇒作るもの
  • 主要指標⇒KPIの指標
  • 独自の価値提案⇒独自の価値を出すための案
  • 圧倒的な優位性⇒強豪などに対する優位性
  • チャネル⇒顧客の流入経路・導線
  • 顧客セグメント⇒ターゲット
  • コスト構造⇒コスト(開発工数、デザイン工数、要件調整工数など)
  • 収益の流れ⇒収益モデルや見込収益、売上など

といったものが一通り揃っているので漏れが発生しづらいです。

また、これを作成するときは一人でやる必要はないのもポイントです。

以前にこれを勉強がてら導入した際は2〜3人程度で2時間程度話しあって作成し、また後日それを見て大丈夫そうかのチェックなどをおこなったりしましたがその時のプロジェクトはうまくできたと思っています。

まとめ

個人的には要求定義の出来がプロダクト・プロジェクトの出来を握っていると考えています。

昨今の流行は開発技術によりがちですが、それを活かすためにも上流工程をいかに整えるのかも身につけることが大切だと考えています。

要求定義というかビジネスに必要な考え方とかの参考にした本

ビジネスモデル・ジェネレーション ビジネスモデル設計書

ビジネスモデル・ジェネレーション ビジネスモデル設計書