release:
システム開発の世界に「アジャイル」という開発手法が用いられるようになって、既に20年ほどが経過しました。
アジャイルといえば一般的に「小さく始めることができ、開発スピードと費用面で有利」と考えられていますが、それはある一面では必ずしも正しいとは言い切れません。
この記事では、アジャイルな開発手法で陥りやすい落とし穴と、アジャイルのメリットを最大限に活かす「スプリント」について解説します。
目次
アジャイルの落とし穴
「アジャイルな開発」とはその名のとおり、本来は「素早い・機敏な=アジャイル/Agile」開発手法を指しています。
しかし、アジャイルな開発手法を取れば、必ずしも「素早く機敏な開発」が進められるとは限りません。
それどころか、一般的に認識されているイメージだけで進めると、望む結果が得られないだけでなく、手戻りばかりでいつまで経っても前に進まないということすら起こり得るのです。
そこで、まずは「アジャイルに関する一般的な理解」の内容と、「もっとも陥りやすい落とし穴」について確認します。
アジャイルの一般的理解
アジャイルの一般的な理解といえば、おおむね次のようなものが挙げられます。
- プロジェクトを細分化し小さいところから始め、進められる
- 完全に仕上げなくとも、見切り発車でもローンチできる
- 手戻りが少なく、開発スピードが早い
- 結果的に費用も少なくて済む
つまりは一般的なアジャイルへの理解は、「小さく始められるため、早く安い」というものといえます。
しかし、それはある部分では正しいのですが、根本的な部分では間違っています。
アジャイルは「早く安い」は本当か?
「小さく始められるアジャイル」は、プロジェクトの一部からだけでも始められるため、「少ない予算からでも始められる」と考えられています。
それ自体は正しいのですが、必ずしも最終的な予算が少なくて済むとは限りません。
大きなプロジェクトを掲げようと、小さなところから始めようと、最終的に到達したい明確な目標が決まっていないと、かえって手戻りが多くなる可能性をはらんでいます。
プロジェクトの進行を紆余曲折することは決して間違った開発手法だとはいえませんが、見切り発車で手探りの開発では、結果的には時間も費用も膨大となる可能性が高くなるのです。
「とりあえず小さく始める」だけでスタートすると、いつまで経ってもゴールにたどり着けず、費用がかさみ結果的に失敗するということも少なくありません。
アジャイルの開発ロジック
アジャイルの問題点を考えるには、従来の開発手法ウォーターフォールと比較して考えるのが、わかりやすくおすすめです。
ウォーターフォールのロジック
従来型の開発手法ウォーターフォールのロジックは、おおむね次のとおりです。
- システムの全体像を描く
- 開発までのシナリオを想定する
- シナリオごとの工数を見積もる
- 見積もった工数を積算し、チームの月間生産力で割る
- システム完成までに必要な期間を計算する
- チームの人件費と期間を掛け合わせ、導入予定のツール代金などと合わせた最終的予算を算出する
ウォーターフォールは、1度決めた計画どおりに開発を中長期にわたって実行していくため、取り掛かるのに時間がかかり、予算も膨大になりやすいというデメリットがあります。
その反面、想定外のことは起こりづらいので、工期や予算は決めたとおりに収まりやすいのです。
また、実績のないチームメンバーでも学びながら成長することができるため、初期段階からエキスパートを大量確保しておらずとも開発が進めやすいというメリットもあります。
アジャイルはロジックが確定しづらい
対して、アジャイルな開発手法では次のようなロジックがあります。
なお、アジャイルな開発手法とひとくちに言っても、さまざまな手法が存在します。
そこでここでは、現在の開発現場で多く用いられる「スクラム開発」と呼ばれるチーム制の開発手法を例に取り解説します。
【アジャイルのロジック】
- 明確なゴールが設定されている
- 導入するツールやアーキテクチャーが決まっている
- 開発に携わるチームメンバーが固定されている
- チームの生産力が予測できる
- チームに裁量権があり、独立した開発を進めやすい
- チームメンバーには最初からスキルと経験が求められる
こうしたロジックに基づいて進められるのがアジャイル開発の理想ですが、実際はそううまくいきません。
その理由の多くが、明確なゴールが設定されていないことと、スキルと経験のあるチームメンバーが固定されていない(確保されていない)ことです。
例えば、顧客満足度を最優先に動くのが開発の基本ですが、アジャイルではこまめにユーザーの声をフィードバックして、機能調整できるのがメリットと考えられています。
しかし、明確なゴールが設定されていなければ「雑多なユーザーの声」に振り回されてばかりで、一向に正解が見えてこないということすら起こり得ます。
そのような状況では、結果的に無駄な工程を繰り返すことも多くなり、手戻りばかりで工期や費用が想定外に膨らむ可能性があるのです。
工期と予算を拡大化させないシステム開発「スプリント」
本来の意味で小さく始め、工期と予算を拡大化させないアジャイルのメリットを最大限に活かすためには、明確な目標に向かって最短距離での開発を目指すべきです。
そのための手法として、スクラム開発の中でも特に重要な「スプリント(反復した計画立案と見直し)」という要素を紹介します。
スプリントとは
日本語で「短距離走」という意味をもつ「スプリント」とは、スクラム開発の基準となる考え方です。
スプリントでは、開発にかかる工期を1週間から1ヶ月前後を基準とした「タイムボックス」という期間に区切り、タイムボックスごとに使用の設計や開発、リリースなどを行い反復して開発を行います。
アジャイル開発では多くの場合数週間から数ヶ月といった期間でのトライアンドエラーを繰り返しますが、スプリットを設定することによりさらに短い期間に区切ることで多くのメリットが得られるのです。
スプリントのメリット
- 急な仕様変更や不測のトラブルにも対応しやすい
- テストとフィードバックがしやすく、ユーザーの声を色濃く反映できる
- 開発者が抱えている作業の意義を把握しやすく、短期目標でモチベーション向上につながりやすい
つまるところ、できる限り小さなPDCAを回し、短期間の目標に対してトライアンドエラーを繰り返すという考え方で望むことが、スプリントにもっとも求められることです。
スプリントの設定方法
スプリントは、おおまかに次のような流れで設定します。
プロダクト・バックログ作成
開発においての機能や改善が必要なものに対して、優先順位を付けます。
その際、スプリントごとに対応すべき内容をリスト化したものを「プロダクト・バックログ」と呼び、TO DOリストのように進捗状況の把握に利用します。
スプリント計画
スプリントで提供できるものやそれぞれの達成方法を示し、具体的にどのような内容や行動を取っていくのかを明確にします。
「誰が」「どのように」といった部分をできる限り具体化し計画を設計することが重要で、プロダクト・バックログとともにメンバー間で共有します。
【設計内容】
- 目標
- 期間
- 仕様詳細
- 作業内容
- 作業ごとの担当者
実施(デイリースクラム)
スプリントを実施します。
期間中は定期的なミーティング(デイリースクラム)を開催し、作業状況や本日の作業予定、現状の課題などを短期間で共有するようにし、進捗に問題があったり、特別な課題が見つかったりした場合は、即座に対処します。
スプリントレビュー
スプリント終了後に会議を行い、振り返ってシステムの検証をしますが、この検証のための会議(会合)をスプリントレビューと呼称します。
スプリントレビューにはプロダクトオーナーやクライアントといったステークホルダーが全員出席し、プロジェクトの進捗を確認するとともにフィードバックを行います。
ここで機能に問題がなければリリースへと移行し、問題があれば次のスプリントへの解決課題として持ち越します。
スプリントレトロスペクティブ
スプリントの最後には、チーム内でスプリントレトロスペクティブと呼ばれる反省会を行います。
良かった点や問題点を洗い出し、対策を話し合うことで次のスプリントがより効率的に進められるよう意見を出し合います。
スプリントレトロスペクティブが終われば、またプロダクト・バックログの作成へと戻り新しいスプリントが開始されます。
まとめ
アジャイルな開発手法に関する一般的な理解とその落とし穴。そして、アジャイルのメリットをもっとも効果的に進めるスプリントという考え方について解説しました。
アジャイルは一見メリットがたくさんある開発方法のように思えますが、メリットの表層だけを捉えて安易に始めると失敗に繋がる可能性が高い開発手法です。
早いから、安いから、というアジャイルで考えられるメリットは、いずれも明確な目標設定と最適な人材が揃っていなければ、そもそも手に入れることすらできません。
アジャイルによるシステム開発を成功させるには、明確なロジックと豊富な経験が必要なのです。
手探り状態で進めるだけでは、かえって工期も費用もかさむということがほとんどで、安易に飛びついてもアジャイルのメリットはデメリットへと変わりかねません。
自社のみで解決できない場合は、外部ベンダーと組むほうが費用面だけ考えてもはるかに得策ということは、往々にしてありえるのです。
目先の利益だけにとらわれず大局的な目でシステム開発が行えるよう、アジャイルの本質を理解した開発を行ってください。