![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
[[TODO]] *概要 [#jac85ef3] -物を売るスキル。 -事務職は売上には影響しないので経営者はそこにコストをかけたいとは思わない。営業職は事務職に比べてやりたくない人が多い。なので人気がないしだからこそ、客先に立てるスキルはエンジニアにとってもチャンス -相手の問題を課題を理解し、問題解決し、価値を提供することに注力する --お客様への価値を提案するためには課題の相互認識が大事 --まずは、ウェブサイトへの訪問理由だったり、相手の探しているサービスの抽象度だったり、最近注力している領域だったりを知ることが大切。その上で、こちらが提案できる価値を提示し、どのように問題を解決できるかを議論する --サービスの中身についての話は、そのあと。聞かれたら言うくらいでよい *目次 [#vb508ff0] #contents *営業を受けた場合 [#vd6d7e01] -営業電話で、相手に先手を取って質問されると反射的に応答を返してしまう習性が利用されているなと思った --正常系の応答プロトコルから逸脱して、「なんでそれ聞くんですか」「切りますよ」と言う訓練が必要 *個人事業主 [#lf88ddd0] -''継続的にSNSでイキる！！'' -''仕事は回してもらうのではなくて、自分で取ってくるか、仕事を自分で作り、自分の値段を自分で決めれるように'' -会社員は特定の人にペコペコしないといけない。フリーランスは全顧客にぺこぺこしないといけない -自分は楽しいけど他の人はやりたくないことは仕事になる、自分はできるけど他の人はできないことは仕事になる。 -プロとは相手の期待値を読み取りあるいは定義し、期待値以上の仕事を安定して出すこと -雇用関係の法形態と、見積もりの方法 -はじめに言うと、工数による見積もりというものは意味がない（下から抑える以外の意味がなくて、全ては相場で決まる） -自分が死んだ時の、相手のリスクをきちんと見積もる。 -あんまりな金額を言ってくる相手には「来るお店を間違えてますよ」と言う！ -ポストセールスは最も効率的なプレセールス -仕事受注価格の最低ラインは決めておいて、値段は相手に言わせる。最低ラインを下回ったらそれは客ではない。会社の維持・生活コストの三倍にする。 *顧客中心の営業を行う [#mf316613] -相手の問題を課題を理解し、問題解決し、価値を提供することに注力する --お客様への価値を提案するためには課題の相互認識が大事 --まずは、ウェブサイトへの訪問理由だったり、相手の探しているサービスの抽象度だったり、最近注力している領域だったりを知ることが大切。その上で、こちらが提案できる価値を提示し、どのように問題を解決できるかを議論する --サービスの中身についての話は、そのあと。聞かれたら言うくらいでよい -顧客の関心事から、顧客の問題解決を行い、価値を提供することに注力する -カスタマージャーニーは顧客の体験を設計する --顧客に対するカスタマージャーニーマップを想定して顧客と認識をあわせることが重要 ([[例>https://drive.google.com/file/d/1F17ars_PlUupJY7VXWpB17byHkzvXKus/view?usp=sharing]]) --顧客の顧客がいる場合、顧客の顧客に対するカスタマージャーニーマップを想定して顧客と認識をあわせることが重要 -顧客中心の値段設定をする。 --高い買い物をさせることに少し躊躇するな。あなたの尺度でお客様の財布事情決めない！ *インサイドセールス [#r72ca6d2] -「インサイドセールス」とは、電話やメールなどを使い、直接対面せずに顧客とコミュニケーションを行なう営業手法です。インサイドセールスに対して、従来型の対面での営業はフィールドセールス、またはアウトサイドセールスと呼ばれたりします。 -C商談、B商談、A商談などにわける必要 -ウェビナー *カスタマーサクセス [#o78bc74f] -アカウントを維持する --ポストセールス、既存のお客さんが契約をしつづけてもらうというのが重要 --ちゃーんレートを下げる -とにかくお客三とコミュニケーション、把握するために、ハイタッチなアクション -NPSを維持する、 -レベニューが下がったとしても継続を下げよう、みたいな感じの重要にしたい、という目標になりえる。 *外注 [#hfe1c292] -電通 --企画・営業を電通がやってくれるらしい *心構え [#d9d4dc6e] -自信があるスキルを売るってスタンスだと早晩躓く --自分のスキルを世の中が必要としているスキルに寄せていく！ *付加価値 [#g0fa2424] -相手の言っていることを、はいやります、では付加価値は出ない。120%の仕事をする。 --「〇〇をしてください」って言われた時に、意図を察知して、「××でこれ出来るけどこれじゃだめ？」って確認を取る（楽にする） --「これをやったらより価値が出ると思う」と提案する（ほぼコンサルみたいなものを無料である程度くばる） -実績を見せる。 --逆に、案件の「実績を公開する権利」は必ずもらうひつようがある。非公開でプロジェクトに従事して得られるのは、「1年生きた」という空白だけ。絶対に実績は明記できるように。 *単価が高いほうが理不尽な要求にならない [#ke24ff80] -金額が高いほど開発者として尊重してもらえ依頼内容も妥当 --金持ちは余裕がある --お金が高いと、「ああこの人は単価が高いから、本質的かつ必要な分だけを注文しよう」となる *初対面 [#zeb04ccc] -会社に訪問した時は胸を張って、名乗って、用件を伝える --当たり前。社会人として当然 *要件定義 [#k48c013b] -非機能要件はあまめに設定 --中央値〜，最悪〜などだが，あまく設定する *契約の種類 [#fe6af5b8] -契約には3種類あり、「準委任契約で委託」「準委任契約で受託」と表現 ++請負（完成に責任を持つ、瑕疵担保責任がある） ++準委任（法律行為を行わない＝ソフトウェア開発・コンサルタント） ++委任（法律行為を行う＝アルバイト店員（売買）） **雇用 [#ze0176db] -バイト，正社員 **請負 [#t1c8dccc] -完成に責任を持つ． -リスクが高いので，見積の際はその分を上乗せする --瑕疵担保責任（検収で気づかないミスがあったら、１年以内ならば売主に対し損害賠償の請求ができる．損害賠償ができないなら売買契約そのものを解除することも可能．契約で瑕疵担保責任をなくすこともできる） **準委託 [#w670989c] -時間契約 -最大限がんばる義務あり（善管注意義務） *契約書 [#b7030706] -例：http://www.maff.go.jp/j/supply/sonota/pdf/sekkei_itaku_keiyaku_110307.pdf -書面で必ず． -名称, 履行期限, 契約金額は必須 -与信管理 --売掛で逃げられないように（着手金，中間金を要求する） *仕事の受注 [#bcb759a4] **見積もり [#xe763767] -仕様や期間などの条件(要求仕様)が確定したとき、見積して金額を確定する。 -要求仕様は要求仕様コンサルティングとしないと，損害賠償が全て自分にかかってくる ***金額の策定 [#p04fb96f] -3つの制約条件を満たす最大値を提案する ++自分の報酬（以上） ++相手にとっての価値（以下） ++競合との相場（以下） -''論理的に考えた見積もりで高すぎると言われたら，「じゃあいいです」という余裕が重要'' -もし交渉するなら，相手にとってどこがボトルネックなのかを見極める ++自分の報酬の場合：瑕疵担保責任などあり，上乗せの必要があること．能力の格が違うこと．したがってバイトとは一線を画していることを伝える．ダメならさよなら． ++相手にとっての価値：さよなら． ++競合の場合：競合の項目を更新して再度見積もり．ダメならさよなら． ***その他の補正 [#d40545aa] -自分がやりたくないものを高くしたりもする --面白そうな仕事 --今後の技術になりそうな仕事 ***火消屋 [#f3594053] -炎上したプロジェクトを救うと、とにかくお金がもらえる --具体的には、客先への信用＋請負契約の損害賠償の最大額まで、最大でもらえる。 ***注意 [#m73f0d27] -業界自体の価格破壊を起こさないために安売りは避けるべき **見積りの内容 [#v652d71b] -要件定義，設計，実装，テスト，ドキュメンテーション --''必ず全て含めること'' --''「本当の」人日で見積もりをするわけではない．''それは自分の報酬に関する制約でしかない．実際に客に出す人日は，価値と相場を込みで考えた時の値から逆算する． **見積もり変更 [#q5f0f9a8] -見積もり後に、要求仕様と異なる条件になった場合は、見積の根拠が失われる --見積もりを破棄し新たな条件で見積書を提出する。「見積もり条件がかわるので再見積します」というのが常套句。 --請求は再提出した見積書に記載した金額でおこなう。 ***客先の都合による変更 [#e60f0fbd] +そもそも仕様変更を見込んで上乗せ ---機能追加がありそうな案件は、ある程度の予め上乗せしておく +仕様変更による再見積もり --先方が追加だと思ってない場合は、やはりトラブルになる。 --仕様があいまいだったり、仕様変更がありそうな案件は、見積書に仕様の条件を厳密に記載して縛る。 +ソフトの場合ある程度の仕様変更は仕方ない --常套句：「本当はないんですけど，今回だけ特別にサービスで」 --厳密に仕様変更を別見積もりにすると、ビジネスにならない。 ***齟齬による変更 [#t7e25549] -どちらの責任で伝わらなかったのかとかいう責任論になる。(言わなかった、聞かれなかったなど) -材料など原価に直結するものの要求は事前に念入りに確認し、見積書に条件を記載する。 --PCだったら、CPUやメモリー、ディスプレイの仕様など。造形物だったら素材や重量など。 -具体例 --たとえば、出張一泊の見積もりで見積もった作業が、客先の都合で二泊にのびた場合、いきなり二泊分で請求するのではなく、二泊になって条件がかわる旨を先方に伝え、見積書を再提出して、その額で請求。 --こういった場合、見積書と請求書を同時に提出することになる。 ***参考価格 [#xff0a9bb] -正社員とフリーランスと会社対会社の単価は異なる --イメージ 1:1.8:3 くらい --会社が人月 80 万円だから、といってフリーランスもそれくらい稼げると思うのはおかしい 1人月を120万円で相手の会社に請求し、それを1人月80万円のフリーランスエンジニアに作業させて、その利ざやを儲けとしていました。 --フリーランスの -大きい会社の人月 --人にアルバイト任せられる値段の、3倍くらい。 --6万円/日で，普通の会社のプログラマ --10万円/日で，大きい会社のプログラマー --25万円/日で，PMやコンサル --コンサル料，東大教員時給40000円（https://twitter.com/n_hidekey/status/600850745500389376） --某ベンチャーでは一時間は外税10000円 -永江一石30000円/時（都内でやるから半日潰れるのでこれでもお試し） --「とりあえず打ち合わせしましょう」と言う人は仕事ができない。デパートの試食回って腹膨らますような方とはお付き合いしませんの姿勢が大切です。 --お金払ってるから相手が真剣、事前にかなり下調べしてきてレポートを書いてきてもらうのだが（先にもらっても当日までは読みません。時間内に含めてますので）、みなさんきちんと調べてきます。これが無料だとなんの用意もしてないケースもよくあるでしょ。相手が「とりあえず話だけでも」みたいな虫のいいことを考えていたら、お金を払ってまで打診はしてこない。お金を払う以上、真剣です。冷やかしとかは一切無くなった。真剣に質問も用意してきてくれる。「プレゼンは有料です。しかもかなり高いです」っていうとだいたいうまく逃れられます。 --しかしそこそこの実績を積めば、「有料」にすることで逆に、「この人の時間には価値があるんだな」と相手も事前に認知してくれるようになる。無料のものは無料の価値しかないわけで、こちらもお金を取る以上、心構えが全然変わってくるのです。 --自分の時間はすべて有料 = だってその価値があると思うからですよ、にしてから、非常にロスがなくなった。 --うち、無料の試食とかないですからご希望なら他へどうぞ -講演料は下げれば下げるほど来るから、なるべく高い状態にしておいたほうがいい。 --1日30万円くらいを目標にしたい（それでも来すぎる。都内50, 地方70くらい） --1時間の講演料は10万円で受けたことがあるけど安すぎた。準備もあるし、移動で一日潰れる。 -僕の最低賃金 --期限のない業務委託は最低5000円 --期限のある請負は最低10000円 **仕事の断り方 [#ze91e021] -本音は抜きにした断り方 ++理由：今別の仕事があるので．繁忙期にお引き受けしてクオリティを下げてしまっては申し訳ない．私には荷が重い。 ++クッション：残念ですが、申し訳ありませんが、お話ありがたいのですが、 ++代替案の提案：一週間後でいかがでしょうか。他のこういった事ならできます。 -NG ++「当方に利益がでないので …」「やりたくないんだから、断って当たり前」という態度 ++「できません」など、否定語の多用 ++「どうしても時間がとれないので」「上司から了承されないので …」 *著作権 [#ta400e28] -著作権 -著作人格権 -著作なんとか権 *守秘義務 [#oef01a8d] -業務内容は秘密． -相手の会社名は普通OK *損害賠償 [#a6b05853] -仕様通りにやってれば問題なく損害賠償は免れる。 *開発フェイズ [#s0d03b6d] -フェイズは単に小分けにする意味でしかない *瑕疵担保責任 [#zc0749e4] -建築では，瑕疵担保責任は，法律上は瑕疵を発見してから１年以内に請求できることになっています。しかし，判例で引き渡しから１０年で時効消滅するとされています。 洋服のクリーニングやオーダーメードも請負である。建設工事であれば「建物を完成させる」、洋服のクリーニングであれば「洋服をきれいにする」というように、請負人は引き受けた仕事を完成する義務を負う。 http://itpro.nikkeibp.co.jp/article/COLUMN/20140619/565308/ http://blogos.com/article/62812/ ソフトは商法第526条2項に定められている通り、ソフトウェア関連の瑕疵担保期間は６ヶ月でお願いしております。しかし、これは商人間の“売買”契約に適用される条文であって、商人間の“請負”契約にもこれが準用されるという規定はありません。もし法定の瑕疵担保期間を交渉の基準に持ち出すならば、民法第637条の１年が基準http://blog.livedoor.jp/businesslaw/archives/52291552.html 瑕疵担保責任は民法572条によって任意規定であることが明確に示されています。よって契約で変更可能 瑕疵担保責任には売買の場合（民法第５７０条）と請負の場合（民法第６３４条）で参照する条文が異なります。 無償で瑕疵の修正（民法では「修補」という）を請求したり、修補を要求する代わりに損害賠償を請求したりできる。これらの請求ができるのは、原則は目的物の引き渡しから1年以内である（民法634条、637条）。また、瑕疵担保責任は民法上は「無過失責任」とされている。瑕疵が生じたことについて請負人に非がなくても、瑕疵を修正したり損害賠償を支払ったりする責任を負う。 情報処理システムの開発に当たっては、作成したプログラムに不具合が生じることは不可避であり、プログラムに関する不具合は、納品及び検収等の過程における補修が当然に予定されているものというべきである。 結局，ソフトの瑕疵担保責任を請求できる期間と，瑕疵の認識からそれを売主に教えなければいけない期間は商品引き渡しから1年，引き渡しが存在しない場合は仕事の終了から1年． *仕様変更を見積もりにいれる文化 [#aba2485b] -プログラムの場合だと目に見えない。 --簡単そうに見える機能でもすごく手間がかかったりする。 --作ろうとしても、家の土地自体が足りないとか、そういう場合はどこかを壊して土地を確保してその上に家を作ってその中に機能を作るみたいなことが必要になるケースがあるのでかなり大変。 --お金かかりますって言うと、お客さんから言うとなんでやねんということになってトラブルになりがち。 --めんどいのではじめから3倍請求するのが通例となっている。しかし受託外syが悪いかと言われたら機能追加は悪いことではないしリスクヘッジだから妥当。 --一方顧客が悪いかというとわからないから注文しているのだし、時間とともにほしい機能や追加機能がふえるのは当然 *コンペ [#jc51eb17] -やめましょう -「コンペは地獄だし、だいたいクソができる」 -随意契約の１本釣りで、末長くパートナーシップを結ぶこと。 --選定パートだけ外部アドバイザリを3人ぐらい招聘し、実績と技術をチェックするのがよい *求人 [#k9a89d44] -アメリカのPhDの学生、将来有望な人々が無料ピザ（と適当な炭酸飲料）だけで釣れてしまうので、「どうです、皆さんもお一つ？」という感がある。free pizza 食事の魔力 |
