###経緯
約1年前まで、大手SIerでガチガチのウォーターフォール開発をしていた筆者が会社を辞め、食わず嫌いしていたアジャイル開発を1年経験し、アジャイル開発への意識が劇的に変化したので、そんな1年を振り返る。
ウォーターフォール開発とアジャイル開発は対立構造にあるものとは思ってないけれど、比較することで見えてくるものもあるので、こんな思考からあんな思考に変わったよ！というのを書いていく
###スクラムとは？
アジャイルのうちスクラム開発というのは、スクラムガイドで定義されている。スクラムガイドは20ページほどしかない。抽象的な表現が多く、スクラムの捉え方はチームによって異なることを推奨しているかのようにも見える。
スクラムガイド
わたしのチームではこんな考えをしているよ！というものを紹介したいと思う。
###アジャイル的考え方(スクラムVer)
-
要件定義工程で要件をかっちり決め、それ以降の工程では簡単に仕様変更をのまない！！！
これはウォーターフォール開発をしているベンダーでは、あるある。お客さんの仕様変更を受け入れてあげたいところだけれども、後ろの工程にいけばいくほど、手戻りは増え、その仕様変更に対する影響調査も増える。また、障害を埋め込むリスクも上昇する。
お客さんにとってもベンダーにとってもなんというマイナス。
→スクラムでは、1つ1つのバックログで仕様を決める。つまり、スクラムのアウトプットの完了条件を定める。わたしのチームでは、アクティブなスクラムにバックログを入れる前に仕様をPOと協議する時間を設けている。（1週間のスプリントで1時間程度）実際のスクラムに入ったあとは、仕様の変更はほとんどしないが、仕様の詳細化は行うため、POとコミュニケーションをとる。仕様の変更が行われるタイミングはスプリントレビュー。スプリントレビューのタイミングでアウトプットを見て仕様変更ができるので、開発者にとっては、次のスプリントのスケジュールに組み込めばよく、ステークホルダーにとっても、アウトプットを見て仕様を決めることができる。これはアジャイル開発の1番の強み:
-
レビューする側とレビューされる側という体制が生む主体性のなさ！！！
SIerでよくある下請け・孫請け構造は、責任範囲を明確にしているため、自分の役割やタスクの範囲はここまで！責任をとりたくない！気持ち・人を生み出しやすい。わたしのチームでは、誰もがどのタスクもとれるように工夫している。例えばとれないと思うタスクがあればペアプロやモブプロ（プログラミング以外も）で実施し知識の共有化を行う。その結果、1年後には全員がすべてのタスクがとれるようになった（これは本当に劇的な進化！）誰もがどのタスクもとれるになると、レビューする立場、される立場という上下の関係性ではなく、フラットなメンバーシップになり、相互にレビューできるようになり、品質もあがる！ -
大規模プロジェクトの見積もりは、どんなに審議を通しても正確になるはずがない！！
大規模プロジェクトの受注は、Sier にとっては売上確保に欠かせないもの。要件定義から基本設計までを準委任契約、その後の工程を請負契約で行うパターンが多いかと。基本設計までは決まっているので、内部設計から開発は見積もれるという前提で請け負っている。本当にそうでしょうか？影響調査や技術調査し、タスクを洗い出して詳細に見積もり、過去の大規模プロジェクトと比較したとしても、開発してみたら、想定以上の工数がかかったぁああ！ということがわたしはよくありました...まだやってないことを正確に見積もるのは、大きい単位ほどずれが発生するのは当たり前。スクラムではそのチームのアウトプットをストーリーポイントで見積もる。スクラムが1週間であれば1週間のアウトプットがどのくらいのタスクなのかを毎回見積る。毎回小さい単位で見積もることで、どんどん見積りの精度が上がるサイクルができあがるのだ。スクラムガイドに経験主義に基づくと記載があるのも頷ける。
###最後に
スクラムの難しいところもたくさんあるのだが、新年なので？(笑)今回はいいところだけを紹介して、終了したいと思う難しい点はまたの機会に！