フロントエンド うえむーのブログサイト | NU-Blog(エヌ・ユーブログ)

こんにちは、うえむーです。
前回に続き「ウォーターフォール」「アジャイル」の違いと個人の見解についてお話したいと思います。

前回投稿したものはこちらになります。
・アジャイル開発とウォーターフォール開発に関しての個人の見解 その1
https://nu-blogsite.net/blog/business/detail/?date_id=X0dL9GAc3

今回は「アジャイル」についてお話したいと思います。

アジャイルについて


アジャイルというのは訳すと「素早い」「敏速な」「頭の回転が早い」という意味になります。アジャイル開発は、システムやソフトウェア開発におけるプロジェクト開発手法のひとつであり、ウォーターフォールと対象的で小単位で実装とテストを繰り返して開発を進めていく事です。開発手法に比べて期間が短縮されるため、アジャイルと呼ばれています。


※この画像はbacklogブログで一部流用してます。

アジャイルのメリット・デメリット


アジャイルのメリット・デメリットをまとめると下記になります。

メリット
・1〜4週間単位の時間枠で、プロジェクトの方向に修正を加えることができる。
・最速で試作品を立ち上げることができる。
・コミュニケーションをとり、そのフィードバックを開発に生かすことができる。

デメリット
・定期的な修正、または技術の変更が多いので、納期が遅れやすくなったり、最悪の場合プロジェクトを完成できないリスクもある。

アジャイルの開発手法


アジャイルの開発手法は3種類あります。

・スクラム
スクラム開発は最も有名なアジャイル開発の手法で、チームで効率的に開発を進めることです。
イテレーション毎に開発の進捗状況や制作物の動作を検査するため、チーム内のコミュニケーションが非常に重要になっていきます。人間関係が悪化するとその手法は成立しないので注意が必要です。

・エクストリーム・プログラミング(XP)
エクストリーム・プログラミング(Extreme Programming)はXPとも略され、事前に立てた計画よりも途中変更などの柔軟性を重視する手法です。
開発チームでは「コミュニケーション」「シンプル」「フィードバック」「勇気」の4つの価値を共有することを推進しており、中でも「勇気」は、開発途中の仕様変更や設計の変更に立ち向かう勇気を指しています。
 
・ユーザー機能駆動開発(FDD)
ユーザー機能駆動開発(Feature Driven Development)は、実際に動作するソフトウェアを適切な間隔で繰り返す手法で、顧客にとっての機能価値という観点で開発が進められているのが特徴です。

自分は対象外ですが弊社でアジャイル開発で大きなプロジェクトで進行しており、有名な「スクラム開発」についてまとめました。
アジャイル開発の図は下記のようになります。



それでは、プロダクトバックログ・デイリースクラムなどの用語を一つずつ解説していきましょう。

スクラム開発の用語一覧


・プロダクトバックログ
プロダクト・バックログは、機能や技術的改善要素を優先順位を付けて記述したものです。ステークホルダ全員が参照し、現在のプロダクトの状況を把握できるようにします。
「ユーザーストーリー」形式がよく用いられますが、形式が重要なのではなく、関係者がいつでも内容を思い出せるようにすることが目的です。

・誰のために
・何のために
・それを実現するのか

について合意し、いつでも思い起こせるようにしておくということです。そうすれば、仕様変更が起きた時、「なぜ変更が必要なのか」が理解しやすくなり、プロダクトの全体の進捗への影響の把握・伝達がスムーズになります。緊急な変更の時「そもそもこの機能は……」という議論や説得に時間をかけてしまえば、プロジェクトの死に直結しかねません。危機に陥る前に、定期的に自分たちの状況を共有しておき、透明性、信頼性を醸成しておきたいものです。手の内を隠してポーカーフェイスで交渉するより、手の内をさらして実力をありのままに把握してもらうのです。

・プロダクトオーナー
スクラムではチームが主体的に作業を行っていきますが、合議制の意思決定は時に非効率です。そこで、プロダクトオーナーを決めます。
プロダクトオーナーは、プロダクト・バックログの作成と優先順位付けの最終責任を持ち、どちらともいえない問題にも、責任をもって白黒をつけていきます。世の中には、やってみなければ分からないことがたくさんありますので、100の議論より、とにかく勘でいいので順番を決め、やってみた結果を見てから判断する方が良いことも多いのです。

・スプリント計画MTG
Sprint Planning はスクラムフレームワークで定められたセレモニーの一つで、簡単にまとめると、以下のようなものです。
・参加者はスクラムチーム全体(開発チーム、スクラムマスター、プロダクトオーナー)
・優先順位付けされたプロダクトバックログから、今スプリントで開発する PBIを選び出す
・チームはタスクレベルでの計画を行い、最終的にスクラムチーム全体として計画へのコミットメントを行う

・スプリントバックログ
スプリント・バックログは、プロダクト・バックログからスプリント期間(1~4週間)分を抜き出した「チームのタスクリスト」です。
チームは、予測どおりにきちんとタスクを終わらせられるかを検討します。チームメンバーの多種多様なスキルを総動員して、自信を持って「終わる」と宣言できるかどうかが、確認すべきポイントです。
スプリント期間中は、スプリント・バックログにある作業や機能を完了させるべく、チームとしてベストを尽くします。「私の仕事」ではなく、「チームの仕事」です。チームとして責任を持ち、全力で仕上げていきます。

・スクラムマスター
スクラムマスターは、メンターです。チームを健全に保つ役割といってもいいでしょう。
スクラムマスターの仕事は、チームの仕事がうまくいっていっているか、困っていることは何かを確認することです。時にチームから問題を分離し、自ら解決に動くことで、チームの集中を保ちます。プロダクト・オーナーがうまく動けていない場合も、アドバイスを行って修正を試みます。

・デイリースクラムMTG
1日1回、15分間のミーティングを行います。メンバー同士がタスク進捗や予定、問題点などを共有しあうのが目的になります。

まとめ


・アジャイル開発はスピーディと柔軟性があり、コミュニケーション能力が上がようになります。
・ウォーターフォール開発は容易に見積もり作成・人材育成できます。
・ハードウェア開発するものはウォーターフォールが適正で、ECパッケージを開発するものはアジャイル開発が適しているのではないかと思います。

アジャイル開発手法で大きなプロジェクトで進行しているチームを見ると結構大変だなという印象があります。
でも、コミュニケーション能力が上がるし一度はその手法を挑戦するのもいいかもしれません。