外注か自作か——一人会社が「自分で作る／既製に乗る」を分ける基準
ツールを自作するか既製に乗るか、受託を自分でやるか。時間という最大の制約から、コアかどうかと可逆性でbuild/buyを切り分けている一人会社の判断基準を実例で。
一人会社にとって build（自作）か buy（既製に乗る）かの判断は、機能比較ではなく時間の配分の問題です。私たちは「それが自社のコアか」と「間違えたときに戻せるか」の2軸で切り分けています。
合同会社i-Willink は社長1名とAI COO の実質一人会社です。開発も受託も広報も同じ稼働時間の中から出しています。この制約の下では「作れるかどうか」より「作る時間をここに使っていいか」が先に来ます。この記事では、私たちが実際にどこで自作し、どこで既製品に乗り、受託ではなぜ外注せず自分でやっているかを、失敗も含めて等身大で書きます。
⏳主変数は「時間」——お金ではありません
一人会社の build/buy 判断で最初に効くのは金額ではなく、その作業に自分の稼働をどれだけ食われるかです。
一般的な build vs buy の議論はコストや機能の比較から入りがちです。ただ一人会社では、月額数千円の差より「セットアップと保守に何時間かかるか」のほうが桁違いに重い制約になります。作る時間はそのまま受託やプロダクト開発から削られるからです。
だから私たちは、あるツールを自作しようか迷ったとき、まず「これを自作したら、来週の受託や tsuu の開発を何時間手放すことになるか」を先に見積もります。ここが割に合わないなら、機能が多少不満でも既製品に乗る、というのが基本姿勢です。build vs buy を「時間の意思決定」として捉える発想自体は、ソフトウェア設計の議論でも繰り返し語られてきたものです（参考: martinfowler.com）。
🧭判断の2軸——コアか、戻せるか
時間見積もりの次に、「コアかどうか」と「可逆性」の2軸で build/buy を振り分けます。
私たちが使っている線引きはシンプルです。第一に、それが自社の差別化そのもの（コア）なら自作を検討します。誰でも既製品で置き換えられる部分（ノンコア）なら既製に乗ります。第二に、あとから乗り換え・撤退が効く（可逆）なら軽く試し、一度決めると抜けにくい（不可逆）なら慎重に既製の枯れたものを選びます。
自作（build）に寄せる
- 自社の運営構造そのものに関わる
- 既製品では業務にフィットしない
- 作った資産がOSSや実績として残る
既製に乗る（buy）
- 差別化に効かない共通基盤
- 保守が続く限りコストが乗り続ける
- 枯れた選択肢が既にある
コアで、かつ既製品がフィットしないものだけを自作に回す。この2軸を通すと、迷っていた候補の大半は「既製で十分」に落ちます。
🛠️自作した例——運営ツールを OSS 化した理由
自社の運営構造そのものはコアなので、willink-claude-kit として自分たちで作りました。
私たちが AI COO を運用するための土台（コマンド・ルール・自走ループの仕組み）は、既製のプロジェクト管理SaaSでは代替できませんでした。運営の型そのものが自社の差別化なので、ここは自作を選び、willink-claude-kit として整備しています。実際にこのツール群は複数の自社スタックで日々動いており、単なる自己満足の内製ではなく実運用の資産として残っています。
一方で、この土台の下で使っている個別の道具はほとんど既製です。フレームワークは Next.js（nextjs.org）、デプロイや自動化は GitHub の仕組み（github.com）に乗せています。ここを自作しても差別化にはならないので、乗れるものには素直に乗る、という切り分けです。
🤝受託は「自分でやる」——なぜ外注しないか
WordPress の受託案件は再委託せず、社長とAI COO で自前で回しています。
受託開発でも build/buy に似た判断が発生します。案件を自分でやるか、誰かに再委託するか、です。私たちは月に20〜40万円ほどの WordPress 受託を数サイト回していますが、これを外注に流さず自前でやっています。理由は品質と、AI COO を使えば一人でも回せる稼働構造にあります。
受託は口頭で受注が固まっているケースが多く、私たちは提案書づくりのような形式的な工程には時間をかけていません。その分の時間を、実装と自社プロダクトの充実に振り向けています。ここでも判断軸は同じです。顧客との信頼関係と品質判断はコアなので手放さない、形式的な書類仕事は削る、という引き算です。
🩹失敗から学んだ——不可逆を軽く扱わない
「作れるから作る」で外販SaaSを走らせて凍結した経験が、可逆性の軸を重くしました。
私たちは以前、社内向けに作った仕組みを SaaS として外販しようとしたことがあります。技術的には作れましたが、外販は価格・サポート・撤退のどれもが不可逆に近く、一人会社の稼働では支えきれませんでした。最終的にこの方針は凍結し、OSS と内部ツールに切り替えています。
この経験から学んだのは、「作れる」と「作るべき」は別だということです。特に不可逆な方向（外部公開・課金・撤退しにくいコミット）に踏み込むときは、コア性だけでなく「間違えたら戻せるか」を必ず見るようになりました。可逆なら小さく試して学べますが、不可逆は間違えると稼働ごと沈みます。
✅まとめ——build/buy は時間の設計です
コアなら自作、ノンコアなら既製、不可逆なら慎重に。根っこはどれも稼働時間の配分です。
一人会社の build/buy 判断は、突き詰めると「限られた時間をどこに置くか」に還元されます。私たちは運営の型のようなコアは自作し、フレームワークやデプロイ基盤のような共通部分は既製に乗り、受託は品質のために自前で回し、不可逆な賭けは可逆性を確かめてから踏み込む、という運用に落ち着いています。
もし今、何かを自作するか迷っているなら、機能表を比べる前に一度だけ問うてみてください。「これは自社のコアか」「間違えたら戻せるか」。この2つに答えるだけで、作るべきものと乗るべきものが、思ったより早く分かれるはずです。
開発パートナーを探していますか？
AIでプロダクトを最速で形にしませんか？
最短1週間でMVPを開発。アイデアの検証から本番リリースまで、i-Willinkがフルサポートします。まずはお気軽にご相談ください。
無料で相談する