肉とビールとパンケーキ by @sotarok

少し大人になった「肉とご飯と甘いもの」

たくさんLTやる前提のPHP周辺の勉強会やります #phpblt

f:id:sotarok:20151104141130p:plain

同僚が potatotips という Android/iOS の Tips を共有する勉強会、というのやってて楽しそうだったのがあり、そういやPHP懇親会、という最初から飲んで全員が発表するスタイルの勉強会大昔にやったな、というのを思い出してもう一度なにかやってみよう、と思いました。

phpblt.connpass.com

ちょっとテッキーなかんじの雰囲気にできると面白いかなーと思います。 ネタには制限はとくにないけど、宣伝っぽいやつじゃないほうがいいな。

もはや PHP にネタは限定しないので、Web周辺、インターネット全般でも良いかと思います。

BLT

  • ポテトチップスに対抗するならなにがいい、と同僚のQAの子に聞いたら「ベーコン!」といってたので、BLT を思いついて、ちょうど LT って入ってるから良さそうだと思って決めちゃいました
  • トップのカチョイイ絵は同僚のスーパーデザイナーが作ってくれましたThank You!

発表者募集って呼びかけようと思ったらもうすでに超溢れてた

  • 参加者溢れてました
  • ありがたいことに、発表したい人のほうが多かった!
  • 多分限界20人くらいはあげられるかとおもう ... ! → あげました
  • 抽選で漏れてしまったら方がいたらすみません!
  • もしもりあがったら #2 もそのうちやろうと思いますのでその時にまたおねがいします><

てことで

楽しみに〜〜 してます〜〜

CTOとはいったいなんだったのか

こんにちは。元クロコスCTOの sotarok です。
元というのは、「クロコス」という会社が吸収合併にされてなくなったからですね。

「CTOとはどういう人だ」という話は、ここ1−2年ホットで、定期的に話題になります。自分の元上司であるグリーふじもとさんやnaoyaさんをはじめ、立派な諸先輩方が語ってくれているところではあります。
よりまとまった話をわかりやすく聞くには彼らの話を聞いてみるというのが良いかもしれませんね。GREEのエンジニアブログとか、wadapのブログとか、WEB+DBとか。


で、まあとはいえ、CTOというのをやってみた身として、自分なりに思っていることを、自分の言葉でまとめておくことをやってみようかな、と思っていたのでせっかくなのでブログに書いてみようと思います。

ただし、はじめに言っておきますがCTOとはこうでなければいけないとか言うつもりはありません。自分が意識していることとか、こういう風に振る舞いたいなと思っているようなことです。正解・不正解のある世界でもないし、考えは変わり続けるからまた3年後あたりには違う事を言っているかもしれませんね。

きめることとか

大事な仕事を大きく3つにまとめてみると、CTOの仕事というのはざっくり言うと

  • 決めること
  • 推進すること
  • 変えること

だと思っています。また、それを何段階か目線をあげて、

  • ビジネス目線 (会社にとって必要なこと)
  • エンジニア目線 (エンジニアにとって必要なこと)

の両方のバランスを取ることが重要です。

いいね、それでいこうと言う

「決めること」、というのはイメージが湧きやすいかと思います。 CTO目線で「技術選定をする」(インフラを決める、ミドルウェアを決める、開発言語を決める、フレームワークを決める...など) というのはよく聞きますし、それを決めてくれるのがCTOだ、と思っている人も多そうです。時代の流れ、会社の状況、市場環境など、複数の要因に左右される不確定な世の中で、的確な選択をし続けていくことの難しさは誰もが感じていると思います。これは重要な仕事で、とても難しいです。


また、メンバーから意見やアイデアが上がってくることも多いのですが、そこが1つのポイントだと思っていて。
実は、「こうしたら良いと思うのだけど」と言えても、「これでいこう」と言える人がそう多くありません。

  • いいね、それでいこう

と言えるかどうかなのかな、と思っています。

どうやって推進するか

実は「決める」というのがどういうことか、というところに、「推進」「変える」というところが含まれている、と認識すると良いのかなと。
「決める」ことは、それ自体ができても、それだけで終わらないのですよね。


なので「推進すること」は、決めたことをきちんと実行できるようにアレコレ手を打っていくことだと思います。
決めてメンバーに落としたら勝手にやってくれることもあるかもしれないし、それでうまくいかないこともあるかもしれません。

  • 決めたことをきちんと推進していくこと、リードすること
  • あるいは推進していくチームや仕組みを作ること
  • あるいはたまにはルールを作ること
  • あるいは他の経営陣を説得すること

など、必要に応じて様々やることがあります。推進する体制を構築していくことが必要です。

それはいつやめるのか

「変えること」とはどういうことかというと、一度決めたことを 変える、ということです。これも重要な仕事だと思っています。
例えばルールや技術選定など、様々な領域において「それは今も必要なのか」「それを決めた時の状況と今がマッチしているだろうか」という本質を考え、

  • 廃止
  • 変更

など、何かを決められる立場だからこそ、変えることもしなければいけません。多くのメンバーは、その時にイケてない現状を変えてくれるのを待っているはずですよね。


コツとしては、決めたときに「それを見直すルール」を考えておくというのが良いと思っています。例えば3ヶ月で一旦みんなに話を聞いてみる、Xヶ月に1度技術振り返りの会を開く、など。誰もが言い出せる雰囲気をいかに作るか、重要ですよね。



甘ったれない

もう一つ、自分が新人時代に、その会社を辞めるときにCTOに言われたことがあり、その言葉は今でも胸に突き刺さっていて、常に振り返る機会を与えてくれています。


「おまえは甘ったれだからな」


甘ったれ、といわれて当時の自分には理解できませんでした。「甘ったれてねーし」と。w
エンジニアリングでは正しいことを言ってるつもりだったし、それなりに新しい風をもたらしただろうし、、
まあでも、要はそういうことではなかったんですよね。


今考えるとやっぱり当時は甘ったれだったし、今はそうならないように意識していることがあります。

最後の砦と覚悟

昔、大きなバージョンの移行の仕事があった時に、自分と先輩がそれを担当してやっていました。対象となっていた事業はかなり大きな売上もあったので、障害を起こしたときの影響が大きく、その事業に関わるメンバーと連携して移行を進めなければいけなかったのですが、そのときの何かの会話で、自分と先輩に対して、上長に、

「これ失敗したとき責任どうやってとるの。」 *1

というような内容を言われたことがあるんですよね。
この時、自分は、答えに詰まってしまったんですよね。あれ、これ確かに責任とれるのか?と。 そのとき先輩が、

「責任は僕が取ります。クビにしてもらってもいいです」

と言ったんですよね。
これは極端な話だし、実際、会社は最終的にその人を守ってくれる (ことも多い) し、個人でX千万円の穴埋めをするのは不可能な話です。クビにしても多分意味がないですし。

でも要はその覚悟でやるのか、というところです。
最後の責任は誰かにとってもらいたい、という気持ちではダメだってことですよね。



CTO になって斬新だったのは、自分より上に責任をとってくれる人がいない状況を経験したことかもしれません。あの感覚は新鮮だったし、緊張感もありました。 いやもちろん、CTOになったからといって誰も助けてくれないなんてことはないですよ。チームメンバーは優秀だったし、みんなが助けてくれてなんとかできることもたくさんあります。
だけど気持ちの上ではやっぱり「最後の砦」でなければ、という意識は嫌でも身についたな、と思っています。

愚痴ってれば誰かに届くという幻想

もう1つ、
これはもうあまり多く語る必要もないんですが、愚痴を言っていれば偉い人のどこかに届いてそれがなんとなく解決されるんじゃないか、という幻想があったりします。
メンバーだったらまだ良いのだけど、やっぱり上に立つ立場の人は総じてそうもいかない、ということですね。

愚痴愚痴しているCTOの元で働きたくないですもんね。

そういう意味で、最後の砦というのは、別に単に技術的なモノのみの話ではないし、やっぱりメンタル的にもチームに良い力をもたらしたいよね、というのがあると思います。


と。そのあたりを総じて、甘ったれないでやる、ということになるかなーと今の自分では思っています。
もちろんまだまだ足りないことがあって「甘ったれ」と思われていることがあるかもしれませんが、まあ、それはそれで。。
またがんばりますw


強いチームを作る

あるときに気づいたのが、「自分がバリバリの活躍をして個人としてパフォーマンスを発揮する」ことよりも「最強のチームを作ってチーム全体のパフォーマンスを最強にする」ほうが会社にとって、成功する近道なのではないか、というところです。

自分が設計をする、コードを書く、運用をするということに対してその 1 OR 0 に関しては、正直どちらでもよくて、


強いチームを作るにあたってそれが必要ならそれをやるし、それ以外のところがより必要ならそれをやる


でしか無いと思っています。
もちろん、自分がプレイヤーとなって、それを含めてチームである、も真です。そういうやり方をする人もいます。

結局、ここ最近の自分は、しばらくエンジニアリングよりもマネジメントをやっていたわけですが、コード書くとやっぱり楽しいなーと思う一方、そこをやって他の事がおろそかになってしまうよりも、このチームでいかに成功できるのか、そこに導けるほうが楽しいとも思ったからです。
幸い、自分のチームには、同じように「チームとして強くなるためには」を考えて色々トライしてくれる人が揃っていました。おかげ本当に助けられたことも多くて感謝しかないですが。


だけど、やっぱり会社ってのはチームでやるものだし、それで「1人でやるよりも大きな成果をあげる」べきだし、それを成し遂げるためにはチームをうまく回すための人の存在は重要な要素の1つだろうな、と思うわけです。
もちろん CTO ではない人がそこをやっている会社も多く存在するわけですが、特に CTO には、開発組織に対してそういう関わり方が求められる場面が多いだろうな、と思っています。


最後に

いやーこうまとめてみると、ホント自分にできていないことが沢山あってほんとうに難しいなと思います。
一言で言うと、多分ふじもとさんの言う「技術的視点で経営にコミットする」ということなんですよね。
自分もまだまだですが、これからも自分も成長し、会社を成長させていきたいと思っています。


最後に、この場でのご報告になってしまい恐縮ですが、本日最終出社としてヤフー株式会社を退職いたします。ありがとうございました。
これからも「肉とビールとパンケーキ」をよろしくお願いします!

f:id:sotarok:20150403144423j:plain

*1:詳細忘れましたがそんなニュアンス、ごめんなさい。あと、この時の上長を批判する意図は一切ありません、念のため

喧嘩をしない技術、あるいはずっと仲良くやっていくために大切な10のこと

妻と約10年喧嘩ゼロを継続中の sotarok です。

この記事は Advent Calendar「家庭を支える技術」に参加しています。 12/22 の予定でしたが遅くなってしまいました、すみませんすみません。。。

21日は mshkさんによる 家庭を支える技術21日目: 平日の夕食作りの時間を休日にシフトする、ウィークックナビのご紹介 でした。すでに24日も終わりに近づいておりますが ... 22日分を更新します。


さて、どんなネタを書こうかといろいろ考えていたのですが、情報共有の方法とかをまとめても、まあよくある話なので、せっかくなのでふたりが誇れるものを何か、と思って思いついたのが事故ゼロ運動...じゃなくて約10年喧嘩ゼロの実績なのかなと思い、これをネタにしていようかとおもいます。転じて「いつまでも仲良くいるために」という感じで。*1

結果、だいぶ、テイスト変わってきましたが、本気でいこうと思いますのでよろしくお願いしますw


友人と結婚生活などの話をするときによく言われるのが、

「いつも仲良いよね」

で、だいたい次に、

「喧嘩しないの?」

という展開になります。
実際、喧嘩はしないし仲良いのですが、まあこの手の話、書き起こすようなものにしても恥ずかしいというか、もはやノロケてんじゃねーよくらいの内容にしかならないし、まあ、そういうことをしてると喧嘩しないよ、というのをまとめておくのもひとつか、と思ったのでせっかくのクリスマスムードなのでしっかりノロケておこうと思います。

背景

まず背景的なものを理解していただけるように Spec of My Family ですが、以下の様な感じになっています。

  • ふたりの出会いは大学
  • ふたりとも同い年、現在20代後半
  • 付き合いはじめて10年4ヶ月
  • 結婚して4年4ヶ月
  • 共働き、子供ナシ

うちのは結婚して4年ちょっと、付き合い始めて10年ちょっとです。最初の1年は喧嘩のようなものをよくしたのですが、それ以降1度も喧嘩していないので、とりあえずちょっと盛って「約10年」ということにしておきましたw

家族のことを、「ふたり」と表現していますが、もっと家族がいる人は、読み替えてくださいね。

1. 相手を尊敬すること

自分のできないことが出来たり、自分が気づいていないことに気づけたり、自分の見えていなかったことを見つけてくれる、相手を尊敬しましょう。

僕も、自分と全然違うことに打ち込む妻を尊敬しています。(世の中全体で見たら近い業界にいるかもしれないけれど)

料理、洗濯、掃除が自分より上手なことかもしれないし、あるいは、根気強さ、頭の回転、頭のおかしさ、相手の良いトコロに惜しみない賞賛を。

2. 相手を尊重すること

自分と違う考え方、違うやり方、または同じかもしれないけれどタイミングが違うこと、相手の主張を尊重しましょう。

お互いの意見を尊重し、時には主張し、時には折れ、あるいは話しあいましょう。 お互いが尊重しあえれば、それは信頼となります。

相手にやりたいことがあるなら、応援しましょう。そして、きっと自分にそういうことがあったとき、応援してもらえるようになるでしょう。

3. トレードしないこと

例えば。「コレやってあげたからアレはやってもらいたい」 という考え方は、 「コレやってあげたのにアレをやってくれない」という思考に直結します。そういうトレードをしないことが重要です。 実は相手は、自分の気づいていないところに気づいてくれていたりしています。そうしたすれ違いで、お互いがも同じように「やってくれない」と考えてしまうかもしれません。*2

作業の分担は大事ですが、協力して成し遂げることが重要で、作業量が半分半分になっていることが重要なのではありません。 例えば「年末年始の大掃除」だとすると、ふたりの目標は「家が綺麗になること」です。達成したいコトを共有し、同じ方向を向いて物事に挑めば、自然とトレードしなくなります。

個人的には...「8割自分がやる」くらいに考えると、意外と良いバランスがとれるのではないか、と思っています。8割、というのは完全に感覚値でしかありませんので細かいことは気にしなくて良いのですが。 お互いがそう思っていると、いつもたくさんやってくれてありがとう、その分僕もやるぜ、という気持ちになります。

4. よく会話すること

共働きにせよそうでないにせよ、会社に行って働いているとどうしても生活がすれ違ったりしますよね。うちの場合は、共働きで、ちょっと時間がずれていたりもして、やっぱり平日顔を合わせる時間が少ないこともあります。

でも、休日目が冷めて布団から出る前、ソファでのんびりしているとき、一緒にご飯を食べるとき ... 意識的にテレビを消し、携帯をしまい、たくさんおしゃべりをしましょう。 (いやあ、ふたりして携帯いじっているときもありますけどねw 今もむしろイヴでふたりでいるのに1人PCいじってるw)

それから、最近は情報共有ツールがたくさんあり、LINEやFacebookメッセンジャーなどで「会話」はしてるかもしれませんが、やっぱり最終的には、オフラインでの会話の量は重要です。

5. 将来を語り合うこと

実は、「変化に強い」という言い方をしようかと思いましたが、あまりにも仕事っぽくなってしまうので。。w

結婚したら...、どんな家に住みたい...、どんなところにいきたい...、どういう家族にしたい...、お互いのイメージする将来を語り合いましょう。どんなクリスマスを過ごしたい、どんな年末年始を過ごしたい、そんな身近なことでも良いと思います。

でも実際は、必ずしも今思っているようにはなりません。でも2人で常にそういやって語り合うことができれば、イメージの軌道修正もでき、変化に強くなります。

そして、変化を楽しめるようになれると思います。

6. スキンシップをとること

手をつなぎましょう、ハグをしましょう。キスも大事です。

言葉で伝えられないものが伝わります。

7. お礼を言うこと

お礼を常に言いましょう。

ご飯を作ってくれたり、洗い物をしてくれたり、洗濯をしたり、干したり、取り込んだり、たたんだり、掃除をしたり、買い物をしてくれたり... 当たり前を当たり前と思わず、いつもそうしてくれる相手に感謝しましょう。
そしてその感謝は必ず言葉で伝えましょう。時には、手紙や花を贈るのも良いと思います。

いつもの1つ1つちょっとしたこと、相手のしてくれることに感謝し、その感謝の気持ちを伝えることが重要です。

8. 愛を伝えること

「好きだよ」「大好きだよ」と声に出しましょう。
そんなことを言わなくても、お互い想い合ってるかもしれません。でも、言葉には魂があります。必ず声に出して伝えましょう。

(とはいえ、「愛してる」っていうのはちょっと普段から言うのは気恥ずかしいものがあるんですがw)

髪を切った時、おめかしした時 ... かわいいね、素敵だねと、思ったときにはちゃんとそれを声に出しましょう。 言葉は必ず、ふたりの絆を強くします。

9. それなりに1人の時間も作ること

さあ、最後に。1人の時間をちゃんと確保することも重要です。

ふたりでいることを制約にしないようにしましょう。同僚と飲んでくる、友達と遊びに行く、あるいは本を読む。相手がそうしたいというときには、そういう時間をちゃんととってあげましょう。 あ、きちんと重要なものをふたりの共通の優先度のものさしで選択できるというのが重要です。遊びすぎるのもよくありませんね。重要なポイントでは、一緒に過ごすのが良いでしょう。まあ、結局バランスが重要なのですが。

どのへんでバランスが取れるのかがわからない?
ここまでのこと ... 相手を尊重し、会話をし、実践できているふたりなら、きっとできるはずです。

10. 1-9 のことをふたりが実践すること

どちらか片方が実践しても意味がありません。ふたりで実践してこそ意味があります。 でもまだできていないなら、あなたから始めましょう。

ふたりはチームですから、ふたり (と、もしかしたら家族や、将来増えるかもしれない家族と。) で家庭を作るのですから。

まとめ

そういうわけで、いかがでしたでしょうか。 なんだかまぁ、図らずしもライフハック系記事みたいな感じになってしまっていますがw、みんな六本木の混雑カポーにイライラすることなく、幸せに、いつまでも仲の良く楽しい家庭をつくっていきましょう!

ハッピーメリークリスマス☆

*1:更にいうと、いつまでもラブラブでいるために!

*2:喧嘩の原因でよく聞くのは、家事などの「分担」です。

Speaker Deck で変な URL 付けられるのを抑制する

発表スライドをアップロードするのに使っている Speaker Deck というサービスがあるんですが、こいつなかなかのクセモノで、発表資料のタイトルをURLに組み込もう としやがります。

つけたタイトルが

The 3 Good Habits for Shell Beginners

の場合、URLは

speakerdeck.com/sotarok/the-3-good-habits-for-shell-beginners

になります。

英語タイトルの場合、単語がハイフンつなぎになるから良いのですが、日本語タイトルをつけると、まさかの中国語風に変換されてURLが付けられてしまいます。

先ほど、

学生・新卒エンジニアのパーフェクト成長戦略

というタイトルで公開したら、

speakerdeck.com/sotarok/xue-sheng-xin-zu-enziniafalsepahuekutocheng-chang-zhan-lue

などという URL になりやがりました。そんなバカなってかんじでしょ?

で、いろいろいじっていたら解決方法を見つけました。

解決法

  • / を含める
  • / 以降を英語にする

以上です。

例えば、

学生・新卒エンジニアのパーフェクト成長戦略

のタイトルを

学生・新卒エンジニアのパーフェクト成長戦略 / PHP Conference Japan 2014

に変更したら、URL は、

https://speakerdeck.com/sotarok/php-conference-japan-2014

となりました。

Enjoy!

Perfume による究極のユーザー参加型エンターテイメント #prfm

とにかく、1日目のライブを終えた時点から、この想いを吐き出したくて仕方がなかった!どうにかしてこの感動を伝えられないか、記録に残せないかを考えていた。 今日、4度目のエンディングを見てようやく、ツアーも無事盛況に終わり、吐き出せる時が来た。*1

ブログに書くにしても… ここ最近何も更新してないのにいきなりPerfumeの話もな、と思ったがまぁ昼間に思いたってはてダからはてブロに移行したのも良いきっかけということで、なんか書いてみようと思う。
しかし、音楽や映像の専門家でもなくライブから帰ったら興奮冷めやらぬ頭で乱暴に書きなぐった乱文のため、多少おかしなことを言っているかもしれないがご容赦いただきたいw いや、とにかくこの感動を書き留めて置きたかった。


今年10月、前作から約2年の時を経て、満を持してリリースされたアルバム LEVEL3 のツアー「Perfume 4th Tour in DOME 「LEVEL3」 supported by チョコラ BB」が本日無事に最終日を迎え盛大にその幕を閉じた。

このツアーでは、Perfumeの3人、そして素晴らしいスタッフの皆様の、新しい演出、挑戦、メッセージ、たくさんの想いが放出されていたと思う。このツアーは、あ〜ちゃんが公演中何度も繰り返し言っていたように、2013年の活動を締めくくる、素晴らしい「作品」として仕上がった。ライブのためのアルバム、そしてそのツアー。


そこで、本文中では、あえて、このツアーのことを作品として呼ぼうと思う。

文才のない一般人のただのブログだが、Perfumeの本作品の一部でも、これを読んでくれた人に伝えられたら幸いです。

演出の一部になったPerfumeとファン

今年のカンヌで話題になったため、知っている方も多いとは思うが、Rhizomatiks の Daito さんが中心となって Perfume の映像演出に様々な革新的でイノベーティブな新しい手法を取り入れている。(これはカンヌ以降、NHKでも特集されたし、展示会も開催されて、色々話題になっている)

人体プロジェクションマッピングである。

普通、プロジェクションマッピングは通常、静止したもの (建物など) を対象に行うが、動く人間をリアルタイムに認識し、人間のいる部分にだけ映像を投影するという手法をとり、一躍話題となった。

カンヌで披露されたこの演出は、形を変え、パワーアップし、ライブの演出にも取り入れられた。おなじみの Spending all my time (album mix) では、白い衣装を纏ってステージで踊り動く3人の姿をしっかりととらえ、プロジェクターから様々な映像が照らされた。当然にようにライブ演出に持ってきて、もう彼女たちはそれが新しいものというより、自分たちの表現の一部としてかみ砕き、モノにしたという感じである。

そして、これはもう何度もやられているので言うまでもないかもしれないけど、Perfume global site project #3 で実施していた、ユーザーが3人の色塗りができる、それが投影されたものも演出に取り入れられていた。
Perfume と映像」ではなく、一体化し、Perfume の存在そのものを作品たらしめてしまった。

そして観客も

さらに驚くべき仕掛けが用意されていた。

interludeにあたるいわゆる着替えの間、これまでもその役割をになってきたButterflyやSpeed of Soundのテイストを受け継いだ、LEVEL3 のアルバム曲 Sleeping Beauty で始まった間は、いつもであればカッコイイ映像を見るだけの時間ですぎるのだが、今回映像が始まってすぐに異変に気づいた人も多いのではないだろうか。

映像では、地球のワイヤーがぐるぐると周り、大阪公演では大阪に、東京公演では東京に光が集まり、日付とともに表示されたのだ。それで今回の映像はただの映像ではないと悟らされた。

次の瞬間、映しだされたのは、多くの人。静止したヒトガタの映像がたくさん集まって Perfume の3人の形を作る。そして次に映しだされたのは、満員の観客 (静止した人の映像) に囲まれた、「ライブのステージのミニチュア」を描いた映像である。

映像の中の大きな Perfume の3人は、そのミニチュアステージの前に群がる観客に手を伸ばし、1人ずつ摘み、カメラは摘まれた “人” をアップにする。しかし、それだけではない、映像の中で摘まれたその観客は徐々にアップになり、その瞬間、リアル(映像の外) でもスポットライトが点灯し、観客の一部が大写しになる。そこには、今、映像の中で摘まれていた "人” が映しだされたのだ!なんと、映像演出の中で使われた観客の 3D スキャンデータの本人がスポットで照らされ、ライブ映像(中継の意味での “ライブ”) でアップとなった!

実はこれ、動画の中で利用された人たちは、3D スキャンされたその当日の観客たちだったのだ!

早めに会場についた人たちは、ひときわ目立つ行列を目にしたかもしれない。「3Dスキャン体験」と書かれたブースに長蛇の列、ここに並ぶと、ブースの中では、Rhizomatiks の展示会でも行われていた、一瞬で人の形をスキャンし3Dデータモデルをつくり映像化するという、3D スキャンの体験ができる。「今後の作品で使われるかもしれません」などと札が立ててあったが、まさかあそこでスキャンされたデータが当日のライブ演出で使用されるとは思わなかったに違いない!

(3Dスキャンされた人はわかると思うが、「チケット持っている人は見せてください」と言われていたのはおそらく、通路際で、カメラが寄れる人を探すためだろうw)

最新のテクノロジーとエンターテイメントの融合...そう、このツアーで、観客の僕らまで、演出の一部に、Perfumeという作品の一部になったのだ。

夢から覚めた僕らは

今作品は、私たちは夢を見ている、からスタートする。その作品を締めくくるのはLEVEL3の最後を飾るバラード、Dream Landである。

アンコールでDream Landのイントロと共に、大きな翼を持つ天使の姿となって現れた3人。この曲を歌いあげた3人は大きな球に戻ってゆく。

Dream Landの中に現れる、その手を僕が引くから、という言葉にこめられた想いは、Perfumeがこれまでたくさんの人の助けを借りてここまで来たその想いをつなぎ、3人が次の世代の手をひくよ、というメッセージなのではないだろうか。

そして、3人は次へのメッセージも残している。Dream Land 終盤落ちてきた風船に記されたのっちの言葉は「君はだれの腕を引く?」。たくさんの人に支えられここまで来たPerfume、そしてPerfumeによってもたらされたたくさんの想い、この想いを繋ぐのは、次は僕らなのだ。

ひとつ上の、 LEVEL3 にレベルアップした彼女たちが、次回の "作品" ではどんな新しい挑戦を見せてくれるのか、楽しみでしかたがない。

その他の感想

  • 1日目はアリーナのセンター機材付近の席だったが、MIKIKO先生が来ていた!
  • オープニング、Enter the Sphere は予想通り!そして光の中に吸い込まれていくような映像、レーザー演出、すべてがカッコ良い!
  • ステージ後ろにあった球(リアプロも)と輪っかは、スウィートドーナツ的なあれかな、という … (勝手な想像)
  • ションションションメドレーは初めて知った…僕もまだまだだw(大阪1日目)
  • 最初のMCで20分使うとか … ずっと全開でしたね。特に、大阪1日目は、あ〜ちゃんがまるで酔っぱらいのようでした。久々の日本のライブでテンションあがってたのかなw ずっとケラケラ笑っててこっちも楽しくなってしまったなー。
  • 2日目のハイライトはダンゴムシw
  • 1mm 映像カッコイイ
  • ポイントから生歌。最高!
  • スタンド席からは、"夢の架け橋” が降りた後の穴を埋める作業を見るのが好きだった
  • あれ当日映像でピックアップする人が見つからなかった場合 (通路側) の fallback の計画とかどうするつもりだったのか聞いてみたい (確率的には、見つからないってこはないんだろうけど...)
  • と、多分結構当日それを探すのと動画完成させるのかはかりシビアな話じゃないのかな!?と。3日目のスタートが微妙に押したのはソレだったりして、とか勝手に思ったり ... (違うかーなー
  • 安定のParty Maker。アルバムで一番好きな曲。手をかざしてー!!
  • ふりかえるといるよって金縛りの曲だったの!?w
  • サンタコスのPerfumeかわいすぎ!
  • ドラえもん役は、毎日違う人がやってた。あれ観客の世代だと大山のぶ代さんの声を思い浮かべるから相当違うように聞こえるけど、のっちの声真似は、今のドラえもんの (ワサビ? だっけ?) の声には似てるきがするw
  • サンタをよぼうのスズを鳴らそうのくだりシュールすぎて笑った。ちなみにここであ〜ちゃんが歌うクリスマスソングは毎回違った!よね?
  • いやーしかし、サンタのくだり長くて笑った
  • 1日目はサンタトナカイだけだったのに、東京にきてからは雪だるまが追加されてて笑った。
  • チョコレイトディスコ中に放出されたひらひらがWOWOWの?空中撮影カメラのレールにひっかかっており、その上を空中カメラが通過するのを見守りつつひやひやした。
  • 風船全然こないよ!!ひとりで6つくらい持ってる人わけで欲しいw
  • ちなみに、アンコールがDream Land 1曲だけだったというのも驚いた。普通ならここ最近リリースられたSweat Refrainもやりそうなものだが、このツアーでは一貫してLEVEL3の世界観を貫きたい、ということだったのかも。

*1:なんと4日すべてのチケットが当選、大阪2東京2に参加してきました。不公平を恨む方もいるかもしれないが、こればっかりは運なのですいません!1年間ももクロのチケットはずれ続けた末のPerfume全当選なので、神からのメッセージとして受け取っておくことにしているw

PHPカンファレンス2013 で「PHPerのためのデータサイエンス入門」という話をしてきました #phpcon2013

先日 9/14 に行われた PHP カンファレンス2013 で「PHPerのためのデータサイエンス入門」という話をしてきました。

データサイエンスというと、おそらく、キモになるところは「モデリングと効果測定のところ」ではないかと僕は思っているのですが、実はデータサイエンスの守備範囲は非常に広く、扱う領域、知識の幅を必要とする分野です。特に、データサイエンスの領域はエンジニアリングの領域のみならず、ビジネスの領域も含むと思います。データを分析し、ビジネスに使える結果・モデルをどう得るか、それを出すためには、どういった結果が、ビジネスに効いてくるのか、それがわからなければいけません。エンジニアリングからビジネスまで、という領域に対して、業務上、コミットできる人は、世の中にそう多くは無いと思います (だからこそ、データサイエンティストというのは稀有な存在であり、今最も注目を集めているのでしょうね)

さて、そんな前置きはともかく、そうはいって、PHP で扱う領域は、主に、Web アプリケーションです。
Web アプリケーションを作る、というのは、サービスを作る、つまりそれはビジネスを作ることです。(まれに、楽しければそれで良い、という人もいるかとは思いますが、それはまた真かと思います。しかし、殆どの場合、それは長続きしないでしょう)

我々が日々開発をするアプリケーションにおいて、何を達成したいのか、それを使う人がどのように使ってくれるのか、どう使ってくれると、我々が達成すべきものに近づくのか、それを考えることは、いちエンジニアにとっても非常に重要なことです。
その足がかりとなるのが「自分の作ったアプリケーションを利用してくれるユーザの行動を分析する」ということになるかと思います。

データを分析する...
それを聞くと、一見、非常に難しく、専門的な知識を必要とするように思えるかもしれません (当然、突き詰めると、計算幾何学や統計的解析手法の知識が必要となる場面もあるでしょう)
しかし、データからユーザの行動を表したり、あるいはモデル化したりすることは難しくても、まず、自分たちのアプリケーションをどうのうにユーザが利用しているのか、知る手がかりを得ることは実は、簡単なことです。

その、まず第一歩を踏み出すための、入門の入門としてのお話をさせていただきました。

うん、なんかすでに文章なげえ。


ようするに「PHPer だろうが、手軽にデータ分析はじめてみようぜ」ってことなんですよ。

資料と補足

発表資料はこちら。


なぜ Treasure Data か

Treasure Data http://www.treasure-data.com/

正直、発表内容は、TD ありきです。
むしろおもいっきり宣伝しています。ちなみにお金は一切いただいておりませんw ステマのつもりはなくて、単に素晴らしいプロダクトをみんなに使ってもらいたいと思っているから紹介しています。

ちなみに、自社内でデータサイエンスチームを持ち、Hadoop エンジニアがいるような方 (会社) はターゲットから外れるかと思います。
本講演では「そんなリソースは無い」「Hadoop クラスタ管理したくない」「ログデータ収集とか作ってられない」それでも分析をしたい!というユーザに対しての1つの方法として、TD を提案しています。
(当然ですが、重要なログデータをどこまで他社サービスに載せられるかというところに関しては、一定の判断を要することになるかとは思います)

つまり、サービス開発を行い、ユーザのデータ分析を行う際に、データの集め方を考えたり、ストレージの増設に追われたり、Hadoop クラスタの管理に追われたりすることは、まったく本質的なビジネス活動とは程遠いところにあるため、リソースを持たない小さな会社でどれだけエンジニアの工数をそこに割くのか、という話なのです。

そんなコストを払わずに、誰かがやってくれるなら、任せてしまいたくありませんか?

我々は、本質的に、自分たちのアプリケーションに必要な開発に、より多くのコスト (エンジニアのリソース) をかけるべきだと思います。



だから、Treasure Data なのです。


(ちなみに、まぁ自社内で Hadoop クラスタを管理したり、データを貯めこんだりすることが本質的に必要な場合もあるでしょう。それはそういった場合があると思いますので、そういうエンジニアすべてを否定する意味ではありません)

あとがき

... なぜか後半無駄に熱く語ってしまいましたが、少しでも、思いが伝わればと思います。
PHP においてどういったフックポイントでどうログを投げるか、今回はあまりコードを用いて説明できませんでしたが、それもまた、機会があればブログにでも書きましょう。


さて、そういうわけで。
参加された皆様、Ust 参加の皆様、僕の発表を聞いてくれた皆様、ありがとうございました。
スタッフの皆様、お疲れ様でした!


PHPカンファレンスFacebookページもあるのでいいね!してね:

「王様達のヴァイキング」と漫画の監修

久しぶりのブログです。こんばんは。

タイトルの通りなんですが、「王様達のヴァイキング」という、週刊ビッグコミックスピリッツ(小学館)で連載中の漫画の監修のお手伝いをさせていただいてます。この度、無事、単行本第1巻が発売されました!
ハッカーとエンジェル投資家をテーマとした漫画です。(料理王対決漫画ではありません...念のためw)

なにそれ知らない、という方は試し読みもできますよ:

こんなNAVERまとめも…!


各所から面白い、と言っていただけていて、お手伝いさせてもらった者として、ものすごく嬉しいです!

自分も、こっそり(でもないかもしれないが)、キャラとして登場させていただいたりしてるのですが、貴重な経験をさせていただいております。漫画の監修というのは、初めての経験でしたので、自分がどんなことやってるのかを紹介してみたいとおもいます。

経緯

ちなみに… 監修のお手伝いをさせていただくことになった経緯は、クロコスがまだ青山で仕事をしていた時、同じく監修のおざーんこと小澤さん(id:ozarn)の元に取材にきた編集担当の山内さん(@)、作者のさだやすさんとお話したことでした。

エンジニアの世界を見てみたい!とのことで、クロコスを会場として開催したPHP勉強会を見学したい、と言われたことがきっかけですw

何をやっているのか

僕の役割としては、技術的内容に関わる設定・ストーリー・セリフのアドバイスと、スクリーンショットの提供などをさせていただいています。それから、ちょっとだけ、ベンチャー企業のアレコレみたいなところとかもお話させていただいたりとか。

技術的に、そんなセリフは言わないとか、その代わりにこうしたらどうか、とか、こんな作業してるときの画面イメージをください、とか、漫画の下書きを見てやり取りしてます。
あとは、Webサービス関連の、作り方、運用の仕方とか、リアリティをもった世界観作りのところは、適宜質問いただいたものに回答したり。(セキュリティ周りは僕の担当ではありません^^;)

ちなみに、設定周りでは、IBMロゴのThinkPadUbuntuをいれてるのが金がなく昔買ってもらったマシンを使ってる設定としては良いのでは、とか (実際に採用していただきました!)、256の名前とか。
自分のアイデアを採用してもらったところも多々あり、それが絵になり、ストーリーになっていくのを見ると、本当にすごいですね。

嬉しい気持ちと、ああ、漫画ってこうやってできるんだーと、感動的でした。

最後に

自分がお手伝いさせていただいてる箇所は、ほんの少しです。
ハッカー漫画を描くのは本当に難しいと思うのですよ。
まず、絶対、絵が地味だと思うんですよ。ターミナル上でアレコレ起こっても。。クラックしても、爆発もしなければ、ドクロマークがドーンということにはならないw
そして、リアリティを追求すればするほど、一般の人からはわけのわからない事になってしまう。

「王様達のヴァイキング」では、僕や、ほかの技術監修さんからの情報をもとに、作家さん担当さんがきちんと噛み砕き、そういう、リアリティをもちながら、かつ、わかりやすく、面白い、盛り上がるものに仕上げていると思います。これは、生半可な実力ではないと思います。
新人作家とは思えない絵のクオリティ、感情、個性、表情の表現。惹きつけられるストーリー。とんでもない漫画家が出てきたな、と。


さて、そんなところで、簡単ではありましたが、単行本の宣伝がてらw、軽く裏話をさせていただきました。 今後も、面白い展開になっていくこと間違いなし!ですのでお楽しみに〜。

公式アカウントもよろしく!



Amazon.co.jp - 王様達のヴァイキング 1 (ビッグコミックス) さだやす

Kindle化は?

よく聞かれるのが、Kindleで出してよ、ということなのですが、担当さんに確認したところ、書籍の出版からは3ヶ月程度のラグがあるらしいです。
とはいえ、出ることは出るらしいので、Kindle派のみなさまにおかれましては、少し遅れますが、楽しみにお待ちいただければと思います!

追記 (2013-07-06)

説明が足りず誤解を与えてしまったかと思われるところもあったので、念のため補足をさせていただきます!
「僕がお手伝いしているのはほんの少しの箇所」と言うのは、謙遜しているわけではなく真実で、例えば、是枝くんのクラッキング技術に関する部分等の技術監修は僕ではありません。主に担当しているのはヘッジホッグやWebサービスが関わる部分や、起業全般に関してです。他にもたくさんの技術監修の方々がクレジットに記載されておりますが、その素晴らしい皆様のおかげで作品が出来上がっています。(他の技術監修の皆様への配慮が欠けていてすみません ^^;)

それから、最初ログイン画面のイメージは作ったのですが、その後実際に採用した画面は他の方からのスクリーンショットの提供だったそうです!お恥ずかしながら、僕の勘違いだったので該当の一文は削除し、訂正させていただきます。