2022年2月1日より、スキルマーケット(副業マッチングサイト)のCoconalaさんに登録し、約1年間「ExcelVBA開発」での副業をやってみました。
ありがたいことに多くのご好評、ご評価をいただける結果となり、
また別業種の扱うExcelファイルを見てその困りごとを解決することで、
自分の業界ではできない経験をさせていただきました。
とても勉強になることが多かったので、
しっかり記録と考察を残しておきたいと思います。
VBA開発での副業に興味がある方は、よろしければご参考ください。
実績
◇ 件数
| 相談(見積)件数 | 91件 |
| 受注件数 | 71件 |
| 成約率 | 78% |
◇ 単価
| 平均販売額 | 24,162円 |
| 平均収入額 | 21,452円 |
| 総作業時間 | 387時間 |
| 時間単価 | 3,860円/時間 |
◇ 時間内訳
| 概要確認～見積り | 40時間 | 10% |
| 詳細打合せ | 50時間 | 15% |
| メインコーディング | 200時間 | 51% |
| テスト・不具合修正 | 60時間 | 15% |
| 納品・調整 | 20時間 | 8% |
◇ 総括
スタート時の目標は「非課税の20万円/年を超えないくらい」でしたが、
最終的には目標対比+650%みたいなよくわからない実績になりました笑
自分の時間単価を5,000円/hとして見積りをしていましたが、
結果的には3,860円/hとなっています。
ココナラさんは売上額の22%を手数料として支払いますので、
5,000円/hでの見積りだと収入が3,900/hになると考えると、
そこそこ正確に見積りできていたように思います。
副業を始めるにあたり「自分の作業時間を計測してみたい」という興味もあったため、
結構細かく作業時間を分けて集計してみました。
結果をみると、「プログラミングしてる時間は総時間の半分くらい」だったようです。
少ないような、多いような、絶妙なラインでしたね。
とりあえず大まかな実績はこんな感じでした。
あとは気づいた点を列挙していきたいと思いますので、
興味がある項目をお読みいただければと思います。
考察
見積り（工数の積算）
スタート当初、一番苦労したのが見積りでした。
多くの方が通る道かと思いますが、最初はすごく安く見積もってしまいます笑
安く見積もってしまうのは2つの原因があって、
- 受注件数が少ないうちは成約率を重視してしまう
- 製作にかかる時間を少なく見積もってしまう
なんですが、まあ1つ目は戦略として致し方ないところもあるのでおいておき、
問題は2です。
はじめた時、副業のやり方をレクチャーしてくれた先輩たちから、
「感覚で見積もった額の大体"倍"くらいが適性額」
と教えてもらい、「そんなことないやろ～」と思ってましたがガチでした笑
Excel+VBAは内製でのアジャイル開発に特化している言語なので、
社内開発では仕様調査はそこそこにとりあえず作って使ってもらい、
「一緒に仕事をしながら完成させていく」なんてことができます。
テストすらリリース後にやることも可能です。
しかし受注開発となると、「ある程度仕様を決めてあとはその通り作る」ことになり、
これがかなり時間を食います。
機能調整が1つ入るだけでも「打合せ⇔コーディング」のやり取りが出ますし、
疑問点がひとつ出るだけでもコーディングが中断します。
もちろん業界・業務を理解する時間が圧倒的に少ないのは当然として、
それを差し引いてなお「受注開発は社内開発の倍時間がかかる」
と言って、あながち間違いではないのかもしれません。
このあたり、本業でのVBA内製に慣れていて「おおよそのコーディング時間がわかる人」ほど積算を誤る気がします。
とはいえ、解決策は数をこなして感覚を磨くしかなさそうです。
私は最初の3ヶ月の時間単価が2,000円を割っていましたが、
そのあとは4,000円を割らなくなりました。（本当に倍ですね）
最低単価の案件は780円/hになってるやつがありますが、
今となってはいい思い出です笑
購入前の打ち合わせ
見積りを行うためにはもちろん先に調査が必要なのですが、
- きっちり調査しないと正確に見積りが出せない
- きっちり調査すると成約しなかったときに調査の工数丸損
というジレンマがあります。
正確に見積りができるならもう半分くらいは仕事が終わっていると思いますので、
絶対購入してもらえるという確信がないとそんなことできません。
また、ココナラさんは「購入するまで通話ができない」という仕様のため、
購入前に正確に見積もろうとすると、テキストでのやり取りを強いられます。
「画面共有でしゃべりながら打合せできるのは購入後」
というのはなかなか大変ですよね。
ということで、私は途中から「見積り有料」にしてやっていました。
- まず3,000円くらいで買ってもらい、見積りを通話+画面共有で行う
- 通話＋画面共有ができない方の依頼は承らない
という感じで。
これがかなりいい方向に働き、
- 相当正確な見積りを出した上で正式にご購入いただける
- 相見積りの方、価格重視の方からは依頼が来ない
- やり取りがテキスト限定(打合せが好きでない)方からは依頼が来ない
ということで、お互いWinWinのマッチングができました。
概要だけで積算する場合の「多めに見積り」分の金額が減り、
打合せ自体の工数もメッセージのやりとりが減る分低くなるため、
結果的にコストパフォーマンスがいいものを提供できたと思います。
もともと私は値段では勝負できないですし、特にExcelVBAは安価でやれる範囲が広い言語なので、質と打合せ重視のお客様と取引できるとお互いにメリットがありました。
これが俗にいう「誰に売るかより誰に売らないかをまず決めろ」ってやつなんですかね。
受注が減ってもいいやと開き直ってやった見積り有料でしたが、
結果的には受注も単価も増えました。
テストと不具合修正
こちらも内製開発に特化したVBAの言語仕様が立ちはだかりました。
VBAという言語は
- エラーが起きると止まったコードをその場で見れる
- イミディエイトウィンドウが高性能
- 対してエラー処理用の機能はだいぶ貧弱
という言語仕様なので、究極エラー処理なんてまったくやらずに、
「デバッグって画面が出たらその場で電話して！」
とやるのが最大効率の言語だと思いますが、受注開発だとさすがにそれができません。
ということで、ある程度は例外処理をきっちり書く必要があるのですが、
今度は「お客様のデータがどこまでの精度かわからない」問題があります。
ちゃんとしたDBをつかう多言語と違い、データソースがExcelのVBAは、
日付列に文字列が入ってるなんて往々にして起きますからね。
しかもお客様からすべてのデータをもらえないことが多いので、
データの形式が正しくない問題にどこまで対処するかが難しいです。
結局私はその旨をお客様に説明し、
「デバッグって画面が出たらその場で電話して！」
に近い方法で対応していました。
が、これは私が在宅勤務などが多く、
多少のエラーは本業時間中でもすぐに対応できたからなんとかなった感じがします。
このため「副業だと終業時間外でしか対応ができない」という方は、
ここの部分での工数肥大を想定しておく必要がありそうです。
自作のライブラリを使用するかどうか
以下の記事でも書いている通り、私はかなり自作ライブラリを使う方なのですが、
副業で納品するマクロでどこまでライブラリを使うかは迷いました。
が、結論ガンガン使いまくりました。
はじめのうちはライブラリを使わないのも試してみたのですが、
不具合を書く確率が違いすぎることを痛感してやめました。
ライブラリって、楽に作れるとか、コーディング量が減るとかより、
使い古している分圧倒的にバグを書かないのが大きいですね。
まずはしっかり動くことのがなにより大事だと思いましたので、
Callしかしてないようなマクロも臆せず作るようになりました。
ちなみにお客様が「自分でメンテもしたい」と要望された場合は、
当然ですがライブラリは使用しないです。
ソースコードをオープンにするか
個人的にはソースコードはオープンにした方がいいと思っています。
先ほどあげた言語仕様の通り、
- エラーが起きると止まったコードをその場で見れる
- イミディエイトウィンドウが高性能
- 対してエラー処理用の機能はだいぶ貧弱
このあたりの問題があるため、
もし非表示にするとなるとかなりの精度のエラー処理が求められますし、
いざというときに「デバッグ画面をスクショしてもらう」ができないのはなかなか大変だと思います。
加えて
- ノンプロのユーザーでも多少の改修であれば実施できる
というのもVBAの大きな長所と思いますので、
せっかくVBAでシステムを作るなら、ソースコードは公開した方が良いと思います。
変数名・関数名について
副業の個人開発でプログラマではない事務職の方に納品するのであれば、
変数・関数名は間違いなく日本語で書くべき、
というより「シートに書いてある文字と一致させるべき」と思います。
- シート名が「企業一覧」なのに「CompanyList」という変数名
- 列名が「価格」なのに「price」という変数名
- 「貸方」「借方」が謎の変数名
あたりの「違う用語を当てている」状態は、
不要な労力をすべての関係者に強いてしまいます。
製作者すでにいないマクロの改修依頼も結構受注しましたが、
シート上の記載とコード上の記載が違うというだけで、
改修難易度が爆上がりするのが実感できます。
このあたりの愚痴は以下の記事に書いてありますので、
興味がある方は是非どうぞ。
英訳してはいけない変数名第1位「ワークシート」
英訳してはいけない変数名第2位「列見出し名」
英訳してはいけない変数名第3位「専門用語」
フィードバックが欲しくなる
最後にこれは個人的な趣向の話かもしれませんが。
私は本業では企画部で業務改善を担当しており、
- 課題を探す
- 解決策を協議する
- 解決策がExcelであればVBAを製作する
Excelでなければベンダー調整役などを担う - 解決策の運用を支援する
- 課題が解消したかを検証する
という流れで仕事をしています。
それと副業での開発を比べると、こんな感じになります。
この表の通りなんですが、本業(≒社内開発)で扱うExcelVBAとは違い、
- まずExcelでやるべきか考える
- どんなアプリ・システムで解決するか考える
- そもそもこの業務をやる意味があるのか考える
といった「どんな解決策を取るかを考える」ことが副業(≒受注開発)ではできません。
もちろんある程度コンサルも兼ねるSIerさんたちはこの辺もやると思いますが、
個人開発の副業ですと、大体は赤い範囲の仕事しかできません。
「これExcelでやらない方がいいですよ」
「この集計表は誰も見てないからやめましょう」
なんてなかなか言えませんからね。
Excel以外のスキルも豊富でこのあたりの「解決策の協議」が好きな人は、
もうやることが決まっている受注開発は窮屈に感じるかもしれません。
また、製作が終わり納品した後の、
「実際の運用」や「効果の検証」にもなかなか携われません。
マクロがどのくらい成果を上げたのかどころか、
そもそも使ってくれたのかも意外と知ることができませんでした。
私はここが結構気になって、
VBAというのはあくまで手段であり目的はその先にあると思っているので、
どうしても不完全燃焼感が拭えないことも多かったです。
また、実際に使うユーザーからダメ出しをもらったり、
どんな機能を使ってもらえ、どんな機能が使ってもらえないかを知る機会がないと、
なかなかシステム開発のスキル向上にはつながらないかもしれません。
コーディングスキルは上がると思いますけどね。
効果や要望といったフィードバックがないと寂しいという人は、
フィードバックをもらう方法を何とか考える必要がありそうです。
まあこのあたりは個人の感覚ですし、気にしたところでという部分なんですけどね。
以上、だいぶ長くなりましたが副業開発の記録と考察を終わります。
ここまでお読みいただいた皆さまありがとうございました！
たった1年しかやっていないので、ベテラン勢には役に立つ考察はなかったかもしれませんが、これから始める方には、多少なり参考になる部分があると思います。
もし副業を始めようか迷っているのであれば、ぜひやってみてください。
1件売れるだけでもすごくうれしいですし、
他の企業の業務を知れるのも、とても面白いです。
と言いながら、私自身は副業を今年でいったん休止にいたしました。
理由は単純で、ブログ執筆や勉強会での登壇の方が楽しかったからです。
なんだかんだ私は、教えたがりの人間のようです。
それを再確認できたのもまた、副業で学んだことかもしれません。
ということで、来年はブログの更新を増やすだけでなく、
ZoomやYouTubeなどを利用した勉強会なども開催したいと思います。
興味がある方はぜひご参加ください。
長文読了、お疲れさまでした！
