アウトプットとアウトカムの違いとは？作ったものと起きた変化を分ける
目次
機能を予定どおり公開した。でも、利用者にとって何がよくなったのかは、まだ分からない。この二つを分けて考えるときに役立つのが、アウトプットとアウトカムです。
プロダクト改善でいうアウトプットは、活動から生まれた機能などの成果物です。アウトカムは、その先で利用者に起きる変化や得られる価値を指します。期待したよい変化だけでなく、意図しない変化にも目を向けます。「何を作ったか」と「何が変わったか」は、同じ話ではありません。
この記事では、用語の違いを理解し、身近な改善の目標を書き分けるところまでを扱います。効果測定の詳しい進め方は、関連する記事へつないで紹介します。
- 機能や資料の完成と、利用者に起きる変化を分けて書く
- 期待する変化を、すでに確認できた結果のように扱わない
- 作ったあとに何を見ればよいか、目標を決める時点で考える
作ったものと、変わったことを分ける
機能公開と利用者の変化
英国教育省のプロダクト管理指針では、活動の結果であるアウトプットと、利用者が経験する変化や便益であるアウトカムを区別しています。新機能を公開したことだけでは、利用者がどんな価値を得たかは分かりません。
たとえば、検索機能を追加することはアウトプットです。一方、担当者が必要な申請を見つけて次の作業へ進めることは、期待するアウトカムとして書けます。検索欄が画面にあることと、探している資料にたどり着けることを分ける考え方です。
| 観点 | アウトプット | アウトカム |
|---|---|---|
| 注目するもの | 作ったもの・提供したもの | 利用者に起きる変化・得られる価値 |
| 書き方の例 | 入力例を画面に追加する | 初めての担当者が記入内容を判断できるようになる |
| 確認する問い | 予定した内容を提供できたか | 困っていた作業はどう変わったか |
表の例は考え方を説明するためのもので、改善済みの実績ではありません。実際の目標にするときは、誰のどの場面かをさらに具体的にします。
同じ改善を二つの言葉で書く
ここでは、架空の申請管理サービスを例にします。実在する顧客やアーコレ！の実績ではありません。
改善案は「申請画面に入力例を追加する」です。これが実現すれば、入力例を読める画面が完成します。ただし、この書き方だけでは、どの困りごとを減らしたいのかが伝わりません。
誰のどんな作業が変わるか
背景に「初めて申請する担当者が、用途欄に何を書けばよいか分からない」という困りごとがあるとします。その場合は、次のように並べられます。
- アウトプット：用途欄に、申請内容に合った入力例を追加する
- 期待するアウトカム：初めての担当者が、用途欄に必要な内容を判断し、記入漏れによるやり直しを減らせる
「満足度を上げる」より、対象者と作業を添えたほうが、何を確認したいかを話し合えます。背景が分からない場合は、要望と課題の違いに沿って、要望の裏にある出来事を確かめましょう。
同じ入力例でも、初回の担当者には助けになる一方、慣れた担当者には不要かもしれません。すべての人に同じ変化が起きると決めず、今回の対象を明確にします。
アウトプットも必要、でも完成だけで終わらない
アウトカムを重視するからといって、作るものや公開日を管理しなくてよいわけではありません。必要な変更を提供できなければ、それによる変化も確かめられません。
ただし、完成したものの数だけを目標にすると、「追加すること」が目的になりやすくなります。入力例をたくさん増やした結果、読む量が増え、必要な例を探しにくくなることも考えられます。これはこの架空例で注意したい可能性であり、確認済みの結果ではありません。
次の順に確認すると、完成と変化の両方を扱えます。
- 何を提供するかを書く。
- 誰の、どんな作業を変えたいのかを書く。
- その変化を確かめる材料を考える。
- 反対に困る人や作業がないかも確認する。
機能を増やす以外にも、分かりにくい説明を減らす、既存の案内を直すといった手段があります。先に期待する変化を共有すると、実現方法を一つの機能案に固定せず話し合えます。
期待する変化と確認できた変化を分ける
公開前の「やり直しを減らせる」は期待です。実際に減ったと書くには、利用後の確認が必要です。期待と実績を同じ欄に置かず、状態が分かるように残しましょう。
| 状態 | 書き方の例 |
|---|---|
| 改善前の仮説 | 入力例があれば、用途欄の記入漏れを減らせそう |
| 公開後、まだ未確認 | 入力例は公開済み。対象者の次回申請で確認する予定 |
| 確認後の記録欄 | 対象・期間・起きたこと・根拠・まだ分からないことを記入 |
最後の行は記録欄の案で、成果が出たという例ではありません。結果が期待どおりでない場合も、そのまま残します。「対象者に知られていなかった」「例は読んだが内容が合わなかった」では、次に直す場所が違います。
確認材料には、申請の差し戻し理由や、担当者への聞き取りなどが考えられます。ただし、前後で変化があっても、それだけで入力例の追加が原因だとは決められません。担当者が業務に慣れた、申請の種類が変わったなど、ほかの変化も見ます。
具体的な確認手順は、機能改善の効果を確かめる方法で扱っています。ここではまず、何を確かめたいかを言葉にするところから始めましょう。
最初の一歩：直近の改善を一つ書き分ける
次のシートは、編集部が用意した整理用の例です。「作るもの」だけが埋まり、「期待する変化」が書けないなら、目的をチームで話し合うきっかけにできます。
| 記入欄 | 架空例 | 自分の改善 |
|---|---|---|
| 作るもの | 用途欄の入力例 | ［記入］ |
| 対象者と場面 | 初めて申請する担当者の用途記入 | ［記入］ |
| 期待する変化 | 必要な内容を判断し、記入漏れによるやり直しを減らせる | ［記入］ |
| 確かめる材料 | 差し戻し理由、作業の聞き取り | ［記入］ |
| 未確認の点 | 例が読まれるか、内容が理解されるか | ［記入］ |
シートを書いたら、「期待する変化」の主語が利用者になっているか見直します。「入力例を公開する」のままなら作るものの説明なので、「誰が何をできるようになるか」をもう一度考えます。
最初から目標の数字を無理に置く必要はありません。現在の状態が分からなければ、まず何を確認するかを決めます。数値目標を置く場合も、対象や測り方をそろえて考えてください。
作るものと期待する変化を並べると、リリースを終点にせず、次に確かめることを共有できます。複数の取り組みを計画する際は、プロダクトロードマップの作り方にも、この「何を変えたいか」の視点を持ち込んでみましょう。
参考資料
- 英国教育省：Be accountable for your outcomes — 成果物と利用者の変化の区別、期待する価値の確認を参照。申請例・シートは編集部による架空例です。
