アジャイルコーチとして、お客さん先でプロセス改善のお手伝いをしているとたびたびでてくるのが「それってアジャイル開発だっけ？」というもの。そういったことは暇人か学者に任せればいいと思っているのですが、そういったお題についていろいろ話すと相互理解も進むので、今回はそのあたりをできる！と噂のアジャイルコーチにうかがってみました。
質問： スプリント内で設計、実装、テストみたいなタスクを作ってもいいの？
さぁ、スクラムをはじめよう！ とスプリントをはじめてみたけど、計画づくりで設計タスク、実装タスク、テスト・・・みたいにこれまでどおりの形でタスク分割してしまっていいのでしょうか？
たとえば、スプリントの使い方によって、以下のように名前をわけてみましょう。
- スプリント内で機能ごとに開発をすすめる方法をアジャイル開発・スクラムとする
- スプリント内で開発フェーズを区切って開発を進める方法を反復型開発とする
- スプリントを指定せず開発フェーズを区切って開発を進める方法をウォーターフォールとする（上の図のウォーターフォール1）
- 「スプリント＝開発フェーズ」で区切って開発を進める方法をウォーターフォールとする（上の図のウォーターフォール2）
ポイントは、繰り返す軸が「機能」か「期間」です。
軸が「機能」の場合、機能単位でリリース可能な状態にしていくので、リリース計画を柔軟に変更できます。
軸が「期間」の場合、リリースのスコープを最初に計画しているところはウォーターフォールになりがちですが、反復型の場合、ウォーターフォールよりも計画の柔軟性が上がります。
反復型がアジャイルなのか、スクラムなのかを判断するのは難しいですが、スクラムガイドを見てみると、「完成の定義」や「スプリントレビュー」といった「機能ごとで出荷可能であるかどうか」を前提に書かれているように見えるので、その点が違うことを認識した上で選択するといいと思います。
さすが、いいこといいますね！ 反復型開発とわけるととてもわかりやすいです。それぞれに特徴があるので使い分けですね！
次の質問です。
リリース日といった締め切りありきの開発って多いと思うんですが、イテレーションやスプリントって固定の期間ですよね。しかも、それぞれの終わりでリリースしない場合もありますし。締め切りありきでスプリントを回すのってスクラムになるんですかね？
なんとも言えないし、あるあるですね。
でもリリース判断自体を変えられるのであれば、スクラムって言ってもいいんじゃないですかね。ただ、考え方によって以下のように意味合いが違います。
- スプリントを中心に考えると、常に開発サイクルがまわっている状態で、プロジェクトごとにリリース計画（締め切り）を考えていく形
- 締め切りを中心に考えると、プロジェクトごとに締め切りをつくって、そこにスプリントを合わせていくイメージ
また、スプリントをまわしたい理由は、比較して改善・学習しやすくすることなので、その恩恵が受けられそうであればどちらでもいいけど、締め切り中心の場合は「どこまでやる？」という判断を、毎スプリントでしたほうが安全に見えます。
本当に勉強になります！ それぞれのメリット・デメリットを考えると、以下のように思います。
- スプリント中心： ベストエフォート型の開発。できる範囲をベースに考えるので軌道修正が楽なのがメリット。ただ、規律がゆるいとどんどんスケジュールが伸びてしまいがちなのがデメリット
- 締め切り中心： 締め切り駆動なので危機感ばっちりなのがメリット。ただ、期限に合わせてスコープ調整する前提になるので、できることしかやれなそうなのがデメリット（期待以上のものができない）
最後の質問です。
これまでの話を踏まえて、そもそもアジャイルやスクラムかウォーターフォールかの決定的な違いってなんなんですかね？
うーん難しいｗ
主軸が「計画ありき」なのか「変化ありき」なのかでしょうか。
ウォーターフォールでも反復型開発にしたり、色々工夫すれば変更容易性を上げることはできると思いますが、最初に考えた締め切りという単位はよっぽど変わらないし、変わる場合は変更コストが大きい。
アジャイル開発やスクラムは、当初の計画から変化しても変化しなくてもどっちでもよくて、リリースしたいタイミングですればいいし、機能ごとに作っているだけなので、変わる場合の変更コストは比較的小さい。
なので、結局締め切りという計画前提で仕事している場合は、あんまり変わらない可能性があります。ただそれでも当初の計画というのは変わるので、その変化の幅をどれくらいまで見越しておくかなんですかねー。
ある程度見通しがついているならウォーターフォールで一気に走ったほうがオーバーヘッドも小さくて楽そうだし、そうじゃないのであれば多少オーバーヘッドがあってもアジャイル開発（スクラム）のほうが変化に対応しやすそうです。
スケジュール（期限）があるのはよくあることですが、スケジュールに対する考え方が違うってことなのかなと思いました。
ウォーターフォールは締切からの逆算型。でありながら詰め込みまくるので逆残にもなってないケースが多いのが問題。
アジャイル開発やスクラムは現在からの積み上げ型。どう帳尻を合わすかプロダクトオーナのセンスだし、スプリントという区切りがあるので変更が楽そう。
いろいろと教えていただきありがとうございます！ 味噌汁で顔洗って出直してきます！
変化を抱擁せよ！ 変化を恐れるな！ 変化を楽しもう！ という言葉はよく聞きますが、どれも別に何かを指し示しているわけではなく、「地球は大切」ぐらいのふわっとしたスローガンでしかないのであんまり響かないように思うんですよね。
なによりも、何をすべきかを明確に指し示していないし。
では変化とはなにか？
それはつまりひとことでいうと、学んで学びを活用することなのではないかとアジャイルモンスターと話していて思いました。
個人的に思うのは、アジャイル開発でもテスト自動化でも、世界のトレンドなら何でも、変化の大きい何かの敵はマインドセット（考え方）だと思っています。
たとえば、成長しない若手だったり、仕事ができないおじさんだったり、過去の栄光にしがみつくおじいさんであったり、マインドセットを変えるのはとても難しい、というかほぼ不可能だろうけど、仮に学んでこなかったからこうなってしまったのであれば、まだなんとかなりそう。
だって、考え方は変わらないかもしれないけど、学びはいつでもはじめられます。
旅と子育てとアジャイルコーチのブログ「世界」 