「ユーザーストーリーマッピング」を読んでみた 【0章の2】
今回【0章の2】では、製品開発の目的とアウトプットや成果についてまとめていきます。
要件よりずっと大事な事について話す
共通理解を築くには、実際に集まって話すべきですが、要件を話すことが本質ではありません。
原書では、「本当は、あなたの仕事は世界を変えることだ」と書かれています。
製品に取り込まれている素晴らしいアイデアで、ユーザーの世界を少しでも変える事ができないとプロジェクトは失敗です。要件だけに注目していると、ユーザーにとってのメリット（よい変化）を深く考えずに話が進んでしまうことがあります。
よって、過去にこの要件があったから、とりあえず要件として入れるではなく、そのアイデアでユーザーがどの変化するかに焦点をあてて話す必要があります。
一番重要なのはアウトプットではなく成果
アイデアを製品にして、ユーザーに届けるまでをアウトプットと呼びます。開発者は、このアウトプットをできるだけ高速化するように努力します。
しかし、アウトプットは本当に大事なものではありません。
アウトプットの後に結果として現れる成果（outcome）が、一番重要です。ユーザーに変化をもたらさない製品を、高速でアウトプットして提供しても意味がありません。
これは私の考えですが、期待した成果が得られるのであれば、ソフトウェアという形でなくてもいいわけです。
ハードウェアかもしれないし、有人のサービスかもしれません。
成果に注目していないと、より良い成果を得られる選択肢を見落としてしまう事もあると思います。
ユーザーと会社の利益は関連する
ユーザーも大切ですが、製品を届ける側の会社も大切です。会社が倒産すると、サービスを維持できなくなります。
しかし、会社が利益を得るには、ユーザーが欲しいと思っているものを供給しなければなりません。
ユーザーのニーズを満たせれば、会社は売上やマーケットシェアの拡大が見込めます。
また、金銭面だけではなく、多くの社員が満足な気持ちになり、メンタルな部分でもプラスに働きます。
このような、優れた成果を上げた結果、長期的に、ユーザーと会社の双方に利益がでる事を「インパクト」と呼びます。
作るものは最小で、成果とインパクトは最大
ソフトウェア開発でよくみられる勘違いは、より多くのアウトプットをより早く得ようとする事です。
しかし、ここまでの流れの通り、重要なのはより多く作ることでなく、より少なく作って成果を得ることです。
すべてのユーザーを満足させるには、アウトプットがとてつもなく膨れ上がります。
そして、その開発コストを許容できる会社は存在しないので不可能です。
よって、アウトプットをできるだけ最小化して、成果とインパクトを最大化するようにすべきです。
そのためには、要件ではなくて、問題を抱えている人々の様子に十分な注意を払う必要があります。
まとめと感想
- 要件よりユーザーに良い変化をもたらすアイデアについて話す
- アウトプットの量を増やすのではなく、成果を増やす
- ユーザーの利益が会社の利益につながり、長期的に双方に利益をもたらす（インパクト）
- 我々のやるべきことは、アウトプットを最小化しつつ成果とインパクトを最大化する
今回もとても共感する内容が書かれていました。
とくに要件に関しては、ユーザーがどのような事に不満を持っているのか。
そしてこの要件によって、どうのように解決されるのか説明できなくてはなりません。
ソフトウェアの機能は増大し、管理や保守面でコストが高くなります。
ユーザーへの利益駆動で機能や要件を見つめ直し、最小のアウトプットで最大のインパクトを得ることができれば、自動的にコスト面の問題も解決できているはずです。
復習用の質問
- 私達がソフトウェア開発において、もっとも話し合わなければならないものはなんですか？
- ソフトウェアをユーザーに届けるにあたって、一番重要なものはなんですか？
- どうすれば会社を成長させ健全化できますか？
- どうすれば、作るものの量を減らせて、最大の成果とインパクトを得られますか？
この記事を書いた人
- 事業開発部 web application engineer
-
2008年にアーティスへ入社。
システムエンジニアとして、SI案件のシステム開発に携わる。
その後、事業開発部の立ち上げから自社サービスの開発、保守をメインに従事。
ドメイン駆動設計（DDD）を中心にドメインを重視しながら、保守可能なソフトウェア開発を探求している。
この執筆者の最新記事
関連記事
最新記事
FOLLOW US
最新の情報をお届けします
- facebookでフォロー
- Twitterでフォロー
- Feedlyでフォロー