こんにちは、クラシルのバックエンドを担当しております鈴木と申します。
今回は「非エンジニアとスクラムを組んでプロジェクトを推進した事例」についてお話したいと思います。
下記の様な課題を持っている方に読んで頂けると嬉しいです！
- 課題に対する不確実性が高い。
- チームメンバー同士でも今誰が何をやっているかわからない。
- チームメンバーの活躍や成果が見えにくい。
※本記事は主に非エンジニアとスクラムをする際に意識した点やトピックを記載しております。基本的なスクラム構築についての説明は触れておりませんのでご容赦ください。
▼非エンジニアスクラムの発足
2022年11月頃にクラシル開発部全体でチームの再編成とスクラムの導入があり、その中で開発を必要としないクラシルのUGCコンテンツの拡充を推進するチームが発足しました。 そこで私（スクラムマスター）を含めた合計6名でプロジェクトを進めることになりました。メンバーはCS業務や、料理レシピのコンテストの開催などをしている「非エンジニア」の方たちです。（+アルバイトさんも含む）
結成時のチームは下記のような状態でした。
- スクラムは全員未経験。
- 定常的な業務が多く、不確実性の高い業務の経験は少ない。
▼（スクラム導入期）どんなことからはじめたか
・定常業務の棚卸しと可視化
まずはメンバー全員の業務スケジュールを曜日ごとに書き出してもらい、それをもとに１つずつどんな作業をやっているか教えてもらいました。
ヒアリングの結果をもとに下記の分類に分けることができました。
- 自動化できる業務
- アルバイトさんにお願いできる業務
- その人の対応が必ず必要な業務
1.は自分が自動化をおこない、2.はアルバイトさんにお願いをして業務の時間を可能な限り削減しました。
3.は毎スプリントタスクボードに[定常業務]として各メンバー分のチケットを作成しました。
これにより課題解決に対して取り組める時間が増え、同時に業務の可視化を行なうことが出来ました。
・アクティブなコミュニケーションによるフォロー体制
スクラム体制になり、タスクボードにチケット化された業務を「はいどーぞ。」と言われてもなかなか上手くいかないケースが発生しました。 自分の伝え方が悪かったり、それぞれの認識にズレが生じていたり様々なケースがありますが、いずれもコミュニケーションをすることによって未然に防げた内容でした。
そこで積極的な声かけを心がけることで、メンバーが言い出せなかった課題・困り事、早い段階で認識のズレを修正することが出来たと思います。
・時間を掛けて[目的]や[背景]を共有していく
チームにはメンバーだけでなく、アルバイトさんへお願いする業務が多く存在します。コミュニケーションをする際に意識していることは業務的な指示のみに留めてしまうのではなく少し時間を掛けてでも目的や背景をしっかりと説明することです。単純な業務であっても最初に時間を掛けて共有しておくことによって、結果的により短い時間で成果を出すことに繋がりました。
これを繰り返すことによって、徐々に「もっとこうした方が良さそう！」「ここを改善出来そう！」など自分以外の視点でも意見を頂けるようになり良い循環が生まれました。
▼（スクラム成長期） 自立への働きかけ
・スクラムイベントの分散
プロジェクトがある程度進行しスクラムに慣れて余裕が出てきたタイミングで、スクラムイベントのファシリテーションをメンバーにお願いするようにしました。
特に効果的だったのはタスクボードの進捗管理を週替りで当番制に変更したことです。担当したメンバーは自分以外のタスクにも関心を持って積極的にフォローし合う環境が少しずつ出来始めました。
チーム全体の課題解決に対する自主性が生まれ、チームの成長につながったと思います。
・ティーチングからコーチングへ
結成時から目的や背景の共有を続けてたことにより、チームメンバーの課題に対する不透明性が下がり、自律的に課題に取り組めるようになってきました。
このタイミングで自分からの積極的なフォローを徐々に少なくしていき、助けを求められた場合でも直接的な解答を控えてるようにしてその時必要な最低限のサポートのみをするように心がけました。
自分は心配性なのですぐに手助けをしたい性格なのですがそれがチームとメンバーの成長を阻害してしまうため、グッと堪えてメンバーの成長につながるような振る舞いをしていきました。
１つずつ壁を乗り越えていくことによって、ハードルの高い課題に対しても挑戦出来るようになっていきました。
▼初めてのメンバーとスクラムをする上で特に気をつけた部分
タスクボードで進捗状況（=成果）が可視化されます。進捗が良い場合はなにも問題ありませんが、遅れている場合ストレスや焦りで心理的負荷が高まります。 （この部分はスクラムの良い点でもあり、悪い点とも言えるかもしれません...。）
進捗が遅れる原因が何だったのかをレトロスペクティブ（≒ふりかえり）で明確にしてチーム全員で改善案を検討・実施。メンバー全員で改善案を検討することによって、一人ひとりが自分ごととして問題を捉え、問題を当事者一人で背負い込む状態にならないように気をつけました。
またコミュニケーションハードルを下げるために、スプリントレビューではお菓子を用意したり、些細な質問でも気軽にできるような雰囲気作りを心がけていました。
具体的には、メンバーからの質問には即レス対応をしていました。他にも、話しかけやすい雰囲気を作るために冗談を言ってみたり...笑
▼まとめ
現在のチームで約5ヶ月間一緒になってスクラムをまわしてきました。
チームの状態に合わせてスクラムマスターの振る舞いを柔軟に変えていくことが大切なのだと、実践しながら学ぶことが出来ました。
これからももっと良いチームになるようにがんばります！
この記事がシステム開発以外でスクラムを実践される際の参考になりましたら幸いです。
スクラム体制にして良かった点
- タスクの見える化によって、メンバーの成果が見えやすくなった
- 見える化によってチーム内外とも連携がしやすくなった
- 不確実性の高い業務に立ち向かう勇気と実行力が培えた
