作るか、使うかi-Willink
作るか既製を使うか——小さな会社の2つの判断軸
道具やシステムを自分で作るか、既製のものを使うか。人の少ない会社では、機能や金額の比較より、時間をどこに使うかの問題になります。「自社の芯か」と「間違えても戻せるか」の2軸で決めている判断を、作るのをやめた実例とあわせて書きます。
作るか既製を使うかは、機能や金額より時間の配分で決まります。私たちは「それが自社の芯か」と「間違えたときに戻せるか」の2軸で切り分け、芯で、かつ既製では合わないものだけを作っています。
AIのおかげで、作ること自体はずいぶん安くなりました。だからこそ、何でも作れてしまう誘惑があります。けれど作った物には、直す・更新する・説明するという手間がずっとついてきます。
私たちは社長1名とAIで会社を回しているので、何かを作ると決めることは、ほかの何かに使う時間を手放すことと同じです。この記事では、私たちが使っている判断の2軸と、作るのをやめた例・作った例を紹介します。
この記事の要点
- 1最初に見るのは金額でなく、作った場合に、ほかの仕事の時間をどれだけ手放すか
- 2自社の芯（ほかで置き換えられないもの）で、かつ既製では合わないものだけを作る。それ以外は既製に乗る
- 3外に売る・お金を取る・やめにくい約束のように戻しにくい方向は、作れても慎重に決める
最初に見るのは時間
人の少ない会社では、月額数千円の差より、作って直し続ける時間のほうがずっと重い制約になります。
作るか使うかの話は、機能の表や月額の比較から始まりがちです。けれど人の少ない会社では、月に数千円の差より、作るのにかかる時間と、その後ずっと続く手直しの時間のほうが重くつきます。
だから私たちは、作ろうか迷ったとき、まず「これを作ったら、ほかの仕事の時間をどれだけ手放すか」を見積もります。割に合わないなら、機能に多少の不満があっても既製に乗ります。AIで作る速さが上がっても、この見積もりは省きません。作る時間が短くなっても、直し続ける時間は残るからです。
判断の2軸——芯か、戻せるか
1つ目は、それが自社の芯でほかに置き換えられないか。2つ目は、間違えたときに元に戻せるかです。
時間の見積もりの次に、2つの軸で振り分けます。
- 自社の芯か: ほかの会社の既製品で置き換えられるものは、作っても差になりません。置き換えられない、自社のやり方そのものに関わるものだけを作る候補にします。
- 間違えても戻せるか: 社内だけで使う道具なら、合わなければ捨てて既製に戻れます。外に売る、お金を取る、お客様と約束するといった方向は、始めたら戻しにくくなります。
芯で、かつ既製では合わないものだけを作る。この2軸を通すと、迷っていた候補の大半は「既製で十分」に落ちます。
作るのをやめた例——外に売るSaaS
2026年3月、社内向けの仕組みを外に売るSaaSとして作っていた計画を止め、無償公開と社内の道具に切り替えました。
私たちは以前、自分のクラウドに業務システムのひな形を配置できる仕組みを、外に売るSaaSとして作っていました。認証などの基本の機能はできあがり、技術的には作れる見通しが立っていました。
それでも2026年3月23日に、外に売るのをやめる決定をしました。記録に残した理由は4つです。具体的なお客様の姿がない。技術のある人は無償の公開版で同じことができる。使い続けてもらう理由がなく、継続して料金をいただく根拠がない。そして、作る動機の多くが会社を知ってもらうためだった、という点です。
外に売ると、値段、問い合わせへの対応、やめるときの説明まで、どれも戻しにくい約束になります。作れることと、作るべきことは別でした。この仕組みは無償の公開と社内の道具に切り替え、空いた時間を別の仕事に回しています。
作った例——会社の回し方の土台
AIに仕事を任せるためのルールや検査の仕組みは、既製のツールでは置き換えられない芯なので、自分たちで作っています。
反対に、自分たちで作っているのが、AIに仕事を任せるための土台です。何を任せ、どこで止め、どう確かめるかというルール、コマンド、検査の仕組みです。これは会社の回し方そのもので、既製のプロジェクト管理の道具では置き換えられませんでした。
この土台は、社内の1か所にまとめて持ち、そこから一部を公開版として切り出しています。作った物が、社内の道具として毎日使われ、同時に外に見せられる実績にもなる。芯を作るなら、そうした残り方をする物を選びます。
既製に乗った例——インフラ
サーバーやデプロイの基盤は差にならないので、既製のサービスに寄せています。2026年9月には、使うクラウドをさらに絞りました。
土台の下で使っている道具は、ほとんど既製です。Webの画面は広く使われているフレームワーク、変更の確認や公開の自動化は GitHub の仕組みに乗せています。
2026年9月8日には、新しく作るシステムの既定の構成を、Google の Firebase を中心にした形に切り替え、AWS はドメインの管理とメールの送信だけに使う、と決めました。複数のクラウドを使い分けて自前で組むより、1つに寄せて既製の仕組みに乗るほうが、保守の時間が少なくて済むからです。ここを自分たちで作り込んでも、お客様にとっての差にはなりません。
よくある質問
AIで作るのが速くなったなら、全部作ってしまえばよいのでは？
作る時間は短くなっても、直し続ける時間、更新に合わせる時間、使い方を説明する時間は残ります。作るかどうかは、その後の手間まで含めて決めます。
「自社の芯」はどう見分けますか？
ほかの会社の既製品で置き換えたら、お客様から見た違いがなくなるかどうかで見分けます。置き換えても違いが出ないものは、芯ではありません。
既製のツールに不満があるときは？
まず設定や使い方で埋められないかを試し、それでも業務に合わず、しかもそれが芯に関わる場合だけ作る候補にします。不満が芯でない部分なら、多少は我慢して既製に乗ります。
作った物をあとから既製に置き換えることはできますか？
社内だけで使う道具なら、比較的戻しやすいです。外に売ったりお客様と約束したりした物は戻しにくいので、そうした方向に踏み出す前に慎重に決めます。
参考・出典
- Utility Vs Strategic Dichotomy（Martin Fowler）（差を生む部分と、そうでない部分で作り方を分ける考え方）
- Firebase ドキュメント（Google）（私たちが新しいシステムの既定にしている既製の基盤）