スクラム開発。Webサイト制作に当てはめられる？

2021年06月21日 2021年07月17日

Webサイト制作は、一般的にはウォーターフォール開発のステップで進むことが多いです。

ウォーターフォール開発とは、読んで文字のごとく、水が上から下に流れていくように、基本すべての制作ステップが後戻りしないように、順番に必要な要素を潰していって完了に持っていく進め方です。

それに対になる進め方としてアジャイル開発という進め方があります。
アジャイル開発の言葉の定義としては、作業を細かく区切りつつも、実装とテストを繰り返しながら完成に持っていく進め方です。

そのアジャイル開発について、厳密に進め方を定義したスクラム開発という進め方があります。

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

スクラム開発の定義

公式のスクラムガイドのページでは以下のように紹介されています。

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。

まぁ、わかるようなわからないような。
ぶっちゃけ、この公式のサイトの説明もその他紹介記事の内容も専門用語が多すぎでわかりにくいです。

スクラム開発における用語整理

スクラムを説明する場合、このスクラムに関する用語を最初に整理しておく必要がありそうです。特に重要と思われる用語について予め整理してみます。

1. プロダクトオーナー

あるサービスの提供者になります。
Webサイト制作に当てはめると、Webサイトそのもののオーナーになります。Webサイト制作会社から見るとクライアントがそれにあたるでしょう。

2. 開発チーム

スクラム開発そのものを実行する部隊を指します。
Webサイト制作に当てはめるとWeb制作会社の担当プロジェクトチームがそれにあたります。

3. スクラムマスター

スクラム開発が適切に実行されているかの責任を責任者です。
Webサイト制作に当てはめるとWeb制作会社のプロデューサーがそれにあたると思われます。

4. スプリント

スクラム開発は、「スプリント」という期間単位で制作を進めます。
その期間は内容により変動するのではなく、最初に１週間と決めたら１週間という固定期間になるようです。
スプリントで実施する項目は後述のプロダクト・バックログで定義します。

5. スプリントレビュー

スプリントの期間で実現できたことはスプリントレビューという場でチェックを受けます。参加者は開発チームとプロダクトオーナーになります。
最終成果物のユーザーになりうる人に参加することも有効とされています。

6. プロダクト・バックログ

バックログというとプロジェクト管理ツールのBacklogをイメージしてしまいますが、スクラム開発においては別の意味を持ちます。
スクラム開発における、アイデア一覧を指します。
WBS（作業分解構成図）と近いものをイメージしますが、「アイデア」という点が大きく違います。その重要度により優先順位づけがされています。

7. スプリント・バックログ

スプリントの計画を開発チーム側で整理したもの。
開発チーム側でやりやすいフォーマットを定義しても問題ない。

8. インクリメント

インクリメントというとプログラムの概念において「1つプラスする」というような意味を持ちますが、スクラム開発においては、スプリントにおける成果物そのものを指します。各スプリント期間において、何をインクリメントにするかはプロダクト・バックログで定義されます。

アジャイル開発といえど、エンドレスループにはならない。

用語が概ね理解できたところで、スクラム開発のステップを整理しておきます。

プロダクト・バックログで優先順位をつけたアイデアを一覧化する。
プロダクト・バックログのアイデアをスプリント計画に反映する。
スプリント計画を具体的な作業イメージに落としたスプリント・バックログにする。
スプリント期間内でスプリント・バックログで定義された開発を進める。
スプリント期間の最後にスプリントレビューを行い、次のスプリントに進める。レビューで出た項目はプロダクト・バックログに反映させる。

「スプリント」という固定期間でアイデア実現を継続していくというループ要素はあるものの、同じことを繰り返し行うのではなく、優先順位をつけたアイデアを実現していく。
アジャイル的な要素も持ちつつ、無限ループに陥らないウォーターフォール的な側面も持ち合わせているものと言えるのでと思いました。

Webサイト制作でスクラム開発を当てはめるのは、設計と主導線のページデザイン？

次に、この開発手法をWebサイト制作に適用できるものかについて考えてみる。
元々このスクラム開発の想定としては、アプリケーション開発を想定し、UIや機能の使い勝手について想定されているものだと思う。
しかしWebサイト制作すべての工程にこれを当てはめるのは現実的ではない。

例えば、設計フェーズが確定した後のデザインフェーズで設計に差し戻されるようなレビューが行われるとプロジェクトが前に進まない。

なので、これは個人的な感想ではあるが、スクラム開発を行うのは「ここ」という定義をしてから取り入れるのが良いと思う。

そういう意味では、画面設計、機能設計部分がそれにあたる。
設計書でそこをレビューできるのが理想だが、そこにモックアップ的なものを取り入れ、それで機能や使い勝手をレビューするというのは考えとしてあると思う。

あとは主要画面のデザイン、ここもWebサイトのオーナーが特にこだわりをもつところ。トップページだけではなく、主導線の画面を選定する必要はあるが、設計とあわせてデザインをモックに組み込み、レビューするというのは現実的な考え方だと思う。