アジャイル開発の本命!? スクラム開発とは何か

意外と長いアジャイル開発の歴史

　最近のDXブームで注目を集めるアジャイル開発だが、この言葉が登場したのは今から20年近くも前のことだ。

　従来からのウォータフォール開発モデル――要件定義、仕様策定、設計、開発、テストの各プロセスごとに文書化を厳密に行う――には、開発プロセスが鈍重で時間がかかり、仕様変更に弱く、しばしばプロジェクトが頓挫するという問題を抱えていた。

　それを解消するために、より軽量な開発モデルが必要だと唱える人たちがおり、彼ら（17人のソフトウェア工学の専門家）が一堂に介して、お互いの主張をすり合わせて「アジャイルソフトウェア開発宣言」という文書を世に出した。これが2001年のことである。以下はその宣言文である。

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

　この宣言には、「アジャイルソフトウェアの12の原則」という附則も付いているのだが、その内容を要約すれば、以下のようになる。

2-3週間あるいは2-3カ月といった短いスパンで成果物（動くソフトウェア）をリリースし、継続して改善を行うこと。そのためには顧客と開発者、開発者同士のコミュニケーションが重要であり、自己組織的なチームが必要である。

　アジャイルソフトウェア開発宣言は、各国語に翻訳されており、日本語版は以下のページで参照できる。非常に短い文書なので未見の方は一読しておくことをおすすめする。

http://agilemanifesto.org/iso/ja/manifesto.html

アジャイル開発の先駆けとなったXP

　上記のように、アジャイルソフトウェア開発宣言には、具体的な方法論などは書かれていない。17人の専門家のお互いに異なる主義主張をすりあわせた結果、簡素にせざるを得なかったという見方もできるだろう。

　具体的な方法論や手法の構築は個々の専門家に任せて、その根底に流れる原理原則を抽出したものが先の宣言文になったということだと思われる。

　そのような経緯であるから、一口にアジャイル開発と言っても、その方法論や手法はたくさんある。

　最初にアジャイル開発手法として有名になったのは、ケント・ベック氏らが提唱した「エクストリーム・プログラミング」（XP）である。ケント・ベック氏は、アジャイルソフトウェア開発宣言の署名欄に最初に名が書かれている人物だ。

　細かいことだが、ケント・ベック氏が著書『XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法』を世に出したのは1999年であり、アジャイルソフトウェア開発宣言よりも前である。もっとも、アジャイル開発は、XPを代表とする軽量なソフトウェア開発手法が台頭してきた結果、それらを総称するために生まれた言葉であるから特に不思議なことではない。

　さて、XPが登場して間もないころ、注目を集めたのはその特徴的な「プラクティス」である。代表的なXPのプラクティスには、以下のようなものがある。

テスト主導型開発（テストファースト）

プロダクトコードを書く前にテストプログラムを作成する。これにより、曖昧な仕様が明確化されるとともに、必要以上にプログラムを作り込んでしまうオーバーテクノロジーを防げる。

ペア・プログラミング

二人一組でコーディングする。一人がナビゲーター、もう一人がドライバーのように振る舞うことで、コード品質が向上する。

リファクタリング

既存のコードを書き直す。動いている（完成している）コードを見直すことで、より簡潔でバグが入り込みにくいコードにしていく。

　ウォーターフォール開発が一般的だった当時、これらの開発手法は非常にインパクトが強かった。テスト主導型開発は開発→テストという流れを逆転させるものだし、リファクタリングは「動いているものはいじくるな」という古来の教えに反する。二人一組のコーディングで生産性が上がるというのも当時は眉唾ものだった。

　これらの（当時としては）奇抜なプラクティスは、XPへの関心を高める原動力となったが、同時に「XPは開発者のためだけのもの」という矮小化されたイメージを植え付けることになったように思う。

　実際のXPは、より包括的なフレームワークである。XPでは、「5つの価値」と「19のプラクティス」を定めており、5つの価値にはアジャイルソフトウェア開発宣言とほぼ同じ内容が含まれている。また、上に挙げた3つのプラクティスは「開発のプラクティス」に属するもので、ほかに「共同のプラクティス」「管理者のプラクティス」「顧客のプラクティス」が存在する。

　それにも関わらず、XPでは開発のプラクティスが独り歩きした。それには開発者にとって手を出しやすいからという理由もあるだろう。いくら「顧客とのコミュニケーションが重要」と言っても、現場レベルでは顧客には手を出しようがない。開発のプラクティスなら、開発チームの内輪だけで「ちょっと試してみる」ができる。

　包括的なフレームワークであるXPには、開発チームをどう運営するか、顧客との関係をどう構築するかといったプラクティスも含まれている。しかし、開発のプラクティスが注目されすぎたため、それ以外の部分があまり浸透しなかったことは残念である。

アジャイル開発の組織づくりにフォーカス

　かなり遠回りをしたが、ようやく本稿の主題であるスクラム（Scrum）開発である。提唱者のジェフ・サザーランド氏は、やはりアジャイルソフトウェア開発宣言に名を連ねる17人の専門家の一人だ。

　ラグビーのスクラムから名付けられたこの開発手法は、名前のとおり開発チームが一丸となって機能するにはどうすればよいかという点にフォーカスしている。

　以下、スクラム開発のエッセンスを紹介しよう。

チーム内の役割

　「プロダクトオーナー」は、開発する製品の総責任者であり、顧客あるいは顧客の代理人が務める。実装する機能の取捨選択や優先順位の決定などを行う。開発チームの一員ではあるが、より高い視点が必要である。

　「スクラムマスター」は、従来のプロジェクトマネージャーに相当する役割であり、チームが正常に機能しているかどうかを観察する。意思決定はプロダクトオーナーが行うため、その役割はチーム内の調整とチーム外との交渉などである。

開発サイクルとバックログ

　スクラム開発では、プロジェクトの開発期間を「スプリント」という短い期間に分けて、段階的な開発を行う。1つのスプリントは最長で4週間とする。製品に実装する機能は、「プロダクトバックログ」に記載し、そこから各スプリントで実装する機能を「スプリントバックログ」に落とし込む。

開発工程とミーティング

　スクラム開発では、ミーティングと開発工程を何よりも重視する。スクラム開発で行われるミーティングや開発工程には以下のようなものがある。

　「計画ミーティング」は、プロジェクトと各スプリントの最初に行うミーティングである。プロダクトオーナーが提示したバックログの内容をチーム全員で検討し、必要であれば修正を加えて承認する。

　「スクラム会議」は、毎日決められた時間に行うミーティングである。スクラムマスターが議長となり、進捗や新たに浮上した問題がないか、次回のスクラム会議（明日）までに行うことなどを確認する。1回のスクラム会議は15分以内に終わらせる。

　「スプリントレビュー」は、各スプリントの終了後に行う工程。スプリントの成果物を確認し、必要であればバックログの見直しを行う。

　「振り返り」は、スプリントレビューの終了後に行うミーティング。開発体制など製品以外についても議論を行い、次のスプリントに向けた改善案などを話し合う。

　「クロージャ」は、プロジェクトの最後に行う工程。最終的なデバッグを行ってプロジェクトの終了を確認する。

　かなり駆け足であるが、以上がスクラム開発の概要だ。ソフトウェア開発手法と言いつつも、スクラム開発にはXPに見られるような開発技法に関するプラクティスは存在しない。どんな開発技法を用いるかは、開発チームで話し合って決めればよいというスタンスである。実際にスクラム開発を実践する際には、テスト主導型開発やリファクタリングなどを組み合わせることが多いようである。

DX時代にこそ求められるスクラム開発

　今さら種明かしをするようだが、実はスクラム開発の歴史はXPよりも古い。

　サザーランド氏がその開発手法を『アジャイルソフトウェア開発スクラム』という一冊の本にまとめたのは2003年だが、サザーランド氏がスクラム開発を提唱し、実践しはじめたのは1993年からだという。

　では、この歴史の長いアジャイル開発手法が、なぜ今注目されているのだろうか。それは、DXの必要性が声高に叫ばれ、ビジネスとITの距離が一気に縮まったせいではないか。

　アジャイル開発という言葉が生まれた約20年前、ソフトウェア開発手法は、開発者だけが気にするものだった。だが今やDXの時代である。DXに取り組み、ビジネス変革を推し進める企業は、最終的にIT組織になる。そうした方向性が示されている中、ソフトウェア開発手法が経営課題として重要度を増すのは必然であろう。特に、IT組織化していく会社をどう機能させるかという点は、プログラミング技法よりも重要度が高い。そうしたニーズにうまくハマったのがスクラム開発というわけだ。

　もっとも、本稿で紹介したようなエッセンスをかじっただけで実践できるほど、スクラム開発は甘くない。本気で取り組むのであれば、しっかりとしたトレーニングを行う必要がある。例えば、KDDIは米Scrum Inc.と業務提携し、永和システムマネジメントと組んでスクラム開発のトレーニング／コーチング・サービスを提供している。ちなみに、米Scrum Inc.はジェフ・サザーランド氏の会社（CEOは息子のJ.J.サザーランド氏）であり、スクラム開発のトレーニングとコンサルティングを行うほか、認定試験も実施している。

　いずれにせよ、国内のスクラム開発経験者が限られている現状では、こうしたサービスを利用することも検討したほうがよいだろう。