しるろぐ

いろいろ書きます。

東京 Crystal 勉強会 #1 に参加してきました

crystal.connpass.com

2015年7月31日に五反田のモバイルファクトリーで行われた 東京 Crystal 勉強会 #1 に参加してきました。

Crystal は、最近話題のRubyシンタックスの静的型付け言語です。

どれぐらいRuby風かというと、こんなぐらいです。

発表内容

20分のトークが2本と、LT5本でした。 資料等はすべて、 東京 Crystal 勉強会 #1 in 五反田 - 資料一覧 - connpass にまとまっているので割愛しますが、Crystal の言語の説明から、実装の話、Crystalを使ってみた話、言語の歴史から見る Crystal という言語の位置付けの話など多岐に渡る話で、とてもおもしろかったです。

今後

今後も、日本のCrystal界隈を盛り上げていくために勉強会やもくもく会を開催するみたいなので、気になる方は是非 crystal-jp(slack) に参加してください!

以下のページからメールアドレスを送信すると自動でslackへ招待されます(ちなみにこの仕組みもCrystalで書かれています)。

Crystal-JP Slack Invite

ヒューマンエラーに精神論は危険信号

たまに参照することが増えたので日記にまとめておく。

ヒューマンエラーは仕組みで解決しましょう!!

多分この本

記憶が確かなら、この本です。

スプリントに名前を付けると覚えやすいしやる気がでる

単純に優先順に作業すると、いろいろやりすぎて思い出に残りにくいので、スプリントにタイトルを付けて、特定の何か(機能でもいいし方向性でもいいし)に集中したスプリントバックログを作ろう、みたいな話をする。

スクラムについて軽くおさらい

スクラムでは、スプリントと呼ばれる大体1~4週間の短いタイムボックスを繰り返しながら開発を行う(うちは2週間)。 スプリントは、計画 -> 開発/スタンドアップミーティング -> レビューな感じで進んでく。

計画フェース

計画フェーズでは、スプリント期間に何をやるかを計画する。

  1. ユーザストーリーを優先順に並び替えプロダクトバックログを作成する
  2. そこからチームがスプリント期間に達成できるユーザストーリーを選択する
  3. ユーザストーリーを実現するための作業をタスク化する(スプリントバックログ
  4. スプリントバックログ上の作業を期間内に完了することをチームでコミットする

開発フェーズ

うぉぉ作るぞー!みたいな感じ。 スタンドアップミーティングというやつを毎日やって、気軽に障碍を共有することで、チームの進捗を妨げるあれこれについてすぐ対処することができる。

レビューフェーズ

スプリントの最後に、今回コミットしたユーザストーリーを実現できたかみんなでレビューする。 運用中のサービスだと、これを待たずにリリースしていることもあるけど、気にしない。

あと、KPTみたいなフレームワーク使って、お仕事のススメ方の改善活動なんかもしておくとGOOD。

人数が増えるとなんかスプリントが謎い感じになる

チームメンバーが増えるにつれて、2週間のタイムボックスで達成できるユーザストーリーが増加する。 増加する分には、早くユーザに価値を届けられていいんだけど、安易に上から順にユーザストーリーを選ぶと、なんかいろんなところに手を出し過ぎる感があって、

今回何にコミットするんだっけ?
結局どういう価値が届くんだっけ?
いや、そこが改善されるのも、こういう機能が付くのもわかってるんだけどさ…
2週間後にはこのプロダクトはどうなってるの?

みたいな、これとこれとこれが新しく入るよって説明はできるんだけど、半年後振り返ったときに、あの時にこのプロダクトはこう変わった!みたいなことが説明し辛いなあと感じるようになってきた。

リリース前は、このスプリントでアルファ版が完成したぞ!ベータ版ができたぞ!みたいなそういう達成感があった。

スプリントをヒトコトで表す

そこで、スプリント計画会議の最初に、今回のスプリントでチームとして何を解決したいか、ヒトコトでユーザに説明するとしたら何がいい?テーマは何?というのを聞くようにしてみた。

たとえば、「今回は、ユーザからのお問い合わせ(わかりにくい部分や不満点)を減らすようなスプリントにしよう」とか「この機能の面白さを強調するような周辺環境を整えよう」とか「今回は、1日以下でできるような細かい改善施策を大量に消化してプロダクトバックログを整理しよう」とかそういう感じ。

できれば、スプリントバックログ作成前にやって、テーマに沿ったユーザストーリーを入れるのが良いと思うが、優先度をどうしても守りたい、ということであれば作成後でも構わない。

とにかく、名前を付けることが重要で、それによって多種多様なユーザストーリーをひとつの方向性として示すことができる。 「○○週間」とか「○○強化月間」とか、普段と変りなくてもそういう名前を付けるだけでなんか意識が変わる。

テーマとしては、他にこんなものがありそう。

スプリントパターン例

  • ユーザのXXXという問題をひたすら解決する(問題を絞る)
  • ひたすらサービスのUIを使いやすくする(作業内容を絞る)
  • XXXなユーザが喜ぶことをする(ターゲットを絞る)
  • XXXの機能群を見直す会(作業対象を絞る)

スプリントにタイトルを付ける

決めたテーマを忘れないようにタイトルを付ける。 チームメンバーが、何やったか思い出せればどんな内容でも問題ない。

(自分はそのまま書くのつまらないので、あるチームはアニメネタ、あるチームは名言ネタで統一するようにしてる)

おわりに

長々と書いたけど、とりあえずスプリントに名前付けるとやる気出るよ!ということを書いた。

最近つけたお気に入りタイトルを紹介して終わる。

第X話 「これがリリース・・」 「だったものさ。その骸だよ」
第X区間 おじさまが見てる
Fes.X 成功する秘訣は、今より少しだけ上を目指すこと
Fes.X 質の高い偽物はくだらない本物よりずっといいんだぜ

最近の開発フローの改善と、「スプリントおじさん」という取り組み

ここ最近、自分が見ているプロジェクトの1つで、うまくスケジュール通りに作業が進んでいなかったので、その対策をした。 その中でも特に効果があった2つを紹介する。

背景

簡単にプロジェクトの背景を説明する。

  1. スクラムっぽい開発をしている
  2. スプリントの期間は2週間
  3. スクラムマスターはいるが専任ではない
  4. すでにリリース済みで運用中のWebサービスである

基本的によくあるスクラムっぽい感じで、2週間というタイムボックスの中にチームが作業可能なストーリーを突っ込んで、ひたすら消化する。 スプリントの最後には、レビューをして、次のスプリントの計画を立てる。

スクラムマスターは、一応自分が担当しているが、専任ではないし、他のプロジェクトも見ているので、注意深くチームを見れていない。

課題

以下のような課題があった。

  1. バグの修正や問い合わせ対応など、計画時に含まれていなかったタスクがスプリント中に増えてしまう
  2. エンジニアやデザイナがこだわって必要以上の時間をかけてしまう
  3. スプリントの終わりになってようやく、かなりのストーリーが残っていることに気づく
  4. 優先順に作業ができていない

1. スプリント中の追加タスク

毎回差し込みタスクはあるので、それを含めて見積もりはしているのだけれど、メンバー的には「追加があったんだからもともと入っていた予定が終わらなくても良いよね」という言い訳の余地を与えてしまっていた。

2. 必要以上のこだわり

2週間のタイムボックスは、人によっては全体像が見えにくいらしく、10個タスクがあるのに1つのタスクに5日かけてしまうようなことが発生していた。 また、作業によっては要件以上の作業(あとで必要になるから、せっかくやるならこれもやりたい)に取り組み、見積もり時の作業より大分ファットなことをやってしまう傾向があった。

3. ギリギリになって焦る

理想的なグラフと現在の進捗グラフは、常に見れるようになっているが、大きなストーリーはスプリントの終わりになるまで解決しないことが多く、終わり頃に一気にグラフがガクンと下がる、という不健全な状態に慣れてしまっていた。

大きなストーリーを消化して満足していると、実は細かいストーリーがいくつも残っていて、「あれ実はこれ終わらないんじゃね?」って現状に気づく。

4. 優先順に作業できない

ストーリーは優先順に並んでいて基本的に順番に作業するようにしているが、

  • 同時に作業しづらい
  • 特定の人しかできない(その人がやったほうが明らかに早い)
  • 作業順の読み合いによるデッドロック

などのもろもろの理由により、いくつものストーリーが並行して走っていた。

そのせいもあり、どのストーリーも中途半端で、スプリントの最後にガクンとグラフが下がる、または下がらないというギャンブルを強いられていた。

作業順などはサブタスクの切り方で工夫はできるものの、逆に非効率になる場合があって難しい。

対策

新機能大臣と改善大臣

課題1の差し込みタスクに関しては、

  • できるだけ、スプリント中に追加はしない
  • スプリントごとにバグや問い合わせを優先的に対応するメンバーを決める

という対策をした。

とくに後者は、「新機能大臣と改善大臣」という名前でチームに定着し、細かな改善を行う改善大臣がバグや問い合わせの対応を行うことで、新機能などの大きなストーリーの遅延を防ぐことができた。

スプリントおじさん

課題2,3,4に関しては、チームメンバーにしっかりスプリントのタスクを把握してもらうのが良いかなと思ったので、「スプリントおじさん」という取り組みを考えて運用している。

フレーバーテキスト

スプリントおじさんは近年発見された妖精で、理想的なグラフに沿って実績を積むのが生きがい。そのためには手段も問わないらしい。口癖は「進捗が危機に陥った場合、おじさんは(グラフ維持の)目的のために有効ならば、手段を選ぶべきではない

仕組み

1週間単位でメンバーの誰かが「スプリントおじさん」になって、以下のことをやる。 おじさんは、毎週末にその週の総評をして、次のおじさんを指名する。

やること

  • 停滞している課題があったら「進捗どうですか」
  • 並行して作業が動いていた場合、それぞれの進捗を見つつ、スムーズに工程が進むようにする
  • 詰まっていそうなメンバーがいたら助け舟を出す/助けられそうな人にお願いする
  • 作業をふくらませているメンバーがいたら注意する。合言葉はYAGNI
  • 仕様や要件を削って作業ボリュームを減らす
  • (不思議な力によって)タスクを消滅させる

効果

今のところかなり良い。 メンバーによって、いろいろな動き方があり、今後の運用の参考になる。

また、一度おじさんを経験したメンバーは、作業のすすめ方や作業内容(これって今必要?的な)に気を使うようになり、おじさんの負担が減っていくように思えた。

おじさんをタイムボックスのサイズと合わせていないのは意図的で、スプリントと1:1にしてしまうと、綺麗に終わったらその人のおかげ、終わらなかったらその人のせい、になってしまうのを懸念した感じ。

まとめ

会社やチームによって、全然やり方違うし、うちのやりかたも詳細に書いているわけではないのでアレだけど、こういった様々な問題に他社ではどう取り組んでいるのかとても興味ある。

追記

『Pull Toy.』 社内ゲームジャムに参加した

5/16,17の土日を利用して社内でゲームジャムが開催されたので見学に行った。

テーマは「ひも」。

スケジュールは、1日目昼に企画発表、夕方にα版発表。2日目昼にβ版発表、夕方に最終発表という感じだったのだけれど、企画発表見ていたら面白そうだったので午後から急遽参加した。

Pull Toy.

ストーリー

障害物を避けながら、ぼくの大好きなおもちゃを、おもちゃ箱に片付けよう!

画面イメージ

f:id:ofsilvers:20150518082826p:plain:w160 f:id:ofsilvers:20150518082823p:plain:w160 f:id:ofsilvers:20150518082828p:plain:w160

テーマの解釈

イライラ棒 + ひも

仕組み

椅子やゴミ箱、猫や靴下などの障害物が、"ぼく"とおもちゃ箱の間に配置されている。
"ぼく"は、おもちゃを障害物にあてないように慎重にゴールのおもちゃ箱までおもちゃを誘導する。
障害物におもちゃが5回あたってしまうと、おもちゃが壊れてGAME OVER。

どうしても障害物が邪魔で通れない場合は、3回まで”ママ”に片付けをお願いできる。

プレイイメージ

f:id:ofsilvers:20150518085440g:plain f:id:ofsilvers:20150518085407g:plain

Game Jam

初参加だったけど面白かった。 作業時間は10時間弱ぐらいだったっぽい。

開発

本当はUnityでやりたかったけど、インストールとドキュメント読むだけで終わりそうだったので、SpriteKitで作った。
…とは言ってもSpriteKitも初めてだったので最初の1時間ぐらいはリファレンス眺めたりしてたけど。

とにかく時間内に完成させることが目標だったので、didMoveToViewにひたすら処理を書きまくる感じで設計とかはボロボロだけど、完成度は一番高かった!(贔屓目)と思う。

デザイン

たまたま、別チームでデザイナさんが参加していたので、素材を書いてもらった。
「タイトル画面は、左向きで、赤ちゃんがこの玩具を引っ張ってる感じで!」とか「家にあって、赤ちゃんの邪魔になりそうなやつを適当にいくつか!」みたいなゆるふわな要求でステキな画像を作ってくれた @momoyageek に感謝。

リリース

予定はないけど、他の参加者の何人かは頑張るみたいだ。頑張れ。

「エセ芸術家ニューヨークへ行く」というゲームをやっていて「一文字探偵(仮)」というゲームを考えた

今日たこ焼きパーティーで「エセ芸術家ニューヨークへ行く」というゲームをやった。

oinkgms.com

簡単に言うと、1人だけ親の出したお題を知らない状態で、順番に一筆ずつ絵を描いていって、エセ芸術家(お題を知らない人)を当てるゲーム。

  • 親とエセ芸術家は、エセ芸術家がバレなければ勝ち
  • 子はエセ芸術家を見つければ勝ち
    • ただし、エセ芸術家だとバレても、お題を当てれば親とエセ芸術家の勝ち(※)

このゲームは※の部分がとても面白い。
お題を知っている人たちは、エセだと思われない程度にお題に沿った絵を描きつつ、エセにお題がバレないように分かりにくい絵を描かなければいけないというジレンマがある。


ただ、親には特にジレンマはなく、書きやすく分かりやすいお題を出せばよい。
みんなが分かりやすく書けばエセ芸術家にお題が伝わるし、みんなが分かりにくく書けばエセ芸術家が紛れるからだ。

そこで、親に(も)ジレンマがあるゲームを考えてみた。
もしかするとすでに似たゲームがあるかも知れない(が、少なくとも自分は知らない)。

概要

ゲーム名は適当だけど「一文字探偵(仮)」。
親は、誰かが分かるが全員は分からないようなお題を出す。
子は、自分と誰かは分かるが多くの人には分からない質問をする。

ルール

5人(1人が親で4人が子)で試したので、5人ルールで書く。

  1. 親は4文字の単語(名詞でも概念でも何でもいい)を考える
  2. 4枚の紙それぞれに4つの丸を書き、それぞれの紙に1文字ずつ書く
    • たとえば、思いついた単語がたこやきなら「た○○○」「○こ○○」「○○や○」「○○○き」
  3. それらの紙を、1枚ずつ子に配る
    • 配られた子は、他の子に見えないようにする
  4. 1文字目を引き当てた人から順に、親に対してYES/NOで答えられるような質問をする
    • たとえば、「それは食べ物ですか?」「手のひらに乗るサイズですか?」等
  5. 親は質問に対し、YESかNOで答える
  6. このとき、補足の解答をしてもよい
    • 「はい、スーパーやコンビニなどで売っています」
    • 「はい、しかし実際に手のひらに乗せると、火傷をするかもしれません」
  7. 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, ... みたいなセットが多い