こんにちは、開発2部のTashです。
本記事では、ウォーターフォール型開発を経験してきた立場から、
アジャイル開発の現場に入って最初に感じた戸惑いや気づきをまとめています。
アジャイル開発に参加してみて
アジャイル開発に、半年ほど携わりました。
これまでウォーターフォール型の開発に関わることが多かった私にとって、アジャイルは、知識としては聞いたことがあるものの、実務としては未知の領域でした。
私はプロダクトオーナーアシスタントとしてプロジェクトに参加し、主に要件定義を担当しています。
体制としては、プロダクトオーナー1名、エリアプロダクトオーナーアシスタント1名、プロダクトオーナーアシスタントが私を含めて当初2名でスタートし、途中で体制の変更を経て、最終的には5名体制となりました。
最初は少人数でのスタートだったため、役割分担も手探りな部分がありました。
私が担当していた開発チームは、スクラムマスター1名、開発メンバー5名という構成です。
最初に感じた違和感と不安
アジャイル開発に参加して、まず感じたのは
「決まっていないことが多いまま進んでいく」という点でした。
ウォーターフォール型の開発では、要件をある程度固めてから次の工程に進むことが一般的です。
一方で、アジャイルでは「今わかっている範囲で決め、動かしながら調整していく」ことが前提になります。
頭では分かっていても、最初はなかなか慣れませんでした。
そのため、
- 要件の粒度が人によってばらついている
- 仕様が完全に固まっていない状態で開発が進む
- 会議（イベント）が想像以上に多い
といった点に、当初は強い不安を感じました。
たとえば、「次のスプリントまでにどこまで決めておくべきか」という認識が人によって微妙に異なり、そのズレに戸惑うことがありました。
特に要件定義を担当する立場としては、
「この状態で進めて、本当に問題はないのだろうか」
という気持ちが、なかなか拭えなかったのを覚えています。
「イベント」の意味が分からなかった頃
アジャイル開発では、デイリースクラム、プロダクトバックログリファインメント、スプリントプランニング、スプリントレビュー、レトロスペクティブといったイベントが定期的に行われます。
参加し始めた頃は、
「なぜこれほど頻繁に集まるのか」
「この場では、何を求められているのか」
がよく分からず、正直なところ、参加しているだけで精一杯でした。
特にデイリースクラムでは、単なる進捗報告の場になってしまい、
「この時間は、何のためにあるのだろうか」
と疑問に感じることもありました。
少しずつ分かってきたアジャイルの考え方
数スプリントを経験する中で、少しずつ考え方が変わっていきました。
アジャイルでは、最初から完璧な答えを出すことよりも、
早めに違和感に気づき、修正できる状態を保つことが重視されます。
イベントも「報告の場」ではなく、
認識を揃え、問題を早期に発見するための場なのだと少しずつ腑に落ちてきた、という感覚に近いかもしれません。
要件定義を担うプロダクトオーナーアシスタントの立場としては、
「決め切ること」よりも、「修正しやすい形で伝えること」のほうが重要なのだと感じるようになりました。
要件定義についても、
- 「すべてを事前に決め切らなくてはいけない」
- 「曖昧さは極力残さないべきもの」
という考え方から、
- 「今のスプリントで必要な粒度まで決めればよい」
- 「動かしながら調整できる余白を残す」
という考え方へ、少しずつシフトしていきました。
次回に向けて
次回の記事では、アジャイル開発で行われる各イベントについて、
それぞれの目的と、実際の現場ではどのように運用されていたのかを整理して紹介する予定です。
アジャイルに初めて触れる方や、非エンジニアの方にも、
「現場ではこういうことをやっているのか」とイメージしてもらえる内容にしたいと考えています。
