仕事が定義できなければその仕事は請け負えません

提案書って作ったことありますか。
では、その提案書をレビューしたことはありますか。

どっちが大変かワタシの感覚から言うと、提案書を作るより提案書をレビューするほうが大変と思います。

提案書を作る人は、営業、技術のそれぞれに人がいるものなので提案ごとにチームを明示的に作ったり、なんとなく集められて提案活動をしたりします。どっちにしても提案書を提出する締め切りがあるもので、その目標の日程に向かって活動をするので提案チームは提案チームで高揚しながら締め切りに追いかけられながら死にます。あ、死なずにゾンビになりかけながら提案書を取り繕います。

レビューする側はそれを遺品を裏返してみたり、ひっくり返してみたりしながら検分するわけです。

なにせ、提案チームは勢いで作っていますからね。進行が追いついていないアニメ制作スタジオのようなものです。気を抜いて流してしまうとずっぽりと肝心なことが抜けていたり、矛盾があったり、実現性の有るか無いかわからないことを書いてあったり。

請け負えるかどうか
提案すると言うことは提案要請に対してその仕事を請け負えると明らかにすることです。提案要請された仕事を請け負えるということは、その要請された「仕事が何であるかを定義できる」ということです。でなければ、仕事が何であるかがわかっていないことになります。

「仕事を定義できる」があって、それを実現できる技術を持っていて、かつ、実現するまでのリソースを確保できる。

これが成立して初めて提案できるんですよ。

ところが、提案書を見ると何を仕事として定義したかがわからない状態の提案を持ってくるケースがあるんですね。こっちとしては、「で、何んで請け負えるのよ」と聴きたいわけです。

仕事が定義できて、それを実現できる技術を持っていて、かつ、実現するためのリソースを確保できる見通しがたつから初めて請け負えるんです。でなければ、危なくて提案なんてできやしないです。

そうそう、仕事の定義　＝　提案する技術仕様です。それとどこまでカバーするかの作業の範囲。これがあって仕事が定義できます。その仕様の裏づけが実現できる技術です。ただ、いくら仕事を定義できて、実現できる技術を持っていても、実行するためのリソースが無ければ実現できないですよね。そうしたリソースのスキームを作ることも大事なポイントです。

前に書きましたが提案チームは必死に作ってきた提案書ですが、そうしたセオリーを押さえて提案書を作ってくれている提案チームは希少です。

レビューをする側はそれを意識してみてあげないといけない。提案書の実現性の検証の一番簡単な方法は、その提案書のプロジェクトを自分がプロマネできるかどうかという観点で接することでしょうねぇ。

レビューという検証とはいえ、採用されたら誰かがその提案プロジェクトをキャリーすることになるのですから。最悪、「お前がやれ」といわれかねないですし。