ノート:親指シフト

message: 追記により埋もれると面倒なので、冒頭をお借りして記録させていただきます。 -- かえで 2006年6月10日 (土) 16:59 (UTC)
*Wikipedia:査読依頼/親指シフト_20051230
*Wikipedia:査読依頼/親指シフト_20060611
thread_title: 秀逸選考、査読依頼、校正依頼などへの提出記録

message: 親指シフト配列との統合を提案します。202.247.193.162 2005年5月8日 (日) 01:41 (UTC)
replies: text: Googleでは親指シフトキー配列(26件)より親指シフトキーボード(10,300件)の方が圧倒的に多いですね。—Tokek 2005年5月21日 (土) 10:03 (UTC)
replies: text: :親指シフト配列(約1,020件)ですね。検索結果数が統合の理由となることはないと思いますが、内容の統合には賛成です。本家の「Japanese language and computers」には、「Oyayubi shift」という空リンクが設定されていますから、将来的には記事名を「親指シフト」とする事も考慮すべきかもしれません。 -- かえで 2005年5月22日 (日) 11:15 (UTC)
配列の説明の過程でキーボードを説明することはできますが、逆の場合はカバーしきれない部分(NICOLA以後の新配列への影響など)が出るので統合するなら親指シフト配列側を基本にすべきかと考えます。また、親指シフトのすべてがNICOLAではないため、NICOLA配列を項目名として「親指シフト」「～配列」「～キーボード」はすべてNICOLA配列に転送するのが一番すっきりするように思いますか如何でしょうか。--鈴見咲 2005年5月22日 (日) 14:22 (UTC)

text: 「親指シフト配列の記事を基本にすべき」はその通りだと思います。でもNICOLAより親指シフトのほうがずっと通りが良いというか、言葉として定着しているのではないでしょうか。Mononohazumi 2005年5月23日 (月) 13:26 (UTC)
replies: text: :ここでややこしいのは、日本語入力コンソーシアムが配列名称を「NICOLA」と定義しているにもかかわらず、同サイト上ではことごとく「親指シフト」とか「親指シフト(NICOLA)」と表記している点にあると思います。厳密には「親指シフト方式:親指シフト系配列全てを含む」であり「NICOLA:いわゆる親指シフト配列」であるべきかと思われますが、現実には親指シフト配列を主にお使いの方が、積極的に配列名を「NICOLA」と呼ぶ例は、皆無に近い状況です。そうなりますと、記事名については「親指シフト」を採用し、「NICOLA」は曖昧扱い(雑誌のnicolaがあるため)、記事中にて「NICOLA」の語を提示するのが妥当かもしれません。記事統合時に、記事順序を「親指シフト配列(他配列への言及以降を除く)」→「親指シフトキーボード」→「親指シフト配列(他配列への言及以降)」とサンドイッチにすれば、順序の問題は回避できそうです。 -- かえで 2005年5月25日 (水) 16:38 (UTC)
(インデント切って)結局、202.247.193.162さんが提案された本件については、どう処置すればよいのでしょうか…？
提案されたご本人による発言が続いていないとなると、そもそも「統合の意味」自体が無くなってしまうように思いますが。
もし記事統合をされる方がいらっしゃるようでしたら、統合後の記事整理も含めてお願いしたいところです。ただくっつければよい、と言う記事ではありませんので…。かえで 2005年7月31日 (日) 20:45 (UTC)
thread_title: 記事の統合

message: 記事中に「しかし、JISキーボードによるローマ字入力が多数を占める現在では、親指シフト方式のシェア拡大の可能性は低く、以前からの使用者が使用を続ける場合がほとんどであると思われる。」という部分があります。このうち現在という表記は(誰がいつ読むか解らないという)Wikipediaの性質から考えて不適切と思われますが、どう処置すべきでしょうか。適切な表現が浮かびましたら、修正いただきたいところですし、適切な言い換えができないとなれば排除する必要がありそうです。最近になって親指シフト系に首を突っ込み始めた身としては思われるにも引っかかるのですが、ここはまた別の話と言うことで。 -- かえで 2005年11月6日 (日) 11:21 (UTC)
replies: text: :早速対応いただきありがとうございます！ -- かえで 2005年11月15日 (火) 16:27 (UTC)
thread_title: 表現の問題

message: 小指シフトキーに関する挙動の件ですが、ワープロ専用機時代の挙動に関してはどのように取り扱いましょうか。
私は実機を知らないので何ともいえないのですが、小指シフトを使う場合であっても、半濁音の入力を行う場合に限っては同時打鍵判定がなされた( http://d.hatena.ne.jp/tree3yama/20051022/1129992734 )様ですので… -- かえで 2005年11月15日 (火) 16:27 (UTC)
replies: text: 実機(LX-3000)で確認したところ確かにそうなっていました。今の今まで知りませんでした。取扱説明書（紛失）では先に半濁音キーを押すように説明されていたように思うので公式の仕様でなく一種の裏技です。mononohazumi 2005年12月30日 (金) 21:29 (UTC)
thread_title: 技術的な問題

message: こちらで下書きします。
*仮名の配列は不変。
*1号機OASYS100では読点の位置が違った。横書き文書では日本語でもピリオドとコンマを使うという前提だったのか。また「ヴ」の入力ができなかった。
*その後すぐに読点が現在の位置に。「ヴ」の入力も可能に。
*90年ごろ（？）半濁音の交差打鍵による入力を導入。業務用ではソフトウェアの更新で過去の機種に遡ってサポートされた。
*オアシスポケットで親指キー共用型が登場（親指ピュンとどちらが先か？）
*タブキーおよび空白キーは薬指で押すのが公式の指使いで、初期の製品では端のほうに配置されていた。その後親指でも操作できるように横に延長され、おそらく多くのユーザは親指で操作するようになった。さらに後のパソコン用専用キーボードではタブキーや空白キーより外側にキーが追加されたので親指でしか操作できなくなった。
mononohazumi 2005年12月30日 (金) 21:59 (UTC)
mononohazumiさんも書かれているように、「、」の位置は 2代目 OASYS である OASYS 100J のときに変わっており、それ以降そのままです。カタログ写真 を見たかぎりはそうです
(神田さんのページには「配列はずっと変わっていない」というようなことが書いてありますが)。
つまり初代である OASYS 100 が例外なので、できれば OASYS 100J 以降の配列図を掲載したほうがよいかなあ、とおもいます。
ついでですが、OASYS、NICOLA や各種エミュレータで採用された配列の異同の資料がここにあります (配列データはページの下部の 3 つのリンクです)。たぶんここまで詳述しないとはおもいますが、参考まで。--Hatukanezumi 2007年1月10日 (水) 14:05 (UTC)
thread_title: 配列の変遷

message: こちらの史料によると、1986年発売のOASYS30AFが最初のようです。-- uttiee 2006年1月2日 (月) 00:29 (UTC)
replies: text: 意外と遅くまで親指仕様のみだったのですね。神田氏のサイトは改めて見るとすごい読み応えですね。mononohazumi 2006年1月4日 (水) 07:58 (UTC)
thread_title: JIS配列パーソナルOASYSの登場時期

message: ローマ字入力との併用は必ずしも必須ではないと思うので、現状のように修正しました。
現に私は日本語入力は親指シフト一本で通しており、ローマ字入力を習得する意志はありません。
*親指シフトキーボードがなければ、ソフトウェアエミュレータをインストールする。
*ソフトウェアエミュレータをインストールできない場合は、日本語入力をしない。いっそ英語で書いた方がまし。
*:-- uttiee 2006年1月4日 (水) 02:43 (UTC)
replies: text: 筋金入りですね。私も基本的には親指党ですが、ローマ字のほうを先に覚えたこともあり、親指入力が出来なければすぐに諦めてローマ字で打ってしまう風見鶏です。親指シフトを覚える前は親指シフト仕様のオアシスでローマ字入力していた時期さえあります。それでも親指仕様を買ったのはそのうち覚えたいという意識があったからですが。

text: ローマ字との両刀使いにならざるを得ない→併用する人が多い の変更には同意しますが、しかし、「先に親指シフト入力を覚えると自然にタッチタイピングができるようになっているため、その後で英字配列を習得することは容易である、という意見もある」というのはちょっとこじ付けっぽく感じます。若干修正させてもらいます。

text: mononohazumi 2006年1月4日 (水) 07:10 (UTC)
replies: text: :修正後の記述は情報として意味を成していないように思えましたので、コメントアウトさせていただきました。

text: :「先に親指シフトを覚えると楽に英字配列を覚えられる」というのは、無論私の主観による主張でもありますが、私一人の主張というわけではなくて、ソースは失念しましたがどこかで見たものの受け売りです。少数意見には違いないでしょうが、必ずしも独りよがりな意見でもないと思います。

text: :-- uttiee 2006年1月4日 (水) 10:02 (UTC)
replies: text: ::了解。訳の分からない文章になってしまったのでコメントアウトされても仕方ありません。mononohazumi 2006年1月4日 (水) 11:29 (UTC)
thread_title: ローマ字入力との併用

message: Wikipediaでの「作法」を知らないので、とりあえず気がついたところをコメントしておきます。具体的なアクションをどうすれば良いかは教えてください。
1. 最初の定義
「キー配列」は「入力方式」とした方が良いのではないか。親指シフトの革新的なところは、「親指と他の指の同時打鍵により一つのキーを3通りに活用する」というものなので、「キー配列」とすると、その一部分しか表現していないのではないか。
ただし、親指との同時打鍵だけを取り上げるとすると、例えば飛鳥も親指シフトになってしまう。これはある意味で正しいことではあるが、世間一般で普通に親指シフトと言った時に考えるものとは少し違ってきてしまう。
これらを考慮した拙案は以下の通り。
親指シフト(おやゆびシフト)は、日本語の文章を高速かつ快適に入力することを目的として考案された入力方式(文字キーの配列を含む)、およびこの入力方式を採用するキーボードの仕様である。
2. 操作方式
「入力した読みをカタカナに変換する」のが「無変換キーを2回打鍵」するのはIMの機能であり、親指シフトとは関係がない(親指シフトでも実現していない場合もあるし、親指シフトでなくても実現している場合もある)。よって削除が適当。
さらに言えば、変換キー、無変換キー自体の機能についてもここに書くことは不適切。ただし、「親指を活用する」という考え方の延長として、変換キー、無変換キーに重要な役割を持たせることの意味については別のところに記述するのも一つの手かもしれない。
3. 快適さ
(1) 「以下のように説明している。」以降の文章については引用ならば引用元を明記すべき。
(2) 「親指シフトユーザの動向がこの「快適さ」を裏付ける例もある。」は、やや論理が不明確。むしろ、「快適さ」は個人により評価の基準が異なり、客観的に(例えばスピードのような数値で)測ることが困難であることを述べた上で、かなりの人間が親指シフトを使い続けている事実の重要性を述べる方が筋が通りやすい。
この点を考慮した拙案は以下の通り。
快適さ」は個人により異なり客観的な指標化が困難である。このため、上記の説明についても非親指シフトユーザにとっては理解が困難で、客観性がないと批判される原因にもなる。しかし、以下に述べる通り、親指シフトユーザが、現実に直面する困難を工夫により乗り越えて親指シフトを使い続けていることは、この「快適さ」の証左の一つと言えよう。
4. タッチタイピングへの適合性
「使用者の手によってキーの刻印が隠れる」のは他の方法でも同じなので削除
5. OASYSの栄光と挫折「当初は他社に特許を許諾しなかった」と新JISキーボード化の失敗「神田は「他社に使わせないとは、一度たりとも言ったことがない」と発言している。」との整合性は?
6. 「日本語以外への親指シフトの応用」について記述することは有用か?これは言い出しっぺでドラフトを私が書かないといけないのでしょうが・・・。
杉田伸樹(ぎっちょん)
--Gicchon 2006年1月8日 (日) 08:04 (UTC)
replies: text: 1については私は現状のままでもよいと思います。そこまで厳密に考えなくても。

text: 2は私もちょっと気になっていました。親指シフトというよりオアシスの説明になっていますね。

text: 3については行き違いになってしまいましたね。私が編集している間にぎっちょんさんがノートを書かれました。でも、私の編集と目指す方向は近いようです。冒頭で「客観的な比較は難しい」と断ってみましたが、いかがでしょうか？

text: 4については、他の配列と同じとは言えないと思います。親指シフトキーを頻繁に操作するのでその上に親指を置きっぱなしにしたくなります。これから分かりやすいように編集してみます。

text: 5:そういえば矛盾していますね。

text: 6:お願いします。
replies: text: :mononohazumi 2006年1月8日 (日) 08:43 (UTC)

text: 1. 「親指シフト」の項目に「親指シフトキーボード」の項目を統合した、という歴史的な事情もあって、「キー配列」と「キーボードの仕様」という表現を併記しています。「キーボードの仕様」には、同時打鍵やクロス打鍵という独特の入力方式が含まれます。御提案のようにすると括弧の多い読みづらい文章になってしまうので賛成できません。

text: 2. 入力方式の項目からは削除しても構わないと思いますが、変換／無変換キーの機能に関する記述はあってよいと思います。入れるとしたら「歴史－開発の背景」の項目で、「変換／無変換キーによる対話型かな漢字変換」を開発したことに触れておけばよいかと思います。

text: 3. (1)「指がしゃべる」という件のことかと思いますが、これは特定のソースからの引用ではなくて、複数のソースの要約だと考えてください。リンクにあるような親指シフト支持者のサイトを見れば、これに類する表現は容易に見つかるかと存じます。

text: 5. 「当初は他社に特許を許諾しなかった」の記述は大昔に私が書いたものだと思いますが、ソースがない憶測に過ぎないものなので、削除して構わないと思います。

text: 6. 「日本語以外への親指シフトの応用」という事例があるのかどうか存じませんので、何とも言えません。
replies: text: :uttiee 2006年1月8日 (日) 13:57 (UTC)

text: 1は、そもそも親指シフトの上位項目がキー配列であることが原因ですね。別名でリンクをするときにはパイプ | を使用すればいいので、編集時に入力方式と書くことで入力方式のようなリンクを矛盾無く生成できます。そうすると括弧書きはせずともよくなりますので、こんな感じになります。
replies: text: :親指シフト(おやゆびシフト)は、日本語の文章を高速かつ快適に入力することを目的として考案された入力方式、およびこの入力方式を採用するキーボードの仕様である。

text: 3-(2)は……新たに書いた部分(下)との整合性を取りたかったので無理やり一行でつなげてみましたが、みごとに表現力不足でずっこけていた様で……すみませんですorz。

text: 6については、要約を文章中のどこか(シフトの説明部分近くが理想？)に作成いただき、ついで文末リンク部に既存サイトへのリンクを張れば良さそうです。この点に関してはGicchonさんの専攻(?)と思われますので、ぜひとも記述をお願いしたいところです。

text: それと……提案とは別件で。ノートの方に転記し忘れていましたが、「他配列を貶めなくとも親指シフトの良い所は説明できるのではないか」という考えを元に、FAQベースの【親指シフトの「欠点(質問)」と「それに対する反論(回答)」】を書いてみました。設問の最後から二つ目にも書いたのですが、やはり「自分自身が打鍵評価をしていないキー配列を対象にして物事を書くのは難しい(解っていない人が書いたものと見なされて軽視されてしまいがち)」と思います。Qwertyロマかなネイティブ(もしくはJISかな・新JISかなネイティブ)な方が「親指シフトを見て、思ったことをわざわざ指摘してくださる」ことは非常にまれだと思いますので、ここは留意しつつ記述する必要があるように思います。
replies: text: :たとえば私が、親指シフトや飛鳥配列で「親指シフトを踏みにじって飛鳥の優位性を主張する」文章を書いた場合、親指シフトを使う方にとっては気分が悪いでしょうし説得力など皆無だと思うのです。同じことが、全ての配列同士の比較においても通用するはず……と考えますと、私は「他配列の否定・他配列との比較」を行うことは、自らの首を絞める行為に他ならないのではないかと感じています。

text: 次いでこれも蛇足なのですが……文中JISかなの説明において「旧」の文字を置くことは不適当です(「思われます」というレベルではなく、JISかなは「現時点で有効な最新の公的規格」なので、どうやっても言い訳が通用しません)。現在高頻度で編集が行われていますので全文置換はできませんが、この表現はJISかなユーザにとって不快な表現であるだけでなく「事実と異なる記述」となりえます。もし項目編集中に見かけましたら、「JISかな」「JIS配列」などへと置換いただくようお願いいたします。 -- かえで 2006年1月8日 (日) 14:44 (UTC)

text: 言い出しっぺで書いてみました。ご笑覧ください。--Gicchon 2006年1月10日 (火) 14:06 (UTC)
replies: text: :お疲れ様です！早速拝読させていただきました。その表記方法ですと、親指シフトが「英字による記述や4段配列ではない方法を探している人向けに提示可能な、現実的な解決策の一つ」というスタイルで示せるわけですね。さすがです。 -- かえで 2006年1月10日 (火) 17:02 (UTC)
thread_title: 提案

message: 親指シフトキーボードとの統合後、やっと落ち着いてきたところへ申し上げにくいのですが、親指シフト配列への改名を提案いたします。
理由は、現状では富士通の開発した親指シフト配列と「親指によるシフト」が区別できなくて混乱するからです。
ぎっちょんさんが書かれた外国語への応用例は「親指によるシフト」ではあっても親指シフト配列ではありませんよね。また、シフトキーにおいて様々なシフト方式の比較をしようと考えているのですが、親指シフト配列と親指によるシフトを区別しないことにはどうにも混乱します。
提案：
#現状の「親指シフト」の内容を「親指シフト配列」へ移す。
#「親指シフト」には「親指によるシフト」の内容を残す他、親指シフト配列の略称でもある旨記述。「親指シフトキーボード」の二の舞にならぬよう、「親指シフト配列」に関する記述をせぬよう注記が必要。
#「親指シフト」へリンクしているページは、必要に応じて「親指シフト配列」へリンクするよう修正。#記事名を「親指シフト配列」にするとハードウェアの「親指シフトキーボード」に関する記述が置きにくくなるので再分離。「親指シフト配列」に関する記述をせぬよう注記が必要。
3についてはこれまでの経緯から抵抗があるでしょうが、キーボード関連の記事を発展させていくには配列とシフト位置とハードウェアを区別することは是非必要だと思います。統合直後と違って整理されているので可能だと思います。
いかがでしょうか。
mononohazumi 2006年1月11日 (水) 10:45 (UTC)
replies: text: （別案）「親指シフト」の語が配列名とシフトキーの位置の両方の意味で（ウィキペディアの外でも）使われている現状を考えるとむしろシフトキーの位置のほうを面倒くさくても「親指によるシフト」と呼んだほうがいい気もしてきました。mononohazumi 2006年1月11日 (水) 11:06 (UTC)
replies: text: :（提案取り下げ）どうも別案のほうが良さそうです。提案を取り下げます。「親指によるシフト」を「親指シフト」と略さないようにして混乱を防げば、急いで改名する必要は無さそうです。一人合点になってすみません。mononohazumi 2006年1月11日 (水) 11:14 (UTC)
replies: text: ::今すぐやるというのは時期尚早かも……という気もします。一方では「重複記事が無くなり、ページも重くなってきた」ことですし、将来的には分割することも考慮するべきだと思います。私としてはこういう案を想定していたり。

text: ::#「親指シフト」は曖昧さ回避のためのページ({aimai})扱いにして、単なる区別の場所とする。たとえば「あすか」のようなページを作成する。

text: ::#新生「親指シフト」で案内するのは次の項目とする。
replies: text: :::#親指シフトキー - シフトキーを参照のこと。

text: :::#親指シフト配列(NICOLA)、もしくは親指シフト配列(日本語入力コンソーシアム配列) - 親指シフトの配列・理論・ソフトウェア実装に関する項目。親指シフト配列の利点・欠点・指摘についても扱う。

text: :::#親指シフトキーボード(NICOLAキーボード)、もしくは親指シフトキーボード(日本語入力コンソーシアム配列キーボード) - 親指シフトのハードウェア実装に関する項目。親指シフト配列の利点・欠点・指摘については扱わない。

text: ::個々人が「親指シフト」とのみ呼称し「NICOLA」と呼ばないのは勝手だと思いますが(そこに干渉する気はもちろんなし)、Wikipediaの項目名としてはやはり「NICOLA」の語句を項目名に含めることは必要だと思います。現状では、Googleで「NICOLA」を検索すると、「親指シフト - Wikipedia」は「サッコ・バンゼッティ事件 - Wikipedia」のおまけ扱いになっています……これでは余りにも寂しいですので。

text: ::どちらにせよ、将来的にどういう方法で分割するか……という方法論について、今のうちから論じておく価値は確実にあると思います。 -- かえで 2006年1月14日 (土) 10:44 (UTC)
thread_title: 改名の提案

message: どこかにソースがあった記憶があり、かつそれが提示されていない部分を下記にメモしていきます。
===OASYSと競合関係にあるメーカーが親指シフトを採用するには、大義名分が必要であろう。===
東芝かどこかの技術者さんがこれに関する言及をしていたようですが、そのリンクがないため独りよがりっぽく見えてしまい、非常に勿体ないと感じています……そうではないことを示すためのソースが必要かと。 -- かえで 2006年1月22日 (日) 04:04 (UTC)
thread_title: ソースが不透明な項目に関するメモ

message: 東芝かどこかの技術者さんがこれに関する言及をしていたようですが、そのリンクがないため独りよがりっぽく見えてしまい、非常に勿体ないと感じています……そうではないことを示すためのソースが必要かと。 -- かえで 2006年1月22日 (日) 04:04 (UTC)
thread_title: OASYSと競合関係にあるメーカーが親指シフトを採用するには、大義名分が必要であろう。

message: 今飛鳥配列エミュレータのやまぶきを親指シフト配列のエミュレートに使っています。このエミュレータは同時打鍵の判定が専用キーボード以上に寛容で、シフトキーが先行した場合でも文字キーが先行した場合でもタイミングのズレを無制限に許容します。それでも一応親指シフト配列での入力ができているので、エミュレータだから必ず同時打鍵判定時間を短くしなくてはならないというものでもないようだと思い、本文を編集しました。
現状親指ひゅんQより誤判定が多いな、というのが感想ですが、慣れや設定で解消できることかもしれません。エミュレータと同時打鍵判定の関係を究明（おおげさ）するため、しばらく使ってみようと思います。
mononohazumi 2006年1月22日 (日) 10:56 (UTC)
replies: text: 今この瞬間も使っていますが、誤判定が多い気がするのは実力を試してやろうと雑な打鍵をするためかもしれず、よく分かりません。mononohazumi 2006年2月5日 (日) 00:37 (UTC)
thread_title: エミュレータと同時打鍵判定の関係

message: なんと！　削除依頼中なので編集できないんですね。大きな問題ではなさそうなので早く特定版削除かどうか判定してもらいたいものです。
仕方ないのでこちらで下書きします。以下下書き。mononohazumi 2006年2月5日 (日) 00:37 (UTC)
（ノートページでは他人の書き込みを書き換えず追記していくというのが一般的なマナーですが、ここから下に関しては下書きという性質上本文と同様の扱いで書き換えていただいて結構です）
親指シフトの習得に関しては、最初は専用キーボードで練習すべきだという意見もあるが、一方で専用キーボードを用意しなくても試せるエミュレータから気軽に始めればよいという者もいる。
他の配列を先に覚えていた者は、親指シフトを練習すると一時的にその配列での打鍵が混乱することがある。しかし、我々が小学校でカタカナを覚えてもひらがなを忘れなかったのと同様、複数のキー配列を覚えることは可能である。慣れると複数の配列を自由に切り替えて打てるようになる。
以下では、キーの位置を簡潔に表示するために、一般に馴染みの深いQWEERTY配列によるアルファベットの位置をもって表示する。
===ホームポジション===
ホームポジションに関しては、親指シフトでは守らざるを得ない構造になっている。JIS配列では標準と異なるホームポジションを提唱する者もいるが、親指シフトにおいては設計段階で想定されていたものがほとんど唯一である。
===同時打鍵===
同時にポンと打つ。例えば「J」のキーと親指シフトキーを同時に打って「お」を得る場合、右手の親指と人差し指を同時にうつわけだが、慣れると右手親指と人差し指に力を入れた状態が「お」の形と感じられるようになるので、感覚としては二つのキーを打つというより「お」のキーを打つ感覚になる。
===半濁音===
半濁音に関しては二つの方法があるが、半濁音キーを使う方法はオアシス時代のものであり、エミュレータの中にはサポートしないものもあることを考えると、これから覚える場合は交差打鍵によるのがよいだろう。
===語呂合わせ===
ローマ字入力か英文タイプを先に覚えている方のために、語呂合わせによるキー位置の暗記法を紹介する。アルファベットの位置を記憶していることが前提である。
（私が親指シフトを覚えたときに自分で作ったものを基にしています。オアシスから変換したものがハードディスクの片隅に残っていました。内容はすっかり忘れていたので、無理やりな語呂合わせに自分で笑ってしまいました。改良していただければ幸いです）
*A級のウヲ　A-うを
*小さなBlockベィ B-へぃ
*スロットマシンでChance到来 C-すろ
*Dogフードでテナずける D-てな
*ビタミンEがタリない　E-たり
*F-1マシンにケりを入れたらちょっとュげが出てきた F-けゅ
*Giant馬場が座ったらセモたれが壊れた G-せも
*Hなハミだし H-はみ
*白人にクルしめられたIndian I-くる
*Jリーガーへの道はトオい。J-とお
*キノうからK察官になりました K-きの
*イョうなほどポリシーの強いLionsファン L-いょぽ
*Macdonald'sにはソーユ（醤油）は無い M-そゆ
*メヌき通りをNissanプレジデントが走る N-めぬぷ
*O型のツマ O-つま
*Piっという音とともに小さなェラーダイアログが出た。コンマった（困った）。P-,ぇぴ
*丸（。）々と太ったおばけのQ太郎 Q-。ぁ
*コャく（子役）のRussia人少年 R-こゃ
*シアわせなSuperman S-しあ
*T字路で轢き逃げサレた。 T-され
*チニ飢えたUltraman U-ちに
*フヤけたVideoテープ V-ふや
*カエのWhiteシャツ W-かえ
*ひー、X線写真なんて嫌だよー X-ひー
*ヨッパラいがY褻行為をした。 Y-らよぱ
*Zzz...ぅぅぅ（いびきをかきながらうなされている） Z-.ぅ
*コンマ何秒でペプシの一気飲みをすればネムけなど吹っ飛ぶ ,-ねむぺ
*ホワん官（保安官）制度に終止符を打つ .-ほわ
（書き換えていただいてよいのはここまで）
thread_title: 練習法節の下書き

message: ホームポジションに関しては、親指シフトでは守らざるを得ない構造になっている。JIS配列では標準と異なるホームポジションを提唱する者もいるが、親指シフトにおいては設計段階で想定されていたものがほとんど唯一である。
thread_title: ホームポジション

message: 同時にポンと打つ。例えば「J」のキーと親指シフトキーを同時に打って「お」を得る場合、右手の親指と人差し指を同時にうつわけだが、慣れると右手親指と人差し指に力を入れた状態が「お」の形と感じられるようになるので、感覚としては二つのキーを打つというより「お」のキーを打つ感覚になる。
thread_title: 同時打鍵

message: 半濁音に関しては二つの方法があるが、半濁音キーを使う方法はオアシス時代のものであり、エミュレータの中にはサポートしないものもあることを考えると、これから覚える場合は交差打鍵によるのがよいだろう。
thread_title: 半濁音

message: ローマ字入力か英文タイプを先に覚えている方のために、語呂合わせによるキー位置の暗記法を紹介する。アルファベットの位置を記憶していることが前提である。
（私が親指シフトを覚えたときに自分で作ったものを基にしています。オアシスから変換したものがハードディスクの片隅に残っていました。内容はすっかり忘れていたので、無理やりな語呂合わせに自分で笑ってしまいました。改良していただければ幸いです）
*A級のウヲ　A-うを
*小さなBlockベィ B-へぃ
*スロットマシンでChance到来 C-すろ
*Dogフードでテナずける D-てな
*ビタミンEがタリない　E-たり
*F-1マシンにケりを入れたらちょっとュげが出てきた F-けゅ
*Giant馬場が座ったらセモたれが壊れた G-せも
*Hなハミだし H-はみ
*白人にクルしめられたIndian I-くる
*Jリーガーへの道はトオい。J-とお
*キノうからK察官になりました K-きの
*イョうなほどポリシーの強いLionsファン L-いょぽ
*Macdonald'sにはソーユ（醤油）は無い M-そゆ
*メヌき通りをNissanプレジデントが走る N-めぬぷ
*O型のツマ O-つま
*Piっという音とともに小さなェラーダイアログが出た。コンマった（困った）。P-,ぇぴ
*丸（。）々と太ったおばけのQ太郎 Q-。ぁ
*コャく（子役）のRussia人少年 R-こゃ
*シアわせなSuperman S-しあ
*T字路で轢き逃げサレた。 T-され
*チニ飢えたUltraman U-ちに
*フヤけたVideoテープ V-ふや
*カエのWhiteシャツ W-かえ
*ひー、X線写真なんて嫌だよー X-ひー
*ヨッパラいがY褻行為をした。 Y-らよぱ
*Zzz...ぅぅぅ（いびきをかきながらうなされている） Z-.ぅ
*コンマ何秒でペプシの一気飲みをすればネムけなど吹っ飛ぶ ,-ねむぺ
*ホワん官（保安官）制度に終止符を打つ .-ほわ
（書き換えていただいてよいのはここまで）
thread_title: 語呂合わせ

message: 意見を書く前に。どなたかが「削除依頼中」レッテルをはがしたらしく、これが悪戯とみなされて編集できなくなった様です……いや、どちらにせよ「私の行為そのものが発端」であることには違いないわけでして、その点申し訳ありません。恥ずかしくて穴に入りたい気分ですorz
【JIS配列では標準と異なるホームポジションを提唱する者もいるが～】の件などについては(つまりはここに限らず本文中全体について)、それを示すリンクを【JIS配列では標準と異なるホームポジションを提唱する者もいるが～】などと文中に提示し、文末にある「参考文献」の節にWikipedia:出典を明記するスタイルで詳細を追記するというのもアリかなと思います。Wikipedia:引用のガイドラインを見た限りでは「文献の記述をそのまま使うことは非常に危険」な様で(今回あわてて削除依頼を出した理由でもあります)、かといってただ漠然と記述してしまうとPOVと勘違いされてしまう恐れもありますので、このあたりが落としどころなのかもしれないと感じています。
専用キーボードと汎用キーボード流用の差については別途節を起こして、将来的に分割される先となるであろう「親指シフトキーボード」への言及をできるようにするほうが良さそうですね。専用キーボード自体もエミュレータもしくはキーボードドライバを使うわけで、そのあたりを含めてうまく記述できれば良いのですが……まだピンと来る記述方法は思い浮かんでいません。
【一方で無料で試せるエミュレータから気軽に】は【一方で専用キーボードへと変更しなくとも試せるエミュレータから気軽に】とするほうが、より実情に近づけるかと思います。
【複数のキー配列を覚えることは誰にでも可能である。】はそのまま書いてしまうと微妙かもしれませんね……ここはむしろ控えめに【複数のキー配列を覚えることは必ずしも困難とは言い切れず、事実実践している者もいる。】などという方向性が良いのかも？
半濁音の小指シフトサポートな件、それができるかどうか解っているものについてはエミュレータ一覧にて【(半濁音の小指シフト入力はできる)】【(半濁音の小指シフト入力はできない)】といった記述を付加する方が良さそうですね。その上で【エミュレータの中にはサポートしないものもある(詳しくはエミュレータ一覧を参照)ことを考えると】とするとより良いかと思います。
語呂合わせについては「ナイスアイデア！」だと思います。合調語のように直接記述するか、抵抗器のように外部リンク扱いとするかは要判断かもしれませんが、学習方法の節を追加して記述する価値は確かにありそうです。
本文が編集できないと、できることが非常に限られてしまいますね……つくづく自分が情けないです……重ね重ね申し訳ない限りです。 -- かえで 2006年2月5日 (日) 05:10 (UTC)
replies: text: コメントありがとうございます。

text: 引用の問題は難しいですね。親指シフトからは話が逸れますが、私も敬語のページに関連して失敗してしまいました。敬語のページの記述に特定の本の要約が含まれているのではないかと疑ったのですが、引用の問題に触れると話がややこしくなると愚考し、オーソドックスな理論を中心にするべきだという理由だけを出して該当部分をコメントアウトしてしまいました。オーソドックスな理論を中心にすべきだとも実際に思っていたのですが、かえでさんの場合と違って不可抗力ではなく、隠し事をしていたわけで恥ずかしいかぎりです。詳しくはノート:敬語をご覧ください。

text: 親指シフトの話に戻ります。

text: JISキーボードのホームポジションに関しては、標準でないホームポジションの具体的な内容にまでは触れる必要がないと考えます。外部リンクもJIS配列に関連しては貼らなくてよいかと。後はJIS配列のページに任せるべきです。

text: 「一方で無料で試せるエミュレータから気軽に」に関しては「一方で専用キーボードを購入しなくとも試せるエミュレータから気軽に」くらいがよいのではないでしょうか。さもしいようですが、費用の問題は気軽さに大きく影響すると思います。

text: 「複数のキー配列を覚えることは誰にでも可能である」は確かに言い切りすぎでした。

text: エミュレータの半濁音キーサポートの有無への言及は、ごちゃごちゃして見にくくならないでしょうか。

text: 語呂合わせがナイスアイデアとのこと、そんなに大げさなものではありませんがありがとうございます。外部リンクにする理由が著作権上のものならば、私の考えたものなので必要ありません。ただ、強引すぎる語呂合わせもあるので、改良していただければ幸いです。

text: mononohazumi
thread_title: 練習法節の下書きについての意見

message: 本文を編集する勇気はない(＝確証が持てない)のでこちらに書かせていただきます。節【操作方式】にある「親指ポン」についてですが、これは過去のカタログにあるもの(全て神田氏公開の製品パンフレット)に由来するものでしょうか。パンフレット群において「親指ポン」の対象となっているキーは変換操作に供するための「区切り」「かな変換・漢字変換」「無変換・変換」もしくは「実行キー」などの編集キーに対するもののようで、かな入力区間で用いる親指シフトキーに関してはこの表現が用いられていないように思います。当時の他の資料にはどう書かれていたのかを知らないものですから、そのあたりについてご存じの方によるご意見をお伺いしたいところです。 -- かえで 2006年3月15日 (水) 02:40 (UTC)
replies: text: この件について、uttieeさんの会話ページにて回答をいただきました、ありがとうございます。今のところ、少なくとも「変換」など機能キーに関することであるということのみはハッキリしていますので、折を見て位置の移動＆加筆を行ってみるほうが良さそうですね。 -- かえで 2006年5月28日 (日) 15:27 (UTC)
thread_title: 「親指ポン」はどのキーを叩く音か

message: この表現、より正確かつNPOVな表現を目指すために「少ない動作で快適に」あたりにしてみたいと考えています。
*親指シフトによる入力が必ずしも「入力速度」の向上をもたらすとは限らない(極端な話、自分に合う入力方式が一番体感速度が速いともいえる)
*「効率≒短い作業時間≠総運指距離の短さ＆アクション数の少なさ」と誤解されうる可能性がある
*人はどうしても「今やっている方法が一番快適＝効率的」と考えてしまう癖がある……もちろん、事実はそうとは限らないにもかかわらず。
この3点を考慮すると、「効率よく」という語は誤解を与えてしまうのではなかろうかと思います。そこで、より平易な言葉であり、かつ誤解を与える恐れの無い「少ない動作で」などの表現にしてみようかと考えていますが、いかがでしょうか。 -- かえで 2006年5月28日 (日) 15:27 (UTC)
replies: text: これは「親指シフトが何を目指して開発されたものであるか」を表現したものです。その意味では現状の表現で問題ないと考えます。親指シフトがそれを現実に達成しているかどうかは別問題であり、それは本文中で議論していますから中立性に問題があるとは思いません。--uttiee 2006年5月28日 (日) 15:39 (UTC)
replies: text: :なるほど了解しました。確かに「それを目指した」のであって、このままで問題ないですね。解説いただきありがとうございます。 -- かえで 2006年5月31日 (水) 20:51 (UTC)
thread_title: 「効率よく快適に」は[[POV]]かも？

message: 先月中旬にWikipedia:検証可能性が公式な方針として採用されました。本記事においては節「快適さ」「タッチタイピングへの適合性」「入力速度」「学習の容易さ」「他の入力方式に与えた影響」「ソフトウェアエミュレーション」あたりがこの方針に引っかかる恐れがあるようで、今のうちに検証可能性を確保する必要があるように思います。 -- かえで 2006年7月1日 (土) 16:40 (UTC)
===「他の入力方式に与えた影響」===
replies: text: 「他の入力方式に与えた影響」にはもともと(他の配列側に)信頼できるソースがないので、節ごとコメントアウトしました。 -- かえで 2006年7月1日 (土) 16:46 (UTC)
replies: text: :飛鳥配列などの作者の方にメールで聞いてみるという方法は駄目ですか？ 私は実名の含まれないメールアカウントを持っていないので、かえでさんお願いできませんか？ --モノノハズミ 2006年7月2日 (日) 10:35 (UTC)
replies: text: ::飛鳥については、作者氏がもともと査読つき論文を執筆する(ために自己の主張を取捨選択する)意思がないので、聞く以前に答えが出てしまっているようです……。月配列は論文が出たと言う話を聞いたことがない(出ていれば2chの該当スレッドや月配列ユーザが取り上げているはず)ので、これもおそらくはないでしょう。残るは花配列と中指ニコラなのですが、当該解説ページにはそれらしき記述がないので、メール問い合わせというのは確かに必要な手段かな、と思いました。ただ、ACT_(キー配列)の様に情報処理学会での発表をしている(別刷りを用意している)という記載はないので、ちょっと望み薄かな……と。問い合わせてみますので、ひとまずお待ちください。 -- かえで 2006年7月2日 (日) 17:30 (UTC)

text: :言葉が足りませんでした。メールで聞いてみるというのは、「査読つき論文はありませんか？」という質問をするという意味ではありません。もっと直接的な質問です。「あなたが○○配列に親指によるシフト操作を採用された上で親指シフト配列の影響はありますか？」と質問するのです。それに対してハイという返信があったら、そのメールが情報源にならないでしょうか。配列の作者によるメールは、その配列に関するかぎり信頼できる情報源として利用できるのではないでしょうか。Wikipedia:検証可能性にも自主公表された情報源でもその情報源自身に関しては情報源として使用できるとあります。メールが情報源として利用できないとしても、公式サイトで一言触れていただければ文句なくWikipedia:検証可能性を満たすことができます。もちろんメールでは質問の意図を説明する必要があります。下手をするとアイデアの盗用を責めているように解釈される虞がありますかからね。 --モノノハズミ 2006年7月2日 (日) 21:24 (UTC)
モノノハズミです。取り急ぎIPにて。この度は説明不足により かえでさんならびに配列作者の方々へご迷惑をおかけしました。あの説明で分かれというのが無理な話です。お詫びいたします。
自主公表された情報源でもその情報源自身に関しては情報源として使用できるとはいっても、入力効率や学習の容易さに関しては駄目かもしれませんね。一種の自画自賛ですから。しかし、こと他配列からの影響に関しては問題ないと思います。特許権侵害訴訟を警戒して他配列からの影響を否定することはひょっとしたらあるかもしれませんが、実際には受けていない影響を受けたとおっしゃる理由はありません。実際には公知の事実ということになりますから、他配列からの影響を否定しても訴訟リスクは減少しないのではないかとも思いますが、そこは法律に詳しい方に聞いてみないと分かりません。
その他にも開発目的（達せられているかは別として何を目指して開発されたか）など、配列の公式サイトを情報源として利用できる分野はありそうです。
59.128.37.187 2006年7月2日 (日) 23:31 (UTC)=モノノハズミ
Wikipedia:検証可能性

text: 日記側にお知らせ頂きありがとうございます。私はまた読み違えていましたか……すみません。メールでの問いかけ法についてはWikipedia:検証可能性#「真実かどうか」ではなく「検証可能かどうか」に例がありまして、メールによる照会結果「そのもの」を根拠とすることはできない様です……この点についてはWikipedia:削除依頼/飛鳥配列を書くキッカケと重なっていたこともあり、自己判定をする過程でWikipedia:検証可能性#自主公表された情報源と、Wikipedia‐ノート:検証可能性#オンライン掲示板やブログ等の情報について、それからWikipedia:独自の調査#一次資料と二次資料、Wikipedia:独自の調査#なぜ独自調査を排除するのか、Wikipedia:独自の調査#専門家の役割、Wikipedia:独自の調査#この基本方針の起源：ウィキペディア創設者の意見あたりとともに読みつつ、延々と考えていました。結果として行き着いた答えが「査読つき論文/出版済み書籍/査読つきWeb文献などのみを根拠とする」というスタイルでして、(削除提案におびえることなく)安心して記事を掲示し続けられる状態を作り上げるには、コレがどうしても必要だという結論に至りつつあります……Wikipedia:削除依頼/飛鳥配列の経過を見るに、今からふるいの目が将来細かくなる事を見越して「予め問題が出そうな部分を除去/置換する」ことが必要かと思っています。今のところキー配列関連としては、「親指シフト」「新JIS配列」「SKY配列」「ACT_(キー配列)」は査読済み文献のみでの記述が可能そうなのですが、ほかについては出直しが必要かもしれません。 -- かえで 2006年7月3日 (月) 03:12 (UTC)
すみませんなどと言われてはこちらが恐縮してしまいます。100パーセント私の責任です。
メールを情報源にすることができないとして、公式サイトの記述は駄目ですか。入力効率などについてではなく、他配列からの影響についての情報源とできませんか？
モノノハズミ 2006年7月3日 (月) 09:26 (UTC)

text: その点についてはWikipedia:検証可能性をどう解釈するかで異なってきそうですので(今思えば、どうにでも解釈しようがある方針って変ですよね……)、ひとまずWikipedia:削除依頼/飛鳥配列の結果を待ってみようかと考えています。 -- かえで 2006年7月4日 (火) 09:31 (UTC)
そうですか。執筆当時は「合法」だった記事が後から公式方針になった方針によって削除されるというのは釈然としませんね。これが法律だったら不遡及の原則があるのですが。
ところで、ひとつアイデアがあります。ウィキブックスへ移行するのはどうでしょうか。まだあちらの方針などを読んでいないので思い付きの域を出ませんが、すでに飛鳥配列の記事を削除依頼に出されており急を要するので。
思い付きついでに書かせていただけば、親指シフトに限らずキーボード関連の話題を網羅した本を協同作業で書いたら面白いなと、実現可能かも分からないうちから勝手にワクワクしております。
モノノハズミ 2006年7月4日 (火) 10:03 (UTC)
thread_title: 検証可能性

message: :「他の入力方式に与えた影響」にはもともと(他の配列側に)信頼できるソースがないので、節ごとコメントアウトしました。 -- かえで 2006年7月1日 (土) 16:46 (UTC)
replies: text: :飛鳥配列などの作者の方にメールで聞いてみるという方法は駄目ですか？ 私は実名の含まれないメールアカウントを持っていないので、かえでさんお願いできませんか？ --モノノハズミ 2006年7月2日 (日) 10:35 (UTC)
replies: text: ::飛鳥については、作者氏がもともと査読つき論文を執筆する(ために自己の主張を取捨選択する)意思がないので、聞く以前に答えが出てしまっているようです……。月配列は論文が出たと言う話を聞いたことがない(出ていれば2chの該当スレッドや月配列ユーザが取り上げているはず)ので、これもおそらくはないでしょう。残るは花配列と中指ニコラなのですが、当該解説ページにはそれらしき記述がないので、メール問い合わせというのは確かに必要な手段かな、と思いました。ただ、ACT_(キー配列)の様に情報処理学会での発表をしている(別刷りを用意している)という記載はないので、ちょっと望み薄かな……と。問い合わせてみますので、ひとまずお待ちください。 -- かえで 2006年7月2日 (日) 17:30 (UTC)

text: :言葉が足りませんでした。メールで聞いてみるというのは、「査読つき論文はありませんか？」という質問をするという意味ではありません。もっと直接的な質問です。「あなたが○○配列に親指によるシフト操作を採用された上で親指シフト配列の影響はありますか？」と質問するのです。それに対してハイという返信があったら、そのメールが情報源にならないでしょうか。配列の作者によるメールは、その配列に関するかぎり信頼できる情報源として利用できるのではないでしょうか。Wikipedia:検証可能性にも自主公表された情報源でもその情報源自身に関しては情報源として使用できるとあります。メールが情報源として利用できないとしても、公式サイトで一言触れていただければ文句なくWikipedia:検証可能性を満たすことができます。もちろんメールでは質問の意図を説明する必要があります。下手をするとアイデアの盗用を責めているように解釈される虞がありますかからね。 --モノノハズミ 2006年7月2日 (日) 21:24 (UTC)
モノノハズミです。取り急ぎIPにて。この度は説明不足により かえでさんならびに配列作者の方々へご迷惑をおかけしました。あの説明で分かれというのが無理な話です。お詫びいたします。
自主公表された情報源でもその情報源自身に関しては情報源として使用できるとはいっても、入力効率や学習の容易さに関しては駄目かもしれませんね。一種の自画自賛ですから。しかし、こと他配列からの影響に関しては問題ないと思います。特許権侵害訴訟を警戒して他配列からの影響を否定することはひょっとしたらあるかもしれませんが、実際には受けていない影響を受けたとおっしゃる理由はありません。実際には公知の事実ということになりますから、他配列からの影響を否定しても訴訟リスクは減少しないのではないかとも思いますが、そこは法律に詳しい方に聞いてみないと分かりません。
その他にも開発目的（達せられているかは別として何を目指して開発されたか）など、配列の公式サイトを情報源として利用できる分野はありそうです。
59.128.37.187 2006年7月2日 (日) 23:31 (UTC)=モノノハズミ
Wikipedia:検証可能性

text: 日記側にお知らせ頂きありがとうございます。私はまた読み違えていましたか……すみません。メールでの問いかけ法についてはWikipedia:検証可能性#「真実かどうか」ではなく「検証可能かどうか」に例がありまして、メールによる照会結果「そのもの」を根拠とすることはできない様です……この点についてはWikipedia:削除依頼/飛鳥配列を書くキッカケと重なっていたこともあり、自己判定をする過程でWikipedia:検証可能性#自主公表された情報源と、Wikipedia‐ノート:検証可能性#オンライン掲示板やブログ等の情報について、それからWikipedia:独自の調査#一次資料と二次資料、Wikipedia:独自の調査#なぜ独自調査を排除するのか、Wikipedia:独自の調査#専門家の役割、Wikipedia:独自の調査#この基本方針の起源：ウィキペディア創設者の意見あたりとともに読みつつ、延々と考えていました。結果として行き着いた答えが「査読つき論文/出版済み書籍/査読つきWeb文献などのみを根拠とする」というスタイルでして、(削除提案におびえることなく)安心して記事を掲示し続けられる状態を作り上げるには、コレがどうしても必要だという結論に至りつつあります……Wikipedia:削除依頼/飛鳥配列の経過を見るに、今からふるいの目が将来細かくなる事を見越して「予め問題が出そうな部分を除去/置換する」ことが必要かと思っています。今のところキー配列関連としては、「親指シフト」「新JIS配列」「SKY配列」「ACT_(キー配列)」は査読済み文献のみでの記述が可能そうなのですが、ほかについては出直しが必要かもしれません。 -- かえで 2006年7月3日 (月) 03:12 (UTC)
すみませんなどと言われてはこちらが恐縮してしまいます。100パーセント私の責任です。
メールを情報源にすることができないとして、公式サイトの記述は駄目ですか。入力効率などについてではなく、他配列からの影響についての情報源とできませんか？
モノノハズミ 2006年7月3日 (月) 09:26 (UTC)

text: その点についてはWikipedia:検証可能性をどう解釈するかで異なってきそうですので(今思えば、どうにでも解釈しようがある方針って変ですよね……)、ひとまずWikipedia:削除依頼/飛鳥配列の結果を待ってみようかと考えています。 -- かえで 2006年7月4日 (火) 09:31 (UTC)
そうですか。執筆当時は「合法」だった記事が後から公式方針になった方針によって削除されるというのは釈然としませんね。これが法律だったら不遡及の原則があるのですが。
ところで、ひとつアイデアがあります。ウィキブックスへ移行するのはどうでしょうか。まだあちらの方針などを読んでいないので思い付きの域を出ませんが、すでに飛鳥配列の記事を削除依頼に出されており急を要するので。
思い付きついでに書かせていただけば、親指シフトに限らずキーボード関連の話題を網羅した本を協同作業で書いたら面白いなと、実現可能かも分からないうちから勝手にワクワクしております。
モノノハズミ 2006年7月4日 (火) 10:03 (UTC)
thread_title: 「他の入力方式に与えた影響」

thread_title:  査読依頼(6/11分)