携帯電話のアンテナを折ったり曲げたりする人がいる。 実は私も、昔やりました。 どういう仕組みで壊れるのか、だいたい分かっているのだが。 それにしても、結構皆さんやっておられるようです。 まず、アンテナを引き出す時はよい。 アンテナの先をつまんで引っ張れば伸びる。ここで折れることはまずない。 問題は、アンテナを引っ込める時だ。 この時に、アンテナの先端を押して格納しようとする人が結構いるのである。

運がよければ期待通りの結果になる。 つまり、アンテナが格納されて、それで終わりである。 世の中そううまい話ばかりではない。 ぐにっとアンテナが曲がったり、ツイていないと、折れてしまうのだ。 この件に関して、携帯電話のマニュアルには、注意書きが必ずあるはずである。 つまり、アンテナを格納する時には、先端ではなく、根元をつまんで引っ込めろ、という指示があるのだ。 だから「欠陥ではない」と言えばその通りとしかいいようがない。 FPROGORGでは、モジュラプラグのツメが折れるのは欠陥じゃないのか、 という指摘もさせていただいたが、こちらはあまり注意書きを見たことがない。

余談はさておき、携帯電話のアンテナ、意外とよくできている。 アンテナを完全に格納した状態と、完全に引き出した状態、 この2状態に関しては、アンテナが簡単に動かないように、 やや抵抗があるように設計されている。 その中間の中途半端な状態においては、アンテナは軽くするすると伸び縮みする。

アンテナを伸ばした時に、携帯電話をどうやって使うかというと、 やはり伸ばしたものは伸ばしたままにして使いたい。 だから、伸ばした状態で保持する機構が欲しい。これは分かる。 そこで、伸ばし切ったらすぐには戻らないようにしてある。 これが実は文字通り曲者なのだ。 アンテナを押し込もうとした時に、抵抗があるために、するっと押し込むことができない。 しかし力はかかる。 アンテナの先端を押したのに、根元が動かない。 その結果は、破壊工作とならざるを得ない。

根元を持ってアンテナを引っ込めると、少し力がかかっても、曲がったり折れたりすることはない。 力のかかる範囲が狭いからである。 同じ太さの木なら短い方が長いよりも折れにくい、というのと同じ理屈である。

さて、このような状況を想像していただいたところで、次のステップに進めたい。 どうすれば、アンテナを折れる事故を防ぐことができるだろうか。 1分間でいくつ思い付きますか。

§

もちろん、根元を持って格納すればよい、というのが一つの正論である。 しかし、実際にそのような扱いが行われない場合があることは、 電車の中で観察しているだけでも十分に事例を集めることができる。

余談だが、電車の中で携帯電話を使うのはマナーに反するそうだが、 なぜマナーに反するのかさっぱり説明がない。 というか、説明できない。 これはアタリマエだ。 なぜならマナーに反しないからである。 もちろん、大声で電話と対話したり、爆音のような音量で着メロを鳴らしたり、 そういうのがマナー違反だというのは全く異議はないが、 それって携帯電話とは全然関係ない話だ。 人間が直接その場で大声で話しているのも、 目覚まし時計をいきなり鳴らしたりするのも、 電車の中ではいみじく迷惑なのだ。

ペースメーカーの誤動作伝説というのもある。 これも納得いかないというか、どうも怪しい話である。 何が怪しいかといって、実は山手線をしばしば使っているのだが、 車掌さんが「携帯電話はマナー違反だ違反だ違反だ参ったか!」 という感じで実にうるさく全車両に大声でアピールしてくれる。 そちらの方が迷惑この上ないと思ったりするほどなのに、 なぜか一向に携帯電話が使われていない車両には出くわさない。 つまり、効き目がないのである。 2、3駅も行くうちに、必ず誰かに電話がかかってくる。 PHSなのかもしれませんが。 とにかく、呼びかけとは裏腹に、実際に混雑した車内で携帯電話は日常的に使われていることが分かる。 何が納得いかないかというと、 これでまだ事故が起きていないというのが怪しいというのだ。 実は既に被害者が出ているのだろうか?　そのような報道は見たことがないのだが。

※ 2006年3月現在、まだそういう事例を見たことがない。 ただ、これは本人から聞いたのだが、 ペースメーカーを付けている人が、 目の前で携帯電話の着信音とかを聞くと、 心臓が止まりそうになるほどビックリするそうだ。 そちらの方がよほど危ない。 心配しない方がいい。

ところで、一時期、山手線内で次のような携帯電話の車内広告があった。 携帯電話はマナー違反だからメールを使おう、というような感じのキャッチフレーズなのである。 電話の会話がウルサい、という視点としては正論だが、 電波の話はどこに行ったのだ?　なお、数日してこの広告は姿を消した。不思議な話である。

§

携帯電話のアンテナの話に戻ろう。 アンテナの根元を持って格納すれば安全なのに、 頭を持って格納して折る事故が発生している。 これはまず事実としておこう。 この事故を防ぐアイデアを無節操に考えてみた。

・折れないアンテナにする。

絶対折れないような材質があればいい。 もちろん、そんな材質があったら既に使われているような気もするけど。 携帯電話は重量の問題もあるので、難しそうだ。

・折れてもすぐに交換できるようにする。

新品を突っ込むだけで交換できるようにして、1本10円位のコストで買えるようにするわけです。 折れると困るという条件に目を付けて、折れても当然、という発想の転換ということ。

・曲がるが折れない材質にする。

曲がっても元に戻せばokという発想だ。何となくイヤですけど。

・頭を押しても格納できないようにする。

頭の部分を尖らせておく、というのは冗談ですけど。 危ないから。 例えばアンテナの根元にロックボタンを付けて、 これを押さないと格納できないようにすれば、 まず根元のボタンを押す操作が必要だから、 次に根元を持って引き込んでくれることを期待できるかもしれない。

・アンテナがなくても使えるようにする。

PHSで、アンテナのないタイプ。これはアンテナ折れません。当たり前だ。

※ 私が今使っている携帯電話 (FOMA) にはアンテナがないから折れない。

・先端を押したらアンテナが格納されるようにする。

つまり、先端を押す程度の力で、アンテナがうまく入るようにすればよい。 折れなくなる。 これは結構難しいかもしれないが。バネか何かで引き込むような感じに作っておいて、 伸ばした所でロックさせる。 ちょっと先端をずらすとロックが外れてするっと引き込む、 というようなメカニズムは原理上は可能だと思う。

・通話が終わったらアンテナが格納されるようにする。

　 これ、一番格好いいですよね。 通話が終わったらスルスルと自動的に格納される。 もちろん、電話がかかってきて、通話開始のボタンを押したら、自動的に伸びる。 特許取れませんかね。

※ というタイプの携帯電話、見たことがないぞ。

§

ところで、アンテナの先端を使って格納するのも、 電車の中で携帯電話を使うのも、 やめろといわれてもやる人が絶えないのは事実だ。 となれば何か理由があるのである。 そこを理解しないと、根本的な対応はできないと思う。 やめられないのなら、納得できるような方法でやってもらうというのも一つの解決策である。

例えば、電車の中の携帯電話。 携帯電話可の車両と不可の車両を分けてしまうというのはどうだ。 偶数車両はokで奇数車両はダメ、というようにすればよい。 特急だと、禁煙席と喫煙席を分ける位だから、禁電話席と電話席を分ければよい。 ペースメーカー等に関する問題があるとしても、多分解決するはずだし、 少なくとも今よりは安全になると思うのだが。

※ 問題がそもそもないから、解決するといっても謎なのだが。

§

ニフティサーブ、FPROGORGでの話題。実は前々回のこのコラムで紹介した話題の続きである。

---- List 1 (1文字ずつ処理、定石版) ----

　　while ((c = getchar()) != EOF)

---- List 1 end ----

この書き方の是非に関して、ずるずると長引いたのだが、 最終的に猛烈に気になったのは、List 2のように書けばいいのではないか、というご指摘。

---- List 2 (1文字ずつ処理、カンマ版) ----

    while (c = getchar(), c != EOF)

---- Lsit 2 end ----

言われてみればそうだ。 処理も明快だし、なぜこう書かないのか不思議な位だ。 では、なぜこの書き方ではなく、 List 1 のような代入式の値とEOFを比較するという書き方が一般に使われているのだろうか。 K&Rに書いてあるから、という極めて納得力のある説もあった。 真相はそれで当たりかもしれない。

※ カーニハンとリッチーがそう書いたのだから、 それは正しいのである。

少し理屈っぽいが、 List 1のような書き方の方が、 特に初期のコンパイラの場合は、 いいコードを生成したのではないだろうか、という説もある。 式が値を持つという特徴は、代入式の代入結果がどこかのレジスタに残っている可能性を想像させる。 それをすぐにEOFと比較することで、無駄のないコードを作ることができそうな気がする。 カンマで分けて書くと、cに1文字代入した後に、 cの値とEOFを比較するコードをそのまま書かれてしまいそうだ。 もちろん、今時のコンパイラが、この程度の処理を最適化しないとは考え難い。 実際はどちらも同じコードになるかもしれない。 さらに、コンパイラがどんなコードを出すかという所までは、 C言語の規格が保証するわけではないから、 何かの間違いでList 2の方がよいコードを生成しないとも限らない。 しかし、直感的には、やはりList 1の方がよいコードを出しそうな気配があるような気がするのである。

§

初心者が書くコードでさえ、なぜそう書いたか、理由はあるものだ。 ましてや、K&Rに出ているコードである。 絶対に何か理由はあるのだ。 しかし、それが見切れない。 悩んでもいいが、ただ、最近「こだわらない」ことにしている。