1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

初めて個人で受託開発を行った際の流れ

Posted at

この記事の目的

本記事では、初めて個人で開発を受託した際の請負から納品、振り込み手続きなどの流れや注意点を全て記録する。初めて個人でお仕事をいただく際にこの記事を読むことで、つまづくポイントをあらかじめ確認することができるかと思います!

もし、ベテランフリーランスの方が本記事を見て何かアドバイス等がありましたら、コメントをいただければ幸いです。

基本的な流れ

  1. お仕事のお話をいただく
  2. 準委任契約をむすび、「作業」と「成果物」で報酬を分割
    1. 業務分析によるシステム化のイメージ
    2. 要件定義によるイメージのすり合わせ
  3. 見積書の送付
  4. プロトタイプのコーディング
  5. デモを披露 and フィードバック
  6. 「作業」部分の請求書の送付
  7. 「成果物」の開発を開始
  8. 「成果物」の納品
  9. 「成果物」の請求書の送付

業務委託の形態について

業務委託契約は、「仕事を他者に任せるための契約」の総称である。この中には、具体的な契約形態として 委任契約、準委任契約、請負契約 が含まれる。

委任契約

説明
「○○をやってほしい」とお願いして、その内容を進めてもらう契約です。ただし、「結果」ではなく「過程」にフォーカスします。頼まれた人(受任者)は頑張って取り組む義務がありますが、成果がどうなるかについては責任を負いません。

システム開発の具体例
プロジェクト管理をお願いする場合がこれに当たります。
例:「プロジェクトがスムーズに進むように全体を管理してほしい」という依頼。進行状況の報告やスケジュール管理が主な仕事ですが、プロジェクトの最終的な成功や失敗までは責任を負いません。

ポイント

  • 責任:やること(プロセス)をしっかりやる義務はあるけど、結果の責任はない。
  • 報酬:お願いしたことを進めていれば、成果に関係なくお金が支払われる。

準委任契約

説明
「やることの中身(仕事内容)は決まってるけど、結果は保証しない」という契約です。これも「過程」を重視していて、頼んだ人の期待に応じて仕事を進めてもらいます。

システム開発の具体例
システム運用や監視、要件定義の支援などがこれに当たります。

例:サーバーの監視業務:「24時間システムが落ちないかチェックして、不具合があればすぐ報告してね」という依頼。監視して報告する義務はあるけど、システムが壊れないことまでは保証しません。
要件定義の支援:「クライアントと打ち合わせして、必要な仕様を整理してほしい」という依頼。整理する努力はするけど、クライアントが満足するかどうかの結果は保証しません。

ポイント

  • 責任:仕事をきちんと進める義務はあるけど、結果がどうなるかまでは責任なし。
  • 報酬:仕事をした分だけお金が支払われる。成果がうまくいったかどうかは関係ない。

請負契約

説明
「完成させてほしいものが明確に決まっている」という契約です。成果物ができることに責任があり、きちんと完成しないとお金は支払われません。

システム開発の具体例
システムやソフトウェアを完成させて納品する仕事がこれに当たります。

例:Webサイトの開発:「このデザインどおりにホームページを作って納品してください」という依頼。納品物が完成して、動作確認が通るまでが責任範囲です。
アプリ開発:「この機能が全部使える状態でスマホアプリを作って納品してほしい」という依頼。アプリが完成していないと報酬は発生しません。

ポイント

  • 責任:完成品に対して責任がある。納品物に問題があれば直す必要がある。
  • 報酬:仕事が完成したときだけ支払われる。完成しなければお金はもらえない。

まとめ

  • 委任契約:進め方やサポートを頼む(結果は保証しない)。例:プロジェクト管理。
  • 準委任契約:決まった内容を進めてもらう(結果は保証しない)。例:監視業務やコンサル。
  • 請負契約:完成させることがゴール(完成品の責任を負う)。例:アプリやシステムの納品。

流れについての詳細

お仕事のお話をいただく

どのようにお仕事の話をいただくかは、かなりケースバイケースかと思います。会社だと営業の方が取ってきてくれたり、個人だと知り合いから仕事を頼まれるなどのケースが考えられます。

準委任契約をむすび、「作業」と「成果物」で報酬を分割

先ほどの契約形態の中から、ケースに適したものを選択して、契約を結びます。筆者のケースでは、以下のような業務内容でした。

  • 開発するシステムがそもそもうまくいくかの検証(半分研究、半分開発のイメージ)
  • システムそのものの開発

今回作成したのは、AIが関連するシステムだったので、AIの特性上、うまくいくか検証してみないことには分からないという特性があります。

つまり、「作業」に対して責任を負う部分と「成果物」に対して責任を負う部分で大きく二分されていました。そこで、報酬の形態についても2回に分割していただくという流れになりました。

  • 開発するシステムがそもそもうまくいくかの検証作業 → 準委任契約による報酬
  • システムそのものの開発 → 請け負い契約による報酬

契約を結ぶにあたって、以下の契約を結びました。

機密保持契約
機密保持契約とは、以下の内容を外に漏らさないということを書面のサインや押捺によって約束するものである。

  • 製品の開発動向、製品情報など
  • 製品のアイディアや技術情報など
  • 顧客情報など

業務委託契約
これは、「仕事を他者に任せるための契約」であり、署名や押捺によって、これに同意する。

  • 基本事項
  • どのようにして作業を進めていくか
  • 契約の形態はどのようにするか
  • 契約の成立方法について
  • 進捗の管理体制などはどのようにするか
  • 再委託は可能か
  • 業務完了の定義
  • 成果物の権利
  • 損害賠償について

ただし、業務委託契約は契約の中でも「大枠」を定義したものに過ぎないので、具体的な業務はどのようにするか(賃金、具体的な契約範囲、etc...)などは「個別契約」というものの中で結ばれる。

個別契約
業務委任契約の中で定められた大枠の中で、具体的な契約の内容を詰めるもの。「作業」に対する報酬と「成果物」に対する報酬の区別はここで行われる。例えば、調査、納品、保守運用などの報酬の分割などについてもこの段階で行う。個別契約の具体例として、以下のものが挙げられる。

  • 業務内容: ○○システムの要件定義・設計・開発
  • 実施期間: 2024年1月1日~2024年6月30日
  • 報酬: 500万円(分割払い: 月次請求)
  • 委託者の提供物: 開発用サーバーアクセス、既存システム仕様書
  • 受注者の納品物: 動作確認済みのプログラムコード一式、関連ドキュメント

上記のような条件での契約を以下の書類のやり取りにより行う。

  1. 提案・見積書(受注者→発注者): 業務内容、業務・責任範囲、スケジュール、見積もり額、その他条件を受注側が発注側に示すためのもの
  2. 注文書(発注者→委託者):委託者(業務を依頼する側)が、受注者に対して「この内容で業務を正式に依頼する」ことを示す書類
  3. 注文清書(受注者→発注者):受注者が、委託者から受け取った注文内容(注文書)を確認し、「この条件で業務を受ける」ことを正式に同意する書類。同意する旨、内容、実施期間、報酬額、支払条件などを確認し、押印を行う
  4. 請求書(受注者→発注者):依頼を遂行し,商品を納品する際などに実際に請求をするための書類.請求書の送付後,振込が終了することで,受託開発はひと段落つく

業務分析によるシステム化のイメージ

まずは、AIシステムをどのように構築すべきかを決定するために、以下の聞き取りを行いました。

  • 目的は何か
  • どのようなシチュエーションで使用されるのか
  • 使用するデータの特性

これらの情報をもとに,そもそもAIシステムを作る必要があるのかなどの部分から吟味していきます.実際の業務の流れの聞き取りを行い,その作業フローのどこの部分をAIシステムにより置き換えられるか,あるいは追加できるかを確認します.

要件定義によるイメージのすり合わせ

ある程度システム化したい作業の流れが把握できたら,その作業を代替するために,必要なシステムの要件を固めていきます.例えば,コールセンターの質問応答をチャットボットで自動化したいという内容であるとします.

  • これまで人が行っていた音声対応の部分を全てテキストによるチャットボットで置き換えたい
  • そのためにはバックエンドでサーバーを建て,リクエストを裁く必要がある
  • 一度にアクセスする人数は ~ 人なので,ロードバランサーが必要
  • 個人情報を扱う必要があるので ~ というセキュリティが必要

といった具合です.ここでは以下のことを意識しました.

  • 責任範囲の明確化(やれることとやれないことをはっきりとさせる)
  • 金銭,セキュリティ,リソース等の制約の確認

ここで,発注者と作業者のイメージを擦り合わせることで,後々のトラブルを回避することができます.

見積書の送付

ここの段階で,報酬の見積書を作成し,送付しました.ここで作成する書類は相手の方でフォーマットが決まっている場合や,自由な場合があるかと思います.

ここでの報酬額の決定方法は,(自身の欲しい時給)x(かかるであろう作業時間 + バッファー時間)で計算しました.重要なのはしっかりバッファーを設けること だと思います.私の場合,システム開発に限らず大体の作業は自信が想定する1.5倍くらいの時間を要する傾向があるのでそれを考慮して作業時間を決定しました.

自身の欲しい時給に関しては,責任の重さと比例していくので,メンタルの健康も考慮して決定するのが良いと思います.

「作業」部分の請求書の送付

「作業」に対する報酬は,成果物の質に基本的には依存せずに支払われるので,作業前に請求し,報酬をいただきました.

プロトタイプのコーディング

要件定義で決定したシステムの機能をコーディングしていきます.今回の契約では,この部分は「作業」に対して報酬が発生する契約でした.ここはただ頑張って実装する.

デモを披露 - フィードバック

プロトタイプの実装が終了し,デモを披露し,フィードバックをいただきます.「作業」に対する報酬はこのプロトタイプを作成した際の,知見を共有することで,いただいていました.ここで,頂いたフィードバックをもとに,納品を行うシステムの仕様を固めました.

成果物の開発を開始

フィードバックの内容を受けて,実際に納品するシステムの開発を開始しました.この部分は,納品後に報酬をいただくという契約を結んでいるので,作業後に請求書を送付しました.

成果物の納品

成果物を納品し,その後,以下の内容を確認しました.

  • 委託者の環境でシステムがちゃんと動くか
  • 委託者からの質問に対する回答

上記の部分をしっかり行い,委託者に満足していただけるようにしました.

成果物の請求書を送付

システムの確認を全て行い,動作が保証されたところで,成果物に対する請求書を送付し,振込みをしていただきました.

最後に

走り書きにはなりましたが,これが初めて個人で受託開発を行った際の,営業から報酬を受け取るまでの流れになります.ここまで見てくださりありがとうございました.

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?