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