こんにちは、この前テントサウナに行ってきました、ディレクターの佐々木です！
さて。 アジャイルという言葉が飛び交う昨今、私は、主に継続する保守案件などで、その実践に取り組んでいるつもりでいました。でも今回、真のアジャイル、特にスクラムに焦点を当てたプロジェクトに参加し、まだまだ理解が浅かったなと感じました。その体験を通じて得た学びや、メリット・デメリットについてざっくりとご紹介します。
アジャイルとは
そもそもアジャイルとは、ソフトウェア開発の分野で誕生した手法です。 従来のウォーターフォール型開発で見られた計画重視や柔軟性の無さ、などの課題を解決するために注目されるようになりました。クライアントの要望や変化する現代の開発環境に適した手法として広がっています。 この手法は、アジャイルソフトウェア開発宣言に基づいています。アジャイルソフトウェア開発宣言（※Netscape4.01でも見れそうなサイトですね！）
この宣言を噛み砕いて意訳すると
- プロセスやツールよりも個人と対話を
→ コミュニケーションを密にして相手としっかり向き合おう！ - 包括的なドキュメントよりも動くソフトウェアを
→ ドキュメント作成よりも、実際に動くソフトウェアを重視しよう！ - 契約交渉よりも顧客との協調を
→ 契約も必要だけど、それよりも信頼関係が大事だよね！ - 計画に従うことよりも変化への対応を
→ その時々の変化に応じて柔軟に対応していこう！
要するに、『早く、小さく、試行錯誤しながら進めていく』というアプローチです。アジャイルはプロジェクトやチーム特性に応じて柔軟にアプローチやツールを選んで取り組むことができますが、先人たちが発見した効果的なフレームワークとして、スクラムやエクストリームプログラミングなどの代表的なアプローチがあります。私たちのプロジェクトではスクラムを採用しました。
スクラム
スクラムは、チームで行う作業を小さなサイクル（スプリント）に分割し、定期的に見直しと改善を行うプロセスを含む手法です。 今回のプロジェクトで、私たちはスクラムという手法に取り組みました。
あくまで今回ご紹介するのは、私たちが取り組んだスクラムの実践例です。スクラムは役割やプロセスが明確に定義されたフレームワークですが、プロジェクトの特性に応じて一部の調整が行われることもあります。ただし、スプリントや定期的なフィードバックなどの基本的な原則は守る必要があります。
私たちのプロジェクトでは、2週間のスプリントを使って、プロダクトの開発と進行管理を行いました。
- スクラムチームの登場人物
- PO（プロダクトオーナー）: プロダクトの価値を最大化する責任を持ち、バックログアイテム（後述）を管理します。
- スクラムマスター: スクラムが円滑に進行するようサポートし、チームが自律的に仕事を進められるよう促進します。
- 開発者: プロダクトを実際に作り上げる技術者です。
これらの役割を持つメンバーが、2週間ごとに成果物をリリースし、定期的なフィードバックと改善を繰り返していきます。
- スプリント
私たちのプロジェクトでは、2週間のサイクルで成果物をリリースしました。このサイクルを繰り返すことで、プロダクトの質やチームの生産性が向上していきます。 - バックログアイテム
バックログとは、開発すべきタスクや要件のリストのことです。プロダクトオーナーがこのリストを管理し、優先度を決めて開発者が取り組むタスクを選びます。 - PBI（プロダクトバックログアイテム）
作業単位であるPBI（プロダクトバックログアイテム）は、作業の複雑さを評価するストーリーポイントとして見積もり、プランニングポーカーを使ってチーム全員でその内容を議論しました。 - プランニングポーカー
チームメンバーが各タスクの作業量を見積もる際に使う手法です。メンバー全員が独立して作業の複雑さを評価し、お互いの見積もりを伏せた状態で選び、同時に公開します。これにより、他のメンバーの意見に影響されることなく、偏りのない客観的な見積もりができるようになります。 - ベロシティ
ベロシティは、1スプリントでどれだけのストーリーポイントがこなせたかを測る指標です。私たちのプロジェクトにおいては、この数値から間接的にチームの効率や作業速度を見ることができました。これにより効率が「見える化」され、チームのパフォーマンスを数値で把握できました。 - レトロスペクティブ
スプリント終了後に行う振り返りを行い、プロセス改善やチームのコミュニケーションを向上させるための場です。私たちの場合は、Miroなどのツールを使い、各自が良かった点や改善点、今後取り入れるべきことをみんなで書き出し合い記録し、振り返った結果をスクラムの運用にフィードバックして改善していきました。 - スクラムにおけるミーティング
これには、次回スプリントの計画を立てる計画会議や、PBIの整理と見積もりを行うグルーミング会議、PBIの消化確認をするレビュー会議などが含まれます。これらの会議は、チームの進行を円滑にするために重要ですが、頻度が高いため、時間の確保が課題となることもありました。私自身も、多い時で週4回、長いものは2時間のミーティングがあり、時間管理が求められました。
私が感じたメリットとデメリット
これらは私が経験したプロジェクトの一例であり、すべてのスクラムプロジェクトに当てはまるわけではないことをご理解ください。
メリット
- スクラムを導入することで、チーム全員がプロジェクトに強い当事者意識を持ち、達成感ややりがいを感じられるようになりました。
- 振り返りのプロセスを通じて、チーム全体が少しずつ成長していることを実感しました。さらに、ベロシティの活用により、パフォーマンスの向上が数値として確認できるようになりました。
- クライアントとの関係がフラットになり、建設的な意見交換がスムーズに行えるようになった点も大きなメリットです。
- また、1スプリント内で無理のない範囲でPBIをこなすことができ、過度な負担を避けながら効率的に進めることができました。
デメリット
- ミーティングの頻度が高く、これが時間的な負担となることが多くありました。アジャイル特有のこの特性は、必要な部分でもありますが、私たちは、各自の責任範囲を広げることで、確認や承認が必要な場面を減らし、ミーティングの回数自体を削減することができました。
- 日々の保守作業に追われ、改善に手が回らないことがしばしば発生しました。これを解決するためには、保守と改善を別のスクラムチームで進める方が理想的だという意見もありました。
- ベロシティの安定は、プロジェクトでの成長を示す一方で、各メンバーの努力も不可欠です。しかし、準委任契約の外部委託チームでは、固定された稼働時間の制約があるため、個人で得られた効率向上のノウハウを他のプロジェクトに活かす余地が限られており、今後は他プロジェクトでも活かせる方法を模索できればと思います。
まとめ
スクラムを完全に取り入れることはすごく大変ですが、しかし、それを乗り越えた先には、たくさんの学びと成長があり、プロダクトの品質が効率よく向上していくものだと思いました。 プロジェクトの内容や予算に応じて、柔軟にアジャイル手法を取り入れ、オリジナルのスタイルを適用できることが理想だと思います！
