ステークホルダーとの間に不要な摩擦をうまないために知ること

不確実性の高いプロダクト開発をしていくとき、スクラムを始めとしたアジャイル開発で短いイテレーションを繰り返し、学びながら不確実性に対処していくことが重要であることを多くの人が認識している。
しかし、いざスクラムを導入するとなったとき、プロジェクトの進行をスクラムチームに任せ、外部から進捗の管理をしないという話になると、「チームの生産性はそれで落ちないのか」と聞かれることがある。
確かに、従来の管理者視点では、いつまでに何を作るかが重要であり、リリース期限を守るためにいかにチームの生産性を上げるかが重要だった。
しかし、スクラムでは「機能は継続的改善が必要で完成しない」とか「完璧な工数見積もりなど時間の無駄になる」などと言われたりする。
ステークホルダー (利害関係者) が、これを聞いて不安になるのも分かる。要するに「いつできるかどうかわからないけど任せてほしい」と言っているように聞こえるのだ。
ときには、「チームに任せるとチームメンバーで談合してさぼってしまうのではないか」という不安を漏らす人まで出てくる次第である。
その結果、スクラムチームへ外部から過干渉する人が出てきて、本来のスクラムが目指すべき自己組織化や自己管理とは程遠いチームとなってしまう。
こうなってしまっては、最悪の場合スクラムなんてあまり意味なかったということにもなりかねない。
ステークホルダーとの間に生まれる摩擦は、スクラムを導入はしてみたが、実際に運用しようとすると難しいと思われる要因の一つだ。

外部からの圧力で意思決定を捻じ曲げない

プロダクト開発では、優先度の決める意思決定が誰かを明確にすることは重要だ。そして、スクラムにおける優先度の意思決定者はプロダクトオーナーである。
ところが、スクラムチームへの外部からの過干渉により、意思決定者が不明確になってしまうことがある。特に、チーム外にいる権力を持つステークホルダーの意見によって開発内容が変更されるという話はよく聞く。
スクラムではプロダクトオーナーの意思決定をあくまでも尊重する必要があり、決して意思決定に権力の影響を与えてはいけない。権力が絡むと職階が上の人がかならず勝ってしまう。
権力が絡む意思決定では、意思決定者としてのプロダクトオーナーが機能しなくなり、まさに「船頭多くして船山に登る」という状況になる。
もしプロダクトオーナーの意思決定が信用できないというのであれば、それはプロダクトオーナーするべき人じゃない人がやっていることなので、優先度の意思決定できる人をプロダクトオーナーにする必要がある。
ちなみに、プロダクトオーナーが意思決定をするからと言って、プロダクトオーナーに何も言ってはいけないということではない。
もしビジネス上必要な開発があるのなら、プロダクトオーナーが優先度判断をするときに参考になる材料出して説得すればいいということだ。

どんな権力者であれ、優先度を変更させるためにはプロダクトオーナーを説得する必要がある。

透明性と合意形成が重要

ステークホルダーにとっては、スクラムよりもウォーターフォールのほうが明確で理解しやすいかもしれない。
しかし、ウォータフォールで不確実性の高いプロダクトを開発することは時間もお金もかかるし、失敗したときのリスクが高い。
どんなに賢い人がウォータフォール型でプロダクトを設計したとしても、成功させるプロダクトを作ることは難しい。
では、ステークホルダーの理解を無視してスクラムを導入してよいかというとそういうわけではない。
ステークホルダーには拒否権があり、ステークホルダーの納得のいかない開発を推し進めてはいけない。スクラムチームはステークホルダーの理解を得て、ステークホルダーの協力を得ながら開発しないといけない。
そして、ステークホルダーの理解を得るために重要なものとして、透明性の確保と合意形成がある。
透明性はスクラムを支える三本柱 (透明性・検査・適応) の一つであり、ステークホルダーの理解を得るために重要なものだ。
人は見えないものに対して不安を感じるので、何が起きているのかを見えるようにする、つまり透明性を高めることで、チーム外の人でも理解できるようにするということである。
しかし、透明性はただ見えるようにするだけでは不十分である。
「透明性」を「公開している」ことと勘違いしている人がよくいる。
やっていることをただ公開していることは透明性を確保しているとは言えない。情報は確かにあるが、情報を探すのに労力がかかるのであれば意味がないということである。
相手が知りたい情報がいつでもすぐ確認できる状況になっていることが透明性では重要である。つまり、情報を持つ人と知りたい人の間で情報共有の合意形成が必要になる。
スクラムでは、3つの作成物と3つのコミットメントなども合意形成された一つの透明性の形といえる。

透明性とは情報を知りたい人がすぐに知れる環境があること。

期限通りに機能をリリースすることは重要ではない

いつまでにどんな機能を出したいという話が出てきたときに常に意識して起きたいのは、プロダクト開発ではアウトプットではなくアウトカムがもっとも重視されるべきということである。
機能を期限通りにリリース、つまりアウトプットを出すことで達成感は得られる。
しかし、プロダクトで顧客に価値を提供してアウトカムが得られてこそ機能を開発したことに意味が出る。
たくさんアウトプットしてもアウトカムが出なければ意味がない。逆にアウトプットが少なくてもアウトカムがあればいいのだ。
そして、アウトカムが実際に得られたかを知るためには、事前に期待されるアウトカムを定義し、アウトカムを測定する仕組みを実装していなければならない。
この機能があったらいいという理由だけで開発着手してはいけない。
この機能があったら、アウトカムとしてこの数値が伸びて、顧客に価値が提供できていたことがわかる、ここまで考えてから開発に着手する。
ただ、アウトカムの重要性は分かっているが、アウトカムの測定方法と実装した機能が直接的に結びつかないという話もよく聞く。
例えば、売上などはその最たるものだ。セールス部隊の働きなどいろいろな要因が絡むため、売上の上昇と機能が直接的につながることはあまりない。DAUやMAUを増やすという指標も同じだ。
アウトカムを測定するための指標が変化する要因が複数考えられるとき、思考停止して複数の要因を無視してそのままアウトカムにしたり、アウトカムの測定を諦めたりする人がいる。
しかし、本当に提供できる価値が見えているのであれば、ターゲットは明確であり、アウトカムの測定方法ももっと具体的になるはずである。
つまり、曖昧な指標などになっているのであれば、ターゲットが見えていないということ、言い換えると価値の深堀りができていないといえる。
この状況で開発を進めることは、闇雲に開発しているのと同じで、目隠しで的当てをしているようなものだ。いつかは当たるかもしれない、でも当たるまで投げ続けられる体力があるとは限らない。
プロダクト開発に関わる人全員が、どんなアウトカムが得られるのかを常に意識できるようにしておくことが重要である。

何回リリースするかは問題ではない、何を得られるかが問題である。

最後に

スクラムでは、「みんな良い仕事するために集まっている」という考えが基本としてある。
スクラムチームを管理しないと生産性が下がってしまうという不安がある人は、生産性が下がるのは「管理をしていないから」ではなく、「与える仕事や仕事の与え方自体が悪いのから」と考える必要がある。
そして、もう一つ重要なことは、管理することと方向性を示すことは別と知ることだ。
プロダクトのビジョン実現のためにプロダクトの向かう方向性を示さなければならない。
チーム全員がプロダクトビジョンに共感し自発的に動けるようになるまで、とことんなぜそれをやるのかを考え抜き、対話していく必要がある。