フリーランスが400万円オーバー案件をポシャった話し | vol.001
こんにちは、エンジニアの「すえ」（@sueTech_）です。
今回は、自分が過去にお仕事させて頂いたケースでの失敗談を、内容ボカシながらお伝えしていきます。
実際に開発業務を外注した際にどんなポイントで躓くのか、どこを気をつけるべきなのか、皆さんにお届けできればと思います。
タイトルにもある通り、400万円を超える予算の案件だったため、ポシャった際にはかなり悲しかったのですが、この記事で成仏させたいと思います笑
こんな案件でした。
お仕事をくださったクライアント様は、スタートアップとして新規事業に取り組んでました。既にエンジェル投資家から資金を調達しており、数名ですが社員の方もいらっしゃいました。
お仕事内容は「某スポーツ競技のCtoCコミュニケーションプラットフォーム開発」ということで、デザイン性は重視したいものの、機能としては複雑なものはありませんでした。
既に数社のWeb開発企業に見積もりを取られていたのですが、初期開発としては予算オーバーだったため、自分にお願いしたいとのことでコンタクトを頂きました。
その後、初期開発400万円、CTOが見つかるまでは継続的に開発マネージャーポジションをお願いしたいということで、合計すると900万円は下らない規模感のご予算で、初期開発分の請負契約に至りました。
開発・マネージメント・チーム立ち上げ。
そのような経緯で実際にお仕事がスタートしました。
クライアント様から頂いたプロトタイピングと資料を元に開発を進めていき、不定期ながらミーティングを開催し、進捗共有やUIUX・機能面でのご提言なども行っていきます。
スタート時点では、プロタイピングもしっかりと作られていたので、とてもスムーズでした。
リリース後の開発マネージャー業務も見据え、この期間から自分の知り合いフリーランス・副業を行なっているエンジニアに声をかけて、開発チームも組織していきました。
ちなみに、こんなことを考えてリリース前からチームビルディングを行ないました。
・リリース後は、ユーザーからのフィードバックを素早く反映できる開発体制にしたい。
・有能なエンジニアの採用は、常に動いていないと達成できない。
・スムーズに開発へ参加できるように初期段階から加わってもらいたい。
・要望には応えながらも、なるべく早くリリース出来るようにしたい。
ただ、資金調達済みとは言え、スタートアップ。キャッシュエンジンも無く、初期開発予算と社員人件費でいっぱいいっぱいの状態でした。
そこで、リリース前から動いてもらう開発メンバーへの報酬は、自分からの持ち出し（ざっくり40~50万円/月！）という形にして何とか動かしていこうということにしました。（リリース後は、各々がクライアント様と直接契約）
もちろん、リリース後にはサービスを動かすためのサーバー費用や開発チームの業務委託費がかかってきます。クライアント様には受託業務でランニングコストは賄える体制を整えてもらうよう提言し、案件は進んで行きました。
💡発注者の方へ
システムは開発して終わりではなく、むしろ始まりです。継続的にしっかりとシステムを動作させ続けるためにはどうすべきか、何が必要か検討することも大切です。
やっぱり変わる初期仕様。
予算パツパツ・ゆえにリリース日を遅らせたくない・プロトタイピング済みだったため請負契約という形にはしましたが、スタートアップで働く同じよしみとして、ある程度の仕様変更は受け入れるような契約にしました。（大幅に変更がある場合には別途お見積もり）
進めていく中で、「デザインのブラッシュアップ」を行なっていきたいということになり、クライアント様から新たなプロトタイピングが不定期に送られてくるようになりました。
そちらを拝見すると、バックエンド（API・DB）の変更が必要になっていたり、画面数が増えていることが多々あったため、「別途お見積もり or まだ着手していない箇所に関しては初期のプロトタイピングのまま」というご提案を行いました。
こうして壊れていきました。
クライアント様からのご回答としては、要約すると「予算は増やせない・受託の売上も乏しい・仕様は変わっていない・400万円の予算を使って」というものでした。
「予算は増やせない」
物理的に現段階で400万円以上の現金が無いとのことでした。受託側からの目線でお話しすると、別途お見積もりが発生する可能性もある中で、予算確保も無しに開発内容の更新を行なっていたのか…というのが、正直な感想でした。
ですが、無い袖は振れないことも事実であり、ある種の敗北を確信した瞬間でもあります…
「受託の売上も乏しい」
日々、受託業務で忙しいとお話しを伺っていたのですが、社員1名の人件費を賄うのがやっとの状態とのことでした。少なからず自分も受託業務の経験がありますので、苦労はもちろん重々承知しております。
ただ、数ヶ月分の人件費は受託売上でカバー出来ていたのに、初期の予算分しか会社に残っていないというのは計算が合わず、本当に売上が立っていたのか・会社として受注していたのか（個人の懐に入れていたのではないか）という疑問は残りました。
「仕様は変わっていない」
クライアント様からすると、画面に変更はあったが機能は変わっていないというご認識のようでした。開発現場あるあるですが、画面が変わるということは付随して裏側（API・DB）なども変えなければならないことがあるということをご理解頂けていませんでした。
簡単なホームページ制作の知識はお持ちだったようで、HTMLの修正くらいに捉えていたようでした。
「400万円の予算を使って」
機能に変更が生じれば、工数が増えていき、納期にも影響が生じます。持ち出し稼働していただいたエンジニアたちとは準委任契約を結んでおり、毎月稼働分の報酬をお支払いしていました。
そのため、工数が増えることによる金銭的影響は自分がモロに受けるのですが、クライアント様からは「400万円まで、まだ余裕ありますよね？」という発言が飛び出しました。身包みを剥がそうとしないでください…
クライアント様の主張を意訳すると、こんな感じになります。
確かに変更はあったが、大した工数にもならない画面の変更だけだろう。
400万円で発注したんだ。400万円以内で何とかしたまえ。
一方で、対する自分の主張はこんな感じです。
画面数は増えており、機能自体も増えています。
請負契約金額を引き上げるか、機能を削ってください。
話し合いの場が設けられたり、補助金を模索したりとしましたが解決には至りませんでした。両者の主張の溝は埋まらないまま、最終的には突然の「投資家からの資金引き上げ」により案件はご破算となりました。
当初は400万円だった報酬は、中途解約条項により計150万円となりましたが、持ち出しの委託費とトントンという結果です。
💡エンジニアの方へ
実際の進捗状況で言うと、150/400万円以上の進みでした。投資家から資金引き上げが行われ、事業継続困難ということでお支払い頂ける範囲内で着地しました。
契約を結んでも避けられない不都合はありますが、しっかりと契約条項は確認しましょう。
ここがクリティカルでした。
振り返ってみると、結果的にこのようなポイントがクリティカルに響いたのかと思っています。
・「仕様」が指すところの認識違い
・キャッシュエンジンを持っていない & 自己資金が無い
「仕様」が指すところの認識違い
これは、受託業務を行なったことがあるエンジニアであれば一度は経験したことがあるのではないかと思います。
「画面のレイアウトを変更したい」「◯◯ケースにも対応できるようにしたい」など、キックオフした後にクライアントからご要望をいただくことは往々にしてあるかと思います。
そういった際、予算範囲内で行う場合と別途見積もりが必要な場合がありますが、そもそも今回は「仕様変更レビュー」のステップが欠落していたことが問題でした。
エンジニアでは無い方やIT企業に勤められたことがない方、システムの発注経験がない方がクライアントになる場合は多々あり、この辺りの知識を丸っと把握しておいてほしいというのは、不可能です。
エンジニアが会社の外で自分でお仕事を取って納品する場合、こういった知識面のカバーをすることは当然であり、クライアントが発注している理由のひとつだったりします。
💡エンジニアの方へ
開発能力が高い、最新の技術動向に精通しているだけでは自己完結してお仕事をしていくことはとても難しいです。相手が望んでいることを把握することも、とても重要なスキルの１つです。
今回のケースでは、クライアント様のチームメンバーとしての振る舞いも期待されていたこともあり、「こちら側で負担しよう」精神で進めていましたが結果として破綻してしまいました。
💡発注者・エンジニアの方へ
作業には適切な報酬が支払われるように、発注・受注側ともに気をつけましょう。目先の利益追求は、結果として誰の利益にもなりません。
発注側は要望を出したいだけ出す、コストは限りなく切り詰めるようなことをするとプロジェクト自体が頓挫する可能性がとても高まります。また、法的リスクも抱えることにもなってしまいます。
受注側もクライアントにご理解いただけるように、技術的なトピックも分かりやすく伝えるように務めるべきだと身をもって再実感しました。
エンジニアはソフトスキルよりもハードスキルが重視される風潮がありますが、社内でお仕事する際でもとても大切な要素だと思います。
自分含めエンジニアは「技術オタク」であることを自覚しましょう。笑
クライアントからすれば、意味不明な妄言を垂れ流しているのと同じ！
× PythonとRustでは、ガベージコレクションの有無で速度が〜〜〜
× ◯◯本に書いてある△△駆動開発で進めていけば〜〜〜
仕様をどのくらい質が高く確定できるかというところで、成功率が変わってきます。現在、自分の場合は開発前に下記のことを行うようにしています。
・仕様に不安があれば、仕様確定まで準委任での業務委託で携わる
・プロジェクト内で使用する言葉の定義を一致させておく
・仕様変更フローの合意を得る
キャッシュエンジンを持っていない & 自己資金が無い
そろばんを弾いて壮大な事業計画を引いているだけでは、会社は生き残れません。しっかりと足元を見て進んでいくことも、とても大切です。ただ、受託側からクライアントの金銭的事情にまで口を出せることは滅多にありません。
もし、フリーランスの方が資金的信用力の乏しいクライアントとお仕事をされる際には、契約書をしっかりと作成されることをおすすめします。
また、時には見送る決断をすることもとても重要です。今回のケースのように下手をすると数ヶ月分の努力が水の泡になることだってあります。
幸いにして、自分は副業という形で携わっていたので大事には至りませんでしたが、フリーランスで活動されている方には死活問題になりかねません。
💡エンジニアの方へ
仕事をこなすだけではなく、自分の中の「危険察知センサー」はとても大切です。自分のように痛い目を見る前に常日頃から意識しておくと良いかと思います。
以上、今回は実際の現場レベルでの失敗談をご紹介させていただきましたが、いかがでしたでしょうか？少しでもITに関わる人たちのお役に立てれば、幸いです。
それでは、また次の記事で！
Twitterやっています！アカウントはこちら！
😚お仕事のご依頼お待ちしております！ご連絡はこちらのフォームから。
🤗無料のITご相談を受け付けております。お気軽にご連絡ください！
🤔システムや新規事業の外注・受託での体験談を募集しております。あなたのエピソードをお待ちしております！
・30分インタビュー（Zoom or 都内23区内にて対面）にご協力いただける方には、3,000円のAmazonギフトカードをプレゼントしています。
・フォームご応募いただいた方の中から、インタビュー対象となる方へご連絡差し上げます。
この記事が気に入ったらサポートをしてみませんか？