Hatena::ブログ(Diary)

雑記/えもじならべあそび このページをアンテナに追加 RSSフィード Twitter

様々な文字入力手法を「運指動画」でご覧頂くことが出来ます。
「シャドータイピング50音順式タッチタイピング練習法」、ひっそりと公開中。
Advanced W-ZERO3[es]ctrlswapminiかえで携帯配列(圧縮ポケベル打ち入力)を利用中。
普通のキーボード用にNICOLA(親指シフト)を圧縮?した、「かえであすか」を利用中。
はてスタの色識別性が改善されるまでの間、私ははてスタ捨て場にカラースターを捨てます。

【注意】この日記に出てくる「運指(最適化)」という語はほぼ、タイパーさんが表現するところの
「ワード(最適化)」のことを指し示しています
……表現間違いをなくすために、現在訓練中です。

2007年03月31日 土曜日

メモ。

トヨタ生産方式――脱規模の経営をめざして

トヨタ生産方式――脱規模の経営をめざして

 p.162まで読んだ……けど、特に追加の感想はなし。

 あ、平準化のキーワークが「助け合い運動」「リレーバトンタッチ」だというところは実践的かつ面白い視点だと思う。

 「ヘンリー・フォード一世はかわいそうな人だ……自身が持っていた【理想の姿】が、後継者たちには必ずしも完全には理解されなかったのだから。」(p.190の要約)という話があった……けど、これはどこにでもある話じゃないかなぁ……という気も。なかなか理想どおりには行かないもので。

 そして、pp.213〜214にはまとめとして「豆腐納豆は本来逆の意味」の話がある。これ以前にも「×自動化、○自働化」とか「×省人化、○少人化」というふうに「ことばあそび」を基にした発想転換の様子がいくつか紹介されていて、この点は興味深いと思った。

 ……とりあえず全部読んだ。この内容で1400円というのは「素晴らしく安い」……けど、果たして仕事に直接応用できるかどうか。

 

2007年03月30日 金曜日

メモ。

  • 交互打鍵率100%の場合、動きが速い方の手は、動きが遅い方の手の動作速度に同期して動く。
    • 結果として、「遅い方の手の速度」が全体の速度を規制する働きをする。
    • 習熟していくことにより、遅いほうの手が徐々に早いほうの手の動きに追いつくようになる。
  • 左右の手の応答速度が異なるならば、その分だけ左右負担率を変えるという方向性(非同期)もありえる。
    • たとえばパソコンの内部では様々なバスクロックが非同期で繋がっている……ああいうイメージ
    • 非習熟状態での「平均的な左右速度差(生態速度差)」にピタリと合致する比率を取れば、最もストレスを感じずに済む可能性がある。
    • 完全習熟状態での「平均的な左右速度差(生態速度差)」にピタリと合致する比率を取れば、最も高速な入力が行える可能性がある。

読書中→トヨタ生産方式――脱規模の経営をめざして。

トヨタ生産方式――脱規模の経営をめざして

トヨタ生産方式――脱規模の経営をめざして

 p.89まで読んだ。当初の読みどおり、神田さんの本……

コンピュータ―知的「道具」考 (NHKブックス (478))

コンピュータ―知的「道具」考 (NHKブックス (478))

と同じようにいい感じで読める書籍


 いきなりこの本から読み始めると、絶対にワケが解らないと思う。


 イマドキであれば「図版を多用した説明」がそこら中のWebページで読めるので、まずは下調べをするほうが良いかと。

 ……で、ネットで色々と調べすぎて「訳がわからなくなってきた〜!というぐらいになってから」読むと、ちょうど理屈を整理出来てよい気がする。


 筆者がン十年かかってたどり着いた結論を「いきなり理解する」ためには、それぐらいの下調べは必要だと思う。

 逆に言うと、Sourceであるこの本を後から必ず読まないと、いま公開されているコンテンツがどういう理屈から派生しているのか・何を生かして何を端折って何を書き換えているのかというあたりが理解できないままになってしまうので、最終的にはこういう「一次資料」にあたる必要はある、と。


 大ロット生産を止めて「小ロット生産でも利益を出せるようにする」という考え方は、確かにいかにも日本人的(or日本市場的?)に合っているかも。

 断片的な話だけを聞くと「いや無理だろ」とか思うことばかりなのだけれど、それらが「どういう順序で繋がっているのか」ということを本書で理解できれば、これが夢物語ではなく実現可能性がある(ただし平気で四半世紀ほどかかるという問題はある)ことが理解できるかも*1


 うーん、「トヨタ生産方式」を一言で表すと、それは「FOLIC (the First Out Last In is Chain; 先出し後入れが連鎖する)」というルールなのかもしれない。

 ……あっ、「ファースト」の「F」を使っているけど、カタカナ読みするならたぶん「F」の音ではなく「H」の音を借りて「ホリック」とするほうが通りはよいと思う。


 ……って、感想文にすらなっていない気がorz


2007年4月8日21:30:47追記

 FOLICはPull生産方式でしか活用できない……けど、鉄道の運用方式をうまく活用すればPush生産方式でも使えるかもしれない

*1:周知に時間がかかるあたりの状況は、傷の消毒に関する話と酷似しているかもしれない。

2007年03月28日 水曜日

メモ。

 ただいま Ubuntu Linux 6.1 を貰い物のPCに導入中。

 通常モードでは起動できずに「セーフモードLinux」とかいうモードで起動しているので……果たしてインストールが完了しても、動くかどうか。

 とはいえ、LiveLinuxのように起動して、そこからインストーラを立ち上げる……というのは、親切なのか面倒なのかがよく分からず微妙。

 FedoraCoreとはちがって、割と自由にパーティーションを設定しつつインストールできる(Linuxの知識がほとんどなくてもいける)のは◎。せいぜい「Linux-swap」と「/」のために別々の論理ドライブor物理ドライブが必要だということさえ分かっていれば、他はWindowsを使い慣れている程度で大丈夫そう。何も考えずにインストールしたいのならば、FedoraCoreのほうが楽かもしれない。

……インストール成功。

 スピーカをつないでいないので、音声系はどうか分からないのだけれど。

 毎回思うのだけれど、Linuxって進んでるのか遅れてるのか判断に迷うんですよね……。

 「パッケージ管理システム経由でインストールしているソフトウェアに関しては、システム関連でもアプリ関連でも区別することなく、自動アップグレードしてくれる(?)」というあたりは、毎回思うのだけれどものすごく便利。

 この環境で理想エミュレータがあれば、個人的にはWindowsを使い続ける意味ってほとんどないような気が。

2007年03月27日 火曜日

「トヨタ式」には「改善【術】」など存在しない!……そして、そこにあるのは「トヨタ式」の「改善【道】」なのかもしれない。

(参考: http://www1.harenet.ne.jp/~noriaki/link71-1.html )

(参考:『郵政公社 トヨタ式に混乱』の新聞記事に思う - アイティセレクト取材ノート [ITmedia オルタナティブ・ブログ])

(過去:現場発のボトムアップ方式【21世紀版の作業改善】をやるなら、手始めに「飛鳥カナ配列」を試してみよう!と言ってみるテスト。)

(過去:メモ。@2006年10月31日)


 ※今日の記事を要約すると、【私は「トヨタ式」を誤解していました……】という話です。


 改善「術」と名がつくと、大抵は「トヨタ式という名前の、きちんとした改善行為用マニュアルがある」かのように見えるのですが……どうやら、トヨタ式の本質は「改善行為手順」ではなくて「改善手順創作」(配列方面では「飛鳥理論」など)にあるようなのです。


 私のような部外者から見れば、たとえば「郵政のJPSで改善術の適用に失敗した(この場合は設計時点で失敗している様にしか見えない)」事例を見て【トヨタ式=箱庭で定型物を転がす場合にしか使えない】と思いがちなのですが、これはどうやら「トヨタ式が適用できない」のではなくて、「トヨタ改善【術】が通用すると思って失敗した」とみなすほうが正しいようなのです。


 そのことをうまくまとめている説明文を、 http://www1.harenet.ne.jp/~noriaki/link71-1.html から一部引用させていただきます。

 トヨタ生産方式は直接品質向上やコスト低減という成果(結果)を目的とせず、ムダの排除というプロセス重視の考えを持っている。成果(結果)は運に左右される面が大きい。成果(結果)を重視すれば、成果が出ない時は運が悪いということで、最大の努力が引き出せない。その半面、ムダの排除という努力を基準に考えれば、成果が大きい時や小さい時の変動はあっても、長期的にみれば最大の成果を引き出せる。

( from http://www1.harenet.ne.jp/~noriaki/link71-1.html )

 ここを見て「えーっ、やっぱりストップウォッチを持って、ピーピーギャーギャーと叫ぶだけが仕事なんじゃないの?」なんて思わないように……それは(今までの知識が原因で起きる)勘違いですからッ!


 JPS関連記事に見られる状況になってしまった原因というのは、もしかすると「工場流の「何か」を見つけて工場流の「なぜなぜ」検証をする」ことを前提にしてしまったから……なのかもしれません。

 一番初めに立ち返って、「そこが郵便局であり、業務が集配業務であり、荷物が不定形であり、行き先がばらばらであり……」ということを前提にしなければ、このお話は「スタートラインにさえ立てない」はずなのです。

 こうなった原因は、「トヨタ式」には「改善【術】」がある……ゆえに、それを適用すれば全てがばら色になるッ!という、誤った指導方針があったのではないかと……いまのところはそう考えています。

 そして最終的にはトップダウン式に計画書を押し付けて「やれ」と言ってしまった、と。その計画書が素晴らしい精度を持った代物であれば、いくらキツかろうとも「仕事がきつすぎる!」以外のコメントは出ないはずです……が、実際には「実態に合致していない!(=ムラが大きい)」という評価がでていて、これは「計画が正しく設計されていない」ことをはっきりと表しています。


 さて、世の中には「古武術介護」というものがあります

 その内容については今回触れませんが、今回は「古武【術】」というところに注目してみます。

 一般的には「武術」というよりも「武道」のほうが語としてのなじみがあるように思われますが、書籍古武術介護入門[DVD付](古の身体技法をヒントに新しい身体介助法を提案する)】には【術】と【道】の差を明快に説明する、興味深い一節があります。

一般的には「武道」という言葉のほうになじみがありますよね。私がお世話になった甲野善紀先生は,「道」とつけてしまうことで精神論に逃げ,具体的な技術ができるかどうかという原点を忘れてしまわないようにあえて「武術」と名乗っています。

(from 古武術介護入門[DVD付](古の身体技法をヒントに新しい身体介助法を提案する) pp.92-93)

引用部分での「私」とは、同書著者である岡田慎一郎さんのことを指しています。

 【術】は「すでに出来上がった技」であり、【道】は「技を作るために考え試す過程」である……というふうに表現しなおせばよいでしょうか。

 実際、古武術古武術介護については「既に伝承可能な状態」であり、「そのままその目的には利用可能である」ことから、これは【道】ではなく【術】と表現するのが最もよくあっていると感じます。


 ……では、「トヨタ式」はどうでしょうか。

 前出のように、「トヨタ改善【術】」は異業種への転用時に大失敗を経験しています。

 これは「トヨタ改善【術】」が同業種・同種作業での運用に対して最適化されすぎていることに起因するのかもしれません。

 一方で、表立って出てくる話としての「トヨタ改善【道】」についてはほとんど拝見したことがない気がしています。

 ……そして、さきに http://www1.harenet.ne.jp/~noriaki/link71-1.html から一部引用させていただいた内容は、明らかに【術】の領域ではなく【道】の領域でした。

 そうすると、「トヨタ式」を「何かに応用しようとする」場合には、「トヨタ改善【術】」をそのまま適用するのではなくて、その根っこにある「トヨタ改善【道】」について習い実践方法を探るほうが、遠回りにはなるかもしれませんがその実一番の近道になるのかも……と、そんな気がしています。


 http://www1.harenet.ne.jp/~noriaki/link71-1.html をジーッと見ていると、なぜか【誰かさんが70ヶ月以上かけて構築してきたこと】と、とてもよく似ているなぁ……という印象を受けました。

 もちろん、トヨタ式の【儲けるIE】とピタリと一致するわけではなくて、アスカ式は【楽するIE】というほうが相応しい仕上がりになりつつあるわけですが……意外なところで「繋がっちゃったよ!」と思ってみたり。


 飛鳥カナ配列の「とことんホームポジション死守」という方針は、もしかすると「どこで打ち間違いをするor言い換えに関するひらめきが出るかは解らない→人間の癖で、BackSpaceを打った後にホームポジションへと手を戻してしまう→結果としてホームポジション死守を選択した」のかも。

 「トヨタ改善【道】」と「飛鳥カナ配列」、ほかにも共通点があるのかもしれませんね……。


 このあたりはちょっと興味深いところなので、一般向けには役に立ちそうもない「トヨタ改善【術】」ではなく、一般向けの思考ツールとしてイケてる可能性がある「トヨタ改善【道】」に関する教材があるかどうかを探しているところです。

 トヨタ式を始めた第一人者(豊田喜一郎氏?)か、その一番弟子(大野耐一氏?)ぐらいの方が製作したツールでないと「意味がない」と思うので、探すにもちょっと時間はかかりそうですが……。


 とはいいつつ、一応見当をつけて唾をつけたものはあります。書籍では下記のもの。

 amazonレビューを見ると、だいぶ興味をそそる方向性の内容であることが読み取れます……というか、著者である大野さんの雰囲気が、もしかすると「富士通神田泰典さん」に似ているのかも?なんて想像してみたり。

トヨタ生産方式――脱規模の経営をめざして

トヨタ生産方式――脱規模の経営をめざして

大野耐一の現場経営

大野耐一の現場経営

 通信教育講座でも面白そうなものを見つけたのですが、そちらが当たりかどうかは……そのうち書く事になるはずです。


 さて、「トヨタ改善【道】」は、私にとっては未だに「ワケが解らんまま」の飛鳥理論をうまく紐解くツールになるのでしょうか……。

 いずれにせよ、日本語入力法もまた、こういった生産革新の分野と同じく【「問題解決中毒」であり、かつ「問題解決能力がある」方が、今後もこの分野をリードしていくことになる】のだろうなぁ……と感じました。


 以上、駄文終わり。


2007年3月28日16:07:25追記。

 通信教育講座についてのメモ

 いずれもJTEX・日本技能教育開発センターによるもの。

 著者が誰なのかはちょっと良く解らないので微妙。

 とりあえずは前者をチェック予定。

2007年03月25日 日曜日

地震は怖い──宮城県沖地震は「刹那*1の後に」来ても、なんらおかしくはない──という事実。

 ※未だに風邪が治っていないので、変なことを書いているかもしれません。


 宮城県沖地震がもうすぐそこまで来ている……という状況だけに、石川県方面で起きた地震に限らず「近年の地震傾向」はとても気になります……。

 個人的な趣味視点でしかモノが語れないものの、地震が来るまでに「宮城県では」こういう状態であって欲しいな……と思うことが3点。

鉄道関連。

 現有保安設備などをフル活用して「誤報に対する非難を恐れることなく・遅延に対する非難を恐れることなく」地震が来る恐れがあればとにかく非常停止を掛けるシステムを構築して欲しい(既に構築済み?)。

 通常運転時に「定時運行性を重視」するのは企業として正しい姿だと思うけれども、それはあくまでも「安全性が不安なく満たされている場合に限って履行すればよい」のであって、「地震が来るかもしれない」のならば「止めるほうが妥当」であることは、既に十分周知されているように思う。

 個人的には、むしろ自動車についても道路側では「全信号の赤点滅化(P波受信→S波通過後までの間のみ)」を行い、車両側にも「自動ハザード点灯+手動減速指示(P波受信→S波通過後までの間のみ)」をするシステムが必要だと思う。

電力関連。

 応急送電適性を考えると、いくら見栄えが悪くとも「架空線は架空線のまま維持」して欲しい*2

 余力があれば、応急送電するときに役立つように「迂回に利用できる余剰回線の確保」も。

 そして、自治体と共同で「(点検完了→発電再開までの速度が最も早いであろう)火力発電所を拠点とした応急送電シミュレーション」や「近隣電力会社からの給電を受け入れることを前提とした応急送電シミュレーション」を行って欲しい。

 阪神淡路大震災応急送電までの7DAYSにある記述や、ライフラインの電化設備依存度が極端に高まりつつある現状を考えると「応急送電を真っ先に完了させないと、ほかのインフラ復旧を大幅に遅らせる原因になる」ので、このあたりは慎重かつ迅速に対応できるような体制作りがどうしても必要になると思う。

通話・通信関連。

 可能な限り「リアルタイム通話に関しては、地域内ローカルループを優先的に復旧」させて欲しい。地域ドメイン・企業ドメイン血縁ドメインなど色々な帰属関係があるが、ボランティアベースを含む地域内ベースの活動が通話断絶によって阻害されれば「即時的な救援活動」にとって致命的なダメージとなりかねないので。

 通信については「地域内ローカルループのみを確保しても無意味」なので、こちらは「上流から優先して復旧」させることを前提に、「周辺にある非被災地域の上り線を、迅速に被災地域へとリンクさせる」ことに注力して欲しい。

 基本的な対策としては「通話は被災地内部での広域内線的な利用を優先・通信は被災地と非被災地を結ぶ連絡用途を優先」あたりが落としどころになりそうな気がする。

 DoCoMoやSBMが採用している「Push-To-Talk」システムのような「パケット音声系」が活躍するかもしれない。

いずれにせよ……

 震災対策としては「既存技術の徹底活用」がキーポイントになりそう。

 そして、それぞれの対策を行ううえで生成された「マニュアルドキュメントソフトウェアハードウェアの設計図」などといった「ソフトウェア的な資産(=複製可能な資産)」をうまく共有していくことこそが、イマドキの震災対策として最もコストパフォーマンスに優れ、かつ「一番みんなが安全でいられる可能性が高い」という結論を得るために必要なのかも。

 ソフトウェアハードウェアと違って「イニシャルコストと維持コストはべらぼうに掛かるが、複製に要するコストはそれと比べれば少なくすむ」という特性(ただし長所であるとは限らない)がある。

 ハードウェアソフトウェアの特性差をよく理解している人が集まって防災計画を検討していくようになれば、「次世代防災計画」を始めることも可能なのかも……。

タミフル75mg(Tamiflu75)。

 ……というか、インフルエンザ自体に罹ったのがはじめてなもので、だいぶ酷い思いをしました。

 今も単に「熱が平熱に戻っただけ(これは解熱剤の作用)」であって、体調は万全とは程遠い状況だったりします。


 タミフルを受け取るまでのパスに関しては、担当医には「棲家は高層階ではない?」「話題のタミフルだけど、飲む?」とかいう感じで確認されて、しかも薬剤師にまで「暴れそうになったら押さえてもらうように伝えること!」という感じで指示を受けたり……と、一般的な処方薬らしからぬ対応があってだいぶ恐怖心を抱いていました……。


 そんなことがあって、とりあえず擬似内線用の【W-ZERO3[es]】と、のどが渇いたときのための【350mlペットボトル入りの水】は用意して床につきました……が、何かがあってからでは微妙なので(!)メールメモを書いていました。

 (十分に慣れている「かえで携帯配列」を使っていてもなお)何度も間違いつつ文字を打っていた記憶はあるので、仮に「自分にはあっていない」らしい(W-ZERO3[es]の)標準入力法を使っていたら、途中で投げ出していたかも……という気すらしています。こういう時こそ「慣れたインターフェースのものを使う」ことが重要になりそうです。


 以下のメールメモは、いちばん上が「2007/3/24 6:31」で、コメントを挟んでから「2007/3/24 6:36」「2007/3/24 6:43」の順に記録したものです……これらはパソコン側にメールしたものをそのまま貼り付けていて、後加工は一切行っていません。

起きあがって実際に行動したのか、行動している夢を見ているのかが全く判然としない。

水と電話機は寝床に置く方がいいし、トイレと同じ階に寝床を確保しないと危ない。

付き添いがいれば一番いいのかもしれないのだけれど、そこまでやる必要があるのかどうかは謎。

-----------------

sent from W-ZERO3

 上記で「実行動か夢行動かが判然としない」というのは、トイレに関する話……床についたときと同じ服装のまま、「まるで万全の体調であるかのように軽快な動きで」自宅には存在しない「和式トイレ」に行った「記憶」がありました。

 その後すぐに「再びトイレに行こうとして起きた」ものの「体がだるくてしばし行動できなかった」ので、はじめて先の行動が「現実ではなく夢だと気づいた」のですが……完璧に実行動と夢行動が混線していました。

 夢側に転けていたからよかったものの、もし逆だったら……と思うと今でも怖いです。

嘔吐対応の洗面器と、薬も置いておく方がいい。行動したのか。行動する夢を見たのかが全く判然としない。

-----------------

sent from W-ZERO3

あと、汗をかくので下着の替えも。

奇行に注意」ってのは対策として正しくない。

「寝床から移動する必要性を最小限に留められる環境を作ること」が重要

頭と体の間で治癒バランスが崩れるからなのかもしれない。熱は下がるのに頭はまだぼんやりとしたままという期間があって、その間に事故が起こっているのかもしれない。

-----------------

sent from W-ZERO3

 ゲロゲロな状態のままで対策を考えようとしている自分っていったい……orz

 とはいえ、一般的に「寝床に用意できるものは寝床に置く」ことそのものはとても重要だと感じました。

 それと、理想的には「1階部分」で、できれば「トイレに隣接」した場所を寝床とすることも重要かと。


 実際の印象からすると、「Tamiflu単体の仕業」という印象はあまり正しくないのかもしれません。

 むしろ「Tamifluと解熱剤の作用によって、脳と運動機能の回復度に差が生まれる→夢行動側にコケれば幻覚になり、実行動側にコケれば奇行になる」と説明するほうが、当時の印象に近いような気がします。

 医学的な見方を知らない「個人的な」感想としては、「Tamifluを全面禁止にすれば止まる」という考え方はとても怖くてもできません……むしろ「抗インフルエンザ薬と解熱剤を組み合わせる限り、どういう組み合わせでも発生する」可能性があるようにすら感じました。


 もう一つ「何かがおかしい」と感じたのは……上のメモで多くの文字数を割いて「(そもそも無駄な行動を可能な限り抑止するために)手元に何を置くべきか」について書いていることと直結するのですが、現行の「奇行に走ったらすぐに止めよ!」という「イベントドリブンな対処法」が広く知れ渡っているということにあります。

 ハインリッヒの法則については耳にタコができるほど聞かされた方が多いと思われますが、この問題は本質的に同法則に従って検証するべきであり、「イベントドリブンで対処しようとしてはいけない」可能性が高いように思うのです。


 こういう状況である以上、少なくともTamifluを処方された方のうちなるべく多くからアンケートを取って、「現実にTamifluがもたらす可能性がある脅威」や「その脅威を未然に防ぐために有効だったものに関する情報」などに関する情報を、徹底的に収集する必要があるように思いました。

 個人的な感想としては、Tamifluを飲むに当たって、留意するべき事柄をまとめた紙片──それはたぶん「BAND-AID キズパワーパッド付属紙規模の詳細な情報──が必要だと感じました。


 本業のお医者さんや薬剤師さんですら「イベントドリブンでの対策しか伝授できない」ということは、本質的にそもそも「製品安全情報」の提供が遅れているはず……と、私はそう思いました。


勝手にまとめ。

  • 体温が乱高下するかもしれない「Tamifluの2粒目飲用後〜4粒目飲用前あたり」は、「頭だけ」がだるいとか「体だけ」がだるいとか言う「乖離状態」にある可能性がある気がする。
  • 可能な限り患者が「動く歩数を最小限度にとどめる事ができるように」することが重要
    • 寝床はトイレに可能な限り近いことが望ましい。同一階であり、かつ最低層階が望ましい気が。
    • あらかじめ患者に確認して「きちんと患者記憶してもらいつつ(←ここが一番重要!)」準備する方が良いものは、次のとおり……嘔吐対応の洗面器・のどの渇きに対応する飲料水・消化が悪くなさそうな軽食品・多量の発汗時に自力で着替えるための着替えを(下着だけでなく寝巻き全体で)一式・連絡用の携帯電話
  • 6〜7時間おきに看護する側が確認できればよいのかも。発熱が続く限りは毛布をかけていれば異常に発汗するので、着替えを逐一手伝いつつ体温を測りなおす……という具合が適当かもしれない。
  • 状況がこういう感じなので、年齢等の事情によっては「発熱が収まるまでは入院する」という方法が、とても有効な対策となりうる可能性がある。
    • 病院の一階部分で「大部屋またはブロックごとに水まわり設備がある」空間を用意できる場合、そこを「インフルエンザ患者が解熱するまで1〜2泊隔離するための場所」として使うという手もある。とにかく「何かあったときに、即座に数人が駆けつけられる状態」を作り出すことが肝心。家庭では無理な場合があるからこそ、それを病院でフォローするための手順を構築するほうが良いと思う。*3
  • 熱が下がったからといって医者の許可なく無理に出席/出社するな!困るのは本人ではなく、伝染される側だ。
  • 一連の事故責任は、薬単体のせいでもなければ、その場で止められなかった大人のせいでもない。本当に悪いのは「何が起きているのか・なぜ起きているのか」を把握し「どう対処すればいいのか・どういうリソースが必要なのか」を検討し「できそうな対策から即座に行っていく」というシーケンスを「ほとんど取ってこなかったこと」にあるのではないか、と。*4
  • 要因分析を試みると【×人、×物、○手順】になるはず。*5

 ……と、たぶんそんな感じなのだと思います。

 期の終盤に病欠をとるというのはサイアクな状況でして、もー胃が痛くてたまらないのですがorz

*1今日は「1秒を75等分したうちの一区間」という意味で使っていますが、文の内容としては「定義はできないが、とにかく短い時間」という意味で用いても矛盾しないと思われます。何らかの信念に基づきこの語句を採用したというわけではないため、解釈についてはお読みになる方ご自身にお任せしたく思います。

*2:電力線を地下線化すると、地震による被害が「水道・ガスと同時かつ同程度に」発生する可能性が高くなり、リスク分散の実現が困難となる恐れがある。

*32007年3月27日10:25:14追記分

*42007年3月27日10:25:14追記分

*52007年3月27日10:25:14追記分

2007年03月24日 土曜日

メモ。

 Aインフルエンザを罹っていて、身動きが取れません……orz

 復帰するまで、今しばらくお待ちください。


 ketttさんの「@Wikiで表組みがうまく行かない」という件、「|」の前後に「(半角スペース)」を突っ込まないといけないようです(今試してみて、始めて気づきました)。

 一応修正してみましたので、チェックいただければ幸いです。


 熱は上がったり下がったり……勘弁してほしいですorz

熱にうなされながら描いてみるテスト。

(2007年3月25日10:05:56に↓手書き表をjpeg形式→png形式に変更&一部変更)

f:id:maple_magician:20070325100505p:image

 グラフを単純に書くために「見かけの」手順数などという妙な書き方をしてみましたが、「かな系とローマ字系における」【記憶するべき】全手順数は

  • 「単字かな」出力系*1──83〜96手順
  • 「拗音かな」出力系*2──120〜200手順

の2つの基準しかない*3ことに注意。

 ここでややこしいのは、「単字かな」出力系でありながらも(姫踊子草入力法や下駄配列のような)「拗音かな」出力系に近い打鍵感を実現できる方式が既にいくつか登場しているということで。

 それと、JISX4063に準拠しない「拡張ローマ字系(AZIK/ACT/JLODなど)」であれば、1.0操作/かなに近い操作数で入力できる場合があるはず……ですが、超長文を基にした打鍵数計測をするほどの気力はないので、今日グラフには含めませんでした。


 それと、入力デバイスがこのグラフ上では

をごちゃ混ぜに表現している点にも注意……って、JISX4063を除けばきちんと分離されているから、それほど問題ではないのかも。


2007年4月19日2:05:58追記。

 ケータイで15キーを占有すれば、JISX4063綴りローマ字入力と同一の入力効率を実現できる……のですが、グラフにそれを描き忘れていました。一応下にリンクを追加しておきます。

 【指に宿る記憶】かえで携帯配列を改造して「カシス配列」と仮名をつけてみるテスト。

*1:表にあるものでは「かなめくり・ベル打ち・かえで携帯配列・JISかな系・NICOLA・飛鳥・小梅」が該当する。

*2:表にあるものでは「Kodame・JISX4063綴りローマ字入力・姫踊子草配列・下駄配列」が該当する。

*3:拗音を含む文字「列」を定義しているか否かという点のみによって左右され、その他の技術的用件には左右されない。

2007年03月22日 木曜日

飛鳥メモ。

 飛鳥の評価を厄介にしている点は色々とあるのだけれど、一つに「シフトの押下回数が人によって変わってくる」ところがあるのかもしれない。

 完全に連続シフトを生かせばそれなりに打鍵数は減るのだけれど、初期段階では「一切連続シフトをする余裕がない」だろうし、私のように「同手側の連続シフトは使わない」という例もあるし……。

 個人的には「同手同期シフト」と「両手連続シフト」は使いやすいと思うけれど、「同手連続シフト」と「両手同期シフト」は使いづらくて仕方がないんですよね……。

 どう考えても「Rayさんはそういう前提では配列設計をしていない」はずなのに、なぜ飛鳥ではそれでも違和感を感じることなく使えるのか……いまだに自分で納得できる説明を見つけられずにいたり。

 (※同期シフトNICOLA方式、連続シフトTRON/JIS系かな方式。「同期連続シフト」が許容されているのは、飛鳥と同じ「同期連続シフト」を採用した配列のみ。) 

 ……うーん、「同期連続シフト」という仕掛けが「同期シフト連続シフトの両方を許容する方式」である理由がハッキリしないと、どうにも答えは出ない予感。一つの配列で2つの作法を混在できてしまう(許容幅が広いor誤打する可能性が高い)から、「私が感じた飛鳥」と「ほかの方が感じた飛鳥」が同一である保証がまったくないというところが微妙かも。


 飛鳥カナ配列まとめWiki (仮称)ひらがなの50音順を利用した練習法にとりあえず追記……したのですが、既に書いていただいている【がぎぐげご+ん】までの方法と、追記した【さしすせそ】以降の方法が全然全く整合性ナッシングな状況でして……orz

C言語メモ。

 C言語、基本的なところにはまりまくり。

int a,b;
a=1;
b=a++;      // b←a の後に a++
int a,b;
a=1;
b=++a;     // a++ の後に b←a

 なぜにこういう仕様なのだろうか……「独習C」の書き方も「仕掛けが理解できた後でないと、記述意味が理解できない」記述になっているあたりが微妙。

int a,b;
int xor(int a,int b);
int xor(int a,int b){
    int c;
    c = (a || b) && !(a && b);   // or と nand の and を取る。
    return c;
}

 うーん……「独習C」に責任はないのだけれど……できれば、p.57の「and/or/not」とp.59の「xor」のみではなくて、「nand/nor」についても表で掲示するほうがいいと思いました。

 ……いや、「独習C」では、説明の順番がそもそも変なのかも。

 論理演算では「not→and/or→nand/nor→xor」の順番で説明しないと、混乱する可能性がありますので(というか、電子回路本ではこの順序で説明する例が多いような?)。

(メモ)新興検索エンジン雑感。

百度

 ……「Google以前」の頃のインターフェースなのだろうか?

 「親指シフト」で検索するとRayさんの伊豆別館が一番上になる(日本語入力コンソーシアムは3位)ことからして、PageRankベースではなくてキーワードベースリンク要素内のテキストを検索結果に反映しない(=miserable failure問題が発生しない)方式の検索エンジンなのかも。

サグール

 ……10件ごとの検索結果ページが連なって表示されるタイプスクロール速度が遅い「携帯電話」などで利用するには良いと思うけど、PCで使うには冗長すぎる……かも?。

 「親指シフト」で検索すると日本語入力コンソーシアム34位になってしまう……なぜだろう。

MOOTER

 ……絞り込みキーワードの折りたたみ方・表示方法は面白いと思う。それと「ブログフィルター」が実装されているのは興味深い……のだけれど、手動設定なのか「関心空間」が非ブログとして扱われている点は微妙。この設定、「ブログ排除/ブログのみ」「ショップ排除/ショップのみ」とかいう感じで属性を指定して絞り込みできると便利なのだけれど……。

 こちらも「親指シフト」で検索してみると日本語入力コンソーシアムは3位……うーん。

2007年03月21日 水曜日

「飛鳥カナ配列」は、【効率よく打てるから、結果的には快適に打てる】ではなく【快適に打てるから、結果的には効率よく打てる】にフォーカスして設計された……のかもしれない。

(注:単なるメモです)


 計算配列──【効率よく打てるから、結果的には快適に打てる】配列──たとえばNICOLAとか、TRONかなとか。

 計算配列の手動選別──【効率よく打てるから、結果的には快適に打てる】配列から、【快適に打てるから、結果的には効率よく打てる】配列を探し出している──たとえばJIS X 6004 とか。

 手捏ね配列──【快適に打てるから、結果的には効率よく打てる】配列──たとえば飛鳥カナ配列とか。


 計算配列に近いほど「一定テンポ打鍵時に高効率をたたき出す可能性が高い」。

 手捏ね配列に近いほど「会話テンポ打鍵時に高い快適性を発揮する可能性が高い」。


 どの配列においても、慣れた人にとっては【効率よく快適に入力できる】はず……なのだけれど、個々人がそれぞれにどういう打鍵方法を望んでいるか・どういう打鍵テンポを望んでいるかによって、選択先となる配列は異なってくるのかもしれない。


 飛鳥の配列指針を一言で表すと、それはたぶん【気配りの集合体】という風に集約されるのかもしれない。

 ──故に、飛鳥の場合は【快適に打てるから、結果的には効率よく打てる】という順序が成立するし、その逆は真ではないので、結果として一般的な「打鍵評価スクリプト」でうまく評価するのが難しい……と。


 何か「簡易的に飛鳥を習得した気分になれる」テキストが必要になるかもしれない。

 たとえば「ASDFJKL;IOM,.」と変換・無変換のみを覚えて、その状態でも記述できる文章をざっくりとテスト打鍵してもらう、とか……。


 飛鳥の「面白さ」を提示しようとする場合、ほかのかな系を紹介する方法そのままでは十分な魅力を提示できないのかもしれず、「飛鳥らしさ」を良くつかんだテキストが色々と必要になるのかもしれない。


 かな系の中では「特にややこしい・特に習得しづらい」ととられがちな飛鳥から「ややこしいと思われてしまう要素」を解消した紹介ができるようになれば、自動的に「飛鳥よりは習得しやすい」はずの、ほかのかな系──清濁同置系配列や、濁点分離系配列など──に対する意識までを含めて、ユーザさんからの見かけを一気に変えることができるのかもしれない。


 こういう手順を通して「配列を乗り換えること」に対するベネフィット感を提供できれば、かな系以外をも含めた配列系全体に、今よりもさらに光が当たるようになるのかも。


 

2007年03月19日 月曜日

http://d.hatena.ne.jp/paprikan/20070314/1173846889

 シャドールームさん経由記事からさらに経由して拝見しました。


 漢字はなくなるかも?という結論部分ではなくて、その考察内容が興味深かったもので……コメントさせていただいたこともあり、手元メモすることに。

 個人的には「コンピュータがあれば、日本語の魅力はより発揮される」かな……と。


 「出力」革命は大型コンピュータ時代に・「編集革命ワープロ時代に、それぞれ技術的な用件をクリアしてきたわけで。

 そして、「入力革命パソコン時代の今だからこそできるのかもしれない。

 ソフトウェアの力によって「ハードウェアの都合に縛られずに日本語入力法を変更できる」今の時代であれば、「個々人の要求に合致する入力法を自由に設定できる」余地があり、結果として「入力編集〜出力の全領域で、コンピュータ時代だからこそ示せる日本語の魅力」を提示できるのかも。


 【日本語入力革命】=【自分に合う入力法を自由に使い、探し、設計するという意識&環境普遍的になること】≠【唯一つの「すばらしい」入力法を全員が強制されること】


 日本語入力法に関わる論者が一人残らず【唯一つの「主観ですばらしいと思う」入力法を全員に強制すること】を諦めなければ達成できないし、逆に言えば日本語入力法に関わる論者が【自分に合う入力法を自由に使い、探し、設計するという意識&環境普遍的になること】を望めば、それはいつか必ず実現できるのではないかな……と。


 もちろん今は【自分に合う入力法を自由に使い、探し、設計するという意識&環境普遍的になること】自体が「ただの夢物語」でしかないのですが……。

 それでも【色々な入力法を経由】して【それでも満足できずに独自の入力法を設計する】という方が増えつつある現状からすると、既に【唯一つの「主観ですばらしいと思う」入力法を全員に強制すること】の理屈は夢云々を語る以前に「破綻している」としか言いようが無い状況でして。


 原理的に破綻しない解決法として【自分に合う入力法を自由に使い、探し、設計するという意識&環境普遍的になること】を望むのは、理屈としては問題ないはずです。

 もちろん、この考え方が普及すれば【唯一つの「主観ですばらしいと思う」入力法を全員に強制すること】を望む人にとっても無益ではなく「きちんと恩恵を受けることができる」わけで。

 結果的に得たいと思う理想が「どこでも自分が気に入っている入力法が使えること」であるならば、そのために必要のないこと──たとえば「俺は○○を使いたい。だからお前が××を捨てて○○にするべきだ」という話──はすっぱりと忘れて「コンパクトな理想を追求する」ほうが、話は早いはずです。


 「自分が使うこと」のために「他人に使わせること」の必然性が存在してはいないことを、今後どうやって証明していけばいいのか……。

 当面のネックは「自身の管理下にはないコンピュータについての対応」でしょうか。

 ここは色々と難しいところがある気もするのですが、基本的には「なるべく多くの配列を扱えるエミュレータを優先的に推奨していく」方向性が良さそうに思います。

 さすがに理想エミュレータはまだ存在していないわけですが、特定配列のみをエミュレートするツールを押すよりは、良い方向へと働くはずです。


 そして、もう一つの側面として「練習法」の整備と「案内サイト」の整備も必要ですね。

 飛鳥カナ配列まとめWiki (仮称)については既に色々と記述いただいていまして(私が書いた分量以上に、既に他の方に記述いただいているのです)、こういったものを含めた「みんなで構築していく」タイプのコンテンツがより増えると良いのかもしれません。

 こういったコンテンツと既存のコンテンツを縦断的に検索していくことで、今後ユーザになるかもしれない方にとって「より理解しやすい」状態を構築できるかどうか……も、入力法に関する意識革命(?)を推進していく中で、重要な要素となりそうな気がします。


 いずれにせよ、「みんなが公平に幸せになれることが一番!」と、結局はそこに行き着くのかも。

2007年03月18日 日曜日

メモ。

 ホームポジションを「叩くフリ」をする練習法のみ記述

 これ以上シンプルに書く方法が思い浮かびません……もっと何とかなる「気はする」のですがorz


 かな系鍵盤配列に関するリンク集の「月配列2-263」について、発生年月日を【2003年9月1日〜】にしました……過去ログ内の発言日をそのまま用いました。

それと、月配列を親指シフトでさんのリンクをここに紐付け。

「ΝΝが親指シフト配列の最適化とかしてみるブログ」さんにより、「翡翠配列」の設計が開始された模様です。

 親指シフトブックマーク(@ぎっちょん)さん経由。


 「連続的な同手シフトを抑制」「逆手シフトを抑制」とあるようですが、それ以外にシフト方法に関する記述は特にないようで、「同期シフト(NICOLA&小梅方式)」「普通シフト(TRONM式方式)」「同期連続シフト(飛鳥方式)」のいずれを採用しているのかは読み取れませんでした……このあたりの説明は後々に行われそうですね。

 遺伝的アルゴリズムを用いて親指シフト配列を設計すると、全手順を検索する方法とは全く逆で「清濁同置よりも清濁異置のほうが値を得やすい」というのは、理屈では理解できるものの実験的にテストした例を見かけたことはない気がするもので、この点は興味深いです。


 現在の動向を拝見する限り、newnyuさんが探索する先には【片手シフトは非連続打鍵用に使用(無シフトまたは逆手親指シフトと密に連接)、両手シフト連続的に使用】というスタイルがあるのではないかな……と思ってみたり。いずれにせよ、評価打鍵とそれを基にした再計算など、今後の動向には期待したいところです。


 ひとまず、かな系鍵盤配列に関するリンク集に追記してみました。

RSS配信方法の設定を変更してみました。

 「よろしければ配列について教えろ その6」で588さんが指摘されていたことに関連して、設定を変更してみました。


 はてなダイアリーの「設定」→「公開設定」→「RSSの公開設定」→「RSSフィードへの全文掲載」について、設定をデフォルトの【RSSフィードに全文を掲載しない(要約のみ掲載)】から【RSSフィードに全文を掲載する】に変更しています。


 RSSフィードを利用して「全ての記事を、自分にとって見やすい方法で見ることができる」状態を構築されている方がいらっしゃる……とあれば、この設定変更は必須かな、と思いまして。

 ……うちの日記を全文配信にしてメリットがあるのかどうかは不明ですが^^;、ひとまず。

月配列の親指シフト化を姫踊子草/繭姫で実現できるのか?

 月配列を親指シフトでさんのページで【菱や 姫踊子草 では「シフトを押しっぱなしにした状態で裏のキーを連続で押す」ことができなかった】という指摘があったもので、去年の8月頃に作った定義を引っ張り出してみました。


 「姫踊子草」のエンジンで指摘の挙動を再現できるかどうかは確かめていないのですが、「StrokeMode=2」を「StrokeMode=1」に変更すれば、おそらく動くのではないかな……と。


 ここでのポイントは、飛鳥カナ配列の「同期連続シフト」を再現する「MultiDownHold=」ではなく、SandSを再現する「SemiShift=」を用いることでしょうか。

 (2007年3月19日1:11:12追記:「MultiDownHold=」は文字キーDown→シフトキーDownの挙動を同時打鍵処理して、シフトキーは該当文字キーを修飾します。一方で「SemiShift=」は文字キーDown→シフトキーDownの挙動を同時打鍵処理せず、シフトキーは次の文字キーを修飾します。お好みで使い分けると良いのかも)


 とりあえず当時の定義をはってみます。

【繭姫専用】センタシフトJISX6004(スペースキーシフトに、普通+逐次)+小指は(HMOデフォルトまま)英字シフトに.hmo_kana

visible=1←この行は常に先頭に置き、かつ削除しないでください。
'
' センタシフトJISX6004(スペースキーシフトに、普通+逐次)+小指は(HMOデフォルトまま)英字シフトに.hmo_kana
'「スペースキーは文字入力中でなければ空白・文字入力中はSandS」
'
StrokeMode=2
SemiShift= 
'         ^は半角スペース。
'MultiDownHold= 
'              ^は半角スペース。
TypeModeDefault=14

=
qwertyuiop@[	そ$け$せ$て$ょ$つ$ん$の$を$り$ち$未
asdfghjkl;:]	は$か$し$と$た$く$う$い$゛$き$な$未
zxcvbnm,./	す$こ$に$さ$あ$っ$る$、$。$れ

= 	*
'^は半角スペース。
qwertyuiop@[	ぁ$゜$ほ$ふ$め$ひ$え$み$や$ぬ$M「$未
asdfghjkl;:]	ぃ$へ$ら$ゅ$よ$ま$お$も$わ$ゆ$M」$未
zxcvbnm,./	ぅ$ぇ$ぉ$ね$ゃ$む$ろ$・$ー$未



={ }	*
' ^は半角スペース。
qwertyuiop@[	ぁ$゜$ほ$ふ$め$ひ$え$み$や$ぬ$M「$未
asdfghjkl;:]	ぃ$へ$ら$ゅ$よ$ま$お$も$わ$ゆ$M」$未
zxcvbnm,./	ぅ$ぇ$ぉ$ね$ゃ$む$ろ$・$ー$未


=H
'スルー出力、英字打ち用

【繭姫専用】センタシフトJISX6004(無変換キー+変換キーをシフトに、普通+逐次)+小指は(HMOデフォルトまま)英字シフトに.hmo_kana

visible=1←この行は常に先頭に置き、かつ削除しないでください。
'
' センタシフトJISX6004(無変換キー+変換キーをシフトに、普通+逐次)+小指は(HMOデフォルトまま)英字シフトに.hmo_kana
'「スペースキーは文字入力中でなければ空白・文字入力中は変換」

StrokeMode=2
SemiShift=LR
'MultiDownHold=LR
TypeModeDefault=14

=
qwertyuiop@[	そ$け$せ$て$ょ$つ$ん$の$を$り$ち$未
asdfghjkl;:]	は$か$し$と$た$く$う$い$゛$き$な$未
zxcvbnm,./	す$こ$に$さ$あ$っ$る$、$。$れ

=L	*
qwertyuiop@[	ぁ$゜$ほ$ふ$め$ひ$え$み$や$ぬ$M「$未
asdfghjkl;:]	ぃ$へ$ら$ゅ$よ$ま$お$も$わ$ゆ$M」$未
zxcvbnm,./	ぅ$ぇ$ぉ$ね$ゃ$む$ろ$・$ー$未


=R	*
qwertyuiop@[	ぁ$゜$ほ$ふ$め$ひ$え$み$や$ぬ$M「$未
asdfghjkl;:]	ぃ$へ$ら$ゅ$よ$ま$お$も$わ$ゆ$M」$未
zxcvbnm,./	ぅ$ぇ$ぉ$ね$ゃ$む$ろ$・$ー$未


={L}	*
qwertyuiop@[	ぁ$゜$ほ$ふ$め$ひ$え$み$や$ぬ$M「$未
asdfghjkl;:]	ぃ$へ$ら$ゅ$よ$ま$お$も$わ$ゆ$M」$未
zxcvbnm,./	ぅ$ぇ$ぉ$ね$ゃ$む$ろ$・$ー$未


={R}	*
qwertyuiop@[	ぁ$゜$ほ$ふ$め$ひ$え$み$や$ぬ$M「$未
asdfghjkl;:]	ぃ$へ$ら$ゅ$よ$ま$お$も$わ$ゆ$M」$未
zxcvbnm,./	ぅ$ぇ$ぉ$ね$ゃ$む$ろ$・$ー$未


=H
'スルー出力、英字打ち用

 次に、月配列を親指シフトでさんのページで公開されている配列を定義ファイルへと変換してみます。

【繭姫・姫踊子草共用】センタシフト月配列(スペースキーシフトに、普通+逐次)+小指は(HMOデフォルトまま)英字シフトに.hmo_kana

visible=1←この行は常に先頭に置き、かつ削除しないでください。
'
' センタシフト月配列(スペースキーシフトに、普通+逐次)+小指は(HMOデフォルトまま)英字シフトに.hmo_kana
'「スペースキーは文字入力中でなければ空白・文字入力中はSandS」
'
'この定義は、下記のページを基準に作成しました。
'http://www.sodan.ecc.u-tokyo.ac.jp/~noolab/tsuki/tsuki.html
'
'ただし、右下にある「ろ_」キーに関しては「非シフト側」しか打てません。
'
'
'StrokeMode=2
StrokeMode=1
'非繭姫環境に対応するため、モードを1に変更。
SemiShift= 
'         ^は半角スペース。
'MultiDownHold= 
'              ^は半角スペース。
TypeModeDefault=14

=
qwertyuiop@[	そ$こ$し$て$ょ$つ$ん$い$の$り$ち$「
asdfghjkl;:]	は$か$、$と$た$く$う$。$゛$き$れ$」
zxcvbnm,./	す$け$に$な$さ$っ$る$ー$゜$・$未

= 	*
'^は半角スペース。
qwertyuiop@[	ぁ$ひ$ほ$ふ$め$ぬ$え$み$や$ぇ$@$未
asdfghjkl;:]	ぃ$を$ら$あ$よ$ま$お$も$わ$ゆ$;$:
zxcvbnm,./	ぅ$へ$せ$ゅ$ゃ$む$ろ$ね$ぉ$?$M_



={ }	*
' ^は半角スペース。
qwertyuiop@[	ぁ$ひ$ほ$ふ$め$ぬ$え$み$や$ぇ$@$未
asdfghjkl;:]	ぃ$を$ら$あ$よ$ま$お$も$わ$ゆ$;$:
zxcvbnm,./	ぅ$へ$せ$ゅ$ゃ$む$ろ$ね$ぉ$?$M_


=H
'スルー出力、英字打ち用

 挙動としては、たぶんこれで正しいと思います……但し、挙動を検証したのは「繭姫」のみで、「姫踊子草」による確認は行っていません。

 あっ、姫踊子草系の制限なのかどうかは不明ですが、「ろ_」キーは無シフト側のみが使用可能で、シフト側は定義できない(無シフト側として解釈される)ようです……その点にはご注意を。

2007年03月17日 土曜日

メモ。

(将来:Google製のN-gramは、1〜7gramで26GB(しかも圧縮済みでの容量)。)

 スラッシュドット ジャパン | Google、大規模日本語データの公開を検討

 Google: 大規模日本語データ公開に関する特別セッション

 この2つを見てみたい気がします。

 単字出現頻度・2字連接頻度・3字連接頻度あたりが公開されれば、日本語入力法を設計・評価する上で重要な資料となりそうですし。

2007年11月5日2:43:15追記。

 半分は希望通り(というか予想通り)になった模様。

 http://itpro.nikkeibp.co.jp/article/NEWS/20071101/286215/

 http://googlejapan.blogspot.com/2007/11/n-gram.html

 http://www.gsk.or.jp/catalog/GSK2007-C/catalog.html

 ……ってゆーか、「大規模データ」という時点でN-gramぐらいしかないとは思うのですが^^;。

2007年03月15日 木曜日

ナナオのカラーユニバーサルデザイン対応ワイドモニターが欲しい!

 ……と叫んでみたのだけれど、私自身が第二色弱だから「色弱シミュレータ」の効果を確認できるかどうかは不明だし……うーん。

 ちなみに、以下の文章は「EIZO/L567」での表示検証は行わず、「Toshiba/DynabookSS M200 140/2X」の液晶パネルで表示させたものを見て言及することにします。

 #M200のパネルは私が見ると「全体が青に傾いて見える」ので、相当変なことを書いているかもしれません。


 できれば今回のプレゼントに関しては、「物理インターフェース論理インターフェースなどを実際に設計している方(=色設計の主導権を持っている方)」にあたって欲しい気がします。


 ……で、とりあえずキーワードに書かれている案内にしたがって、一通りリンクを貼ってみることにします。


 http://www.youtube.com/watch?v=ZhOSQc4FZxg

 基準動画

 冒頭の「EIZOロゴ……ではなくて、その横にある【◆(青:B)】【\(赤:R)】【/(緑:G)】に注目。

 この動画は、あなた自身に色弱や式網があるか否かに関わらず「貴方が普段見ている色」で表現されています。

 色とりどりのピーマンりんご(?)、赤いイチゴハンバーガーピザ、赤いイチゴ……という感じの順番ですな。


 http://www.youtube.com/watch?v=KUUBqKrMiuY

 色覚シミュレーション Protan型。

 冒頭の「EIZOロゴ……ではなくて、その横にある【◆(青:B)】【\(赤:R)】【/(緑:G)】に注目。私が見ると、【\(赤:R)】がほぼ黒に見えます。

 緑→青緑→青は再現されているが、青→【紫→赤→黄色】→緑あたりが不分別に近い状態になっています。

 全般的には、私から見ると「ものすごく違和感がある」ように見えます。


 http://www.youtube.com/watch?v=cN_3DZJ5rpQ

 色覚シミュレーション Deutan型。

 冒頭の「EIZOロゴ……ではなくて、その横にある【◆(青:B)】【\(赤:R)】【/(緑:G)】に注目。私が見ると、【\(赤:R)】が茶色に寄っていて、【/(緑:G)】が青に寄っている様に見えます。

 全般的には、私から見ると「明度が低い」ことを中心とした印象を受けますが、あまり標準動画とのハッキリとした差を感じ取れなかったりもします。


 うーん……色覚シミュレーションを通した後の「明るさ」が必ず減少しているあたりは微妙かも。

 実際には「見かけ上同じ明るさになるように」シミュレーションしないと、色の違いよりも明るさの違いにとらわれた印象を持ちかねないような気がします。

 目は耳ほどのダイナミックレンジは持ち合わせていないような気がしますが、それでも耳と同じく目にも「普段いる環境の明るさに順応する」方向での補正がかかっているはずなワケで、このあたりについては更なる調整が必要ではないかな……と感じました。

 http://www.itmedia.co.jp/news/articles/0703/15/news002.html

 冒頭のピーマン写真……ほとんど見分けが付きません^^;。左のほうがくすんでいる様には見えるのですが、並べたりせずに1枚ずつ提示されたら「両方とも普通……かも?」と感じそうです。

 大量のカラーチップが載っているところでは……「灰色」と「淡い緑」の区別が付きづらいです(これはたぶんEIZO/L567で見れば区別できる類だと思う)。


 http://www.cudo.jp/sikumi/index.html

 このあたりの「呼び方」には色々ありましたね……。

 http://www.nig.ac.jp/color/mou.html

 この方のように「理詰めで【色盲】に決めたはいいが、結局世間様の語感には抗えず、最終的には【色弱】という呼びを使うことにした」という例もありますし。

 個人的には後者のほうが「筋が通っている」気がするもので……いっそのこと【色弱】を正式名とするのではなくて、【色覚弱者】を正式名(もちろん人に対するもの)として、略称および医学上の区別名として「色弱」を用いる……というあたりが、一番ぴたりと来るように思います。


 http://colorfilter.wickline.org/

 色変換シミュレータ……もともと今まで作った自作ページは「なるべく見づらくならないように」気をつけてきたつもりでした。

 ……が、一件だけいやな予感がしたので↓をテスト。

 http://www29.atwiki.jp/asuka-kana-layout/

 ……うーん、微妙かもしれないですね。

 とりあえず、一番下に注記を追加してきました。


 色の世界では、長年の言及が実って「色のバリアフリー化を目指す動き」が徐々に進行し始めているようです。

 こういう行動が本当の意味で成功する頃には「今を生きている人が全員土へと還っている」はずですが、どれだけ時間がかかるかを解っていてもなお「今からやらなきゃ、何時まで経っても変わらないままじゃん!」という意思を持って行動されている方がいるというのは、とても心強いものがあります。

 それにしても……こういう分野に首を突っ込んで、しっかり製品を世に送り出すあたりが、やっぱりナナオらしいですね。そういうポリシーはとても好きです。


 ……さて。

 「日本語入力法のバリアフリー化」は、一体どうやって達成すればいいのか……相変わらずハッキリとした答えは出ないものの、今のところ空想レベルでしかない日本語入力法のバリアフリー化案日本語入力練習法のバリアフリー化案については、まだまだ練り直しが必要かなぁ……という気も。

 こちらは「今を生きている人が全員土へと還って……」なんて程に遠い話ではなさそうで、仮に「イベントが起きるとすれば」四半世紀後〜半世紀後までの間に動きそうな予感がします。

 たぶんキッカケは「ケータイから先に使い慣れた世代が、働き盛りになった頃」に訪れるだろう……と。彼らはおそらく「何かに気づき、何かに不満を持つ」はずで、その頃の彼らにとって「ケータイの操作イメージを体で覚えているからこそ直感的に納得でき、かつ矛盾がない」説明を書き上げられるかどうかが、今からの勝負なのかもしれません。


 ……いや、そもそも「日本語入力法のバリアフリー化」という表現が「適切なのかどうか」という点からして再考する必要があるのかも?

 個人的には、日本語入力法に関するそれも「バリアフリー化」という視点で語るほうが「昔の論議を引きずることなく、本当に必要なことを可視化できる」のかも……と、そう感じていたりします。

2007年03月14日 水曜日

日本語入力法雑感。

 更新しないつもりだったのですが……忘れてしまいそうなので。


 基本的にはどの入力法を使っても入力速度は同じ……たいてい、速い人はどの入力方式を使っても速いし、遅い人はなにを使っても遅い。

 しゃべる速度や手書きする速度とは別に、人それぞれに「打てる速度」が決まっている(訓練すれば(個人差はあるが)入力速度は上がる)。

 「どの入力法を使っても入力速度は同じ」なのであれば、個々人が選ぶべき入力方法の基準として「誰かが出したトップスピード」は全くアテにならない可能性すらある。

 「どの入力法を使っても入力速度は同じ」なのであれば、個々人が選ぶべき入力方法の基準としてもっとも適しているのは「自分で試してみて、もっとも快適だと思う(余裕を持って入力できる)入力方法」になる……自分にとって余裕がある入力方法に限り、そこからさらに速い入力速度を目指すことができるはず。

 ……入力方法に関する「快適さ」に対する要求は千差万別なのだから、一つや二つの入力方法で何とかしようとする……というのは無理がありすぎると思う。

 

2007年03月13日 火曜日

メモ。

 一週間ほど更新を停止します……たぶん。

 この週末、全くと言っていいほど本を読み進めることができなかったので、なんとかしたいのです……。

 ただし、コメントへの返答は行っていく予定です。

2007年03月12日 月曜日

メモ。

 「とくダネ」で、ダシの話。

 「切れ目を入れた昆布を非沸騰状態で30分〜60分煮る→昆布を引き出してから火を止めてかつお節を入れ、かつお節が全て沈んだら濾す。濾すときにはかつお節を絞ってはいけない」と。

 出ていたシェフの方は「3ヶ月にいっぺんでもいい、時間をとってだしをとり、子供にその味を覚えてもらうべきです」……という趣旨の話を。

 まえに「ためしてガッテン」か何かで【市販の出汁はうまみが出すぎて調整しづらいから、豚汁を作るときには出汁を入れないほうが良い】という話もあったような。

 話を「とくダネ」にもどして、最後に誰かが「お母さんが〜伝えないと」といっていたけど、そこは他の誰かが手伝っても良いのではないかなとも思う。ついでに言うと、それを「忙しい朝に作らなければならない」という制約もないわけで。

 個人的には「十分に余裕が取れる【休日の昼下がり】あたりからゆっくりと準備して、その日の晩御飯と翌朝の朝食にダシを使う」ぐらいがちょうどよいのではないかな……と思ってみたり。「無理をせずにできる範囲でやること」が、それを継続するための秘訣なのだと思うから。

 日本版「スロウフード」の原点、ということで。

「飛鳥カナ配列まとめWiki (仮称)」を作ってみた。

(関連:飛鳥カナ配列まとめWiki (仮称))


 飛鳥スレッドで「最新版が21c290だと勘違いした」というかたの話を拝見して、微妙にへこみました……ええと、それは完璧に私のせいかもですorz


 せめて罪滅ぼしになれば……と思いまして、ひとまず「飛鳥カナ配列まとめWiki (仮称)」を作成しました。

 「記述基本方針」にも書いたとおり「自由にコピーできる状態を維持」することを前提としてページを作成しました……ので、よりまともなWikiを作成できそうな方がいらっしゃいましたら、ご遠慮なく新Wikiを作成いただければ……と思います。


 それと、日本語入力用キー配列(指に宿る記憶)に関するリンク集がものすごいことになっているようなので、こちらは親指シフトのそれと同じようにページを分離してみました


 どういうページを作っていけばよいのか、いまいちピンとこないところは迷いどころなのですが……ひとまず必要そうな雛形だけを作ってみた、という状態です^^;。

 ちなみにWikiデザインについては、Rayさんが以前公開していた「ゆめ」という配列から連想したものを採用しました。

2007年03月11日 日曜日

メモ。

(関連:メモ。@2007年03月07日コメント)

 mayuhime ni yoru [asuka kana hairetu no ro-mazi sixyuturixyoku] tesuto wo site imasu.

 繭姫による「飛鳥カナ配列のローマ字出力」テストをしています。

 gamennni JIS X 4063 tuduri no ro-mazi de mozi wo hixyouzi saseta baai, yomiyasusa ga itizirusiku otottari sinaikadouka ga kini natte imasu.

 画面にJISX4063綴りのローマ字で文字を表示させた場合、読みやすさが著しく劣ったりしないかどうかが気になっています。

 settei deha [kogaki mozi wo dokuritu site dasu] youni siteiru hazu nano desuga, nazeka [kogaki mozi wo matte dasu] youni kawatte simau baai ga aru youdesu.

 設定では「小書き文字を独立して出す」様にしているはずなのですが、なぜか「小書き文字を待って出す」様に変わってしまう場合があるようです。

 yappari midurai desune....dou siyou. utteiru sanakaha mada iito sitemo, sono ato yomi kaesou to suruto kanari turai mono ga arimasu.

 やっぱり見づらいですね……どうしよう。打っている最中はまだいいとして、その後読み返すとするとかなり辛いものがあります。

 uenoreidehatekitouniwakatigakisiteimasuga,zissainidakenndougawosatueisurutonaruto,kouiuhuunizennbuturanattemoziganixyuurixyokusaretesimaunode,korehakoredekanarimiduraikimosimasu.

 上の例では適当に分かち書きしていますが、実際に打鍵動画を撮影するとなると、こういう風に全部連なって文字が入力されてしまいますので、これはこれでかなり見づらい気もします。


 いずれにせよ、未だ「ぐたりモード」は継続中……orz

パソコン市民IT講座 - Google 検索というものがあるらしい。

 なんだか「同じキーワード」「似たような受講料」で提供されてるなぁ……と思ったら、どうやら

 ……こんな感じらしく。


 構成としてはネットカフェのそれにとても近いようで、「パソコン2台を占有するから1000円/時間」が標準料金らしき点にはなるほど納得……という感じ。

 ネットカフェは「水もの商売」だけれど、同様の機材を使っても「パソコン講座」とすればそれは「習い事」だから、予約による商売が成り立つ……と。

 「パソコン市民IT講座」というのは、ソフトウェアパッケージ名か、もしくはフランチャイズ契約時のブランド名のようなものなのでしょうか。


 ここで不安なことは2つ。

 後者は「聞きに行けば解る」のだろうけれども、わざわざそれだけを聞きに行く気にはなれないし……。


 ……個人的には、ここで「Knoppixを使った同種の教材」を作れれば面白そうだな……と、そんなことを考えてみたり。

 ここでやってるのと似たような感じで「画面を出して、音声アナウンスをする」タイプソフトを作って、「先生」という名前のアプリケーション名でメニューかデスクトップから起動できるようにする、とか。

2007年03月09日 金曜日

メモ。

 Qwerty配列 - Wikipedia

 どの記述がどのソースに対応しているのかを明示することが困難な状況なので、とりあえず「肯定論&否定論」を全部バッサリとコメントアウトしてきました(各論を書くための元ネタとしてはそのまま使える&過去版から切り貼りされると特定版削除が必要になってしまうので、「記述の消去」ではなく「コメントアウト」としています)。

 ……とりあえずは様子見。

 そのほか、今日はぐったりモードなので、あとは書けそうにないです……。

2007年03月08日 木曜日

飛鳥理論と秋の空……?

(過去:メモ。@2007年03月05日)

(過去:増田式キーボード練習法・改メモ(本を見ないと解らないと思う)。)

(過去:増田式もどき練習法の飛鳥風煮込み。)


 5日に書いたメモについて、ketttさんから「配列表をベースとした相関図」を頂きました。

http://sapporo.cool.ne.jp/tsukimoriseki/ito.png

 「どの線を描いて、どの線を捨てるかを決定する」→「実際に線を引いて、可視化できる範囲のみを描画する」というシーケンス全体が、かなり手間のかかる作業のはずでして……図示頂きありがとうございます。

 アレを書いた時点では、「どうやって3次元的に表現するか」ということしか考えていなかったのですが、実際はこうやって2次元的に表現していただけるほうが見渡しやすいですね。


 ……で、この図を見つつ「キー使用頻度」だけでは確認し切れなかった「飛鳥が最低限度果たそうとしているであろうこと」を書き出してみることに。


 うーん……新事実やら事実の整理やらといったことが出来ずにいます……orz

 もう少しじっくり眺めてみることにします。

2007年03月07日 水曜日

メモ。

 ↓の記事(?)で全ての時間がつぶれてしまいました……orz

 そのため、ketttさんが公開された画像の件、今日の夜に言及させていただきます。


 そういえば、下に書いた動作って「オフ・ビートリズム(?)」と相性がよさそう。

 邦画SWING GIRLS」を見てから取り組むと、打鍵練習時の違和感を多少は緩和できるかもしれない。


D

 「退屈だッ!」うんざりだッ!」と指摘されてしまった……orz

 そりゃ……確かに退屈だね。素直に謝るしかないところで。

 国内ユーザ向けの動画投稿サイトって、どこかにないだろうか。

 ……いや、掲示を取り下げるほうが先なのかもしれない。

 

増田式もどき練習法の飛鳥風煮込み。

(出力先: http://www29.atwiki.jp/asuka-kana-layout/pages/28.html )

(未来:ホームポジションを「叩くフリ」をする練習法)

(参考:飛鳥をこうやって練習してみました)

(過去:NICOLAから飛鳥カナ配列への移行記録。)

(過去:増田式キーボード練習法・改メモ(本を見ないと解らないと思う)。)

(過去:メモ。@2007年03月05日)


 飛鳥スレッドでの件を拝見して、少しばかり考えてみました。

 お役に立てるかどうかは不明ですが、ひとまず……。


 基本的に、飛鳥はほかのカナ系配列と同じく「カナ系」の配列です。

 そして、手順を覚える鉄則は「最もシンプルパターンから覚える」であろうかと思われます。

 ……とすると、連続シフトは後回しにして「単独で文字を出せるように覚える」ようにすれば、見た目は遠回りかもしれませんが、一番の近道なのではないかな……と*1



 練習順序は……迷いますね。

 とりあえず「器用に動くほうの手」に絡む文字を優先して練習するほうが、覚えやすいかもしれません*2

 


 以下の練習手順には【人中薬子】という文字が出てきます……が、この文字が出ているところでは「練習する側の手×ホームポジション」の該当キーを「叩くフリ」*3をしてください。

 叩くフリをするときには、決して「叩くフリをするキーに割り当てられているカナを想起」したり、「叩くフリをするときに使う指の名前を黙読」したりしないでください。


(飛鳥21c344準拠)右手が器用に動く方は、こちらから先に練習してください。

  • 右手の練習
    • アンシフトの練習
      • ホーム段
        • 【 人ん 中ん 薬ん 子ん 】
        • 【 人い 中い 薬い 子い 】
        • 【 人か 中か 薬か 子か 】
        • 【 人た 中た 薬た 子た 】
        • いたい・かいたい・たいかい・かいか・かいかい・かいかん・かんたん
      • 上段
        • 【 人」 中」 薬」 子」 】
        • 【 人と 中と 薬と 子と 】
        • 【 人は 中は 薬は 子は 】
        • 【 人ぶ 中ぶ 薬ぶ 子ぶ 】
        • とかい・はかい・ぶかい・とたん・はたん・ぶたん・はいかい・ぶんたい
      • 下段
        • 【 人っ 中っ 薬っ 子っ 】
        • 【 人ょ 中ょ 薬ょ 子ょ 】
        • 【 人ゅ 中ゅ 薬ゅ 子ゅ 】
        • 【 人め 中め 薬め 子め 】
      • 人差し指伸領域
        • 【 人) 中) 薬) 子) 】
        • 【 人ゆ 中ゆ 薬ゆ 子ゆ 】
        • 【 人ゃ 中ゃ 薬ゃ 子ゃ 】
      • 小指伸領域
        • 【 人へ 中へ 薬へ 子へ 】
        • 【 人ほ 中ほ 薬ほ 子ほ 】
    • 片手シフトの練習
      • ホーム段
        • 【 人く 中く 薬く 子く 】
        • 【 人の 中の 薬の 子の 】
        • 【 人つ 中つ 薬つ 子つ 】
        • 【 人さ 中さ 薬さ 子さ 】
      • 上段
        • 【 人〜 中〜 薬〜 子〜 】
        • 【 人そ 中そ 薬そ 子そ 】
        • 【 人こ 中こ 薬こ 子こ 】
        • 【 人ぞ 中ぞ 薬ぞ 子ぞ 】
      • 下段
        • 【 人を 中を 薬を 子を 】
        • 【 人ど 中ど 薬ど 子ど 】
        • 【 人も 中も 薬も 子も 】
        • 【 人ぼ 中ぼ 薬ぼ 子ぼ 】
      • 人差し指伸領域
        • 【 人ぢ 中ぢ 薬ぢ 子ぢ 】
        • 【 人づ 中づ 薬づ 子づ 】
        • 【 人む 中む 薬む 子む 】
      • 小指伸領域
        • 【 人ご 中ご 薬ご 子ご 】
        • 【 人ろ 中ろ 薬ろ 子ろ 】
    • 両手シフトの練習
      • ホーム段
        • 【 人る 中る 薬る 子る 】
        • 【 人す 中す 薬す 子す 】
        • 【 人が 中が 薬が 子が 】
        • 【 人ま 中ま 薬ま 子ま 】
      • 上段
        • 【 人ぇ 中ぇ 薬ぇ 子ぇ 】
        • 【 人よ 中よ 薬よ 子よ 】
        • 【 人ふ 中ふ 薬ふ 子ふ 】
        • 【 人! 中! 薬! 子! 】
      • 下段
        • 【 人で 中で 薬で 子で 】
        • 【 人、 中、 薬、 子、 】
        • 【 人。 中。 薬。 子。 】
        • 【 人? 中? 薬? 子? 】
      • 人差し指伸領域
        • 【 人ヴ 中ヴ 薬ヴ 子ヴ 】
        • 【 人ず 中ず 薬ず 子ず 】
        • 【 人や 中や 薬や 子や 】
      • 小指伸領域
        • 【 人ぃ 中ぃ 薬ぃ 子ぃ 】
        • 【 人げ 中げ 薬げ 子げ 】

(飛鳥21c344準拠)左手が器用に動く方は、こちらから先に練習してください。

  • 左手の練習
    • アンシフトの練習
      • ホーム段
        • 【 人て 中て 薬て 子て 】
        • 【 人う 中う 薬う 子う 】
        • 【 人し 中し 薬し 子し 】
        • 【 人き 中き 薬き 子き 】
      • 上段
        • 【 人「 中「 薬「 子「 】
        • 【 人じ 中じ 薬じ 子じ 】
        • 【 人け 中け 薬け 子け 】
        • 【 人ぴ 中ぴ 薬ぴ 子ぴ 】
      • 下段
        • 【 人ー 中ー 薬ー 子ー 】
        • 【 人に 中に 薬に 子に 】
        • 【 人み 中み 薬み 子み 】
        • 【 人ば 中ば 薬ば 子ば 】
      • 人差し指伸領域
        • 【 人( 中( 薬( 子( 】
        • 【 人ぎ 中ぎ 薬ぎ 子ぎ 】
        • 【 人・ 中・ 薬・ 子・ 】
    • 片手シフトの練習
      • ホーム段
        • 【 人り 中り 薬り 子り 】
        • 【 人あ 中あ 薬あ 子あ 】
        • 【 人ち 中ち 薬ち 子ち 】
        • 【 人だ 中だ 薬だ 子だ 】
      • 上段
        • 【 人ぁ 中ぁ 薬ぁ 子ぁ 】
        • 【 人え 中え 薬え 子え 】
        • 【 人ね 中ね 薬ね 子ね 】
        • 【 人ざ 中ざ 薬ざ 子ざ 】
      • 下段
        • 【 人び 中び 薬び 子び 】
        • 【 人せ 中せ 薬せ 子せ 】
        • 【 人ひ 中ひ 薬ひ 子ひ 】
        • 【 人ぜ 中ぜ 薬ぜ 子ぜ 】
      • 人差し指伸領域
        • 【 人ぅ 中ぅ 薬ぅ 子ぅ 】
        • 【 人ぉ 中ぉ 薬ぉ 子ぉ 】
        • 【 人& 中& 薬& 子& 】
    • 両手シフトの練習
      • ホーム段
        • 【 人ら 中ら 薬ら 子ら 】
        • 【 人な 中な 薬な 子な 】
        • 【 人お 中お 薬お 子お 】
        • 【 人わ 中わ 薬わ 子わ 】
      • 上段
        • 【 人% 中% 薬% 子% 】
        • 【 人れ 中れ 薬れ 子れ 】
        • 【 人べ 中べ 薬べ 子べ 】
        • 【 人ぺ 中ぺ 薬ぺ 子ぺ 】
      • 下段
        • 【 人ぐ 中ぐ 薬ぐ 子ぐ 】
        • 【 人ぱ 中ぱ 薬ぱ 子ぱ 】
        • 【 人ぽ 中ぽ 薬ぽ 子ぽ 】
        • 【 人ぷ 中ぷ 薬ぷ 子ぷ 】
      • 人差し指伸領域
        • 【 人─ 中─ 薬─ 子─ 】
        • 【 人ぬ 中ぬ 薬ぬ 子ぬ 】
        • 【 人* 中* 薬* 子* 】

 ……間違いがあるかもしれませんので、何かご意見がありましたらコメントいただけると助かります。


2007年4月8日17:30:14追記。

 この練習法は、「一番器用な指は人差し指」で、「一番強い指は中指」という想定で設計しています。

 そのほか、「一打鍵目は押しちゃダメ・想起してもダメ」「必ず動かしやすいほうの手から練習する」「全キー練習はしない」というルールも採用していまして、色々な意味増田式とは異なった方針を取っています。

 そのため、このテキストを「無料増田式」だとおもって使うと期待した効果は得られませんので、「増田式」を試したい方は、必ず本を買ってから試してください。


以下注釈。

*1親指シフト系配列での連続シフトは「ズボラの結果・応用技術の一つ」なので、基本をきちんと押さえておけば「自然と使えるようになる」はずですし。

*2親指シフトの設計時点で、神田さんは「片手シフトはアンシフトと同じ感覚で打てる(片手操作なのでタイミングを取りやすい?)」ということを発見されたようです。そのため、今回のシフト練習については「片手シフトを先、両手シフトを後」としました……ので、片手シフトの練習をする場合は「二つのキーをそれぞれの指先の力で叩く」のではなく、【二つのキーを叩けるように指先を形作り、その状態から手のひらごと押し下げる】ようにしてください。

*3:ここで「(練習中に無意味な)キーを実際に叩く」と、かえって習得しづらくなるのではないか……と、私はそう感じています。可能な限り練習手順をコンパクトにしたい&不要と思われる動作はミリ単位で削りたいので、ここは増田さんとは違う方針で行こうかな、と。それと、飛鳥の配列は「ホームポジションとの関係さえ習得できればよい構造になっている」ので、増田式にあるような完全キー練習が最適かどうかは、私にはよく解らないのです。

2007年03月06日 火曜日

2シフトによる「親指シフトDvorak」配列……?。

(参考:メモ。@2007年03月05日)

 単なるメモ

前提。

  • 「48鍵×2シフト=96状態」を「32鍵×3シフト=96状態」へと置き換える。
    • 「4段配列よりは3段配列のほうが入力誤りが少ない」「同習得しやすい」が真かどうかを検証……できるだろうか。
  • この方式にとって最適な英字配列が何であるかは不明。
  • シフト方式には、とりあえず2親指による同時連続シフト(または普通シフト)を使う。
  • 「?」には、記号類を詰める。

シフト

AOEUIDHTNS-^
aoeuidhtns-^
1234567890?

シフト

;QJKXBMWVZ_?
;qjkxbmwvz_?
???????????

シフト

:,.PYFGCRL/@
:,.pyfgcrl/@
???????????

2007年03月05日 月曜日

メモ。

 ケータイで体感できる?こと。

  • 親指は結構器用、頻度と力の掛け方さえ気をつければ、かなり使える。
  • 英字配列がサイトメソッド・かな配列はタッチメソッドでも問題なくイケることを知っている。

 五十音練習、行ごとではなく段ごとの場合。

 あ段、い段、え段……○い○ん。

 う段、お段……○う○ん。

 ……こんなの役には立たないかも……。


 飛鳥理論関数集合に変換できそうな気がした……のだけれど、忙しすぎて失念してしまったorz

 ただ、最近Rayさんが「カナ位置の先祖がえり」を何度も試行されているだけに、過去スレッドblogを見渡せばヒントは見つかる……のかもしれない。

 とりあえず思い浮かんだものをメモ

  • 90個弱のカナが空間に浮かんでいる。
    • 2字連接の頻度に応じた太さの糸で、カナ同士が結ばれている(脳神経の絡み具合と似たような感じ)。
  • 糸が絡み過ぎないように左右に分かれている。
  • 糸の絡み具合がひどいカナが、ホームポジション(ASDFJKL;)か、もしくは「ホームポジションに3本の指を置いたまま、残りの1本の指のみでチョイ打ちできる場所」に来ている。

 後はすっかりと忘れてしまったので、とりあえずこの件は放置

2007年03月04日 日曜日

メモ。

http://blogs.itmedia.co.jp/akihito/2007/03/post_c0f3.html?ref=rssall

 JISX4063(1.7x打鍵系)のせいで(?)「パソコン入力環境ダメダメケータイで十分じゃん」だと思われているかもしれない(「Kodame」や「かえで携帯配列・改造版」レベルの1.8x打鍵系配列がケータイで常用されれば、その動きは決定的になると思う)現状は何とかしたいのですが、JISX4063を「気に入って使っている人に対していやな思いはさせたくない」というところもまた真なのであって……。

 うーん……背反条件……なのだろうか。なにかうまい突破口はありそうな気がするのですが、実際のキーワードも道筋も全く見えてこないのが悩みどころでして。


やさしいC++〈Part2〉クラスとオブジェクト指向 (I・O BOOKS)

やさしいC++〈Part2〉クラスとオブジェクト指向 (I・O BOOKS)

 これらの本が、帯に書かれている売り文句そのものの……つまり「C++関連書籍を理解するための本」だとされている理由が、ようやくわかりました。

独習C

独習C

 まだp.31までしか読んでいないのですが、「入門分野すら知らない状態で読んでも理解できない」「最初のステップを越えてから読むと、ものすごく丁寧に解説してある本多本だということに始めて気づく」ことは確実なようです。

 ……うーん、さすがにこの3冊を一緒にまとめた書籍は作れないな……と、そう思いました。

 とはいえ、大人買いは無駄じゃなかったのかもしれず。

 それにしても、Web書店系の書評はあれでも結構役立ちますね……「ある1冊の書籍についての厳しい意見が、別の複数の書籍を購入するための動機になる」とは思ってもいませんでしたし、しかも実際に「自分にとって合いそうな書籍を選ぶ参考になる」のですから。

 ロングテール「だけ」で商売になるわけではなくて、ロングテール「が」ヘッドの売り上げに良い影響をもたらす……と。

飛鳥カナ配列の「ー」。

日記頻度(半手動、http://d.hatena.ne.jp/maple_magician/20051108/1131442718)。

日記頻度(自動http://d.hatena.ne.jp/maple_magician/20050521/1116697514)。

連接傾向(雑記内、http://www.eurus.dti.ne.jp/~yfi/keylayout/kana_continuity_list.html)

ターゲットの前に連接しやすい文字ターゲットの後に連接しやすい文字
(遠い←)やんごじぜぁっひむよげあだぶょにえゃいせふぱがなずはらまさぃねちでけべどてそるつぽかしぉぴぇおざりとほわたこのゅもればめうぺぼゆろき(→近い)(近い←)どまとぼるをすじはかんのむがにさたこぷくふざしばでずだなら」わおっちぶきもそいひ、てゆり。よめへうせぱねつびやあほけろみぜ「げえれ・ご?ぐべ(→遠い)
(遠い←)ぱばのもょどただねはひふそじがなざかこて。きつにさら、「いでくまめうごわーん(→近い)(近い←)いーんっわつすませしるとのをはだなにらざけじでさたがり」ばへちやぶかめぱえ(→遠い)
(遠い←)?わそやぐぷさえゅざ!ゃれほばょぺむずあけびぶりぎすらだどろふめかちみでてじ」しつごがるこ「たぽとにをひ。のー、きくなはいまもうん(→近い)(近い←)ょゅにしだかつできっめをゃたてんぶがのろはさなこどまおす。と」るじけくばゆもいりひへ「ちれふらみずあむぇうぴ、やよげほごえびわぐねそづぎざせぢぼぷー(→遠い)
(遠い←)ぷ、ゅゃもの。りはにび「じぱすんっこい(→近い)(近い←)んーっゅょすぺぷくゃみね」で(→遠い)
(遠い←)ぱくえむにとてべう。」「たつ、ぴいんきっぷるのす(→近い)(近い←)ーじんるぽでいすぢばり(→遠い)
(遠い←)ねろづよげょほめぃせゆーべぎち」やごぐをばむでふぶびりにも。えゃじたがるれみつ、て「はまゅぞぷずどんうのとだけかきあなくわすおらしそさこい(→近い)(近い←)つてばるんまいはなたでにがをかーっらすものびとだしぞず。、どこきれく」べよそほぐぽちさじろわふりぬやげあえ?ぼぜせう!おひ(→遠い)

飛鳥21c290

 
_ 
BS
ECBS
  _
 

飛鳥21c290+wv("ぶ" and "ー" are exchanged)

 
_ 
BS
ECBS
  _
 

飛鳥21c343

 
_ 
BS
ECBS
  _
 

「ー」雑感。

  • 手の形としては結構いい感じ。人差し指以外との連接を構成する場合に、無理な形とならない。小指・薬指・中指を全てホームに置いたままでも打てるので、普通打鍵していてもホームからずれる量が少なく済む。
  • そもそも21c290では、上段〜中段に「ー」が絡むカナが多かったので、配列と「ー」の位置関係はうまくマッチしている……実際、入れ替え実験は数十分で停止する羽目に。
  • 21c343は「Qぴざぺ」「Eじれ」を除けば中段〜下段に「ー」が絡むカナが多いから、この変更は妥当……かもしれないけど、「EV」「VE」「QV」「VQ」が打ちやすいかどうかは謎。
    • とはいえ、他に置ける場所はなさそうだし……「Z」は頻度的&「Qぴざぺ」との絡みで無理、「X」は小指×薬指が連動して動いてしまうので無理、「C」は指が長い分だけ余計に「V」よりも移動量が増えるから無理、「B」は遠すぎ、「G」は中指を連れて行ってしまうから無理……って、全部「W」「V」より悪手になってしまうorz
  • 「ー」は特定かなとの極端な連接を伴って高密度で使用される(使うときと使わないときの差が激しい)ので、これを「Fてりら」を抱える人差し指に頼っても大丈夫なのだろうか……という不安が。
  • 21c343の配列そのものが、上段に「ー」を置いたままにすることを難しくしている予感も。かといって、あまり「ー」にこだわり過ぎると「かなの大移動」が必要になってしまうし……。
  • 「Vー」を実用的に使おうとすると、「Qぴざぺ」には救済措置が必要かな……と、使ってもいないのに余計なことを書いてみるテスト。
    • これらのかなは「Wー」に依存して配置されている(これはすでに、21c290の時点で綺麗に表現されている)はずなので、「Wー」が「Vー」に移動したのであれば、必然的に移動する必要が出てくる……と。
    • とはいえ、「Eじれ」はどうにもならないだろうなぁ……と。厄介なことに、後置の「れー」と前置の「ーじ」は、相対的に「ー」と近い連接頻度を持っているらしく。
    • しかも、「ー」のために動かすと色々と面倒な問題が後から出てくるわけで……むむむ。

もちろんパソコンにも未来はありますからッ!

(言及:ケータイが標準になる日)

(過去:メモ。@2007年03月04日)

(過去:「生産革新」「事務革新」では、どれぐらい「まっさら」にしなければならないのか。)

(過去:文章の長さは「記述窓が長文推敲に向いていない」せいで短くなった?)

(目標:伽藍とバザール)


 興味深い記事だったもので言及させていただきたく。

 ただし、ほとんど独り言のような状況ですが……。


 携帯電話のひらがな入力法には進化の余地がありまして、パソコンで一般的な【JISX4063準拠のQwertyローマ字入力】とほぼ同等の入力効率を「ローマ字入力ベース」「かな入力ベース」のどちらでも実現できます。

http://d.hatena.ne.jp/maple_magician/20070211/1171129111

http://d.hatena.ne.jp/maple_magician/20070209/1170992260

 前者はソフトウェアの開発を予定しているそうで、後者W-ZERO3[es]+ctrlswapminiをつかえば実現できます。


 個人的には入力効率よりも打ちやすさを優先したいので、以下の方法を実際に使っています。

http://d.hatena.ne.jp/maple_magician/20070102/1167705361

 これもW-ZERO3[es]+ctrlswapminiで実現できます。

 いま、W-ZERO3[es]についているQwertyキーボードは「溜まったホコリを掃除するために引き出す」ばかりでして、「使うためにキーボードを出す」ことはほとんどありません……。


 ケータイで標準的な「かなめくり入力」は「打つ回数が少し多い」という問題はあるものの、「覚えやすくタッチタイプしやすい」というメリットがあるので、これが受け入れられるのは当然だろうな……という気がしています。

 http://slashdot.jp/~yasuoka/journal/308687

 ローマ字入力自体が「多くの機械で使えるから」「英字入力技術を共用できるから」という理由で四半世紀前に選択されたらしいことは記憶にそう遠くないのですが、このままいくとケータイに押されて消えてしまう可能性もありますね……。


 パソコンキーボードを使って「よりも楽に」入力する方法については、今でも色々と試行錯誤が続いている状況です。

 http://www4.atwiki.jp/japanese_keyboard_layout/

D

 かつては「論文を書いて発表する」「金銭を投入して製品化する」以外に方法がなかったことと比べて、最近では「掲示板Blogで公開する」「ソフトウェアを使って容易に実現できる」例が多く、開発速度がとんでもなく速くなっている&様々なフィードバックを元に改善が進んでいる……というのが、近年の入力法開発における特徴だと思います。


 近年製作が開始されたものを中心として、まだ広く一般に使っていただける状況にはなっていない(導入用ドキュメント整備の遅れ・練習方法ドキュメント整備の遅れ・開発途中のため現状提供ベースのものが多い)という問題は抱えていますが、このあたりは徐々に解消して行きたいと考えています。


 パソコンの文字入力関連に絡む「事務革新」は四半世紀前から止まったままの状況となっている気がするのですが、ここは実際何とかしなければならないと考えています。

 いまのところ、安全(VDT障害を低減する入力方法)・品質(ストレスに起因するミスが少ない入力方法)・生産性(高速に入力できる方法)の全てを「利用者全員に対して」満足に提供するには、「一つや二つの入力方法を提供するだけでは全く足りない」可能性があるように思います。

 手指のサイズ・運動特性・思考特性が人によって異なるため、文字入力法はそれこそ「服・靴・机・椅子を選ぶのと同じように」多彩なバリエーションを伴って提供できる必要がありそうです。

 ケータイに対するパソコンキーボードメリットは「10本の指でタイピングできる」ことに集約されそうですので、それを徹底的に生かせる入力方法を色々と提案していけるようにしたいところです。


 最後に。

 まるでコンサルティングの役にはたたないであろうトラックバックをしてしまいまして、その点申し訳ありません……。

2007年03月03日 土曜日

メモ。

 今日は……微妙にしくじって指が痛いので、短信のみ。

飛鳥21c290

 
_ 
BS
ECBS
  _
 

飛鳥21c343

 
_ 
BS
ECBS
  _
 

連接傾向(雑記内、http://www.eurus.dti.ne.jp/~yfi/keylayout/kana_continuity_list.html)

ターゲットの前に連接しやすい文字ターゲットの後に連接しやすい文字
(遠い←)ぱっげざぶ・べふひょをぷむめごもやでゃぎそがばぐえまだこわ。けはびせあ「ずみにろるね、らじてかどりしーくつされ」たのなちきいとうすん(→近い)(近い←)、いあつなえしでおわかっすよ。きらく…たこうは「とひちにもみまじさふどげりそめだてほのせをぞるゆへけれんがやばぎー」べむねびごずぶぼぬ・ろぜざぽ2i【↓ぐ!ぱ(→遠い)
(遠い←)ぴおぇべぼっゃねぺふ?ざづ!ぜそゅひをげぶあぐ・ほせむごょやだばぷでゆぎなさわて「びーこめたもらはろに、ちどるすしみずりかきえ。」れじつくがとけまういんの(→近い)(近い←)すは、きしもあのに。いん「かおだてなうた…こつさぃひとよるまく」じそーみふせめほどけでちわやをろむごがぶびれへざぎばねげゆえっらずぜりぱ【べ!ぷ○・ぽ→ぐ(→遠い)
(遠い←)!べぽづぬぱぐわひぼげぞびそむ?・ば」よごふめざねおろぎどずゃせちらけすかでじだもあ「えながつをにるんやくうさてたこ。はみのと、まれきーりしい(→近い)(近い←)すしせじっでずまいえうだたちとりにさんくるのぁつわかなゆはれどあらよーもが」ねこざけ。、きおぜをみやへぬてぎづむほふ【ごげばろぱそ(→遠い)

単字出現頻度(雑記内、下二桁を落とした)

240187173157154148120113107103102979695948781807672

雑感(一部の打鍵テストのみ、評価打鍵はまだ)。

  • 今までの「です。」は【ホームポジションに指をおいたまま、小指だけ後から薬指だけを*1下段に伸ばして打つ】感じだった……けれど、今回の「です。」は【手のひら自体を一段下げて、その状態からJILと打つ】感じ。単独で練習してみる限りは打ちやすいのだけれど、文章内で突然出てきた場合にどうなるか……は微妙。もっとも、文末で使うのだから「ホームポジションから手がずれても大丈夫」ともいえるけど、「です。」を打つたびにずれるというのは……慣れてみないとイケるかどうかが分からない。腕を動かす代わりに指の負担を減らした、という感じ?
  • 慣れていないせいかどうかは不明ながら、「ですが/、」には違和感が……「ですが」まで低コストのままで打ててしまうというのは、どうかなぁ……という気も。もっともこれは、従来法の「です/が、」に慣れすぎているのが原因だと思うので、新たに使う人にとってどうかは不明(……いや、たぶんよい方の評価がでると思う)。
  • JISでは「L」=「か」で、「SL」=「が」です……そのイメージが強く残っているためか、飛鳥の「L」=「か」で、「左L」=「が」というのは、ある意味「(他のかなとの連接を考慮しない限りは)すでに実績がある」のかも。
  • 人差し指悲鳴を上げなければ、これを採用する方が快適さが増すような予感がする。

「生産革新」「事務革新」では、どれぐらい「まっさら」にしなければならないのか。

(参考:2007年03月01日)

【注意】

 この文章は、Web上で拾える文章を読みつつ「テキトーにでっち上げた」ような状況です。

 私自身は革新活動を行うための専業会社に勤めているとか言うわけではありませんので、眉につばをつけてからお読み頂くことをおすすめします……。


 生産革新を行う上では、その行為自体が「改善(たとえば自動化とか、あるいはコンパクト化とか)」とは【全く異なる事をするのだ】という意識を強く持って、根本から・些細な事から見直していく事が重要です。

 ……もちろん、「重要」ではあっても「必須」ではないのですが、手を広げれば広げるほどにいろいろな発見をすることができるはずです。

 逆に「革新」は、後の「改善」をするための重要な基礎となる(改善レベルではできないような、初期に広く伝染してしまう事項について取り扱う)部分に絞って取り扱うようにする事も必要です。


 たとえば、富士通が作った「日本語電子タイプライタOASYS」は、初期の製品に関しては「改善」プロセスをほとんど含まない、純粋な「革新」プロジェクトだったと見なすことができそうです。

 あるいは、Rayさんが制作されている「飛鳥カナ配列」では、【継承OASYS親指シフトというシステム】【革新シフト方式と基礎配列】【改善=基礎配列の文字入れ替え】という3つのプロセスを経ていると見なすことができそうです。

 日本語入力法は、その多くが「継承革新改善」のうちいくつかのプロセスを経ています。この分野についての試行錯誤の様子を見渡すことにより、それらのプロセスを把握し、自分でやってみることにより、自業務への「考え方の展開」を図る事ができるかもしれません……。

 ゆえに「いちど自身が使用する【文字入力法】の変更を検討してみませんか?」と、そういう提案をしてみたくなるわけです。

 ……が、今日の本題はそこではなくて。

うまい説明方法が思いつかなかったので、とりあえず画像で掲示できる一例を。

f:id:maple_magician:20070303163031p:image

 いわゆる「改善プロセスの一つとして、古くから「事務処理の機械化・OA化」が進んできました。

 これにより日本人は「読みやすい文字」と「手書きよりは書きやすい環境」を得ることができました……それが上の状態。

 ところが、この時点で一つ、とても大きな事を見落としてしまっています。それは【手書き時代ではフォーマット(活字体)とデータ(手書き体)を容易に区別できたが、OA化により両方が活字になってしまい、視認性が劣化した】というところにあります。


 そこで、下のような「文字の大きさとフォントを変える」という事をやって「改善」しようとします……が、これを「改善」のレベルでやろうとすると失敗する可能性があります。

 「改善」では必ずしも作業手順が簡易的になるとは限りませんし、統一的に手法を使うという共通認識が生まれるとも限りません。

 そもそもこの方法、ワープロ専用機が「明朝体ゴシック体をあつかえるようになった」あたりから存在する、とてもオーソドックスな方法なのですが……Webショップ系から回ってくる納品書のたぐいですらも行われていないぐらいにマイナーな方法です。

 ……もしかすると、それ故に「コンピュータ出力の文字は見やすいが、コンピュータ出力の帳票は項目も読まないと理解しづらい」と誤解されているのかもしれません。


 そこで、「革新」の一つとして、「フォーマットデータで使うフォントと文字の大きさの比率を決める=手書き時代と同等の視認性を持つ文章作りを目指す」という事を検討してみることをおすすめしたいと思います。

 もちろん、実践するかどうかは個々の判断にゆだねられるわけですが、こういう単純なテーマは「誰にでも検討するべきレベルが理解できる」ので、部門内に存在するほかの「革新の対象とするべきもの」を見つけ出すための教材として使えるはずです。

 #影響範囲がえらく広いテーマほど、「1から組み立て直す」ために向いている……ということで。


 ちなみに、この手のテーマを扱う場合には、こういう方の意見が案外重要だったりします。

  • 入社したてで、まだ右も左も分からない……社内の常識に縛られていないので、「改善」ではなく「革新」に直結するアイデアをひらめきやすい。
  • もうそろそろ退職で、「昔はよかった」が口癖の方……いまのOA化によって「ダメになった部分」をしっかり体感しているだけに、「改善」ではなく「革新」に直結するアイデアを山ほど持っている可能性がある。

 たとえば、入社したての方を指して「あいつはまだ業務のことを知らないからダメだ」とか言ってみたり、退職寸前の方を指して「あの人はもう頭が固いからダメだ」とか言っているような方は、特に注意。

 あなたの「常識」は「改善」のためには役立つかもしれませんが「革新」のためには役に立たないかもしれません。

 頭から否定してしまっては、話は始まらないのです。こういう場合は上記のような方の意見から「革新の種」を拾ってきて、それを「革新の力」へと変えるための努力を惜しまないことが基本といえるでしょう。


冒頭で「日本語入力法」を持ち出した理由。

 パソコンを使った「日本語入力法」は、もともと「手順の固まり」です。

 日常業務で「手順の固まり」を直すとなると、自分一人だけでその影響が収まらず、他の方を巻き込んでいろいろとやる必要が出てくる場合が多いと思われます。

 一方で、「自分が使うパソコンの中での手順だけを変える」日本語入力法の変更という行為には、つぎの特徴があります。

  • (自宅のPCを利用する場合は特に)他の方を巻き込まなくとも「手順の変更」ができる。
  • とにかくいろいろな方法が提案されている。そして、それぞれの入力法が【継承革新改善】の関係で複雑に絡みあっている。
  • 入力速度を「速くする」効果はあまりない(それは入力方法ではなく練習次第)が、入力作業を「楽にする」(速くするための伸びしろを確保することができる)効果がある。
    • 「回りくどい手順を取ろうが、簡便な手順を取ろうが、完成した成果物品質が安定していればどちらでもかまわない」ということと、「同じ品質成果物を得るためには、なるべく簡便な手順を取る方がよい」ということを、他者に影響を与えることなく確実に体感できる。
  • 未だに根絶への道筋すらたっていない「VDT障害」に対して、ある程度の明確な成果を提示できる可能性がある(たとえば、今提案されている方法の多くは、ローマ字入力に対して2/3程度の操作で日本語入力が可能である)。
    • (特に近年設計された日本語入力法は)制作者が長い期間をかけて「自分自身が入力法を使いまくって、なるべく楽に操作できる方法を追求する」例が多い。
  • (これは改善の分野になるのですが)それぞれの入力方法には「入力法を習得するためのコスト」がかかるが、それが「見た目の難しさと一対一で関係するとは限らない」ことを体感できる可能性がある。
    • これは「大量の文章を打った時に使いやすい入力法は、少ない練習量でも覚えやすい」可能性がありそう。作業手順領域で喩えれば「作業手順書がシンプルコンパクト」よりも「作業動作がシンプルコンパクト」であるほうが、実践する上では都合がよい……ということと等価かもしれない。
      • 私はたまたま「飛鳥カナ配列」という方法を選んだのですが、飛鳥の見た目がえらく難しそうだった割には「JISかな入力(ぬふあうえお……の配列)」や「Qwertyローマ字入力」よりも【習得開始から1年後の習熟度】が高かった様に思います。しかも、飛鳥は当時開発中で「入力規則の変更に関するアナウンスが連発していた」ために「必要に応じてアナウンスに準ずる練習をし直していた」中での話でして……。
    • 「一つの手順ですべての人に対応する」だけではなく「人に応じて手順を変更してでも、最終的な成果物品質を安定させることを優先する」という考え方が納得できるようになるかもしれない。
      • 人間の運動特性は必ずしも画一的ではないので、一つの手順&一つの作業環境に縛り付けて「作業安全」と「品質安全」を保証しようとすると、「作業安全」と「品質安全」のどちらかに無理がくるか、あるいは全体的なパフォーマンス最適化できないおそれがある。作業内容によっては「最終的な成果物品質保証できる範囲で手順&環境をいくつか用意し、作業者の特性に応じた手順&環境を適用する」という方法が有効であることを実証できるかもしれない。
        • 特に「セル生産」がこの方針を採用しやすい。体格差を考慮した作業台のサイズ変更などでは、すでに応用されているはず。

 ……と、日本語入力法に首をつっこむと「生産革新」や「事務革新」で役立つかもしれない視点を得ることができるはずだと思われます。

 仮に興味があるようでしたら、いろいろとお試しいただければ幸いです。

*1:2007年3月6日1:01:33追記訂正。

2007年03月02日 金曜日

メモ。

 http://www.kanshin.com/keyword/1104353

 M式五十音ソフト(50音順ローマ字入力)

 中身はいつもどおり、代わり映えしないんですよね……orz

2007年03月01日 木曜日

メモ。

 生産革新日本語入力に生かした「飛鳥カナ配列」……って、これをキーワードに使うとなると「生産革新とは何か」をぶっちゃけて説明しなきゃいけないですね……うーん。いちおう「革(=大きく変える)」「新(=まっさらな状態に戻してから再構築する)」の条件は満たしている気もするのだけれど、ホントかどうかは定かではないし。


 http://store.yahoo.co.jp/d-tech/kkbox98.html

 新井さんとこの新作、NICOLAを正式にサポートする商用エミュレータ(50音ソフトV3)とスクエア物理配列のキーボードのセット。

 うまいこと考えるなぁ……この方向性には期待したい。


 シャドールームさん経由。

 あえて、「ゆっくり」「手際よく」、それが実は効率化の道。 - トラパパ@TORAPAPA [ITmedia オルタナティブ・ブログ]

 なるほど納得、コメント済み。


 asahi.com:5年後の生産性、5割増に 経済財政諮問会議の数値目標

 「今から5年後の生産性を、現在比5割り増しに……」という話ではなくて、「一年ごとの生産性「伸び率」を、現状の1.016倍から1.024倍へと引き上げよう……」という話。

 大型設備投資減税よりも、事務系まで共通して使える「小型電化機器」投資減税(極端な話、電動テープカッターなどを含む)が大きな効果を生むかもしれない。

 「怪我をする危険性があり、失敗する可能性が高く、かつ遅いもの」を「怪我の危険性が少なく、失敗する可能性が低く、かつ速いもの」へと交換することにより、手順圧縮を行ううえで重要な「注意力極小化*1」を手助けできるので、これは「作業者自身が行う手順最適化」に良い影響を与えます。

 労働生産性伸び率、5年で1・5倍に…諮問会議が目標 : 経済ニュース : 経済・マネー : YOMIURI ONLINE(読売新聞)

 首相希望は「(5年で、伸び率ではなく)生産性倍増」って……逆算すると「毎年1.15倍」になるような。

 事務系職種については、作業能率改善VDT障害回避の両立に向けて「キー入力入れ替えソフト」のJIS規格化をする……ってゆーのは、割と現実的な解になりそうな気はする。というか、「手順は変えるためにある(破るためにあるのではない)」「シンプルコンパクトな手順ほど高速化に適する」という前提を無視しなければ、これを忌避する理由はあまりないような。

「キー入力入れ替えソフト」のJIS規格化を目指して。

(未来:(メモ)「キー入力入れ替えソフト」のJIS規格案として、どういう配列定義用フォーマットがあればよいのだろうか……。)

(過去:とりあえず親指シフト「エミュレータ」と親指シフト「ソフトウエアロジック」だけをJIS化してみよう!)


 飛鳥の版が早速上がってしまって「えーっ」という感じだった……ということは置いておくとして。


 ふと一歩引いて考え直してみると、飛鳥の配列が確定するか否かに関わらず「色々な入力法が存在する&今後もさらに色々な入力法が提案される可能性がある」ことを考慮すると、結局のところは「色々な入力方法を実装できるフレームワークが必要」というところに落ち着きそうだな……と。


 ……で、実現するかどうかという段階はおいておくとして、ひとまず「どういう形でJIS化できる可能性があるだろうか」ということについて考えてみました。

 純粋技術的な側面(これは私が言及するべきかどうかがよく解らない)よりも、【いかにメリットを享受する利用者数を多く取るか】【いかに多くの著名な協力者を得られるか】にフォーカスをあててみました。


実装方法について。

パターン1、とりあえず親指シフト「エミュレータ」と親指シフト「ソフトウエアロジック」だけをJIS化してみよう!による方法。

 ……親指シフトにしか適用できないところが微妙。

 頼る先が日本語入力コンソーシアムしかないのだけれど、今まで利用者から散々「日本語入力コンソーシアムは普及への努力をしていない!」とかいう声ばかりを聞いてきた気もするので、ちょっと微妙かな……と。


パターン2、姫踊子草のようなシステムインターフェース(MMI)のみを定義する方法。

 ……この方法であれば、ソフトウェアベース入力法は一通り実装できそう。

 #ただし、日本工業規格制定・改正案の工業所有権の扱いに係る声明書(Word 23kb)に署名されるかどうかは、それぞれの入力法設計者に任されますけど……配列を単独でJIS化するのが事実上困難である以上、何とかなりそうな気はします。


 ここで、考える道具―ワープロの創造と挑戦を読了、なんとなく感想を。で引き合いに出した考える道具―ワープロの創造と挑戦で、森さんによる以下のコメント(注:意訳)をもう一度持ち出してみます。

 JISの委員会に「けん盤配列製作者」を二人以上入れると、何時まで経っても意見はかみ合わない*2

 鍵盤製作者を排除した「日本語入力用鍵盤についてトコトン考える」ような委員会が必要で、それがなければ誰も決定結果を信用しないはず。

 実は元の文章、「けん盤配列製作者」を二人以上〜などという書き方ではなく、具体的にこういう方の名前が挙がっています。

 ……で、ここに上げられた方々が「俺が、俺が……」と言い出しては絶対に決まらない!*4から、製作者を入れるべきじゃない……という話に至っていたわけです。

 ところが以前に書いたとおり、これは【人間物理けん盤との接点を決めようとするからモメる】のであって、【物理けん盤とシステムとの接点を決めようとすれば、全員の意見を含めたエミュレータができる】ことになり、結果として「みんなが幸せになれる」可能性を秘めていると、私はそう考えています。


JISの規格へと乗せる場所について。

パターン1、けん盤規格として「新JISキーボード規格(要するにJISX6004の後継)」を作る。

 ……これははじめから論外。

 第三入力方法たるNICOLAユーザが増えては居ないらしい*5し、第四入力法以下は統計すら出ないだろうし……いずれにせよ「けん盤配列」としての規格化は現実的ではない、と。


パターン2、JIS X 4064:2002「仮名漢字変換システムの基本機能」のアップ・トゥ・デート時に追加で「キー入力入れ替えソフト」のJIS規格版をぶち込む。

パターン3、新規で「キー入力入れ替えソフト」のJIS規格化を行う。

 ……「結束すれば実現可能」かも知れない。

 色々な入力法をサポートして「規格制定によってメリットを享受する人」が多ければ多いほど、規格の実現性は高まる……と、ここがポイント

 規格部分は「英字配列テーブルの書記法」「かな漢字配列テーブルの書式法」「配列テーブルの解釈方法」「同期シフト法(NICOLAなど)・同時連続シフト法(飛鳥など)・連続シフト法(TRONなど)・左右独立連続シフト法(M式など)・SandS法・複数キーUpリリース法(速記系配列)・同時打鍵を絡めた逐次打鍵法(蒼星など)についての挙動定義」「解釈したテーブルをJISX4064対応システムに伝達する方法」「標準的に採用するべき配列テーブル」の多章立てになりそう。


規格が目指すべき最終的な方向について。

 日本語入力用キー配列(指に宿る記憶)に関するリンク集に掲げた方法のうち、日本工業規格制定・改正案の工業所有権の扱いに係る声明書(Word 23kb)に署名いただけた入力法全てと、その他の「工業所有権を主張しない入力法の全て」が実装可能な仕掛けを採用していただきたいと考えています。

 #個人的には「日本語入力用キー配列(指に宿る記憶)に関するリンク集に載っている方法のうち、同意を得たもの全てが規格の紙面に載らない限りは完璧とはいえない」と思います。


 この「キー入力入れ替えソフト」のJIS規格化という考え方自体は、決して【既存の商用入力方法だけが実装できれば、それでよい】という考え方で実装されるべきではなく、【既存の入力方法+今後発生するであろう入力方法が一通り実装可能である】必要があります。

 「俺が、俺が……」の理論でほかの入力方法に関する配慮が不足すると、せっかく規格を作る意味がなくなってしまいます。そのあたりに関して一貫して引っ張っていただける方にリーダー役を引き受けてくださると、うまくいく可能性が上がると感じています。

 #ちょくちょく手弁当で会合を開く必要が出るでしょうから、首都近郊で手を上げてくださる方がいると良さそうです。


 ……で、私がここ(柔軟性の維持)にこだわる理由は色々とあるのですが、そのうちの一つは明確な記事が元となっています。

 02/02/25 公式レビューへのコメントをしてきたのさ。

 これは鈴見咲さんの姫踊子草の楽屋裏(HTML版)で公開されているものです。

 少なくとも、この記事の意図を全く理解できない人には、委員になってほしくはないなぁ……と。


配列そのものを売って飯を食っている人はどうすればいいのか。

 タタク ゆとり世代のキーボードシステム”タタク”や、あるいは超絶技巧入力のような例について。


 ……日本工業規格制定・改正案の工業所有権の扱いに係る声明書(Word 23kb)に署名すると、配列そのものの使用権を使って飯を食うことはできなくなります。

 それでは困る!という場合は……「署名はせずに、配列をこの規格向けには供出しない」必要があります。

 規格に載らなければ初期配列定義として含まれることはないわけですから、後はこの規格に合致するように配列を微調整して(たぶん調整の必要はなく、単に既存の定義をこの規格向けの定義へと変換するだけで済むはず)、定義とインストーラを販売すれば、それでよいのではないかと思われます。


 ……ほかの方法よりは十分に高い実現可能性があるはずですが、それでも実現可能かどうかは不明です^^;。

(2007年10月22日2:29:29追記)キーボードに配列データを搭載する方法についての追記。

 この規格にひとつ追記したいことが。

 接続したキーボードのうち、この規格に合致する配列データを「キーボード自身が持っている」場合については、その規格を(必ず、ではなく)優先して選択できるようになるといいかも。

 切替方法についてはどうにもよい案が浮かばないので、とりあえずは「配列データを記録したROMを搭載しておいて、PC側にコピーできるようにする」ぐらいが妥当かも。

*1:MODAPTS風に言うと、終局動作で必要な注意力を減らすことができる→作業時間を短くすることができる、ということ。

*2:p.214で森さんは、通信用JIS文字コード「78JIS」初期委員会の解散理由に関する発言をしており、それと同じ事態を危惧しているものと思われる。

*3:……いや、普通に考えると池上良己さんなのかもしれない。

*4:78JISの初期委員会は国語学者が大勢居たせいで3年経っても結論が出ず失敗したので、次の委員会では国語学者を林大さん一人にして「氏の独断と偏見に頼る」方針を採った……という前例があるらしく。

*5:というか、親指シフトは「昔普及しすぎた」ので、そのときのシェアを超える必要があり、ハードルが異様に高すぎるのです。