はじめに
私は新卒であるプロジェクトに入ってから、スクラムチームで開発を進める中で、少し不思議に感じることがありました。
同じチームで開発しているはずなのに、実装が終わった後に別の人の確認待ちが発生することがありました。
また、最後のレビューで専門的な観点の指摘が入り、思っていたよりも大きな手戻りが発生することもありました。
例えば、以下のような状態です。
- 実装が終わった後に、デザインレビュー待ちでチケットが止まる
- マーケティング部の確認が終わるまで、次の作業に進めない
- 仕様を考える人と実装する人が分かれている
- フロントエンド、バックエンド、デザインのように関心ごとが分断されている
- 「これは自分たちでは判断できないので、専門家に確認する」という場面が多い
もちろん、デザイナーやセキュリティ担当者など、専門家の力を借りること自体はとても大事です。
私自身も、専門家の方に確認していただくことで、自分だけでは気づけなかった観点を知ることができました。
しかし、毎回確認待ちが発生したり、最後に大きな手戻りが起きたりする状態を見て、「これは本当にチームとして開発できているのだろうか？」ともやもやするようになりました。
私は、スクラムチームは「価値を届けるためのチーム」であり、サブチームや階層は存在しないものだと思っています。
スクラムガイド2020でも、スクラムチームについて、以下のように記載されています。
スクラムチーム内 には、サブチームや階層は存在しない
スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキル を備えている。また、⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチーム内で決定する
スクラムチーム全体が、スプリントごとに価値のある有⽤なインクリメントを作成する責任を持つ
一方で、現実のプロジェクトでは、チームの中にさらに小さなチームができてしまうことがあります。
例えば、デザイン担当のチームや、マーケティング担当のチームなどです。
この記事では、私が感じた 「スクラムチームの中に別チームができてしまうこと」へのもやもやを分析した結果をまとめ、これからのアクションを検討したいと思います。
拙い文章ではありますが、最後まで読んでいただけると幸いです。
スクラムチームの中に別チームができるとは
まず、「スクラムチームの中に別チームができる」とはどういう状態なのかを整理します。
私が考える「別チームができている状態」とは、同じスクラムチームに所属しているにもかかわらず、実態としては作業や責任が分断されている状態です。
例えば、以下のような流れです。
- 「仕様を考える別部隊」が仕様を考える
- 「アーキテクト集団」が設計する
- 「エンジニア集団」が実装する
- 「デザイナー集団」が確認する
- 「マーケティング部門」が確認する
- 指摘があれば実装に戻る
この流れ自体が必ずしも悪いわけではありません。
しかし、各工程が分断されていて、前の工程が終わるまで次の人が関わらない状態になると、少しずつ問題が出てくると思います。
特に、デザインやマーケティングのような観点は、最後に確認すればよいものではなく、できれば早い段階から考慮した方がよいものです。
にもかかわらず、最後のレビュー段階ではじめてそれらの観点が入ると、次のようなことが起きます。
- 実装後に大きな手戻りが発生する
- 専門家の確認待ちで作業が止まる
- チーム内に知識が蓄積されない
- 「これは専門家が見るもの」という意識になる
- プロダクト全体への責任が分断される
今思うと、この状態はスクラムというよりも、小さなウォーターフォールに近いのではないかと思います。
役割分担は悪いことなのか
ここで注意したいのは、役割分担そのものが悪いと考えていたわけではないということです。
例えば、デザインが得意な人、セキュリティに詳しい人、フロントエンドが得意な人、バックエンドが得意な人がいることは自然です。
むしろ、それぞれの専門性を活かすことで、プロダクトの品質は上がると思います。
スクラムガイド2020 においても、以下のように記載されています。
スクラムはスクラムチームにおいて、開発者、プロダクトオーナー、スクラムマスター という 3 つの明確な責任を定義する。
開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。
スクラムガイドの「責任」については、下記の記事がより分かりやすく説明されていると思うのでぜひご覧ください。
私が問題だと感じたのは、専門性を活かすことではありません。
問題なのは、専門性を活かすことと、責任を分断することが混ざってしまうこと です。
例えば、デザイナーに相談することは良いことです。
しかし、実装がほとんど終わった後にデザイナーへ確認を依頼し、大きな導線変更が必要になると、手戻りが大きくなります。
マーケティング担当者に相談することも良いことです。
しかし、チーム内でユーザーへの見せ方や訴求についてまったく考えず、最後にマーケティング部門へ丸投げする状態になると、チームとしては学習しづらくなります。
つまり、問題は「専門家に相談すること」ではありません。
問題は、専門家の観点がチームの外に置かれたままになっていること だと思います。
外部の専門家に頼る場合を整理する
組織の構造などの問題で、デザイナーやマーケティング担当者のような専門家が、常にスクラムチームの中にいるとは限りません。
複数のチームを横断して支援している場合も多いと思います。
そのため、スクラムチーム外部の専門家に頼ること自体は有効な選択肢です。
ただし、どのような場合に外部の専門家に頼るべきかを整理しておいた方がよいと思います。
私は、外部の専門家に頼る形でよいのは、以下のような場合だと考えています。
- その専門知識がたまにしか必要ない
- レビューだけで大きな問題が起きない
- 相談するタイミングが明確になっている
- 確認待ちがスプリントに大きく影響しない
- チーム内でもある程度の論点整理ができる
例えば、年に数回しか発生しないような特殊な確認であれば、外部の専門家に相談する形でよいと思います。
また、デザインやマーケティングの大きな方針はすでに決まっていて、細かい確認だけをお願いする場合も、外部レビューで十分かもしれません。
一方で、毎スプリントのように相談が必要になっていたり、専門家の確認がないと実装方針を決められなかったりする場合は、少し注意が必要です。
その状態は、もはや「外部から支援してもらっている」というより、「チームに必要な能力がチームの外にある」状態だと思います。
チーム内にスキルを持つことを考える
ここまでの内容を踏まえると、必要なスキルを持った人材が１つのチームにいることは理想的です。
毎回同じ専門家に確認を依頼し、そのたびに待ち時間や手戻りが発生しているのであれば、チーム内にそのスキルを持つことを考えた方がよいと思います。
ただし、ここでいう「チーム内にスキルを持つ」は、必ずしも専任の専門家をチームに追加することだけを意味していません。
もちろん、デザイナーやセキュリティ担当者がチームに入れるのであれば、それは強い選択肢です。
しかし、現実的にはすべてのチームにすべての専門家を配置することは難しいと思います。
そのため、まずは以下のような状態を目指すのがよいのではないかと考えています。
- 専門家に相談する前に、チーム内で論点を整理できる
- よくある指摘をチーム内で共有している
- 過去のレビュー内容をチェックリスト化している
- 設計の早い段階で専門家の観点を取り入れる
- 同じ指摘を何度も受けないようにする
例えば、デザインレビューで毎回同じような導線の指摘を受けるのであれば、実装前にチームで確認する観点として持っておくことができます。
マーケティング観点で毎回同じような指摘を受けるのであれば、リリース前の確認項目としてチーム内に残しておくことができます。
このように、外部の専門家からのアウトプットを受け取るだけではなく、知識を吸収し、専門家の知識を少しずつチーム内に取り込んでいくことが大事だと思います。
待ち時間が発生することはチーム改善のサインかもしれない
ここまで考えてみると、「専門家の確認待ちで作業が止まる」という現象は、単なるスケジュール調整の問題ではない気もしています。
もちろん、専門家の方も忙しいので、すぐに確認してもらえないことはあります。
しかし、毎回同じように確認待ちが発生しているのであれば、それは個人の問題ではなく、チーム設計の問題かもしれないと思っています。
例えば、以下のような状態です。
- 専門家の確認がないと作業を進められない
- レビューが後工程になっている
- レビュー後に大きな手戻りが発生する
- チーム内で判断できる範囲が狭い
- 専門家の知識がチームに蓄積されていない
このような状態であれば、単にレビューを早めるだけでは根本的な解決にならないと思います。
むしろ、「その専門性はチーム内に必要なのではないか」「もっと早い段階で相談すべきではないか」「チームで学習できる仕組みが必要ではないか」と考える必要がありそうです。
これからどう向き合うのか
以上のように、「スクラムチームの中に別チームができてしまうこと」へのもやもやについて、いろいろな観点から問題を分析してきました。
この分析結果から、このような問題に直面した際に、まず以下のようなことを整理すると良いと思いました。
- どこで待ち時間が発生しているのか
- どこで手戻りが発生しているのか
- どの専門性が頻繁に必要になっているのか
- チーム内で判断できることは何か
- 専門家に相談すべきことは何か
- 過去の指摘をチームの知識として残せているか
特に、「待ち時間」と「手戻り」は見える化しやすいので、これから実践していきたいと思います。
例えば、以下のようなことです。
- あるチケットが実装完了してから、デザインレビュー待ちで何日止まっていたのか
- マーケティング確認後に、どのくらい文言や導線を変更したのか
- 同じような指摘が何回発生しているのか
- その指摘を、次回以降のチェックリストに反映できているか
感覚として「なんとなく止まっている気がする」で終わらせるのではなく、待ち時間や手戻りを見える化することで、チームで議論しやすくなるのではないかと思っています。
まとめ
この記事では、「スクラムチームの中に別チームができてしまうこと」へのもやもや を分析し、私なりに次に何をするべきかを検討した結果をまとめてみました。
専門家の力を借りることはとても大事です。
ただし、専門家の観点がチームの外に置かれたままだと、待ち時間や手戻りが発生しやすくなります。
スクラムチームは、単に作業を分担するためのグループではなく、価値を届けるためのチームだと思います。
そのため、価値を届けるために頻繁に必要になる能力は、少しずつでもチーム内に取り込んでいくことが重要なのではないでしょうか。
私自身まだまだ勉強中ですが、今後もチームで価値を届けるために、どのようなチーム設計がよいのか考えていきたいと思います💪