同僚やチームメイトが、どのように「アジャイルを導入した」かを熱心に語るのを耳にすることが増えました。その後は、2 週間のスプリント、バックログ改善ミーティングなどについての説明が続きます。あなたには、それは「スクラムではないのか」と思われるかもしれません。では、スクラムはアジャイルなのでしょうか。アジャイルがスクラムなのでしょうか。このような疑問に答えることが、チームが確実に適切な方法論を使用するための最初の一歩になるでしょう。
アジャイルについて
アジャイルとは、ソフトウェア チームが変化に対応するために役立つ、一連の原則と価値観を取り入れたプロジェクト管理の哲学です。アジャイル チームは、プロセスやツールよりも個人や対話を、包括的な文書よりも作業用ソフトウェアを、契約交渉よりも顧客とのコラボレーションを、計画の遵守よりも変化への対応を重視しています。このような価値観は、アジャイル マニフェストに定められており、その背後には 12 の原則があります。
アジャイルを理解するには、別のプロジェクト管理哲学であるウォーターフォールと比較するとよいでしょう。ウォーターフォール デリバリーでは、製品のスコープが設定されており、時間とリソースに柔軟性があります。ウォーターフォール型の組織は、リリースが決定している製品を提供するために、プログラマーを増やしたり、スケジュール期間を延長したりすることがあります。
アジャイルでは、製品のスコープは柔軟ですが、リソースと時間は確定しています。アジャイル チームは、その時点のチームで予定どおりにソフトウェアを提供することを約束します。提供するものは、顧客が必要としているとチームがわかったものと、割り当てられた時間内でチームが作り出せるものを柔軟に組み合わせたものになります。
アジャイルを使用するメリット
アジャイル チームの行動の背後には強い「理由」があり、その方法も明確にされています。アジャイルの原則は、チームの大規模かつ野心的な目標を、管理しやすい作業単位に分割し、一貫して達成していくことです。アジャイル ソフトウェア開発者は、小規模でアジャイルなチームが、ウォーターフォール デリバリー型の大規模な競合他社より優れているという、多数の実例に支えられています。アジャイル チームは「アジャイル コンビナート」からのメリットも得られます。アジャイルを学ぼうとする人のための豊富なリソースとツールは多数揃っており、大勢のコンサルタントが導入を支援したいと熱望しています。
アジャイルを使用するデメリット
アジャイルの原則に従うと、想像もしていなかったところまでたどり着けます。アジャイルを使用して、チームは市場や顧客からのフィードバックに基づいて方向転換できます。このような理想を追っていくと、あなたが目指していたものとはまったく異なるものをチームが構築していると気付くかもしれません。そこに不安を感じ、新たな道を探り、顧客からのフィードバックを新しい方向に活かそうとするときに、方向性を見失ったとさえ感じるかもしれません。このように結果はそれぞれ異なるため、すべてのチームや企業がアジャイルな方法で作業に取り組むわけではありません。しかし、チームがこのようなハードルを乗り越えることを選択すれば、最終的にはより良い製品を顧客にリリースできることがわかるでしょう。
スクラムとは何か
スクラムは、チームが作業をスプリントと呼ばれる短い開発サイクルに組み込むためのアジャイル・フレームワークです。スクラム・チームは、各スプリントの最後に作業を確定してリリースし、このペースのとおり進められるプラクティスとチーム構造を採用します。スクラムはアジャイルの原則をさらに一歩進め、チームが日々の業務でアジャイル原則を実践できる構造を作ります。スクラムは十分に文書化されたアジャイル・フレームワークであるため、多くのチームが大きな混乱もなく採用できます。
スクラム方法論を使用するメリット
スクラム チームは予定どおりにソフトウェアをリリースします。業務の進捗状況を更新するのではなく、それらを見せることができます! ソフトウェアをリリースすると、顧客はすぐにそれを使用できます。顧客の使用状況データが増えるほど方向性が決まり、大きく成長できます。また、スクラム チームは他のチームよりも燃え尽き症候群や解約が少なく健康的です。これは、チームの成功のために、スプリント計画やスプリントのふりかえりなど、スクラム プラクティスに重点を置いているためです。
スクラム方法論を使用するデメリット
スクラムは「オールイン」のアプローチです。スクラム・マスターのような新しい役割を追加し、決められたミーティングの予定に合わせて全員のスケジュールをリファクタリングすることが成功の基礎となります。多くのチームには、新しいチームメイトを採用するためのリソースや、新たにミーティングをする時間がありません。チームが「オールイン」で団結できなければ、スクラムのメリットはあまり引き出せません。また、すべてのチームがそのような速いペースで業務をこなせるとは限りません。その結果として品質が低下すると、多くのチームがスプリントを延長し続けます。最終的には、ウォーターフォール型に戻ってしまいます。
他の方法論: カンバンとウォーターフォール
カンバンとは何か
カンバンとは、チームが継続的に業務を進めるのに役立つアジャイル フレームワークです。カンバン チームは、カード、コラム、WIP 制限、具体的なコミットメントと達成ポイントを含むカンバン ボードで作業を整理します。カンバンは、製品やサービスのほとんどが視覚化されないナレッジ ワークに適しており、チームが毎日の状況を視覚化し、業務を進めていくのに役立ちます。
ウォーターフォールとは
ウォーターフォール デリバリーは、クライアントや企業の仕様に基づいた製品またはソリューションの開発に焦点を当てています。チームは要件を調査し、数週間、数か月、場合によっては数年かけてソリューションを構築します。規制が厳しく、許容範囲が非常に狭い業界では、ウォーターフォールが適しています。
たとえば、政府が義務付けている 100 時間で、完璧に手術を終える手術用ロボットを製造しているとします。この制約が仕事のアイデアの元となり、その仕様が開発の焦点になります。チームはロボットが仕様を満たすまで何度も実験とテストを繰り返します。仕様が具体的かつ厳密な場合、ウォーターフォール開発では何よりも要件を満たすことにチームが集中できます。
チームに最適な方法論とは
アジャイル変革に期待し、これを始めるなら、方法論を選ぶと良いでしょう。アジャイル方法論には、組織がアジャイル原則を実践するために必要なチーム構造、プラクティス、ツールが用意されています。また、独自に始めることもできます。アジャイル マニフェストとある程度の創造性があれば、それぞれの業務とチームに応じて独自のアプローチを設計できます。
アジャイル vs. スクラム
アジャイルに決まったルールはありませんが、スクラムには相当数のルールがあります。アジリティを高めるための指針となるフレームワークが必要なら、最初にスクラムを選ぶと良いでしょう。スクラムなら、チームが迅速に業務を遂行し、必要に応じて方向転換できます。さらに、スクラムの導入を促す、今すぐ採用できるテンプレートもあります。また、究極の柔軟性を求めているのであれば、チームでのアジャイルへの移行を促すこともできます。アジャイル変革とは、現在の業務を分解してアジャイルな働き方を構築する、胸の躍るようなプロセスです。
アジャイルとウォーターフォール
一般に、アジャイルかウォーターフォールかの選択を迫られることはそれほどありません。それより、一方から他方への方向転換が必要になることがよくあります。そのような場合、顧客が鍵となります。顧客が注目しているのはソリューションでしょうか、それとも問題でしょうか? 顧客自身が必要なものを理解していて、その作成を誰かに依頼したいと考えているなら、ウォーターフォールが適しています。顧客が問題を抱えており、あなたがその問題を解決しようとするなら、それはすべてアジャイルになります。
Jira でアジャイル プロジェクトを管理する
今日のアジャイル フレームワークの最も良い点の 1 つに、プロジェクト管理ツールによるアジャイル フレームワークの適切なサポートがあります。Jira は、カンバン、スクラムなどをすぐに使えるように構築されています。エキスパートは日常的に Jira を拡張し、最も複雑なアジャイル フレームワークもサポートしています。アジャイル チュートリアルから開始しましょう。