スクラムでの設計、どこが違う？ウォーターフォールとの対比
こんにちはこんばんは。スクラムマスターの いのもえ です。
先日、ソフトウェア開発における "設計" の工程について、スクラムや LeSS でどのように扱うのが良いか考える機会がありました。
ソフトウェア開発における「設計→実装→テスト→リリース」の流れではあるものの、スクラムや LeSS のスタンスがこれまで自分が経験してきたものと明確に違うし、前提としてこれを知っていないと辛いのではと思ったので筆を執りました。
以降では「スクラムにおける〜」といった表現を多用しますが、特に明記がない限り「LeSS における〜」と読み替えていただけます！
工程のおさらい
スクラムのサイクルでは、実装工程に入るまでに以下のような流れがあります。
プロダクトバックログリファインメント（PBR）
スプリントプランニング（SP）
実装工程へ
よくある V 字モデルに当てはめると、 PBR が要求定義、 SP が基本設計・詳細設計を指します。違いをあえて挙げてみると、プロダクトバックログアイテム（PBI）の単位が小さいため、基本設計と詳細設計を分けて考えることは稀だと思います。
V 字モデルがピンとこない方はこちらから。
設計方針の違い
以降では V 字モデルにきっちり乗っ取る開発を「ウォーターフォール開発」と表現しながら、違いについて説明します。
工程を比較してみると大きな差はでませんが、両者のスタンスは大きく違い、ウォーターフォール開発が「今回の改修のためのの設計→今回の改修のための実装」とセットになっているのに対し、スクラム開発は「今回の改修のための実装→別の機会に同じ箇所を触るときにリファクタリング（設計）」となるイメージを持ちました。
ウォーターフォール開発
ウォーターフォール開発での設計段階では、得られた要求をもとに将来のことも考えて設計することが多いと思います。顧客や利用者に対し、「今回はスコープ外とすると思うが、こういう状況や使い方も将来ありえますか？」と質問したりするようなイメージです。
ウォーターフォール開発では設計作業の不備が後工程に響くため、極力不備がなくなるように色々な切り口から設計をレビューする必要があります。将来のことを考えるのも、次のプロジェクトの改修に向けて少しでもやりやすくなるようにと考えてのことだと想像できます。
スクラム開発
一方のスクラム開発では、得られた要求にフォーカスして、一番シンプルに実現することを考えて設計することが求められます。例えば、すでに RDB を用いて実現しているサービスの改修であれば、まずは既存の RDB に対してカラム追加やテーブルの追加を考えることが良いとされています。
また、常にリファクタリングしながら開発を進めることを求められています。改修範囲について「今の要求で最高の設計になっているか」と検査・適応することがまさにリファクタリングという行為と一致しているという考え方です。
※ 安全にリファクタリングを続けられるよう、「自動テストが充実している」という前提が必要です。今回の記事では割愛します。
リファクタリングをどのように進めるかを含めた設計を SP で実施します。LeSS の場合は SP2 で行うイメージで、必要に応じてチーム横断で実施します。
スクラム開発は行き当たりばったり？
スクラム開発の設計段階で将来のことを考えないのは、以下の意図があります。
「使いそうだから用意したが結局使わなかった」などの無駄を極力省くため
設計しておかないことによって後工程の自由度を上げておくため
特に (2) については以下で詳しく解説されています。
「Clean Architecture 達人に学ぶソフトウェアの構造と設計」の 15 章「選択肢を残しておく」
「エンジニアリング組織論への招待 〜不確実性に向き合う思考と組織のリファクタリング」の「リアルオプション戦略と遅延した意思決定」
リアルオプションやデシジョンツリーについて知るだけでもかなりイメージが湧くと思います。以下の記事がわかりやすかったのでよろしければ！
技術的なチャレンジを取り入れるタイミングの違い
スクラム開発では基本的には既存のものに一番シンプルな変更を加えるのが良いとされるため、一見技術的なチャレンジが取り入れづらいと感じる方もいるかもしれません。
ウォーターフォール開発
ウォーターフォール開発では新しいプロジェクトを始める時に、一緒に技術的なチャレンジを取り入れる場合があります。例えば新しいアーキテクチャを取り入れるなどです。
小さなサービスであったり、既存のサービスとの関連性が低いとよりそういったチャレンジが起こりやすいと思います。
ウォーターフォール開発は盤石な設計の上に開発を積み重ねる手法です。チャレンジしたいのであれば設計段階ではチャレンジを考慮する必要がありますから、新しいプロジェクトが始まるタイミングで取り入れられることになります。
スクラム開発
いくつかタイミングがあります。ここでは 2 つ紹介します。
(1) 技術課題が大きくなるタイミング
既存のアーキテクチャのまま機能を追加し続けると「この要求を満たす開発をすると技術的な課題が大きくなる」というタイミングが来ることがあります。そのタイミングが技術的チャレンジを取り入れやすいタイミングです。
前の章で紹介したデシジョンツリーの考え方に近いです。
例えば、ユーザーのログイン状態をローカルファイルで管理していたとします。サーバーが 1 台であるときには特に大きな問題になりませんが、アクセスが増えサーバーが複数台必要になったときには「ユーザーのログイン情報に一貫性が持てない」という問題が起こります。この問題発生時がチャレンジするタイミングです。初めはローカルファイルで保存する形で実装しますが、サーバーを増やすタイミングが来たらログイン情報をサーバー同士で共有できるようなアーキテクチャに乗り換えるようなイメージです。
(2) 定期的なワークショップ
サービス全体を俯瞰したときの課題感については現在のアーキテクチャに関するワークショップを定期的（四半期に一度など）に実施するのが有用とされています。
現在のアーキテクチャを様々な切り口（データモデルやディレクトリ構造など。あらゆる切り口で全て明らかにする必要はないです）で見られるようにし、お互いの課題感や改修の方針について議論する場です。
初めにアーキテクチャを理解している人に資料を用意してもらう必要はありますが、課題感や方針を共有することで分担や計画して作業を進めることができるようになります。
また、このワークショップの様子を録画したり、利用したホワイトボードをとっておくことによってオンボーディングの資料としても利用できます。
〆
いかがでしたでしょうか？
例によってアジャイルコーチとディスカッションしながら考える機会となったのですが、「前提として知っておかないと単に開発しづらい、または重要工程に漏れが発生しそうだな」と思ったので記事にまとめてみました。
特にアーキテクチャに関するワークショップは今までやったことがあまりないのですが、是非やってみたいと思いました！（オンボーディング資料作成もできるのもお得でいいですよね）
参考になれば幸いです！
いいなと思ったら応援しよう！
