# 静かなプロダクトを作るメモ

> 直接サポートが調査になるとき、自動化が値するとき、節制が小さなプロダクトを理解しやすく信頼できる状態に保つ方法を書きます。

Published: 2026-06-02 | Updated: 2026-08-08

Mole for Mac は、発売からおよそ 3 週間で小さな売上の節目を越えました。
数字の話ではなく、その過程で選んだいくつかの判断を書き残しておきたいです。
その多くは、現場のエンジニアの直感とは逆向きで、それでもいちばん先に守りたい判断でもあります。自分の製品を作っている方なら、遠回りをひとつ減らせるかもしれません。

## すべてのメールに自分で返します

発売以来、サポートはすべて手で処理しています。返金、
アクティベーションのリセット、値引き後の差額返金、ふつうの質問。
量は少なく、問い合わせてくるユーザーは 1% を大きく下回ります。
半時間あればエージェントに任せる仕組みも組めました。それでもやらなかった理由は、ふたつです。

ひとつは、サポートこそが製品の本音を教えてくれる場所だからです。返金依頼は、
なぜその人が失望したかを教えてくれます。ぎこちない質問は、アプリのどこが
自分を説明できていないかを教えてくれます。数通のやりとりで、ユーザーが本当に欲しかったものが浮かび上がり、
それは最初に聞かれたことと違うことも多いです。
初日に自動化で濾してしまうと、いちばん必要なときにシグナルを失います。

ふたつめは、すべての案件を自分で扱うと、言葉が身体に入るからです。回数を重ねると、
問題の型ごとの最善の答えがわかり、そもそも質問が生まれないように製品が引き取るべき問題も見えてきます。
量が増えて自動化を入れるときも、当てずっぽうではなく、その習熟をコードに載せられます。

自動化の閾値は、チケット数ではありません。同じ質問が繰り返し、答えが安定し、
例外の輪郭がわかっていること。それまでは、雑多な会話そのものが調査です。
そのあとは、既知の道を自動化に任せつつ、珍しい案件が人に届きやすい形にすればよいです。

いまのところ、このやり方は持ちこたえています。マーケティングには一切お金を使っておらず、
成長は口コミで、返金率は 0.8% 未満です。

## 足場は後回しでよい

インフラも同じ論理です。発売前にチケットシステムも、
ヘルプデスクも、ナレッジベースも用意しませんでした。エンジニアは、支えとなる仕組みを先に作りたがります。
それは自分が作れる部分だからで、AI のおかげで半日仕事になり、ますます魅力的で、
同じくらい時期尚早な最適化になりやすいです。半日は本当に半日です。でも、
まだ要らないシステムを手入れし続けるコストも本物です。不在が依頼を落とし始めたり、
応答時間を隠し始めたり、同じ答えをばらつかせ始めたりしたときに足せばよいです。それまでは、
受信箱のほうが単純で、情報量も多いです。

## 何を作らないかを決める

よい製品とふつうの製品の差は、ほとんどが「やらないこと」にあります。どの機能をどのリリースに載せ、
どの要望が本物の必要で、どれはそう聞こえるだけか。それ自体はよいアイデアでも、
この製品には置かないもの。私は、それ単体ではよい機能提案をくれたユーザーに、
何度もお詫びしてきました。Mac には心地よい技がたくさんありますが、Mole がやるべきではないものもあります。
すべてに「はい」と言うとシチューになり、シチューは保守が難しく、ファイル削除を任せるにはなおさら信頼しにくいです。

私は、製品の先およそ半年の道筋を頭に置いています。各バージョンが何を足し、何を外に置き、
初回ユーザーが説明なしで辿り着ける場所にどう着地させるか。よくある最初の作業にマニュアルが要るなら、
いちばん届けたい人に対して、そのインターフェースはすでに失敗しています。ドキュメントは、深さや
境界ケース、信頼のためにはまだ必要ですが、製品の基本のかたちを救うものであってはいけません。
古くからの剃刀が言い得て妙です。必要でないかぎり、実体を増やさない。

いまは、機能がロードマップに載る前に三つの拒否条件を使っています。ユーザーがその機能に入っていないのに、
常時タイマーやリスナー、サンプリングのコストを足さないこと。
小さな便利のためだけに、特権ヘルパーを広げたり、新しい権限を求めたりしないこと。
そして、落ち着いた既定値ですべての人の代わりに決められるなら、設定項目を足さないこと。
ソフトウェア全般の普遍則ではありません。この製品のための予算です。常駐の仕事、特権、設定は、
いずれもユーザーがずっと信じ続けなければならない表面積の形です。

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/quiet-product-loop.webp" width="1360" height="454" loading="lazy" alt="製品判断ループでは直接の会話がユーザ文脈を保ち、繰り返しニーズがプロダクトフィット、信頼と安全、自己説明のゲートを通ってから固定、予定、または却下され、早い自動化は信号を失います">
  <figcaption>直接の会話は、繰り返しの必要がはっきりするまで文脈を保ちます。製品適合、信頼、自己説明が、修正にするか、ロードマップに載せるか、意図的な「いいえ」にするかを決めます。よい修正は、将来の質問を減らします。</figcaption>
</figure>

## 立ち位置

Mole の立ち位置は一文です。Mac のための、静かな守り手。掃除し、
アンインストールし、最適化し、分析し、見守り、それ以外は邪魔をしません。
野心は言い方は単純です。Mac ユーザー百人に一人が Mole を手元に残してくれるなら、
本当に役に立ったことになります。最近は視覚に障害のあるユーザーも使い始め、
粗いところに当たったので、新機能よりアクセシビリティの修正を前に出しました。
彼らにとってアプリがどう感じられるか、楽しみにしています。静かな守り手は、
誰にとっても静かであるべきです。

## AI 時代に、製品を人間のまま保つ

AI のおかげで、この製品のかなりの部分が可能になりました。それでも、使う人との会話に
取って代わることはなく、そうあるべきでもないと思います。効率はいま買えます。
開発者とユーザーのあいだの感覚と信頼は、まだ一通ずつの会話で積み上げるしかありません。
AI で作られた製品が人の温かさを保つ仕方は、あるいはそこにあるのかもしれません。コードは生成できても、
関係は生成できない。

これは私にとって初めての有料製品で、ここでの判断のいくつかは、のちに間違っていたとわかるかもしれません。
この道をもう長く歩いていて、私の愚かなところが見える方がいたら、ぜひ教えてください。
Mole がそもそもここに至るまでの話は、もう少し長く、
[500 行のシェルスクリプトから Mac アプリへ](https://mole.fit/ja/blog/the-story-of-mole)
に書いてあります。

---

Canonical HTML page: https://mole.fit/ja/blog/notes-on-building-a-quiet-product
Blog index for agents: https://mole.fit/ja/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
