メモ。
NICOLAのための「現代的な」解説をするには、どういう切り口でNICOLAを捉えればいいのだろうか。
今のうちにその作業を始めておかないと、勝間さん旋風の第一弾*1が終了した途端に、揺り戻しの逆風が吹くかもしれない……それだけはなんとしても避けたい。
一番怖いのは「やってみたけどダメだった」系のリアルな話……すでにフォトリーディングでは出ている*2のだけれど、その点は勝間さんも書籍上で「講習会に参加しないとキツいかも」というフォローをしているから、いまはもう大丈夫だと思う。
それだけに、かえって親指シフトの話だけがあまりにも凪ぎすぎているので、何か嫌な予感がする。
もしもうまくいかなかった方がいるなら、劣等感など抱く必要はないので、素直に意思表示を行っていただきたいところ。
後になってから堰を切ったように、いっぺんに噴出するとフォローしきれなくなるので、いまのうちに分散表明してほしい……。
これが飛鳥の話なら、すでに数十人の方が試していて、かつ「○○が不満だったので□□に移行した/□□を作成した」という先行事例も多岐にわたっているから、「仮に馴染まなかったとしても自分自身を責めたりする必要はない」ということを説明しやすい/気づいていただける可能性が高いのだけれど……。
2008年1月8日1:00:48追記。
……ふと思ったのだけれど、四半世紀使われてきたはずの「NICOLA」に関して、「乗り換え失敗情報データベース」が出来ていないのはなぜだろう。
飛鳥には(誰が探しても見つかるくらいに)多様な事例があって、飛鳥への乗り換えに失敗しても、失敗した原因を元にどういう配列へと乗り換えれば良いのか見当がつきやすい(ので、自分自身を責めずに次の配列へとチャレンジできる)という事情があるのだけれど、これって290版近傍以降のわずかな期間で一通り洗い出された気が。
Rayさんから見れば喜ばしいことではなかったはずだと思うのだけれど、けん盤配列が人と機械のインターフェースそのものだという性質上、こういう事例がはっきりしているというのは「あとから取り組もうとする方にとっては、変なプレッシャーの影響を受けることなく取り組むために必要なバッファ」として働くから、後々のことを考えると、全体としては良い方向に働くはずです。
#そもそも、当時試された方は(私自身そう思ったのだけれど)明らかに「イノベーター」か「アーリーアダプタ」に属しているはずで、そう簡単には満足してくれないし、もともといろいろな方法を試してみたい！(あるいはより自分に合いそうな方法を探したい！)という好奇心旺盛な方だということもあるので、当時の状況からすれば「試した方全員が採用する」ということはありえなくて当然……という事情が絡んでいたようにも思うのだけれど。
……で、翻って「なぜにNICOLAではこういう事例がそろっていないのか」というところが、とても不思議なんですよね。
飛鳥に対してはるかに長い期間使われていて、かつとてもたくさんの方が経験してきたはず……なのにもかかわらず、です。
2ちゃんねるの配列関連スレッドを見ていても、NICOLAから移行された方がそのことを書くスレッドというのは、決まってNICOLAスレッドではない場所(新JIS・月配列スレッドで特によくお見かけしますね……)だというのが、前々から引っかかっていたのですが、このあたりも何か関係しているのでしょうか。
月配列スレッドではGA配列も含めていろいろな版をお使いの方が普通に意見交換されていますし、飛鳥スレッドでも最新版に限らずさまざまな版をお使いの方がいらっしゃるようで……こういう雰囲気の場所と、NICOLAスレッドとでは、何か「違う空気」が流れていたりするのでしょうか。
うーん……そういうことを「書きづらい・表現しづらい」雰囲気があるのだとすると、それはさすがにまずいと思う。
なにがそれを書きづらくしているのか、という事情はわからないのだけれど、何か重い事情でもあるのだろうか……。
基本的に、せっかく配列乗り換えを決意してくださった方に対しては「最終的には何らかの配列へと乗り換えして、ばっちり100％満足したうえでセカンド配列ライフを謳歌していただきたい」ところなので……この世には「誰に対してでも100％の満足度を提供できる、完全無欠の万能配列」など存在しないだけに、この手の失敗情報データベースのようなものは「どの配列にとっても」必要になってくると思います。
#失敗情報データベースは「自分を責めずに済むという環境を満たすための、ほぼ唯一かつ最良の治療薬」なので。
本来ならば、NICOLAの「一番おいしいところ」をきちんと見つけた上で、それに対応する形で失敗情報データベースが構築できればよいのかもしれないのですが、今の私は力量不足で、NICOLAの「一番おいしいところ」をきちんと掴むことは出来ていないんですよね……。
後付け的なものではない、「裸のままのNICOLA」がどういうものなのか、きちんと調査してみる必要があるのかもしれないですね。
2008年1月8日6:24:57追記。
Wikiで失敗情報データベースをやる……とすると、主観でまとめ記事としての「移行報告転入出記録」を書いてもらって、移行元配列Wikiと移行先配列Wikiの該当ページにリンクを貼り付けてもらう……という方法が、簡易的にできてよいのかも、という気も。
トップページの最下方に「失敗情報」と立てて、ページ「この配列に乗り換えました！」「この配列から乗り換えましたorz」「この配列に舞い戻ってきましたｗ」があればいいのかも。
……いや、「乗り換え」って言葉が変なんだな。日本語が「する」言語ではなくて「ある」言語なのだとすると……道具ではなく場所を強く連想させる「転出/転入」がいいのかも。で、再転入・最転出は“【再】”付きでリンクを引っ張ってもらう……と。
この仕掛けを導入後に私が移行報告転入出記録を書いた、と仮定すると……
- ★転出元★→★転入先★の
移行報告転入出記録を、記事として書く。客観めいた「よい・悪い」解説は抜いて主観の「好き・嫌い」で書く。 - JISかな→Qwerty/JISX4063ローマ字の
移行報告転入出記録を、記事として書く。客観めいた「よい・悪い」解説は抜いて主観の「好き・嫌い」で書く。 - Qwerty/JISX4063ローマ字→AZIKの
移行報告転入出記録を、記事として書く。客観めいた「よい・悪い」解説は抜いて主観の「好き・嫌い」で書く。 - AZIK→NICOLAの
移行報告転入出記録を、記事として書く。客観めいた「よい・悪い」解説は抜いて主観の「好き・嫌い」で書く。 - NICOLA→飛鳥カナ配列の
移行報告転入出記録を、記事として書く。客観めいた「よい・悪い」解説は抜いて主観の「好き・嫌い」で書く。 - 飛鳥カナ配列→かえであすかの
移行報告転入出記録を、記事として書く。客観めいた「よい・悪い」解説は抜いて主観の「好き・嫌い」で書く。
ここに、ヘッドフォンのそれと同じく「好き・嫌い」で書くほうがいい……と思った理由は、massangeanaさんがまとめていらっしゃる「親指同時打鍵に対する疑問の説いろいろ」を拝見していて思いつきました。
……いや、よくよく読んでみると、どうもこれは
- 実際に試してみたら、自分自身にとっては具合がよくなかった(このまま書けば主観的表現になるところ)。
- なぜなのかという理由を考えてみて、合点がいったとおりに書いた(ここで客観的表現に化けた)
というプロセスを経て書いていらっしゃる方が多いのではないか……と。
客観的表現で書こうとするから「正しい・正しくない」という話になって、まとめWikiなどで展開しようとすると矛盾する……とすると、主観的表現で「気に入った/好き・気に入らなかった/嫌い」のまま書いてもらうほうが、百万倍スッキリする話になると思うもので。
これがうまく行くかどうか、テストしてみる価値がある……のかも？要検討。
