はじめに
当方１０年以上ウォーターフォール開発のみを行っており、アジャイル開発って何？ウォーターフォール開発とだいたい同じでしょ！というような軽い気持ちでアジャイルスクラム開発の現場に参加し、大変な苦労をしました。。。
なので同じ苦しみを経験する人が少しでも減るよう、私が感じた事などを踏まえつつアジャイルスクラム開発を経験する前に知っておいた方が良いことなどをまとめます。
アジャイルスクラム開発とは？
まず、私も勘違いしていましたがアジャイル開発とスクラム開発というのはイコールではなく、別物となります。
アジャイル開発：開発→検証→リリース→開発→検証→リリース...を短い期間で繰り返す。
スクラム開発：チームの連携を重視し、一致団結してシステム開発頑張る！
簡単に言えば上記のような内容となります。
アジャイルとスクラムがセットでよく扱われるのは、アジャイルとスクラムの相性が単純に良いからです。
それでは、まずはアジャイル開発から書いていきます。
アジャイル開発とは？
アジャイル開発未経験の場合、恐らくどの現場でも最初に見せられる資料はこれでしょう。
https://agilemanifesto.org/iso/ja/manifesto.html
これはどこかのお偉い方々がアジャイルという開発手法についての定義を話し合った結果、決定された内容が書かれています。
- プロセスやツールよりも個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも変化への対応を
上記のようなことをアジャイル開発では重視するよ！と書かれています。
ここで一つ大事なのは、右側に書かれている内容をより重視するが、左側もおろそかにしないよ！と書かれていることです。
どっちも大事だけど、どっちかっていったら右側の方が重要だよね、というぐらいに理解しておくのがよいかと思います。
アジャイル開発とウォーターフォール開発の違い
ここが一番理解するのに苦労しました。
どうしてもウォーターフォール開発を経験していると、「アジャイルって要はウォーターフォールの小さいやつでしょ？」というような認識をされている方が多い気がします。
上記との違いを簡単に説明すると、アジャイル開発というのは
まだ何やりたいか全部は決まってないけど、とりあえず動き出そう！
開発に時間が掛かり、開発中にも新しいトレンドや要素を取り入れる必要がある！
という案件に対して行う開発手法だと私は理解しています。
ウォーターフォールはいくら小さくしようが、最終成果物は完成品となり、そのままリリースなりを行うのが一般的だと思いますが、アジャイルの場合は、極端に言えば完成品でなくて良いのです！
例えば、ある情報を一覧化して表示する機能を開発するとします。
そうですね、、、仕様としては、
- データが一覧で表示される
- 各データに対して更新削除ができる
こんなところにしておきましょうか。
ではこれをウォーターフォールとアジャイルで開発するとどう違うかを説明します。
ウォーターフォール開発の場合、恐らく全ての機能が実装された一覧表示機能を開発してリリースするでしょう。
それに対してアジャイル開発では、まずデータが一覧で表示されるという部分のみを開発してリリースします。
次に、各データに対して更新削除ができるという部分を開発してリリースします。
ここが大きなポイントです！
もし上記機能がすべて必須であり、既に必要な機能として決定しているのであればウォーターフォールで開発を行うべきでしょう。
アジャイルでは、「データが一覧で表示される」という価値と、「各データに対して更新削除が行える」という価値を分割することで、最小単位の価値(MVP[Minimum Viable Product]/後述あり)を構築していくことを目的としています。
MVP(Minimum Viable Product)とは
アジャイル開発として、私はこれが一番重要な考え方なのではないかなと思っています。
前述のアジャイル開発についてでも少し触れましたが、MVPとは顧客にとって価値があり、かつ最小限の単位の事を表します。
ソーシャルゲームを想像してみてください。
最近のソーシャルゲームで、リリース当初は項目だけ用意されており「Coming Soon」となっていて使えない機能を見たことがあるのではないでしょうか。
これが顧客にとって価値があり、かつ最小限の単位という考え方となります。
顧客への最小限の価値としては大筋のゲームがプレイできるという物であり、
マルチプレイができるやUIのカスタマイズができるというのは最小限ではなく、後々実装すれば良い機能であると考えます。
ちょっとまって！
それじゃあマルチプレイができるゲームがやりたい！と思っている顧客にとっては、最小限の価値を満たせていないのでは？
と思った方、その通りです。
最小限の価値とは、ターゲットとなる顧客や状況によって変わるものであり、
顧客やプロダクト状況を見ながら、何が最小限なのか？を都度判断していく必要があります。
ユーザーストーリー
アジャイルスクラムの開発では、機能等でタスクを作成しません。
必ずユーザー(顧客)が求めている、困っていることは何か？→それをこう解決してあげよう！というタスクになります。
※ユーザーストーリー例
＜ユーザ＞が＜困っている事or求めている事＞を解決する為に＜実現すること＞を行う。
そうすることで＜価値＞が達成される。
ここで大事なのは、このタスクを実施した時に得られる価値とは何か。
本当にユーザが望んでいる価値が満たせるのかが重要であるという点です。
以下の図を見た事ある方は多いのではないでしょうか。
上記の図は、作業の内容だけを見て開発を行うとこうなりがち！という例です。
どうしても仕様書を渡された人は、仕様書の内容を実装するという所に視点が行きがちですが、本当に大事なのは顧客が何を望んでいるのか？という本質の部分です。
これを見失わないように、アジャイル開発ではユーザーストーリーという形を採用しています。
スプリント(イテレーション)
アジャイル開発では、一定の開発サイクルを繰り返し行いますが、この一定の開発サイクルの事をスプリントと呼びます。
(スプリントというのはどちらかというとスクラム開発の呼び方であり、アジャイルではイテレーションと言うそうです。)
１スプリントの期間についてはプロジェクトによって様々ですが、２週間＝１スプリントとしている事が多いそうです。
この決められた１スプリント毎になんらかの機能や成果物を作成することになります。
また、作成されるタスクについては、大きくても１スプリントに２つは入るサイズにするというのが通例なようです。
(２週間＝１スプリントの場合、１つのタスクは大きくても１週間で終わるサイズでないとダメ。超える場合はタスクを分割するなどの対応をします。)
長くなってしまったので、次へつづきます。