今回もドキュメントに関するお話です！
前回は、ドキュメントが残らない問題についてお話をさせていただきました。
ドキュメントと呼ばれるものは沢山あると思いますが、今回はその中でも、商談などで一番最初に作る資料「叩き台」について語りたいと思います。
たたき台って、話を進めるためには超重要なんですが、果たしてどんなところが重要なのか？
この辺いつものノリで語ります！
今回のテーマ「たたき台」について
今回のテーマは商談のときなどに使う「叩き台」ですが、やっぱり重要なポイントは・・
「5W1H」をきちんと伝える事。
これが最初の時点で伝わっていないと後で「聞いてないぞ」に発展します。
そしてプロジェクトが炎上したり、導入の手詰まりに繋がっていく訳です。
資料の美しさや体裁も重要だけど、とにかく5W1Hを意識して作る事はもっと大事！
今回のシナリオ
例えばこんなとき、たたき台は効果を発揮します。
ガチのシステム導入を例にしてストーリーを作ると、非エンジニアの方は解りにくいと思います。
なので、今回はシンプルに「ブログサイトを作ってほしい！」を例にして説明します。
もしあなたにこんな依頼が来たら
例えば、ある人がブログをはじめたいと思い付きました。
でも、「はてなブログ」のようなものじゃなく、完全オリジナルなサイトで作りたい。
でもどうやっていいか解らないどうしよう・・・
あっそうだ！どこかにブログサイトの構築を頼もう！
そして、この人からあなたへ依頼が来ました。さぁどうやって進めていきましょう？
まずは例を提示する
この時点で、依頼者はどうして良いか解りません。なので最初は紹介資料のような「例」を出すのが一般的です。
例えば以下のように「こんな事ができます」を絵にします。
いまどきは、リモート会議がかなり主流になってるので、文字よりも、絵や実物で見せる方が好まれます。
まずはこんな感じで「何ができる？」を理解してもらいましょう。
重要なポイントその１
最初の例はできるだけシンプルに表現する事が大事です。
メリットばかりをひたすら盛り込んだ資料になると、肝心の導入イメージがボヤけてしまいます。
実は契約前だと、案件をとるために、地に足の付いていない提案をする業者が非常に多いんです。
このようなやり方は、現場の担当者が相手だと信用されない傾向があります。
提案して、その場では盛り上がったけど結局話が進まなかった・・なんてよく聞きませんか？
こういう場合って、もしかしたら提案が現実的でない事を見破られていて、相手にされてない可能性があります。
依頼者の業務フローと、導入したときのイメージを、この段階でどれだけリンクさせられるかがポイントです。
叩き台に依頼者の要望を追加
次は最初の例に、FIXとなった要望のイメージを盛り込んでいきます。
ただし載せるのは、出来るという確証が取れてるものだけにしてください。
重要なポイントその２
ここで重要なポイントは、これがエビデンスにもなるという事。
とりあえず進める・・というやり方でやってしまうと「なんだそれ聞いてない」が飛び交う傾向があります。
まず要望を絵にする事で、明確化して、後に発生しうる「聞いてない」を防止します。
・・それでも「なんだそれ聞いてない」「どうしてこうなった？」になってしまう事はあります。
でもそんなとき、こういう叩き台があると「初回でこのように決めました」・・とエビデンスとして提示する事ができるんです。
要望がFIXできたら？
次は作業範囲の線引きをします。皆様もご存じの通り、日本は丸投げ文化が主流です。
依頼者は、こちらから宣言しない限り、何もかも全部やってくれると思っています。
なので、依頼者がやる事と、自分が作業として請け負えるものを資料で明確にしましょう。
※今回はざっくりこんな感じ
最近は、複数の会社を使って１つのものを作り上げるケースが多いので、初期段階での作業範囲の定義はかなり重要です。
さらに重要なのは、これが受注前に定義できてる事！
受注前にこの辺りの認識があっていないと、後に高確率で作業範囲でもめます。
これが定義できると、作業ボリュームが見えるので適切な見積りが作れます。
そして、依頼者側も具体的な導入時のイメージを頭の中で描けるので、安心感から受注確度があがるときがあります。
私の経験では、受注前でも導入内容と範囲をしっかり定義すると、結果的によくなる事が多かったです。
重要なポイント３
ここで、特に重要なポイントは「誰が」「どのように」の明確化です。
実は、ここを曖昧にしたまま進める会社って結構多かったりします
曖昧になる原因の多くは、提案段階では「誰がなにをすればよいか」調整しない人が多いからです。
お客は現時点で何も言わないし、そこは現場が受注後調整すれば良いだろう・・とにかく受注！受注が優先！
・・みたいな文化の会社が実はめっちゃ多いんですね。
作業内容を知らないと、当然作業範囲の線引きなんか定義できません。
結果、作業範囲で揉めます。例え対応出来ない作業だっとしても「とにかくやれ」と依頼者は言い続ける事でしょう。
提案は、現場と依頼者側に確認をして作業範囲を定め、関係者に共通認識を持ってもらう等のコントロールも必要です。
ちなみに作業範囲は、営業と技術間でコミュニケーションエラーが発生する事が多く、これもよく対立の原因となっています。
課題管理
商談のタイミングで課題管理を使って、商談を成功に結び付ける作戦もあります。
導入前の懸念点などを事前にうまく解決してあげれると、信頼を得られて一体感が生まれます。
逆に、マイナス要素を隠し続けグレーなまま進めるのはNG。このツケはいつかどこかで回ってきます。
後で解約の要因にもつながるリスクもあります。
最後に
今回は商談などで「叩き台」をどう活用していくかをお話ししましたが、いかがでしたでしょうか。
実は叩き台にも「粒度」があって、大きな案件では、以下リンク先並みの叩き台を作れ！って言われる場合があるかもしれません。
農林水産省 動物検疫支援システム オンライン連携機能構築 システム要件定義書
でも、今はクラウドが使われてるおかげで、ハードウェア、ソフトウェア、開発、すべて提案するケースは少ないです。
なので、ここまで幅広い資料を求められる事は、今はあんまり無いかもしれません。
まぁ・・こんなレベルで書いたら逆に読まれない可能性もあります・・。
私の経験では、今回話した要点が整理されてれば、多少ラフな資料でも結構通用してます。
逆に内容をたくさん盛り込んで話を難しくすると、伝えるべき事が伝わらないかもしれません。
なので、よくあるテンプレを使わず、臨機応変に作る方が今時は良い気がします。
今回は以上です！最後まで読んでくれてありがとう！
