はじめに
スクラム開発における成功とは何だろう
そもそもPJTとは期限があるが、前例はないものである
前例がないものに対して「ウォーターフォールじゃなくてアジャイルでよかった」と断定できるだろうか
既存のウォーターフォールの進み具合が悪く、アジャイルに開発した場合は効果を実感しやすい
元々アジャイルで開発した場合はいかがだろうか
開発サイド、発注サイドとしてもこの成功体験を積めない限りは、本質的にアジャイル開発はできないと考えている
今回は、スクラム開発の成功について思考し、スクラムマスターとして活かせるノウハウを積もうと思う
スクラムの成功例(開発T)
スクラムはチームの雰囲気を重要視するフレームワークである
少人数で迅速に開発を行うため、一致団結となり前進する
それぞれがタスクの進捗状況を理解し合い、取り残されることがないよう前進する
疑問や困難があればすぐに相談し、障害をできる限り取り除いた状態で開発できる環境
そのために各々仕様を理解するために事業側に相談を出し、
相談を受けたらすぐに親身になって解決できる環境が理想である
タスクを細分化し、各々担当するため、成果物ができるたびに達成感を覚えることができる
スクラムの成功例(事業T)
目的→目標まで定まっているが、過程が決まっていない要望
目標達成できれば良いが、UI/UX周り等、言語化しにくい部分の要望は出しきれない
そのような状態だが要望を出し、擦り合わせながら作れるシステムが理想
顧客に直接関わり、ROIを強く求めるようなシステムの場合、変化しやすいスクラムには向かない
先にROIを出す場合、ROIありきの改修となる
その場合は、柔軟に変更をするスクラムは向いておらず、ROIすらも変えたくなる
後にROIを出す場合、システムありきのROIになる
それはあくまで結果論であり、ROIを達成できても事業へのインパクトは大きくない
あくまで社内の改善のため、スクラムは向いているシステムである