はじめに!
某プログラミングスクール最終課題にて、スクラムマスターを経験させて頂きました！
スクラムマスター何それおいしいの？状態からのスタートでしたが、
勉強になったことや、未だに思い返しても嬉しかったことが多々ありましたので、
備忘録として体験談を書かせていただきます
本来のスクラムマスターの役割と違う部分や、顧客のいない中での開発なので、
間違っていたり、非現実的な部分もあるかとは思いますが、
私個人の理想のチーム論として見ていただけますと幸いです
理想としたチーム状態
『チームメンバーが主体的に、コードを書くこと（＋チームと顧客）にだけ集中している状態。』
以下、イメージ図です。
（今回の投稿は、この図が作りたかった、と言うのが動機のほとんどです
）
開発環境
・チームメンバー：6人
・制作物：某ECコピーサイト(Ruby on Rails)
・システム：アジャイル開発（スプリントレビュー: 1回/週、デイリースクラム: ３回/日）
プロダクトオーナーさんは、スプリントレビュー時のみ登場。
・開発期間：3週間
・開発時間：10 h/日
マスターとして心がけたこと
行動方針は、「理想の状態 ”チームメンバーが主体的にコードを書くこと（＋チームと顧客）にだけ集中している状態"になることを妨げる障害物を取り除くこと。」として、具体的には以下の行動を心がけました。
1. 行動の賞賛
コードを書く、発言をする、自分の意見を言う、など、行動することは全てウェルカム！
2. ターゲット（やるべきこと）の明確化
Trello（タスク管理アプリ）に、一目で課題がイメージできるレベルまで落とし込むよう、カードを量産する！
（何をしたらいいかがわからない状態は辛いです。非効率です。）
3. 全体における、各人の仕事の位置付けの共有
常に頭の中で全体像をイメージする、パワーポイントなどで可視化する。
（なんのためにやっているのか、がわかった方がやる気が出るはず。コラボレーションも進むはず！）
4. 不満の察知
とりあえず話す。表情を見る。毎朝話すことが大事かと感じています。朝スクラムは大事
学んだこと
チームでまとまるためには、共通の目的が絶対必要！！
チームメンバーは様々な考え、目的、思い、価値観を持って行動している。
上記の行動をしたところで、簡単にまとまることは決してありえない。
何が大切かを共有する、それをベースに話し合う、というのが効果的なのではないかと思いました。
『〇〇のために、ここは××をすべき』のような感じですかね。
自分の意見が正しいと思わない。きちんと相手の話を聞く。
これが二番目に大事だと思いました。かなり難しいですが。
（感情のコントロールも大事。。。）
人の考えはそんな簡単に伝わりません。。。
反省点
・タスクの見積もりを失敗すると死ぬ。
基本的にチーム内のトラブルのほとんどは、個人のスキルをタスクが大きく上回った時に発生しました。そして、その原因は、タスクの難易度を軽く見積もった、あるいは見積もれなかったこと、つまり、技術の理解不足、に起因していました。ある程度難易度を当てることは絶対に必要だと思いました。。。勉強あるのみ！
（タスクのアサインがスクラムマスターの本来の仕事かどうかはさておいて）
・自分の弱さを自覚する。
感情が乱れるのは、自分の未熟な部分が出てきた時かと思います。
自分で認識していれば、多少は対処可能、のはず！
個人的に嬉しかったこと
『チームメンバーがマスターの期待を上回る行動をした時』
難しいと思っていた人同士で協力し始めた時とか、スキルの低かった人が自分で勉強して武器を手に入れて、むしろチームを引っ張ってくれたりとか、もっと仕事下さいとか言ってくるとか、本当に楽しそうに課題に取り組んでくれるとか、グイグイ来てくれるとか、不和を乗り越えた時とか、そういう時は、胸が熱くなります