＊本コラムは、技術評論社「Software Design」2021年4月号に寄稿したコラムを掲載しています。

あなたのアジャイル開発チーム（スクラムチーム）は、どんな人が関わっていますか？　スクラム開発であれば、まず、スクラムマスター、開発チーム、そしてプロダクトオーナーがいると思います。では、ほかにはどんな人が関わっていますか？　たとえば、あなたの職場の上司だったり、アジャイル開発チームに投資をしてくれる人だったり、プロダクトを使うエンドユーザーだったりと、それはチームによってさまざまです（図1）。そのような利害関係者（以下、ステークホルダ）は、あなたの開発チームに（大小あれど）影響を与えるため、どのように付き合っていくかが重要です。今回は、ステークホルダと上手に付き合っていくための方法を紹介します。

図1　スクラムチームとステークホルダ

アジャイルにおけるステークホルダの重要性は高まりつつある

スクラムガイドの歴史をさかのぼって考えてみましょう。今日、2020年までにスクラムガイドは5回の更新をはさんでいますが、年々ステークホルダへの言及が増加し、「スクラムガイド2020^注1」では12回の言及があります。
「スクラムガイド2010^注2」では、とくにスプリントレビューとスプリントキャンセルという2つのイベントについてステークホルダとの関わり方を述べています。

これら以外ではスクラムにおいてステークホルダとの関わり方については明記されていませんでした。
では、最新版のスクラムガイド2020ではどうでしょうか。まず、大きく変更があった部分が下記の2つです。

●スクラムチームとステークホルダ

1つめは、「スクラムチームとステークホルダ」といったスクラムチームとステークホルダが主語になった文脈が4回出てくることです。これらはスクラムチームとステークホルダが一緒に働かなければならないことを示しています。

●プロダクトオーナーの説得

2つめは、「ステークホルダがプロダクトバックログを変更したいときは、プロダクトオーナーを説得する」とあることです。つまり、ステークホルダがどう動くべきかまで記載されるようになりました。今まではスクラムチームが主語になり、ステークホルダに訴求することがメインで記載されていました。しかしこれからはステークホルダに訴えかけるだけでなく、ステークホルダもスクラムにのっとって協力して働かなければならないことを示しています。
なお、IPAのアジャイル開発の進め方の指針の中でもスクラムチームとステークホルダが定義されています^注3。

◆　◆　◆

では、ここからは実際のプロジェクトにおけるステークホルダとの付き合い方について考えてみます。
ここで、プロジェクトのフェーズを大きく2つに分けることにします。プロジェクトの立ち上げからプロダクトバックログの作成までを企画立案フェーズとし、プロダクトバックログを消化していく段階からを開発フェーズとします。

企画立案フェーズ

ステークホルダを探そう

プロジェクト初期では、プロダクトバックログを作成するためにステークホルダから情報収集を行うことが多いと思います。
アジャイル開発では継続的にステークホルダと付き合っていく必要があるため、各ステークホルダをできるだけ細かく定義しておくとスクラム開発フェーズでの交渉がやりやすくなります。
なお、ご存じの方はいるかもしれませんが、インセプションデッキの1項目であり、一緒に協力して働く人たちを定義する手法の1つである「ご近所さんを探せ」を使うことも良いでしょう。

ステークホルダを定義しよう

では実際にアジャイル開発でのステークホルダの定義はどのように実施すればよいのでしょうか。重要なポイントとしては3つあります。ステークホルダが所属する組織の目的と役割、好み、所有知識量です。それぞれをまとめた例を表1に挙げました。

●所属する組織での目的と役割

ステークホルダは自らの所属組織（自社、自部署、自チームなど）で何かしらの役割を担っていると思います。それらを把握することでプロダクトバックログアイテムの作成やリファインメント^注4を効率的に進めることができます。役割や目的を把握していない状態では、ステークホルダの意図していることを整理したり、それらを可視化してプロダクトバックログアイテムを詳細まで書ききったりすることは難しいです。
そのため、スクラムチームはステークホルダの所属する組織（部署など）のミッションがわかる資料を取り寄せると良いです。たとえば、組織の今年度の取り組みがわかる資料などでも良いと思います。そうすることで、スクラムチームからの提案や、認識の齟齬が少ないプロダクトバックログアイテムを作成できます。

●好み

ステークホルダの好みが論理的なのか、情緒的なのか、バランスを把握しておくと良いです。よく言われることではありますが、正論だけでは人は動きません。たとえば論理的な正しさを求めている場合は、数値的なデータを多く提示したり、納得感を求めている場合は、両者の気持ちに寄り添った抽象的な言い分を用意したりするほうがうまくいくことがあります。

●所有知識量

スプリントを進めている最中はスクラムチームはいくつもの課題解決や判断をするために、ステークホルダの力を借りることが多いと思います。その際にはステークホルダの知識量を把握しておくことが重要です。なぜなら、既知の説明を受けることはステークホルダにとって無駄な時間になってしまいますし、もし事前準備として資料を作成していればそれらにかかった時間も無駄になってしまいます。
そのため、一度にすべてを把握することは難しいですが、日々の会話の節々からステークホルダを観察することで判断していきましょう。とくに、知識量についてはビジネス面とシステム面を軸にして整理したり、特定の分野について詳しいことなどを把握したりしておくと良いでしょう。

表1　ステークホルダの定義

スクラム開発フェーズ

ステークホルダとコラボレーションしよう

では実際に開発フェーズでのステークホルダとの付き合い方はどのようなものになるのでしょうか。
スプリント中はステークホルダと常に何らかの形で関わりがあるのですが、その中でも、とくにスクラムの主要なイベントであるスプリントプランニングとスプリントレビューは、「提供するサービス」そのものを決める場ですので、ステークホルダはより強い興味・関心を持って参加してきます。
それぞれのイベントを軸に考えていきたいと思います。

スプリントプランニング

●スプリントプランニングとは

スクラムガイド2020には、「スプリントプランニングはスプリントの起点であり、スプリントで実施する作業の計画を立てます。」とあります。またステークホルダに言及する部分には、「スクラムチームはステークホルダに伝達するスプリントゴールを定義する。」とあります。

●スプリントプランニングの進め方

スプリントプランニングではスプリントで実行する作業の計画を立てることになります。作業の計画を立てるにあたってステークホルダとの対話で発生する事象について、どのように対応をするか考えてみます。スプリントプランニングではステークホルダとさまざまなやりとりが発生すると思いますが、この節では「ステークホルダからバックログの優先順位の変更をお願いされる」という筆者がよく立ち会ったケースとその対処法を一例として紹介します。
ステークホルダは自らが利益を得るバックログアイテムが最優先であることを望みます。しかし、各ステークホルダの優先順位は必ずしも一致しません。またすべてのプロダクトバックログアイテムを最優先で実施することもできないため、必ず優先順位の低いプロダクトバックログアイテムができてしまいます。
スクラムチームは多くの場合、ステークホルダにプロジェクトの説明やそれに関わるヒアリングを実施していると思います。そのため、ステークホルダはプロジェクトに対しての期待値が高くなっていることがあり、ほかのプロダクトバックログアイテムが自分のものよりも優先度が高く実施される計画になっているのはよく思われないことが多いです。
ステークホルダはプロダクトオーナーが決定した判断を覆すことはできませんが、その後関係性を悪化させないためのいくつかの手法を紹介します。

●期待値の調整

最優先で要求を実施される（期待値が高い）想定をされていることが問題と考えます。ヒアリングをうかがった時点で、簡単にできます、などと発言していないでしょうか。確かにその場は良い印象を与えられますが、結果的にそのような受け答えからすぐに実現されるだろうと思われていることもあります。
また何も言わない場合でも基本的には自分の都合の良い方向で誰しもが考えてしまうものです。そのような認識の相違を生まないため、常に現状の事実を伝えると良いです。その場合には、とくに要望の技術的な実現性や、スケジュールを伝えておくことが良いと思います。

●優先順位の説明

多くの場合ステークホルダの担当するプロダクトバックログアイテムの優先順位が高い場合には、どのスプリントで実施するかの結論さえ伝えられれば「なぜ」はそこまで求められません。
しかし優先順位が低い場合には説明が不十分のままでは不信感を抱かれてしまう可能性がありますし、協力的に進められないことがあると思います。その場合は、各ステークホルダが所属する組織のスケジュールや、それぞれのバックログアイテムのROIを算出して比較した結果で優先順位を定めていることを説明すると良いでしょう。

●今後の計画について

今後のスプリントの計画について共有をすることです。ここまで、事前の期待値の調整方法と、現状の優先順位の説明方法を考えてきました。最後にスプリントの将来の見通しについてしっかりと伝えると良いです。
いつ、どのようなものができあがるのかを共有しましょう。ここで注意してほしいのは、「プロダクトバックログアイテムの優先順位が低いために何も検討していません」と伝えないということです。ステークホルダを不安にさせないように、「スプリントXで実施する予定です。まだ先のことなので細かいことは決まっていませんが、何月までには実施する想定で検討しています」などと伝えてあげることが良いでしょう。

スプリントレビュー

●スプリントレビューとは

スクラムガイドでは、スプリントレビューの目的について、下記のように記載があります。

では、実際に限られた時間の中でスプリントレビューを効果的に進めるには、ステークホルダとどのような関わり方をするとうまくいくのでしょうか。

●スプリントレビューの招待

スプリントレビューに誰を招待したら良いか迷うことがあると思います。スプリントによって招待すべきステークホルダは変わることがあります。招待すべきステークホルダを招待できていない場合は、ステークホルダにプロダクトの状態を共有できず、検証してもらうこともできません。招待が不要なステークホルダを招待している場合は、ステークホルダの貴重な時間を奪ってしまうことになります。また本来不要な議論に時間を費やしてしまうかもしれません。
では招待すべき、すべきでないステークホルダはどのように判断すれば良いのでしょう。招待すべきステークホルダを判断するためには、スプリントレビューで何を確認してもらいたいかを明確にすることが大切です。そのためにはプロダクトバックログを見れば自ずと招待すべきステークホルダがわかるような記載がされていると良いでしょう。
エピック（関連するプロダクトバックログの集合）を活用することも良い方法です。エピック単位で関係するステークホルダを定義すれば招待すべきステークホルダを決めることは容易になるでしょう。

スプリントレビューの進め方

ではスプリントレビューの場でステークホルダとどう関わるべきか、ポイントをいくつか紹介しましょう。

●ステークホルダにとっての価値は何か

スプリントレビューではステークホルダからプロダクトについての新しい課題やアイデアのフィードバックを引き出すことが重要です。しかしそのフィードバックについてスクラムチームと意見が対立するときがあります。なぜこういったことが起こるのでしょう。ステークホルダが重要視している価値は何でしょうか。スクラムチームが重要視している価値は何でしょうか。ここにギャップがないか注目してみると良いでしょう。
たとえば、スクラムチームは開発効率を考えた「コスト」を、ステークホルダはビジネスの「価値」を基準にして意見を言う傾向があります。スクラムチームからするとコストがかかり過ぎると感じるような内容でも、ステークホルダからしてみればそれだけのコストをかけても価値がある内容かもしれません。
自分が当たり前だと思っている前提を相手は認識していますか？逆のパターンもあるかもしれません。1つずつ確認して意見をすり合わせていくことが大切です。

●できます≠すぐできます

ステークホルダからのフィードバックはありがたいものです。開発チームは技術的に実現できるかをその場で考え「できます」とその場で答えることもあるかもしれません。ただし注意が必要です。スクラムチームからするとスプリントレビューにおけるフィードバックはプロダクトバックログに追加後、リファインメントされて優先順位を決めていくと考えていますが、ステークホルダは自分のアイデアをすぐに実現してくれると思っている可能性があります。「できます」は「すぐできます」ではないことを伝えることが大切です。

●ユーザーにとっての価値を伝える

スプリントレビューが機能開発の完了報告や進捗状況の報告の場になってはいけません。ユーザーが新しくできるようになったことは何か（＝ユーザーにとっての価値）を伝えることが大切です^注5。
ステークホルダは機能ができた、できない、だけを聞いてもそれがプロダクトにとって必要な機能なのかを判断することは困難です。どんな価値があるかを理解してもらって初めて有用なフィードバックを引き出すことができるでしょう。

●変化を許容する

ステークホルダのフィードバックをスクラムチームが拒絶してしまう場合があります。たとえば、スクラムチームが苦労して作り上げてきた機能に対して、この機能はないほうがユーザーにとってユーザビリティが良い、という意見が出た場合などです。
アジャイルは変化に対応することが大切です。本当にプロダクトに対する良い改善であるならばスクラムチームは歓迎すべきです。ただし計画の変更も同時に検討することが重要です。

●DoneかUndoneかは明確に

スクラムチームにはプロダクトバックログを受け入れるか否かを判断する基準として用いられる完成の定義があります。完成の定義を満たしている成果物をDone、満たしていない成果物をUndoneと呼ぶチームも多いです。スプリントレビューではDoneの成果物をレビューすべきですが、プロダクトの状態によってはUndoneの成果物がスプリントレビューの場で披露されることもあるでしょう。
この場合は、ステークホルダにUndoneであることをきちんと説明しましょう。ステークホルダによっては完成しているものと思ってリリースできると勘違いしてしまう場合もあるかもしれません。もちろんスクラムチームはUndoneの成果物をリリースするべきではありません。

おわりに

アジャイル開発を進めるにあたって必要になるステークホルダとの関わり方についてこれまで述べてきました。今回述べた例はほんの一例で、実際には各プロジェクト、スクラムチームごとに異なる状況でいろいろなことが発生すると思います。そのようなステークホルダとの関わり方についての判断を求められた場合、本記事が少しでも参考になれば幸いです。