ソフトウェアの受託開発における話です。主にPM向けです。
開発したソフトウェアの大半は、使うユーザがいて、そのユーザの満足度がビジネスに与えるインパクトが少なからずあるものです。
それは、自社のプロダクト開発であろうが、受託の開発であろうが変わりはありません。
自社開発であれば、ユーザーの声を拾って改善していくことがビジネスの成長に繋がると意識しやすいのですが、受託開発になると途端に発注者の顔色をうかがうようになり、ユーザへの意識が希薄になります。
その原因は様々ですが、一番の問題は、「ビジネスの目的が共有できない」という事かと思います。
例えば、発注者としては、「なるべく安くものを作りたい」、受注者としては、「利益をあげたい」、みたいな目的の場合、このプロジェクトでは、ユーザが優先されません。
ユーザにとって必要なものは何か、それはお金を払う価値があるものか、価値があるならどの程度を想定するか、このあたりを考えず(説明せず)に、コストを下げたいという話をする発注者は割と多いと感じています。
受注者としても、リスクを下げるために、言われたこと以上の事はやらない、曖昧さを極力なくそう、という行動をとりがちです。
そして、お互いの(誤った)目的を達成するために、本来、ユーザにとって大事だったはずの機能をドロップしてしまう、みたいな事が起きます。
このような事を避けるためにも、「このプロジェクトを行う目的は何か?」という事をユーザ視点、ビジネス視点で理解する必要があるという事です。
そして、この目的は、発注者、受注者双方にとって、受け入れ可能なものでなければなりません。
実際、長い目で見ると、自社の利益だけを優先しても、良い結果は得られません。
ユーザの満足度が得られなければ、顧客(発注者)のビジネスが縮小していくことになり、継続受注も困難になります。
発注者、受注者、双方にとって、目的を共有することはメリットしかありませんので、「このプロジェクト、目的がよく分からんな」みたいな事があったときに、そのままにしないようにして欲しいです。
もし、受託開発において、PM等が「自社の利益が目的です。」とか「マイルストーン通りにリリースする事が目的です。」みたいな事を言っている場合には、このプロジェクトを行う上で、「顧客の目的は?」「ユーザにとっての価値は?」「顧客とユーザも含めた成功とは何か?」とか聞いてみてください。
面倒くさいやつって思われるかも知れませんが、このあたりを明確にしておかないと、より面倒くさいこと(大規模な追加開発や仕様変更みたいなこと、最悪はプロジェクト中止)が起こるリスクがあります。