Kousei Ikeda/Blog

2017.11.29/Works
アートボード 1

株式会社闇と一緒に、漫画×ホラー×株&仮想通貨なウェブサイトを作りました!TD+Prを担当しました。

今回は、恒例メンバーに加え Keiko Hakuiと 西垣 香須美 (Kasumi Nishigaki)ら新戦力の天才アルバイター達が。彼らの働きとそれにあわせた設計で、地味に過去最多くらいの膨大な演出箇所を消化できた。そういう意味ではスケジュール/要件/やりたいことにあわせてリソースを最大化する設計ができたんじゃないかなと。いやでもほんとにふたりとも飲み込み早いし出来が良くてさすが。

技術的にも過去の闇案件の知見のメンバー内での蓄積から、普通ならやらない判断だろみたいな土壇場で「やったほうがクオリティ上がるからやる」判断ができたポイントも。外側もコードも全く新規なんだけど、知見としてはなんとなく元気玉みたいなイメージを感じてる。もしくは合体ロボ的な。
でまあギリギリで、この実装やったほうがおもしろいけどやるかやらないか…まあやるか、やれるでしょ、やろう!とチームがアクセル踏む瞬間。

やらない判断もありなんだけど、もしやれなくても巻き戻して成り立つっていう冷静な判断を片手に持っておきつつもう片手には、自分には絶対にそれができるしそしてやるべきだという確信を持って臨むということ。そのバランスだよね。

他人からは全くわからなくても思い出すと胸が熱くなって鼻がツンとするような、そんなエキサイティングな瞬間。そういうの存在するよね。

もちろん、ギリギリをGOに倒すか否かは案件の性質と目的や効果によると思うし。そこは適切に判断すべきだししてるつもり。ギャンブルじゃなく、リスクをとるということ。

プログラマとしての密やかな喜びとしては、コードの設計が上手く行ったなっていうのが結構あって。仕様の追加変更に対して大規模な構造変更をほぼ伴わずに対応できたかなと。こういうのってプログラマにしかわかんないと思うけど地味に結構嬉しいもの、だよね。
一方でもちろん課題も新たに感じていて。

裏側で下支えする感じにまわったのでモーションのコードもっと書きたかったなとか、もっとシェーダー書きたいとか。最近映像制作リソースが充実してきたことに端を発するプリレンダリングの映像を制御した演出とリアルタイム/インタラクティブ演出の使い分けに関する考察とか。ボリュームのほうにエネルギー持っていかれたかなぁ、より大きいものがより良いものだとは限らないよ?とか。要所要所でもっと良い判断ができたんじゃないかとか、、、。
まあ個人レビューでは課題に枚挙のいとまはないものだよね。

あと表題のネタね。
この案件の納品日のまさに翌朝、起きたら右手がなんかおかしいのよ。キーボード打てないのね。過去に闇V2を作った時に突発性難聴になったことがあったんだけど、今回は撓骨神経麻痺になって利き手が麻痺してキーボード打てなくて過去最高に焦った、みたいな。納品終わるまでならないとかどんだけ優秀な労働者なんだ、と思いつつ、他にも案件あったからすぐ医者2件行って。1週間〜2週間くらいっていわれてこれはやばいと思い速攻で外注リソースの確保に奔走したけど何故か翌日寝て起きたら治ったからセーフ。
健康だからすぐなおったのか。医者に脅されたのか。それとも忙しいから一番すごい薬下さいって言ったのがよかったのか。まあ治療法で急に治る類ではないと言われてたけど。
この話をすると不健康さをよく心配されるけど、呪いでも内部疾患でもなくて疲れて変な場所で寝てしまった外因性らしく、酔っぱらいとかは電車に乗ってるだけでなったりするときもあるらしい。どんな健康な人でもなるときはなるらしいから、硬くて尖った物の上で寝ないことをオススメします!
まあおいといて、とりあえず、知見の元気玉みたいな感じだったし次は全然違うことやろうかな。全然違うことしよう。

ともあれありがとうございました!

KOWAKABU | Archive | Kousei Ikeda http://ikekou.jp/archive/2017/10/kowakabu/

2017.07.13/Event, Works

og

いよいよ明日、7/14からスタート。毎年夏恒例な株式会社闇で、MBSさん&NTTさんでご一緒させて頂いてるMBSお化け屋敷プロジェクト、今年はひらパーでやります!

着ぐるみとか人形ってなんとなく怖い、、、そんな恐怖を主題に、長年ひらパーにあって今年4月にクローズした「ファンタジーキャッスル」を題材に「呪いきぐるみギギ」というひとつの世界観で昼と夜で全く別で2つのお化け屋敷なんです。

ほんとに長年使ってた人形ならではのホコリとか汚れとかほんともうすごいいい感じで、こんな機会はもうそうないだろなぁと。

演出はさすがのお化け屋敷プロデューサー五味さん。「ここで来る」ってわかってても声でちゃう怖さです。

昼は屋内で、例年の梅田お化け屋敷の数倍の圧倒的ボリュームで楽しめるお化け屋敷。ついこないだまで光のあたる場所で人とともにいた人形たちが終わりの時を迎えて暗闇に佇む姿はいますぐに付喪神になって動き出しそうでもうむっちゃ怖い。

夜は夜で、閉園後の暗いひらパー全域を使った屋外型お化け屋敷。こちらも同じくファンタジーキャッスルの人形たちが出迎えてくれて、ひらパー全体が、いいようのない恐怖に包まれます。ほんでまあ普通に、閉園後の遊園地を歩き回れるまわれるってだけでまずないレア体験で、不思議でキレイで楽しいし、普段は怖いのが苦手だからお化け屋敷とか行かないわ〜って方も、楽しんでもらえる感じがしてます。行かないと勿体無いです。

個人的には呪い着ぐるみのギギがだんだん可愛く見えてきてます。ストーリー含めてかなり魅力的なキャラクター。グッズ発売したら欲しい。

夜のほうはチーム参加なので4人一組(または5人)で申し込んでね、っていうのが若干ありますが、そこはご友人と連れ立っていただいて、ぜひに昼夜ともに遊びに行ってみて頂けると嬉しいです!

お化け屋敷xホラーナイトツアー ひらパーの怖い夏

2017.06.04/Works

20170525-DSC_5215

JavaScriptを題材に、オブジェクト指向プログラミングの入門講座の講師をした。お声がけいただいたのは京都の制作会社三社、有限会社アーキテクトタイタンさん、株式会社おいかぜさん、株式会社翠灯舎さん。場所は株式会社おいかぜさんのoikazeCUBE。

さて、JSでOOPを扱うということになり、当初の自分の想像以上にかなり内容をまとめるのに苦労した。普段自分が業務で書く分には特に問題ない程度に使っている使えていると思っている部分も、教えるとなるとやはりいったん復習。あらためて調べ直しはじめると、とにかく(少なくともES5までは)言語レベルで定まった書き方がないため特にクラスや継承まわりが「良くみかけるこの書き方はここがダメだ、俺の考える正しい書き方はこれだ」という記事が、知ってはいたが星の数ほど出て来る。いや、星の数ほどは言い過ぎだけど。

こりゃあかんやっぱ本だ、と思ってオライリーのJS関係の本もわさっと買ってあらためて目を通したが、それぞれ微妙に否定し合う部分もあったりして、自分では困らないレベルに普段ある書き方に定めて書けているとしてもどれを「正しい」と教えてよいのかかなり悩んだ。というか、どの書き方もそれぞれにメリット/デメリットがあってそれゆえに多様な意見があるのだとおもうし、でなければそろそろたった1つの方法に収斂していてもよいはずだし。とにかくあらためて初学者にはこれはかなりつらいのではないか、と思った。

クラスベースの言語じゃないと言われつつ糖衣構文としてclassキーワードが使えるようになったり、やっと導入されたそのclassキーワードすら、導入は失敗だった、これは使うべきではない、と書いてある本も見かけた気がするし、「classキーワードを使うやつと同じプロジェクトに入るのは俺はまっぴらごめんだ!」なんて言ってる方もいたし、初学者が色々調べたら調べるほどに完全に混乱すると思う。というか自分も今回あらためて調べまくって一時的にかなり教え方に悩んだ。

とはいえ、色々な情報をわ〜っと自分の中に入れて今回の講座向けにどうしようか考えをまとめたところ、いろんな書き方を都度試行錯誤して自分なりの究極の書き方をトリッキーに実現するより、もうみんなそろそろES6で書いてclassキーワード使うのでいいんじゃないかな、究極のJSマスターからするとclassキーワードを使うのはベストな方法ではないかもしれないけど、みんなが読んで理解しやすくコードがシンプルになるという意味でのコストメリットも考えると、それなりの場面でそれ(classキーワードを使う)でいいんじゃないかな、っていうもともとの思考に一周して戻った。

それにそもそも本講座の目的自体がどちらかというとOOPをしようとするということはどういうことか?という思考の指針を初学者に示してあげることだと考えていたから、JSの高度な書き方のテクニックの部分にあまり余計な気を取られたくなかったので、とにかく今回はシンプルにclassとextendsを使うことにした。今日はES6でclassキーワード使うけど、案件によってはBabelを入れれないものもあると思うしということでES5での最も基本的な気がする書き方への変換も示しつつ。

結果として狙いは成功したと感じていて、classを作るのが人生初でES6とclassキーワードを書いたことが一度もない受講生さんもその部分は全くひっかかりなく書き方は覚えてくれて、OOP的な考え方、ひいてはクラスにどういう機能をもたせてどういうインターフェースを持たせるか、の部分に頭を悩ませることに時間とリソースを割けたと思う。

今回、講座の準備をしていて改めて思ったのは、インターネットにはやはり情報が無限(に感じられる程)にあるということ。そしてそれはときとして迷いを生じさせコストを増加させるということ。そういう時にはやはり本を手に取ることに一定の利点があるということ。(でも本でも情報がバラバラなことがあるということ・・・でも多分今回が自分史上最高にまとめるのに苦労したし他の言語ではここまでの苦労はあまりないようにも思うが。)

そしてそれら知識を得る方法がたくさんある今、じゃあどういうところに直接教える利点があるかというと、やはりコミュニュケーションを取ること。言語化しづらい、検索しづらい悩みを引き出す問いかけをして、それにフィードバックをするということ。

今回でいうと、classの書き方を覚えるのはすぐだが、とにかく初学者なので「そもそも良きクラスとはなんだろう」という指針が自分の中にない。だからとにかく基礎の書き方を教えたら、課題を出して、チャレンジしてもらいながら「その機能はそのクラスが持っているべきかな?」とか「そのメソッド名を見た人がする機能の想像と実際の中身があってるかな?」とかそういうやりとりを個別にしていくことに、結構手応えがあったように思う。

これってふと考えると要はペアプロみたいなもので、規模の大きな企業、自社サービス系だとそんなの普通に行われてるよなにいってんの、というものだとは思うが、受託メインだったり、中小の制作会社だとなかなかそうもいかないと思う。自分もそういう環境を享受できた経験はない。自分ももし自分よりできる人とそういうやりとりを日々しながら仕事をできていたらなんて良かっただろうと思っていた・・・というか今でも毎日思っている。が、みんな忙しいし、人手が足りないから呼ばれたり採用されたりするわけだし、各々が前に進んでいるので、なかなかどうしてそういう機会を得るのは簡単ではない。

あと、一人で全員見きれないことも想定して、翠灯舎の佐野さんに補助講師していただきつつの、佐野さんは普段はPHPメインの人で(そしてJSもやってらっしゃる)言語は違えど時折佐野さんと「こういう時僕はこういう感じなんですけど、どうしてます?」「あーPHPの人はこんな感じにしてる人が多いですね」みたいな別の視点も入れて頂いたりしながらの雑談も交えつつのスタイル。多分、受講生全員をみてまわるという点と、講師・補助講師間のかけあいという点で、補助講師は重要、いていただいたほうが良いと痛感した。

実は、果たして僕がこの題材を教えることが適切なのか、は正直迷った。自分はOOPの全てを知り尽くしている、だから教えれるとは全然思えていない。そもそも僕は普段の仕事内容的に演出重視のサイトやインタラクティブコンテンツを作ることが多いし、長期保守するプロダクトばかりでもない。つまり究極に設計をつきつめることが利益につながる立場になく、そこまではしていないできていない自覚はある。またGoFの全パターンをそらで書けるわけでもないし、大規模なシステム系のJSを日々書いてるわけでもない。SIer勤務でもない。毎回「あーここの設計もっとこうすればよかったなぁ」というのもある。しかし理想的にまでつきつめられていないとはいえ、各プロジェクトにおいてスケジュールとリソースと座組を考えてここまでというバランスの判断を適切にすることに意味はあると思っているし、界隈の同業と比較してそれついて考えるのがどうやら好きであるという肌感はあるし、それに受講生の方々の普段のお仕事も大規模システム系ではなく近いものでその点においては受講生の方々より自分にはいくらかの経験があるし伝えられることもある、という自信はある。じゃあ何をやろう?という思いで組み立てた講義アウトラインだ。ただやはり学びのロードマップを考えいてった時に、あるレベル以上のより高度なテーマについては、大規模・多人数・長期保守・自社プロダクトゆえにスケジュールとリソースが潤沢にかけられている、そういう会社の設計のエキスパートを招いて、一緒に内容を考える企画をしたいな、と感じた面もあった。まあ今回は初学者講座だし、それはまだまだ先のレベルの話だ。

さらに余談だが、今回の資料は、Marxico、Dropbox paper、Keynote、色々迷った。Marxicoはプレゼンテーションモードがない。Keynoteはシンタックスハイライト機能がない。Dropbox paperは両方あるが、僕の環境では日本語入力時に1文字目が勝手に確定される謎のバグが起きていて(サポートにも投げたのだが)きつかったのと、書体を指定したかった。ということでMarkdownで書いてPDF化できるElectronアプリMarp – Markdown Presentation Writerを見つけて、ソース落としてきて吐き出すPDFの見た目とかを好みにいじってビルドして、出力した。便利だ。多分次もこのスタイルで行きそう。

話は戻るが、結果として受講生さんから良い感想を頂いているのも聞こえてきて、講座をどう組み立てるのかにかなり試行錯誤した分、嬉しかった。ありがとうございました。そして講座はまだ続く。準備頑張ろう。

JavaScript course in KYOTO vol.2 : OOP with JavaScript | Archive | ikekou.jp

2015.10.18/Works

IMG_9456

株式会社フィールドさんが運営されている「いろいろスクール」で「JavaScriptで学ぶプログラミング初級講座」の講師を担当しました。

4回講座で、プログラミングの基礎をやってみようという趣旨。初級講座なので、全く経験ない人にも、心理的ハードルなしにやってみてほしいなというレベル感で設計してた。内容は全部僕らが決めるから、長山さんと一緒に白紙の状態から設計したからなかなか難しかった。

そして昨日ちょうど、発展版にあたる「JavaScriptで学ぶプログラミング実践講座」を開始。初回は僕担当で、オブジェクト指向のとっかかりを2時間にいかに凝縮するかを考えるのに、授業の設計と資料作成でその何倍もの時間が。初級講座より、より抽象的な概念を扱うから、伝え方が全然難しいものだなと。

でもまあ、この時間で全て学ばせるのは当然無理ではありつつ、導入としてはそこそこによい優先順位の付け方と伝え方をできたと思いつつ、というか受講生さんがはじめてなのに結構理解していただいてみなさん優秀、という話でした。

2015.10.03/Event, Works

IMG_9940
IMG_4588

「スパイラル」30周年記念事業展覧会「スペクトラム ―いまを見つめ未来を探す」展で、高橋匡太さんのインスタレーション作品<いつかみる夢「散華」>をシステム面担当でお手伝いした。東京都青山にある、ギャラリーと多目的ホールを中心にワコールアートセンターが運営する施設が、スパイラル。

30年の流行色の変遷をテーマにした流れるような照明演出と、過去と現在が重なり不思議な感覚をもたらす映像で、作品は構成される。
一面が色に染まった空間と薄暗い空間に明るく浮かび上がる不思議な映像は幻想的で非日常をもたらしてくれる。ずっとそこでぼーっとしていたい気持ちになる。設営中にごろんと仰向けになって空間を味わえたのは役得。

それに過去は平面だったけど今回は長い階段状の通路に設置したから立体感があってそれもよい影響をもたらしてたと思う。

何度かお手伝いさせていただいているのでシステムやノウハウ的にはかなりこなれてきて、タイトなスケジュールだけどなんとか。初回の大変な記憶からすると成長したなと・・・ただそれでもまだトラブルがあるのが現場の難しい所。毎度場所違うし。リスクはゼロにはならないけど、最小化するために機材決めたり、削られがちな機材費をクドクド説得して予算引き出したり、オペレーション決めたり。なんかそういうのも役目。
スケジュールがタイトだったからiOSは友人のMasashi Tanakaに手伝ってもらって。なんとか。

開催は2015年9月26日(土)— 10月18日(日)なので、お近くに行かれる機会のある方はぜひ。

[ Credit ]
Masashi Tanaka : iOS Programming
Kousei Ikeda : Technical Direction, Programming

2015.09.11/Works

Scenery iPhone 6 - 398 - 2015-09-11 0-59

SCRAPさんの脱出ゲーム企画「呪われたオーディション会場からの脱出」の告知サイトを作った。
株式会社闇案件。

コアコンセプトは「脱出ゲームの告知サイトから脱出する面白さ」「謎が解けなくてもホラー体験できる楽しさ」。

まず基本的な謎が4問。それを解けた前提で挑戦する第5の謎があって、さらにもうひとつ最後の大きな謎がある。その謎解きの面では、リアルな脱出ゲームの謎の面白さとはまた別の、ウェブサイトであったりスマホであったりという特性も活かした謎を盛り込めたのもよかったなーと。

一方で、ターゲットとしては謎大好きな既存謎解きユーザー、スクラップさんの既存ファンだけでなく、株式会社闇としてのリーチも生み出したかったので、謎解きが得意じゃない、謎を解けない(僕のような)人間にも楽しんでもらえるようにしようと。謎が解けなくてもひと通りの演出は体験できるように設計されてる。

ヒントを出すかどうか、どのくらいゲームオーバーになりやすいかどうか、とかも、開発チーム内でのレビューも繰り返しつつ、社内だけど案件に関わってない人を数人づつ計画的に使って体験してもらって、調整。あとは拡散目的の、友だちにこのサイトを送りたくなるような機能もつけた。
ホラーサイトだけどどの程度ユーザービリティは意識していて、スクロールジャックしたりで要は自己操作感をどの程度持たせて、どの程度奪うのか。という調整もしてる。

謎作りはスクラップさんが軸となるネタをくれて、Tonkaさんが肉付けしていった感じ。謎解きに詳しいわけじゃない僕から見てだけどなかなか良い気がする。
(そういうえば前にも本人の結婚式で謎解き2次会やっててそんときもおもしろかったんだった。)

ホラー演出案とデザインもいつも通りTonkaさんがハイクオリティなやつを光速で作ってくれた。ほんとホラー好きだなぁ。

構築面では、静的なページのHTMLコーディングはOkudaさんにお願い。
あとは僕も企画段階から入って一緒に考えつつ、全体設計、プロト制作、技術選定、俺も演出考えたり、フィジビリティのジャッジ、テクニカルディレクション、プログラミング、モーションデザインとかはいつも通り担当。

作りながら、あーこういうのもアリだね、今回は使えないけど今度使おう、みたいなのが色々発見されるのは、やっぱり頭のなかだけで考えてるのより、全然出てくるよね。

技術的に言うと、最初はCanvasでやる部分とDomでimgタグ動かす部分とWebGLとハイブリッドでやろうとしてて、WebGLやりたいなーって単純に思って(笑)、pixi.jsとかCreateJSとか検証してたけどWebGLはパフォーマンス求める部分が今回ないのでコストに折り合わないから割愛。
ビルドにはGulpとBrowserifyとつかって、browser-syncとBrowserifyとWatchifyとあとまあUglifyとか定番の諸々という感じ。
バージョン管理はGitでgit-flow。とはいってもルールは厳密じゃなくて都合がいいぶぶんだけ取り入れてる程度だけど。git-flowは結構好き。(とはいえgithub-flowとかやったことないから比較の上ではない)
画像まわりでいうと、SpritesheetつくるのにFlash CC 2015を通すと新機能でいい感じなのだけど、結局CanvasもナシにしてDom操作だけに今回はしたから、Flash通して吐き出すのはあまり相性が良くなく。
TexturePackerとかSpineとかも検証したが、Retina対応が微妙(というか時間内にやりたいことの使い方がわからなかった)・・・SpritesmithはRetina対応できるけどこれまた若干問題が・・・ということで時間もあまりなくて見切りをつけて、画像ファイル自体の最適化とか読み込みタイミング調整して体感上特に問題ない感じになったのでSpritesheetはまた今度ってことに。ここらへんのワークフローは確立しておきたいな。
Canvas使うなら、Flash CC 2015を通して素材吐き出すとSpritesheetの画像とJSを吐いてくれて、今は良さそう。闇サイトのときはその機能Flash CC 2014にはなかったから、あんときあれば・・・という思いはある。
JSは自作のクラス群もdeath.co.jpのときに作ったやつがある程度こなれてきて、その時は入れてなかったBrowserifyで依存関係は管理できてるし、まあそこはしっくりきつつある。
そんな感じでJS的には特になんか特殊なことはしてない。普通。普通のことを柔軟かつ高速にどうイテレートするかっていうことだと思う。

足音撮るためにオフィスに水まいて広報DQに歩いてみてもらったりとか、耳元で囁かれる感のある声を撮るためにこれまた広報DQに耳元でDISってもらったりとか、そんなことしながら音も録音したり。工夫した割に結局使ってないやつもあるけど、面白かった。次も囁いてもらえる企画ぶっこもうと思う。

謎解き自体は自分は慣れてないから、自分が普通に取り組んだら解けないだろうなぁと思いながら公開したら、公開してすぐにもう解いた人何人もTwitterにいて。すごいなーって。すごい。俺全然解けない。

ホラーの恐怖って要は死の恐怖を連想・喚起する行為だと思うから、ホラーサイト作りながら死について考えてみる、、、そんな日々を経て、完成。

ということで!ぜひぜひ。やってみてね。
あとお友達に教える時に楽しい機能もつけたし。それも使ってもらえたら嬉しいなと。

[ Credits ]
Seitaro Tonka : Direction, Art direction, Design
Yusuke Okuda : HTML/CSS Coding
Yoshiko Dokyu : Special Thanks
Kousei Ikeda : Techncal direction, Motion design, Programming

リアル脱出ゲーム「呪われたオーディション会場からの脱出」 http://realdgame.jp/audition2015/

2015.07.22/Works

takahashi-animation

株式会社闇と一緒に、お化け屋敷で使うシステムを作った。
といっても今回はビビらせる部分のシステムではなくて、今あるお化け屋敷にエクステンションして、来場者にもっと楽しんでもらうためのシステムという感じ。

MBSさんが毎年夏に期間限定で開催しているお化け屋敷で、今年のテーマは「呪い指輪の家」。
ストーリーと演出はお化け屋敷プロデューサーの五味弘文さん。
オバケがデジタルまわりのプランニングで入ってて、一緒にやろうってことになった。
打合せ行って「オバケです」「闇です」って挨拶する時のホラー度数の高さすごい。それだけでもうアイスブレイク完了する威力絶大。

体験の流れとしては、

  1. 最初にニックネーム登録をして、バーコード入りのレシートを受け取る。
  2. そのあとバイタルセンサーを受け取って、お化け屋敷に入る。
  3. 入っている間にバイタルの値が取得される。あと複数アングルでビビってる映像が撮影される。
  4. 出てきて動画を確認・承認すると、バイタルの値を解析して算出されたビビリ値と、撮影された映像を使って、完成版の動画が生成される。
  5. 動画を生成したらアップロードして、ビビり度のグラフを入れたウェブページを生成して、アップロードして、完成。
  6. 最初に貰ったレシートからURLにアクセスすると、自分の動画とビビリ度グラフが見れる。

て感じ。で、その一連の流れを可能な限り自動でやる仕組みを、作った。
とはいえなんでもセンシングしてやればいいかっていうとそうでもなくて、人力にまさるものはない部分もあるので、そこは人力で。
イベント系は、コスト面でも運用面でも、ここのバランス感覚とジャッジが大事かなという印象。

お客さん向け説明だけど、詳しくはこちら。
ビビり度診断について | 梅田お化け屋敷2015×NTT西日本 「呪い指輪の家」

asdf

センサー制作と解析の実装の部分、愛知県立大学とNTTが共同研究として行っているバイタルデータから恐怖を数値化する研究をベースに、NTTさんが開発した今回専用のデバイスでやってる。

お化け屋敷の、今回は変えられない部分があって、変える余地のある部分があって、与えたい印象や演出とか狙いとかあって、全体の正常なユーザー行動フローがあって、リタイヤしたりっていう想定しうる異常系があって、なんかよくわからんエラーが起きたりっていう想定外の異常系があって、そこらへん視野に入れつつシステム全体考えて、あとはNTTさんとの切り分けして、つなぎ込みして、、、打合せとメールを厭わずにいっぱいしてFIXしてく。

一方で僕と、一緒にやったSTARRYWORKSの久保田さん、は得意領域や知識領域が違ったので、互いにフラットに質問したりアドバイスしたりできて、なんかいろいろおしえてもらったし、そこもふまえつつタスク振り分けたり、そういうのが忌憚なくできる人間関係はすごいよかった。チームでがつっとやるの楽しい。コミュニュケーションコストの低減はスピードにつながるし当然クオリティにつながるし、なによりストレスが減るし。そこに無駄なエネルギー使うのほんと勿体無い。意味ない。座組的には、MBS、五味さん、NTT、愛知県立大学、オバケ、闇、と色々いたんだけど、そういう意味では少なくとも観測範囲の全員が気さくで柔軟ていうものすごくありがたい案件だった。

お化け屋敷自体、去年より仕掛けのボリュームも2倍くらいになってるらしいし、今回僕らのシステムも入ったし、他にも新しいチャレンジがいくつかあって、どうしてもリスク避けて去年と同じことしようってなったりしそうなところで、いやこれだけ色々と新しいことをやろう!という意思決定の力のすごみ感じる。

でまあ諸々FIXしたら(しながらだけど)久保田さんとゴリっとプログラミングして、最後は現場入りまくって調整とテストをひたすらイテレート。ここはもう根気が安定性につながると思う。あらゆるタイミングのでユーザー離脱(お化け屋敷ではままある)するユーザーの行動シナリオを思いつく限り書きして検証するときにはお化け屋敷大好きな頓花さんの経験がものすごく活きたし、どの瞬間にアプリが落ちても次復帰して続きから動くようにしたし、監視もしてるし。色々とノウハウ溜まってくのはよいこと。

サーバーサイドは負荷対策してる時間今回はなかったからS3とJSで乗り切る。そのために画像からHTMLまで全部ローカルで自動生成してアップしてる。

オープンしてからもとれた映像みながらカメラかえたり、アングルなおしたり、スタッフとタイミング調整したり、サイトなおしたり、色々と改善していってる。中長期のイベントで改善していくのって面白いな。

問題は、やっぱそういう柔軟性ありきでなんとかなった感じなので、例えばガチガチにスケジューリングして外に振るとか今回は想像がつかない。自分らがCL含むステークホルダーと直接コミュニュケーションとって、仕様策定〜デザイン〜プログラミング〜現地テストまでいつでもやれる力があってできることで。PM的課題は次回に持ち越しと言える。まあそもそもウォータフォールとか無理だと思うけど。

あとは今回は驚かせる演出部分とか、個人ページ部分じゃない本体ウェブサイトとか、全体のアートディレクションとか、デバイスまわりとか、は関わってないから、次はそこにも噛みたいところ。まだまだプラスになれる部分いっぱいあると確信した。

あとなんだろ、テレビ局の美術さん、ものすごいスピードで、しかもでかいのを、今回用の建物とか造作とかあっというまに作っていくので、さすがものすごいなと。こちらからなにか依頼できるならしたいくらい。

鷹の爪もムービー作ってくれてて。さすがのクオリティ。わかりやすくて面白くてテンポいい。
【呪い指輪の家×鷹の爪】大阪会場スペシャルムービー – YouTube

梅田お化け屋敷の本体サイト。(このページはMBSさん制作なのでぼくらは作ってない。)
梅田お化け屋敷2015×NTT西日本「呪い指輪の家」|MBS

お客さん向けの、今回のシステムについての説明ページ。(こっちはぼくら。)
ビビり度診断について | 梅田お化け屋敷2015×NTT西日本 「呪い指輪の家」

KAI-YOUさんも紹介してくれた。ありがとうございます。
大阪のお化け屋敷が超怖い…! 株式会社闇、五味P、NTT西日本がタッグ

関係者のみなさま、ありがとうございました。
ものすごく怖いから絶対行って!と、お化け屋敷大好きな頓花さんも看板の陰から言ってる。9/6までやってるから、みんなぜひ。

IMG_3864

2015.05.19/Works
IMG_2782

IMG_2782

去る4/1に公開した「株式会社闇」のサイトをつくりました。今月のウェブデザに掲載してもらってたのであらためて。

担当はテクニカルディレクションとプログラミング、あとモーションデザイン。クリエイティブディレクション担当の頓花さんがやりたいことをこちらも意見ぶつけつつ、もちろんこちらも演出のアイデアも出しつつ、最大限実現する。

開発環境構築、技術検証、パフォーマンス検証、ライブラリ選定、プロト、全体設計、実装、モーションデザイン、途中から実装者を増やせるように疎結合に考えるとか、再利用しやすいように作るけど時間もかけすぎれないバランス考えたりとか、あとスポットで手伝ってくれれる人のスケジュール考えて準備しつつタスク割り振ったり、次々出てくる演出の要望に対してリソースとスケジュール判断して可否を回答、、、とかとか。

コーポレートサイトなんだけど、「怖がらせる」ということを考えて、かつその後ユーザーはどうするのか、どうしてほしいのかって考えたときに、友達同士のLINEグループとかで行われてる怖い動画リンク貼りを思い出した。自分が怖がったあとはきっとこれだろうな、って思ってそこにフォーカスした。きっと、「これ怖いから見てみてよ!」か「これ面白いから見てみてよ(怖いけど言わないでおこう)!」みたいな友達へのイタズラ的ユースケースが生まれると思った。そしてその予想は当たったと思ってる。twitterとか見ててもそういう風に楽しんでもらった人も多かったみたい。自分自身も友達に見せてビビってるとこ見て楽しんだし、そしてそれはそのまま認知拡大施策なわけで。

きっちり固まってから投げてもらう外注さんていう感じじゃなくて、僕も大阪に行って、チームみんなでデザインしたり実装したり映像作ったり音作ったりっていうのを同時進行にガっとみんなでやって超スピードでクオリティ上げてく感じ、あれは根詰めるから体力的には疲れるけどやっぱ楽しい。濃いチームでないとできないと思ってる。

うまくいった一方で、サーバー落ちたりして、最初からスケーリング考えとけばよかったなとか、色々反省点もある。まあ実際のところ誰もその余裕はなかったからしょうがない。正直、実装も自分的に完璧ではないけど、優先順位は色々あって、残り時間も少ない。まあなんせ自社サイトだから、意思決定者はそこにいるし、切るものはガンガン切る。案件において意思決定の時間的コストはとても大きいので、承認フローが少なく、意思決定が早く、結果として短時間でクオリティが上がってく、という良いサイクル。案件でもクライアントと直接話せるかどうかでコストは大きく変わるんで、あらためて思う。つまり事業会社がクリエイティブを抱えると最強、、、ってことだよね。まあそれは意思決定がされる前提なので、もちろん一概には言えない。

クモの動きのキモさとか、文字の動きとか、を試行錯誤してるの楽しかった。演出をしないデバイスとするデバイスは当然あって、そのあたりもスムーズにいきやすい構築フローはちょっと見えた。

あとサイト内に使われている音もオフィスでその場で録音して加工したやつ。僕も音出す役で参加してる。音源俺、みたいな。どの音かは内緒。

4/1に公開してから結構バズって、加えて広報担当の頑張りもあり、色々な人に見てもらった気がして、とても嬉しい限りで。その後株式会社闇としてはありがたいことにお問い合わせなどもそれなりに頂いているようで、自分たちが「これ楽しいでしょう」と思って作ったものが、自分たちのビジネスゴールに連れて行ってくれるのはとても幸せなシナリオだなと。実際作ってて楽しかった。

お声がけ頂いたスターリーワークスさん、ありがとうございました。いつもありがとうございます。

Darkness inc. | Archive | ikekou.jp
株式会社 闇

2015.05.09/Works


お仕事で山形産業科学館の常設展示コンテンツを2つ、製作しました。

科学館と聞いてわかるように、子供が科学を学ぶ場。今回作るのは音コンテンツ。周波数(数値というよりは波)と音の関係がふんわりとわかるといいなという趣旨。

細かいコンテンツ内容はリンク先に譲るが、パっとやってみた基礎的な実装だと、周波数の変化がある程度のスピードまでなら問題なかったんだけど、高速かつ連続的に周波数を変動させると耳障り的に厳しく。1秒で44100サンプルで、1回に書き込むのが最小で2048サンプルだから、21ms程度なんだけど、人間の耳はちゃんと聞こえるんだなーすごい。ほんで高サンプリングレートのwavを読み込んでそれでも足りないデータを補完しつつ音を出したりとか、音まわりのバイナリいじったり、考えたアルゴリズムが当たって滑らかにできたり、無駄な試行錯誤もあったとは思うけど、それはまあ試行錯誤とはそもそもそういうものなので、作ってて楽しかった案件。勉強になった。技術的投資要素があるかどうかも、もちろんそれはクライアントには関係ないんだけど、自分がその案件をやるかどうかの判断としては大事。

UIとしては新しい(少なくとも普段使い慣れているものではない)ものになっちゃうのは必然なので、かつ子供がさわるから、可能な限り「次にやるべき1つのこと」だけわかるようにして、細かい説明はせず、間違った時にはじめて注意を出す、という方向に。してほしい動作はイラストやアニメーションを使って促す。

デザインはパートナーさんにお願いしたけど、画面が大きいからPC画面では感覚わからんだろうなと思ってフルHD出せるプロジェクタをAmazonでポチってデザイナーさんに送りつけて、あと実際の画面寸法送って、このサイズで出しながらデザインしてくださいってお願いする。文字サイズとかいちいちこっちで確認して修正してもらうコスト考えると安いと判断。実際これは良かった。

あと常設展示はやっぱ大変。安定性、UPSでのPCの起動終了にあわせて自動起動自動終了。電源管理も大事。子供がさわるからボタンのタフさとかも必要になってくる。

長時間動かすとkinectも思わぬ挙動する。デバッグも大変。こちらの環境ではいくら試しても再現しない問題も発生して。でも状況教えてもらって、写真も撮ってもらって、原因をカンである程度絞って、テキストでログ出力するようにして。再度起きたらログフォルダまるっとおくってもらって、膨大な量だからログを解析するアプリケーションも別途作って。ここまでくるともう人間てなんだろうっていう気になる。

ハードはMacにしたかったけどkinect使ってるから無理。あとオンサイト保守がないから別途それ用の会社と契約しないといけない。そのあたり普通みんなどうしてるんだろう。Winである必然性がなければMacで作りたいのが気持ちなのだけど、年単位で設置するやつはオンサイト欲しい。

今回は什器製作はイニシアチブとれなかって、気になる点はなくはなかったので、そこは今後の課題。

公開してから修正アプデもかけて、そのあたりはクライアントさんと直でやりとりしつつ、さらに非常に協力的でいてくれていたお陰でとてもスムーズ。ありがたや。関係性の構築大事。

今回は自分がディレクター兼テクニカルディレクター兼プログラマーだったから現地入ってからもゴリゴリコードさわって直す。デザインの意思決定も早いうちにイニシアチブ取れたからギリギリまで微調整できた。ここらへんは、自分が色々やりすぎるとリソースが足りなくなるとわかりつつ、色々やっているほうがスムーズな面もあると悩ましい部分。実装は1人アサインして2人でやってはいたものの、もし自分がコードさわってなくて(さわれなくて)D/TD/Prの3人が1週間もぞろぞろと現地に滞在すると費用が単純に3倍。今回は一人で現地入れる体制でよかった。

写真にはないけどカーペットに立ち位置の足型つけてもらった。すごいきれいにできてる。カーペットやさんすごい。

開発中にkinect v1が発売終わる。びっくりした。情報いただいて速攻で代理店さんに問い合わせて確保。

山形の食べ物むっちゃ美味しい。出張楽しい。過去には宮崎もチキン南蛮の美味しさに感動したし(チキン南蛮発祥の地)、青森ではイカの刺身をいかわたで作った醤油につけて食べる食べ方が美味しすぎて未だにいろんな人に吹聴しているし、そして今回の山形も山形料理はどれも美味しくて大体食べ尽くした。お仕事で行っているのでもちろん忙しいのだけど、晩御飯に現地のものを食べれると出張は一気に楽しい。そのくらいの時間を確保するのも精神衛生上、大事。笑

お話いただいたハートスさん、チーム組んでくれた軸屋さん岡本さん江見さん、色々アドバイスいただいたSI_HOさん、ありがとうございました!

余談だけどこの感じの写真の背景をもっとボケさせたいんだけどどうしたらいいのか。望遠を買うといいのか。F値のいいやつを買って開放で撮るのか。全然わかってないから次は写真の勉強をしたい。

Sound wave | Archive | ikekou.jp
Voice changer | Archive | ikekou.jp

2015.04.23/Works

スクリーンショット 2015-04-23 11.09.00

精華の1年生が2014年後期の授業でプログラミングを勉強して作品を作りました。そしてそれを有志の学生が春休み中にHTMLを勉強してウェブサイトにまとめてくれました。(まだあとちょっとなおすとこあるけど)

http://flashtown.digicre.jp/
※FlashなのでPCのみ

作品のお題は「身近な1人を思い浮かべて、プログラミングを使ってその人が楽しむものを作る」こと。
サイトのお題は「高校生が見て精華に興味を持ってくれるように考える」こと。

多分今日あたり、オープンキャンバスにもMac設置して展示してる・・・のかな。

プログラミングもHTMLもCSSも全部はじめて、とはじめてづくしで完璧なクオリティではもちろんまだないけれど、
発想や、イラストや、アニメーションや、音作りなど、今持ってる自分の武器とはじめてのプログラミングを組み合わせて、充分にさわって楽しい魅力的な作品になってるのはいくつもあるなと思います。
なかには、誰を思い浮かべたらこの作品になるんだろ、、、とグっとくるのもちらほら。笑

正直いろんな授業がある中で最も「全然やったことない」内容な授業の一つだと思うし、プログラミングわからん!逃げたい!って思いながらも、作りきってくれたのうれしいです。ほんとギリギリまでブラッシュアップしてくれた子もいるし。

加えて、2年生になってからも継続してプログラミングを学んでみたいと思ってくれてる子がいるってのはさらにうれしいわけです。

まあ、半年の間にMacが壊れる人が数人いて、こいつらどういう荒い使い方してるんだw と思ったりもしましたけども。

ということで、アーカイブサイト制作WG、お疲れさまでした!

制作 :
Ayase Muraya, Mika Yoshikawa, Tomomi Tamura, Yukari Nakano, Rei Yoshida, Rikako Kamata, Saaya Katayama, Kasumi Nishigaki, Chika Hayashi,

講師 :
Yukihiro Sasae​, Masayuki Nishimura​, Tomohiro Tsutsumi​, Kousei Ikeda​

Special thanks :
Shin Matsumura​

・・・ちなみに授業は講師4人が個別にクラスを受け持っていたのですけど、一覧を見ながら「ウチのクラスの子らが一番よくできてるわ〜!」と思ってます。w

>

Next page