  |
はてなキーワード: データソースとは
大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。
悪く言えば自分の能力に絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。
相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。
本来の業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。
せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。
プログラミングの経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドでVBAから、Rやら自社製品の解析用環境の割と珍しいタイプのスクリプト言語など（特定されそうだからぼかすけど。）
とりあえず手が出せそうなものは何でも調べてみてありものを改造してみたり勝手に作ってみたりして提案していた。
物怖じしない新人がぎゃーぎゃー騒いでいるぐらいのものだったと思うが、何にせよいくつかの改善が上手く実務にハマって成果として認められたりしだしたのが1年目。
この辺で気付いたことだが、製造業のITリテラシーは驚くほど低い。製造業と一般化するのはフェアじゃないかもしれないから厳密に言えば弊社の、という意味だが。
なんせまともにプログラムを書いたことが無い新人が半年で身に着けた程度のスキルで書いたプログラムで、1日かかってた仕事が1時間で終わったりするのだ。
ようするにMS officeの達人みたいなのがいっぱいいて、Ctrl+CとCtrl+Vが機能のすべてだと思っているということだ。
（そして彼らの口癖は「忙しい」だ、会議中も左手はCtrl+CとCtrl+Vを叩き続けている。）
2年目に気付いたのは、弊社エンジニアのITリテラシーが低くとどまっている要員のひとつに、実はITインフラチームがことのほかマトモだということがある、ということだ。
製造中のセンサーデータやらテストデータやらETL的にはおそらくえげつない部分で、かなり優秀な人間が居て上手くぶん回し切っている様子だった。
無骨だが使いやすいイントラ上のwebページが用意されて、グロテスクな部分を気にせずクリックだけで上述のデータを整ったものとして引っ張ることができた。
だから逆に言えば下々の人間はコピペでなんとか恰好を整えられるのだった。
彼らはモダンな発想があって、あるいはお偉いさんが「ビッグデータ」とか言い出したのかもしれないが、ともかく、HadoopやらAWSやらそういったものを導入しようと試みているらしかった。
私はそれに感動した。なんせWebスクレイピングみたいな方法で他人が社内プラットフォームや社内WIKIに上げた報告をまとめたり、製造時データと紐づけたり、それからグラフ描いたりみたいな業務が増えていたからだ。
それっぽく表現すればデータ分析屋さんということになるのだろうが、どぶをさらっているという表現のほうが近かったかもしれない。
何にせよそういったものを一気通貫、自動化できるポテンシャルがあると感じられた。
SQLもjavaも書いたことなんて無かったが、1年前やっていたことを考えれば同じことだ。何にせよ歓迎だった。しかも管理はIT持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。
ところがその「ビッグデータ」プロジェクトは人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。（あとで聞いた話、外部コンサルで外れを引いたらしい）
自分もドメインの知識からの助言とか想定される使い方についての意見を伝えていったし（有難迷惑だった可能性は否定できないが）、もう少し待てばモノになると信じていたし、実際そうなった。
具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果の確認の為に数十億行のデータが活用された。彼らの力が無ければ常識的な時間では終わらなかった仕事だった。
残念だったのは彼らの優秀さの割に一般のエンジニアのスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。
そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。
もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社（厳密にはその親会社に）に買われることになった。
そういう時に起ることは不要な冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署が相手側にも存在するということだ。
つまりどちらにもある部署は統合するか一方を無くすかという戦争が始まるのだ。ITも例外ではない。（ITインフラ部署の無い会社はさすがに無いはずだ）
一方で製造業の本懐である「製品を作り、売る」という部分は比較的守られる。それこそが根源的な資源であり、利益を生む仕組みであり、既存の顧客への説明が必要だからだ。
そして私の仕事は歩留まり改善であり、故障解析であり、データ分析だ。何が起こったか。
（ここで簡単のために旧弊社を（旧）A社、買収した側の競合他社を（旧）B社と呼ぶことにする。）
今の旧A社から引き続いている業務をB社のプラットフォームで行えるように転換せよという下命である。
旧B社の製造データに対するアプローチはA社とまったく異なっていた。Web UIは美しく整っており、それっぽいグラフが簡単に表示され、A社側のお偉いさんからも好評を得ていた。
だがそのバックエンドは控えめに言って酷いモノだった。いくつもの情報を正常に保存できておらず、「それっぽい何か」を素早く返答することを第一義としているように見えた。
そして上述のように器用貧乏街道を歩んできた私に投げられたのは次の言葉だ
「増田くん、B社のプラットフォーム使うことは決定事項だから、君が自動化してたやつ全部そっちで動くようにしといて。よくわかんないけどプログラムとかてきとうにできるでしょ？」
もちろんhtmlもjavascriptもphpもRoRも一行も書いたことが無いのが当時の私である。
果たして旧A社のプラットフォームはB社のプラットフォームのデータソースのような扱いを受ける羽目になり、私はjavascript本格入門を片手にB社の事業所に出向くことになった。
そこで散々「旧A社のプラットフォームは遅い・使いづらい・不安定」と貶されながらチマチマとグラフを表示するページを書いている。
クオリティの低いバックエンドを作る集団が書いているサーバーサイドphpの酷さは素人目にも分かるレベルで筆舌に尽くしがたいものがあるが、
反面教師だと思って耐える日々だ。
最近分かったことは旧B社のバックエンドスクリプトがデータを引っ張るついでに意図的に旧A社のプラットフォームを攻撃しているということだ。DDoSとまでは言わないが、悪意100%である。
いわく旧A社のプラットフォームを畳むためには旧B社のプラットフォームが優秀であることを示す必要があるとのことである。（つまり旧A社プラットフォームが不安定かつ重くなることを意図しているらしい）
旧A社から継続されてる業務はまだそこ使ってるんですけど・・・
それはもちろん旧A社の上司に報告したが「見て見ぬふりをしろ」とのことだった。旧A社のITで何度もお世話になったひとに伝えると「知ってるけどね・・・」と悲しい目をして苦笑いしていた。
旧A社ITはその優秀さでそれらの攻撃をいなしつつあるようにも見える（私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングのレベルが二回りぐらい違うように見える）
そして私はいつまでソフトウェアエンジニアの真似事を続けてキャリアを消費していけばいいのか、もうダメかもしれない。
C 買ってきたばかりのCDをPC音楽ソフトウエアに読み込ませても、タイトル情報が表示されません。新譜のCDはいつごろから情報を取得できるようになるのでしょうか?
新譜CDによってデータベースに登録されるタイミングにばらつきがあります。CDによって、発売日前でも情報を取得することが可能ですし、発売から一週間経ってもデータが取得できない場合もあります。世界最大の音楽情報データベースであるGracenote Media Database（ＣＤＤＢ）は、インディーズ盤、非売品、語学ＣＤ、輸入盤等のあらゆる音声ＣＤを対象としているため、データソースの一部は、ユーザーサブミッションに依存しており、データ標準化処理作業に時間を要するためです。また、ＣＤを発売するレコード会社が登録できるように、レコード会社向けのデータ登録、管理用のプログラムを用意しており、これをお使いのレコード会社の新譜ＣＤついては、ＣＤの発売日には情報取得ができるようになっています。
の中の一文
世界最大の音楽情報データベースであるGracenote Media Database（ＣＤＤＢ）は、インディーズ盤、非売品、語学ＣＤ、輸入盤等のあらゆる音声ＣＤを対象としているため、データソースの一部は、ユーザーサブミッションに依存しており、データ標準化処理作業に時間を要するためです。
を根拠とし、
さらには
新譜CDによってデータベースに登録されるタイミングにばらつきがあります。CDによって、発売日前でも情報を取得することが可能です
を無視して、
を事実だと結論付けるには根拠に乏しく、論理の飛躍が見られる。
営利サービスのCDDBを含めてすべてのCDDBサービスが有志による入力よって成り立つボランティア運営だという悪質なデマを広めないで欲しい
今回の更新により、取り扱い可能なデータ容量の拡大とリフレッシュレートの増加が実現され、またすべてのデータソースに制限なくアクセスできるようになります。ダッシュボードの共有機能は Power BI 無償版ではご利用いただけなくなりますが、Power BI Pro では引き続きご利用いただけます。
なお、Power BI Pro 試用版は、試用期間が延長され、2017 年 6 月 1 日から 2018 年 5 月 31 日までご利用いただけるようになりました。ぜひご興味のある方は 2017 年 6 月 1 日以降、通常どおりにサインインするだけでお試しいただけますので、ご検討ください。Power BI Pro の詳細については、こちらまでお問い合わせください。 ぜひ、Power BI のご利用をこの機会にご検討ください。何卒、よろしくお願いいたします。
チーム
話題になってるね東京アニメアワードフェスティバル（TAAF）2016。
いま来た人でどれくらいバタバタしてるか知りたい人は、PDFを読むと良い。
短編アニメーションの応募要項という重大な文書にもかかわらず、8ページ目にしれっと「長編アニメーショングランプリ」とか誤字があるわけですよ。
（流石に英語の3ページ目はちゃんと TAAF2016 International Short Animation Grand Prizeとなってる）
つまり、そういうミスをするような組織体であるというのは、まあ最初から判ってたわけです。
一般社団法人日本動画協会にはあんまり関係ないんだけど、一般論として一般社団法人には色々あります。
ちゃんとしたところ、いいかげんなところ、ちょっとどうかと思うところ、色々です。
で、重要なところなんですが、一般社団法人って、公益法人じゃないし株式会社じゃないし、役所でもないわけです。
割と立ち位置が中途半端なこともあって、良い意味でも悪い意味でもユルイことが多いわけですね。
実行委員会との連携や、長編及び短編審査、招待作品選定等、極めて順調に準備が進んでいます。
江口氏のディレクターの解任による不利益や不都合は一切ありません。
江口美都絵氏（東京アニメアワードフェスティバル・元フェスティバルディレクター）に対する刑事告訴・民事裁判に関する御報告 (2016/2/15 付発表文に対し、第8項を追加発表) | 日本動画協会
「極めて順調に」とか「不都合は一切ありません」とか、お役所は書かないのです。
お役所の文書（口約束ではなく文書）は、広い意味で公正証書と呼ばれてて、ちょっと特殊な扱いになるからです。
（民事訴訟法228条あたりを読むとわかるよ。普通は公文書と呼ぶよね）
なんで書かないかというと、こういうことになった時に、結構マズイ＆面倒なことになるから。
shortfilmdepot.com の本年度の登録者でエントリー手続が行えなかった作品につきましては、TAAF事務局は、来年度開催予定のTAAF2017に対しても応募受付可能とする措置をとり、shortfilmdepot.comの運営者と協議を行い、登録者に対して告知を行います。
TAAF2016 「コンペティション部門短編アニメーション」ノミネート全作品発表！ | 東京アニメアワードフェスティバル2016
お役所の文章はこういう「1番の解任で問題ないって書いてる以上、2番の問題は解任された人とは無関係だよね」という言質をとらせないようになってます。
（念の為補足すると、1番を書いて無ければ「揉めたの契約解除した委託先に妨害されたからだから、そっちに損害賠償してね」って出来た）
まあ、これもお役所仕事とかの典型ではあるので一般論として聞いて欲しいんだけども、
世の中には「言えばまあ通るんじゃないかな」的な勢いでイイカゲンな事をしてくるところがワリとあります。
仕事発注して仕事が動き出してから「やっぱあれキャンセルね、一銭も払わないから。だってキャンセルだし」みたいな。
お役所も不思議な時間間隔で動いてるので、お金なかなか払ってくれなかったり、微妙に話がなくなったりします。
書類になってるとちゃんと守ってくれるし、イイカゲンなことは書かないんだけどね。
（なので、役所のひとに無茶言われた時は、文書で請求してくれって返すと大抵お金払ってくれる）
と、同様に、なんかこう、訴訟すれば自動的に通ると思ってるひとも結構居ます。
まあ訴訟慣れも嫌なモンだけど、メンドウ嫌がるひと多いからね。
となったとき、「じゃあ確認訴訟するかあ」とはならないことが多い。
（雇用契約上の地位を確認→クビじゃねえよな→和解金貰って辞めるのパターン）
これもまあ一般論なんだけど、
クビは無効ですノータッチです、だと勝てることが多いよね。弁護士は忠告しないのか。
ここまで読んでくれた人にちょっと良いことを教えるけど、
「東京アニメアワード 357件」でググった時に出てくるサイトあるよね。
つまり「ウラドリしない」「独自ソース持たない」「主張を転記してくれる」美味しいサイト群。
ちょっと説明すると、TAAF2016の短編応募はこんな状況でしたってのがTAAF2016サイトで公開されてる
コンペティション部門短編アニメーションの応募総数は、インターネット上の応募受付サイトである shortfilmdepot.com への登録者で、TAAF公式サイトを通じて自らエントリーの手続を行った方々の173作品を含む522作品でした。
shortfilmdepot.com の本年度の登録者でエントリー手続が行えなかった作品につきましては、TAAF事務局は、来年度開催予定のTAAF2017に対しても応募受付可能とする措置をとり、shortfilmdepot.comの運営者と協議を行い、登録者に対して告知を行います。
TAAF2016 「コンペティション部門短編アニメーション」ノミネート全作品発表！ | 東京アニメアワードフェスティバル2016
わかりにくいんだけど、
というわけで、349作品が（理由は不明だけど）来年受付になるよ、と書いてある。
というわけで、いま357件って書いてるところは、ちゃんとしたデータソース別に持ってないんじゃないかなあ。
（なお、530件－173件＝357件になる。530件っていうのはおたぽるが役所にヒアリングした時の数字だね）
こういう時、慎重さに差がでるから、良く観察したほうが良いよ（誰がとは言わないけど）
ゆる～く書いてるように見えるのに、確認が取れた数字しか載せないところは、やっぱ揉まれてんなあという感じ。
東京アニメアワードフェスティバル、大量の未審査作品を発生させたまま終了… | 東京都議会議員 おときた駿 公式サイト
iPhone5の予約日と入荷日の関係についてグラフを作成した。データソースとしては、【16GB&32GB専用】iPhone5入荷連絡待機所1-7
http://logsoku.com/thread/anago.2ch.net/iPhone/1349596183/
を使った。総データ数961。
こちらがグラフ：
丸の面積が人数を表す。だいたい峠は越えたようだが、まだすぐ入荷するかんじでもない。
元スレは記述にブレがあるので、それを直すのにけっこう時間をかけてしまった。
Google エンジニアの Steve Yegge 氏、Google+ への懸念を漏らす
http://japan.internet.com/busnews/20111013/8.html
で記事になってたけど、原文とちょっと要旨が変わっちゃってサービスへの警鐘みたいになってしまってたので、全文訳してみた。くそ長い。お暇な方どうぞ。
（2011/10/19 08:14）ありがたい誤訳の指摘をいただいたので3カ所修正。
Stevey の Google プラットフォームぶっちゃけ話
僕は6年半ばかり Amazon にいて、今はそれと同じくらい Google にいる。この二つの会社について強く感じることは（しかもその印象は日々強まるのだけれど）、 Amazon は全てにおいて間違っていて、 Google は全てにおいて正しいということだ。そう、やりすぎな一般化だけど、驚くほど正確だと思う。いやもうとにかくね。百、いや二百のポイントで二つの会社を比較することが出来るだろうけど、僕が正しく覚えていれば、 Google はそのうち三つを除いて優れている。実にある一点に関してはスプレッドシートを書いたんだけど、法務が外に出すなって言うんだ。リクルーティングは惚れ込んだみたいだけどね。
つまり、まあ簡単に言えば、 Amazon の人事採用プロセスってのは基本的に欠陥品なんだ。だって、チームがチーム毎に、自分達のために人を採用するんだぜ。だから、色々平均化の努力はしてるみたいだけど、採用基準はチームによって信じられないくらいバラバラさ。そんでもって作業工程ってのも腐ってる。ソフトウェア信頼性工学なんてお呼びじゃないし、エンジニアに何でもやらせようとするんだ。コーディングする時間もないくらい。もちろんこれもチーム毎にバラバラで、要するに、運次第ってところ。施しやら困った人を助けるのやら、コミュニティに貢献するのやら、そんなのはもってのほか。バカにしに行くんでもなけりゃ、近寄るべきじゃないね。それにまた施設も染みだらけの壁に囲まれた箱みたいな家畜場で、装飾やらミーティングエリアなんてものには一銭も使ってない。給料やら福利厚生なんてのも最悪だ。まして最近じゃあ Google やら Facebook っていうライバルがいるのにね。社員特典なんてものも見たこと無かったな。採用通知の番号を照合して、ハイ終わり。コードベースも悲惨そのもの。エンジニアリング基準ってものがないんだから。チームによっては個別にがんばっていたくらいかな。
公平に言えば、彼らは良いバージョン管理ライブラリシステムを持っていた。これは僕らもまねるべきだし、僕らのところには同様のものが無い、良い pubsub システムもあった。でも多くの部分で彼らが使っていたのは、ステートマシンの情報を RDBMS に突っ込んだり読み出したりするだけのくそみたいなツールの塊だった。僕らならただでも欲しくないようなね。
僕が思うにその pubsub システムとライブラリ管理システムが、まさに Amazon が Google より優れている三つのうちの二つだ。
早期にリリースして、狂ったようにイテレートするってのも彼らのうまいところじゃないかって言うかもしれない。けど逆もまたしかり。彼らは早期にリリースすることを何にもまして優先する。品質保持やらエンジニアリング規則、その他長い目で見たら重要になってきそうなものはみんな後回し。そんなだからたとえ市場で競争相手よりアドバンテージがあったとしても、結局ちょっとしたことをやるのにも問題を起こしちゃうよね。
でも、一つ、そんな政治的な、思想的な、技術的なへまを補うだけの、彼らが本当に本当にうまくやってることがある。
Jeff Bezos は悪名高きマイクロマネージャーだ。彼は Amazon の小売りサイトの1ピクセルまで管理する。彼は以前 Larry Tesler を雇った。 Apple の主任科学者で、たぶん世界で最も有名で尊敬される HCI エキスパートさ。そんでもって、 Jeff は Larry が言ったことを、 Larry が辞めるまで3年間無視し続けた。 Larry は大規模なユーザビリティ研究もやっただろうし、少しの疑いの余地も無く誰もそのひどいサイトを理解できないってことをデモしたに違いない。けれど、 Jeff は1ピクセルたりとも動かさせはしなかった。トップページにぎっちりつまった内容の1ピクセルたりともね。それらはまるで何百万という彼の貴重な子供達なのさ。けれど Larry はそうじゃなかった。
マイクロマネジメントが Amazon が僕らよりうまくやっている三つ目ってわけじゃあない。つまり、まあ、彼らはうまくマイクロマネジメントをやっていたと思うけど、それを強みって言いたいわけじゃ無い。まずは何が起こっているかみんなに理解してもらうための文脈を準備しているだけさ。僕らはこれから、公衆の面前で、 Amazon で働きたけりゃ私に金を払えと言ってのける男について話すわけだからね。誰かが彼に反対したときは、彼は彼の名前入りの小さな黄色いポストイットを手渡して、誰が会社を動かしているかを常に忘れさせまいとする。思うに彼は全くの… Steve Jobs なのさ。ファッションとデザインセンス抜きのね。 Bezos はとんでもなく頭が切れる。誤解しないで欲しい。彼の前じゃ、普通のコントロールフリークなんてヤクが極まったヒッピーみたいなもんだよ。
それである日 Jeff Bezos が指令を出した。まあ彼がいつもやってることなんだけど。その度にみんなはピコピコハンマーで叩かれるありんこみたいに走り回るんだ。でもそのある一度、2002年かそのくらいのことだったと思うけれど、彼は指令を出した。とんでもなく巨大で、目の玉が飛び出るほど重たいやつを。普段の指令が頼んでも無いボーナスに思えるようなやつを。
彼の巨大な指令はこんな感じだった。
1)この時点より、全てのチームはサービスインターフェースを通じて全てのデータと機能を公開すること。
2)各チームは各々そのインターフェースを通じて通信しなければならない。
3)その他の全てのプロセス間通信は許可されない。ダイレクトリンク、他のチームのデータソースから直接データを読むこと、メモリ共有モデル、バックドア、全てを禁じる。ネットワーク越しのサービスインターフェースを経由した通信だけが許可される。
4)使用する技術は問わない。 HTTP 、 Corba 、 Pubsub 、 カスタムプロトコル、何でも良い。 Bezos は気にしない。
5)全てのサービスインターフェースは、例外なく、外部に公開可能なようにゼロから設計されなければならない。すなわち、チームは全世界のデベロッパに向けてインターフェースを公開することができるよう、設計し、計画しなければならない。例外は無い。
6)そうしない者は解雇される。
7)ありがとう！良い一日を！
ハハ！。ここにいる君たち150人ちょっとの元 Amazon 社員ならもちろんすぐにおわかりの通り、7番は僕が付け加えたジョーク。 Bezos は間違いなく君たちの一日なんかに興味ないからね。
それでも、6番は、本当だった。だからみんな一生懸命会社に行った。 Bezos は、さらに上級のチーフ熊ブルドッグであるところの Rick Dalzell に率いられた数人のチーフブルドッグを雇って、成果と進行を監視させた。 Rick は元レンジャーで、陸軍士官学校出身で、元ボクサーで、元 Wal（ごにょごにょ）Mart で拷問のような削減をやってのけた人物で、デカくて愛想の良い、「堅牢なインターフェース」という言葉を連呼する男だった。 Rick は歩き回り、「堅牢なインターフェース」について語り回り、そして言うまでも無く、みんなたくさんの進展をし、 Rick にそれを知らせた。
それからの数年間、 Amazon 内部はサービス指向アーキテクチャに姿を変えていった。その変化を形にしている間に、彼らは非常に多くのことを学んだ。 SOA に関する学問や論文は当時もいくつかあったけれど、 Amazon のとんでもない規模からすれば、そんなもの、インディ・ジョーンズに向かって「通りを渡るときは左右をよく見るんだよ」って言うくらいの意味しかない。 Amazon の開発スタッフはその途上でとにかくたくさんの発見をした。そのほんの一部をちょっぴり挙げると、こんな感じだった。
とまあこれらがほんの一例。他にもたくさんの、おそらく何百の、 Amazon が見つけた個別の発見や教訓があった。外部サービスにはおかしなところがいくつもあったけれど、君たちが考えるほどじゃあない。サービスに対して組織するってことは、外部のデベロッパを信用できないのと同じように、お互いを信用することなんてできないんだということを、チームに教えてくれたんだ。
細々と投稿していた、当時フォロー＆フォロワー1桁だった自分が
どうして一夜にして200以上のリツイートをもらったのか、
未だに解せなくて、自分の記憶とWeb上の記録を整理してみる。
（幸運なことに、自分は投稿数・フォロワーともに極端に少ないので、
せっかくなので、誰もがアクセスできるWeb上の記録などを参照して、伝播過程を分析してみる。）
早い時期のRTに気づいたのは、投稿した翌日の午後。
確かまだRTは20前後で、サブカル系とくに東方関係の人たち中心だったと記憶している。
（残念ながら、最初に誰がRTしてくれたのか覚えていない。
公式の「リツイートされたあなたのツイート」欄に表示されるのは「最新の15人」だけなので、
伝播過程を正確にたどれず、あやふやな自分の記憶に頼らざるをえない。）
その後、同日（投稿翌日）の18時過ぎから、爆発的にRTが増えるんだけど、この辺は、http://twimpact.jp/の記録と一致する。
どうも伝播経路が二つあって、一方はサブカル系へpixiv利用者や腐女子のネットワークを中心に伝播し、
もう一方はデザイナーの竹内光司さん（@adesignerjp）やtwicca開発者のAoyama,Tetsuyaさん（@r246）が
恐らく18時半～19時頃にRTしてくれて、クリエイター系にも拡散した模様。
（この二人が目にした伝播経路にもすごく興味があるんだけど、調べようがないんだなあ。）
RTの増加時期は、自分の記憶では、投稿翌日の夕方18時台にひとつと、22時台にもうひとつの大波があった。
前者ではとくに、10代から20代のサブカル系が趣味の生徒＆学生っぽい人たちが目立ったので、
「こりゃ、帰宅時にtwitter始めた人たちがRTしてくれてんのかな」と、
突然に増えていくRTに目を見張りながら、ボンヤリ考えたのを覚えている。
ちなみに、当該つぶやきをRTするには、そもそも「四時」が自動ポストされることを知っていることが前提だから、
その利用者周辺を中心に拡散するのは道理。
そういうわけで、比較的若年層のサブカル系とクリエイター系に拡散したんじゃないかと、自分は納得している。
ところで、http://twimpact.jp/のチャート図（「ReTweetレーダー」）は、
自分のアイコンから直接矢印が引かれているもの以外は、ほとんどアテにならない。
アイコンに併記される数字はこれまでRTされた当人の投稿数を示すように、
既存のトータルな影響の流れを図式化したものであって、当該つぶやきのRTとは無関係だからだ。
（そもそも、チャート図に表示されている勝間女史と「四時」の親和性は極めて低いだろうし。
念のためと、勝間女史の投稿を「もっと見る」でひたすら遡って確認してみたけど、
それゆえ、今まで一度もRTされていない人や非公開の人は、データとして表示されていないし、
恐らくはtwitterの「リツイート」ボタンを押して拡散した場合（公式RT）しか対象としていないようだ。
（twitterのリストには、非公式RT＝RT@ID名と記入した場合でも、カウントに入れて表示してくれるっぽい。）
だから、RTが87としか表示されていないのだろう。
（twitterのリストでは、投稿翌日の午後から翌々日の午後までに、227RTあった。
その後、RT解除または非公式RT投稿を削除されたりしたようで、現在は222で定着した模様。）
もうひとつ、http://retweeter.unicco.in/というサイトでも、伝播過程の分析がある程度可能。
こちらでは、「48 retweets 」があって、「total : 14,637 views」と表示された。
このRTが48という基準がよく分からないけれど、こちらのサイトでは、RTされた時間をたどることができるのがメリット。
それと、フォロワーの数を組み合わせて、当該つぶやきを閲覧したであろう人数を概算してくれるのも面白い。
（実際のRTは、このサイトの予測の5倍弱なので、総閲覧数も変わりそうだけれど、
でもまあ目安として、数万人規模の閲覧があったというのは、すごく興味深い。）
他方で、デメリットとしては、上述のRTのデータ数が不明なのに加えて、
当該IDの全てのRTがずっと記録されているわけではなく、
「一定期間以上ログを残すのは、100以上のRTに限る」といった制限がされている印象。
（というのも、当該つぶやき以降に、別の自分のつぶやき投稿をRTしてくれたフォロワーがいて、
RT直後にはこのサイトに、自分のIDでは2つのRTに関するログが残っていたのに、
数日を経て今日見たら、ログは当該つぶやきだけ＝1つだけに減っていたから。）
他にも、伝播過程の分析としては、
「お気に入り」登録してくれた人をたどるというのも一案だけれど、
こちらは公式にデータがオープンにされていないだけあって、もっと難しい。
例えば「ふぁぼったー」は、そもそも登録者しかデータとして表示されないっぽいので、ほとんど使えない。
（登録してない人は、自分がお気に入りされたかどうか検索することはできても、
お気に入りした人としてカウントされる＝データソースとして反映されることはないっぽい。）
実際に、当該つぶやきをRTしてくれた人で、なおかつ「お気に入り」登録してくれた人を
twitter上で自分は何人か見つけたけど、「ふぁぼったー」には全く反映されていなかった。
ちなみに、SPSSも今年6月に日本語twitter解析ソフトを出している。
http://www.spss.co.jp/campaign/tw.html
ソフトが手元に無いので上記サイトの記事だけで予測するに、ハッシュタグ付き投稿の感性分析メインみたいだし、
とんでもなく高額（学割でも17万円以上！）で、さらさら購入する気になれず。
分析事例を見ると、とくに続編では時系列の変化が内容ごとに分かって、確かに面白そうなんだけどさ。
リンク先に掲載されているハッシュタグを使ったつぶやき分析の2つの例。とくに続編（後者）が秀逸。
もう２週間も前の増田記事に対してレスするのもどうかと思ったがインターネット上で誰かがこの記事を検索することを想定して書いておく。
元増田が検索したCDDBの情報だと本質的な部分が分からない。
一方GracenoteのFAQにこういうのがある。
C 買ってきたばかりのCDをPC音楽ソフトウエアに読み込ませても、タイトル情報が表示されません。新譜のCDはいつごろから情報を取得できるようになるのでしょうか?
新譜CDによってデータベースに登録されるタイミングにばらつきがあります。CDによって、発売日前でも情報を取得することが可能ですし、発売から一週間経ってもデータが取得できない場合もあります。世界最大の音楽情報データベースであるGracenote Media Database（ＣＤＤＢ）は、インディーズ盤、非売品、語学ＣＤ、輸入盤等のあらゆる音声ＣＤを対象としているため、データソースの一部は、ユーザーサブミッションに依存しており、データ標準化処理作業に時間を要するためです。また、ＣＤを発売するレコード会社が登録できるように、レコード会社向けのデータ登録、管理用のプログラムを用意しており、これをお使いのレコード会社の新譜ＣＤついては、ＣＤの発売日には情報取得ができるようになっています。
もともとCDDBのサービスが始まった頃はユーザー（CDを買った人）が自分で取り込んだCDのタイトル情報をみんなで共有しようぜというものだった（と思う）。
上記Gracenoteの説明では、大概はCDを売る人がデータベースに登録し、一部がユーザーサイドで登録されることとなっているが、どのくらいの割合でユーザーが登録しているのか分からない。
ただ私自身もタイトル情報未登録のCDがあった際には、自分が登録したタイトル情報をCDDBに送信している(但し最近はほとんどその必要はない）。
そして一つ言えることはGracenoteの中の人がひたすら登録作業をすることはあり得ない。
結局ユーザーにとっては無料のサービスということもあり、曲名が表示されなかったら諦めて自分で打つしかない訳だ。
一方、曲名が表示されたからと行ってそれでよしという訳でもなく、それが正しいかどうかについてざっとでも見る習慣もつけた方が良い。
本気で間違っていることもある。誰のせいかはわからない。
