企画書の考え方

| Comments

ウチの会社では、何か新しい機能を実装する前に、それについての企画書を書きます。

「それがどう価値があるのか?」「どうやって作るつもりなのか?」を明確にするためのものです。

※ソフトウェア開発(受託開発でない)に特化していますが、他でも使えると思います。 また、あくまで個人の考えであって色々とツッコミどころがあるかもしれません。

ここでは、「営業用に、Dropboxみたいなツールがほしい」という要望が来たとします。

(「個人的に、あったらいいなと思った」でも、「上司から案件が振ってきた」でも構いません。)

まずは理想から考える

ここでいう理想とは、企画書を見る人(同僚・上司・お客さん)の全員で一致できるような方向性・思想のことです。

これは目指すゴールではありません。全然具体的でなく、どこまで行けば終わりかがわからないので。

理想を考える上で気をつけることは、できるだけ狭く定義することです。

「全て自動でやってくれる」とか言っても何の意味もありません。

かといって、

「特注DropBoxを作る」とまで具体的に言っても、求めてるものはそれではないかもしれません。 いわゆる、ドリルじゃなくて穴がほしい、という話です。

大きな例としては、「営業が効率的に受注できるようにする」とかでしょうか。

あるいは、ニーズそのまんまで「営業が効率的に情報共有できる」とかでもいいです。

次に、現実でそれを妨げている要因を探す。

事前に仮説を立てた上で、お客さんにヒアリングを行ったり、現状調査を行います。

その結果、

  • 支社などが地理的に離れている
  • 名刺や連絡先などのデータが個人のPCの中にしか入っていない。
  • アポの履歴が管理されていない
  • 今、誰がどこへ営業に行っているのかわからない。
  • 誰がどのくらい売り上げているかは自己申告になっている。

(普通はもっと細かいと思いますが・・・。)

それらの問題を解決できそうなアイデアを考える。

ここは特に発想が飛躍すると思います。論理的な流れではないので説明はしにくいですが。

自分の裁量や技術でいけそうなレベルをざっくり出します。

一般的な企画書はここから始まるのかもしれませんね。

ここでは例えば、

社内外から、顧客の連絡先・相手先の情報を自由に編集・表示できる

今、誰がどこを訪問しているかを記録する

取引先毎に現在の進捗が編集・閲覧できる。

などでしょうか。

どれだけメリットがあるのかを説明する。

その機能・アイデアが実現できたら、先ほどの問題がどう解消するのかを説明する。

例えば、

  • 担当が変わった場合でもスムーズに引き継げる。
  • 同じお客さんに訪問してしまうことがなくなる
  • どのくらい生産すればいいのかわかる
  • 大阪でも東京での売れ行きがわかり、社員の評価がしやすい

どう実装するのかを考える。

ここまでできれば、ゴールがだいぶ明確になっているので、 それを実現する機能の具体的な実装もイメージできるはずです。

自分の技術力的に難しすぎるのであれば、他の人を巻き込むなり、もう少し手前をゴールにしましょう。

スケジュールを考える。

省略。

Comments