息子と肉じゃがとカレー
息子がぼそっと言った。「肉じゃが、食べたい。」
私はその一言で、重い腰を上げることにした。冷蔵庫を開ける。肉、じゃがいも、たまねぎ、にんじんと必要な具材を確認する。そして、具材を大ぶりに切り、大きめの鍋に投げ入れて炒め始めた。美味そうな匂いが家中にじわりと広がっていく。
息子が鼻をひくひくさせながら言った。「いい匂いだね。今日はカレーかな？カレーはまだ？」
私は眉をひそめる。いやいや、今作ってるのは肉じゃがだぞ。最初に君が肉じゃががいいって言ったんだぞ。
息子はしばし考えた後、顔を輝かせて言った。「でも、やっぱりカレーが食べたいなぁ…！」
そんなにカレーがよかったのか。しばし考えを巡らせる。
あれ？ここにカレールーを入れたらカレーになるんじゃないか？それなら、カレーにしちゃうか！
息子は飛び上がって叫ぶ。「カレーだ！カレー大好き！パパ大好き！」
こうして、息子の突然のリクエスト変更にも対応し、結果としてみんなが満足するカレーが完成しました。
こんにちは、ヌーラボでCTOをしている馬場です。
最近、社内で「アジャイルソフトウェア開発って何？」ということを話すことがありました。これを機に、あらためてアジャイル開発について整理してみましたので、#ヌーラボ真夏のブログリレー2024 Techの記事としてお届けします。
アジャイルソフトウェア開発の本質
アジャイル開発とは、プロジェクトの途中で顧客やチームメンバーの要件が変わっても、それに柔軟に対応することです。以下のポイントが肉じゃがをカレーにしたストーリーに当てはまります
顧客との継続的な対話
息子との対話を通じて、初期の要件（肉じゃが）が変更されましたが、最終的に満足する結果（カレー）に至りました。迅速な価値提供
肉じゃがを作り始める段階で、既に家の中には良い匂いが漂い、息子の期待が高まりました。カレーへの変更も迅速に行われました。変化への対応
プロジェクトの途中であっても、顧客（息子）の要求が変わった場合に柔軟に対応しました。これがアジャイル開発の要です。自己組織化チーム
料理を作るプロセスで、自分自身がリーダーシップを発揮し、プロジェクト（料理）の成功に向けて自主的に行動しました。持続可能なペース
息子の期待に応えるために、持続可能なペースで料理を続けました。無理をせず、楽しみながらプロジェクトを進めることができました。
このように、アジャイル開発は、変化する要求に対して柔軟に対応し、迅速かつ継続的に価値を提供するのです。
ソフトウェア開発の歴史は、数十年にわたる進化の過程で様々な手法やアプローチを生み出してきました。ここでは、従来のウォーターフォールモデルの起源とその特徴、そしてアジャイルソフトウェア開発の誕生について解説します。
ウォーターフォールモデルの起源と歴史
ウォーターフォールモデルの概念は、1960年代に大規模なシステム開発プロジェクトでプロジェクト管理と品質保証のための手法として発展しました。1966年、ロイ・ワインシュタインによる論文「Managing the Development of Large Software Systems」で最初に文書化されました。その後、1970年にウィンストン・ロイスが発表した論文「Managing the Development of Large Software Systems」でさらに広まりました。この論文では、ソフトウェア開発プロセスを一連の順序立てられたステージに分けることが提案されました。
特徴とプロセス
ウォーターフォールモデルは、次のステージに進む前に前のステージを完全に完了させることが要求される線形プロセスで、以下のステージで構成されています。
要求分析（Requirements Analysis）
設計（Design）
実装（Implementation）
統合（Integration）
テスト（Testing）
導入（Deployment）
保守（Maintenance）
長所と短所
長所
明確なステージ: 各ステージが明確に定義されているため、管理が容易。
文書の充実: 各ステージで詳細な文書化が行われるため、後の参照が容易。
短所
柔軟性の欠如: 要求や設計の変更が困難で、変化に対応しにくい。
後工程での問題発見: テストは後半に行われるため、問題の発見が遅れる。
アジャイルソフトウェア開発の誕生
ウォーターフォールモデルの限界を克服するために、アジャイルソフトウェア開発が生まれました。アジャイル開発は柔軟性、迅速な対応、および顧客の満足度を重視するアプローチです。
市場の変化と要求の変動
従来のウォーターフォールモデルは、要件定義から設計、実装、テスト、リリースまでの各段階が厳密に順序立てられているため、プロジェクトの初期にすべての要件を確定する必要があります。しかし、実際のプロジェクトでは市場の変化や顧客の要求がプロジェクトの途中で変わることが多く、ウォーターフォールモデルでは柔軟に対応することが難しいという課題がありました。高いリスクと遅延
ウォーターフォールモデルでは、プロジェクトの最終段階までソフトウェアの動作する部分を見ることができないため、開発途中での問題発見が遅れ、リスクが高くなります。結果として、大規模な遅延や失敗につながることが少なくありませんでした。顧客満足度の低下
従来の手法では、顧客が初期に提示した要件が実際のニーズとズレていることが多く、完成品が顧客の期待に応えられないケースが頻発しました。アジャイルは顧客との継続的な対話とフィードバックを重視することで、これを解決しようとしました。チームの士気と生産性の向上
ウォーターフォールモデルでは、役割分担が厳格であり、開発者が自律的に動けないことが多く、チームの士気や生産性に悪影響を及ぼしていました。アジャイルは自己組織化チームを強調し、チームメンバーの自主性や協力を促進することで、生産性と士気を向上させようとしました。迅速な価値提供
従来の手法では、プロジェクトの終盤まで顧客に価値を提供することができませんでした。アジャイルでは、短期間のイテレーションを通じて、継続的に動作するソフトウェアをリリースし、早期かつ頻繁に価値を提供することができます。
アジャイルソフトウェア開発宣言 (Manifesto for Agile Software Development)
2001年に、17人のソフトウェア開発者がユタ州スノーバードで集まり、従来の開発手法の問題点を解決するための新しいアプローチを議論し、「アジャイルソフトウェア開発宣言」を作成しました。この宣言は、「4つの価値」と「12の原則」から成り立っています。アジャイルソフトウェア開発は、これらの価値と原則に基づき、従来の手法の問題点を解決し、より柔軟で効果的な開発プロセスを提供することを目指しています。
「4つの価値」のところはミスリードされがちなのですが、原文には「すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。」と記載されています。これは、たとえば価値の一つである「計画に従うことよりも変化への対応を重視します。」であれば、「計画に従うこと」を軽視していいわけではないのです。
主なアジャイル開発手法
アジャイルソフトウェア開発にはいくつかの具体的な手法があります。それぞれの手法には独自のプロセスやプラクティスがあり、アジャイルの原則を具体的に実践するための方法が提供されています。以下に代表的なものを紹介します。
スクラム (Scrum)
スクラムは、反復的で増分的なアプローチを採用するアジャイルフレームワークです。
特徴:
スプリント: 固定された期間（通常は2〜4週間）で作業を進める。
デイリースクラム: 毎日行われる短いスタンドアップミーティング。
スプリントレビュー: スプリントの終わりに行われる成果物のレビュー。
スプリントレトロスペクティブ: チームがプロセスを振り返り、改善点を見つけるためのミーティング。
エクストリーム・プログラミング (XP)
XPは、ソフトウェア開発の品質と生産性を高めるためのプラクティスに焦点を当てたアジャイル手法です。
特徴:
ペアプログラミング: 2人のプログラマーが1つの作業ステーションでコードを書く。
テスト駆動開発 (TDD): コードを書く前にテストケースを作成する。
継続的インテグレーション (CI): 頻繁にコードを統合し、自動ビルドとテストを行う。
リファクタリング: コードの設計を継続的に改善する。
カンバン (Kanban)
カンバンは、作業の流れを可視化し、効率的なプロセス管理を実現するための手法です。
特徴:
カンバンボード: 作業項目を視覚的に管理するためのボード（列は「To Do」「In Progress」「Done」など）。
WIP制限: 一度に進行中の作業量を制限する。
継続的改善: プロセスを定期的に評価し、改善点を見つける。
ハードウェアの進化がもたらしたソフトウェア開発手法の変革
ソフトウェア開発手法の変化には、ハードウェアの劇的な進化も大きな影響を与えています。
処理能力の向上
ハードウェアの進化により、コンピュータの処理能力が飛躍的に向上しました。これにより、より複雑で大規模なソフトウェアの開発が可能になり、開発手法もそれに合わせて進化しました。高速な処理能力は、アジャイル開発で重要な短い反復サイクルや継続的インテグレーションを可能にしました。メモリとストレージの増加
メモリとストレージの容量が増加したことで、開発環境やテスト環境がより充実し、複数のバージョンや大量のデータを扱うことが可能になりました。これにより、より頻繁なリリースやフィードバックサイクルが実現しやすくなり、アジャイル開発のプラクティスに適合しました。ネットワーク技術の発展
インターネットとネットワーク技術の発展により、リモートチームやグローバルなコラボレーションが可能になりました。これにより、アジャイル開発のチーム間のコミュニケーションや協力が容易になり、分散型チームでのアジャイル実践が現実のものとなりました。仮想化とクラウドコンピューティング
仮想化技術やクラウドコンピューティングの普及により、開発およびテスト環境の迅速な構築とスケーリングが可能になりました。これにより、アジャイル開発の要求する迅速なデプロイメントとフィードバックループが強化されました。モバイルデバイスの普及
スマートフォンやタブレットなどのモバイルデバイスの普及により、ソフトウェア開発のニーズやユーザーエクスペリエンスの要求が多様化しました。これに対応するため、アジャイル開発はユーザーのフィードバックを迅速に反映し、継続的な改善を行う必要が高まりました。
ハードウェアの劇的な進化は、ソフトウェア開発の方法論や手法の進化に大きな影響を与えました。処理能力の向上、メモリとストレージの増加、ネットワーク技術の発展、仮想化とクラウドコンピューティングの普及、そしてモバイルデバイスの普及により、より柔軟で迅速な開発が求められるようになり、アジャイル開発の導入が進みました。これらの技術的な進歩が、アジャイル開発の実現と普及を支える基盤となっています。
まとめ
ウォーターフォールモデルは、その明確なステージと厳格な順序立てにより、大規模で予測可能なプロジェクトに適している一方、変化に対応しにくいという課題がありました。
アジャイルソフトウェア開発は、その柔軟性と迅速な対応力から、現在では多くの企業やプロジェクトで採用されています。
アジャイルは開発スピードを上げることを直接の目的とするものではありません。アジャイルの主な目的は、柔軟性を持って変化に対応し、顧客のニーズに迅速に応えることで、結果的により価値の高いソフトウェアを提供することです。
それと、僕に息子はいません。