アジャイルチーム における役割分担とは?

Agile teamsアジャイルチーム は構造的にウォーターフォールチームとは異なります。アジャイルチーム はチーム自体に注目しますが、ウォーターフォールチームは組織構造に従っています。伝統的なウォーターフォール開発では、多くの場合スケジュールは「トップダウン」で決まります。つまり、経営陣がペースとスケジュールを設定します。アジャイル開発では、チームが自己組織化して、より大規模な組織の中で自分のスケジュールと方向性を定めます。私がスクラムを学んでいた頃、私の頭には 1 つの疑問がありました。「開発マネージャーとスクラムマスターは、どうやってチーム内の責任を共有するのだろうか?」これから、この疑問の答えを探っていきましょう。

ウォーターフォールチーム VS スクラムチーム

多くのウォーターフォールチームでは、マネージャーが中心となっています。メンバーは、優先順位の設定、進捗管理、パフォーマンス評価をマネージャーに任せます。アジャイルチーム は 自己組織化 します。メンバーはプロダクトオーナー (常にチームの管理体制内にいるわけではありません) と一緒に仕事をします。開発する製品のビジョンを定めるのはプロダクトオーナーです。一連のスプリントを通して、チームがどのように製品を開発すべきかを判断します。

自己組織化チームにはそれぞれの目標があります。スプリント計画では、メンバーはスプリントに貢献するためにどの程度働くかを決めます。そのため、プログラムを成功に導いたというやりがいがあります。自分のスケジュールを持つエンジニアは、より高品質でより一貫した製品を開発します。なぜなら自分のスケジュールを持っているからです。エンジニアは、予定通りに高品質の製品を開発することを望んでいます。組織内では全員が同じ目標を持っています。企業として、私たちはみな成功を望んでいます。グループ開発における Tuckman のステージでは、チームを編成して発展させる方法について説明しています。アジャイルな自己組織化チームも例外ではありません。

お互いに信頼し率直であることは、優秀な アジャイルチーム にとって不可欠です。適切なチームを採用するよう常に集中して管理することで、チームが仕事を達成できると信頼できます。チームの仕事に関して、細かいところまで詳細に管理する必要はありません。スクラムマスターと開発マネージャーは、機能の複雑化 (フィーチャークリープ)、ウォーターフォールのアンチパターン、部門間での衝突、副次的プロジェクトによるチームの真のゴールからの逸脱といった外部からの妨害要因からチームを守ります。

役割 1: スクラムマスターAgile teams_scrum master

スクラムマスターは アジャイルチーム のプロジェクトリーダーであり、スクラムプロセスのパフォーマンス最適化に集中します。スクラムマスターがプロダクトオーナーとチームの間に入り、スタンドアップを行ったりチームの障害を取り除いたりすることで、スプリントの一貫した成功を目指します。チーム間の調整はコストがかかるため、優秀なスクラムマスターはチーム間の調整も行い、コアチームが製品開発に専念できるようにします。このような行動により、全員の効率と一貫性を維持することができます。

スクラムマスターは アジャイルチーム のプロジェクトリーダーであり、スクラムプロセスのパフォーマンス最適化に集中する。

スクラムマスターは、アジャイルプログラムに必要なほとんどの入出力を調整します。スクラムマスターは、スプリントのキックオフ日々のスタンドアップスプリントレビュースプリントのふりかえり を行います。スクラムマスターはアジャイルコーチとしての役割も担います。ストーリーポイントの見積もり、スプリント計画、継続的デリバリーという製品ライフサイクル全体を通して、アジャイルプラクティスを導入して使いこなせるように支援します。コーチングもスクラムマスターの重要な役割です。チームがアジャイルになるよう支援するだけではなく、組織全体にアジャイル開発を提唱し、アジャイル開発がプロジェクトや企業に役立つ理由を広めます。しばしば、企業にとってアジャイル方法論が目新しいときは、チーム外のアドバイザーや利害関係者にもアジャイルコーチングは必要になります。

スクラムマスターは、チームや開発マネージャーとともに、バックログでの項目の見積もりを行います。はじめに、チームにはスクラムマスターと開発マネージャーからの助言が必要になります。チームが形成されるにつれ、順調なスプリント計画を通してプログラムの知識が共有されます。チームが効果的に仕事を進められるようになれば、スクラムマスターは見積もりからデリバリーのベロシティ最適化に重点を移します。

役割 2: 開発マネージャーAgile teams_Dev manager

チームでアジャイルを採用するとき、開発マネージャーには不確実なことがたくさんあります。ストックデール中将のようになっても良いでしょう。しかし、アジャイル開発チームがマネージャーの見積もりや最適化を信頼しない場合でも、マネージャーは重要な役割を担っています。

優れた採用

開発マネージャーの最も大事な仕事は採用です。適切な候補者を採用するのに、なぜそんなに多くの時間を費やすのでしょうか?チームの変化は、2 つのレベルで費用がかかります。

  • 候補者探しのために、優れた製品開発が二の次になる。
  • 新入社員が加わると、既存のチームは時間を費やして新人研修を行う必要がある。新入社員をチームに取り込む際、いくつかのスプリントでベロシティの低下を経験することになる。

開発マネージャーの最も大事な仕事は採用である。

チームが適切に自己組織化され、うまく機能していれば、組織の全員が製品の品質とデリバリーを通してそれを知ることになります。ここには、開発マネージャー以上に影響力を持つ者はいません。

アジャイルチーム とウォーターフォールチームの大きな違いの 1 つは、開発マネージャーが見積もりプロセスにおいてパートナーを務めることです。ウォーターフォールチームでは次のような会話がなされます。

  • マネージャー: 「このフィーチャーのデリバリーにはどれくらいかかりますか?」
  • エンジニア: 「6 週間です。フィーチャーを実現するために、A、B、C を行う必要があります」
  • マネージャー: 「なるほど。わかりました。ただ、4 週間ですべてを完了する方法を見つける必要があります。

しかし、アジャイル開発マネージャーは優秀な人材を採用し、その人材を信頼することを理解しています。アジャイルプロセスの基本的教義では、仕事に最も近い人材こそがスコープ設定とデリバリーの適任者と考えています。チームがスケジュールを設定します。開発マネージャーは、見積もりプロセスで質問し仮定を吟味することで価値を付加します。指示することではなく、プロセスのパートナーになることでそれを行います。

アジャイルプロセスの基本的教義では、仕事に最も近い人材こそがスコープ設定とデリバリーの適任者である。

優れた開発

スクラムマスターがチームのベロシティに集中しますが、開発マネージャーは、1 人 1 人にコーチングすることでチームメンバーのベロシティを向上します。開発マネージャーは組織内の優れた才能をまとめ、活気づけます。優秀なマネージャーは、マネージメントの基礎の達人です。自分のチームと 1 対 1の面談を行い、フィードバックを与え、コーチングをします。優れた開発マネージャーは、メンターとしてエンジニアを指導し、アイデアやコード、テスト、文化といった成果を挙げます。優秀な開発マネージャーは、自分のチームとパートナーになります。ときには、アーキテクチャ設計の決定において、チームに混乱が生じたり行き詰まったりすることがあります。優秀な開発マネージャーは、行き詰まりを解消するために適切なタイミングを見計らって介入するか、チームに任せて解決方法を学ばせます。スクラムマスターはチームメンバーのような技術的知識を持っていないこともあります。知識のギャップが見られる場合は、開発マネージャーがスクラムマスターとチームの間に立って重要なコンテキストを提供します。

さらに、スクラムマスターは企業のシニア開発者とパートナーになって、開発文化を築きます。プログラムで使用する技術の選択に影響を与えることが多く、コードアーキテクチャからエンドユーザー体験に至るまで、製品の品質に責任を負い続けます。開発マネージャーはコードレビューを行って、プログラムの短期的および長期的ゴールを達成できるコードをチームメンバーに構築させます。また、チームや大規模組織のために社内のコンテキストを作ります。

さらに詳しく

時間をかけてアジャイル文化での優秀なマネージャーの行動を見てきました。そして今私たちが知りたいことは、皆さんのチームはどのようにアジャイル方法論を実践しているのかということです。コメント欄で教えてください!

また、アジャイルの話題や方法に興味がある方は、アトラシアンのアジャイルソフトウェア開発ガイド「アジャイルコーチ」をご覧ください。ソフトウェアをより良くするための真面目なガイドです。

アジャイルソフトウェア開発ガイド「アジャイルコーチ」を見る!

著者注: この記事は、2014 年 1 月に投稿した記事を新しく包括的に更新したものです。




*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2015 年 10 月 30 日投稿 "Who's who in agile teams?"