以前書いたエンジニア副業についての記事

が、随分読まれているようだったので少し具体的にわたしが副業時代に考えていたこと、頑張っていたことなどを書きました。

副業時代はクラウドワークスを使って副業していたので、主にクラウドワークスを使ってわたしが案件を取得する際に意識していた部分についてになります。

前置き

クラウドワークス や ランサーズ といった所謂クラウドソーシングのサービスには、アンケートのような多数のワーカーさんに対して仕事を発注する形式（クラウドワークスのタスク形式）と、少人数のワーカーさんと契約してアプリやサービスなどの開発を行う形式（プロジェクト形式）の二つの形式があります。

タスク形式はあまり特別なスキルなどは必要とせず、敷居は非常に低いのですが、その分報酬も安いです。

逆にプロジェクト形式は案件を取得するまでは見積もりをしたり要件を確認したりと準備が必要ですが、タスク形式に比べると報酬は高いものが多いです。

せっかくエンジニアとして副業しようというのであれば、自分のスキルを使ってプロジェクト形式を獲ったほうが報酬・実績など得るものは多いですので、ここではプロジェクト形式を前提として書きます。

ちなみに、タスク形式は「クラウドソーシングのサービスの使い方を覚える」という点では使えると思いますので、サービス登録後は最初に一度やってみるのも良いかと思います。

案件取得のために意識していたこと

案件の契約は、

1. 発注者（クライアント）が概要をクラウドソーシングのサービスに提示
2. 受注希望者（複数）が、見積もり金額や自分の実績などをアピール
3. 発注者と受注希望者の間でメッセージのやりとり
4. 発注者が契約する受注者を決定

という流れになります。

複数の受注希望者がいる中で、いかにして自分の優位性をアピールするかという点が重要になります。

そのあたりで意識していたことを書いていきます。

発注側がほしいのは安心感

実践していたことの前に、まず発注側としてどういったことを考えているだろうか、という部分について先にわたしが思うことを書いておきます。

実際にわたしがクラウドワークスで開発を請け負ったクライアントさんと、プロジェクト（アプリ開発）完了後に話した時のことです。

興味本位で「どうしてわたしと契約しようと思ったのですか？」と聞いてみました。

その答えは、 「りゅーたさんなら、アプリを完成させてくれると思ったから」 でした。

このプロジェクトに応募してきた人の中には、わたしよりもずっと安い金額を提示してきた方もいたそうです。それでも選んでいただけたのは、開発を任せても大丈夫という安心感を持っていただけたからだったようです。

クラウドソーシングって、どこの誰かよくわからない人と仕事の受発注をするサービスなので、「本当にこの人と仕事して大丈夫か？」みたいな不安が常にあると思います。これは仕事を請け負う側にもあるので理解できるかと思います。

そういう不安感を取り除くことが受注への近道と考えます。

すごく当たり前に聞こえるかもしれないですが、これは強く意識した方が良いことかと思います。

お金と時間をかけたのに、結局欲しいものが完成しなかったというのがクライアントとして最大のリスクなはずなので。

完成をイメージできる提案をする

発注者が不安になるのは、発注者にもわからないことが多いからだと思います。

発注者が技術の事に明るくない場合もありますし（というかその場合の方が多い）、アプリ・サービスの開発が初めてということもあるでしょう。

できる限り具体的に完成までの道筋を提案に含めることで、その不明な部分をクリアにすることができます。

例えばアプリ開発だと、こんな感じで提案してます。

具体的にどういう手順で作業をしていくか、というのをできる限り具体的に書き出すと良いかと思います。

また、クライアント側の確認は随時必要となってくると思いますので、どの時点で、どういう確認をお願いする予定か というのも書いておくと、先方との協働のイメージがつきやすいかと思います。

このやりとりをしている時点では、当然ながらまだ契約はしていません。ですが、気持ちとしては契約が取れているという想定で、実際に作っていく過程を示してあげる方が良いかと思います。

下調べをする

上記の、具体的な提案をするという部分と類似ではあるのですが、クライアントの提示した案件の内容について、詳細が気になる部分があればしっかり下調べしておきましょう。

例えば、類似したアプリ、サービスなどを提示していただくことは頻繁にありますので、少なくとも実際に使ってみたり、サイトを見たりはしておいたほうが良いです。

実はわたし自身も仕事の発注をしたことがあるのですが、こちらが提示した類似サイトなどの内容を全く見ずに応募してきた方が結構いました。

そういった方たちからのメッセージは、自分（達）のスキルと実績のアピールだけが書かれたテンプレートをそのまま送ってきているような感じのもので、そのスキル・実績がどのようにこの案件に活用できるのかという部分についての記述が一切なく、「本気で受けるつもりは無いのかな」という印象を受けました。

ちゃんと下調べした方の提案は、提案に具体性があり、下調べしてない方との差がはっきりわかります。

プロジェクト形式では価格を受注者の方から提案できますが、受注者の中には絶対に元がとれないような安い金額を提示してこられる方もいます。

そういった方たちと価格の優位性を競っても勝ち目がないですし、仮に受けれたとしてもストレスが溜まるだけですので、こういうところで優位性を狙った方が自分のためにも良いかと思います。

そもそも下調べを無駄に感じてしまうのは、「どうせこの案件はとれないだろう」という前提から来ているように思います。正直、そんなやる気が無いような感じの人と一緒に仕事したくないですよね？

見積もり前提をちゃんと書く

これも具体性を上げる施策の一環とも言えるのですが、見積もりした際には見積もりの前提をちゃんと書いておきましょう。

例えば、

• 対応する OS やブラウザのバージョン
• アイコンなどのデザインは作業工数として含めているのか否か
• アプリであれば、ストアへのリリース作業は自分がやる想定なのか、クライアントの方でしてもらう想定なのか

などといった部分になります。

自分とクライアントで作業の範囲を明確にするのと同時に、後々「ストアへのリリースまでやってくれるものと思って契約したのに！」みたいな揉め事を回避する際にも役立ちます。

これはクラウドソーシングに限らず、業務委託などで開発を請け負う際にも言えることかと思います。

見積もりを出す時点でその見積もりの前提は何か、やる範囲・やらない範囲をどう想定して見積もりを出したのかというのは明確にしておいた方がお互いのために良いです。

さいごに

受注する側で見積もりを頑張って作ったり、下調べしたりしないといけないのかという面倒さを感じるかもしれません。

また、いろいろ頑張ったからといって、結局案件がとれないということは良くあります。

発注者が、依頼自体を取り下げる場合もあります。

それでもやはり、調べるべきことは調べて、最初に考えるべきことは考えておいたほうが、案件獲得の確率は上がります。

また、個人的には受発注前のやりとりはプロジェクトが始まってからのやりとりの縮図だと思っていて、ここでの対応が適当になる人は、プロジェクト中も対応が適当になるように思います。

そういうクライアントを見極めるためにも、受発注前のやりとりはしっかりと。

下調べで未知の技術を調べたりするのも無駄にはならないですし、数をこなしてくるとこういうやりとりにも慣れてくるかと思います。

焦らずにやっていきましょう。

最後まで読んでいただきありがとうございます。 このブログを「いいな」と感じていただけましたら、Twiter にてフォローいただけるとうれしいです。ブログ更新情報などもお届けします。

Follow @ryuta461

この記事をシェアする