アジャイル開発をするうえで大切なマインドセットを数回の記事に分けて紹介しています。真面目に仕事をしているはずなのに、なぜか上司からチームへの評価が高くない、他のチームに比べて指摘が多いなど、そういったお悩みを解消するお手伝いができたらと思います。

第1回は、「小さく挑戦・小さく試す」でした。
第2回は、「担当領域を明確に分けず、全員で成果を出す」です。

うまくいっていないスクラムチームを見ると、担当領域を綺麗に分けすぎていたり、他者の担当領域に関心を持たない例をよく見ます。例えば、プロダクトバックログ（やることリスト）は、プロダクトオーナーの担当範囲だから、エンジニアが提案を控えるとか、テストはQAの人の仕事だからエンジニアはあまり知らなくても良いといったものです。

そもそも、スクラム開発以前の仕事だと、相手の担当領域に口を出さずに自分の担当領域だけ全うすることが良しとされていた時代もあったと思います。また、他の人の担当領域に口を出すことで、自分もその範囲に対して責任を負わなければならなくなるといった思考の方も見かけます。しかし、担当領域を分割して他者の領域に関与しないといった仕事の仕方は、他者の仕事領域に無関心になってしまうだけではなく往々にして局所最適になりがちです。

ソフトウェア開発の声の大きい担当者が、ソフトウェアの開発しやすさを求めてプロダクトオーナーにできるだけ早く詳細に仕様を決めるように依頼をしたらどうでしょうか。ビジネスの成功といった全体最適にたどりつかず、ソフトウェアの開発しやすさといった局所最適にたどりついてしまいます。本来は、プロダクトオーナーと開発者が一緒になって解決策を考えることで、顧客やビジネスのことを考えている思考と、ソフトウェアの知見が融合することにより良い結果を導き出せるのです。

それに加えて、そもそもスクラム開発の原点となった研究論文では、担当領域を綺麗に分けるのではなく、オーバーラップしてチームが組み合わさることが新製品開発において高い開発パフォーマンスを生むとされています。

単価に合わせて最適化してもいいのでは？

とはいえ、「上流工程は人月単価の高い人がやっているから、工程を分けたほうが効果的だ」といった意見もあるのではないでしょうか。確かに、POをやる方はエンジニアよりも高い単価で働いていたり、エンジニアの方はQAの方よりも高い単価で働いていることが多いのも事実だと思います。

しかし、高い単価で働いている人間が優秀で下流のことをすべて理解しているか？というと、必ずしもそうは言えないのではないでしょうか。アジャイルでは、現場のことは現場で作業をしている人が一番わかっているという前提のもと、現場で手を動かしている人からも意見を出すのが最適化されやすいとされています。

また、Googleで実施されている手法であるデザインスプリントでも、関係者全員で何を作るか考える方法が取られています。これも、それぞれの専門領域の人が集まったほうが良い知見が集まるとされているからです。一度、上流下流や単価などを考えずに、チーム全員で協力する考えにしてみるのはいかがでしょうか。

担当領域を明確に分けないようにし、他の領域へ気を配っていたチームのふりかえりの事例

私が支援したチームで、システムの障害が多かったチームが全員で障害を減らすことに取り組み、障害を大きく減らすことができた事例を紹介します。もともと、そのチームのQAの方は稼働が少なく、エンジニアの方も、POの方も、QAの方も、障害が多いことに慣れ始めてしまっていました。その後、QAの方が別の方に交代になりました。そして3スプリントが経った後のふりかえりでQAの方から「障害が多すぎるのではないか」との問題提起がなされました。すると、慣れ始めていたエンジニアの方も、POの方も一緒になって、自分たちにできることはないか？と真剣に議論が始まったのです。

おそらく担当領域の意識の強いチームであれば、「ここで障害が多いのはQAがカイゼンしないといけないのでは？」とQAの方に人に丸投げしてしまうところだと思います。このチームで更にすごいのはPOも一緒になって、できることはないか？と検討を始めたことでした。担当領域意識の強いPOであれば、ものづくりフェーズの問題でしょと考えてしまいがちです。

そしてアクションとしては、QAの方が主体になって障害分析をするといったものも決まりました。そして、それだけではなく非機能要件で問題が起こっていることも多いことにも課題感がチームにあったようで、プロダクトバックログリファインメント（作りたいものの要件を整理したり見積もりをする時間）でPOが作りたいものをチームに共有したときにどんな障害が考えられるか事前に徹底的に議論するといったアクションが決まりました。結果として、チームは少しのバックログリファインメントの時間を投資することで障害を事前に予測し、非機能要件での問題も激減しました。

まさに、担当領域を明確に分けず、他の領域への関心をもったチームであったからこそ、障害が多いといった問題に対して、それぞれができることを考えて一緒になって対策を出すことができ、障害の激減に繋がりました。

担当領域を明確に分け、他の領域への関心をなくしたチームの末路

私が支援に入る前のチームで、エンジニアがサービスのユーザに対して無関心だったことから、エンジニアの仕事がつまらなくなってしまった例を紹介します。

このチームでは、プロダクトオーナーとその補佐のデザイナーで、ユーザインタビューやユーザテストを実施していました。エンジニアを任意参加にしていたところ、エンジニアの方は1人も参加する人はいませんでした。エンジニアの心理としては、ユーザーインタビューやユーザテストはPOの仕事といった考えがありました。そうすると、当たり前ですが、エンジニアの方々はユーザはどんな人で、何を望んでサービスを利用してくれているのか、どんな使い方をしているのかを全く理解できていませんでした。

その結果、エンジニアから実装したい機能があったときにPOに提案するわけですが、ユーザのことを全く理解していない人から上がった見当外れな意見を採用するわけにもいかず、エンジニアからの意見は、プロダクトバックログ（やることリスト）の下の方に入れられ実装される機会もなくなってしまいました。

すると今度は、エンジニアの気持ちとしては、自分たちの意見は全く取り入れられないといった状況になってしまいます。そうすると、エンジニアからのプロダクトバックログへの意見もどんどん減っていきました。そして最終的には、エンジニアは作業をこなすだけの人のように感じられ、面白みを感じることも少なくなり、離職者が増えてしまいました。

まとめ

• 担当領域を明確に決めると、他の領域への関心が低くなり、チームとしてうまく成果を出せなくなってしまう

• 担当領域を明確に決めずにオーバーラップするように仕事をすることで、新製品を開発がうまくいった研究がある

• 人月換算で高い人が上流みたいに分けるよりも、すべての領域の専門家が集まって対策を考えるほうが質が高くなる傾向にある

• 担当領域を明確に分けずに、全員で成果を出すマインドがあれば、チームで全体最適が生まれやすい