月末になると、3つのExcelファイルを開いて、数字を1つずつ別のシートに写していく。
「これはプログラムで自動にできるのでは」と思いながらも、何をどう頼めばいいのか分からず、今月も結局手で作業してしまう。
そんな経験がある方は少なくないのではないでしょうか。
頼みたい気持ちはあるのに、プログラミングの言葉で説明できる自信がない。その小さな引っかかりが、依頼の手前で足を止めているのかもしれません。
ココナラには、Excelの自動化や小さな業務ツールの作成、エラーの修正などを請け負う出品者が数多くいます。
この記事では、専門知識がなくても意図が伝わるプログラミングの頼み方を、依頼文の書き方、納品物の決め方、出品ページの見方、向かない依頼の扱い方に分けてお伝えします。
仕様書がなくても頼めます。伝えるべきは「今の作業」です
ココナラでプログラミングを頼むなら、画面の設計や機能の一覧をきちんと書かないと相手にされない。
そう思い込んで、依頼文を書く前に手が止まってしまう方も多いようです。
けれども小さなツールやExcelの自動化であれば、出品者が本当に知りたいのは技術用語ではなく、あなたが今どんな手順で作業しているかです。
どの言語で書くか、どう組み立てるかは、本来プロが考える部分だからです。
たとえば「売上、在庫、顧客の3つのファイルから、商品コードが一致する行の金額を拾って、請求書のひな形に貼っています」と書くだけで、出品者はおおよその作業量を想像できます。
逆に「Excelを自動化したいです」の一言だけでは、数時間で終わる話なのか、数週間かかる話なのか判断がつきません。
返信が来なかったり、見積りが思ったより高くなったりする原因の一つは、この情報の少なさにあります。
依頼文に入れたいのは、今の手作業の手順、元になるファイルと完成形の見本、使っているパソコンとソフトの種類、そして「必須のこと」と「できたら嬉しいこと」の区別の4つです。
見本のファイルは、中身を架空の数字や名前に置き換えたもので十分です。
完成後の画面を手書きしたメモの写真でも、長い文章より早く伝わることがよくあります。
うまく説明しようと力むより、見せられるものを見せる方が、話はずっと早く進むのではないでしょうか。
行き違いは「動く」の意味のずれから始まります
プログラミングの依頼でよく聞く失敗に、「納品されたのに動かない」というものがあります。
ただ中身を見ていくと、出品者の環境では動いていて、依頼者のパソコンでは動かないというずれであることが少なくありません。
Macで作られたものをWindowsで使おうとした、会社のパソコンでは新しいソフトを入れられなかった、といった行き違いです。
もう一つ多いのが、元のファイルの形が少し変わっただけで止まってしまうケースです。
毎月の表に列が1本増えた、ファイル名に日付が入るようになった、それだけで動かなくなることは珍しくありません。
依頼者にとっては同じ作業でも、プログラムにとっては別の作業に見えてしまうからです。
これを防ぐには、どんな状態で何ができれば「動いた」と言えるのかを、依頼の前に一文で決めておくことが近道になります。
見積り相談の段階では、次のような点を聞いておくと安心です。
納品されるのはソースコードなのか実行ファイルなのか、使い方の説明は付くのか。
納品後に不具合が見つかった場合、どこまで、いつまで無料で直してもらえるのか。
元のファイルの形が変わったときの手直しは、別料金になるのか。
ココナラの見積り相談は購入前に無料で送れるので、こうした確認は取引が始まる前に済ませておけます。
細かく聞くのは気が引けるかもしれませんが、ここを曖昧にしたまま始めて困るのは、実は出品者も同じではないでしょうか。
出品ページで見るべきは「話が通じる相手か」の手がかり
出品者を選ぶとき、評価の星の数や実績の件数に目が行きがちですよね。
もちろん参考にはなりますが、プログラミングの場合はそれ以上に、自分の説明で通じる相手かどうかを見ておきたいところです。
手がかりになるのは、サービス説明に対応できる言語や動作環境が具体的に書かれているか、そして料金に含まれないことが明記されているかです。
対応範囲をはっきり書いている出品者は、依頼の時点で線引きをしてくれるので、後からのずれが起きにくくなります。
評価コメントに「専門知識がなくても丁寧に説明してもらえた」といった声があるかどうかも、非エンジニアにとっては大事な判断材料です。
最初のメッセージへの返信で、こちらの説明を自分の言葉で言い直して確認してくれる人なら、その後のやりとりもかみ合いやすいはずです。
金額は依頼の中身によって大きく変わります。
短いスクリプトの作成やエラーの修正なら数千円台から出品されているものが多く、複数のファイルを扱う業務ツールになると数万円台の見積りになることもあります。
差が出るのは、扱うデータの量と複雑さ、操作画面を付けるかどうか、納品後の手直しをどこまで含めるかといった部分です。
また購入者には、1回の支払いごとにサービス手数料5.5%がかかるため、予算には少し余裕を見ておくと安心です。
ココナラでプログラミングを頼む良さは、「この作業だけ」という小さな単位で相談できるところにあります。
制作会社に頼むほどの規模ではないけれど、自分で勉強して作る時間もない。
そうした隙間の作業を、出品者の評価や対応範囲を見比べ、購入前にメッセージで確かめたうえで任せられます。
支払いもサービスを通して行われるので、知らない個人と直接お金をやりとりするより、踏み出しやすいと感じる方も多いかもしれませんね。
大きな依頼は、最初の一歩だけ切り出して頼めます
一方で、ココナラが向きにくい依頼もあります。
日々の業務の中心になるシステムを作って何年も保守してほしい場合や、途中で要望がどんどん増えていきそうな場合は、1回ごとの取引には収まりにくくなります。
個人で活動している出品者も多いため、長期の保守や急なトラブルへの即日対応まで約束できるとは限りません。
顧客の個人情報を大量に扱うツールでは、データの受け渡しそのものに慎重さも求められます。
それでも、全体を一度に頼む必要はありません。
「請求書の転記部分だけ」「試作として1画面だけ」と切り出せば、取引の単位にちょうど収まります。
試作を受け取ってから次を考えれば、最初の出費を抑えつつ、その出品者との相性も確かめられます。
大がかりな仕組みが必要だと分かって制作会社に相談することになっても、手元に試作があれば要望をずっと伝えやすくなります。
納品のあとも、確かめる作業が残っています。
出品者から正式な納品が届くと、購入者はトークルームで内容を確認して「承諾」か「差し戻し」を選びます。
期限内に回答がないと自動で承諾される仕組みなので、納品されたらその日のうちに、決めておいた基準で動くかを試すのがおすすめです。
頼んで終わりではなく、受け取って確かめるところまでが頼み方の一部だと考えると、少し気持ちが軽くなりませんか。
プログラミングの頼み方で大切なのは、専門用語を覚えることではなく、今の作業の手順と「動いた」と言える状態を自分の言葉にすることです。出品ページでは対応範囲と説明の丁寧さを見て、見積り相談では納品物と納品後の対応を確かめる。大きな依頼は小さく切り出して、最初の一歩だけを任せる。頭に浮かんでいる面倒な作業の手順を3行だけ書き出せば、それがそのまま見積り相談の最初の一文になります。
そもそも何を頼めばいいのか、自分でもまだはっきりしないと感じている方には、こちらの記事が手がかりになるかもしれません。
