スクラムマスター時代に共創に向けて実践していたこと

リテールアプリ共創部マッハチームの西田です。

今回は部の理念でもある「共創」をテーマに自分が実際に行ったことを紹介させていただきます

最初に

筆者は現在エンジニアとして働いていますが、スクラムマスターとして活動していた時期にやっていたことを、いい機会なので整理しておきたいと思い、このブログを書き始めました

スクラムマスター時代はお客様と「共創」関係を作るのに、ずっと試行錯誤してたように思います。うまくいったりいかなかったりでしたが、その中でやってたことを紹介します

うまくいったと感じたこと

• チームメンバーとお客様のゴールを合わせる
• 全員が自主的に動ける環境づくり
• 感謝を伝える

うまくいかなかったと感じたこと

• 1度話しただけでは100%は通じない
• 場が整えても勝手には機能しない

チームメンバーとお客様のゴールを合わせる

プロジェクトが進むとどうしても自分の領域にフォーカスしてしまい、プロジェクトの本来の目的を見失いがちです

例えば、そのプロジェクトの本来の目的からそれた内容でも期日を間に合わせるために、妥協点を探したり、ソースコードの保守性を保つために、プロジェクトの目的からみて、理にかなったような機能でも容易に実現できなかったりすることがありました

これらは、それぞれの領域での判断基準のブレが原因の1つで、お客様がプロジェクトで達成したいことをチーム全体で共通の認識とすることで、より近い価値基準でプロジェクトを進行できる可能性があります

また、同じゴールを共有していると、お客様はコンテキストの高い会話で新しい機能についての説明を行うことができ、チームメンバーからも的を射た提案がしやすくなります

また、お客様のプロジェクトのゴールを知ることで、自分たちが行う仕事の延長線にある提供するべき価値を認識しながら、日々の業務に取り組むことができます

チームメンバーとお客様のゴールを合わせるために、具体的には以下のような取り組みをしました

• ビジネス上のKPIの共有いただく
• お客様のドメイン領域の理解を深める
• プロジェクトについて考える時間を増やす

ビジネス上のKPIの共有いただく

お客様がそのプロジェクトで達成したいKPIがある場合は、共有いただく場を設けたりしていました。

KPIを共有してもらうことで、今のプロジェクトの状態（うまくいってる、うまくいってない）、課題、外部からの評価などをメンバーは知ることができます。

プロジェクトの状態を知ることで、プロジェクトが抱えてる課題に対する解像度が上がり、プロジェクトのゴールへの理解度が深まります

(個人的な感覚ですが、エンジニアは課題感を知ると解決したくなる性分の人が多いように感じますので、その点でもメリットがありました)

ただ、機能開発とビジネス上のKPIに効果が現れるまでは、タイムラグがあり、ビジネス的なKPIをそのまま評価につながることは難しかったです。しかし、主要な目的はカンバンのボード上のPBIとビジネス的な目的を紐づけることで、共通のゴール認識を持ち、タスクに対しての意義を高めることにありました

お客様のドメイン領域の理解を深める

お客様のドメイン領域の解像度を上げることで、日々のタスクとプロジェクトのゴールとのつながりをよりイメージしやすくなります。

また、お客様には開発者にも意見を求めてる方が多く、ドメイン領域について知って上での意見を話すために、どうしてもドメインの知識は必要です

筆者の経験上、自社のドメイン領域について話したいお客様は多く、説明をいただいたりしました。また、可能であれば、現場に赴き、実際に働いてるところを見せてもらってたりしました

プロジェクトについて考える時間を増やす

これは個人的な習慣なのですが、プロジェクトについて考える時間を明示的に増やすことを行ってました。1日15分などと決めて、お客様のドメイン領域や、プロジェクトについて考える時間を明示的に設ける取り組みをしていました

特に物量を意識し、考える時間を増やすようにしていました。質よりも量で、考える時間が多ければ多いほど、自信を持って色々提案できるようになっていったと思います

自主的に動ける環境づくり

チームメンバー全員が自主的に動ける環境づくりを意識していました

プロジェクトを自分ごとのように考えることができれば、責任が生まれ、モチベーションが向上したり挑戦したい気持ちが起こることが期待できます

また、自分の判断でタスクを進めれると、自分ごとのように考えられ、そのタスクに対し、責任が持てるようになります

具体的に以下の取り組みをしていました

• 自己効力感を意識する
• 定期的に短い 1on1
• 心理的安全を高める
• 話し出すハードルを下げる

自己効力感を意識する

自己効力感とは「自分なら遂行できる」と、自分の能力を信じれる感覚のをことを言います。自己効力感があると、仕事を自分のことのように感じられ、視座が上がったり、自ら行動しようと思うモチベーションが高くなります

それに、個人的な感覚ですが、後から振り返った時に、どんなに大変でも、自己効力感高く仕事をしていた場合は満足感が高いことが多いです

自己効力感を高めるためには、「自分の力」が寄与し、物事を成功に導いたという体験が必要です。そのためには、自分で考え、自分で決定し、自分の影響力が及ぶと思える範囲を増やしてもらうことが有効と考えます

そのために段階的なアドバイスを意識して行っていました。ほとんど全てやってもらい、それがうまくいかなそうなら、リマインドし、それでも難しそうなら、細かな指示をします。それでうまくいくようになっていったら、その逆順を辿るようなことをしていました

定期的に短い 1on1

プロジェクトによっては、定期的に短い 1on1 を設けていました。人によって 1on1 に必要な時間はまちまちだったので、個別に15分ずつとかを設けずに、1時間枠くらいをあらかじめとっておいて、短い人は2,3分くらいで終わり、必要な人は30分ほど話すみたいな感じで柔軟にしていました

定期的に1on1する大きな目的はハートビートで困りごとがないかを聞くのが最大の目的でありながら、こういう場でしか話してもらえないことがあったり、自分では出てこないようなアイディアをもらえることも多かったです

心理的安全を高める

自主的に動く環境づくりには、心理的安全を高める配慮も必要でした。失敗が怖くなると自主的に動きづらく、どうしても他人の指示を待ちたくなります

健全に失敗してもよい空気作り、失敗してもチーム全体の課題として取り上げて、振り返りなどで全員で解決策を出すようにしていました

また、失敗を個人の責任にしないことを繰り返し、ことある毎に説明していました。ただ、この考え方を心の底から思ってもらうのはかなり難しかったように思えます

そのため、自分が失敗した時も必要以上に謝らない、引きずらない（ように見えるよう）を意識してました

話し出すハードルを下げる

会議になると話し出せない人が一定数います。特に、コロナ禍以降にオンラインミーティングが増えてから、この傾向は顕著になっている気がします

話の流れを止めてまで発言するのは、勇気が必要です。ただ、いろんな観点の意見を出すことはとても大事で、本人は大したことない、自信がないと思っているようなことでも、役に立つことは多々ありました

具体的には以下のようなことをしていました

• その会議が発散の場なのか、決めの場なのかを事前に伝え、何を期待してるかを事前に明確にしておきました。事前に思いつきでもいいのでたくさんの意見が欲しいのか、決めの場なので、懸念を言って欲しいのかを明確することで、その場に沿った発言をしやすくすることを意識していました
• Slack（チャットツール）で自由に発言してもらうスレッドを立てて、思いついたことをメモ程度でも良いので書いてもら、間が空いたところでスレッドを見返します。こうしておくと、場の流れを止めずにいろんな意見を出してもらうことができました

感謝を伝える

日々、自分が役に立っているという実感は重要です。自己効力感にもつながります。ただ、なかなか機会がないと、感謝は伝えにくいこともあります。そのため、感謝を明示的に伝える時間を取ることもありました。

時間をとってみると、単純に感謝されることが嬉しいということもあったり、意外なことが感謝されたりして、気づきがあったりしました

また、言われる側も嬉しいですが、自分がなぜ相手の行動に感謝したのか、その行動のどういう点に感謝したくなったのか、など、相手の行動をリアルに想像することで、相手への理解が生まれ、尊敬が生まれやすくする効果もありました

1度話しただけでは100%は通じない

ここからはうまくいかなかったなということを紹介していきます

自分は、スクラムマスターをする前は、基本的に1度話せば大体のことは伝わると考えてました。しかし、スクラムマスターという立場で、メンバー全員に意図を理解してもらうまで説明する難しさを知りました

基本的に人は人の話を100%理解するのは難しいです。なぜなら、多くの場合、人は人の話を聞くときに、曖昧な部分を、自分の記憶で補完しながら理解するからです

そうすると、聞く人毎によって受け取り方に違いが出てしまい、伝わり方が異なってしまいます

なので、どうしても伝えたいことは、角度や観点を変えて何度も説明します。感覚的には自分にとってこのくらいなら伝わるという感覚では足りないことが多く、くどいかな？と思うくらいでちょうど良かったことが多かったように思えます

場を整えても勝手には機能しない

仕組みを整えても勝手には機能しないことが多かったです。特に自発的に始まったことでなく、自分が発信元でチームに周知させていくのが難しかったです

人はなかなか自分の納得しないこと、必要性の感じないことを習慣的にやってもらうようになるのはかなり難しかったです

どうしてもやってもらう必要があることは、場を整えるだけでなく、定期的なリマインドや、やる意義の説明を 1on1 で行ったりしていました

最後に

自分がスクラムマスター時代に自分が実際にやってみたこと、失敗して得た気づきを紹介させていただきました

振り返ってみると、地道で当たり前なことをすることの難しさをずっと感じていたように思えます

この記事が誰か役に立てば幸いです