SAFe 用語集

[wpdm_file id=107]

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

 

glossary-icon

A

Agile Architecture
アジャイルアーキテクチャー
アジャイルアーキテクチャーは、新しいビジネスの機能性を実装することと同時に、システムのアーキテクチャーや設計のアクティブな進化をサポートする価値やプラクティスの集合である。このアプローチを用いて、1つ、あるいは1つ大きなシステムでも、そのアーキテクチャーは現在のユーザーのニーズをサポートしつつ、時間とともに進化する。これによって、事前に大きな設計(BUFD)や、ステージゲート法の開始と停止を避ける。

Agile Release Train
アジャイルリリース列車(ART)
アジャイルリリース列車は、複数のアジャイルチームから構成される長期にわたチームである。通常、50~125人のメンバーからなる。ARTにおける各チームは計画策定、開発及び振り返りに関する一定的なリズムを用いて、共通ミッションにベクトル合わせをする。各列車には、2週間ごとに価値のある、評価可能なシステム能力を継続的に定義、構築、テストするために必要な、専任のリソースが含まれ、継続的にプロダクト開発フローを提供する。

Agile Teams
アジャイルチーム
アジャイルチームは5名~9名のメンバーからなるクロスファンクションナルグループである。チームは短い反復の時間枠内でソリューション価値を定義、構築及びテストのための能力と権限を持つ。チームは価値の納品を成功させるためのメンバーから構成され、必要な場合、専門家からのサポートを受ける。

Architectural Runway
アーキテクチャー滑走路
SAFeはアジャイルアーキテクチャーのコンセプトを実装するために、アーキテクチャー滑走路を1つの手段として利用する。滑走路はビジネスの取り組みを開発するため、また、新しいフィーチャーやシステム能力を実装するために必要な技術土台を提供する。過度的な、遅延を招く再設計を行うことなく、今後の優先順位が最も高いフィーチャーの実装をサポートするために、エンタープライズのプラットフォームは十分な既存の技術的インフラがある場合、アーキテクチャー滑走路が存在すると言う。

ページの先頭に戻る

B

Budgets
予算
SAFeは、プロジェクトではなく、価値のストリームに投資するというリーン-アジャイル予算編成の戦略を用意している。こうすることで、支出を制御するのはプログラムポートフォリオ管理だけれども、すばやく意思決定をして柔軟に価値を納品するための専用の予算権限が価値のストーリーに与えられる。

Built-in Quality
作り込んだ品質
作り込んだ品質はSAFeの4つの中心的価値の1つである。エンタープライズの持続可能な最も早いリードタイムで新しい機能性を納品するための能力、及び迅速に変化するビジネス条件に対応する能力は作り込んだ品質に依存する。

Business Epic
ビジネスエピック
エピックを参照する。

Business Owners
ビジネス責任者
ビジネス責任者は、特定のリリース列車が提供する価値に関して、主要な責任、統制、効力及びROI責務を持つ管理層の利害関係者の小さなグループ(通常3名~5名)である。ビジネス責任者は顧客関係、開発、ソリューションの品質、配置、運用、プロダクト管理やアーキテクチャーに管理責任を持つ。

ページの先頭に戻る

C

Capability
システム能力
システム能力はフィーチャーと似ているが、より高いレベルのソリューションの振る舞いを表し、実装には複数のARTが必要なことが多い。システム能力は、価値のストリームのバックログに維持され、各PIでソリューションの価値を納品できるよう、プログラムインクリメントに収まるサイズに調整される。

CapEx and OpEx
資本的支出と業務費
価値のストリームの予算には、資本的支出と業務費の両方の要素が含まれることがある。資本的支出は通常、ソリューションの構築に使う有形物的資産の購入や更新や修理、または他の資産に必要な資金である。場合によっては、特定の無形資産の開発に掛かる労力も資本の支出として扱われることがある。一般的に業務費は給与や諸経費、外注費、原料費、消耗品など、ソリューション開発作業に直接関連するものが含まれる。

Communities of Practice
専門技術コミュニティー
専門技術コミュニティー(CoP)は1つあるいは複数の関連領域内で実践的な知識を共有するミッションを持つ、チームメンバーやほかの専門家から構成され、プログラムやエンタープライズ範囲内で活動する非正式なグループである。

継続的なインテグレーション
Continuous Integration
継続的なインテグレーションはチームメンバーが頻繁に自分達の作業を統合し検証するプラクティスである。ソフトウェアの場合、これを日次的に、あるいは一日数回で実施できる。可能であれば、結合の問題や不具合を迅速に発見する自動化されたビルドやテスト環境を用いて、インテグレーションを確かめる。

Coordination
連携
価値のストリームの連携を参照する。

Core Values
中心的価値
SAFeはベクトル合わせ、作り込む品質、透明性とプログラムの実行という4つの中心的価値を反映し、大事にする。

Customer
顧客
顧客は価値のストリームの作業を享受する人である。彼は納品された価値の究極な判断者である。顧客は開発組織の内外にいるにも関わらず、開発する価値のストリームの不可欠の一部である。

ページの先頭に戻る

D

Develop on Cadence
開発はリズムに合わせる
重要なイベントは一定的な、予見性のあるリズムを用いて行う、すなわち日常的な開発活動を素早く同期しているリズムに基づくことは、システム開発に固有なバラツキを管理するために役に立つ。これはSAFeの基本な前提の1つである。ビッグピクチャー(全体像)から、同期された短い反復は素早いリズムで繰り返す一方、より大きなプログラムインクリメントはこれらの反復の結合からなるということは直接確認できる。

DevOps
DevOps
DevOpsは、アジャイル開発チームと、ソフトウェアやシステムを開発する、テストする、配置する及び維持する技術専門家間のコミュニケーション、協調及び密な協力関係を強化するための考え方であり、文化であり、技術プラクティスの集合である。

ページの先頭に戻る

E

Economic Framework
経済的枠組み
経済的枠組みは、使命と財務上の制約(プログラムポートフォリオから生じた予算上の考慮事項など)の両方を満たすよう全員を連携させる意思決定規則である。SAFeのリーン-アジャイルの第1原則は、経済的な視点で見ることであり、この原則によって、ソリューション開発を成功させるために経済が果たす主要な役割が明らかになる。

Enabler Capability
イネイブラーシステム能力
イネイブラーシステム能力は、価値のストリームレベルに現れ、その種類の作業として表現される。これは一種のシステム能力なので、恩恵の記述や受け入れ基準など同じ属性を共有し、1つのPIに収まるようスケジュールしなければならない。

Enabler Epic
イネイブラーエピック
イネイブラーエピックは、一種のエピックなので、エピック用に定義されたエピック価値記述の書式を使って記述される。複数の価値のストリームやPIにまたがることが多い。実装をサポートするための軽量のビジネス企画を含まなければならず、ポートフォリオカンバンシステムを通じて特定および追跡される。

Enabler Feature
イネイブラーフィーチャー
イネイブラーフィーチャーは、プログラムレベルに現れ、その種類の作業として表現される。これは一種のフィーチャーなので、恩恵の記述や受け入れ基準など同じ属性を共有し、1つのPIに収まるようスケジュールしなければならない。

Enabler Story
イネイブラーストーリー
イネイブラーストーリーは、一種のストーリーなので、反復に収まる必要がある。ユーザーの声の書式は必要ないかもしれないが、要求を明らかにしテストをしやすくするための受け入れ基準を持つ。

Enablers
イネイブラー
イネイブラーは、今後のソリューション能力をサポートするために必要な調査、アーキテクチャー及びインフラに関する開発活動である。イネイブラーは、SAFeの4つのレベルすべてに存在する。レベルに応じ、イネイブラーエピック、イネイブラーシステム能力、イネイブラーフィーチャー及びイネイブラーストーリーがある。

Enterprise
企業
企業は、SAFeポートフォリオを構成する一連の価値のストリームのため究極の戦略、信任、およびガバナンス権限を持つビジネスエンティティを表す。どのSAFeポートフォリオも、より大きな企業というコンテキストの中に存在する。このコンテキストから、ポートフォリオで対処しなければならないビジネス戦略が生まれる。また、企業は、すべてのポートフォリオに対する全体的なガバナンスのモデルを提供する。

Enterprise Architect
エンタープライズアーキテクト
エンタープライズアーキテクトは、ビジネス利害関係者、ソリューションとシステムアーキテクトと協力し、価値のストリームにわたる全体共通な技術実装を推進する。エンタープライズアーキテクトは、共通の技術的ビジョンに沿って、継続的なフィードバックに基づいて、適応的設計とエンジニアリングプラクティスを育み、プログラムとチームの協調を促進する。

Epic
エピック
エピックはポートフォリオの大きな狙いに向けて価値のストリームを導く役割をする。エピックは集約的投資であり、その影響は広範囲にわたる。そのため、コスト、影響、機会の明確化と分析が必要である。こういったことを考慮すると、エピックを実装する前に、軽量のビジネス企画を作成し財務承認を得る必要がある。エピックにはビジネスエピックとイネイブラーエピックの2種類があり、ポートフォリオ、価値のストリーム、プログラムの各レベルで使用される。

Epic Owners
エピックオーナー
エピックオーナーは、ポートフォリオカンバンシステムを通じてエピックを管理する。エピックオーナーはビジネス企画を作成し、承認された後に、影響されたリリース列車の主要な利害関係者と一緒に作業し、実装の実現を手伝う。

ページの先頭に戻る

F

Feature
フィーチャー
フィーチャーは、利害関係者のニーズに対応するためにシステムが提供するサービスである。各フィーチャーはアジャイルリリース列車によって開発される。フィーチャーは、プログラムバックログ内で保持され、それぞれのプログラムインクリメント(PI)で価値を納品できるよう、PIに収まるようにサイズが決められる。各フィーチャーには、恩恵に関する短い説明及び定義された受け入れ基準が含まれる。

ページの先頭に戻る

GHI

Implementing 123
実装 123
SAFeの実装 1-2-3 はSAFeを実装するための実績のある、成功したパターンである。このパターンは3つの基本ステップを説明する。 (1) 実装者やリーン-アジャイルチェンジエージェントにトレーニングを提供する (2) 経営者、マネジャー及びリーダーにトレーニングを提供する (3) チームにトレーニングを提供し、アジャイルリリース列車を発車する。

Innovation and Planning Iteration
イノベーションと計画策定反復
SAFeは、定期的にイノベーションと計画策定反復を提供し、様々な目的のために用いる。例えば、目標を達成するための見積もりバッファとする。検査と適応、PI計画策定活動のための専用時間、リズムに基づくイノベーションのための機会、継続的な教育のための時間、技術インフラ、障害対応及びバックログ手入れのための時間として使われる。

Inspect and Adapt
検査と適応
検査と適応(I&A)は各PIの終了時に行う定例的なイベントである。チームはこの時間を利用し、ソリューションをデモすることによって、フィードバックを得る。その後、振り返り、問題解決、改善活動の識別を行う。改善項目はすぐにPI計画に組み込まれる。

Iteration Execution
反復の実行
SAFeでは、反復は固定された2週間の時間枠(タイムボックス)である。この時間枠内で、アジャイルチームはチームバックロ項目に基づいて、定義、構築及びテスト作業を行い、その結果をシステムベースラインに組込む。

Iteration Goals
反復ゴール

反復ゴールは、チームとプロダクトオーナーが反復で達成することに合意したビジネスゴールと技術ゴールの概要のまとめたものである。SAFeでは、アジャイルリリース列車は自己組織化され、自己管理する複数のチームからなるチームであるため、 反復ゴールは効果的に連携するための不可欠のものである。

Iteration Planning
反復計画
反復計画はチームメンバー全員が次の反復を計画するためのイベントである。反復計画ミーティングのアウトプットは、反復に確約するストーリーと受け入れ基準からなる反復バックログ、反復ゴール、及び反復ゴールを達成するために必要な作業に関するチームの確約である。

Iteration Retrospective
反復振り返り
反復の振り返りは、各反復の終わりに開催する短いチームミーティングである。チームメンバーはプライベートで安全な環境に集まり、プラクティスの有効性を議論し、次の期間の改善を定義する。

Iterations
反復
反復(スクラムのスプリントと同じ意味)は厳格な時間枠(タイムボックス)である。時間枠内で、チームはテストされ、動作するシステムの形式で、インクリメンタルな価値を提供する。各反復は1つ標準的なパターンに従う。それは反復の計画、ゴールへの確約、実行、主要な利害関係者へのデモ、最後に、振り返りの開催というパターンである。振り返りでは、チームはパフォーマンスを向上させるために必要なアクションを分析し決定する。

ページの先頭に戻る

JKL

Lean-Agile Leaders
リーン-アジャイルリーダー
リーン-アジャイルリーダーは生涯の学習者、管理者、講師、コーチである。リーン-アジャイルリーダーはリーン、システム思考及びアジャイル開発の価値、原則及びプラクティスを理解し、示すことを介して、チームがより良いソフトウェアシステムを構築するために支援する。リーン-アジャイルリーダーはリーン・アジャイルリーダーシップの原則に従う。

Lean-Agile Mindset
リーン-アジャイルの考え方
アジャイル宣言とリーン思考を適用するで、リーン-アジャイルの考え方は概念から納品までの価値フローの理解と最適化にフォーカスするリーン-アジャイル開発への包括的なアプローチを提供する。SAFeのリーンの家は持続可能な最短リードタイムで価値の提供、人と文化への敬意及び容赦ない改善に基づく。リーン-アジャイルリーダーシップはすべてを支える土台となる。

ページの先頭に戻る

M

Metrics
メトリックス
SAFeにおける主要な測定尺度は動作するソリューションの客観的な測定値である。これは経験的に、各反復及びプログラムインクリメントの全体を通じ、そして終了の時点でのデモによって決定される。さらに、進捗を測定するために、チーム、プログラム及びポートフォリオのメトリックスのような、中間的及び長期的な測定尺度もある。

Milestones
マイルストーン
マイルストーンは、開発スケジュール上の特定の進捗ポイントを示すもので、プログラムの進捗とリスクを測定し監視するために非常に役に立つ。フェーズゲートのマイルストーンとは異なり、SAFeのマイルストーンはPI、計画された学習のポイント及び固定日付に基づく。

Model-Based Systems Engineering
モデルベースシステムエンジニアリング
モデルベースシステムエンジニアリング(MBSE)はソリューション開発における要求、設計、分析、検証活動に、モデリング及びモデリングツールを適用することである。MBSEは構築前に、あるいは構築中にシステムの特徴を学習するための費用効率の高い方法を提供し、大規模システム文書の複雑さとコストを管理するために役に立つ。

ページの先頭に戻る

N

Nonfunctional Requirements
非機能要求(NFR)
非機能要求はセキュリティー、信頼性、保守性、拡張性、使いやすさなどを含むシステムの特性を記述する。また、システムの設計に関する制約や制限でもある。

ページの先頭に戻る

OP

PI Planning
PI計画策定
PI計画策定は、アジャイルリリース列車の脈として機能し、SAFeの独創的な、リズムに基づく対面式の計画イベントである。SAFeに、このイベントは重要で、不可欠である。

Portfolio Backlog
ポートフォリオバックログ
ポートフォリオバックログはSAFeの最上位のバックログであり、ポートフォリオソリューションセットを作るために必要な今後のビジネスとイネイブラーエピックの保持場所として機能する。このセットは戦略テーマに取り組み、ビジネスの成功を促進するために必要な競争上の差別化要素及び業務の効率化を提供する。

Portfolio Business Epic
ポートフォリオビジネスエピック
ポートフォリオビジネスエピックはポートフォリオ内で発生する最大規模のビジネス向けの横断的取り組みについて記述する。

Portfolio Kanban
ポートフォリオカンバン
価値のストリームの行動コース及びそれを実現するためのアジャイルリリース列車に影響を及ぼすエピックを識別し、またエピックのフローを管理するために、ポートフォリオカンバンシステムは利用される。

Portfolio Level
ポートフォリオレベル
SAFeのポートフォリオレベルはSAFeの最上位レベルの関心事である。ここでプログラムは価値のストリームの線に沿ってエンタープライズビジネス戦略との整合がはかられる。より大きな企業では、複数のプログラムポートフォリオがあるかもしれない。それぞれに戦略と資金が決まっている。
SAFeのポートフォリオレベルは、SAFeの最上位の関心事である。ポートフォリオを基本構成要素として、リーン-アジャイルな企業が価値のフローを中心に組織化され、価値のフローをもたらす価値のストリームそれぞれによって戦略意図を達成するのに必要なシステムやソリューションが開発される。

Pre- and Post-PI Planning
PI計画前/後ミーティン
PI計画前/後ミーティンを行うことで、大規模な価値のストリーム内のARTやサプライヤーが次のPIのに関する整合の取れた計画を作成することができる。プログラムレベルのPI計画策定では実際の詳細な計画が行われ、PI計画前/後ミーティンはそれの最初と最後に行われる。

Product Management
プロダクト管理
プロダクト管理は顧客ニーズの識別に責任を持つ。プロダクト管理はARTのビジョンやロードマップ、価格、ライセンス、ROI及びプログラムバックログを管理し、フィーチャーの優先順位付及び受け入れ基準を通じ、PI目標とリリース内容を促進する。また、ベースラインにフィーチャーの受け入れを行う。

Product Owner
プロダクトオーナー
プロダクトオーナーはチームのメンバーであり、チームバックログのストーリーの定義や優先順位付けに責務を持つ。プロダクトオーナーは拡張されたプロダクト管理層/プロダクトオーナーチームの一員でもある。プログラムバックログ、ビジョン及びロードマップを理解し、貢献する。

Program Backlog
プログラムバックログ
プログラムバックログは、アジャイルリリース列車ソリューションを進めるために、今後予想されるすべての作業を唯一の決定的に保管する場所である。バックログは主に今後完成していくフィーチャーからなる。これらのフィーチャーによってビジネスのメリットを提供する。また、今後のアーキテクチャー滑走路を構築するために必要なイネイブラーフィーチャーも備えている。

Program Epics
プログラムエピック
プログラムエピックは、分析や軽量的なビジネス企画が必要となる十分大きな取組であり、、単一のアジャイルリリース列車で実装される。1つのPIに収まるように調整されたフィーチャーと異なり、プログラムエピックは複数のPIを通じ、実装される。プログラムエピックは価値のストリームやポートフォリオエピックの結果である場合があるし、ARTはより大きな労力と価値を表す取り組みを検討する時、局所で取り上げられる場合もある。

Program Increment
プログラムインクリメント(PI)
プログラムインクリメント(PI)は、リズムと同期によって、計画策定を促進し、WIPを制限し、フィードバックに値する価値を集約し、一貫したプログラムレベルの振り返りを確実に行うためのより大きな開発時間枠である。PIは複数の開発反復及び1つのイノベーションと計画策定反復からなる。PIは、スコープが大きいため、ポートフォリオレベルの検討事項やロードマップ作成について考えるときのリズムも提供する。

Program Kanban
プログラムカンバン
プログラムカンバンは、反復の境界に達する前に、フィーチャーが分析されるようにする。フィーチャーは適切に見積もりされ、優先順位が付けられ、受け入れテスト基準も確立される。

Program Level
プログラムレベル
の他のリソースが適用される。SAFeにおけるプログラムは長く存続するアジャイルリリース列車によって納品する。価値のストリームの一部を納品する。

Program PI Objectives
プログラムPI目標
各チームのPI目標を集約したものがプログラムのPI目標となる。プログラムPI目標はビジネス責任者によってビジネス価値が評価され、承認される。価値のストリームレベルのPI計画が必要な場合には、各プログラムのPI目標をまとめて集約し、それを価値のストリームのPI目標とする。

Program Portfolio Management
プログラムポートフォリオ管理
プログラムポートフォリオ管理(PPM)はエンタープライズポートフォリオにおける最上位の戦略と信頼された意思決定責任を持つ機能を表す。このPPM機能は、戦略と投資資金、プログラム管理、統制に責任を持つ。

ページの先頭に戻る

QR

Release
リリース
リーン-アジャイルのゴールは、価値のある、完全にテストの済んだ、動くソリューションのインクリメントを頻繁に納品することである。これは、絶え間ないリリースのストリームによって実現される。各リリースは、最終的な使用の有効性の検証と承認が済んでいて、適用を確実に成功させるために必要なドキュメントが付属したものである。

Release Any Time
随時リリースする
SAFeは関心事の分離を提供する。これによって、開発チームに、自分たちの環境における複雑性や激しい変化を管理するために必要なリズムと同期ツールが提供される一方、市場へのリリースは同期(PIの境界で行う)や非同期両方(随時行う)でできるようになる。

Release Management
リリース管理
リリース管理は、リリースの計画、管理及び統制を支援するための機能である。この機能は価値のストリームをビジネスゴールに導くための権限と責務を持つ。専用の個人が含まれている場合もあれば、ポートフォリオでリーン-アジャイルリーダーを果たす役割が含まれている場合もある。

Release Train Engineer
リリース列車エンジニア(RTE)
リリース列車エンジニアはアジャイルリリース列車プロセスと実行を促進する。障害をエスカレートし、リスクの管理、価値の納品及び継続的な改善を推進することを支援する。

Roadmap
ロードマップ
ロードマップは、価値のストリームとアジャイルリリース列車の納品物、及びマイルストンをスケジュール上に示して伝えるためのものである。ロードマップは確約された納品物が記載され、次のいくつかのPIでの予定納品物が可視化される。ロードマップは、ソリューション管理とプロダクト管理によって作成され、ビジョンや納品戦略が進化するのに合わせて更新される。

ページの先頭に戻る

S

SAFe Principles
SAFeの原則
SAFeは、9個不変の、リーンかつアジャイルな原則を基礎として作成されている。これらは、基礎となる教義であり、基本的真理かつ経済的土台であり、そこから導かれる役割やプラクティスによってSAFeは効果を発揮する。

Scrum Master
スクラムマスター
SAFeのスクラムマスターはアジャイルチームの奉仕型のリーダーとコーチである。プロセスの確実な実行、チームへのスクラム、XP及びSAFeの教育、障害の取り除く、及び高性能なチームダイナミクスのために継続的なフロー、そして絶え間ない改善のための環境の促進はスクラムマスターの主要な責務である。

ScrumXP
スクラムXP

ScrumXPは、SAFeの環境で、クロスファンクション、自己組織化なチームが利用する軽量で規律のある生産的なプロセスである。1つのスクラムXPチームは5人から9人で構成され、可能な限り同席させる。スクラムXPチームはスクラムプロジェクト管理プラクティスやXPから取り入れられたプラクティスを利用し、価値のフローを可視化し、測定する。

Set-Based Design
セットベース設計
セットベース設計は、開発サイクルの中でもっと長い期間、要求や設計の複数の選択肢を残すというプラクティスである。経験に基づくデータを使用して、。創発な知識に基づく最終的な設計の選択肢を絞り込む。

Shared Services
共有サービス
共有サービスは、ある特定のアジャイルリリース列車にフルタイムで専属することができないが、アジャイルリリース列車や価値のストリームの成功に欠かせない専門性のある役割である。セキュリティー専門家、情報アーキテクト、DBA、ドキュメント作成者、品質保証、IT運用担当者などを含む。

Solution
ソリューション
ソリューションは、最終的にお金を出す購買者に納品される最終プロダクトの場合も、組織内の運用の価値のストリームを助ける一連のシステムの場合もある。

Solution Architect/Engineering
ソリューションアーキテクト/エンジニアリング
SAFeのソリューションアーキテクト/エンジニアリングはソリューションのアーキテクチャーおよびエンジニアリング設計全体の技術面に責任を持つ、個人またはチームを表す。
価値のストリームやアジャイルリリース列車を共通な技術とアーキテクチャービジョンに足並みを揃えることに支援する。

Solution Context
ソリューションコンテキスト
ソリューションコンテキストでは、対象のソリューションが置かれる環境の重要な側面と、使用、インストール、運用、及びソリューション自身へのサポートに対する影響を明らかにする。ソリューションコンテキストは開発の優先順位や、インフラー、テスト環境、ソリューションのシステム能力、フィーチャー、非機能要求に影響があるし、DevOpsや同様の配置に関する考慮事項に重要な点を決める。

Solution Demo
ソリューションデモ
ソリューションデモは、価値のストリームのPIサイクルにおける頂点のイベントである。このイベントで、複数のアジャイルリリース列車のすべての開発作業(サプライヤーの貢献分も含む)の結果が、統合され、評価され、顧客やその他の利害関係者に対して明らかにされる。このデモによって、ソリューションに関する客観的な評価リズム及び利害関係者や顧客のフィードバックを得られるリズムが提供される。

Solution Intent
ソリューション意図
ソリューションの意図は、システム構築者が構築するソリューションに関する知識、また、どのように構築するかに関する技術情報を格納、管理、伝達するためのリポジトリを表す。ソリューション意図には、ソリューションの現状や意図された変更に関する仕様、設計、テストが含まれる。ソリューション意図は、ドキュメント、スプレッドシート、ホワイトボードセッションからフォーマルな要求やモデリングツールまで、さまざまな形で実現できる

Solution Management
ソリューション管理
ソリューション管理は価値のストリームの内容に関する権限者であり、価値のストリームバックログの開発及び優先順位付けに責任を持つ。この役割は顧客と協力し、顧客のニーズを理解したり、ビジョンやロードマップを作成したり、要求を定義したり、価値のストリームカンバンを通じて作業を指導する。

Spanning Palette
共有パレット
共有パレットは成果物そのものではない。むしろ、SAFeの各レベルに適用できる様々な役割と成果物を含んでいる。共有パレットは特定のコンテキストにおけるSAFeの実装に使われている。詳細について、「プログラムレベル」をご参照。

Stories
ストーリー
アジャイル開発において、ストーリーはシステムの振る舞いを定義するための主要な成果物である。ストーリーは要件ではない。ストーリーは通常ユーザーの視点で語られ、ユーザーの言葉で書かれた望ましい小さな機能に関する短いシンプルな記述である。各ストーリーは、実装のため意図的に縦で小さく切り分けられたシステム機能であり、高度なインクリメンタルな実装をサポートする。

Strategic Themes
戦略テーマ
戦略テーマは具体的な箇条書きのビジネス目標であり、これによって、エンタープライズビジネス戦略にSAFeのポートフォリオが結び付けられる。戦略テーマは、ポートフォリオ内の意思決定のビジネスコンテキストとなり、経済的枠組みや価値のストリーム及びARTへの投資に影響を及ぼす。また、予算、ポートフォリオ、ソリューション、プログラムバックログについて意思決定するときのインプットにもなる。

Supplier
サプライヤー
サプライヤーは、リーン-アジャイルな組織が顧客に価値を納品するために、役に立つコンポーネントやサブシステムの開発および納品を行う。サプライヤーは、他とは異なる明確に優秀なスキルやソリューションを持っていて、その技術の専門家である。早く経済的に納品するためには、彼らに依頼すると高い効果を得られる可能性がある。

System Architect/Engineering
システムアーキテクト/エンジニアリング
システムアーキテクト/エンジニアリングは、開発中のソリューションの共通の技術およびアーキテクチャーのビジョンに向けて、足並みを揃える。この役割はシステムとサブシステムの定義に参加し、技術面の想定事項を検証し、代替案を評価する。ソリューションの技術面やアーキテクチャー面を広い視野で見たビューを提供し、伝え、進化させることで、ソリューション開発をサポートする。

System Demo
システムデモ
システムデモは利害関係者からフィードバックを得るため、また、ART全体システムを評価するための重要な仕組みである。システムデモは、各反復の終了時に行い、アジャイルリリース列車におけるすべてのチームによって提供された最も近い反復内で統合され集約された新しいフィーチャーの姿を提供する。システムデモは、プログラムインクリメント内の現在のシステムレベルの進捗を事実に基づいて測定する手段となる。

System Team
システムチーム
システムチームはARTや価値のストリーム、あるいは両方における特殊のアジャイルチームである。システムチームの責務は、継続的インテグレーション、テスト自動化、各アジャイルチームからのコードの結合、エンドツーエンドのソリューションテストを含む、アジャイル開発環境インフラの利用と構築に支援を提供することである。システムチームはシステムデモ時のソリューションデモに参加する。

ページの先頭に戻る

T

Team Backlog
チームバックログ
チームバックログは、チームがシステムの一部を進めるために行う必要があるすべてのものを表す。チームバックログに、プログラムバックログから由来するユーザーストーリーとイネイブラーストーリー、チームの特定のコンテキストから発生したストーリーが含まれる。

Team Demo
チームデモ
チームデモは各反復の終了時で行う。プロダクトオーナー、他のチームメンバー及び利害関係者に動作するソフトウェアを示すことにより、チームの進捗を測定すると同時に、フィードバックをもらう。デモ時、チームが各ストーリー、スパイク、リファクタリング作業、新しいNFRのすべてをデモする。

Team Kanban
チームカンバン
チームカンバンは、ワークフローの可視化、仕掛かり作業制限の確立、スループットの測定、継続的なプロセス改善を利用し、価値のフローを促進する方法である。カンバンはシステムチームや、DevOps、保守チームなどに対し有用な手法である。また、対処が中心の仕事、矢継ぎ早の作業、急速に変化する優先順位、計画してもその価値は低いことなどの場合、この選択につながる。

Team Level
チームレベル
チームレベルは、アジャイルリリース列車の構成要素であるアジャイルチームの組織、成果物、役割、活動、およびプロセスモデルを説明する。

Team PI Objectives
チームPI目標
チームPI目標は、今後のPIのためにアジャイルチームが達成しようとする具体的なビジネスと技術ゴールの要約である。チームPI目標を用いて、ビジネスと技術的意図への理解を検証したり、連携はプロセスや戦術的な問題ではなく、結果に焦点を当ているかどうかを確認する。チームPI目標は、コミュニケーション、ベクトル合わせおよび可視性を向上させるよう記述をまとめる。

Test-First
テストファースト
テストファーストは、コードやコンポーネントの開発に先立ってテスト自体を開発し、システムを少しずつ増やして開発し、テストするプラクティスである。そうすることによって、テストは、システムが構築される前に意図されたシステムの振る舞いを詳述し、よりよく定義する。それによって品質を向上させるのに役立つ。

ページの先頭に戻る

U

User Experience
ユーザーエクスペリエンス(UX)
アジャイルチームはユーザー向けの要素を含むソリューションの実装を担うが、UX設計者は、より大規模なソリューションのコンポーネントやシステムにわたって、一貫したユーザーエクスペリエンスを支援する。

ページの先頭に戻る

V

Value Stream Backlog
価値のストリームのバックログ
価値のストリームのバックログはソリューションに関する予想される今後のすべての作業の最終的なリポジトリである。このバックログは、複数のARTにまたがることができる今後のシステム能力、やアーキテクチャー滑走路を構築するため、また学習を促進するためのイネイブラーからなる。

Value Stream Coordination
価値のストリームの連携
価値のストリームの連携はポートフォリオにおける価値のストリーム間の依存関係を管理するためのガイダンスを提供する。

Value Stream Engineer
価値のストリームエンジニア
価値のストリームエンジニアは価値のストリームのプロセスと実行を促進する。この役割は障害のエスカレーション、リスクの管理、価値の納品と継続的な改善をサポートする。

Value Stream Epics
価値のストリームエピック
価値のストリームエピックは1つの価値のストリームに生じる大きな、分析と軽量のビジネス企画(エピックをご参照)が必要となる取組である。1つのプログラムインクリメントにフィットするように定義したシステム能力と異なり、価値のストリームエピックは複数のPIにわたって開発できる。価値のストリームエピックはポートフォリオエピックの結果である可能性があり、価値のストリームがより大きな取組を計画時に、局所的に生じる可能性もある。

Value Stream Kanban
価値のストリームカンバン
PIの境界に達する前に、価値のストリームのエピックとシステム能力は適切に優先順位が付けられ、高い信頼性の実装のために受け入れ基準が確立される。価値のストリームカンバンはPIの境界に達する前に、価値のストリームのエピックとシステム能力が議論され、分析されるように、役に立つ。

Value Stream Level
価値のストリームレベル
価値のストリームレベルは、大規模で複雑なソリューション(通常は複数のARTやサプライヤーの協力が必要となるようなソリューション)を構築する場合を対象としている。このレベルは、大規模で、多くの専門分野にまたがるサイバーフィジカルシステムを構築しようとして、非常に大きなシステム上の課題に直面した企業が利用する。

Value Stream PI Objectives
価値のストリームのPI目標
PI計画後ミーティングで、各ARTの目標が価値のストリームレベルでさらに集約され、価値のストリームの目標になる。SAFeでは、価値のストリームのPI目標はトップレベルのPI目標である。それを用いて、利害関係者は次のPIで価値のストリームが何を納品できるかが期待できる。

Value Streams
価値のストリーム
価値のストリームは、価値を理解し整理し納品するためのSAFeの主要構成要素である。それぞれの価値のストリームは、顧客に価値のフローを継続的に提供するために企業が使用する、長期にわたる一連のステップである。アジャイルリリース列車は価値のストリームを実現する。

Vision
ビジョン
ビジョンとはこれから開発するソリューションの今後のビューを記述したもので、そこには顧客や利害関係者のニーズと、そのニーズに対処するためのフィーチャーやシステム能力の案が示される。開発するソリューションの大局的なコンテキストの概要や目的も示される。ビジョンは「共通パレット」に表れ、SAFeの各レベルで適用できる。

ページの先頭に戻る

W

Weighted Shortest Job First
重みづけされた最短作業から着手(WSJF)
重みづけされた最短作業から着手(WSJF)はプロダクト開発フローに基づく作業の優先順位付けのための経済的なモデルである。WSJFは遅延のコストを作業の期間で割ると計算される。SAFeでは、「作業」はARTによる開発するエピック、フィーチャー及びシステム能力である。遅延のコストには、 1) ユーザー-ビジネス価値、 2) 時間価値、及び 3) リスクの低減/機会をもたらす価値という3要素が含まれる。

ページの先頭に戻る

XYZ

なし

ページの先頭に戻る

Last Update: 2 December 2015