チームとチームを繋ぐDoD（完成の定義）
はじめに
これは、「[いちばんやさし,いきいき]+いくおの Advent Calendar 2021」二十二日目の記事だ。
今日は水曜、テーマは目標や計画について。ある程度の規模の成果を生み出すには、複数のチームでの協働が必要となる。そのときに計画の進行を阻む「認識の齟齬」。これを乗り越えるためにできることについて考えてみた。
育ってきた環境が違うから
認識の齟齬。それは同じチームであっても発生するものだ。特にチームが出来上がったばかりの頃はちょっとしたことでもズレが起こる。これは「育ってきた環境が違う」からだ。たとえば「○○を実装する」というタスク。これはどういう状態になったら達成しているといえるだろうか。
コーディングした本人が「終わった」と思ったら
テストが通ったら
カバレッジXX％のテストが通ったら
プルリクが通ったら
mainにmergeされたら
本番環境にデプロイされたら
ざっと思いつくだけでもこれくらいある。ここの認識がズレていると、周囲はデプロイ可能なものが出来上がったことを期待しているのにテストさえ通っていない状態だ…ということが容易におこりうる。
その認識の齟齬を埋めるのに有効なのがDoD、完成の定義だ。スクラムには欠かせないものだが、スクラム以外でも有用だと私は考えている。
チームが違えば文化も違う
さて、チームをまたいで協働するときには、チーム内で閉じて開発を進めているとき以上に認識の齟齬が起こりやすい。ここでは、AチームとBチームで協働し、Bチームが動き出すにはAチームの成果物が必要だ、という仮定で説明したい。
よくあるのが、Aチームとしてはここまでやったら完成だ、という定義をしているがBチームにとってはまだ完成とみなせないという状態だ。
これも結局は「DoDの認識が揃っていない」ということなのだが、異なるチーム間で認識を揃えることはチーム内でDoDを揃えるよりも少し難易度が高い。
これは、チームというものが専門性やコンテクストで切り分けられていることに由来する。チーム内であれば揃っている前提条件が、チームをまたぐと成立しなくなるのだ。
「私たちのチームでは○○を達成したら完成だと考えています」と、AチームからBチームに伝えたとする。BチームとしてはAチームの業務をよくわからないがゆえに、「なるほどわかりました」と一旦は受けてしまう。が、実際にAチームの成果物を扱おうとすると、何かが足りない、となってしまう。認識の齟齬と、それに起因する不整合の発生である。
後続タスクが「開始できるか」でDoDを検証する
「Aチームの成果物の完成条件」という、普段考えていないことをレビューしろといわれても正しく行うことはできない。じゃあ、どのようにしてAチームの成果物が十分なものであるかを事前に定義できるのか。
それは、言葉にすると当たり前だが「後続タスクBが開始できるか」を確認することで定義可能となる。DoR、Definition of Readyの確認だ。
チームAが作ったDoDと、チームBが作ったDoRを突き合わせる。そこに過不足があれば調整する。そうすることで「後続タスクが開始できるDoD」を設定できる。
チームをまたぐならローコンテクストコミュニケーションを充実させる
このようにDoDやDoRを言語化していくプロセスは、ともすると煩雑に感じるかもしれない。普段ハイコンテクストにチーム内コミュニケーションを成立させているならなおのことだ。
しかし、異なるチームは異なるコンテクストを、カルチャーを持っているものだ。あなたのチームが成長し、スペシャルなチームになっていくほど独自のコンテクストが生まれていく。
チームの「当たり前」を俯瞰し、ローコンテクストコミュニケーションに落とし込む。この姿勢がいきいきと心地のよい協働を生み出していくのだ。
この記事が気に入ったらサポートをしてみませんか？