ソフトウェア以外の製品に対するアジャイル
アジャイルはソフトウェア開発の世界で最も一般的に知られていますが、多くの組織は、ソフトウェア以外のプロジェクトにも有益なフレームワークを見つけます。以下に、ソフトウェア以外の環境でアジャイルを使用した実際の例を示します。
財務:
Mike Palazzolo, President of Fintentional, applies an Agile approach to his fee-only financial planning practice. “As a former software engineer, I practiced using some of the Agile predecessors known as evolutionary and spiral software development. I am applying an Agile approach to my fee-only financial planning practice.
一度きりの財務計画を作成することに対する批判の一つは、クライアントに提供される頃には時代遅れになることが多いということです。私は継続的なリテーナーベースの財務計画サービスを提供しており、クライアントと協力し、年間を通して計画とコーチングを提供しています。1 年を「スプリント」に分割して、各スプリントに対応できる以上の取り組みを行わないようにしています。これにより、状況の変化に合わせて、年間のコースを変更することもできます。私はプロセスを促進するために、「財務計画プロジェクト管理ソフトウェア」などのテクノロジーを使用しています。
マーケティング:
Alexander Kariagin, Partner Marketing Director with CloudBerry Lab, uses Agile to manage marketing projects. “We plan and manage two-week Sprints and apply story points, backlog, review, kickoff, and a daily 30-minute stand-up meeting. This Agile approach allows us to spread tasks among ten marketing team members. Each team member feels responsible and informed about what is going on.”
Monica Georgieff, Head of Marketing for Kanbanize, adopted a Lean Agile approach to campaign management. “We map our campaign activity on a Kanban board. We discovered that it works wonders for our efficiency and output. This has helped us deliver quick, high-quality work. For example, an idea today could be a reality next week because we are much more flexible to market changes. It turns out that software methodologies work for marketing, too!”
Christine Bottagaro, CMO at Rogue Wave Software, has also relied on Kanban to execute marketing projects. “We tried a number of Agile ceremonies, but Kanban worked best. It assumes constant work, with no end dates, and allows for real time prioritization. This suits our work pace, ongoing ideas, work in progress, and completed projects. We rely on an online card system to track work across teams and to manage our backlog.”
アジャイル フレームワークが導入する反復型アプローチは、ソフトウェア製品と非ソフトウェア製品の両方に適用できることが証明されています。認定スクラム レーナーの Hubert Smits 氏によると、「アジャイル/スクラムは経験主義的思考に基づいています。複雑な問題は、最初に完了した最も重要な情報を提供するステップを持つ小さなステップで解決するのが最善です」ということです。
上記の例で説明したように、多くのビジネス「製品」は、これらの小さな反復ステップのメリットを得ることができます。
アジャイル製品管理の役割
製品管理の意図は、製品開発と緊密に連携し、市場調査、顧客フィードバック、開発能力に基づいて製品の方向性と要件を管理することです。残念ながら、製品マネージャーは、最も市場性の高い製品を構築するために顧客や市場のインフルエンサーとやり取りするのではなく、ソフトウェア リリースに関連するプロジェクト管理タスクに追われていることがよくあります。
アジャイル開発の世界では、製品マネージャーを戦術的で技術的な活動 (従来のウォーターフォール環境ではその活動に時間を使いがちになる) から、市場と対話する外部向けの役割に移行するのに役立つ役割が追加されています。しかし、製品マネージャーが製品所有者の役割を引き受けることは珍しくありません。これは、以下で読む通り、最も経験豊富な製品マネージャーにとっても重圧が非常に大きくなる可能性があります。
アジャイル製品マネージャー: アジャイル製品マネージャーの目標は、顧客や会社のリーダーシップと協力して製品の方向性を定義することです。製品マネージャーは、顧客の真の声を代弁する責任があります。顧客の問題を完全に理解する最善の方法は、顧客と話し合い、現場を訪問し、日々のビジネス生活を体験し、スタッフに問いかけることです。これを行う中で、製品マネージャーは顧客の苦労を最初から把握し、問題点を軽減する機能と機能を定義できます。顧客との直接的な現場での交流がなければ、顧客の苦労やニーズを完全に理解することは不可能です。
アジャイル製品マネージャーになるための認定プログラムは、実用的製品管理の実用的マーケティングによって提供されます。
製品マネージャーが直面する課題: 他の組織の役割と同様に、製品マネージャーも障害に直面します。最も一般的なハードルは、要件を定義することです。すべてのチーム (開発、サポート、専門サービス、セールスなど) は、製品に含めるべき機能について意見を持っています。幸い、顧客とのやりとり中に具体的な情報が収集されるため、製品マネージャーはユーザー ストーリーと製品ロードマップを実際のデータで裏付けることができます。
さらに、製品マネージャーの役割は、ビジネス目標に合わせて製品ロードマップを定義するなどの戦略的な活動から、販売、マーケティング、製品サポートで行われる戦術的な活動まで多岐にわたります。残念ながら、製品マネージャーは、技術的で戦術的な活動に苦戦し、戦略的な活動の時間がなくなってしまうことがよくあります。製品マネージャーは、セールス チームには製品のデモを要求され、マーケティング チームには販促使用の作成に引き込まれ、開発チームにはプロジェクトの管理に使われるのです。製品に関する知識があるため、製品マネージャーはこれらすべての活動に最適なリソースですが、戦略と戦術のバランスが不可欠です。
アジャイル製品所有者: アジャイル環境の製品所有者は、開発チームと協力して、ユーザーのストーリー、製品ビジョン、仕様を明確にし、バックログを管理し、ビジネスに対する製品の価値を最大化します。製品所有者は、ビジネスの意図を開発チームに伝え、彼らが業務を求められている理由を明確に理解できるようにします。製品所有者は、技術/開発の理解とビジネス インテリジェンスのバランスが非常に優れています。ビジネスと顧客のニーズを理解し、ビジネス チームとコミュニケーションを取り、技術的な活動を調整して優れた製品を提供するという全体像を確認できます。製品所有者は通常、ソフトウェア開発の基本を理解した有能なコミュニケーターであり、顧客の問題に対処する必要性を理解しています。製品所有者は、製品所有者になる前にビジネス アナリストの地位に就くのが一般的です。
認定コースは、認定スクラム製品所有者 (CSPO) になるため、Scrum Alliance により提供されています。この認定資格は、製品所有者としてのキャリアを促進するだけではなく、製品所有者の役割の範囲を明確に理解する上でも重要です。
製品所有者によるミス: 製品所有者の役割を取り入れることには、アジャイル環境で大きなメリットがあります。しかし、この役割がミスをすることもあります。成功するには、製品所有者は次の手順を実行する必要があります。
- 決断力を持つ
- チームの信頼を得る
- 製品ビジョンを理解する
- チームに姿を見せ、チームが利用できるようにする
- 変化に適応可能 (アジャイル) になる
- チームのマイクロマネジメントを避ける
アジャイル組織内で製品管理と製品所有者の両方の役割を採用することで、一人の人間に負担をかけることなく、責任のバランスを取るのに役立ちます。顧客との交流、ニーズの伝達、ユーザー ストーリーの構築、日々のスクラムへの参加、販売の有効化、サポートのトレーニング、製品のデモ、機能の文書化、要件の明確化などを実行すると考えてみましょう。これは、最も有能な製品マネージャーにとっても荷が重い仕事になる可能性があります。製品マネージャーと製品所有者が職務を共有し、製品マネージャーが単独で行う際に直面する過負荷を避けることができれば、組織全体にメリットがあります。
下の図は、製品マネージャーと製品所有者が行う一般的な活動の一部を定義しています。
製品要件文書
製品要件文書 (PRD) がアジャイルの世界で使用されているのかどうかという質問がよくあります。実際、従来の PRD はアジャイル環境では使用されていません。その代わりとなるのがユーザー ストーリー (機能に関するペルソナ ベースのニーズの説明) です。これらのユーザー ストーリーは顧客価値に焦点を当て、アジャイル チームが詳細に関する共同作業を行い、プロジェクトのイテレーションを計画するために使用されます。
アジャイルの役割に関するその他の一般的な誤解
スクラム マスター vs. 製品マネージャー vs. 製品所有者: 最も人気のあるアジャイル手法のスクラムでは、スクラム マスターが主にスクラム チームのモチベーションと集中力を維持し、気が散るのを防ぎ、ガイダンスと指導を提供します。製品所有者の主な責任は、バックログの管理、ユーザー ストーリーの伝達、リリース日と機能の決定です。最後に、製品マネージャーは、顧客の問題点に基づいてユーザー ストーリーを定義し、市場調査を行い、製品ロードマップを作成する責任があります。
考慮すべきその他の重要な役割:
- 機能所有者: 機能所有者は、製品全体ではなく、特定の機能にのみ責任があるという点で、製品所有者とは異なります。
- 開発チーム: 開発チームはすべての技術開発タスクを実行します。チームは、分析、設計、コードの記述、テスト、技術的なコミュニケーションを担当します。
アジャイル組織はすべて異なるため、役割もさまざまです。ウォーターフォールからアジャイルに移行する組織が、単に製品マネージャーを製品所有者に移行させるのは珍しくありません。しかし、これは、優れた製品マネージャーが優れた製品所有者になる、またはその逆を意味するものではありません。むしろ、ある組織に適した手法は、別の組織で有効な場合もあれば、有効ではない場合もあります。これは組織や製品の進捗に応じた責任についても同様です。結果として、顧客に高品質の製品を提供することに関連するすべての活動に十分な注意を払うために、追加の役割が定義されます。
製品ロードマップとバックログ
製品ロードマップは、製品の意図する進捗を示すために開発され、維持されます。これらのロードマップは、製品が成長計画を持っていることを見込み客に示すために、販売ライフサイクル中に頻繁に参照されます。ロードマップは通常、製品マネージャーによって管理されます。
製品バックログには、スプリントまたはユーザー ストーリーを提供するために完了する作業が含まれます。バックログは開発チームの活動を推進するために使用され、通常は製品所有者によって管理されます。
製品ロードマップとバックログは、製品の各段階 (バックログ) を提供するために必要とされる、戦術的な詳細を含む長期計画 (ロードマップ) を示すという形で共同で作用します。
Smartsheet はアジャイル製品マネージャーと製品所有者にとって不可欠なツールです
ニーズに合わせ変化に対応できるようデザインされた、柔軟性のあるプラットフォームで、チームの能力を最大限に引き出しましょう。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。