アジャイルは戻らない（小さい前進の繰り返し）

要件定義にて。 こんなことがあった。

いや待て。手戻りすれば時間は食うんだぞ。
無駄手は打ちたくないだろ～
費用に跳ね返るし。

ユーザーサイドとして最低限知っておくべきことをまとめてみる。
あくまでもざっくりと。シンプルに。

より深い理解のためには、本とか読んでね。

「アジャイル開発」とは概念だ

アジャイルは概念です。
その下に、いくつかの手法がある。
スクラムが有名だと思うけど、他にもある。（他はやったことないから分からん！）

あくまでも考え方。だから、みんなが同じ考え方を理解してないとうまくいかない。
ここ大事。

なんでも共通認識は大事なんだよ。

軽いとか、簡単だとかってのは、思想理解あってこそ。
あと、そんなに簡単なことじゃない。開発には変わりないからな。

スクラム手法ベースで考えると、あらかじめ決めた期間で、作業、確認、振り返りを繰り返す。
PDCAを細かく繰り返しましょうって話。確認タイミングが多いから、そもそも手戻りなんて概念が存在しない。すべては前進なんだよ。

ウォーターフォール開発と比較されるよね。

手戻りを未然に防ぐ考え方

早めに、目に見えるものをつくってユーザーと共有することで、認識の差異を小さくしようってこと。
開発者とユーザーの間には、どうしたって埋まらない溝があるのですよ。

で、目で見えるものの代表格がモックアップ画面とかラフ画面とか言われるもの。
機能実装されてないけど見た目はそれなりの画面。
これをコーディングしちゃう。
作りながら走る。

そーすることで、ユーザーの認識は高まるし、作り込んだものも無駄にならない。
ユーザー目線だと、実装されてない機能を想像しながら、こうやって使うんだよねってゆー認識も含めて確認しとかなきゃね。
開発者視点でいけば、ちゃんと使えるかたちでコーディングしないと無駄になる。ある程度の技術力が求められるよ。

見た目の確認ができたら、できたねって文書を残す。
改善が必要なら、改善しようねって文書を残して、今やるか、後でやるか決める。

重要で必須な改善ならすぐに、後でもいいものは後で、ってな感じ。

とにかく、ラフから組んでく。んで、記録を残す。

ウォーターフォール開発だと、できあがりをいきなり見ることになる。
設計書を書き終わったタイミングと、開発が終わったタイミングで成果物を見ることになるから。
指摘チャンスが少ない。あと指摘すると確実に手戻りになる。

要件定義は必須

見えるものを作るにしたって、方向性は決まってないとね。
それはいわゆる要件定義。

要件定義書からアジャイルで作るってのもアリではあろうが。
かなりの難易度になると思うよ。
そもそもアジャイル理解してない人たちで始めると、いつまで経っても終わらないってことになる。

要件はしっかり決めた状態で、設計、開発、テストあたりをアジャイルでってのがスムーズかと。
なんとなくの方向性とか全体像とかが決まってないと、何が優先とか決められないでしょ。
要件定義よりも上位の何かがあればいーんだけど。
要件定義書があるからこそ、以降のフェーズで改善ベースの開発作業を進められるってもんよ。

ドキュメンテーションも必須

とにかく文書化。
記録。

言った、言わないを避けられるし、やったこととやってないことが明らか。

アジャイル開発には都度の「改善」も含まれてるから、ちゃんと振り返るためにも、ドキュメンテーション必須。

議事録にする必要はなくて、課題管理ツールとかでもいいんだよ。
だからBacklogとかRedmineとかJiraとか流行ってるんだろ。
記録を残して、重要度も、緊急度も、作業実績も管理できる。必要な尺度で評価できるしね。

いつやるかの見通しもつく。
ユーザーも積極的に参加しなきゃね。

ドキュメントの量は、ウォーターフォール開発よりも多くなるんじゃない？

メリットもあればデメリットもある

アジャイルでなんでもできるって言い方されるんだよね。。
たしかにそーなんだろうけど。

うまくいくこともあれば、うまくいかないこともあるからな。
絶対に成功する方法ってわけじゃないから。

なんにでもメリットとデメリットはあるんだよ。
完成形がしっかり決まってるなら、ウォーターフォール開発の方が向いてるだろ。完成形にコミットすればいーんだから。
アジャイルは、完成形が決まってないものに向いてるったって。どこに向かうかは決めないと、アジャイルでの手戻りだって積もってくよ。

ユーザー負担はウォーターフォールとほとんど変わらいと思うんだ。
作業量が必要になるタイミングと頻度が違う。
アジャイルは高い頻度で小規模なものが定期的に。
ウォーターフォールはフェーズ終わりに大規模なもの。

必要なことは変わらない

要件定義はできてるって前提で。
そのときにもけっこうユーザーがやることあるんだけど。

その後の確認サイクルでは、スクラムだと、3週間とか4週間ごとに確認が必要。
見る量は多くないけど、そこでの決定はそのままシステムに跳ね返るからね。
定期的に確認してください。

ウォーターフォール開発で確認する設計書の枚数とアジャイル開発で確認する設計書の枚数は、同じシステムなら、同じでしょ？
むしろ改善を繰り返すアジャイルの方が延べ数では多いかも。

よりよいものができるはず

ちょっとずつ確認してくから、手戻り量は少なくなるはずだよねって考え方。
完成形からの手戻りに比べれば、まず軽く作ってみた程度のものの方が修正しやすかろうと。
設計書も都度書いてくし修正してくから。
手直しが必要な部分が見えやすいしね。

ものづくりだから。

手戻り量が少なくなったら作業量が節約できるから、結果的に、いいものを作るための作業にリソースを回せるでしょ？ってこと。

短期開発など可能性に過ぎない

完成形のコード量が100だとしたら、必須記述量は、アジャイルだろーとウォーターフォールだろーといっしょ。
ただ、手戻り量が相対的に少なくなることを期待できるアジャイルの方が、無駄になるコード量が減るって期待。

ウォーターフォールでは仕組みまで書いちゃってるから、修正すると+50くらいになるだろうところを、アジャイルだとラフ書きだから+20くらいに抑えられるんじゃね？くらいのもんよ。

実際どーなるかなんて誰にも分からん。
しかも要件定義がおかしかったりすると、アジャイルでも手戻りは相当量になる。
小さいものだって積もってけば大きいんだよ。

ユーザーの登場頻度が高くなる

必ずユーザー確認が必要。
確認間違えればおかしなつくりになるってのは自明。

定期的にユーザー確認が必要だから、必然として、ユーザーの登場回数が増える。
ウォーターフォールの場合でも、フェーズごとにユーザー確認は必要だし、確認項目はそんなに変わらない。必要リソースは変わらないんだろう。
ただ頻度が上がると、その分の準備やら調整やらは必要だろうね。
アジャイルのいいところは定期的なスケジュールとして決められるところなんだけど、これを苦痛と思う人には大変かもね。

魔法の開発手法ではない

なんでもできる。
だれでも簡単。
みんなハッピーな開発手法！アジャイル！！
・・・じゃないからね！

家をつくるって例えで考える。

ウォーターフォール開発は、完全な設計図を書いたら確認。ここである程度のかたちは分かるだろう。
そして家ができたら確認。
途中でも確認するか？
基礎打ったら確認。骨組みできたら確認。壁できたら確認。
けどここでは、設計図どおりかを確認するでしょ。

アジャイル開発は、ラフな設計図を書いて仮組状態で確認。家の完成形は想像するしかない。
基礎は固めときたいけど。
家のかたちなんてグズグズで分からないかもしれないけど、まずは見えるところを確認。
窓の数を決めて、だいたいの配置ができたらラフ設計図と仮組の家を確認。
部屋の数を決めて、だいたいの配置ができたら、ラフ設計図と仮組の家を確認。
みないに進む。

想像力とか方向性のコントロールとか、大事そうでしょ？
場合によっては移動させられない柱みたいな話が出てきたりするんだから。
避けるのか、位置変えるのか、使わないのかとか、全体を考えながら決めてくわけ。

「アジャイル」とゆー考え方があるんだよ。
ウォーターフォールと対で語られることが多いんだけど、これも疑問。
あんまり突っ込まないけどさ。手法ってより思想。
共通認識は大事よ。