[2792] マイクロソフト化するGoogle──Google Buzzに望むこと

投稿:  著者:


《twitterと同様に見えるようなサービスは不要》

■KNNエンパワーメントコラム
 マイクロソフト化するGoogle──Google Buzzに望むこと
 神田敏晶

■クリエイター手抜きプロジェクト[231]電子書籍編(5)
 PDFの販売まで
 古籏一浩

■子だくさんIT社長のFileMaker日記[02]
 CSVファイルを扱おう
 茂田カツノリ

--PR------------------------------------------------------------------
★DTPの情報なら、まずはここからチェック!『DTPサポート情報ブログ』
│ ≫≫≫ http://blog.ddc.co.jp/mt/dtp/
≪≪≪  用語集もあるよ!
└--------------------------------------------------------------------
★印刷見積/印刷企業PRの印刷ビジネスマッチングサイト『PrintJapan.com』
│ ≫≫≫ http://www.printjapan.com/
≪≪≪  無料登録受付中!
└--------------------------------------------------------------------
■運営:株式会社吉田印刷所(TEL:0250-43-6144) http://www.ddc.co.jp/

-----------------------------------------------------------------PR---


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■KNNエンパワーメントコラム
マイクロソフト化するGoogle──Google Buzzに望むこと

神田敏晶
< https://bn.dgcr.com/archives/20100215140300.html
>
───────────────────────────────────
KNN神田です。

ソーシャルサービスでは、ことごとく失敗しているGoogleだが、ここのところ、どこか「マイクロソフト化」きているような気がしてならない。

Google Wave
< http://wave.google.com/
>
にしても、今回のGoogle Buzz
< http://buzz.google.com/
>
にしても、ユーザーに、「こう使えば便利!」という提案がなされていないままなので、カオスの世界に投げ込まれたような気がする。

当然、twitterのような機能のフィーチャーは、さっさと実装しておけばよかったけれども、市場が成長してから参入する。もしくは、買収するという「マイクロソフト化」の発想でいたのかも知れない。

「Google Buzz」のコンセプトを動画などのデモで見ても、実際にどう使えばいいのかが、直感的に理解することができない。また、せっかく有料のGoogleAppsに切り替えたばかりなのに、無料のGmailにしないとこのGoogle Buzzが使えない。有料ユーザーの方が、無料のユーザーよりも選択肢が減るというおかしな状況だ。

最近の Googleは、一体、何を一番、ユーザーに、おすすめしたいのかがまったくわからなくなってきている。

実験的なアプローチであれば、
GoogleLabs
< http://www.googlelabs.com/
>
でもよかったはずだ。

Gmailというユーザーに一番近いサービスに、わざわざGoogle Buzzを組み込んできたということは、かなり本腰を入れたサービスとして考えることができる。

ただ、直感的に使えず、シナジーが見えてこないものが、ある日突然、画面に現れるのは考えものだ。しかも、ヘルプを見ても、何の役にも立たない「マイクロソフト化」が進化している。

twitterと比較すると、いくつかの差があるが、一番の違いが、twitterの「タイムライン」に対して、GoogleBuzzは、「スレッドライン」であるところだ。これはGmailの特徴的機能であるから、重なった「スレッド」での実装は、けっして悪いアイデアではない。

しかし、読んでも読まなくてもいいtwitterのゆるさがそこにはなく、Gmailに内包されているせいかも知れないが、読まねばならない...、あとで読む...というような使命感や債務が発生している点がとても気になる。

twitterと同様に見えるようなサービスとtwitterとの差は、もはや機能の差ではなく、twitterというプラットフォーム上に存在するユーザー数の絶対数の違い、いやフォローとフォロワーの実にゆるやかな関係の上に成り立つ社会観だろう。

twitter同様のサービスは不要であり、差別化される必要がある。

Gmail のBuzz機能としては、SPAMメールや読まない企業メルマガのフィルタリングツールから、もっとmailのリアルタイム化に特化すべきではなかっただろうか。文字数を限定することによって、楽になったtwitterを考えれば、twitterのDMの140文字ではやりとりできない部分をGoogle Buzという機能で補完すべきだったと思う。

ボクがGoogleのエリック・シュミットであれば、Google Buzzは、twitterアカウントとGmailアカウントを連携するbit.lyのようなツールとして開発を指揮しただろう。

twitterアカウント名を、Buzz側で打てば、bit.lyのように、相互フォローしている相手側にGmailアカウント名が表示され、gmailへのメールへもリンクされるというような連携のほうがtwitterユーザーにとっては有益だろう。

twitterのDMの中で、bit.ly的な「Buzzリンク」をクリックすれば,Gmailでのメッセージが表示される。twitter側で迷惑メールのアカウントをアンフォローすれば、Gmailにも届かなくなるとか...。

Google側も読まれていないメールの各人のフィルタを覚えて、それを毎度、管理している手間が不要となる。メルマガを出す企業も、読まれていない読者数をカウントする必要がなくなることだろう。

GoogleからTwitterへのツイートという一方通行ではなく、twitterのDM部分を拡張する、ExtentionとしてのGoogle Buzzに期待したいものである。

KandaNewsNetwork,Inc.< http://www.knn.com/
>
〒251-0037 神奈川県藤沢市鵠沼海岸7-10-12 グランドソレーユ105
KandaNewsNetwork,Inc. 代表取締役 神田敏晶
Mobile 81-90-7889-3604 Phone81-3-5458-6226

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■クリエイター手抜きプロジェクト[231]電子書籍編(5)
PDFの販売まで

古籏一浩
< https://bn.dgcr.com/archives/20100215140200.html
>
───────────────────────────────────
今回は電子書籍編の最後、販売について説明します。原稿を書いてレイアウトや校正を自動化して、PDFまで作成したとしても、販売できなければ意味がありません。

電子書籍、今回はPDFなのでデジタルデータを販売できるところであれば、どこでもよさそうです。デジタルデータを販売しているところは、探せば(同人ソフト販売サイトなども含めれば)結構あります。

しかし、いわゆる情報商材を扱っているところは極力避けないといけません。というのも、情報商材と同じようなものと見なされてしまうためです。例えば、情報商材を多く扱っているインフォトップなどです。

・インフォトップ
< http://www.infotop.jp/
>

また、スクリプトやデータを含めるとかなり大きいサイズになり、ZIP圧縮しても67MBほどなので、このようなデジタルデータを販売できるところは少なくなります。とりあえず、今回は巨大サイズのZIPデータもOKなデジコンカートにしました。

・デジコンカート
< http://haishin.tv/dccart/
>

また、これ以外に伝統的な代引きも用意しました。ずっと前から使っている、クロネコヤマトの代金引換です。CD等にデータを焼いて送るだけなので、あまりコストもかかりません。

代金引換
< http://www.yamatofinancial.jp/service/co_3.html
>

デジコンカート、代引きともいくらかの手数料が引かれます。デジコンカートだと販売価格のうち26.25%が手数料になります。クロネコヤマトだと1万円未満では315円+運賃で、だいたい1,000円くらいになります。どのみち印税率よりかなり良いことは確かです。

書籍の場合、本の価格に対して6%〜10%くらいが著者の収入になります。5,800円の本であれば1冊売れれば580円の収入になります。といっても、出版不況で印税率はかなり下がっていて、よくて7%くらいになっています。これだと1冊売れると406円になります。

これが25%引かれるデジコンカートであっても、1冊売れれば約4,300円になります。また、今は日本語の電子書籍は扱えませんが、アマゾンで販売可能になった場合には35%ほどになるようです。5,800円なら1冊売れると2,030円になります(実際にそこまでの割合になるかどうかは正確にはわかりませんが。また、ここらへんはiPadの関係もあり流動的な部分とも言えます)。

・個人が印税35%の電子書籍を出版できる時代(in the looop)
< http://blogs.itmedia.co.jp/saito/2009/12/235---amazon-ki.html
>

ただ、ニッチな書籍の場合、売れる部数は極端に少ないので1冊あたりの収入が多くても、トータルではほんのわずかな金額にしかなりません(紙の書籍の場合は最低でも2,000部くらいは刷る)。その点、紙の書籍の場合は著者が保護されている面もあります。最低の収入金額が保証されているからです(出版社が潰れた場合は別)。

つまり紙の本であれば最低収入は確保できる、自前で出した電子書籍だと、最低収入すら保証できない。しかし、売れれば大きいということになります。もっとも著者の場合、紙でも電子書籍でも売れれば収入は増えます。そうなると、売れるかどうかさっぱり分からない電子書籍よりも、最低収入が見込める紙の本の方がよい、といった事になります。

実際にここまで作ってみると、販売までの労力はかなりのものです。特に自前で自動レイアウトするスクリプトなどを作ったせいもありますが、このようなことを普通の著者に求めるのは無理があります。そこまでしても、売れるかどうかさっぱり分からないわけですから、まさに丁半博打です。

こうなると、出版社がいかにうまい仕組みを作るかにかかっています。ただ、上記のアマゾンを経由して販売すると出版社があまり儲かりません。儲からないとリスクを取りにくいですから、アマゾン以外で販路を作って収益を確保するなどしないと、アマゾンだけは儲かるけど、なぜか出版(社)不況が続くといったオチもありえます。そして、アマゾン以外にもiTunes Storeになっても状況はあまり変わらないかもしれません。

電子書籍の普及でもっとも割を食うのは印刷会社でしょう。電子書籍になれば印刷自体がほぼなくなってしまいます(電子書籍を印刷してくれ、という需要は非常に少ないでしょう)。まあ、日本では電子書籍がうまく普及するかどうかも分かりませんので、ゆるやかな衰退ということになるのかもしれません。また、教科書などは紙のままでしょうし、行政関係は紙の方が低コストで済むということもあります。

衰退とは逆に、力を求められるのは編集者でしょう。どちらかと言えば、売れるか売れないか、継続できるかできないか、うまくいくかどうかは編集者に大きく依存しそうです。ただ、裏を取る、確認調査をする、市場の動向を調査するなど雑務も多いので、そうなると複数の編集者か、やはり出版社などの組織力が必要になります。

実際のところ、自分で書いて自分で出すと思い込みで書いてしまったりすることもあります。また、他環境での確認ができないため、編集者の確認作業などが入る一般書籍と比べて、動作の安全度が落ちるというのが実感として分かります。

何にしても、電子書籍は始まった(何度も始まっている気もしますが)ばかりですし、いろいろ試行錯誤してみるしかないのかもしれません。

【古籏一浩】openspc@po.shiojiri.ne.jp
< http://www.openspc2.org/
>

発売中です。
「Adobe Illustrator CS3 + JavaScript 自動化サンプル集」
< http://www.openspc2.org/book/PDF/Adobe_Illustrator_CS3_JavaScript_Book/
>
(目標販売部数は無事に超えました。どうもありがとうございます)

毎度おなじみアスキーの連載もよろしく。
・画像の自動アップロードもJavaScriptにお任せ!
< http://ascii.jp/elem/000/000/497/497020/
>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■子だくさんIT社長のFileMaker日記[02]
CSVファイルを扱おう

茂田カツノリ
< https://bn.dgcr.com/archives/20100215140100.html
>
───────────────────────────────────
最近Twitterが盛況だ。僕もアカウントを取ったのは3年ほど前だが、当初は日本人いなかったので英語の練習場、くらいに思っていた。そしたら昨年末くらいから急激に日本人ユーザが増え、元来コミュニケーション好きな僕は思いっきりハマっている。役に立つしね。

TwitterそしてUstreamのブームで、デジクリ著者の方々も活躍の場がより広がりそうな感じになってうれしい。本来、神田敏晶さんのような方がものすごおくお金持ちになられるのが、いい世の中だと僕は絶対に思うのだ。という話とは関係なくて、今回はCSVについての基礎的というか前提的な話。

●CSVの定義を一応再確認ね

「CSV」とは「Comma Separated Values」の略称で、データをカンマ区切りで並べた形のテキストファイルのことだ。

"150-0001", "東京都", "渋谷区","神宮前9-99-9","茂田ビル100階","株式会社レクレアル"

という感じで並んでるデータのことだ。各項目を囲むダブルクォーテーションはなくてもいい。そしてデータ1件ごとの区切りには改行が入る。

という誰でも知ってそうなことをわざわざ書いたのは、以前ちょっと仕事を依頼しようとした相手との会話で、僕は基幹システムとのやりとりを固定長テキストでやるってゆってたのに、その人は「CSVで」と勝手に話を進めて全然かみ合わなかったことがあるからだ。結局、テキスト形式でデータを渡すのは全部CSVと呼ぶもんだと思ってたらしい。知らない用語に出会ったら辞書くらい引いてほしいものだが、こういうのも仕事に取り組む姿勢のひとつだなと判断し、この人物に依頼するのはやめたのだった。

ほかの例でも、いわゆるTAB区切りテキストなのに「.CSV」って拡張子付けてよこすからFileMakerで読めなくて困った、なんてこともある。これはすぐに気づいたが、ウソが含まれるのは困るものだ。

ちなみに、FileMakerはインポートについては、正直に拡張子をみて形式を判断する。実際のデータ形式と異なる拡張子が付いていると、エラーが起きたり読み込みがずれたりするのだ。一方Excelの場合は、拡張子は信じずに形式で判断するので、Excelなら開けるのにFileMakerでダメだった場合は、拡張子がウソかもしれないので確認しよう。

●CSVファイルを取り込む方法

CSVデータをFileMakerに取り込むには、以下の3つの方法があるので、その特徴も含めご紹介しよう。

1)直接開く
CSVデータをFileMakerで直接開く。さくっとFileMaker形式に変換してfp7形式のファイルになるので便利。変換も結構速い。

2)既存テーブルにインポートする
あらかじめ取り込み用テーブルを作っておき、そこにインポートする。フィールドを定義しておかねばならないが、そこに当てはめる形なのでどんどん発生してくるデータを追加インポートする際には便利。

3)既存データベースに新規テーブルを作成しインポートする
既存のFileMakerデータベースで「レコードのインポート」を行うのは2)と同じだが、インポート画面でのテーブル選択で「新規テーブル」を選ぶ方法。テーブルの追加ができるというわけだ。余談だが、この方法でFileMakerファイルをインポートすると、計算フィールドや集計フィールドについても式や設定がそのまま取り込める。バージョン6以前で、複数ファイルに分かれていたものを統合するときに便利だ。

●CSVファイルを扱おう

手始めに、郵便番号の一覧CSVを下記からダウンロードし、FileMakerで開いてみてほしい。
< http://www.post.japanpost.jp/zipcode/dl/kogaki.html
>

全国だと12万レコードほどになるが、このくらいならFileMakerで軽く扱えることがわかる。インポートについては、テキストファイルとしての扱いになるため若干の時間を要するし、インポート後の最初の検索では索引生成の時間を要するが、その後はこのくらいの件数なら検索も一瞬でできる。

ちなみに、日本語を含むテキストファイルのインポートにおいては、文字コードはShift-JISであることが多く、それならFileMakerでのインポートも問題ない。UTF-8でもまず大丈夫だ。ただし、ときおり文字コードの判別がうまくいかないこともある。直接開く場合はコード指定をする画面を通らないが、インポートにおいてはコード指定が可能。データのプレビューをみて、文字化けしないようなコードを選択すればよい。

FileMakerに取り込んでしまえばこっちのもの、あとは分類別に集計をしたり、データを加工したり、形式を変えてまたエクスポートしたり、いかようにもできる。

FileMaker内にあるデータをCSVテキストファイルとして書き出すには、レコードのエクスポートを使えばよい。この場合、エクスポート指定したフィールドについて、対象レコードすべてのデータを書き出すという動きになる。1レコードだけ書き出したい場合は、対象レコードをそれだけに絞ってから書き出せばよい。

CSVへのエクスポートで気をつけたいのが文字コード。デフォルトだと「Macintosh(英語)」となってしまい、このままでは日本語が文字化けするのだ。ちゃんとShift-JISまたはUTF-8を選ぶのを忘れずに。

なお、書き出し先のディレクトリやファイル名が決まっているなら、それを「file:ディレクトリ名/ファイル名」という形で変数に設定し、それをエクスポート時に使うという形で、ファイル名と書き出し先とを指定することが可能。これはインポート等でも使え、ファイルのリネームをFileMakerで行うなんてこともできる。

CSVの取り扱いは、日々の業務において重要かつ手間のかかる部分となっていることが多く、それだけにFileMakerで省力化することで、業務効率の改善に大きく寄与することが多い。CSVならExcelでももちろん扱えるが、より自動化を進めたいならFileMakerを使うことがお勧めだ。

インポート/エクスポートには、HTMLの改行コードを設定するなどのさまざまな小ワザがある。このへんはちょっとメルマガだけでは紹介しきれないが、僕のトレーニングではよく扱う題材なので機会があったらぜひ(宣伝)。

【しげた・かつのり】FileMaker公認トレーナー/FileMaker認定デベロッパー。
株式会社レクレアル代表取締役。先日、ある小説家の方から取材を受けた。なんか嬉しかった。
Twitter(個人用)< http://twitter.com/shigezo
>
※※FileMaker情報メルマガ配信中!登録は以下で※※
< http://www.recrear.jp/
>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■編集後記(2/15)

・上村愛子、惜しかった。表彰台映えする美貌だったのになあ。「日本の評価を下げてくれた(かもしれない)オリンピック選手がいる。あのスノーボード兄妹だ。彼らのパフォーマンスを見て、いやーな感じを抱いた人は多いと思う。熱血を冷笑するという近頃のさめた風潮とはまた別の、なんとも言いようのない不快感だ。まさしく「人は見かけによる」のだな。親の顔が見、たくもないが。きちんと教育しないで、世界の舞台に送り出した大人たちの責任は重大だ。同じ日本人として恥ずかしい」と書いたのは4年前の今日だった。また同じような不快感が、同じスノーボードの選手によりもたらされた。日本からバンクーバーに移動するときの、国母選手のだらしない姿をテレビのニュースで見たときは、「このバカをカナダへ行かせるな!」と思い、その後の会見で、全然反省の様子も見せずにおちゃらけているのを見て「このバカをさっさと帰国させろ!」と思ったものだ。JOCに国民からの抗議が殺到したというが当然だろう。橋本聖子団長が責任を負うかたちで出場を認めたが、その会見でもきちんと反省していないように見える。「自分にとって五輪はスノーボードの一部で、特別なものでない」なんてコメントも、ずいぶん無神経である。オリンピックには多額の税金を投入しているのだ。自分だけ目立てばいいやと思っているらしいこのバカを「仕分けしろ!」。監督やコーチなど、身近な大人がきちんと指導すべき問題だ、と思ったら国母選手は4年前もトリノで問題を起こしていて(その当時は子どもだからともかく)、いまは21歳でヨメもいるというではないか。だめだこりゃ〜。すべて自分一人で責任とれって。(柴田)

・先週、Google BuzzをTwitterのGoogle版と書いた。使ってみて、これはTwitterより掲示板だと思った。Twitterで不便だと思うところを変更していったら、人より話題が中心になっちゃった。たとえば一つのツイートの話題を掘り下げたい、(ハッシュタグがなくても)あとで一覧したい、そうだ自動的にメールもくればいいのに、で、そのメールも検索できていいよねとか、タイムライン未読はたまる、面白い話題を見逃したくないから、コメントのついたホットな話題は上位に持っていきたいとか、文字数上限を増やしたい、後から修正かけたい、動画や画像も扱いたいとか。私個人としては、自動翻訳機能をつけて欲しいとか、フォロー機能はいらないからカテゴリを作ってくれとか、スター機能(お気に入り機能。メールで一元管理すれば不要ともいえるが)が欲しいとかの要望がある。匿名(といってもアカウント固定なのでペンネームのようなもの)と実名入り交じった、グローバルで動画や画像の扱える巨大掲示板に成長すれば面白いのになぁと。(続く)(hammer.mule)