どうもこんにちは。
前回に引き続き、アジャイル開発についての記事を書いていきます。
アジャイル開発と比較されるウォーターフォールとは
ウォーターフォール開発とは、開発をいくつかの工程に分けて順番に取り組んでいく手法です。開発するものを明確にする工程と、その工程に対応したテストが存在します。ソフトウェアの品質向上や品質保証の話でもよく出てくる「V字モデル」をベースにしています。
参照: https://webrage.jp/techblog/v_shaped_mode/
ウォーターフォールの工程は時系列で並べられていて、基本的に「前のフェーズが完了するまで先に進まない」「後戻りがない」前提で進められます。時系列順で進むため、進捗の確認を簡単に行うことができるのはウォーターフォールの強みです。
上記から「明確な要件が最初から決まっていて、要件を変更される可能性が低いプロジェクトに適している」手法だと言えるでしょう。
アジャイル開発とウォーターフォール開発の比較
共通点
- 顧客からの要求がなければ何を作るのかが決まらず、設計がなければどのようにソフトウェアを作るのかが決まりません
- 実装しなければ動くものができません
- テストをしなければ作ったものが要求と合致しているか確かめることができません
違い
アジャイル開発とウォーターフォール開発の比較表に、いくつかの追加項目を提案します。以下は新しい項目を加えた拡張版の比較表です。
| 項目 | アジャイル | ウォーターフォール |
|---|---|---|
| 後戻り | ○ | ×（原則後戻りはしない） |
| 開発工程の見直し | ○ | × |
| 要件の見直し | ○ | × |
| スピード | × | ○ |
| 進捗確認のしやすさ | ○（スプリントごとに進捗確認） | ○（全体計画に基づく） |
| 顧客との関与 | ○（継続的なフィードバック） | ×（プロジェクト終了時に成果物提供） |
| チームの柔軟性 | ○（役割の流動性あり） | ×（固定された役割） |
| リスク管理 | ×（変更に柔軟だが不確実性が高い） | ○（計画に基づいたリスク管理） |
| 文書化の重視 | ×（必要な範囲でドキュメント作成） | ○（詳細なドキュメント作成が求められる） |
| プロジェクトの予測可能性 | ×（柔軟だが不確実） | ○（計画通りに進行） |
| 変更の対応 | ○（変更が容易） | ×（変更にコストと時間がかかる） |
| コスト管理 | 柔軟（変更に応じて変動） | 固定（計画通りのコスト管理） |
| 適用プロジェクトのタイプ | 小規模〜中規模、変化が激しいプロジェクト | 大規模、要件が明確で安定したプロジェクト |
| テストのタイミング | 継続的（各スプリントで実施） | 最後にまとめて実施 |
| チームの関与 | 強い（全員が全体に責任を持つ） | 弱い（役割が明確に分担されている） |
どちらが良いというように優劣をつけることは難しいですが、アジャイル開発は柔軟で流動的であることがわかります。
このメリットは、「顧客の要望に沿ったシステムを開発することができる」にあります。ウォーターフォール開発でも顧客の要望に沿ったシステムを開発することはできますが、「顧客が自身の要件を把握していない」「要件が変わった」という問題に対応することができません。
また、「スプリントごとに開発工程を見直すことができる」という点もアジャイル開発の強みです。これによって、より効率を重視した開発を行うことができるようになります。
開発した機能の6割は使われないだと...
機能の贅肉
開発をしているエンジニアにとっては、すべての機能を使用してもらう前提で開発をしているので、6割の機能が使用されていないという事実を聞くとショックですね。本では、6割の機能のことを「贅肉」と呼んでいます。
投稿者の体脂肪率は19~20%の間なので、約10%は贅肉ですね...
なぜ、「開発したすべての機能が使用されない」という悲劇が起こってしまうのでしょうか。それは、ユーザにとって「必要がない機能」だからです。でも、どうしてユーザにとって必要のない機能を開発しているのでしょうか。
それは、顧客の要求を聞き出す時に問題があります。その理由は、顧客の「欲しいもの と 必要なもの」は違うからです。「欲しいもの」を顧客の要求としてすべて取り入れてしまうと、必要ではない機能を開発してしまうことになります。なので、「必要なもの」を聞き出さなければいけないのですが、顧客自身もそれを区別できていないこともあるので難しい...
なので、「顧客に随時動いている機能を触ってみてもらって、フィードバックをもらう」という工程が必要になります。
プロセスの贅肉
機能の贅肉がある一方で、プロセスの贅肉も生まれてきます。
例えば、以下です。
- ドキュメント・議事録作成
- 進捗の共有方法
- テスト項目の確認
- リリース時の約束事
上記のような、ドキュメントの作成や共有、確認といった工程は「非効率」だと感じてきたり、「当たり前」になってきます。そうすると、気づいたらやらなくなっていたり、共有や確認を行なっている目的を見失って形だけの状態になってしまいます。結果として、効果が薄まってしまいますよね。これが、「プロセスの贅肉」です。
また、「確認の待ち時間が長い」なども「プロセスの贅肉」と言えますね。
無駄な工程を無くしたり改善したりするのは、簡単そうで簡単ではありません。本当に必要な工程なのであれば方法を変えたり、目的を再確認するようにするなどの手段が必要です。逆に必要のない工程をなくすには、本当に無くして良いのか勇気と自信が必要です。他にも、「その工程はコストに見合っているのか」などの確認をすることも重要です。
このような贅肉をなくすためには、各工程に対して「期待している効果が得られているか」「効果的に利用されているか」などといった観点で評価する必要があります。
バリューストリームマッピング
プロセスの贅肉を見える化するための手法として、バリューストリームマッピングという手法があります。
バリューストリームマッピングとは、開発からリリースまでの工程を可視化し、その工程ごとに問題点を紐づけていく作業のことです。
まとめ
次の記事でもアジャイル開発について書こうと思います。