未分類

AppSheet副業の案件はどう取る?個人が中小企業の業務アプリ受託にたどり着くまでの実話

AppSheet副業で営業ゼロから案件が来た実話のアイキャッチ(暗い机にノートPCとデスクランプ)

「AppSheet を覚えたはいいけど、案件なんてどうやって取るんだ」

「営業なんてしたことない自分に、個人で受託なんてできるのか」

副業でノーコードを学び始めた人が、たぶん一番詰まるのがここだ。

私はフリーランス → 会社員 → 副業という三段階を歩いてきた所長だ。いまは AppSheet を使った業務アプリの開発を副業でやっている。

この記事では、私の最初の1件がどこから来たのかを正直に分解する。狙って取ったというより、向こうから来た。その経路と、単価をどう考えたかまでをそのまま書く。

AppSheet 副業は「一斉応募で取る」より「見つけてもらった」が現実だった

AppSheet 副業の案件獲得と聞くと、クラウドソーシングで提案文を量産して一斉応募する姿を思い浮かべる人が多いと思う。
求人っぽい案件に片っ端から手を挙げて、数を撃って当てる。世間ではそういうイメージが強い。

ただ、私の場合はそうではなかった。

応募らしい応募をした記憶がない。気づいたら向こうから声がかかっていた、というのが実際のところだ。

ここは混同されやすいので先に割っておく。一斉応募で取る人もいるのだろうが、少なくとも私はそれを体験していない。私は見つけてもらった側だ。

「営業なんてしたことないのに、個人で受託なんて無理だろう」

そう感じる人は多いはずだ。私自身、売り込みのスキルはいまもまったく持っていない。

それでも案件は来た。理由はシンプルで、営業の代わりにアウトプットを出し続けていたからだ。

狙って取りに行ったのではなく、出していたら来た。

そもそも私が AppSheet をちゃんと学び始めたのも、営業のためではなかった。

きっかけは本業のスプレッドシート入力だ。

入力、集計、範囲選択…。

きらいではないがめんどくさかった。どうにかならんかと YouTube の動画を見漁っていたら、データモデリングという考え方に出会って、ズブとハマっていった。

要するに、自分の困りごとを解決するために学んでいただけ。

その過程をたまたま周りから見える場所に置いていた。一斉応募で勝ち取った案件ではなく、自分の手を動かした記録が呼び水になった。少なくとも私の場合は、「営業ができない」ことは案件獲得の妨げにならなかった。

私が副業で月5万円の節目までどうたどり着いたかは、別記事で全体の流れをまとめている。本記事はその道のりのうち、最初の案件が向こうから来たときの話だ。

最初の1件はどこから来たか — 私の場合の経路を分解する

では、その「向こうから来た」は具体的にどういう流れだったのか。
あとから振り返ると、こんな順番だった。

  1. コミュニティ内の SNS で、AppSheet 学習のアウトプットを発信していた
  2. 発信の中身は「わかった」「できた」というアハ体験のメモ程度
  3. 頻度は3ヶ月ほど、週0〜2 の不定期
  4. それを見た人から「案件が多いから手伝ってほしい」と声がかかった

ちゃんとした発信ですらなかった。それだけだ。

順番に見ていくと、再現できそうな気がしてこないだろうか。少なくとも「毎日バズらせろ」みたいな話ではない。

発信といっても「アハ体験を書いてただけ」

発信と書くと立派に聞こえるが、中身はそんなものではなかった。

書いていたのは、ここがわかった、これができた、みたいな個人的なアハ体験のメモだ。本当に、その程度の温度感だった。

学習メモを人目のある場所に置いていた、というだけだ。技術記事を書いたわけでも、ノウハウをまとめたわけでもない。
それでも、学んでいる人が学んでいる過程を出していると、見ている人にはちゃんと伝わるらしい。

完成した実績を見せる必要はなかった。むしろ「いま伸びている最中」が伝わったのが良かったのかもしれない。

できあがった作品より、できるようになっていく過程のほうが、見ている側には頼もしく映ることがある。少なくとも私の場合はそうだった。

3ヶ月・週0〜2 でも声はかかる

頻度も、胸を張れるものではない。

期間はあんまり覚えていないが、3ヶ月くらいだったと思う。頻度はまちまちで、週2のときもあれば、まったく書かない週もあった。

毎日コツコツでも、計画的でもない。気が向いたときに学習の手応えを置いていた。それで声がかかった。

副業をどのタイミングで再開し、なぜこの発信を続けられたのか。これも別記事で書こうと思っている。
無理のない頻度でも、学んでいる過程を見える場所に出していたら、私の場合はそこから入口が開いた。

「個人なのに大丈夫か」は二次受け構造で解けた

声がかかったとして、次にのしかかるのが「実績ゼロの個人が引き受けて大丈夫なのか」という不安だろう。

正直に言うと、私はあまり不安がなかった。

学習のおかげなのか、もともとの素養なのかはわからない。ただ、不思議と自信があった。

「なんでも作ってやる。作らせてくれ」くらいの気持ちだった。あまり自信を持つタイプではないので、自分でも珍しい状態だったと思う。

「とはいえ実績ゼロで、そんな自信なんて普通は持てない」

そう思う人がほとんどだと思う。私だって、ひとりで全部背負う構造だったら、ここまで強気にはなれなかった。

支えになったのは、引き受けた仕事が二次受けだったことだ。

窓口・契約・ヒアリングは一次受け、私は実装に集中

二次受けの役割分担はシンプルだった。

一次受けが窓口・契約・ヒアリングを担当する。私はそのヒアリング資料を受け取って、要件定義・モデリング・実装をやる。

営業も交渉もしなくていい。私が向き合う相手は人ではなく、ほぼ「業務をどうアプリに落とすか」という設計の問題だった。

ここが二次受けのありがたいところだ。個人で受託というと、見積もり・契約・クレーム対応まで全部ひとりで背負うイメージがつきまとう。

「個人なのに大丈夫か」という不安の重さは、たぶんここから来る。私の場合は、窓口を担ってくれる相手が前にいるだけで、その不安の大部分が消えた。

二次受けの役割分担。

  • 一次受け: 窓口・契約・ヒアリング
  • 私(二次受け): 要件定義・モデリング・実装

この構造のおかげで、不安より先に「作りたい」が来た。守られた場所で手を動かせたのは大きい。

実装担当として「現場の言葉をそのまま落とす」

実装担当として一つだけ意識していることがある。

私は現場の言葉を、なるべくそのままアプリに落とし込むよう心がけている。

業務の呼び方や手順を、こちらの都合で言い換えない。現場が使っている言葉のまま設計に落とす。それだけで、後の食い違いがかなり減る。

中小企業が自分たちで業務アプリを内製化していく視点については、別記事でまとめようと思っている。

単価の考え方 — 「テーブル数 × 単価」という見積もりの軸

案件が来て、構造で守られたとして。最後に未経験者が固まりがちなのが値付けだと思う。

相場なんて、最初はさっぱり分からなかった。

いくらで受ければいいのか、自分の作業に値段をつける感覚そのものが無い。ここで止まる人は多いはずだ。

私が落ち着いた考え方はこうだ。データモデリングで使うテーブル数を軸にして、テーブル数 × 単価という式で見積もる。

「未経験でいきなり値段なんてつけられない」

その通りだと思う。だからこそ、感覚で決めずに数えられるものを軸にした。

アプリの規模は、結局どれだけのデータを扱うかで決まる。

そのデータの土台になるのがテーブルだ。テーブルの数なら数えられる。規模に応じて見積もりが動くので、自分の中で根拠を持って提示できる。

AppSheet の開発で時間を食うのは、見た目の作り込みより、データの構造を設計する部分だ。

扱うテーブルが増えれば、リレーションも入力フォームも検証も増える。だから工数はテーブル数とゆるく連動する。感覚で「えいや」と出すより、設計の手応えと値段がつながっていたほうが、自分も相手も納得しやすい。

値付けの根拠は「仲間の提案価格」

とはいえ、式があっても掛ける単価の部分が分からない。ここはゼロから発明しなかった。

値付けの根拠は、AppSheet 仲間が実際に出している提案価格を参考にしている。
すでに案件を回している人たちが、どのくらいの価格を提示しているか。その実価格を参照軸にすれば、相場から大きく外れた値付けにはなりにくい。

単価の決め方は2段構え。

  • 規模の軸: データモデリングで使うテーブル数 × 単価で見積もる
  • 金額の軸: 単価そのものは AppSheet 仲間の実際の提案価格を参考にする

「いくらが正解か」を一人で悩むより、すでに動いている人の値付けを参照する。私はそうして、大きくは外さずに済んだ。

受ける案件・受けない案件 — まだ実運用判断はしていない

受ける案件と受けない案件の線引きについても触れておきたい。ただ、ここは正直に書く。

私はまだ1件目の進行中で、実運用で線を引いた経験がない。だから「これは見送った」という体験談も、まだ持っていない。

強いて事前の線を挙げるなら、一つだけある。
AppSheet の制約を理解せず、何でもかんでも実装できると思っているところからの案件は受けたくない。とはいえ、その切り分けは一次受け側でされているはずなので、私のところまで回ってくる気はしていない。

もう一つ、実運用の線引きとは別に、私が最初から意識している軸がある。「自分のキャパで完結できるか」だ。本業を持ちながらの副業なので、納期や保守の重さが生活を圧迫しそうな案件は、単価が良くても私は気が進まない。逆に、窓口や契約を一次受けが持ってくれて、自分は実装に集中できる座組だと、私の場合はその不安がぐっと小さくなる。

結論: 未経験から3ヶ月でやること

ここまでが私の現在地だ。最後に、未経験から始めるなら最初の3ヶ月で何をやるか。
この1件をやってみて確実に言えるのは、結局この2点に尽きる。

  1. 学習源を1つに絞る: あれこれ手を出さず、信頼できる学習源を1本決めて深く追う
  2. 小さくても作って発信し続ける: 完璧な作品でなくていい。学んだ手応えを見える場所に置き続ける

私が学習源として絞ったのは、YouTube チャンネル「読み書きパソコン」だ。
実務で使うアプリを開発するなら、このチャンネルでやっていることをしっかり学習すれば、結構幅広いアプリの作成に対応できるようになると思う。

読み書きパソコン(@yomikakiPC)

副業全体の流れや再開のタイミング、中小企業側の内製化の視点も、いずれ別記事で書いていくつもりだ。


副業に失敗したとしても、全然痛くない技術は手元に残る。覚えた AppSheet は、副業につながらなくても役に立つ。

いまの仕事や普段の事務作業の効率化を自分で回せるし、AI で精度の高い回答生成の仕組みを作るときにも生きてくる。だから個人的には、かなりおすすめだ。

そもそも私がなぜ一度フリーランスを離れて会社員に戻り、それでも副業を続けているのか。その経緯は別記事に書いている。「会社員のまま副業」という今の立ち位置の背景として、よければ。