チームの士気は、業務の成果を直接左右する要素です。社員が自分は評価され、やる気を持てていると感じれば、仕事への関わり方、定着率、仕事の質ははっきりと上向きます。士気を高く保つには、いくつもの面で意識して、しかも一貫して取り組む必要があります。価値観をどう根づかせ、成果をどう認め、コミュニケーションをどう組み立て、成長をどう後押しするか、といった面です。ここで紹介する6つの取り組みは、そのひとつひとつに対応しています。 主なポイント 会社の文化は、スローガンを掲げるだけでは育ちません。日々の行動で何度も強化していく必要があります 従業員を大切にし、育て、その働きを認めれば、動機は目に見
アジャイルチームの構造: 成功のための役割と責任
この記事では、アジャイルチームがどう構成されているのか、そこにどんな役割があり、その構造がデリバリーにとってなぜ大切なのかを説明します。あわせて、Scrum が Agile の代表的な実装になった理由と、プロジェクトの実際の要求に合わせてチーム編成をどう調整すればよいかも見ていきます。
重要なポイント
Agile アプローチ自体は厳密な役割を定めていませんが、Scrumは Product Owner、Scrum Master、チームという構造を用意しています。
クロスファンクショナル・チームは引き渡しによる遅れを減らし、意思決定をチームの外に出さずにチームの中にとどめます。
Agile チームを適切に編成すれば、変化への適応と目標達成が速くなります。
Agile の柔軟な性質
Agile の中心にあるのは、問題が現れてからチームが対応するまでの距離を縮める、というひとつの考え方です。決まった組織図や固定の役割セットは定めていません。それが Agile の強みであり、同時にフレームワークなしでは実践しにくい理由でもあります。Scrum はこのすき間を埋めるものです。プロセスを作り込みすぎることなく、Agile を日々の運用に落とし込めるだけの構造を与えてくれます。
Agile はアプローチ、メソドロジーではない
Agile は Agile マニフェストに示された原則にもとづいています:
- 変化への適応性
- 顧客との協働
- 継続的改善
Agile は考え方であって、手順書ではありません。そのもとで働くチームは、扱う仕事の種類や必要な調整の度合いに応じて、Scrum、Kanban、SAFe といった実装を選びます。実装の選び方を誤っても、チームが「Agile でなくなる」わけではありません。たいていは摩擦が生まれ、Agile で速くなるはずだったものがかえって遅くなる、というだけのことです。詳しくはこちら:カンバンボード。
人気の Agile 実装としての Scrum
Scrum は、3つの主要な役割に分かれた構造的なチームを用意しています:
- Product Owner: バックログを管理し、タスクの優先度を決めます。
- Scrum Master: プロセスを後押しし、障害を取り除きます。
- チーム: スプリントのタスクをやり遂げる自己組織化されたグループです。
例: チームは2週間のスプリントで作業します。次に何を作るかは、Product Owner がビジネス上の価値をもとに決めます。Scrum Master は、ブロッカーがスプリントを止めてしまう前にそれを取り除きます。作業の進め方を決めるのは開発チームです。この3つの責任のどれかがあいまいになったり、一人に集中したりすると、説明責任の構造が崩れ、スプリントで約束したことが当てにならなくなります。
Agile チーム構造が協業をどう支えるか
- クロスファンクショナリティ: メンバーが必要な分野をひととおりカバーしているので、外部のチームを待たずに作業を最初から最後まで進められます。引き渡しが少ないほど、サイクルタイムは短くなります。
- 自己組織化: タスクにどう取り組むかはチームが決めます。管理者が決めるのは方向で、やり方までは決めません。そのため、日々の意思決定で承認待ちが詰まることが減ります。
- 反復プロセス: 定期的なレトロスペクティブがフィードバック・ループになり、プロセスの問題が次のスプリントへ持ち越されて大きくなる前に拾い上げます。
例: チームはスプリントごとにレトロスペクティブを行います。目的は責任追及ではありません。働き方について、具体的な変更点を一つか二つ見つけることです。レトロスペクティブを省くチームは根本原因に手をつけないまま、スプリントのたびに同じところでつまずきがちです。
興味深い事実
ご存じでしたか? ソフトウェア開発の文脈で「Agile」という言葉が初めて使われたのは、2001年に17人の開発者がユタに集まり、Agile マニフェストに署名したときでした。このマニフェストは、業界が計画やデリバリー、チームの自律をどうとらえるかを大きく変えました。関連情報:エンジニアチーム向けプロジェクト管理ソフトウェア。
Agile チームを異なるプロジェクトに適応させる
Agile の構造には柔軟性があり、プロジェクトの種類や規模によって形が変わります。たとえば:
Kanban では、決まった役割はありません。チームはスプリントのサイクルを回す代わりに、ワークフローの可視化と進行中の作業の制限に力を注ぎます。
SAFe(Scaled Agile Framework)では、複数のチームを共通のプログラム目標に向けて連携させるため、役割がより階層的になります。
Agile と Scrum をもっと深く知りたい方は、まず基礎を扱った「Agile マニフェストとは? その核心的価値と原則の理解」から読んでみてください。そのうえで、チームの要となる役割を理解するために「Scrum Master とは? 主要な役割と責任の解説」に進むとよいでしょう。
結論
Agile チームの構造がうまく機能するのは、説明責任を実際に仕事が行われる場所に置いているからです。クロスファンクショナルな構成は待ち時間を減らします。自己組織化は承認の手間を省きます。レトロスペクティブは、プロセス上の負債が知らないうちにたまっていくのを防ぎます。Scrum、Kanban、SAFe のどのフレームワークを使うかは、それほど大きな問題ではありません。大事なのは、チームが明確なオーナーシップと短いフィードバック・ループを持ち、自分たちの働き方を調整する権限を持っているかどうかです。
推薦図書
"Scrum: The Art of Doing Twice the Work in Half the Time"
あらゆる組織で、反復的な開発とチーム単位の取り組みによって生産性を高める方法を説明しています。
"Agile Project Management with Kanban"
Kanban の視覚的な管理システムを取り入れて、プロジェクトの流れとデリバリーを改善する方法を示しています。
"The Lean Startup"
すばやいテストと顧客からのフィードバックを通じて、成功するビジネスを築く方法を紹介しています。