アジャイルとスクラムの違いって何？（手戻りなんてしないんだ）

スクラム組んだら前にしか進まないだろ。
下がらないだろ？

曲がっても前進

システム開発はオリエンテーリングではない。
ゴールはなんとなくしか決まってない。
明確なゴールがないってことを共通認識として持つべし！

もちろん、売上10パーセントアップとかいった数値目標（KPI）はあろうが。
それはプロジェクトの目標。
システムそのものがお金を生み出すわけじゃない。
システムはあくまでも手段です。目標を達成する方法はたくさんあるんだし。

ここで言うゴールは、システムの完成形のこと。
目標達成の手段として、道具となるもののかたちは、ケースによってそれぞれ違う。
いろいろやってみて、結果的に目標を超えちゃってもいいよねってのがアジャイル手法の基本的な発想。

オリエンテーリングは、スタート地点も経由地点もゴール地点も決まってる。
けど、現実の業務じゃあそうはいかんのよ。

ゴールは変わる前提

スタート地点からだと明確なゴールは見えないよねってゆー例ね。
昔の映画で、未来を描いてるものがある。

けど、正確じゃないでしょ。

現在地（スタート地点）から見えるゴールなんて、しょせんはぼやけてるもんなんだってのが大前提。
走りながら、未来は変わるんだよ。
だから開発するものも変化するって前提。
環境要因での変化もありえるからね。

徐々に見えてくるゴール

霧の向こうのゴールに向かうようなイメージ。
なんとなく見えてはいるけど、ゴールに近いほうが、そのかたちは見えやすい。

あんなものつくりたいなってイメージはあるんだろうけど。
想像の世界のもので、他人との共有は非常に難しい。

ゴールが分かってたとしたって、地図みたいに俯瞰した視点がなきゃ、道のりなんて割り出せない。
最短距離でゴールに到達できるに越したことないんだけど。
システム開発しようってんだから、同一事例は少なくて、類似ったって他人のことだから、自分たちには当てはまらんでしょう。
道しるべなしで、ゴールと思しき方向へ行くしかないんだよ。

変化する要素もあるから

加えて、変動要素もある。

• 予算が変わっちゃう
• 世界が変わっちゃう

特に、外的要因による変更なんて、いいものから悪いものまで、いろいろあるでしょ。

そうなると、ゴール地点が変わっちゃうってこともありうる。
ルール違反ぽいけど、現実世界じゃあ往々にして起こりうる話だ。

とにかく進むしかない

暗中模索とか、五里霧中とかいったことばが当てはまるような。

ゴールの方に向かって、ゴールと思しき地点との距離を測って、また向かう。
近づいても進んでるし、離れても進んでるし、ゴールとの距離が変わらなくても進んだことは事実。

そうやって、細かい単位でチェックするから、ゴールから大きく外れることがないでしょってのがアジャイル手法のメリット。
ゴールに近づけば目的地は分かりやすくなるし、目的地が変わってることにも気づきやすい。

確認頻度を多くする手法

てなわけで、短い期間を区切って、そのたびに自分の位置を確認しながら、ゴール地点と思われる方に進んでいくんだ！

この「短い期間」ってのを「イテレーション」と呼ぶ。
アジャイル開発手法のときに登場することば。

そして、スクラム手法の場合は、イテレーションを「スクラム」と呼ぶ。
イテレーションの単位は、2週間から4週間が一般的。

イテレーションのたびに、もしくはスクラムのたびに、PDCAを回すよ。
つまり、計画して、実行して、評価して、改善する。
だから、アジャイルが進めば進むほど、プロジェクトの作業効率が上がっていくと期待できるわけだ。

たとえば、イテレーションが3週間なら、あらかじめ3週間で何するかは提示しておいてもらって、

• 最初の1週間で機能確認
• 次の1週間で実装
• 最後の1週間でユーザー受入テスト

みたいな感じ。
だから確認する側もタイムリーに回答返さないと、プロジェクト全体が遅れる。

説明が足りてないと悲劇に

上の例で見るところの「最後の1週間」でユーザー受入テストになるでしょ。
そんときには動く画面が見れるわけよ。
ここでは完璧なものってわけじゃなくて、ある程度ゴールに近づいたものだから。

早いタイミングで確認できるものは最終納品物レベルの完成品じゃない。
そのイテレーション内で、成果を見られる状態になったもの。

だから何をチェックするかってのも先に決めとく。

そうしないと、品質が悪いとか、機能ができてないとか、動かないとか、もうできたのかとか、だったら機能追加しろとか、ユーザーから無理難題が上がってきちゃうんだよ。
これはプロジェクトリスクってやつね。
そんでもって、まず見てみてから手直しすればいいみたいなことを言い出す人が出てくる。
これはやばい。

どうしても先行確認が必要なら仕方ないけど、手戻りを前提とした進め方はよくない。
結局、手戻りはスケジュール遅延の原因になるし、使われないものを作らなきゃいけない技術者のモチベーションを下げることになる。
チームのみんな人間だもの。
モチベーション管理ってのもけっこう重要なんだよ。

アジャイルは、手戻りを前提とした開発手法ではないし、アジャイルだから速いってこともない。
システム開発に近道なんてない。
ゴールが見えにくいのはだれにとっても同じ。
アジャイル開発の場合は、細かい期間で評価と改善が可能だから、軌道修正しやすいってこと。
んでもって、その前提になるのは、ユーザーからの小まめなフィードバック。ユーザーがスケジュールどおりに対応できなければ、開発も遅れる。
決められた指標で評価して改善しながら、若干ブレつつも、ワンチームで開発を進めていくんだよ。