Scrum チームの役割と責任 - 最も効果的な Scrum チームを構築する方法

By Kate Eby | 2016年8月25日

生産性の高い Scrum チームの重要な構成要素の 1 つは、スキルのバランス、性格のバランス、責任のバランス、仕事のバランス、力のバランスです。何十もの要因が、社内に Scrum を導入し、パフォーマンスの高い Scrum チームを一から構築することに入りますが、バランスとは、すべてを浸透させる品質です。

バランスのとれたアプローチは、多くのビジネス分野で、特に製品開発を成功させるには非常に重要です。しかし、Scrum がどこに適用されるにしても、チーム メンバー間で強みと個人的な特徴のバランスのとれた集団を持つことは、実績のあるチーム モデルです。重要な特徴を認識し、バランスのとれたチームを構築し、維持する方法を知ることは、Scrum チームの候補者の採用を担当する際に特に重要です。この記事では、Scrum チームを構築する際に十分な情報に基づいた意思決定を行う必要がある詳細について説明します。チーム開発に関するアドバイスを提供し、チーム ビルディングの活動に関する提案を提供し、特定の役割と責任に適した候補者の種類を説明します。

協調スクラム チームワーク

アジャイル マネジメントの最も人気のあるフレームワークである Scrum の基礎は、1986 年にハーバード・ビジネス・レビューの記事で始まりました。記事では、竹内と野中が「スクラム」という言葉を紹介し、ラグビー チームがポイントを獲得するために使用するチーム ワーク戦略を強調し、製品開発チームが成功率を向上させるために同様の方法を使用できることを示唆しました。

この記事で発表された調査によると、小規模で自己組織化されたチームは、チームが目標を与えられたが、それらの目標を自分で達成する方法を決定できた場合、複雑な製品に対するパフォーマンスが大幅に向上しました。

ケン・シュワーバーとジェフ・サザーランドは、Scrum のフレームワークを開発し、1990 年代に Scrum チーム メンバーの役割を正式に定式化しました。1995 年に「SCRUM ソフトウェア開発プロセス」と題する論文を出版しました。徐々に Scrum に他の機能強化を加え、追加の論文を出版した後、シュヴァーバーとサザーランドは 2010 年に Scrum ガイドの最初の出版を完了しました。

Scrum ガイドは、Scrum とそのチームの役割を「人々が複雑な適応型問題に対処し、可能な限り高い価値を持つ製品を生産的かつ創造的に提供するフレームワーク」と言及しています。...Scrum フレームワークは、Scrum チームとそれに関連する役割、イベント、アーティファクト、ルールで構成されています。

チームの役割に関する Scrum ガイドの説明では、「スクラム チームは製品所有者、開発チーム、スクラム マスターで構成されています。Scrum チームは自己組織化と部門横断型です。自己組織化するチームは、チーム外の他のメンバーから指示されるのではなく、自分の仕事を達成するための最善の方法を選択します。部門を超えたチームは、チームに参加していない他のチームに依存せずに、仕事を達成するために必要なすべての能力を持っています。Scrum のチームモデルは、柔軟性、創造性、生産性を最適化するように設計されています。Scrum Teams は、製品を反復的かつ段階的に提供し、フィードバックの機会を最大化します。

2016 年 7 月、シュヴァーバーとサザーランドは Scrum ガイドの最新版をリリースしました。2016 年版に追加された最も注目すべきコンテンツは、スクラム チームのメンバーが互いに、また他の会社の人員とどのようにやり取りすべきかについての詳細を含む Scrum Values セクションです。

Project Management Guide

Your one-stop shop for everything project management

the 101 guide to project management

Ready to get more out of your project management efforts? Visit our comprehensive project management guide for tips, best practices, and free resources to manage your work more effectively.

View the guide

Scrum チームサイズの推奨事項

最も一貫性のある Scrum チームを達成し、グループ内のチームワークのレベルを最大限に高めるために、専門家は多くの場合、チームの規模に関するアドバイスを提供します。彼の組織 Scrum.org を通じてスクラムトレーニングを提供している Scrum は、2007 年の著書「The Enterprise and Scrum」でチーム規模の推奨事項を提供しています。シュヴァーバーは、Scrum チームは「コミュニケーションの速度、コンテンツ、精度、帯域幅を最大限に高めるためには、規模を制限する必要がある」と説明しています。チームの規模は最大 9 人です。

著書の後半で、シュヴァーバーは次のアドバイスを提供しています。「チームの規模を可能な限り7に近づけるようにします。7 人のマインドは、システムの共通のメンタルモデルを達成し、維持でき、ドキュメントなどの人工援助なしで設計とコードで表現できるようです。誤解や記録時間は最小限に抑えられます。

名声健康のプロジェクト マネージャーであるミンディ・シュナーゼは、スクラム アライアンスの CSM (認定スクラムマスター) 認定と PMI (プロジェク トマネジメント協会) の PMP (プロジェクト マネジメント プロフェッショナル) 認定を取得しています。シュナーセの前の雇用主であるインターナショナル ゲーム テクノロジー (IGT) では、品質保証エンジニアのリーダーとして働いた後、スクラム マスターの役割に移行しました。Schnase の経験は、さまざまな規模の Scrum チームでの作業に関わってきました。

Schnase 氏は、1 チームあたり 7 ~ 9 人は優れた管理しやすい規模であると助言していますが、チーム規模はプロジェクトの詳細の影響を受けているとも説明しています。「プロジェクトのスコープによって大きく異なります。私はいくつかのチームの Scrum マスターでした。1 人には 3 人のメンバーがいたが、他のメンバーは 7 人から 10 人でした。」

彼の組織 Scrum Inc., を通じてスクラム コースを教え続けるサザーランドは、チームの規模と生産性に関する次の分析を含む、組織のウェブサイトにチームのダイナミクスに関する多くの情報を含んでいます。

「ソフトウェア開発の伝説の人物であるローレンス・プットナムは、物事の所要時間と理由を研究する彼の人生の仕事になりました。彼の仕事は、20 人以上のプロジェクトが 5 人以下のプロジェクトよりも多くの労力を使っていることを示し続けました。少しだけでなく、たくさん。...そこで彼は、何百もの異なる企業で 491 件の中規模プロジェクトを見ていました。これらはすべて、古いバージョンの用途ではなく、新製品や機能の作成を必要とするプロジェクトでした。彼はプロジェクトをチーム規模で割り、すぐに何かに気づきました。チームが 8 チームを超えて成長すると、物事を成し遂げるのに劇的に時間がかかりました。3 ~ 7 人で構成されるグループは、同じ量の作業を行うために、9 ~ 20 人のグループの労力の約 25% を必要としました。

専門家からは、7 人のチーム メンバーが魔法の番号であるようです。しかし、特定のプロジェクトに基づいてメンバーの量を調整することを恐れてはいけません。

ワークフローとスクラム イベントで Scrum チームの効果を高める

 

Kanban board

アジャイル プロジェクト管理の一環として Scrum に従う決定を下すと、あらゆる形と規模のチームが特定のワークフローに参加します。スクラム イベントは、特にチーム メンバー間で定期的なコミュニケーションを促し、スクラムで定義されていない追加の会議の必要性を最小限に抑えるという貴重な目的に役立ちます。

Scrum イベントをスケジュールに組み込まないと、チームは効果的でも集中することもできません。以下のリストは、Scrum チーム メンバーが製品開発に使用する一般的なワークフローを表しています。

製品ビジョン – 製品所有者は、エンド ユーザー、顧客、チーム メンバー、その他の関係者など、さまざまな情報源からの意見を受け取った後、製品ビジョンをステートメントにまとめます。製品ビジョン ステートメントには、製品目標や製品が会社の戦略にどのように適合しているかに関するビジネス ケースの詳細が含まれています。

製品バックログとリファインメント – 製品バックログ項目は、プロジェクトに個別に提供できるすべてを表します。これらの項目のほとんどは、製品機能やユーザー ストーリーと同様に、顧客に価値を提供することに重点を置いています。(ユーザー ストーリーには、ユーザーが新しい機能で何を達成するかを説明する、具体的で詳細なシナリオが表示されます。)製品バックログには、市場要件、仕様、ユースケース、その他の項目も含まれます。

製品所有者は、各項目が表すビジネス価値に応じて、製品バックログ項目に優先順位を付けます。一般的に、製品の価値の 80% は機能の 20% です。製品バックログ項目に優先順位を付けるためにビジネス価値を割り当てることで、最も価値の高い機能が最初に構築されます。製品バックログの上部にある項目は明確に定義されており、今後の Sprint に含まれます。その他の項目は、製品バックログ リファインメント ミーティング中に改良する必要があります。

製品所有者と開発チームの中には、現在の Sprint の中間または終わり近くで製品バックログ リファインメント ミーティングを開催し、将来の Sprint 用の製品バックログ項目をさらに改良するチームもあります。他の Scrum チームは、洗練を継続的なプロセスとして扱っています。

効果的なスプリントの実行: チームが効果的なスプリントを実行できるように、次の 2 つのステップが完了します。Sprint (固定長イテレーションとも呼ばれる) とは、チームが次のイテレーションを再検討して準備する前に 1 回の作業イテレーションを完了する期間であり、アジャイル プロジェクト管理の主要な構成要素です。

 

  • スプリント計画 – 製品所有者、Scrum マスター、開発チームがスプリント計画セッション中にミーティングを行い、今後の Sprint の製品バックログ項目を選択し、目標にコミットします。開発チームのメンバーは、Sprint の期間を埋めるのに十分な作業ができるまで、製品バックログの上部にある項目を選択します。選択した項目がスプリント バックログに移動します。
  • スプリント バックログと Scrum ボード – スプリント バックログ内のすべての項目を Sprint の終わりまでに完了する必要があります。共通の責任感を確保するために、項目は物理的またはデジタルの Scrum ボード (タスクボード) 上の「To Do」、「進行中の作業 (WIP)」、および「完了」というラベルの付いた列の 1 つに配置されます。Scrum ボードはチーム全体に表示され、関連する項目 (多くの場合、タスクやユーザー ストーリーとして付箋に書かれる) は Sprint のステータスをリアルタイムで反映する必要があります。このガイドラインに従えば、特定の項目がスケジュールに遅れている場合にチームは調整を行うことができます。


スプリント – スプリントは 1 ~ 4 週間続きます。各スプリントは、短い開発サイクルを表し、製品増分 (正式には出荷可能な製品増分として知られている) または最終製品のいずれかになります。チームは、特に最初は出荷可能な製品増分を必ずしも完了できるとは限りません。しかし、これはチームが時間の経過とともに改善するために努力すべきことです。

デイリー スクラム – 各スプリントでは、開発チーム メンバーがデイリー スクラムとして知られる毎日のスタンドアップ ミーティングに参加します。会議の最大時間は 15 分で、参加者は次の 3 つの基本的な質問に対する回答のみを共有するためです。1) 前回の会議以降に達成したことは?、2) 次回の会議の前に何を行いますか?、3) どのような障害が発生していますか?

この会議の目的は、開発チームが取り組みを調整し、作業を同期させ、障害 (技術上の問題、部門の障害など) を報告する機会を与えることです。これは、従業員がマネージャーに進捗報告を行う会議ではありません。Scrum マスターは、解決が必要な障害を見つけるために参加するかもしれませんが、製品所有者は通常参加しません。

スクラム・オブ・スクラムミーティングScrum アライアンスのウェブサイトで Scrum インストラクターのマイク・コーン氏の注目のステートメントは、スクラム・オブ・スクラム会議を「スクラムを大規模なプロジェクト チームに拡張する上で重要なテクニック」と表現しています。これらのミーティングでは、チームのクラスターが、特に重複と統合の領域に焦点を当てて、自分の仕事について話し合うことができます。7 つのチームと 7 人のチーム メンバーで構成される完全にバランスのとれたプロジェクトを想像してみてください。7 つのチームはそれぞれ、毎日のスクラム ミーティングを (同時または連続して) 実施します。その後、各チームはスクラム・オブ・スクラム ミーティングに参加する 1 人を指名しました。

シュナーゼが促進したスクラム・オブ・スクラム ミーティングでは、スクラム マスター、製品所有者、技術リーダー、一部の QA マネージャー、プログラム スポンサー、スクラム チームが取り組んでいるプロジェクトに直結した部門マネージャーが参加しました。「1 週間おきに、スクラムのスクラムを使って、成果、マイルストーン、進捗、依存関係、障害について話し合います。」とシュナーセは言います。

スプリント レビュー – 各 Sprint の終了時に、チームはスプリント レビュー (イテレーショ ンレビューまたはスプリント デモとも呼ばれます) を実施し、スプリント中に作成された製品機能を関係者、製品の結果から直接影響を受ける個人に示します。スプリント レビューやスプリント デモは、ソフトウェアを使用し、すぐにフィードバックを提供できる人に製品をデモする貴重な機会でもあります。

スプリントのふりかえり – スプリント レビューの後、Scrum チームはレトロスペクティブ ミーティングに参加し、スプリントの成功と欠点について話し合い、改善計画を立てます。振り返りのもう 1 つの目的は、Scrum チームが使用するプロセスと実践をさらに発展させ、次の Sprint に対してより効果的にすることです。

また、チームは製品の品質を向上させる方法を見つけ、必要に応じて完了の定義に従って項目を変更します。Scrum Inc. の「Scrum の基本」では、「バックログ内の項目が独立し、実行可能で、ポイント値が割り当てられ、それが行われたことを意味する基準を明確に定義していれば、準備が整います。」という定義が定義されています。「これは、納品時にアイテムに何が期待されるかを全員が正確に把握できる完了の定義と呼ばれます。」

Scrum チーム開発モデル

効果的な Scrum チームを構築するには、チーム メンバーがうまく仕事をするために、全員が情熱とプロセスに対する前向きな態度を持つことが重要だとシュナーセは言います。いくつかの Scrum リソースは、スクラム チームを構築したり、チームに新しい人を追加したりする際に従う効果的な方法として、ブルース・タックマンのグループ開発モデルを言及しています。1965 年に心理学会誌に掲載された「小グループの発達的シーケンス」というタックマンの記事では、新しいチームは高性能レベルに到達し、最適な結果を出す前にさまざまな段階を経る必要があると述べています。タックマンは、これらの段階を「フォーミング、ストーミング、ノーミング、パフォーマンス」とラベル付けしました。

タックマンのグループ開発モデル内の各ステージの名前は、その期間中のチームのダイナミクスを正確に反映しています。

フォーミング - タックマンはこの段階を、方向性、テスト、依存に焦点を当てたステージと呼んでいます。チーム メンバーはまだお互いに慣れておらず、チーム全体の協力的な取り組みではなく、自分の仕事を個人の割り当てだと考えています。チーム ビルディングのセッションやグループ ランチは、多くの場合、チームがより快適になるのに役立ちます。

Storming – Storming の段階では、チーム メンバーは一般的に自分の意見にしがみつき、チームの影響力のさまざまな側面に抵抗するため、グループ内での対立が頻繁に発生します。Storming のステージは、チーム メンバーがチーム内で違いはあるが、多様性がアイデアを増やし、生産性を高める可能性があることを受け入れることを奨励される時です。次のステージに進むには、チーム メンバーが自分の仕事の要件やタスクの要求に対する安心感を必要としています。信頼と安定性が確立されると、対立の解決が容易になります。

ノーミング – チームがノーミングの段階に到達するまでに、メンバーは合意の領域を確立し、合意に達しました。個々の役割に関する明確なガイドラインが確立されているため、メンバー間のオープンさと結束性が新たに発見されました。この段階での目標は、協力してグループ基準を策定し、関連するアイデアや解釈について話し合うことです。

パフォーマンス — パフォーミング ステージでは、グループは統一されたビジョン、集団的エネルギー、目的意識を持っています。チームは共に良いパフォーマンスを発揮し、ポジティブで外交的な方法で問題を解決することを学びました。タックマンによると、役割は柔軟で機能的になり、チーム構造はより高いレベルのパフォーマンスをサポートできると言います。

シュナーゼは、新しいメンバーがチームのダイナミクスを変えるので、人々が Scrum チームに追加される際に、タックマンのモデルを考慮に入れることをおすすめします。チームが変わるたびに、フォーミング、ストーミング、ノーミング、パフォーミングの各段階を経ると彼女は言います。「新しいチーム メンバーを追加すると速度が低下するため、そのことを考慮する必要があります。」

シュナーゼはまた、スプリントのふりかえりを行うのが効果的なもう 1 つの理由を指摘しました。「振り返りは重要です。なぜなら、チームはポジティブなことや、どのような点を改善できるかを振り返る必要があるためです。チームがパフォーミングステージに進むのに役立ちます。」

 

初期スクラム チーム ビルディング

ほとんどの開発モデルと同様に、結果を出すのに時間がかかります。スクラム チームも同様です。新しいチームがすぐに優れた結果を生み出すわけではありません。チームがパフォーマンス ステージに到達するまでの時間は、個人やチームの団結など、他の要因によって異なるため、チーム ビルディングが不可欠です。

「最初のチーム ビルディングは、信頼を確立し、チームの全員が他のチーム メンバーの強みを認識するのに有益です。」とシュナーセは言います。「チームとして成長するには時間がかかります。」

チーム ビルディングの鍵は、全員にとって興味深く楽しいものを見つけ出し、誰も参加するのが好きな厄介なチーム ビルディングのエクササイズを捨てることです。チームの潜在的な活動のリストを準備し、チーム メンバーにどれが楽しいかを尋ね、追加の提案を求めます。博物館や地元のスポーツ ゲームへの旅行、グループ ボランティアの機会、強力なチーム環境を育むシンプルなチームランチなど、オフィス外で絆を持つ遠足を検討することもできます。さらに、スクラム トレーニング ワークショップ (特にブレイクアウト セッションを含むワークショップ) に一緒に参加することで、チーム全体に利益をもたらす個々の強みを分析するのに役立ちます。

リモートチーム対協力するスクラム チームの

チーム ビルディングは、チーム メンバーが異なる国はもちろん、さまざまな都市に配置されている場合に困難です。Schnase は世界中の Scrum チーム メンバーと協力してきました。専門家の中には、1 つの場所で協力しながら一貫性と信頼を育むのが簡単であることが多いため、共存するチームのみを構築することを勧める人もいますが、シュナーセ氏は、この種の取り決めは必ずしも実行可能であるとは限らないと述べています。

たとえば、IGT でのシュナーゼの役職は、オーストラリアや中国、米国のさまざまな都市のスクラム チーム メンバーと協力しました。タイムゾーンの違いは難しいかもしれませんが、特にグループ ミーティングの手配では、状況をうまく機能させることができると彼女は言います。

このような状況では、チーム ビルディングのプロセスはビデオ会議ツールを使用してオンラインで行う必要があるかもしれません。企業によっては、当初はチーム メンバーを集めるメリットを理解しており、トレーニングやその他のチーム ビルディングの目的のために、チームが中央の場所でミーティングを行う費用を支払う場合があります。雇用主にこのような場合は、スクラムのチーム メンバーに、例えば Scrum トレーニング カンファレンスでお互いに会うという考えを支持するかどうかを尋ねるとよいでしょう。全員が承認した場合は、雇用主に選択肢を提案します。

Scrum チームの役割、責任、好ましい特徴

初期の Scrum 開発者は、ラグビー チームがボールを行き来し、1 つの結束力のあるユニットとしてフィールドを上る際に使用するのと同様に、自己組織化された構造の中で Scrum チームの役割を想定していました。Scrum チームの構造は、製品開発チームが継続的で調整され、信頼できる結果を達成するために従う実証済みのモデルになりました。

バランスのとれた Scrum チームには以下が含まれます。

 

scrum team responsibilities
  • 製品ビジョンを促進し、製品バックログに優先順位を付け、顧客の製品の機能と価値を最大化する製品所有者
  • 開発チームを効果的に指導し、イベントを促進し、チームの進捗を妨げない気が散る事態を排除する Scrum マスター
  • そして、成果物を段階的に完了し (各スプリントの終了時に完了した製品機能)、優れた最終製品の生産に集中している開発チーム メンバー

Sutherland 氏とシュワバー氏は、スクラムの役割には理由があり、これらの役割を組み合わせることで生産性が低下することが多いと強調しています。また、雇用主は、メンバーがスプリントごとに 1 つの製品にのみ集中し、複数の製品や他のチームと協力する必要がない場合、チームの生産性がはるかに高く、安定していることを認識する必要があります。

以下のセクションでは、各役割に関連する責任と好ましい特徴をレビューし、採用マネージャーがそれに応じて候補者を評価しやすくします。

 

製品所有者の役割

Scrum ガイドは、製品所有者の役割が「製品の価値と開発チームの仕事を最大化する」責任があると説明しています。言い換えれば、製品所有者は、組織の投資収益率(ROI)を最大化する高品質の製品を提供する責任があります。その他の主な責任は、製品に対する顧客の期待事項を理解し、説明すること、製品機能の優先順位付けされたリストである製品バックログの管理に関連します。

シュナセ氏は、製品所有者は「チームに製品の大まかな要件と目標を提供できるが、チームがこれらの目標を達成する方法を決定できるようにする」性格を持つ必要があると述べています。

製品所有者は通常、製品またはプロジェクト管理、マーケティング、またはユーザー エクスペリエンス (UX) 設計の経験があります。多くの場合、顧客の期待、競合製品、市場の需要、開発中の製品タイプの将来の傾向の分析を含む背景があります。学術資格は、製品、ビジネス、業界の種類によって異なります。最も重要なのは、製品所有者が製品に対する強いビジョンとつながりを持つ必要がある事です。

次のリストは、この役割で成功を収めるために製品所有者のジョブ ディスクリプションが取り上げるべき責任を表しています。

  • 製品ビジョンを策定し、顧客の期待を強調する - 製品所有者は、さまざまな情報源からの情報を評価し、製品ビジョンを開発し、そのビジョンを促進できる人物である必要があります。製品所有者は、Scrum チーム、関係者、その他の組織全体に響く製品に関する重要なメッセージを提示できる必要があります。製品所有者は、製品を説明する際に顧客の視点を表し、その新機能や強化された機能が期待を超える方法を表すのは特に重要です。
  • 製品開発のビジネス面を考慮する - 製品所有者はビジネスに精通し、製品開発を含む企業のニーズを理解し、予算上の懸念事項と ROI に基づくタイミング、ポジティブな市場状況、意思決定の重要性を認識する必要があります。また、製品所有者は、製品リリース計画を策定し、市場、経営上層部、スクラム チームなど、複数のレベルで製品をプロモーションする際に戦略的である必要があります。
  • 明確で感動的な目標を持つチームのモチベーションを高める – 製品所有者は、各プロジェクトの大まかな要件と目標について開発チームと話し合い、すべての質問に答え、チームにこれらの期待に応える方法を決定させる必要があります。製品所有者は製品バックログの優先順位付けを担当しますが、開発チーム メンバーは、各 Sprint で完了できる作業の量と必要なスプリントの数を決定するメンバーです。したがって、製品所有者は、チーム メンバーをコントロールしようとせずにやる気を引き出す性格を持っている必要があります。
  • 製品価値と開発チームの進捗を最大化 – この包括的な責任は、製品所有者が現在最も重要な製品機能を正しく特定し、次の Sprint の優先順位付けリストの一番上に属することがいかに重要であるかを強調します。製品開発プロセスを通じてこれをうまく行うには、製品所有者は製品バックログ項目を継続的に改良し、再調整する必要があります。製品バックログ項目、またはより具体的には、製品機能とユーザー ストーリーは、それぞれが製品にもたらす価値に応じて優先順位を付ける必要があります。専門家の中には、さらに一歩踏み出し、価値は最も低いコスト項目のビジネス価値の最も高いトレードオフによって決定されると言う人もいます。しかし、主要な顧客を満足させ、他のビジネス戦略要因を分析する必要がある場合もあります。
  • 製品バックログの優先順位付けと管理 – 経験豊富な製品所有者は、製品バックログの唯一の責任として、考慮し、適切に評価する必要がある依存関係を認識します。最も効果的な製品所有者は、誰かが変更やその他の新機能をリクエストするためにアプローチしたときに選択的である必要性を理解しています。彼らは、すべてのことに承認を与え、製品開発の他の側面をビジネス価値と現実的な期待に沿って維持できないことを知っています。「いいえ」と言うタイミングを知ることは、仕事の重要な部分です。
  • 製品バックログを定期的に改良 – 製品バックログに記載されている各機能をチーム全体が理解できるように、製品所有者は説明を明確にし、重要度を説明し、チームに未回答の質問があるかどうかを尋ねます。また、これらの詳細は、顧客の期待に合った高品質の製品に対するチームのコミットメントを保証するのにも役立ちます。製品所有者の中には、開発チームのメンバーに技術仕様書やその他の類似する詳細を製品バックログに追加するよう求める人もいますが、開発者がこれらのタスクに費やす時間は最小限に抑える必要があります。
  • 製品機能 に焦点を当てたユーザー ストーリーを紹介 – 開発チームはスプリント計画ミーティング中に決定されたスプリント バックログを担当しますが、製品所有者はユーザーの視点から伝えられる機能の説明であるユーザー ストーリーを担当します。製品所有者の中には、ほとんどのユーザー ストーリーを自分で作成する人もいれば、チーム全体をプロセスに巻き込む人もいます。
  • チームとのエンゲージメントを維持し、継続的に対応する – 可能な限り最高の製品を提供するというコミットメントを示すためには、チームと積極的に関わることが含まれます。製品所有者は、チームへの利用可能性を強調し、コミュニケーション スキルを使って強力な関係を築きます。
  • ネットワーキングを通じて知識を増やす - 製品所有者は、定期的にカンファレンスやワークショップに参加して、業界の他の人とネットワークを構築する必要がある理由を知る必要があります。ビジネス モデリングのテクニック、教訓、製品サクセス ストーリーなどについて、他の人が何を言う必要があるかを聞いて、知識を獲得するのに最適な方法です。

 

Scrum マスターの役割

Scrum マスターは、主に Scrum チームが Scrum の慣行とルールを理解し、従っていることを確認する責任があります。その責任に加えて、Scrum マスターは、組織内の他のメンバーがスクラム チームに与える気が散る量を制限し、チームの進捗を妨げる相互作用に関するフィードバックを受け入れるのに十分なスクラム理論を尊重するようにします。

スクラム マスターは、複雑なプロジェクトのチーム コーチと進行役として、開発チームがその目標に集中し続けるために、可能な限り多くの障害を排除することで価値を提供します。シュナーゼは、Scrum マスターズは必要に応じて障害や障害を取り除いてチームを支援すべきだと述べました。「誰かが必要なネットワーク フォルダに入れない場合や、テスト環境がダウンしている場合、Scrum Masters はこれらの問題をエスカレートして解決するのに役立ちます。」と Schnase 氏は言います。「Scrum マスターズは、積極的かつ熱心に取り組むだけでなく、あらゆる関係者とコミュニケーションを取れる必要があります。

Scrum マスターズは、デザイン、エンジニアリング、IT、マーケティング、製品またはプロジェクト管理、品質保証、テストなど、さまざまな背景と学問分野から来ています。謙虚さ、忍耐力、忠誠心などの資質と、幅広いナレッジベースと強力なリーダーシップ スキルを持ち、対立を解決する方法を知っている優れた進行役や交渉者であることが可能です。また、Scrum マスターズは、他の情報源から受けるプレッシャーに関係なく、Scrum にコミットし続ける必要があります。

高いレベルで継続的にパフォーマンスを発揮するには、以下の詳細なリストで示されているように、Scrum マスターズは複数の責任に取り組み、いくつかの個人的な特徴を持つ必要があります。

  • サーヴァント リーダーとしての役割を果たす — 真の使用人リーダーは、チームが会社のビジネス目標を達成する方法で顧客に結果を出すために必要なものを持っていることを確認することに重点を置く必要があることを知っています。この点で、Scrum マスターは複数の組織 (チーム メンバー、顧客、会社) に同時にサービスを提供します。Scrum ガイドによると、Scrum マスターの役割には、製品所有者、開発チーム、組織へのサービスにおける特定の責任が含まれます。Scrum マスターは模範を示し、チームの他のメンバーが従いたいと思うタイプの人物です。インスピレーションに満ちた Scrum マスターは、物事が計画通りに進まない場合でも、自分の能力を信じ、自分の可能性に合わせて働くことを他の人に奨励します。
  • 権威を感じることなく責任を受け入れる — 「バンドのリーダー」というタイトルのブログ投稿で、Cohn 氏は力のない期待事項について説明しています。「スクラム マスターはプロジェクトの成功に対する責任を負いませんが、チームと一緒に残っている場合、スクラム マスターはチームのスクラムの採用と実践に責任を負います。Scrum マスターはこの責任を、達成に役立つ可能性のある力を引き受けることなく引き受けます。」

「スクラム マスターズへのインタビューに関するアドバイス」という別の投稿で、Cohn 氏は「ある管弦楽団の指揮者は、一度、個々の音楽家の演奏方法に本当の力がないと説明しました。」と述べ、期待を明確にしました。しかし、彼は彼らが最高の音楽家になるのを助けることに多大な責任を感じています。

  • 障害を解決し、可能であれば未然に防ぐ – Scrum マスターは、可能な限り障害を解決または削除することで、開発チームの作業を保護します。多くの場合、チーム メンバーはスクラム マスターに毎日のスクラム中の障害について伝え、障害が Sprint 中に作業を完了する能力を妨げる理由を説明します。

最近の求人情報では、採用マネージャーは、幅広い技術的知識を持ち、特定の業界の詳細を完全に理解している Scrum Masters に好みを示しています。この種の知識を持つ Scrum マスターは、技術的な問題に関連する障害にチームがより迅速に対処できるようにするという利点があります。

表面の下に隠れている障害の中には、チームの全体的な効果に対する脅威もあるので、そのような脅威を排除できる観察的で関与する Scrum マスターを採用することが非常に望ましいです。Scrum マスターの経験が豊富であればあるほど、潜在的な問題を認識し、問題になる前に解決しやすくなります。

  • チームの改善方法を指導する – Scrum マスターズは、知識や経験に基づいて例を示し、自分の可能性を最大限に引き出すよう指導することで、チームを指導します。そうすることで、チーム メンバーが自分自身をよりよく理解し、自己組織化や機能横断を含む慣行を実施するのに役立ちます。Scrum マスターズが自己組織化の力を奨励すると、チームは仕事の所有権を高め、意思決定や仕事の見積もりを簡単に見つけ、共通の目的を一緒に達成するというより強い感覚を持ちます。

Cohn 氏は、Scrum Master コーチングとパーソナル トレーナーが提供する支援の種類を比較しています。「スクラム マスターの助けを借りて、エクササイズ レジメンを守り、正しいフォームですべてのエクササイズを行うのに役立つパーソナル トレーナーと似ていると考えてください。優れたトレーナーは、ハード エクササイズをスキップしてカンニングしないようにしながら、モチベーションを提供します。しかし、トレーナーの権限は限られています。トレーナーは、あなたがしたくないエクササイズをさせることはできません。その代わりに、トレーナーはあなたの目標と、それを達成するためにどのように選択したかを思い出させます。」

  • 紛争をできるだけ早く認識し、解決する - Scrum チームの全員が非生産的な態度や機能不全の行動に対処する自由を持っていますが、誤解や妥協の必要性から対立が発生することもあります。このような場合、Scrum マスターズはチームの対立を早期に認識し、ダメージをコントロールし過ぎる前にチームの対立を解決する必要があります。スクラム マスターズはまた、ある程度の対立は避けられず、必ずしも悪いことではないと知っています。対立を克服する能力は、最終的にはチームを強くします。

「スクラム マスターズのインタビューに関するアドバイス」というタイトルのブログ投稿で、Cohn 氏はスクラム マスターズが仕事にもたらす協調的な考え方が対立の解決にどのように役立つのかについて説明しています。「優れたスクラム マスターは、チーム内に協力的な文化が存在することを保証するために働きます。Scrum マスターは、チーム メンバーがオープンな議論のために問題を提起できることを確認する必要があります。論争が発生した場合、共同作業の Scrum マスターズは、チームが勝者と敗者の面ではなく、関係者全員に利益をもたらす解決策の面で考えるように奨励します。」

  • Scrum イベントを促進する - 最高の Scrumマ スターは、イベントを促進し、人々を導く方法を本能的に知っているようです。実際、ほとんどの Scrum マスターは、リーダーシップ コースや長年の経験からこの種のトレーニングを受けています。Scrum イベントに参加する人々は、自分の準備と明確な期待値を設定する能力を高く評価しています。
  • 耳を傾け、観察する – 繰り返しますが、バランスは非常に重要です。効果的なスクラム マスターは優れたコミュニケーション スキルを持っていますが、いつ聞いて観察するかを知っています。リスニングとは、集中したアクティブなリスニングを意味します。これを観察することで、言葉遣い、表情、その他の合図を綿密に観察することで、大きな声で伝えるのではなく、明らかであることを観察することを指します。
  • Scrum 教育者や主催者として行動する – スクラム マスターズは、Scrum チーム メンバーが Scrum を理解し、従っていることを確認するだけでなく、チームに接続している他の従業員が Scrum を理解していることを確認します。組織が初めて Scrum を採用する場合、Scrum マスターは Scrum の実施を計画し、スクラム チームの生産性を高めるための変更を提案し、調整期間を通じて支援を提供することで、この取り組みをリードする人です。大企業では、この取り組みでは、他の Scrum マスターと協力して Scrum の効果を高める場合があります。

スクラムについて他の人に教える一方で、Scrum マスターズがスクラムの価値を促進し、そのフレームワークと指導原則がすでに他の企業にとって大きな結果を生み出している方法によって、一部の人々の懐疑的な意見を克服することが必要になるかもしれません。

  • 企業の政治スキルを使って組織全体の人々に影響を与える — 経験豊富なスクラム マスターズは、自分が活動しなければならない文化や条件を変えることで行動を変えたり、人々に影響を与えたりすることで、人々の行動を変えることができるかもしれないことを知っていますが、実際には人を変えられません。これらの Scrum マスターはまた、誰が大きな決定を下すのか、既存のアライアンスを活用する方法、道に障害を投げる可能性が最も高い人々の周りに回り道を取る方法を理解しているので、説得と動機を使って組織内のさまざまなレベルで他の人に影響を与える方法を知っています。

開発チームの役割

製品を作成する人は、共同で開発チームとして知られています。このグループには通常、ソフトウェア開発者、ユーザ インタフェース デザイナー、データベース スペシャリスト、オペレーション エンジニア、品質保証エンジニア、テスター、システム アナリスト、テクニカル ライター (ドキュメント スペシャリスト) などの経験とトレーニングを受けた専門家が含まれます。Scrum ガイドによると、「Scrum は、その人が行う作業に関係なく、開発者以外の開発チーム メンバーの肩書きを認識しません。このルールには例外はありません。
 
開発チームの主な機能は、一連の Sprint と製品のインクリメントを成功させるために必要な作業を実行し、次に高品質の最終製品を納品することです。Scrum 開発チームに誰かを雇う予定がある場合、シュナーゼは、テスト支援を提供し、自動化などの他の機能を実行する専門家を探すよう提案します。「すべてのチーム メンバーは、相互トレーニングを行い、お互いに助け合う意思を持つ必要があります。」
 
Scrum Inc. が出版した「Scrum の基本」は、部門を超えた開発チームを持つことの重要性にも取り組んでいます。さらに、製品バックログ内の 1 つの項目を完了できるチームには、少なくとも 2 人が必要です。これにより、同僚が病気になったり、休暇を取ったり、別の仕事に移ったりした場合に備えて、特定のチーム メンバーのスキル セットへの依存関係を排除できます。
 
以下のリストには、開発チームが共有する責任と、トップ チームのパフォーマーの望ましい特徴が含まれます。

  • 約束された機能と品質レベルを提供 – Scrum のチーム ワークに最適な従業員は、チームに残る期間を一貫して改善し、計画通りに機能を実装し、質の高い仕事を提供できる共同作業者とコミュニケーターです。彼らの行動を通じて、目標に対する強いコミットメントと、スクラム環境で成功する能力を示します。
  • 顧客に喜んでもらえる製品を世に送り出すことを、純粋に考える – 最も価値のあるチーム メンバーは、顧客をよく知っていて、顧客の期待を超えるために必要な努力をしなかったら、自分自身に失望する人です。これらの従業員は仕事に誇りを持ち、顧客からポジティブなフィードバックを受けると興奮します。
  • チームが完成に集中できるようにする – 開発チームはスプリント バックログのすべてのタスクを担当します。パフォーマンスの高いチームは、これらのタスクを Scrum ボードにコピーし、頻繁に更新を行い、すべてのタスクがリアルタイムでどこにあるかを視覚的に参照できるようにします。Scrum ボードの列には、どのタスクが完了し、残りの項目でどれだけの進捗が行われているかを明確に示す必要があります。これらのガイドラインに従うチーム メンバーは、混乱を排除し、チームが前進することに集中し続けます。
  • 毎日の Scrum やその他のミーティングをコミュニケーション ツールとして使用する – 良心的なチーム メンバーは、自分の時間は貴重で限られていると知り、同僚の時間を同じ敬意を払って扱います。毎日の Scrum やその他のミーティングを指定どおりに使用し、許可された期間内にコミュニケーションを取る準備を整えています。また、同僚との他のコミュニケーションも簡潔かつポイントに保ちます。
  • 現実的なコミットメントを実現 — 効果的なタイム マネージャーは、一定量のダウンタイムが全員の一日の一部である必要があると認識しています。特に創造性を育みたい場合は、リラックスして充電する時間が必要です。これらの目的のためには、スケジュールの一定の余裕が必要であり、予期せぬ状況や緊急事態に備えて十分な計画を立てます。経験豊富な開発者は、これを知り、それに応じてコミットメントの締め切りを見積もります。
  • 将来のスプリントにアイデアを提供 – 誰もが製品バックログで気づいた未対応アイテムの機能オプションを率先して提供するチーム メンバーを高く評価しています。製品バックログは製品所有者の責任リストの一部ですが、コンテンツを改善する方法に関するアイデアを提供することは、チーム全体でできることです。製品バックログ項目を改善すると、必然的に製品の増分と最終製品が改善されます。
  • クロス トレーニングと継続的な学習の機会を受け入れる — 成長志向のチーム メンバーは、イノベーションの重要性を理解し、急速に進化する技術環境に継続的に適応するため、高度な学習機会に興奮しています。彼らは変化に対応し、トレーニングを横断し、協力的な状況に積極的に取り組みます。また、自分の経験を他の従業員と共有し、新しいチーム メンバーのメンターとしての役割も果たしたいと思っています。
  • 技術的な経験とビジネス知識 を組み合わせる – テクノロジーを理解しているのと同じくらいビジネス コンセプトを理解する開発チーム メンバーは、いくつかの面で価値があります。テクノロジーをビジネス関係者に説明できるだけでなく、根本的な技術的要因ではなく、マーケティングに重点を置きすぎている製品をリリースした結果について知らせることもできます。

たとえば、製品の全体的なパフォーマンスに重くのしかかっている機能を追加しすぎると、開発者はできるだけ早く製品所有者に懸念事項を通知します。これらの開発者は、製品所有者が理解するビジネス用語で懸念事項を説明し、可能なソリューションに取り組む意思があることを示し、パフォーマンスなどの技術的側面が製品の市場価値にどのような影響を与えるかを理解していることを示すことができるため、貴重な資産です。

  • チームに干渉しないポリシーを適用する – 社内の他のメンバーは、自分の要求を開発チームに押し付けたくなる可能性があるため、Scrum ガイドはこの傾向に対処するための声明を含める必要があると判断した可能性があります。開発チームは他の誰かが言うことに基づいて行動することは許されません。

すべての Scrum チームの役割に関する一般的な採用のヒント

詳細を取り上げたので、Scrum の専門家が仲間のチーム メンバーに求めると言う資質の一般的なリストを見直しましょう。

  • ミスを認め、ミスから学ぶ – 全員がミスを犯すため、従業員がこれらのミスから学び、結果として改善することが重要です。誰かを採用したり、スクラム チームに招待したりする前に、どの候補者がミスを犯したことを認めないかを認識しましょう。これは、説明責任を負わないなど、より厄介な特徴の指標になる可能性があります。チームは無数の詳細に協力するため、非難ゲームを行う傾向を示さずに、スムーズにチームの役割に移行できる候補者を追加することが重要です。
  • フィードバックを重んじる – マインドフル チームのメンバーは、明確でシンプルで敬意を払ってフィードバックを与え、受け取る方法を知っています。また、フィードバックが役立ち、高揚感を高める必要があることを知っています。可能な限り、これらのチーム メンバーは個人的にフィードバックを提供する方法を探しています。信頼は方程式の重要な部分でもあります。お互いを信頼し合うチーム メイトは、より良い仕事をします。候補者がフィードバックや信頼についてどのように感じているかを適切に評価することで、候補者の性格が大きく明らかになります。
  • 仕事にユーモア、エネルギー、楽しみをもたらす – チームに参加し、他のメンバーとのつながりを感じるには、全員からの個人的な投資が必要です。ユーモア、エネルギー、楽しい活動を通じて個性を示す従業員は、多くの場合、より迅速に他の人とつながります。面接でこれらの資質を評価することは必ずしも簡単ではありませんが、自分の興味や好きな趣味、旅行、週末の活動について一般的な質問をすることで、候補者が特定のスクラムチームにどれだけ適しているかについての手がかりが明らかになります。

 

貿易のスクラム ツール

共同所有権は Scrum の重要な部分です。チームとして改善するには、さまざまなツールを使用してパフォーマンスと進捗を追跡することに価値があります。

  • Scrum ボード – さまざまな種類のタスクボードが存在しますが、Scrum で使用される最も一般的なモデルは、この記事で前述した Scrum ボードです。前述のとおり、Scrum ボードには通常、「To Do」、「進行中の作業 (WIP)」、および「完了」というラベルの列が含まれています。スプリント バックログの各タスクは付箋に書き込み、これらの列の 1 つに配置され、Scrum チームが Sprint の終了前に完了する必要がある作業量を決定するのに役立ちます。

Scrum ボードは、速度と呼ばれる指標を使ってチームのアウトプットを追跡するためにも使用できます。速度を測定するために、チームはスプリント バックログから各タスクに相対ポイント値を割り当てます。スプリントが完了すると、チームは [完了] 列にポイントを追加し、その特定の Sprint のチームの総速度を計算できます。この方法を使用することで、チームはチームのパフォーマンスのベースラインを作成し、今後の Sprint で処理できる作業量を予測できます。

また、チームは Scrum ボードと速度を使用してプロジェクトの完了日を予測したり、ワークフロー調整が実際にチームのパフォーマンス レートの改善に役立ったかどうかを分析したりすることもできます。詳細については、Scrum Inc. の Scrum ボードのコースワークを参照してください。

  • バーンダウン チャート – スプリントを完了する際に、チームは毎日のスプリント バーンダウン チャートを使用して、スプリント バックログに残っている作業量を示したい場合があります。残りの作業は垂直軸で追跡され、時間 (スプリント内の日数に応じて) は横軸で追跡されます。このタイプの視覚的表現は、チームが進捗を測定し、予想される完了日に順調に進むようにするのに役立ちます。バーンダウン チャートは、製品のリリース タイムライン中の傾向や作業を追跡するのにも役立ちます。バーンダウン チャートの作成の詳細については、Scrum Inc. のスプリント バーンダウン チャートのコースワークを参照してください。

 

Burndown chart
  • RACI マトリクス – すべてのチームが知っているように、個人の説明責任が必要な場合があります。このような場合は、RACI マトリクス (責任、説明責任、相談、情報に基づく) などのツールを使用して、タスクや成果物を整理された役割と責任図に分けるのに役立ちます。このツールの詳細については、「RACI のすべてを網羅したプロジェクト管理ガイド」を参照してください。

Smartsheet を使用して Scrum プロジェクトを簡単に管理する

シンプルなタスク管理やプロジェクト プランニングから、複雑なリソース計画やポートフォリオ マネジメントまで、Smartsheet は共同作業の改善と作業速度の向上に役立ち、より多くの成果を上げるのに効果的です。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。

 

ワークフローの合理化とサイロの完全排除を実現するより良い方法を見つけましょう。

Smartsheet 無料お試し Get a Free Smartsheet Demo