スクラムにおいて開発者が推進するものとは？

はじめに

スクラムチームには開発者、プロダクトオーナー、スクラムマスターの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、アジャイル、スクラムの関係を自分なりにまとめてみたものの一部です。

このようにスクラムでは「技術的卓越性」は「完成の定義」という形で抽象化されています。

これに限らず、スクラムは意図的に不完全になっています。だからこそシンプルになっている一方で、本質を理解しないで進めると形だけ「開発プロセス」として取り入れられる、あるいは歪められる可能性があります。

スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。スクラムは実践する⼈たちの集合知で構築されている。スクラムのルールは詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。

スクラムガイド2020

一方XPでは「品質」という原則と、いくつかの主要プラクティスに含まれており(少なくとも4つ)、より具体化されています。

スクラムガイドにおいては「完成の定義」は抽象化された概念のため、それをチームで具体化する必要があります。

そして、完成の定義は開発者だけのものではないですが、開発者が準拠する必要があるため、開発者が自分たちで作り上げていくのが望ましいです。そこに間違いなく、XPで挙げられているプラクティスは必要でしょう。

インクリメントの完成の定義が組織の標準の⼀部となっている場合、すべてのスクラムチームは最低限それに従う必要がある。組織の標準になっていない場合、そのスクラムチームはプロダクトに適した完成の定義を作成する必要がある。

開発者は完成の定義に準拠する必要がある。プロダクトに関わるスクラムチームが複数ある場合、共通の完成の定義を作成して、それに準拠する必要がある。

スクラムガイド2020

ソフトウェア開発においては技術的卓越性を追求し、スクラムとXPをつなげる、それがスクラムにおける開発者の責務ではないか、自分はそう考えています。