フリーランスエンジニアが
エージェント案件だけで月60万〜80万円を作る。
これは全然悪くありません。
ただ、そこから先に行くなら
小さな個人案件や直接案件を取って
自分でお客さんの課題を解決する経験が必要になります。
でも、ここで多くの人が不安になると思います。
営業して案件が取れたとしても
その後ちゃんと進められるのか。
お客さんと揉めないのか。
仕様追加を言われ続けて、しんどくならないのか。
正直、この不安はかなり正しいです。
なぜなら、直接案件で事故る原因のほとんどは
最初の要件定義とヒアリングで決まるからです。
なんとなく話を聞いて
なんとなく「できます」と言って
なんとなく実装を始める。
これをやると、かなり高い確率で揉めます。
この記事では、フリーランスエンジニアが
小規模事業者から直接案件を取ったときに
事故らずに進めるための要件定義のやり方を話します。
動画で聞きたい人はこちらです。
記事では、直接案件で使えるように流れを整理して書いていきます。
- 直接案件で事故る原因は、実装力よりも最初の要件定義にある
- お客さんの要望をそのまま作る前に、現状の業務フローを見る必要がある
- 改善案は、インパクトと工数の2軸で優先度を決める
- 最初は低工数・高インパクトの改善から信頼を作る
- エージェント案件だけでなく、個人案件を取りたい人
- 直接案件を取ったあと、顧客対応や要件定義で事故りそうで不安な人
- 実装だけでなく、業務改善まで提案できるエンジニアになりたい人
直接案件で事故る原因は、ほぼ最初にある
個人で案件を取るときって
最初は営業に意識が向きがちです。
どうやってお客さんに出会うか。
どうやって提案するか。
どうやって受注するか。
もちろん、そこも大事です。
でも、実際に事故るのは
受注した後です。
お客さんから、
ここを自動化してほしいです
こういう感じで
すぐ作り始めてしまう。
一見、スピード感があって良さそうに見えます。
でも、ここが危ないです。
お客さんが言っていることは
あくまで「点の困りごと」だったりします。
本当に改善すべき場所がそこなのか。
そもそも業務全体はどう流れているのか。
どこに一番時間がかかっているのか。
ここを見ないまま作ると
後からこうなります。
これもできませんか？ あれも追加できませんか？
このズレが積み重なると
案件は一気にしんどくなります。
だから、直接案件では
実装に入る前の要件定義がかなり大事です。
大企業向けの要件定義とは、少し違う
ここで話している要件定義は
大企業の基幹システムを作るような話ではありません。
大企業向けなら
ステークホルダーの承認を取るとか
複数部署の合意形成をするとか
そういう話がメインになることもあります。
でも、フリーランスエンジニアが最初に狙うべきなのは
もっと小さな事業者さんの業務改善です。
たとえば、
- スプレッドシートの集計を自動化する
- シフトやタイムカードの管理を楽にする
- 手作業のレポート作成を自動化する
- LINEやフォームのデータを整理する
- 外部APIをつないで、毎日の作業を減らす
こういう案件です。
この規模だと
今目の前で話している人が
そのまま意思決定者だったりします。
だからこそ、形式ばった資料を作るより
まず相手の現状をちゃんと聞いて
業務の流れを一緒に整理する方が大事です。
まず、お客さんの現状を図にする
結論、最初にやるべきことはこれです。
お客さんの現状をしっかりヒアリングして
業務フローを図にしてください。
これだけで、事故のかなりの部分は防げます。
たとえば、シフト管理やタイムカード管理を
人力でやっているお店があるとします。
バイトの子が出勤したら紙に書く。
退勤したらまた紙に書く。
店長が1日に1回それを集計する。
その結果を別のシステムや表に入力する。
こういう流れがあったとします。
ここでお客さんは、こんな感じで言ってきます。
紙を写真で撮ったら、AIが自動で計算してくれるものを作れませんか？
これだけ聞くと
確かに作れそうに見えます。
でも、全体の流れを見ると
そもそも紙に書いていること自体が
根本の課題かもしれません。
紙をAIで読むより
最初からフォームやLINEで打刻した方がいいかもしれない。
集計だけでなく、入力の段階から変えた方がいいかもしれない。
こういうことは
全体像を見ないと分かりません。
お客さんは自分の業務に慣れすぎていて
自分がどういう流れで仕事をしているのかを
意外と把握していないことがあります。
だから、エンジニア側が
「今どういう流れで仕事していますか？」と聞いて
一緒に整理してあげるだけでも価値があります。
お客さんの要望をそのまま作るのではなく、まず現状の業務フローを整理します。点の困りごとではなく、全体の流れを見ることで、本当に改善すべき場所が見えます。
数字で見ると、改善すべき場所が変わる
業務フローを整理したら
次に見るべきなのは数字です。
どの作業に何分かかっているのか。
誰が何回やっているのか。
月にどれぐらいの時間が消えているのか。
その人件費はいくらぐらいなのか。
ここを数字で出してください。
なぜなら、お客さんの感覚と
実際にインパクトが大きい場所は
ズレていることがあるからです。
お客さんは、
「ここが面倒なんです」
「ここを自動化したいです」
と言ってきます。
でも数字で見ると
実は一番時間がかかっているのは
別の工程かもしれません。
その場合、エンジニア側から
と言えます。
これができると
ただ言われたものを作る人ではなく
お客さんの業務を見て提案できる人になります。
正直、ここが単価の差になると思っています。
実装だけなら
AIでも、他のエンジニアでも、外注先でもできます。
でも、相手の業務を整理して
数字で改善インパクトを見せて
「まずここからやりましょう」と言える人は
かなり価値があります。
改善案は「インパクト × 工数」で決める
現状を整理して
数字も出したら
次にやるのは優先度決めです。
ここで使いやすいのが
インパクトと工数の2軸です。
インパクトが小さいのに、実装工数だけ大きい改善から始めることです。エンジニア側もしんどいし、お客さん側もお金を払った割に効果を感じにくくなります。
見るべき軸はシンプルです。
- この改善をやると、どれぐらい時間やコストが減るのか
- 実装にどれぐらい工数がかかるのか
- API利用料やAI利用料など、金銭的なコストはどれぐらいか
- 運用に乗せるまでに、どれぐらい説明や調整が必要か
この2軸で見ると
最初にやるべきことが見えます。
まず狙うべきなのは
低工数でインパクトが大きい改善です。
いきなり大きなシステムを作る必要はありません。
むしろ、個人案件に慣れていない段階で
最初から大きいものを作ろうとすると
実装でも、認識合わせでも、運用でも事故りやすいです。
まず小さく成果を出す。
お客さんに「あ、この人ちゃんと仕事してくれるんだ」と思ってもらう。
そこで信頼を作る。
この順番が大事です。
信頼ができた後なら
もう少し大きい改善提案も通りやすくなります。
仮に途中で少しミスがあっても
最初にちゃんと仕事してくれた人として見られているので
許容される幅も変わります。
逆に、信頼がない状態で
いきなり大きいことをやって失敗すると
「もうあなたはいらないです」となりやすいです。
だから最初は、コスパの良い改善からでいいです。
要件定義は、自分の身を守るためにも必要
要件定義って
お客さんのためだけにやるものではありません。
自分の身を守るためにも必要です。
直接案件でよくあるトラブルは
最初は小さい範囲で決めていたのに
途中からどんどん要求が増えることです。
これもできますか？ ついでにこっちもお願いします
こうなると、かなりしんどいです。
もちろん、最初の実績作りで
多少頑張ることは大事です。
でも、全部を聞きすぎると
相手の要求はどんどん膨らみます。
「これをやってくれたなら、これもやってくれるよね」
という空気になるからです。
だから最初に、
- 今の業務フローはこうなっている
- 今回はこの範囲を改善する
- これは次のフェーズで対応する
- 今月はここまで進める
- 追加でやるなら、別見積もりにする
ここを握っておく必要があります。
後から追加要望が来たときも
最初に整理したワークフローと優先度を見せれば
話を戻しやすくなります。
こう言える状態を作っておくことです。
ここを曖昧にすると
お客さんも悪気なく範囲を広げてきます。
そして、エンジニア側だけが苦しくなります。
作る前に、改善の正解を握る
エンジニアとして一番しんどいのは
頑張って作ったのに
成果が出ていないと言われることです。
ちゃんと実装した。
時間も使った。
でも、お客さんからすると
あまり楽になっていない。
これが起きると
かなりむかつくと思います。
でも、その原因は
作る前に改善の正解を握れていなかったことだったりします。
どこを改善すれば一番インパクトがあるのか。
どれぐらい時間が減るのか。
どれぐらいコストが下がるのか。
どの順番でやるのか。
ここを最初に握っておけば
作った後の評価もズレにくくなります。
直接案件で大事なのは
コードを書くことだけではありません。
お客さんの業務を理解して
数字で課題を整理して
何をやるべきかを一緒に決めることです。
ここまでできると
ただの実装者ではなくなります。
小規模事業者からすると
「この人に相談すれば、業務が整理される」
という存在になります。
これが、次の案件にもつながります。
直接案件で最初に確認するチェックリスト
最後に、直接案件を取ったときに
最初に確認する項目をまとめておきます。
- 今の業務は、誰がどの順番で何をしているか
- 各作業に、1回あたり何分かかっているか
- その作業は、1日・1週間・1ヶ月で何回発生しているか
- どの作業が一番時間を使っているか
- お客さんが困っている場所と、数字上インパクトが大きい場所は一致しているか
- 低工数・高インパクトで最初に改善できる場所はどこか
- 今回やる範囲と、次フェーズに回す範囲はどこか
- 追加要望が出た場合、どう扱うか
このあたりを最初に握っておくだけで
かなり事故りにくくなります。
よくある質問
Q. 小さい案件でも、ここまで要件定義した方がいいですか？
はい。むしろ小さい案件ほど大事です。
小さい案件は金額が小さい分
曖昧なまま始まりやすいです。
でも、曖昧なまま始めると
追加要望や認識ズレでしんどくなります。
最初に重たい資料を作る必要はありません。
業務フロー、数字、優先度だけでも整理してください。
Q. お客さんが「とりあえず作って」と言ってきたら？
すぐ作り始めない方がいいです。
「作る前に、どこを改善すると一番効果があるか整理しましょう」
と伝えた方がいいです。
ここで嫌がるお客さんは
後から範囲が広がったり、成果の認識がズレたりする可能性があります。
Q. 要件定義ができると単価は上がりますか？
上がりやすくなります。
なぜなら、言われたものを作るだけの人から
業務改善の優先度を一緒に決められる人になるからです。
小規模事業者にとっては
コードそのものより
「どこを改善すれば利益や時間に効くか」を整理してくれることに価値があります。
まとめ
直接案件で失敗しないために必要なのは
いきなり実装を始めることではありません。
まず、お客さんの現状を聞く。
業務フローを図にする。
各工程の時間やコストを数字で見る。
インパクトと工数で優先度を決める。
今回やる範囲と、次に回す範囲を握る。
この順番です。
個人案件や直接案件は
うまくやれば、エージェント案件の時間の切り売りから抜けるきっかけになります。
ただし、要件定義を雑にすると
せっかく取った案件が一気にしんどくなります。
逆に、ここを丁寧にできると
お客さんから信頼されます。
追加の案件も出やすくなります。
同じような課題を持つ別のお客さんにも提案しやすくなります。
今、直接案件を取りたいけど
受注後の進め方が不安な人は
まず今日話した要件定義の流れから押さえてください。
僕の公式LINEでは、直接案件の取り方や
小さな個人案件から月収100万円を目指す流れも整理しています。
今のエージェント案件だけで止まりたくない人は
よければ一度、見に来てください。
月収100万円の壁を突破する
エンジニアロードマップを受け取る
LINEで無料ロードマップを受け取る →
はるや
- AIに負けないエンジニア育成を発信
- 稼ぎ続ける本質的なエンジニア戦略を発信
- フリーランスエンジニアの単価アップ・個人案件・キャリア戦略を解説
手取り20万円の会社員エンジニアからフリーランスになり、月単価50万、60万、70万、100万、130万円と単価を上げてきた経験をもとに、開発スキルだけで終わらない働き方を発信しています。