デザイナーがはまったプロダクト開発の罠

皆さんこんにちは！キャディでプロダクトデザイナーをやっているモリと申します。よろしくお願いします。

今回はキャディの話ではなく少し昔の話をしようと思います。僕自身がとあるプロダクト開発の現場で行き詰まった時の話です。
もしデザイナーで同じような状況で悩んでいる方がいましたら参考にしてみていただけると嬉しいです。

この記事は、CADDi Advent Calendar 2021の15日目にエントリーしています。

adventar.org

こんな経験ありませんか？

僕は以前C向けサービスを開発・運営している会社（仮にA社とします）でデザイナーとして働いていました。

ある時、開発チームはマネジメントが考案したとあるソリューション（機能）を伝えられました。
A社ではソリューション（機能）が決定した状態で開発チームに依頼されるプロセスなっています。機能の中には技術難易度が高く、開発に3ヶ月以上かかる機能もありました。そしてソリューションしか伝えられていないチームはその機能がユーザーのどんな課題を解決するかを知らないため開発のロードマップを書き換えることはできませんでした。

チームは何とか機能をリリースし、マネジメントは満足した様子でした。

数週間後、チームはリリースした機能の利用状況やユーザーフィードバックを調査しました。すると以下のような事実が判明しました。

• 作った機能がユーザーにまったく使われていない

• 無茶なリリースとテスト不足により障害やバグが頻発している

• 新しくリリースした機能がメイン機能の邪魔をし、UXを棄損している

便利な機能を追加したはずなのに、ユーザーに使われなかったり、果ては使いづらくなったとまで言われる事態になっていたのです。

ビルドトラップ

何が問題でこのような状況に陥ったのでしょうか。
原因はマネジメントが開発チームにソリューション（機能）を渡していたことにありました。そしてマネジャーはソリューションをチーム伝えることが仕事だと思っていました。
マネジメントがソリューションを伝えるようなやり方だと、成功の指標や目標をの設定を飛ばしてしまいます。
するとチームの実績は「機能の数」や「リリース回数」「ベロシティ」で評価されます。「機能が本当にユーザーに価値をもたらすか」は評価せずバックログがどれだけ消化されたかどうかで判断されます。まさしくビルドトラップにはまった状態と言えます。

ビルドトラップとは、組織がアウトカムでなくアウトプットで成功を計測しようとし行き詰まり、実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状況。

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

この経験からアウトカムとアウトプットちゃんと理解することがビルドトラップを避ける上で大事だと学びました。

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

アウトカムとアウトプット

アウトカムとアウトプット。
皆さんもビジネスや開発現場で耳にしたことがある言葉だと思います。この２つの言葉、響きが似ているし同じ意味で使われることもあったりするのでちょっと混乱を招きますね。アウトカムとアウトプットの違いは何なのでしょうか？「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」にあった記載がわかりやすかったので以下に引用します。

アウトカム

アウトカムとは機能を届けて顧客の問題を解決したという結果のことです。

アウトプット

アウトプットとは簡単に数えられるもののことです。プロダクトの数とか機能の数、リリースの回数や開発チームのベロシティと言ったものです。

ビルドトラップの兆候

ちょっと考えてみると、アウトプットを評価の指標にすると開発が上手くいかなくなるのは理解できると思います。ただ現実問題としてビルドトラップに陥っている組織は多いのではないでしょうか。

要件や機能の複雑性が上がるとアウトプットとアウトカムの境界が曖昧になりビルドトラップにはまりやすくなる気がします。そこで自分自身がビルドトラップはまりそうになった時に現れた兆候と、どう回避するかを

何を作るかだけを伝えている

これは自分自身がビルドトラップにはまっていたパターンです。
デザインやプロトタイプをチームにプレゼンするとき、何ができるようになるか（アウトプット）を説明してしまっている時があります。そういう時は大体チームからの質問で自分がアウトプットモードになってしまっていたことき気づきます。何がユーザーの価値なのか、何を解決したいのか（アウトカム）を伝えることを常に忘れないよう気をつけたいものです。

機能要求

「次はこの機能を開発します」
マネジメントが開発チームに「こういう機能（ソリューション）が欲しい」と要求してきたら気をつけてください。そういった時チームは「なぜそれが解決策なのか、そもそもなぜその問題が起こっているのか？」を質問してみると良いかもしれません。

競合他社への追従

「他社もやってるし、ウチでも開発しよう！」
こんな言葉を聞いたら要注意です。ユーザー視点の指標を設定できていないためアウトプットにフォーカスしていまっています。
競合の機能（アウトプット）をベンチマークし、自社でも同じ機能を開発しようと試みます。もしそのような状況に陥っていたとしてらマネジャーにこう聞いてみましょう「競合はその機能でどんな成果を出しているのですか？」

さいごに

ここまでを振り返って、自分が過去のビルドトラップに気づけたのはキャディでの開発経験が大きかったと思います。
それはキャディが、不確実性を受け入れ、実験と実証を重視するアウトカム指向のプロダクト主導組織だったからだと思います。

ここまで読んでいただきありがとうございました。もしキャディのプロダクト開発に興味を持った方は是非ご連絡ください。