ワーキングアグリーメントで価値観の相互理解を深めよう(#29)

ワーキングアグリーメントとは

今回は、チームのメンバーでお互いの価値観を共有する際に使える「ワーキングアグリーメント」という手法を紹介します。

ワーキングアグリーメントとは、チームのパフォーマンスを上げるためのチームのルールを明文化したものです。
例えば、「作成した成果物は翌日までにレビューしてもらう」「会議に遅刻しない」などのルールを決めることで、日々の業務を円滑にします。

このルール決めは、メンバー全員で話し合って決めることが推奨されます。
それぞれのメンバーが「自分が当たり前にやっていることを皆もやって欲しい」「このようにやってもらった方がやりやすい」など、相手に暗黙的に期待していることを、皆で共有してルールとして決めることで、スムーズにコミュニケーションをとれるようにします。
また、各メンバーがどのような価値観や期待を持っているのかが共有されるので、お互いの理解を深める効果もあります。

チームが発足して間もない時期で、まだチームのルールが整備されていない時などには特に効果的です。

チーム状況に合わせてアレンジ

筆者のチームでは、定期的に改善を検討する会議があり、そこでワーキングアグリーメントを決めることが提案されました。
ただ、筆者のチームは、毎年の新人の配属や既存メンバーの異動でメンバーの入れ替えはあるものの、チーム自体は発足してから何年か経過しており、チームのやり方はそれなりに整備されていました。
ワーキングアグリーメントという位置づけではありませんでしたが、チームが発足して間もない時期に皆でチームのやり方やルールを決めてあり、その後も定期的に改善していました。
今回は、「それでもやってみたい」という皆の意見に乗ってやることにしました。

また、ワーキングアグリーメントの決め方については、細かい「チームのルール」を定義するよりも「どんなマインドを持って取り組むか」を中心に議論したいとメンバーから提案されました。
皆が参考にしていたワーキングアグリーメントの紹介ページには「ルール」と一緒に「マインド」という項目があり、どんなマインドを持って取り組むかの例が書いてありました。
今回はルールよりもそのマインドを議論したいということでした。

その提案を聞いた時、「ルールを定義しないと実施効果が半減するのでは」と思いました。
しかし、結果的には提案のとおりやることにしました。
よく考えれば、筆者のチームは前述のとおりチームのやり方を定期的に皆で改善しており、大まかなルールは定義されていると言えます。
そのため、明文化していない日々の細かいルールを定義するよりも、「どんなマインドを持って取り組むか」を議論した方が、各メンバーの価値観が共有でき、お互いの理解を深める効果が高いと思いました。

また、ITエンジニアのような創造性の高い職種の場合、チームの細かいルールをすべて明文化することが必ずしも良いとは限りません。
ルールを明文化すると、それを厳格に守る雰囲気となって柔軟な対応をしづらくなったり、ルールを守ることに負担に感じたり、創造的な思考を妨げたり、ルールに依存して自主性が低下したりなどの恐れがあります(もちろん、そうならない適切なルールもあります)。
ワーキングアグリーメントの関連記事の中には、ルールを守らなかった場合に軽い罰を与えるという事例もありましたが、これはリスクがあります。
全員が軽い罰を楽しめるほどの強い信頼関係のあるチームなら良いですが、そうでないと罰が不満やストレスになったり、罰を受けないようにリスクを避けることに意識が向いて消極的な行動が増えてしまったりする懸念があります。

このような経緯で「どんなマインドを持って取り組むか」を議論することになりましたが、それならば、マネージャーの自分は参加しない方が良いかもしれないと思って、マネージャー不参加で開発メンバーのみでやってもらうことにしました。
筆者は 1 on 1 などで最近加入したメンバー含めて全員の価値観をある程度、理解しています。
また、筆者の価値観は記事に書いて公開しているため、メンバーから理解されています。
しかし、メンバー同士の価値観の相互理解は、そこまでできていない可能性がありました。
従って、筆者が不参加の方が、お互いの価値観を知らない者同士で議論することになり、相互理解を深めるのに効率が良いと判断しました。

ファシリテーターは、新卒入社2年目の若手メンバーにやってもらいました。
ファシリテーターを若手がやると、他メンバーがなんとかうまくいくように協力的な姿勢で積極的に発言する傾向があるので、皆に意見をたくさん出してほしい時はあえて若手にお願いすることがあります。

進行方法の詳細はファシリテーターに任せました。
その結果、最初の20分間でオンラインのツール上で各自が付箋に自分の考えを書いてから、残りの40分間でその付箋をグルーピングしながら皆で議論していくという方式になりました。

実施した結果

筆者のチームで決まったワーキングアグリーメントの一部を紹介します。

＜コミュニケーション＞

- 悪い報告ほど早めにしよう
- 良い会議になるかは自分次第
- 「自分が一番発言してやるぜ」の心意気で！
- Slackの連絡には必ずスタンプで反応しよう
- リアクションは大事にしよう
- ポジティブフィードバックや賞賛コメントを積極的に口にしよう
- 他メンバーの分報にスタンプだけでもいいので、毎日コミュニケーションをとろう

＜エンジニアリング＞

- クラス、メソッド、プロパティの名前は、意識して付けよう
- 分報に進捗や考えをこまめに書こう
- チーム全員がリーダーシップをもって行動しよう
- 「知りながら害をなすな」の精神で
- AIや便利なツールはどんどん取り入れていこう

出てきた意見のいくつかは「ルール」にする方が良さそうなものもあります。
ただ、それらをあえて「ルール」とはせずに、「そういうマインドで取り組みましょう」というゆるい共有くらいが、今のチームには合っていると思いました。
これまでの連載で紹介してきたように、筆者のチームは各自が主体性を発揮して楽しく開発することを重視しています。
そのため、ルールで強制するよりも、チームのメンバーがこうありたいと思っていることに共感して、主体的に行動を変えてもらうことに期待した方が良いように感じたからです。

この後、行動が劇的に変わったかというと、そこまで大きな変化はありませんでした。
ただ、前よりもリアクションの頻度が増えたり、分報の投稿が増えたりなど、少しだけメンバーに行動の変化がありました。
そういう些細な変化は、ルールによる強制ではなく、他のメンバーの価値観に共感し⾃分から行動を変えた結果だと思います。
また、メンバーそれぞれが大事にしている価値観の相互理解もできたので、お互いの理解を深めるという意味でも良かったと思います。

まとめ

今回は、筆者のチームの状況に合わせてアレンジしたワーキングアグリーメントの決め方を紹介しました。
もし、筆者のチームが発足したばかりのチームであれば、アレンジせずにチームのルールを決めるやり方をしたと思います。
プラクティスは、そのチームに合わせたやり方で実施するのが良いと思うので、皆さんも自分のチームに合ったやり方で実施してみてください。

この記事の初出は、Software Design 2024年8月号です。

---

連載「ハピネスチームビルディング」の次回の記事はこちら↓

前回の記事はこちら↓