メインコンテンツへスキップ
メニュー

新しい提供物は自社で先に試すか:答えが出ない問いを先に書く

自社で先に動かすかは、早く形になるかではなく、答えが出る問いの種類で決めます。

この記事の要点

  • 自社運用で答えが出るのは「動くか」までだ
  • 「他人が払うか」は自社運用では答えが出ない
  • 答えが出る問いと出ない問いを、着手前に分けて書く
  • 外へ移す期日を先に置き、整備を目的にしない
自社で先に動かすかは、早く形になるかではなく、答えが出る問いの種類で決めます。
この記事の要点を図にしたものです。
目次

自社運用で答えが出るのは動くかまでだ

A&Aの考え方

これから外へ売ろうとしている新しいものを、ここでは提供物と呼びます。自社運用とは、その提供物をまず自分の会社の業務で動かすことです。

A&Aの考え方

次に出すものを自分用に作るのは、速くて気持ちがよい進め方です。要望を出す人と作る人が同じなので、仕様の確認が要りません。壊れても自分が困るだけなので、怖さもありません。

A&Aの考え方

とはいえ、この進め方で答えが出る問いの範囲は、思っているより狭いです。答えが出るのは、動くか、どこが壊れるか、維持に毎週どれだけ手がかかるか、の三つです。どれも自分の手元で観測できることです。

出典に基づく事実

Gumloop が自社のサポート運用について公開した記事が、この範囲の例になります。Gumloop は、業務の自動化を組み立てる道具を提供する会社です。

Gumloop ↗

出典に基づく事実

2026 年 2 月 17 日付の同社の記事は、自社のサポート運用を、すべての利用者が使えるのと同じ道具で組んだと書いています。特別な内部機能ではなく、一般の利用者が使える部品だけで組んだ、と記事には明記されています。

Gumloop ↗

出典に基づく事実

同じ記事は、サポートの担当が 2 人だけだとも書いています。そして記事の冒頭には、サポートに関わる自動化が週に 50 万件を超えて動いている、という数値が掲げられています。これは同社の自己申告で、何を数えたのかも、どう測ったのかも記事には書かれていません。

Gumloop ↗

A&Aの考え方

どの会社でも同じ数値になるとは考えないでおきます。

A&Aの考え方

この記事から読み取れるのは、Gumloop の業務でも成立する組み方ができた、というところまでです。同じ記事からは、その組み方を外の誰かが買うかどうかまでは分かりません。買う人がいるかどうかを、この記事は観測していないからです。

他人が払うかは自社運用では答えが出ない

A&Aの考え方

自社運用で答えが出ない問いが二つあります。他人が金を払うかどうかと、他人の入力が自分の入力と同じ形かどうかです。

A&Aの考え方

どちらも、外に人がいないと観測できません。自分は提供物の中身を全部知っているので、入力に揺れが出ません。自分は困りごとの当事者なので、払う理由を確かめる場面も来ません。

出典に基づく事実

Anthropic が公開している Chatbase の事例ページに、どちらの問いにも関わる記述があります。Chatbase は、企業の顧客対応を AI で自動化する仕組みを提供する会社です。

Anthropic ↗

出典に基づく事実

同ページによると、Chatbase は自社を最初の顧客として扱いました。その立場で、決まった形の問い合わせをさばくことに加えて、顧客の感情や製品への指摘まで取り出せることを見つけた、と書かれています。

Anthropic ↗

出典に基づく事実

同じページは、Chatbase の出発点についても書いています。文書と対話する画面として始まり、企業の顧客からより高度な機能を求められて今の形になった、という経緯です。

Anthropic ↗

A&Aの考え方

この二つの記述を並べると、順序が見えます。自社運用で見つかったのは機能の手がかりで、提供物の形を決めたのは外の顧客の要求でした。これは A&A の読み方で、出典自身がこの順序を主張しているわけではありません。

出典に基づく事実

出典のどちらも、自社を最初の利用者にしたことが売上や継続率を上げたとは述べていません。事例ページには利用が伸びたという記述もありますが、これは Chatbase の自己申告で、自社運用の効果を測った数値ではありません。

Gumloop ↗Anthropic ↗

答えが出る問いと出ない問いを着手前に分けて書く

A&Aの考え方

着手前にやることは、問いを二つの束に分けて書くことです。自社運用で答えが出る問いと、出ない問いです。

仮想例

A&A の設計案として、四つの欄からなる一枚の表を挙げます。これは仮の例で、実際の案件の記録ではありません。

仮想例

自社運用で答えが出る問い: 動くか、どこが壊れるか、毎週どれだけ手がかかるか

仮想例

自社運用では答えが出ない問い: 誰が払うか、いくらなら払うか、他人の入力はどんな形か

仮想例

外へ移す期日: 自社運用を終える日

仮想例

移す前に捨てる前提: 自分だけに当てはまっていた条件

A&Aの考え方

前の二欄を埋めてから着手します。空欄のまま始めると、始めてから「これで売れるか」を自社運用の中で確かめようとして、答えが出ないまま時間だけが延びます。

A&Aの考え方

四欄目の「捨てる前提」は、書きにくい欄です。自分の業務に合わせて置いた前提のうち、外の顧客では成り立たないものを書きます。使っている道具が揃っていること、用語が社内と同じこと、手順の順番が決まっていること、などです。

A&Aの考え方

受託の場合、出典の 2 社との違いがここに出ます。2 社はどちらも自社製品を多くの利用者へ提供する会社で、自社運用がそのまま製品の実利用例になります。特定の顧客へ個別に納品する受託では、自社の業務と顧客の業務が同じ形とは限りません。自社運用の結果が、顧客の受け入れ条件を示すとは限らないということです。

外へ移す期日を先に置き、整備を目的にしない

A&Aの考え方

外へ移す期日は、自社運用を始める前に置きます。後から置こうとすると、置けなくなるからです。

A&Aの考え方

自社運用には、終わりの条件がありません。自分が使っている限り、直すところはいつでも見つかります。しかも、直すたびに良くなるので、進んでいる感覚が続きます。期日が無いと、整備そのものが目的に変わります。

A&Aの考え方

期日は日付で置きます。達成条件で置かないのが要点です。「使える状態になったら外へ」という決め方では、使える状態かどうかを自分が判定するので、外へ出す日はいくらでも先に延びます。

A&Aの考え方

期日が来た日にやることは、二欄目に書いた「答えが出ない問い」を外の人に聞くことです。完成を待たずに聞きます。出典の事例では、外からの要求が来たあとに形が変わっています。

A&Aの考え方

ここで、自社運用が持ち込む偏りに触れておきます。自分は、その提供物にいちばん詳しい利用者です。自分が迷わなかった操作でも、外の利用者は迷う可能性が高いです。この偏りは使い込むほど強くなるので、期日を延ばすほど不利になります。

まとめ

A&Aの考え方

自社運用が答えるのは、動くか、どこが壊れるか、毎週どれだけ手がかかるか、までです

A&Aの考え方

誰が払うかと、他人の入力の形は、自社運用では答えが出ません

A&Aの考え方

着手前に、答えが出る問いと出ない問いを二つの束に分けて書きます

A&Aの考え方

外へ移す期日は日付で置き、達成条件では置きません

A&Aの考え方

自社運用は検証の代わりではなく、外へ出す前の整備です。そう考えると、期日を置くことに抵抗がなくなります。

次に出す提供物を自分の会社の業務で先に動かすかどうかは、早く形になるかどうかではなく、その動かし方で答えが出る問いの種類で決まります。自社運用が答えるのは、動くか、どこが壊れるか、維持に毎週どれだけ手がかかるか、までです。誰が払うかと、他人の入力がどんな形かは、外に人がいないかぎり観測できません。だから着手前に、答えが出る問いと出ない問いを二つの束に分けて書き、外へ移す期日を達成条件ではなく日付で先に置きます。自社運用は検証の代わりではなく、外へ出す前の整備です。そのうえ、自分はその提供物にいちばん詳しい利用者なので、使い込むほど外の利用者とのずれは大きくなります。

よくある質問

自社で動かさずに、いきなり外の顧客で試してはいけませんか

いけなくはありません。壊れたときは、その説明に時間を取られます。その分を自分が引き受けられるなら、そのほうが早く答えが出ます。判断の分かれ目は、壊れたときに失う信用の大きさです。失うものが小さい相手がいるなら、外から始める進め方は成り立ちます。

自社運用の期間は、どのくらいが適切ですか

適切な長さは示せません。A&A は、自社運用を始めてから外へ出すまでにかかった日数を測っていないので、日数の目安は出しません。決め方として言えるのは、動くかどうかを確かめるのに必要な日数を自分で見積もり、終わりの日付を先に書く、という手順だけです。

自社の業務と顧客の業務が違いすぎる場合はどうしますか

その場合は、自社運用で答えが出る問いの欄が短くなります。欄が「動くか」だけになるなら、自社運用でできることは、ほぼ動作確認だけです。自社運用の日数は短く置き、残りの問いは外の人に聞く計画にします。

出典・編集情報

記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。

  1. Supporting the world's most AI-native companies with a 2-person team

    Gumloop · February 17, 2026

    確認日 2026-10-20
  2. Chatbase Claude Platform (API) case study

    Anthropic · undated case study page

    確認日 2026-10-20

編集方針

← 記事一覧へ