Home
Feeds
for Mobile相手に何か話しかけるとき、なんとなく「 あ、」ってつけちゃいませんか。あ、今日はしょーもない話です。
たとえばコンビニのレジで。読み取りが終わって店員が袋詰めをしていて、で、支払いという段になったとき、店員が袋詰めの手を休めるのを見計らって「nanacoで」と言いたいとき、ついつい「あ、nanacoで」って言っちゃいませんか。私は言っちゃいますが。
この「あ、」、無線通信でいうところの「ランダムアクセス」に近い役割を果たしてるんですよね。あるいは、衝突型通信におけるフロー制御的な。
相手が聞ける状態にあるかどうかわからない、そもそも自分が話していいターンなのかわからない、その時に、瞬間的に「あ、」と言って相手の反応を確かめる、あるいは、その「あ、」が相手の言葉と衝突しないかどうかを確かめる、そういう役割があると思うのです。
「あ、」と言って相手の反応を見る、その時、その「あ、」に反応して相手が聞く体制になるかどうかを確かめる、また、言われた方も、「あ、」という言葉を聞いて、あ、この人は今から何かしゃべるんだな、と判断して聞くモードになる、っていう暗黙のプロトコルが成立しているように思うんですね。
「音波」という無線通信を行う場合に、やっぱりこの「あ、」は、ランダムアクセス、あるいは、フロー制御(RTS/CTS)として非常に重要な役割を果たしているんですよ。
一方、1対1で会話が成立していてほぼ連続的に会話が続いている状態ってのは、トラフィックチャネルが1対1で成立している状態なわけで、いちいち「あ、」を挟む必要はありません。必要なのは、あくまでしばらく会話が途切れたり、会話がなかった相手に話しかけるとき。無線ドーマント状態からの復帰でもランダムアクセスによりチャネル割り当てが必要なのと同じですね。
このエントリの一番最初の行にも「あ、」を使いました。これは、相手に対して何らかの問いかけをして相手の反応を待っている状態、という前提に対して、ちょっと待って、もう少ししゃべるのでしゃべらないで聞いて、の意味であり、この「あ、」によって、もう少しだけしゃべる時間のリソース割り当てを確保するための手順だったのです。
「あ、」(connection request)→「（目線、しぐさ）」(connection accept/assignment)→「(本文)」というプロトコルが成立しているんです。この手順の開始のきっかけが「あ、」なわけで、この「あ、」を省略して相手に話しかけるというのは、リソース制御型通信や衝突回避の仕組みを備えない衝突型ネットワークと同じで、古い世代のやり方に過ぎないわけです。
といって、ついつい「あ、」と言っちゃうことを正当化してみる今日のお話。
TWEET