入社して間もないの若手エンジニアは「アジャイル」という言葉をなんとなくは知っていても、
「アジャイル開発」と「スクラム開発」の違いや関係性を理解できていない人も多いと思います。
開発者先輩たちや取引先との会話で 「アジャイル」や「スクラム」って言葉が出てくるけど、いまいち違いがわからないんだよね……
とも坊アジャイル = スクラム と勘違いしている人も多いよね！
・「アジャイル開発」と「スクラム開発」の違いや関係性を理解できる
・「アジャイル開発」と「スクラム開発」の概要がわかる
・スクラム以外のアジャイル開発の手法（フレームワーク）を知れる
「アジャイル開発」と「スクラム開発」の違いは？
みなさんの職場では「ウォーターフォール開発」や「アジャイル開発」という言葉をよく耳にすると思います。
どちらも「プロジェクトにおける開発手法」のことを指しています。
そして、アジャイル開発は、何か1つの手法のことを指すわけではなく、“アジャイル”という概念に沿った開発手法全般のことを指します。
以下のようなイメージとなります。
つまり、スクラム開発はアジャイル開発の手法の1つです。
だから、スクラム開発のことをアジャイル開発って呼ぶ人がいるだね
ウォーターフォール開発とアジャイル開発の違いは、以下の記事で解説しています。
アジャイル開発（Agile）とは？
アジャイル開発とは、価値のあるソフトウェアを素早く継続的に提供するための開発手法の総称です。
ちなみに、アジャイル（Agile）には「俊敏な」「素早い」と言った意味があります。
2001年にKent Beck(ケント・ベック)ら、17人によって生み出され、アジャイル開発の概念は「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」にまとめられています。
アジャイルソフトウェア開発宣言では、左記に価値があることを認めながらも、右記のことにより価値をおいています。
また、アジャイル宣言の背後にある原則では、以下のように12の原則としてまとめられています。
このように、アジャイルソフトウェア開発宣言の「4つの価値」とアジャイル宣言の背後にある原則「12の原則」に準拠した開発手法を総称して「アジャイル開発」と呼んでいます。
スクラム開発（Scrum）とは？
スクラム開発とは、アジャイル開発手法の1つであり、ユーザーに価値のあるプロダクトを素早く生み出すための軽量なフレームワークです。
1990年初頭にKen Schwaber(ケン シュエイバー)とJeff Sutherland(ジェフ サザーランド)により生み出されました。
また、スクラム開発におけるチームメンバーの役割、イベント、作成物などのルールは「スクラムガイド」で定義されています。
参考画像：スクラムガイド2017,2020
スクラムは以下2つの考え方に基づいて作成されています。
・経験主義
理論よりも経験を重視し、その経験を基に物事を判断する。
・リーン思考
ムダを省き、本質に集中する。
当初計画に固執することなく、日々の状況変化に柔軟に対応し、ユーザーにとって本当に価値のあるプロダクトを提供するための開発手法です。
「スクラム開発」のチームの役割やスクラムイベントの概要は、以下の記事で解説しています。
スクラム以外のアジャイル開発のフレームワーク
Digital.ai社が世界のアジャイル開発者を対象に実施しているアンケート「State of Agile Report 15th」が2021年7月に公開されました。
@15th State of Agile Report (P.13)
調査結果では、アジャイル手法のうちの66%がスクラム開発を実施しており、スクラムと他のフレームワークのハイブリットも合わせると約80%がスクラムを実践しています。
ただし、アジャイル開発を実施する上で、スクラム開発は一つの手法に過ぎません。
以降、アジャイル開発におけるスクラム開発以外のフレームワークを簡単に紹介します。
エクストリーム プログラミング（XP）
エクストリームプログラミング（XP）は、1999年にケント・ベック氏が発表したアジャイル開発の手法です。
継続的な成長という観点を軸にし、5つの価値、4つのプラクティスに従って開発を進めます。
コミュニケーション：開発チーム、顧客とのコミュニケーションを重視。
シンプル：初期設計を極力シンプルにする。基本的な機能のみとし、必要なときに都度追加。
フィードバック：顧客からのフィードバックを得て、必要な機能を採用する。
勇気：はじめに線密な計画を立てないため、途中に大胆な変更が必要になる場合がある。
尊重：他のメンバーを尊重する姿勢は必要不可欠。
- 共通プラクティス
反復：1つのイテレーション（設計・実装・テスト）が約1〜2週間で完了するサイクルを繰り返す。
共通の用語：円滑なコミュニケーションのため、用語集を作成する。
開けた作業区間：開発チームと顧客でコミュニケーションがとりやすく、開発に集中できる環境づくり。
回顧：ふりかえりを実施し、同じミスを繰り返さないようにする。- 開発プラクティス
テスト駆動開発：プログラムの実装よりもテストコードを先に作成する。
ペアプログラミング：２人１組でプログラミングを行う。
リファクタリング：完成したコードをわかりやすく書き換える。
ソースコードの共同所有：作成コードはチーム全員が共有し、作成者にかからず等しく責任をもつ。
継続的インテグレーション：コードが完成するたびに、すぐに既存のコードと結合テストを行う。
YAGNI：「You Aren’t Going to Need It」の略。いま必要なコードのみを記述するという意味。- 管理者プラクティス
責任の受け入れ：最終的な開発の責任が管理者にあることを受け入る。
援護：チームのメンバーの不足部分を補助し、開発の援護する。
四半期ごとの見直し：四半期ごとに状況を見直し、開発の進行を調整する。
ミラー：状況を可視化し、チームの現在地を可視化する。
最適なペースの仕事：チームの負荷が大きすぎないか常に確認する。- 顧客プラクティス
ストーリーの作成：要求機能のコンセプトを短い文章でストーリーを作成する。
リリース計画：リリース計画を立てる。
受け入れテスト：イテレーションごとに受け入れテストを実施する。
短期リリース：2週間〜３ヶ月というできるだけ短い時間間隔でリリースする。
ユーザー機能駆動開発（FDD）
ユーザー機能駆動開発（FDD）とは、ジェフ デ・ルーカが1997年にシンガポールの大手銀行の大規模開発プロジェクトで提案したアジャイル開発手法です。
フィーチャー（feature）とは顧客視点での小さな単位の機能価値をリストアップし、フィーチャーごとに計画→設計→構築の順で実施します。
FDDは、5つの活動とソフトウェア工学に基づく様々なプラクティスを中心に構成されています。
・全体モデルの開発
対象となるドメイン全体のオブジェクトモデルを作成する。
・featureのリストアップ
全体モデルから小さな機能を切り出してフィーチャーリストを作成する。
・featureごとの計画
チームでフィーチャーの順番を決め、実装先のクラスを担当する開発者に割り当てる。
・featureごとの設計
担当するフィーチャーから一度に開発する分を選択し、シーケンス, オブジェクトモデル, クラス/メソッドの概要を書き、設計を実施する。
・featureごとの構築
フィーチャーの実装を担当する開発者は、設計を元にコード作成、単体テスト、コードレビューを実施する。
※feature = 顧客視点の十分に小さな単位の機能や価値のこと
リーン（Lean）
リーンとアジャイルは正確には別物です。
しかしながら、両者はどちらも「不確実性への対応」という観点では一致しているため、アジャイル開発の手法の一つとして紹介されることもあります。
リーン思考
・「ムダ・ムラ・ムリ」を最小化する考え方。
・リーン（Lean）=「筋肉質」や「痩せた」という意味がある。
リーン思考がベースとなっている開発手法を3つ紹介します。
新しいビジネスを短期間で成長させるための開発手法です。
アメリカの起業家エリック・リースによって生み出され、シリコンバレーのベンチャー企業の多くが採用しています。
顧客志向を中心に据えた「構築→計測→学習→再構築」のサイクルを繰り返すことによって、確実に顧客満足度を高めます。
[4つの構成要素]
・仮説
市場規模やニーズを数値化し、その事業の課題や要求の仮説を立て、ビジネスモデルを検討します。
・構築
仮説を立てて実際に検証するためにプロトタイプを製作します。
ここでコストを抑えるためにMVP（必要最低限の機能）にすることが重要です。
・計測
プロダクトを活用して得たデータをとってユーザーへのヒアリングを実施します。
最初に立てた仮説が正しいか確認し、異なる場合は違うアプローチで事業が継続できるか検討します。
・学習＆再構築
計測で得たデータを整えて今後の方針を作成します。
仮説通りの場合はスケールアップの方法を、仮説と異なる場合は方針変換や路線変更を視野に入れて再構築します。
4つの構成要素に沿って進めることで、コストをそれほどかけずに「最低限の製品、最低限のサービス、最低限の機能」を持った試作品を短期間で作り、顧客に提供することができます。
リーン生産方式(※1)の原則と実践をソフトウェア開発に適応した開発手法です。
「7つの原則」「22の思考ツール」に沿って開発を進めます。
[7つの原則]
1. ムダをなくす
2. 学習を増幅する
3. できるだけ遅く決定する
4. できるだけ早く提供する
5. 人を尊重する
6. 品質を作り込む
7. 全体を最適化する
ソフトウェア開発における「カンバン」は、大きく2つに分けられます。
・方法論としての「カンバン（Kanban）」
ソフトウェア開発におけるかんばんシステムのこと。
インクリメンタルなアプローチであり、組織に合わせてプロセスを進化する方法。
・ツールとしての「カンバン（kanban）」
視覚化したプロセス管理システムのこと。
これにより、何を開発するか、いつ開発するか、どれぐらいのコストで開発するかを発信する。
方法論としてのかんばんは、英語圏において「Kanban」と大文字から始まる言葉で説明されています。
（ツールとしてのカンバンは小文字）
[3つの原則]
・見える化
作業項目を付箋で洗い出し、ワークフローが記載されたボードに貼ることで、作業の状態が見える化できます。
・WIPの制限
同時に進める仕事の数に制限を設けることで、1つの作業をより早く終わらせることができます。
・流れの管理
作業のワークフローを理解し、ワークフローの邪魔がされないように流れを管理します。
どんなワークフローにもボトルネックがあり、それをカイゼンすることでより良いワークフローになります。
（※1）リーン生産方式
1991年にジェームス・P・ウォマック（James P.Womack）、ダニエル・T・ジョーズ（Daniel T．Jones）らが、
トヨタ自動車のトヨタ生産方式（※3）をベースに研究し、「ムダの無い生産方式」として生み出したもの。
（※2）ジャスト・イン・タイム
必要なものを、必要なときに、必要なだけ作ること。
1980年代にトヨタ自動車のトヨタ生産方式（※3）におけるジャストインタイム生産の考え方が発祥。
（※3）トヨタ生産方式（TPS）
1980年代にトヨタ自動車が生み出した、工場における生産の運用方式の一つ。
“7つのムダ”、”ジャストインタイム”、”自動化”を柱としている。
コメント