アジャイルFAQ

• Q. スクラムチームのメンバーを入れ替えるときに気をつけることは何ですか？
• Q. スプリントレビューにステークホルダーが参加していますが、あまり反応やフィードバックがありません。どうしたらよいでしょうか？
• Q. スクラムでは「成果物」ではなく「作成物」と呼ぶのはなぜですか？
• Q. 初期の段階でいつリリースできるかを予測するのにストーリーポイントは使えますか？
• Q. プロダクトバックログにおける優先順位と順番の違いは何ですか？
• Q. プロダクトオーナーは開発しているプロダクトの技術的な知識をどこまで持つべきですか？
• Q. スクラムマスターはデイリースクラムに参加しますか？
• Q. リモートでアジャイル開発できますか？注意点があれば教えてください
• Q. 年末年始やお盆などの長期休暇がある場合はスプリントを長くしてもよいですか？
• Q. プロダクトオーナーが会議や休暇で不在のときはスプリントの長さを変えてもよいですか？
• Q. アジャイルにおいて、チームが機能しているというのはどういう状態ですか？
• Q. プロダクトゴールが導入された理由は何ですか？
• Q. スクラムマスターの仕事はどう管理したらよいですか？
• Q. 画面のデザインやレイアウトなどの標準化は最初のスプリントより前に行いますか？
• Q. スクラムガイドでは「役割」から「責任」という表現に変わりましたがなぜですか？
• Q. 受託開発では発注者がプロダクトオーナーになるのでしょうか？
• Q. なぜ完成していないプロダクトバックログアイテムをスプリントレビューで披露してはいけないのですか？
• Q. スプリントゴールはどのように設定しますか？
• Q. プロダクトオーナーはなぜ複数人ではいけないのですか
• Q. スクラムでは3つの責任しかありませんが、デザイナーやQAはどう扱えばいいですか
• Q. 既存のスクラムチームに新たにスクラムマスターとして参画したら、まず何をすればいいですか？
• Q. ウォーターフォールで要件定義まで行い、その後スクラムで開発することはできますか？
• Q. ベロシティの目標値を設定する是非について教えてください
• Q. 他のチームとストーリーポイントやベロシティを比較できますか？
• Q. スクラムマスターとしてスクラムチームに働きかけるときに気をつけることは何ですか？
• Q. スプリントゴールを達成できたかどうかは、いつ誰が確認するのですか？
• Q. プロダクトバックログアイテムが完成したあとに、見積りが適正だったかを確認して修正することに意味はありますか
• Q. スクラムマスターをローテーションするのはありですか
• Q. ストーリーポイントと時間を変換するのはなぜよくないのですか
• Q. スクラムチーム内にマネージャー（評価者）がいてもいいですか
• Q. プロダクトバックログアイテムはいつ見積もればいいですか？
• Q. 社内でアジャイル開発標準を作るときの注意点を教えてください
• Q. ベロシティの活用方法を教えてください
• Q. スクラムではイベントの司会やファシリテーションは誰がやりますか？
• Q. スクラムにおいて開発者を社外から集めるとどんな問題がありますか？
• Q. スクラムの自己組織化と自己管理の違いは何ですか？
• Q. スクラムチームの分割を検討していますが、どういう点を考慮すればいいですか？
• Q. スクラムはソフトウェアにしか適用できませんか？
• Q. 認定スクラムマスター試験の過去問は公開されていますか？
• Q. デイリースクラムで問題に言及しないのですがどうしたらいいですか？
• Q. デイリースクラムは1日のどのタイミングでやるのがいいですか？
• Q. スクラムチームの開発者は複数チームを兼務してもいいですか？
• Q. スクラム未経験者がチームに加わるときに、どうオンボーディングするとよいでしょうか？
• Q. 過去のスクラムガイドはどこから入手できますか？
• Q. スクラムマスターとして会話の少ないリモートチームにはどう声をかけるといいですか？
• Q. スプリント中の障害や割り込みはどう管理すればいいでしょうか？
• Q. スプリントプランニングでのタスク分割は全員で行うのでしょうか？
• Q. スクラムチーム外と技術的な調整をするのは誰ですか？
• Q. なぜスプリントレビューでインクリメントを提示することが重要なのですか？
• Q. スプリントゴールの達成が厳しそうになったらどうしたらいいですか？
• Q. プロダクトマネージャーとプロダクトオーナーは別のものですか？
• Q. 完成の定義と受け入れ基準の違いは何ですか？
• Q. 期日までにリリースできるかどうかはどうすれば分かりますか？
• Q. アジャイルやスクラムでお勧めの書籍を教えてください
• Q. 最初のスプリントを開始するまでに何を準備しておくといいですか？
• Q. スクラムマスターの仕事にはどのようなものがありますか？
• Q. 開発者のなかにリーダーを置くのは良くないのですか？
• Q. プロダクトオーナーとスクラムマスターが分かれているのはなぜですか？
• Q. なぜスクラムが広く浸透しているのですか？他の手法と比べて優れた点があるのですか？
• Q. 新たに開発者が増えたときにどうフォローすればいいですか？
• Q. インクリメントに対するステークホルダーの承認はいつどうやって取ればいいですか？
• Q. 画面デザインやエラーメッセージはプロダクトオーナーが決めるのですか？
• Q. スクラムではデータベースのテーブル設計はいつ行いますか？
• Q. プロダクトバックログアイテムを分割するのは誰ですか？
• Q. デイリースクラムがスクラムマスターへの進捗報告になってしまうのですが、どうしたらいいですか？
• Q. プロダクトゴールを途中で変更することはありますか？
• Q. スプリントレビューに誰を呼べばいいですか？
• Q. ステークホルダーからマイルストーンや計画を立てろと言われますが、どうしたらいいですか？
• Q. プロダクトバックログアイテムがたくさんあって整理に時間がかかるのですが、どうしたらいいですか？
• Q. プロダクトオーナーはどのような人が適任ですか？
• Q. スクラムでは誰が進捗を管理しますか？
• Q. 初回リリース後に発生する運用系のタスクは別のチームに任せるのですか？
• Q. 初期の段階ですべてのプロダクトバックログアイテムを詳細に洗い出すのですか？
• Q. スプリントゴールは複数設定してもいいですか？
• Q. スプリントの時間が余ったらどうしたらいいですか？
• Q. 認定スクラムマスターの資格の更新方法を教えてください
• Q. 複数プロダクトのプロダクトオーナーを兼任することはできますか？
• Q. スクラムマスターには技術的な知識が必要ですか？
• Q. 開発者全員が各プロダクトバックログアイテムの実現イメージを共有するのが望ましいですか？
• Q. 結合とバグ修正がスプリント終盤に集中するのですがどうしたらいいですか？
• Q. 予算はどうやって決めればいいですか？
• Q. 開発者にスキルの低い人がいる場合どう扱えばいいですか？
• Q. プロダクトバックログ管理ツールは何がおすすめですか？
• Q. プロダクトオーナーに学習やリファクタリングを提案しても、機能開発を優先されてしまうんですが？
• Q. なぜスプリント期間は一定なんですか？
• Q. スプリントレトロスペクティブではスクラムマスターがファシリテーションするのですか？
• Q. スプリントプランニングにとても時間がかかるのですが、どうしたらいいですか？
• Q. スプリントで緊急事態が発生した場合、どうしたらいいですか？
• Q. スプリントで何も完成しなかった場合スプリントレビューをキャンセルしてもいいですか？
• Q. スプリントゴールに合わないものはプロダクトバックログから選ばず、実現の順番が前後することもありますか？
• Q. Tシャツサイズ見積りをどうベロシティに変換するのですか？
• Q. アジャイル開発での一般的な品質指標の考え方はありますか？
• Q. スクラムマスターに向いているのはどんな人ですか？
• Q. スクラムではスプリントごとにリリースが必要ですか？
• Q. スクラムマスター資格の認定団体の違いを教えてください
• Q. スクラムを部分的に取り入れてもいいですか？
• Q. プロダクトオーナーとスクラムマスターを兼任していいですか？
• Q. ログインや共通処理はいつ作ればいいですか？
• Q. プロダクトバックログアイテムの分割の指針について教えてください
• Q. プロダクトバックログアイテムのフォーマットや含めた方がいい項目を教えてください
• Q. 着手したもののスプリント中に完成しなかったプロダクトバックログアイテムはどう扱えばいいですか？
• Q. デイリースクラムが15分で終わらないのですが、どうしたらいいですか？
• Q. 初めてのスクラムでは、スプリント期間はどれくらいがおすすめですか？スプリント期間を決める上でのポイントはありますか？
• Q. 新しいプロダクトの開発を始めるとき、技術的な調査も含めて長い時間がかかるように思うのですが、調査が終わってからスプリントを開始するのですか？
• Q. プロダクトオーナーが強い場合、弱い場合にどういうことが起こりますか？
• Q. イベントを固定するということはイベント日には休暇が取れないように思うのですが、どうしたらいいですか？
• Q. プロダクトオーナーは1人だと単一障害点になると思うのですが、なにか対策しますか？
• Q. 複数チームのスクラムマスターをしているとき、すべてのチームのイベントに全部参加しなければいけませんか？
• Q. スクラムマスターはスクラムチームには必ず1人で2人以上はダメですか？
• Q. スクラムチームメンバの評価はどのようにすべきですか？よくある個人の目標管理制度とどう組み合わせるのですか？
• Q. スクラムチームのマネジメントに有効な評価指標は何ですか？
• Q. スクラムチームを持つマネージャーの役割として、従来のマネジメントと大きく異なる点はありますか？
• Q. スプリントプランニングで「熟練チームはタスクを時間見積りしないこともある」そうですが、どのようにしてスプリント中に進捗を確認するのですか？
• Q. Google、Microsoft、Amazonなどでも、大規模システムはウォーターフォールで進めているのではないですか？
• Q. 要件定義や設計だけを行うスプリント、テストだけを行うスプリントというのはダメですか？
• Q. 以前のスプリントで作成したインクリメントにバグを発見した場合には、修正はどのように扱えばいいですか？
• Q. スプリントプランニングやレトロスペクティブで、スクラムチーム内の議論についていけないメンバーがいた場合、どうしたらいいですか？
• Q. プロダクトバックログの見積りについて、規模や工数を算出する時にどんな方法を使えばいいですか？
• Q. スプリントの長さは固定ですが、祝祭日があって営業日が減る場合はどうしたらいいですか？
• Q. スクラムの開発者はクロスファンクショナルだと思いますが、そんな優秀な人たちならウォーターフォールでもうまくいくのではないですか？
• Q. 請負契約でアジャイル開発を進めるコツを教えてください
• Q. 1つのプロダクトバックログアイテムが大きくて1スプリントでは作れません。複数スプリントにまたいで開発していいですか？
• Q. リファクタリングはプロダクトバックログやタスクに入れた方がいいですか？それとも各自が定常的に実施すればいいですか？
• Q. 各スプリントで回帰テストをすると大変なのですがどうしたらいいですか？
• Q. アジャイル開発の経験者を採用したいのですが、面接でどんな質問をすればいいですか？
• Q. プロダクトバックログの上位のアイテムの詳細化をスプリント外で他のチームがやってもいいですか？
• Q. 顧客や上司、社内の関係部門がウォーターフォール型の報告を求めるのですがどうしたらいいですか？
• Q. アジャイル開発において、ドキュメント作成の一般的な指針を教えてください

まず大前提として、スクラムでは安定したチームを推奨しています。 これは、チームの中での信頼関係や作業のやり方が成熟するにはある程度の時間と経験の蓄積が必要だからです。 そのため、人の入れ替えがあると、チームに影響が出る可能性があります。

とはいえ、現実の組織では異動や退職、新規メンバーの追加などで、チームの構成が変わることもあります。 その際は、以下の点を考慮するとよいでしょう。

(1) 一度に入れ替える人数は最小限にする

チーム全体をガラッと変えてしまうと、それはもう別のチームです。経験上一度に変えてもチームとして形を維持できるのは、チームのサイズの2割くらいの人数までです。理想的にはゆっくり1人ずつ入れ替えてください。

(2) 新メンバーのオンボーディングを行う

スクラムの経験がない人や、ドメイン知識が浅い人が入る場合は、オンボーディングが必要です。 いきなり開発に入ってパフォーマンスを発揮できることを期待しないでください。

(3) チームで仕事の進め方を再度合意する

メンバーが変われば働き方にも影響を及ぼします。 チームの仕事の進め方（Working Agreement）を改めて確認してください。 今までのメンバーにとっては暗黙だったことが通用しません。

(4) しばらくの間はパフォーマンスが落ちることを受け入れる

人が変わればチームとしての成果量も変わります。 短期的にパフォーマンスが落ちるのは当然です。それをいきなり問題視しないでください。

なお、誤解がないように言っておきますが、ずっと同じメンバーで固定したいわけではありません。 重要なのは、チームとしての安定性をどう保つかであり、長期的には当然、メンバーの入れ替えが起こります。

カテゴリ

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発

• 著者／訳者：西村 直人、 永瀬 美穂、 吉羽 龍太郎
• 出版社：翔泳社
• 発売日：2020-05-20
• 単行本（ソフトカバー）：288ページ
• ISBN-13：9784798163680
• ASIN：4798163686