Skip to main content
ブログに戻る
ブログ

ソフトウェア開発における空間的思考

キャンバス上で作業を配置するのが、見た目がきれいだからではなく、認知的に優れている理由。開発者ツールに空間インターフェースが必要なわけです。

この 40 年間、あらゆる開発者ツールは同じレイアウトでした。左にファイルツリー、中央にエディタ、下にターミナル。上にタブ。場合によっては検索や git 用のサイドバーがつきます。

このレイアウトは機能します。しかし、隠れたコストがあります。すべてが互いに重なり合ってしまうことです。1 度に見えるのは 1 つのファイル、1 つのターミナル、1 つの出力だけ。空間的な把握は、タブ切り替えとキーボードショートカットの連続に縮小されます。

デザインツールが 10 年前に解いた問題を、開発者向けにも適用したらどうでしょうか。開発者にもキャンバスを与えるのです。

タブ税

1 日に何回タブを切り替えていますか。ソフトウェア開発者の研究では、平均して 1 日 300〜400 回のコンテキストスイッチがあるとされています。スイッチ 1 回は無料ではありません。短いタブ切り替えでも、再び文脈を取り戻すのに 15〜25 秒かかります。

つまり、1 日で 75〜150 分が再調整に使われていることになります。コーディングではなく、考えることでもなく、ただ「自分がどこにいたか」を思い出すためです。

この問題が起きるのは、タブが空間の別名だからです。3 つのターミナルが 3 つのタブにあるとき、それらは同じ画面位置を共有しています。脳は、タブ名の裏に何があるかを内部マップとして保持しなければなりません。これは、問題解決ではなくナビゲーションにワーキングメモリを使っている状態です。

空間レイアウトが認知負荷を下げる仕組み

キャンバス上では、その 3 つのターミナルはそれぞれ別の位置にあります。Terminal A は左、Terminal B は右、計画を書いたノートはその上。タブの裏側を覚える必要はありません。見えているからです。

研究ではこれを 外部認知 と呼びます。空間情報を環境(画面)に外部化すると、実際の問題を考えるためのワーキングメモリが空きます。物理的な書類を机に広げ、山積みにしないのと同じ理由です。

具体的な利点は 3 つあります。

1. 周辺視野での把握

Terminal A が画面左側で出力を始めたとき、あなたは右側の Terminal B に集中したままでも、周辺視野でそれに気づけます。タブ方式なら、Terminal A を終えたかどうかは切り替えて確認するまで分かりません。

この周辺視野での把握は、マルチエージェント作業で非常に重要です。各エージェントを個別にポーリングせずに、完了したか、詰まっているか、注意が必要かを知る必要があります。

2. 空間記憶

人間は、物事が「どこにあるか」を非常によく覚えます。認証コードが左のファイルにあり、テストが右にあり、API ドキュメントが上にある、といった具合です。この空間的な符号化は速く、ほとんど努力を要しません。物理空間を移動するときに使っている記憶システムと同じです。

対してタブのラベルは、言語的な記憶に頼ります。「左から 3 番目のタブは... テストランナーのターミナル? それとも 4 番目だった?」といった具合です。こちらのほうが遅く、誤りも起きやすいです。

3. 関係の可視化

キャンバス上では、物事のつながりが見えます。Terminal A から Terminal B へのルーティング線があれば、データフローが可視化されます。フレームでグループ化されたタイルは、同じプロジェクトに属することを示します。近さは関係を意味します。

タブベースのインターフェースでは、関係は見えません。リファクタリング用ターミナルとテストランナー用ターミナルの関係は、頭の中にしかありません。

デザインツールの先例

Figma、Miro、その他のキャンバスベースツールは、10 年以上前にデザイナー向けにこの考え方を証明しました。Figma が登場する前、デザイナーは単一キャンバスのアプリで 1 つのアートボードずつ作業し、レイヤーは見えないまま積み重なっていました。Figma は、すべての画面、コンポーネント、状態が空間的に共存する無限キャンバスを提供しました。

その結果は、単なる「見た目の良い UI」ではありませんでした。考え方そのものが変わったのです。デザイナーは画面ではなくシステムを見るようになり、フロー、状態、ユーザージャーニーで整理するようになりました。空間レイアウトが、そのままデザイン思考になりました。

開発でも同じ変化が起きつつあります。エージェントをキャンバスに配置し、リファクタリング担当のエージェントを変更対象コードの横に置き、レビュー担当を下に、テストランナーを隅に置く。これは単なるウィンドウ整理ではありません。開発ワークフローを、見える・触れる構造として外部化しているのです。

空間が役立たない場面

空間インターフェースが常に優れているわけではありません。次のような場面では劣ります。

  • 単一ファイルを深く編集する場合 — 1 つのファイルに最大限の画面領域が必要なら、従来のエディタが勝ちます。
  • 単純な逐次タスク — 1 つのコマンドを実行して待って、次を実行するだけなら、タブで十分です。
  • 非常に小さい画面 — 空間レイアウトには余白が必要です。13 インチのノートではキャンバスの利点が小さくなります。

最も相性がよいのは、複数の関連するものを同時に扱う場面です。まさにそれが、マルチエージェント開発に求められるものです。

ワークスペースからワークフローへ

空間配置の最も強力な点は、ワークスペースそのものがワークフローのドキュメントになることです。キャンバスのスクリーンショット 1 枚で、何をしているか、各要素がどう関係しているか、全体がどの状態にあるかが分かります。

それを、6 つのターミナルタブのスクリーンショットと比べてみてください。1 つずつ切り替えない限り、作業中の内容は何も分かりません。

これは再開性にも効きます。ノート PC を閉じて翌日開いたとき、保存されたキャンバスレイアウトが、どこで止めたかを即座に思い出させます。空間配置が空間記憶を引き出し、数分ではなく数秒で文脈に戻れます。

開発者ツールの未来は、より良いタブではありません。タブそのものがなくなることです。