ほとんどの会社が逆から尋ねてしまう問い
私はこの問いの、いちばん痛い側で10年近くを過ごしてきました。
前職では7年間、社内ツールをつくることが私の仕事そのものでした。片手間の取り組みでも、四半期の施策でもありません。毎日やっていた仕事であり、それと同じだけ難しく、地味な仕事——つくったものを実際に使ってもらう——がいつも付いてきました。いまはAgentUIのCEOとして、ほかの会社がまさにこの判断を下すのを手伝っています。ですから「つくるべきか、買うべきか」と聞かれたとき、私はどこかで読んだフレームワークを取り出しはしません。取り出すのは、自分の傷跡です。
学んだことを短くまとめると、こうなります。ほとんどの会社は問いを逆から立てています。最初に「これは買えるだろうか」と尋ねますが、出発点としてより良い問いは「この業務プロセスは、うちだけのものか」です。この二つは同じ問いではありません。そして混同すると、何年も失います。
順を追って説明します。
誰もが取り違える原則
世間の常識は、紙の上ではそれなりに筋が通っています。まず市販のソフトウェアを試し、どうしても合うものがないときだけ自分でつくれ、と。私たちはその原則をほとんど信仰のように守っていました。つくる前に、いつも買おうとしたのです。
問題は、その「試す」が現場で実際どういう姿になるかでした。業務の中核をなす領域ひとつのために、私たちは何年も——数週間ではなく、何年も——購入したソフトウェアを回そうと費やしました。その間、別々のツールを2つ走らせました。どちらも失敗しました。そして毎回、失敗の理由は同じでした。ソフトウェアを私たちの業務に合わせるのではなく、私たちの業務をソフトウェアに合わせることを要求されたからです。
この一文が、この議論のすべてを縮めたものです。本当に自社だけに固有のプロセスのために市販のソフトウェアを買うとき、あなたが買っているのは解決策ではありません。働き方まるごとの改修工事を買っているのであり、その工事はいつまでも完工しません。あらゆる回避策、「この部分だけは別途Excelでやろう」というあらゆる妥協、なぜこのツールは当たり前のことをしてくれないのかを説明するあらゆる研修時間。それが、他人の前提に自社を押し込むためのコストです。
誰も教えてくれないのは、そのコストが請求書には現れないということです。ソフトウェアには値札があります。何年分もの業務上の摩擦には、値札がありません。
事例:世界を開いた営業ツール
具体的に話します。抽象論はうなずくのが簡単で、動くのが難しいからです。
私がつくった中でいちばん大きなツールは、営業担当者のためのものでした。それができる前、見積書を1通つくるのは手作業の苦行でした。担当者はいくつものExcelファイルをつなぎ合わせ、最新かどうかも分からない在庫データを探し回り、技術情報——仕様書、PDF、提案資料——をその時々に置かれている場所から掘り出さなければなりませんでした。遅く、間違いが起きやすく、そして担当者本人が「何がどこにあるか」を知っているかどうかに完全に依存していました。
そこで私たちは、担当者がログインしてリアルタイムの在庫を見て、その場で見積書をつくれるツールをつくりました。解けたのは速さだけではありません。すべての技術情報が一か所に集まったことです。製品をクリックすれば、全部が見えました。仕様、ドキュメント、PDF、提案の進め方まで。そして——ここがいちばん大事な部分でしたが——その一式をワンクリックで顧客に共有できました。
このツールは、つくり始めた時点では私が予想しきれていなかったことをやってのけました。**それまで届いたことのなかった世界中の顧客を獲得できるようになったのです。**別の大陸にいる見込み客が、完結していて、体裁が整っていて、技術的に詳細な見積を、数日ではなく数分で受け取れるようになると、距離は問題ではなくなります。このツールは私たちを速くしただけではありません。自信を持って応えられる市場そのものの大きさを広げたのです。
どんな市販の製品も、それをやってくれることはありませんでした。私たちの在庫、私たちの技術文書、私たちの営業の進め方を、私たちと同じだけ理解している市販製品はなかったからです。試しはしました。先ほどの2つのツールと、失われた年月を覚えていますか。まさにこれを置き換えようとして、失敗したのです。
では、いつ買うべきか
ここまで読んで、私が「何でも自分でつくれ」と言う人間だと思われたなら、すぐに訂正させてください。違います。
**私ならCRMは絶対につくりません。**私たちのCRMは買っています。例外なしです。そして、ほぼすべての人に同じことを勧めます。
違いはこうです。CRMはメールをはじめ十数種類のツールと連携する必要があります。本当に複雑で成熟した分野であり、既存の製品が頑丈なのは、何千社もが何年も叩き続けてきたからにほかなりません。自前でつくって得られる固有の優位はありません。膨大な労力を注いで、よくても初日に買えたものより少し劣るものにたどり着くだけです。
それが判断基準であり、たいていの「つくるか買うか」のフレームワークより単純です。
- 問題が普遍的なら、買う。 ほかに100社が同じ必要を抱えているなら、誰かがすでにあなたより良いものをつくっていて、しかもすでにあらゆるものと連携させています。CRM、メール、会計、給与計算——これらは解決済みです。作り直さないでください。
- **プロセスが自社だけのものなら、つくる。**自社の回り方にしか当てはまらない業務の流れがあるなら——たとえば私たちが技術見積書をつくっていたやり方のような——そこが、つくることに意味が出る瞬間です。合う製品は存在しません。そのプロセスは自社の壁の内側にしか存在しないからです。
決め手になる問いは「これ用のソフトウェアは存在するか」では決してありません。**「ここで私たちがやっていることは、どんな汎用ツールにも収まらないほど違うのか」**です。違うならつくる。違わないなら買って、先へ進む。
AIが実際に変えたこと
私のキャリアのほとんどの期間、この判断には残酷な但し書きが付いていました。つくるほうが明らかに正しい場合でさえ、それは高くついたのです。開発者が必要でした。時間が必要でした。つくるという選択肢は理屈の上では正しく、現実にはしばしば手が届かない。だからこれほど多くの会社が、合わないツールを買うほうに流れ、そして私たちのように何年も苦しんできました。
AIがその但し書きを消しました。そしてここが、私が心から面白いと感じている部分です。
古い世界は、業務のすべてをソフトウェアに合わせろと強いました。新しい世界は、事業のほうに合うソフトウェアをつくらせてくれます。この向きが逆転したことがすべてです。どの事業もそれぞれに違っていて、そしていま初めて、開発者の大軍を抱えずに、自社の業務と会社の回し方そのものをデジタル化したシステムを持てるようになりました。
私たちがAgentUIでつくっているのは、まさにこれです。開発者を採用して何か月も待つ代わりに、必要な社内ツールをAIで自分でつくれる、という考え方です。念のために言えば、開発者の仕事がなくなるわけではまったくありません。顧客が直接触れる製品なら、私は迷わず開発者に頼みます。顧客が触れるものには、それだけの手間と作り込みがふさわしいからです。けれど社内のツールなら? たいていの場合、もう必要ありません。必要なのは、AIと、自分でつくれるツールです。
これは「つくるか買うか」の計算を、見くびられがちなかたちで動かします。つくるのが高くついた時代には、痛みを伴ってでも「買って業務を曲げる」ことが合理的な選択であることが多かった。つくるのが安く速くなったいま、天秤は「本当に自社のものであるものは、つくる」へと大きく傾きます。
よく受ける2つの反論
この話をするたび、ほぼ必ず出てくる懸念が2つあります。もっともな懸念で、まっすぐ答える価値があります。
「セキュリティはどうなるのか」
これが最大の懸念です。情報が漏れること、権限のない人がデータに触れること、不正アクセスや情報の喪失を、企業は心配します。当然の不安です。自前でツールをつくることは、歴史的に自前でセキュリティの頭痛も抱えることを意味してきました。ここはAgentUIがマネージドインフラで直接解決している部分で、つくったものが既定で安全に保たれるようにしています。社内ツールをつくるためにセキュリティの専門家になる必要はありませんし、「自社に合うこと」と「情報漏えいを起こさないこと」のどちらかを選ばされるべきでもありません。
「永遠に保守し続けることになるのでは?」
こちらは保守と技術的負債への恐れで、良い「つくる」判断を静かに潰してしまうのはこちらのほうです。つくるということは、終わりのない手入れに申し込むことだ、という前提があります。けれど見落とされがちなのは、つくるのをやめてよい地点が来る、ということです。ツールは役目を果たし、あなたはそこから手を離す。そして本当に厄介な部分——その下で動くインフラの維持、実際に憂鬱を生んでいる部分——は、まさに私たちが裏側で引き受けているところです。だからひとつひとつに付きっきりになる必要はありません。つくって、仕上げて、次へ進む。
あえての持論:大聖堂を建てようとするのをやめる
ここからは私が旗を立てる意見で、「つくる」と決めたあとでさえ多くの人が取り違えていると思っている点です。
巨大なシステムをゼロから建てようとしないこと。ほとんどの場合、それは悪手です。
自社でソフトウェアをつくることに会社が興奮しはじめると、本能は巨大化へ向かいます——事業全体を回す壮大な社内プラットフォームを設計しよう、と。つくるプロジェクトが死ぬのは、その道筋です。価値を届ける前に、自分の野心の重みで潰れてしまう。
はるかに良い一手は、いますでに手作業でやっているプロセス——いまExcelの中で生きていて、自社だけに固有のもの——をデジタル化することです。それだけです。チームが嫌がっているあのスプレッドシート、毎週何時間も食いつぶしている手作業のつなぎ合わせ、自社だけが自社独自のやり方でやっていること。それをつくる。小さくて、具体的で、見返りがはっきりしていて、しかもどんな市販ツールもうまく扱えない類のものです。
壮大な構想ではなく、痛いスプレッドシートから始めてください。大聖堂は待てます。私たちに世界を開いたあの見積ツールも、月に行く計画として始まったわけではありません。「この手作業がつらすぎる、直そう」として始まったのです。
結論
普遍的なものは買う。本当に自社のものは、つくる。はじめから自社のために設計されていないソフトウェアに業務を曲げないでください——私たちは何年もその間違いを犯し、失った時間と失った機会というかたちで請求が来ました。そして何をつくるにせよ、小さく始め、すでに理解している手作業から始め、そこからツールを育ててください。
私のキャリアのほとんどの期間、この助言には「つくるのは贅沢だ」という但し書きが付いていました。もう付きません。かつては開発者と何四半期もの作業を要したものが、いまではそのプロセスを本当に理解している人——つまり、あなた——の手でつくれます。
それが本当の変化です。問いは、はじめから「つくるか買うか」だけではありませんでした。自分たちの実際の働き方に合うソフトウェアを持つ余裕があるのか、という問いでした。いまは、あります。