スクラム開発の基礎知識
現代はIT系企業が躍進し、ソフトアウェアの開発を行う企業は数多く存在します。
その現場においては、『ウォーターフォール開発』と呼ばれる開発手法と、21世紀前後のタイミングから多くの企業が採用し始めた『アジャイルソフトウェア開発』という手法の2つがあります。この2つはよく比較されることが多いのですが、比較をするようなものではありません。
そもそもアジャイルとは、開発手法のことではありません。アジャイルという概念であり、会社、組織、チームの状態のことです。アジャイルは、組織が、『常に改善し続ける状態』であることを表します。スクラムを実践したからといって組織がアジャイルになっている訳ではありません。ウォーターフォールという開発手法をとっても、アジャイルになることは可能です（構造上なりにくいですが）。そこで働く人々が、常に改善しつづける状態を目指し、仕事をしていればアジャイルなのです。常に改善をしつづけるということは、言葉で言うのは簡単ですが、非常に難しいことです。日々の仕事を常によりよく・楽しく・学びながら変えていくということです。アジャイルな組織は、適応力があり、変化を喜んで受け入れ、学び続けるという性質を持っています。あなたの組織はアジャイルでしょうか？
ウォーターフォール開発とは、滝の水の流れのように上流から下流に向けて開発工程を分け、作業が前の段階に逆戻りすることNGとする手法です。逆戻りができないことから、前工程をかなり高い精度でしあげてから後工程へ進む必要があります。
一般的にソフトウェア開発の場合、計画・要求分析・要件定義・設計・実装（プログラミング）・テストの順に進めますが、この流れを順次式に進めます。実装工程で要求分析に間違いがあったと発覚した場合でも前へ戻らず、作りきる必要があります。
ただ、ほとんどの開発現場で、前工程へ戻らない、ということはないです。ユーザの求めるもの、作りたいものが計画段階で明らかになっていることはほとんどありません。また、ウォーターフォールでは、各工程を異なる人物・チーム・別会社が担当することがよくあります。
先の例だと、下記のように分かれます。
- 計画はプロジェクトマネージャー
- 要求分析・要件定義は、ビジネスアナリストと開発リーダー
- 設計・実装（プログラミング）は、開発リーダーと開発メンバー
- テストは、テスターまたはQA（Quality Assurance担当）
各工程で引き継ぎが発生するので、詳細をドキュメント（設計書）に残しておく必要が出てきます。ウォーターフォールだと顧客は開発に参加しないことが多いです（参加してもドキュメントしかレビューができないので、うまみが少ないため）。
アジャイルソフトウェア開発においては、固定されたチームが目的の達成のために、顧客も含めて協力しながら開発を進めていきます。工程毎に異なる人物・チームが担当しないです。
また、プロジェクトマネージャーも存在せず、プロジェクトマネージャーが担当していた仕事をプロダクトオーナーと開発チームで分散します。『イテレーション』、またはスクラムにおいては、『スプリント』と呼ばれる期間（1週間から最大4週間）を区切り、少なくともスプリント毎に『動くソフトウェア』を顧客・ステークホルダー・プロダクトオーナーとレビューします。
顧客・ステークホルダー・プロダクトオーナーと開発チームとのコミュニケーションはより密になり、顧客の欲しいものを実際に動くソフトウェアをベースに議論できるようになります。
スクラム開発とは
そのアジャイルソフトウェア開発の中の一つの方法が、スクラム開発です。スクラムというとラグビーをイメージする人もいるでしょう。まさにスクラムを組んでチームが一つとなって開発に取り組むことからこの名が付けられました。
スクラム開発では、チームのメンバー自身で計画を立て、開発に進行過程に問題がないかどうか、プログラムは正しく動いているかどうかなどをチェックしていきます。
そのため、メンバー間のコミュニケーションが不足してしまうと、さまざまなトラブルが発生してしまうことが予想されます。チーム全体のコミュニケーションこそが、スクラム開発の肝となっているのです。
スクラムは、現状を把握するためのフレームワークと呼ばれています。スクラムを実施したからといって、生産性があがる、コミュニケーションが勝手によくなるということはありません。
適切に運用することによって、現状の問題が炙り出されます。改善をはじめられる土台が築き上げられます。そこから改善をどうしていくかは、スクラムを運営するスクラムチームのパッションにかかっています。
スクラム開発の流れ
スクラム開発の流れとしては、以下のような過程が存在します。
まずは、開発すべきソフトウェアが要求されている機能とその優先順位を可能であれば顧客・ステークホルダーとともに議論し、荒くていいので一覧化します。これをプロダクトバックログと言います。
一覧化した個々の要素を、プロダクトバックログアイテムと呼びます。続いて、プロダクトオーナーと開発チームは、完了の定義(Definition of Done/DoD)を決めます。完了の定義から、固定されたスプリント期間を決めます。続いて、直近数スプリント分のプロダクトバックログアイテムを詳細化します。
スプリントは、固定された期間です。1週間なら1週間をずっと続けます。2週間なら2週間です。スクラムでは最大4週間のスプリントまで許容しています。
その後の流れとしては、優先順位が高いプロダクトバックログアイテムをプロダクトーナーと開発チームが合意のもと、開発チームが選択します。プロダクトバックログアイテムをタスクに分解し、スプリントを開始します。
プロダクトバックログアイテムをタスクに分解する日をスプリントプランニングと呼びます。スプリント終了日には、プロダクトオーナー主導のもと、顧客・ステークホルダーがスプリントレビューを行い、プロダクトバックログを更新します。
最後に開発チームはスプリントレトロスペクティブと呼ばれるふりかえりを行います。
スプリント期間中は、デイリースクラムと呼ばれる毎日の15分以内のミーティングを開発チームは実施、スプリント内の計画との乖離がないか、あった場合どうするのか、他に困っていることがないかを相談し、方針を絶えず決め続けます。
このデイリースクラムの結果、選択したプロダクトバックログアイテムが実現できないなど、必要であればプロダクトオーナーにも相談します。
バックログとは
スクラム開発においては、2種類のバックログが重要な役割を果たします。
1つめが『プロダクト・バックログ』です。これは、ソフトウェアの機能や改善要素の優先順位を記載したもので、開発がどこまで進んでいるかが一目で分かるものです。
そして2つめが『スプリント・バックログ』です。選択されたプロダクト・バックログアイテムから、開発チームがタスク分解したものを見える化したものです。スプリントプランニングで、この作業を行い、選択したプロダクトバックログアイテムがそのスプリントでやりきれるかどうかを開発チームは判断します。
やりきれないことが発覚した場合は、プロダクトーナーと相談します。スプリントバックログは、チームの現時点の状況を瞬時に把握できるものとなっている必要があります
完了の定義(Definition of Done/DoD)とは
プロダクトをリリースできる（顧客に届く）ところまでの、今現在わかっているすべての"やるべきこと"を洗い出し、その"やるべきこと"がスプリント内でできる(DONE)のか、できないのか(UNDONE)を明確に定義したものです。スコープは主にテクニカル品質（非機能品質）になります。
スプリント内でできるものであれば、それを開発チームが必ず実行する、実行するときの明確な定義を開発チーム・プロダクトオーナーで共有し、確認し合います。
例えば、ソフトウェア開発でDONEの例であれば、ソースコードがコード管理システム(CMS)にコミットされていること、静的解析のAランク指摘が0件であること、などです。
このDONEによって、スプリント期間(1週間～4週間)が決まることが多いです。開発チームが、一つのストーリーをDONEするために、やるべきことが物理的に1週間で収まり切らない場合は、2週間スプリントにします。
UNDONEの例としては、アプリのストア申請と承認、ヘルプファイルの作成、外部認証期間における認証テストなどがあります。開発チーム外が実施する作業が多くでます。
スプリント内でできない（UNDONE)が明確になった際には、おおよそのUNDONEをするために必要な期間、誰が（開発チームなのか、外部なのか）どうやるのかを明確にしておき、スプリントの期間外で実施するのか、UNDONEを潰すためのスプリントを用意するのかを、スクラムのスプリントを開始する前に、プロダクトオーナーは開発チームとともに明確にしておかなければなりません。そうしないと、開発するプロダクトが、スプリントが終わってから長い期間リリースできない、とうことになりかねません。
UNDONEを明確にしていないスクラムをしているチームが多いのではないでしょうか。
スクラム開発のチームにおける役割
それでは、スクラム開発のチームにはどのようなメンバーがいて、そのような役割を果たすのでしょうか。詳しくみていきましょう。
プロダクトオーナー
開発すべきプロダクトの総責任者としての役割があります。プロダクトバックログの最終的な優先順位を決める権限と、スプリントを中止する権限、スクラムチームのROIを最大化させる責任があります。
『最終的な』という言葉が重要で、プロダクトバックログアイテムは誰が作っても構いません。プロダクトオーナーは、スプリントプランニングに入る前までに、プロダクトバックログの優先順位を決めておく必要はあります。
ステークホルダーや顧客とのコミュニケーションをプロダクトーナーに任せては良いスクラムチームとは言えません。開発チーム・プロダクトオーナーが真に一体となって助け合いながら顧客価値を最大化させていくことがスクラムの醍醐味とも言えます。
スクラムチームのROIとは、最低限の仮説検証可能なプロダクトの実現はもちろんのこと、開発チームやスクラムマスターのスキルアップも入っています。今実現しようとしているプロダクトのことだけを考えるわけではありません。
つまり、スクラムチームは、プロダクト開発が終わっても継続することを意味します。次のプロダクトを作ることになるかも知れません。そのため、プロダクトオーナーには、長期的な視野が必要になります。それも含めて『スクラムチームのROIの最大化』と言われます。
スクラムにおいて、プロダクトオーナーはただ一人です。たった一人しかいないからこそ、開発チームの協力が必要になりますし、プロダクトバックログアイテムを一人で作るわけではなく、『最終的な』優先順位を決めることに特化します。
忙しい役割ではありますが、プロダクトオーナーがいなくても開発チームがプロダクトオーナーと同じ判断をしてくれるようなコミュニケーションのとり方が重要になります。コミュニケーションの質をどう高めるかは大きな課題です。開発チームや顧客・ステークホルダーとうまく協力できない場合は、スクラムマスターに相談します。
開発チーム
開発チームの役割は、選択されたプロダクトバックログアイテムをスプリント内で実現させることです。また、プロダクトバックログアイテムの実現のための代替案を提案したり、そもそも難しいプロダクトバックログアイテムだった場合は、開発を拒否することも必要です。もちろん拒否だけでは物事が進まないので、どうすれば出来るかをプロダクトオーナーと相談します。
開発チームはクラフトマンシップを持ち、常に自チームの生産性向上を意識しています。開発チームは6±3人(7±2人)のチームになります。全員が開発者ではなく、デザイナー、QA、インフラエンジニア、ビジネスアナリストなど、スプリント毎に『出荷判断可能な製品の増分（Potentially Shippable Product Increment）』を生み出せるスキルセットを持つ必要があります。
このようなチームをクロスファンクショナルチームまたはフィーチャーチームと呼びます。チーム結成当初から出来ている必要はなく、スプリントが進むにつれて徐々にスキルを高めていっても構いません。
従来のプロジェクトマネジメントの考え方では、暇な人を出さない、必ず全員にタスクを割り振り、手が開かないように調整する傾向がありますが、クロスファンクショナルチーム・フィーチャーチームではそのような考え方はしません。
開発チーム内でお互いにできることを認識し、自分たち自身で計画を建てます。スキルの幅を狭くする必要があれば、例えばペアで作業して、スキルを伝搬させていきます。
スクラムマスター
スクラム開発において、重要な存在がスクラムマスターです。スクラムマスターは、スクラム開発の持つ価値・意義を本質的に理解して、その手法をスクラムチームが正しく実践できるようにすることが求められます。
スクラムの運営から始まり（スプリントプランニングやスプリントレビューが確実に行われているかなど）、スクラムの役割が兼任になっていないか、プロダクトバックログが適切に運用されているか、見える化されているか、スプリントバックログはどうか、プロダクトオーナーと開発チームの関係性の質はどうか、を見ます。実施はされているが、効率が悪い、効果的でない場合もスクラムマスターはチームに対してコーチングをします。基本理念としては、スクラムの3原則、透明性・検査・適応の観点とアジャイルマインドセットの観点からチームや組織をコーチングします。
また、完了の定義の拡張に向けて、組織や会社の変革への働きかけを行います。詳しくは、この記事を参照いただければと思います。
スクラムマスターの資格について
では、スクラムマスターになるためには資格は必要なのでしょうか。必ずしも資格が必要というわけではありませんが、『認定スクラムマスター研修』を受けることで、スクラムマスターとしての成熟度は上がる可能性があります。可能性がある、と書いたのは受け身の姿勢で研修を受けても何も得られないからです。
認定スクラムマスター(Certified Scrum Master/CSM)研修とは
認定スクラムマスター研修とは、認定スクラムトレーナー(Certified Scrum Trainer)の資格を持つトレーナーが実施するスクラムアライアンス(Scrum Alliance)認定研修のことです。
研修中にその能力が認められると、認定スクラムトレーナーがスクラムアライアンスに登録をしてくれます。
資格取得の流れ
認定スクラムマスター研修は、2日間もしくは3日間のメニューで行われます。この研修を通じて、アジャイルとスクラムの本質的な理解が促されます。
結果の通知と不合格の場合
研修後、合格した場合は2週間程度でメールにより結果が通知されます。残念ながら不合格の場合は、結果が通知されません。
研修内容と費用
認定スクラムマスター研修の内容は、トレーナーによって全く異なります。
これは、アジャイルソフトウェア開発におけるスクラム開発を行う際に、スクラムマスターとして実際に直面する可能性のある課題を実践的に解決していくために行われるものです。研修の場が試験だと思って望んでください。
研修の参加費はおおよそ、1人20～30万円となっています。
知っておきたいポイント
認定スクラムマスター研修は、複数の団体が行っていて、団体や研修によって内容が異なります。回を重ねるごとにブラッシュアップされていく研修に臨むためには、どのような準備をしておけばよいのでしょうか。
予習事項
アジャイルソフトウェア開発宣言、スクラム開発の概要については把握してから望む必要があります。
認定スクラムマスター研修に臨むにあたり予習しておくべき書籍は以下です。
1.スクラム入門(翻訳はVer1.2ですが、原本はVer2.0が出ています)
2.スクラムガイド(参考程度に)
3.英語のリーディングが得意な方であれば、CoreScrumも読んでおくと良いと思います。
4.以下のNoteも参考になります。
研修の意義
それでは、この認定スクラムマスター研修に参加する意義はどのようなものなのでしょうか。
アジャイル、スクラム開発の理解が深まる
第一に、アジャイル、スクラム開発の概念の理解が深まることが挙げられます。スクラム開発という手法が広まれば広まるほど、開発現場では名前ばかりのスクラム開発も少なからず存在しています。
- アジャイルの本質的な理解
- スクラム開発の基本
- 従来型開発とスクラムの違い
- チームで意思決定をする本質
- プロジェクトマネージャーとスクラムマスターの本質的な違い
などが学べますが、研修内容は受講者のレベルや受講態度によってトレーナーがその場で判断するため、どのような内容になるかは受講者によって決まるとも言えます。
コミュニティについて
認定スクラムマスター研修以外に、スクラムマスターのために行われているイベントがあります。それが『スクラムマスターズナイト』『スクラム実験室』です。
スクラムマスターズナイトとは
スクラムマスターズナイトとは、オープンスペーステクノロジーと呼ばれるディスカッション方法で運営されている、誰でも参加できる課題解決型のイベントです。
参加者同士のディスカッションによって、スクラム開発の現場でよくある課題・疑問の解決方法を取得することを目的に開催されています。
ちなみに、オープンスペーステクノロジーとは、参加者自身が解決・議論したい課題を持ち寄って、少人数のグループでディスカッションを行う方法のことです。
対象者や準備するもの
スクラムマスターズナイトの対象者は、スクラムマスターとスクラム開発に関わっている人です。スクラム開発にまったく携わったことのない人の参加も可能ではあるのですが、スクラム開発について基礎的な知識を取得していることが参加条件となっていますが、最近は初心者の方も多いようですので、気軽に参加が可能です。
参加を希望する人は、『Scrum Masters Night! Facebook Group』でイベントの告知をチェックしてみましょう。ディスカッションしたい議題や、何を学ぶために参加するかを事前に練っておくと、当日がより有意義なものになります。
また、飲食に関しては自分自身で持ち込む形式ですので、各自で準備して参加するようにしましょう。
スクラム実験室とは
スクラム実験室（https://scrum-jikken.connpass.com/）は、現場叩き上げスクラムマスターの猛者たちが、自分たちの考えたワークショップを実験的に試す場です。参加者には被験者となっていただきます。
参加は誰でも可能ですが、中級以上の経験が求められる可能性があります。失敗が多い場ですが、エキサイティングです。
まとめ
スクラムマスターとして成長するためには、まずスクラムを実践してみる、そして常に改善をしつづけることです。スクラムマスターは、常に開発チーム・プロダクトオーナー・ステークホルダーから意見を貰い、開発現場がより楽しく、より効果的、より刺激的になるようにします。
そのために、コミュニティや研修に参加して多様な意見を吸収することが大切です。スクラムマスター自身を否定される声もありがたく受け止め、成長への糧とします。
最終的には、スクラムマスターがいなくてもチームが自己組織化され、仕事ができるようになれば良いのです。スクラムマスターは、自分自身の存在を消すために切磋琢磨します。
