スクラムにおいて開発者が推進するものとは?
はじめに
スクラムチームには開発者、プロダクトオーナー、スクラムマスターの3つの役割があり、Scrum Allianceでは役割ごとの認定資格があります。
自分は2022年6月に認定スクラムデベロッパー(Certified Scrum Developer®, CSD®)を取得しました。その研修とその後自分が考えたことを含め、スクラムにおいて開発者が推進するものについての自分の考えをまとめてみます。
認定スクラムデベロッパー研修を受けたときのこと
自分はアギレルゴコンサルティング株式会社が主催する、David Bernsteinさんによる研修を受けました。
そのときに課題図書として渡されたのが「レガシーコードからの脱却――ソフトウェアの寿命を延ばし価値を高める9つのプラクティス」です。後から知ったのですが、この本は翔泳社主催のITエンジニア本大賞2020の大賞を受賞しています。
研修の前にこの課題図書をパラパラと読んでみました。継続的インテグレーション、テスト駆動開発、リファクタリングのような技術的プラクティスや、ペアプログラミング、分割統治などこれまでの経験で知っているものが多く含まれていました。
研修は座学とワークショップのみでしたが、怒涛の4日間の研修が終わってから、開発者が目指すものは何か?ということをよく考えるようになりました。
想像よりもはるかに高い「技術的卓越性」
アジャイルソフトウェア開発宣言では、「アジャイルソフトウェアの12の原則」の中に「技術的卓越性」という言葉が出てきます。
この研修の影響で一番大きかったのはこの「技術的卓越性」についてのレベル感です。研修内容は確かに自分が知っているものがほとんどでした。しかし、自分が想像していたより遥かにレベルが高いものでした。
例えば「継続的インテグレーション(CI)」に関して、CIツールを入れてテストを動かすこと、そんなイメージを持っていました。しかしDavidさんは「ブランチで開発しているうちは統合ではない」と言い切りました。言われてみれば確かに「継続的」に「統合」することは、ブランチによる開発とは矛盾します。
そして「完了の定義」もレベルが高いものでした。「レガシーコードからの脱却」には3つの「完了」の定義が載っています。この「完了の完了の完了」(Done, Done, Done)こそが本当の完了だと書いています。
スクラムにおいて「完了の定義」は全ての開発者が準拠する必要があります。すなわち「完了の定義」が「完了の完了の完了」なら、すべての開発者が「完了の完了の完了」を理解して実践できる必要があります。
そしてこの考え方は頭では理解できても一朝一夕に身につくものではありません。となると「完了の定義」を「完了の完了の完了」としたいなら、まずチームでこの「完了の完了の完了」こそが必要だという認識を合わせて、そしてチーム全員が理解して実践できるように取り組む必要があります。
自分も過小評価していた「エクストリーム・プログラミング」
もう1つ気づいたのは、エクストリーム・プログラミング、通称XPのことです。
もちろんアジャイルソフトウェア開発宣言の17人にXPを提唱したKent Beck氏が入っているのは知っていて、XPの中のプラクティス、例えば「ペアプログラミング」がどのようなものかは知っています。
しかし自分の中でXPの存在は半分忘れかけていました。その理由は世界で採用される割合が減ってきているからです。例えば2010年のアジャイル開発手法、大きな組織の導入率が高く、半数はスクラムを採用との調査結果という記事では、スクラムが50%、スクラムとXPのハイブリッドが24%、XPが6%と、30%がXPを採用しています。
しかし現在ではXPはほとんど話題に上がりません。例えばJetBrain社の2020年のアンケートではスクラムが38%、カンバンが16%なのに対して、XPはわずか1%です。ハイブリッドを含めても数%しかないでしょう。おそらく「テスト駆動開発」や「継続的インテグレーション」などの個々のプラクティスのみ独立して語られた、あるいはDevOpsなど別のプラクティスとして取り込まれた結果でしょう。
しかしこの認定スクラムデベロッパー研修ではXPの言葉を使った、XPに関する内容が1/3を占めていました。1/3がスクラム、1/3がデザインパターンです。それだけ開発者にとってXPは欠かせないものです。ネットでもXPの支持者を多数見かけます。
自分は改めて書籍「エクストリームプログラミング(第二版)」を読んでみました。そして「パラダイム」としてのXPにはまだまだ大きな価値が残っている、XPは過小評価されていると考えました。
スクラムとXPをつなげる
XPは過小評価されていますが、スクラムは過大評価されているとは思いません。スクラムは凄いフレームワークです。自分はこの辺りが特に気に入っています。
チームを支援する専門の役割であるスクラムマスターがあること
5つのイベントによって検査の機会が組み込まれていること
一方でスクラムには技術的プラクティスがないと言われています。これはある意味では正しいです。次の図は自分がXP、アジャイル、スクラムの関係を自分なりにまとめてみたものの一部です。
このようにスクラムでは「技術的卓越性」は「完成の定義」という形で抽象化されています。
これに限らず、スクラムは意図的に不完全になっています。だからこそシンプルになっている一方で、本質を理解しないで進めると形だけ「開発プロセス」として取り入れられる、あるいは歪められる可能性があります。
一方XPでは「品質」という原則と、いくつかの主要プラクティスに含まれており(少なくとも4つ)、より具体化されています。
スクラムガイドにおいては「完成の定義」は抽象化された概念のため、それをチームで具体化する必要があります。そして、完成の定義は開発者だけのものではないですが、開発者が準拠する必要があるため、開発者が自分たちで作り上げていくのが望ましいです。そこに間違いなく、XPで挙げられているプラクティスは必要でしょう。
ソフトウェア開発においては技術的卓越性を追求し、スクラムとXPをつなげる、それがスクラムにおける開発者の責務ではないか、自分はそう考えています。