  |
はてなキーワード: インタフェースとは
フォーク・メタルの世界をご存知ですか。フォークってさだまさしでも、ゆずでもないです。民俗音楽です。
メタルとアイリッシュ、中東、サンバから果ては和琴までがマリアージュ。
邪道という人もいるでしょう。でも好きなんだからしょうがない。
シャウトとバスドラ高速ダブルとという共通性が、様々なご当地音楽を消費しやすくする。
まるで共通インタフェースでラップされた個別ライブラリのよう。
各地域の旋律や、楽器への回帰は、背後に政治的メッセージを持つものも多く、掘れば掘るほど奥が深い。
今日はヴァイキング・メタル入門編として、カバー曲含み、比較的キャッチーなものを中心にご紹介します。
「海賊王に俺はなる」よりだいぶ汗臭くて酒臭いですが、お付き合い下さい。
のってきました、どんどん行きましょう。
MADはさておき歌詞は、朝まで乱闘と歌で酒を飲み明かす、本能のままに生きる漢たちのこと。
当時のマーケティング戦略ゆえ、酒場で格闘ドンジャラホイという素敵な邦題がついてます。
原曲は、あのドイツのディスコ音楽グループ「ジンギスカン」がモデルとしたとも言われるボニーM「怪僧ラスプーチン」
ヴァイキングじゃなくちょっとわき道、東欧〜ロシアをイメージした旋律がメタルに映えます。
赤黒に顔を塗り戦士を奮い立たせるアンセム。こちらに個人の和訳があります。http://ameblo.jp/aoyuki1212/entry-11887199554.html
「友よ、悲惨な話しを告げよう」で始まる、裏切りものがなぶり殺される怖い唄。
キールホールは、縄で人を括って船底をくぐりらせるという船上の私刑。PVの結末が...ヨーホーホー。
ウィスコンシン通りの場末の薄汚い居酒屋で、死んじまう前にもう一杯。明日には遠くに船出してしまうから。
たしかに
文章において
改行は
と言ったのは私ではない。
というか、そういう意味でテキストサイトのフォントいじりもベスターもラノベもウリポ(マンガの試み、ウバポもある)もみな同様にすばらしいと思うし、ああそういえば倉田タカシ氏の作品にもあった。
倉田タカシ「夕暮にゆうくりなき声満ちて風」（河出文庫「NOVA2」所収）
そこには書き手と読者との壮絶な綱引きがある。読者は読みたいように読み作者はそれをコントロールすることはできないという大原則はわかった上で、それでも書き手は読者になにかしら特別な体験をさせたい、そのためにはなんだってやってやるんだぜ？っていう想いの綱引きだ。
既存のインタフェースの上でおもしろいことをやろうという試みや、あるいはあらたなインタフェース新たなプラットフォームの上でおもしろいことをやろうという試みはとても好きだ。もちろん、そういう試みが試みに終わってしまって作品としてはつまらないということもあるだろう。そのときは正直につまらなかったと意見をよせ、また次を期待する、と声をかけてやればいいのだと思う。
だってそうだろう？
読者が書き手を育てる
べきだ
からね。
今日の報道ステーションでALS（筋萎縮性側索硬化症）の特集をやっていたのを見た人もいると思う。
http://www.tv-asahi.co.jp/dap/bangumi/hst/news/detail.php?news_id=100058
脳からの信号を筋肉に伝える役割を果たす「神経細胞」が侵されて筋肉が徐々に衰えていく難病、ＡＬＳ＝筋萎縮性側索硬化症。年間１０万人に約１人が発症し、根本的な治療法もない「難病中の難病」とも呼ばれている。
で、最近、自分の親がALSに罹ったことが判明した俺が来たわけだが、まぁ当事者としては「これからどうしよう」みたいな事を考えると本当にキツい。キツいけど、こればかりは逃げようがないので、うまくやり過ごしながら何とかするしかない。
ところで、ALSといえば、今話題の「徳洲会」のドンである徳田虎雄氏も患者の一人だったりする。最近では毎日のように徳洲会がニュースになっていて、因果な巡り合わせだなぁと思いながら眺めている。
その徳田虎雄氏だが、二週間ほど前に取調べがあったらしく、参考映像で彼が文字盤で会話する様子が放映されている。
http://www.youtube.com/watch?v=D3cModp30cY
全身の筋肉がピクリとも動かせない、まさに「己の肉体という牢獄」に落ちた大変残酷な状況にあるのに関わらず、この眼力である。どんな病に罹っていても、患者のQoLは本人の生き方や周りとの関わり方次第なのだなぁ、とある意味元気付けられる映像だ。
とはいえ、彼が己の人生を謳歌できているのも周りのサポートがあってこそであって、特に彼は「権力者」だからこのスタイルが貫けている部分が大いにあるはずだ(*)。カネも権力もない一般ピーポーとしては、自分の親に同じようなサポートができるだろうか、というとあまり自信はない。
まぁ、幸いにして家族が「10万人に1人」のクジを引かずに済んだ皆には、この病気が将来「治せる病」となるように少しでも良いから支援してもらえると、うれしい。
*: いちおう補足しておくと、彼は眼球が動かせるので文字盤が使えるが、眼球も瞼も動かせずにコミュニケーションが断絶する「ロックイン」の状態になる患者もいるらしい。もしそうなると、本人も家族も地獄であることは想像に難くない。脳波を使うBMI（ブレインマシンインタフェース）技術が発達すれば、この状況も改善できるようになるとは思うけど。
毎日仕事ができなくて凹んでます。元増田の2年目が羨ましいです。
研究室では解析アプリケーションを作るのにC,C++,Fortranをいじってました
また趣味でサーバの立ち上げやWeb系のJavascriptやPHP,Pythonなどもいじっていました。
まったく違う。組み込みとWebとアプリケーションで文化が違ったわけです。
ここからはあくまで私の体験ですが…
まず、組み込み系はハード（接続図）を読めないと話になりませんでした。
CPU、FLASH、SRAM、FPGA、CPLD、アナログ回路、バッファ、それらをつなぐバス、電源、接点、コネクタ、スロット、A/D、D/Aなどなど、
これらがどうつながってるか意識しなくてはいけません。SoCとか行っても接続図読めないと意味ありません。
次に、FPGA・CPLDの設計があります。言語はVerilogかVHDLです。Xilinx、Altera、Actel等のデバイスに書き込みます。
PLDって言うのは言語で書けるハードです。似ているようでCPUと違うので設計にはスキルが必要です。
この段階でシミュレーション(modelsim等)をしてもらいます。
次にCPUです。言語はC,アセンブラ、C++です。でもほとんどがCです。デバイスはルネサスのSHとかです。自分はここで見習いをしてます。
CPUに直接入ってくる信号（接点・バス等）もありますが、前述のFPGA・CPLDから入ってくる信号のほうが多いです。
で、アプリケーション・Web系と何が違うかといえば、ものすごい短期間にいろんなことが起こります。
リアルタイム処理っていうのでしょうか。割り込みとか聞いたことありませんか。
要はOSがないので自分でなんでも考えなきゃいけないわけです。
CPUの検証はMISRA-Cや専用のカバレッジテストツールで行います。
接点の調整とかLCDパネルとかメンテナンスのツールだとかがないと装置に指令を出せません。
これらにもCPUが入っているわけなので別にコードを書く必要があります。組み込み系の仕事です。
これは言語でかけるリレー回路です。リレーってのはスイッチです。
スイッチを操作することで接続されている機械を操作（電源の入り切りとか）します。
これもCPU,PLD等とは全く違う方式（ラダー）で書きます。十分組み込みの仕事です。
ユニット試験では通っても、組み合わせ試験で動かないというのは１００％あると思います。
試験の仕事じゃないと思われるでしょうが、自分はここも立派な組み込み系の仕事だと思ってます。
などなど一言で組み込み系の仕事といってもいろいろあるわけです。
上の中の2つ3つを仕事に使えるレベルまで持って行くには10年、20年はかかると言われました。
ここで表題の件なのですが、元増田の人は経験8年なので、例えばFPGAを8年やってきてCを書けと言われても大変だと思います。
特にその後にWeb系の仕事（これも一言で表すにはいろいろジャンルがあると思いますが）をされてきたとのことなので
いろいろとあったのだと思います。逆にずーとやっていた分野のことを任せるといいかもしれません。
まずどんなことをやってきたのか聞いてみたほうがいいと思います。
現在二十代後半の自分は小学校でのコンピュータ教育が始まったタイミングの世代です。
始めは「学校へコンピュータ導入しました」みたいな申し訳程度な感じだったと記憶しています。
小学校でのコンピュータ教育の内容としてはCD-ROMを配布され、ODへ挿れるとソフトウェアが書き込まれたISOが自動起動して、そのソフトウェア上でコンピュータを学ぶという形式だったはずです。
学習ソフトウェアは勝手にフルスクリーンになるわけですが、今思えば無知な小学生がOSの設定を変えてしまわない配慮だったのだと思います。
実はこのあたりの記憶は曖昧なので学習ソフトウェアの内容は以下のような感じだったはずです。
これ以外もあったような気がしなくも無いですが、前提として私は小学生男子なので興味のないものは記憶からすっぽり抜け落ちている可能性が高いです。
この中で一番出来が良いのはパラパラマンガツールで、おそらくはプレゼンテーションなどを学ばせるためのものだったのでしょう。
時代を考えるとFlashが出始めの頃でありユーザーインタフェースや機能はFlash作成ツールから影響を受けていたようです。
ポケモンの戦闘シーンを完全再現したことでクラス内でヒーロになったのでこのツールには思い入れが深いですｗ
感覚として元も近いFlash作成ツールはParaFla!で、ParaFla!とペイントを足して2で割ってタイムラインシーケンスが無い感じでした。
地図を学ぶゲームも比較的良い出来で、ユーザーインタフェースはシムシティな感じでしたね。思いっきり影響を受けてるようでした。
確かストーリー仕立てになっていてクリックしてるだけで進み、地図記号とか学べるんじゃなかったかなあ？と記憶が曖昧です。
この学習ソフトウェア、どうコンピュータ教育に活かされていたか？と言えば、何にも活かされていませんでした。
教師は軽くマウスやキーボードの使い方を指導するだけで、あとは良い言葉を選ぶなら生徒の自主性に任せて、変な設定等を行わないように監視しているだけでした。
どういう指導要領になっていたかは知りませんが、コンピュータによるオートメーションを過剰評価して授業もオートメーション化出来るかも？と国は考えたのでしょうか？
まあコンピュータ教育が導入された最初期ですから実験的な意味合いも多分に含まれていたと思います。
パソコンの起動方法から始まり、ローマ字入力(小学校はひらがな入力)、そしてMS Officeへと入りいます。
このあたりは民間のパソコン教室と変わりがないかも知れません。
小学校で行われていた学習のオートメーション化への期待は無惨にも崩れたらしく、教師は手取り足取り教えてくれます。
それは新規フォルダや新規ファイルの作成方法、メールやWebブラウザの使用方法、その他今現在皆さんが日常的に使うであろうソフトウェアの指導が全く無いです。
どうやら学習のオートメーション化は不可能だと気づいたため、今度は思いっきり実用に振ってMS Officeマスターを育てるという選択をしたようです。
Wordでは文字の大きさや色、背景色、ワードアートの使用法、図の挿入、印刷などが中心に指導されます。
ワードプロセッサソフトが大好きな方は気付いたと思います。そうですWordなのにマークアップの指導が一切ありません。
完全に見た目の変更の仕方と印刷だけの指導であり、Wordなのにアウトラインとか完全に無視です。
見た目中心の指導を行うことはWordと変わらないですが、Excel関数の指導に入ると関数の意味をほとんど教えず「B1へ=SUM(A1:A5)と入力してください。はいA1からA5が足された答えがB1に表示されました。次は...」といった感じです。
生徒は教師の指示通り入力するだけで応用とかそういうの全くわかりません。しっかり理解してるのは見た目の変更の仕方くらいです。
時代ですね。こうして互換性無視なオフィスファイルは作られていったのでした。国がそう教えてましたから。
あっそうそうPowerpointとかAccessは授業でやりませんでした。
端的に言うのならば同上。
しかしPowerpointが追加されました。流石にPowerpointも教えないといけないと気付いたのでしょうか？
高校によっては工業高校や商業高校、高専ではもっとマシな指導をしていた可能性はあります。
ただやっぱり社会人から見るとツッコミ入れたくなるような指導が一部で取られていたと思います。国も手探りですから。
この年齢くらいになると学校の授業で覚えたと言うよりも独学でパソコンを習得してる生徒が殆どになっていました。
全くと言って良いほど学校の授業からは得たものがなく、エロ画像探しのほうがコンピュータリテラシーを僕に与えてくれました。
そして大学時代は教授のゴリ押しからOSがWindowsからEmacsに変わりました。
はてブで小学生向けにビジュアルプログラミングScratchが流行り始めてるんだなと知ったくらいでコンピュータ教育の授業の内情がどうなっているか全く知らないです。
なので僕が少年期に受けたコンピュータ教育を前提として「こうだったら良かったのに」というのを書きます。
コンピュータを扱うにおいてデータ管理というのは非常に大事です。
何故判りやすいファイル名を付けるのか？何故フォルダを作るのか？そういうことをしっかりと指導しなくてはなりません。
とりあえず僕も誰かに教える気になって書いてみたいと思います。
今だけ使えれば良いデータはどうせ直ぐに破棄するデータなので用途に合致すればどんな風に作っても構いません。チャットやっててウケを狙うためにネットからダウンロードする時にファイル名を「a.jpg」にするとかそういうことです。どうせ消します。
注意しなければいけないのは残り2つです。残り2つは前提として後々見たり使ったりするデータです。
このデータのファイル名を「a.txt」とかにしたら何のデータか全くわかりません。
つまり後々使ったりするってことは探すってことです。探すのに判りにくいファイル名にしてたら意味もなく違うファイルを開いて探しまわることになります。最近流行の「名前重要」です。
このジャンルのデータはある特定のフォルダ(ディレクトリ)に保存すると決めておけば探すとき非常に楽です。
そのため各OSは、例えばWindowsならば「マイドキュメント」や「マイピクチャ」「マイミュージック」などを用意してくれてます(ソフトウェアも空気を読んでデフォルトの保存先をそういうのにする)。
せっかく用意してくれているので使うようにし、もし自分でフォルダを作るときは名前重要ですから判りやすいフォルダにしておきましょう。
例えばTwitterであるジャンルの話を同好の士に読んでもらいたい場合どうしますか？ハッシュタグを付けますよね？
そうやって名前を判りやすくしておけば自分以外の他人が使う時も非常に楽なのです。
「でもよく使うデータを深い階層に置いてたら面倒じゃん」っていう意見はもっともです。
実はそのために「デスクトップ」という階層や「ショートカット」があるんですね。
デスクトップがアイコンだらけの人ってたまに居ますけど、きっとそういう人はコンピュータ教育は受けたけど保存されるデータの種類を知らない人です。あなたは悪くないですコンピュータ教育が悪い。
世の中には目の見えない人が居ます。そんな人たちがコンピュータを使えるように「読み上げソフト」ってのがあります。
まあいろんな意味で"文字通り"読み上げるためのソフトウェアなわけですが、このソフトは何も編綴もないテキストデータを読み上げるとめちゃくちゃ棒読みです。
それが更に平仮名ばかりで句読点もないテキストだと読み上げソフトは棒読みで一気に読みあげて目の見えない人はものすごく聞き取りにくいです。こんなテキストは目の見える僕たちでさえ読みにくいです。
そこで僕達は漢字を使ったり句読点を使ったりして可能な限り読みやすくします。実はこれがデータの中身にとって重要なのです。
句読点は文章を判りやすくする目印ですが、これを付けることをコンピュータの世界では「マークアップ」と言います。
読み上げソフトはマークアップされた文章だと、何処がタイトルで何処が本文というのが判別できるようになり、更に強調マークアップされている部分では音量を上げたりするので目の見えない人は非常に聞き取りやすくなります。
もしここまで読んである点に気が付いた人はかなり賢いです。その点とは「目が見えないのは機械も同じ」という点です。
マークアップされた文章は機械にとっても非常に判別がしやすい文章であり、実例をあげるのであれば検索するときに使う「Google」が検索結果へWebページのタイトルを載せてくれるのも、マークアップされたタイトルを拾い上げているからなんです。
Wordでも「見出し」と指定された行は機械的に判別され、アウトライン機能で文書の管理が非常にしやすくなったりします。
PDFでも同じでアウトライン表示されたり、読み上げソフトがPDFに対応していたらマークアップに合わせて読みあげてくれます。
少しだけ専門的になりますが、データベースとして使われているCSVファイルやJSONファイルも特定の記号を使われているのでコンピュータは楽に判断できるのです。
更にしっかりとマークアップしておけばPDFを電子書籍でよく使われているEPUBに変換するなど、他形式への変換が失敗しにくくなる利点もあります。
今まで行なってきたコンピュータ教育は正直「コンピュータ教育をしてますよ」という体裁だけを保っている教育の仕方だと思います。
コンピュータが使われるようになったから教育に導入し、MS Officeが使われるようになったからMS Officeを教え、IT市場が大きくなったからプログラミングを教える。
高速に変わっていくコンピュータの状況に合わせてしっかり教育は対応して居るように見えますが、現状のコンピュータ教育が見ているのはコンピュータの上っ面だけです。だから教育も上っ面になる。
コンピュータ教育ではタブレット端末の導入を現在検討しているらしいですが、どうみてもこれは上っ面な判断です。
コンピュータで高速に変わっていってるのは上っ面だけであり基礎の部分は。ハッカーが使ってそうないわゆる黒い画面、つまり端末(コマンドプロンプト/ターミナル)の頃とあまり変わってません。
その基礎を教えずしてOfficeだのビジュアルプログラミングだのを教えても生徒が得るものは何もないと言って良いと思います。
正直この記事は総合職さんやプログラマさん、エンジニアさんから見たら「なにそんな当たり前の常識的なことをドヤ顔で記事にしてんの？」って嘲笑されるような内容です。
その嘲笑されるような内容をコンピュータ教育はできていないわけです。
これWindowsじゃなくたって教えられること、最新ハードじゃない中古のPC-98でだって教えられること、中学生以上は持ってそうなスマホでだって教えられることです。
Webサイト開発・運用・保守の仕事をやっている都合、業務の一環として日常的にスマホを使うことが多いのだけど、プライベートで使っているのはガラケー。
やっぱりガラケーのほうが圧倒的に使いやすいのよねー。スマホに切り替える理由が今のところない。
自分、結構指太いから、狙ったポイントが押せなくてイライラすることが多いんです。
ソフトキーボードは画面を横向きにしないとまずまともに使えない。
Basic認証のID/パスワードとかを毎回手入力するのマジ苦痛ですわ。
UIの研究・調査のためにフリーのゲームをいくつかインストールしたこともあるけど、思い通りの操作ができなくてイライラすることが多いね。
使っているうちにディスプレイがベトベトになるのがまた嫌だったりする。
指紋が気になるたびにいちいち拭いているわけだけど、画面を直接触るというインタフェースである以上、使うたびに必ず汚すことになるわけで、必要な時以外はあまり触りたくない。
あと、ディスプレイとか折りたたみ式じゃないと不安にならないのかしら。
ポケットとかカバンに入れて歩いてる時に画面に細かい傷がついてしまいそうであまり持ち歩きたくない。
2013年4月26日、アーケードゲーム業界に突如現れた大型爆弾、それがけいおん！放課後リズムタイムである。
今時ケータイをいじれば無尽蔵にあるようなゲームが、アーケードに登場した。
アーケードに興味のない方、またTCAG業界に詳しくない方も居られるだろう。ここで軽く紹介しておく。
TCAGとは、トレーディングカードとアーケードゲームを合体させたジャンルである。
カードを集めて、手持ちのカードを使って何らかのゲームを行う。
分かりやすく説明すると、ソシャゲーに筐体がついて多様かつリアルタイム性のあるゲームがプレイできるものである。
TCAGと言っても戦略ゲームやスポーツゲーム、シューティングゲームにリズムゲームなど、カードを使ってどのようなゲームを行うかは多岐に渡る。
ソーシャルゲームとの大きな違いはプレイに対して課金が必須であること、そして独自のインタフェースや機能が自由に設計できることにある。
一般的にソーシャルゲームよりもグラフィック面で大きく有利であり、凝った演出や操作がウリの一つでもある。
また、大人向けの戦国大戦やベースボールヒーローズなども有名であるが、一方でアイカツ！やジャイロゼッター、ムシキングなど子供向けゲームが盛んなジャンルでもある。「カードが手に入る」というのが子供にウケるのだろう。
けいおん！放課後リズムタイムはリズムゲームを題材としている。
つまり、けいおん！の絵が描かれたカードと、けいおん！の楽曲を使って音ゲーをプレイするのだ。
なるほど楽しそうだ。きっとアイドルマスターのように名もないクラスメイトのカードがカスカードとして出てきて、初音ミクProject DIVAのようにキャラクターを使ったPVが見れるのだ。
そして「ちくしょう軽音部のメンバー揃わねぇじゃないかよ！……でもこの子かわいいな！」となるわけか。期待に胸が膨らむな。
……賢明な諸氏ならお気づきかと思うが、ここで取り上げているのだから上記のような真っ当なゲーム要素は一切存在しない。一切。
では、実際の様子を順を追って見ていくことにしよう。
まず君は筐体に1コインを投入する。
すると、あずにゃんのSDキャラクターがゲーム上の注意を喋ってくれる。
なぜあずにゃんがメインキャラクターなのかと言うと、ランキング一位のプレイヤーの推しメンだからである。
つまりこのゲームは筐体一位を取ると筐体のナビゲートキャラクターを変更できるのだ。
カードが排出される。このゲームには描きおろしカードは一切存在しない。最上級のミラクルレアでも既存絵である。
画面が変わる。軽音部の五人から使用キャラクタを選ぶ。ここでカードは必要無い。今後のプレイではナビゲート役があずにゃんから使用キャラクタに変わる。
次はカードスキャンだ。スキャンしたカードが画面に表示され、合計ポイントが計算される。
もし組み合わせが良ければコンボポイントが追加される。例えば、3枚とも同キャラのカードで揃えるとか。
カードの意味はここで終わる。単にポイントとしての役割しかない。
ゲーム中に選んだカードによってスキルが発動するだとか、服装がチェンジするだとか、そういった機能は一切無い。
カード特有の要素は何もないのだ。ただ唯一、スキャン時にカードの画像が表示されるのみ。
次は曲の選択だ。2013年に出たゲームなのに、アニメ一期の曲しか無い。一応キャラソンも入ってはいるが。
ゲームを進めると追加される、と思ったら甘い。
このゲームは本当に一期の曲だけしか無いし、そもそもユーザー登録は無い。
曲のロード画面が映る。黒背景に白字で「ロードしています…」と表示される。他には何も無い。文字のスクロールすら無い。こんな殺風景なロード画面見たことない。せめてキャラクターの画像でも貼ってくれればいいのに。
ゲームが始まる。円形のライン上を赤・青・緑のアイコンが滑り落ちてくる。
同じラインで現れるのでボタン配置が分かりづらいが、1プレイもすれば慣れる。
最高難易度でもさして難しくない。長押しや同時押しが存在しないので、ゲームとしてはただ単調である。
だんだんと背景を見る余裕が出てくる。
……一枚絵だ。一枚絵がゆっくりと拡大されて、縮小して、また別の所が拡大する。
なんだこれは。3Dでダンスしたり、せめて、アニメ映像が流れたりはしないのだろうか。
百歩譲っても、スライドショーにはならなかったのか。同じ一枚絵が、ずっと、ずーっと表示されている。当然、この背景も既存絵だ。
ちなみにこの筐体はブラウン管であり今時のゲームとしては解像度が異様に低い。
というのも数年前のゲームである「めちゃモテ委員長」のゲーム筐体を流用しているためだ。
しかしめちゃモテ委員長は着せ替えができて3Dでダンスしたし、メモリーカードを利用したユーザー登録もできたのだが……。
「50コンボ！」唐突に言われて初めて気づく。このゲーム、コンボ表示が無い。
50コンボごとに声と表示で知らせてくれるが、リアルタイムのコンボ数は一切表示されていない。
選んだキャラクターがプレイ中に関係するのはこのコンボ音声だけである。
そういえば、合格ラインも無い。何点以上とか、何割以上とか、そういった基準が全くない。
かろうじてスコアは表示されている。しかし比較対象が無い状況で数字だけ見せられてどうしろというのだろう。もちろん、曲のハイスコアは表示されていない。
現れるアイコンに合わせて黙々とボタンを押す。背景も見飽きた。
…………ゲームが長い。一番が終わったかと思ったら間奏に入って二番が始まってしまった。
約4分、延々と代わり映えしない背景を見ながら、3ボタン単押ししかない音ゲーをやり続けることになる。
そもそも体力ゲージが無いのでどんなヘタクソなプレイをしてもゲームオーバーにもならない。
ハッキリ言ってTVサイズでも飽きる。それを4分。地獄である。
ようやく曲が終わる。ロード画面だ。「ポイント集計中」の表示が黒背景に踊る。いや、踊らない。ただ無機質に表示される。
ポイントは三種類の評価が下る。カード点、ゲーム点、コンボ点である。これを合算して最終スコアとなる。
「良いカード」を使って「ノーツが多い曲」で「フルコンボ」を出すことが稼ぎプレイの必須条件だ。
これはセーブがないのもあるが、「高スコアを取ってもどこにも発表されない」という意味でもある。
では得たスコアはどうなるのかというと、「使用キャラクターに」加算される。
これは軽音部五人の投票数ランキングであり、決してプレイヤーのスコアではない。
このランキングで一位のキャラクターが筐体のナビゲート役になるわけだ。
もちろん投票数は合算スコアなので、一位を追い抜くためには相当数のプレイが必要になる。
君が継続プレイするモチベーションは「自分の嫁をナビキャラにする」の一点のみ。
もしカードがほしいだけならばカードだけ買うモードがあるのでそちらで延々買われるのが良いだろう。
ただし、全て既存絵だが。
そしてプレイする動機となるランキングはスコアで決まるため、本当に必要なカードは「ポイントの高い上位3枚」に絞られる。
より高位のカードを手に入れた瞬間、これまでのカードは完全に単なる下位互換にしかならない。
さて、ようやくプレイを終えた君は立ち上がって横を見る。
アイカツの筐体と、そこで楽しそうにプレイする幼女が見えるだろう。
ここは大型ショッピングモールの子供向けゲームコーナーである。
このゲームはなぜか女児向けにデザインされており、多くの場合は他の子供向けアーケードゲームと横並びで設置されているのだ。
アイカツではスキャンしたカードと同じ衣装を着た3Dのキャラクターが画面内を所狭しと踊っている。
ジャイロゼッターは高らかに明滅しながら筐体が変形し、ロボット操縦レバーがせり出している。
そんなゲームを横目に見ながら、君は嫁がランク一位になるまで無機質な3ボタン音ゲーをプレイし続ける拷問を続けるのだ。
「外部仕様を変更しているサービスはない」という指摘が多いので追記。
てか、FacebookもTwitterも、外部仕様をもりもり変更してますよね。Facebookなんて既存の機能が無くなったことが何度もあるはずだし、TwitterもWebインタフェースを全面的にREST API経由に切り替えた当初は批判が凄かったと記憶しているけど。
結局、「うまくやるか、うまくやれないか」であって、要求の変更が仕様の変更を求めているなら、それをすることも選択肢から除外されることじゃない。
はてなブログの場合は、過去の強み（職人芸で構築されたインフラ、はてな記法、カスタマイズ性の高さ、etc）が現在の負債になっているという状況で、「じゃあ、作り直しましょう」という判断自体はそんなに間違っているとは思えない。つうか、数年ブランクが空くと痛切に感じるけど、はてな記法辛いよ、実際。もうreSTかmarkdownの拡張でいいじゃん、という感じがする。
結論としては、「はてなダイアリー2.0」を作っても誰も得しないし、不満がある人はそのままはてダ1.0を使い続ければいいじゃん、ということ。
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
プラットフォーム、機能、制限事項が多すぎて分かりにくいから。
「A社からの本を読むには、本とは別に初回に○○円かかります。B社の本も読みたい？では別途、××円かかります」
「次のページへ進むには、この本ではページをつまむようにめくってください。この本ではページを指でスライドさせるようにめくってください」
「この本はページに線を引いたり、ページを切り取ってスクラップにすることはできません。この本は電波の届かないところでは見ることができません」
挙句、これらの制限事項があるにも関わらず、「普通の本と値段はあまり変わりません」
これじゃ、ユーザーは買おうという気にはならないよ。
http://anond.hatelabo.jp/20110707195830
初音ミクLAライブ、外国人の感想その５。これまで紹介した感想は「ヴァーチャル・アイドルとしての初音ミク」を論じていたが、今回はミクの本来の姿、即ち「歌声合成ソフトとしての初音ミク」に注目しているのが特徴だ。また外国における歌声合成ソフトの将来性についてかなり厳しい見方をしているが、その指摘には耳を傾けるべきところも多い。初音ミクの海外進出に関する先行きを占ううえでも目を通しておく価値はあるだろう。
urlは以下の通り。
http://lelangiric.wordpress.com/2011/07/07/i-didnt-go-to-ax-but-yeah-anyway/
ミクのイベント後にはいつもヴァーチャルスターの構成要素は何かって議論が巻き起こる。クラウドソースな人格か？ touhou［東方］っぽさ？ オリジナルのないdoujin［同人］？ それともインターネットとDTMの力に関するフリードマン風の熱狂か？
確かに日本じゃ大うけだが、アメリカではこれからどう成長するんだ？ オレは英語のVocaloid3が発売されるのを待っている。いいものであってほしい。アメリカでのボーカロイドの発展には英語Vocaloid3の性能が極めて重要なんだ。けどな、アニメ産業とボーカロイドとの結びつきについては、オレは戸惑っている。つまりAXがミクノポリス会場になったことにな。今後も長期にわたって、アメリカではボカロオンリーのイベントはないだろう。アメリカに拠点を置く企業製のボーカロイドすら未だにない。オレが知っている［英語ボカロの］２つの会社はPower FX（スウェーデン）とZero-G（英国）だ。
でもな、そこでオレは考えてみたんだ。
ボーカロイドはvst［ヴァーチャル・スタジオ・テクノロジー］（とかその他のapi［アプリケーションプログラミングインタフェース］）といくつかの重要で理論的な方法は似ているんだが、極めて重要な具体的手法は根本的に違っている、とオレは理解している。基本的に（ある人間の）音声ソースを取ってきてあらゆる音素と音程を録音し、ボイスバンクを作った後で、ヤマハのVocaloid2プログラムがボイスバンクを「読む」ことができるようアプリケーションをコードする必要がある。オレはヤマハがこの部分で相当用心していると思っている。なぜなら公式のボーカロイドは（もしオレが間違っているなら訂正してほしいが）全部ヤマハのVocaloid2エディターと一緒に販売されているからだ。この意味でvstとは根本的な差異が存在する。（１）vstは通常daw［デジタル・オーディオ・ワークステーション］と一緒に流通することはない（２）vstの開発者であるスタインバーグは、vstプラグインを規格として作成しており、従って誰もがvstプラグインを作り出せる。
http://en.wikipedia.org/wiki/Virtual_Studio_Technology
http://en.wikipedia.org/wiki/Digital_Audio_Workstation
http://en.wikipedia.org/wiki/Steinberg
つまり、誰もがボイスバンクを作れるってことだ。UTAU現象がそれを示している。UTAUは違うソフトで動くボーカロイドの単なる「代替手段」（本当の意味でではないがオレは耐えられる）のフリーウエアに過ぎない。自家製ボーカロイドが登場するには（『ファンの作ったボーカロイド』はあるが、本物の商業ベースのボーカロイドとは違う）２つの条件を満たさなければならない。ある団体が充分な資本を集めて（１）高品質のボイスバンクを作成し（２）ヤマハからそのVocaloidエディターを頒布する許諾を得ることが必要なんだ。既に言った通り、紛らわしいのはボイスバンクをプログラムに「読ませる」ためのアプリをヤマハとサードパーティのどっちがコードしているのかってこと。思うに、もしおれがAXの会場にいてこの質問をしていたら、特にヤマハからVocaloid2の許諾を得るのにいくらかかるかを聞いていたら、オレは殺されていただろうな。日本のdoujin歌手を使えば高品質なボーカルを作るのはそんなに難しくないだろう。必要なのはインターフェイスと集音マイク。ダチを作ってそいつらに作業をさせる。そしてUTAUのファンダム全体を見れば分かるが、自分自身を体現したボイスバンクを作ろうとするモチベーションの持ち主は山ほどいるぜ。
http://utau.wikia.com/wiki/UTAU_wiki
オレが何を言おうとしているか分かるだろう。つまり、アメリカ製のインディー・ボーカロイド・スタジオの実現性ってのはどのくらいあるんだ？
少なくとももっと注意深く考え抜く必要がある４つの条件があると思う。
１． アメリカのアニメ業界とボーカロイドの関係。オレが思うに、ブランドイメージと、それからボーカロイドとアニメを結び付けているメーンストリームの連中のことを考えれば、こいつは最も重要な問題だ。「アニメ」はアメリカでその「あるべきもの」（つまりdirty japanese hentai shit）より遥かに大きな概念/カテゴリーになるべきだ。でもまあオレが見てきた限り、日本のボーカロイドにも同じ混同の問題があるようだけどな。とにかく、メーンストリームが一般的にアニメをどう見ているかがボーカロイド関連商品の売れ行きに影響するってことなんだが、この問題はオレには重過ぎる。omoやalexが考えてくれんじゃねーの、多分。
http://twitter.com/#!/alexleavitt
２． 誰か英語ボーカロイド使ってるヤツいる？ 西洋ボーカロイドファンダム総体の認識として、１人だけすげえアメリカ野郎がいて、そいつがボーカロイドランキング（ニコニコのやつで毎週ボーカロイドの歌/動画をコメント/再生数/マイリストに従ってランク付けしている）に［英語ボカロを］ぶち込んだことがあった。でもそいつは突然自分の動画を全削除しちまった。この一度こっきりの出来事を除けば、ボーカロイドは完全に日本のものだ。他にも英語が母国語の作り手はいるんだが、皮肉なことに英語話者のボーカロイド製作者が基礎を置く発生核となりそうな連中の大部分は、日本語ボーカロイドにengrishをしゃべらせようとしている有様だ（大笑い）。
この問題にはさらに深い根がある。
３． そんな真面目な議論じゃないんだが、ある文化の労働的な基底はどうして特定の製品に同調し他の製品には抵抗するのかについて話がなされている。歴史的かつ社会経済的な問いだ。どうしてチリは銅を掘っているのか？ なぜならそれがくそったれなほど沢山あるからだ。結果として採鉱は（おそらく）経済的な基盤が上部構造へと波及していくのと同じように（違うか？）文化的な行為となる。なぜアメリカは基底からやって来る沢山のボーカロイド曲を持っていないのか？ その理由はもう挙げているな……（１）なぜならdirty anime hentaiだから（２）アメリカにいるデスクトップミュージック人種はテレビゲームと映像作品に集中してやがるから。
http://www.imdb.com/title/tt0132477/
http://en.wikipedia.org/wiki/Base_and_superstructure
４． ２番目に上げたデスクトップミュージックの問題は重要だぜ。もしお前が独立した作曲家としてメシを食っていきたいのなら、お前の時間と貴重な音楽的アイデアをボーカロイドのように不安で子供じみた音に賭けてみようなんて考えは二度と起こさないだろう。そいつは正直、新しすぎる。西洋諸国は上出来なデスクトップミュージックを作っている。問題は、ボーカロイドは今も、そしておそらくは長期にわたって、もしかしたら決して、独立したアーティストにとって頼れる収入源にはならないってこと。たとえそれで生計を立てる気がないとしてもだ。アメリカでボーカロイドは、他のデジタル関連のインディー業界のように花開くことはできるのか？ アメリカのボーカロイドが日本のdoujin業界のようになるにはどうしたらいいんだ？
http://anond.hatelabo.jp/20110707195830
初音ミクLAライブ、外国人感想その２「再生の約束」フリーダム訳
http://anond.hatelabo.jp/20110708223459
初音ミクLAライブ、外国人感想その３「ミクノポリスのボカレタリアートたちよ、団結せよ！」
http://anond.hatelabo.jp/20110709211718
初音ミクLAライブ、外国人感想その４「仮想の歌姫：初音ミクの人気と未来の音色」
http://anond.hatelabo.jp/20110710234300
初音ミクLAライブ、外国人感想その６「ミクノポリス：７月のクリスマスと世界征服」
http://anond.hatelabo.jp/20110712205546
初音ミクLAライブ、外国人感想その７「AX11：ミクノポリスの印象」
http://anond.hatelabo.jp/20110713211501
初音ミクLAライブ、外国人感想その８「ミクノポリス：コンサート・リポート」
http://anond.hatelabo.jp/20110714210122
初音ミクLAライブ、外国人感想その９「アニメ・エキスポ：初音ミク」
http://anond.hatelabo.jp/20110715222900
初音ミクLAライブ、外国人感想その10「アニメ・エキスポ2011（抄訳）」
http://anond.hatelabo.jp/20110716194029
初音ミクLAライブ、外国人感想その11「世界は彼女のもの：初音ミクはいかにして全てを変えたのか」
http://anond.hatelabo.jp/20110717201147
初音ミクLAライブ、外国人感想その12「アニメ・エキスポ2011でのボーカロイド体験」
http://anond.hatelabo.jp/20110719031316
初音ミクLAライブ、外国人感想その13「ミク：日本のヴァーチャル・アイドルとメディア・プラットフォーム」
http://anond.hatelabo.jp/20110719203237
なんか今日のツイッターのTLをチラ見してたらFacebookがやたらHOTになってたので一言。
なんでかって？
ミクシィ（）笑があるから。
GREE（）があるから。
なんでかって？
一部のネットジャンキーや情報強者様達は新しく生まれてくるウェブサービスやトレンドに敏感で、
それらに飛びついては居心地が良いところを探し、一定以上定着すると次を探し求めて行く。
一方で情報弱者な日本の一般ユーザは、マスメディアで取り上げられて、話題の的にされたものじゃないとまず使わない。
ツイッターも最近になりようやくマスメディアに取り上げられることも増えたけど、それでも日本でのアクティブユーザが
爆発的に増えたかというとそうでもない。そしてコア利用者層と違い、それらの人々はクライアントを使わない（クライアントの存在を知らない）
ツイッターはクライアントがあって初めて使いやすいウェブサービスとなる。正直ウェブや携帯ウェブからは使いにくい。
けれど、最近のメディアの流行に乗せられて始めたような人はウェブや携帯ウェブから利用している程度である。
日本の一般ユーザはそれを「使いづらい」ままだと認識し、しばらくすると彼らはそのまま去っていくだろう。
クレームを入れる人もいるかもしれないが、サポート画面やサポート問い合わせ先が英語となるとそこで躊躇して
送るのをやめるものもいるだろう。
先ほどのmixiやGREE、モバゲーはマスコミの力を利用しつつ、さらに日本の一般ユーザがよく利用するシーンに合わせて、それらから
より最適に使いやすいように最適化したものをサービスインタフェースとして提供している。
さらに、日本企業が経営しているので、サポートももちろん日本語、クレームも言いやすいのでバンバンクレームを入れる。
日本人の一般ユーザにまだまだIEユーザが多いように、日本人はデフォルトのまま、慣れたものを利用しようとする。
その中でさらに使いやすいものを取捨選択していくので、海外のサービスは日本の一般ユーザまでになかなか浸透しづらい。
そうすると、Facebookが日本でも流行るという流れは、ごく一部については一時的に流行るだろうが、そこまでにとどまり、
広く一般には広まらずに沈下していくのではないかなと言うのが今の考え。
そんな上司がいる。
社員同士非常に仲がよく、私の入社と同時ぐらいに第1次twitterブームが着たので、若手はすぐにそこでつながっていた。
twitterでの話題は、大学関係者とも関わることが多いので教育的な話から、コードのことであったり、最新インタフェースのことであったり、ネタやプライベートな話まで
まぁ初期ユーザに一番多い使い方をしてきたのだと思う。
一方、その上司は3、4年前から今の会社にやってきた。現在、40代前半。
上司が転職してきた直後は別のチームにいたから全く関わりがなかったが、1年前から新たなプロジェクトとして同じチームに編成された。
前いたチームの同期からの評判もよい人だった。
上司がtwitterを始めたのは、ちょうど1年前くらいのtwitterがメディアでかなり取り上げられてきた時だったので、誰かが上司さんもやってみたらいいじゃないですかーとでも言ったのだろう。
あっさりその上司はtwitterにはまり、職場の人から大学時代同期の研究者だったりをフォローして楽しんでいた。
そうすると、職場でもtwitterの話をするようになっていて、「~さんこの前twitterで言ってたあれどうなったのー?」なんてことを上司が聞いたりしていた。
それまでは職場でtwitterの話題をすることはなく、最初は私も合わせていたが、その上司にかなり気に入られたらしい私は、特にtwitterの話をされることが多く、次第にエスカレートしていった。
随分前に私が会社での飲み会について投稿したことをネタにしてきたりもした。
その飲み会には上司もいたし、投稿をみればなんの話かは分かるだろう。しかしその投稿をした時はまだ上司がtwitterを始める1か月以上前だった。
上司は、あっさりと「君のつぶやき読めるだけ読んだんだよねー」と認めたし
「あれって、"more reading"し続けるとページ重くなって全部は見れないんだねー」とケラケラ笑いながら言うし、その後ももっと前の私の話をネタにして話続けることもしばしばあった。
さらには、別クラスタでフォローしてる子と私のリプライのやり取りの話までしてきた。つまりは私のprofileページをチェックしているということだ。
別に読めるようにしているのだから、昔のを読むことは文句言えなし、読むなとも思わない。
しかしそれはこっそりやってほしい。よりによって本人に告げるな。
webでも現実世界でも同一人物であることは本人も認めているわけだけれど、私はやはりネットとリアルは異なるものと捉えている。ネットという画面を通したものだからこそリアル世界で知り合ってる人とも向き合えることがあると考えている。
今まで、webでのルールなんて意識したことなかったけれど、あぁ実は自分にもwebルールがあるのだとまざまざと実感した。
上司には、私や若手が持つそんなweb概念が全くない人だった。
こんなことがずっと続き、少し私が嫌がっているのも気にせずtwitterの話ばかりされるのが本当につらくなってきたので、上司とは徐々に距離を置くことを決めた。
ネットとリアルの区別がつけられない人だからリムーブしただけで傷つくだろうなと思い、フォローはしたままで、仕事としては全く悪い人ではないので、ただ表面上仲良くし、飲みに誘われても断っていた。
どうやら、その時点で上司はひどく傷ついていたらしい。さらにひどい事が起きた。
その頃私は、プライベートなことで深く悩んでいて、ネガティブな発言が多かったし、誰とも分からないように人を批判する分を投稿していたりした。
できるだけ一般的な話に持ち込むようにはしていたけれど、感情的な部分もあったのかもしれない。
なんと、上司はそういう私の一連の投稿を、自分のことについて書かれたと思ったらしい。
長期休暇などもかぶりしばらくぶりに上司に会う日があった。
廊下で会っても無視するくらいの機嫌の悪さ。
なんだ?と思っていたら上司に個室に呼ばれた。
すると、上司は私のその問題のついーとをプリントしたものを数枚もってて、いきなり目の前のデスクにその用紙を投げ出し「これはないよね」と言い放った。
初めて空いた口が塞がらなかった。
はっきりいって、そんなことを投稿してる間、上司のことは微塵も考えていない。完全にドン引いた。
仕方がないのでその投稿をするに至った経緯まで全て話、関係ないことを主張し、なぜか上司がうなだれていた。
そして私が避けていることが気になったようなので、さらに自分のwebの使い方と上司のwebの使い方の違いを説明し、
ネット上の話をされるのは私はつらいとだけ訴えた。
これが約半年前。
その時上司は分かったとは言っていたが、現在もなにも分かっていない。
落ち込んだ投稿をした時は、一緒にがんばりましょうというDがきた。
つい最近もまた思わず愚痴っぽいきついことを書いてしまったら、
ボクだって努力してるんですというDがきた。
だからお前のことじゃねーよ、親とのことだよ
「だからといって、人がどういう考え方をしていても勝手で、使い方を他人に強制されるようなものではない」と上司は言った。
確かにその通りである。
上司のようなネットの使い方をして、自分が傷ついたんだ!ってことを相手に伝えれば、そっちだってある程度もしくはそれ以上の傷を被る。
相手にそんな傷をつけた時点で、自分の使い方を強制したことになっていることを上司は気がついていない。
それだってその通りである。
でも上司には「受け手側はそれをどう受信したかの責任は自分で持つべき」と言いたい。
私の発言が軽薄な時も確かにあるかもしれないが、鬱ポストを連発するわけでないし、個人を中傷したポストをしているわけでもない。
流そうと思えば流せるものを真に受け止めるのは、その受け手だけで留めてほしい。リアルにまで持ち込み、他者を責めるな。
彼ら彼女らは、どうしてそんな自分が不幸になるような使い方をするのだろう。
ネットでは発信者の状況は分からない。それなのにどうしてそれを真に受け止めて、ネットがつらくなるような使い方をするのだろう。
しかしそういった人達は一定数必ずいる。
結局はtwitterもまた一部の人の利用に留まっていくだろう。
すばらしいツールなだけに、そういった考え方をする人達のせいで広まらなくなるのならなんとも勿体ないことだ。
しかしもっと勿体ないのは、ネット上で実力を発揮している人がそういった人達のせいで姿を消していくことにある。
素晴らしい人がひとり姿を消せば、このweb上の可能性も同時に一つずつ消えていく。
ネットとリアルを区別しない人達による罪というのは実は予想以上に大きい。
今でも上司とのフォロー関係は続いている。恐らく今後も変わらない。
確かにめんどくさくなる時もあるけれど、折角いいツールを見つけ、いい人達とも巡り会えたのに、やめたくはない。
自分がweb界にいつか影響をもたらすとは思いもしないが、確実にそんなやつらよりはいい使い方をできる気はする。
なのでなにがあろうともやめることはない。
中央官庁での経験からいうと、基本的に省内文章のほとんどは電子化されてるし、電子文章のシステムも年々地道に改良されてる。省庁間を横断した電子文章システムの登場もスケジュールに入ってる。でも対外的な「文章」のインタフェースは結局紙にはんこ押した奴しかない。なので外に対して出す文章や、外から入ってくる文章はどうしても電子化できない。
これを全部電子化しようとすると、役所とか役人とかそういうレベルじゃなくて、日本中の公文章のやりとりを全部電子化するぐらいの勢いが必要。企業の社印が入った文章とか、個人が役所に出す書類とか、そういうのが全部電子化できる状態まで持って行かないと意味がない。
そのコストが本当に支払うのに足るものなの？現状でもそれなりに回ってるのに。
総務省が掲げる霞が関・自治体クラウドの計画が本格的に動き始めた。同省は2009年8月10日、「政府情報システムの整備の在り方に関する研究会」の中間取りまとめを公表した（資料はこちら）。これは、2015年の本格稼働をターゲットとして、府省の情報システムの将来像を描いたものだ。これによると、現在は府省ごとでバラバラに構築・運用している情報システムのうち、共用可能なものを霞が関WAN内のデータセンターに集約する。その際に、基盤となる「政府共通プラットフォーム」を開発。この上でアプリケーションをSaaS（ソフトウエア・アズ・ア・サービス）形式で利用する。政府共通プラットフォームには、府省間で共通利用するデータを連携する機能も含まれる（図1）。この政府版プライベート・クラウドが、霞が関クラウドの実態である。
府省横断の業務改革が不可欠に
この取り組みで重要なのは、どれだけアプリケーションを共用化できるかという点だろう。府省ごとに利用しているアプリケーションをそのままSaaS化するだけでは、単にWebアプリケーションのホスティングにすぎない。システムだけの統合・集約に終わらずに、業務プロセスの統合・集約、すなわちシェアード・サービス化にまでつながらなくては、大きなメリットを得ることはできない。
そのためには、府省を横断した業務の標準化が不可欠となる。中間取りまとめでも、業務の見直し（BPR）を課題として掲げている。しかし、その道筋は見えてこない。中間取りまとめの資料には、2009年度から2015年度までのスケジュール（予定）が掲載されているが、業務の見直しに関連するような工程は2010年度中の「要件定義」と「最適化計画策定」の2つだけだ。府省横断で業務を改革した上でシステム要件を定義するまでを、1年足らずの期間で完了できるのだろうか。
短期間での業務改革を実現するためには、強力なリーダーシップが必要だ。府省を横断して大なたを振るえるとしたら首相しか考えられないが、総選挙を間近に控えた今、実働部隊となるプロジェクトメンバーを選ぶことさえもままならないのではなかろうか。
一方の自治体クラウドも実現へ向けて大きく動き始めている。総務省は2009年7月17日、「自治体クラウドに係る開発実証団体」の募集を開始。実証実験に参加する都道府県を募り始めた（資料はこちら）。都道府県CIOフォーラム（詳しくはこちら）の事務局を務めている日経BP ガバメントテクノロジーでは、8月のフォーラム開催に向けて事前アンケートを実施しているが、実際にいくつかの都道府県が実証実験に参加する予定だと回答している。
自治体クラウドは、自治体専用のWANである総合行政ネットワーク（LGWAN）内にあるデータセンター（3カ所の予定）に市町村のシステムを統合・集約する取り組みである。市町村レベルでのシェアード・サービス化ととらえることできる。市町村の場合は、それぞれが同じような住民サービスを提供しているため、シェアード・サービスに向いているといえる。
理想論でいえば、全国の自治体が利用するシステムを統一すれば、コスト面で大きなメリットを得られるし、ガバナンスを効かせやすいというメリットも生まれる。しかし、アプリケーション（あるいはSaaS事業者）の品質を維持できるのかが見えない、地域特性による個別のサービスが提供しにくい、あるいは地場のITベンダーが育成できないなどデメリットも少なくない。実際、総務省の実証実験では、ASPやSaaSは自治体側が選択できるようにしてある。自治体クラウドは当面、都道府県単位のシェアード・サービス化ということになりそうだ。
ただし、都道府県単位でバラバラの仕様のシステムを作るわけではない。自治体クラウドの要件の中には、「自治体クラウド連携インターフェイス」というものがある。これは、アプリケーション間でデータを連携するためのインタフェースで、将来的には都道府県間の連携も見据えたものになっている。
とはいえ、都道府県を横断したアプリケーションの共用化は容易ではないだろう。都道府県をまたいで業務を標準化しなければならないからだ。自治体クラウドと霞が関クラウドの両方に共通することであるが、IT面での研究や実証・分析に偏らずに、業務の標準化にも力を入れていかなければ成功はおぼつかないだろう。というよりも、IT面の実装よりも、業務の改革・標準化のほうがハードルが高いのではないだろうか。
（吉川 和宏＝日経BP ガバメントテクノロジー） [2009/08/21]
http://itpro.nikkeibp.co.jp/article/Watcher/20090818/335667/
