【12/19】アジャイル開発超概要
はじめに
皆さんはじめまして、細井です。
この記事に興味を持っていただきありがとうございます。
前年に引き続き、未熟ながらも筆を取らせていただける事となりましたので、
今年の記事は自分の学び直した内容をアウトプットしようと思います。
内容はズバリ、「アジャイル開発の超概要」的なものです。
ここ数年はアジャイルから離れていたので色々と違いもあるでしょうし、間違っているかもしれませんが、ドラ◯もんのように生暖かい目で読んでいただけますと幸いです。（ツッコミ大歓迎です）
それでは、早速見ていきましょう。
アジャイル開発とは？
ざっくり概要
従来のウォーターフォール開発では、シーケンシャルに要件定義、設計...と進んでいき、基本的に今のフェーズが完了するまで次のフェーズに進むことはありません。
なので、手戻り等が発生すると、そういった要素でプロジェクトが炎上してしまう事もあります。後には引けなくなってしまいがちですね。
そして皆さんも聞き馴染みがある...あるいは実践済みかもしれませんが、
本記事で取り上げるアジャイル開発とはプロジェクトの変化や要件変更・追加等に迅速に対応し、顧客満足を最優先とするソフトウェア開発手法です。
そのため、市場の動向・顧客フィードバック・プロジェクトの針路変更などに、その都度すぐに対応できる点が強みだったりします。
とはいえ必ずしもアジャイル開発が良いという訳ではなく、そこは一長一短です。
例えば予測可能性の観点で言えばウォーターフォール型は事前に全てのフェーズを計画するため、予算やリソースの管理が容易ですし、ドキュメント化やアウトソーシングが比較的簡単です。
反対にアジャイル型は短いスパンの開発と変更が頻繁に発生するため、プロジェクトが長期化すればするほど予算・時間ともに予測が困難になる事があります。
また、アジャイルを効果的に実践する場合、経験豊富なチームとより強いコミットメントが必要になります。
そういった強みと弱みがあるので、プロジェクト要件やチーム状況に応じて最適な開発モデルを選択する必要があるっちゅうワケやなという訳ですね。私は東海オンエアが好きなのでついつい口癖が出てしまいます。
ざっくり歴史
1990年頃から「スクラム（Scrum）」や「XP（eXtreme Programing）」といった顧客と開発者が緊密な連携をとりながらソフトウェアを開発する開発手法が登場し始め、その手法の発明者らが2001年初頭のアメリカ・ユタ州で会議を開き、「アジャイルマニフェスト」を宣言した事で広く知られるようになったと言われています。
なんかマンガみたいでめちゃくちゃカッコいいシーンですね。
ざっくり原則
アジャイル開発には以下の12原則が存在します。
私たちは以下の原則に従う:
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
ざっくりフレームワーク
アジャイル開発には様々なフレームワークがありますが、特に代表的なものとして「スクラム」と「カンバン」が挙げられるかと思います。
スクラムでは「スプリント」と呼ばれる一定の固定長の期間を設け、定期的なレビューと調整を行います。
一方、カンバンでは進行中の作業可視化等に重点を置いており、継続的なフローで作業の流れをスムーズにします。
その他にもフレームワークは存在しますが、プロジェクトの要件やチームの特性に応じて最適な手法が選ばれ、二者択一ではなくお互いの相互補完的な関係として組み合わせる事もあります。（例：スクラム+カンバン）
ざっくり実践
さて、ここからが本題、というよりも具体的に何をするのか？というお話です。
アジャイルにおけるステークホルダーは主に以下の例が挙げられます。
エンドユーザー
プロダクトオーナー
スクラムマスター（スクラムフレームワークの場合）
開発チーム
その他のビジネス関係者
上記を例に考えてみましょう。
プロダクトオーナーがビジョンと目標を開発チームに共有し、その他のステークホルダーからインプットを受けて一番最初のプロダクトバックログを作成します。
（ざっくりプロジェクト全体のタスクのようなものと考えて頂ければスムーズに理解できるかと思います）
次に、プロダクトバックログから次のスプリントで取り組むタスクを決定します。
タスクはユーザーストーリーと呼ばれる具体的な機能や要件を表現したものに分割され、それぞれの要素をもとにスプリントバックログと呼ばれるタスクを決定し、通常1〜4週間の期間を定めて要件定義〜テストまで実施します。
基本的にはここでユーザーストーリーの実現に必要な労力や具体的な工数を時間単位やストーリーポイントと呼ばれるもので見積もりますが、今回は割愛します。
そうしてスプリント計画が出来たら、後は日常的な情報共有やカンバンによる作業進捗の可視化を行いつつ実際にスプリントを回していきます。
これは「ざっくりフレームワーク」の章に掲載した図をイメージするとわかりやすいですね。
スプリントの終わりには開発した機能をステークホルダーに向けて実際にデモしたり、フィードバックを受けて必要に応じてプロダクトバックログを更新します。
ここで大事なのはプロダクトバックログは決して「不変」などではなく「常にプロジェクトの現状やステークホルダーの要求に応じて継続的にメンテナンスされるべき」であるという点です。まさにアジャイルの真骨頂とも言える「柔軟性と適応能力」が発揮されるポイントですね。
以降は上記の繰り返しです。
スプリント毎にレトロスペクティブと呼ばれる反省会的なものをして次回のスプリントに活かしたり、ユーザーからの要求に応じてプロダクトバックログを更新したり...なんだか忙しないイメージですが、こういった継続的なコミュニケーションを通じて顧客の真のニーズを満たすことを目指していくという訳です。
総括
技術の進化により、会社への出社オンリーのような働き方でなく、リモートやハイブリッドでの勤務も現実的に可能な世界となりました。
それはつまり如何なる状況（限度アリ）でも人と人とが柔軟にコミュニケーションを取る方法が確立されたという事実に他なりません。
例えば、リモートワークは、個々の作業者が自己管理のスキルを発揮する場でもあります。
アジャイル開発では自己組織化されたチームが推奨されるため、このような環境はチームメンバーが自らの責任を持ってタスクに取り組むことを促進します。
さらに言えば、リモート環境におけるアジャイルの実践は、国内外のメンバーによる文化的な多様性の促進にも寄与します。
異なる国に属するチームメンバーが同じプロジェクトに参加することで、多様な視点がプロジェクトに反映され、革新的なアイディアが生まれやすくなり、柔軟にプロダクトへ組み込む事が出来ます。
これは、昨今のグローバル優位な市場における競争力の向上に直結しますね。
総じて、アジャイル開発とリモートワークの組み合わせは、組織が現代のビジネス環境の要求に効果的に対応するための強力なツールとして機能します。
これにより、組織は柔軟性を持って迅速に対応し、継続的に顧客価値を提供することが可能となるのです。
余談
2019年頃、ガートナー・ジャパン株式会社が日本国内におけるアプリケーション開発 (AD) に関する調査結果を発表していました。
以下の図をご覧ください。
図1. 各開発手法に関する現在および今後の方針
ざっくり言うと、日本国内におけるアプリケーション開発ではウォーターフォール型を採用している企業が約43%を占めるというものです。
反対に、海外市場では近年アジャイル型を採用している企業が90%近くにも登るという文献があったりします。これは驚異的な数字ですね。
個人的にはここ数年で国内でも徐々にアジャイル型にシフトしている所も多いかな～、という印象でしたが、実際はレガシーシステムを扱うプロジェクトだったり、人員的なリソースやコストの問題で全面的なアジャイル移行が現実的でない場合も多いのかもしれません。
ただ、そういった所はケースバイケースで部分的にアジャイルを取り入れている場合も多いと思います。一つの開発手法に限らず、いいとこ取り出来るようにしていきたいですね。
おわり
この記事ではざっくりと、超概要ですが、アジャイル開発について書かせて頂きました。
皆様のアジャイル開発に対する理解を深め、色々なプロジェクト管理手法への興味を引き出す一助となれば幸いです。
最近では様々な企業のプロフェッショナルたちがアジャイル開発についての文献を公開していたりするので、興味がある方は是非調べてみてくださいね。
拙い文章ではありましたが、ここまでお読み頂きありがとうございました。また来年！
Marvelでは今年も『Marvelアドベントカレンダー2024』をやります🎄🎅Marvelのエンジニアがクリスマスまで記事のバトンを繋ぎます🦌🛷
是非毎日のお楽しみとしてご覧ください🎁
★Marvelのアドベントカレンダーはこちら
https://note.com/marvel_engineer/m/ma7e8d8ae4288
Marvelが少しでも気になった方は是非Wantedlyもご覧ください🙌
