チーム間コミュニケーションにおける「ただ話す」のすすめ

この記事は SmartHR Advent Calendar 2023 2nd の12日目の記事です。

こんにちは、SmartHRでプロダクトエンジニアをしているytakaです。
この記事では、チーム間のコミュニケーションにおける、シンプルかつ強力な手法をご紹介します。

それが「ただ話す」です。

ただ話す

「ただ話す」は、チームの輪読会で読んだ『大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法』にて紹介されていたメソッドです。本書には以下のように記載されています。

大規模なグループで何年も働き、複数チームにまたがる調整テクニックを数多く観察した結果、最も上手くいきそうなテクニックを発見しました。手順は次の通りです。

(1) あなたは、チームBとの”調整が必要”なことに気づきます。
(2) 立ち上がって、
(3) チームBのところに歩いていき、
(4) 「やぁ!、話し合おうよ!」と言います。

この一連を私たちは”ただ話す”とよんでいます。

引用元: 『大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法』（丸善出版、2019; p. 260-261）

「…ったく、そんなこと言われなくたって、話すくらいやってるっつーの🤷‍♂️」

そう思われた方もいるかもしれません。僕は思いました。

しかし、実際に複数チームでの開発を進める中で、このシンプルな調整方法がいかに強力かを実感することができました。
この記事では、実際にチームで「ただ話す」を実践してみた気付きを紹介します。

チームの状況について

まずはチームの状況について説明します。

私が所属するのは「配置シミュレーション」というプロダクトを開発するチームです。

配置シミュレーションは、人員配置や異動をシミュレーションすることのできるプロダクトです。SmartHR上に蓄積された情報を参照しながらシミュレーションができ、シミュレーションした結果はSmartHRのデータベースに反映することもできます。詳しくは以下のサービスサイトをご覧ください。

smarthr.jp

このプロダクトは2023年2月にリリースされ、リリース後、開発メンバーが継続的に増えています。特に2023年10月には、もともと他のプロダクトを開発していたチームが合流し、現在は2チーム体制で開発を進めています。

複数チーム化の功罪

もともとは1チームスクラムの体制で開発をしていましたが、チームメンバーの増加にあたり、 Large-Scale Scrum（LeSS）というフレームワークを利用して、2チーム体制で開発を進めることにしました。
LeSSは「大規模スクラム」とも呼ばれ、単一チーム開発におけるスクラムの強みを複数チームにも拡大・適用するためのフレームワークです。
LeSSの採用の決め手は、もともとスクラムによる開発を行っていたこと、弊社でもLeSSの実践例があることでした。

チームメンバーが増えることによる弊害として情報量やコミュニケーションコストの増加が懸念されます。
LeSSでは全員参加のスクラムイベントは全体の一部で、日々の開発はチームに裁量を持たせ、やり取りの多くをチーム内にとどめることで、これに対処することができます。
チーム間のコミュニケーションが必要な場合は、全員参加のスクラムイベントを利用するか、もしくは何かしらの手段でコミュニケーションをとります（チーム間の日々のコミュニケーションの仕方については、LeSSでは特に定義されていません）。

スクラムイベントとしてチーム間のコミュニケーションの機会が定義されていることには、以下のようなメリット/デメリットがあると感じています。

メリット
- いつ・どのような話を共有すればよいかわかるので、コミュニケーションの負担が少ない
- 基本的にメンバー全員が集まるので、情報の伝達漏れが少ない
デメリット
- 定義されていない場でのコミュニケーションのハードルがあがる
- スクラムイベントのタイミングを待つことにより、情報の伝達が遅れる場合がある

総じてメリットの方が強いと感じていますが、デメリットも無視できません。複数チームで単一プロダクトを開発するとなると、コードのコンフリクトの解消や仕様の調整のために、気軽に・早くコミュニケーションをとりたい場合もあります。

そんなときに役に立つのが、「ただ話す」です。

「ただ話す」の実践

書籍で紹介されていた「ただ話す」の手順を、もう一度見てみましょう。

(1) あなたは、チームBとの”調整が必要”なことに気づきます。
(2) 立ち上がって、
(3) チームBのところに歩いていき、
(4) 「やぁ!、話し合おうよ!」と言います。

私たちのチームはフルリモートで開発をしており、コミュニケーションにはSlackやZoomを利用しているため、書籍で紹介されているように隣のチームに歩いて話しに行くことはできません（ぎりぎり、立ち上がることまではできそうです）。代わりに、Slackで相手チームのチャンネルにコメントしに行ったり、短時間のオンラインMTGを実施することで会話をしています。

以下、具体例です。

例1
- 🤔うちのチームで開発してた機能がそろそろリリースできそう！そういえば、隣のチームも開発している機能もそろそろリリースだったよな…
- 💡リリースの手順の調整や、マージ時のコンフリクトの解消が必要かもしれない
- 🏃‍♂️よし、隣のチームに話しに行こう！
例2
- 🤔うちのチームにアサインされたこのタスク、仕様にわからない点があるな...
- 💡確か隣のチームに詳しい人がいた気がするな
- 🏃‍♂️よし、隣のチームに話しに行こう！

どちらもありふれたコミュニケーションではありますが、ポイントは「ただ話す」ことが有用な調整方法だと共通認識を持つことで💡 → 🏃‍♂️への行動のハードルが下がり、素早く調整ができることです。もしこの認識がないと、「相手チームの時間を奪ってしまうかな…」とか、「自チームだけで解決できないか考えてみよ…」のような思考になる場合があります。しかし、多くの場面では素早くコミュニケーションをとることで問題が早期に解決し、結果としてチーム全体の利益につながると実感しています。

また例1、例2共にゆくゆくは仕組みで解決したい問題ではありますが、仕組み化には時間がかかります。話すことで解決しそうな問題はまずはそれで解決して、ツラみが溜まってきたタイミングで仕組みを作るようにすることで、アジリティを保って開発を進めることができると考えています。

このおかげもあってか、チーム合流後も大きなコンフリクトやコミュニケーションのずれもなく、いいペースで新機能をリリースすることができています 🚀

「ただ話す」のハードルを下げる

「ただ話す」を引き出しやすくするために、チームで意識的/無意識的にしていることを紹介します。

Working Out Loud（WOL）の習慣
- WOLについては以下の記事に詳しく書かれているので、ご覧ください
- https://blog.studysapuri.jp/entry/2018/11/14/working-out-loud
- SmartHRではWOLの習慣が根付いているチームが多く、日ごろから何をしているかを発信する文化があります
- これによりリモートであっても相手チームの状況がわかりやすく、話しかけに行きやすい状態ができています
絵文字による文化の浸透
- 輪読会で「ただ話す」が紹介された際に、チームメンバーの一人がすぐに次のようなSlackのカスタム絵文字を作成してくれました
- 「ただ話す」の絵文字
- 話せばすぐに解決できそう！というものについては、この絵文字でリアクションすることで行動を促しやすくなり、「ただ話す」が文化として定着するのに一役買ってくれています
話してくれてありがとうの気持ち
- 話しかけられた側のチームも、話してくれたことに感謝する態度で迎えます
- チームでの褒めや感謝の文化については、以下の記事でも紹介しているのでご覧ください
- https://tech.smarthr.jp/entry/2023/10/03/133216