ブログ

ryuzeeによるブログ記事。不定期更新

【翻訳】スクラムは抽象クラス

みなさんこんにちは。@ryuzeeです。

スクラムはフレームワークです。ロール、作成物、イベントが決められていますが、それを具体的にどうやってこなしていくのかは定義されておらず、それぞれの環境にあわせてやり方を考えていく必要があります。

それを分かりやすく説明したのが、Scrum is an abstruct classという記事です。 今回、記事を執筆したPaddy Corry氏に快諾いただきましたので、和訳にてご紹介します。

なお、誤解のないように言っておくと、スクラムはアジャイル開発を進める上での唯一のフレームワークでは決してありません。 つまりスクラムのフレームワークで既定されていることを止めた場合、それはスクラムではありませんが、だからといってアジャイルでなくなることとイコールなわけではありません。 自分たちにとって良いやり方があれば、それをやればいいのであって、スクラムに厳格に従うこと自体を目的化しないでください(ただし最初からカスタマイズするのは、ほとんどの場合うまくいきません)。

スクラムは抽象クラス 〜チームが実装する〜

Javaでは抽象クラスのインスタンスを作ることはできません。 これが意味するのは、抽象クラスはそのままの形では存在しえないということです。 派生させて、具体的な実装が行われれば、実体として存在できるようになります。

言い換えると、抽象クラスで規定されている振る舞いが気に入ったのであれば、そこから派生できるし、自分独自のバージョンを作れます。 しかし、そこには暗黙の契約もしくは了解があります。 抽象クラスを使うということは、そこで規定されている振る舞いを継承してそれに適合させることに合意するということです。 抽象クラスから派生させると、あなたのサブクラスは、そのインスタンスになるのです。

抽象クラスはシグネチャを持ったメソッドを含んでいます。 メソッドシグネチャは複数のことを意味します。 まず、名前があること。 次に、期待する入力と出力があることです。 これら2つによってエントリポイントとイグジットポイントを設定します。 そして、あなたはメソッドの実体を記述します。 つまり、それがどのように動作するかは自由に決められます。

ここでちょっと、スクラムが抽象クラスであると想像してください。 この抽象クラスは、sprintPlanningというメソッドを持ち、Sprint Goalを引数に持ち、Sprint Backlogを戻り値として返します。 メソッドシグネチャは明確に定義されていますが、Sprint Planningをチームがどう実装するかは完全にチーム次第です。

スクラムを抽象クラスで記述するとこんな感じでしょうか。

abstruct public class Scrum {

    abstruct SprintBacklog sprintPlanning(SprintGoal sprintGoal,
                                          Collaboration collab,
                                          Humility humility);

    abstruct DailyPlan dailyScrum(SprintBacklog sprintBacklog,
                                  SprintGoal sprintGoal,
                                  List<Task> yesterday,
                                  List<Task> today,
                                  List<Impediment> impediments);

    abstruct Feedback sprintReview(List<Stakeholder> stakeholders,
                                   ProductIncrement workingSoftware,
                                   Collaboration collab,
                                   Humility humility);

    abstruct List<ContinuousImprovement> sprintRetrospective(List<Event> whatWentWell,
                                                             List<Event> whatCouldImprove,
                                                             Collaboration collab,
                                                             Humility humility);

    abstruct ProductBacklog refineProductBacklog(ScrumTeam team,
                                                 List<Stakeholder> customers,
                                                 Feedback feedback,
                                                 Metrics metrics);

    // 技術的プラクティスの抽象メソッドは用意されていない。自分たちでどんな実装をするか決める必要がある
}

ロールやイベントや作成物を減らしたら、もはやスクラムではない

スクラムは肉付けする必要があるメソッドシグネチャのセットを定義しています。 全てのイベントやロールや作成物がスクラムの実装によって調整されていたとしても、それは依然としてスクラムです。 抽象クラスとの契約をを破ってメソッドを除去したり省略した場合だけ、それはスクラムではなくなります。 その場合は、何か他のものを実装しているのです。

スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。(スクラムガイド)

チームがレトロスペクティブをやめることにした時のことを想像してください。 残念なことに、これはスクラムに最低限必要とされることから離れてしまっていることを意味します。 スクラムの実装であるためには、レトロスペクティブの実装が必要です。 しかし、どのようにレトロスペクティブを行うのかは、完全にあなたたちスクラムチーム次第です。

スクラムにメソッドを追加する必要があるはず

抽象クラスの中身を実装する上で素晴らしい点は、メソッドの追加が自由なことです。 実際、スクラムを実装すると、すぐに既定のメソッドは最低限であることに気づくでしょう。 いくつかの重要だと思われるメソッドが完全に欠落しているのです。

スクラムガイドはソフトウェア開発の細かいことを規定したりチェックリストであることを意図しているわけではありません。 重要なプラクティスの多くはスクラムガイドには載ってはいません! 実際に進めてみて、自分たちに足りないものを見つけないといけないのです。

この不足自体が完全に設計された意図的なものである点は興味深いと言えるでしょう。

すべてをまとめたものがスクラムであり、その他の技法・方法論・プラクティスのコンテナとして機能する。(スクラムガイド)

エンジニアリングプラクティス追加の必要性

たとえば、エンジニアリングプラクティスはケン・シュエイバーとジェフ・サザーランドによってスクラムガイドから明示的に取り除かれています。 数千ものアジャイルチームでソフトウェアを届けるために使われているフレームワークが、ソフトウェアをどう作るかについて何のガイドラインも含んでいないのです。

抽象クラスのメタファーでスクラムを表すと、エンジニアリングプラクティスを自分たちで定義して追加しなければいけないメソッドだと考えることになります。

初めてのスクラムではXPのすべてのプラクティスを実施した、とジェフ・サザーランドに習った。 しかし、ケン・シュエイバーはスクラムからエンジニアリングプラクティスを外すべきだという考えに至った。 モデルをシンプルに保ち、技術的プラクティスに関する責任をチームに任せるためだ。(ヘンリック・クニベルグ。塹壕よりScrumとXP)

訳注:底本が違うため、日本語版には該当箇所は含まれていません。

ソフトウェア開発チームごとに、追加する必要のあるメソッドにはさまざまな違いがあるでしょう。 あなたの組織のとあるロールをスクラムに追加して、それをどうスクラムチームにうまく組み込むか、といったことも含まれるかもしれません。 ステークホルダーマッピングやバリューストリームマッピング、メトリクス、リリースプランニング、継続的インテグレーション、継続的デプロイメント(リストは続く…)などについても検討したいかもしれません。

スクラムの定義

でも、コアを見失ってはいけません。 スクラムはその手助けもしてくれます。 最初の原則とスクラムの定義に立ち返ってみましょう。

スクラム(名詞):複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。(スクラムガイド)

スクラムは学習と適応を促すように設計されています。 アジャイルマニフェストは、ソフトウェアを提供するためのより良い方法について、どう捉えているか思い出してみましょう。 スクラムはまさにそのとおりになっているのです。

スクラムは経験主義、すなわち透明性、検査と適応についてのものです。 これらは物事を進めるよりよい方法を見つけ、チーム内で新たに役立つプラクティスを見出す上で、必要不可欠です。 スクラムフレームワークはこれを促しますが、チーム全体はそうなることに対して責任を持つ必要があります。

実験によって役にたつプラクティスが明らかになれば、それを抽象的なフレームワークの実装に追加できます。 しかし、それには勇気が必要です。 チームは改善をしている最中でも価値を届けることにフォーカスしつづけないといけません。 これは大変です。 コミットメントと信頼が必要で、チームは困難を受け入れなければいけません。

まとめると、スクラムは抽象クラスのように設計されていますが、あわせて、自分の実装の助けとなるフレームワークでもあります。 ここでの暗黙的な契約は、あなたが役割や作成物やイベントを実装することです。 しかし、新たなロールや作成物やイベントをあなたのチームの創発的なプラクティスとして追加することは、価値あるプロダクトを成功裏に届ける上での助けとなるでしょうし、経験主義のプロセスはあなたの旅の助けとなるはずです。

時には抽象芸術のように感じるかもしれませんが、スクラムはこのように設計されているのです。

それでは。

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック