なぜ速い開発は、テストを減らす前に摩擦を設計するのか

May 15, 2026

1 min read

3 views

63%

たった10分が、開発体験を壊す

毎PRで10分かかるテストは、数字だけ見れば小さく見えるかもしれません。だが、開発者の体感ではまったく違います。コードを書き、確認し、直し、また確認するという小さな往復のたびに待ち時間が挟まると、思考は分断され、手応えは鈍り、実験の回数が減ります。

そして面白いのは、こうした遅さは必ずしも「テストが多すぎる」から起きるわけではないことです。むしろ本質は、変更と確認の距離が長すぎることにあります。画面の一部を少し直しただけなのに、アプリ全体を毎回見に行くような設計では、速度は時間の問題ではなく、構造の問題になります。

一方で、ある場面では、誰も見たことのないUIを自分で実装しようとして、検索しても決定版が見つからず、手探りで組み立てることがあります。たとえば、あるアプリの入力欄を別の有名アプリのような感触に寄せたいときです。ここでは速さの問題は、CIではなく、**「正解がないものをどう具体化するか」**という問題として現れます。

この二つは一見別の話に見えます。しかし実際には、どちらも同じ問いにぶつかっています。

私たちは、まだ形の定まっていないものを、どうやって速く、確実に、気持ちよく作るのか。

本当のボトルネックは、テスト時間ではなく「意味の距離」

開発が遅くなるとき、多くの人はまず実行時間に注目します。並列化する、分割する、キャッシュする、対象を絞る。もちろんそれらは重要です。だが、さらに深いレベルでは、遅さの正体は変更の意味がどれだけ広範囲に波及するかを、システムがうまく把握できていないことです。

たとえば、入力欄の角丸を少し変えたとします。その変更は見た目だけの話のようでいて、フォーカス時の挙動、スクロール時の追従、キーボード表示時のレイアウト、送信ボタンとの距離感まで連鎖します。もし確認が手作業中心なら、たった一行の変更が、広い意味の探索になってしまいます。

逆に、コンポーネント単位で変更を検知し、その変更に関係するテストだけを実行できれば、確認の範囲は一気に狭まります。ここで重要なのは、単にテスト数を減らすことではありません。変化した場所にだけ注意を向ける仕組みを作ることです。これにより、開発者は毎回全体を見渡すのではなく、意味のある局所に集中できます。

これはUI設計にもそのまま当てはまります。SlackのようなTextFieldを作るとき、必要なのは「入力できる箱」を置くことではなく、どこで改行するか、どこで送信するか、どこで空状態を見せるか、どの状態がユーザーに安心感を与えるかを見極めることです。UIの良し悪しは見た目の近さではなく、状態遷移の気持ちよさに宿ります。

つまり、開発速度を左右するのは単純な実行時間ではなく、変更がどれだけ賢く局所化されているかです。速いチームは、ただ速く走るのではなく、関係ないものを巻き込まないように設計しています。

良い開発体験とは、「全体を毎回見なくて済む」こと

人は複雑なものを一度に理解できません。だからこそ、優れたシステムは「全体を見せる」より先に、「今見るべき部分だけを見せる」ことを重視します。ここに、テスト設計とUI設計の深い共通点があります。

入力欄をSlack風にする作業を考えてみてください。ユーザーが期待しているのは、単なる文字入力ではありません。入力中の行間、送信の確信、貼り付けた瞬間の見え方、長文になったときの伸び方、キーボードとの相性など、細かな摩擦の総和です。つまり、UIは一つの部品ではなく、体験の境界面です。

テストも同じです。インタラクションテストは、ただ「動くか」を確認するものではありません。人が触れたときにどこで不安になるか、どこで期待が裏切られるかを見つけるための装置です。だからこそ、毎PRで10分かかるなら、そのままの形では体験の境界面として重すぎます。開発者はコードを書いた直後に、その境界面を越えて戻ってこなければならないからです。

ここで有効なのが、**「確認コストを、変更の粒度に合わせる」**という考え方です。大きな変更には広い確認が必要です。しかし小さな変更に毎回フルコースの確認を要求すると、開発者は自然に試行回数を減らします。すると、発見の機会が失われ、結果として品質も下がります。

この観点から見ると、速い開発とは、ビルドやテストを単に高速化することではありません。「触るたびに気軽に確かめられる」状態を作ることです。気軽さは贅沢ではなく、創造性の前提条件です。

速さの本質は、時間短縮ではない。試行回数を減らさずに済むことだ。

テスト分割とUIの細部は、どちらも「局所性の設計」である

ここで一つ、見落とされがちなメンタルモデルを提示したいと思います。それは、開発システムは局所性の設計であるという見方です。

局所性とは、ある変更がどれだけ狭い範囲で完結するか、あるいはどれだけ狭い範囲の確認で十分か、という性質です。UIであれば、ボタンを押したらその場で反応が見えること。テストであれば、あるコンポーネントを変えたら、そのコンポーネントに関係する検証だけで済むことです。局所性が高いほど、学習と修正は速くなります。

この視点を持つと、Shardingのような分割実行は単なる計算資源の話ではなく、認知の圧縮として理解できます。全ケースを一度に見るのではなく、複数の小さな視野に分けることで、結果を読み解く負担を下げる。変更検知で関連テストだけを回すのも同じです。対象を絞ることで、開発者の注意を最も価値の高い場所に留めるのです。

UI実装でも、同じ原理が働きます。たとえば、Slack風のTextFieldを作るとき、見た目を完全に再現しようとして全体を一気に複製すると、内部の状態管理やフォーカス制御まで複雑化しがちです。そうではなく、入力エリア、プレースホルダー、送信タイミング、行の伸縮といった要素を分けて考え、それぞれを小さく検証するほうが、結果として完成度は高くなります。

このとき大切なのは、「小さくすること」と「簡単にすること」は違うと理解することです。小さな部品に分けるからこそ、どこで壊れたのかがわかりやすくなり、どこを直せばよいかが見える。つまり、局所性は複雑さの隠蔽ではなく、複雑さの可視化です。

実は、良いUIも良いテストも、ユーザーや開発者に「ここだけ見ればいい」という安心感を与えます。その安心感があるから、人は頻繁に触れられる。頻繁に触れられるから、改善が進む。改善が進むから、さらに触りやすくなる。この循環こそが、開発速度の正体です。

速いチームは、確認を後工程に押し込まない

多くのチームは、速度を上げようとして確認を後ろに寄せます。とりあえず作る。まとめて見る。最後にまとめて直す。しかしこれは、開発の中で最も高くつくやり方です。なぜなら、後半になるほど変更の意味が増殖し、どの修正が何に効いたかがわからなくなるからです。

対照的に、速いチームは確認を前倒しします。コンポーネント単位で確かめる。UIの違和感を早めに見つける。関連するテストだけを回す。これらはすべて、**「あとでまとめて理解するコスト」**を減らすための工夫です。

この発想を日常的な比喩で言えば、料理に近いです。10品を最後に一度に味見するより、炒めるたびに塩加減を確認するほうが、全体の失敗は減ります。しかも、途中で微調整できるため、完成品の自由度も高い。テストもUIも同じで、後で一気に確認するより、途中で小さく確かめるほうが、最終的な品質は上がります。

ただし、ここで誤解してはいけないのは、前倒しが目的ではないということです。目的は、学習ループを短くすることです。入力欄の見た目が少しおかしいとき、その場で直せるなら、思考は途切れません。テストが10分かかるなら、その10分の間に別の作業へ逃げてしまい、元の文脈を失います。速さとは、待ち時間の短縮以上に、文脈保持の技術なのです。

Key Takeaways

速さの本質は、実行時間の短縮だけではない。 変更した場所にだけ注意を向けられる設計が、開発体験を大きく変える。
テストは数を減らすより、関連性を高める。 変更検知やコンポーネント単位の実行は、確認の意味を局所化するために有効。
UIの細部は、見た目ではなく状態遷移で考える。 Slack風のTextFieldのような実装は、入力中、送信時、空状態、長文時の振る舞いを分けて設計するとよい。
良い開発体験は、全体を毎回見なくて済むことから生まれる。 人間の認知負荷を減らすことが、結果として品質と速度の両方を押し上げる。
確認は後工程に押し込まず、小さく前倒しする。 早いフィードバックは、ミスを減らすだけでなく、試行回数を増やし、創造性を守る。

まとめ: 速さとは、摩擦を減らすことではなく、摩擦を設計すること

私たちはしばしば、開発を速くするとは摩擦を消すことだと考えます。しかし本当に重要なのは、摩擦をゼロにすることではありません。意味のある摩擦だけを残し、無意味な摩擦を消すことです。

テストの10分は、ただ長いのではなく、変更と確認の距離が遠すぎるサインです。Slack風のTextFieldを手探りで作る苦労は、ただ珍しいUIだから大変なのではなく、まだ言語化されていない体験を具体化する必要があるからです。どちらも、開発とは「正解を当てる作業」ではなく、正解に近づくループをいかに短く、濃く、局所的に回すかだと教えています。

だからこそ、速いチームは単に自動化を増やすのではありません。変更の意味を小さくし、確認の視野を絞り、試行を止めない仕組みを作ります。そこでは、テストもUIも、別々の技術ではなく同じ哲学の表現です。

そしてその哲学は、こう言い換えられます。