スクラムチーム（Scrum Team）は、プロダクトオーナー（PO）とスクラムマスター（Scrum Master）がそれぞれ1名ずつと、数名の開発者（Developers）からなる小さなチームです。
Scrum.org のスクラムガイドによると、スクラムチームについて次のように書かれています。
スクラムの基本単位は、スクラムチームという⼩さなチームである。
https://www.scrum.org/resources/scrum-guide
スクラムチームは、スクラムマスター1 ⼈、プロダクトオーナー1 ⼈、複数⼈の開発者で構成される。
これは、⼀度にひとつの⽬的（プロダクトゴール）に集中している専⾨家が集まった単位である。
はじめてスクラムをやってみるときには、まずここが難しいですよね。
目次
プロダクトオーナーはひとりだけ（複数人は NG）
プロダクトオーナー（PO）は、スクラムチームがこれから何を作るか？という目的＝プロダクトゴールを決める責任があります。そのためには、これから作ろうとしているソフトウェアにとって、いったい何が重要で、逆にその他は重要ではないのだということを、しっかりと自分で決められなければなりません。いわゆる「全てが優先度 高 です」というような、決められない PO では務まりません。本当に１番が最優先で、２番・３番は、１番のものより優先しないのだという、ちゃんとした優先度を決める必要があります。
そのためにはユーザーや役員など、様々なステークホルダーの意見を十分にヒアリングして、必要なコミュニケーションを行って、何を作るか？何が完成していてほしいか？を意見を取りまとめます。そこまでを PO が終わらせていて、そのうえで代表者としてチームの開発者に伝える。これができる人が PO でなければなりません。
複数人の、例えば「○○作成委員会」の状態では PO としての責任が果たせないんですね。それを代表する一人を立てる必要があります。
「アジャイルがうまくいかない」というよりも、「なかなか優先度が決められない」そのために開発が遅れているような組織では、ひとりの PO を任命することが難しかったりします。逆に、スクラムを始めようとするときには、まず PO がやらなければならないことをしっかり説明したうえで、引き受けてくれる人を探すことが重要と思います。
掛け持ちでは目的に集中できない（開発者も PO も）
スクラムチームは、ひとつの目的（プロダクトゴール）に集中していることが重要です。集中しているか？というと考えるのが難しいですが、逆に「ひとつの目的に集中していない状態」を考えると、例えば複数の全然異なるプロダクトゴールを目的にするような、複数のスクラムチームの開発者を兼務している状態は、集中できていないと言えそうです。
一方、昔ながらのウォーターフォールでは、社内に複数の開発プロジェクトがあって、その複数のプロジェクトに掛け持ちで、例えばインフラエンジニアとして、とか、テスト担当者として、というようなごく限られた役割で参加するということが、よくあったように思います。そういう人員配置はしないよ、ということです。スクラムでは掛け持ちではなく、ひとつのプロジェクトに 100% 専任で参加するというのが基本になります。そう聞くと、はじめてスクラムをやろうとした場合には、たいてい「それはおかしい」というような反応が返ってきます。しかし、そこでウォーターフォールの慣習のまま兼務でチームに入ってもらってはうまくいきません。
これはプロダクトオーナー（PO）についても同じです。例えば PO が、もっと他に重要なプロジェクトに時間を取らなければならないからと言って、スクラムチームの開発者と必要なタイミングで全然コミュニケーションを取ってくれないというのでは、やっぱりうまくいきません。逆に、PO がこのソフトウェアを作成するのを最優先のミッションとして時間をとって動ける場合には、ぐっとスクラムがうまくいく可能性が高くなると思います。スクラムがはじまるまでに、PO の予定を先にブロックしてしまうぐらいのイメージで進めましょう。
スクラムチームはプロダクトゴールに集中する専門家
そもそもチームメンバー全員に目的（プロダクトゴール）が共有されていないということも、集中できていない状態と言えます。
プロダクトオーナー（PO）が折角プロダクトゴールを考えていても、それが全くスクラムチームの開発者に共有されず、全員がぼんやりとバラバラなプロダクトゴールを想像しながら開発をしていては、それぞれ全く違うものを作ろうとしてしまう。それでは非常にロスが多くなってしまいます。しっかりと PO と開発者はコミュニケーションをとって、またプロダクトゴールを明確な文章に起こすなど明確に共有して、いつでも見えるようにしておいて、そのゴールにチーム全員が集中できるようにする必要があります。
また「専門家」という点では、PO がチームにプロダクトゴールを示し、開発者が同じゴールに向かって開発を行うことで、スクラムチーム全体が徐々にプロダクトゴールを達成できる専門家集団になっていく、という側面も重要と思います。プロダクトゴールに関する、いわゆるビジネス的な側面は、スクラムが始まったばかりの頃はまだプロダクトゴールを考えた PO にしかわかっていないということが多くあるかもしれません。また開発者は、ソフトウェア開発を行うために必要な技術は持っていても、それらのビジネス的な背景や価値を最初はイメージできずに、最初のうちは PO と沢山会話をしなければうまくいかないかもしれません。しかし、スプリントを繰り返すたびに、それらはだんだんと共有されて全員が同じものをイメージできるようになっていきます。次第にスクラムチーム全員が、そのチームのプロダクトゴールを達成することが出来る専門家集団という風になっていきます。
もちろん、そのためにも開発者は自分達が開発するソフトウェアに必要となる技術をもっていること、あるいは多少わからなくてもすぐにキャッチアップして使えるようになる力があることが求められます。全員が全てのスキルを持っている必要はありませんし、誰しも得意な領域とそうでない領域があるはずです。それでも、チームの誰かはスキルを持っている必要があります。誰もどうやって開発していいのか？全くわからないようなものは、さすがにスクラムにしたからといって開発できるようになったりはしません。
もしかしたら、大規模なウォーターフォールの開発では、スキルが足りない人が何人か体制に含まれていても、お客様やステークホルダーには秘密にしたまま、何とかごまかせていたかもしれません。しかし、少人数のスクラムチームでは、できない人はできないことが見える化されて、ハッキリとわかってしまいます。それが困るのであれば、ちゃんとスキルがある人でチームを構成しなければなりませんし、逆にスキルが不足している人員で開発をしなければならないことが確定している場合には、それがこのチームの実力であることをお客様やステークホルダーにもわかってもらったうえで、少しずつ開発をしていくしかないのだと思います。どちらにしても、チームにはプロダクトゴールを達成するための専門家になってもらうしかないのです。
スクラムチームは全員が Azure DevOps を使用する
Azure DevOps を使って開発を行う場合は、スクラムチームのメンバーは全員が Azure DevOps を扱えるようにします。
プロダクトオーナー（PO）は、自分でプロダクトゴールを示すために Azure DevOps に入力する必要があります。開発者はプロダクトゴールを確認するほかに、開発のためにずっと Azure DevOps を使います。
スクラムマスターは、スクラムチームがうまくスクラムをできていれば Azure DevOps を直接操作しなくてもいいかもしれません。しかし、実際にはなかなかそういう状況にはならないと思います。最初に使って見せたり、設定やクエリ・チャートを変えてより良い使い方を示したり、あるいは開発者が適切に Azure DevOps を使えているか？確認したりします。いろんな場面で Azure DevOps を使う場面があると思います。
しかしもし、スクラムマスターがスプリントごとに Azure DevOps でやらなければならない事があるとしたら、それはスクラムマスターの役割を誤解しているかもしれません。スクラムマスターはあくまで補助で、POと開発者がメインで Azure DevOps を使います。
コメント
