プロダクト開発を通じて企業のビジョンを達成するには

先ほど述べた、開発チームが企業のビジョンやプロダクトのゴールを達成することへの意識が希薄であるという状態は一体なぜ起きるのだろうか。そして、どんな問題を引き起こすのだろうか。

アジャイル開発に移行したばかりのチームは、直近のスプリントバックログに書かれている要求を実現することに注力しがちである。早くリリースする、小さくリリースするという特徴のみを取り上げると、直近のスプリントバックログを消化していくことに意識が向きやすいからだ。

もちろん、それは間違いではない。開発者の責務は、スクラムガイドに定義されているとおり、要求を最大限実現することだからだ。しかし、プロダクトというものは目先のプロダクトバックログに注目するだけでなく、最終的なプロダクトゴールを意識しなければ全体を見失ってしまう。

忙しいチームメンバーは、どうしても開発実装という行為に目が向きがちで、プロダクトゴールへの意識がだんだん薄れてしまうのは、みなさんもよく目にする光景ではないだろうか。あるいは、遠く感じられるゴールよりも、実装のイメージが湧きやすい直近のプロダクトバックログに注目してしまうこともあるかもしれない。 

しかし、プロダクトゴールを意識することなく次以降のスプリントの話をしても、方向性が間違っていることは大いにある。行きつく未来を意識しないので、プロダクトバックログの優先順位基準がわからないためだ。

プロダクトの方向性を定め、優先順位基準を決めて共有するのはプロダクトオーナーの役割だ。しかし現実には、社内的なステークホルダーとの力関係から、その役割を全うしづらいことも優先順位基準が不明確になる要因の一つだ。プロダクトオーナーとステークホルダーの間でプロダクトゴールと優先順位基準が共有できていない限り、ステークホルダーからのフィードバックは意図したものにはならないし、開発チームにとっては理不尽な要求に聞こえるだろう。

それだけではなく、最終的な方針なしにふりかえりなどのセレモニーを行っても、改善する方向性がずれてしまっていたら元も子もない。本質的な改善につながらないだろう。開発チームがよかれと思って実施した施策が見当違いだったり、なんでもかんでも機能を盛り込んでしまい結局ユーザーに使われなかったりと、価値提供につながらない活動を行う可能性がある。

では、これまで見てきた陥穽に陥らないようにするにはどうしたらよいだろうか。押さえておかなければいけないことは3つある。

まず、組織のゴール、プロダクトゴール、届ける顧客価値。チームのタスクはこの順番にブレイクダウンされ、統一した繋がりを保っている必要がある。チームのタスクが完成すれば、定められた顧客価値を実現できるという具合だ。

次に、組織のゴールは進化するので、プロダクトゴール、顧客価値、チームのプロダクトバックログ（ストーリー）、タスクはそれに追従して見直さないといけないということである。一定期間で見直すことを決めておくとよいだろう。

最後に、チームとマネジメント層の間で、どこまでがお互いの権限の範囲なのか線引きをきちんとすること。線引きをしたうえで組織のゴールと乖離がないように、チームが計画をマネジメント層に説明することはもちろん必要だ。

では、一つずつ見ていこう。

最近では、プロダクト開発を通じて企業・組織のミッション・ビジョンの実現を行うことが多くなってきている。そのためには当然、プロダクトゴールは、組織のゴールを実現するように設定するべきである。

プロダクトゴールを設定したら、エピック、フィーチャーと分割していくことになる。ここで注意すべきなのは、プロダクトゴール、エピック、フィーチャー、そしてプロダクトバックログに一連のつながりをもたせることだ。こうすることでプロダクトゴールを意識したプロダクトバックログができる。プロダクトバックログを実現することで、フィーチャー、エピック、最終的にはプロダクトゴールが満たされるように分割していくことが望ましい。

分割したプロダクトバックログだが、ずっとそのままの優先順位で放置しておいてはいけない。

それはエピック、フィーチャーも同様だ。なぜなら、アジャイル開発においては自組織を取り巻く環境の変化やユーザーからのフィードバックに応じて優先順位をつけなおし、エピックやフィーチャーを進化させていかなければならないからだ。

エピックやフィーチャーが進化したとき、当然プロダクトバックログも以前のままではいけない。内容の見直しと優先順位のつけなおしが必須だ。組織のゴールやプロダクトゴールが進化したときも同様で、プロダクトバックログを追従させていかなくてはならない。

えてして、ここの整合は取りづらいことが多いので、あらかじめ一定期間での見直しを行うよう合意しておくと進めやすいだろう。

マネジメント層がチームのやることにどこまで関与するのかをあらかじめ決めておき、権限を明確に移譲することは、意思決定を早くしリリース頻度を落とさないために重要である。

例えば、プロダクトバックログのメンテナンスやスプリント中のタスクをチームに任せ、マネジメント層はチームが正しいことを行うと信じるならば、お互いにとって仕事を進めやすくなるだろう。もちろん、チームが組織やプロダクトのゴールを理解していなければならないため、定期的に同期をとることを忘れてはならない。

ここで、Microsoft社の事例を紹介したい。一般的に、大きな組織は動きが鈍いといわれる。つまり、意思決定が遅くなり、リリーススピードも落ちてしまう傾向にあるということだ。しかし、Microsoftは明確にそれを否定する。彼らは、大きな組織でありながら、35のフィーチャーチームで早い意思決定をし、約3週間おきに一度のリリースを実現しているためだ。各チームは顧客との関係を保ち、自分たちのプロダクトバックログをメンテナンスする。ではどのようにして組織の目標から外れることなく高頻度なリリースを実現しているのだろうか。

Microsoftでは、Epic、Feature、Story、Taskの4つの階層を定義している。Epicは組織の目標、Featureはリリース単位、Storyは顧客の価値の単位、Taskは作業を意味する。Epicは複数のFeatureに、1つのFeatureは複数のStoryに、といった形で漏れやダブりなくブレイクダウンされ、双方向に紐づけがされている。このため、Epicに紐づくFeatureがすべて完成した際には、Epicが実現されることになる。このようにしてEpicからTaskまでの明確なつながりが保たれるのだ。

Epic、Feature、Story、Taskのそれぞれを一定期間で更新することも必要だ。Epicは18か月、Featureは6ヶ月、Storyは3ヶ月、Taskは3週間（スプリントの期間に相当）ごとにそれぞれ見直しがされる。

Epic、Featureはマネジメント層が管理し、StoryとTaskはチームが管理すると定めており、明確に権限をわけている。そのかわり、チームは決定したStory（3ヶ月の計画）の内容をマネジメント層に説明し、組織目標とのずれがないことを確認するFeature chatというセレモニーを採用している。

権限移譲をし、円滑にプロジェクトを進めるために一番大事なのは信頼関係である。マネジメント層は、チームが実施していることは正しいと信じて任せる。チームは品質の高いプロダクトを継続的に出荷しつづけることで、マネジメント層の信頼にこたえるのだ。

参考文献：https://learn.microsoft.com/en-us/devops/plan/scaling-agile

本コラムでは、企業のビジョンやプロダクトのゴールを意識しながら高頻度で継続的なリリースをかなえるための事例を紹介した。

スタートアップでは企業のビジョンを考えた人がプロダクト開発に近いところで携わるのでブレにくいだけであり、大企業では実践が難しいと思われがちだが、プロダクトバックログを組織の目標に紐づけつつ更新していくスキームを採用することは一つの解決策になりうるだろう。

Microsoft社の事例ではEpicの見直し頻度は18ヶ月ごとと紹介したが、企業の年度計画にあわせ、Epicの見直し頻度を1年とするのが現実的だろう。