2026年、企業は社内向けソフトウェアを自社開発すべきか？（私たちは開発しました）

はい。2026年において、企業が社内向けソフトウェアを自社開発するという決定は、単なる自己満足のプロジェクトではなく、十分に理にかなった財務判断です。私たちが自信を持ってそう言えるのは、この1年間実際にそれを行ってきたからです。私たちのブログ、ナレッジベース、リリースノート、アンケート、ニュースレター、イベントトラッキングはすべて、自社で構築したプラットフォーム上で動作しています。ただし、この問いに対する完全な答えには後半部分があります。「ツールは開発し、インフラは購入する」ということです。この決定において後悔が生じる原因のほとんどは、この2つを混同してしまうことにあります。

なぜ社内ツールにおいて「開発か購入か」の力関係が逆転したのか？

開発コストが劇的に低下した一方で、利用料（レンタルコスト）が上昇し続けているからです。現在、平均的な企業は106個のSaaSアプリケーション（月払いまたは年払いのサブスクリプションソフトウェア）を利用しており¹、世界全体のSaaS支出額は2025年に約2,990億ドルに達すると予測され、前年の約2,510億ドルから増加しています²。これらの数値は公開時点のものであり、変化の激しい市場における当時のスナップショットとしてご理解ください。

かつては、これらのサブスクリプションはどれも、自社で開発するよりも安価でした。その計算は、開発には開発者を数ヶ月間雇う必要があるという前提に基づいていました。しかし、AIによるコード生成がその前提を覆しました。以前なら数ヶ月かかっていた社内ツールの開発プロジェクトが、今ではプロンプトの入力、レビュー、修正を数日間行うだけで完成することがよくあります。一方で、サブスクリプションの料金がそれに合わせて安くなることはありませんでした。アカウント（シート）ごとの課金体系は従業員が増えるたびに負担となり、本当に必要な機能は常に現在契約しているプランのワンランク上のプランに設定されています。

だからといって、開発が無料になるわけではありません。しかし、比較検討する価値が十分にあるほど、開発コストが安くなったのです。

私たちは実際に何を開発したのか？

私たちはPOSを提供する企業であり、最も課題の大きかった領域である「コンテンツ」から着手しました。以前のナレッジベースのワークフローでは、共有ドキュメントでヘルプ記事の下書きを作成し、変更があるたびにヘルプデスクツールにコピー＆ペーストしていましたが、そのツールの検索機能では折りたたまれたセクション内のテキストを検出できませんでした。この問題を解決するために、独自のコンテンツプラットフォームを構築しました。これが完成すると、ブログ、リリースノート、アンケート、ニュースレター、メールキャンペーンもこのプラットフォームに移行し、2026年6月にWordPressの使用を終了しました。

それ以来、開発リストは増え続けています。イベントトラッキング、営業見積もり用の提案書作成ツール、アプリ内チャットウィジェットなどです。次は、マーケティングオートメーション、CRM（顧客関係管理）、プロジェクト管理のサブスクリプションを置き換える予定です。それぞれのツールは、購入した既存の製品が特定の具体的なワークフローに対応できなくなったタイミングで開発されました。

内部からの2つの注意点があります。第一に、開発は無料ではありませんでした。創業者や開発者が実際に時間を費やしており、その時間は他の用途にも使えたはずです。第二に、自社で構築したツールは永遠に自社の管理下に置かれます。バグの修正もバックアップの作成も自社の責任であり、問い合わせるサポート窓口はありません。自分たち自身がサポート窓口だからです。私たちはこのトレードオフを理解した上で受け入れました。あなたも同様に受け入れるか、あるいは購入し続けるべきです。

依然として購入すべきソフトウェアとは？

誤りが発生した際にお金が失われたり、法的リスクが生じたりするものです。その筆頭が決済処理（カード決済の処理。カード業界のセキュリティ基準であるPCI準拠の対象）であり、税金計算、給与計算、そして会計の公式記録システム（すべてのデータが照合される信頼できる唯一の情報源）がこれに続きます。AIを活用した開発は、フォーム、ダッシュボード、トラッカー、スケジューラー、コンテンツシステムといった「ツールレイヤー」には適しています。しかし、実際の負荷がかかる中で常に正確に動作しなければならない「インフラレイヤー」には適していません。これと同じギャップは、汎用的なAIアプリビルダーでPOSを構築できるかという疑問にも当てはまります。

配布方法についても同様の考慮が必要です。社内ツールはブラウザ上で動作し、デプロイした瞬間に利用可能になります。しかし、アプリストアへの掲載が必要なものは、AIによって短縮されることのない数週間にわたる審査プロセスを経る必要があります。

私たちはこの自社ルールに従いました。すでに運用しているコマースインフラの上にコンテンツツールやトラッカーを構築し、決済の仕組みを再構築することはしませんでした。決済の再構築はおすすめしません。

開発するツールの優先順位をどう決めるか？

私たちは、以下の3つの質問を使ってリストを整理しました。

• 火曜日にこのツールが壊れた場合、それは「不便」ですか、それとも「大惨事」ですか？まずは「不便」なものから開発しましょう。

• 購入した製品は、特定の具体的なワークフローに対応できていませんか？「請求書が気に入らない」は仕様ではありません。「検索機能で記事の半分が見つからない」は具体的な課題です。

• 1年後に誰がそのツールを管理していますか？すべての社内ツールには、責任を持つ担当者が1人必要です。担当者が決まらないなら、開発すべきではありません。

「ソフトウェア企業だから言えることだ」という指摘もあるでしょう。確かにその通りです。しかし、私たちが最初に置き換えたのは、コンテンツ、アンケート、スケジュール管理といった、技術的な専門知識が最も不要なツールであり、その仕様策定の多くは本番コードを書かないスタッフによって行われました。実際に求められる要件は、「ソフトウェア企業であること」よりもシンプルです。社内の誰かがツールの誤りに気づくことができ、AIが生成した内容が実際のデータに反映される前にレビューできることです。AI機能を搭載したツールと、AIが構築できるツールの違いはここにあり、後者は人間がチェックできる場合にのみ機能します。

では、2026年に企業は社内向けソフトウェアを自社開発すべきでしょうか？

トラッカー、ダッシュボード、コンテンツシステム、スケジューラーなど、現在レンタルしている「ツールレイヤー」については、自社開発すべきです。一方で、決済、給与計算、税金、公式記録システムなど、数値の誤りが実質的な損失につながる「インフラレイヤー」については、自社開発すべきではありません。私たちは前者を再構築し、後者を購入し続けることで、サブスクリプションのリストを削減し続けています。「壊れたときに不便に感じるもの」は開発し、「間違っていたときに致命的な打撃を受けるもの」は購入しましょう。

最初に解約したいサブスクリプションがコマース関連のものである場合は、まず具体的なコストを算出することから始めてみてください。参考として、一般的な小売業者のソフトウェアサブスクリプションにかかる実際の年間コストをこちらで紹介しています。