Scrum-quick-guide
スクラム-概要
アジャイルは、ソフトウェア開発業界の大きな流行語の1つになりました。 しかし、アジャイル開発とは正確には何ですか？ 簡単に言えば、アジャイル開発はソフトウェア開発チームとプロジェクトを実行する別の方法です。
何が新しいかを理解するために、従来の方法を要約しましょう。 従来のソフトウェア開発では、開発を進める前に製品要件が確定されます。
滝モデル
この特性を持つ最も一般的に使用されるソフトウェア開発モデルは、次の図に示すウォーターフォールモデルです。 ただし、ほとんどの場合、新しい機能が追加され、以前の要件も変更される可能性があります。 ウォーターフォールモデルは、このような要件の継続的な変更に対応するように構成されていません。 さらに、製品が完全に利用可能になるまで、ユーザーは製品の機能を明確にすることはできません。
反復増分モデル
反復インクリメンタルモデルでは、開発は、限られた数の最終要件および優先要件から始まります。 成果物は、製品の有効な増分です。 要件からコード開発に至る一連のアクティビティは、反復と呼ばれます。 増分の機能と、新しい、修正された、保留中の要件の一部またはすべてに基づいて、後続の反復に次の多くの要件が与えられます。 後続の反復の結果は、製品の強化された作業増分です。 これは、製品が必要な機能を達成するまで繰り返されます。
通常、ユーザーは開発作業に関与していないため、コミュニケーションのギャップが生じ、機能が不正確になる可能性があります。 この関与は開発チームにとってポジティブですが、チームの時間を厳しく要求し、遅延を追加する可能性があります。 さらに、反復中の非公式な要件の変更は混乱を招く可能性があり、スコープのクリープも引き起こす可能性があります。 この前提により、アジャイル開発が生まれました。
アジャイル開発
アジャイル開発は反復的なインクリメンタル開発に基づいており、要件とソリューションはチームのコラボレーションを通じて進化します。 タイムボックス化された反復アプローチを推奨し、変更に対する迅速かつ柔軟な対応を促します。 これは理論的なフレームワークであり、開発チームが従うべき特定のプラクティスを指定するものではありません。 スクラムは、従う必要があるプラクティスを定義する特定のアジャイルプロセスフレームワークです。
アジャイルメソッドの初期の実装には、Rational Unified Process（1994）、_ Scrum_（1995）、_ Crystal Clear、Extreme Programming_（1996）、_ Adaptive Software Development、Feature Driven Development_（1997）、および_Dynamic Systems Development Method（DSDM）_（1995）が含まれます。 2001年にアジャイルマニフェストが公開された後、これらは現在*アジャイル方法論*と総称されています。
アジャイルマニフェスト
アジャイルマニフェストは2001年にソフトウェア開発者チームによって公開され、変化する要件や顧客の関与に対応するために開発チームに与える必要がある重要性を強調しています。
アジャイル宣言は次のとおりです。
「ソフトウェアを開発し、他の人がそれを行えるようにすることで、ソフトウェアを開発するより良い方法を発見しています。 この作業を通じて、私たちは価値を見出しました：
- プロセスとツールに関する個人との対話
- 包括的なドキュメンテーション上の作業ソフトウェア
- 契約交渉を通じた顧客コラボレーション
- 計画をたどることへの対応
つまり、右側のアイテムには価値があるが、左側のアイテムにはさらに価値がある。」
…アジャイルソフトウェア開発のためのマニフェスト、著者：ベック、ケント、他 （2001）
アジャイルマニフェストアイテムの定義
左側のマニフェストアイテムは、次のように説明できます。
| Manifesto Item | Description |
|---|---|
| Individuals and interactions |
Importance needs to be given to:
|
| Working Software | Delivery of working software at short duration intervals helps gain customer trust and assurance in the team. |
| Customer collaboration | Constant involvement of customer with the development team ensures communication of necessary modifications. |
| Responding to change | Focus on quick response to the proposed changes, which is made possible with short duration iterations. |
アジャイルマニフェストの重要な要素は、人々と協力する能力を信頼しなければならないということです。 このため、開発された特定のアジャイル手法は、プロジェクトのライフサイクル全体でチームワークとコラボレーションを強調することにより、チームメンバーの能力を引き出します。
アジャイルの主要原則
アジャイル宣言は、次の原則に基づいています。
| Principle | Description |
|---|---|
| Satisfaction and Delivery | Customer satisfaction through early and continuous working software. |
| Welcoming Change | Welcome changing requirements, even at later stages of development. |
| Deliver Frequently | Deliver working software frequently (weekly rather than monthly). |
| Communication is the Key | Ensure close association of developers with business people on daily basis. |
| Environment and Trust | Build projects around motivated individuals. Give them necessary support and trust them. |
| Face-to-face Communication | Encourage face-to-face conversation to ensure efficient and effective communication. |
| Software as Measure of Progress | Working software is the primary measure of progress. |
| Sustainable Development | Promote sustainable development with the ability to maintain a constant pace throughout the development. |
| Attention to Details | Continuous attention to technical excellence and good design. |
| The Power of Less | Simplicity is essential. |
| Self-organizing Teams | Regular attention of the team on becoming effective in changing circumstances. |
アジャイル手法
動的システム開発方法論（DSDM）
これは、ソフトウェアプロジェクト用のアジャイルフレームワークです。 従来のアプローチを微調整するために使用されました。 DSDMの最新バージョンはDSDM Aternと呼ばれます。 Aternという名前は、Arctic Ternの略です。これは、長距離を移動できる海鳥で、優先順位付けやコラボレーションなどの自然な作業方法であるメソッドの多くの機能を表しています。
スクラム
これは最も人気のあるアジャイルフレームワークであり、特にチームベースの開発環境内でタスクを管理する方法に集中しています。 スクラムは、反復および増分開発モデルを使用し、反復期間を短縮します。 スクラムは実装が比較的簡単で、迅速かつ頻繁な配信に焦点を当てています。
エクストリームプログラミング（XP）
これは、アジャイルソフトウェア開発の一種です。 短い開発サイクルで頻繁にリリースすることを推奨します。これは、生産性を向上させ、新しい顧客要件を採用できるチェックポイントを導入することを目的としています。 この方法論の名前は、従来のソフトウェアエンジニアリング手法の有益な要素が極端なレベルに引き上げられているという考えに由来しています。 （エクストリームプログラミングは、より高品質のソフトウェアをより生産的に生産するために人々を組織するソフトウェア開発分野です。）XPは、最終製品の品質に大きな違いをもたらす斬新なアプローチで分析、開発、およびテストフェーズに対処します。
テスト駆動開発（TDD）
これは、非常に短い開発サイクルの繰り返しに依存するソフトウェア開発プロセスです。まず、開発者は、目的の改善または新しい機能を定義する自動化されたテストケースを作成し、次にそのテストに合格する最小限のコードを生成します。最終的に、新しいコードを許容可能な標準にします。
Lean
これは、最終顧客の価値の創造以外の目標に対するリソースの支出を無駄にするための生産慣行であり、したがって、排除の目標です。 製品またはサービスを消費する顧客の観点から見た場合、価値という用語は、顧客が喜んで支払うアクションまたはプロセスとして定義されます。 リーンは、少ない作業で価値を維持することに重点を置いています。
かんばん
これは、高レベルの生産を改善し、維持するためのシステムです。 かんばんは、在庫費用を管理するために組織が採用している戦略であるジャストインタイム（JIT）を達成する1つの方法です。 かんばんは、生産システム全体の実行をサポートする効果的なツールとなり、改善を促進する優れた方法であることが証明されました。
結論
過去10年にわたって、企業はアジャイルプラクティスを使用してIT開発チームとプロジェクトの成功とパフォーマンスを劇的に改善した成功事例が増え続けています。 これにより、メディアやテクノロジー、大企業、さらには政府など、さまざまな業界でアジャイルが広く採用されるようになりました。
アジャイルフレームワークは、チームが以下の恩恵を受けるのに役立ちます。
- 納品/市場投入までの時間の短縮
- 不確実性とリスクを減らす
- 顧客価値に注目して投資収益率（ROI）を向上させる
これらのさまざまなアジャイル方法論の中で、スクラムは過去20年間で世界中で非常に成功していることが証明されています。
スクラム-フレームワーク
スクラムは、複雑な製品を開発および維持するためのフレームワークです。 Ken SchwaberとJeff Sutherlandはスクラムを開発しました。 一緒に、彼らはスクラムルールの後ろに立っています。
スクラムの定義
スクラムは、可能な限り最高の価値の製品を生産的かつ創造的に提供しながら、人々が複雑な適応問題に対処できるフレームワークです。
スクラムは、1990年代初期から複雑な製品開発を管理するために使用されてきたプロセスフレームワークです。 スクラムは、製品を構築するためのプロセスや手法ではありません。むしろ、さまざまなプロセスや手法を採用できるフレームワークです。 スクラムは、製品管理と開発プラクティスの相対的な有効性を明確にして、改善できるようにします。
スクラムフレームワークは、スクラムチームとそれに関連する役割、イベント、アーティファクト、およびルールで構成されます。 フレームワーク内の各コンポーネントは特定の目的を果たし、スクラムの成功と使用に不可欠です。
スクラムのルールは、イベント、ロール、アーティファクトを結び付け、それらの間の関係と相互作用を管理します。 スクラムのルールは、このチュートリアル全体で説明されています。
注-業界全体で、スクラムにはドキュメントがなく、スクラムチームは開発者だけで構成されているなどという誤解があります。 完全にそうではありません。これらについては、後のセクションで説明します。
スクラムプロセスフレームワーク
スクラムでは、規定のイベントを使用して規則性を作成します。 すべてのイベントはタイムボックス化されたイベントであるため、すべてのイベントの期間は最大になります。 イベントについては、以降の章でさらに詳しく説明します。
スプリント
スクラムの中心はスプリントであり、2週間または1か月のタイムボックスであり、その間にリリース可能な製品の増分が作成されます。 新しいスプリントは、前のスプリントの終了直後に開始されます。 スプリントは、スプリントの計画、毎日のスクラム、開発作業、スプリントのレビュー、およびスプリントの回顧展で構成されます。
- スプリント計画では、スプリントで実行される作業は、スクラムチームによって共同で計画されます。
- デイリースクラムミーティングは、スクラムチームがアクティビティを同期し、その日の計画を作成するための15分間のタイムボックスイベントです。
- 増分を検査し、必要に応じて製品バックログを変更するために、スプリントの最後にスプリントレビューが開催されます。
- スプリント振り返りは、スプリントレビューの後、次のスプリント計画の前に行われます。 この会議では、スクラムチームが自身を検査し、その後のスプリントで実施される改善の計画を作成します。
結論
スクラムは、規則性をもたらす特定のルール、イベント、および役割を定義するプロセスフレームワークです。 ただし、基本的なスクラムルールに違反しない限り、ニーズに基づいて任意の組織に適応できます。
スクラム-役割
スクラムチームは、スクラムマスター、プロダクトオーナー、チームという3つの役割で構成されています。
スクラムマスター
スクラムマスター（スクラムマスターと表記されることもありますが、「スクラム」の後に正式用語にはスペースがありません）は、スクラムプロセスのキーパーです。 彼/彼女は以下に対して責任があります-
- プロセスをスムーズに実行する
- 生産性に影響を与える障害を取り除く
- 重要な会議の開催と促進
プロダクトオーナー
製品所有者は、製品の価値とチームの仕事を最大化する責任があります。 これを行う方法は、組織、スクラムチーム、および個人によって大きく異なる場合があります。
プロダクトオーナーは、プロダクトバックログを管理する唯一の責任者です。 製品バックログ管理には以下が含まれます
- 製品バックログ項目を明確に表現します。
- 製品バックログアイテムを注文して、目標とミッションを最適に達成する。
- チームが実行する作業の価値を最適化する。
- 製品バックログがすべての人に表示され、透明で、明確であることを保証し、チームがさらに取り組むことを示します。
- チームが製品バックログのアイテムを必要なレベルまで理解できるようにします。
プロダクトオーナーは、上記の作業を行うか、チームに実行させることができます。 ただし、製品所有者は引き続きこれらのタスクの責任を負います。
プロダクトオーナーは1人であり、委員会ではありません。 プロダクトオーナーはプロダクトバックログで委員会の希望を表すことができますが、プロダクトバックログアイテムの優先度を変更する場合はプロダクトオーナーに対応する必要があります。
プロダクトオーナーが成功するには、組織全体が自分の決定を尊重する必要があります。 プロダクトオーナーの決定は、プロダクトバックログのコンテンツと注文に表示されます。 異なる要件のセットから作業するようにチームに伝えることは誰にも許可されておらず、チームは他の誰かの言うことを実行することも許可されていません。 これはScrumMasterによって保証されます。
チーム
チームは自己組織化され、機能横断的です。 つまり、チームはアナリスト、デザイナー、開発者、テスターなどで構成されています。 必要に応じて、プロジェクトに関連するものとして。
業界の一部の人々は、このチームを開発チームと呼んでいます。 ただし、このような参照は、チームが開発者のみを持ち、他の役割を持たないという論争につながります。 それは誤解にすぎないことは明らかな理解です。 ソフトウェア製品を開発するには、すべての役割が必要であり、それがスクラムの本質です。チームは協力して機能します。 機能横断型チームには、チームの一部ではない他者に依存せずに作業を達成するために必要なすべての能力があるため、時間と労力を節約できます。 スクラムのチームモデルは、柔軟性、創造性、生産性を最適化するように設計されています。
最適なチームサイズは、敏remain性を維持するのに十分なほど小さく、スプリント内で重要な作業を完了するのに十分な大きさです。 可能な場合、チームの規模は5〜9人の範囲に維持する必要があります。 チームメンバーの数が5人未満の場合、相互作用が減り、生産性の向上が小さくなります。 メンバーが9人を超えると、調整が必要になります。
スクラムチームは、情報のスムーズな流れと問題の迅速な解決を確保するために、毎日緊密に連携しています。 スクラムチームは、製品を反復的かつ段階的に提供し、フィードバックの機会を最大化します。 完全な製品の段階的な配送により、潜在的に有用なバージョンの作業製品が常に利用可能になります。
スクラム-スクラムマスター
スクラムマスターは訓練された責任者であり、下記のサービスを提供します-
プロダクトオーナーへのスクラムマスターサービス
ScrumMasterは、次のようないくつかの方法でプロダクトオーナーにサービスを提供します。
- 効果的な製品バックログ管理の手法を見つける。
- スクラムチームが明確かつ簡潔な製品バックログアイテムの必要性を理解できるようにします。
- 経験的環境における製品計画の理解。
- プロダクトオーナーが価値を最大化するためにプロダクトバックログを調整する方法を知っていることを確認します。
- 敏ility性の理解と実践。
- 必要に応じてスクラムイベントを促進します。
スクラムチームへのスクラムマスターサービス
ScrumMasterは、次のようないくつかの方法でスクラムチームにサービスを提供します。
- 自己組織化と機能横断的なスクラムチームのコーチング。
- スクラムチームによる高価値製品の作成を支援する。
- スクラムチームの進捗の障害を取り除きます。
- 要求または必要に応じてスクラムイベントを促進する。
- スクラムがまだ完全に採用および理解されていない組織環境でスクラムチームを指導する。
組織へのスクラムマスターサービス
ScrumMasterは、次のようないくつかの方法で組織にサービスを提供します。
- スクラムの採用において組織をリードし、指導する。
- 組織内でのスクラム実装の計画。
- 従業員と利害関係者がスクラムおよび経験的な製品開発を理解し、制定するのを支援します。
- スクラムチームの生産性を向上させる変更の原因。
- 他のスクラムマスターと協力して、組織でのスクラムの適用の有効性を高めます。
結論
スクラムは、規則性をもたらす特定のルール、イベント、および役割を定義するプロセスフレームワークです。 ただし、基本的なスクラムルールに違反しない限り、ニーズに基づいて任意の組織に適応できます。
スクラム-イベント
スクラムプロセスフレームワークは、一連のイベントと対応するアーティファクトによって表示できます。 スクラムイベントは、タイムボックス化されたイベントです。 つまり、プロジェクトでは、すべてのスクラムイベントには事前に定義された最大期間があります。 これらのイベントにより、プロジェクトに関係するすべての人にプロジェクトの進捗状況を透明にすることができます。 スクラムの重要なイベントは
- スプリント
- スプリント計画
- 毎日のスクラム会議
- スプリントレビュー
- スプリント回顧展
スプリント
スプリント中に、作業用製品の増分が開発されます。 通常、期間は2週間または1か月で、この期間はプロジェクト内のすべてのスプリントで一定です。 プロジェクト内のスプリントごとに期間を変えることはできません。 新しいスプリントは、前のスプリントの終了直後に開始されます。
スプリント目標は、スプリントの目標セットです。 増分を作成する理由に関するガイダンスをチームに提供します。 スプリントプランニングミーティング中に作成されます。 スプリントの範囲が明確になり、要件の詳細が学習されると、プロダクトオーナーとチームの間で再交渉されます。 したがって、各スプリントはそれに関連付けられ、構築されるものの定義、設計、および構築をガイドする柔軟な計画、開発作業、および結果として得られる製品の増分です。
スプリント目標が廃止された場合、スプリントをキャンセルする必要があります。 これは、組織の方向が変わった場合、または市場や技術の条件が変わった場合に発生する可能性があります。 スプリントはプロダクトオーナーのみがキャンセルできますが、他の人は同じものに影響を及ぼします。
スプリントは期間が短いため、スプリント中のキャンセルはほとんど意味がありません。 スプリントのキャンセルは別のスプリントに再編成されるためにリソースを消費するため、非常にまれです。
スプリントがキャンセルされ、スプリント中に作成された作業の一部がリリースされる可能性がある場合、プロダクトオーナーは通常それを受け入れます。 すべての不完全なスプリントバックログアイテムは、製品バックログに戻されます。
スプリント計画
スプリントで実行される作業は、スプリント計画会議で計画されます。 スプリント計画ミーティングの期間は、2週間のスプリントで最大4時間、1か月のスプリントで最大8時間です。 ミーティングが開催され、すべての必要な出席者が出席し、スケジュールされたミーティングの目的を理解していることを確認することは、スクラムマスターの責任です。 スクラムマスターは、会議の司会を行い、議論の維持と時間通りの閉鎖を監視します。
スプリントプランニングは、次の2つの質問に焦点を当てています-
- Sprint Incrementで提供する必要があるもの、および提供できるもの
- スプリントの実行に必要な作業はどのように達成されますか？
この会議へのインプットは-
- 製品バックログ
- 最新の製品インクリメント
- スプリント中のチームの予想能力
- チームの過去のパフォーマンス
スクラムチームは、スプリント中に開発できる機能について議論します。 プロダクトオーナーは、プロダクトバックログアイテムの説明を提供します。 チームは、スプリントで何を達成できるかを評価するのに最適であるため、スプリントの製品バックログからアイテムを選択します。 チームはアナリスト、デザイナー、開発者、テスターで構成されています。 作業は共同で行われるため、再作業が最小限に抑えられます。
次に、スクラムチームがSprint Goalを作成します。 スプリント目標は、チームが製品増分を作成する理由に関するガイダンスを提供する目的です。 次に、チームは、スプリント中に選択した機能を実際の製品の増分に組み込む方法を決定します。 このスプリントに選択された製品バックログアイテムとそれらの配信計画は、スプリントバックログと呼ばれます。
スプリント中の作業は、スプリント計画中に見積もられ、さまざまなサイズや労力がかかる場合があります。 スプリントプランニングミーティングの終了までに、作業は1日以下の期間のタスクに分割されます。 これは、作業の割り当てを容易にし、完了を追跡するためです。 チームが作業が多すぎる、または少なすぎることに気付いた場合、選択したプロダクトバックログアイテムをプロダクトオーナーと再交渉できます。
チームは、技術的またはドメインのアドバイスを得るため、または見積りを支援するために、他の人（スクラムチームの一部ではない）をスプリントプランニング会議に招待することもできます。
毎日のスクラム会議
デイリースクラムミーティングは、チームのための15分間のミーティングです。前回のデイリースクラムミーティング以降の作業を迅速に理解し、次の24時間の計画を作成するために毎日実施されます。 この会議は、デイリースタンドアップ会議とも呼ばれます。
毎日のスクラム会議は、毎日同じ時間に同じ場所で開催され、複雑さを軽減しています。
会議中、各チームメンバーは次のように説明します-
- チームがスプリントゴールを達成するのを助けた昨日、彼は何をしましたか？
- チームがスプリントの目標を達成するために彼は今日何をしますか？
- 彼または彼のチームがスプリントの目標を達成するのを妨げる障害を見ていますか？
デイリースクラムはステータス追跡イベントと誤解されていますが、実際には計画イベントです。
会議へのインプットは、チームがスプリント目標の達成に向けてどのように行っているかであり、アウトプットは、スプリント目標の達成におけるチームの努力を最適化する新規または修正された計画でなければなりません。
スクラムマスターはデイリースクラム会議を調整し、会議の目的が満たされていることを確認しますが、会議はチームの責任です。
必要に応じて、チームはデイリースクラムミーティングの直後に、詳細な議論のために、またはスプリントの残りの作業を再計画するために会合することがあります。
デイリースクラムミーティングの利点は次のとおりです-
- チーム内のコミュニケーションを改善します。
- スプリントへの影響を最小限に抑えるために、障害物を早期に除去しやすくするために、障害物がある場合はそれを特定します。
- 迅速な意思決定を強調し、促進します。
- チームの知識レベルを向上させます。
スプリントレビュー
スプリントレビューは、すべてのスプリントの最後に開催されます。 スプリントレビュー中に、リリースされる増分のプレゼンテーションがレビューされます。 この会議では、スクラムチームと利害関係者が協力して、スプリントで何が行われたかを理解します。 それと、スプリント中の製品バックログの変更に基づいて、参加者は価値を最適化するために必要な次のステップに到達します。 したがって、Sprint Reviewの目的は、フィードバックと進捗を統一して取得することです。
スプリントレビューは通常、2週間のスプリントでは2時間、1か月のスプリントでは4時間開催されます。
スクラムマスターは以下を保証します-
- 会議が開催されます。
- 参加者は目的を理解しています。
- 会議は必要な議題に焦点を合わせ、必要な期間内に完了します。
スプリントレビューには、次の側面が含まれます-
- 参加者には、プロダクトオーナーが招待したスクラムチームと主要な利害関係者が含まれます。
- 製品所有者は、スプリント中に完了した製品バックログアイテムと完了していないものを説明します。
- チームは、スプリント中に何がうまくいったか、どの問題に遭遇したか、そしてそれらの問題がどのように解決されたかについて議論します。
- チームは、完了した作業を実証し、増分に関する質問（ある場合）に回答します。
- 次に、グループ全体が次に何をすべきかについて話し合います。 したがって、スプリントレビューは、後続のスプリントのスプリントプランニングへの貴重な情報を提供します。
- 次に、スクラムチームは、製品増分の次の予想されるリリースのタイムライン、予算、潜在的な機能、および市場をレビューします。
- スプリントレビューの結果は更新された製品バックログであり、次のスプリントの製品バックログの可能性のあるアイテムを定義します。
スプリント回顧
スプリント振り返りは、スプリントレビューの後、次のスプリント計画の前に行われます。 これは通常、2週間のスプリントでは1時間のミーティング、1か月のスプリントでは3時間のミーティングです。
スプリント回顧展の目的は次のとおりです-
- 人、人間関係、プロセス、およびツールに関して、最後のスプリントから学んだことを組み合わせます。
- うまくいった主な項目と潜在的な改善点を特定します。
- 製品の品質を向上させるための改善を実施するための計画の作成。
スプリントレトロスペクティブは、スクラムチームがスクラムプロセスフレームワーク内を内省して改善し、次のスプリントの成果をより効果的にする機会です。
参照
スクラムガイド©1991-2013 Ken Schwaber and Jeff Sutherland、All Rights Reserved。
スクラム-アーティファクト
スクラムアーティファクトは、開発中の製品、実行された活動、およびプロジェクトで計画されている活動を理解するために、スクラムチームと関係者が知っておく必要がある重要な情報を提供します。 次のアーティファクトがスクラムプロセスフレームワークで定義されています-
- 製品バックログ
- スプリントバックログ
- バーンダウンチャート
- インクリメント
これらは、スクラムプロジェクトで最低限必要なアーティファクトであり、プロジェクトアーティファクトはこれらによって制限されません。
製品バックログ
製品バックログは、最終製品の一部として必要な機能の順序付きリストであり、製品に加えられる変更の要件の単一のソースです。
製品バックログには、将来のリリースで製品に加えられる変更を構成するすべての機能、機能、要件、拡張機能、および修正がリストされます。 製品バックログアイテムには、説明、注文、見積もり、および値の属性があります。 これらのアイテムは通常、ユーザーストーリーと呼ばれます。 製品所有者は、その内容、在庫状況、注文を含む製品バックログの責任を負います。
製品バックログは進化するアーティファクトです。 最も初期のバージョンには、最初に知られ、最もよく理解されている要件のみが含まれる場合があります。 製品バックログは、製品、およびそれが使用される環境が進むにつれて開発されます。 製品バックログは絶えず変更され、有効にするために必要なものが組み込まれています。 製品が存在する限り、その製品バックログも存在します。
構築中の製品が使用されて価値が上がると、製品バックログはより大きく、より包括的なリストになります。 ビジネス要件、市場の状況、またはテクノロジーの変化は、製品バックログの変化を引き起こし、それを実際の成果物にします。
製品バックログの改良とは、製品バックログアイテムに詳細、見積もり、優先順位を追加することです。 これは、プロダクトオーナーとチームが実行する継続的なプロセスです。 スクラムチームは、いつどのように改良を行うかを決定します。
製品バックログアイテムは、製品所有者または製品所有者の裁量によりいつでも更新できます。
通常、上位の製品バックログアイテムは、下位のアイテムよりも明確で詳細です。 より明確かつ詳細になったことに基づいて、より正確な推定が行われます。 次数が低いほど、詳細度は低くなります。
今後のスプリントの候補要件である可能性が高い製品バックログアイテムは、スプリント中にこれらのアイテムを開発できるように改良されます。 1つのスプリント内でチームが開発できる製品バックログアイテムは、スプリント計画会議で選択できる状態にあると見なされます。
スプリントバックログ
スプリントバックログは、スプリント用に選択された製品バックログアイテムのセットに加えて、製品の増分を配信し、スプリント目標を実現するための計画です。
スプリントバックログは、次のIncrementでどの機能が利用可能になるか、その機能を実際の製品Incrementとして提供するために必要な作業についてのチームによる予測です。
スプリントバックログは、理解できる十分な詳細を備えた計画ですが、チームはデイリースクラムで追跡します。 チームはスプリント全体でスプリントバックログを変更し、スプリント中にスプリントバックログが出現します。 この出現は、チームが計画を遂行し、スプリント目標を達成するために必要な作業についてさらに学習するときに発生します。
新しい作業が必要になると、チームはそれをスプリントバックログに追加します。 作業が実行または完了すると、推定される残りの作業が更新されます。 計画の要素が不要と判断された場合、それらは削除されます。 チームだけがスプリント中にスプリントバックログを変更できます。 スプリントバックログは、チームがスプリント中に達成する予定の作業の非常に目に見える、リアルタイムの画像であり、チームのみに属します。
インクリメント
増分は、スプリント中に完了したすべての製品バックログアイテムの合計と、以前のすべてのスプリントの増分を組み合わせたものです。 スプリントの終了時には、新しい増分は使用可能な製品でなければなりません。つまり、使用可能な状態でなければなりません。 製品所有者が実際にリリースすることを決定したかどうかに関係なく、動作状態でなければなりません。
スクラムチームは、増分と見なされるものについてコンセンサスを持つ必要があります。 これはスクラムチームごとに大きく異なりますが、チームメンバは、作業を完了するためにそれが何を意味するかを共有して理解する必要があります。 これは、製品の増分で作業が完了するタイミングを評価するために使用されます。
同じ理解により、チームはスプリントプランニング中に選択できる製品バックログアイテムの数を知ることができます。 各スプリントの目的は、リリース可能な機能の増分を提供することです。
チームは、スプリントごとに製品機能の増分を提供します。 この増分は使用可能であるため、製品所有者はすぐにリリースすることを選択できます。 増分の理解が開発組織の規則、標準、またはガイドラインの一部である場合、すべてのスクラムチームは少なくともそれに従う必要があります。 開発組織の慣例ではない場合、スクラムチームは製品に適したIncrementの定義を定義する必要があります。
各増分は、以前のすべての増分に追加され、徹底的にテストされ、すべての増分が連携することを確認します。
スクラムチームが成熟するにつれて、Incrementsの定義が拡大し、より高い品質のためのより厳しい基準が含まれることが期待されています。 いずれかの製品には、その上で行われる作業の標準である増分の定義が必要です。
スプリントバーンダウンチャート
スプリントの任意の時点で、スプリントバックログに残っている合計作業量を合計できます。 チームは、毎日のスクラムごとに残っているこの総作業量を追跡し、スプリント目標を達成する可能性を予測します。 スプリント全体の残りの作業を追跡することにより、チームは進捗を管理できます。
スプリントバーンダウンチャートは、スクラムチームが費やした作業をトレンド分析するためのプラクティスです。 これは、スプリントゴールに向けたスプリントの進捗を監視するのに役立つテクニックであることが証明されています。
製品所有者は、少なくともスプリントレビューごとに残っているこの合計作業量を追跡します。 プロダクトオーナーは、この金額を以前のスプリントレビューに残っている作業と比較して、目標の希望する時間までに予想される作業を完了するまでの進捗を評価します。 この情報はすべての利害関係者と共有されます。
結論
スクラムの役割、イベント、アーティファクト、およびルールは避けられません。 スクラムの一部のみが実装されている場合、結果はスクラムではありません。 スクラムは完全に実装する必要があり、他の手法、方法論、および実践と整合している場合は適切に機能します。
参照
スクラムガイド©1991-2013 Ken Schwaber and Jeff Sutherland、All Rights Reserved。
スクラム-ユーザーストーリー
ご存じのとおり、ユーザーストーリーは一般に製品の機能を説明するために使用され、スクラムアーティファクトの一部を形成します-製品バックログ*および*スプリントバックログ。
ユーザーストーリー
ソフトウェア開発では、製品の機能が重要な役割を果たします。 これは、ユーザーが最終製品で最終的に使用したい機能です。 これらは、一般用語では要件として知られています。 ソフトウェア開発プロジェクトの成功は、ユーザーの要件を正確かつ適切に理解し、最終製品に実装することにあります。 したがって、要件または製品の機能は、開発プロジェクトチームに完全に知られている必要があります。
1999年に、Kent Beckは製品機能の用語User Storiesを考案しました。 彼は、ユーザーストーリーはユーザーの観点から、システムが彼のために何ができるかというよりも、彼または彼女が持ちたいものに関してナレーションされると説明しました。 したがって、ビューは製品からユーザーに完全に変わり、ユーザーストーリーはすべてのアジャイルフレームワークの要件の事実上の標準になりました。
スクラムプロジェクトでは、製品バックログはユーザーストーリーのリストです。 これらのユーザーストーリーは優先順位が付けられ、スプリントプランニングミーティングのスプリントバックログに取り込まれます。
推定はユーザーストーリーにも基づいており、製品のサイズはユーザーストーリーポイントで推定されます。
ユーザーストーリー構造
ユーザーストーリーの構造は次のとおりです-
_ <ユーザーのタイプ> _として、
_ <タスクを実行するには> _が必要です。
_ <私はいくつかの目標/利益/価値を達成できるように> _。
銀行の顧客がATMから現金を引き出すシナリオで、ユーザーストーリーがどのように構成されているかを見てみましょう。
ユーザーストーリー：顧客の現金引き出し
- 顧客*として、
- ATMから現金を引き出す*、
銀行で並んで待つ必要はありません
ユーザーストーリーの受け入れ基準
各ユーザーストーリーには承認基準も定義されているため、ユーザーストーリーの実装の正確性は、承認基準に基づいた承認テストに合格することで確認されます。
以下は、ユーザーストーリーの顧客による現金の引き出しの例の承認基準のサンプルです。
合格基準1：
- 与えられた*アカウントは信用できる
- そして、カードは有効です
- ディスペンサーには現金が入っています
- いつ*顧客が現金を要求する
- その後*口座から引き落とされることを確認する
- そして、現金が分配されるようにします
- そして、カードが返されることを確認します。
合格基準2：
- 与えられた*アカウントがオーバードローされた
- そして、カードは有効です
- いつ*顧客が現金を要求する
- 次に*拒否メッセージが表示されることを確認します
- 現金が出されないようにします
- そして、カードが返されることを確認します。
ユーザーストーリーを書く
製品所有者は、製品バックログ、したがってユーザーストーリーの責任を負います。 ただし、製品の所有者だけがユーザーストーリーを作成するわけではありません。 スクラムチームの誰もがユーザーストーリーを作成でき、要件が洗練され、新しい機能が追加されると、アクティビティをプロジェクト全体に広げることができます。
ユーザーストーリーの非機能要件
ユーザーストーリーにも非機能要件を組み込むことができます。 所定のATMの例では、365日24時間365日利用可能なATMは非機能要件であり、ユースケースで説明できます。
ユーザーストーリーの管理
ユーザーストーリーは製品バックログで管理されます。 ユーザーストーリーは優先度に従って並べられます。 最も優先順位の高いユーザーストーリーはより詳細なレベルに維持され、最も優先順位の低いユーザーストーリーはより詳細なレベルに維持されます。 すべてのスプリントについて、最も優先順位が高いため、より詳細なユーザーストーリーがスプリントバックログに取り込まれます。 ユーザーストーリーを製品バックログに追加する場合、優先度が最初に決定され、優先度に従ってその場所に従って配置されます。 ユーザーストーリーはいつでも優先順位を変更できます。 必要に応じて、ユーザーストーリーを削除することもできます。
ユーザーストーリーの利点
- ユーザーストーリーの主な利点は、ユーザー中心の定義自体にあります。 これは、最終的に、関連するユーザーシナリオで製品を使用するのはユーザーであるためです。 エンドユーザーをチームメンバーに接続します。
- ユーザーストーリー自体の構文により、ユーザーが達成したい目標、利益、または価値を確実に取り込むことができます。
- 受け入れ基準はユーザーストーリー自体の一部を構成するため、スクラムチームにとっては追加の利点になります。
- プロジェクトの実行中に、ユーザーストーリーに変更を加えることができます。 ユーザーストーリーの範囲が大きくなった場合、より小さなユーザーストーリーに分割する必要があります。 受け入れ基準の条件も変更できます。
- 作業中の製品の増分が各スプリントの終わりにユーザーに配信されるため、スクラムチームはスプリントレビュー会議でユーザーからフィードバックを得ることができます。 これにより、製品にフィードバックを継続的に組み込むことができます。
結論
スクラムのユーザーストーリーは、ユーザーをスクラムチームに近づけ、土壇場での驚きを防ぎます。
スクラム-バーンダウンチャート
スプリントの追跡は通常、バーンダウンチャートを使用して行われます。 バーンダウンチャートは、残りの作業量を日単位の時間数で示します。 たとえば、2週間のスプリントを考えてみましょう-
スプリント期間：2週間
No. 週あたりの日数：5
No. の 1日あたり：6
No. リソースの：6
したがって、スプリントの開始時の残りの総作業量は2 5 6 * 6 = 360時間です。
したがって、理想的なシナリオでは、残りの作業で36時間の作業が削減され、バーンダウンチャートは次のようになります-
スプリント作業が毎日計画どおりに行われた場合、スクラムの進行は理想的なバーにほぼ一致しています。
スプリント作業が遅れ、時間のコミットメントが満たされない場合、バーンダウンチャートは次のようになります-
ただし、バーンダウンチャートは毎日描画され、スリッページは早期に判明しているため、スプリントタイムラインに合わせて修正アクションを実行できます。 チームがタイムラインに合わせてストレッチすると、バーンダウンチャートは次のようになります-
したがって、スプリントの任意の時点で、スプリントに残っている総作業量を視覚化でき、スプリントのタイムラインを満たす可能性を向上できます。
結論
バーンダウンチャートは、スクラムチームが進捗状況とスプリントの目標を達成するために何をする必要があるかを追跡するのに役立ちます。
スクラム-推定
スクラムプロジェクトでは、スプリントプランニングミーティング中にチーム全体で見積もりが行われます。 見積もりの目的は、優先順位別およびチームがスプリントのタイムボックス中に配信する能力別に、スプリントのユーザーストーリーを考慮することです。
プロダクトオーナーは、優先順位付けされたユーザーストーリーが明確であり、見積もりの対象となり、それらがプロダクトバックログの先頭にあることを確認します。
合計でスクラムチームが製品増分の配信を担当するため、製品増分のサイズとそれに必要な作業量に基づいて、スプリントのユーザーストーリーを選択するように注意が払われます。
製品増分のサイズは、ユーザーストーリーポイントの観点から推定されます。 サイズが決定されると、過去のデータ、つまり生産性と呼ばれるユーザーストーリーポイントごとの努力によって、努力が推定されます。
スクラム推定技術
ユーザーストーリーのスクラム推定は、各ユーザーストーリーの難易度に基づいています。 難易度を評価するために、特定の尺度が使用されます。
スクラム推定で使用されるスケールにはいくつかのタイプがあります。 以下はいくつかの例です-
- 数値のサイズ設定（1〜10）
- Tシャツのサイズ（XS、S、M、L、XL XXL、XXXL）
- フィボナッチ数列（1、2、3、5、8、13、21、34など）
- 犬の品種（チワワ、………、グレートデーン）
推定手法は、通常、スクラムチーム全体がスケールの値に精通し、快適になるように選択されます。 最も一般的に使用され、最も人気のあるテクニックは、フィボナッチ数列に基づくPlanning Pokerです。
プランニングポーカーテクニック
Planning Poker推定テクニックでは、ユーザーストーリーの推定値はプランニングポーカーをプレイして得られます。 スクラムチーム全体が関与しているため、迅速で信頼性の高い見積もりが得られます。
プランニングポーカーは1組のカードでプレイされます。 フィボナッチ数列が使用されるため、カードには1、2、3、5、8、13、21、34などの番号が付けられます。 これらの数字はストーリーポイントを表します。 各推定量にはカードのデッキがあります。 カードの番号は、チームメンバーの1人がカードを保持しているときに、すべてのチームメンバーが見えるように十分大きくする必要があります。
チームメンバーの1人がモデレーターとして選択されます。 モデレーターは、推定が行われているユーザーストーリーの説明を読み取ります。 見積者に質問がある場合は、プロダクトオーナーが回答します。
各見積もり者は、自分の見積もりを表すカードを個人的に選択します。 すべての見積もりが選択されるまで、カードは表示されません。 その時点で、すべてのカードが同時にめくり上げられ、すべてのチームメンバーが各見積もりを見ることができます。
最初のラウンドでは、推定値が異なる可能性が非常に高くなります。 高評価者と低評価者は、推定の理由を説明します。 すべての議論は理解のみを目的としており、個人的に行われるものではないことに注意してください。 モデレーターは同じことを確認する必要があります。
チームは、さらに数分間、ストーリーとその見積もりについて話し合うことができます。
モデレーターは、特定のストーリーが作成されるときに役立つディスカッションのメモを取ることができます。 話し合いの後、各見積もり者はカードを再度選択して再見積もりを行います。 カードは、誰もが推測するまで再び秘密にされ、その時点でカードは同時に裏返されます。
推定がストーリーに使用できる単一の推定に収束するまで、プロセスを繰り返します。 推定のラウンド数は、ユーザーストーリーごとに異なる場合があります。
ポーカーの見積もりを計画する利点
プランニングポーカーは3つの推定方法を組み合わせています-
専門家の意見：専門家の意見ベースの推定アプローチでは、専門家は何かがどれくらいかかるか、またはどれくらい大きくなるかを尋ねられます。 専門家は、自分の経験、直感、または直感に基づいて推定値を提供します。
専門家の意見の推定は通常、多くの時間を必要とせず、いくつかの分析手法と比較してより正確です。
アナロジー：アナロジー推定では、ユーザーストーリーの比較を使用します。 推定中のユーザーストーリーは、以前に実装された同様のユーザーストーリーと比較されます。 推定は実証済みのデータに基づいているため、これにより正確な結果が得られます。
分解：分解推定は、ユーザーストーリーをより小さく、より推定しやすいユーザーストーリーに分割することによって行われます。 スプリントに含まれるユーザーストーリーは、通常2〜5日で開発できます。 したがって、おそらくより長い期間を要するユーザーストーリーは、より小さなユースケースに分割する必要があります。 また、このアプローチは、比較可能な多くのストーリーがあることを保証します。
結論
プランニングポーカーは、楽しく、しかも生産的な見積もり方法です。 最終的な見積もりが到着する前にセッションが議論のために開かれているので、チームがコンセンサスに到達し、ユーザーストーリーの実装の広い視野を持つことも容易です。
スクラム-ツール
スクラムツールは、スクラムプロジェクトの計画と追跡を容易にします。 製品バックログ、スプリントバックログ、スプリントの計画と追跡、バーンダウンチャートの表示、毎日のスクラムミーティングの実施、スクラムの回顧の実施のための単一の場所を提供します。
スクラムツールにはさまざまな種類があります。 一部は無料（オープンソース）、一部は有料、一部は蒸留版のツールを入手できます。 ただし、すべての機能とスケーラビリティを得るには、フルバージョンを購入する必要があります。
利用可能なスクラムツール
以下は、現在市場で入手可能ないくつかのスクラムツールのリストです。 オープンソースツールにはアスタリスクが付いています。
| Axosoft | Airgile | Agile Cockpit | Jira (GreenHopper) | Mingle |
| Scrumwise | Agilo For Scrum | Banana Scrum | Kunagi | OnTime Now |
| Version One | AgileWrap | Daily-Scrum | Intervals | Pango Scrum |
| Acunote | Agile Tracking Tool* | Digaboard* | iMeta Agility | Pivotal Tracker |
| Agile Agenda | Agile Task | EasyBacklog | Ice Scrum* | pmScrum |
| Agile Bench | Agile Soup | Explain PMT | Hansoft | Prj Planner |
| Agile Buddy | Agile Manager | Agile Express* | GravityDev | Project Cards |
| Agile Fant* | Agile Log | Fire Scrum* | Fulcrum* | Quantum Whisper |
| Quick Scrum | Retrospectiva* | Scrum’d | Scrum Factory* | Scrumpy |
| Rally Dev | Scrinch* | Scrum Dashboard* | Scrum Edge | Scrum Pad |
| Redmine Backlogs | Scrum 2 Go | Scrum Desk | Scrum Do | Tweet Scrum |
| Scrumrf | Scrum Time* | Scrumwise | Select Solution Factory | Tackle* |
| Urban Turtle | ScrumTool | Scrum Works | Timebox | Tangy Orange Scrum |
結論
一般的にアジャイル、特定のスクラムは、ドキュメントの作業がないことを意味しません。 スクラムアーティファクトが定義され、スクラムの計画と追跡が確立されています。
スクラムツールは、スクラムプロジェクトに関する情報の取得と追跡を容易にします。 ツールの選択は、他のツールのニーズに加えて、組織が必要とする機能によって異なります。
スクラム-利点
スクラムは、顧客、チームメンバー、および関連する利害関係者間の継続的なコラボレーションをサポートします。 そのタイムボックス化されたアプローチと製品所有者からの継続的なフィードバックにより、常に重要な機能を備えた製品が動作することが保証されます。 さらに、スクラムはプロジェクトのさまざまな役割にさまざまな利点を提供します。
顧客にとってのメリット
スプリントの期間は短く、優先順位の高いユーザーストーリーはすべてのスプリント計画で取り上げられます。 すべてのスプリントの配信で、顧客が必要とする機能がすぐに含まれるようになります。 さらに、顧客が変更要求を提起すると、現在のスプリントに吸収されるか、次のスプリントに含まれます。 したがって、開発チームは顧客の要件に迅速に迅速に対応します。
組織にとってのメリット
組織は、優先順位付けされたユーザーストーリーの開発に必要な作業に集中できるため、オーバーヘッドと再作業を削減できます。 顧客に対するスクラムの特定の利点により、開発チームの効率が向上し、顧客満足度が高まり、顧客維持と顧客照会が可能になります。 組織の市場の可能性を高めます。
プロダクトマネージャーのメリット
プロダクトマネージャーは、プロジェクトでプロダクトオーナーの役割を果たします。 製品所有者の責任は、顧客満足度を確保することです。 スクラムは迅速な対応、作業の優先順位付け、変更の吸収を促進するため、プロダクトマネージャーは作業が顧客のニーズに合っていることを簡単に確認でき、それが顧客満足度を保証します。
プロジェクトマネージャーのメリット
プロジェクトマネージャーは、プロジェクトでスクラムマスターの役割を果たします。 スクラムの共同性により、簡単で具体的な計画と追跡が容易になります。 バーンダウンチャートを使用して残された作業を理解し、デイリースクラムミーティングを行うと、プロジェクトマネージャーは常にプロジェクトの状態を把握できます。 この認識は、プロジェクトを監視し、問題をすばやく見つけて対処するために不可欠です。
開発チームのメリット
スプリントのタイムボックス化された性質と、すべてのスプリントの終了時の作業製品の増分配信により、開発チームは自分の作業がすぐに使用されることに熱心になります。 組み込みのチームコラボレーションにより、チームは彼らの仕事を楽しむことができます。 すべてのスプリントのユーザーストーリーは顧客の優先順位に基づいているため、チームは自分の作業が重要であることも理解しています。
スクラム-認証
スクラム認定は、スクラムアライアンスによって提供されます。 次の認定が提供されています-
- 認定スクラムマスター（CSM）
- 認定スクラムプロダクトオーナー（CSPO）
- 認定スクラムプラクティショナー（CSP）
- 認定スクラムコーチ（CSC）
- 認定スクラムトレーナー（CST）
認定スクラムマスター（CSM）
認定スクラムマスターは、スクラムアライアンスのメンバーになり、スクラムマスターの役割を果たし、他の認定資格を得るための基本的な認定です。 認定には、CSMコースへの参加が必要です。 その後、候補者はスクラムメンバーシップとCSMオンライン試験の詳細を指定したメールを受け取ります。 受験後、候補者には認定スクラムマスター（CSM）認定が与えられます。
認定スクラムプロダクトオーナー（CSPO）
認定スクラムプロダクトオーナーは、スクラムアライアンスのメンバーになり、プロダクトオーナーの役割を果たし、他の認定を受ける資格を得るための基本的な認定です。
認定スクラムプラクティショナー（CSP）
認定スクラムプラクティショナーは、経験豊富なスクラムマスターおよびプロダクトオーナー向けの認定です。 候補者は、少なくとも1年間スクラムマスターまたはプロダクトオーナーでなければなりません。 候補者は、指定された役割で行ったことの詳細な説明を含む申請書を提出する必要があります。
候補者がスクラムマスターの役割または製品所有者の役割を必要な期間積極的に実践している場合、候補者はCSM認定またはCSPO認定の直後にCSP認定を取得することができます。
認定スクラムコーチ（CSC）
認定スクラムコーチは、コーチングに重点を置いている人向けの認定です。 認定では、候補者が過去5年間で少なくとも1500時間スクラムの採用と習熟を通じてスクラムチームを指導したことが要求されます。
認定スクラムトレーナー（CST）
認定スクラムトレーナーは、CSMまたはCSPOクラスを教えたい人のための認定です。 申請者はCSMまたはCSPOを持っている必要があり、申請する前に少なくとも1年間はCSPでなければなりません。
スクラム-よくある質問
以下は、スクラムに関するいくつかのFAQです-
質問：スクラムとアジャイル開発の違いは何ですか？
回答：アジャイル開発はソフトウェア手法であり、スクラムはアジャイルに続くプロセスフレームワークの1つです。
質問：スプリントとイテレーションは同じですか？
回答：スクラムのスプリントと反復インクリメンタルモデルの反復の両方が、有効な製品の増分を提供します。 ただし、これらは次の点で異なります。
- スプリントと反復のライフサイクルは異なります。
- スプリントはタイムボックス化されていますが、反復はそうではありません。
- スプリントの継続時間は、反復の継続時間に比べてはるかに短くなります。
質問：スクラムマスターは役職ですか、それとも既存の役職を持つ人が果たす役割ですか？
回答：スクラムマスターは、役職を持つ人が果たす役割です。 通常、プロジェクトマネージャーの役割を担っている人もスクラムマスターの役割を果たします。
質問：プロダクトオーナーとスクラムマスターの役割を同じ人が演じることはできますか？
回答：いいえ、所有権が異なるためです。 製品所有者は、製品バックログ、ユーザーストーリーの優先順位付け、およびスプリントに割り当てられたユーザーストーリーでの作業製品の増分の検証を処理します。
質問：スクラムプロジェクトにドキュメントが必要ないということですか？
回答：いいえ。 スクラムプロジェクトは、他のプロジェクトと同様に、ユーザーストーリー、設計、テストケースなどのドキュメントが必要です。
結論
アジャイルとスクラムは同じではありません。 スクラムは、アジャイルに適応するプロセスフレームワークの1つです。 フレームワークには優れたコラボレーションと自己組織化も必要であるため、経験豊富なチームメンバーがいるチームにはスクラムが推奨されます。 スクラムルールに厳密に従わないと、プロジェクトが失敗する可能性があります。 したがって、チーム全体でスクラムの概念を適切に理解する必要があります。 スプリントは短期間でタイムボックス化されているため、スクラムマスターがプロジェクトを継続的に監視している場合でも、ジョブのスクラムの詳細を学習する時間はありません。
