Vim と NeoVim をめぐる小さな出来事の話だが、ソフトウェアがユーザーのデータをどう扱うべきかという点では、かなり重い話でもある。元記事は、ある Mastodon 投稿を手がかりに、編集者が「このソフトは信頼できるのか」をどう判断するかを語っている。便利さや機能の多さより先に、積み上げた作業を壊さないことがどれだけ大事か、そこに目を向けさせる記事だ。しかも、単なるバグ報告では終わらず、設計思想そのものへの不信に話が広がっていく。
元記事の出発点は、コンピュータ科学者の David Chisnall が Mastodon に書いた投稿だ。彼は 2000年ごろから vim を使っていて、本を書き、博士論文を書き、何十本もの論文や 150本以上の記事も vim で書いてきたという。長年使っていると、よく使うコマンドは意識せずに手が動く。だからこそ、作業の途中で「うっかり消したものを戻せる」仕組みは、単なる機能ではなく生活の一部になる。
Chisnall が特に気に入っていたのは、persistent undo だった。これは、undo の履歴をファイルとして残し、ファイルを閉じたあとや再起動後でも、過去の編集履歴に戻れる仕組みだ。彼の説明では、削ってしまった文章を一週間前のファイルから探し出して戻したり、いったん整えたコードを commit 前に壊してしまったときに、何を変えたのかを辿ったりできる。しかも vim は、この機能を約 20年にわたる大きなバージョンアップの間も維持してきたという。彼にとっては、特別な操作ですらなく、Raskin の第一法則そのものだった。つまり、ソフトウェアはユーザーのデータを傷つけてはならないし、放置によっても損なわせてはならない、という考え方だ。
ところが NeoVim で同じことを試すと、undo が効かなかった。しかも事情は少し複雑で、NeoVim は vim の fork、つまり派生版だ。最初は「vim より良くなったもの」と期待して使い始めたが、実際には undo ファイルの形式が変わっていて、古いファイルをアップグレードするわけでも、別名で扱うわけでもなかった。NeoVim は vim の undo ファイルを見つけると、その中身を消し、vim からは読めない新しい形式で置き換えてしまったという。Chisnall が issue を立てると、「persistent undo の形式は不安定なので、データが保存されることを当てにしないでほしい。いちど変わったし、また変わるだろう」という趣旨の返答があった。
彼はこの時点で NeoVim を見限った。単に機能が壊れていたからではない。ファイルシステム上にあり、しかもユーザーが必要とするかもしれないデータを、プログラムが勝手に削除してよいという態度に、信頼を置けなかったからだ。元記事の筆者はこの投稿をほぼ全文引用しつつ、そこから「人は自分の作業を失うこと、あるいは軽んじられることを覚えている」という点を重ねている。そして最後に、Jef Raskin の『The Humane Interface』にある三つの法則を挙げる。コンピュータは作業を傷つけてはならない。無駄に時間を奪ってはならない。人間の都合や弱さに配慮していなければならない、という内容だ。筆者にとっては若い頃に強い影響を受けた本で、こんな重要な考えがこの blog に今まで出ていなかったのが不思議だ、とも書いている。
この記事でいちばん面白いのは、技術的な出来事そのものより、そこから一気に「この開発者たちを信じていいのか」という話に飛ぶところだと思う。persistent undo を壊しただけなら、多くの人は「移行時の不具合だったのだろう」と受け止めたかもしれない。だが Chisnall は、壊れたこと以上に「壊しても構わない」と考える姿勢に反応している。ここには、ソフトウェアの品質をどう測るかという視点の違いがある。機能一覧に載っているか、ベンチマークが速いか、UI が洗練されているかだけではない。失って困るものを、実際に失わせないか。その一点で見たときに、評価はかなり変わる。
この感覚は、開発者側には案外見えにくい。自分たちはフォーマット変更を「仕様変更」や「内部整理」と呼びたくなる。でもユーザーの側からすると、保存していた履歴を消されるのは、途中まで書いた文書を勝手に破り捨てられるのに近い。しかも undo は、派手さはないが一度慣れると手放せない機能だ。日常的には意識しない。けれど、必要になった瞬間だけは替えがきかない。だからこそ、壊れたときの落差が大きい。私はここに、ソフトウェアの信用が「普段は気づかれない場所」で決まる厳しさがあると思う。
Chisnall が persistent undo を「何度も使うものではないが、必要なときは非常にありがたい」と語っているのがいい。こうした機能は、売り文句としては地味だ。でも実際の作業では、派手な新機能よりずっと効くことがある。書きかけの文章や修正前のコードは、最初から「元に戻すつもりで」作るわけではない。雑に直したり、後で整えたり、気が変わって戻したりする。その揺れを許容するための仕組みが undo であり、さらに過去にさかのぼれる persistent undo は、失敗を前提にした設計だと言える。
ここで思うのは、良い編集環境とは「速い」ことより「失敗しやすい人間に優しい」ことではないか、という点だ。Raskin の法則が強いのは、まさにそこを突いているからだろう。人は集中していてもミスをするし、時間が空けば何をしたか忘れる。ソフトウェアがその前提を受け入れるなら、ユーザーは安心して大胆に試せる。逆に、履歴を壊すような挙動があると、作業はどんどん慎重になり、結局は速さも落ちる。機能の削除ではなく、創作や編集の自由度を削ることになるからだ。
NeoVim 側の返答として紹介される「形式は不安定だから、保存を期待しないでほしい」という考え方も重い。技術的には、将来の互換性を完全に保証できない場面はある。ただ、問題はその説明がどこまでユーザーの感覚に寄り添っているかだと思う。名前に persistent と付いた機能に対して、「永続を当てにするな」と言ってしまえば、言葉と実態がぶつかる。ユーザーは機能名を仕様の約束として読む。そこで裏切られると、次に何を信じればいいのか分からなくなる。
私は、ここで失われるのは undo そのものより、「このソフトは自分の資産を守る側に立っている」という感覚だと思う。互換性の維持は面倒だし、内部表現を変えたくなる場面もあるだろう。だが、その都合を押し通してしまうと、ユーザーは「いつかまた壊されるのでは」と身構えるようになる。そこから先は、機能の評価ではなく関係の評価になる。信頼が切れると、同じソフトでも使われ方が変わる。大事な作業には使わない、履歴を頼らない、バックアップを余計に増やす。便利なはずの道具が、警戒対象になるわけだ。
元記事が引用した Raskin の法則は、単なる古典的名言ではなく、今もそのまま通じる現場感覚だと思う。とくに第1の法則は強い。作業を壊さないことは、バグを減らすという狭い話ではない。データをどう保つか、互換性をどこまで守るか、破壊的変更をどう伝えるかまで含む態度だ。そこに無頓着な組織は、たぶんプロダクトのどこかでまた同じことをする。
この文章を読んで、私は「良いソフトウェア」は機能が多いことより、失敗したときに人を見捨てないことだと改めて感じた。しかもその判断は、公式サイトのデザインや勢いのあるリリースノートでは見えにくい。むしろ地味な細部、たとえば undo の履歴をどう扱うかに出る。派手さの裏で、ちゃんとユーザーの立場に立てるか。そこが問われているのだと思う。
参考: “They had no concept of a duty of care to their users.” – Unsung
