はじめに
現在、safeフレームワークを使用したアジャイル開発を実施しているため、safeについて深く理解するためまとめる。
safeでのスクラムの導入
スクラムの定義（Scrum Theory）
スクラムは複雑な問題に対して適応するソリューションを通じて、人々、チーム、組織が価値を見出すのに役立つフレームワーク
スクラムマスターの役割
スクラムではスクラムマスターが以下を促進する
- プロダクトオーナーは複雑な問題に対する作業をプロダクトバックログに発注
- スクラムチームはスプリント中に作業を価値に変換
- スクラムチームとその関係者は結果を検査し、次のスプリントへ向けて調整する
- 上記を繰り返す
スクラム理論-3つの柱
透明性（Transparency）
作業は作業を行う人だけではなく、作業を受け取る人にも見える必要がある。透明性の低い成果物は価値を低下させ、リスクを増大させる決定に繋がる。
透明のため検査が可能になる、透明性のない検査は誤解を招き、無駄が生じる。
検査（Inspection）
成果物と進捗は問題検出を目的として、頻繁に検査する必要がある。
検査により、適応が可能になる。適応を伴わない検査は無意味。
（スクラムイベントは変化を起こすように設計されている）
適応（Adaptation）
作業に問題が発生し、許容範囲外の事例が発生した場合、また結果として得られた製品が許容できない場合は、調整する必要がある。（有識者に質問する、優先順位を変更するなど）さらなるずれを最小限に抑えるため、迅速に調整する
関係者に権限や自己管理能力がない場合、適応は困難になる。スクラムチームは検査を通じて学んだ瞬間適応することが求められる。
スクラムの価値観
開発が成功するかどうかは、人々が以下5つの価値観を実践できるようになるかで決まる
- コミットメント（Commitment）
- 集中力（Focus）
- 寛容さ（Openness）
- 敬意（Respect）
- 勇気（Courage）
スクラムチームは目標を達成し、サポートし合うことに尽力する。彼らの焦点は目標に向けて最善の進捗を上げるためのスプリント作業である。
スクラムチームメンバーは自立した人間としてお互いを尊重し、互いに尊敬している。
スクラムチームメンバーは正しいことを行い、困難な問題に取り組む勇気を持っている。
これらの価値観がイベントや成果物の作成に向けて働くことにより具体化されると、透明性、検査、適応のスクラムの柱が生き、信頼を構築する。
イテレーション（Iterations）
safeにおける開発期間の単位。1イテレーションは2週間が一般的
価値を生み出すだけでなく、開発されたものを改良する期間
詳細
リードタイムを短くすることがリーンアジャイル開発の重要な目標です
リーンアジャイル開発：無駄を省き、顧客へ優れた商品を提供するために小さなサイクルで検証と改善を繰り返す開発
アジャイルチームは計画（plan）、実行（do）、確認（check）、調整（adjust）のPDCAサイクルをできるだけ早く実行する。
PDCAのサイクルには以下のイテレーションイベントがある。
- 計画：イテレーションプランニング（Iteration Planning）
- 実行：イテレーションイクスキューション（Iteration Execution）...dsuなど
- 確認：イテレーションレビュー（Iteration review）
- 調整（振り返り）：イテレーションレトロスペクティブ（Iteration Retrospective）
イテレーションの計画
PDCAの計画ステップ、これによりチームメンバーがが共通の目標を持つ。
このイベントではチームメンバが協力して、チームキャパシティに基づいて、次のイテレーション中にどれだけのチームバックログを提供できるか決定する
イテレーションの実行
作業を行うプロセス、イテレーション中にチームは新しい機能を構築しテストすることで、「実行」を完了する
作業が完了すると、プロダクトオーナーへ作業デモすることで、イテレーションレビューに到達し、成果を披露できる
DSU（Daily Stand-up）はイテレーション内の小さなPDCAサイクル、毎日チームメンバーで集まり進捗状況と問題・課題について共有する
また、次イテレーションに先立って、バックログを整理することもある
1イテレーションでPDCAを回す。
イテレーションレビュー
チェックを行うプロセス、成果物をプロダクトオーナーや関係者にデモし、フィードバックを受ける。
イテレーションレビューでは、進捗状況を評価し、次イテレーションに先立って調整を行う機会が提供される。
その後、チームは次イテレーション計画に向けて最終的なバックログの調整を行う
ART内のすべてのチームへデモを行う
プロセスを改善する
前回の改善点をレビューする、今イテレーションであがった課題は原因分析し、次回改善ポイントとする。
この定期的な振り返りは、各チームの絶え間ない改善（safe house of leanの柱の一つ）が確実に行われる機会。
検査と適応（I&A）
PIの最後で実施する重要なイベント、ソリューションの現在の状態をトレインによって実証、評価する。その後チームはバックログ項目を振り返り評価する
safeにはSAFe House of Leanの4つの柱の1つとして、「絶え間ない改善」が含まれている。改善の機会はイテレーションレトロスペクティブなどで発生している。
SAFe House of Leanの4つの柱
- 人間と文化の尊重(Respect for People and Culture)
- フロー(Flow)
- イノベーション(Innovation)
- 絶え間ない改善(Relentless Improvement)
I$AイベントにはART関係者全員が参加する、PI計画のプログラムバックログに入る一連の改善バックログ項目が作成される。
I&Aイベント
- PIシステムデモ（PI System Demo）
- 定量的および定性的な測定（Quantitative and qualitative measurement）
- 振り返りと問題解決のワークショップ（Retrospective and problem-solving workshop）
参加者
- アジャイルチーム（Agile teams ）
- リリーストレインエンジニア（Release Train Engineer (RTE) ）
- ソリューションアーキテクト（Solution Architects）
- 製品管理者、経営者、その他関係者（Product Management, Business Owners）
PIシステムデモ（PI System Demo）
ARTがPIで開発した全機能を示すこと
1時間ほどのタイムボックスで実施する
また、ビジネスオーナーは各アジャイルチームのPI目標に対する、実際のビジネス価値をスコアリングする（計画値を満点として評価する）
定量的および定性的な測定（Quantitative and qualitative measurement）
PIシステムデモでの評価をもとにチームでレビューしデータと傾向について話し合う、RTEとソリューションアーキテクトは情報を分析し潜在的な問題を特定し、結果をARTに提示しやすくする責任を負う
振り返りと問題解決のワークショップ（Retrospective and problem-solving workshop）
問題解決ワークショップで対処したい問題を特定するために、チームは30分ほどで振り返りを実施する、
問題解決ワークショップでは振り返りで出た問題に対処するために開かれる。約2時間ほど。
問題解決ワークショップの各プロセス
- 解決すべき問題に同意する（Agree on the Problem(s) to Solve）
- 「よく述べられた問題は半分解決された問題である。-チャールズケタリング」、ここでチームは対処したい問題を自ら選択しましたが、問題の詳細には同意していない可能性がある。数分間かけて問題を明確にする、何を、どこで、いつ、影響を強調しながら
- 根本原因分析の実行（Perform Root Cause Analysis）
- 5つのなぜ、特性要因図で原因を洗い出す、チームで洗い出された原因をブレインストーミングし問題解決に寄与する原因を特定する。さらに特定された原因に対してなぜなぜ分析をおこない真の原因を特定する。真の原因を出す
- 最大の根本原因を特定する（Identify the Biggest Root Cause）
- 一人5票を持ち、各原因の中から問題解決につながる原因に投票する
- 新しい問題を再度説明する（Restate the New Problem）
- 最も多く票を集めた原因を選択し、それを問題として明確に言い直すことでチームの問題に対する理解を深める。
- ソリューションのブレインストーミング（Brainstorm Solutions）
- 解決策をブレインストーミングする（15^30分）
- 改善バックログ項目の作成（Create Improvement Backlog Items）
- 出された解決策から投票し、最大3つまで、その後のPI計画イベントに反映させるストーリーとする