アジャイル開発について
はじめに
急遽これまでの案件とは毛色が変わったアジャイルベースの案件に参画することになったので、ざっと勉強した内容をまとめました。
アジャイル初心者に向けた基本的な内容になっているのではないかと思っています。
アジャイル開発(スクラム)について
そもそもプロダクト開発の目的は何か
そもそも何かを生み出すことの目的は何かを明確にすることが大切である。
- プロダクト自体を開発すること？
- プロダクトを作って利益を上げること？
ほとんどの開発は後者が目的。では、その成果(利益)を最大にするためには何が必要か。
- 利用できるものを作る
- その評価を受ける
- 評価をもとに改善する
このサイクルを継続することが大切である。
では、このサイクルの中で新しいアイデアが出てきた場合はどう対応するのか？
ウォーターフォールでは、追加アイデアを案件の中で組み込むことが非常に難しい。
また、組み込んでも実際にサービスインしないと実際の評価を得られない。
そのため、サイクルを短くして、最小限のものを作ったうえ評価を受けながら、短期間に追加アイデアを対応していく手法がアジャイル開発である。
アジャイル開発とは
以下のような進め方を一般的にアジャイル開発手法と呼ぶ。
- 目的達成のために関係者が協力して進める
- 一度にまとめてではなく、早い段階で実際に動作するものを 小さく 作成し、評価を受けることを繰り返す
- 利用者の フィードバック を継続的に得ながら、作っているもの自体や計画を調整する
アジャイル開発のうち、主な手法に以下のものがある。
- スクラム
- エクストリーム・プログラミング(XP)
- カンバン
これらに共通するのは、
「事前に全てを正確に予測し、計画することは出来ない」
ということを前提にしている点であり、計画は変更されるものとして開発を進める手法となっている。
アジャイル開発では、
- どのくらいの期間・人数で、
- その範囲の中で大事な要求に優先順位をつけ、
- 優先度の高いものから対応していく
そのため、従来のウォーターフォールでの見積手法とは異なることに注意する。
基本的な考え方として、重要なもの・リスクの大きなものから先に作り、そうでないものを後回しにすることで、成果を最大化していく。
スクラム手法とは
1990年代から提唱されている手法で、以下の特徴がある。
- 要求を価値やリスクや必要性を基準にして並べ替えて、その順にプロダクトを作ることで成果を最大化する。
- スクラムでは固定の短い時間に区切って作業を進める。固定の時間のことを タイムボックス という。
- 現在の状況や問題点を常に明らかにする。これを 透明性 と呼ぶ。
- 定期的に進捗状況や作っているプロダクトで期待される成果を得られるのか、仕事の進め方に問題がないかどうかを確認する。これを 検査と呼ぶ。
- やり方に問題があったり、もっとうまくできる方法があったりすれば、やり方そのものを変える。これを 適応 と呼ぶ。
スクラムは分かっていることよりも分からないことが多いような複雑な問題を扱うことに適しており、
5つの イベント (会議等)、3つの ロール (人の役割)、3つの 成果物 など最低限のルールセットで構成されている。
このルールは最低限のため、どのように適応していくかは各々で考えて取り入れていく必要がある。
これ以外のルール（コードの書き方やテスト方法等）は各々で状況を踏まえて取り入れていく必要がある。
スクラムで決められているものは以下の通り。
- 機能や要求を並べ替える
- 成果物1： プロダクトバックログ
- プロダクトの責任者
- ロール1： プロダクトオーナー(PO)
- 動作するプロダクトを開発する
- ロール2： 開発チーム
- 短く区切って繰り返す
- イベント1： スプリント
- 頻繁に計画する
- イベント2： スプリントプランニング
- 成果物2： スプリントバックログ
- スプリントごとに完成させる
- 成果物3： インクリメント
- ゴール達成に向けた日次検査
- イベント3： デイリースクラム
- スプリントごとの成果レビュー
- イベント4： スプリントレビュー
- 問題がなかったか、より成果を出すための検査
- イベント5： スプリントレトロスペクティブ
- プロダクトオーナーや開発チームを支える
- ロール3： スクラムマスター
プロダクトバックログ
機能や要求、要望、修正などプロダクトに必要なものを抽出し、順番に並べ替えたリストであり、プロダクトバックログはプロダクトに1つ。
項目の順番は、その項目が実現されたときに得られる価値やリスク、必要性で決定する。
それぞれの項目は、プロダクトバックログ上で一意な順番をもち、上位のものから開発を行う。
そのため、上位のものほど内容が具体的で詳細なものになる。
計画を立てる際に必要になるため、それぞれの項目(特に上位項目)は見積もられている必要がある。
ただし、ここでの見積は、時間や金額などの絶対値ではなく、作業の量を相対的に表した値がよく使われる。
プロダクトバックログはプロダクトを作っている間は常に新しい要求や対応項目が発生するため、常に更新され、最新の状態でなければならない。
プロダクトバックログの項目は決まっていないが、ユーザーストーリーと呼ばれる形式で書かれることが多い。
ユーザーストーリーとは、
プロダクトの機能をエンドユーザーや顧客の視点から堅苦しくない一般的な言葉で説明する
ものであり、 「誰に」この機能を利用してもらうのかを明確にする。
プロダクトオーナー(PO)
プロダクトバックログの管理者であり、1プロダクトに1人。
プロダクトバックログの並べ替えのほかに次のようなことを行う。
- プロダクトのビジョンを明確にし、周りと共有する
- おおよそのリリース計画を立てる
- 予算を管理する
- ステークホルダーとプロダクトバックログの項目内容の確認や順番・実現時間を相談したりする
- 既存のプロダクトバックログの項目の内容を常に最新の状態に更新する
- プロダクトバックログの項目の内容を関係者が理解できるように説明する
- プロダクトバックログ項目が完成しているか確認する
POが決めたことは他人が覆してはいけない。PO自身が結果に責任をもつ体制にすることが大切。
開発チーム
開発チームの役割は、POが順位付けしたプロジェクトバックログの項目を順番に開発していく。
開発チームは以下の理由のため、通常3～9人までで構成されている。
- 3人未満の場合は、お互いの相互作用が少ない・個人スキルに依存する
- 10人以上の場合、コミュニケーションコストが増える
開発チームはプロダクトを作るために必要な全ての作業が出来なければならない。
例えば、要求の分析をする、設計する、サーバを構築する。コードを書く、テストをする、ドキュメントを作成する等。
これを 機能横断的なチームと呼ぶ。
「分析チーム」や「テストチーム」などの特定の分野のみ対応するチームを作らないことがポイント。
能力差はあれど、個人が複数のことが出来るようになることが望ましい。
開発チーム内に役職や特定の肩書を作らない。
開発チーム内での仕事の進め方は、開発チームメンバーで合意し、外部から仕事の進め方を支持されることはない。
あくまで開発チームとして責任をもって作業を進める。これを 自己組織化 と呼ぶ。
スプリント
最長1か月の固定の期間に区切って、繰り返し開発を行う期間。(2週間ごと等。1週間と4週間が混ざっているものは×)
開発チームはこの期間の中で、計画、設計、開発、テスト等プロダクトバックログ項目を完成させるのに必要な作業をすべて行う。
固定期間で区切ることで開発チームにリズムが出来て、集中でき進捗把握などもしやすくなる。
スプリント最終日に作業が残っていても、スプリントを延長することはない。次回のスプリント内で対応などを考える。
スプリント期間はメンバーやプロダクト規模などを考慮して、1週間～4週間の週単位で設定することが一般的。
なお、状況の変化によって現在のスプリントでの作業が意味がなくなった場合は、POの判断でのみスプリントを途中で中止することが出来る。
スプリントプランニング
スプリントを始める前に、何を作るのか、どのように作るのかを計画する必要がある。
この計画を決めるためのイベント(会議)をスプリントプランニングと呼ぶ。
ここでの時間は、1ヶ月のスプリントであれば、8時間を目安に、期間に応じて変更する。
スプリントプランニングでは2つのトピックを扱う。
スプリントで何を達成するかを決定する
最初にPOが今回のスプリントで達成したい目的を明らかにする。
次に、今回のスプリントでそれを達成するために完成させるべきプロダクトバックログ項目を選ぶ。選ばれる項目はバックログの上位項目であることが一般的。
選択する項目数は、これまでの実績(ベロシティ)や見積サイズ、作業に使える時間(キャパシティ)を踏まえて仮決定する。
検討した内容を踏まえ今回のスプリントの目標を決める。これをスプリントゴールと呼び、開発チームがスプリントで対応する項目の理由を理解しやすくなる。
プロダクトバックログの上位から順にスプリント内での開発対象を決定するため、上位項目は内容を具体的にする、 項目の疑問点を解決する、何が出来れば完成なのか(受け入れ基準)を明確にする、項目を扱いやすいサイズに分割する、 項目を見積もる等の事前作業が必要になる。この活動を、 プロダクトバックログリファインメントと呼ぶ。(単にリファインメントとも)
リファインメントはスプリント直前では間に合わない可能性があるため、余裕をもって行う。 スプリントの10%以内の時間で行うのが、一般的。開発チームがどのように選択したプロダクトバックログ項目を実現するかについて計画を立てる
選択した項目ごとに具体的な作業を洗い出し、必要な作業計画を立てる。選択したプロダクトバックログ項目と作業の一覧を合わせて、 スプリントバックログ と呼ぶ。
スプリントバックログは開発チームの作業計画であり、スプリント期間中も自由に作業を追加したり削除したりすることが出来る。
個々の作業は1日以内で終わるように設定するのが一般的。
スプリントバックログを検討した結果、1.で選択したプロダクトバックログ項目を完成させるのが難しいと開発チームが判断した場合は、
POと相談し選択したプロダクトバックログ項目の一部を外したり、作業計画を検討しなおすことにより、作業量を調整する。
この時注意すべき点は、開発チームはスプリントプランニングで合意した内容を完成させるように全力を尽くす必要はあるものの、
計画したことをすべて完成させることを約束するわけではないという点である。
全ての完成を約束してしまうと、見積が外れたり、難易度が高かったり、不測の事態が発生したりした場合に、開発チームが長時間残業したり、
必要な作業を省いてしまう可能性が出てくる。
その結果、プロダクト全体に様々な問題が発生することに繋がる。
スプリントバックログの担当者は事前に決めておく必要は無く、担当者が着手する際に項目を選択するようにする。
インクリメント
スプリントごとに過去のスプリントも合わせて、これまでに完成したプロダクトバックログ項目を合わせたもの。
多くの場合、動作しているプロダクトとして提供され、スプリント終了時点で完成していて正常に動作しなければならない。
そのため、POと開発メンバーが同じ「完成像」に向かう必要があり、そこには共通の基準が必要である。
それを、 完成の定義と呼ぶ。開発チームはこの定義を満たしたプロダクトを作らなければならない。
完成の定義としては、以下の項目があげられる。(一例)
完成の定義は言い換えると、品質基準とも言える。項目は後から追加しても良いが、削除するのは品質が悪くなる可能性があるため、注意が必要。
デイリースクラム
計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを調整するために、日々行うイベントである。
デイリースクラムにおけるルールは以下の通り。
- 毎日
- 同じ時間
- 同じ場所
- 割り当てられたタイムボックスは15分(時間超過厳禁)
時間超過する場合(何らかの問題が発生している場合)は別途時間を設けて、話し合うようにする。
朝会として作業開始前に行うことが一般的。
形式としては、以下の3つの質問に答える形で発言する。
開発者の状況を日々共有することで、プラダクトの透明化を図り、各自の進捗や状況を把握し、計画の修正や作業方法の改善を行う。
ただし、デイリースクラムが単に進捗報告の場にならないようにすることが重要。
あくまでもデイリースクラムの目的は、「 スプリントゴールの達成」であることを意識する。
POと開発チーム全員がこの目的を把握し、デイリースクラムを行うことで、発生している問題点や、進捗の遅れなどをいち早くキャッチし、
スプリントゴールの達成、さらにはプラダクトの完成に障害となりうるリスクを排除できる。
スプリントレビュー
スプリントの終わりに、スプリントゴールの達成を振り返るイベントである。
以下のようなことを実施する。
- 完成した機能を顧客に実演する
- プロダクトバックログ項目を更新する
- 今後の開発の見直しを示す
つまり、「このスプリントでの成果は何だったか」、「残タスクはどのぐらいか」、「そのタスクをどのように処理するか」を話し合う場として実施する。
参加者としては、ステークホルダーとスクラムチームがあげられる。特にステークホルダーには必ず出席してレビューしてもらうことが大切である。
スプリントレトロスペクティブ
スプリントの最後に行われる、スプリントの振り返り会議。
スプリントレビューとの違いは、スプリントレビューが「スプリントの成果」にフォーカスするのに対し、
スプリントレトロスペクティブはチームの動き等の「スプリントのプロセス」にフォーカスすることが特徴である。
スプリントレトロスペクティブの目的は、 今後のスプリントをより良く実施し、スプリントの効果と成果物の品質を上げることである。
話し合うポイントとしては、以下の内容があげられる。
- 直近のスプリントの評価
- 良かった点や今後の課題について話し合う
- スプリントの中で課題を解決した事例があれば、それを取り上げる
- 次回以降のスプリントにおける改善点を出す
会議の時間は最長で3時間を目安に、スプリント期間に応じて短く設定することも可能。
ただし、短すぎるとおざなりな内容になるため、ある程度まとまった時間を確保する方が良い。
スクラムマスター
スクラムを理解し、スクラムの進め方が出来ているか管理し、円滑に進めていく役割を担う。
スクラムマスターの役割は、
とされ、チームの秘書のような役割ではないことに注意が必要。
自己組織化されたチーム は日々のタスクをどのように処理するか決定権を持った存在である。ただし、スクラムでチームが決定できる範囲は、
スプリントゴールとスプリントバックログを、完成の定義として合意された品質で提供するために、チーム自身でどう進むべきか？
に限定される。言い換えると、誰がどのタスクに取り組むのか、メンバー同士でどう助け合うか、新しいものを学ぶ必要があるのはいつか、
1日の作業の優先順位をどうつけるかを、外部の権限にとらわれず、チームが決められるようにしておかなければならない。
また、自己組織化したチームは、スプリントゴール・バックログ・動作するプロダクトを期間内に提供するという範囲内で権限を持つことを意識する。
スクラムマスターは、自己組織化したチームを構築し、企業のあらゆる階層で基本原則として自己組織化が行われるように努力する。
スクラムマスターの役割をまとめると、以下のようになる。
- スクラムマスターの目標は、自己組織化を促進すること
- スクラムマスターは、コーチでありファシリテーターである
- スクラムマスターは、デリバリーに対して責任を負わない
- スクラムマスターは、チームの秘書ではなく、チーム自身で障害を乗り越える手助けをする
- スクラムマスターは、チームが責任を持つように促す
さいごに
いろんな情報をざっとまとめた形ですので、ふわっとした部分もありますが、アジャイルとは何かを把握できたと思います。
やはりウォーターフォールに比べると考え方が違うので、慣れるまでにかなり時間がかかりました。ウォーターフォールしかやっていない人がアジャイルに入ると、超短期間のウォーターフォールになってしまい、ただただ苦しい事態が発生します。初挑戦する場合はスクラムマスターを外部からでも招集する方が、長期的に見ていいのではないかと思います。
ご覧いただきありがとうございました。
