DMM.com #1 Advent Calendar 2018 の5日目を担当します、 @mesh1nek0x0 です。
普段はスクラムマスターとして、チームが気持ちよく成果をあげていくために
あれやこれやと考えながらいろいろ試行錯誤しています 
チームビルディングやスクラム開発に関する投稿だと、
構造だったり、抽象的な概念の話はよく見かけますが、
その構造にするために、どういう取り組みをしているのか？
どうやって維持しているのかは、あまり具体的な知見が共有されていないと感じています
そこで、今日は私の所属するチームで
現在もチームで続けている７つの取り組みついて
「具体的にこういうことをやっているよ」という内容をご紹介していきたいと思います！
▼このAdvent Calendar について
前日の記事は、 @mafuyuk さんの 「定期的にローカル環境のDockerリソースを掃除する」 でした。
これは DMM.com #1 Advent Calendar 2018 - Qiita の5日目の記事です。
カレンダーのURLはこちら
DMM.com #1 Advent Calendar 2018 - Qiita
tl;dr;
長いので先に要約を掲載しますと。
スクラムチームで現実的にスプリントを回すためには...
正しい方向へチームが全力を注げるよう、"あるある”な事象を解決しやすい仕組みを用意するとよい
と、私は考えています。
別の言い方をすると、 本来チームが進みたい方向以外に目が行き過ぎない仕組みを作る とも言えます。
私のチームでは、上記考えに基づいていろいろ試行錯誤したところ、
これから紹介する7つの取り組みを導入後に
チーム内から「スプリントが順調」という言葉がよく聞こえる状態を維持できています。
それら7つの取り組みを紹介するので、よかったらチームでも使えそうなものを取り入れてみてください 
対象読者
- いわゆるスクラム開発のお作法を概ね理解している方を想定（以下用語だけで内容が把握できる）
- バーンダウン
- タイムボックス
- ふりかえり
- デイリースクラム
- ...etc.
- ある程度現場で開発経験がある人を想定
前提
さっそく色々と取り組みを紹介していきたいところですが
その前にチームの状況について、ざっくりとご紹介します。
- スクラムチームで開発
- タイムボックスは2週間
- ふりかえりは1週間ごとに実施（1スプリント2回実施）
- プランニングはスプリント開始前に2時間程度で決定
- デイリースクラムは毎日10分程度
- 1拠点で開発
- チームは7人
- POが1名
- 開発メンバーが5名
- スクラムマスター（私）が1名
- Webアプリケーションの開発
- サービスの基盤となるプラットフォームの開発・運用・保守
- バックエンドAPIの開発からフロントエンドまですべてを担当
このような状況で、これから紹介する7つの取り組みを実施したところ、
チーム内から「スプリントが順調」という言葉がよく聞こえる状態を維持できています。
本題
その1 - 行動指針を立てて、チームで共通の判断軸をもたせる
実施しやすさ：★★★☆☆ （決めてしまえば楽ですが、言葉選定に結構困る）
継続しやすさ：★☆☆☆☆ （
浸透させるためには別の工夫が必須です）
効果：★★★★★ （浸透すると行動がぶれにくく、なにごとにも安定を感じます）
メルカリの3つのバリューをリスペクトして始めた取り組みの1つです。
メルカリにならって３つの価値観を定義しています
人は、なんらかの判断を行ってから行動をしているそうでして、その判断は、それぞれの知識・経験・価値観に基づいて行っていると考えています。
共通の判断軸がない状態で任せてしまうと、チームの意図しない行動（e.g. 積極的なのは嬉しいんだけど、そうじゃない...みたいな行動）が生まれてしまうことがままあります。
この取り組みでは、行動の判断軸として、チームの共通の価値観をプラスすることで、
チームの行動を大きくぶれないようにする狙いがあります。
なお、価値観をチームに浸透させるために、SlackのEmojiやReacji
Channeler（Slackで特定のemojiリアクションが付いたら別のチャンネルにを内容を通知するSlackの公式App）を活用して、見せる化を意識しています
その2 - 方針至上主義（事前にやりたい方向のすり合わせ）
実施しやすさ：★★★★☆ （既存のコードレビュー同様に、設計時点でレビューを実施するだけです）
継続しやすさ：★★★☆☆ （設計の資料にgithubのようなレビュー機能はないため、通知や差分などは概ね人力になります...）
効果：★★★☆☆ （チームで作るものの認識を事前にあわせているとレビューも比較的スムーズに感じます）
ひらたくいうと、設計です。やろうとしていることに関して、
変更や影響、手戻りが大きそうなものに関しては
あらかじめチームでの合意を必須にする、ということです。
その1で大まかな行動の方向性は揃いますが、全てが揃うわけではありません。
これは、共通の判断軸を持っただけで、他の知識や経験という判断軸がなくなったわけではないため、
どうすべきかが異なることは十分ありえるからです。
方針の時点で一度チームレビューを挟むことで、開発後に大きな手戻りが発生しようにしています。
ちなみにすべてを方針ありきで進めているかというと、そうではありません。
あとから経緯の確認が必要になりがちな変更や影響、手戻りが大きそうなものに絞って実施しています。
それ以外の瑣末なことに関しては各自および、ちょっとしたチームの相談による判断で進めています
具体的な手段として、弊社ではconfluenceを導入しているため、
この方針のすり合わせはそちらで行っています。
レビューの際に、インラインコメントで質問したり、意図を確認したりして、
事前にどういう意図で、どういうものを作ろうとしているのか、チームで認識を合わせます。
その3 - issue検討会（事後の軌道修正）
実施しやすさ：★★★☆☆ （メンバーが気になることをあげてもらい、週1回1h話し合う時間をとる）
継続しやすさ：★★★☆☆ （継続的に気になることをあげやすい、投稿しやすさの工夫が必要）
効果：★★★★☆ （今すぐはできないけど、いつかやりたいことも拾ってチーム内で共有しやすい）
事前の考慮不足をはじめとした、もやもやする/したことに関してチームで議論する時間を週1回1hで設ける取り組みです。
スプリント中にもやもやすることはありませんか？
たとえば、
- 実際に運用してみたら想定外のルーチン作業が発生したので仕組みを変えたい
- 新しいxxが発表されて、そっちに乗り換えたほうが時間短縮できるかも
- xxクラスが肥大化してきてそろそろリファクタしたい...
などなど。
こういったモヤモヤを集めておき、週に1回時間をとって話し合うのがissue検討会です。
実現手段として、githubのissue機能を利用しています。
検討会が始まると、メンバーから議論したい話題を選んでもらいます。起票した人からもやもやについて具体的に語ってもらい、チームでどうしたいか検討することで、もやもやを解消していきます 
なお、検討後に具体的にタスクが必要なものはバックログにタスクを積んで、issueをcolseします。検討の結果、なにも行わないものも、その旨を記載してissueをcolseしておきます。（※あとから、経緯を確認しやすくするためです）
なお、もやもやはSlackのSlash Commandsから投稿できるようにもなっており、スプリント中に発生したもやもやも、サッと議題に投げ込んで、本来やるべきタスクにすぐに戻って集中できるように工夫しています 
その4 - カイゼンタスクを積みっぱなしにしない、Fresh Keep
実施しやすさ：★★★★★ （時間をとって1つ紹介するだけ）
継続しやすさ：★★★☆☆ （人力で選んで、得られることを紹介する必要があります）
効果：★★☆☆☆ （簡単なものは紹介することで消化されやすくなる傾向がありました）
その3が「見える化」の取り組みでしたが、これはそれを「見せる化」するための取り組みです。
合間ですぐに取り組めそうなタスクを毎日1つ、紹介します。
その３で紹介した、issue検討会では各自のモヤモヤから発生するタスクなので、性質上カイゼン系のタスクが多くなります。
そのため、開発タスクなどど比べると必然的に優先度が下がりがちです。
ですが、せっかく見えるようになった各自のモヤモヤも、
消化されないままだと本質的な問題が解決できません。
そこで、毎日1つは開発チームの目につくようにすることで、
モヤモヤの解消に自然と意識を向けられるようにする狙いがあります。
紹介する際には単純にリンクを貼るだけでなく、
取り組む際のメリットを列挙したり、アイキャッチになる画像を添えたりして、手に取りやすいように意識しています。
その5 - ファイブ・フィンガーズ（from カイゼン・ジャーニー）
実施しやすさ：★★★★★ （バーンダウンできそうか？を指の数でメンバーに5段階評価してもらうだけ）
継続しやすさ：★★★★★ （必要なのは手だけなので続けやすいです）
効果：★★★★★ （普段はあまり積極的に意見できないメンバーも含めて全員が数字を出すので、周囲も理由をきいてチーム全体の状況を把握しやすくなります）
デイリースクラム時に実施しています。
このプラクティス自体は、独自のものではなく、カイゼン・ジャーニーで紹介されていたものをチームに取り入れています。
詳しくはぜひ書籍を読んでいただきたいのですが、簡単に紹介しておきます。
デイリースクラムが始まると
「現在のスプリントをチームで達成できそうか？」という観点で、
個人個人が「本当はどう思っているか？」を5本の指で同時に表明します。
各自のタスクの進捗にフォーカスしてしまうと、個人に視点が移ってしまい、問題 vs 個人となりがちだからです。
各自のタスクの進捗についてではなく、実施中のスプリントの達成についての考えを表明することで
問題 vs チームという捉え方に、自然と持っていきやすくなります。
今までは「（自分のタスクについては）問題ありません」という意見ばかりでしたが、導入後は
「xxさんが詰まっていそうなので、経験のあるooさんがフォローに入らないと、残り時間的にまずいと思っている」などの
「みんなでスプリントを達成するための」意見が出て来やすくなったと感じています
その6 - Update Doc Day 資料の更新と断捨離
実施しやすさ：★★★★★ （時間を確保するだけなので始めやすいです）
継続しやすさ：★★★☆☆ （どこに片付けるか？という場所が明確でないと続きにくいと思います）
効果：★★★★☆ （定期的に資料が整理されて、ナレッジの探しやすさもup）
スプリント中に発見した「このドキュメント…◯◯したい」を改善する時間を意図的にとる取り組みです。
古い資料や、間違っている資料、足りない資料などを整理する事で可能な範囲で属人的なものをへらす事が目的です。
スプリント終了後のタイミングで、1時間だけ下記のいずれかに専念して取り組みます。
-
古くなっていると思うナレッジに要修正を示すラベルをつける -
古くなっているとわかっているナレッジの内容を更新する -
ナレッジの配置を整理する -
捨てた方がいいかも？というナレッジには
削除予定を示すラベルをつける
ナレッジは、全てをコード管理できれば、それはそれは理想的ですが、現実はそうもいかないので
ナレッジ化したものはなるべく腐らないようして、必要な時にすぐに情報を引き出せるようにしています。
スプリント中に資料の作成が発生した場合、GTDでいうINBOXに当たる場所に資料を仮置きしてもらいます。
スプリント終了後に片付けるべき場所に、整理整頓をしていく、という形を取ることで、
スプリント中は、資料作成だけに集中しつつも、資料が散らかったまま、という状態を回避しています 
その7 - チーム内社内ブログ team.fm
実施しやすさ：★★★☆☆ （文章さえかければ、はじめるのは比較的簡単）
継続しやすさ：★☆☆☆☆ （ブログスペースの確保および継続的に文章を書くのが大変です）
効果：★★★★☆ （紹介してもらえることがモチベーションに繋がったり、メンバーからコメントで意見が出たり、チーム内の行動を活性化していると感じています）
チームの状況を包み隠さず、チーム内外にお知らせする社内ブログを書くという取り組みです。
主に2つのカテゴリについて、毎週1記事ずつ、投稿しています。
- value-side（v-side）
- その1で紹介した行動指針に沿っている開発メンバーの行動をpick upして紹介する記事
- 価値観の観点から各個人の行動に注目してフィードバックを行うことで、行動指針の浸透をより強化
- 早いフィードバックでメンバーの成長を促す
- po/sm-side（p-side）
- 開発メンバー抜きでPOとスクラムマスターが話したことを紹介する記事
- POが何をみて、どう考えて優先度を決定しているのか？を公開して、POの優先度判断への理解度を高める（※PO vs 開発メンバーのようにならないようにする）
弊社では特別ブログ用のシステムを導入するなどはしておらず、
confluenceのブログ機能を利用して実現しています。
なお、この.FMと名乗っているのはbackspace.fmというpodcastの記事のカテゴリ分けの構成が元ネタなだけで、podcastで配信しているとかではありません 
社内ブログなので、自チームだけでなく、他チームにも自チームの取り組みを自然と紹介することになり、
チーム外からのメンバーの社内評価にも一役買っているようです 
まとめ
もし導入する内容に迷うようでしたら、やりやすさと継続のしやすさを踏まえて、
もっとも効果のあるファイブ・フィンガーズがオスメです 
| 取り組み | 実施しやすさ | 継続しやすさ | 効果 | 合計 |
|---|---|---|---|---|
| 行動指針を立てて、 チームで共通の判断軸もつ |
3 | 1 | 5 | 9 |
| 方針至上主義 | 4 | 3 | 3 | 10 |
| issue検討会 | 3 | 3 | 4 | 10 |
| カイゼンタスクを積みっぱなしにしない、Fresh Keep | 5 | 3 | 2 | 10 |
| ファイブ・フィンガーズ | 5 | 5 | 5 | 15 |
| Update Doc Day | 5 | 3 | 4 | 12 |
| チーム内社内ブログ | 3 | 1 | 4 | 8 |
いずれの取り組みも、チームでありがちな事象に対して、特にルールなどを設けずに自然と回避できるように仕組みづくりをすることを狙っています。
良さそうだし、取り込めそうだなと思うものがあればぜひ、チームにも導入してみてください
最後に
チームの生産性アップに関して他にも「こんな取り組みやってみたら、効果があったよ！」
というものがありましたら、ぜひぜひコメントにお寄せください
明日は @kkkdev さんです！ 引き続きDMM.com Advent Calendar 2018をお楽しみください。