メイルは議論には向いてない

メイル(インターネット)を仕事で使ってます、って人は、もう日本中のほとんどがそうだと思いますが、筆者は、メイルは仕事には向いてない媒体だと考えます。
メイルとは何なのか？物理的サービスでは郵便に近いと思いますが、それより遥に速く届き、おまけに概ね無料です。とは言え、電話ほど速いわけではない。
つまり、郵便と電話の中間的な媒体。電報がまあまあ近いでしょうか。
メイル≒電報＋概ね無料＋返信機能。ここ重要です。

電報や手紙で、仕事の業務の細かい連絡ってしないでしょう？でもメイルではやってしまう。簡単に送信できるからです。
ただし、忘れちゃいけないのが電話＆手紙＆メイル＆電報は、本質的に私信なのです。内緒話なのです。でも仕事で「私信」って、あり得ないのです。本質的な問題がここにあります。

仕事なのに、内緒話じゃ、仲間がフォローできない。
言い換えると「共有しなきゃならないモノ」を「私信」で送ってることです。
だからccしてみたり、メイリングリストで運用してみたりですが、「全員に返信する」を全員が間違いなくやらなければなりません。
更に、今度は同じメイル文章が、個人のハードディスクと、メイリングリストアーカイブと多重に存在するので、ハードディスクの無駄とか、そういうミクロでケチくさい話もあります。

また、本質的に「手紙」であることが、業務の連絡としての運用を妨げます。居るでしょ？題名で名乗る人。ナカジマです。いや知ってます。
また、1通のメイルに、複数の案件を混ぜることも、頻繁に起ります。
取引先にインタビューしてみたところ、クライアントとしては案件単位じゃなくて、受注単位で考えてるみたいなんですね。だから題名はいつも一緒「○○の件」
これをやられると、メイルの分類が困難になるし、議論が派生したときに何の話か判らなくなる。

そういう意味では、返信機能をなくせばよいのかもしれませんが、残念ながら別の混乱が起るでしょう。

これによって、後期に参加した人が、メイルの議論を追いかけるのが面倒すぎるのです。返事を書くときの「引用」の慣例も、それに拍車を掛けてますね。例えば2000行の引用があって、下の方に大事な話が有った！とかとても探せません。

あくまで通常のメイル運用を維持したままでの話であれば、
この辺りの改善に積極的に努めてるのが、Gmailです。

• 引用の引用を折りたたむ機能があるので、新しく人間が書いた分に専念できます。
• メイル一覧に、本文の前半がチラっと出るので、緩い題名を書く人でも、内容の確認ができます。
• ラベル機能は、メイルの多角的な分類が可能になります。フォルダによる分類は、一ヶ所に入れるしかなかったけど、「○○様」「△△案件」「請求書」。いったいどれに分類すればよい？

ただし、これもベストではありません。全員が使わないと意味がない。
単純に、サーバサイドにデータを預けることに不安を感じる人も、非常に多い。
日本人に特に。

そういった現状を無視して、とりあえず筆者の案では、twitterがもっとも理想に近いです。

• メイルの題名は、事実上機能してない場合が多い→じゃあ要らない
• 引用は要らない→160文字制限とかでも結構いいんじゃね？
• 添付ファイルは便利だが、何度も添付しまくってどれが最新版だか？→別の媒体を使うべき
• ハッシュタグの概念は、Gmailのラベルに近く、分類には望ましい。

じゃあ、「twitterを仕事の連絡に使いましょう」そんな訳には行きません。メイルの唯一の利点は、私信であるからこそ企業秘密に使えてもいます。
ということは、twitter的な機能を提供する、プライベートチャットがあれば良いのではないか？

androidのgmailサポートは pushでは有りません syncです。

未だに誤解があるというか、「プッシュメール」を誤用しているというか。

「自分宛のメイルをすぐに確認できる」から「プッシュメイル」だと思ってる人が居ますが、結果の話しかしてないでしょう？何が「プッシュ」なんだ？って話が抜けてるんです。

「サーバに着信した個人宛のメイルを、個人端末に直接配送する」から「プッシュ」なのです。故に「 自分宛のメイルをすぐに確認できる」。

サーバから見て「押してる」わけですよ。本来はそういう意味です。

実際にht-03aを使ってみれば判りますが、gmailアカウントのサポートは、pushともpullとも言ってません。「同期」だと言っています。

故に、「androidはプッシュメール」は誤用です。っていうか、むしろ嘘です。意味が真逆だから。

似て非なる話。

iPhoneのMMSサポートも「プッシュ」だって話なんで、個人的にちょっと期待してたんだけど、ショートメイルの機構で、着信の事象を通知してるだけみたい。

メイル本文は、依然としてimapで取りにいくから、これもプッシュだとは言い難いでしょう。

結果として、本当の意味でのプッシュメイルは、日本の携帯電話では、ショートメイルだけですね。キャリアが自前の機能だけで実現してますから。

ショートメイルの機構を使えば、そのままプッシュメイルが出来そうなもんですが、日本の携帯電話キャリアと、プロバイダimapサーバは、本質的に無関係なので、当面は難しそうです。

しかし、そうまで「プッシュメイル」が必要か？って言ったら要らんでしょう。現実問題。どっちみち端末操作しなきゃメイルは読めない訳だし。「メイルは一時間以内に返信するのが友情の証」なんてただの強迫観念ですからね。

っていうか、勢いで書いたメイルって、後で読むと大抵恥ずかしいんで、5時間ぐらい推敲することをお勧めします。

appengineの制限は、グーグルにとっても制限

この記事の内容は既に古く、有料に限り(無料分はありますが、どうせ週$2取られるので)、専用インスタンスを無限に動かせるようになってます。
https://developers.google.com/appengine/docs/python/backends/overview?hl=ja

ただし、小生のスタンスは変わってないので、この記事自体は据え置きます。

---

基本的には、「30秒も要らねえよ」ってスタンスなので、解決方法は書いてません。それを探しに来たかたは悪しからず。

http://code.google.com/intl/ja/appengine/docs/roadmap.html

appengineのロードマップ的には、taskqueueやcronに限り、30秒ルールを撤廃する可能性があるらしいのですが。筆者はあまり困ってません。「悩まされてるデベロッパー」ってJavaで書いているのんじゃないでしょうか？

筆者はJavaは遅い、と思ってます。JSPの、「あー今コンパイルしてるな」なタメ時間もあり得ません。スピンアップ時間の無駄使い。

「スピンアップ終わったら、速いんだよ」とか言わない事を祈ります。そりゃあ当たり前というか。全部遅かったら目も当てられない。多分アナタも使わないでしょう。

ちなみにpythonの「スピンアップ」は2秒ぐらいっぽい。速いと見るか遅いと見るか。

もしくは、Slim3というフレームワークが速いらしいので

http://sites.google.com/site/slim3appengine/

使ってみたらどうかと思います。ひょっとしてそれで済む話かもしれません。

そもそも、appengine は、社内で使ってるクラウドの一部を切り売りしているだけ。の筈。グーグルでも30秒ルールに従ってるのです。

datastoreの実装も、「あーこれならGmail作れるな」というものばかり。ラベルは、StringListProperty使ってるんだろうな。とか。

フツーのRDBMだったらリレーション使うところはReferencePropertyで、かなりやっていけます。またはModelクラスのメソッド実装で引っ張ってくるとかね。発想の転換が大事です。

1回のトランザクションで、データを1000個しか取り出せないのもグーグルにとっても同じです。Gmailや、Readerの件数表示が、1000以上は表示できないでしょう？件数も詳細を出さないで、800件ぐらい、とかサボってます。

と言うわけで、30秒撤廃は、グーグル内部のサーバ運営の根幹に関わるのでそうそう簡単では無いでしょう。想像ですが。

まあグーグル自身がやる、って言ってるんで可能性は0ではありませんが。まあ有料Quotaでしょう。

同じく、MapReduceをサポートするかもしれない！とか喜んでいる人が多いですが、何をするつもりなんでしょう？

#db.Model.count()が遅いから。じゃないですよね。

っていうか、

Support for mapping operations across datasets

って書いてあるんだけど、これってMapReduceなの？

違うんじゃね？

仮に使えるようになったとしても、無料はあり得ない。端的に言えば、MapReduce Quotaという項目が増えます。

30秒ルールとは別の意味で、

想定以上のリソースを食いつぶされる可能性がありますからね。

グーグルのファイル共有サービスは日本人には難しいか

仕事上の都合で、

取引先の担当者と、グーグルドキュメントの共有を試みました。

結論から言うと、まるでうまく行きませんでした。

「ドキュメントに入れておきましたよ」って言っても

何時のまにか忘れてしまって、

メイルで着信している分から探したいらしいですね。

結局、メイル添付での運用に戻ってしまいました。

日本人は、マイクロソフトが

Outlook Expressをオマケで付けたお陰で、

メイル添付に慣れきっています。

わざわざ、webサイトを開こう、って気はまるでない見たいですね。

#メイル添付ファイルでの運用は、問題点だらけなのですが、

#それに気づかずに、頑張ってしまうケースが殆ど。らしい。

#その証拠に、「○○管理用.xls」って一杯作ってるでしょう？

「Gmailアカウントを持っている」というだけじゃ駄目らしい。

結局、「Gmailを常用してます」って人しか残らない。今のところは。

この辺りを何とかしないことには、日本では中々普及しないでしょう。

それを痛感しました。これはグーグル系に限った話では無いでしょう。

Windows 7から、Outlook Expressの付属を辞めて、

Windows Liveに移行して欲しい感じですが、

日本市場に関して言えば、しばらくは無理に思います。

理由は前述のとおり。

Gmailに慣れた筆者には、微妙なwebサービスでした。

という側面もあったりします。

インターネットエクスプローラとファイヤーフォックスとクロームとグーグルの関係

重い重い、と言われているFirefoxですが、
理由はハッキリしています。
「Windows向けの裏技を使ってないから」です。

InternetExplorerは当然使っています。
裏技って何か？
Internetが付かない、エクスプローラは、
実はInternetが付く方のプログラムの殆どを包含してるのです。
#この表現は厳密ではありません。説明用です。

InternetExplorerの3まではそうでもなかったのですが、
InternetExplorerの4からそうなりました。
Windows98辺りから、アクティブデスクトップとか言い出したでしょう？
デスクトップにHTMLを貼り付けられる。
それはそういう事です。

http://msdn.microsoft.com/en-us/library/aa741312(v=vs.85).aspx

一昔前のモバイルノートPCは、WindowsXPでメモリ512MB、とかなので、
「Firefoxは重いからIE使ってる」となるのも無理からぬ事です。

しかし、起動しちゃった後の方が問題です。

IE7未満は、他のブラウザに比べて、javascriptエンジンが遅いのです。
具体的には、文字列連結処理が遅い、らしい。
文字列連結って何か？

webの殆どはHTMLで書きますね。
HTMLの一部をjavascriptで切ったり貼ったりできます。
サーバに一括でHTMLを作るんじゃなくて、ブラウザ側で自分で作り直すんですね。
ブラウザに処理させる、って言ったら、現状はjavascriptしか選択肢が無い。

サーバとPCとの、データの行ったり来たりがゴッソリ減るので
レスポンスが良くなる、
だけじゃなくて、インタラクティブな操作が出来る。それがajaxです。
もう何年も前ですが、グーグルマップの登場は衝撃だったでしょう？
ajaxの真骨頂です。
javascriptの株が、大幅に上がりました。あれで。

javascriptは結構おもしろい言語です。
画面をフェードしたり、ポップアップボカボカ出したり、だけが脳じゃないんです。
グーグルマップの様な、高度な実装もちゃんと書ける。
この辺りは話すと長いので。

HTMLは文字列です。切ったり貼ったりは文字列処理です。
それが遅い、と言ったら、イマドキのajaxのサイトが遅い、のと同義です。

まあ普通の、日本国内のwebサイトを見ている分にはIE7でも平気ですが、
Gmail等、グーグルのajaxサイトは、
javascriptの限界に挑戦しちゃってますので、
Gmailが遅い、から使いたくない、という話になっちゃいます。
実際に、そういう人は多いです。

「IE7でGmailが遅いから、メモリを買ってきた、2GBにしてるのにまだ遅い」
知人がそんなコントをやってました。

#話の流れてきには、「ここでFirefox」と言いたかったのですが

面白くないのグーグル。
Gmailが重いのはオレらのせいじゃねえよ、と思ったかどうかは知りませんが。
Chromeを作りました。

試してみてください。馬鹿っ早いです。
512MBでも実用になるはずです。

一方、Chromeは「webサービスの利用」に特化しているので、
ブラウザとしてはかなり機能アッサリです。

InternetExplorer8では、文字列処理の速度が大幅に改善してます。
アップグレード出来る人は、アップグレードするべきでしょう。
マイクロソフトもアップグレードさせたがってるでしょ？

ただそれでもFirefox3とかChromeには追いついてないらしいですが。

Firefoxが重いのはまた理由が違います。
Firefoxがマルチプラットフォーム対応なのに関係があります。

マルチプラットフォームブラウザを実装するにあたり、
マルチプラットフォームフレームワークを開発した、らしいんですね。
XULナントカって奴、らしい。
http://ja.wikipedia.org/wiki/XULRunner
https://developer.mozilla.org/ja/docs/XULRunner/What_XULRunner_Provides

Firefox内部は、結構javascriptで動いてます。
エクステンションがドッサリありますが、これらはすべてjavascriptで出来ています。
https://addons.mozilla.org/ja/firefox/

ただwebを見るためのブラウザとしては、考えすぎとも言えます。
この「考えすぎ」部分は、当然、ある程度はメモリを食います。だから重い。

故に、エクステンションを使わない人は、
FirefoxのHTMLエンジンだけを抜き出したブラウザが幾つかあります。
HTMLエンジン単体は、mozillaプロジェクトの中の、geckoという単体製品なので、
スキルがあれば、他の製品に組み込めるわけです。
http://ja.wikipedia.org/wiki/Gecko
https://developer.mozilla.org/ja/docs/Gecko

むろん、mozillaプロジェクトとして、そうして欲しいわけです。
https://developer.mozilla.org/ja/docs/Embedding_Mozilla

例えば、K-meleon http://kmeleon.sourceforge.net/
InternetExplorer並の軽さ、しかもGmailも快適。
ただしWindows版しかないけど。

と言うわけで、IE7未満以外を使えば、Gmailが快適に使えます。

メイルの整理で、フォルダに完全分類は無理

筆者は、5年前ぐらいから、完全にGmailに切り替えてしまいました。
古典的なフォルダに相当する概念として、ラベルがあります。
逆にフォルダ機能はありません。
特に、アウトルック利用者で、これに抵抗を感じる人は多いですが、
いや本当に貴方、メイルの整理できてますか？と聞きたい。

ファイル類の整理と言うのは、普通は「○○の件はココ」と決めて、
そこに置くことです。これはもう紙文書のファイリングの延長線上の運用です。

受信箱の下層にフォルダを作って、自分で運ぶ。
「○○株式会社様」とかね。

しかし、直接取引ならともかく、代理店や中請けが挟まると、もう駄目です。
大抵メイル1通に、複数クライアントの話を混ぜてくれます。
結果として、クライアント名での分類は、無理です。

じゃあ案件名で。それも無駄です。
元請けさん的には、大抵クライアントは1軒一括り。
だからその調子で下請けにも連絡してしまう。らしい。

結果的に、「フォルダに分類」を諦めて、受信箱にメイルがドッサリ。
「アウトルック最近起動が遅くてさー」目に浮かびます。

この通り、普通にメイルといっても、複数の切り口があり、
「○○の件はココにあります」っていうフォルダベースは無理です。
複数のフォルダにコピーしておくのも気持ち悪いですね。

そこでラベルです。
まあ、メイルに貼る付箋紙みたいなものだと思いねえ。

前述の例で行くと、「○○代理店」「○○株式会社様」「○○システム」
ラベルを3枚貼れば良いわけです。それで整理は完了です。
少なくとも矛盾は出にくいことは、お分かり頂けるでしょう。

これの肝は、「メイルの実体は何処にも動かしてない」ところです。

後は、特定のラベルが付いているものを、抽出する機能があれば、
フォルダに整理したのと似たようなものです。

コンピュータならではの方法ですね。物理文書ではこうはいきません。

メイルソフトでもラベル機能を実装したものはあるかも知れませんが、
筆者はGmailに出会って、それ以外の選択を放棄しています。

「済んだ案件は、受信箱から見えなくなってほしい」なら
「アーカイブに送る」を使えば良いです。

しかも、Gmailは検索機能が強力。

アウトルックを使っている人は、アウトルックの検索能力を信用してないので、
日付でソートして、肉眼で探すくせがあるようです。
「そのメイル、何時送った？」って口頭で聞いてきます。意味ないです。
私のサンプリングが偏ってるのでしょうか？そうであって欲しいです。