本当に良いツールは「空気」であるべき：エンジニアが知るべきUXの極意

「優れたツールは意識させない」という言葉を聞いたことがありますか？真に使いやすいツールやフレームワークとは、学習コストを感じさせず、開発者の思考を止めることなく、まるで自分の指先のように自然に馴染むものです。もし今、あなたがツールそのものの設定や複雑な作法に振り回されているなら、それは「良いツール」ではありません。エンジニアリングにおいて、最も洗練された体験とは、ツールが透明化し、ただ作りたいものだけに集中できる環境を指すのです。

いやはや、これまた極端な意見ですね。著者がVimの「可視性」に執着し、Sublimeのマルチカーソルやその他の機能がそうではないかのように示唆しているのは奇妙です。脳が慣れて意識しなくなったからといって、可視性が低いわけではありません。マルチカーソルは多くのツールで標準搭載されている機能ではないため、効率的に使うには習得が必要です。Vimのキーバインドと同じですよね。それにVimはターミナルユーザー向けのTUIというだけじゃなくて、キーボードを自分の体の一部として馴染ませ、何度もマウスに持ち替えるのを避けたいという人たちのためのキーバインドでもあります。15年Sublimeを使っている人がマルチカーソルをそう捉えているのと同じようなものです。

長年ターミナルを使っている身としては、人々が「理解できない」としてもあまり驚きません。議論はいつもこうなりがちです。「ターミナルなら簡単なコマンドでこうできる」「いや、私のFrobnicatorStudioにはCtrl+Alt+Soっていうショートカットがある」と。これだと不毛な比較が永遠に続きます。「Vimならキー4つで24行消せる」（Sublimeユーザーには無縁の話）対「Sublimeにはマルチカーソルがある」（Vimユーザーにも無縁の話）みたいなね。ここで重要な論点は、ターミナルは小さなCLIツールをパイプラインで組み合わせることで無限のユースケースをカバーできるけれど、習得に1年くらいかかるという点でしょう。そこまで到達すれば平均的なGUIユーザーより生産性は圧倒的に高くなりますが、苦労と努力が必要です。多くの人は不本意ながらも、仕事でSSH越しにサーバー管理を強制された結果、身につけていくものです。そういう経験がなければ、わざわざターミナルの苦痛を味わおうとは思わなかったでしょうね。

社内ツールを開発者向けに数多く設計してきた身として、これ以上ないほど共感します。以前は「中身が見える」状態にしておくのが開発者のためだと思っていたのですが、結局それがチームメイトの作業を邪魔しているだけでした。彼らは自分たちの仕事をこなすためにツールを使っているわけで、どこにもないような独自ツールをいじくり回したいわけではないんですよね。今でも「逃げ道」は残していますが、ユーザーが自然と成功するように導く設計を心がけています。追記：エラーメッセージの質と、よくある間違いへの自動提案は本当に重要ですね。あと、投稿の核心ではなく例示された部分ばかりを攻撃する人が多いのは……がっかりします。

この言葉を思い出しました。「人は常にお辞儀をしてへりくだる者を注目し、『なんて謙虚なんだ！』と言う。しかし、真に謙虚な者は誰にも気づかれない。世界はその者のことを知らないのだ。」～ ティト・コリアンデル

たいていの場合、キーボード操作がいかに生産的か、マウスに手を伸ばすのがどれだけ無駄かを理解していないからです。実際、生産性が高いと自負する人たちの多くは、それを正確に測定したことがありません。本当にそうなのかを知らないのです。長年、キーボード対マウスの生産性競争は行われてきましたが、テストの詳細次第でどちらが勝つかは変わります。多くの場合、テストの前に「自分のほうが生産的だ」と主張していた側が、結果を見て負けているというケースも少なくありません。

著者は慣れ親しんだツールが優れていることの証明だと勘違いしているようです。現実はどのツールもトレードオフであり、XよりYを好むからといってユーザーが愚かなわけではありません。そのツールが持つ「アフォーダンス」を使いこなしているからというだけの話です。ある開発者にVim、Emacs、Sublime Textを10年ずつ使わせたら、どれが一番なんて断言できなくなるはずです。個人的なお気に入りはあっても、なぜ他の人が違うツールを使うのか理解できるようになるからです。これは、使い慣れないソフトウェアにまともなチャンスを与えたことがない無知から生まれる議論のように思えます。補足：長く業界にいる古参の証は、あらゆるソフトウェアに対してなんとなく不満を持ち、新しい改善の約束を疑うことかもしれません。結局、どんなソフトウェアも長期的には凡庸さに収束していくものですから。

インターフェースが「透明化」するのは、それに費やした時間の関数です。著者が言及しているのは、デザイナーやプロダクト担当が付け加えた「意図的な摩擦（discretionary friction）」への違和感かもしれません。ただ、マージコンフリクトの解決のように、タスク達成のために必要な摩擦というのもあります。十分な時間を費やせば、それらの「破壊的な」ステップでさえ背景に溶け込んでいくものです。具体例を挙げると、737のコックピットは操作パネルが非常に密ですが、パイロットとして10年以上経験を積めば、インターフェースは不可視なものになります。Bloomberg端末や、医療現場のMRスキャンソフトなどでも同じです。ボタンが散乱しているように見えても、毎日8時間以上使う人にとっては、即座にアクセスできることが正解なのです。プログラマーとして、自分の経験や好みを他人に一般化しすぎるのはよくないですね。ソース：IDEOで10年間コンシューマー向けおよび専門ソフトの設計をしていた経験から。

よく言った！ただ、多少いじり回す必要があるツールも魅力的ではあります。毎日ツールが小さなパズルを投げてきて、それを解くというね。その小さな達成感が人を正気に保つこともあります。ツールの言語を本当に理解しているという実感を持つのは悪くないものです。とはいえ、最近は箱から出してすぐに動かないものには疲れました。摩擦が少ない方を選びたい派です。VS Codeのようにプラグインで理想の環境を作るのは魅力的ですが、職場のフローがQTCreatorやVSに依存しているなら、摩擦が最も少ないそれらを使うのが賢明です。音楽プレイヤーも同様で、HQPlayerは設定が大変なので、使い勝手の良いMusicBeeを使っています。若くてエネルギーがあるうちは摩擦も楽しいですが、仕事が日課になるとそうも言っていられませんね。

GUIツールはインターフェースが標準化されていた90年代の方が優れていました。「透明化」の要因もそこにあったと思います。誰かが「標準ウィジェットよりWebアプリのパッケージ化の方がクールだ」と考えた結果、会社の独自デザイン哲学を学習させられるのは御免です。最近ターミナルばかり使うのは、予測可能性が高くトータルの摩擦が少ないからです。もし皆がuser32.dllのモダンな後継のようなものを使っていたら、GUIの世界から離れることもなかったでしょうね。

これは逆の視点からも真実です。ツールをすべて可視化することが「心地よい」ユーザーもいます。F16の操縦席に座って、すべてのボタンを把握していることに安心感を得るようなものです。しかし、これはスケールしません。目の前にボタンを100個並べることはできても、1000個は無理です。人間の複雑さの許容範囲には限界があります。多くの人に使ってもらいたいなら、ユーザーが増えるごとにボタンの数を減らし、ツールをより不可視な方向へと進化させる必要があるのです。