より早く価値を提供することに重点を置いて、 アジャイル製品管理 顧客からのフィードバックへの迅速な対応を最優先すべきです。にもかかわらず、多くの組織は依然として煩雑な変更管理手法に依存しており、これがリリース配信のボトルネックにつながる可能性があります。手作業による変更レビューなどの旧来の手法がリードタイムやサイクルタイムに影響を与えると、製品と顧客体験の両方に悪影響を及ぼします。

プロダクトマネージャーが変更承認時間の短縮といった取り組みに関与することは稀ですが、実際には変更のデリバリーを迅速化することはバックログ管理と同じくらい重要です。そのため、変更承認チームはプロダクトマネージャーに働きかけ、ユーザーストーリーからデプロイメントまでのプロセスを迅速化するよう働きかけ、変更承認時間について相互に責任を持ち、歩み寄りを図る必要があります。

変更承認の迅速化は、データ分析と自動化といったテクノロジーによって実現できます。人工知能（AI）と機械学習（ML）による分析は変更リスクをモデル化できるため、チームは真のリスク脅威となる変更にのみ時間を割くことができます。自動化により、特に標準的な変更モデルに適合する低リスクの変更は自動的に承認されます。このプロセスにより、リリース頻度が向上し、顧客満足度が向上します。また、次のリリースで有益な変更をすぐに展開できる機会も得られます。

変更管理は価値提供の重要なポイントです

ソフトウェアデリバリーパイプラインは、リリースが変更承認を待っている間、劇的に遅くなる可能性があります。しかし、多くの組織は変更承認ポリシーに慎重な姿勢を崩しておらず、ほぼすべてのケースで変更諮問委員会（CAB）による手動承認を必須としています。

変更承認は開発から運用への引き継ぎを意味するため、遅延が発生することもあります。開発と運用の組織が高度にサイロ化されている場合、新しいリリースのデプロイメント承認を待つ間にキューが形成される可能性があります。この関係性を考慮すると、変更承認の遅延は、顧客が次のリリースを待っているという状況だけでなく、開発チームが進行中の作業に役立てるフィードバックの遅れを示している可能性もあることを指摘しておく価値があります。

その scrum.org チームは、このフィードバックの遅れがもたらす弊害を強調し、市場投入までの時間を短縮することよりも、短い「学習時間」、つまり迅速なフィードバックループを追求することを概念的に検討するようチームに促しています。その違いは微妙ですが、企業文化に反映されます。変更がリリースされると、ビジネスは顧客やユーザーからのフィードバックループに基づいて、変更の影響について学習を開始できます。

変更管理チームには重要な役割があります。リリースが品質、パフォーマンス、セキュリティの最低基準を満たしていることを確認するための門番であり、これらを総括して全体的な価値提供を実現します。チームは、以下の2つの点を組み込むことで、引き継ぎの問題を解決できます。

1. 変更レビューサイクルタイムの所有権を双方から促進するために必要なプロセス改善を実施する DevOps
2. リスク管理をより迅速かつ有益なものにするために分析テクノロジーに投資する

アジャイル製品管理には変更管理も含まれるべきである

アジャイルプロダクトマネージャーは既に多くの仕事を抱えています。それでもなお、必要な変更がタイムリーに市場に届くよう、全体のサイクルタイムを管理する責任を負わなければなりません。

遅れをとる「注文を受ける」役割から、主導的で積極的な役割へと移行するために、アジャイルの専門家は、変更管理と製品管理が柔軟になるようにプロセス改善の機会を探すことを提案しています。 ティム・クリーシーProsci の最高イノベーション責任者である は、次のような効果的な変更管理の実践について説明しています。

• アプローチ — 変更管理アプローチは、アジャイル プロセスのフェーズに合わせて調整する必要があり、どのアクティビティが価値を生み出すかに関して選択的である必要があります。
• 資料 — 変更管理リソースのニーズはアジャイル開発の取り組みごとに異なるため、特定のフェーズにおける従業員の影響に基づいて方向転換する準備ができていなければなりません。
• プロジェクト管理との統合 — 変更管理チームとプロジェクト チームは、より早い段階で、より高いレベルのコミュニケーションとコラボレーションを伴って統合する必要があります。

プロセスをマッピングし、変更管理を改善できる箇所を特定します。 ニーナ・スカルニチ （PMP、パブリシス・シアトル）は、手続き上の問題がプロセスを過度に複雑化し、ボトルネックを引き起こす傾向があると述べています。「そうなった場合、状況を改善する最も簡単な方法は、時間を無駄にしている箇所を特定し、業務プロセスを合理化し、ワークフローを改善する機会を見つけることです。」

より小さなバッチサイズを目指します。 DevOpsグループ 変化についての思考実験を行った 展開頻度 四半期ごと、月ごと、そして日ごとへと、バッチサイズは変化します。「バッチサイズが小さいほど、テストや導入が容易になり、失敗してもロールバックが容易になります。そのため、導入頻度の増加とバッチサイズの縮小により、変更失敗率、リードタイム、MTTRが低下し、可用性が向上することが期待できます。」

より頻繁なデプロイメントは、より低頻度のサイクルでの同じ変更よりも、全体としてより多くの価値をもたらすことを認識します。 DevOpsグループ 「各デプロイメントは、お客様が実際に何を求め、何を必要としているかを知る機会であるため、無駄な労力も削減できると期待しています。多くのチームは、お客様が実際には必要としておらず、決して使用しない機能の構築に時間を費やしています（一部の推定によると、提供される機能の50%以上はお客様に何の価値ももたらさず、無駄になっています）。より頻繁に、より小さな単位でデプロイメントを行うことで、最終的に価値をもたらさない大量の作業を一括処理することを避けています。」

アジャイルな製品管理には、顧客からのフィードバックを今後の機能計画に反映させる必要性など、多くの優先事項がありますが、製品管理では変更のデリバリー時間を高い水準に保つことも重要です。言い換えれば、変更管理の改善は、価値提供の加速と顧客体験の向上にとって、容易に達成できる成果であることが多いのです。 DevOps チーム全体の継続性。

デジタルトランスフォーメーションを推進するデータドリブンな統合戦略の構築方法を知りたいですか？ウェビナーをご覧ください。 驚くべきビジネス成果の鍵はデータです.