マイクロビジネスの収益化——受託×新規×OSS

💼土台: 確実に現金になる受託

新しいことに挑戦する余力は、確実な収入があってこそ生まれます。

私たちの場合、Webサイトの受託制作・保守が、実際に毎月の現金を生んでいる主軸です。地域クラブやNPO、中小企業のサイト運用を継続的に受けており、これが会社の土台になっています。派手さはありませんが、次の取り組みに時間とお金を割く余力は、ここから生まれています。

🌱種まき: まだ収益化前の新規事業

新規事業は、受託と同じ「今すぐ回収する」物差しで測ると芽を摘んでしまいます。

私たちはアプリやマーケットプレイス型のサービスにも取り組んでいますが、これらは現時点でまだ収益の主軸にはなっていません。共同開発のパートナーがいる取り組みもあれば、自分たちだけで進めているものもあります。受託のように「今月いくら」を追う事業ではなく、ユーザーが定着するかどうかをまず見る段階だと捉えています。焦って収益化を急ぐより、使われ方を観察する期間を確保することを優先しています。

🔓無償: OSSという別の物差し

OSSは収益の物差しでは測らない、という割り切りをしています。

私たちは開発ツール系のOSSも公開していますが、これは直接の収益源として設計していません。ここでの狙いは、自分たちの開発運用の仕組みを外に出し、使ってもらいながら磨くことです。収益化を急がないぶん、機能追加や改善の判断を「儲かるか」ではなく「日々の運用で役に立つか」で決められるという利点があります。

具体的には、自社の開発ループを支える仕組みの一部を、社名やクレデンシャルを取り除く調整をした上でOSS側へ移植したことがあります。無償で外部に公開する前提だったからこそ、「他人が読んでも恥ずかしくない設計になっているか」という基準で棚卸しする機会になり、移植先での第三者レビューを通じて自社側の運用の粗（軽微な不具合）もいくつか見つかりました。収益化していれば後回しにしていたかもしれない改善が、無償公開という前提のおかげで先に進んだ、という一例です。

⚖️全部を同じ物差しで測らない

「これは何のためにやっているか」を事業ごとに言語化しておくと、判断がぶれにくくなります。

受託は「今月の現金」、新規事業は「定着するかの検証」、OSSは「実証と信頼の蓄積」——このように事業ごとに測る物差しを分けておくと、新規事業の伸びが遅くても焦らずに済みますし、逆に受託の手を抜いていい理由にもなりません。一人会社は判断者が自分しかいないぶん、この線引きを曖昧にすると、全部を「儲かっているか」で測ってしまい、時間のかかる取り組みを続けられなくなると感じています。

🧭まとめ: 土台・種まき・無償を分けて考える

整理します。①確実な受託収入を土台にする②新規事業は「定着するか」を先に見る、収益化を急がない③OSSは収益ではなく実証と信頼の蓄積という別の目的で運用する④事業ごとに測る物差しを言語化しておく。

全部を同じ基準で急がせないこと。これが、限られた時間で複数の取り組みを同時に進める上で、実際に効いていると感じている考え方です。

📚参考・出典

• GitHub Open Source Guides: Getting Paid for Open Source Work（OSS の活動に資金を得る手段をGitHubが整理しているガイド）
• GitHub Docs: About GitHub Sponsors（支援の受け取り方と手数料の扱いについてGitHubが示している公式ドキュメント）