レガシーコードからの脱却 5章のメモ - プロダクトオーナーって誰がなるの？

5章が印象的だったので、
メモとして思ったことを書き残しておきたいと思います。

5章は、タイトルに記載してある「9つのプラクティス」のうち、
1つめ「やり方より先に目的、理由、誰のためか伝える」が紹介されています。

実現方法を伝えるべきではない、目的を話すべき

受託案件ではクライアント、プロダクト開発ではユーザーから「こうしたい、こうしてほしい」という要件をもとに開発すると思います。

要件を出す側は「こうしたい、こうしてほしい」のような具体的の方法ではなく、その目的を話すべき。具体的な方法を伝えると、それを正として開発しがちとなり、目的に沿ったものが出来上がらないことが多い。また、方法をそのまま実装すると、システムに最適な設計プロセスが損なわれ、レガシーになるのを止められない。

と、本書から解釈しました。

実際、ユーザー側に「こうしたい、こうしてほしいを伝えないで、何をしたいか目的を伝えて」と言える機会は少ないと思っています。（言える機会があるのは、社内システム開発のようなパターンと考えています）

本書で記載されている通り、目的を知らないまま開発すると、
目的や効果がでないものが出来上がる可能性を拭えません。

そのため、以下のような手法等を使い、
目的を割り出す必要があると感じています。

本当は、目的を直で聞けるのが一番だと思いますが、
話す方も「こうあるべき」という先入観にとらわれている可能性があるため、
整理するためにこういった方法や壁打ちして整理 -> 目的を明確にした方が良い。

と、思っています。

目的をもとにユーザーストーリーを作り、POが受け入れ基準（何をするのか、いつ動くのか）を定義する。そうすると、開発者はストーリーと受け入れ基準を満たすため、最適な設計・開発に集中できる。

と、解釈しました。
内容は納得しました。

記載されている通り、POはいた方が良いというのは当然なのですが、
どの部門・立ち位置の人がなるべきなのか...というのが疑問です。

もし、本書の通り代替パス・エッジケース等を含めた受け入れ基準を定義するには、
プログラミング的な観点がある開発側の人が最適かなと考えています。
（ただ、ユーザーの業務知識・システムを十分に知り尽くしているということが前提）

ビジネス側の人がPOになる際は、
開発側から受け入れ基準を明確にするためのヒヤリングを行い、
共通認識を得るプロセスが必要と感じました。

以上です。

本書の内容をそのまま適用するのは難しいですが、
目的と受け入れ基準を元に開発するということが重要であると認識しました。

普段、「目的は？」「受け入れ基準は？」を言語化せず、
自然とこなしているケースが多いため、再認識して開発に望もうと思います。