『Pull Toy.』 社内ゲームジャムに参加した
5/16,17の土日を利用して社内でゲームジャムが開催されたので見学に行った。
テーマは「ひも」。
スケジュールは、1日目昼に企画発表、夕方にα版発表。2日目昼にβ版発表、夕方に最終発表という感じだったのだけれど、企画発表見ていたら面白そうだったので午後から急遽参加した。
Pull Toy.
ストーリー
障害物を避けながら、ぼくの大好きなおもちゃを、おもちゃ箱に片付けよう！
画面イメージ
テーマの解釈
イライラ棒 + ひも
仕組み
椅子やゴミ箱、猫や靴下などの障害物が、"ぼく"とおもちゃ箱の間に配置されている。
"ぼく"は、おもちゃを障害物にあてないように慎重にゴールのおもちゃ箱までおもちゃを誘導する。
障害物におもちゃが5回あたってしまうと、おもちゃが壊れてGAME OVER。
どうしても障害物が邪魔で通れない場合は、3回まで”ママ”に片付けをお願いできる。
プレイイメージ
Game Jam
初参加だったけど面白かった。 作業時間は10時間弱ぐらいだったっぽい。
開発
本当はUnityでやりたかったけど、インストールとドキュメント読むだけで終わりそうだったので、SpriteKitで作った。
…とは言ってもSpriteKitも初めてだったので最初の1時間ぐらいはリファレンス眺めたりしてたけど。
とにかく時間内に完成させることが目標だったので、didMoveToViewにひたすら処理を書きまくる感じで設計とかはボロボロだけど、完成度は一番高かった！（贔屓目）と思う。
デザイン
たまたま、別チームでデザイナさんが参加していたので、素材を書いてもらった。
「タイトル画面は、左向きで、赤ちゃんがこの玩具を引っ張ってる感じで！」とか「家にあって、赤ちゃんの邪魔になりそうなやつを適当にいくつか！」みたいなゆるふわな要求でステキな画像を作ってくれた @momoyageek に感謝。
リリース
予定はないけど、他の参加者の何人かは頑張るみたいだ。頑張れ。
「エセ芸術家ニューヨークへ行く」というゲームをやっていて「一文字探偵（仮）」というゲームを考えた
今日たこ焼きパーティーで「エセ芸術家ニューヨークへ行く」というゲームをやった。
簡単に言うと、1人だけ親の出したお題を知らない状態で、順番に一筆ずつ絵を描いていって、エセ芸術家（お題を知らない人）を当てるゲーム。
- 親とエセ芸術家は、エセ芸術家がバレなければ勝ち
- 子はエセ芸術家を見つければ勝ち
- ただし、エセ芸術家だとバレても、お題を当てれば親とエセ芸術家の勝ち（※）
このゲームは※の部分がとても面白い。
お題を知っている人たちは、エセだと思われない程度にお題に沿った絵を描きつつ、エセにお題がバレないように分かりにくい絵を描かなければいけないというジレンマがある。
ただ、親には特にジレンマはなく、書きやすく分かりやすいお題を出せばよい。
みんなが分かりやすく書けばエセ芸術家にお題が伝わるし、みんなが分かりにくく書けばエセ芸術家が紛れるからだ。
そこで、親に（も）ジレンマがあるゲームを考えてみた。
もしかするとすでに似たゲームがあるかも知れない（が、少なくとも自分は知らない）。
概要
ゲーム名は適当だけど「一文字探偵（仮）」。
親は、誰かが分かるが全員は分からないようなお題を出す。
子は、自分と誰かは分かるが多くの人には分からない質問をする。
ルール
5人（1人が親で4人が子）で試したので、5人ルールで書く。
- 親は4文字の単語（名詞でも概念でも何でもいい）を考える
- 4枚の紙それぞれに4つの丸を書き、それぞれの紙に1文字ずつ書く
- たとえば、思いついた単語がたこやきなら「た○○○」「○こ○○」「○○や○」「○○○き」
- それらの紙を、1枚ずつ子に配る
- 配られた子は、他の子に見えないようにする
- 1文字目を引き当てた人から順に、親に対してYES/NOで答えられるような質問をする
- たとえば、「それは食べ物ですか？」「手のひらに乗るサイズですか？」等
- 親は質問に対し、YESかNOで答える
- このとき、補足の解答をしてもよい
- 「はい、スーパーやコンビニなどで売っています」
- 「はい、しかし実際に手のひらに乗せると、火傷をするかもしれません」
- 2文字目の人、3文字目の人と続き、全員が2回ずつ質問をしたら、全員が穴を埋めて、一斉に見せ合う
勝敗
親の場合
| 正答者数 | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|
| 得点 | 0 | 3 | 2 | 0 | 0 |
正答者が少なければ少ないほど点数が高い。
しかし、半数以上が正答した場合や、誰も正解しなかった場合は0点。
正答した子の場合
| 正答者数 | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|
| 得点 | - | 2 | 3 | 1 | 1 |
正答すれば最低1点はもらえる。
正答者が少ないと高得点だが、1人勝ちより2人勝ちのほうが点数が高いのは、露骨に分かったアピールをして、親と利害が一致することを防ぐため。
誤答した子の場合
| 正答者数 | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|
| 得点 | 1 | 0 | 0 | 0 | - |
全員分からなければ点数がもらえる。
まとめ
人数や点数などのバランス設計は調整の余地あるけど、何度かやってみた感じだと、だいぶ面白かったのでまたやりたい。
もしくは類似ゲームがあったら教えてください。
インディアンプランニングポーカーというのを考えた
今日、チームでプランニングポーカーしてたら、ふと思いついたので書いてみる。
プランニングポーカーとは
タスク（ユーザーストーリー）の見積もりを立てるときに行う手法です。
いくつかのポイントの書かれたカード*1の中から、工数を選んで、一斉に公開して、チームでの工数感の認識をすりあわせます。
大体の流れ
1. 見積もりたいタスクを選んで
3. それぞれカード（工数）を選んで、一斉にオープン
4. 全員が一致していたらその工数で終了
5. バラバラであれば、一番高い人と一番低い人がなぜその数字を選んだのかを説明する
6. その理由を元に再度カードを選びなおし、3-5を繰り返す
ちゃんとした説明が希望の人は「プランニングポーカー」とかでググってください。
インディアンポーカーとは
トランプゲームの1つです。
自分に見えないようにカードを持ち、他の人のカードや発言を参考にしながら、「降りる」「勝負」を選択して、カードの強さで勝敗を決めるゲームです。
交換（カードを引き直す）がある場合もあります。
大体の流れ
1. 山札からカードを取って、自分に見えないように頭の前に出して
2. なんやかんや騒いで
3. 勝負したり降りたりします
ちゃんとした説明が希望の人は「インディアンポーカー」とかでググってください。
インディアンプランニングポーカーとは
自分の見積もりが分からない状態で話し合って、自分の見積もりを当てたら勝ちなゲームです。ただし、見積もり自体はちゃんとやります。
大体の流れ
1. 自分の手札をシャッフルして
2. 自分に見えないように頭の前に出す
3. メンバーはそれぞれの見積もりを見つつ、妥当そうな見積もりを選ぶ（その人ならそう出しそう、みたいな）
4. 自分の見積もりが分かった人は一度だけ宣言することができ
5. 宣言があたっていると点数が入る
6. 最終的にせーので、妥当な見積もりの人をさして終了
難しいタスクに小さいポイントを出している人は難しさがわかってないから任せられないな、とか、あの人なら逆に、あっというようなアイデアを出してすぐ終わらせてくれるかもしれない、とかあの人はいつも多めに出すから妥当そう、みたいなことを考えつつ、話し合うので、普段自分の見積もりがどのように見られているか、逆にこのタスクでこの見積にするにはどうしたらよいか、みたいなことが考えられて良いと思います！（やってない）
*1:?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, ... みたいなセットが多い
最近作ったhubotの紹介
去年の年末あたりに急にhubotで遊びたくなって幾つか作ったので、社内のLT大会的なやつで紹介した。
スライドは本当に紹介だけなので、軽くテキストで補足する。
hubot-shinchoku
silvers/hubot-shinchoku · GitHub
shinchokuって話しかけると、進捗どうですかからランダムに画像を引っ張ってきて表示してくれる。
進捗ダメですって言っても許されるような空気になるのでギスギスしなくて良い。
hubot-karma
まだリファクタリングしていないので公開してないけど、ユーザ名++とかユーザ名--とか書くとカウントしてくれる。
承認欲求が満たされて良い。
hubot-chocho
オフィスの空調が暑かったり寒かったりしたので、みんなである程度同意をとって空調を調整できる君が欲しかった。
変にストレス貯めなくて良い。
ちなみにchochoは空調調太郎の愛称。
hubot-chat-sirubo
心が荒んだときにボットと会話して心を和ませる用。
それなりの返信パターンを用意している。
心が洗われて良い。
hubot-ramen-gotanda
五反田のラーメン情報を教えてくれる君。
重み付けなどは特に行ってないので、推し麺があればリストに複数突っ込む感じで。
ランチで悩まなくて良い。
hubot-saying
○○な名言を教えてくれる君。今のところロックな発言のみ対応。
意識高まって良い。
その他
かなり社内向けのツール群をいくつか作った。
まとめ
hubot楽ちんだし楽しいよ。
2014年のふりかえりと2015年の抱負
新年になったし、なかなかこういう機会じゃないとふりかえることもないのでふりかえっておく。
仕事
マネジメント
2014年は新しいグループを立ち上げたりしてマネジメントっぽいことに挑戦した年だった。
マネジメントでは、メンバーが集中して開発できる環境を整えつつ、面談などでメンバーと調整して、グループのあるべき姿、今後目指すところをうまく示せたと思う。
前半はマネジメントとエンジニアのバランスがなかなか見えていなくて、残業しがちだったのもだんだんと（仕事減らすのに）慣れてきて後半はうまくプライベートの時間をとれたと思う。
席にいない時間が多く、チャットで指示したりレビューする、みたいなのがメインになってしまったのは失敗だった。
来年はもうちょっと面と向かってあれやこれやする時間を増やしたい。
今後は自分がメインでゴリゴリ開発するのは誰も幸せにならないので、後輩を育てる、コードを書いて勉強するのは業務外で、というのが今後の課題になってきそう。
あと経営学とか組織論的なやつの勉強の必要を感じる。
新規プロジェクト
また、新規プロジェクトの立ち上げも同時期に行って、プロジェクト全体の開発リーダーをした。
開発リーダーぽいことは2013年もやっていたけど、立ち上げから担当したこともあって、歴史的経緯とか気にすることなく、いろいろな仕組みやルールを決めることができたのが良い経験になった。
自分のプロジェクトの基盤を整えただけでなく、成功を通じて他のチームに良い空気が伝搬していて色々なフィードバックがもらえたのが嬉しかった。
ただ、仕組みをかっちりしすぎたせいで、新しいメンバーが入ってきたときに文化に慣れるまで時間がかかってしまった。
もう少しプロジェクトメンバーに合わせて柔軟に対応できるようにしたい。
個人的な課題としては、立ち上げから関わるとリリースする時期には飽きてることと自分でやったほうが早い病をどうするか。
これに関してはどうすればいいかまだ答えは見つかってない。
仕事ではコード書いてないけど書いたらすごいんだぜ的な感じを醸し出すためにOSS貢献とかブログとかのアウトプットを頑張るのはどうか。
フロントエンド
インフラ→サーバーと来て2014年はフロントエンドをメインに開発した。
ブラウザともそこそこ友達に慣れてきたし、coffeescript, nodeなどにも挑戦できた。
開発だけでなく、専門職として会社全体のプロダクトのUI/IA設計に関わることができた。
nodeはまだちょっと触った程度なので、2015年はもっとゴリゴリ書けるようになりたい。
パフォーマンスやUI周りも、経験的に解決することが多かったので、分析周りの力を身につけたい。
その他
社長賞とクレド賞（社員投票的な）をいただいた。
来年は、データ分析やネイティブアプリの年になりそう。勉強せねば。
プライベート
ボードゲーム
大学のころに大分ボードゲームやって飽きたと思っていたけれど、会社のゲーム部のおかげでボードゲーム熱が再来した。
同じゲームばかりやってしまった感じがあるので、2015年はいろいろなゲームに挑戦して「大体のボドゲはやったことあるよ」ぐらいになりたい。
あとTRPGのリプレイ動画をニコニコで見てる。面白い（見るのが）。
日本酒
せっかくsakelifeで毎月お酒が届くんだし…と思って大体月一ぐらいで『四合瓶または寿司』という日本酒宅飲みをするようになった。
お金の徴収はナシ、それぞれの財布事情に合わせて四合瓶か寿司、またはそんな感じのものを適当に持ってきて飲もう！みたいな会でいろいろなお酒を飲んだ。
その他にも、会社の休憩スペースで就業後に寿司とか買ってきて飲んだりしてた。
記憶に残っているのだと、「画竜点睛」と「来福mellow」が美味しかった。他にも美味しかったの沢山あるけど、銘柄が…。
米違いとかグラス違いとか飲み比べ系が面白かった。
家
元々荷物は少ないほうだったけど更に減らした。
積ん読が多いので2015年はちゃんと減らしつつ本棚もスッキリさせたい（毎年言ってる）。
その他
2014年は全然美術館にいけなかったので2015年は月1ペースぐらいで行きたい。
まとめ
プライベートはお酒飲んだ記憶しかない。
結構仕事の年だったなって印象が強いけど、やりたいことは提案したら全部やらせてもらっているしとても良い年だった。
2015年は、個人の技術力の向上と、後輩の育成、インプットとアウトプットのバランスを頑張りたい。
天下一クライアントサイドJS MV*レームワーク武道会に参加<しました #ten1club
天下一クライアントサイドJS MV*フレームワーク武道会 - connpassに参加してきました。
イベント見たときはもう枠こえてて、参加するにはLTしかない！みたいな感じだったので、ドキドキのLT応募。実際はキャンセルが多くて、補欠登録でも大丈夫そうだったけれど、良い経験できてよかった。
話したこと
angular X designer - デザイナからみたAngularJS #ten1club
簡単に言うと、HTMLやjavascript周りを専門にやる人が潤沢にいないチームで、エンジニアとデザイナの両方がHTMLをさわると、
- エンジニアが組んだロジックがデザイナによって壊される
- デザイナが組んだデザインがエンジニアによって壊される
みたいな悲しい出来事が起きてしまう。
デザイナはIF、ELSEを呪文のようだと思っているし、表示条件を変えたい、みたいなときにロジックが書ける人のサポートが必要だ。
それは一般に、マークアップエンジニアであったりフロントエンドエンジニアであると思うんだけれど、SPAのような片手間じゃないjavascriptが必要なプロダクトでは、フロントエンドの業務範囲がでかくなってしまう。
そこで、表現に関わる部分をデザイナにやってもらいつつ、それができるような環境・仕組み作りをフロントエンドエンジニアが行う、ということをやるためにMV*フレームワークとしてAngukarJSを選択し、実際に試した感想を話した。
内容としては以下のような感じ。
- Angularは薄くないフレームワークなので、すぐに「利用できる」環境が整っている
- 学習コスト高いと言われているが、「利用する」だけならそんなに学習コストは高くない
- ngClass, ngAnimate, ngClick, ngSwipe*あたりは、エンジニアのサポートが必要なくデザイナが挙動を制御できるので楽しんでもらえる
- Controllerはデータを突っ込むことだけを考えて、少しでも複雑そうならModelに移してしまうのがよい
- directive, filterなどはガンガン作っていく
- フロントエンドエンジニアは死ぬ
ユーザからの反応を普段使っているチャットツールで見れるようにすると捗る
タイトルですべて話しきったけど、とても便利なのでおすすめ。
B2Cなサービスを作っていると、ユーザの反応が気になる。
ただ、いちいち色々なSNSにアクセスして検索するのもだるいし、メンバーによっては見なかったりするので、チーム内での情報共有がしにくい。
やっぱりサービス作っているならユーザがどう思っているか、どんなことを今後期待しているかみたいなのは、メンバー全員が意識したいし、それをサポートする仕組みがあると嬉しい。
さいわい、うちの会社では社員全員がIRC（チャットツール）でコミュニケーションをする文化が育っていて、離席時以外はログを読むことを期待されている。
そこで、各種SNSをクロールするBOTを作って*1、サービスの評判をほぼリアルタイムに通知するようにしたところとても捗った。
良かったこと
- ユーザからの要望や不具合報告を以前よりも早く対応できるようになった
- ユーザの感想から会話が広がり、メンバーの意識のすりあわせができるようになった
- 単純に見ていて楽しいし、褒められると嬉しい
あまり良くなかったこと
- 雑談が捗りすぎる
今後できたらいいなと思うこと
- ある程度フィルタリングしたい
- 文章解析してどんな反応か分類できたりするとイイネ
- 要望だったら自動でチケット切るとか
*1:自分が作ったやつは保守面倒になってしばらく前に止めたけど、最近同期がいい感じのものを作ってくれた
