sd-senkoさんのﾌﾞﾛｸﾞ

ゆるぎないアニメ、青い花のBD-BOXが発売決定。それにともなう影響

Sat, 25 May 2013 21:33:56 +0900

2009年に放映していた「青い花」というアニメがあります。

女子高生の登場人物たちによるいわゆる"百合"モノですが、
シリーズ序盤で、メインキャラクター同士がキッスをして交際がスタートするなど、
同じ百合ジャンルの作品の中でも、恋愛方向に踏み込んだ内容になっています。

同年に話題になっていたアニメには、
「けいおん」「戦国BASARA」「涼宮ハルヒの憂鬱(2期)」「化物語」「とある科学の超電磁砲」
などがあり、このあたりと作品のカラーを比較すると、キャッチーさに欠けるのは否めず、
商業的には「あまり成功しなかった」という評価を受けています。

その一方で、その年の文化庁メディア芸術祭で賞をもらったり、
雑誌企画のクリエイター向けアンケートで、一位を取ったりしています。

http://www.aoihana.tv/news/
>2009年にリリースされた映画、DVD、ゲーム、ホビーなどから、
>本当に良質なコンテンツをエンタメ業界1000人へのアンケートによって選出し、
>「ヒット作」というカテゴリーに収まりきらない"掘り出しエンタ"を推薦する巻頭特集を掲載。
>そのアニメ部門にて数あるタイトルの中から「青い花」が第1位に選ばれました！

今回は、おもに青い花のソフト販売をとりまく話をしたいと思います。
2009年当時は、ブルーレイの発売がまだ本格化しておらず、
網羅率としては、上位の作品から50～60%くらいだったでしょうか。
地デジ放送ははじまっていましたが、TBSを中心に、まだ多くの作品がSD放送をされていました。

青い花は、ハイビジョン制作・ハイビジョン放送だったのですが、DVD単巻しか発売されず、
「テレビ録画したものが、DVDよりもずっときれい」という状況でした。
ファンの間では、青い花の商業的不振を説明するのに、
「ブルーレイが発売されなかった」という事実は、いつしかスケープゴートのようになっていました。

　ファンA　「全話録画している。BDだったら買ったのに」
　ファンB　「俺も全話録画しているが、作品を応援するために買った」
　ファンA　「くそー、BDさえ出れば…」
　ファンB　「DVDが売れないからBDも出ないんだよ、今からでも遅くないから買え」　

こんなやりとりが、数年続きました。

「面白い作品は、面白いという事実だけで十分である」

という時代が、アニメの分野では、この頃、終わりを告げています。
（ゲームとかは、もうちょっと早かったかな）

ソフトの売り上げでランキング付けがされ、

「面白くてもセールスが振るわなかったら失敗」

と考える視聴者が、目に見えて増えていました。
熱心なファンほど、自分が面白いと思っているアニメのセールスが振るわないと、
作品が否定されたような気分になるというのですから、深刻です。

言うまでもないですが、作品の評価（自分の感想）と、
商業的な成功、失敗は、きっちりきっぱり分けて考えるべきことです。

我々消費者は、売れるアニメを求めるのではなく、
面白いアニメを求めることが、本来の姿だからです。
ファンが面白さを第一優先とせずに、
本来はアニメ制作者が気にするべき商業的成否と、
自分の感想をまぜこぜにしてしまっては、
いずれ全体が機能不全に陥ってしまうはずです。

（などといいつつ、この「売れなきゃ失敗」という風潮も、
　強烈な感情をともなう分、やや飽きられてきたかなという気はします。
　あるいはこの数年の間に、誰もが一度
　「自分の好きなアニメが売れなかった、それによって目に見えない誰かからバッシングされた」
　という経験をして、別の段階へ移行がはじまっているのかもしれません。）

一方、BD-BOXの発売が決まった今だから書ける「たられば」ですが、
その当時にブルーレイが出ていれば、「覇権」とまでは言わないまでも、
そこそこ売れることで、ある種のレッテル貼りは回避できたかもしれないし、
逆に、ブルーレイがそこまで売れなかったにしても、
数年にわたって、ファンの間に不満をためることはなかったでしょう。

「結局ブルーレイを出すことになるなら、当時出せば良かったんよ」
というのは、客観的事実としてあると思います。
ね、メディファクさん。

ともあれ、旧作アニメのブルーレイ化を求めるサイトの投票で上位になったり、
原作の完結という大きな節目があったりで、
アニメ「青い花」はついにBD-BOX化の運びとなりました。

ファンの間で行われる、「BDが出ればうんぬん」「BDが出ないのはうんぬん」
というやりとりをもう、見なくて済むのです。
なんと素晴らしいことだろう。

これから、アニメ「青い花」は、新しい時代を迎えます。

一言で言うと、布教の準備が整いました。
何かを目指して、布教するのではありません。

かつて「青い花」という、唯一無二のアニメがあったこと。
その事実をまだ知らない人に、ありのままを感じてもらうという、それだけです。
そのために、
そして布教を阻害する、忌まわしき状況を払しょくするためにも、
BD-BOXは必要だったんですね。

あなたの周りで、青い花BD-BOXを持って布教する人を見かけたら、
ぜひ、借りて見てあげてください。

声優志望者の多さに思うこと

Sun, 12 May 2013 22:20:19 +0900

芸能人養成サービス市場の実態　お笑い芸人減少も、ダンサー志願者は増加：株／FX・投資と経済がよくわかるMONEYzine

これを読んで色々思うことがありましたので、記事を書こうと思います。
（最初にことわっておきますが、自分はアニメ業界とも声優業界とも関係ない、ただのオタクです。）

一年間に声優養成サービスに費やされる金額は、50億円強だそうです。
金額ベースでいうと、ボーカリスト養成とほぼ同規模で、お笑い芸人養成の数倍の規模と、
リンク先の記事には書いてあります。
それなりの養成所に通うとだいたい一年で100万円前後と言われますから、
5000人以上の声優志望者がいるようです。
そして市場規模は今後も年数パーセントの拡大が見込まれています。

一方で、声優として活躍できている人がいまどのくらいいるか？と言うと、
Wikipediaに記事があり、なおかつ声優のテンプレートが貼られている人が5000人ほど
なおかつ、それなりに実績があり、英語版にも記事がある人と言うと、1000人ほどです。

その数字を年間のデビュー数に換算すると、200人～50人以下という感じでしょうか。

声優志望者が、その実在需要に対して数十倍に達する、
一言で言えば「声優志望者がとても多く、なお増加傾向にある」ということは、
得なことでしょうか。損なことでしょうか。
色んな立場から考えてみたいと思います。

１．声優志望者にとって
　単純に、競争倍率が上がるので、損なことだと思います。
　それでも志望するということは、それだけ声優という職業に高い価値を認めているということですね。

２．養成所にとって
　高い授業料を設定できたり、養成所の規模を大きくできるので、得です。
　ただ、デビュー・所属実績を出せないと、
　養成所の競争力が下がるので、安穏とはしていられません。

３．事務所（プロダクション）にとって
　より多くの声優志望者の中から、新たに所属させる人材を選べるので、得です。
　ただ、新人を選ぶ条件は他の事務所も同じなので、
　やはり安穏とはしていられません。

４．デビュー済みの声優にとって
　声優志望者が増えても、有力な事務所は一定の数しか新人を取らないことや、　
　正直なところ事務所の力や本人の持つコネクションの影響の方が大きいので、
　数自体はどうでもいいと感じているはずです。
　むしろ声優志望者が多いということは声優という職業の価値が高まるので、得かもしれません。
　将来現役から退いて、講師をやるのも良いでしょう。

５．アニメ制作者にとって
　彼らは基本的にプロダクションとしか関わりませんから、直接的には関係がありません。
　ただ、優れた新人を安価で使いやすいというメリットは生じています。
　現状は、制作者自体にそこまでの審美眼（あるいはこだわり）がないので、
　プロダクションや音響監督まかせです。
　強いてオーダーがあるなら「若いのがいい」とか「ルックスが良いのがいい」、
　あるいは「あえて棒なのがいい」とか、
　そのレベルだと思います。

６．視聴者にとって
　現状、我々が感じ取れるのは、
　「年齢が若くて」
　「ルックスが良くて」
　「そこそこ演技ができる」
　新人が日々どんどん出てきますよ、ということです。
　その源泉が「声優志望者の数がとても多いこと」なわけですね。
　これが損か得か素直に考えれば、得じゃないでしょうか。
　

ただ、もう一歩踏み込むと、
視聴者サイドとしては、もうちょっとデビューさせる数を絞り込んでもらっても、
実はメリットが出ます。
なぜなら、より優れた人材には、より長く、より多くのアニメに出演してもらうことが、
視聴者にとっては望ましいからです。

「そこそこ良い新人」と、「ある程度の出演実績を持つ声優」のどちらが、
よりアニメの質に貢献できるかといえば、後者に決まっています。
それでも、同じ人に20年も30年もアニメヒロインをしてもらうわけにはいかないので、
新人も業界に入れて、経験を積んでもらわないといけないのです。
新人の役目として、「今は未熟かもしれないけど、ちゃんと育ってね」
という意味合いを含めると、
多すぎる新人の数は、アニメ作品の質や、視聴者の体験にメリットをもたらさないことがわかります。

結論として、

・声優志望者の数が多いことは、素晴らしいことだと思います。
・声優志望者の数が多いことで、新人の質が上がります。
・そのようにしてデビューさせた新人を、その時々で便利に使うだけでなく、
作品を通じて育て、長く活躍させていくことが、視聴者にとってはメリットとなります。

そもそも論で、
「なぜ声優志望者が多いのか？」
「なぜ声優という職業の価値が高く評価されるのか？」
ということも併せて考える必要があると思います。

それは、端的に言えば、アニメに出て活躍している声優さんや、
あるいはアニメ作品そのもの、あるいはその周辺のショービジネスに、
声優志望者の規模にふさわしいだけの魅力が宿っているからです。
それらの魅力を維持し高めていくことも、俯瞰的に見れば、養成所ビジネスの一端なんではないでしょうか。

※吹き替えブーム・ナレーションブームというのは聞かないので、
今回はアニメとその周辺に限って書きましたが、
別にアニメ以外の声の仕事をディスっているわけではないので、悪しからず。

Wikipediaを声優アンテナ化する

Sat, 09 Mar 2013 22:21:57 +0900

ブログというものが流行り出した頃に、すでに株式会社はてなさんがはじめていたサービスで
「はてなアンテナ」というのがあります。
http://a.hatena.ne.jp/

好きなサイトを登録しておけば、その更新状況を、まとめて監視できるというものです。
今も絶賛稼働中で、多分一人前のイベンターには必須じゃね？とか思うのですが
自分は活用できてないのでいつも出遅れます。

単に声優さんの出演情報に限って言えば、Wikipediaは多くのケースでベストな選択になりえます。
（話数ベースの出演情報が得られないのが最後のネックではあります）
たとえば好きな声優さんのWikipedia記事をいくつもはてなアンテナにつっこんでおけば、
それはそれで価値を持つと思います。

で、「Wikipediaをアンテナ化する」という意味でもっと便利なものが作れないかな？と
自分なりにプログラムを書いてみました。
と言いながら、「Wikipediaをアンテナ化する」というのは実は出発点ではなくて
そもそも何が知りたかったか？というと

「Wikipediaの記事って、なんか気づいたら更新されてるけど、どこが更新されたのかわかりにくーい」

みたいなことです。編集履歴を見れば済むのだけど、余計めんどくさいですよね？
なのでまず時系列で変更箇所を表示できるようにしたいと考えました。
かといって編集履歴そのものをプログラムに収集させてもノイズばかりになるので、

「当該記事に含まれている、別の記事へのリンク」
「別の記事から当該記事へ張られているリンク（、を当該記事の情報源とする）」

を収集することにしました。
上はページをパースすればいいですが、下はどうするんだろう？
というと、実はWikipediaにはAPIが用意してあります。

http://ja.wikipedia.org/w/api.php?action=query&prop=links&plnamespace=0&pllimit=500&redirects=&export=&format=xml&titles=%E5%A4%A7%E4%B9%85%E4%BF%9D%E7%91%A0%E7%BE%8E&list=backlinks&bllimit=100000000&blnamespace=0&bltitle=%E5%A4%A7%E4%B9%85%E4%BF%9D%E7%91%A0%E7%BE%8E

以下のURLにアクセスすると、記事「大久保瑠美」に含まれる別の記事へのリンクがplタグで、
また記事「大久保瑠美」に対してリンクを張っている別の記事がblタグで、表示されます。
これをプログラムのデータベースに保存しておいて、
プログラムが次にWikipediaにアクセスしたときに変化があれば、
それを差分として覚えさせておけばよいのです。
そしてユーザーは差分を見て、ページの変更（リンクの変更）を知ることができます。

そうしてできたのが
http://kyouen3.appspot.com/ja/%E5%A4%A7%E4%B9%85%E4%BF%9D%E7%91%A0%E7%BE%8E

こちらです。URLの記事名のところを任意に変えてアクセスすると、プログラムがWikipediaを見に行き、
もし過去にページを取得したことがあり、さらに今回差分が見つかれば、
それをログとして表示してくれるようになってます。
これ実は英語のWikipediaにも対応していまして、

http://kyouen3.appspot.com/en/Rumi_%C5%8Ckubo

とやると英語版「大久保瑠美」のリンク差分が表示されます。
実はアンサイクロペディアにも対応しています。
http://kyouen3.appspot.com/un/%E5%A4%A7%E4%B9%85%E4%BF%9D%E7%91%A0%E7%BE%8E
幸か不幸か、まだアンサイクロペディアンには、目をつけられていないるみちゃんです。

中国語版Wikipediaにも対応していますよ。
http://kyouen3.appspot.com/zh/%E5%A4%A7%E4%B9%85%E4%BF%9D%E7%91%A0%E7%BE%8E
「光之美少女」「一起一起這裡那裡」「变身！公主偶像」「星光少女」
海外のタイトル訳は、見ているだけで面白いですね。
どれが何を指しているかわかりますでしょうか。

これらのページにはcontent-type/jsonが設定されています。
JavaScriptからの利用を意図したのですが、クライアントプログラミングが苦手で、まだ実現してません。

で、「任意のページで差分収集ができるなら、声優さん全体に対象を広げられるんじゃん」
ということでカタカタ作ったページが、こちらになります。

~~http://kyouen3.appspot.com/log/ja/seiyu?exclude=1~~
http://kyouen3.appspot.com/seiyu　（パスを変更しました。）

これは、日本語版Wikipediaの記事「Template:声優」のリンクを解釈することで
声優さんの記事のリストを作成し、
さらにリスト上の記事をプログラムに巡回させることによって、約4000人の声優さんの差分を収集し、
それをまとめたものです。

見た目の問題、細かな動作の部分、取り除けるノイズ的なものはまだありますが、
「Wikipediaを声優アンテナ化する」という目的はすでに達せられました。
自分自身、会社で「あー暇だなー」なんて思った時に、
動作監視もかねて頻繁にアクセスしております。
るみちゃんの「ムシブギョー」出演決定を知ったのは仕事中、自分のサイトだったりしました。
（ソースはWikipediaなんで、自分のサイトというのは少しあつかましいですが）

これからどうすんお？というのは全く白紙。
自分自身が満足しているうちは、これ以上はないのでしょうね。

技術的な話題は、またの機会に。
Webスクレイパーとして、またページ処理のメインプロセッサとして、
「Apache Camel」は今回とてもとても大活躍しております。
プラットフォームとしての「Google App Engine」にも感謝しなくてはなりません。
そしてMediawiki API の存在。
多言語対応（＋アンサイクロ対応）があっさりできるのは、
各国で共通のAPIを使っているからなのです。

さて、現状で一つ不満なのは

「日がな一日サイトを眺めていても、案外更新が少ない！」

ということです。4000人を監視していても、一日のログとして残るのは200～300くらいでしょうか。
なんだか直感的に、実態に則していない気がしてしまいます。
まぁ企業系ナレとかボイスオーバーとか、ラジオのゲストとか、
Wikipediaに載りくい仕事はあるでしょうが。
ボリューム的に、今段階で単独のWebサービスとして育てていくのはちょっと厳しいかなと思います。
うーん、どうしよう…。

GAE/jでシンプルにApache Camelを動かす

Mon, 25 Feb 2013 23:09:41 +0900

Apache Camelの紹介はこちらから。
解説動画:るみちゃあああああああああああああああああああああああああ

■Apache Camelコンテキストをシンプルに書くことで、
GAE/jのスピンアップ時間を減らすことができます。

Apache Camel本体に付属のサンプル、camel-example-gaeは、
GAE/j本番環境におけるスピンアップ時間が考慮されておらず、
スピンアップに30秒前後かかってしまいます。（CPUのグレードで一応短縮可能）
しかしこれはspringフレームワークの挙動によるものなので、
spring周りの記述をごっそり取り除くことで、スピンアップ時間を1/5程度に短縮できます。

springを抜くので、マッピングやインスタンスの起動時にやってくれる設定関係が弱くなりますが、
CamelContextを手動で立ち上げ、ProducerTemplateを使うことで全く同じことが行えます。
（逆にこちらの方がわかりやすい方も多いのでは…）

では、サンプルをご覧ください。

public class SampleServlet extends HttpServlet {

　　@Override
　　protected void doGet(HttpServletRequest req, HttpServletResponse resp)
　　　　　　throws IOException {
　　　　try {
　　　　　　CamelContext context =
　　　　　　　　new DefaultCamelContext(new SimpleRegistry());
　　　　　　context.addRoutes(new Route());
　　　　　　context.disableJMX(); // 必須
　　　　　　context.start();
　　　　　　ProducerTemplate pt = context.createProducerTemplate();
　　　　　　Exchange e = new DefaultExchange(context);
　　　　　　pt.send("direct:start", e);
　　　　　　resp.setContentType("text/html;charset=UTF-8");
　　　　　　resp.getWriter().println(e.getIn().getBody(String.class));
　　　　} catch (Exception ex) {
　　　　　　Logger.getLogger(SampleServlet.class.getName())
　　　　　　　　.log(Level.SEVERE, null, ex);
　　　　}
　　}
}

class Route extends RouteBuilder {

　　@Override
　　public void configure() throws Exception {
　　　　from("direct:start")
　　　　　　　　.process(new SampleProcessor());
　　}
}

class SampleProcessor implements Processor {

　　public void process(Exchange e) throws Exception {
　　　　e.getIn().setBody("オアシス君無限増殖法");
　　}
}

ルーティングルールとして、directコンポーネントではじまるルートを用意しておき、
そこへProducerTemplateを使ってExchangeを投げる格好になります。
投げる前に、Exchangeのヘッダーやボディに細工をしておくこともできますし、
投げた後は、Exchangeがまた返ってきます。それをさらに違うルートへ投げても良いです。

consumerサイドでしか使えないコンポーネント（ローカルだとfileとか）の場合は、
ConsumerTemplate#receive("endpointUri") が使えます。こちらもExchangeを生成します。

RestfulなWebサービスでは、サービスへリクエストされたURIを元にページを返します。その場合は

　　　　exchange.getIn().setHeader(Exchange.HTTP_URI,req.getRequestURI());

のようにしてやれば、ルーティングルールの方でもリクエストURIを受け取ることができます。
クエリパラメータやPOSTメソッドについても同上です。

DefaultCamelContext のコンストラクタに、なぜSimpleRegistryを渡すのかは、
こちらのトピックが参考になると思います。（自分は読めてないですが…）
http://stackoverflow.com/questions/14644570/do-camel-routes-not-run-on-google-app-engine

最後に、GAE/ｊでApache Camelを動かすメリットについてですが、

1.ルーティングルールとプロセッサーによりモジュール化が進むので、読みやすく書きやすい

2.httpコンポーネントが勝手にやってくれるコネクション管理が優秀、高速なのでウェブスクレイピングに向く

3.全体的なパフォーマンスの良さ

（どれもGAE/ｊ上の話に限りませんでした。）

Datastore読み出し一回、外部サイトへアクセスしてXML取得一回、
からの差分演算…で300msec(内、CPUは50msec以下)とかです。
レスポンスが良くてコードの見通しも良いと、機能をどんどん盛りたくなりますよね。

ASF : Apache Camel
http://camel.apache.org/

日本Apache Camelユーザ会(JACUG)
http://sourceforge.jp/projects/cameluserjp/
https://sites.google.com/site/jaacug/home

Apache CamelでExcelを読み書きするProcessor

Sat, 23 Feb 2013 11:28:05 +0900

備忘録ですー

public class POIProcessor implements Processor {

　　@Overide
　　public void process(Exchange e) throws Exception {
　　　　// read
　　　　InputStream is = new ByteArrayInputStream(e.getIn().getBody(byte[].class));
　　　　Workbook wb = WorkbookFactory.create(is);

　　　　// main
　　　　Sheet sheet = wb.getSheetAt(0);
　　　　sheet.getRow(1).getCell(1).setCellValue("owaaaaa");

　　　　// write
　　　　ByteArrayOutputStream baos = new ByteArrayOutputStream();
　　　　wb.write(baos);
　　　　e.getIn().setHeader(Exchange.FILE_NAME, "yay.xlsx");
　　　　e.getIn().setBody(baos.toByteArray());
　　}
}

Apache POIで編集後のExcelワークブックを保存しようとすると基本
wb.write(new FileOutputStream("foo.xlsx")) になります。
これだと確かに即ディレクトリに書き出しがされるのですが
ルーティング処理と書き出しが切り分けできなくて、Apache Camel的にはいやんな感じなので、
ByteArrayOutputStreamを使ってみました。
ボディにセットされたバイト配列は、任意のタイミングで任意の場所に、
fileコンポーネントで書き出すことができます。

Excel処理がメインになるのなら、read部とwrite部を別プロセッサにして、
普段はWorkbookで取り回す方が全然いいと思います。

ASF : Apache Camel
http://camel.apache.org/

日本Apache Camelユーザ会(JACUG)
http://sourceforge.jp/projects/cameluserjp/
https://sites.google.com/site/jaacug/home

新人声優の頑張ってる感　というエンタテインメント

Thu, 14 Feb 2013 22:23:24 +0900

アニメを見ている時に

「このアニメおもしろーい」

と思う感覚と、

好きな声優さんが出ているアニメを見て、思わず

「がんばれ…！」

と応援してしまう感覚とは、
割と遠いものだと思います。

自分自身、「応援」「贔屓目」「声優目当て」っていうのは、
アニメを見る上で、本質ではないと思ってました。
アニメを見る上では、「見たままを面白いと感じるか、そうでないか」が全てだと。

なので、優れた声優さんというのは、アニメを面白くしてくれる声優さんであり。
優れた声優さんを起用することが、アニメ全体にとって、
ひいてはアニメというジャンル全体にとってのメリットであり。

その文脈において新人声優さんとは、次の世代を担うための「優れた声優さん」の候補生であり。
ですから、アニメを制作する人たちにおかれましては、限られたリソース（アニメの配役）を
最大限有効に（有望な新人さんに）割り当ててほしいよね。

くらいのことを思ってました。投資と回収、ですか。

この考えで行くと、
「新人声優をアニメに出演させるのはあくまで投資であって、
また、新陳代謝のために、必要にかられてであって、
作品としては（優れた声優を起用するよりも）メリットが薄い」

ってことになります。
感覚的には間違いなんだけど、これまでそれを突き崩す論理が思い浮かばなかった。

で

最近思い至ったのが

「『新人声優の頑張ってる感』こそが新人声優を起用するメリットなんだよ！」
「『新人声優の頑張ってる感』こそがエンタメなんだよ。」

ってことでした。
（もう結論言ったのでいいかな。）

思い至って見れば、「『頑張ってる感』を楽しむ」というスタイルは割とありふれていて。
高校野球や箱根駅伝に代表されるアマチュアスポーツとか。同人作家さんとか。歌い手とか。

「応援すると元気をもらえる」というのは確かにそうですが、
ちょっとひねた言い方をすると、我々は「頑張ってる感を楽しみ、消費している」のですね。
それは「物語を楽しみ、消費する」行為と、きっとそんなに遠くないはずで。
「その種のエンタテインメント」としてとらえることができるのです。

その考えに立つと、「優れた新人声優」なるものが定義できて、それは

「『頑張ってるなぁ～』と思わせる声優」

ってことになります。何をすれば「頑張ってるなぁ～」と思えるのかまでは、
今回書きたいことではないので、触れませんが。

なので、投資と回収（つまり、デメリットのあとにメリットがきて、全体でプラスになればよい）
というモデルはちょっと修正が必要で、

「新人声優のうちは『頑張ってる感』で視聴者を楽しませ、
声優として成熟したらアニメを面白くすることで視聴者を楽しませれば、
最初から最後までウハウハ」

ということになりますね。

「この新人声優下手だな」
「上手い声優だったらもっと面白くなったのに」

って感想は確かにそのとおりですけど

他の見方をすれば、「本人から醸し出される『頑張ってる感』が足りなかった」
ってことも言えるんじゃないでしょうか。
頑張ってるなぁ～って思えたら、たとえ下手に感じても、それを楽しめると思うんですよね。
何を持って「頑張ってる」とするかは、やっぱり横へ置いておきますけど。

というわけで、本日の謎理論でした。

間違いなく激動の一年

Sat, 22 Dec 2012 23:57:48 +0900

今年30になりました

本当に、いろんなことがありました。

ちょっとしたWebサービスを作って、沢山の人に使ってもらえたこと。
オープンソースへの誘い。勉強会にも行くようになった。
新しい仕事をはじめたこと。

このどれもが、去年の自分にはなくて、
去年の自分は一体何を張り合いにしてたのか、謎なくらいですが。

るみちゃんの出てるイベントにもよく行きました。

戦コレ…アニメフェアと、ゲームショウ
ゆるゆり…ゆるゆりんぴっくとかとしまえんとか。ライブは行ってないです…次回は行きたい
LadyGo…セカンドデート。あとアニメフェアのお渡し会（買えなくて見てただけ）
あっちこっち…OPED発売イベント
その他…アラタなるセカイの発売イベント

去年行ったので覚えてるのはカッピのイベントとスイートプリキュアの舞台挨拶くらいなので、
イベンターとしても一年目だったかもしれないですね～

んで

来年どうなるのっと言うことなのですが
おそらく、自分の限界を探る一年になると思います
というのもここ最近、新しい案件を頼まれまくっていまして
全部応えてたらキャパもスキルも足りないよという状況が現にあります

ただ実際目の前に困っている人がいて　自分に力があれば助けられるという状況で
少しずつでも応えていくことが自分の力にもなるという正のスパイラルがあり
どうなっていくのかなと言う感じです。

正直な話、自分一人がわかるプログラムであれば、どんな要件にでも応えてみせますが
（うちはWebは関係してこないし、GUIを洗練させろとかではないので頼まれることは限られています）
透明性と保守性と、ロジックの妥当性という意味では、
今までより一段も二段も高いものづくりをしなくてはいけない必要性を感じています

でも、それができたら、正直、受託開発できちゃうよねという感じで、
なんだかまた見通しが混沌としてきますが…

なのでまだ2013年は未知数です。
本当はプライベートでWebサービスいっぱい作って楽しく暮らせればいいのだけど、
そういう実務をこなすことで今は引き上げてもらっている、という感じです。
多分、今の状態でベストを尽くしていれば、道は開けるのじゃないかな。
ということで。

ごらく部再考

Thu, 29 Nov 2012 04:24:15 +0900

これまで割と「自分はごらく部の中でもるみちゃん派だ」
と言ってはばからないタイプだったのですが
（実際それを口にする場があったかは別にして）

なんかうたがっせんのBD繰り返して見てたら、しんみりとしてきた気分になって
DTで頑張ってるみかしーとか、プリリズ2でも共演してるだーつーとか
キャラクターが受けてるのかいろんなとこに呼ばれてるゆかちんとか

四人がごらく部以外でも頑張ってるのを見てると
ごらく部の見方が変わってくる、と思うのです

単純に考えれば、四人で集まることの価値がそれだけ増しているということ
あと、ごらく部としての活動が終わっても四人はしっかり声優人生を歩んでいくだろうということ

それって、裏返せばごらく部の終わりのはじまり　なんですよね
ネガティブな意味ばかりでなく発展的解散というか
そういうことを考えられる時期に入ったというか

実際、アニメ2期も終わり
来年2月末にライブ3弾が控えてるとは言え　それが終わると一段落はして
アニメ3期はあっても全然不思議じゃないですけど
「ま、終わんだよ！いつかは！」という。

これだけイベントを精力的にやっていて
支持層がしっかりあって
そしてゆるゆりスタッフの普段のスタンスも含めて考えれば
きっとごらく部にも、いずれは、何かのイベントをもって、
明確に区切りをつけるときが来るのでしょう

もしかしたら、ふぇすてぃばるがその場になる可能性もなくはないのですよね
（放送室が続いているうちは発表・即解散は難しいと思いますが）

みたいなことを考えていくと　非常におセンチな気分になって
まぁーそれだけ色々やったよねーごらく部ーみたいな感じで
過去のイベントの記憶が反芻したりします

四人はきっとごらく部なくても頑張れるのですが
ごらく部というつながりが、思い出に変わる時のことを考えたら
今をもっと楽しんでおくべきだなぁ　と思いました。

仕事の近況とか

Thu, 29 Nov 2012 03:10:56 +0900

昔いた事務の会社に戻って4ヶ月経ちました

趣味の延長でプログラム書いてまったり過ごすという当初の目論見は、
半分達成され、半分があらぬ方向へ行っております
今日はその辺とかまとめておこうと思います

・別事業所の立ち上げがあったので頑張った（8～10月頃）
事業所といってもクライアント企業の一室を借りてそこで仕事するみたいな感じですね
人材的に手薄な中、一応経験者で比較的「わかってる」人間ということで割と無理してました
一日の半分はA事業所で、もう半分はB事業所で、みたいな生活が結構続きました

・フレックスタイム導入（10月～）
元々フレックスという方式にこだわっていたわけでなく
「データ処理の仕事なんて、忙しくないときは8時間いても仕方ないからさっさと帰りたい」
みたいなことをずーっと言っていたら
フレックスがいいんじゃないですかという結論になりました
自分の場合はこれとプラスアルファで、入社時の条件として
「仕事が落ち着いたら週4にしてください、その分忙しい時は無理しますから」
と言ってOKをもらっていたのもありました

フレックスタイム導入で、8時間勤務、9時～18時の枠組みが取っ払われ
「好きな時に来て、好きな時に帰っていい。好きな時に休んでいい」ということに。
もちろん自分がいないことで他の人に迷惑がかかってはいけないので、
そこは段取りをする必要があります。

こんなの、普通に考えたらむちゃくちゃなんですが
自分の場合は、A事業所とB事業所をまたがって仕事していたせいで
「この人は同じところに8時間いないんだな、毎日いないんだな」というのが
社内で定着していたので、それに乗っかることになりました。
結果的にはラッキーでした。

・後輩が増えた（9月～）
うちの会社は、昔から人の定着率が悪い分、人をぽんぽん採ります。
気がつけば自分と同じデータ処理の人間が自分含めて4人になりました。
（自分が入るまでは0か1）
まぁみんな基本的にはOffice系の人材なので、
がっつりプログラマーという感じではないので
自分としてはJavaとかApache Camelとかには興味を持ってもらうとこからなのですが
人手が足りてる分楽になったなぁという実感はあります。

で、うちの会社のデータ処理がわかってるのは「相対的には」自分ということで
データ処理の人材については、面接とか新人研修とかも自分が担当してる形です。
A事業所、B事業所ともに…

・真面目に働きたくないのにかえって色々頼まれるジレンマ（11月～）
うちの会社の問題点として「勤続年数の長い人が少なくて、管理監督する立場の人間が少ない」
というのがあり
データ処理に関してはすでに上司が存在しないので（クライアント直です）
自由が効く、裁量が与えられているという意味ではいいんですが

そもそも自分は「トータル時間で週4日分くらいしか働かない、人より働かない」
というところを実現するのにモチベーションを置いているはずなので
後輩には偉そうに振舞わなくてはいけなくて、上層部には色々申さなくてはいけない、責任のともなうポジションというのは
もうそれ自体矛盾をはらんでいまして、さっさとバトンタッチしたいところであります

ちなみに自分は、新しく来る人来る人に
「自分はいっぱい働きたくないんです」「仕切りたいとかじゃ全然ないんです」「現状がそうなってるだけです」「だからよろしくお願いします」
と力説することにしているので　彼らがとって代わってくれることを期待しています。

・進まないライブラリ開発（10月～）
そんなこんなで「まったりプログラムを書く」みたいな生活からは遠ざかっています。
ただ、最初の二ヶ月で作った、Apache Camelを使ったCSV変換アプリケーションの枠組みは試算として持っているので
それをフル活用して作業効率を出している感じです。
事業所またいで残業しまくっていた時期も、Apache Camelにはだいぶ助けられました。
普通にAccessでやってたらミスが避けられないような煩雑な作業が、
大幅に軽減できるのですから。
この辺は落ち着いたらどんどん記事を書いていきたいと思っています。

ただ、ここへ来て割と毒されてしまった部分というか
事務の会社ではあくまでOfficeがデファクトスタンダードなのかなという部分は認めざるを得なくなっていて
一度作ったら他の人間に任せてしまうような、ちょっとしたツールを用意するには、
保守性も含めて、AccessやExcelでちょろっと書く方が良いのかなと思ってます。
不本意ですが。
それで対応できない部分だったり、みっともなくなってしまう部分については、
どんどんプログラムを書いていきますけど。
あと全体最適化という意味ではOfficeでは無理なので、そこも大きな枠組みで。

「ITは自分を楽にするもの」というのは原理原則だと思います。
しかしそれにはイニシャルコストが必要であり、
正しく筋道を立て、その時に相応しいものを用意する必要があるというのもまた然りで、
それを考えるのが我々の仕事なんだと思います。

まだまだ、これからですねー。ITで人生最適化だ。

実践Apache Camel:CSVをあやつる（Stub）

Sat, 13 Oct 2012 12:50:07 +0900

現在、事務系の会社に勤務し、データ操作業務をJava+Accessで行っています。
最近は、Apache Camelを使ったコードを書くことが中心になってきました。
今回は、Apache CamelでCSVを扱う時のポイントをまとめてみようと思います。

1.Apache Camelのスタンドアロンパターン

Apache Camelでは、ルーティングルールと呼ばれる処理の手続きをJavaコードに記述します。
スタンドアロンの用途においてApache Camelは、
プログラム実行とともにローカル内の特定のフォルダを監視をはじめ、
そこにファイルが投入されたらルーティングルールに基づいた処理を行い、
処理が終了したらファイルをフォルダから消去（あるいは移動）します。
ルーティングルールは、一つのJavaソースファイルの中に、並列的に書くことができます。

　public static void main(String[] args) throws Exception{
　　　Main main = new Main();
　　　main.addRouteBuilder(new RouteBuilder()){
　　　　　@Override
　　　　　public void configure() throws Exception{
　　　　　　// prefectureフォルダを監視
　　　　　　from("file://prefecture")
　　　　　　　.process(new PrefectureProcessor())
　　　　　　　.to("file://./");

　　　　　　// cityフォルダを監視
　　　　　　from("file://city")
　　　　　　　.process(new CityProcessor())
　　　　　　　.to("file://./");

　　　　　　// houseフォルダを監視
　　　　　　from("file://house")
　　　　　　　.process(new HouseProcessor())
　　　　　　　.to("file://./");
　　　　　}
　　　});
　　　main.run();
　}

この例では、一つの実行クラスによって、三つのフォルダを監視し、
フォルダごとに別の処理を行うよう、記述することができています。
エクスプローラー上から、三つのフォルダのいずれかにファイルをドラッグ＆ドロップすると、
処理が終わったタイミングで、ファイルがディレクトリに戻ってきます。
ですので三つの処理をどの順番でかけてもいいし、何度かけてもいいのです。
エクスプローラー上でオペレートが可能になる、という点は、
事務系のプログラマから見ると、非常に魅力的です。

2.Apache CamelでのCSVの読み込み

CSVはそれ自体はプレーンなテキストであり、
改行記号とカンマによって行と列を表現した二次元のデータ構造です。
CSVのデータ構造をApache Camelに理解させるには、以下のように記述します。
※CSVコンポーネントを利用するためのライブラリ、camel-csvのロードが必要です。

　　public void configure() throws Exception{
　　　　from("file://foo").unmarshal("csv");
　　}

CSV形式でunmarshalすることによって、
メッセージのペイロードは、Listクラスに変換されます。

　　public void configure() throws Exception{
　　　　from("file://foo").unmarshal("csv").process(new Processor(){
　　　　　　@Override
　　　　　　public void process(Exchange exchange){
　　　　　　　　// unmarshal済みのcsvをListオブジェクトとして取得
　　　　　　　　List list = exchange.getIn().getBody(List.class);
　　　　　　　　System.out.println(list.get(0).get(0));
　　　　　　}
　　　　});
　　}

このサンプルでは、csvの先頭セルのデータを読み取って標準出力しています。

3.フィールド行の読み込みとMap化

CSVでは多くの場合、先頭行にフィールド名の情報が記述されます。
これをもとにListクラスからListクラスへ変換を行い、
以降のデータの扱いを容易にするようにします。

　　//ルーティングルールの記述
　　from("file://foo").unmarshal("csv").process(new ToListMapProcessor());
　　
　　
　　//プロセッサーの記述
　　public class ToListMapProcessor implements Processor{
　　　　@Override
　　　　public void process(Exchange exchange){
　　　　　　List list = exchange.getIn().getBody(List.class);
　　　　　　List> listMap
　　　　　　　= new LinkedList>();
　　　　　　//フィールド名をListとして保持
　　　　　　List csvField = list.get(0);
　　　　　　int size = list.size();
　　　　　　for(int row = 1; row < size; row++){
　　　　　　　　Map map
　　　　　　　　　　= new HashMap();
　　　　　　　　int column = 0;
　　　　　　　　for(String field : csvField){
　　　　　　　　　map.put(field, (String)list.get(row).get(column));
　　　　　　　　　column++;
　　　　　　　　}
　　　　　　　　listMap.add(map);
　　　　　　}
　　　　　　exchange.getIn().setHeader("field",csvField);
　　　　　　exchange.getIn().setBody(listMap);
　　　　}
　　}

ListからListに変換するには、
列番号⇒値の対応を、列名⇒値の対応に変換してやればよく、
そのためにlistの先頭行を、列名として利用しています。
また、ListオブジェクトのcsvFieldに、"field"という名を付け、
メッセージのヘッダーにセットしています。
これにより、以降のプロセッサーでもフィールド情報を簡単に呼び出すことができます。
このようにオブジェクトを簡単にマッピングできるのも、Apache Camelの魅力の一つです。

(つづく)