「チームをつくるワークショップ」というのを開催しました
社内の某プロジェクトのメンバー全員で「チームをつくるワークショップ」というワークショップを開催しました。
背景
2週間ごとに「チームメンバーの満足度をあげる」というテーマで振り返りを行っていたのですが、KEEPやPROBLEMが直近の物事に左右されがちという問題がありました。
また、この1年でチームメンバーも増え、お互いが何を考えて仕事しているのか、どういう環境が嬉しいのかという情報共有が不足しているように感じました。
そこで、1年の振り返りとして、お互いのことを深く知り、自分たちがどんなチームになることを選択するのか、というのを話し合う機会を用意しました。
資料
www.slideshare.net
流れ
4人一組のグループに分かれてもらって、グループごとにワークを行うようにしました。
まずはじめに、以下のような話をして、チームを作る上でお互いのことを知るのが重要だ、みたいなことを話しました。
チームを作る上で、メンバーのことを知ることが重要だよ。
（自分たちの）チームの目標は、製品のビジョンを達成することに加え、メンバーのサポートをすることだよ。
次に、以下の順番で5つのワークをこなしました。
- 自己紹介（一緒に働くメンバーがどんな人で何をしたいのか知る）
- 理想的なチームについて考える（チームの将来像に関する意見交換）
- 現在のチームがどうなっているかまとめる（現状の認識をすり合わせる）
- なにをどうすれば理想に近づくのか考える（理想と現実のギャップを見極める）
- ネクストアクションを決める（理想に近づけるために、個々人が何をするか決める）
Work 1. チームメンバーをもっと知ろう！
個人ワークで自己紹介を考えてもらい、グループ内で自己紹介をしました。
自己紹介を作る上で以下のような観点で自己紹介をしてもらうようにしました。
- あなたの業務はなんですか？
- あなたがチームに対して貢献できることはなんですか？
- 周りがあなたに期待していることはなんですか？
- あなたは今後どのような人になりたいですか？
Work 2. 理想的なチームについて話そう！
過去の経験を元に、それぞれが思う理想的なチームについて考えてもらいました。
その後、グループ内で「理想的なチームはどんなチームか」をまとめてもらい、全体に発表をしました。
- 今までで良かったチームはどんなチームでしたか？
- どういったところが良かったですか？
- そのためにどのような工夫がされていましたか？
Work 3. チームの現状を確認しよう！
同様に、今のチームはどんなチームであるかをグループでまとめてもらい、全体に発表をしました。
- 今のチームの良い/好きなところはなんですか？
- 今のチームの悪い/嫌いなところはなんですか？
- 今のチームの特徴（個性）はなんですか？
Work 4. 何ができるかを考えよう！
理想と現実の差は何か、どこを改善すればよいか、どんなことをすればよいか、というのをグループ内でまとめてもらい、全体に発表をしました。
- 今のチームに足りないことはなんですか？
- 何が変われば理想的なチームになりますか？
- それを変えるためには何をすれば良いでしょうか？
Work 5. アクションカードを書こう！
最後に、Work 4でまとめた課題に対して、各々が何をできるかを付箋にまとめてもらいました。
自分が、理想的なチームに向けてできることはもちろん、みんなにやってもらいたいことを発表したり、誰かにやってもらいたいことを書いてその人に渡す、といったことをしました。
- 理想のチームにするため…
- 自分ができることを付箋に書こう
- みんなでやりたいことを付箋に書いて発表しよう
- 誰かにやってほしいことを付箋に書いて渡そう
そして、最後に、
- 各グループがまとめてくれた「理想」を右に
- 各グループがまとめてくれた「現実」を左に
- メンバーごとのアクションカードをその間に
貼ったボードを成果物として作成し、ワークショップを終了しました。
やってみて感じたこと
初めてのワークショップ（参加も開催も）だったのですが、比較的うまく行ったのかなと思います。
ただ、思っていた以上に話が盛り上がり（特に自己紹介や理想のチーム）時間をオーバーしてしまったので、もう少し余裕を持った時間配分にすると良かったかなと思いました。
全体的にワークの時間を2倍ぐらいにしても良い感じでした（印刷に1時間ぐらいかかってスタートが30分弱遅れてしまったの申し訳ない…）。
あとは、時間がなくてアクションカードの共有がボードに貼るだけになってしまったけれど、本当は「誰々から誰々へ。理想的なチームにするためにほげほげしてほしいです」とか「私から私へ。理想的なチームにするためにほげほげをします」みたいな感じで宣言するような形をとりたかったなというのが反省点。
参加者の反応
ワークショップ後にアンケートに回答してもらったのですが、以下のような反応がもらえました（抜粋）。概ね好評だったようです。
- アクションカードを渡しあうのが面白かった
- アクションカードを貰えると、自分では気付いけない/気づかない、期待されている事を知れる
- チームメンバーの自己紹介で改めてどんな人物なのがわかった。全員分聞きたい
- 普段の業務とは違う雰囲気でチームメンバーとのコミュニケーションがとれたところがよかった
- 普段業務でかかわらない人の意見を聞くことができた
- 目標や課題などについて改めて考え直すよい機会となった
- 改めて「よいチームってなんだろう」「自分は何を期待されて何を貢献できるんだろう」と考えつつ、今の仕事を見つめなおせてよかった
- チームが目指したいこと、個人が目指したいことを考え直すいい機会になった
- 個人の意見や目指すものが知れたこと。今後、コミュニケーションすすめる上での種にできそう
- 普段言うタイミングを逃しがち、明文化されず雑談ベースで話しているような内容を表現出来た
特に、他人にアクションカードを渡す部分と、できるだけ普段関わらない人とテーブルが同じになるようにしたのが評価が高かったです。
また、似たようなワークショップがあれば是非参加したい。他のチームもやったほうが良いという回答も多かったので、アップデートしてまた開催できればいいな。
逆に反省・改善点としては、
- ぼくが参加していなかったこと
- ホワイトボードが各テーブルにあれば発表楽かも
- 話す時間とまとめる時間を分けてもらえると時間気にしなくていいので嬉しい
といったものがありました。
現場からは以上です。
おにやんま - ISUCON5予選敗退反省会 #isucon
ISUCON5予選に、 @karupanerura, @ar_tama と3人で「チームおにやんま」として参加しました。
当日の動きなどは他の二人が書いてくれると思うので、反省点をまとめておきます。
反省1：分担をきちんとする
インフラ編
インフラ整えるあたりで3人とも同じ罠（symlinkがー、daemon offがー、再起動がー）にハマったりしていたので、誰か一人が全メンバーのインスタンスでインフラ整えて渡すみたいなことをしておけばよかった。 その間に残りのメンバーはアプリケーションの仕様を把握したりコード読んだり。
アプリ編
指示出すメンバーが明確に決まっていなくて、それぞれが判断してアプリいじってたり、「AとBとC直そう」みたいに話したあと、誰がどれやる決めてなくて、「誰かがやってると思った」みたいなのがあったので、作業方針が決まったあとに、この作業は誰々、この作業は誰々とちゃんと分担するべきだった。
次回以降の対策
- インフラ整えてスナップショット配布
- 誰が何やっているか分かるようにする（小さい単位でブランチ切る）
反省2：みんなで忙しくならない
3人が3人ともゴリゴリコード書いていると相談もしづらいし、何かハマったときのヘルプが大変。 誰か1人は、計測中心に動きつつ、何か会った時に遊撃手として動けるようにしたほうが良かった。 あと開発しやすい環境を整えたり。
次回以降の対策
- 全体を見る人を立てる
- その人は実作業はせず、サポートに徹する（ハマった時の聞き役や開発しやすい環境を整えたり）
反省3：相談の時間を沢山とる
いちおうpt-query-digestで上から順に撲滅していったけど、もうちょい実装方法について共有しても良かった。 いろいろ意見出たけど、どの作業方針が決定稿か、みたいな認識がとれてなかった気がする。
次回以降の対策
- 全体を見る人を用意する
- 大画面でコードレビューしつつ、方針をコメントしてみる？
反省4：あわてないあわてない
なんか午前中にインフラまわりで時間かけてしまって、進捗ゼロです！みたいなので、お昼の時間も忘れて焦ってしまった*1ので、もっと時間をかっちり決めても良かった。
次回以降の対策
- ポモドーロテクニック的な感じで作業を止めて相談する時間を作る？
- 時報をslackに流してもいいかも？
- 音楽流して心に平穏を
おまけの反省
12:36 silvers: ブログ用におにやんまの写真とっとけばよかった 12:38 karupanerura: Uploaded an image: Slack for iOS Upload 12:38 ar_tama: https://instagram.com/p/8Es-fjLKqA/?taken-by=ar_tama 12:39 silvers: すごい 12:39 silvers: おにやんまerの鑑だ 12:40 ar_tama: ₍₍ (ง ˘ω˘ )ว ⁾⁾
ISUCON運営に感謝
— silvers (@silver_s) 2015, 9月 28*1:15時ぐらいに寿司食べた
午後、ぼーっとしてくる時間に休憩を推奨する発言を垂れ流すようにしてみた
会社の正式な制度ではないんだけど、チームとしてより生産性をあげるために昼休み以外にも休憩時間を取るといいんじゃないかという話になったので、お試しで15:30-16:30ぐらいを休憩推奨時間にしてみた。
もちろん、昼休みや休憩推奨時間以外にも適宜休憩はとっても良いけれど、制度として時間を確保することで
- 堂々と休みやすくなる（全然いつ休んでも良いんだけど、気持ち的に）
- チームメンバーとコーヒーブレイクしながら雑談しやすい
- slackに通知する（ようにしている）ので良いタイムキーパーになる
といった利点がある。
また、業務と関係ない話から面白い発想が生まれたり、普段あまり関わらない人と話すことで良いシナジーが生まれたりすることがあるのでそこも期待しているところではある。
実際に、その時間に話した内容からいくつかの新しい制度を会社に提案し採用されていたり、新しい勉強会のネタが生まれたりと良い結果がでているので計画通り。
どうでもよい雑談のしやすさは、チームとして今後力を入れていきたい部分なので、サポートしていきたい。
ちなみに
こんな感じで休憩に関する適当な名言を流しつつ学校のチャイムのmp3のURLを流してます。
追記
記事読んだ社内の人から質問あったので答えとく。
Q. 1時間多く昼休みとっているようなもん？
昼休みとは違います。
Q. どんなことをしているの？
例えば、飲み物飲んだり、トイレ行ったり、ストレッチしたり、たばこ吸ったり。
集中してて見てなかったチャットの返答をしたり、レビューをしたり。
あとは、溜まっているブログ記事読んだり、良いライブラリないかなって探したり。
Q. それって制度なくてもいつでもできることでは？
その通り。
ただ、その時間を「チームとして、大体この時間にとるとステキですね」ってすることで、ついでに相談ができたり雑談ができたりしてイイネって制度。
Q. 休憩っていうからサボってるのかと思った
良い名前があれば募集中。
ただ個人的には、脳の血管ブチ切れるぐらい思考している時か、ひたすらコードをガリガリ書いている時以外の業務時間は休憩だと思ってるのでこういう名前になった次第。
東京 Crystal 勉強会 #1 に参加してきました
2015年7月31日に五反田のモバイルファクトリーで行われた 東京 Crystal 勉強会 #1 に参加してきました。
Crystal は、最近話題のRuby風シンタックスの静的型付け言語です。
どれぐらいRuby風かというと、こんなぐらいです。
これ、Rubyでもそのまま動くんじゃないか？ Crystalすげーっ。 https://t.co/pO0F0vqTly
— Yukihiro Matsumoto (@yukihiro_matz) 2015, 6月 16発表内容
20分のトークが2本と、LT5本でした。 資料等はすべて、 東京 Crystal 勉強会 #1 in 五反田 - 資料一覧 - connpass にまとまっているので割愛しますが、Crystal の言語の説明から、実装の話、Crystalを使ってみた話、言語の歴史から見る Crystal という言語の位置付けの話など多岐に渡る話で、とてもおもしろかったです。
今後
今後も、日本のCrystal界隈を盛り上げていくために勉強会やもくもく会を開催するみたいなので、気になる方は是非 crystal-jp(slack) に参加してください！
以下のページからメールアドレスを送信すると自動でslackへ招待されます（ちなみにこの仕組みもCrystalで書かれています）。
ヒューマンエラーに精神論は危険信号
たまに参照することが増えたので日記にまとめておく。
どこかで読んだんだけど、事故の再発防止対策で、「ちゃんと確認する」とか「ちゃんとログを見る」とか『ちゃんと』って言葉が出てきたら精神論なので危険信号、みたいなことが書かれていて本当にそうだと思う。それで対策した気分になる分、何もしないよりたち悪い。
— silvers (@silver_s) 2014年3月13日
ヒューマンエラーなのにヒューマンが頑張る対策をいくらあげてもダメだよ！！
— silvers (@silver_s) 2014年3月13日
ヒューマンエラーは仕組みで解決しましょう！！
多分この本
記憶が確かなら、この本です。
- 作者:中田亨
- 発売日: 2013/07/05
- メディア: 文庫
スプリントに名前を付けると覚えやすいしやる気がでる
単純に優先順に作業すると、いろいろやりすぎて思い出に残りにくいので、スプリントにタイトルを付けて、特定の何か（機能でもいいし方向性でもいいし）に集中したスプリントバックログを作ろう、みたいな話をする。
スクラムについて軽くおさらい
スクラムでは、スプリントと呼ばれる大体1～4週間の短いタイムボックスを繰り返しながら開発を行う（うちは2週間）。 スプリントは、計画 -> 開発/スタンドアップミーティング -> レビューな感じで進んでく。
計画フェース
計画フェーズでは、スプリント期間に何をやるかを計画する。
- ユーザストーリーを優先順に並び替えプロダクトバックログを作成する
- そこからチームがスプリント期間に達成できるユーザストーリーを選択する
- ユーザストーリーを実現するための作業をタスク化する（スプリントバックログ）
- スプリントバックログ上の作業を期間内に完了することをチームでコミットする
開発フェーズ
うぉぉ作るぞー！みたいな感じ。 スタンドアップミーティングというやつを毎日やって、気軽に障碍を共有することで、チームの進捗を妨げるあれこれについてすぐ対処することができる。
レビューフェーズ
スプリントの最後に、今回コミットしたユーザストーリーを実現できたかみんなでレビューする。 運用中のサービスだと、これを待たずにリリースしていることもあるけど、気にしない。
あと、KPTみたいなフレームワーク使って、お仕事のススメ方の改善活動なんかもしておくとGOOD。
人数が増えるとなんかスプリントが謎い感じになる
チームメンバーが増えるにつれて、2週間のタイムボックスで達成できるユーザストーリーが増加する。 増加する分には、早くユーザに価値を届けられていいんだけど、安易に上から順にユーザストーリーを選ぶと、なんかいろんなところに手を出し過ぎる感があって、
今回何にコミットするんだっけ？ 結局どういう価値が届くんだっけ？ いや、そこが改善されるのも、こういう機能が付くのもわかってるんだけどさ… 2週間後にはこのプロダクトはどうなってるの？
みたいな、これとこれとこれが新しく入るよって説明はできるんだけど、半年後振り返ったときに、あの時にこのプロダクトはこう変わった！みたいなことが説明し辛いなあと感じるようになってきた。
リリース前は、このスプリントでアルファ版が完成したぞ！ベータ版ができたぞ！みたいなそういう達成感があった。
スプリントをヒトコトで表す
そこで、スプリント計画会議の最初に、今回のスプリントでチームとして何を解決したいか、ヒトコトでユーザに説明するとしたら何がいい？テーマは何？というのを聞くようにしてみた。
たとえば、「今回は、ユーザからのお問い合わせ（わかりにくい部分や不満点）を減らすようなスプリントにしよう」とか「この機能の面白さを強調するような周辺環境を整えよう」とか「今回は、1日以下でできるような細かい改善施策を大量に消化してプロダクトバックログを整理しよう」とかそういう感じ。
できれば、スプリントバックログ作成前にやって、テーマに沿ったユーザストーリーを入れるのが良いと思うが、優先度をどうしても守りたい、ということであれば作成後でも構わない。
とにかく、名前を付けることが重要で、それによって多種多様なユーザストーリーをひとつの方向性として示すことができる。 「○○週間」とか「○○強化月間」とか、普段と変りなくてもそういう名前を付けるだけでなんか意識が変わる。
テーマとしては、他にこんなものがありそう。
スプリントパターン例
- ユーザのXXXという問題をひたすら解決する（問題を絞る）
- ひたすらサービスのUIを使いやすくする（作業内容を絞る）
- XXXなユーザが喜ぶことをする（ターゲットを絞る）
- XXXの機能群を見直す会（作業対象を絞る）
スプリントにタイトルを付ける
決めたテーマを忘れないようにタイトルを付ける。 チームメンバーが、何やったか思い出せればどんな内容でも問題ない。
（自分はそのまま書くのつまらないので、あるチームはアニメネタ、あるチームは名言ネタで統一するようにしてる）
おわりに
長々と書いたけど、とりあえずスプリントに名前付けるとやる気出るよ！ということを書いた。
最近つけたお気に入りタイトルを紹介して終わる。
第X話 「これがリリース･･」 「だったものさ。その骸だよ」 第X区間 おじさまが見てる Fes.X 成功する秘訣は、今より少しだけ上を目指すこと Fes.X 質の高い偽物はくだらない本物よりずっといいんだぜ
最近の開発フローの改善と、「スプリントおじさん」という取り組み
ここ最近、自分が見ているプロジェクトの1つで、うまくスケジュール通りに作業が進んでいなかったので、その対策をした。 その中でも特に効果があった2つを紹介する。
背景
簡単にプロジェクトの背景を説明する。
基本的によくあるスクラムっぽい感じで、2週間というタイムボックスの中にチームが作業可能なストーリーを突っ込んで、ひたすら消化する。 スプリントの最後には、レビューをして、次のスプリントの計画を立てる。
スクラムマスターは、一応自分が担当しているが、専任ではないし、他のプロジェクトも見ているので、注意深くチームを見れていない。
課題
以下のような課題があった。
- バグの修正や問い合わせ対応など、計画時に含まれていなかったタスクがスプリント中に増えてしまう
- エンジニアやデザイナがこだわって必要以上の時間をかけてしまう
- スプリントの終わりになってようやく、かなりのストーリーが残っていることに気づく
- 優先順に作業ができていない
1. スプリント中の追加タスク
毎回差し込みタスクはあるので、それを含めて見積もりはしているのだけれど、メンバー的には「追加があったんだからもともと入っていた予定が終わらなくても良いよね」という言い訳の余地を与えてしまっていた。
2. 必要以上のこだわり
2週間のタイムボックスは、人によっては全体像が見えにくいらしく、10個タスクがあるのに1つのタスクに5日かけてしまうようなことが発生していた。 また、作業によっては要件以上の作業（あとで必要になるから、せっかくやるならこれもやりたい）に取り組み、見積もり時の作業より大分ファットなことをやってしまう傾向があった。
3. ギリギリになって焦る
理想的なグラフと現在の進捗グラフは、常に見れるようになっているが、大きなストーリーはスプリントの終わりになるまで解決しないことが多く、終わり頃に一気にグラフがガクンと下がる、という不健全な状態に慣れてしまっていた。
大きなストーリーを消化して満足していると、実は細かいストーリーがいくつも残っていて、「あれ実はこれ終わらないんじゃね？」って現状に気づく。
4. 優先順に作業できない
ストーリーは優先順に並んでいて基本的に順番に作業するようにしているが、
- 同時に作業しづらい
- 特定の人しかできない（その人がやったほうが明らかに早い）
- 作業順の読み合いによるデッドロック
などのもろもろの理由により、いくつものストーリーが並行して走っていた。
そのせいもあり、どのストーリーも中途半端で、スプリントの最後にガクンとグラフが下がる、または下がらないというギャンブルを強いられていた。
作業順などはサブタスクの切り方で工夫はできるものの、逆に非効率になる場合があって難しい。
対策
新機能大臣と改善大臣
課題1の差し込みタスクに関しては、
- できるだけ、スプリント中に追加はしない
- スプリントごとにバグや問い合わせを優先的に対応するメンバーを決める
という対策をした。
とくに後者は、「新機能大臣と改善大臣」という名前でチームに定着し、細かな改善を行う改善大臣がバグや問い合わせの対応を行うことで、新機能などの大きなストーリーの遅延を防ぐことができた。
スプリントおじさん
課題2,3,4に関しては、チームメンバーにしっかりスプリントのタスクを把握してもらうのが良いかなと思ったので、「スプリントおじさん」という取り組みを考えて運用している。
フレーバーテキスト
スプリントおじさんは近年発見された妖精で、理想的なグラフに沿って実績を積むのが生きがい。そのためには手段も問わないらしい。口癖は「進捗が危機に陥った場合、おじさんは（グラフ維持の）目的のために有効ならば、手段を選ぶべきではない」
仕組み
1週間単位でメンバーの誰かが「スプリントおじさん」になって、以下のことをやる。 おじさんは、毎週末にその週の総評をして、次のおじさんを指名する。
やること
- 停滞している課題があったら「進捗どうですか」
- 並行して作業が動いていた場合、それぞれの進捗を見つつ、スムーズに工程が進むようにする
- 詰まっていそうなメンバーがいたら助け舟を出す/助けられそうな人にお願いする
- 作業をふくらませているメンバーがいたら注意する。合言葉はYAGNI
- 仕様や要件を削って作業ボリュームを減らす
- （不思議な力によって）タスクを消滅させる
効果
今のところかなり良い。 メンバーによって、いろいろな動き方があり、今後の運用の参考になる。
また、一度おじさんを経験したメンバーは、作業のすすめ方や作業内容（これって今必要？的な）に気を使うようになり、おじさんの負担が減っていくように思えた。
おじさんをタイムボックスのサイズと合わせていないのは意図的で、スプリントと1:1にしてしまうと、綺麗に終わったらその人のおかげ、終わらなかったらその人のせい、になってしまうのを懸念した感じ。
まとめ
会社やチームによって、全然やり方違うし、うちのやりかたも詳細に書いているわけではないのでアレだけど、こういった様々な問題に他社ではどう取り組んでいるのかとても興味ある。
追記
書き忘れたけど、スプリントおじさん、「おじさん的には〜」って発言することで、"その人”から離れて客観的な意見を言えるっていうのが良いところでもある
— silvers (@silver_s) 2015, 5月 29