第1週が命題を、第2週が証明をくれた。第3週はどうだ — 能力をツールとして形づくるとき、露出と非露出の線を実際にどこに引くか。
今週のSignal
線をどこに引くかが、すなわちアプリの性格だ。 同じサーバー、同じ能力でも、どのツールを差し出しどのツールを閉じるかによって、まったく違うアプリになる。露出一覧は能力の宣言であり、非露出は性格の宣言だ。 第3週の核心の話題がこれだった — 「何をできるようにするか」と同じくらい「何をできないままにしておくか」が設計だ。二つの一覧は一枚のコインの両面であり、その境界線が、アプリが誰のためのものかを語る。
境界は機能の制約ではなく、信頼の土台だ。 閉じておいたツールは欠けた機能ではなく約束だ。ブラックボックスが「映像は触らない」をツールの不在で約束したように、閉じることは使う人に与える保証になる。第3週の反応の中で印象深い一行 — 「閉じた部分があるから、かえって信じて使う。」何でもできるツールよりも、絶対にできないことが明確なツールのほうが信頼される。
Vol 4の中心に達した。 すべてのサーバーがアプリになれるという可能性と、その可能性に線を引く責任。今月はこの二つを同時に語る。第3週はその均衡点 — 豊かに開きつつ、危険には開かない感覚。
ツール・パッケージメモ
今週のメモは境界設計の順序。ツールを設計するとき足し算から始めると、一覧が肥大し、危険な能力がそっと混ざる。勧める順序は逆だ — まず「このアプリが絶対にできてはならないこと」の一覧を作り、それを非露出の領域として釘づけにする。そのうえで、その線の内側でツールを足す。閉じるものを先に決めれば、開く作業が安全になる。興味深いことに、この順序に従うとツール一覧はより短くなる。閉じる領域を先に定めておくので、本当に必要な能力だけを残すことになるからだ。境界が設計を手伝ったわけだ。
短い思考
権限という言葉は重い。誰が何をできるかを規則で定め、検査し、拒否する。ところがツールという単位に移すと、権限が一覧になる。あるツールはできて、ないツールはできない。規則を読まなくても、一覧を見ればわかる。権限をコードから仕様へ移したこと — これが4月の間ずっと流れる静かな転換だ。そして仕様は人が読める。作った人でなくとも誰でも、ツール一覧を開けば、そのアプリが何を約束し何を拒むかがわかる。信頼が検証可能になる場所がここだ。
現場から
ハン・ドギョンさんが診療の流れをツールとして形づくる過程も、この順序に従った。彼はまず「ツールが絶対に越えてはならない線」を引いた — 診断、処方の最終判断。その線を非露出として釘づけにした後、その内側で患者の受付・問診の整理・記録の整頓のツールを豊かに足した。一日60人を診る速さはツールが手伝い、判断の重さは人が負う。閉じるものを先に決めたからこそ、開く作業が自由だった。
今週の問い・来週の予告
あなたが作る画面の「閉じた一覧」を書いてみたことがあるか。普通は開く機能だけを書く。今週の勧め — 閉じる一覧を先に書いてみてほしい。来週は4月を閉じながら、ハン・ドギョンさんの話を丸ごと — 長く働いた人の経験がどう流れになり、流れがどうツールになるかを締めくくる。
makemind.dev 「更新」— 毎週ひと呼吸、一週間のSignalを集めます。