クロスファンクショナルチームになるための壁崩しのお作法

こんにちは、asatoです。

スクラムチームはクロスファンクショナルです。一方で、クロスファンクショナルになることが難しいと感じているチームも多いと思います。コミュニケーションやプロセスで、職能間に壁を感じているチームも多いのではないでしょうか。

僕はと言えば、幸運なことに何度か、そのようなチームの中にある壁が崩れていき、チームがクロスファンクショナルなプロダクト開発の一歩を踏み出すシーンに出会うことができました。取り組みの一部は、スライドやブログでも公開しています。

このブログでは、これらのチームから感じた「壁の崩し方」について話したいと思います。

「壁」とは

「壁」というメタファーを使っていますが、壁は以下の特徴を持ちます。

自分の仕事を相手から隠す
自分の仕事に相手を干渉させない
相手の仕事を自分の責任と関心の外にする

悪いことばかりではなく、壁によって同一職能内で効率的かつ心理的安全性を保った仕事ができます。一方で、プロダクト開発全体を見たときに、効果性や効率性が悪くなりやすいです。例えば、上で紹介したスライドやブログでは、以下のような効果的な事例を紹介しています。

プロダクトオーナーやデザイナー、QAエンジニアが協力して受入基準を特定することで、機能適合性が向上した
ソフトウェアエンジニアとQAエンジニアが協力してユニットテストコードを書くことでテストコードの質が向上した

こういったより効果的な世界を目指して、僕たちは壁を崩そうと躍起になるわけですね。

壁崩しのアンチパターン

というわけで「壁、崩そうぜ！」の話をするのですが、その前によくない壁崩しの話をしたいと思います。

侵攻

まず、侵攻です。相手に求められてもいないのに壁を壊し、相手の領域に入ることです。例えば、以下のようなことです。

エンジニアも企画から関わらせろ！
私たちソフトウェアエンジニアもテストケースレビューをしてやろう！
私たちQAエンジニアがユニットテストの品質を見てやろう！

そのプラクティスが間違っているわけではありません。関係性のない中で相手の領域に足を踏み込むことや、自分の領域は守った状態であることがアンチパターンです。

砲撃

相手の領域のことをよく知らずに自分の領域から攻撃をしかけます。例えば、以下のようなことです。

もっと簡単に開発できないの？
もっと早くプロダクトのコンセプトまとめられないの？
なんでこの不具合見落としたの？次はどうするの？
デザイナーのレビュー遅くないですか？

チームの課題を自分事として捉えず、自分とは無関係の他者の課題と捉える姿勢ではクロスファンクショナルを目指すのは難しくなります。

放棄

自分の専門領域を他者に委ねる行為です。

〇〇さんが言ってるから、それでいいか
「一緒にやりましょう」と声をかけて、自分は決めない

このアンチパターンで一番怖いのは「みんなで決める」です。以前ブログに書きましたが、「みんなで決める」を全てに適用することで、意思決定を鈍化させたり小さな変化しか起こせなくなることがあります。

スクラムだからみんなで決める？ | at-blog

壁崩しの御作法

こんなことを考えていくと、壁崩しには以下のような御作法があるのではないかということに気づきました。

まず、自分の仕事や専門領域について公開する
次に、相手の仕事や専門領域について知る
最後に、協働できる領域を見つけ合い、実験し、共有領域を増やしていく

このステップを念頭に、僕がいたチームで役立ったプラクティスを紹介します。

職能ごとのタスクチケットからストーリーチケットへ

僕が関わった多くのチームでは、プロダクトバックログアイテムとして職能ごとのタスクチケットが管理されていました。タスクチケットは、その職能の人から見ると何をするかが明確で扱いやすいです。一方で、一つのストーリーを完成させるために、他の人たちが何をするのかを不透明にしてしまう側面があります。逆も然りで、相手からも自分の仕事を隠しています。これでは協働のしようがありません。

ストーリーチケット、つまり一つのユーザーの目標を一単位とし、完成のために複数の職能のタスクを必要とするチケットを使うことで、それぞれが何をするのかを話す機会を増やせます。自分の仕事は終わっているがチケットが完了しないときに、「このチケットを終わらせるために自分でもできることはないか」「自分に何ができればこのチケットをより速く完成できるか」を考えるきっかけになります。結果、自然と協働に目が向きやすくなります。

もちろんストーリー単位のチケットにしただけでは効果が薄く、フロー効率やスウォーミングのようなマインドセットの認識を揃えることも重要でした。

自分の仕事の透明性をあげる

あなたの仕事の透明性は高いですか？

実は、上で紹介したチームでは、僕がチームに入った当初、テストで何が行われているのかQAエンジニア以外のメンバーからは完全にブラックボックスでした。テストのタスクのチケットがプロダクトバックログにあり、QAエンジニアはそれが完了したと伝えるだけでした。この状態で、誰かと協力することは難しいでしょう。

まずは、自分の仕事の透明性をあげましょう。このチームでは、QAエンジニアが作っていたテストケース書をプロダクトバックログアイテムからリンクさせるようにしました。QAエンジニアの仕事が見えるようになっただけですが、関係性はよくなりました。相談し合うことが増え、テストケースが実装にも役立つことがわかり、実装前にテスト観点やケースを共有したことで、PBIのサイクルタイムの改善も実現されました。

途中経過の透明性をあげていくスタンスも大事です。Working out loudの精神ですね。ふにゃふにゃな仕事を公開することで、ここに壁はないというマインドセットを耕せますし、可逆な段階でフィードバックを得られます。

もちろん最初は怖かったり面倒に感じられると思いますが、慣れれば仕事がやりやすくなるはずです。

雑な勉強会

キャリアが違うと思っている以上に当たり前が違います。雑な勉強会を開くことで、自分の領域の景色をチームメンバーに紹介できます。逆もまた然りです。

勉強会というと身構えてしまう人が多いので、雑にすることが大事です。ハードルを下げに下げ多くのチームメンバーに参加してもらい、自分の領域の話をしてもらうことが肝要です。

僕が好んでやっていたのは、「昨日読んで面白かったブログやスライドの共有」です。界隈だと「カラオケ」って呼ばれてるみたいですね。毎日10分、その日立候補したメンバーに共有してもらっていました。純粋にナレッジシェアにもなりますし、異なる職能のメンバーからはその人がどんなことを気にする仕事をしているのかを感じることができます。

他にも登壇動画の視聴、LT会、輪読会、などなどありますね。

「自分にとって当たり前のことでも、誰かにとっては当たり前じゃない」ということを伝えることで、共有してくれることが増えたように思えます。誰かの役に立つことを強調することが続けるコツのようです。

お前ら付き合っちゃえよー

コラボレーションのチャンスは自分たちではわかりにくいことがあります。周りからそのチャンスを提案してみるのは有効なプラクティスだと思っています。「ここは○○と○○が協力したら、もっとうまくいくなんてことないですかね？」みたいなやつです。

これをするためには、アンチパターンに陥ることなく、自分の仕事を公開し、相手のことを理解している必要があります。ただ、こういう対話も理解につながりますので、積極的にやっていただけるといいかと思います。

スクラムマスターは、特にこういう行動を取りやすい立ち位置にいるように感じています。プロダクト開発のEnd-to-Endに目を向けて、それぞれの専門性に関心と尊敬を持ち、常に何かをよりよくしたいというマインドがコラボレーションのチャンスを見つけてくれるような気がします。見つけたときは、ぜひ一度場に提示してみましょう。（僕も頑張らないとなぁ…）

まとめ

いくつかのチームで職能間の壁が崩れたな、と思う場面に出会えたので、アンチパターンやグッドプラクティスについてまとめてみました。もちろん各チームでコンテキストは異なりますので、何が効くかはお楽しみですね。壁崩しのアンチパターンに陥っていないかは、割と再現性あるのかもなーとか思ってます。

さて、目の前のチームに向き合うかー。

気に入っていただけたら、
サポートもお待ちしております！