関係の質を高めるための取り組み ④変化を与えてみよう
小糸悠平氏（以下、小糸）：次が変化を与えてみようということです。これはわりとリモートでありがちですが、マンネリ化ですね。同じようなことをしていて新鮮味がないということです。あとは、ふりかえりで出る改善案が似たようなものばかりになる傾向になっちゃいます。
そんな傾向の時に、仮説を立てます。（スライドを示して）“マンネリ”と書いていますが、そもそも（マンネリとは）「飽きているんだろうね」ということと、あとは「チームが現状これ以上できることはないと判断しているんじゃないか」というところですね。
どうすれば解消できるんだろうということで、私の大好きな刺激、変化を与えようということと、あとは、新しい視点があると気づきが増えるかもということです。
チームに変化を加えて得られたこと
やった内容は、チームに変化を加えてみたということで、わりといろいろなことをやっています。ほかのチームのスクラムマスターと交換してみたり、チームのイベントに見学者を招いたり、逆にほかのチームのイベントに参加してみるとか、ふりかえりの手法を変えてみるなどです。これらをやることで、特に新しい視点が入ることで気づきが増えるのがすごく良かったです。
それから、見学者の感想から新たな気づきだったり、ほかのチームの良い案をパクったり、ほかのチームを見ることで自分のチームの良さが再確認できて、チームの結束が深まったことも得られたことだったかなと感じています。
三宅潤也氏（以下、三宅）：これって、（ふだんから）いろいろなチームの人を招いて自分たちを見てもらったり、自分たちもほかのチームを見ているから、期間限定でチームでスクラムマスターを交換してもそれなりに進められるということなんですかね？
小糸：どうですかね。私たちの場合、まったく違うプロダクトではなく複数チームで同じプロダクトを開発していたので、どんなことをやっているかはある程度把握できていたのが、スクラムマスターの交換ができた原因かなと思いますね。
三宅：なるほど。（コメントを見て）Discordでアライさんに書いてもらったんですが、やっていることが近いからこそ、チーム間の交換留学的なことができたんですね。
小糸：そうですね。
関係の質を高めるための取り組み ⑤とりあえずやってみよう
小糸：最後はとりあえずやってみようです。
三宅：もうなんか、タイトルからなにもわからないんですけれど、とりあえずやってみようということで（笑）。
当時のチームの傾向として、あるチームで扱っているプロジェクトがビジネス的にどんどん拡大してきて、今いるチームのメンバーで新しいチームを作らなければいけない時がありました。
開発者はいっぱいいるんですが、「スクラムマスター、どうする？」という時に、適格な人がわかりやすく誰もいなかったり、あとは「誰かやらない？」と声をかけてもぜんぜん手が挙がらないのがチームの傾向でした。
仮説です。「スクラムマスターはなんか大変そう」と思われているんじゃないかということです。実際、自分もちょっと思っていました。
あと、スクラムマスターと大きく括っちゃうと、役割ややることがぼんやりしていて、実際になにをしているか、なにが魅力なのかが周囲に伝わらないんじゃないのかとちょっと思っていました。
では、どうすれば解消するんだろうということです。当時、自分は開発者をメインでやっていたのですが、スクラムマスターにもすごく興味がありました。社内を見渡してもやれそうな人がいない。人が足りない。でもチームを作らなきゃ。誰かがやらなきゃいけないので、「じゃあ、やるしかないか」ととりあえずやってみることにしました。
あと、（僕が）やってみたら、「スクラムマスターはなんか大変そう」ということの解像度がもう少し上がって、やっていることが理解できるんじゃないかと思いました。
ほかの会社でもそうなのかもしれませんが、特に会社では、スクラムマスターとリーダーがニコイチになっていて、開発以外の雑務全部（をやる）みたいなイメージで捉えていたり、なんかすごく大変そうなことをリーダーと一緒にやっていくというような、ボヤボヤっとしたポジションというイメージが当時はありました。
開発者をやりながらスクラムマスターをやって得られたこと
（スライドを示して）ということでやったことです。Dev（開発者）をやりながらスクラムマスターをやってみました。
まず、スクラムマスターをやる上で、タスクを大きく自分の中で分解してみました。1つがチームの成果・幸福度を高めるための活動です。
当時はチームでベロシティを測っていなかったり、そもそも見積りをつけていなかったりで、やれどもやれども終わらない超バカデカバックログみたいなものが何スプリントも続いていたり、なんかちょっと良くない状況になっていました。そういうのを改善するとか、ふりかえりをちょっと盛り上げるためのことを仕込んでみるとかしました。
2つ目はビジネスが成功するための活動です。これが対POのよろず相談や、スケジュールの相談、お金の相談といったところの、対POをちょっと盛り上げるような、サポートするような活動。
3つ目がお金とか契約、手続きに関するところです。例えば、チームで使っているSaaSの契約だったり、あとはパートナーで来てもらっている方たちのいろいろな契約やお金の手続きです。
（スライドを示して）括弧で書いてしまっていますが、私自身は上2つの活動にモチベーションをすごく持てて、やっていてすごく楽しいと思えましたが、3つ目のところは不得意だったり、あまりモチベーションが感じられませんでした。
これはもう単にラッキーなだけというか、環境が恵まれていたんだなと。本当に感謝しているのですが、不得意なタスクを効率的に実行できる上司や、あとは自分がもともと所属していたチームのスクラムマスターだったりが「おお、やりたくないならやってやるよ」と快諾してくれました。
「じゃあその分、君がやりたいスクラムマスターのタスク、本気でやってみなよ」と後押ししてもらえて、Devやりながらスクラムマスターをやってみました。
得られたこととして、スクラムマスター（のこと）は言葉だけでなんとなくわかった気になったりしていましたが、実際になにをやっているのか、ロールの解像度がすごく上がりました。
スクラムマスターをやることで、「なんでビジネスの側、POってこんなこと言っているのかな」「なんでこの期限でこういうお願いをしてくるのかな」「なんでこういう相談するんだろう」という背景や、その人となり、プロジェクトの置かれた状況をより解像度を高く理解できることで、理解度が高まりました。
コードを書く時間自体はちょっと減ってはいたものの、例えばプルリクのレビューを見た時に、「ここまでの品質が本当に必要なのかな」という見極めだったり、みんなで全体のアーキテクチャをレビューしている時に、「このアーキテクチャはこのビジネスの状況と、このお金の状況と、ここまでに出さなきゃいけない」という背景を含めた時に、「本当にこのアーキテクチャは適切なのかな？」と、考える時のヒントがすごく得られたと思います。
あとは、本当なら我々の会社の中のスクラムマスターがやっている仕事なら「お金とか契約の手続き系も全部やれば？」という話ですが、そういったところはちょっと不得意だったり、モチベーションがないところを組織にバックアップしてもらえたことは、環境が恵まれていることを実感できました。
スクラムマスターをメインでやっている小糸さんからしたら、「Devやりながらスクラムマスターはどうなのよ？」みたいなのがあるのかもしれないですが、どうですかね？
小糸：私はたぶんそのロールの切り替えがうまくいかず、自分の中で整理できなくて、どっちかに偏りそうだなと思いながら聞いていました。三宅さんはたぶんバランス良くできるのですごいなと。
三宅：良いフィードバックだけだと、ちょっと不安になっちゃいますね。スクラムの教科書的なところでいうと、たぶん1つに集中してフォーカスしたほうがいいのかなという気もしつつ、自分の中では、Devとスクラムマスターは切り離せない側面があると思っていて。両方やれて良かったなと思っています。
小糸：ということで、ちょうどいい時間帯で。リハよりだいぶ延ばせたな（笑）。
最後にということで、我々KAG、KDDIアジャイル開発センターでは、一緒に働いてくれる仲間を募集中です。
三宅：募集中です。
小糸：「K」DDI 「Ag」ile Development Center、どこの頭文字を取っているんだという感じはしますが、もともとKDDI内部でスクラムを実践していたものを、2022年7月に分社化しました。カジュアル面談もやっているので、興味を持ってもらえた方はぜひ問い合わせしてみてください。
以上で、私たちの発表を終わりにしたいと思います。みなさん、ご清聴いただきありがとうございました。
三宅：ありがとうございました。
