最近PdM活動を行っている中で、アジャイル開発における対峙する不確実性の捉え方を変える事によって、生産性が大きく向上しそうな体験を感じることができたので、言語化してみる。

想定読者

• リリースした後にCSから「これじゃ使えない」と言われる

• 振り返りの場で顧客価値について言及されない

• リリースしたのに使ってくれているのかどうかわからない

• 本当に使ってくれるかわからない のに長期間開発してリリースしている

• 施策を計画的にリリースすることに重きを置いている

アジャイル開発は不確実性を受け入れる開発

改めて12の原則を照らし合わせてみると本質が書いてあるなぁと思う。

とある通り、変化することを受け入れるというマインドセットそのものがアジャイル開発における重要なピースの一つになっている。

ではどういった変化を受け入れるべきなのか。「エンジニアリング組織論への招待」では3つの不確実性がソフトウェア開発に含まれているという

• 目的不確実性

  • 何を作るのかという不確実性

• 方法不確実性

  • どうやって作るのかという不確実性

• 通信不確実性

  • コミュニケーション上発生する不確実性

本書においてはアジャイル開発では「目的不確実性と方法不確実性の両方に対して段階的にアプローチする」と書いてあるが、これをしっかり回すことは難しい。

通常の開発では方法不確実性、通信不確実性に目が行きがち

なぜ不確実性を減らしていくことが難しいのか。
それはそれぞれの不確実性が対象領域がかなり異なっているためだと思っている。

• 目的不確実性

  • ビジネス的な成長と顧客理解の合わさったところ

• 方法不確実性

  • スケジュールの予測、ベロシティーの安定化

• 通信不確実性

  • チーム内における情報の非対称性

また、それぞれの不確実性の対処方法も異なる。

• 目的不確実性

  • 顧客や対象者の課題検証、解決策検証。プロダクトのビジョンやゴール設定などのプロダクトマネジメントの実施

• 方法不確実性

  • 多面的な見積もりやベロシティ計測による予測可能性の向上

• 通信不確実性

  • KPTなどでの振り返りによる情報非対称性の解消や、心理的安全性の確保

開発チームという枠組みの中での改善を行おうとすると、影響を及ぼせるのは方法不確実性と通信不確実性のみとなってしまうので、振り返りの場で上がってくるイシューも、方法不確実性や通信不確実性の話題に終止してしまう。

目的不確実性はマーケット環境や顧客理解、ビジネスサイドの動き方といった事業部全体を包含しなければ不確実性の探索が難しいため、目的不確実性をコントロール下に置くことに対して難しさを感じたり、はなから無理だと決めつけて管轄外と捉えるようになってしまう。

対処方法も対象領域も異なりすぎるため、短絡的に考えれば開発チームに閉じる方法不確実性と通信不確実性のみを扱うのが気が楽である。ただ、目的不確実性もコントロール下に置ければ難易度は上がるものの、開発チームにとっても事業部ひいては顧客にとっても良いのではないかと思っている。

目的不確実性をコントロール下に置くとどうなるか

ざっと下記のメリットがあると思う。

• どこまで作れば完成なのかがアウトカムベースでわかる。

• まずは最低限何を作ればいいかがわかる

• 顧客への価値提供を身にしみて感じることができる

• 最も重要なことに取り組んでいる事がわかる。

• BizとDev双方協力して顧客への価値提供していることを一体感を持って感じることができる

アジャイル開発においては、目的不確実性と方法不確実性を双方合わせて解消していくプロセスを踏んでいくことになるが、これを前提に開発することを念頭に入れることで、初手は完璧に作りすぎる必要がないことを理解出来、最もコアで不確実性の高いものを先に作る重要性を理解できる。
そうすると、「これって無駄に作りすぎているんじゃないか」とか、「このまま長期で開発していくとダレてしまう」などの不要な懸念や不安を感じることなく、目的に向かって迷いなく進んでいくことができる。
また、全てを完璧に作る必要がないため、思考のリソース的にも「考えを遅延させて重要なことだけを考えればいい」状態が継続されるため、常に重要なことに取り組んでいるという状態を作ることができる。

目的不確実性をコントロール下に置かない、計画駆動な開発スタイルでいったほうが確かに「モノが作れるスピード」は段違いで早くなるかもしれない。ただそれが顧客に価値を届けられたかどうかをベースに考えていないことで、「これってなんのために作ったんだろう」という、作った後に大きな手戻りが発生する危険をはらみ、中長期的にモチベーションが下がっていってしまう。

小さく答え合わせをしながら、手段と目的の不確実性を言ったり来たりして、少し遠回りしてでも最終的には遠くの地点にたどり着ける。そういった感覚を得られるのではないかと思っている。

目的不確実性の解消には技術が必要

ではどうやれば目的不確実性をコントロール下におけるのか。それはプログラミングスキルとは違った「技術」が求められる。

• ビジネス理解

• プロダクトゴール、プロダクトビジョンの策定

• 仮設構築力

• 開発外の部署の理解

• 顧客理解

• アセットとPLの次元の違い

  • https://note.com/kotamat/n/n83af86c6fb11 を参照

• etc..

これらはプロダクトマネジメントに求められるスキルであり、非常に多岐に渡る。これらを一朝一夕で身につけるのは非常に難しい。自分自身もまだこのスキルを身につけられたと自信を持って言える状態ではないし、果たしてそんな日が来るのだろうかという不安を覚えるくらい、非常に幅広く、深いスキルが要求される。

ただ、全てが完璧にならないとコントロール下に置けないかというとそうではないと思う。目的不確実性は0 or 100の世界ではなく、次第に少しずつ下げていくものであるため、そこに5でも10でも関与し下げられる事ができるのであれば、それだけでもとても価値のあることであるし、上記に述べたメリットを享受することができる。

目的不確実性を下げるために開発の観点からやれること

目的不確実性は下記の様に、ある特定のフェーズを通過するごとに下がっていく。

このような活動に積極的に関与していくことだったり、もしここに上がっているフェーズをすっ飛ばしてものを作ろうとしている場合は、一旦立ち止まって「なんのために作ろうとしているのか」というのを考え、たとえ間違ってもいいので、後から検証できるような形に持っていくというのでもいいかもしれない。

また、「1秒でも早く価値を届けるためにどうすればいいか」というのを考え、やれることをやっていってもいいかもしれない。

特におすすめなのは 施策をリリースした後にCSと顧客に展開するのではなく、施策の出来上がりの解像度が少しでも上がったらすぐにFBを求めに行く というもの

• まずは動くものを作るというアジャイルの原則を否が応でも実現する必要が出てくる

• 顧客へのヒアリングより圧倒的に速いスピードでFBを貰える。

• CSが「これだとお客さんに使ってもらえない」という意見がリリース後に出てくることがなくなる。

• CSに事前に展開しておくことで、リリース後に顧客に使ってもらえるような準備をリリース前に実施してもらえる

• 例えばCSが顧客と商談するときに、施策に対して顧客からFBをもらい、リリース前に調整ができるかもしれない。

というところで、少なくともリリース時には 「CSが顧客に使ってもらえる」状況まで目的不確実性を下げる ことができ、かつその プロセス自体も対して難しいことを要求しているものでもないため、すぐに取りかかれる難易度でもある。

また スプリントゴールを設定後に事業部に展開する というのも良い。質は多少劣るもののいくつか同様の効果を得られる。

これ以外にもあるかもしれないが、まずは自分のできるところからやってみるとよい

まとめ

目的不確実性をコントロール下に置く重要性と、まずできることからやっていこうという話をさせてもらった。
「もっとこうしたほうがいいんじゃないか」「こういう観点もありそう」みたいな意見があればコメントにいただけると嬉しいです。
あと、プロダクトマネジメントや開発手法などに関して、一緒にお話していただける方も募集中です。 https://twitter.com/kotamats にDMいただければと思います。