2007-06-23
■少数言語としての手話
地域差や性差、国際手話、手話の芸術、今後の存続までを幅広く解説。視覚言語の姿を明らかにする。
ビーケーワン:少数言語としての手話
男性言葉、女性言葉があるように、手話にも性差があったり、地域差つまり方言(?)があったりするのか。
図書館にリクエストしてみようかな。
■ザ・ファシリテーター
小説なんだけどbookカテゴリで。
ファシリテーションのマインドを説明――という表現はちょっと悪いなぁ、と思うのだけど――した小説。
面白いのは、ファシリテーションとは何か? ファシリテーターと何か? という説明が半分を過ぎたところで出てくること。
ファシリテーションの謂いを使うなら、"ストーリーの流れ"の上でのアイスブレイクやフォーミング(形成)、ストーミング(混乱・対立)、ノーミング(統一)が終わったあとにようやく出てくるのだ。
それよりも前、幹部達の合宿の場で、「ファシリテーターとは何か」と主人公が尋ねられるシーンがある。
言葉の意味は、よくわかったうえでの質問であることは明らかだった。棘がある。
(略)
「司会をすることですかな」
「ハイ、司会もしますし、記録係もさせていただきます。会議が効果的に進むことなら、何でもさせていただきます」
と主人公は
つまり、真実はそうではないということの、筆者の考えが表れている。その先にあるのだと。
ファシリテーターをそのように思っていた人ならば、読むべき本であろう。
また、「現実はこんなに簡単じゃない」とか思っても、それゆえに読むのをやめてもいけないだろう。
「かくあるべき」「かくありたい」姿を表出化させるのもまた、ファシリテーションの中の一つの大事なステップなのだから。
2007-06-22
2007-06-21
■富士通「LOOX U」開発者インタビュー
--先ほどオアシスポケットの話をしましたが、結果的には、当時、あれだけ小さいと思っていたオアシスポケットよりも小さいPCになりました。キーボードのサイズやレイアウトはどのように決めましたか?
本田雅一の「週刊モバイル通信」
「富士通社内でも、オアシスポケットというのは1つのベンチマークだったのですが、実際にオアシスポケットを持ってきて比べてみると、LOOX Uの方が小さいんですよ。
(略)
オアシスポケットよりも小さいのか……。なんか興味沸いてきた。
(オアシスポケットは確かにベンチマークになっていると、親指シフト使いである私も、そう思う)
■Google Toolbar for Firefox の update
検索語の補完が、ヒストリからのものだけじゃなくてサジェスチョンが効くようになった。
これはいいや。
2007-06-20
■複数選択/単一選択のジレンマと、Gmail に見るUIの考察
あるリストボックス。
複数選択して、そして何かの処理をさせる機能が必要。(機能A)
だから、リストボックスを複数選択なスタイルにする必要がある。
そしてもう一つ。
一つだけ選択して、そして何かの処理をさせる機能も必要。それは一度に一つだけしか対象にしたくない。(機能B)
さてどういうUIにしよう?
リストボックスはモードを持たない
つまりリストボックスは複数選択のまま。
一つだけ選択されている状態の時だけ、機能Bの(ボタンなどの)UIが有効になる。
複数選択されている状態の時だけ、機能AのUIが有効になる。
欠点
初期状態で機能Aや機能Bが無効になっている。
それを有効にするのに選択しなければならないことに気づけるか。
リストボックスはモードを持たない の2
機能A,機能Bのボタンはいつも有効。
ボタンを押した時に、複数選択か単一選択かを判断して、条件を満たさないときは警告を出し、選択を促す。
取り合えずボタンを押してみることができる。
欠点
許されない(=してほしくない)選択条件の時に警告が出るのは、不必要にビックリさせるかもしれない。
リストボックスがモードを持つ
複数選択と単一選択のモードを切り替えるUIがある。
ラジオボタンかチェックボックスか、フリップ系のUI。
どちらの状態にあるかで、機能Aと機能BのUIの表示/非表示、あるいは、有効/無効が切り替わる。
欠点
結局、機能Aを使うには? 機能Bを使うには? という条件がパッと見て判らないのは変わらない。
今は昔の話
Dos以前の時代は、実はこのジレンマは、無かったと言ってもいい。
対象とする項目を選択してから、機能を選択するUIは主流ではなかった*1。
機能を選択してから、対象とする項目を選択する方が普通だった(と思う)。
Windowsの時代
リストボックスに単一選択のモードと、複数選択のモードがある。
正確には複数選択のモードにもう2種類あって、選択→Shiftを押しながら別の項目を選択でその間の全項目を選択、Ctrl+選択で一つずつピックアップ、Shift+キー押下で連続選択というのが一つのモード。
もう一つはCtrlもShiftも関係なく、クリックで選択/解除が切り替わる。
結局のところ、この"Windows標準"のコンポーネントが主流になる運命にあった。
Windwos API や Visual Basicで扱える"標準"の操作感が――善し悪しとは別の次元で――必要とされた。
(Macintosh も調べるべきなんだけどなぁ……と思いつつパス)
Gmail
項目をクリックすると、メールの詳細(つまりは本文)の表示になる。
一覧の各項目の左に、一つ一つチェックボックスがある。
直感的な操作として、クリックが選択/解除の切り替えとなる。
さて、あるチェックボックスを選択してみる。別の項目のチェックボックスをShiftキーを押しながらクリックしてみよう。
はい。
Windows標準の複数選択モードと同じく、二つの項目間の全ての項目が選択状態になる。(知ってました?)
解除も同じようにできる。
選択になるのか解除になるのか? Shiftキーを押しながらクリックする時に注意して見てみると、ちょっと複雑そうな規則が見て取れる。
けれど、実に直感的な感じ。(追記:Windowsの機能の方が法則は単純だが"そうなってほしかったんじゃないのに〜"という感じ。Gmailの方が法則は複雑だが"そうなってほしかった"様に選択できるなぁ、という印象を持った。)
実は、スターも同じ様に複数選択できたりして。
あと一歩
Gmailは項目をクリックすると即座に本文表示になった。
これを見直せばいい。
普通に項目の方をクリックした時に、選択された様に見えればいいのだ。
機能の方は、右クリックした時にコンテキストメニューがでる様なインタフェースでよいか。
そしてあと一歩。
選択: すべて選択, 選択を解除, 既読, 未読, スターあり, スターなし
というリンク(ラベル)が一覧の上にある。
"既読, 未読, スターあり, スターなし"のラベルは、アプリケーションに依るものなので、ここはアプリケーションごとに変更すればいいだろう。
さらにその上に、選択した項目に対する操作が並んでいる。
これはいいな。
複数選択してからの機能は、こんな風に一箇所に固まっていればいいんだな。
■リスクとは"危険性"や"脅威"のことではなくて"未来の不確定性"のことだ
アンチウイルスソフトって不要ですよね?
http://q.hatena.ne.jp/1182168711
を受けて。
"リスク"は"危険性"でも"脅威"でもない。
"未来の予測のしにくさ"、"未来の不確定性"のことである。
PMBOKガイドなんかではこれは非常に明確に示されている。
リスクにはプロジェクトに良い影響を与えるものと悪い影響を与えるものがある、と書いてある。
"ウィルスのリスク"とは"ウィルスに感染したときの脅威"ではない。
"今までの十年間でウィルスに感染したことがないから今日も大丈夫だろう"とは言えないこと、過去の観測が現在と未来を確定しない、確実性を増やさないということが"リスク"だ。
"今で家に鍵をかけたことがないけど一度も空き巣に入られたことがないから今日も大丈夫だろう"
"今まで車に鍵を置きっぱなしにしても車上荒らしにも盗難も遭ったことがないから今日も大丈夫だろう"
"今まで賞味期限を3日ぐらい過ぎた牛乳を飲んできたけどおなかをこわしたことがないから今回も大丈夫だろう"
3つめは、前の2つと(今回の質問と)は違っている。
"3日ぐらい過ぎた牛乳を飲んでも"大丈夫だった過去の経験が、確実性を高めていると判断してもよい(そう判断しない人もいるだろうけど)。
1つめと2つめは、一般には*2、大丈夫だった過去の経験から、確実性が高まっているという判断はできないだろう。
アンチウィルスを使っている理由は"ウィルスの脅威から守る"ためじゃない。
"ウィルスの脅威"というリスク(=不確実性)をコントロールできる手段が限られているから、だ。
現代のウィルスは「ネットワークを介する」という性質があるので、ネットワーク上の"ウィルスの脅威"は私にはコントロールできない。
自分のPC上の"ウィルスの脅威"のリスクは、質問者が主張する通り、ある程度までは自分でコントロールできる。
けれど、"それでも残る不確実性"を減らすためにアンチウィルスを入れている。
減るのは、"脅威"ではなくて"不確実性"だと、私はそう意識して行動している。
さて、先に、ネットワーク上の"ウィルスの脅威"は私にはコントロールできない、と書いたけど、この質問に反応してこんなエントリを書いているのは、多少なりともそれをコントロールしたい、リスクを減らしたいという、そんなささやかな欲求からだったりするわけだ。
■postscript
「また随分と堅っ苦しい文を書いたもんだな」
「ふむ。なんとかまとめられそうだと思ったから書き始めたんだけど、当初考えていたいくつかの要素は落っこちたな」
「そりゃ仕方がないだろ。ネタを100%使い切って書けるなんてそうあることじゃない。ところで、これはあれだろ? 相手が使っている言葉を再定義してしまうことで以前の議論を白紙にしてしまうっていうやり口だよな」
「もちろんそれもあるけどね。でもPMBOK云々のあたりは本当だし、"セキュリティはなぜやぶられたのか(ブルース・シュナイアー/井口 耕二)"にも『セキュリティのプロの世界では、「脅威」と「リスク」を区別して使う』って出てくる」
「『プロがリスクと言うときには、脅威の発生可能性と攻撃が成功したときの被害の重大さを考慮している』ともあるな」
「確率的にものを見る、という視点は同じだよ。またPMBOKを引くなら、『前提条件とは、計画を立てるにあたって、証拠や実証なしに真実、現実、あるいは確実であると考えられた』ものである」
「ふん?」
「あやふやで、確実でないもの、確率的にしか捉えられないものを、確率的に見ればそれはリスクだが、確定的に見たらそれは前提条件だと言っている。そして、リスク・マネジメントの中の、リスク識別には『前提条件が正しいことを確認すること』が含まれている」
「根拠はないが今までこうだったからこれからもそうだろう、というのが前提条件だ、と? リスク識別でそれが正しいことを確認する……いや、現状に照らし合わせると言った方がいいのかな? とにかく、それがただの思いこみ、間違いだと判った瞬間にリスクに変わる」
「それだけじゃないよ。今までは確かに正しかったことがある時点で変貌するということもありうる」
「……ていうか、今の世の中たいがいそんなじゃないか?」
「そうだね。『今までの常識は通用しない』なんて、ありきたりな言葉にしか見えないほどだし」
「確かにな。『考えてもみなかった』なんていう常套句もあるな。"セキュリティはなぜやぶられたのか(ブルース・シュナイアー/井口 耕二)"からも引いてみようか。『タイタニック号は沈まないと考えられていたから救命ボートは不要だとされた。エニグマという機械の暗号は解読不能だと考えられていたから、イギリスに解読されているなどドイツは思いもしなかった』てなところだ」
参考
2007-06-19
■私のマシンだけSubversionが重かったワケ
httpを使うレポジトリなのに、Google Desktop の除外URLに指定していなかったから。
なのだろうか?
■プロジェクトマネジメント・プロフェッショナルとPMP PMBOKとPMBOKガイド
まずは書名になっているプロジェクトマネジメント・プロフェッショナルの話。
ここを読もうと思った人ならば説明するまでもないかもしれないが、"プログラムプロジェクトマネジメント・プロフェッショナル"はプロジェクトマネージャーの認定プログラムで、普通は頭文字でPMPと呼ばれている。
ここで書名をPMPとしなかったのは歴とした理由がある。
p13
開発研究職であっても営業職であっても、あるいは企業経営者であっても「プロジェクトの真の成功のために何をすべきか」という貢献に焦点をあわせ、その責任を果たす人を「プログラムプロジェクトマネジメント・プロフェッショナル」と呼ぶ。PMIの認定資格であるPMP(Project Management Professional)は、その必要条件の基準を提供するが、PMPの資格保持者がすべてプログラムプロジェクトマネジメント・プロフェッショナルとは言えない。
その意味で区別して使っている。
つまり、プロジェクトマネージャーではない人であっても、この本の対象読者として想定されている。
あるいは、むしろ、普段PMBOKに縁がない人ほど読むべきなのかもしれない。
さて、今、何気なくPMBOKと書いたけれども、この言葉もこの本での捉え方は通例のそれとちょっと違うかもしれない。
p129
PMBOKとPMBOKガイドは違う。PMBOKというのは、プロジェクトマネジメントの知識全体のことを指しており、この中にはいわゆる「暗黙知」のような概念も含まれる。PMBOKガイドは、その一部を「形式知」化したものである。
もうこの部分だけで、目から鱗が落ちる思いだった。
普段PMBOKと言う時は、PMBOKガイドのことを暗に指していたのではなかったか。PMBOKガイドをぺらぺらと捲った時に感じた「まさにガイドライン」という感覚・イメージは、ごく表面的な捉え方でしかなかった、と。
決断と判断。
マネジメントとコントロール。
リスクと前提条件。
論理と知覚。
スケジュールと時間。
問題とリスク。
様々な概念が、渦を巻き、"自分の中"へしまいこまれた。
さぁ、次は、"自分の行動"を通して、それらを外へ外へと"出す"番だ。

