ブログ

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

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）

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

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

スクラムの定義

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

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

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

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

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

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

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