2025/10/04
スクラムでは、スクラムチーム全体が「毎スプリントごとに価値ある有用なインクリメントを作る」責任を共有し、開発者は「スプリントゴールの達成を確約する」とされています。 にもかかわらず、実際の現場では「自分の担当作業だけを見る」「他の人の作業に関心を持たない」という状況がよく起こります。 その背景には、主に次の3つの構造的 …
2025/10/03
機能横断的なチームを育てるには、メンバーが専門分野に閉じこもらず、幅広いスキルに触れることが欠かせません。 そのために役立つもののうち、代表的なのがペアワークやモブワークです。誰かと一緒にコードを書いたり設計を考えたりすることで、知識やスキルが自然とチーム内に広がっていきます。 ただし、手段はそれだけではありません。 …
2025/09/16
スクラムでは、スクラムマスターがパフォーマンスを管理するわけではありません。 スクラムチームは自己管理であり、誰が何をいつどうやってやるかはスクラムチーム自身が決めます。これが基本原則です。 また、責任の観点では、プロダクト自体の進捗（プロダクトゴールに向けた状況）であればプロダクトオーナーが説明責任を担い、スプリント …
2025/04/03
まず大前提として、スクラムでは安定したチームを推奨しています。 これは、チームの中での信頼関係や作業のやり方が成熟するにはある程度の時間と経験の蓄積が必要だからです。 そのため、人の入れ替えがあると、チームに影響が出る可能性があります。 とはいえ、現実の組織では異動や退職、新規メンバーの追加などで、チームの構成が変わる …
2025/03/06
はい。リモートでアジャイル開発をうまく進めている例は多数あります。 たとえばリモートを活用することで、ステークホルダーがスプリントレビューに参加しやすくなるといったオンサイトにない利点もあります。 ただし、全体で見ると、プロセスの観点ではオンサイトと比べて大きな違いはありません。 一方で、コミュニケーションや人間同士の …
2025/03/06
列挙するとキリがありませんが、以下のような状態を想像するとよいでしょう。 チームが安定的かつ継続的に価値を提供してる チームが失敗から学習し、成長を続けている 問題が発生しても多くはチーム自らで解決できる 管理者がいなくても、自らの判断で行動できる チームが「自分たちが機能しているというのがどういう状態なのか」を考えて …
2024/06/09
スクラムガイド2020には以下の記述があります。 スクラムでは「開発者」という言葉を使っているが、開発者以外を排除しているのではなく、単純化のために使用しているだけである。 スクラムから価値を得ているのであれば、そこにあなたも含まれていると考えてもらいたい。 つまり開発者というのはエンジニア、デザイナー、テスター、アー …
2023/12/27
「どのような働きかけをすると良いか」はチームの状況によって違います。 チームは千差万別であり、複雑系に類するものなので、定型的なアプローチでうまくいくものではありません。 これを踏まえたベストプラクティスは、スクラムチームになんらかの働きかけをする前に「まず観察しろ」です。 スクラムマスターとして、指摘や改善の依頼をす …
2023/11/19
この質問は言い換えると、マネージャー兼プロダクトオーナー、マネージャー兼スクラムマスター、マネージャー兼開発者のありなしです。 スクラムガイド2020では、スクラムチームの構造や説明責任に関する記述は以下のようになっています。 スクラムチーム内には、サブチームや階層は存在しない。 自己管理型であり、誰が何を、いつ、どの …
2023/10/12
みなさんこんにちは。@ryuzeeです。 スクラムチームのパフォーマンスを測定したいとステークホルダーに言われて悩んでいるスクラムマスターは多いと思います。 今回は、スクラムチームのパフォーマンスはどうやって測ればいいのか、何を気をつけるといいのか考えてみましょう。 具体的なメトリクスについては、別の記事で触れる予定で …
2023/07/28
司会とファシリテーションの違いの境界線は必ずしも明確ではありませんが、司会は会議やイベントの全体的な進行をスムーズに行うことに重点を置く一方で、ファシリテーションは議論と意思決定のプロセスに重点を置きます。 ここでは両方をまとめて扱います。 スクラムガイド2020ではファシリテーションや司会という単語は登場しませんが、 …
2023/07/27
開発者を社外から集めるというのは大きく分けると2つです。 開発をまるごと別の会社にやってもらう（別の会社に発注する） さまざまな会社から派遣やSESで来てもらったりフリーランスの方にチームに入ってもらったりする どちらの形態なのかによって多少の違いはありますが、以下のような問題が起こりやすいです。 開発のノウハウや暗黙 …
2023/07/25
スクラムガイド2017では自己組織化という単語が使われていて、以下のような記述がありました。 自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。 一方で、スクラムガイド2020では、自己管理という単語が使われ、表現も変わりました。 また、自己管理型であり、誰が何を、い …
2023/07/21
スクラムチームは10人程度までがよいとされています。 これは人数の増加に伴ってコミュニケーションのオーバーヘッドが大きくなることが大きな理由です。 したがって、10人を超える場合はスクラムチームの分割を検討することが一般的です。 また、人数が10人を超えなくても、認知負荷の観点からスクラムチームを分割することもありま …
2022/11/10
組織によっては、スクラムチームの開発者が複数チームを兼務することがあります。たとえばAのプロダクトに半分、Bのプロダクトに半分といった具合です。 スクラムではこのような兼務を明示的には禁止していません。 ただしスクラムガイドは「やってはいけないこと」をすべて定めるようなものではなく、最低限の原則と守るべきことを述べたも …
2022/07/14
スクラム未経験者が新たにチームに加わるときは、その人の経験や力量にあわせて受け入れをすることをお勧めします。 いきなり、各種イベントに参加して、意見を言ったり、作業をセルフアサインしたりするのは難しいことが多いですし、価値観や原則、チームの作業の仕方や完成の定義を理解していないうちに作業をしてしまうとチームにも影響を与 …
2021/10/01
まずは、チームが作成しているプロダクトの売り上げ、利益、キャッシュフローの計測が基本です。 つまり、生み出した価値を基準にします。 これらは短期的に達成すれば良いわけではなく、継続的に達成していく必要があります。 その上で、これらの指標に結びつく内部の指標に何があるのかを考えてみてください。 成果との関連を確認せずに一 …
2021/10/01
評価の目的は何ですか？ チームメンバーとして、チームの業績に貢献するための能力、やり方の改善のための評価でしょうか？それとも給与を決めるための評価でしょうか？ それらは、全く違うものですので、まずはそこを分けて考えると良いと思います。 つまり仕事がうまくなるようにするためのフィードバックは頻繁に行う必要がありますし、期 …
2021/10/01
実行責任や説明責任、結果責任については、従来どおりマネージャーが一端を担うはずです。 つまり実行そのものについてはスクラムチームに委ねたとしても、マネージャー自身はプロダクトオーナーやスクラムマスターと協働する必要はありますし（この場合マネージャーはステークホルダーになります）、マネージャーの責任が担保できないような場 …
2021/10/01
誤解のないようにいっておくと、個人としてインフラやアプリを始めとするさまざまな領域の設計や実装を全部できないといけないわけではありません。 開発チーム全体を見た時に必要なスキルを網羅していることがだいじです。 外部のチームへの受渡しや依存が増えれば増えるほどリードタイムは長くなり、計画作りも難しくなります。 また、いま …
