  |
はてなキーワード: モーニングコールとは
http://anond.hatelabo.jp/20170215202351
私も夢の中で目覚まし時計の音を(音楽,BGMとして)聴いたり夢の中で朝の支度をしたり夢の中で授業を受けたりする人間です。
ベッド横のテーブルに置いてある目覚まし時計の音は全く聞こえない（目覚ましとしてではなく、夢の中の音楽としても）けど、枕元のスマホで設定したアラームの音は辛うじて聞こえるし、（よく失敗するけど）目を覚ませる人間です。
そんな私が起きられる方法、起きられない方法をメモ代わりに置いておきます。
参考にもならないと思いますが…
ダメです。全く聞こえません。聞こえなさすぎてこれを聞いた家族が声を掛けに来るという使われ方をしています。
ベッド横のテーブルに置いてあるため、距離が悪いのかもしれません。枕元に置いたらどうかな。
2.枕元のスマホのアラーム（睡眠サイクルに合わせて起こしてくれるやつ、好きな音楽）
辛うじて目は覚める。起きられるかどうかは別。
音楽を変えられるのが良い。音に慣れてくると起きられなくなりますからね。
3.カーテンを開けっ放しにする
朝日で起きようなんて甘い考えをした私が悪かった。
このレベルになると光で起きようなんて戯言ですね。
4.照明付き目覚まし時計（鳥のさえずりで起こしてくれる）
こいつは我が家の電気をいたずらに消費しているだけなのでは…？と思います。
寝過ごして目が覚めるとこいつが誰にも気づかれることなく優しく（と言ってもLEDの白ーい眩しいライト）光っているので虚しくなります。
起きれる人向けのインテリアだったんや。
5.家族に起こしてもらう
100%二度寝します。家族への申し訳なさが募り、家族も辟易、良いこと無し。
6.友人にモーニングコールを頼む
学生のうちしか使えないだろうなと思いますし、学生でも休み期間中などは使えませんが、家族が声を掛けに来るよりずっと起きれます。
家族以外に迷惑かけたくない、そもそも家族以外と会話するのが億劫だ、という性格だからかな。
モーニングコールサービス等で代替可能だと思います。私みたいな性格の人におすすめ。
今思い出せるのはこのくらいかな。
いや、しょーもない話なんだけど、
と頼まれて困っている。
「いやー、私も朝が苦手でして…はは、」
とごまかしているが、何より、こんなリスクだけあることを引き受けたくはない。
知ってか、知らずしてか、部長は、
『朝が苦手なら、早起きしてワタシも起こしてくれればいいじゃない？』
と笑顔で突っこんでくる。
「増田部長、何時起きですか？私、その時間帯はもう電車に乗っているから無理ですよ、はは」
『いや、別にしゃべらなくってもいいんだ。ただ、電話をかけてくれればいいんだ。難しくないだろ？』
「これって業務命令ですか？」
『当たり前だろー。お前、どれだけワタシをひどく見ているんだ（笑）』
「そ、そーっすよねー、たはは。」
－－－－－－－－－－
というのが、昨日の話で、さっそくモーニングコールを忘れたところ、
昼前に、頭がぼっさぼさのままで部長が出社してきた。
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。
OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。
前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法で OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。
言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたのお気に入りの OAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。
また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法で OAuth を使っているサービスの利用者であっても、また自ら OAuth ベースのサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。
この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。
この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。
この前書きのあとは、まず OAuth のセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティのコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。
その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。
最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。
いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーが OAuth ベースのサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースのシステムの主要なセキュリティ欠陥は非常に蔓延しています。
筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。
というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。
ここで言及されている情報やリンクされている情報は今のところ既存のサービスに悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のものを破壊するのではなく改善することを目指してください。この記事は、自社サービスを不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。
この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。
まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。
ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッション・グループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。
ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザがビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。
ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的に営業部門のメンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。
トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティのアプリやサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:
上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。
さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザはインストールするネイティブアプリすべての信頼性に自分で責任を負う。
さらに
クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。
基本的に言って、OAuth のセキュリティガイドラインは、OAuth を利用する開発者がユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。
私の知る主要な OAuth ベースのサービスはほぼすべて、ここに概説した手法で攻撃可能です。
OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください！ 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者や管理者に「OAuth はもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。
OAuth ベースのサービス設計でよく見かける間違いは、ブラウザ用に、パラメータのひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティのプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザのブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリやサービスのユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローを OAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。
「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつのサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザがブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。
EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebook のユーザは全員 GMail に対して Facebook そのもののふりをすることができてしまうということです。
この問題は、OAuth エンドポイントがユーザのウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザをログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザのブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。
ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)
Citrix もこんな間違いをしています:
(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)
Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータをリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースのサービス開発者でさえも似たような状況で潜在的にヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。
サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービスは一般的にいって独自の「SDK」を提供しており、サードパーティの開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。
この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアントの機密情報を取得する脅威」に分類されています。しかしサーバがウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者は OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームが OAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
具体的に言うと新卒の皆様の就職活動に向けての準備でございますな。
そこで、超具体的に高卒or大卒or院卒(除く博士)就職する人向けのTOEICの話でも。
テクニカルに500点取る人と、理解して400点の人は、質が違う。
TOEIC公式サイトのサンプルでも見て、どう思うかで判定できるね。
これを「英語の試験だ」と思うか「ああ、ビジネスで使いそうな例題ね」かで違う。
業務で英語なんか全く使わないのに「高い方が優秀だろ」みたいな理由で点数見てるトコね。
まあ、世の中努力ではどうにもならん理不尽な事が多いのを知るのも就活の意義ではあるので、
そこは諦めて、出来る事をしてくれ。
商社やメーカー、中小工場の営業に至るまで、英語圏で仕事する人達は多い。
で、経験則的に、フツーに英語使えたら風邪引いててもこれくらい点数取れるだろ、と設定してる。
（まあ、野生の勘でブロークンイングリッシュで乗り切るオヤジとかが生息してたりするんだが）
新人の間はアンチョコ片手に苦労しながら現地のコーディネーターに合流出来て、
意思疎通して開拓したり交渉したりする（契約は英語屋orネイティブを挟む）のを期待してる。
だいたい、700～800点位を基準にしてるところが多い。
コッチ狙う人は正攻法で頑張ってくれ。
ワリとIT企業に多いんだが、意味もなく高い値に設定しているところが多い。
500～600点を基準にしてる所はまず意味ない数字だな。機械的に単位の「優」を数えるのと一緒。
あと、積極的に海外展開してるように見えないのに、750～900点とかつけてる所。
まず、商社や販社、外資の「英語普通枠」は、帰国子女とか準ネイティブが占めます。
身も蓋も無いですが、諦めましょう。
（諦める必要の無い努力型英語話者は、素でTOEIC800は超えるので関係ないしね）
「日本人だけど英語が使える枠」として残りたいなら、800点を目指しましょう。
まあギリ800，だいたい700～750くらいだと問題無いと思います。後は経験なので。
このレベルになるとTOEIC受けて知らない単語は滅多に出てこない、
思い出すのに時間かかるとか、なんかこもった話し方されると解らん、というレベルかな。
人によってやり方違うけど、まあ慣れかな。
学生さんだとそもそもビジネス文書に慣れが無かったりするので、
意外と日本語の新聞の社説を速読できるようになると、効果があったりする。
最初に言っとくと、試験の意味がわからない人でも、技法で600点ぐらいまでは行ける。
そうだなあ、
「英語は判んねえけど、今オレの悪口言っただろ」とか
「単語並べりゃ海外旅行は出来る」みたいなバイタリティ溢れる人は、
逆に、TOEICの点数はスゲエ良いのに、英語使って仕事できない人も居る。
で、「600点以上」とか書いてる会社は、何も考えてないことが多い。
600点って、辞書片手に英文メールで仕事のやりとりが何とか出来るレベル、だから。
これは巷にあふれるテクニカルな手法でとりあえずチャンピオンデータ取っちゃえば勝ち。
当然毎月試験受けるし、小手先のテクニックも大量に使ってくれ。
英語力(というと胡散臭いが)上昇には意味ないが、どうせ元々意味のない数字だ。
ヨドバシのチラシ見て「どれが一番割引率が高いか」とか、
中央線の時刻表見せて「どの列車に乗ると高尾山に一番早く着くか」とか、
展示会に行ったら「セミナー会場は変更になりました。なお飲食禁止です」とか、
ホテルにモーニングコール頼んで、お湯が出ないって文句言ってるオッサンの愚痴を聞いたり、
歯医者に「都合悪くなったんで、来週にならんかな」とか言ってるオッサンの電話聞いたり、
「明日の未来の為に、我がジオン国国民はXXXXXならんのである！」を穴埋めさせたり、
「あの壺をキシリア様に届けてくれよ！ 」を聞いて、届けるのは何家か聞いたりとか、
和訳してテスト見れば、日本人なら風邪でもまあそりゃ取れるだろって内容なの。
だから「天気予報なのは判ったけど、その気象条件の単語は知らん」とか
「オッサンの説明がウザくて、何曜日か忘れた」とか
そういう状況なら、後は努力だ。
「おれの５００馬力を試してみたいってまなが言うんだよぉ」
AB先輩、ぼく、かな＆あながギャラリーの集まる峠に戻ると、
やぐち、おまえとはこれっきりだ。
ぼくは矢口先輩が自慢し続けるのを途中でぶちきってやった。
かながもう帰りたい、というので
AB先輩はかな＆あなを送っていくことになった。
僕も同乗していくことになった。
やぐちせんぱいのチームのほかの先輩たちも数人集まってきていたが、
やぐちがこねえなら、俺らもちょっと走って帰るよ、
ということになった。
矢口先輩のFD3Sは、他の先輩が乗って帰る手はずになっていたらしい。
やぐちのやろー。
ぼくは他の先輩たちの心の声を心の中で代弁した。
翌朝、６時前だったか。
「モーニングコールだ、ばかやろー。」
ちょーご機嫌で、朝からまじでうざかった。
「やっぱ都会の女はエロいなー」と自慢が始まったので、
会話をさえぎり、
「すみません、用事はなんですか？」
と僕は強引に聞いた。
「あ、そうそう。かなちゃんがお前に話しがあるから携帯教えてくれっていわれたから教えちゃったぞ。童貞、もらってくれるんじゃねえ？」
うるせえ。
そう思いながらも、ぼくは本当にかなさんに気に入られてセックスできるんじゃないか、童貞捨てられるんじゃないかと妄想し始めた。
「せんぱい、まなさんって大宮なので、都会の女じゃないですよ。」と訂正を入れ、
僕は電話を切った。
その日の夜、かなさんから電話があり、今日これから会えないか？といわれたので二つ返事でイオンで待ち合わせることにした。
イオンで会ったかなさんはとてもエロくみえた。それはきっと僕がエロを意識していたからだろう。
スターバックスに席を取り待っていると、コーヒーとふらぺちーの（ぼくの）をもってかなさんが目の前に座った。
「ごめんね。急に呼び出して。」
ぼくの妄想は果てしなかった。
「○○くん、昨日あの金庫の中でなにか変わったことなかった？」
「なんすか？やぶからぼうに？」
セックスの可能性が一気に低くなった。
「なんかあったなら教えて欲しいの。教えてくれたら私も正直に話すから。」
僕は金庫の中、貯蔵庫で聞いた女性の声について話した。
かなさんが連れて行ってくれたのはファミレス風の個室居酒屋だった。
ぼくは初めてのことにとまどいながら、お酒を注文するかなさんがすごく大人に見えた。
「あの、運転して帰るンじゃ？」
は？
まじなんなん？
なんだかむしゃくしゃしていたので、僕はその店で一番高いものを注文した。
「こんなこと信じてもらえるかわからないけど、わたし、見えるの。霊感があるとかそういうのじゃないの。ただ見えるの。いつも見えるわけじゃないけど・・・、こんなこと言っていいのかな。わかる？女の子の日？」
ぼくはうなずいた。
「わたしね、おんなのこの日が近づくと見えるようになるみたいなの。でも普通に生活している時は見えないの。昨日みたいに特別な場所にいったときだけなのね。ほら、この辺だと首なしライダーが有名でしょ？わたし見たことあるのよ。すごいスピードで追い抜いていったかと思ったらがけの前で消えたの。その時彼氏が運転してたんだけど、そのままライダー追いかけてたらがけに落ちてたと思う。あれ、やっかりな霊よね。そうそう、あの峠の近くにダムがあるでしょ？昨日も別荘へ行く途中に通ったじゃない。あの時、ダムの水面に子供が立ってたの。ああ今日はマズイな、ってその時は思ったけど、まなとあながどうしても行ってみたいっていうから仕方なくついていったの。いざという時、あなたたちから彼女たちを守れるかもしれないしね。」
「それでね。これは秘密なんだけど、そういう時わたしが明確な意志をもって他人に触れると、その触れられた人にもわたしの霊感みたいなものが移るの。ごめんね。昨日金庫へ入る前、きみを押し出したのはわたしなの。」
そういえばAB先輩に金庫へ入るようにうながされた時、誰かに背中を押されたのを思い出した。あれはかなさんだったのか・・・。
「ほんとうにごめんね。わたし、あの別荘に入った瞬間から声が聞こえてたの。AもBも見かけは強そうだけど精神は弱いの。多分、幽霊なんてみたら泣いちゃうくらい。きみはね、まだ子供だから特別なの。ごめんね。バカにしてるわけじゃないの。あの中ではきみしか頼れなかったの。このこと、多分一生きみの心に残ると思う。だから、わたしね、きみの願いをみっつ、なんでもかなえてあげる。」
なんでも？
「もちろんなんでもって言っても、わたしにできることよ。エッチなことでも大丈夫よ。」
「じゃあ、一度やらせてください。」
思わず口について出たのがこんな言葉だったことを、ぼくは黒歴史としていまでも記憶している。
「いいわよ。」
あっけなくセックスできることになった。
「ただし・・・。わたしの身体を通るってことは、あなたにもその覚悟がないと無理よ。どういう時に出てくる歌かわからないけど、きっと霊感のようなものが身についてしまうかう。」
さすがにその言葉を聞き、ぼくは躊躇した。
「考えさせてください。」
死にたい。
マジ死にたい。
恥ずかしながら、どうしても起きる自信が無い日は母親にメールして朝モーニングコールをかけてもらっています。
昨日もやはり明け方まで仕事をしていたため、母親にメールをしてモーニングコールを依頼しました。
先ほど友人がからメールがきたため気づいたのですが、どうやら僕はこの前ふられた子にも「起こして」的なメールを送っていたようです。
俺の人生おわりました。
たしかに凄く眠い中で、母親に送ったメールが、ないことに気づいてもう一度メールしようと思ってメールしたのはうっすら覚えています。
先ほど友人からメールが来た際に、送っているはずのないし、送ったはずも無い子のメール履歴が上の方にありました。
きっときもいなーこいつとか思われているのでしょう。
会社の同僚なのに、今日会社であってもいっさいつっこみがありませんでした。
僕は今後どういう行動をとればいいんですか？
だれか教えてください...
「あまり使わないよな」、何て考えていて
ぼけっとしていたら三〇になった、そんな感じ。
PHSなんか必要でもないのに、みんな持ってたからってだけの理由で持ってて
使った事なんて数えるほどしかない時期もあったけど
別にケータイが好きでも嫌いでもなく、ただただ縁がなかったとしか表現できない状態だった。
少し前までは。
価値観がちょっと変わったかな。
・朝は大体かかってくる電話とかメールの音で目が覚めるようになった。
内容は、本当にどうでも良い内容ばかり。甘いモーニングコールみたいな物だったら嬉しいんだろうけど。
生活時間が一緒な人間が周りにいるのだからなのだから必然なのだろう。
結局そのままハンズフリーでおき支度を始める。
ただ鳴ってもいないのに、鳴った気がして起きることも（これは慣れるのだろうか？）
・NTTの回線では全く気にならなかったナンバーディスプレイ。知らない番号でも平気で出ていたけど今は無理。
最初数人にしか教えてくて、もちろんその人とだけなはずだったけど
番号はいつの間にか広まって、NTTの番号しか知らないはずの人からも普通にかかってきて何か少し怖かった。
大抵の知人を登録することで解決したが、未だに番号だけの表示はやだ。非通知なんて最悪だ。
これを今まで自分が平気でしてたと考えると、空恐ろしい。自分が普段持ち歩く物に侵入ってのが嫌なのではないかと思う。
おかげでNTTの方も見覚えのない番号は警戒するようになる始末。
・目の前の人を無視できるようになった。
無視という単語が適切かどうかは分からないけどこれが一番大きい。
例えばコンビニとかで電話しながら店員とやり取りしても回線の向こうの相手にそれを感づかれないそんな今まで無かった行動スキル。
又、目の前で会話している人がいても今の段階では電話側にインタラプトされたらそっちに意識を持って行かれる。
それまでの自分の中では今まで当たり前のように目の当たりにしてきた
少し嫌悪感を抱く行動だったけど、それが普通なんだと思えるようになった。
・走行中の電話は本当に危ないと思った。
でもみんな普通にやってるから、これもしばらくすれば慣れるのだろうか？
・結局大切な事は、メールでアポ取ってから行動するというスタイルが変わらなかった。
本当はもっとどこでもドアみたいなのを少し期待していけど
自分だけで見たらこっちのアドレスが携帯のそれになったぐらいの変化しかなかった。
一番期待していたのが期待はずれだった。
いつもイーモバ＆PCって言うのもあるかも知れない。
・「又電話する」って言う話の切り上げ方を身につけた。
なんだか知らないけれどだらだらした会話になりがちなので。
・布団の中でネットが出来るって素晴らしい。
・何故か大の途中にかかってくる、電話してると大がしたくなる場合が多いと気づいた。
結構音に気を遣う。
朝？
のらりくらりと、生きてきましたが。
ところで、ぼくは朝ごはんを食べるのか？
男の子だろ？ いいやそういう問題じゃなくって。
「盛り上がってる？」
「いいえ、そうでもありませんよ。ははは」
ぼくはふがいない自分を笑いつつ、ベンチに腰掛けた。
ぼくはあれか。そして、ベンチに腰掛けた。
「あれ？ ぼくはさっきベンチに腰掛けませんでしたか？」
「そうでしたね」と笑う。笑い合いもひとしおである。
その時であった？
ズガーン！
衝撃もひとしおであったその後、ぼくと唯ちゃんは急いでベンチに腰掛け
「唯ちゃん、無事か？」「ええ、私は無事ですか？」「ええ、無事です」
流した涙の数だけ物語はあるのだろう。
唯ちゃんの無事を確認しつつベルトを締めるやいなや激痛がトシキの息の根を
止めた。トシキは息の根を止められつつ反撃。お互いに鼻血まみれの顔でニヤニヤ
笑っていたのだろうか。
「まあ、座れ」「いやだ」「やめて二人とも」唯ちゃんの白い顔が黒く歪む。
トシキは観音座りをしてチャクラを溜めなさい。溜めなかった。どうするのか、
しないのか、それとも...？
「ふふ」どちらともなく、お互いをにらみ付けた。その刹那！ トシキの
そして、天空を調査する魔法のソナタはめくるめく砂漠のどまんなかで
いまだ見えざるアルテミスの物腰を柔ら柔らかにしつつ、堪えがたい刻の
いとなみを柔らかに見つめるといいね、と、トシキと加奈子は思った。
唯ちゃんは、あまり思わなかったのかねえ？ なんてね。
それはそうと今朝喰った目玉を離さない。もう離さないんだ。
西日が消えやがて夜明けだ。そんな真夜中の物語.....ＩＦ.....
http://anond.hatelabo.jp/20080718005952
いるんだよね、女友達と同じように男も男友達として付き合えると思っている奴。
でもさ、女友達と同じような付き合いは無理だって。
大体さ
一時期は毎日のようにメール交換（モーニングコールorメールから明日も頑張ろうメールまで）したり、月に2回は呑みに行ってた。
こんな事やっている男友達なんていね〜
間違いなくいね〜
こういうのがサークルクラッシャーになるんだよな。
敢えて突っかかってみるけど、「男友達」という言い方がどうも引っかかる。
一時期は毎日のようにメール交換（モーニングコールorメールから明日も頑張ろうメールまで）したり、月に2回は呑みに行ってた。
でも、恋人という感じではなく。
どう見てもバレバレじゃん。
気づいてたんでしょ。その相手の男は自分のことが好きだって。
でも自分はその相手と付き合うつもりはない。
だから「男友達」というカテゴリを用意して「恋人じゃないけど、仲のいい関係」を無意識に作ろうとしたんじゃないかな。
でも相手はそんな出来合いのカテゴリに収まりたいとは思ってない。
表面上はお互いに仲良かったんだろうけど、二人の間には心理的な見えない一線が存在した。
男の方はそんな関係を続けていくことが心苦しかった。だからメールの切れ目を境に、距離を置くようになった。
そんなところな気がする。
気持ちはわかるよ。自分も傷つきたくないし、そして相手も傷つかせたくない。
でもそれを「男の人って、どうしてあんなに分かりやすいんでしょう？」という言い方に転嫁するのは、やっぱり感心しないな。
男から見たら。
うちの彼氏(35歳)にそっくりです。
特にこの辺。
そもそも睡眠時間自体が長い。放っておかれれば12時間以上寝ていることはザラだし、予定のない休日は基本的に寝て終わる。更に言うと、ストレスのかかる状況におかれるとその過眠ぶりに拍車が掛かる。
休日のデートは11時頃待ち合わせとかでも3-4回に1回は寝坊して遅刻される。20-30分なんて可愛いもんじゃなくて、2-4時間のオーダー。もちろん起きるまで連絡は一切なし。15時とか16時頃に「ごめん、今起きた・・・」と電話があることもしばしばです。
実家暮らしなので平日は母親に起こしてもらってて仕事に遅刻したことはないそうです。
（でも休日は母親も寝てるので起こしてくれる人がいなくて起きれないって言われて目が点になった）
デートの日は起きた時点でメールをもらうことにして、ある時間までそれがないようなら私がモーニングコールしてみるとか試してみたけど、電話ぐらいじゃ全然起きてくれません。
休日のデート自体も映画観るか食事するかした後ラブホのフリータイムに入って（彼だけが）４時間ぐらい寝てるような感じです。そんなに眠いなら帰って寝れば？て言ってるんだけど、人が隣りにいてくれた方が落ち着いて眠れるから一緒にいて欲しいとか言われて、仕方なくその間は隣で本読んだり携帯ゲームを音消してやったりしてます。そういう時は確かに寝つきもいいし時間が来て私が起こすまでまったく目を覚まさないんだけど、別に普段も寝つきがわるいとか不眠に悩んでるとかいう訳じゃないそうなので、人が隣りにいるかどうかとかあんまり関係ないんじゃないかと本当は思ってます。
どれだけ改善して欲しいって泣いて頼んでも全然直らなくて、本当は私とのデートがストレスで会いたくないんじゃ？とか思ってたんだけど、こんな人が他にいるんだなって知ってちょっと納得しました。
でも納得できてもこんなんじゃ事前に映画の座席を予約することもできないし（今まで遅刻でムダにしたチケット多数）休日に公共交通機関を利用して遠出の旅行に行くこともできません。
紹介されてるような目覚ましグッズをプレゼントするしかないのかなあ。
