UEI/ARC shi3zの日記

■Webプログラマーがデュアルディスプレイで作業する理由

　先日、小野さん(小野和俊のブログ)に「うちもデュアルディスプレイにしようと思うんだけどメーカーはどこがいいの?」と聞かれて、どちらかというと

　「エッ!?いままでデュアルじゃなかったの!?」

と思ったことを急に思い出したのでメモ。

　家庭用ゲーム機のゲームプログラマーは10年以上前から、いや、ひょっとすると30年以上前から、基本的にデュアルディスプレイ以上の環境で仕事をしてきました。

　この役割分担はとても明確で

1. メインディスプレイ→ソースを編集
2. サブディスプレイ→実行結果を表示(ゲームならテレビ画面)

　となっています。

　ケータイゲームをつくるときはこの延長で

1. メインディスプレイ→ソースを編集
2. サブディスプレイ→エミュレータを実行

　というのがデフォルトです。

　というかこれ以外の環境ではとても仕事になりません。

　ALT+TABで切り替えまくって・・っていうのがやれなくもないですが、まあ無理ですね。

　少なくとも作業効率は1/10くらいになると思います。

　だからウチの会社では9割以上の社員がデュアルディスプレイ以上で仕事をしています。

　だいたい、毎年黒字がでてお金があまるので、そのとき設備投資できるものといったらディスプレイの枚数とメモリくらいしかないわけで。メモリも、ふつうのWindowsマシンだと常識的に増やせるのは2Gくらいが限界ですしね。

　ではなぜ常に画面が出ている必要があるのか?

　人間の視界はそれほど広くないので、注視できるのは常に一つの画面。場合によってはひとつのウィンドウのそのまた一部分に過ぎません。

　つまり視界の端に文字が書いてあっても読むことは出来ません。

　けれども、眼球はたえず運動していて、画面のあちこちを常に注視して脳内に情報をかたち作ります。

　だから本来中央の視界に入ってこない周辺視野も全くのムダというわけではないのです。

　「ヒューメインインターフェース」によると、人間は画面がパッと切り替わると、切り替わった画面になにが書いてあるのか認識するまで少なくとも3秒、最大7秒かかると言われています。タスクスイッチのコストがそれだけあるのです。

　これが「わずか三秒」と切り捨てられるものではないことは、実際に開発をする人なら想像できると思いますが、そのたびに思考は停止し、ついさっきまで何をしようとしていたのか懸命に思い出す必要があるのです。

　このスイッチが一日に何十回も起きます。

　仮に一日1000回動作確認をするとして単純にロスする時間は最低3000秒〜最大7000秒。あいだをとって平均5000秒とすると、1時間20分程度の労働時間が奪われることになります。

　しかしこれはかなり控えめに見積もった数字で、実際に3秒のロス以上に、プログラミングのテンポを取り戻すためにもっとおおくの時間がかかります。

　また、これはソース→実行結果という一方向しか計算してませんが、実際には実行結果→ソースという流れもあるわけで、それを含めるとさらに二倍の時間、つまり2時間40分もの時間をロスすることになります。

　一日1000回動作確認することがなかったとしても、ひとつのソフトを開発するのには何万回もの動作確認が必要になります。

　そのたびにこの全くムダな時間を過ごすことになるのです。

　単位時間当たりにどれだけ作業を効率的に進めることが出来るかということを「生産性」と呼ぶとすれば、ALT+TABによるタスク切り替えは脳のタスクスイッチにとって完全に悪なのです。

　もっと言えば、ALT+TABを押すことにより画面が切り替わると、思考が分断され、実際にはもっと多くの時間を失うことになります。

　これがディスプレイの面積が充分広いとどうなるか?

　常に視界に入るか、少しクビを傾けるだけで実行結果とソースをスムーズに切り替えることが出来ます。

　クビを振り視線を移動するコストは3秒もありません。

　また、このような場合、人間はもっと早くタスクを切り替えることが出来ます。

　視界の隅にソースの画面または実行結果の画面が映り続けることによって、脳のサブタスクが常にプロセスとして動き続けるきっかけとなるのです。もちろんCPUの内部タスクはALT+TAB(Macならコマンド+TAB)で切り替えても構いません。問題は視界の隅に常にどちらかの情報が映っていることです。

　多くのマルチタスクシステムがオーバーラップ型のマルチウィンドウシステムを採用しているのも、こういう理由があるからかもしれません。

　もちろんディスプレイが一枚でもそれほど絶望的な状況にならないことがあります。

　充分に広い解像度があれば、左半分にソース、右半分に実行結果(またはその逆)といったように使うことが出来るからです。

　しかしケータイゲームなどのように、画面に対して充分実行結果が小さい場合ならともかく、HD解像度のゲームソフトや、充分な広さを前提としたPC向けのWebページのように大きな面積を必要とするものは、やはり小さいウィンドウではきちんと動作確認ができません。

　結果的に、

1. メインディスプレイ→ソースを編集
2. サブディスプレイ→ユーザと同じような環境でサイトを表示

　という分け方が必須になるのです。

　

　また、ディスプレイが物理的に二枚以上あるのと、単に広い解像度のディスプレイがあるのとには大きな違いがあります。

　ディスプレイが二枚あるということは、最低でも二つのアプリケーションを同時に「最大化」できるということです。

　ウィンドウの最大化は、視界を全て単一のタスクで埋め尽くし、集中力を高める効果が期待できます。

　特にEclipseのようなIDEでは、ソースコードを中心にそれを補完する細かな情報が凝縮されており、小さなウィンドウで使うのは絶望的に難しくなります。

　そういうわけでWebプログラマには必ず二枚以上のディスプレイが必要だと思って居ます。

　欲を言えばディスプレイがたくさんあるのに超したことはありません。

　三枚あれば次のような使い方が考えられます。

1. メインディスプレイ→ソースを編集
2. サブディスプレイ1→ユーザと同じような環境でサイトを表示
3. サブディスプレイ2→サーバ側のコマンドプロンプトを表示

　四枚あれば次のような使い方がかんがえられます。

1. メインディスプレイ→ソースを編集
2. サブディスプレイ1→ユーザと同じような環境でサイトを表示
3. サブディスプレイ2→サーバ側のコマンドプロンプトを表示
4. サブディスプレイ3→データベーステーブルを表示

　五枚あればさらに次のような使い方が考えられます

1. メインディスプレイ→ソースを編集
2. サブディスプレイ1→ユーザと同じような環境でサイトを表示
3. サブディスプレイ2→サーバ側のコマンドプロンプトを表示
4. サブディスプレイ3→データベーステーブルを表示
5. サブディスプレイ4→ドキュメントを表示

　あとはスペースと予算に応じて、これらを組み合わせるだけです。

　データベースとドキュメントとコマンドプロンプトを同時に見る必要はあまりなさそうなので、そこだけは三枚目のディスプレイに割り当てて切り替えて使うというのでもいいかもしれません。

　しかし間違いなく言えるのはディスプレイは狭いよりは一望できる範囲で広い方がずっといいのです。

　Mac OS Xの次バージョンのLeopardには、Spacesと呼ばれる新機能が搭載されます(アップル - OS X Lion - 世界で最も先進的なコンピュータのオペレーティングシステム。)。

　

　

　これはデスクトップを縮小し、仮想的に4つの画面を使えるようにする機能です。

　ALT+TABで完全に切り替わるよりは、画面が連続している分だけ脳の切り替えは早いと思われますが、これも同じ効果を期待しているものだと思います。

　今のところ、ディスプレイが三枚以上になる場合は、一枚あたりの大きさは17インチくらいが限界のように思っています。

　SXGA解像度で三枚あればいまのところたいていの用途には充分です。

　僕はWUXGA(1920x1200)のシネマディスプレイを二枚つなげていますが、欲を言えばもっと一枚あたりを小さくして、数を増やしたいくらいです。

　MacProが標準でサポートしているのが二枚までなのでとりあえず我慢しているだけです。

　Flashのように画像とソースが入り乱れるようなオーサリング環境ではWUXGAくらいないとかなり大変です。

　話がとっちらかりましたが、そういうわけでプログラマにはデュアルディスプレイ以上が絶対お勧めです。

　お勧めの機種というのはこれといってなく、強いて言えば同じ解像度で同じメーカーで同じ日に同じ型番を揃えて買った方がいいということくらいです。

　発色が左右微妙に違うと気持ち悪いですし、眼にもよくありません。

　大きいディスプレイを買うくらいなら、小さめのやつを沢山買った方が良いと思います。

　あとはもちろん、ナナオがいいとか三菱がいいとか、普通のLCD選びと同じ程度の善し悪しというのはあります。

Permalink | 21:38