可塑的ソフトウェア：ロックダウンされたアプリの世界でユーザーの主体性を取り戻す
可塑的ソフトウェアは、ユーザーが閉じたアプリに合わせるのではなく、最小限の摩擦でツールを作り変えられるべきだと主張する。Ink & Switch は数十年の研究を統合し、ローカルで共創する計算システムを探求している。
日本語
コピー
個人コンピューティングが最初に約束したのは、新しい粘土だった——ユーザーが自由に形を変えられる可塑的な素材だ。実際に手に入ったのは家電製品だった。遠くで作られ、密閉され、変更できない。ツールが自分の必要とする働き方をしてくれないとき、できるのはフィードバックを送って後は運を天に任せることだけ。本来なら逆であるべきなのに、自分のワークフローをソフトウェアに合わせて曲げることを強いられる。
本稿が思い描くのは可塑的ソフトウェアだ。ユーザーが最小限の摩擦でツールを作り変え、自分の固有のニーズに合わせられる。修正は例外ではなく常態となる。適応は使用の現場で起こり、遠くの会社のエンジニアリングチームを通して起こるのではない。
このビジョンを実現するには多くの障壁がある。プログラミング言語からオペレーティングシステム、アプリストアに至るまで、現代のコンピューティングの風景はあらゆる層が同じ前提の上に成り立っている。ユーザーは受動的な受け手であり、能動的な共同創造者ではない、という前提だ。必要なのはその正反対——すべてのユーザーを少しずつ作り手へと誘うコンピューティングシステムである。ツールは互いに孤立したモノリシックなアプリではなく、組み合わせてカスタムのワークフローにできる。システムはローカルのコミュニティが共に創造することを支える。
幸いなことに、参照できるものは多くある——過去数十年の研究成果も商用製品も。本稿はそうした仕事のアイデアと、私たちが長年プロトタイプを試して得た経験を統合したものだ。ソフトウェア開発者であれ、研究者であれ、あるいはただのコンピュータのユーザーであれ、可塑的ソフトウェアの世界に向けて私たちとともに歩んでほしい。
引用する場合は以下を用いてほしい：
Geoffrey Litt, Josh Horowitz, Peter van Hardenberg, and Todd Matthews. 2025. Malleable Software: Restoring User Agency in a World of Locked-Down Apps. Ink & Switch. https://www.inkandswitch.com/essay/malleable-software/.
動機
私たちは自分の環境を作り変えたい
環境は重要だ。最高の仕事をし、最高の人生を送るには、それぞれが固有の可能性を発揮できる空間が要る。
ギター製作者は自分の工房を整え、のこぎり、ハンマー、のみ、やすりを手の届く位置に置く。必要に応じて新しいツールも作る——木の塊を支えにしたり、ペンチを削ってちょうどいい形にしたり。
家庭の料理人は、包丁、まな板、鍋を何年もかけて少しずつ揃え、その中から手に馴染むものを選ぶ。天井にフックを取り付け、棚を動かし、平日の夕食を作るときも週末の大掛かりな料理のときも、自分の動線に合うようにキッチンを変えていく。
どれも当たり前のことだ。物理的な世界では、物理的な現実はこねられるから、環境を作り変えるのは自然なことである。
小さな調整——壁に付箋を貼る、引き出しの中身を入れ替える、家具を一つ動かす——は誰の許可も要らずすぐできる。工房を建てる、キッチンを改装するといった大きな変更にはもっと力と技術が要る。自分にできないときは、地元の職人に頼めばいい。
自分が掌握する物理的な空間で働き、暮らすとき、私たちはそれを少しずつ自分のニーズに合う形に作り変えていく。Stewart Brand は『How Buildings Learn』でこう書いている。「建物が愛されるのは、年季と改造可能性による。建物は使い手から学び、使い手も建物から学ぶ。」
大量生産されたソフトウェアは硬直している
今日、私たちはますます多くの時間を、原子ではなくコードでできた環境の中で過ごしている。この移行は多くの能力をもたらした——大陸をまたいで即座に協働でき、何千ものファイルを一瞬で検索できる。だが私たちは大切なものも失いつつある。自分の環境を作り変え、本当に自分のものにする能力だ。
一例を挙げよう。本稿の著者の一人が所属していたソフトウェアチームは、壁に貼ったインデックスカードで作業の進捗を管理していた。この看板は常に変化していた——区切り線が動き、チェックリストが生まれ、メインのグリッドの周りに特殊なカード領域がいくつも広がった。ツールの流動性が、プロセスの流動性を生んでいた。
インデックスカードの壁は、ソフトウェア開発を管理するためのこねられる媒体である。
後にチームは、リモートの協力者を支えるためにウェブベースの課題トラッカーへ移行した。するとあの特殊なカード領域をモデル化することも表示することもできなくなり、チームはプロセスのその部分を捨てた。その後のプロセスの変更も同じく止まった。以前なら新しいアイデアを試すのに数分で済んだことが、今では設定に何時間もかかるか、そもそも不可能かもしれない。仕事をコンピュータ化したことで、かえって人の自主性が失われた。
ソフトウェアの硬直は小さな不便にとどまらない。人が重要な仕事をするのを深刻に妨げる。医師で作家の Atul Gawande はこう書いている。医療のコンピュータ化が、史上最高水準の燃え尽き症候群を引き起こしている、と。たとえば、以前は紙のフォームに記入するとき無関係な欄を飛ばせたが、今はソフトウェアが記入を強制し、医師にそのルールを変える権限はない。Gawande が紹介するある医師の言葉——「余分に時間がかかることには腹が立たない。腹が立つのは、その時間が無意味なことだ。」
硬直した電子カルテシステムが医師を燃え尽きへ追いやっている。
ソフトウェアが自分のニーズを満たさないとき、開発者にフィードバックを試みるかもしれない——だがそれは通常、即座の変化にはつながらない。ユーザーのニーズはそれぞれ異なり、中央集権的な開発チームが全員の問題を解決することはできない。 しかも、開発者があまりに多くの解決策を一つの製品に詰め込もうとすれば、結果は肥大した寄せ集めになるだけだ。この罠を避けるため、優れたプロダクトチームは大多数のユーザーからの要望を断ることを学び、ニッチな要望の山を放置することになる。
私たちの具体的なニーズがソフトウェアで満たされない——これは避けられないことのように思える。だが、それはソフトウェアは集中した開発チームが握るものだという前提を疑わずに受け入れているからにすぎない。もっと多くの制御を、自分のニーズをよく分かっているユーザーの手に委ねたらどうなるだろう？
Gawande はある脳神経外科医の話を紹介している。その外科医は IT アナリストと組み、自分の科のカルテシステムを作り替えた。「ほどなくして、彼らは脳神経外科外来専用の、より速く直感的なインターフェースを作り上げた」。この要件はその科から出てきたもので、全国の医師全員のものではない。直接的な生産性の向上に加え、医師たちは自分の道具をより自分で制御できていると感じられるようになった。燃え尽き症候群への解毒剤が、ここにある。
この話は確かに勇気づけられるが、例外に近く、常態ではない。私たちがソフトウェアを配備するためのツールとインフラが、ユーザーを受動的な受け手として扱い、能動的な共同制作者として扱っていないからだ。 ソフトウェアは柔軟で組み替え可能なツール群ではなく、一枚岩のモノリシックなアプリとして組織されている。カスタマイズするにはプログラミングが要るが、ほとんどの人にその技能はない——ましてや、多くのソフトウェアはオープンソースですらない。ソフトウェアはユーザーの手に渡るとき、それを編集するツールを伴わない。アプリストアは、消費者にソフトウェアを配布する企業のために設計されたもので、友人にツールを共有する趣味人向けではない。これは工業的な大量生産の仕組みであって、小規模な手仕事ではない。
公平に言えば、大量生産されたソフトウェアは多くの利点をもたらした。手頃な価格で、磨き上げられたアプリを大量に使える。信頼性、アクセシビリティ、安全性も進歩した。開発者は持続可能なビジネスモデルを築き、チームを養いながら、改善を続けるソフトウェアを届けられている。
だが、これらの話や無数の他の例が示すように、硬直した大量生産のソフトウェアは足を引っ張りもする。平均的なユーザーから外れるほど、専門的に磨かれたことによる利点よりも、カスタマイズによる利点のほうが大きくなる。誰もが何らかの点で人とは違う——書くこと、音楽を作ること、議論すること、プロジェクトを計画することに、強いこだわりがあるかもしれない。具体的なニーズがあるとき、自律性がものを言う。
私たちの目標：可塑的ソフトウェア
私たちは、ユーザーが共同制作者として自律性を持つ、新しいコンピューティングの生態系を思い描いている。この理念を可塑的ソフトウェアと呼ぶ——誰もが最小の摩擦で自分の道具を自分のニーズに適応させられるソフトウェア生態系だ。
- 「ソフトウェア生態系」とは、ソフトウェアとそのユーザーを取り巻く広範な技術的環境と文化的環境を指す。可塑性は狭い技術的問題ではない。
- 「誰もが」とは、広範な使いやすさこそが目標だという意味だ。個人の自給自足を育むことは有用だが、地域コミュニティと協働することにも同じ価値がある。
- 「道具を適応させる」には、既存のソフトウェアへの小さな手直しから、深い改造、さらには既存のツールとうまく連携する新しいツールの創造まで、一連のカスタマイズ全体が含まれる。適応とは、ゼロから作り直すことではない。
- 最後に、「最小の摩擦」が鍵だ。自分の道具を編集するのは素早くでき、軽やかに感じられるべきである。理想を言えば、ニーズが生じたその場でさっと直し、手元の作業に戻れることだ。
既存のアプローチ
設定やプラグインがあるだろう、と思うかもしれない。確かに、ソフトウェアをカスタマイズする手段は数多くあり、称賛に値する。だがそれらにも限界があり、上に挙げた目標を完全には実現できない。
設定
設定はアプリの挙動を変える一般的な方法だ。項目があれば、チェックを入れて作業を続ければいい。
だが設定は、アプリの開発者が事前に露出させようと考えた選択肢しか提供しない。ニーズを満たす設定項目がなければ、そこで行き止まりだ。設定はまた、互いに関係のないチェックボックスの寄せ集めになりやすく、それらを貫く一貫したメンタルモデルがない。
設定は、アプリ開発者が事前に選んだ特定のカスタマイズをユーザーに許す。
プラグイン
中心にいる開発者の手が届く範囲を超える一つの方法は、第三者のプラグインがアプリの挙動を拡張できるようにすることだ。優れたプラグインシステムは、誰かが作ったプラグインをそのままインストールできるため、ユーザーがカスタマイズを始めるハードルを大きく下げる。プラグイン API にはもう一つ決定的な利点がある。基盤となるアプリと多様な拡張の間の契約を安定させ、長期的な保守を容易にするのだ。
しかし、プラグインシステムでも、アプリの挙動を特定の、許可された方法でしか変えられない。 あるカスタマイズに対応するプラグインインターフェースがなければ、ユーザーはお手上げだ。（実際のところ、ほとんどのアプリにはプラグイン API すらない。よいプラグイン API を設計するのは骨の折れる仕事だからだ！）
別の問題もある。プラグインをインストールすることと、プラグインを作ることの間には、越えがたい溝がある。しかもアプリごとに独自のプラグインシステムがあり、プラグインはたいてい異なるアプリ間で使い回せない。
Obsidian という Markdown エディタには、エディタの挙動を拡張する豊富なコミュニティプラグインの生態系がある。
Mod による改造
設定項目や公式の拡張 API では足りないとき（あるいはそもそも提供されていないとき）、ユーザーは許可を必要としない modding によって自分で何とかできることがある。たとえばブラウザ拡張はウェブサイトのユーザーインターフェースに介入し、新しいクライアント側の挙動を注入できる。元のアプリの開発者がフックを一切公開していなくてもだ。
許可を必要としない mod は、公式にサポートされたプラグイン API よりもはるかに広い範囲をカバーする。実際、元の開発者が明確に反対している種類の拡張であっても、mod なら実現できる——広告ブロッカーは、サイトの利益よりユーザーの利益を優先している例だ。
Mod にも限界がある。mod を作るには、面倒なリバースエンジニアリングが必要になることが多い。基盤のアプリが進化すると、mod は保守しづらくなる。同じアプリ上の異なる mod どうしが、きれいに共存できないこともよくある。
基盤となるプラットフォームの能力の限界も、mod にできることを制約する。たとえばブラウザ拡張はサーバー側の挙動を変えられないため、提供できる機能はそれだけで大きく見劣りする。しかも他のプラグインと同じく、公式サポートのない mod はインストールと制作の間に大きな隔たりがある。ブラウザ拡張を一つ作るには、ブラウザを離れてコードを書き、ビルド済みの成果物を配布しなければならない。（この手順を回避する戦略については後で触れる。）
ニッチな需要に応えるブラウザ拡張の一例：BoA Checklist は Bank of America のサイトで各取引の横に常設のチェックボックスを表示し、その取引を確認済みかどうかを記録できる。
オープンソース
オープンソースソフトウェア運動は、ソースコードを配布することで、ソフトウェアのユーザーが本当の意味で自分のソフトウェアを所有し、コミュニティに還元し、必要なら自分に合ったバージョンを作れるようにしようというものだ。世界にとってプラスに働く力であり、可塑性の重要な源でもある。
ただし、コードを編集できるからといって摩擦が小さいわけではない。まともなオープンソースのコードベースに手を入れるには、ボタンの色を変えるような些細な変更でも、相応の専門性と労力が要る。熟練したプログラマーにとっても、開発環境を整え、コードベースを把握するまでの壁は高く、気軽に手を出す気にはならない。
ユーザーは GitHub でオープンソースプロジェクトに変更を提案できる。
AI 支援プログラミング
最後に、今を代表する話題を一つ。AI ツールはソフトウェアを自動的に可塑にするのか。
歴史を振り返れば、普通の人でもプログラムを書けるようにすることは、ソフトウェア制作の民主化における最も難しい謎の一つであり続けた。文法が親しみやすい言語や意味論が単純な言語、操作を記録してマクロにするシステム、ビジュアルなライブプログラミング環境など、さまざまな道が試されてきた。
今、大規模言語モデルが新しい手を提示している。自然言語で表した漠然としたアイデアを、自動でコードに変えるというものだ。プログラミング経験がなくても、会話するだけで誰もが Web アプリを作れる——そんな流れが生まれつつある。事例は日々出てくる。記者が作った学校給食のアイデアを生成するアプリや、環境学を専攻する学生が作った植林の進捗を追跡するサイトなどだ。私たち自身も、AI でソフトウェアツールを組むのが手軽だと感じている。専用の日本語翻訳アプリや、カスタムのトレーニングメニューを備えたミニマルなワークアウトタイマーなどだ：
Claude Artifacts で AI を使ってワークアウトタイマーツールを組む
こうした進展の可能性は大きいと考えているし、今まさに可塑的ソフトウェアに取り組むべき理由でもある。だが同時に、AI がコードを生成するだけでは、可塑性が抱える障壁はすべて取り除かれない。 すべてのコンピュータユーザーがコードを完璧に書けて直せると仮定しても、なお大きな問題が残る。
ユーザーは、新たに孤立したアプリを作るのではなく、すでにインストールした既存のツールをどう調整するのか。AI が生成したツール同士をどう組み合わせ、共有データの上により大きなワークフローを組むのか。ごく小さな変更でさえ AI にコードを書いてもらうのではなく、ソフトウェアの調整をより直接的で細やかに制御するにはどうすればいいのか。一文のプロンプトからクラウドホスト型のアプリを生成する製品は、これらの問いに一つも答えていない。
AI プログラミングツールを今のソフトウェアエコシステムに持ち込むのは、腕の立つ副料理長をフードコートに連れて行くようなものだ。 メニューを見て注文することに慣れているなら、どんなに優れた料理人でも役には立たない。同じように、アプリストアのクローズドソースソフトを使っているなら、AI プログラミングアシスタントはユーザーとしてはほとんど助けにならない。AI の能力を活かすには、フードコートを出て、もっと厨房に近い場所へ行く必要がある。開かれた形で何かを作れる場所だ。
ユーザーの主体性を中心にコンピューティングの基盤を組み直すのは、野心的な目標だ。幸い、パーソナルコンピューティングの誕生以来、それを実現する有力な構想は数多く示されてきた。
次のいくつかの節では、可塑的ソフトウェアを実現する鍵と私たちが考える三つの設計パターンをまとめる。問題を解く正確な処方箋ではないが、今日のソフトウェア世界で十分に顧みられていない重要な考え方であり、可塑的ソフトウェアを実現する答えの一部になると信じている。
ユーザーから作り手へ、坂は緩やかに
可塑的ソフトウェアといっても、誰もが自分のツールをすべてゼロから作るわけではない。そんなのは時間の無駄だ。既製のツールの多くはすでに自分たちのニーズにかなり近く、少し手を入れれば済む。
もっと合理的なのはこうだ。まずは他人や他社が作った既製のソフトウェアツールを使う。だが、自分のニーズを満たせないと気づいたときのために、それを変更する選択肢を残しておく。受け身のユーザーとして始め、徐々に編集者や作り手になっていけばいい。
1990 年の論文 User-Tailorable Systems: Pressing the Issues with Buttons で、EuroPARC の Allan MacLean とその共同研究者たちは、ユーザーが段階的に作り手になれるソフトウェアシステムを設計するための、強力なメンタルモデルを提示した。
この図を見てほしい。横軸はカスタマイズの強さ、つまり深さを表し、縦軸はそのカスタマイズに必要なスキル水準を表す。このモデルでは、次の深さに進むためにユーザーが急に大量のことを学ばなければならなくなると、図に垂直な「崖」が現れる。
設定をいじる段階から本格的なプログラミングへいきなり飛ぶのは、とても越えられそうにない険しい「崖」だ。（図は MacLean らによるもの）
こうした崖を削り、ステップアップを滑らかにするために、MacLean らはひとつの設計目標を掲げた。カスタマイズ能力を一段上げるのに必要な学習とスキルも、一小段分だけで済むべきである。 このルールに従ったシステムは、崖のない「緩やかな坂」として描ける。
複数のカスタマイズ技術で構成された、カスタマイズ能力の緩やかな坂。（図は MacLean らによるもの）
研究者たちは Buttons という自動化システムでこの原則を検証した。当初、ユーザーにできるのはボタンを動かしたり、テキストや色を変えたりする程度だった。坂を少し上がると、変数の値を編集したり、ツールキットで簡単なインターフェースを組み立てたりできる。頂上に達して初めて、Lisp プログラムを書いて新しい振る舞いを生み出せる。肝心なのは、どのカスタマイズもできる限り最も単純な技術で済ませ、本格的なプログラミングはどうしても必要なときだけ使うという点だ。
成功したエンドユーザー可塑環境の多くは、この緩やかな坂のパターンを採っている。スプレッドシートはその一例だ。誰かから複雑な表を送られたとき、まずは眺めるだけでもいいし、入力用と示されたセルを書き換えるだけでもいい。もう少し進めば、書式を整えたり、ラベルをいくつか足したりするかもしれない。使い込むうちに、数式を変えたり、自分でセルを追加したりし始める。スプレッドシートは最初、誰かが組み立てて幾つかのつまみだけを残した「アプリ」のように使える。だがアプリと違い、より深いカスタマイズへと滑らかに進んでいける。
スプレッドシートは、利用からより踏み込んだ変更へと続く緩やかなカスタマイズの坂を提供する。
緩やかな坂をどう実現するかについて、スプレッドシートはいくつか有用な示唆を与えてくれる。第一に、スプレッドシートにはその場のツールチェーンが備わっている。スプレッドシートを使う人は誰でも完全なエディタを動かしている。もっと深く変更しようと思ったとき、別の開発環境をインストールしたり開いたりする必要はない。
また、スプレッドシートには往々にして雑さが許される雰囲気がある。プロの設計アプリのようなピクセル単位の洗練と比べると、スプレッドシートをいじるのは感覚的に安全なのだ。
緩やかな坂を実現するもうひとつの方法は、明示的なモードだ。HyperCard は 1980 年代の Mac プログラムで、ユーザーはその中で「カード」の束を作れる。いくつかの「レベル」が用意され、その時点でどの操作を実行できるかが決まる。
HyperCard では、ユーザーが「レベル」を選んで自分の編集能力を制限できる。
レベル 1 は読み取り専用。レベル 2 と 3 はテキストとグラフィックの編集ができ、直接操作のインタラクションを採る。レベル 4 ではボタンを作ったり、ものを繋いだりする能力が加わる。レベル 5 では HyperTalk というスクリプト言語による本格的なプログラミングが解禁される。これらの明示的なモードはガードレールとして働き、ユーザーが思わぬ結果を恐れずに安全に探索できるようにする。
HyperCard の各レベルは、能力とスキルにおける一小步を表している。
最後に、崖を平らにするとどうなるかを見てみよう。前述したとおり、ブラウザ拡張をインストールすることと、自分で拡張を作ることの間には大きな溝が横たわっている。
ブラウザ拡張をインストールするところから、ブラウザ拡張を作るところへは険しい崖だ。ブラウザを離れ、面倒なプログラミングをこなすことが求められる。
ウェブサイトのカスタマイズにもっと軽量なやり方を導入すれば、はるかに緩やかな坂が得られる。Stylish や Arc Boosts のようなツールを使えば、ブラウザ内でカスタムスタイルのテーマを作成して共有できる。曲線をもう少し上がると、マクロシステムによってウェブサイト上で行った操作を記録して再生できる。JavaScript を少し知っていれば、Tampermonkey で書かれたユーザースクリプトをブラウザの中で直接いじれる。
Arc Boosts では、ブラウザ内で直接操作のインタラクションを通じてウェブサイトのスタイルを再設計できる。
これらの技術は、能力とスキルの敷居の間でそれぞれトレードオフがある。ウェブサイト上の色をひとつ変えたいだけなら、表現力の低い、その作業に特化したシステムの中で済ませられるべきで、ブラウザ拡張を丸ごと書く必要はない。こうした技術があれば、この坂はもっと緩やかにできる。
ウェブカスタマイズ技術は、ブラウザ拡張を使う前に、より緩やかな坂を提供する。
坂を緩やかにする方法は二つある。ひとつは図の右側から出発し、必要なスキルを下げるやり方だ。この戦略は、プログラミングの完全な表現力から出発して、それをより手に取りやすくする膨大な仕事に対応する。より親しみやすい構文、ライブプログラミング環境、例からプログラムを推論する仕組み、漸進的な足場かけなどが含まれる。
だが、同じくらい重要でありながら見落とされがちな戦略がもうひとつある。図の左側から始めて、能力を少しずつ増やしていくというものだ。成功しているカスタマイズ可能なシステムの多く——スプレッドシート、HyperCard、Flash、Notion、Airtable——は似たパターンに従っている。プログラミング能力を任意で備えたメディアエディタだ。環境がドキュメント編集と見慣れた直接操作のインタラクションを提供していれば、ユーザーはコードを一行も書かずに多くのことを成し遂げられる。
最後にひとつ。誰もが坂の頂上まで登る必要はない。 ある段階まで来ると、多くのアマチュアユーザーは時間と労力を節約するため、あるいは必要なスキルを学ぶのを避けるために、他人に助けを求める。肝心なのは、妥当な学習とスキルの積み増しで、多くのカスタマイズがアマチュアユーザーにも手の届くものになるということだ。なだらかな坂道は、スキルレベルの異なる人どうしの協働も滑らかにする。この点は、共同制作の重要性を論じる際に改めて掘り下げる。
アプリではなくツール
ここまでは単一アプリの硬直性に注目してきた。だが、ソフトウェアを自分の必要に合わせて調整しにくくしている理由はもうひとつある。「アプリ」という概念そのものだ。この考え方にあまりに慣れ親しんでいるせいで、どこに問題があるのか見えにくくなっている。台所を例にとって考えてみよう。
アプリはアボカドスライサー
アボカドを切る方法のひとつは「アボカドスライサー」を使うことだ。三つの道具をひとつにまとめた小さな器具で、アボカドを半分に切る鈍いプラスチックの刃、種を取り出す円形の種抜き、そして一度に7枚にスライスするプラスチックの櫛が付いている。
アボカドスライサーはひとつの用途にしか応えない。
誰でも使えて、練習も要らず、危険もない。だが、アボカドスライサーはその一つのことだけに特化しているがゆえに、それ以外は何もできない。あらゆる作業に専用の道具を揃えていったら、家中がプラスチックの山になる。
トウモロコシの皮むきからレタスの千切りまで、ほぼ何にでも専用の道具が見つかる。
もうひとつの方法は包丁を使うことだ。アボカドを切るどの工程もこなせるし、それだけにとどまらない。鶏胸肉を切る、玉ねぎをみじん切りにする、ニンニクを潰す、どれもお手のものだ。安全に使いこなせるようになるには確かに練習が要る。だがその手間だけの価値はある。包丁は汎用の道具だからだ。
包丁はアボカドを切れるし、それ以上のこともできる。
この類推をソフトウェアに当てはめると何が見えてくるか。多くのアプリはアボカドスライサーだ。 特定の用途——旅行の計画、ワークアウトの記録、レシピの整理——に向けて機能を束ねたものだ。ひとつのアプリがその用途の多くのタスクを抱え込むせいで、どれも中途半端になることがある。こんな経験はないだろうか。大事にしている機能がそのアプリに欠けている一方で、使う当てのないものが山ほど詰め込まれている。
さらに重要なのは、大きなタスクを複数のアプリでこなすには、たいてい手作業での調整が要ることだ。ウィンドウを並べてデータをコピー＆ペーストするくらいしかできない。もっと使い勝手のよいソフトウェアの道具が欲しいなら、より小さなツールどうしがもっとうまく連携できるようにする必要がある。
旅行をひとつ計画するのに、互いに隔離された多くのアプリの間を手作業で調整することになる。
だからといってアプリモデルがまるごと無価値だというわけではない。単一アプリの範囲内では、ユーザーは一貫した体験を得られる。開発者は他のツールとの相互運用を気にせず、細部まで磨き上げられるからだ。アプリごとにデータを隔離するのは、セキュリティやプライバシーの問題に対処する手軽な方法でもある。アプリに金を払う（そして支援に金を払う）のは妥当な課金モデルだ。これらは無視できない重要な利点である。
だが、複雑な問題を解こうとしたり、複数のアプリにまたがる創造的なワークフローを組み立てようとしたりすると、アプリ間の隔離は深刻な厄介ごとを持ち込む。より汎用的で組み合わせ可能なツールを中心にソフトウェアを再編成できないだろうか——アボカドスライサーではなく、包丁のように。ここには解くべき副問題が二つある。ツール間でデータをどう共有するか、そしてユーザーインターフェースの中でツールをどう組み合わせるかだ。
ツール間でデータを共有する
異なるソフトウェアツールを協調させて一つの仕事を成し遂げようとするなら、それらのツールは同じ共有された現実を操作できなければならない。
現代のクラウドプラットフォームやモバイルプラットフォームでは、各アプリが自分の私有の孤島の中でデータを管理している。ある旅行の計画は、ノートアプリ、Google Maps のリスト、カレンダーに散らばっている。この断片化が可塑性を妨げる。各アプリがそれぞれデータを管理していると、ワークフローに新しいツールを持ち込むたびに摩擦が増える。人は、ある部分をこなすのにより優れた代替ツールがあるとしても、既存のアプリの中だけで全部を片付けようとする。
逆に、データがアプリ間で共有されていれば、エンドユーザーはもっと柔軟にツールを組み合わせられる。よく知られた例がデスクトップのファイルシステムだ。情報がファイルとして保存されていれば、異なるサブタスクに特化した異なるツールで同じファイルを編集できる。Lightroom で写真の明暗を調整し、その写真に Apple Preview で走り書きの注釈を加えられる。協働する人どうしがそれぞれ好みのツールを使うこともできる——一人が VSCode でコードリポジトリを編集しながら、別の同僚が emacs で同じものを編集する、といった具合に。
ファイルは異なるツールの間の共通基盤になる。
ツールが共有データの上で動くもうひとつの例は、ローコードのデータベースアプリ構築プラットフォームだ。Microsoft Access や Filemaker Pro のようなデスクトップアプリから、Airtable や Notion のようなクラウドアプリまで含まれる。これらの環境では、エンドユーザーが同じデータベースに対して複数のビューを構築できる。たとえば Airtable には、グリッドの表エディタ、カードの看板、カレンダーといった汎用ツールが備わっている。カスタム UI を追加することもできるが、特別な場面でしか必要にならない。多くのタスクは汎用のグリッドエディタで片付くからだ。
Airtable で同じデータを複数のビューから編集し、リアルタイムに反映させる
データを共有するという発想は、振る舞いを伴う共有オブジェクトにも広げられる。 Smalltalk では、ユーザーの目の前にあるのは image だ。永続化された状態だけでなく、その状態に対応するコードまで含んだオブジェクトの倉庫である。システム内のあらゆるものがオブジェクトとして表現されているおかげで、既存のオブジェクトを操作する新しいツールを持ち込める。メソッドを呼んで振る舞いを起動するのもその一つだ。
最後に、共有データに基づくリアルタイム協調のおかげで、別々の人が別々のツールで同時に作業できる。 例が Webstrates で、ブラウザ上で協調動作する可塑的なソフトウェアプラットフォームだ。Webstrates では、各ユーザーが動かすツールが、ブラウザの DOM に置かれた共有同期データセットを協調編集できる。つまり、2人のユーザーがそれぞれ好みのエディタで同じ論文を共著できる。片方が WYSIWYG エディタ、もう片方がプレーンテキストのインターフェースで、という具合に。
同じ論文を Webstrates 上で2つの異なるエディタからリアルタイムに編集する
ユーザーインターフェースの合成
ツールは土台となるデータを共有するだけでなく、それらをまとめて使うためのワークスペースも共有する必要がある。
アプリケーションというパラダイムは、これを支えない。アプリはウィンドウかタブを占有し、その中に一つの世界を築く。利点はある。アプリの作り手はその世界の中で体験を丹念に磨き上げ、すべてが噛み合うようにできる。だが同時に、複数のアプリを併用するには、互いに隔離された体験の間を行き来しなければならない。 食材を別の厨房へ運ばないと次の調理器具が使えない、そんな状態だ。データが行き来できたところで、体験は分断されたままだ。
アプリによるデータの独占と、対話環境の支配を、どうすれば同時に崩せるのか。ここまでプラグインや無許諾の mod といった手法を見てきた。それらは隙間をこじ開け、アプリを内側から拡張できるようにする。悪くはない。だが「アプリではなくツールを使う」世界を望むなら、もう少し別のものが要る。さまざまなツールを一箇所に集め、共有空間で使えるようにする環境だ。
一つの系統は複合ドキュメントシステムに由来する。OpenDoc や OLE がそうだ。書き手は複数のメディアを相互に埋め込み、一つのドキュメントに組み上げられる。たとえばテキストドキュメントに画像を埋め込み、その画像にデータ表を埋め込む。ある部分を選べばエディタがその場で開く。ウィンドウを切り替える必要も、ファイルシステムを探し回る必要もない。こうしたシステムは開かれている。開発者は新しいメディア型を持ち込めるし、既存のメディア型に新しい差し替え可能なエディタを提供することもできる。
OpenDoc のドキュメントは複数の「パーツ」からなり、それぞれ別のエディタで編集されるが、一つのドキュメントにまとまっている。
UI をより小さな断片に分解すると、新たな設計上の難問が生じる。ドキュメントの各部分にどのエディタを使うか、ユーザーはどう選ぶのか。ドキュメントを共有するとき、相手が必要なサブエディタをすべて持っていると、どう保証するのか。選択やフォーカスといったグローバルな対話は、エディタをまたいでどう機能するのか。OpenDoc のようなシステムはこれらの問いに答えを出しており、研究する価値がある。もっとも、現代の協調アプリや Web アプリの性質が、周囲の状況をすでに変えてしまってはいるが。
ドキュメントの各部分にエディタを埋め込むだけでは足りないこともある。Tchernavskij が Designing and programming malleable software で挙げた例を見てみよう。あるアプリのカラーピッカーを、別のアプリで再利用するにはどうすればいいのか。 カラーピッカーはチャートエディタと違い、ドキュメントの特定の一部分に対応しているわけではない。ドキュメント全体のオブジェクトを相手にするツールなのだ。仕事を成し遂げるには、カラーピッカーが他のオブジェクトを何らかの形で認識し、その色を変更できなければならない。通常、ユーザーインターフェースはこうした接続をハードコードしてしまう。だが拡張や再利用を支えるには、もっと柔軟で開かれた仕組みが要る。
Designing and programming malleable software にある挑戦課題：あるアプリのカラーピッカーを別のアプリで再利用する。
Tchernavskij はこの問題に対して entangler を提案した。関連する UI 要素を動的に発見して接続する、UI システム内の専用レイヤーである。別の研究プロジェクト Varv は、積み重ね可能な拡張としてのイベントトリガー列で振る舞いを記述し、同じ問題に取り組んでいる。具体的な手法はそれぞれ異なるが、共通点はある。いずれも UI の各部分のつながりを何らかの形で表現し、その表現が後からの拡張を支えられるようにしている。
さらに過激な UI 合成のアプローチは、物理世界を合成可能性の土台にする。Dynamicland がそれだ。Dynamicland のプログラムは物理オブジェクト（紙片など）の集まりからなり、それらがコードとデータを担うと同時に、対話の取っ手にもなる。Dynamicland では、いくつかのインターフェースを机の上で近づけ、テープや糊でくっつければ、それで合成が完了する。プログラムは空間的な関係——指し示す、近接する——を利用して、オブジェクト間に仮想的な接続を張ることもできる。画面ベースのシステムが Dynamicland の物理世界の使い方をそのまま真似ることはできない。だが少なくとも一つ、示唆は得られる。一貫した物質性と物理法則そのものに価値がある、ということだ。
Dynamicland でプログラムを動かす紙片。机の上で組み合わさり、緑の「ひげ」を伸ばして互いのつながりを定義する。
Dynamicland の組み合わせやすさは、プログラムを協調して動く小さなオブジェクトに分解しているところにも大きく由来する。これらのオブジェクトはグローバルデータベースを介して通信する。だから新しいツールをシステムに追加し、既存のオブジェクト間のメッセージを横取りして、既存ツールの振る舞いを変えられる。情報の送り手と受け手の間に固定された接続をあらかじめ前提としないシステムでは、その情報を新しい用途に使い、システムを積み重ねるように拡張するのが容易になる。
共創
誰もが自分だけの計算体験を作れると想像するのは確かにわくわくするが、可塑的ソフトウェアを個人主義の視点で捉えても、あまり先には進めない。
個人がその場でソフトウェアに手を入れて自分のニーズを満たし、「利用から創造への緩やかな坂」を登っていけるのは当然よい。だが望む変更が大きくなるほど、それを実現するのに必要な時間と技能は増える。誰もが自分のためだけにそうした変更を加え、一度使ったら捨てるというのでは、得られるものはコストに見合わないことが多い。誰もがソフトウェアを作る専門家になりたいわけではない。
可塑性を共同体の視点から見なければならない、もっと根本的な理由もある。私たちはコンピュータを一緒に使っているのだ。あるプロダクトチームには統一されたプロジェクト管理システムが必要で、病院のある部署には統一された患者登録システムが必要になる。こうした共同体は、自分たちで制御できない汎用アプリに満足しているわけではないが、かといって各自がばらばらに解決すればよいものでもない。共同体が自らの問題を解決する共有の仕組みを構築し、維持できるようにすべきだ。
適切な基盤があれば、私たちは協力して自分たちのソフトウェアを作れる。 世界中で似たニーズを持つ人々が成果を交換し、共同で開発できることは、フリーソフトウェアコミュニティがすでに証明している。ローカルの共同体——企業から家庭、市民団体まで——は、地元のニーズに合ったソフトウェアを構築し維持できる。地元のニーズが「坂」の高いところまで登り、特別な技能と熱意を要するようになっても、共同体の全員がその水準に達する必要はない。その役割を引き受け、仕事をやり切る人が十分にいればよい。
「ローカル」な文脈向けにソフトウェアを作ることは、世界汎用のソフトウェアを作るより簡単なことさえある。 ユーザーと直接接して、彼らが直面する状況にすぐ対応できるなら、隙のない産業グレードのソフトウェアを作る必要はない。設計時にすべての人のニーズを予測する必要もなく、自分の共同体のニーズだけを予測すればよい。Clay Shirky はこのあり方を「状況に埋め込まれたソフトウェア」と呼び、学生たちが「社会的インフラや文脈に敏感な情報を利用して」自分たちの共同体向けのソフトウェアを素早く作る様子を描いている。Robin Sloan はさらに身近な層について書いている。家族のために作るアプリは「家庭料理」でよいのだ。
こうした理由から、可塑的ソフトウェアの技術基盤は社会技術システムを支えるものでなければならないと私たちは考えている。異なる層にいる人々が協働し、ソフトウェアを自分自身と自分のコミュニティのために役立てられるようにするのだ。
フリーソフトウェアの歴史は、そうした社会技術システムをどう作るかの手がかりを与えてくれる。とりわけ私たちが刺激を受けたのは、フリーソフトウェアコミュニティが、中心で管理される単一のアプリケーションバージョンだけが存在すべきだとは考えない点だ。たとえば小規模なコミュニティが運営する Mastodon インスタンスは、コミュニティ固有の機能やルールを実現するために Mastodon のコードを改変することがよくある。もちろんこうした場合でも本格的なエンジニアリングの投入は必要で、しかもアプリケーションの層で動いていることに変わりはない。ソフトウェア改変への坂がより緩やかで、アプリよりツールが多い世界へ進むなら、より小さなコード片をどう共有し協働開発するのか、ソフトウェアが多様化する世界で相互運用性をどう保つのかを解明する必要がある。
Ink & Switch のプロトタイプ
Ink & Switch では、可塑的ソフトウェアのさまざまな側面を探る研究プロトタイプを何年もかけて作ってきた。これらは商用製品ではない。各プロトタイプの目的は、可塑性を実現するのに必要な技術への理解を深めること、そしてそのプロトタイプを深く使うことから学ぶことにある。（実際、この記事自体が自作の可塑的ソフトウェア環境で書かれており、その成功と失敗のいくつかも共有する。）
私たちの仕事は計算スタック全体にわたり、大きく二つの筋に分けられる。一つは基盤となるインフラを探る筋で、データを保存し、コードを読み込み、ユーザーインターフェースを定義する技術を、その上に可塑的な体験を築ける形で扱う。スタックのより上に位置するもう一つの筋は、特定のユーザー体験、すなわち動的ドキュメントに焦点を当てる。静的なメディアが、少しずつインタラクティブな振る舞いによって豊かになっていくものだ。以下、順に見ていく。
可塑性のためのインフラ
ソフトウェアを動かし開発するための今日の インフラ の多くは、可塑性を優先事項として設計されていないことはすでに述べた。可塑性を中心に据え直した着想源もいくつか示した。デスクトップのファイルシステムはツール間でデータを共有できるようにする。Smalltalk、Hypercard、スプレッドシートは実行時にコードを編集できるようにし、その場での変更を可能にする。ブラウザベースのアプリは DOM で自身の UI を記述するため、拡張によって許可なく魔改造できる。
こうした先人に刺激を受け、私たちはソフトウェアを構築し、動かし、共有するためのインフラスタックのプロトタイプを作り続けてきた。可塑性を最優先に据えたものだ。 私たちのアプローチはもう一つの研究領域の上に成り立っている。local-first softwareである。データの所有と制御をユーザーに優先的に委ねつつ、他者と協働する能力も保つという考え方だ。この作業の一環として、ユーザー間で JSON ドキュメントを永続化し同期するための協働ライブラリ Automerge を開発した。
PushPin：拡張可能なメディアキャンバス
local-first の基盤が可塑性（malleability）をどう支えるのか、その手がかりをつかむために私たちが作ったのが PushPin というプロトタイプだ。Web ベースの協働メディアキャンバスである。このプロジェクトで打ち出した中心的なアイデアが「ドキュメント関数型リアクティブプログラミング」（DFRP）で、ツールを React で書かれた UI コンポーネントとして表し、その背後に JSON ドキュメントを置き、Automerge が自動で永続化と同期を行うという考え方だ。
従来のアプリと比べ、DFRP では UI を拡張する手間が小さい。UI コンポーネントを一つ足すだけでよく、バックエンドのデータベースや REST API を気にする必要がない。さらに、データと UI が分離しているおかげで、既存のドキュメント に新しいインターフェースを定義するのも容易だ。新しいコンポーネントを定義し、それを別のエディタとして登録すればいい。
PushPin のボード。埋め込まれた各カードは React コンポーネントとして実装され、それぞれが同期された Automerge ドキュメントを背後に持つ
PushPin はいくつかの難問も浮き彫りにした。まず、ある状況でドキュメントを表示するのにどの UI を使うべきか、という問題だ。私たちは単純なモデルを試した。シナリオをハードコードするやり方で、「ボード上でカードとしてレンダリングするときはコンパクトビュー、メインコンテンツとしてレンダリングするときは展開ビューを表示する」といった具合だ。だが、これではすべてのニーズを満たせなかった。たとえば、目の前のタスクに応じてユーザーが複数のビューを選ぶ、ということができない。
埋め込みのモデルには、隔離と協調のバランスが必要だということも分かった。私たちが採ったのは制限の強いモデルで、コンポーネント同士は相互に埋め込めるが、それ以上の通信は許さない。この強い隔離のおかげでコンポーネント内部の挙動は推論しやすい。その一方で、ホバー状態のようなコンテキストを UI コンポーネント間で手軽に共有できず、リッチなユーザー体験の中には実現できないものがあった。無許可の魔改造も十分には支えられない。既存コンポーネントの内部に手を入れる仕組みが何もないからだ。ビューをどう配布するか、コンポーネント間でどう協調するか——これらの問いに対する私たちの模索はまだ続いている。
Cambria：ツール間で schema の互換性を調停する
PushPin を使っていると、schema の互換性が頭痛の種になる。ツールをアップグレードすると、既存データとの互換性が壊れることがよくある。そもそも、複数のツールが基盤となる JSON データの形式について完全に一致できなければ、ツール間の相互運用は難しい。これはより広い問題の一例だ——ツールがデータの形について合意できないとき、どう協調すればいいのか。可塑的な環境では、中心となる権威が schema を規定してくれることを当てにはできない。
私たちは Cambria というプロトタイプシステムを作り、書き込み用 schema と読み取り用 schema を切り離すことでこの難題に取り組んだ。各更新は各ツールが好む schema で書き込まれ、必要になったときに別の schema で解釈される。その schema は同じ schema の新旧バージョンでもいいし、別のツールが使うまったく異なる schema でもいい。一度きりのデータ移行ではなく、継続的にリアルタイムで行われる変換であり、任意の schema で同時に書き込み、読み取りする能力を保つ。
Cambria のプロトタイプで限定的なテストを行った結果、リアルタイムのデータ翻訳は複数の schema を支える有望な道だと私たちは考えている。ただし、Automerge と統合できるプロダクション品質のバージョンはまだ作れていない。難しいのは、基盤となるデータエンジンへの深い統合が必要になる可能性がある点だ。
Cambria は lens と呼ばれる変換グラフを通じて、ツール間でデータをオンデマンドにリアルタイム翻訳する。
Farm：コードをデータとして扱う
PushPin は環境に新しいツールを持ち込むハードルを下げたが、システムは実行時に編集できなかった。コードは GitHub リポジトリに置かれ、標準的な Web アプリのパイプラインでデプロイされる。そこで次のプロジェクトでは、変更をもっと流動的にすることを試みた。local-first のデータ層に、ユーザーデータだけでなくシステム自身のコードも載せる のだ。私たちは Farm というシステムを作り、ユーザーは Elm でツールを書けるようにした。ソースコードは Automerge ドキュメントに保存され、同期される。
最も基本的なレベルでは、コードをデータとして扱うことでツールの共有が簡単になる。だが、協働の多くの側面は依然として厄介だ。ツールを編集するとき、他の人の利用を壊さずに済ませるにはどうすればいいのか。複数の協力者が同じツールの異なる部分を並行して作業するにはどうすればいいのか。こうした問いの連なりが、次のプロジェクトへとつながっていく。
Patchwork：バージョン管理 + 自举
可塑性（malleability）の核心は、人が探索し、フォークできることにある。ユーザーはそれぞれ、作業を失ったり協力者の状態を乱したりする心配なく、あるソフトウェアへの変更を自由に試したり、複数のバリアントを作ったりできる必要がある。従来のソフトウェアエンジニアリングのプロジェクトでは、こうした問題は Git のブランチのようなバージョン管理の概念で解決されてきた。
バージョン管理システムはソフトウェアエンジニアには有用な道具だが、可塑的なソフトウェアを支えるために設計されたものではない。習得が難しく、正式な協働プロセスを前提としている。可塑的なソフトウェアには新しいアプローチが必要だと私たちは考えている。普通のユーザーが使いこなせることを最優先し、気軽で非公式な探索をよりよく支えること。私たちはこの構想を汎用バージョン管理と呼んでいる。
こうしたバージョン管理の理念をさらに探るため、私たちは Patchwork を開発した。可塑的なソフトウェアのための Web ベースの協働環境である。Patchwork は PushPin と Farm の中心的なアイデアの上に成り立ち、ユーザーデータとソフトウェアコードの両方を Automerge ドキュメントに保存する。その上で、履歴ビューや簡易ブランチといったバージョン管理のツールを加えている。これらのツールはシステム内のあらゆるドキュメントに適用できる——記事であれ、あるソフトウェアツールのコードであれ。
Patchwork はテキスト文書のブランチ間の diff を表示できる。他のメディアタイプにも対応している。
Patchwork は、これまでのインフラ関連プロジェクトとは進め方がひとつ違う。今は「自举」の状態にある——ラボの内部ナレッジワークの大半を、執筆からホワイトボードでの議論、プロジェクト計画まで Patchwork 上でこなしている。 この文章自体、Patchwork 上でホストされている共同編集の Markdown ドキュメントで書いたものだ。
Patchwork ではさまざまなツールを使ってきた——テキストエディタ、ホワイトボードから、シミュレータ、オーディオシーケンサー、ゲームまで。
Patchwork で作業する中で気づいたことがある。可塑的なシステムでは、ソフトウェアを改善する機会が自然と浮かび上がってくる。 この記事を書く過程にもその例があった。私たちが主に使っているのは共同編集の Markdown エディタだ。
Patchwork でこの記事を編集する
書いているうちに、記事が長すぎることに気づいた。だが Markdown エディタを見ただけでは、各節の分量が判断しにくい。そこで節ごとの文字数を数えるだけの Section Word Counter というツールを作った。
Patchwork では、こうした新しいツールをそのまま既存のワークフローに組み込める。デスクトップ IDE で書いて Automerge ドキュメントに同期すればよく、Patchwork 自体をリビルドしたり再デプロイしたりする必要はない。インストールすれば、Section Word Counter はすぐに既存の記事ドキュメントに対して使え、記事を編集するとリアルタイムで更新される。
2つの Patchwork ツールが同じ Automerge ドキュメントを編集／表示できる。
コードをデータとして扱えることは、共有も簡単にする。文字数カウンタはもともと、著者の一人が自分の日常用に作ったもので、その人の Patchwork インスタンスにしか読み込まれていなかった。ところが別の著者が使いたいと言い出したので、他のドキュメントと同じようにリンクで共有できるようにした。共同編集者はそれぞれ、どのツールをインストールするかを自分で選べる。
URL でツールを共同編集者に共有する。（チャットは、今のところ Patchwork に移行できていない数少ないユースケースのひとつ。）
必要が出るたびに、同じやり方でツールをいくつも作った。記事全体の構成を議論するときには「Zoomout View」が役に立った。
新しいツールがそれほど役に立たなかったこともある。共同著者にフィードバック依頼を割り振る「Request Tracker」を作ったが、ほとんど使われなかった。たいした損失ではない——作るのに手間はかかっていないし、無視するのもアンインストールするのも簡単だ。
Patchwork をカスタマイズする中で、もうひとつわかったことがある。AI は可塑的な環境と相性がいい。 前に書いたように、AI にコードを書かせるだけでは可塑性は保証されない。だが可塑的な環境と組み合わせれば、AI 支援の開発によって自分のツールをはるかに速く編集できる。
私たちは AI の力を借りて、Patchwork 内で多くのツールを素早く組み立ててきた。先ほどの Section Word Counter も AI 支援で、執筆の合間に数分で書けた。わざわざ時間を確保する必要はなかった。
可塑的な環境は、AI が生成したソフトウェアをより有用にするプラットフォーム機能も提供できる。たとえば、AI との会話から直接小さなソフトウェアツールを作れるインターフェースがある。この UI は表面的には Claude Artifacts のような既存製品と似ているが、生成されたツールは Patchwork の内部にあることで追加の能力を得る。永続化とマルチユーザー協働が自動でサポートされ、既存のツールと組み合わせて既存のデータを編集するのにも使える。
AI との会話で Patchwork 内に作ったデモ用タイマー。永続化とマルチユーザー同期が最初から付いている。
Patchwork の可塑性は少しずつ見えてきたが、大きな未解決の問題がいくつか残っている。
ひとつは、軽量で汎用的なバージョン管理というアイデアを、コードに対してどこまで徹底できるかだ。 ソフトウェアツールのブランチを作る基本的な仕組みはすでにあるが、ブランチをめぐる機能はまだ作り切れていない——たとえば、あるツールの異なるブランチを同時に表示して実行する、といったことだ。もっと大きく言えば、ソフトウェア開発をより非中央集権的な形で協働して進めることには、厄介な社会的問題があることにも気づいている。ひとつのツールについて、全員が同じバージョンを使うのか、それとも各自がフォークして別々に進むのか、どうやって合意するのか。そのツールの製品判断は誰が下すのか——最初に作った人が引き続き決めるのか、それとも誰でも自由に貢献できるようにするのか。魔法のように解決できる問題ではないが、バージョン管理のツールが助けになると考えている。
関連する課題のひとつは、品質に対する期待値の管理だ。私たちが作っているツールのほとんどは、商用製品のような磨き込みとは程遠く、粗削りな個人用ツールにすぎない。誰かがツールを共有するとき、その品質レベルをどう伝えればいいのか。「そのまま共有する」ことと、継続的なメンテナンスを約束することは、まったく別の話だ。
最後に、Patchwork の現在の埋め込みモデルは限定的で、これを改善したいと考えている。ツールは他のツールを埋め込めるが、埋め込まれた側のツールのインターフェースは窮屈に押し込まれてしまうし、ユーザーには階層の各レベルでツールを選ぶための、より良い方法が必要だ。また、UI コンポーネント間には、もっと豊かなコミュニケーションの仕組みが必要だと徐々にわかってきた。理由はいろいろある。たとえば、あの汎用コメントツール（どんなツールとでも組み合わせて使える）を作っているときに気づいたのは、ツールがユーザーの現在の選択範囲をセマンティックな領域として報告できると便利だということだった。こうしたツールの組み合わせを実現するために、私たちはいくつかハードコードされた回避策を追加したが、もっと汎用的で結合の少ない方法を見つけたい。おそらく、前述の entanglers や Varv のようなアイデアからヒントを得られるだろう。
Patchwork で、テキストドキュメントとスプレッドシートをホワイトボードに埋め込む
Patchwork は今も活発なプロジェクトだ。バージョン管理の取り組みについては初期の成果をすでに公開しており、実験ノートにまとめている。進展に合わせて、システム全体についてもっと多くのことを共有していく予定だ。最終的には、Patchwork をオープンソースツールとして公開することも計画している。
動的ドキュメント
インフラストラクチャの仕事では、ソフトウェアのホスティング方法に革新をもたらしたが、ソフトウェア自体の振る舞いは依然として従来のコードで定義されている。しかし、コードを書くこと——たとえ AI の支援があっても——は、使うことと変更することの間に険しい「崖」があることはわかっている。
そこで、もう一本の主要な作業の柱として、ユーザーがプログラミングなしでカスタムツールを作れるようにすることに焦点を当てている。前述のスプレッドシートや Hypercard など、いくつかの先例を紹介したが、いずれも同じ考え方を示している。直接操作できる情報から出発し、そこに選択的にプログラミング能力を重ねていくというものだ。
私たちは動的ドキュメントの取り組みでこの伝統を引き継いでいる。目標は、既存のメディアドキュメントに振る舞いを重ねられるようにする新しい技術を探ることだ。解明したいのは、ユーザーが情報をどう表現すれば、それにインタラクションを与えられるようになるのか、ということ。そして、ツール同士が同じドキュメントの中で協調し、共有の土台として共存するにはどうすればいいのか、ということだ。
Potluck：レシピ計画のための動的プレーンテキスト
Potluck では、ユーザーがテキストノートに動的な振る舞いを与える方法を探った。たとえばレシピで材料の分量を比例調整したり、タイマーを設定したりできる。ユーザーは自分が自然だと感じる任意のテキスト構文で情報を表現し、検出器を書いてテキストから意味のある構造を解析できる。
Potluck は多くの有用なツールの作成を支えられることがわかり、また、使い慣れた任意の形式で情報をさっと書き留められる体験は心地よかった。
Potluck ドキュメントでレシピを比例調整する。スケーリングスライダーの振る舞いは、ユーザーが Potluck エディタ内で数式言語を使って指定する。
AI 支援も Potluck にうまく統合できる。AI が検出器と計算ルールのセットを起草し、ユーザーは生成されたロジックをライブプログラミング環境で確認し、自分で編集できる。
AI 支援でレシピの分量を倍にする。生成された検出器と数式はそのまま確認・編集できる。
ただ、Potluck の問題のひとつは、任意のプレーンテキストから構造を解析するのがかなり面倒なことだった。複雑な検出器ルールを使わずに、関連する情報同士の関係（包含関係や順序関係など）を表現するのは難しい。
Embark：旅行計画のための動的アウトライン
次のプロジェクトでは、もっと構造化されたアプローチを試すことにした。旅行計画ドキュメント用のエディタ Embark を構築し、階層アウトラインを基本フォーマットとした。アウトラインが下層の構造を提供することで、Potluck で複雑なパターンを検出する際の問題の一部が解決された。
さらに、構造化情報を第一級の概念として導入した。Google Maps の位置情報のようなオブジェクトを「言及」してアウトライン内に保存できる。これらのオブジェクトは、経路計画や天気予報などの計算の入力として使える。
最後に、地図やカレンダーのようなリッチビューをアウトラインに埋め込み、旅行関連情報を可視化・操作できるようにした。
Embark ドキュメントで車のルートを計算する。ルート計算は周囲のドキュメントが提供するコンテキストを利用する。
Embark から得られた重要な結論は、豊かで共有されたコンテキストを持つ埋め込みモデルは強力なインタラクションを生むということだ。Embark に埋め込まれたビューは周囲の情報を深く認識する——地図ビューはアウトライン内の位置情報を読み取り、可視化できる。利用できる情報は局所的なコンテキストに依存する——地図をアウトラインの別の場所に移せば、表示する情報を制限できる。インタラクションも同期する——地図上の地点にマウスを重ねるとアウトライン内でそれがハイライトされ、その逆も同様だ。これらの仕組みが相まって生まれるのは一貫したユーザー体験であり、これはより制約の多い埋め込みのアプローチ——たとえば Patchwork で現在採用している方法や、あるウェブサイトが `` で別のウェブサイトを埋め込むやり方——では提供できないものだ。
Embark では、地図がアウトラインドキュメント内の構造化データとインタラクションできる。
Potluck と Embark の両方で直面した主要な課題は、情報のフォーマルな表現とインフォーマルな表現のバランスをどう取るかだ。思いつきを非構造的な方法で表現するのは価値があるが、計算ツールは一般に、より構造化された表現のほうをうまく扱える。さらに、データスキーマはユーザーの入力だけにとどまらない——Google Maps の位置情報には独自の構造化フォーマットがあり、そのフォーマットはさまざまなツール間で共通して使える必要がある。
最後に、Potluck と Embark で得たこれらのアイデアを、より広いタスクに一般化できるかどうかは、まだ結論が出ていない。この2つのプロジェクトをレシピと旅行という具体的なユースケースにそれぞれ落とし込んだのは、範囲を絞り、実際に使われるようにするためだったが、これらのアイデアの一般化をさらに試み、Patchwork のような可塑的なインフラストラクチャの上に統合していく計画だ。
より良い未来へ
この記事では、これまでとは異なる形のコンピューティングの姿を描いてきた。それは人々が自分自身のツールを作れるようにし、権力を地域コミュニティへと移し、人々が最高の仕事をする助けになる。こうした異なる形のコンピューティングが実際にどう実現されるかについても、先人の実践と私たち自身の仕事の両方から、多くのアイデアを共有してきた。
一方で、前方にある課題を過小評価するつもりもない。何十年もの間、アプリケーション中心のコンピューティングを洗練させることに膨大な労力が注がれてきた。新しい道を切り開くには、厄介な問題が山積している。私たちが根本的だと考える問題はすでにいくつか挙げた。受動的な利用から能動的な創造へ、どうすれば滑らかに移行できるか。アプリケーションをどうやって組み合わせ可能なツールに分解するか。協働する集団のニーズを、どうすれば常に中心に置けるか。
これでもまだ不完全なリストで、この記事ではほとんど触れていない重大な課題も残っている。
プライバシーとセキュリティ：拡張可能なソフトウェアと相互運用性を求めることと、悪意ある行為者が現実に存在することの間で、どうバランスを取るのか。信頼できない見知らぬ他人が既存ソフトウェアへの改変を共有し、そのソフトウェアが機密データにアクセスできるとなれば、危険なことが起こりうる。
ビジネスモデル：開発者がモノリシックなアプリケーションではなく、組み合わせ可能なツールを届けるとしたら、何で稼ぐのか。サポートとメンテナンスのコストは誰が負担するのか。
文化：個人の自律へ向かう運動をどう育てるか。人々が自分の環境——デジタルのものであれ、そうでないものであれ——を進んで作り変えたくなるようにするにはどうすればいいか。
いずれも手強い難問だ。技術的な能力だけでは完全な答えは出せない。経済と文化の変化も必要になる。だが変化は可能だ。コンピューティングはまだ若く、この数十年で大きく変わってきた。この先にも構造的な変革が大量に待っているはずだ。
多くの異なる立場の人が貢献できる。コンピューティングの研究者なら、コンピューティングの根底にあるメタファーを今こそ再構想し、より多くの権力をユーザーの手に渡す好機だ。プラットフォームの開発者なら、天秤を少し傾けてみてはどうか。エンドユーザーを、何としても守るべき受動的な利用者ではなく、能力ある参加者として見るのだ。安全性と、箱を開けてすぐ使える手軽さは長所だが、拡張性と強力さも同じく長所だ。ソフトウェア製品を作っているなら、あらゆることを代わりに決めるのではなく、ユーザー自身がもっと主導権を握れるようにする方法を考えてみてほしい。可塑的ソフトウェアを十分に実現するには根本的な変革が要ると私たちは考えているが、漸進的な改善にも同じだけ意味がある。
ある空間に住んだり働いたりする人が、自分のツールを少しずつ作り変えてニーズに合わせていく。そこから生まれる質は特別だ。可塑的ソフトウェアには、パロアルトで密室のうちに磨き上げられたようなデザインの一貫性はないかもしれない。だが時間が経つにつれ、古い家のような味わいが生まれることに私たちは気づいた。そこには過去の使われ方が刻まれ、以前の判断の痕跡が残り、同時に今のニーズに合わせて進化し続けている。
誰もが自分のデジタル環境を作り変える権利を持つべきだ。コードによって定義される部分がますます大きくなるこの世界で、それは私たちの創造的な可能性を発揮し、自律感を保つための重要な道だ。可塑的ソフトウェアを現実のものにするために、ぜひ一緒に取り組んでほしい。
私たちが進めている研究を追いたい方は、メールニュースレターを購読してください。
謝辞：
- 本記事で言及した研究プロジェクトに貢献してくれた Roshan Choxi、Orion Henry、Ignatius Gilfedder、Mark McGranaghan、Alexander Obenauer、Jeff Peterson、Max Schoening、Paul Shen、Paul Sonnnentag、Matt Tognetti、Adam Wiggins に感謝する。
- 本記事に貴重なフィードバックをくれた Mary Rose Cook、Marcel Goethals、Alex Komoroske、Clemens Klokmose、Steve Krouse、Jess Martin、Andy Matuschak、Paul Sonnentag、Alex Warth、Adam Wiggins に感謝する。
- 制作の場を撮影させてくれた Thomas Mitchell Clark（ギター製作家）と Nathan Peterson（Food Practitioner）に感謝する。