プラクティス名 （別名）
ただ話す （ただ叫ぶ）
プラクティスの目的・狙い
- フロー効率の低下を予防する
どんな時に使うか
- 他チームと調整すべき課題が発生した時
- この件についてどの場で相談しようかあれこれ迷ってしまう時
実施手順
- 立ち上がる
- 相手先のチームがいる場所へ歩いて行く
- 「やぁ、ちょっといいかな？」と声をかける
これだけだとプラクティスの意図が伝わらないと思いますので、趣旨を明確にするためにいくつか質問したいと思います。これまで複数チームが関わる開発で以下のようなことはありませんでしたか？
- 他チームとどこで調整するか悩む（チャット？メール？どの会議？課題表？・・・）
- 次回の定例会で相談するから、それまで今行っている作業の手を止める
- 自チーム側の仕様がきちんと確定してから声をかけようと後回しにする
- 向こうは向こうできっと進めてくれているだろう、と期待して声をかけないでいる
このような状況に心当たりがある場合はこのプラクティスを試してみるべきかもしれません。相手が他チームとなるとつい正式な問合せルートで・・・と考えがちですが、ただ単純に話しに行った方が早いということが少なくありません。
アレンジ例
- 他チームとの調整だけでなく、自チーム内の調整（例えばPO確認など）にも適用できます
- 複数チームが同じ部屋でプランニングを行っているシーン等で「誰か〇〇について詳しい人いない？」と他チームに大声で呼びかけてその場で会話を始める（＝「ただ話す」の応用版で「ただ叫ぶ」というプラクティスだそうです）
アンチパターン
- 「チーム間の課題は管理表に起票するルールです！」とか「定例会議に持ち込んで下さい！」と「ただ話す」ことを禁止する（→起票が必要なら事後すればよいだけの話）
参考情報
書籍
LeSS公式サイト（「Just Talk」参照）
こぼれ話（私的コメント）
チーム間のコミュニケーションを比較した結果、「より正式な調整方法の環境が整っている方が、調整しようという動きが少なくなる」というパターンが見つかったそうです。円滑なコミュニケーションを図るためのルールが、逆に会話を減らしてしまうというなんとも皮肉な結果ですね。
このプラクティスはアジャイル宣言にある「プロセスやツールよりも個人と対話を」という原則を別の形で言い表したものとも言えそうです。またこのプラクティスの最大の発明は、当たり前の概念を「ただ話す」という秀逸なネーミングでプラクティスとして再定義したところ。プラクティス化することで単に「大切だから意識しよう」というスローガンにならずに、具体的に取り得るアクションとして認識できるようになります。