はじめに

ココナラで初案件は取れた。レビューも★5でついた。けれど 2件目・3件目が単発で終わってしまい、収入が安定しない——副業を始めて半年〜1年くらいの方からよく聞く悩みです。

実は、単発と継続を分けているのは技術力ではありません。 「依頼内容そのもの」をどう設計するか、つまり要件定義のフェーズで決まっています。私が初案件の3,000円を、半年で5〜6回のリピート（累計15,000円ほど）に育てられたのは、 「データを納品する」のではなく「ツールを納品する」 という発想転換が効いたからでした。

本記事は3部作の 継続案件化編。クライアントの真因を引き出すヒアリング術、ツール化提案の伝え方、そして非エンジニアでも使いこなせるEXE納品の具体的な作り方を、すべて手順レベルで書きます。まだ初案件を取っていない方は、先に 入門編 からどうぞ。

ヒアリングで「真因」を掘るとは何か

表層ニーズ vs 真因

クライアントが最初に書いてくる依頼文は、ほとんどの場合 表層のニーズ です。「Aサイトの商品データをCSVで欲しい」と書かれていても、その奥に必ず別の動機があります。

  • 表層: CSVが欲しい
  • 真因A: 競合の価格を毎週チェックして自社の値付けを調整したい
  • 真因B: 自社サイトに在庫を反映する手作業が辛い
  • 真因C: 取引先の納期管理が破綻しそうで根本的に仕組みを変えたい

真因がAなら定期実行が必要、Bなら自社システムへのインポート形式が重要、Cなら通知や自動連携が刺さります。 同じ「CSVが欲しい」でも、真因によって最適な納品物が変わる——ここに気づけるかが、単発と継続の分岐点です。

私が体験した発見ストーリー

最初の案件で、依頼文には「商品の価格・在庫を毎月CSVで送ってください」とだけ書かれていました。私はそのまま受けようとしましたが、メッセージ往復の中でクライアントがふと、 「自分の好きなタイミングで取れたら一番ありがたいんですけどね」 と漏らしました。

これが転機でした。「毎月送る」というのは表層で、真因は 「自分の判断で実行したい」 だった。タイミングはイベント前・在庫変動の予兆が見えたときなど、クライアントしか分からない領域だったわけです。

真因を掘る質問テンプレート

その後、私は初回ヒアリングで必ず以下5問を聞くようにしました。

  1. 「このデータを最終的に何のために使いますか？」（用途を聞くと真因が出る）
  2. 「取得頻度はどれくらいの想定ですか？」（毎月／週次／不定期で要件が大きく変わる）
  3. 「最終的に操作するのはどなたですか？」（あなた本人／チーム／非エンジニアで難易度が変わる）
  4. 「サイトの仕様が変わったときはどう対応したいですか？」（保守の必要性が見える）
  5. 「データを最終的にどんな形で見たいですか？」（Excel／自社システム／メール通知 etc.）

5問のうち1〜2問だけでも真因が掘れることが多く、 そこから「ではこういう納品形態はいかがですか？」と提案に転換 する流れがほぼテンプレ化しました。

ツール化提案の伝え方

「データ納品」から「ツール化」への切り替え会話

クライアントから「自分の好きなタイミングで取れたら…」という言葉を引き出した後、私が実際に送ったメッセージはこんな感じでした。

1点ご提案なのですが、データを毎回お送りする形だけでなく、 ご自身でいつでも実行できるツールとしてお渡しする こともできます。ダブルクリックで起動するWindowsアプリで、Excelファイルが結果として出てきます。今回ご相談のサイト構造であれば、追加の費用なしで対応可能です。いかがでしょうか？

返信は 「そんなことができるんですか！？ぜひお願いします！」 でした。クライアントは技術的にどう実装するかは知らない。だから「できる／できない」を選択肢として見せる側の責任です。

クライアントに刺さった一言

このメッセージで最も効いたのは「ダブルクリックで起動」という一言だったと、後でクライアントに聞きました。 コマンドラインを開いてPythonを実行する、という前提が彼らの世界には存在しない。だからこそ「PCを使ったことがある人なら誰でもできる操作」に翻訳するだけで、価値の伝わり方が一段変わります。

提案時に避けるべき技術用語と置き換え表現

非エンジニアのクライアントに提案するとき、私が無意識に避けるようになった用語と置き換え表現を一覧にします。

NG用語 置き換え表現
実行ファイル / バイナリ Windowsアプリ／ダブルクリックで起動するソフト
引数 / オプション 設定項目／チェックボックス
ターミナル / コマンドライン （触れない方が良い。GUIで完結させる）
ライブラリ / 依存関係 必要なものはすべて中に同梱しています
デバッグ / リファクタ 不具合の修正／中身の整理
Git / リポジトリ （触れない方が良い。Google Drive等で配布）

「相手の語彙でしゃべる」のは技術以前のコミュニケーション基本ですが、エンジニア同士の会話に慣れているとつい忘れがちな部分です。

非エンジニアに優しい納品形態（フル展開）

ここからが本記事の本丸。継続案件につなげる納品物の三種の神器、 EXE化・Excel出力・操作マニュアル の作り方を順に書きます。

EXE化する理由と落とし穴

なぜEXE化が必要か

非エンジニアのPCには、ほぼ確実に Pythonがインストールされていません。仮にインストールしてもらおうとすると、PATH設定・pipのバージョン違い・依存ライブラリの衝突など、サポートコストが跳ね上がります。

これを一発で解決するのが PyInstaller によるEXE化です。Pythonインタプリタ・依存ライブラリ・自分のスクリプトを丸ごと1ファイルにパッケージし、 クライアントのPCにPythonが入っていなくても動く実行ファイル を作れます。

基本コマンドと最低限の設定

最小構成は以下のとおり。

pip install pyinstaller
pyinstaller --onefile --noconsole main.py
  • --onefile: 1つの.exeに全てまとめる（配布が楽）
  • --noconsole: 黒い画面（コンソール）を表示しない（GUIアプリのとき）

CLIツールで「進捗を表示したい」場合は --noconsole を外し、コンソール出力が見えるようにします。クライアントが進捗を見られた方が安心するので、 進捗ログは出した方がいい というのが個人的な結論です。

落とし穴1: Windows Defenderが警告を出す

PyInstallerで作ったEXEは、署名なしだとWindows Defenderが「不明な発行元」として警告を出すことがあります。納品マニュアルに 「警告が出たら『詳細情報』→『実行』を選んでください」 とスクリーンショット付きで明記しておくと、初回起動時のトラブル問い合わせがほぼゼロになります。

落とし穴2: ファイルサイズが大きくなる

PyInstaller --onefile で作ると、シンプルなスクリプトでも 20〜80MB ほどになることがあります。pandas や Selenium を含めると100MBを超えることも。Google Drive・Dropbox 経由なら問題ありませんが、メール添付は厳しいことを覚えておきましょう。

落とし穴3: 一部のライブラリで追加設定が必要

Selenium・Playwrightのようにブラウザドライバを使うライブラリは、 PyInstallerのデフォルト設定では同梱されない ことがあります。--add-data オプションでドライバファイルを明示的に同梱するか、起動時に自動ダウンロードする方式に切り替える必要があります。最初の納品前に 必ず別PC（理想はクライアントと同じWindows環境）で動作確認 すること。

Excel出力の列設計

EXEで生成されるデータの受け皿として、CSVではなく Excelファイル（.xlsx） を採用するのが私のスタンダードです。理由はシンプルで、 非エンジニアの業務はExcelで完結している から。

列名固定・並び順固定の重要性

クライアントは納品されたExcelをそのまま自社の既存ファイルにコピペしたり、VLOOKUPで参照したりします。 列名や並び順を毎回変えてしまうと、その下流のすべてが壊れる。一度決めた列構成は、追加要望があっても 末尾に追加する 運用に統一します。

NG: 列を真ん中に挿入する
OK: 列は常に末尾に追加し、既存列の位置・列名は固定

日付付きファイル名の自動生成

ファイル名に取得日時を入れておくと、 クライアント側で履歴管理が自動化されます。例えば以下のようなフォーマット。

products_20260505_1430.xlsx

datetime モジュールで datetime.now().strftime('%Y%m%d_%H%M') を使えば一行で実現できます。これだけで「先週のデータと比較したい」のようなクライアントニーズに、追加実装ゼロで対応できる。

openpyxlでの最低限のExcel出力

pandas経由で書く場合は1行で済みますが、書式を多少整えたいなら openpyxl を直接触るのもおすすめ。

from openpyxl import Workbook
from datetime import datetime

wb = Workbook()
ws = wb.active
ws.title = "商品一覧"

# ヘッダー行
ws.append(["商品名", "価格", "在庫", "取得日時", "URL"])

# データ行（取得結果をループで追加）
for item in scraped_items:
    ws.append([item["name"], item["price"], item["stock"],
               datetime.now().strftime("%Y-%m-%d %H:%M"), item["url"]])

# 列幅の自動調整（簡易版）
for col in ws.columns:
    max_length = max(len(str(cell.value or "")) for cell in col)
    ws.column_dimensions[col[0].column_letter].width = max_length + 2

wb.save(f"products_{datetime.now().strftime('%Y%m%d_%H%M')}.xlsx")

列幅の自動調整を入れるだけで、クライアントが「ファイルを開いた瞬間の印象」がぐっと良くなります。 小さなUXの積み重ねが満足度に効く、と感じる場面のひとつです。

簡易操作マニュアルの作り方

EXEとExcelを揃えても、 操作マニュアルが無ければ問い合わせは止まりません。マニュアルは納品物の一部、と位置づけて手を抜かないのが結論です。

図解スクリーンショットの最小構成（4枚）

私が標準で同梱するマニュアルは、以下4枚のスクリーンショットを軸にしています。

  1. 配置: ファイルをデスクトップに置く図（ZIPを解凍する場合は解凍後の状態）
  2. 起動: ダブルクリックする図（赤丸でクリック箇所を強調）
  3. 実行中: 進捗が表示されている図（黒画面でも安心してもらえる）
  4. 完了: Excelファイルが生成された図（成功時の状態を見せる）

たった4枚ですが、 「何をすれば終わるか」が画像だけで完結している のがポイント。テキストだけのマニュアルは、非エンジニアにとっては「読まないもの」だと割り切ります。

動画マニュアルを15分で作る方法

最近は静止画より動画の方が刺さるケースも多い。私が使っているのは以下のいずれか。

  • Loom: ブラウザ拡張で録画→共有URLが即発行される。クライアントは閲覧のみで再生可能
  • OBS Studio: 無料・高機能。MP4で保存して納品物に同梱
  • Windows標準のXboxゲームバー: Win + G で起動。インストール不要で即録画

動画マニュアルは 3〜5分の長さ に収めるのが鉄則。長いと結局見られません。

トラブルシュート欄の必須項目

マニュアル末尾に「うまく動かないとき」セクションを入れます。最低限カバーするのは以下の3項目。

  • 起動しない: Windows Defenderの警告画面のスクショ＋「詳細情報→実行」の手順
  • 結果が空のExcelになる: ネット接続確認・対象サイトが表示されているかの目視確認
  • 文字化けする: Excelの文字コード設定（UTF-8）を変更する手順

これだけで一次サポート問い合わせの半分以上は減ります。 クライアントが自己解決できる仕組みを作るほど、保守の単価が上げやすくなる という副産物もあります。

💡 2026年現在の補足: マニュアルの初稿はAIエージェントに作らせて、スクリーンショットだけ自分で差し込む手順が圧倒的に時短になります。AIに任せられるフェーズと自分でやるべきフェーズの線引きは、別記事【AI活用編】で詳しく扱う予定です。

検収を明確化する仕組み

ツール納品で揉める典型は、 「これは仕様通り」「いや想定と違う」 の押し問答です。これを起こさない最も効く対策は、 検収基準を出品段階で文章化しておく こと。

私が標準で出品ページとメッセージに入れている検収項目は以下4つです。

  • 取得件数: 想定件数の目安（例: 100件以上）／極端な乖離は事前合意
  • 列の網羅性: 出品ページに記載した取得項目（商品名・価格・在庫・URL）が全て埋まっていること
  • サンプル一致: クライアント指定の3〜5件で目視一致を確認
  • 再取得条件: 軽微な不具合（列名間違い・パース漏れ）は7日間内なら無償再取得

これを納品時に「以下の検収基準で確認をお願いします」と一行添えるだけで、検収プロセスが構造化されて、感情的なトラブルがほぼ消えます。

スコープ管理 — 「ちょっと追加で…」を防ぐ

継続案件が育ってくると、必ず出てくるのが「ちょっと追加で◯◯もできますか？」の依頼です。これを 善意で全部請けると、自分の単価が崩壊 します。

私がやっているのは「軽微 / 追加費用」の境界線を最初から見せておく方法。

カテゴリ 内容 対応
軽微修正 列名の誤字・取得漏れの再取得 7日以内なら無償
仕様変更追随 サイト側のHTML変更によるツール改修 月額保守 or 都度見積もり
機能追加 別サイト追加・スケジュール実行・通知機能 追加見積もり

依頼が来たときに「これは軽微修正の範囲です／こちらは追加見積もりになります」と即返答できる枠組みがあると、 クライアント側も合理的に判断してくれる ようになります。

受け渡し方法の標準化

納品物の受け渡しは、毎回違う方法だとトラブルの温床になります。私の標準は Google Drive に統一。

  • パスワード付きZIPの添付メール／メッセージは廃止（昨今のセキュリティ議論で非推奨）
  • Google Drive の共有リンクで配布（権限はクライアントのGoogleアカウントに限定）
  • バージョンが上がったら同じフォルダ内に v1.1 / v1.2 と並べる（履歴が残る）

この運用にしてから、 「どのバージョンを使えばいいか」「ファイルが見つからない」系の問い合わせがゼロ になりました。

結果として5〜6回のリピートにつながった経験

最初の3,000円・時給58円で受けた案件は、ここまで紹介した手順を順に踏むことで、半年で 合計約15,000円 の継続案件に育ちました。内訳はおおよそ次のとおり。

回数 内容 単価
1回目 初回スクレイピングツール納品 ¥3,000
2回目 サイト仕様変更への追随 ¥2,000
3回目 別商品ジャンルの追加 ¥3,000
4回目 CSVフォーマットの調整 ¥1,500
5回目 取得項目の追加 ¥3,000
6回目 スケジュール実行のオプション化 ¥2,500

単価そのものは大きくありませんが、 2件目以降の作業時間は1〜3時間程度 に圧縮できているので、時給ベースでは初案件と比べて10倍以上の改善。さらに、ここで得たクライアントとの信頼関係が、 別案件の紹介や口コミ★5レビューの追加 という形で間接的にも効いてきます。

継続案件は、単発の積み重ねよりも 複利 で効くタイプの収益構造です。

まとめ — 単発を継続に変える3つのコア

ここまでの内容を3つに圧縮するなら、こうなります。

  1. 真因ヒアリング: 「データが欲しい」の奥にある動機を質問で引き出す
  2. ツール化提案: 単発のデータ納品ではなく、自分で実行できるEXE+Excelを提案する
  3. 検収・スコープの構造化: 揉めない仕組みを最初に文章化しておく

技術力を上げる前に、 依頼内容そのものを設計し直す 方が早く効きます。

次のステップ

ここまでで「単発を継続に変える」基本は揃いました。次は 継続案件を育てて単価を上げる フェーズ。技術改善の5軸（再利用性・例外処理・ログ・出力・変更耐性）と、パッケージ化による価格戦略を解説します。

👉 次の記事: 副業プログラミングで単価を上げる技術投資 — 5つの改善軸＆パッケージ価格設計

まだココナラに出品していない方は、入門編を先にどうぞ。

👉 入門編: ココナラでプログラミング副業を始める方法｜Pythonスクレイピングで実績ゼロから1案件目を取るまで