経済的にスクラムマスター認定を取得する：段階別の計画
この記事が紹介されたことを、嬉しくお知らせします…
LinkedIn のこちらで紹介されています >>>
以来、 スクラムのフレームワーク がソフトウェアの開発・提供の最良の方法の一つとなり、誰もが同じ目標を持つようです。
朝起きてノートパソコンを開き、こんなものを持つ喜びと安心を感じることです。
スクラムマスター認定。
それが夢ですよね？
優れたものを届けること。 ソフトウェア を雇用主や顧客へ。
スクラムの技能と知識、そして次の認定を力に、素晴らしいキャリアを築くこと。 スクラムマスター認定.
多くの人にとって、認定はスクラムを始めるきっかけです。
この記事では初めて、認定取得を助ける、詳しく踏み込んだ段階別ガイドをご紹介します。
経済的に、速く、オンラインで、手間なく！
たった四つの簡単な手順で、認定を持つ優れたスクラムの専門家になれます。 スクラムマスター認定。
スクラムがキャリアを支え、仕事の有効性を高める方法と、スクラムマスターの技能を今すぐ伸ばすべき理由をお伝えするのが、この記事の目的です。
定義：スクラムマスター認定とは？
最も適切な定義は、次の場所で確認できます。 スクラムマスター認定 その定義の掲載先は、 International Scrum Institute™の Scrum Master Accredited Certification™.
スクラムマスター認定とは、 スクラムによるソフトウェアの開発・提供における能力の証です。 スクラムマスター認定は、 正式な多肢選択式試験で確認された、スクラムの知識と優れた専門性を認めます。
スクラムの開発プロセスは、これまで何百万人もの専門家に大きな利点をもたらしてきました。スクラムで技能とキャリアを高めた人々に、あなたが加われない理由はありません。
迷っているなら、認定なしで成長するキャリアは、もはや想像できないとお伝えします。次の分野での役割、肩書、経験は問いません。 情報技術（IT） の世界で。
今ではITの専門家でなくても、スクラムとその仕組みを理解し、認定を取得できます。
職業やIT部門への所属を問わず、重要で議論の余地のない事実があります。あなたの仕事と組織へ提供する価値は、IT、ソフトウェア、そして次のものに依存し、相互につながっています。 アジャイルスクラムのプロセスと原則.
さらに、従来のビジネスモデルは次の形へ移行しています。 サービスとしてのソフトウェア（SaaS） を基盤とする事業、いわゆる デジタル化の動き, によって、IT部門の内外を問わず、認定取得は任意の選択ではなくなっています。 今ではスクラムマスター認定は必須なのです。
キャリアを始めたばかりでも、経験豊かなIT専門家でも関係ありません。認定が必要です。
人や機能の管理を担っているかどうかも関係ありません。やはり認定が必要です。
例えば、次のような肩書かもしれません。
- ビジネスアナリスト、
- ソフトウェアアーキテクト、
- エンタープライズアーキテクト、
- ソフトウェア設計者
- ユーザーエクスペリエンス（UX）デザイナー、
- ユーザーインターフェース（UI）デザイナー、
- ソフトウェア開発者、
- ソフトウェア開発マネージャー、
- テストエンジニア、
- テスト自動化の専門家、
- テストマネージャー、
- ITシステム運用の専門家、
- Unix/Linux管理者、
- 情報セキュリティ（InfoSec）エンジニア、
- ITネットワークエンジニア、
- データベース管理者（DBA）、
- プロジェクトマネージャー、
- プログラムマネージャー、
- プロダクトマネージャー、
- チームリーダー、マネージャー、部長、経営幹部、
- あるいは、ここに挙げていない他の肩書でも同じです。
今日、スクラムの開発フレームワークを学び、次の認定を取得してマスターになりましょう。 スクラムマスター認定.
アジャイルスクラムと認定が登場する前の、混乱と不満の3要素
スクラムが開発の実践と事業にもたらす影響を理解するには、ある一日、あるいは一つのプロジェクトを振り返ると良いでしょう。
そこで、組織でスクラムによる開発・提供を採用する前のプロジェクトを、少しお話しします。
執筆の数日前、約20年前に一緒に働いていた元同僚と昼食を取りました。マーカスという彼は、次の機関でスクラムマスターとプロダクトオーナーの認定を取得しています。 International Scrum Institute™.
現在、アジャイルのプロジェクト管理ソフトウェア分野で有力な開発会社のスクラムマスターを務めています。
今、彼は世界各地にメンバーが分散するアジャイルスクラムチームを支援しています。
昼食中、分散型チームには典型的な課題が多いと認めました。特に挙げたプロジェクトの問題には、次があります。
- メンバー間の働き方の違い、
- 時差。
- 文化の不一致。
- 言語の制約。
それでも、アジャイルスクラムでの仕事は20年前より楽しく、生産的で、実りが多いと話しました。 スクラムによる開発・提供のプロセスを使わなかった頃と比べて、ということです。
経験豊かで実績のあるマネージャー、マスター、オーナーである彼の言葉は、スクラムの価値を強く裏付けていました。
ありがとう、マーカス！
そこで私は、スクラムに出会う前のプロジェクトを話しました。多くのマスターも、認定取得前の経験と似ていると感じるでしょう。
1990年代後半、私はスマートカードを基盤とする次の仕組みを作る開発グループにいました。 公開鍵基盤を構築する開発グループにいました。スマートカードが参加者の秘密鍵を安全に保護し、対応する公開鍵と、それを包む証明書は、名前のとおり公開して配布しました。
当時、それ自体が比較的複雑なITプロジェクトで、相互に依存する複数のハードウェアとソフトウェアの開発チームが必要でした。膨大な、 研究開発（R&D） を行い、完全に機能するハードウェアとソフトウェアのシステムを作る必要がありました。
当時は、まだ次のものがなかったことを思い出してください。 実用最小限の製品（MVP） という考え方で、実験し、作り、学び、再び試すことを行っていませんでした。
アジャイルでMVPを作る方法に興味があれば、こちらをお読みください。 記事 Cleevioの記事で、この複雑なプロセスの全体像がよりよく分かります。
スクラムなしで、多数のハードウェアとソフトウェアから成る高度な基盤を作るのは大きな挑戦でした。
マスターや認定取得者がいないチームで経験した、三つの大きな問題をご紹介します。
認定がない場合の混乱と不満の第1要素：プロジェクトを理解する前に、全体を計画しなければならなかった
スクラムがなかったチームは、顧客の要求を満たさない、全く的外れなソフトウェアとハードウェアを開発・提供していました。
第三者企業に、製品やサービスの作り方を指示される時期もありました。
能力成熟度モデル（CMM）, ISO 9001:2008 などの派生手法は、正しいソフトウェアを正しく作れるよう、企業を支えようとしました。
その成功度はこの記事の主題ではありません。ここではスクラムと認定の利点に集中し、品質管理やプロセス改善の標準を、時代遅れの代替手段として扱う意図はありません。
ただし、スクラム以前の改善フレームワークは、段階的な方法で導入されていました。私たちはそれを次のように呼んでいました。 ウォーターフォール型ソフトウェア開発モデル.
このモデルでは、各プロジェクトは顧客のニーズと要望を把握する要件分析から始めることになっていました。
次に設計、実装、テスト（検証）、本番環境での保守を行い、開発ライフサイクルの終わりに達しました。
しかし、現実はそのとおりには進みませんでした！
ある段階の予想外の遅れは、その後の段階にも必ず悪影響を与えました。
それがスクラム以前の姿でした。
認定を持つ専門家の指導なしに、ソフトウェアをチーム間で何度も受け渡しし、仕事は官僚的で複雑、非生産的になりました。
結局、製品だけでなく、社員の意欲と組織の使命への確約も完全に損なわれました。
認定がない場合の混乱と不満の第2要素：チーム間の確約、変更管理、協力の規律の欠如
スクラム以前のプロセス改善の枠組みの最大の弱点は、次の点でした。 主に、指導部の自己都合による組織上の要求に集中していました。
監視、規則への準拠、予測可能性などが、その要求でした。 顧客への良い対応や、社員の意欲向上には全く目を向けていませんでした。
そのため、ソフトウェア管理チームや社内外のさまざまな関係者は、提供プロジェクトの締め切りを固定し、開発の各段階の進捗を簡単に監視しようとしました。
計画から外れると人を罰し、予定した完了日までに、現れた問題を解決できることを期待しました。
独立した縦割りの部門が、完全に分離した開発工程を担当しました。例えば開発とテスト（検証）は完全に独立し、同じ使命のために働くはずの人々が、互いの名前さえ知らないことが多かったのです。
組織が、事業の使命や従業員の職業人としての成熟よりも、このような縦割りの考え方を重視した理由は何でしょうか？
理由は単純で、 マトリクス管理です。マトリクス管理は、組織の管理と人員配置の仕組みで、1970年代から使われてきました。一見すると、その発想は賢明に見えます。
指導部は、似た職能や技術を持つ社員を同じ、良くても隣接する縦割りの部門に集め、組織を作ります。
当時は、独立・自律した部門である「コンピテンスセンター」が、企業でよく見られました。
C++開発者の部門、データベース管理者の部門、海外の完全に独立した品質保証部門と、分割は延々と続きました。驚くような状態でした。
マトリックス組織の最大の課題は、スクラムやマスターなしに仕事を届けるため、プロジェクトマネージャーが各部門から社員を一時的に借りなければならないことでした。
社員はチームと同じ場所にさえおらず、自分のセンターの部屋にいたままでした。
完了すると臨時チームは解散し、参加者は別のプロジェクトの次の任務へ移りました。
そのため、進行中のソフトウェアプロジェクトが目指す事業価値は、独立した各部門にとって、最優先にはなりませんでした。
自分の仕事を、こちらのプロジェクトで一つ、あちらのプロジェクトで一つと、チェック欄を埋めるように捉える傾向がありました。
リーダーとマトリクス組織モデルは、専門家として、売上、収入、利益を含む最終的な業績の向上に、どう主体的に取り組むべきかを教えませんでした。
McKinsey & CompanyによるMcKinsey Quarterlyの記事も、この点を明確に示しています。 マトリクス組織を超えたコスト最適化の幻想.
元の記事は、世界の年間の次の費用について、Gartnerの推計を引用しています。 ITシステムの復旧に6,000億米ドルを費やしている と推計しました。予定外の保守作業と不具合への対応です。
ここで少し、変更管理と障害への対応がどう行われたかを思い描きましょう。 ウォーターフォール、マトリックス組織、スクラムなしという構成で、どう行われたのでしょうか。
そう、そのとおりです。 経営者と社員は、 変更管理、障害やエラーへの対応 を、そもそも起きるべきではない厄介な例外と見なしていました。
変更は遅延の代名詞となり、連鎖的な遅れを生みました。不具合や障害で責任を押しつける相手を探しました。
さらに、各部門には、誤りに対処し、修正し、学ぶ仕組みがなかったため、同じ失敗を繰り返しました。
さらに、次のものを増やし続けました。 技術的負債 。
認定がない場合の混乱と不満の第3要素：独裁的な判断が民主的な判断を覆した
スティーブ・ジョブズは、こう語りました。
「優秀な人を雇って、何をすべきか指示するのは意味がない。私たちは、何をすべきか教えてもらうために、優秀な人を雇う。」
しかし、これはスクラム以前の一般的な指導部の意思決定とは、正反対でした。
スクラム以前は、指導者の独裁的な判断が、チームの集合知を覆していました。
実際の仕事を担う集団の、民主的な意思決定の力を無効にしていました。 。その仕事は、構想から運用まで、ソフトウェアエンジニアリングの全ライフサイクルに及んでいました。
影響を受ける現場のチームから判断が遠ざかるほど、使命を左右する正しい判断は難しくなりました。
リーダーの判断は、衝動的で、十分に考えられていないことが多く、たいていは遅く、曖昧でしたが、時には早すぎることもありました。
こうした 独断的な決定 を上から押し付けられ、従業員は自分が軽視されていると感じました。競争上の事業やソフトウェアの課題に対し、創造的で革新的な解決策を生む組織の力を、完全に妨げました。
また、意見を求めるときでさえ、開発チームが判断に意見を出す意欲をくじいていました。
以上が、スクラムを採用する前の開発・提供の簡単な概要です。次に、スクラムで混乱と不満をどう解消したかを見てみましょう。
スクラムとは？
この節をスクラムのあらゆる疑問に答える決定版にする意図はありません。ただし、初心者から中級者の多くに、深い理解への良い出発点を提供します。
より高度で実用的に、素早く学びたい方にも用意があります。次をお勧めします。 こちらのリンクから、スクラムのガイドをダウンロードしてください。
スクラムとは何でしょうか。複雑にせず定義すると、次のとおりです。
スクラムは、複雑な問題に適応的な解決策を用いて価値を生み出す、軽量なフレームワークです。反復的・段階的なソフトウェア開発は、その重要な用途の一つです。
主な焦点はソフトウェアですが、反復的でアジャイルなスクラムは、他の業界にも適用でき、既に使われています。
IT業界では「Scrum」が2000年代初めに、アジャイル開発・提供の流れとともに生まれた言葉だと思う人が多いのですが、それは誤りです！
1986年1月のHarvard Business Reviewの記事は、後のスクラムに先行する製品開発の方法を紹介しました。竹内弘高氏と野中郁次郎氏による「The New New Product Development Game」です。（そう、Newが二つです）
ぜひお読みください。 「The New New Product Development Game」 スクラムの始まりが分かります！
IT業界でスクラムを話す際、「アジャイルスクラム」もよく聞きます。そのため両者の違いを探す人もいます。
良いお知らせです。「アジャイルスクラム」と「スクラム」は同じもの、スクラムの開発プロセスを指します。では、なぜ前に「アジャイル」を付けるのでしょうか。
スクラムが全面的に受け入れ、組み込んでいるためです。 アジャイルソフトウェア開発宣言（アジャイルマニフェスト） を、基本のプロセス、原則、哲学に組み込んでいます。技術的な詳細に入る前に、宣言とスクラムの価値を理解しましょう。
アジャイルソフトウェア開発宣言（アジャイルマニフェスト）
アジャイルソフトウェア開発宣言の価値観：
- プロセスやツールよりも、個人と対話を重視する。
- 包括的なドキュメントよりも、動くソフトウェアを重視する。
- 契約交渉よりも、顧客との協力を重視する。
- 計画に従うことよりも、変化への対応を重視する。
右側の事項にも大きな価値はありますが、宣言では左側をより高く評価し、優先します。
宣言が重視する要素は、時間をかけて確かめ、慎重に選ばれたものです。その目的は次のとおりです。
- ソフトウェアを通じて、顧客とステークホルダーへより良いサービスと価値を届ける。
- 役割、肩書、キャリアの段階にかかわらず、ソフトウェア開発という専門分野をより良くする。
スクラムの価値
既にお伝えしたとおり、スクラムは開発プロセスだけでなく、強固な基本原則も持っています。
実際、ほとんどのビジネスの専門分野で、その原則を活用できます。
大きな成功には認定取得だけでは不十分です。スクラムの価値をしっかり理解する必要があります。
そうすることで、顧客と雇用主が喜ぶ、素晴らしい仕事とソフトウェアを届けられます。 ここで、その原則を詳しくお伝えします。
勇気
顧客に最高の価値と利益を届ける正しい行動が、最も簡単とは限りません。そんなとき、マスター、オーナー、メンバーは責務を思い出すべきです。
担当する事業とITの分野で、可能な限り最良のプロダクトとサービスを作ることです。平凡な水準を超えるには、 チームは遅かれ早かれ、関係者全員を満足させることのできない難しい判断に直面します。
そのために、全員が認定の研修で学んだことを思い出す必要があります。
勇気を持つことを思い出し、勇敢に判断して行動する力を身につけるのです。
集中
「集中」という価値を聞いたら、次の二つを考えてください。
- 正しい仕事の特定： ゴールの達成に必要なタスクは何か。顧客が喜ぶ最高の製品やサービスを開発するために、何が不可欠か。
- 優先順位付け： 次に取り組むべきことは何か。
その時々に、マスターとオーナーを含む全員が答えるべき重要な質問があります。 「雇用主がそもそも私たちを採用した理由を満たすため、今すべき最も重要なことは何か？」という質問です。
スクラムには、ストーリーとタスクを適切に優先するためのイベントがあります。関連タスクを含む優先順位付けを、常に重視します。
こうして、正しい仕事を正しい順序で行います。 正式なイベントと関連するリファインメントは、集中の方向を検査し、仕事を適応させる助けになります。
- スクラムグルーミングミーティング： リファインメントは、今後のバックログ項目を明確化・分割・見積もりし、順序の判断にも役立ちます。会議は、この継続的な活動を行う一つの方法です。
- スプリントプランニング： ストーリーを届けるための、依存関係と正しい順序を理解する助けになります。
- デイリースクラム： デイリースクラム（デイリースタンドアップ）は、一日の方向を定める助けになります。最も必要な所へ集中を向けなければなりません。
- スプリントレビュー： レビューは、今後のレビューをより成功させるため、チームがどこに注力すべきかを間接的に示します。
- スプリントレトロスペクティブ： これらの会議は、開発プロセスの何を先に改善すべきかを決める助けになります。
ここでは集中の観点だけで会議を説明しました。詳しくは、 この記事の後半のスクラムの会議の説明をご覧ください.
ここまでで、優先順位付けと集中の大切さが明らかになったでしょう。
確約
マスター、オーナー、チームの確約がなければ、ソフトウェアで優れた成果を出すことはできません。
多くの人は、確約を、特定のスプリントで届ける成果の目標への合意と拘束と解釈します。
理にかなった理解ですが、それだけで完全とは言えません。 著者は献身を強調するため「執着」という言葉を使います。スクラムの確約は、チームの目標と相互支援に関わるもので、過労や、予測したすべての項目の完了を確実にすることを求めません。
開発、人生、事業で成功するには、目標に強くこだわる必要があります。したがって、スクラムでは、 顧客の問題を解く、素晴らしいソフトウェアづくりへ、強いこだわりを持つべきです。
なぜ確約とゴールへの強いこだわりが重要なのでしょうか。優れたソフトウェアを作って届ける使命への熱意がなければ、簡単ではない障害に出会うたびに、仕事は遅くなり、止まってしまうからです。
そしてマスターとチームは、ゴールを届けられない理由をオーナーに正当化する説明を作り始めます。 平均以上を目指すなら、言い訳をする余地はありません。
非常に強い献身があってこそ、顧客の問題を解決し、ソフトウェアで価値を生む仕事が、より取り組みやすく、充実したものになります。
尊敬
年齢、性別、人種、信念、経験、能力、意見、業績にかかわらず、全員が互いを尊重し、頼りにしなければなりません。
尊重はチーム内にとどまりません。関わる社内外のIT・事業の関係者も、十分に尊重し、歓迎します。
経験豊かなメンバーは、経験の浅い人の貢献意欲を否定しないよう注意すべきです。
多数が同意しない反対意見を、適切に受け止め、答えることは特に重要です。
公開
「公開」は、平均的なチームと高い成果を出すチームを分ける主な要因の一つです。心を開いた個人が集まる、大きな力として捉えてください。
創造的で革新的、知的で正直、率直で謙虚な人々です。 スクラムでは、課題と異なる見方を率直に話せるべきです。ただし公開は、すべての判断や行動を適切にするわけではなく、尊重、品質、ゴールは依然重要です。
条件は、透明であり、共同の使命への貢献を目指すことです。
すべての判断や行動が、必ず成果を加速し、大きな成功物語につながる必要はありません。
公開と勇気により、開発グループは間違いを恐れません。 間違いや最善ではない結果を、生産性と品質を意味ある形で高める、大切な機会と捉えます。
スクラムの主な構成要素
スクラムチームは、一人のプロダクトオーナー、一人のスクラムマスター、開発者から成り、三つの異なる責任があります。この記事の従来の「スクラムチームメンバー」は開発グループを指し、第四の責任や別のチーム全体ではありません。
世界中の受講者に提供する、ほかのプログラムに加えて、 International Scrum Institute™ は、これら三つの役割のための、主要な研修・認定プログラムを三つ提供しています。
これらのプログラムは、 Scrum Master Accredited Certification™ (SMAC™), Scrum Product Owner Accredited Certification™ (SPOAC™)、そして、 Scrum Team Member Accredited Certification™ (STMAC™).
適切な組織は、三つの技能を持つ人材を十分に備える必要があります。スクラムで成功するために、特に重要です。
各責任を果たす必要があります。責務は別々ですが、オーナーやマスターも、スプリントバックログの仕事をする際は、元の責任を保ちながら開発者として貢献できます。
一つの製品に取り組む複数チームは、一人のオーナー、一つのプロダクトゴール、バックログを共有します。各チームにマスターの責任と有効な支援が必要ですが、一人が一チームだけを支援するという規定はありません。
これらの役割の目的と機能を理解し、適任者を置く大切さを軽視しないでください。難題の根本原因は、役割への理解不足や、人材が適切でないことがよくあります。
三つの役割を見ていきましょう。
三つの役割：スクラムプロダクトオーナー
スクラムプロダクトオーナーは、 価値を最大化するようバックログを並べ、関係者と製品やリリースを判断します。開発者はスプリントで完了を予測する仕事を選び、リリースの形は製品の状況によります。オーナーは利用者の機能・非機能要件を代表します。
従来のプロジェクトマネージャー、プログラムマネージャー、プロダクト管理の役割より、はるかに幅広い役割です。
製品とプロジェクト管理の仕事を統合し、開発・提供とも密接に結び付きます。
主な仕事は、次のとおりです。
- プロジェクトの要求を管理し、明確にする。
- リリースを導き、投資収益率（ROI）を確保する。
- チームと密に協力すること、
- 関係者を管理すること。
三つの役割：スクラムチームメンバー
スクラムチームは、 ソフトウェアを実装します。開発者は、次の期間に完了できると予測する仕事量を選びます。 スプリント。スプリントは固定長のイベントで、その間に作る使用可能な成果は、完成の定義を満たすインクリメントです。
高い成果を出すチームは、必要な開発技能の大半を備えます。開発者、設計者、テスター、データベース管理者など、様々な役割の人が協力します。
顧客が対価を支払う、優れたソフトウェアを共同で作り、届けます。
メンバーは、マトリックス組織の職能別部門に属するのではありません。開発者が開発センターに、テスターがテストセンターに属する、といった形ではなくなります。
以前の組織上の所属を問わず、各人は自分のスクラムプロジェクトに属します。仕事は、オーナーの要件を届ける、可能な限り優れたソフトウェアを作ることです。
チームの特徴は、次のとおりです。
- 権限を与えられている、
- 自律的、
- 職能横断的、
- 自己組織化している、
- 小規模、
- 十分な参加時間を確保している（専任は一般的な組織上の選択）、
- 同じ場所でも分散していても、密に協力できる、
- 一人は皆のために、皆は一人のために。
三つの役割：スクラムマスター
スクラムマスターは、 参加者と外部関係者がスクラムを正しく理解・適用できるよう奉仕します。実践を支え、生産性と成果の継続的な改善を助けます。
役割は、スクラムのプロセスと、新しい考え方・行動を根付かせることです。
変革を促す人として、新しい規範や標準を作るよう指導します。いつでも相談できるようにします。物理的な近さは役立ちますが、必須ではありません。
主な責務には、次があります。
- 事業とITの環境にスクラムを根付かせる、
- 価値を理解し、実践するようチームを指導する、
- オーナーとチームの密な協力を確保する、
- 障害を取り除く、
- 奉仕によって導く、
- 有効なイベントを支え、必要なら進行を助ける。ただし、デイリースクラムの主体は開発者であることを守る。
プロダクトバックログ（スクラムバックログ）
プロダクトバックログ、スクラムバックログ、スクラムプロダクトバックログ は、既知のすべての要件を管理する中心的な要素です。
成功に必要な顧客要件と作業項目をすべて含みます。機能・非機能要件や、次に関わる特徴などです。 ユーザーエクスペリエンス や ユーザーインターフェース 設計。
機能要求と、その概要レベルの次のものを含みます。 ユーザーストーリー。テスト・開発環境の構築など、前提や補完的な要件も含められます。不具合の解消、技術的負債の軽減、機能改善のストーリーも入ります。
製品ごとにバックログを持ち、オーナーが作成、維持、調整に責任を持ちます。 要件をどう開発して届けるかを、バックログが答える必要はなく、答えるべきでもありません。
それはチームの責務です。要件に応えるタスクを決め、スプリントバックログに記録します。 両バックログは別の作成物ですが、物理的に別の文書やツールとは限りません。プロダクトバックログの項目が、スプリントバックログの内容を導きます。
プロダクトバックログは、生きた文書です。 ソフトウェアの段階的な改善と同様、学びに応じて追加、削除、並べ替えが行われます。 スクラム自体は別の変更管理を要求しません。オーナーは、当初の最善の理解に基づいて初版を作ります。
各スプリントで製品の成長を観察し、顧客要件の知識が増すにつれて、項目を追加・削除・調整します。
オーナーは、バックログの要件に優先順位を付けます。 優先度が高いほど詳細を充実させ、チームが容易に理解し、必要なタスクを作れるようにします。
さらに、次のような見積もり手法を用い、 ストーリーポイントなどで定期的に要件を見積もります。優先度の高いストーリーは見積もりを調整・改善し、プランニングに備えます。
スプリント
要件を実装するすべての活動は、スプリント内で行われます。 スプリントは、出荷可能なソフトウェア製品やサービスのインクリメントを開発するための、作業のサイクルです。 スプリントは、イテレーションとも呼ばれます。
小さなプロジェクトと考えられます。名称のとおり短く、長さは一か月以内です。四週間は一般的な例で、暦上の厳密な最大長ではありません。
競走と違い、終了時に息切れし、力尽きてはいけません。元気を保ち、次を活力を持って始められるべきです。
スクラムは、メンバーに圧力やストレスを与えるためのものではありません。集中し、安心して、邪魔されずに働くとき、人は最高の力を発揮します。正しく適用したスプリントは、それを実現する助けになります。
各スプリントは、次から始まります。 スプリントプランニングミーティング。プランニングで何をどれだけ実装するかを決め、その要件を届ける活動を始めます。
デイリースクラム（デイリースクラムミーティング） は、各稼働日の同じ時刻に、同じ場所で行います。 開発者は、ゴールへの進捗を検査し、翌日の計画を適応させます。 進捗を遅らせたり止めたりする障害の除去を、マスターに依頼することもできます。
レビューとレトロスペクティブで、スプリントを締めくくります。 スプリントレビュー では、チームと主要関係者が成果とプロダクトゴールへの進捗を検査し、今後の適応を話し合います。作業の場であり、オーナーの承認を得る関門ではありません。
その スプリントレトロスペクティブ, チームは、協力の仕方、スクラムの使い方、改善方法を振り返ります。
そして、次のプランニングで、改善の可能性と意見を共同で考慮します。 スプリントは、少量の作業を短い期間で進めることで、こうしたフィードバックの循環を可能にします。 これは、スクラムの枠組みが、チームと組織の継続的改善を支える重要な理由と、その仕組みの一つです。
スクラムの検査と適応
検査と適応は理解しやすい一方、正しく実践し、習得するのは最も難しい概念です。
企業は、複雑なシステムの全体像を完全に予見できるマネージャーはいないと、ついに認めました。信頼できる全体計画を立てられず、別の方法が必要なのは明白でした。
次のものとともに、 リーン生産方式 （別名： リーン運動）、企業には、戦略的な力を与えるプロセスの開発が必要でした。 プロジェクトや日々の運営の途中で学び、進め方を修正できる標準的な手順が必要でした。
こうして生まれたのが、 トヨタの改善の型で、スクラムの検査と適応を考える際の有用な比較になります。目的は関連しますが、単にスクラムの経験主義の柱の別名ではありません。「スクラムの検査と適応」では、次のように考えます。
- 手順1. 検査： 現時点の知識と理解を使い、プロジェクトの現状の把握に全力を尽くします。
- 手順2. 適応： 次の段階の方向とビジョンを定め、戦略を立てて実行します。
- 手順3. 学習： 注意深く観察し、学び、教え合います。仕事の中で、うまくいくことと、いかないことを継続して記録します。
- 手順4. 再開： 再び手順1から始めます。
以下の四段階は説明のための比喩で、各イベントと一対一に対応する定義ではありません。検査、適応、学習はスプリント全体で起こります。
- 手順1. 検査 は、レビューとレトロスペクティブにたとえられます。
- 手順2. 適応 は、プランニングにたとえられます。
- 手順3. 学習 は、デイリースクラムにたとえられます。
- 手順4. 再開 は、一つのスプリントの終了と、次の開始にたとえられます。
自己組織化
チームは自ら組織化します。ゴールに必要なタスクを合意で決めます。自己組織化したチームには、マネージャーやリーダーは不要です。
スクラムの自己組織化は、非常に規律あるものです。
スプリントバックログ や デイリースクラム は、自己管理を支えます。 スプリントバーンダウンチャート は、進捗を可視化する任意の方法の一つです。
多くのチームには、自ら仕事を組み立てる学習期間が必要です。認定を持つ有能なマスターは、早く優れた自己組織化を実現できるよう支えます。
自己組織化には、意見の違いや対立があっても協力する力が含まれます。共同の意思決定プロセスを守り、信頼する必要があります。
そのプロセスには、共同で責任を負う仕事の計画、見積もり、実装、報告、レビューなどが含まれます。
スクラムのイベントと継続的なバックログのリファインメント
イベント1. スプリントプランニング（なぜ・何を・どうやって）
その スプリントプランニングミーティングで、実行可能なスプリントバックログを作り、その間に実装する要件を定めます。
プランニングでの各役割の責務は、次のとおりです。
- オーナーは、なぜそのスプリントに価値があるかを提案します。全員でゴールを考え、開発者は完了できると予測する項目を選びます。
- チームは必要なタスクと見積もりを特定します。開発者は、過去の実績、余力、完成の定義を踏まえ、何をどれだけ完了できると予測するかを決めます。
- マスターは会議を進め、自己組織化と自律的な判断力を損なわないようにします。
プランニングにオーナーの出席は必須です。 質問に答え、要件と受け入れ基準を明確にするためです。
利用者やマネージャーなどを、助言のために招くこともできます。 招かれた人は助言を提供しますが、進め方についての開発者の判断を代行しません。
イベント2. デイリースクラム（デイリースタンドアップ）
この デイリースクラム は、最大15分の会議です。各稼働日の同じ時刻、同じ場所で行います。スプリントバックログとバーンダウンチャートを直接見られる場所が最適です。 そうすれば、スクラムチームの全員に見える事実と進捗を基に、デイリースクラムを進められます。
デイリースクラムは、スクラムチームの自己組織化を支え、障害を体系的に見つけることを目指します。
開発者のためのイベントです。バックログの仕事をするオーナーやマスターは、開発者として参加します。他の人の参加は、開発者の集中と自己管理を守る必要があります。全役割や関係者の参加は必須ではありません。
開発者は、ゴールと具体的な計画に集中できる構成を選びます。次の三問は、よく知られた任意の形式であり、現在のスクラムが定める質問ではありません。
- デイリースクラムの質問 #1. 前回のデイリースクラム以降、どのような活動をしましたか？
- デイリースクラムの質問 #2. 次のデイリースクラムまでに、どのような活動を行う予定ですか？行動計画は何ですか？
- デイリースクラムの質問 #3. 作業の進捗を遅らせたり、妨げたりする障害に直面しましたか？または、そのような障害が予想されますか？
デイリースクラムは、開発者自身が進めます。 マスターは必要に応じて、目的と有効性への理解を助けます。イベントは15分で、三問の形式は任意です。
時間のかかる意思決定や問題解決は、目的に含まれません。 判断の調整や問題解決には、必要に応じて別の会議を設けます。通常はデイリースクラムの後に開きます。
マスターは、特定した障害と日付を、チームが見られる別の記録、フリップチャート、報告に残します。私は会議の最後に、未解決の障害の状況を簡単に更新するのが有益だと感じています。
イベント3. スプリントレビュー
この スプリントレビューミーティング は、スプリントの終わりに行います。一〜二時間が適する場合もありますが、正式な上限は一か月のスプリントで四時間で、短いスプリントでは通常短くなります。ソフトウェアと設備に応じ、会議室、実験室、チームの部屋で行います。
目的は、期間中に作った出荷可能なインクリメントを見直し、開発の透明性を高めることです。
チームは成果を実演し、関係者と達成事項や環境の変化を話し合います。成果を検査し、次の行動を考える場で、固定された約束のタスク一覧に照らす遵守確認ではありません。
レビューでは、チームと関係者が成果を検査し、バックログを適応させます。次のゴールは、その後チーム全体で考えます。したがって、 レビューは、「検査と適応」の正式で実用的な実践です。
参加者は、チーム、オーナー、マスターです。利用者、顧客、事業担当者など、他の関係者も任意で参加できます。
実演されたインクリメントへの意見を伝えられます。 こうして、ソフトウェアを作っている相手から、直接、加工されていない意見を得られます。
イベント4. スプリントレトロスペクティブ
この スプリントレトロスペクティブ はレビューの後に行い、スプリントを締めくくります。一か月のスプリントで最大三時間、短いスプリントでは通常短くなります。
目的は、メンバーの協力とスクラムの実践を改善することです。
その結果、生産性、各人の成果、ソフトウェア品質が高まります。
小さな事後検証のようなもので、改善の可能性を特定し、プロセスの障害を除きます。よく見られる例は、次のとおりです。
- アジャイルなソフトウェア開発の実践を取り入れる。たとえば、 エクストリームプログラミング（XP） または テスト駆動開発（TDD）.
- 新しいチームの規範と原則の特定、または
- プロダクトオーナーとやり取りできる時間を増やす。
例外なく、毎回のスプリントの終わりに実施します。 それによってのみ、プロジェクト固有の状況に応じ、使い方を体系的に適応・改善できます。
関連する実践：プロダクトバックログのリファインメント（グルーミング）
スクラム バックログのリファインメント（グルーミング）ミーティング は、バックログを最新に保つことを目指します。 進行中のプロジェクトについて、チームの最善の知識と理解を反映できるようにします。
必要に応じて、または予定を組んで話し合います。週二回、各30分は実例の一つで、必須の頻度や上限ではありません。オーナーと開発者が協力し、有用ならマスターや他の人も関わります。
参加者は、次の行動でバックログを調整します。
- 新たに見つかった要件から、ストーリーを追加する。
- 不要になったストーリーを除く。
- ストーリーの見積もりを調整する。
- 優先順位を更新する。
- 巨大なものを理解しやすく小さく分け、優先順位を付ける。
認定を取得する四つの簡単な手順
認定取得は、簡単で速く、すべてオンラインで行えます。
次の機関のおかげで、 International Scrum Institute™以前より速く、経済的に認定を取得できます。
認定を取得する四つの簡単な手順は、 スクラムマスター認定 時間やお金を無駄にせず、手間もかからない、次の方法です。
-
手順 #1. オンラインで登録
次を使ってオンライン登録してください。 Scrum Master Accredited Certification™ 登録ページ。
登録後、International Scrum Institute™ が、試験アクセスコードをオンラインで即座にお届けします。
次のリンクから、 スクラムマスター認定プログラムに登録.
-
手順 #2. オンラインで学習
次を使ってオンラインで学びます。 スクラム学習ガイド、The Scrum Framework™.
The Scrum Framework™ は、完全な実践志向を目指して作られています。有能なマスターとして、仕事とキャリアの日々の課題に対応する助けになります。成功するマスターの一日を示す事例や実例が豊富です。
次のリンクから、 The Scrum Framework™ の無料版を申し込む.
-
手順 #3. オンラインで認定試験を受験
The Scrum Framework™ を注意深く読み、学び、理解すれば、準備は完了です。試験合格への十分な自信を感じられるはずです。
次のリンクから、 スクラムマスター認定試験へ進む.
-
手順 #4. 認定を取得
合格すると、すぐに認定をお届けします。
雇用主と顧客は、雇用主向け認定検証ツールで真正性を確認できます。次のリンクから、 雇用主向けスクラム認定検証ツールへ進む.
スクラムマスター認定についての私の結論
ここで振り返りましょう。段階別ガイドをすべて読めなかった方にも、認定取得の利点と注意点について、私の考えを整理してお伝えします。
利点
社員、フリーランス、コーチ、講師の利点
- 認定は、スクラム分野の能力と最新の知識を認める証となります。
- 自己研鑽をやめた同業者に差を付け、認定と実績を備えたマスターとして、夢の仕事への採用を助けます。
- 視野を広げ、継続的な学習へ心を開き、責任の拡大と素晴らしいキャリアの機会を得る助けになります。
- 顧客と雇用主に喜ばれる優れた製品・サービスを届ける、新たな道具一式が身につきます。
組織と雇用主の利点
- チーム、活動、プロセスの効率を高め、費用を削減します。
- 訓練された有能な社員により、それまで獲得できなかった案件の受注を助けます。
- 研修と技能開発を促し、社員の満足と確約を高めます。
- 成果物の品質と顧客満足、最終的には組織の成功と収益性を高めます。
注意点
-
認定で学習を止めないでください。取得は、最初の一歩にすぎません。
学んだ「検査と適応」の精神で、実験し、観察し、学び続けるのは、引き続きあなたの責務です。
-
世界中の組織すべてに合う万能策はありません。スクラムも例外ではありません。
私たちの観察では、スクラムの最高の成果を得られない組織の多くに、共通点がありました。自社の事業とITの環境に、スクラムを適応できていなかったのです。
「検査と適応」の精神で、スクラムを100%成功を保証する処方箋とは考えないでください。事業とIT固有の力学に合わせる、自らの思考力を軽視しないでください。報酬を受ける専門家として、最大の処理能力と事業成果を得るため、まさにそれが求められています。
-
スクラムは、IT部門のすべての問題を解決したわけではありません。学びを止めず、 DevOpsなど、新たに登場する開発・提供のプロセス。
スクラムの既知の弱点とDevOpsの対応を理解するには、後で次の記事をお読みください。 DevOpsとスクラムの重要な6つの違いとは？
認定は、アジャイル開発・提供の実践を始める優れた方法です。
Gartnerの調査 「より良いスクラムマスターになる」 2019年に公開されたこの記事の2023年についての予測は、 世界の企業の92%、米国の企業の96%がアジャイルスクラムを採用するというものでした。元の記事が示した予測であり、現在の導入率の実測ではありません。
ですから、今こそ、
残る問いは、いつ始めるかだけです。