4月下旬、iPadがいよいよ日本発売となります。iPadは様々な箇所で賛否両論を巻き起こていたようですが、その中で否定的な意見として言われたのが「シングルタスクだからダメ」というものです。おそらく、これは複数のアプリケーションを同時に起動しておきたいと言う意味だと思います。
コンピュータをマルチタスクで動かすのは当たり前になっていますが、人間がそもそもマルチタスクをできているんだろうか？という疑問が湧いたので、それについて思考実験をしたことをまとめてみました。iPhoneユーザなので、改めて各々の操作を振り返りつつ、iPadで行ったとしてどうなるだろう？と考えて行きます。
脳がそもそもマルチタスクなのか？という話を始めてしまうと、無意識や反射のことを考えなければならず、おそらく「よくわからない」と言う結論が大抵待っていると想像できるので、実際に動かしている部分がどうなっているかに焦点を当てて行きたいと思います。
追記 2010/03/08
人間のCPUは1つだと言う仮定
人間は1CPUをもったマルチタスク可能な動物で、訓練によってタスク切り替え速度をかなり向上させることができる。と私は仮定しています。よく両手でピアノが弾けるとか、ブラインドタッチができるというのが、同時進行で手が動いているように見えますが、ブラインドタッチについて言えば、指は逐次で動いています。これはキーボードでのインプット自体が逐次でないと受け付けていないからもでもありますが、同時押しも、指を逐次で押しています。それが相当な速度なため、できない人から見れば、同時に動かしているように見えています。
おもしろいのはブラインドタッチの「フリ」をしてみると、次に何を動かせば良いか意識しなくてもよくなるので、ほぼ同時に両指を誰でも動かすことができます。逆にいうと、意識が大きく影響していると言う表れです。ただ、先述の通り、意識と言うものではなく、可動部位を中心に考えます。
可動部位は重複させられない
例えばiPadというデバイスを前にしたとき、私たちが利用できる可動部位として思いつくのは、目、耳、手になると思います。まずそれぞれの部位について同時進行のように見せられる組み合わせを考えてみます。
目 + 耳
動画再生をしている時などが考えられるます。説明字幕が出ている間にナレーションが進んでいたりすると、聞き漏らし、見落としが発生する場合があります。逐次で目と耳を切り替えながら、字幕とナレーションを交互に認識していると考えられます。
目 + 手
ホームでアプリケーションを選択している時や、写真をフリップしながら見ている時などが考えられます。まず目で操作対象を決め、実行するために必要な手順に沿って手を動かして行きます。扱っている情報の性質にはよると思いますが、目で始まって手で実行と言う逐次処理を求められます。
耳 + 手
キー入力をしている時に、入力音をONにしているとします。カチッという入力音が聞こえたことで、正確に入力されたと判断して、次の入力をおこなうと言う動作が可能です。目での判断も間違いなく入っているのですが、耳から手、手から耳と言う逐次処理を行っていると考えられます。
可動部位には主従関係と優先度が発生している
どのパターンにも言えることは、主となる可動部位があり、その実行結果に従って次の可動部位が連動 していると捉えられます。目がほとんどの場合、主となっているはずです。目が使えない暗闇は耳に、音が特にない場合は手でなど、状況に合わせて優先度が変わっていきます。
iPadに関しては視覚が必須のデバイスなので、目で対象を捉えるというのがトリガーになると考えられます。
ここから2つある可動部位を重複として考えます。
目 + 目
目が2つあることで焦点合わせなどを行っており、同時に違うものを見るというのはできていません。視野の端にとらえると言うことはできますが、そのものを具体的には捉えられていません。焦点を移して行くことになるので、実質は逐次処理であると思います。
耳 + 耳
反射した音などを両側から捉えるというここと、どちらの耳から聞こえるかで方向の特定などができています。おそらく同時に聞こえているというのは成立していると思いますが、同じ方向から来る音を一緒に聞いているかというと、それはできていないはずです。片方からの音をまず捉え、頭の中の振動が反対側に伝わるか、反射した音がもう一方に遅れて入ってくるかでしょう。
手 + 手
厳密には指と言うサブシステムで考えるべきですが、両手で操作する場合は、フルキーボード入力が考えられます。これは冒頭に述べた通り、実際は逐次入力となります。また、指を2本以上同時に押す場合、それぞれが完全に独立して動くことはなく、例えば画像の拡大であれば、画面の中央から外側へと同じ方向へ動かしています。他の操作もそうです。
マルチタスクはできそうだが、独立した同時処理はどうなのか？
これまでの内容から、人間はマルチタスクが可能だと考えられそうです。ここで一歩進めて、同時に複数のアプリケーションが起動できるとして、独立した状態で使いこなせるのか？と考えてみます。目、耳、手は2つあるので同時に動かすことはできますが、独立して動かすのは困難だと言うことです。
しかし、ここでそもそもの前提として足りないものがあると思いました。それはデバイス側、つまりコンピューターそのものが逐次処理のため、同時入力は受け付けていないと言うことです。2画面や複数アプリケーションという状況はあっても、フォーカス、つまりターゲットをまず決めるという処理が必要な以上、やはりコンピューター側の都合で同時入力はさせてもらえません。
GUIであれば、フォーカスによって1つずつですし、CUIだとキーボード自体は同時入力できますが、内部での解釈は逐次処理になっています。実は人間の行動様式や可動部位を考慮してデザインされていると言われるデバイスも、コンピューター側の逐次処理という制約ありきということになります。
それを考えると、複数のアプリケーションが同時に動くと言うよりは、同時に起動しているのと変わらないぐらい切り替えのストレスがないか、そう見せるインターフェースがあれば今は十分だろうと私は思います。
そういう意味では、メニューとアクティブなアプリケーションが常時表示され、アプリケーションの切り替えも兼ねるWindows7のタスクバーは、かなり秀逸なデザインだと思います。実際、そのおかげでWindows用のDockが不要になりました。
どのI/Oをどこまで独立させていけば良いのか？
ピアノは鍵盤1つ1つが独立したI/Oですし、パーカッションもそうです。しかし、音としては独立していても、人間に取っては和音と言う結果 を得ることができます。コンピュータのI/O、それらを総合したUIを考える場合、どこまでの単位で独立させると良いのか？ということについて再考が必要だろうと思います。
マルチプロセッサが普及してきていますが、メモリ管理も含めて完全に独立処理というのは、できるできないがあります。演算と描画を独立させることでパフォーマンスが上がったように、同時処理ができるということは入力方式から再デザインされる必要があるのではと今は考えています。
今回の思考実験は浅い考察だと思うので、I/Oを独立させる単位を考えなおすと言う方向で、また、まとめてみたいと思います。
書評というより、本を読みながらノートをとるというのを試したら、思いのほか楽しかったので、その内容について残しておこうと思います。
書籍の紹介やサマリーはAmazonや書評を書いている方々に任せるとして、本を読んで自分が「おっ」と思ったことをトピックにして行きます。
ノートを記憶時間の長さで分類する
短期記憶
タスク、アイディア、緊急の要件などが主な用途。後で思い出せるキーワードとしての価値が重要。今を忘れて次のアクションにつなげるために書き留める。
中期記憶
短期記憶の断片や切り抜き、コピーなどをスクラップする。短期記憶をある程度膨らませたり、整理したものが中心となる。その他、何らかのタイミングで見返す必要のあることとして、議事録や勉強したことなども記しておく。その場合、Plan –> Do –> Seeのサイクルを前提とし、予測としてトピックを立て、それに対する検証結果や実態となる流れで記述して行く。見積と消化時間のような計測効果が望めるのと、結果的に「まとめ」となる。
長期記憶、優先度管理(スケジュール)
マンスリーで予定管理。１ヶ月単位というのが中長期の視野を持たせることになる。また、限られた枠という制約がコンパクトに情報を記述して行く習慣を作る。予定は未定。予定を編集しやすいように、何度でも貼ったり剥がしたりできる小さなラベルシールを利用する。シールをドラッグアンドドロップするという表現は言い得て妙。
スケジュール管理のこつとして、「バッファ」を作る。この日は予備日として週１回あけるということにしておく。予定外のものなどはそこで吸収する。自分の場合、打ち合わせと書類作りに時間をとられてばかりという状態が好ましくないので、作業のためにそういったミーティングや外出を一切入れない日をつくるというのは重要だと思った。
勉強したことを試す機会をタスク化する
まとめるべきは、この勉強をした後に自分が何をするか。何かの思考法や整理法などについて勉強したのであれば、それをどこで試すかをタスクにしてしまう。更にキャッチフレーズをつけることで、自分への意識付けを強める。
試す機会をタスクとして管理するというのは良いと思う。強制力は大事。自分の場合は、読んでる最中にノートを取りながら読むという取り組みをスタートしてみた。こうすると、斜め読みしてはいけないところを拾える効果があった。既存知識は読み飛ばしがちだが、文書化しようとすると、見逃しや曖昧な理解について浮き彫りになる。
セミナーは持ち帰ることを決めておく
目的を明確にしておくことでアンテナを張り、聞き逃しを無くする。講師の印象に残りたい場合は、事前に講師について情報を収集し、講師が求めている情報について質問をするのが効果的。
何かあるかもしれないという「期待」でセミナーに参加は確かに漫然と聞いてしまうと思う。自分が決めたテーマと違った内容であれば、それはそれで比較検討にもなりうる。そういった前提の決め打ちもいいかもしれない。また、講師が求めている情報というのは、つまり共通の話題を得るチャンスであるということ。
ビジュアルイメージをタグにする
ノートをスキャンして管理するときのタグにビジュアルイメージとする。時系列とイメージの方が内容よりも思い出しやすくなる。他にはページ数を最もさいたコンテンツをタグとする。
ノートは連番で管理しがちだが、ハッシュとして管理するのが良いと解釈した。試しにノートに名前をつけてみたが、しっくりきている。またタグ管理のアプローチとして、情報量と密度を用いるのは確かに有効だと思う。ある短い期間中に集中した出現したもの、長期で特定のタイミングで現れるものを抽出などといったものは、様々な検索サービスで活用されている。自分が整理した情報についても、そういう集約の仕方を応用してみるのはいいかもしれない。
読後感想
著者はノートつまり紙というデバイスの長所を何度も繰り返し訴えるが、デジタルデバイスとの棲み分けがはっきりしていて、自分が扱っている情報の性質を的確に捉えていると感じた。個人的にはいわゆるライフハックという行為をどのデバイスでやるかは生活様式次第だと考えていて、「このテクニックは自分だとこのデバイスで済ませられるな」などといった比較検討をしながら読み進める過程は楽しいものであった。
情報集約ツールを考案しているが、改めて自分が扱っている情報の種類、それぞれの特徴をマインドマップで書き出そうとすると、うまく説明しきれないものがある。これらを理解し応用方法を考えることがまず先決だと感じている。
最近はデジタル化の手間を省くためにノートPCで議事録などを記録するようにしていたが、情報整理の方法を突き詰めるという意味で、改めてノートでの記録に戻ってみた。まだまだ改善の余地は大ありだ。白紙という自由は、これほどまでに自分を楽しく悩ませるものかと思えた。
もともと文房具も好きで色々試していて、文中で紹介されているノートを始めとした文房具を、さっそく文具屋で片っぱしから手に取ってみた。この中で、また合う合わないがあり、ネットでの情報を見たときに良さそうと思ったものが、実物を見るとそうでなかったりと、これもまた楽しい。
文房具で何か、ひとネタ書いてみようと思う。
WDHA#023 に参加してきました。Evernote で情報整理というテーマで話しつつ、生産性を高めるために最近試してみている方法やツールについても話しました。
忘れることで効率を上げる
Evernoteの素晴らしさや使い方については割愛しますが、何でもノートとして残すという使い方は、知識労働において大きな補助となってくれます。
まず情報過多の状態で、様々なことを記憶しておこうとすると、あっという間にオーバーフローを起こし、判断を誤る元になるというのは多くの人が実感していることと思います。「とりあえず残しておく」「後から見返す」という前提で、Evernoteにノートとして残したものを、記憶から外すことができるというのが最大のメリットだと感じています。
かといって、何でも残していいものではないのだなということも分かってきました。Evernoteさえ見れば安心という状態にしたかったので、ブックマークも移行しようとしたのですが、ここで問題がありました。
Evernoteで残すべきは静的な情報
動的に変更される、つまり情報が更新されて行くものについては、結局のところ現サイトを訪問しなくてはならないので、わざわざEvernteからだと手数が多くなるということです。ましてや、ブラウザを使用して、ネットワークにつながって初めて手に入れられる情報はさらに相性が悪いと感じました。
そこで、コラムやサンプルコードなど、更新されることが(ほぼ)ない情報で手元に残したいものだけをEvernoteで保存するようにしました。つまりスクラップブックとして使うということです。こうすることで、いつサイトが閉鎖して情報が得られなくなるか分からない、というブックマークゆえの不安は解消できました。
また参考にしたいWEBサイトのスクリーンショットも同様にEvernoteで残しておけるようになったのは、個人的に嬉しいことの1つでした。
ノートブックで管理する？タグで管理する？
ノートブックはいわゆるディレクトリです。これでノートを分類して行くと、慣れ親しんだ使い方にはなりますが、ノートブックをまたいで探したり、どのノートブックでも見つかるようにというのは望めません。
タグで管理すると、上記の問題は解決しますが、ルールなくつけてしまうとタグ自体を整理することに追われる可能性があります。おそらくは、ノートブック管理とタグ管理のハイブリッドが良いとは思います。
WDHAで発表した時点では、ひとつのノートブックにすべての情報を入れ、タグで管理するというものでしたが、Evernoteクライアントのパフォーマンスを低下させてしまうので、ある程度のノートブック分類をした方が快適さを保てそうです。
そこで、今はノートブックをInbox(テンポラリ、未整理)、Project(プロジェクトに関する資料)、NameCard(名刺)と大きく分けてみました。整理し終わり保存しておきたいものはArchiveに入れてしまいます。今は、記憶時間の長さで分けようかなと考えています。後回しにしているもの、その内(1ヶ月以上先)にやりたいことなど。
今後の鍵はツールの使い分け
情報整理を始めて見ると、自分が抱えている情報の性質について見直すきっかけになりました。思いの外、大事と思っていたものにも無駄が多く、静的なのか動的なのか？といった分類を始めると、どのツールにどういった情報を集約しておくべきか？というのが課題として見えてきています。「こんな時はここを見れば大丈夫」という安心感を作り、なおかつ、「ここ」という選択肢は少ない方が良いようです。ただ、1つでなんでも管理は難しいので、自分の行動範囲とPC環境を考慮してツールを選ぶ必要があります。今度はEvernote以外のツールをどう使うか、Evernoteとの棲み分けはどうするかについても、まとまったら書いてみようと思います。
昨夜、「Ustreamで生Zen-Codingやってみましょうか」 という内容がTwitter上で賑わっていました。
Zen-Codingってなに？
HTMLとCSSを効率良く記述するためのスニペット生成マクロです。 効果の程については、まずこの動画を見てもらえればわかると思います。
Zen Coding v0.5 from Sergey Chikuyonok on Vimeo .
こういう手法はEmacs使いの人には馴染み深い物と思います。過去にはRuby on RailsのデモがTextMateを使って、上記のようなコーディング動画を配信されていました。私もその当時、TextMateいいな！と思って導入しましたが、日本語対応がうまくできず、EclipseベースのIDEに戻りコード補完をガシガシ使ってコーディングしてきました。
Zen-Codingはどうやって使うの？
現在ですと、Aptana, NetBeans, Coda, Espresso, TextMate, VisualStudio, Dreamweaver CS4とクロスプラットフォームで使用できます。これは素晴らしいことですね。私は現在、Eclipse + PDT + Aptanaという開発環境で諸々の言語を使用していますので、今回はEclipseで使うための方法について補足したいと思います。
前提として、EclipseMonkey というプラグインが必要になります。これはEclipse上で動かせるマクロを作成するためのプラグインです。マクロは標準ではJavaScriptで記述することになっており、Rubyで書いたりもできるようです。Zen-CodingはJavaScriptで記述されています。
Zen-Codingを導入する前の準備
公式サイトにてインストール方法が紹介されています。 まずは、Installingの手順に従ってAptanaのインストールとEclipseの再起動までを行いましょう。インストール時に依存関係を追って、一通りのツールがインストールされます。
その後、Zen Coding for Aptana v0.6 をダウンロードし、 中のファイルすべてを以下の画像のように配置します。
新規プロジェクトで一般のプロジェクトを作成した後、scripts/libというディレクトリを作成しています。すると、メニューのスクリプトに「Zen Coding」という項目が現れます。早速、デモのように適当なHTMLファイルを作って試しましょう！Expand Abbreviation という項目がスニペット展開を行ってくれます。快適です。
Zen-Codingのショートカットキーをカスタマイズ
ショートカットキーをカスタマイズするには、まず該当するマクロのファイルを開きます。5行目にKeyという内容があるので、そこを編集します。M3って何だ？と思うかと思いますが、以下のような対応になっています。
ここまでできれば、快適なコーディングライフの歩みを一歩進めることができるでしょう。逆にZen-Codingの内容を参考にして、よく使うスニペットマクロを作成して行くと、楽しみが広がってくると思います。
自覚的デザインシリーズ で継続しているデザインプロセスの言語化について、ルック&フィールのうち、特にフィールについて思うところがあった。自分向けのメモを兼ねて残す。
車両用の信号は点滅した方が安全ではないのか？
そもそも、車を運転している時に困ることが1つある。青信号から黄色の信号に変わるタイミングが分かりにくいということだ。自分の視野に青信号が入ってから、自分が通り過ぎるまでに黄色に変わるかもしれないという予測は以下の要素から成り立っている。
信号に近づくまでの経過時間
現在の走行速度
道路状態(雪が降っていると特に余裕を持たなくてはならない)
歩行者用の信号の状態
ここで最も簡単に気づくのは、周辺の歩行者用の信号が点滅しているかどうかである。すでに点滅が始まっており、通過するはずの信号までの距離が遠いのであれば減速を始める。これは歩行者用の信号が赤色に変わって間もなく、車両用の信号は黄色になるからだ。
しかし、歩行者用の信号が常にあるとは限らない。であれば、車両用の信号自体、色が変わる前に点滅した方が、突然の急ブレーキとなる確率は下がるのではないか？赤か青に変わるときに点滅すると、フライングスタートする人がいそうで、危険な気もするが。
前置きはともかく、操作フィーリングについて上記の話から、「予兆」「経過」「完了」3つの要素に分けられると仮定した。しかし、能動なのか受動なのかで内容が多少変わってくる。
能動の場合
予兆
自分の意志でアクションを起こそうとしているので、その時点で不要。ルックとしてはアクションのトリガーだと認識できる状態にしておくのが好ましい。
経過
自分が起こしたアクションについて、正常に対象が作動して進行していることを示す。ローディング画面や拡大・縮小などの途中経過を表わすフィール。自分が今どこの段階にいるかを表示するナビゲーションも同様の意義を持つ。 長い時間を要するものほど、注意をはらうべき。瞬時に終わる場合は、むしろ不要だろう。
完了
アクションが終了したことを示す。ポップアップ通知や画面遷移など、それぞれの動作後に正常に終わったのか、異常があったのかを明示的に示す必要がある。特に異常時には再試行についての説明、導線が必要。どこの箇所に異常があったか表示、やり直しへの導くリンクなど。
受動の場合
予兆
考える時間、次のアクションに入るまでの猶予を与える。次のアクションまでに残されている時間、注意書きなどによる告知。ポップアップなどの通知は基本、突発的に発生るものだが、最初の段階でどういった周期で通知されるのかなどが把握できていれば、なお良い。
経過
予定された処理が進んでいるという安心を与えるもの。インジケーターなどは能動の場合と同じであるが、受動の場合はそれ自体を意識からはずすことを期待しているので、経過を見せないでおくのも一つの手。
完了
これについては能動と同じが良いと思われる。ただ、経過を見えなくしていた場合、経過中に何が起きていたのかを詳細に知るすべを残しておく必要性はより高い。ログの表示や閲覧の方法など。ログがあると、情報のギャップを早期に埋めることができる。
見直してみると、ソフトウェア設計の基礎とも言うべき内容が多分に盛り込まれている。情報過多になりがちな現代人にとって「気づかずに流れる」という状況が増え、確保出来る時間が細切れのため、即効性のある結果を求めている。
流れては困る情報や自分の行動の結果がどうだったかを適切に通知する設計がされているものは、「解りやすい」という評価を得られていると思う。
今年最初のWDHAは森田雄さんをゲストに迎え、特別版として開催されました。地元からの対バンという形で指名を受け、僭越ながらスピーカーを担当です。
事前に、チームマネジメントに関する内容を森田さんは発表するつもりだと伺い、であれば新年1発目だし、個人事業主として活動してきた経験の棚卸しにしようと考え、タイトルの内容としました。
個人というより、私の場合はクライアントとの折衝から開発・保守までを一通りこなすことになりますし、そのような関わり方を自分のスタイルとしています。会社員として働いた時期もありますが、独立してからは特に環境の違いを比較できるようになりました。その上で自分なりの思考法であったり、行動指針を6つにまとめてみたのが今回の内容です。
これといって目から鱗のような話ではないと思いますが、聞きに来てくれた人たちが、明日から前向きな気持ちで働くことができるようにというテーマで内容を練りました。
見方を変えて考える
これから登場するメソッドのベースとなる行動指針です。問題をソフトウェアで解決するというのが私の主な仕事ですが、そのアプローチは千差万別で、これが正解というのは常にありません。つまり一方向からだけ問題を見ていても、選択肢は少なく、より良い方法に気づかずに終わります。自身の視点を変え、仮想的に立場を入れ替えて想像する力というのは、様々な場所で役立ちます。
浅く広く学ぶ
以前、専門と専業は違うというテーマについて書きました。
ひとつの穴を掘り続けると、いずれ掘り返した土が自分に降り注ぎます。深く掘り進むためには、掘り返した土をよけておく広いスペースが必要です。
手を動かし続ける
頭で解っているつもりでも、実地では予想と違う結果というのはよくあるケースです。来るべき時に備え、ほんの少しでも自分の手で動かす、作るという行為を続けることは、大きなリターンと発想につながります。
そして、手を動かして学んだものは、不思議と忘れません。特にものづくりの現場に置いて、管理職であろうが、社長であろうが、良し悪しを判断して実行するためには、自分の手で確認するという行為なくして最適解は選べないと思います。
過去を現在へつなげる
過去は財産です。もしあなたに過去の失敗があったとして、後悔したまま、失敗の状態で放置しているのであれば、それが失敗です。 過去は取り返せませんが、どこかで役立てよう、活かそうと頭の片隅に とどめておけば、日の目をみる時が来るでしょう。
そのためには、過去の経験を定期的に振り返り、教訓を現在へ適用するというのは効果があります。過去あっての現在であり、過去を分析し、現在できることを積み重ねることで将来につながると考えれば、過去の失敗も見つめ直しやすくなると思います。
風通しを良くする
似た境遇の人間に仲間意識を持ち、そこからできるコミュニティは様々な活力を与えてくれます。しかし、新しいアイディアや発見が生まれるのは、自分が日々過ごす領域の外と交わる時ということがよくあります。
自分と違う業種の人との交流や、違う発想や視点を持った人の考えや意見は宝の山です。そういった機会を大事にし、積極的に取り入れ、歩み寄ることは後々の発展につながります。
パートナーになる
個人に焦点をあてようとするほど、その背景には多くの人との関わりが見えてきます。分かりやすい例で言えばクライアントになります。 契約の主従関係は現実問題ありますが、それでもパートナーのように振舞うというのが良好な結果を残すために肝要だと思います。 アドバイザーであり、実現者であり、片腕であり。そういった人が、今、求められている人材像だと感じています。
どれかできれば良いというものでもなく、6つのメソッドはそれぞれが相互関係にあると 自分では実感しています。この先、新たにメソッドが追加されるのか、何かに集約されるのか、それはわかりませんが、しばらくはこの行動指針で活動して行くと思います。
