from __future__ import katryo

カリフォルニア州マウンテンビュー在住のソフトウェアエンジニアがいろいろ書きます。

「USJのコースターはジェットコースターはなぜ後ろ向きに走ったのか?」感想

USJのコースターはジェットコースターはなぜ後ろ向きに走ったのか?」を読んだ(どうでもいいことだけど、業績悪化した遊園地を立て直す話なので甘城ブリリアントパークを思い出して脳内でAKINOの歌声が流れ続けていた)。

新書でおなじみの「なぜ」タイトルでウッと身構えてしまうが、内容はだいぶよかった。実例を、しかも実際にうまくいったケースを見せてくれるので、机上の空論かもという不安なしに読み進んでいける。

本の内容

簡単にまとめる。

USJで実現したアイディアの、作成の中心にあるのがイノベーションフレームワークだ。ドヤ感ある命名だけど、著者がそう書いてるので受け入れよう。

イノベーションフレームワークとは

イノベーションフレームワークは四つの柱で成り立っている。

  1. フレームワーク
  2. リアプライ
  3. ストック
  4. コミットメント

1のフレームワークが核にあると考えていい。フレームワークのなかにフレームワークがあるのは気持ち悪いけど受け入れよう。

アイディアを練る際に重要なのは、以下の二つをしっかり考えて決めることだ。

  • どんな条件を満たしているべきかを決める
  • どこに着眼点をおくかを決める

これはTDD(テスト駆動開発)のようなものだ。マーケターは、まずspecを考えねばならない。最終的な目的を達成するために、成り立たねばならない条件(spec)を定める。

着眼点を決めるのは、必要条件を決めてからだ。条件をきちんと定め、的を射たものと確信できていないと、アイディアを練るときに見当違いの領域に立ち入ってしまい、無駄に時間を費やしかねない。

条件と着眼点を決める際の手法には複数あるが、戦略的フレームワークが最も汎用的に使える。

戦略的フレームワークとは

まず、何を目的にして、どんな条件を満たせばよいかをはっきりさせる。で、その条件を満たすためにどんな戦略をとるかを決める。そして、その戦略で進めたとき、必要な条件を満たすための戦術を考える。

目的のspec => 戦略のspec => 具体的なアイディアと、トップダウンにspecを考える。

このように、段階的にブレイクダウンしていくことで、何をすべきかを決めていく。

あとはすごい頑張れば勝つ確率が高められる。

「すごい頑張る」の部分についても本書では書かれているがそのへんは省略する。

感想

フレームワークを使っても、あくまで確率が高められるだけで、確実に勝てるわけではない」と率直に告げている点に好印象を抱いた。


エンジニア的に問題に取り組むと、どう解決するかにいきなりフォーカスしてしまいがちだ。最初の目的設定と、specへの落とし込みが、特に怠りやすい点だと思う。細部にフォーカスして行動する際に迷いを持たないためにも、満たすべき必要条件をきちんと決められるようにしたい。

2014年振り返り

来年の生き方を考えるために、今年を振り返る。

月ごとのまとめ

1月

修士課程を修了できないという危機感がどんどん強くなっていた。

2月

修了できた。

3月

新生活の準備をしていたら終わった。引っ越し先を探したり、京都で行きそびれている場所を探して巡ったりしていた。

4月

入社と研修。ネットワークとかクライアントとサーバの関係とか、現在の実践的なWeb技術の基礎を学んだりしていた。

5月

研修続き。長崎に旅行した旅先で2万5000円の部屋に泊まったりした

エンボディチェアを買ったり、ドラム式洗濯乾燥機を買ったりして、QOLを高めた。

6月

まだ研修。

7月

研修の最終段階。WebアプリケーションをAmon2で作った。

それまではWebアプリケーション開発に対してRailsウェーイな姿勢で接していたが、研修を経た結果、言語やフレームワークではなくメンテナブルな設計を保つことが重要だと考えを入れ替えた。だがPerlはノイズが多すぎて嫌い。

新生活を始めてから買ったものをまとめたりした

8月

研修を終えた。crontabでのバッチ処理とか、MySQLのチューニングとか、枯れているけどしっかり作ると手間がかかる開発手法を身につけた。

YAPC::Asiaに参加して、エンジニアネットワークを体感した。

9月

職場でのキャッチアップ。Webアプリケーションを作るのが自分の責務になった。

情報科学若手の会に参加した。

サイエンスとエンジニアリングの境界面を確認し、自分の立ち位置と学ぶ方向を決めた。

10月

Railsについて、自分の経験を話した。Webアプリケーションを構成するコンポーネント群とどう付き合うか、考えをまとめた。

Railsでできることは、まだRailsに任せてよい。でも、分割できることは分割して、小さな領域にフォーカスしたほうがいい。余計な部分を消して、部品の目的に集中できるから。

あとFate/stay nightクリアした。

11月

ビジネスの観点からみたプロジェクト開発がわかってきた。プログラミングをしていると個々の小さな目的にフォーカスしてしまいがちだけど、それではビジネスにならない。プロジェクトの目的を忘れず、常に頭の中の20%くらいはプロジェクトの目的を考えておく、それくらいがいい。

あとDenkinovelの機能追加をした

月末に、さくらインターネット石狩データセンター見学に参加した

12月

忘年会の準備が大変だった。

魔法使いの夜、エンディングまでプレイした。後日譚だけまだやってない。

振り返ってみて

技術に関して

ミドルウェアからクライアントまで、Webアプリケーション開発はできるようになった。ひとまずなにかを作れる自信は持てた。いうなれば、防具が揃った状態だ(皮の鎧くらいだけど)。

ここから先は武器がほしい。

とりあえず、コンピュータサイエンスをある程度は身につけておきたい。年末に始めたアンダースタンディング・コンピュテーションを続けて、コンピュテーションをアンダースタンディングすることでその第一ステップとする。

それと、関数型プログラミングくらい「できる」と胸を張りたい。目前の課題として、業務で一番使える可能性の高いScalaをします……。

加えて、実務で直接使える知識として、OSやミドルウェアの動きなども説明できるようになりたい。だいぶ前に買ったなるほどUnixプロセスで順を追ってコードを実行することで基本を理解しておいて、ISUCONの過去問で実際のソフトウェアをどう動かすかの感覚を身につけるつもりでいる。

まとめると、来年は、専門分野を持つための発射台を作るフェーズにしたい。広い分野の知識を土台に固めておいて、いつでもキャッチアップできる体勢を整える。

文章に関して

アナテマ・フィジクスと、とある原作付きのノベルゲーム開発を再開したい。ゲームエンジンに何を採用するかは決めきれていないけれど、マルチデバイス対応を考えて、WebView上で動かすノベルスフィアのO2エンジンか、Adobe AIRVMとして使うAIRNovelのどちらかを採用するつもりでいる。

Denkinovel、12月にiOS版を出すつもりだったのに進んでない。Swift情報がいまいち出揃っていないことと、よりモチベーションが湧くもの(CSとかFateとか魔法使いの夜とか)を優先したのが原因。積んだゲームと本を崩し切るまで1か月くらいかかるけども、それからiOS向けアプリをきちんと作りたい。

来年の抱負

※(恥ずかしいので削除しました)

ホビット 決戦のゆくえでHFRをおすすめしない理由

ホビット 決戦のゆくえを見てきた。平和な村にオークが攻めてくるとかエルフは歳を取らないとかの話はしない。言いたいことはひとつ。

HFR(High Frame Rate)はおすすめしない

なぜHFRはダメなのか

  • 明るくて
  • なめらかだから

以上二点について説明していく。

明るい

HFRは明るい。本当に明るい。これまでの3D映画体験を覆すような明るさだった。あれほど鮮烈な光のなかで映画を見ると、どうなってしまうのか?

あの荘厳な中つ国がニュージーランドの観光地になる。城砦はセットになり、ドラゴンがCGになる。

かなりまずい。

従来の映画では、適度な暗さがリアリティを担保してくれている。ところがHFRの強すぎる光は、不自然さを白日に晒してしまうのだ。

現代劇だとそれでもよさそうだけど、ホビットみたいな架空の世界が舞台だとちょっときつかった。

なめらか

HFRは1秒間に48コマを再生できる。なるほど。なめらかだ。

HFRで、本物の世界により近づいた表現ができるピーター・ジャクソンは自信を持って語っている。

で、その結果、TVドラマみたいになった。

本編が始まった瞬間「あっ、映画じゃない」と感じた。どうしてそうなったのか理由はよくわからないのだけど、これまでの経験から、映画とは24コマで動くもの、と脳が記憶してしまっていたのだと思う。なめらかすぎる絵の動きを認識した脳が、目の前の映像を映画と呼ぶことを拒絶してしまった。

そして僕は、アニメにCG表現が使われ出した頃のことを思い出した。

ちょっと脱線。アニメのコマ数の話

映画は1秒間に24コマが映される(24fps)が、アニメは基本的に1秒間に8コマが再生される(8fps)。これは手塚治虫鉄腕アトムをTVシリーズとして制作するために始めたもので、自然に見えるぎりぎりのコマ数らしい。手描きのアニメだと、動画の作成に人手間がかかるため、コマ数は少ないほうが時間と制作費が節約できる。対して、3DCGはコマ数を増やしてもそんなに手間が変わらない。そのため、1秒間に24コマまるまる使ってもかまわない。

で、昔(といっても20年前とかそのへん)のアニメは、無邪気にも手描きの作画と3DCGを同じ画面で動かしていた。8fpsに24fpsでのCGが入り交じって、かなりの違和感が生まれていた(んだったと思う。そんな記憶がある。間違ってたらごめん)。異様になめらかに動くので、別世界のオブジェクトだと一目でわかってしまうのだ。

コマ数を揃えると、違和感はほぼなくなる。CLANNADの幻想世界とか、作画もCGも1コマにしていたけど、そのシーン内では自然に見えた。(他の3コマのシーンとつなげると際だって違うアニメーションになり、異世界だと一瞬でわかる効果はあった。が、これは別の話)。

今のCGは、作画にあわせて8fpsに揃えている作品が多い。宇宙戦艦とか大量の兵士とか、けっこう自然に動いている。(また話が逸れるが、自然に見える理由はほかにもある。最近のアニメのCGは、1コマずつCGアニメーターが調整して、動き自体をアニメっぽくデフォルメしている)。

閑話休題、HFRから感じる印象

「映画じゃない」と感じるのは、ちょっとつらい。映像技術的にはより高レベルなはずなのに、安っぽく思えてしまうのだ。もしかしたら、将来、すべての映画がHFRになって、24コマの映像が消滅して……という時代になったら印象も変わるのかもしれない。でも少なくとも今は、まだ、違和感が強すぎて、consが大きい。

まとめ

HFR、よくない。

#石狩DC 第3回石狩DC見学ツアー行ってきた報告

さくらインターネット石狩データセンター見学に行ってきた

北海道に一泊二日とかこわいなーどうなるんだろう、と思ってたけど知ってる人けっこういた。

IMG_4526

立地

データセンターは石狩の謎の地域にある。詳細は書けないのだけど、だいぶ人工都市というかSFめいた立地だった。使徒に攻撃されたときはきっと戦略自衛隊があそこに集結すると思う。

DC内部

印象的なのがサーバの冷却システムで、そのときその場で一番効率的なシステムを見極めるため、実験的に、冷却システムをエリアごとに変えているとのこと。

社長

一番驚いたのがさくらインターネット社長の言葉。「仮想化とかないよねー時代はベアメタルだよねー」とか言ってた。まじか。あれだけ仮想化の長所を謳っていたというのに、オーバーヘッドには勝てないと今さら言い出すのか……。

まとめ

今回の見学で、さくらインターネットのインフラが、大規模で、かつきちんとした施設で運用されていることがわかった。サーバ管理の物理的イメージを得ることができたのは価値ある体験だった。

あと、さくらのクラウドクーポン1万円分をもらったのでDockerを入れて実験して遊びたい。

抽選

そういえば、参加するには応募、抽選を経ないといけないのだけど、この抽選は完全にランダムらしい。連続当選のリピーターもいれば、僕みたいに初めての応募で当選した人もいる。

応募時に、質問したいことを書く欄を埋める必要があるのだけど、データセンターにまったく興味の無い冷やかしを選別するのに利用しているだけで、応募者の肩書ほか属性は気にしないのだとか。なので、見学してみたい人は来年以降もどんどん応募するといいです。

写真

石狩DCの設備のカッチョイイ写真はこのへんで見られます。

http://knowledge.sakura.ad.jp/event/2826/

http://ksakuma.hatenablog.jp/entry/2014/12/14/202906

食事

一日目の夕食、だいぶ豪勢だった。

IMG_4548

IMG_4547

こういうのが出た。

IMG_4532

会場がホテルの教会(みたいなホール)で、厳かな空間のなか、鮭とばをつまみにワインと日本酒を飲んだ。こういうところに予算使って大丈夫なのさくらインターネットどうしたの、と不安な気持ちになりながらも、LTでDenkinovelを紹介したりした。

沿岸バス

空港からデータセンター、ホテルへの移動はほぼすべて沿岸バスを使わせてもらった。

萌えキャラでラッピングした車体が有名なバス会社。

IMG_4528

羊に挟まれた子が白浜ひばり。

沿岸バスの萌えキャラ、なんと20人もいる

キャラクター一覧のページを見ると、キャラクターデザインの佐倉はなつみさんの絵柄の変遷がわかって感慨深い。

勉強会に立て続けに参加・発表してきた。 #hikarie_go

Goの勉強会とRubyの社内勉強会。一週間に二回、別言語の発表をするのはけっこうしんどかった。

ヒカルのgo #3

イベントページ: http://connpass.com/event/9175/

社内Ruby会議 #1

「Sprockets絶ちに挑戦した」のほうは、Qiitaにあとで詳細な資料を上げようと思う。

なぜ勉強会に参加するか

勉強会への参加の目的をまとめると、以下のようになる。

  • 発表という締め切りを設けて、1トピックについて学ぶきっかけにする
  • 人に会う
  • 自分の能力と得意領域をアピールする

プログラミングの勉強会、大抵の場合は発表しないと学習効率が悪く、家でぽちぽち本を読んでコード書くほうがマシだと思っている。

人間は(アッ巨大主語だ)(少なくとも自分は)楽をしたい生き物なので、放っておくと積極的に学習することはない。そこで、勉強会での発表を申し込んでしまえば、締め切りがあるし逃げ出せないので勉強せざるを得なくなる。

という理由で、参加できる勉強会を見つけたときは、できるだけ発表を申し込むようにしている。

#Rubyhiroba で発表してきた

これ。もう一ヶ月前のことになる。 http://rubyhiroba.org/2014/presentation.html

「Rails3で作り始めたアプリケーションをちょっとずつ改善してゆく道のり」を発表してきた。

この発表、Denkinovelの紹介部分は情報科学若手の会で話した部分をそのまま流用している。当初、若手の会でもRailsでの実装部分を説明しようと思っていたのだが、発表時間も短かったうえ、若手の会にはRailsやってない人が多そうなので断念した。上記のRubyhirobaの発表はその削った部分も大幅に投入したものだ。

Denkinovelの実装についてちゃんと公開したのはRubyhirobaが初めてで、ノベル作成からJSON変換までをどう表現すればわかりやすいかなど悩んだ。

BackboneとかAngularとか、JSのフレームワークはSPAの文脈で説明されることが多いけど、アプリケーション全体のSPAではなく単に遷移なしでのリッチな表現のために使う機会のほうが多いと思う。

Denkinovelの知見が他のWebアプリ開発に役だってくれればありがたい。

興味を抱いたこと

id:joker1007 さんの、RailsからSprocketsを投げ捨てる話が興味深かった。

これ。

僕自身、Railsアプリを開発してるとフロントエンドをすべてSprocketsで管理するのが煩わしく感じてきている。

joker1007さんの意見、RailsのSprocketsを捨てるべき、という意見、かなりうなずける。

なぜこの意見に僕が賛成しているのか、まとめてみた。

なぜSprocketsを捨てるべきなのか

npm, Bower, WebPack, grunt, gulpなど、最近のWeb開発ツールはだいたいNodeで動く。Web開発の環境を整えたり、フロントエンドの管理をするのはNodeにやらせるのがこの数年の主流だ。

フロントエンドはJSの領域で、RubyPythonも手出しできない。だから、JSファイルを結合させたり、依存関係を整理したりするのはサーバサイドJSであるNodeにやらせるのがよいと思っている。

RackのライブラリでしかないSprocketsと、Webアプリケーションには必須の言語であるJavaScriptで作られたgulp, gruntでは、利用される頻度が違う。JavaScript製のツールは、Webデザイナーも、非Rubyプログラマも使うのだ。

そして、こっちがより大きな理由なのだが、sprockets、わけわからんことを勝手にやってくれて、それを理解していないせいで不具合を解決できなかったりする。

わけわからんお節介のせいでSprocketsの挙動を調べるのがイヤだから、Sprocketsを捨てたい。なんで挙動を調べたくないかというと、Sprockets、静的ファイルの名前にハッシュ値を与えたり、JSの依存関係をもとに合体させたり、役割が複数あって無駄に大きい。

その点、複数の小さな部品を組み合わせて作っているgruntとかのほうが理解しやすい。UNIX哲学は偉大だ。

ということで、そろそろフロントエンドはRailsの手から放してやるべきなのだと思う。

turbolinksとか誰も使ってへんやろ?

若手の会に行ってきた。 #wakate2014

これ。 http://wakate.org/ 行ってきた。 
情報科学若手の会、情報学に足を踏み入れたい人はぜひ参加するとよいと思う。学生だと安いしおすすめ。

内容まとめ

Togetterにまとまってる。
 http://togetter.com/li/719110 
## 場所 
去年と同じ、山喜旅館。

DSC03780 

DSC03761

自分の発表

LTをした。

内容はこのスライドの短縮版。

なぜ参加するのか

理由1

自分ではない人が何を考えているのかを知るために、今回僕は若手の会に参加した。

情報科学は名の通りサイエンスなので、すでに実現されていることの先に踏み込むものだ。若手の会の人の話を聞くと、現在より一歩進んだ時代がどうなっているのか、目にすることができる。

自分だって、時代を進めるために試行錯誤しているわけだが、自分が今やっていることが価値あるものだと信じ切ることはできない。

だから、情報科学の道にいる人の話を聞いて、自分が何をすべきか考える材料にしたいと思った。

理由2

それと、顔見知りが増えればいいな、と思った。

この業界、ネットワークが複雑なわりに人が少なくて、知り合いの知り合いで繋げば三度ほどで人間関係を網羅できてしまう。

ちょっと知っている人が増えれば、狭い世界のことであれ、業界の動向に詳しくなれる。

ちなみに、若手の会で知り合った人とその後Rubyhirobaで出会ったのだけど、偶然にも学部時代の大学の先輩も同じグループで、3年ぶりの再会になったりした。人間関係ネットワーク、案外重複が多い。

まとめ

たぶん来年もあるのでみんな参加したり幹事になったりスポンサーになったりしよう。

あとやっぱりimosさんすごいと思った。