A-D
アジャイル ソフトウェア管理
定義: アジャイル ソフトウェア開発とは、進化する要件に基づいて、頻繁なイテレーションでソフトウェアのインクリメントを開発するプロジェクト管理アプローチを指します。
別名: アジャイル ソフトウェア開発、アジャイル メソッド、アジャイル プロジェクト管理
語源: アジャイルは、多数のプロジェクト手法の総称であり、中でもスクラムが最も広く使用されています。2001 年、独立系ソフトウェア開発者のチームがユタ州スノーバードのスキーロッジに集まり、ソフトウェア開発でそれまで用いられてきたトップダウン型管理、ウォーターフォール手法の代替アプローチについて話し合いましたが、そこでアジャイルの概念が生まれました。当初は軽量ソフトウェア開発手法と呼ばれましたが、頻繁なイテレーションを特徴とする柔軟なリーン型のプロジェクト管理を反映するために、開発者たちはアジャイルという用語を採用しました。その週末が終わるころには、開発者はアジャイル ソフトウェア開発の 4 つの価値と 12 の原則が記載されたアジャイル宣言を作成しました。
活用法: 自己組織化された部門横断型の開発チームは、顧客や関係者と緊密に共同作業を行い、プロセスのすべてのステップに価値を加え、継続的改善という目標を目指します。
アジャイル プロジェクト管理は多数のスタイルのプロジェクトに進化し、中でもスクラムが最も広く使用されています。その他には、以下のものがあります。
- カンバン
- エクストリーム プログラミング (XP)
- クリスタル
- ダイナミック システム開発手法 (DSDM)
- リーン
- ユーザー機能駆動開発 (FDD)
アジャイルでは機能の優先順位付けとタイムボックス化されたイテレーションに焦点を当てているため、アジャイル プロジェクトに固定費を割り当てることができます。すべての機能を搭載する前に予算を使い切った場合、それらの機能は後で搭載されます。アジャイルでは、チームは常にスプリントのタイムボックス内で、優先度が最も高いアイテムの作業を行い、要件を満たす適切な製品を顧客が受け取れるようにしています。
プロジェクト管理上のメリット:
- 開発の進化において柔軟性を提供し、小規模な変更を簡単に行うことができる。
- 早期および定期的なリリースが可能。
- コストを削減する。
- リソースの無駄を削減する。
- リスクを削減し、問題を早期に発見および解決する。
- プロダクト オーナー、開発チーム、関係者の関与を促す。
- チームの所有権を促す。
- 長々とした仕様書が不要になる。
- 顧客満足度を向上させる。
- チームのパフォーマンス、コミュニケーション、モチベーションを向上させる。
Agile Project Management E-book
How can Agile PM help you do more with less?
Agile project management empowers teams to adapt to change with increased speed and flexibility. Learn how to implement Agile PM and get the most out of the methodology.
受け入れ基準
定義: 受け入れ基準では、顧客を満足させる上でソフトウェアが満たさなければならない一連の条件を指定します。プロダクト オーナーは、ユーザー ストーリーや機能がどう動作しなければならないかを説明する明細書を、顧客の視点から記述します。ストーリーや機能が受け入れられるには、受け入れ基準を満たす必要があります。そうでなければ失敗です。
活用法: 受け入れ基準は、理解しやすい明快な言葉で書く必要があります。たとえば、「ログインしている場合、『購入』ボタンをクリックすると、カートのアイテム数の合計が 1 つ増える必要がある。」という書き方になります。
プロジェクト管理上のメリット:
- ユーザー ストーリーが完成していることを確認できる。
- チームがストーリー/機能を理解するのに役立つ。
- 要件から曖昧さを排除する。
受け入れテスト
定義: 受け入れテストは受け入れ基準から派生し、機能がきちんと動作するかどうかを検証します。テストの結果は、合格と不合格の 2 つだけです。多くの場合、受け入れテストは自動化されているので、ソフトウェアのあらゆるバージョンで実行できます。通常、受け入れ基準には 1 回以上の受け入れテストが含まれます。
別名: 機能テスト、顧客テスト、ストーリー テスト
活用法: 受け入れテストにより、ソフトウェアがビジネスおよび顧客の要件を満たしていることを保証します。受け入れテストはプロダクト オーナーによって記述され、意図した挙動と結果を簡潔な文書で説明する必要があります。たとえば、「ユーザーがこのボタンをクリックすると、テキストが赤に変わる。」といった書き方です。このテストの結果は、合格または不合格のいずれかです。
プロジェクト管理上のメリット:
- 要件を満たしていることを保証することで、顧客の満足度を高める。
- 機能と使いやすさの問題を早期に特定する。
- 開発者とエンドユーザー間の共同作業を促進する。
アジャイル宣言
定義: アジャイル宣言には、反復型ソフトウェア開発プロセスの 4 つの価値と 12 の原則が記載されています。2001 年 2 月、17 人のソフトウェア開発者がユタ州に集まり、軽量開発手法について話し合いました。彼らは『Manifesto for Agile Software Development (邦題: アジャイルソフトウェア開発宣言)』を発表し、その中で「ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法」をいかに発見したかを紹介しました。
活用法: プロジェクト マネージャーは、アジャイル手法などのコア コンセプトに沿ったプロセスを管理する際に、アジャイル宣言を参照します。
プロジェクト管理上のメリット:
- 価値のあるソフトウェアを頻繁にテストし、継続的に提供する。
- 要件の変更を歓迎する。
- 部門を超えた共同作業を促進する。
アプリケーション ライフサイクル管理 (ALM)
定義: アプリケーション ライフサイクル管理 (ALM) とは、当初のプランニングから退役に至るまで、ソフトウェア アプリケーションを継続的に管理するプロセスです。
活用法: ALM はプロジェクト全体を通じて使用され、要件管理、アーキテクチャ、コーディング、テスト、追跡、リリースを支援するさまざまなツールを活用します。
プロジェクト管理上のメリット:
- プロジェクトのステータスを継続的に監視することで、リスクを軽減する。
- サイクル タイムと開発コストを削減する。
- ダウンタイムを最小限に抑える。
バックログ
定義: バックログとは、顧客のニーズを基に変更される製品要件のリストです。バックログは To-Do リストではなく、製品に必要とされるすべての機能のリストです。アジャイル チームはバックログを使用して機能に優先順位を付け、最初に実装すべき機能を把握します。
活用法: 開発チームはバックログから作業を引き出し、各イテレーション中に完了させます。バックログは、チームが顧客の要件をさらに詳しく知るにつれて、開発プロセスを通じて変化する可能性があります。
別名: 製品バックログ
プロジェクト管理上のメリット:
- 機能の優先順位を伝える。
- 長期的な計画を立てられるようになる。
- 顧客のニーズを確実に把握できるようにする。
バックログ グルーミング
定義: バックログ グルーミングはスプリントの終了時に行われ、チームがミーティングを開き、次のスプリントに向けてバックログの準備が整っていることを確認します。チームは、関連性のないユーザー ストーリーを削除したり、新しいストーリーを作成したり、優先順位を見直したり、ユーザー ストーリーをより小さなタスクに分割したりします。バックログ グルーミングは継続的なプロセスであるとともに、このアクションが行われるミーティングの名称でもあります (バックログ グルーミング ミーティング)。
別名: バックログ洗練化
活用法: チームがスプリントを完了すると、バックログ グルーミング ミーティングが予定されます。バックログ グルーミングの目的は、目標を満たす適切な項目のみがバックログに含まれるようにすることです。
プロジェクト管理上のメリット:
- すべての機能がプロジェクトの目標を満たしていることを保証する。
- 開発チームが優先順位を理解し、軌道から外れない上で役立つ。
- 重要な機能はどれか、重要でない機能はどれか、およびその理由に関するコミュニケーションを促進する。
大型ビジュアル グラフ
定義: 大型ビジュアル グラフは、アジャイル チームの近くに表示される大きなグラフで、チームの進捗状況を示します。大型ビジュアル グラフを作成することで、欠陥、速度 (バーンダウン チャート)、顧客受け入れテストを表示したり、チームが無駄にしている時間を突き止めたりすることができます。
別名: 情報ラジエーター
活用法: 大型ビジュアル グラフは、プロジェクト情報を非公式の形で表示するために使用されます。通常は壁に掲示され、重要な情報を一目で共有できるようにします。
プロジェクト管理上のメリット:
- プロジェクトのステータスを関係者に伝える。
- 透明性とコミュニケーションを改善する。
- 理解しやすい情報をすばやく伝える。
バーンダウン チャート
定義: バーンダウン チャートは、未解決のすべての作業を示します。垂直軸はバックログを、水平軸は時間を表します。残りの作業は、ストーリー ポイント、理想的日数、チーム日数などの指標で表すことができます。
別名: リリース バーンダウン チャート、イテレーション バーンダウン チャート
活用法: バーンダウン チャートは、アジャイル チームがプロジェクトの残りの総作業を追跡し、作業が完了する時期を予測するために使用されます。
プロジェクト管理上のメリット:
- 計画通りに進行していない場合、チームに警告する。
- 意思決定の影響を示す。
- 進捗を伝え、いつ作業が完了するかを予測する。
バーンアップ チャート
定義: バーンアップ チャートでは、完了した作業の量を追跡します。チャートには 2 本の線があり、1 本は総作業を、もう 1 本は完了した作業を表します。垂直軸は作業の量を表し、タスクの数、時間、ストーリー ポイントの数で測定できます。水平軸は時間を表し、通常は日数で測定されます。
活用法: バーンアップ チャートは、アジャイル チームが進捗を確認し、スコープや機能のクリープを管理するために使用されます。このチャートを使用すると、アジャイル チームはプロジェクトにおける作業の追加や削除を追跡でき、プロジェクトの現実的な完了日をチームが判断する上で役立ちます。
プロジェクト管理上のメリット:
- プロジェクトの問題を簡単に認識して解決できる。
- プロジェクトが完了する時期を見積もる。
- コミュニケーションと透明性を改善する。
頻度
定義: 頻度は、プロジェクトのイベントやタスクの流れまたはリズムを表します。これによってパターンが確立され、チームはそれに従うことで、自分たちが何をしているのか、あるいはいつ完了するのかを把握できます。
活用法: アジャイル チームはプロジェクト中に頻度を達成しようと努力しています。たとえばスクラムでは、スプリントと呼ばれる一定期間のイテレーションが 1 ～ 2 週間続き、チームが定期的な頻度でソフトウェアを出荷できるようにしています。カンバンでは、頻度は作業の継続的なフローです。
プロジェクト管理上のメリット:
- 順序とリズムを確立する。
- チームの効率を改善する。
- チームが頻繁にソフトウェアを提供できるようにする。
キャパシティ
定義: キャパシティは、一定の期間内に完了できる作業量を表し、個人やチームが作業を完了させるのに用いることができる時間数に基づいています。
活用法: プロダクト オーナーとアジャイル チームは、今後のスプリントで引き受けることができる作業のキャパシティまたは量を判断します。キャパシティはスプリント プランニング ミーティング中に決定されます。
プロジェクト管理上のメリット:
- リソース管理を改善する。
- プロジェクトの完了を見積もる。
ニワトリと豚
定義: 「ニワトリ」および「豚」という用語は、スクラムの初期バージョンの策定を支えたソフトウェア開発者、ケン・シュワバー (Ken Schwaber) 氏の「ニワトリと豚の物語」が由来です。スクラムでよく使用される「ニワトリ」とは、プロジェクトに関与しているものの、特定の成果物に対する責任を負わない人を指します (関係者やマネージャーなど)。一方の「豚」は、成果物に対してコミットし、直接責任を負う人です。
ケン・シュワバー (Ken Schwaber) 作「豚とニワトリの物語」
豚とニワトリが道を歩いています。ニワトリは豚を見て、「やあ、レストランを始めないか？」と言います。豚はニワトリを振り返り、「いいアイデアだね。どういう名前にしようか？」と尋ねます。ニワトリは考え、「『ハムと卵』はどうだい？」と答えます。「嫌だね。」豚は言います。「僕はコミットするのに、君は関与するだけじゃないか。」
活用法: ニワトリと豚は、スクラムの参加者と役割を定義するために使用されます。「豚」の役割は通常、実際のチーム メンバー、スクラム マスター、またはプロジェクト所有者です。「ニワトリ」の役割は、マネージャーや関係者です。
プロジェクト管理上のメリット:
- 役割を明確にし、定義する。
- プロジェクトの期待事項を設定する。
- 説明責任を促進する。
継続的改善
定義: 継続的改善とは、時間の経過とともに小規模な変更を段階的に行うことで、品質と効率を改善するプロセスです。カンバンでは、特にワークフローの最適化とサイクル タイムの短縮を行い、それによって生産性を向上させるプロセスを指します。
別名: カイゼン
活用法: 継続的改善は、作業プロセスを段階的に改善させるために使用され、1) 特定、2) 計画、3) 実行、4) レビューの各ステップから構成されます。
特にカンバンでは期日が設定されていないため、チームは進行中の作業に重点を置きます。チーム メンバーが共同作業によって問題のトラブルシューティングや新しいアイデアのブレインストーミングを行うにつれ、プロセスはより効率的になって合理化され、サイクル タイムが減少し、ワークフローが最適化します。カンバンでは、チームは機能横断的である必要はありません。
プロジェクト管理上のメリット:
- 生産性と納品を改善する。
- 将来の作業と納品を予測する精度が向上する。
- 作業を合理化し、無駄を減らす。
- 段階的に改善をもたらす。
- チーム メンバーの誇りと達成感を高める。
継続的インテグレーション (CI)
定義: 継続的インテグレーションとは、新しい開発コードを既存のコードベースに継続的に統合する、ソフトウェア エンジニアリングの慣行です。
別名: 継続的デリバリー、継続的展開
活用法: 機能が完成したら、開発者は欠陥がないかテストし、既存のコードベースに統合します。これにより、コード リポジトリには常にソフトウェアの最新の作業中ビルドが格納されます。実際には、バージョン管理ツール、チームのポリシーと慣習、および特定の CI ツールを使用して、このプロセスの大半が自動化されます。
プロジェクト管理上のメリット:
- 迅速なフィードバックを可能にし、欠陥を迅速に特定して修正できるようにする。
- 各統合の実行に必要な時間と労力を最小限に抑える。
- ビルドとリリースの自動化プロセスを提供する。
- ソフトウェアをいつでも成果物にすることができる。
サイクル
定義: サイクルとは、単一のタスクまたは作業項目が、作業の開始から出荷に至るワークフローを通過するのにかかる合計時間を指します。
活用法: カンバン手法ではスクラムと同じく、速度ではなくサイクル タイムを主要指標として使用します。カンバン チームがワークフローの最適化と成果物の生産の効率を高めるにつれ、サイクル タイムが短縮され、生産性が向上します。サイクルでは時間制限は設定されておらず、ワークフローは継続的デリバリーに基づいています。共通のスキルを持つカンバン チームでは、サイクル タイムがより短くなります。チームは、より短く、より一貫したサイクル タイムを目指す必要があります。サイクル タイムはスクラムでも応用できます。
プロジェクト管理上のメリット:
- 継続的改善につながる。
- 将来の納品の予測能力が向上する (サイクル タイムの一貫性による)。
- 生産性を高める (サイクル タイムの短縮による)。
デイリー スクラム
定義: デイリー スクラムは、スクラム マスターが司会を務めるコミュニケーションとステータスの簡単な確認セッションで、スクラム チームは進捗を共有し、障害を報告するとともに、現在のイテレーションやスプリントに対するコミットメントを行います。デイリー スクラムでは、タイトな時間枠の中で的を絞った会話を行います。ミーティングは毎日同じ時間 (理想的には午前中) に、同じ場所で開催されます。スクラム タスク ボードは、ミーティングの焦点として機能します。
別名: デイリー スタンドアップ、デイリー ミーティング、デイリー ハドル
活用法: 通常はスクラム マスターがチーム メンバーに次の 3 つの質問をします。
- 自分は昨日、何を達成したか？
- 今日、自分は何にコミットし、何を完了させるのか？
- どのような障害や障壁が、自分のコミットメント達成を妨げているのか？
デイリー スクラム中のすべての議論は、これら 3 つの質問への回答に的を絞る必要があります。これらの質問に起因するその他の議論については、個別に対処すべきです。デイリー スクラムに参加するのは、現在のスプリントに関与している人だけにしなければなりません。
プロジェクト管理上のメリット:
- ワークフローを順調に進める。
- 問題を早期に特定するのに役立つ。
- チームの説明責任、コミュニケーション、共同作業を強化する。
- チームがスプリントの「全体像」を確認できるようにする。
- チームの自己組織化と個人のプランニングを促す。
- チーム メンバーが問題に対処し、必要に応じて小さなコース修正を行うのに役立つ。
- 対面でやり取りする機会を提供する (オンサイトの場合)。
デイリー スタンドアップ
定義: デイリー スタンドアップ ミーティングはアジャイル手法の主要要素であり、現在のイテレーションやスプリントについて、アジャイル チームが進捗を共有し、障害を報告し、コミットメントを行う日次フォーラムとして機能します。通常、この 15 分間の短いミーティングは、毎朝同じ時刻に同じ場所で開催されます。終わるまで参加者の集中力を切らさないよう、ミーティングは簡潔にしなければなりません。また立つことで時間が短くなり、ミーティングが割り当てられた時間を超えるのを防ぎます。
別名: デイリー スクラム、スタンドアップ ミーティング、デイリー ミーティング、デイリー ハドル
活用法: デイリー スタンドアップは通常、チームの物理的なスクラム/カンバン タスク ボードを中心に開催されます (オンサイト チームの場合)。チームは、作業のステータスに関する 3 つの質問に答えます。
- 自分は昨日、何を達成したか？
- 今日、自分は何にコミットし、何を完了させるのか？
- どのような障害や障壁が、自分のコミットメント達成を妨げているのか？
デイリー スタンドアップ中のすべての議論は、これら 3 つの質問への回答に的を絞る必要があります。これらの質問に起因する追加の議論は、デイリー スタンドアップ以外の場所で対処すべきです。
プロジェクト管理上のメリット:
- ワークフローを順調に進める。
- (立つことで) ミーティングを短時間で終わらせる。
- 問題を早期に特定するのに役立つ。
- チームの説明責任、コミュニケーション、共同作業を強化する。
- チームの自己組織化と個人のプランニングを促す。
- チーム メンバーが問題に対処し、必要に応じて小さなコース修正を行うのに役立つ。
- 対面でやり取りする機会を提供する (オンサイトの場合)。
完了の定義
定義: 完了の定義は、製品が完成したと見なされるために満たす必要がある、事前に定義された一連の基準を指します。チームは、タスクの完了を定義する内容について合意に達し、製品が出荷可能と見なされる前に完了させなければならないステップのチェックリストを提示します。チームはこのリストを、自分たちのチーム エリアで目立つように、大型ビジュアル グラフの形で表示します。
別名: 単一完了、完了、完了済み、完了リスト、完了チェックリスト、製品の刺身、タスク完了定義、パンチ リスト
活用法: チームは、製品のインクリメントが「完了」と見なされる、つまりすべての設計、コーディング、テスト、ドキュメントが完了し、コードがシステムに完全に組み込まれていると見なされる前に満たす必要がある基準のリストについて合意します。タスクが完了の定義の基準を満たしていない場合、チームの速度にはカウントされません。
プロジェクト管理上のメリット:
- 機能するソフトウェアを提供できる可能性が高まる。
- 機能が「完了」として受け入れられると、手戻りコストが抑えられる。
- 開発チームと、顧客またはプロダクト オーナーとの間の誤解や対立のリスクを軽減する。
E-J
エピック ストーリー
定義: エピック ストーリーは、現状では 1 度のイテレーションで見積もったり完了するのが難しい、大規模なユーザー ストーリーとして定義されます。通常、エピック ストーリーは優先度が低く、いずれ小さなコンポーネントに分割されることになります。
活用法: 多くの場合、エピックは十分に開発されていない新しいアイデアのプレースホルダーとして使用されます。エピック ストーリーは最初の製品バックログを作成する際に一般的に用いられますが、最終的にはストーリーの要件をより詳細に定義した、管理しやすいユーザー ストーリーに分割する必要があります。
プロジェクト管理上のメリット:
- 大規模な要件のプレースホルダーとして便利。
- ユーザー ストーリーの全体像を見るのに役立つ。
見積もり
定義: 見積もりとは、プロジェクトやタスクを完了するのに必要な作業の量に定量化可能な指標を割り当て、プロジェクトまたはタスクを完了する上で必要な期間、工数、またはコストを判断するプロセスです。
使用方法: アジャイル チームは、チーム メンバーによる個々の見積もりに基づいて、タスクを完了するのに必要な作業量や期間の見積もりについて合意に達する必要があります。これは、プランニング ポーカーと呼ばれるゲームの形をとることがあります。
プロジェクト管理上のメリット:
- ソフトウェア プロジェクトの全体的な期間、工数、またはコストを示す。
- コストと期間に関連する不確実性を減らす。
- タスクやプロジェクトを見積もるガイドラインを提供する。
フェイルファスト
定義: フェイルファストとは、タスクやプロジェクトの作業を開始し、即座にフィードバックを得た上で、引き続きそのタスクに取り組むか、それとも別のアプローチを取るか (つまり改良するか) を判断するプロセスです。プロジェクトがうまくいっていない場合は、資金と時間が過剰に費やされるまで待つのではなく、プロセスの早い段階でそれを判断するのが最善です。
活用法: チームは新しいプロジェクトやタスクを開始し、早期にフィードバックを得た上で、分析を行い、プロジェクトが機能するかどうか、成功するかどうかを判断します。タスクやプロジェクトが間違った方向に進んでいる場合、チーム メンバーはできるだけ早く作業を中止すべきです。
プロジェクト管理上のメリット:
- 問題を迅速に特定する。
- 透明性の文化を生み出す。
- 時間、労力、コストの無駄を削減する。
- ソフトウェア製品開発の効率を向上させる。
フィボナッチ数列
定義: 元々は 12 世紀にレオナルド・ピサノが導き出したフィボナッチ数列は、前の 2 つの数字の合計によって後に続くそれぞれの数が決まる (つまり 1、2、3、5、8、13、21...) という数列であり、数字が大きくなるほど、それぞれの間隔が大きくなります。
活用法: チームが作業量を見積もるためにプランニング ポーカー ゲームをプレイする際に、フィボナッチ数列が頻繁に用いられます。数は相対的で、割り当てられている測定単位はありません。
プロジェクト管理上のメリット:
- 見積もりの尺度や比較基準を設定する。
- 見積もりの精度を高める。
障害
定義: 障害とは、個人またはチームによるタスクやプロジェクトの完了を妨げる障壁です。予定外の会議、技術的な問題、知識や専門知識の不足、気が散る職場、オフィスの対立はどれも障害の例です。
活用法: チームは、障害バックログと呼ばれる障害のリストを作成し、チームがデイリー スクラムで集まるエリアに、このリストを目立つように掲示することがあります。障害は、それによってチームの生産性がどれだけ深刻に妨げられているかに応じて列挙する必要があります。障害が全社的な場合、除去するのはスクラム マスターの責任です。障害がチーム レベルで発生している場合、解決または除去するのはチームの責任です。
プロジェクト管理上の懸念事項:
- 結果としてチームの生産性が低下する。
- プロジェクトのタイムラインとコストに悪影響を与える。
- できるだけ早く対処する必要がある。
イテレーション
定義: イテレーションとは、一般的に 2 ～ 4 週間にわたる一定の期間またはタイムボックス化された期間であり、アジャイル チームはその間に、提供可能で潜在的に出荷可能な製品を開発します。一般的なアジャイル プロジェクトは、一連のイテレーション、開発前のプランニング ミーティング、およびイテレーションの終わりのレトロスペクティブ ミーティングで構成されます。スクラムでは、イテレーションはスプリントと呼ばれます。
別名: スプリント、タイムボックス
活用法: イテレーションまたはスプリントの開始時に、プロダクト オーナーとチームがイテレーション中に完了させる要件を決定します。イテレーションの期間は、プロジェクトによって異なる場合があります。
プロジェクト管理上のメリット:
- チームが顧客と効果的に協力できるようにする。
- イテレーション全体を通じてフィードバックを促す。
- 機能クリープを防ぐのに役立つ。
- タイムラインのスリッページ リスクを軽減する。
反復型開発
定義: 反復型開発とは、イテレーションと呼ばれる管理しやすい構成要素にプロジェクトを分割するプロセスです。イテレーションは、アジャイル手法で出荷可能な成果物や製品を生産するのに不可欠です。
別名: インクリメンタル開発
活用法: 反復型開発では、アジャイル チームはサイクルを繰り返すことで、コードの設計、開発、テストを行います。各イテレーションが完了すると、チームはユーザーのフィードバックを収集し、それらのインサイトを活用して製品の次のイテレーションを構築します。反復型開発では、チームはプロセスを評価して改良し、継続的な改善につなげます。
プロジェクト管理上のメリット:
- 顧客満足度を改善する。
- 製品に価値を加える。
- 動作するソフトウェアや製品を迅速に納品できるようにする。
- 継続的改善につながる。
K-P
カンバン
定義: カンバンはアジャイルの範疇に入る非常に視覚的なフレームワークです。カンバン プロセスでは、固定されたイテレーションではなく継続的な作業フローを使用して、出荷可能な成果物を生産します。カンバンを既存のプロセスに適用すると、現在のプロセスに対する小規模かつ段階的な変更が促され、特定の設定や手順を必要としません。カンバンでは、スプリントではなくプロジェクト全体を完了させることに重点を置いています。
活用法: チーム メンバーはタスクを割り当てられるのではなく、製品バックログから作業を引き出します。カンバンの唯一の制約は、任意の時点でパイプラインに存在する作業量の制限 (WIP 制限) です。カンバンを用いることで、チームはサイクル タイムの短縮、ワークフローの最適化、生産性の向上を行うことができ、継続的な改善につながります。
カンバンはアジャイル手法の特色の 1 つです。主にソフトウェア開発で用いられますが、業界やプロジェクトの種類を問わず使用できます。
プロジェクト管理上のメリット:
- チームの効率が向上する。
- 柔軟性を保ち、変化に簡単に対応できる。
- サイクル タイムを短縮する。
- ワークフローを改善する。
- 継続的改善につながる。
- チームが将来の作業を予測する能力を高める。
リーン ソフトウェア開発 (LSD)
定義: リーン ソフトウェア開発は、軽量アジャイル手法をプロジェクト開発に適用した一例です。リーン ソフトウェア開発は、1950 年代にトヨタが開発したリーン生産アプローチ (ジャストインタイム生産とも) とリーン IT の原則を組み合わせ、ソフトウェアに適用したものです。LSD では人員と効果的なコミュニケーションに重点が置かれています。
LSD は 7 つの原則によって定義されます。
- 無駄をなくす
- 知識を生み出す
- 品質を組み入れる
- コミットメントを保留する
- 全体を最適化する
- 迅速に納品する
- 人を尊重する
活用法: リーン ソフトウェア開発の主な目標は、無駄を削減または排除することです。したがって、製品を合理化して最も価値のある機能のみを含め、段階的に提供することに重点を置いています。バックログの優先順位付け、短いフィードバック ループ、頻繁な単体テスト、チームの効率は、すべてリーン ソフトウェア開発の構成要素です。リーン ソフトウェア開発では、バックログから作業を引き出し、ワークフローのスピードと効率を改善するカンバン アプローチを採用しています。
プロジェクト管理上のメリット:
- プロジェクトのコスト全体を削減する。
- ワークフローの効率とスピードを向上させる。
- 動作するソフトウェアを迅速に納品できるようにする。
- 自信を持って意思決定できるので、チームのモチベーションが高まる。
ペア プログラミング
定義: ペア プログラミングのシナリオでは、2 人のプログラマーが単一のワークステーションを共有し、協力して 1 つの機能を開発します。
別名: ペアリング、ペアを組んだプログラミング、ペアによるプログラミング
活用法: ドライバー役のプログラマーがコードを記述する一方、ナビゲーター役のプログラマーがコードの記述中にそれをレビューし、戦略的な方向性を示します。2 人のプログラマーは、タスク全体を通じて定期的に役割を交代します。どちらかの、または両方のプログラマーが、開発プロセスを通じて継続的にコメントを残します。
ペアリングを効果的に行うには、ワークステーションが両方のプログラマーに対応できる必要があります。少なくとも、2 つの椅子を簡単に収容できる十分なデスク スペースが必要です。室内の騒音レベルをコントロールする必要があり、個々のペアや複数のペアのひそひそ話よりも大きくならないようにしてください。
プロジェクト管理上のメリット:
- 結果として、品質の高いコードが得られる。
- スキルの移転が増加する。
- チーム メンバー間のクロストレーニングを可能にする。
- コミュニケーションを促す。
- 問題を明確にし、意思決定プロセスを加速する。
プランニング ゲーム
定義: プランニング ゲームとは、次のイテレーションやリリースに含めるユーザー ストーリーを決めるためのプランニング ミーティングを指します。
活用法: プランニング ゲームには、プロジェクト、IT、ビジネスの関係者が参加します。参加者は、現在の作業量の見積もりを受けて、製品やプロジェクトに最大のビジネス価値を提供するユーザーストーリーを選択します。
プロジェクト管理上のメリット:
- IT 関係者とビジネス関係者間のコミュニケーションが増える。
- それぞれのリリースまたはイテレーションで、機能するソフトウェアを提供できる可能性が高まる。
プランニング ポーカー
定義: プランニング ポーカーとは、作業量の見積もりについてチームが合意に至るために使用される、チーム構築の演習またはゲームです。
活用法: プレイヤーはフィボナッチ数列の数字が印刷されたカードを使用して、ユーザー ストーリーにストーリー ポイントを割り当て、作業量を見積もります。チームは、ユーザー ストーリーや要件の完成にどれくらいの時間がかかるかについて、グループ合意に達する必要があります。また T シャツ採寸など、その他の形式の相対的な見積もりを使用することもできます。
プロジェクト管理上のメリット:
- チームの集合的な知識と経験のメリットを提供する。
- ブレインストーミングとアイデアの生成を促す。
- 問題解決を促進する。
- チームの共同作業を刺激する。
- 見積もりの精度を高める。
製品バックログ
定義: 製品バックログとは、顧客がリクエストした要件のリストです。製品バックログは「To-Do」リストではなく、むしろ、プロジェクトに含めるよう顧客が要求したすべての機能のリストです。スクラム チームは製品バックログを使用して機能に優先順位を付け、今後のスプリントでどの機能を実装するかを決定します。
活用法: プロダクト オーナーは、製品バックログ アイテム (PBI) と呼ばれる、製品バックログ内のアイテムに優先順位を付ける責任があります。開発チームは、製品バックログから優先度の高い PBI を引き出し、各スプリント中に完成させます。プロジェクト開発プロセス全体を通じて、プロダクト オーナーは必要に応じてバックログを変更し、優先順位を付け直します。
別名: バックログ
プロジェクト管理上のメリット:
- 製品バックログ アイテムの優先順位を伝える。
- 長期的な計画を立てられるようになる。
- 顧客のニーズを確実に把握できるようにする。
- チーム メンバーが必要に応じて優先順位の一番高いアイテムを引き出すことができる (カンバン チームの場合)。
製品バックログ アイテム (PBI)
定義: 製品バックログ アイテム (PBI) は、製品バックログに存在する単一の作業要素です。PBI には、ユーザー ストーリー、エピック、仕様、バグ、または変更要件を含めることができます。アジャイル チームのプロダクト オーナーは、製品バックログを編集して優先順位を付け、緊急度や重要性が最も高い PBI を一番上に配置します。PBI は、スクラム スプリント中に完了させる必要があるタスクで構成されます。つまり、それぞれの PBI では、作業のインクリメントが単一のスプリント中に完了させられるほど小さくなければなりません。製品バックログ内の優先順位が高い PBI ほど、ユーザー ストーリーに分割されます。
活用法: スクラム環境におけるイテレーション、またはカンバン環境における継続的なイテレーションによって、開発者は優先順位の最も高い PBI をバックログから引き出して作業します。
プロジェクト管理上のメリット:
- チームは、単一のスプリント中に完了させるべき作業の個々の要素を数値化し、スケジュールを立てることができる。
- ニーズを満たす適切な製品が顧客のもとに届いていることを保証する。
プロダクト オーナー
定義: アジャイル チームの一員であるプロダクト オーナーは顧客を代表し、顧客の要件とビジョンをチームに伝えます。プロダクト オーナーは受け入れ基準を作成し、製品バックログに優先順位を付け、維持します。プロダクト オーナーは、2 つの方向において上手にコミュニケーションを取れる必要があります。つまり、顧客と関係者にチームの懸念事項を伝えること、および製品に関する顧客のビジョンを満たすために、チームを軌道に乗せることです。
活用法: スクラム環境では、プロダクト オーナーはスプリント中に完了させるユーザー ストーリーを組み立て、優先順位を付けます。スプリント中、プロダクト オーナーは無言を保ちます。変更を加えたり、フィードバックを提供したりすることはできません。スプリントが完了すると、プロダクト オーナーはチーム メンバーや関係者とミーティングを行い、フィードバックを提供し、改善の方法について話し合います。プロダクト オーナーは、スプリング プランニング ミーティングで決定された受け入れ基準に基づいて、スプリントの終了時に製品を承認または却下します。
カンバン環境では、達成すべき作業アイテムのバックログをプロダクト オーナーが組み立て、優先順位を付けます。プロダクト オーナーには、すでに進行中の作業に影響を与えることなく、いつでもバックログの作業を変更し、優先順位を付け直す柔軟性があります。
プロジェクト管理上のメリット:
- 顧客のビジョンと最終製品に関するチームの理解が高まる。
- 顧客、チーム、関係者間のコミュニケーションと信頼が高まる。
- 社外関係者のチームに対するサポートを強化する。
Q-S
リファクタリング
定義: コードのリファクタリングとは、外から見た動作に影響を与えることなく、既存のコードの内部構造を改善、明確化、合理化することを意味します。リファクタリングには、コードの書き換えやバグの修正は含まれません。「リファクタリング」という名詞は、抽出法を使用して各コードの目的を明確にするなど、コードをリファクタリングする特定かつ有限の方法を指します。
活用法: リファクタリングはアジャイルで使用され、スプリントの各イテレーション間でコードの明確さと拡張性を維持します。
プロジェクト管理上のメリット:
- コードを清潔で読みやすい状態に保つ。
- コードの重複を防ぐ。
- バグの特定と修正を容易にする。
- コードの維持と拡張を容易にする。
相対見積もり
定義: 相対見積もりは、アジャイル チームがプロジェクト タスクを完了させるのに必要な工数を判断するのに用いる、いくつかのタイプの見積もりの 1 つです。タスクやユーザー ストーリーが、以前に完了させた同等のタスク、または同じような難しさのタスクのグループと比較されます。
別名: サイレント グループ化, 親和テスト
活用法: アジャイル チームは相対見積もりを使用して、類似するタスクの完了にかかった時間を基に、タスクやユーザー ストーリーを完了させるのに必要な時間と工数を評価します。チームはタスクを比較する際に、タスクの工数を極小、小、中、大、または特大として評価する T シャツ採寸など、数値以外の尺度を使用することがよくあります。
プロジェクト管理上のメリット:
- リリース日と将来の予測に関する正確な見積もりを提供する。
- 正確な見積もりを出すのに時間を無駄遣いすることがなくなる。
- 見積もりとコミットメントの混同を避けられる。
- 顧客満足度の向上につながる。
リリース
定義: アジャイル リリースとは、複数のイテレーションまたはスプリントが完了した後の、ソフトウェア パッケージの最終的なデリバリーを指します。リリースは、アプリケーションの最初のビルドである場合もあれば、既存のアプリケーションに 1 つまたは複数の機能を追加することを指す場合もあります。リリースは 1 年以内に完了させる必要があり、場合によっては 3 か月で済むこともあります。
活用法: アジャイル チームは、ソフトウェアのリリースにかかる予定時間をイテレーションの速度で割り、リリースすべきソフトウェアの開発に必要なイテレーションの数を決定します。
プロジェクト管理上のメリット:
- 具体的な目標を提供する。
- 顧客の要件とビジョンを明確にする。
- 数回のイテレーションを完了させた後、アルファ版またはベータ版の先行リリースが可能になる。
リリース計画
定義: リリース計画では、今後のリリースに含まれる機能の概要を示し、リリースの推定日付を提供します。この計画には、リリースを完了させるのに必要な責任、リソース、アクティビティを含める必要があります。
活用法: リリース計画は、リリースを完了させるのに必要な個々のスプリントと、各スプリントで達成する内容に分割されます。リリース日は、そこに含まれるスプリントの数に、チームのスプリント速度を掛けて見積もります。
プロジェクト管理上のメリット:
- リリースを完了させるのに必要な時間とリソースの合計を正確に見積もる。
- 何を達成すべきかについて、チームに共通の理解とビジョンを提供する。
- プロダクト オーナーがストーリーやタスクに優先順位を付ける上でガイドとなる。
- チーム メンバーが意思決定を行う上でガイドとなる。
- チームが予定外の作業で脱線するのを防ぐのに役立つ。
スクラム
定義: スクラムはアジャイルのグループで最も広く使用されているフレームワークです。スクラムは、事前に定義された一連の役割、責任、ミーティングに従う、反復型ソフトウェア モデルです。
スクラムでは、イテレーションはスプリントと呼ばれ、一定の期間が割り当てられます。スプリントの長さは通常 1 ～ 2 週間ですが、1 か月続くこともあります。
活用法: スクラム手法では、スクラム プロジェクトごとに、プロダクト オーナー、スクラム マスター、およびスクラム チームという、3 つの特定の役割を指定します。スクラム プロジェクトの特徴として、製品バックログ、スプリントのプランニング、バックログの改善、デイリー スクラム ミーティング、スプリント レビュー ミーティング、スプリント レトロスペクティブ ミーティングがあります。
スクラム スプリントが完了すると、潜在的に出荷可能な機能するソフトウェアのインクリメントが生成されます。スクラムを使用すると、ソフトウェアの最終的なリリースを待つのではなく定期的に、ソフトウェアのインクリメントを顧客に提供できます。
プロジェクト管理上のメリット:
- チームの説明責任を向上させる。
- プロジェクト中の変更に簡単に対応できる。
- 発生した問題をすぐに特定することで、コストを削減する。
スクラム チーム
定義: スクラム チームは通常、機能横断型のスキルを持つ 5 ～ 9 人のメンバーで構成されます。従来型の開発者チームと異なり、特定の役割はありません。スクラム チームは自己組織化され、自己完結型であり、チームにはスプリントを完了させるのに必要な適切なスキルを持つ、適切な人数のメンバーがいなければなりません。
活用法: スクラム チームは協力してスプリントを完了させ、潜在的に出荷可能な機能するソフトウェアのインクリメントを作成します。スプリントの終了時に、チームはプロダクト オーナーおよび関係者とスプリント レビューを行い、スプリントで達成したことを提示し、問題をレビューするとともに、フィードバックを得ます。スプリント レトロスペクティブ ミーティングを別に行うことで、チーム メンバーは次のスプリントに必要なフィードバックや改善について話し合うことができます。
プロジェクト管理上のメリット:
- チーム メンバーの信頼感と説明責任を向上させる。
- フィードバックとブレインストーミングを通じた継続的な改善につながる。
- 選ばれた一部のメンバーだけでなく、チーム メンバー全員のリーダーシップを育む。
スクラム マスター
定義: 多くの場合、スクラム マスターはチームのコーチと見られています。ミーティングを主催し、障害や問題を解決するとともに、プロダクト オーナーと協力して製品バックログを最新の状態に保ちます。スクラム マスターはチーム メンバーに対する権限を有していませんが、プロセスに関する権限を有しています。スクラム マスターは、正式なトレーニングを完了させて認定スクラム マスターになることもありますが、必須ではありません。
活用法: スクラム マスターはデイリー スクラム ミーティングの司会を務め、プロジェクトのスプリント期間を決定し、ワークフローの進捗を追跡します。またプロダクト オーナーと協力して、製品バックログを最新の状態に保ち、ワークフローの障害を取り除きます。スクラム マスターは、チーム メンバーに過大な負担がかかっておらず、最大限の能力を発揮できるようにします。
プロジェクト管理上のメリット:
- チーム メンバーが最も効率的なスクラム プロセスに従っているようにする。
- チームが自己満足に陥るのを防ぐ。
- 継続的な改善に向けてチームを導く。
- チーム メンバーをプロジェクトとスクラム プロセスの両方に関与させる。
スクラム オブ スクラム
定義: スクラム オブ スクラム ミーティングは、複数のスクラム チームが関与する大規模なプロジェクトを管理するために用いられる、スケールアップのメカニズムです。スクラム オブ スクラムは、互いに依存関係にあるかもしれないチーム間のコミュニケーションを促進するために実施されます。各チームから 1 人のメンバーが参加してチームを代弁します。これはスクラム マスターの場合もあれば、効果的に情報を伝え、チームの疑問や懸念事項に対処できるチーム メンバーの場合もあります。
活用法: スクラム チームが、別のチームのスプリントに影響を与え得る依存関係、リスク、または問題を含む大規模なプロジェクトに取り組んでいる場合、そうした問題を議論または解決するためのコミュニケーション フォーラムとして、スクラム オブ スクラムがスケジュールされます。
プロジェクト管理上のメリット:
- コミュニケーションを促し、チーム間の共同作業を促進する。
- プロジェクトの「全体像」と、あるチームのスプリントが別のチームにどのような影響を与えているかを、複数のチームが確認できる。
- あるチームの作業が別のチームに悪影響を与えるリスクを減らす。
- チームが問題に対処し、必要に応じて小さなコース修正を行うのに役立つ。
- プロジェクトのワークフローを最適化する。
スクラムバン
定義: スクラムバンは、タスクを達成し、成果物を生産するのに用いられる、スクラムとカンバンのハイブリッドです。
活用法: スクラムバンは、スクラム チームが進行中の作業と継続的な改善に焦点を当てることで、カンバン手法をプロセスに適用したい場合に使用されます。また、カンバン チームが毎日のスタンドアップ ミーティングや役割など、スクラム構造をプロセスに適用することもできます。
プロジェクト管理上のメリット:
- 両方の方法のベスト プラクティスを組み合わせて、チームのプロセスを強化する。
- チームに最も適した方法でプロセスを柔軟に改良できるようにする。
- チームのキャパシティと需要のバランスをとる。
- スクラム チームの場合、視覚化を強化する。
- 継続的改善を長期的に進化させる方向へとチームを導く。
スパイク
定義: スパイクとは、疑問を調べたり問題を解決するために作成された、個別のタイムボックス化されたユーザー ストーリーまたはタスクを指します。スパイクでは、出荷可能な製品の生産ではなく、情報を収集し、疑問への答えを提供することに重点を置いています。
活用法: アジャイル チームがさらなる研究や調査を行うまで、ユーザー ストーリーやタスクを正確に見積もれない場合に、スパイクが作成されます。スパイクによって特定のアウトプット (元のユーザー ストーリーの見積もり) が生成され、スプリントを前進させられるようになります。
プロジェクト管理上のメリット:
- ユーザー ストーリーの見積もりの精度と信頼性が向上する。
- ユーザー ストーリーや PBI 要件に対するチームの理解を深める。
- 無駄な作業や、作業が「迷走」してしまうリスクを軽減する。
スプリント
定義: スプリントとは、1 つのユーザー ストーリーまたは製品バックログ アイテム (PBI) が、潜在的に出荷可能な成果物に変換される、一定期間のイテレーションです。各スプリントには、達成すべき一定の時間 (タイムボックスとも) が割り当てられます。これは 1 週間から 1 か月ですが、通常は 2 週間続きます。
活用法: 各スプリントは、プロダクト オーナーとスクラム チームのプランニング ミーティングから始まり、プロダクト オーナーや顧客の要件を満たしつつ、現実的に達成できる作業の量を決定します。スクラム マスターがスプリントの長さを決定しますが、プロジェクト全体で一貫している必要があります。
スプリントの終了時に、チームは作成された製品またはソフトウェアをプロダクト オーナーに提示します。プロダクト オーナーはチームにフィードバックを提供するとともに、スプリント プランニング ミーティングで確立された受け入れ基準に基づいて、製品を受け入れるか却下します。プロジェクトのすべてのスプリントが完了したら、チームは最終的なソフトウェア パッケージをいつでもリリースできる必要があります。
プロジェクト管理上のメリット:
- チームが圧倒されてしまうのを防ぐ。
- 顧客向け成果物の予測可能性と信頼性を向上させる。
- フィードバック ループを短縮する。
- 問題が見つかる前に、作業が進行しすぎてしまうのを防ぐ。
スプリント バックログ
定義: スプリント バックログとは、チームがスクラム スプリント中に完了させることを選んだ製品バックログ アイテム (PBI) のセグメントです。これらの PBI は通常、製品バックログから取得したユーザー ストーリーです。
活用法: チームはスプリント プランニング ミーティング中に、各スプリントを完了させるのに必要な作業工数とチームのキャパシティの見積もりを基に、次のスプリントに含める PBI またはユーザー ストーリーを決定します。チームは PBI またはユーザー ストーリーをタスクに分割し、各タスクを完了させるための作業時間の見積もりを割り当てます。
別名: イテレーション バックログ
プロジェクト管理上のメリット:
- 優先順位の一番高い PBI が最初に完了する。
- 長期的な計画を立てられるようになる。
- 作業を管理可能なコンポーネントに分割する。
- チームがスプリント中に達成できる PBI の量を決定できる。
スプリント プランニング ミーティング
定義: スプリント プランニング ミーティングは、各スプリントの開始前に行うワーキング セッションであり、プロダクト オーナーの受け入れ基準と、開発チームがスプリントの終了時までに現実的に達成できる作業量との間で、相互に合意するのが目的です。スプリントの長さによってプランニング ミーティングの長さが決まり、2 時間がスプリントの 1 週間に相当します。この数式を用いると、2 週間のスプリントのプランニング ミーティングは約 4 時間になりますが、変動することがあります。
活用法: スプリント プランニング ミーティングではスプリントのステージを設定します。スクラム マスターがミーティングの司会を務め、プロダクト オーナーが、スプリントの終了までに完了させるべき製品バックログ アイテム (PBI) やユーザー ストーリーを提示し、優先順位を付けます。その後チームが、PBI やユーザー ストーリーを管理可能なタスクに分解します。最終的に、チームはスプリント中に達成できる作業の量を決定します。
プロジェクト管理上のメリット:
- チームの明確な目標を確立する。
- プランニング ミーティング中に合意した数の PBI とタスクを完了させることについて、チームのコミットメントが得られる。
- スプリント中にチームが過負荷に陥るのを防ぐ。
スプリント計画
定義: スプリント計画は、スプリント プランニング ミーティングの具体的な結果です。スプリント計画は、開発チームが組み立てる書面の文書であり、1) スプリントの目標 (スプリントの終了までに完了させるべき製品または成果物の簡単な説明)、2) チームの可用性と速度を基に、チームがスプリントの終了までに完了させることを約束した、製品バックログ アイテム (PBI) またはユーザー ストーリーの詳細なリストで構成されています。それぞれの PBI またはユーザー ストーリーは、プロダクト オーナーが設定し、チーム メンバーに割り当てた優先順位に応じてタスクに分割されます。
活用法: スプリント計画は、チーム メンバーがスプリントの期間中に参照し、従うロードマップです。この計画により、プロダクト オーナーとスクラム チームは、チームがスプリント中に達成すると約束したことに関する、書面による合意を得られます。
プロジェクト管理上のメリット:
- スプリントの明確な目標を確立する。
- 開発を順調に進める。
- プロダクト オーナーなどの関係者が、チームに追加作業を押しつけるのを防ぐ。
- 合意したタスクを完了させることから、チーム メンバーがそれてしまうのを防ぐ。
- スプリント完了後にレビューする具体的な文書を提供し、作業量とスプリントの長さが現実的だったかどうかを判断できる。
スプリント レトロスペクティブ
定義: スクラム レトロスペクティブとは、スプリントが成功したかどうかを議論し、次のスプリントに組み込む改善点を特定するために、スプリントの完了後に行われるミーティングです。
活用法: スクラム チームはレトロスペクティブ ミーティングを開催してスプリントをざっと分析し、次のスプリント中にチームが対処すべき優先項目を 1 つか 2 つ特定します。レトロスペクティブの目的は、広範なポストモーテムを行うことではなく、チームが継続的改善という目標に向かって前進する具体的なステップに焦点を当てることです。通常、レトロスペクティブはデータ収集、データ分析、アクション アイテムの 3 つに分かれます。
プロジェクト管理上のメリット:
- チームがミスから学び、共同作業を行ってソリューションを実現する。
- 改善がアジャイル プロセスにすぐ組み込まれる。
- チームに活力を与え、問題に対するソリューションのブレインストーミングを行えるようにする。
- フラストレーションとストレスを解消する。
- 継続的改善のプロセスが、顧客にとってのより良い価値につながる。
- チームに力を与える。
スプリント レビュー
定義: スクラム チームは、スプリントの完了後すぐにスプリント レビュー ミーティングを行い、スプリント中にチームが達成したことを見直し、説明します。このミーティングには、プロダクト オーナーまたは顧客、スクラム マスター、スクラム チーム、および関係者が参加します。スプリント レビューは非公式のミーティングです (Powerpoint のスライドを使ってはいけません)。スプリントの長さによってレビュー ミーティングの長さが決まり、1 時間がスプリントの 1 週間に相当します。この数式を用いると、2 週間のスプリントのレビュー ミーティングは約 2 時間になりますが、変動することがあります。
活用法: スプリント レビューの目的は、スプリント中に発生したことを評価し、そのスプリントで潜在的に出荷可能な機能する成果物を生み出したかどうかを判断することです。チームは、スプリント中に開発した成果物を提示または説明します。プロダクト オーナーはチームにフィードバックを提供し、成果物が受け入れ基準を満たしているかどうかを判断した上で、製品を受け入れるか却下します。
プロジェクト管理上のメリット:
- スプリントの目標が達成されたかどうかを判断する。
- スプリントの結果をビジュアルで実証する。
- プロダクト オーナー、顧客、その他の関係者からのフィードバックを即座に提供する。
- 改善が必要な領域を明らかにする。
関係者
定義: 大まかに言えば、関係者とは、チームが生み出している製品に関心を持つ、スクラム チーム外の全員を指します。直属のマネージャー、そのテーマに関する専門家、アカウント マネージャー、営業担当者、法務担当者などが関係者にあたりますが、これらに限定されません。
活用法: 関係者がアジャイルで正式な役割を担うことはありませんが、顧客が最も重要であると見なされています。アジャイルの最優先目標は、イテレーションやスプリントで生み出された個々の製品または成果物に価値を加えることです。製品の受け入れは、顧客を代表して行動するプロダクト オーナーが、顧客の受け入れ基準が満たされていると判断しているかどうかに左右されます。他の関係者は、さまざまな役割を担います。
プロジェクト管理上のメリット:
- 顧客のニーズとビジョンが正確に満たされていることを保証する。
- チームが高品質の製品を提供できることについて、顧客の信頼を高める。
- イテレーションに必要な予算をアカウント マネージャーに伝える。
- パイプラインにある製品を営業担当者に伝える。
- 関係者がプロセスに関わるよう促す。
スタンドアップ/デイリー ミーティング
定義: イテレーションあるいはスプリント中、アジャイル チームは毎朝同じ場所で 15 分間のスタンドアップ ミーティングを行い、現在の作業ステータスについて情報共有します。適切なものでなければならないが、これ以上立っていたくないとチーム メンバーが思うほど長くてはいけない、というのがスタンドアップの考え方です。
別名: デイリー スクラム、デイリー スタンドアップ、デイリー ハドル
活用法: スタンドアップ中、アジャイル チームのメンバーはチームのタスク ボードの周りに集まり、進捗の共有、障害の報告、および現在のイテレーションやスプリントに対するコミットメントを行います。通常、チームは作業のステータスに関する 3 つの質問に答えます。
- 自分は昨日、何を達成したか？
- 今日、自分は何にコミットし、何を完了させるのか？
- どのような障害や障壁が、自分のコミットメント達成を妨げているのか？
スタンドアップ中のすべての議論は、これら 3 つの質問への回答に的を絞る必要があります。その他の質問が上がった場合は、スタンドアップ以外の場所で対処します。
プロジェクト管理上のメリット:
- ワークフローを順調に進める。
- (立つことで) ミーティングを短時間で終わらせる。
- 問題を早期に特定するのに役立つ。
- チームの説明責任、コミュニケーション、共同作業を強化する。
- チームの自己組織化と個人のプランニングを促す。
- チーム メンバーが問題に対処し、必要に応じて小さなコース修正を行うのに役立つ。
- 対面でやり取りする機会を提供する (オンサイトの場合)。
ストーリー
定義: ストーリー (ユーザー ストーリー) とは、エンドユーザーの視点から書かれたソフトウェア システム要件に関する、簡潔かつ非技術的なステートメントです。ストーリーは次の構造に従って記述されます: <ユーザーの種類> である私は、<何らかの目標> を達成できるよう、<何らかのタスク> を実行する必要がある。
活用法: スプリント プランニング ミーティング中、プロダクト オーナーは、各スプリントに含めるストーリーに優先順位を付けます。チームは各ストーリーにストーリー ポイントを割り当てて作業量を見積もり、スプリント中に完了させるタスクにストーリーを分割します。イテレーションまたはスプリントが完了した時点で、チームはストーリーで指定された当初の要件に対応する、機能する製品や成果物を生み出している必要があります。
プロジェクト管理上のメリット:
- 生産性が向上する。
- チームがソフトウェアの要件と受け入れ基準を明確に理解できるようにする。
- ストーリーの実装に先立ち、プロダクト オーナーや顧客が小規模な変更を行う柔軟性を提供する。
- 継続的な改善を促す。
- 製品の価値と品質を向上させる。
- 欠陥のリスクを低減する。
ストーリー マッピング
定義: ストーリー マッピングとは、上から見た製品バックログの視覚化 (ロードマップ) を指します。ストーリー マップは目標または特定の機能から始まり、次にユーザー ストーリーに分割されます。ストーリー マップはツリー形式で作成しますが、壁に付箋を貼った物理的なものである場合もあれば、デジタル形式で作成する場合もあります。
活用法: ストーリー マッピングによって、チームと関係者は、製品バックログと優先順位付けされたユーザー ストーリーを視覚的に確認できます。
プロジェクト管理上のメリット:
- バックログの全体像を視覚的に表現できる。
- 目標や機能要件の理解を深める。
- 製品バックログの欠陥を明らかにする。
- 顧客にとっての価値を高める。
スウォーミング
定義: スウォーミングとは、適切なスキルを持つチーム メンバーが協力して、単独で完了させるのが難しいタスクを完了することです。
活用法: スウォーミングは、ワークフローと納品を順調に進めるべく、タスクや作業項目をすばやく完了させて次の作業に進むために使用されます。特にカンバン チームは、スウォーミングを活用して継続的なワークフローを実現し、進行中の作業 (WIP) 制限を維持しています。
プロジェクト管理上のメリット:
- ワークフローと納品を順調に進める。
- カンバンにおける WIP 制限を維持する。
- チームの共同作業を促進する。
持続可能なペース
定義: 持続可能なペースとは、開発者を疲弊させることなく、アジャイル チームが無期限に作業を行えるペースです (理想的には週 40 時間)。
活用法: 持続可能なペースは、残業、夜勤、および週末の作業を必要とせず、アジャイル チームが最適なパフォーマンスを発揮できるように確立されます。持続可能なペースで作業することにより、残業では突き止められなかったであろう、スケジューリング、管理、品質の欠陥を明らかにし、是正するのに役立ちます。
プロジェクト管理上のメリット:
- ワークライフ バランスを促進する。
- 最適なパフォーマンスを促進する。
- チーム メンバーが常にリフレッシュした状態でいられるようにする。
- 生産性が向上する。
T-Z
タスク
定義: タスクとは、ユーザー ストーリーから分解された作業の 1 単位です。通常、タスクは 1 人だけで完了させます。
活用法: タスクはスクラムで使用され、スプリント中にチーム メンバーが完了させる小規模な作業インクリメントを特定します。チームはカードやメモをタスク ボードに貼り付け、完了させるタスクを視覚的に識別します。
プロジェクト管理上のメリット:
- ユーザー ストーリーを管理可能な単位に分割する。
- チーム メンバーが圧倒されることなく、単一または複数のタスクを完了できるようにする。
- アジャイル タスク ボードで簡単に識別できる。
タスク ボード
定義: アジャイル タスク ボードとは、ユーザー ストーリーをタスクや作業単位に分割した、物理的またはオンラインの視覚的表現です。物理的なタスク ボードは非常にシンプルで、To Do (未実行)、Do (実行中)、Done (実行済み) とラベリングされた 3 つの列があるホワイト ボードです。タスクを表す色付きの付箋やインデックス カードが、タスクの現状を示す列に貼られます。タスク ボードを拡張して列の数を増やしたり、水平のスイム レーンを含めることもできます。
活用法: タスク ボードはスクラム チームとカンバン チームの両方について、重要なビジュアル コミュニケーション ツールとして機能し、常に最新の状態に保つ必要があります。ボードはデイリー スクラムの焦点として機能するため、チーム メンバーが集まれるほど広く、チーム メンバーが他の時間帯に参照できる便利なエリアに配置する必要があります。
チームがスプリントやイテレーションを進めるにつれ、タスク カードをボード上で水平に移動し、タスクの現在の作業状態を反映させます。タスク ボードを強化させ、色分けされたポスト・イット メモや付箋で優先順位、ステータス、担当者などを表すことができます。カンバン タスク ボードでは、進行中の作業制限を示す数値を常に表示する必要があります。
プロジェクト管理上のメリット:
- チームを軌道に乗せる。
- 使いやすく、維持しやすい。
- チームのコミュニケーションを強化する。
- 生産性を向上させる。
- 継続的な改善を促す (カンバンの場合)。
チーム/チーム メンバー
定義: アジャイル、スクラム、またはカンバン環境におけるチームは、5 ～ 9 人から成る小規模かつ高機能のグループで、共同作業を行ってイテレーションやプロジェクトを完了させます。チームには、プロジェクトに取り組むのに必要なスキルと能力があります。スクラム チームが部門横断型のチームである一方、カンバン チームは部門横断型の場合もあれば、スペシャリストの場合もあります。
チーム メンバーには役割が割り当てられず、チームにプロダクト オーナーやスクラム マスターは含まれません。チーム メンバーは、開発者、設計者、テスター、テクニカル ライター、または成果物の作成に必要な適性を持つその他の個人です。
活用法: アジャイル チームは協力してユーザー ストーリーやプロジェクトを完成させます。各メンバーは、単一のタスクまたは作業単位に取り組みます。チーム メンバー全員に、チームの目標達成を支援する義務と責任があります。
プロジェクト管理上のメリット:
- 生産性が向上する。
- 継続的な改善と進化につながる (特にカンバン チームの場合)。
- リーダーシップを発揮し、コミットメントを築き上げる力をチーム メンバーに与える。
- プロジェクトに対する所有権の感覚を高める。
技術的負債
定義: 技術的負債とは、開発チームがソフトウェア パッケージを開発するにあたって長期的な結果を考慮することなく、簡便な短期アプローチを用いた際に発生する負担を指します。技術的負債によって、ソフトウェア パッケージに発生した非効率、不正確さ、およびその他の問題のために、プロジェクトのコストと複雑さが増加します。不適切な管理、能力不足、タイムラインのプレッシャー、ケアレス ミスはどれも、技術的負債を生み出す可能性があります。
活用法: 開発中、チームが品質と付加価値に焦点を当てる動機として技術的負債が使用されます。これにより、コードのリファクタリングとレビュー、自動化された単体テストの実行、一貫性のあるコードの統合が、一貫性を保ちつつ入念に実施されます。技術的負債を防ぐ上で、ペア プログラミングが役立つことがよくあります。関連する知識と経験を増やすよう、チーム メンバーを奨励する環境を生み出すことも、技術的負債を防ぐのに役立ちます。
プロジェクト管理上の懸念事項:
- 製品の品質を低下させる。
- 欠陥率が高くなる。
- 生産性を低下させる。
- ワークフローの速度を低下させる。
- コード メンテナンスの品質を低下させる。
- 変更と実装が高額になる。
テスト主導型開発 (TDD)
定義: テスト主導型開発とは、実際に機能するコードのテストを設計および構築し、次いでそれらのテストに合格するコードを構築する慣行です。
活用法: TDD を用いることで、コードの目的と動作方法に関するチームの理解を、開発を始める前に深めることができます。次に、チームはテスト基準を満たすコードを記述します。TDD を使用しているチームは、テスト基準と受け入れ基準を満たす、より合理化された高品質のコードを作成します。
プロジェクト管理上のメリット:
- 作業速度を向上させる。
- コードの品質を向上させる。
- 再作業を減らす。
- デバッグ時間を短縮する。
- 欠陥率を低減する。
- 参照用のテスト ドキュメントが作成される。
- コードを簡素化する。
- 迅速なフィードバック ループを提供する。
タイムボックス
定義: タイムボックスとは割り当てられた期間を指し、その中で個人やチームは確立された目標に向かって作業します。チームは、作業が完了した時点ではなく、期間が終わった時点で作業を停止します。その後、特定の目標に向けて作業がどれだけ達成されたかを評価します。
活用法: タイムボックスはアジャイル ソフトウェア開発で実施され、成果物を製作する際の品質と価値を高めます。特に、タイムボックスはスクラム スプリントとスパイクで適用され、タスクに一定の長さが割り当てられます。タイムボックス内で完了しなかった作業は、別のイテレーションに再度割り当てられるか、優先順位が付け直されます。
プロジェクト管理上のメリット:
- 最も価値を生み出すタスクや課題により焦点を当てる。
- 顧客のニーズが確実に満たされるようにする。
- 機能クリープを低減する。
- 短いフィードバック ループを提供する。
- 最も重要な機能がソフトウェア パッケージに確実に含まれるようにする。
単体テスト
定義: 単体テストとは、コードの完成後にそのテストと検証を行うために記述された、短いプログラムの断片です。コードの単体テストの結果は、合格か不合格かのいずれかです。単体テスト (またはテスト スイートと呼ばれる一連のテスト) は、ソフトウェア開発製品をテストする第 1 段階です。
活用法: 開発者は、自分たちが開発している小規模なコードの単体テストを記述し、コードが正しく動作することを確認するために文書化します。バグ修正を目的とした単体テストも記述する必要があります。コードが修正、移動、または削除された場合、単体テストを編集してその変更を反映し、再度実行しなければなりません。
プロジェクト管理上のメリット:
- 開発プロセスの早い段階でソフトウェアのバグを特定する。
- コードの各部分の文書を提供する。
- 短いフィードバック ループを提供する。
- 統合テストをよりスムーズに実行するのに役立つ。
ユーザー ストーリー
定義: ユーザー ストーリーとは、顧客またはエンドユーザーの視点から書かれたソフトウェア システム要件に関する、簡潔かつ非技術的な説明です。プロダクト オーナーまたはチームのいずれかが、次の構造に従ってユーザー ストーリーを記述します: <ユーザーの種類> である私は、<何らかの目標> を達成できるよう、<何らかのタスク> を実行する必要がある。
活用法: プロダクト オーナーが製品バックログ アイテム (PBI) をユーザー ストーリーに分割します。ストーリーを完成させるのに必要な作業量を評価するために、ユーザー ストーリーにはストーリー ポイントが割り当てられます。プロダクト オーナーがユーザー ストーリーに優先順位を付けると、チームは優先順位が一番高いストーリーを、次のイテレーションまたはスプリント中に完了させるタスクに分割します。アジャイル チームはこれらのストーリーを使用して、顧客の要件を満たすコードを作成します。イテレーションまたはスプリントが完了した時点で、チームはストーリーで指定された要件に対応する、潜在的に出荷可能な機能する製品または成果物を生み出している必要があります。
プロジェクト管理上のメリット:
- 生産性が向上する。
- チームがソフトウェアの要件と受け入れ基準を明確に理解できるようにする。
- チームに継続的または頻繁なフィードバックを提供する。
- ストーリーの実装に先立ち、プロダクト オーナーや顧客が小規模な変更を行う柔軟性を提供する。
- 継続的な改善を促す。
- 製品の価値と品質を向上させる。
- 欠陥のリスクを低減する。
ユーザー ペルソナ
定義: ユーザー ペルソナとは、その製品を使用するであろう典型的なエンド ユーザーを詳しく説明する、仮説上の記述または伝記です。ペルソナは通常、ストック写真、名前、職業、生活様式、およびエンド ユーザーとしての分類に関連するその他の詳細から成る文書の形をとります。
活用法: アジャイル設計者と開発者は、特定のタイプのエンド ユーザー、または複数のタイプのエンド ユーザーのニーズに合った製品を開発するガイドとしてペルソナを使用します。チームはペルソナを使用して、特定の機能、インタラクション、視覚的な合図を製品に追加するかどうかを決定します。
プロジェクト管理上のメリット:
ターゲットとするエンド ユーザーのタイプに対するチームの意識を高める。
結果として得られる製品や成果物の価値と整合性を高める。
万人を喜ばせることを目的としない、より的を絞り、現実的で、合理化された製品や成果物を生み出す。
何を含めるかを判断しなければならない開発者に対し、焦点を提供する。
速度
定義: 速度は、チームが単一かつ一定期間のイテレーションまたはスプリント内で完了できる作業の量を特定する指標です。
活用法: 開発チームは、チームの構成とスプリント期間が変わらない限り、今後のスプリントを完了させるのに必要な作業工数を予測する手段として速度を使用します。速度は、製品バックログの完了にかかる時間を見積もる手段としても使用されます。つまり、確立された速度をユーザー ストーリーの総数またはストーリー ポイントの合計数で割ることで、チームはバックログを完了させるのに必要なイテレーションの回数を決定します。
プロジェクト管理上のメリット:
- 今後の作業を見積もるのに必要な時間を減らす。
- より正確な作業量の見積もりとタイムボックスを提供する。
- 見積もりを柔軟に調整できる。
- リソースとリリースのプランニングに役立つ。
進行中の作業 (WIP) 制限
定義: 進行中の作業 (WIP) 制限とは、現在開発中で、成果物としてリリースする準備ができていない作業を指します。スクラム チームの場合、これはスプリント中に達成される作業にあたります。カンバン チームの場合、これはバックログから引き出され、現在開発中の作業を指し、カンバン タスク ボードの「進行中」または「進行中の作業」列のカードで示されます。
活用法: カンバン手法で用いられる制約は進行中の作業 (WIP) 制限だけです。カンバン チームは、ある時点でパイプラインに存在できるストーリーや作業項目の数を表す数字を決定し、カンバン ボードに貼り付けます (カードまたはポスト・イット メモを、カンバン ボードの「進行中」の列に貼ることで示されます)。これらの制限は進行中の作業制限または WIP 制限と呼ばれ、作業をスムーズに進め、ボトルネックを明らかにすることを目的としています。
WIP 制限を適用することで、チームは限られた数のタスクに集中し、完了に向かって作業します。チームが現在の作業を完了するまで WIP の列に新しい作業を加えることはできません。WIP の制限を超えたり、設定が大きすぎたりすると、ワークフローや納品に悪影響が及ぶ可能性があります。スクラムチーム内でも WIP 制限を適用して、作業をスムーズに進めることができます (スクラムバンを参照)。
プロジェクト管理上のメリット:
- ワークフローのボトルネックを明らかにする。
- 1 人または複数のチーム メンバーに負荷がかかりすぎるタイミングを示す。
- 作業がパイプラインをスムーズに流れ続けるようにする。
- 生産性が向上する。
- 継続的な改善を促す。
Smartsheet をアジャイル プロジェクト管理ツールとして使用する
ニーズに合わせ変化に対応できるようデザインされた、柔軟性のあるプラットフォームで、チームの能力を最大限に引き出しましょう。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。