【総まとめ】アジャイル開発とは？スクラムとは？初心者向けに徹底解説

アジャイル開発を1年以上やってみて、ある程度知見が貯まってきたので、これまでの知識をまとめます。

これからアジャイル開発を採用してみようという人に向けて、出来るだけ簡単に幅広く解説が出来るよう記載します。

アジャイル開発とは何か？

アジャイル開発の概要

アジャイル開発では、市場や顧客からのフィードバックを得て、より良いソフトウェアに改善をしていきます。

アジャイル開発は俊敏で、柔軟であるというイメージを頭の中に思い浮かべる人が多いと思います。

もちろん、そのイメージもアジャイル開発を捉える上で正解です。

アジャイルソフトウェア開発宣言

これはアジャイル開発を実施する上で、守っていく価値観をまとめたものになります。

アジャイルソフトウェア開発宣言とは、具体的には以下のようなものです。

私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。

引用元：『アジャイルソフトウェア開発宣言』

アジャイルソフトウェア開発宣言を参考に、実際に現場でアジャイル開発を実践していくのには、なかなか抽象的で解釈が難しい場面もあるかと思います。

アジャイル開発はウォーターフォールモデルと何が違う？

ここまでで、「アジャイル開発とは何か」については、何となく頭の中にイメージを付けることが出来たかと思います。

しかし、こんな疑問が出てきたかも知れません。

ということで、以下からは「アジャイル開発とウォーターフォールモデルとの違い」について、記載していきます。

ウォーターフォールモデルの特徴

ウォーターフォールモデルの開発工程は以下の図のようにV字モデルと言われます。

例えば、外部設計が全て終わってから、次の工程の内部設計に取り掛かります。

基本的に後工程から前工程へと手戻りが発生することを防ぐようプロジェクトを管理する必要があります。

ウォーターフォールモデルは要員の観点ではどうなのか？

こんな疑問を抱く方もいらっしゃるかと思います。

設計者やプログラマー、テスターと言ったような「各工程毎に役割分担をはっきりさせることが出来ること」がウォーターフォールモデルの特徴になると思います。

そのため、要員の確保がアジャイル開発に比べると容易であることが多い印象です。

上記の特徴から、「プロジェクトのピーク時には、一時的に要員を増やして、ピークを超えたら要員を減らしていく」というようなコントロールをすることもしやすいです。

アジャイル開発の特徴

アジャイル開発の特徴は、一定の期間の間(アジャイル開発でスプリントと呼ぶ)で動くソフトウェアを製造して、次のスプリントでは、前スプリントでの気付きを活かしながら、要件レベルから見直すことにあります。

これは、MVP(Most Viable Product)と言った、価値を提供出来る実用的で最小限のプロダクトを開発するという考え方に基づきます。

これは、ウォーターフォールモデルと比べると、無駄が発生する可能性が低くなることにあります。

アジャイル開発の開発工程は以下の図のようになります。

後述しますが、スプリントと呼ばれる開発期間の中で、小さくソフトウェアを開発していきます。

アジャイル開発は要員の観点ではどうなのか？

アジャイル開発では、「短い期間でどんどんと工程が進んで行くため、設計書やプログラマー、テスターと言ったように役割を決めていると上手く進んでいかない」という傾向にあります。

特定の工程だけ出来るという人よりも、何でも出来る要員が望ましいとなります。

というわけで、完全に役割を分けることも出来るウォーターフォールモデルと比べると、アジャイル開発の要員は確保するのが難しい傾向にあります。

まとめ – アジャイル開発とウォーターフォールモデルの違い

まとめると以下のようになります。

ここまで、アジャイル開発とウォーターフォールモデルの違いについて、解説させて頂きました。

アジャイル開発のメリット

仮説検証を行いながら、プロダクトを開発出来る

アジャイル開発のメリットとしては、「仮説検証を行いながら、プロダクトを開発出来る」ことが挙げられます。

そのため、必要のないソフトウェアを無駄に作ってしまうリスクが軽減出来ます。

柔軟に計画を変えやすい

アジャイル開発のもう一つメリットとしては、「柔軟に計画を変えやすい」ことが挙げられます。

このまま進めても、期待する効果がないと思った時は思い切ってプロジェクトを中止することも出来ます。

ウォーターフォールモデルは計画を途中から大きく変えることが難しいので、これはアジャイル開発の大きなメリットとなります。

アジャイル開発のデメリット

スケジュールのコントロールが難しい

アジャイル開発のデメリットとしては、「スケジュールのコントロールが難しい」という点が挙げられると思います。

いつまでに全体的なシステムが開発するのかが分かりにくいです。

開発チームで必要な要員のレベルが高い

開発メンバーとして必要とする要員レベルが高いので、要員調達が難しいです。

スクラム

ここからはアジャイル開発の手法の一つである、スクラムについて、重要なキーワードを解説していきます。

プロダクトバックログ(PBL)

プロダクトバックログとは、プロダクトロードマップと要件・機能に基づいて、開発チームが行う作業に優先順位を設定したリストのことです。

PBLは価値がある単位で切り分けます。

スプリントバックログ(SBL)

スプリントバックログとは、プロダクトバックログを小さな作業(2時間程度で終わる作業)に切り分けたリストのことです。

プロダクトバックログの内容が検索画面を実装するである場合、スプリントバックログは検索SQLを書く、検索画面のレイアウトを製造するとかそういうものになります。

ストーリーポイント

ストーリーポイントとは、プロダクトロードマップを消化するのに、どれくらいかかりそうかというポイントです。

このポイントは相対見積もりで算出します。

相対見積もり

相対見積もりとは、今回の作業内容が過去行った作業内容に比べて、大きいか小さいかを比べて、相対的に見積もる手法のことです。

ベロシティ

ベロシティとは、開発チームが1スプリントの間に消化可能な出来高のことです。

ベロシティを安定化すると、先のスケジュール消化の見通しが立ちやすくなります。

ベロシティが安定していれば安定しているほど、開発チームの成熟度は高いと言えます。

プロダクト・オーナー

プロダクト・オーナーとは、「プロダクトの責任者」のことです。

顧客のニーズを元に、システムの要件や機能を記述したプロダクトバックログ(PBL)を作成し、優先度の管理をする

スクラム・マスター

スクラム・マスターとは、「開発を円滑に進めるサポート役」のことです。

プロダクトオーナーと開発チームの真ん中で橋渡しをする役目を担っています。

またチームを円滑にするサポート役という役割から、会議の司会進行を務めることが多いです。

チームに課題が発生したら、真っ先に課題解決に向かうことが求められています。

開発チーム

開発チームとは、アジャイル開発において、実際の開発を行ってく人たちのことです。

上記でも記載した通り、例えばテスターと言ったようなテスト工程だけに特化した要員というよりは、設計から製造、テストまで幅広い工程を独力で行える要員が望ましいです。

チームの雰囲気

アジャイル開発を採用する場合のチームの雰囲気について、解説します。

アジャイル開発を行っているから、以下のようなチームの雰囲気にすべきだというよりは、ウォーターフォールモデルであっても、以下のようなチームの雰囲気を目指すべきです。

心理的安全性

「心理的安全性」とは、以下のようなものです。

ビジネスに関する心理学用語の一つとされ、ハーバード大学で組織行動学を研究するエイミー・エドモンドソン教授が1999年に概念を提唱した。

エドモンドソン教授によると心理的安全性は「チームにおいて、他のメンバーが自分が発言することを恥じたり、拒絶したり、罰をあたえるようなことをしないという確信をもっている状態であり、チームは対人リスクをとるのに 安全な場所であるとの信念がメンバー 間で共有された状態」と定義されている。

引用元：『「心理的安全性」とは何か？ チームや職場へのメリットを紹介』

ざっくりと平たく言ってしまうと、チームの皆が自分の意見を気持ちよく言える状態のことを指しています。

ただし、「決してぬるま湯につかるような関係を目指すものではない」ことはご注意下さい！

HRT

HRTとは、 謙虚（Humility）、尊敬（Respect）、信頼（Trust）の頭文字を取った造語です。

Team Geekというエンジニアには非常に有名な書籍で紹介されました。

HRTを守れば、人間関係の衝突は防ぐことが出来ると思います。

デイリースクラム

デイリースクラムとは、平たく言うと、朝会のことです。

デイリースクラムの議題としては、昨日やったこと、今日やること、問題点を中心に一人ずつ話していきます。

バーンダウンチャートを作成している場合は、このデイリースクラムの時に更新するとチームの進捗状況が可視化しながらチームの皆で確認が出来るため良いです。

また、デイリースクラムの改善策についての具体的な内容を記載した記事は、以下にまとめていますので、よろしければご確認下さい。

リリースプランニング

リリースプランニングとは、プロジェクトの立ち上げ時に、何をいつリリースするのかをざっくりと決定する会議のことです。

別名として、リファインメントという言い方をする時もあります。

決定した結果は、プロダクトロードマップとしてドキュメントに残します。

スプリント

スプリントとは、予め決めた開発期間のことです。

目安としては短くて1週間、長くても1ヶ月くらいがベストです。

スプリント計画

スプリント計画とは、スプリントの中で行うPBLとSBLについて計画を立てる会議のことです。

スプリントレビュー

スプリントレビューとは、スプリント期間内で完成させた成果物を実際にデモしながら、要件通りになっているか、ミスがないかをレビューする会議のことです。

開発チームがプロダクト・オーナーとともに実施して、プロダクト・オーナーがレビュー結果の承認を行います。

振り返り

振り返りとは、平たく言うと「反省会」のことです。

KPTというフレームワークを用いながら、スプリント期間の振り返りを行うことが多いです。

KPTで話す議題は以下で構成されています。

それぞれの頭文字を取って、KPTと呼んでいます。

KPTをやってもなかなか議題が挙がってこないという場合は、YWTというフレームワークがおすすめです。

YWTで話す議題は以下の通りです。

KPTに比べて、YWTは実際に起ったことを思い出しながら話をすることになるので、話題が挙がりやすいです。

必ずメンバー全員が参加し、メンバー皆が発言するようにスクラム・マスターが意識することが重要です。

ペアプログラミング

ペアプログラミングとは、二人のプログラマーが1台のPCを用いてプログラミングを行う手法のことです。

通称、ペアプロと言います。

ペアプロには役割があります。

それはコントローラーとドライバーです。

コントローラー

ドライバーに向かって、プログラミングのコードを指示する人のことです。

ドライバー

ドライバーはコントローラーに言われた通りに手を動かし、PCにコードを打ち込みます。

ある程度、時間が立ったらコントローラーとドライバーの役割を交代する。

メリット

ペアプログラミングのメリットは、「結果だけではなく、プログラミングをする時の思考の過程を共有出来るという点」です。

思考を共有化出来るという点から、プログラミングの時だけではなく、インシデント発生時の調査方法の引き継ぎ等、属人化解消の手段としても選択肢になり得ると思います。

また、二人で一緒に進めるので、変数名とかアルゴリズムとか設計事項の物事が決まりやすいという点もペアプログラミングのメリットです。

デメリット

ペアプログラミングのデメリットは、「当たり前だが、工数が2倍かかる」という点です。

また、結構頭を使うので、一人でプログラミングをするときよりも疲れる気がします。

モブプログラミング

モブプログラミングとは、ペアプログラミングの発展型であり、2人以上の大人数で行う共同プログラミングのことである。

通称、モブプロと呼ばれる。

場合によってはチーム全員が参加することもある。

メリット

モブプログラミングでは、複数人でコードをチェックしているため、コーディングをしながらレビューが出来る。

デメリット

モブプログラミングのデメリットとしては、当たり前だが、多くの人数が同じプログラムの開発を一緒にするので、工数がめちゃくちゃかかる。

というわけで、何でもかんでもモブプロで行うというよりも、大切なイベントの時だけ、モブプロをするとかある程度ルールを決めてやると良いと思う。

アジャイル開発の注意点

一気にアジャイル開発に移行しないで、チームの成長に合わせて移行する

アジャイル開発はウォーターフォールモデルよりも、優れているというわけではないです。

プロジェクトの特性に合わせて、最適な開発手法を選択することが失敗しないために大切です。

アジャイル開発に向いているプロジェクト

以下のような特徴を持つプロジェクトは、積極的にアジャイル開発を採用することを検討すると良いと思います。

アジャイル開発に向いていないプロジェクト

逆に以下のような特徴を持つプロジェクトは、本当にアジャイル開発を採用すべきなのかもう一度検討をした方が良いと思います。

アジャイル開発は顧客と密なコミュニケーションを取ることが前提となっています。

同じ場所で働けないと俊敏性に欠けるため、アジャイル開発が有効に機能しない可能性があります。

アジャイル開発の体験談

アジャイル開発を導入してみて、1〜3ヶ月間の間の体験談については以下の記事にまとめていますので、よろしければご確認下さい。

アジャイル開発を導入した際の試行錯誤が時系列でまとまっています。

また、アジャイル開発をやってみて感じた失敗パターンについても以下の記事にまとめています。

アジャイル開発を学ぶのにオススメの書籍

アジャイル開発について興味を持ったけど、どんな書籍を読んだらいいのかという場合は以下の記事でまとめていますので、良ければご確認下さい！

最後に

ここまで「アジャイル開発とそれに関連する重要キーワード」について網羅的に解説をしてきました。

今後もアジャイル開発について学んだことがあったら、ここに追記していきたいと思っています！