なぜ優れたUIと優れたコードは、どちらも「少しだけ不親切」なのか

Apr 28, 2026

1 min read

1 views

64%

まず、使いやすさは「全部を隠すこと」ではない

便利なものほど、内部が見えなくなります。ボタンを押せば動く、入力欄に文字を打てば整う、メソッドを呼べば面倒な処理が済む。けれど、現実の良い設計はもう少し複雑です。本当に優れた体験やコードは、複雑さを消すのではなく、必要なときだけ適切な形で差し出すからです。

この視点で見ると、見た目は全く違う二つの工夫が急に近づいてきます。ひとつは、Slackらしい入力欄のように、ただのTextFieldではなく、UIとして「ここに書くと気持ちよい」状態を作る工夫。もうひとつは、Rails以外のRubyでも、Railsっぽいdelegateを小さな仕組みとして持ち込む工夫。前者は画面の触り心地、後者はコードの触り心地の話です。どちらも共通しているのは、既製品のままでは足りない違和感を、過剰に大きな道具を入れずに解決することです。

ここに面白い問いがあります。なぜ私たちは、わざわざ「ちょっとだけ面倒な自作」をするのか。 その答えは、単なる好みではありません。良いプロダクトや良いコードベースは、道具のサイズが体験に合っていることを知っているからです。大きすぎる抽象化は重すぎるし、小さすぎる実装は使いにくい。その中間にある、ちょうどよい密度を探すことが設計なのです。

小さな違和感は、だいたい「抽象化の粒度」が合っていない

SlackっぽいTextFieldを作りたくなるのは、見た目を真似したいからだけではありません。入力欄は単なる文字の受け皿ではなく、注意の向き方、送信のリズム、改行の扱い、マウスやタップへの反応まで含んだ行為の器だからです。標準のTextFieldが悪いわけではないのですが、アプリの文脈によっては、欲しいものが微妙にずれます。

たとえばチャットの入力欄では、Enterの意味ひとつ取っても単純ではありません。送信なのか、改行なのか、IME入力中の確定なのか。ここで重要なのは、技術的に可能かどうかではなく、ユーザーの意図を誤解しないかです。Slackっぽさの本質は、見た目の角丸や余白よりも、入力のふるまいが「会話の延長」に感じられることにあります。

同じことがコードにも起こります。Railsのdelegateは、あるオブジェクトが別のオブジェクトの責務を肩代わりするときの、非常に自然な記法です。ところがRails外のRubyで同じ気持ちよさが欲しくなると、途端に選択肢が変わります。ActiveSupportを丸ごと入れるほどでもない、でも毎回手で書くには冗長すぎる。ここでも問題は、機能の有無ではなく抽象化の粒度です。

人は「できるかどうか」ではなく、「気持ちよく繰り返せるか」で道具を選ぶ。

UIでもコードでも、違和感の正体はたいてい同じです。必要な表現力が足りないか、逆に抽象化が重すぎるかのどちらかです。優れた設計はその中間を狙います。完全な汎用性は捨てる代わりに、今の文脈で一番よく使う道筋を太くするのです。

便利さの本体は、機能の数ではなく「摩擦の位置」を変えること

ここで発想を少し変えてみましょう。多くの人は、良いUIや良いAPIを「操作数が少ないもの」と考えがちです。けれど本当に重要なのは、摩擦を消すことではなく、摩擦の場所を正しく移すことです。

Slack風の入力欄を考えると、入力そのものはシンプルに見えます。しかしその裏では、フォーカス、パディング、プレースホルダ、改行、送信、入力中の状態など、複数の要素が緻密に配置されています。ユーザーに見せる摩擦は少ない一方で、実装者は細部を丁寧に管理します。つまり、摩擦は消えたのではなく、ユーザーから設計者へ移動したのです。

delegateも同じ構造を持っています。呼び出し側は、あるメソッドを「自分の責務として」呼べる。内部では、それが別オブジェクトへの委譲だと意識しなくて済む。これによって、コードの利用者は余計な配線から解放されます。ただし、その自由は無償ではありません。どこに委譲があるのか、どこまで責務を広げてよいのかを、設計者がきちんと見極める必要があります。

この関係は、料理に似ています。食べる側は盛り付けが整っている料理を「簡単に食べられる」と感じますが、実際には下ごしらえ、火加減、味の調整という複雑さが裏側に隠れています。良い料理は、手間をなくしたのではなく、食べる人にとって意味のない手間を引き受けたのです。

プログラムも同じです。良い抽象化とは、全体を単純化することではなく、使い手にとって意味のある経路だけを残すことです。入力欄なら「書く」「送る」「改行する」の経路。delegateなら「このオブジェクトとして振る舞う」という経路。余計な分岐を消すのではなく、意図に沿った分岐だけを前面に出すことが、使いやすさの核心です。

「Railsっぽい」も「Slackっぽい」も、実はコピーではなく文脈適応である

ここで見逃しやすいのは、どちらの工夫も単なる模倣ではないことです。Slackっぽい入力欄を作るとき、目指しているのはSlackの見た目そのものではありません。欲しいのは、あのアプリを使っているときの文脈の自然さです。Railsっぽいdelegateも同様で、模倣したいのは文法ではなく、Rubyで書くときの意図が読みやすくなる感覚です。

この違いは重要です。単純なコピーは再現性はあっても、理由がないと脆い。文脈適応は、その場に合う体験を作るので、結果として長持ちします。たとえば、同じ「入力欄」でも、チャット、検索、フォーム、メモでは求められる性質が違います。ある場面では即送信が正義でも、別の場面では改行が正義です。ある場面では委譲を徹底的に隠すべきでも、別の場面では明示したほうが安全です。

つまり、優れた設計とは「ベストプラクティスを守ること」ではなく、文脈ごとに最適な失敗のしにくさを作ることです。UIでは、誤入力や迷いを減らす。コードでは、冗長な定型や責務の散らばりを減らす。どちらも、使う人の頭の中にある判断回数を減らすための工夫です。

設計の価値は、選択肢を増やすことではなく、正しい選択肢が自然に選ばれるようにすることにある。

この視点を持つと、自作の意味が変わって見えます。自作は「車輪の再発明」ではなく、文脈に合わせて車輪の幅や材質を変える行為です。標準部品が悪いのではありません。ただ、標準部品が最適とは限らない。特に、使い勝手の微妙なズレが体験を左右する領域では、そのズレを放置しないことが重要です。

良い自作は、野心ではなく境界線の設計である

自作というと、つい大きな野心を想像しがちです。もっと速く、もっと汎用的に、もっと賢く。しかし実際に価値が出るのは、むしろ逆です。良い自作は、できることを増やすより、守るべき境界を明確にするからです。

Slack風のTextFieldなら、入力欄に必要なのはチャット体験であって、巨大なエディタ機能ではありません。delegateも同じで、欲しいのはRubyのコードをRailsのように重くすることではなく、よくある委譲パターンを軽く書けることです。つまり、どちらも「多機能化」ではなく狙いを絞った再表現です。

このとき大切なのは、実装の美しさよりも、境界の読みやすさです。どこまでが標準の責務で、どこからが自分の文脈なのか。どこまでがUIコンポーネントで、どこからがアプリの振る舞いなのか。どこまでがオブジェクト自身の責務で、どこからが委譲先の責務なのか。境界が曖昧だと、便利さはすぐ負債に変わります。

ここで使える実践的な判断基準があります。

その違和感は毎回起きるか 一度きりなら我慢できても、繰り返すなら抽象化の候補です。
その違和感は文脈固有か プロジェクト固有なら小さく作る価値が高いです。一般解を追いすぎると重くなります。
その便利さは利用者の判断を減らすか 判断が減らない便利さは、単に設定項目が増えただけかもしれません。
その抽象化は見えないコストを増やしていないか 便利に見えても、依存や把握コストが増えるなら本末転倒です。

小さな自作の価値は、機能の派手さでは測れません。むしろ、どれだけ静かに日常の摩擦を減らしたかで測るべきです。

Key Takeaways

良いUIも良いコードも、複雑さを消すのではなく適切な場所へ移す。
違和感の正体は、たいてい抽象化の粒度が文脈に合っていないこと。
自作の目的は機能追加ではなく、境界線を明確にして使い手の判断回数を減らすこと。
「Railsっぽい」「Slackっぽい」はコピーではなく、その文脈での自然さを取り戻す作業。
小さな定型の自動化ほど、毎日の体験に大きな差を生む。

では、何を作るべきか

次に何かを作るとき、まず問うべきなのは「もっと機能を増やせるか」ではありません。どこで人が迷っているか、どこで同じ文章を何度も書いているか、どこで入力や委譲が不自然に感じられるかです。そこに、あなたの文脈だけに効く小さな仕掛けを置く。すると、見た目には地味でも、体験全体は驚くほど滑らかになります。

入力欄ひとつ整えることと、delegateひとつ整えることは、実は同じ営みです。どちらも、人が毎回考えなくてよいことを、設計が先回りして引き受ける行為だからです。優れたプロダクトやライブラリは、豪華なことをするのではなく、当たり前を気持ちよくする。

その意味で、最も洗練された設計とは、派手に目立つものではありません。むしろ、使う人に「何も意識しなくてよかった」と感じさせるものです。ただし、その静けさの裏には、必ずどこかで誰かが丁寧に線を引いています。入力欄の線、責務の線、委譲の線。私たちが本当に鍛えるべきなのは、機能の数ではなく、その線を引く眼差しなのです。