スクラムってコミュニケーションコストが高い？に答えてみる
昨日に引き続き今日もスクラムのお話を。スクラムはコミュニケーションコストが高いって話がよく出るので、私（マネージャー）の視点でよくある話に回答してみる。今日も網羅はできないが、思いつく範囲でまとめてみる。（昨日の記事も貼っておく。）
前提
スクラム導入前は各メンバーにマネージャーがまとまった作業を依頼していた
スクラム導入前はぼんやりチームと呼ぶものは存在していたが、いわゆる個人商店と呼ばれる状態で、メンバー間の関係性はかなり疎な状態だった
全チームでスクラム導入している訳ではない
スタートアップ。フルタイムの開発メンバーが30人くらい
スクラムってコミュニケーションコスト高いの？
結論から言えば、コミュニケーションコストが高いのではないと思っている。弊社の場合では、主に３つのケースが見られる。
単純増のコミュニケーションコストのケース（ただし、本来必要だがやっていなかっただけ）
別のコストの皺寄せの結果コミュニケーションが発生しているケース
必要以上に人を集めている結果、合意形成に時間がかかっているか、もしくは必要でない人まで集めているケース
単純増のコミュニケーションコストのケース
スプリントレトロスペクティブのコミュニケーションコスト
スプリントごとに「ふりかえり」をするスプリントレトロスペクティブ。
スクラムやその他のアジャイル開発を実践している方は当たり前に実施するものだ。
しかし、世の中的には「ふりかえり」は当たり前では無い。当たり前に行なわなれるべきであるが、当たり前に行なわれていない。ということで、もともと「ふりかえり」の習慣がない人からすると、単純増なのだ。なぜふりかえりが当たり前に行なわれないか一例を挙げて少し考察してみる。
そもそも個人商店で開発している人たちにとっては、自分自身のことをふりかえるのは、意味を感じられにくい。彼らにとってこのふりかえりは自分の成功談や失敗談を単に人に語るだけになる。他の人は具体的に何が起こっているかわからないため、クリティカルな問題解決方法は自分の中にしかなく、話すだけ無駄だ。つまり、コミュニケーションコストが高くなる。個人商店で開発している、あるいはプロダクトバックログアイテムを個人に割り当てている環境では、「ふりかえり」は健全に行なわれにくい。これが私が見てきたよくある一例だ。
他にもふりかえりが当たり前に行なわれない理由はあるが、ここでは取り上げない。
対策としては、「透明性」を高めること。透明性を高めることだけが、ふりかえりにおける検査と適応の価値を生み出すと考えている。
透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。
デイリースクラムのコミュニケーションコスト
弊社ではあまり挙がったことはないが、こちらもよく聞く。
デイリースクラムに意味を感じていないために、単純に増えたこの時間に無意味に感じてしまうのだと思う。
デイリースクラムの価値は毎日の検査・適応である。これをできていないデイリースクラムに陥るスクラムは多いのではないかと思う。毎日の検査・適応を正しく実施できていない例をいくつか挙げてみる。
特定の誰か（マネージャー・スクラムマスター・PO）への報告の場になっている
プロダクトバックログアイテム単位、もしくは、1日以上の作業量のタスクにしか分割できていない
トラックナンバー1になっているスキル・技術が多い
「昨日やったこと」「今日やること」「困っていること」の三拍子を話すだけで終わっている。
デイリースクラムは開発チームのためのものであることを十分に理解する必要がある。対策手段は色々あるので割愛する。
計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである
別のコストの皺寄せの結果コミュニケーションが発生しているケース
スプリントプランニングのコミュニケーションコスト
スプリントプランニングはプロダクトバックログアイテムをスプリントバックログに落とし込んでいく作業をする。当たり前に必要な作業である。コミュニケーションコストが高いと言う人はプランニングの作業をどうしていたのか。例を挙げてみる。
そもそも開発着手前にタスクを検討しない。開発が進んだ際に都度都度タスクを検討していた
事前にタスクを検討するが個人で決める
マネージャーがプロダクトバックログアイテム、もしくは大きな粒度で人にアサインする
主には誰かに依存していたプランニングの作業をチームで行うことになる。つまりここに皺寄せが発生している。
これらのケースの多くの場合、タスクに分割する作業が暗黙知になっている。そのため、個人観点ではプランニングに価値を感じられにくい。一方で組織観点だと、その人の思考を他の人が知ることができるため、暗黙知を共有することができる。SECIモデルでいうところの「共同化」のプロセスに移行できる。
繰り返しになるが、前述のように個人レベルではあまり価値が感じられないために、プランニングはコミュニケーションコストが高いという人が多いのである。
必要以上に人を集めている結果、合意形成に時間がかかっているか、もしくは必要でない人まで集めているケース
必要以上に人を集めている結果、合意形成に時間がかかっている
弊社では大体どんなチームでも一度はここに陥っていた。
チームで活動しているから、チームで合意形成を取らなければいけない、と考えている場合が多いのだ。
しかし、多くの場合、必要以上に集めている。議論をできる知見を持っている人・決定する判断基準を持っている人、この2点に着目して人を集めるべきである。条件はANDでもORでも良いが、この2点を備えていない人を集めると厄介なことになる。
あるいは、判断基準を持っている人がいない場合にも合意形成に時間がかかる。このような場合は対策が難しいが、おすすめとしては「メンター」をコンポーネント単位で決めておくことだ。その人の判断基準を参考にしながら進めていくと良い。（※アジャイルプラクティスガイドブック、コンポーネントメンター参照）
必要でない人まで集めているケース
前項同様、弊社では大体どんなチームでも一度はここに陥っていた。
多くの場合、必要で無い人を集めると、意見が出ないだけでその人の時間を無駄に使ってしまう可能性が高い。具体的にいうと、バックエンドの議論にフロントエンドのメンバーを呼ぶようなケースだ。
ただ、バックエンドの議論にバックエンドのメンバーの全員が必要かでさえ、一度考えたほうが良い。
妙に気を使って関係するメンバー全員を集めたがるケースは本当によく見かける。議論を集約し、素早く進めるためには、メンバーを絞る勇気も必要だ。
まとめ
コミュニケーションコストが高いという人はとても多いと思う。そのような人は大体局所最適を考えている人で全体最適を考えていないか、あるいは、局所最適の集まりが全体最適だと勘違いしているかのどちらかだ。
コミュニケーションコストが高い、という人には、暗黙知を形式知にするプロセスや検査・適応をイテレーティブに繰り返していくプロセスの重要性を伝えていくべきである。
この記事が気に入ったらサポートをしてみませんか？