ココナラでサービス2件を下書きした。2万円より先に決めた6つのこと
1件目は「Webアプリの不具合を調査・修正します」。2件目は「AWS・Terraformの構成を調査します」です。
どちらも価格は2万円にしました。ただ、今回いちばん時間を使ったのは、価格を決めることではありませんでした。
「何を受けるか」「何を納品するか」「何を受けないか」を文章にする作業です。
この記事を書いている時点では、2サービスとも下書き保存までです。公開、購入、契約、納品はまだありません。2万円が売れる価格だと確認できたわけでもありません。
それでも、出品前に決めておく項目は具体化できました。今回は、自分が2件の下書きで共通して決めた6つのことをまとめます。
1. 最初の1件で扱う問題を小さくする
Webアプリ修正では、対象を次のように区切りました。
1リポジトリ
1画面または1機能
再現できる1症状
AWS・Terraform調査では、1つのAWS環境、または1つのTerraformリポジトリのうち、事前に合意した範囲を対象にしました。
「Webアプリを直します」「AWSを見ます」だけでは、依頼者と出品者で想定がずれる可能性があります。最初の成果物を自分が確認できる大きさに区切ることで、見積もり時に話す範囲が明確になりました。
ただし、この区切り方で実際の依頼に対応できるかは未検証です。問い合わせが来たら、症状や構成を確認して調整します。
2. 着手前に必要な情報を決める
作業を始めてから情報不足に気づかないように、購入前の見積もり相談を必須にしました。
Webアプリ修正で確認するのは、対象コード、技術構成、症状、再現手順、期待する動作、確認環境、希望納期です。
AWS・Terraform調査では、現在の構成、困っている症状や運用課題、期待する状態、対象範囲、変更可否、確認環境、希望納期を確認します。
情報がそろう前に、原因や修正可否、改善効果を断定しないことも文面へ入れました。
3. 作業量と同時受注数に上限を置く
2件とも、基本の作業量は4時間程度を目安にし、納期の目安は5日、同時受注可能件数は1件に設定しました。
4時間は、購入前の見積もりで最終的な範囲を決めるための上限です。5日も実績から算出した最適値ではなく、本業と並行して確認と説明まで行うための初期設定です。
実際の作業時間はまだ測れていません。受注できた場合は、調査、修正、確認、説明にかかった時間を分けて記録します。
4. 「作業したこと」ではなく納品物を書く
Webアプリ修正では、次を納品物にしました。
修正差分
原因と変更内容の説明
実施した動作確認と結果
購入者側で確認できる手順
元に戻す方法
AWS・Terraform調査では、確認した事実、課題や原因候補、優先順位を付けた改善案、変更時の注意点、確認手順、復旧時の考慮点を納品します。
「調査します」だけで終わらず、依頼者が受け取るものを列挙しました。修正できなかった場合も、確認済みの事実と切り分け結果を残す前提です。
5. 対象外を先に書く
対応できることだけでなく、基本料金に含めないことも先に書きました。
Webアプリ修正では、アプリ一式の新規開発、仕様が定まっていない全面改修、決済・認証・本番DB・本番インフラ全体への変更、無制限の修正、常時待機や緊急対応などを対象外にしています。
AWS・Terraform調査では、本番環境への直接変更、AWSアカウント全体の再設計、新規インフラ一式の構築、24時間監視、緊急障害対応、セキュリティ監査や認証取得の保証などを含めません。
対象外は「できないことの一覧」ではなく、基本料金で責任を持って確認できる範囲を示すための境界です。必要な作業が広い場合は、勝手に作業を拡大せず、追加対応へ進む前に範囲と金額を相談します。
6. AIへ入力しない情報と、人が確認する箇所を決める
技術案件では、コードや構成情報を扱います。そこで、パスワード、APIキー、秘密鍵、個人情報、顧客データは受け取らない前提にしました。
顧客コードや構成情報を外部AIへ入力する場合は、利用条件と許可範囲を事前に確認します。AIを使った場合も、修正差分、動作、調査結果、納品内容は自分で確認します。
AI利用の許可と、成果物を実績として公開する許可は別です。許可がなければ、顧客のコード、設定、画面、会話を記事へ載せません。
2万円は、まだ検証前の価格
今回は、2件とも2万円に設定しました。
ただし、公開も購入もされていないため、この価格に需要があるとは言えません。また、課税事業者の設定によって購入画面の表示額が変わる可能性があるため、公開前に自分の設定を確認する必要があります。
価格の妥当性は、問い合わせ数、見積もり相談の内容、必要な作業量、受注後の実測時間を見て判断します。現時点で分かったのは、「2万円で何でも対応する」のではなく、2万円で渡す範囲を先に文章にする必要があることでした。
出品前に使える6項目の確認メモ
これから技術サービスを作る方は、まず1案だけ選び、次の項目を埋めてみてください。
最初の1件で扱う問題：
着手前に必要な情報：
基本料金で使う作業時間の上限：
依頼者へ渡す納品物：
基本料金に含めないこと：
AIへ入力しない情報と、人が確認する箇所：
まだ実績で確認できていないこと：埋められない項目は、推測で補わず「未確認」と残します。問い合わせが来たとき、どこを相談する必要があるかが分かります。
同日の夜記事は、別の行動を記録する
2サービスを下書きした同じ9月9日に、私はココナラの公開募集へも1件応募しました。出品サービスの下書きとは別の行動です。
応募では前向きな返事をいただきましたが、後から示された条件を確認し、契約・仮払い前に辞退しました。執筆、納品、売上はありません。
この経緯は、今夜17:30公開予定の「ココナラに登録して初めて応募した。契約前に辞退するまでに確認したこと」でまとめます。朝の記事は出品する側の範囲設計、夜の記事は応募する側の契約前判断がテーマです。
今回作った2サービスも、公開前の確認が残っています。公開後に問い合わせや見積もり相談が届いたら、この6項目で無理なく対応範囲を決められるかを検証します。
普段の開発・検証の進め方や制作例は、自己紹介と開発・修正のご相談にまとめています。
