ふつうの商品と違い、モノもない、値段もないモノを売るシステム開発。
こんなのが欲しいって言われたけど、いったいどうやって進めて、どうやって受注すりゃいいのよ？！
みたいな、初めてシステム営業をやる方、初めてシステム受注する方などにざっくり仕事の流れを把握していただくためのメモ。
はじめに。この流れにあてはまるシチュエーション
いわゆる「システム開発の受託」ちょい手前ぐらいの話。
テンプレのホームページ制作から、ちょっとしたプログラムの入ったサイト制作など、
- ざっくりアンダー200万円以下
- 2～3人のチームで、納品まで3～5か月以内でサクっと終わるぐらい
の小規模案件の営業・受注のシチュエーションを想像して書いています。
（それ以上はまた流れが違うと思われる。たとえば広告代理店がいて二次請け三次請けがいて…みたいな開発とか）
こんな規模のお仕事を受けているところ、または今から受けようと思っている新人の方には、
ざっくり「へー、システムってこんな感じで仕事が進むんだー」と思ってもらえると思います。
下準備編、見積～発注まで編、制作・納品・請求編の３パートに分かれて説明しますが、記事ボリューム的には
下準備編＞＞＞＞見積～発注まで編＞制作・納品・請求編
ですね。下準備編が一番長いのはやはり、なにごとも準備が大切っということか。
では、じっさいに流れを解説していきます。
【下準備編】
【下準備編】① なによりも最初にやるのは、己を知ること
いきなりアレですが、システムの営業に行く行かない以前に、ざっくりとまず己を知っておく。
すなわち、会社としてそもそも、どうやって仕事を取ってくるの？っという方向性を把握しておくことが必要です。
自分達がパッケージ商品（カスタムNG～ある程度出来ててカスタムOK）を中心にビジネスをしているのか、フルオーダーのカスタム中心で受けてるのか。
社内のMaxリソースはどれぐらいか。あるいは技術レベル的にはどのぐらいか。
そしてどこまで内製（社内で制作）でどこから外注（社外の制作会社）を使うのか…etc.
あなたの活動が無駄足にならないためにも、
会社として、どんな仕事なら受託が出来るのかを、知っておく。
とりあえず話だけは聞きに行ってもイイじゃん？という意見もアリだし、
何かのついでにじゃあ話だけ～っというならまったく問題ないが、
ちゃんとセールスとして人が動けば会社のカネがかかることになる。
そもそもウチの会社は紹介以外での受託は受けないよ、とか、逆に
●●万円以下の案件は受けないよっというところもあったりして、そういう場合、
せっかくお金をもらえる話になりかけても実らない。収穫できない。
最低限どういうカンジの案件なら受けてもOKかは把握しておこう。
で、そのレンジに収まらないなら話だけゆる～く聞いて受け流しておくなり、ちゃんと断るなりする、と。
【下準備編】② 提案の方向性を考えよう
では次。
会社がどういった方向での商売をしているか、というところが把握できたら、
いきなりGO！ではなく、次にどういった提案、つまり最終的にはどういう形で仕事を獲って来るべきか、イメージする。
つまり、パッケージ商品を売っているなら最終的にパッケージを使ってもらうように提案すべきだし、
フルカスタムならお客さんの予算とか納期とか、あとぶっちゃけ最低限のライン何ができないとダメなのかあたりをきっちり聞いておきつつ、落としどころというのを頭に描いておく。
実際にはいわゆるヒアリングと要件定義ってヤツで“落としどころ”は決めるのだが、
そもそもどの穴に落とすかがイメージ出来ていないと、要件定義はきわめて難しいと思う。。
経験が長い人や要件定義の上手い人は、お客さんに合わせて落としどころを都度作っているように見えるが、
経験でもう既にいくつかのパターンの穴を持っていて、つねに落としどころをイメージできていているのだと思う。
A、パッケージがある（定型の商品がある）とき
お客さんのやりたいことを聞いてみて、こっちが売れるパッケージにうまく落とし込むように提案するといい。
例えば「ホームページ格安制作5Pプラン」みたいな定型の商品を持っているとしたら、
色々要望を聞きつつ、なんだかんだうまいことその「ホームページ格安制作5Pプラン」をお勧めして、買ってもらう。
提案の流れ例）
お客さん：
「ホームページで商品売りたいと思ってるんだけど、ほらあの楽天とかみたいに、ネットでクリックして買えるやつ。あるでしょ。あれがいい。
……え？今？…今はホームページも無いんだよね～。
タダでできるページ作ってみようかなと思ったけど、シロウトっぽいページも嫌じゃない？
だからまあ安くてキレイでとりあえずスマホでも見られるページが良くて」われわれ：
「あぁ～確かにお客様の商品であれば、通販サイトがピッタリですね。
ただ、今まったくネットでの集客を行っていらっしゃらないなら、
まずはホームページを持つところから始められると良いと思います。
ネットで見て来ましたって人がそこそこ増えてから、通販ができるサイトへとステップアップされるのもありですよ。
たとえば弊社であれば、最低で15万円～ホームページが制作できるプランがありますが、…」
こんな感じ。
流れとしては、
- 話をいただく（問い合わせ）
- 具体的にどんなことがしたいのか、尋ねる（ヒアリングフェーズ）
- 希望に沿うような、自社の商品をお勧めする
- 商品を購入＆契約
- 商品のテンプレに沿って制作、納品
- 請求してお金ゲット
以上。とてもシンプル。
定型商品の場合は売る方も買う方も分かりやすいが、テンプレを改造出来ないとか、その分制約がきついので、
そこらへんはちゃんと説明責任を果たしておく。
B、フルオーダーでやるとき
最初に言うが、このパターン、難しい。やはりそれなりの経験が必要だと思います。
というのは、フルオーダーでシステムを作るということは、客先の業務を理解した上で提案・制作する必要があるので、ある程度色々な業務を見聞きした経験が提案力に影響してきます。
とはいえ提案しないといけないときもあるので、ひとつコツがあるとすれば、今世の中にある何かのシステムを、相手と共有すること。
メール配信のしくみ？Googleカレンダー？
出来合いのものでイメージに近いものをあげつつ、いわゆる「要件」というものを、お客さんとの対話の中で吸い上げていきます。
つまり、何を目的にしてシステムを作りたくて（今何が不都合/不便で）、システムを作ることで何を実現したいのか。
最低限、作ったシステムでは何が出来ていないといけないのか。
パッケージでもちゃんと聞かないといいモノは出来ないが、フルオーダーはより丁寧にそのあたりを聞かないと始まりません。このシステムに必要な要件を定義するというステップが大事。
とはいえ、お客さんのやりたいことって、大概はふわっとしてる（※要件がまったく固まってない）うえ、
イチから作るといえど実際には世の中のどこかには参考に出来る、似たサイトなりシステムなりがあります。
話をするときには、実際にさわって見て、イメージがつかめる具体物があると
双方ともにスムーズなコミュニケーションが出来るので、
まずは要望をふんふんと聞きながら、取っ掛かりとなる何か似たサイトなりシステムなりを探ると良いかも。
流れはお客さんの話を聞いて提案、というか企画をするところからスタートすることが多いです。
- 話をいただく（問い合わせ）
- 具体的にどんなことがしたいのか、尋ねる（ヒアリング/要件定義）
- 希望をどうやって叶えるのか、たとえばWEBサイトを作るのか通販サイトを作るのか、を決めて、提案する。※お客さんの要望がふわっとしているほど、企画してから提案に行くことになる。 （企画・提案）
- 提案のフィードバックをもらい、必要に応じて再提案（企画・提案/コンペのことも）
- 企画・提案内容に合意したら、契約（業務委託契約、システム開発契約）
- 設計＆フィードバック＆修正（設計）
- 制作＆フィードバック＆修正（制作）
- 納品（納品・検収）
- 請求してお金ゲット
- その後も継続して面倒見るなら、保守（運用・保守）
パッケージの有る無しで、お客さんに尋ねる内容は変わる！
パッケージ商品を最終的に買っていただくのであれば、パッケージを購入するためにセールストークを繰り広げるとともに、パッケージ商品で制作するために必要な項目だけ訪ねていけばいい。
たとえばテンプレートから選べるホームページ制作だったら、タイトルとテンプレートのNoと…みたいな感じ。
これに対しフルオーダーではそういう訳にいかないので、どんなイメージのサイトにしていきたいのか、何をするのか、じっくりヒアリングすることになる。
【見積～発注まで編】
発注書（お客さんが「この内容でいくらいくらカネを払うから作ってくれ！」という注文書）を回収するまでは、いわゆる「プレセールス」「営業活動」と呼ばれ、「案件」になる前の企画段階ととらえます。
お客様のやりたいことを、具体的な制作物に落とし込み（提案と見積）、
発注書を回収できてはじめて、システム開発としては「案件」と扱います。
【見積～発注まで編】①見積～発注書回収までの流れ
まずは、お客様がどんなことがしたいのかを確認し（ヒアリング）
それをどうやって実現するかを、お客様に提案し（アポイント、提案＆概算見積もり作成）
お客様と具体的な内容をつめ、制作内容を確認の上、正式な見積もりをお客様に提出（見積書作成）
お客様が内容と金額に納得されたら、発注書に捺印。（発注の成立/発注書の回収）
金額が小さいときはそうそう問題にはならないが、とくに金額がそこそこ大きい場合や、納品後にも継続的にお金をいただくような場合には注意。
見積段階でかならず「納品月の翌月より別途月額費用として◎◎円が発生します。」など、書面であとから証拠になるように伝えておくこと。
必要に応じて「業務委託契約」（制作物を作ることを、お客様→開発会社に委託しますという契約書） 、「保守契約」（制作したものを、お客様にかわって開発会社が面倒を見ますという契約書）などの契約を交わしてください。
【見積～発注まで編】
【制作・納品・請求編】
システム開発において、お客様からお金をいただくのは納品が終わってから。
例外的に、工期の長いもの（半年とか1年とか）の場合は分割して先にお金をいただく場合もありますが、基本的には以下の流れです。
- 制作する
- お客さんに納品する
- 納品物に瑕疵（かし／バグとか、注文通りにいってないところ）がないかお客様のチェックを受ける⇒この作業を検収と言う
- 問題がなければ請求書を発行する
- お客様が支払って、我々が金を回収する
カネを払ってもらうまでがオシゴトだよ！
【制作・納品・請求編】①仕事は発注書をもらって（契約を交わして）から始める
お客様がどんなに「やるやる」とおっしゃっていても、こちらが提案時にデザイン案を作成していても、
「発注書」をいただくまではお客様にそれをお渡しすることもできません。
また、お客様に何かをお渡しする、つまり「納品」が発生する場合には、原則、その対価を「請求」 しなければなりません。
【制作・納品・請求編】発注書
発注書を回収したら、お客様とやりとりをしながら制作を進める。
制作が完了したら、お客様に納品する。
★納品のタイミングや内容は、できれば提案時に、遅くとも制作中にお客様と調整しておくこと！
たとえば、ECサイトで「サイトは出来たけれど商品が設定されてないから、納品まだだ！」なんてモメることがあるため。
「何を作って、どういう状態になったら納品なのか」をちゃんとお客様と確認しておく。
納品物でバグがないかどうか、お客様に一通りチェックしていただいて（これを検収と言います）、問題無ければ
検収完了書（納品書にハンコおしてもらうとか）をもらってください。
検収はちゃんと期限を区切る
また、検収はかならず、「検収期間」として検収が終わる期日を決める。
これは、納品してものすごく時間が経過したあとに「あのときは気づかなかったけど、こんなバグがあった！当然バグなんだから、タダで直せ！」っというモメごとを防ぐためです。
ちなみに、検収期間内にお客様がバグを見つけられなかった場合には、バグがあっても制作者のせいにはなりません。お客様の責任となります。契約書上はネ。
検収が終わったら、請求を立てる
無事検収が終了したら、請求を立ててください。
いつ請求をするかは、お客様と調整することもあります（たとえば決算月だから、まだ納品終わってないけど先に請求して下さいなど）。
お客さんもビジネスなので、払えるキャッシュが潤沢にある月（予算をとってある月）と、乏しい月があります。
原則としては、納品が完了した月の月末で締めて、翌月末にお支払いいただくように請求書を発行します。
見積書、納品書、請求書の例
前使ってましたがMisocaは小規模の場合かなり便利でした（※宣伝とかではないです）
あとちょっとしたメモ
既にやりたいことが決まってる/売れる商品がある場合は？
たまに作りたい内容がとっても明確なお客さんがいらしたり、あるいはこちらが出来ることが明確な場合があったりします。
基本的な流れは一緒で、ヒアリング、提案、受注、制作、納品、そして請求。という流れです。
ただそれぞれのステップが定型化されている分、とてもやりとりは早くなります。
既にやりたいことが超具体的に決まってるお客さんの場合
そもそも、もしお客さんが、
超具体的に**「これこれこういうサイトが欲しいの！ドメインこれ！中身はこれでこういう機能！」**
…みたいな願望を持っていらしたら話は超早いです。
「あ～、じゃあそれは10万、そっちは20万、合計30万ですねー。
いまおっしゃった感じでは、これもつけると便利だと思いますよ～。50万になりますけどオススメです～」みたいな。※価格はてきとうです
こっちから提供するパッケージがあって値段も決まってる場合
洋服を買うみたいに取引のやりとりがスムーズにいきます。
「どれにします？ちなみに梅は20万、竹は50万、松は100万です★
梅だとメルマガ機能はないですヨ。松だとオリジナルのロゴとドメインついてます」
「ふーん、じゃ、ロゴは持ってるし竹にします」
な感じでさっくりやれることを比べて、選んでもらうだけなので、ラクです。
またこちらが出来る範囲も決まっているので、それに沿って制作すれば良いので、比較的ラクです。
さいごに
実はIT的なお仕事から離れて久しいのですが、過去の投稿をあまりにたくさんの方に見ていただいているので（議事録まとめに10万PVありがとうございました！）下書きのまま放りっぱなしだったこれを加筆修正し、公開してみました。
私自身、実はまったくの未経験・知識ナシからディレクターをはじめまして、最初は「商取引の流れ」的なところから覚えていきました。
ITの用語もわからないしビジネスの流れも分からないしで、てんやわんやしてすごい大変だった覚えがあります。
ぶっちゃけ仕事のとりかたもよーわからん、営業の流れもよーわからん、という状態で、かつ無形の商品を売るというのはカナリ難しいです。
こと、システム開発でできることなんてものすごく幅広いがゆえに、こちらが提案できることというのはあまりに広すぎて、
**お客さん⇒『提案してほしい、今のオレにぴったりなオススメを知りたい』 こっち側⇒「じゃ、あんた一体何がしたいのさ？やりたいこと教えてくれよ？」**と卵が先かニワトリが先かみたいな状態をよく見かけます。
上にも書きましたが、自分がやりたいことが具体的にわかってるお客さんなんてほぼいません。
なぜなら、やりたいことが具体的に分かってたら、やれる方法を自分で探せるからです。
お客さんもどうすればいいのか良くわかんないけどこんなカンジになったらいいな～、ということに対して深く切り込んでいって、そうなりたいと思うにはどんな背景があって（一体何に困っていて／どんな課題があって）、なぜそれをやりたいのかを聞くことによって、お客さんが本当にされたいオススメを探り、正しくオススメする…これこそが、「ヒアリング」であり「要件定義」ということじゃないかな～、と、私は思ってます。
お客さんがやりたいことを自分自身で具体化できるんだったら、実現させるために今はクラウドソーシング等環境が整いすぎてるので、別に、わざわざディレクターだの営業だのに頼まなくてもいいので。
それを越えて付加価値を出せる仕事をしたいな、なんていつも思います。