この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
背景
私は、クラスメソッドで受託開発を行うCX事業本部に所属しており、プロダクト・マネージャーとして、これまでの数年間にいくつかの開発案件に携わってきました。
この間、弊社で受託する案件が次第に複雑かつ大規模になってきていると感じます。
このような状況では、お客様が提示された仕様を実現すること自体の難易度が上がることになり、私たちもお客様と密にコミュニケーションをとり、開発するプロダクトのあるべき姿や実際の仕様についてディスカッションを重ねながら開発を行っていきます。
他方で、私たちは、プロダクトは開発して納品すれば終わりとは考えていません。
むしろ、開発して納品させていただいたプロダクトが、弊社にご発注いただいたお客様のビジネスや、それを利用するエンド・ユーザーにどのような価値を提供するのか、それを最大化するにはどうしたらいいのか、さまざまな視点で検討する大切さを痛感する機会が多くありました。
仮に、一生懸命に開発して納品したプロダクトが、エンド・ユーザーにあまり活用されず、私たちに発注してくださったお客様のビジネスのグロースに貢献しないような事態となれば、こんなに悲しいことはありません。
その過程で、こうした「納品したプロダクトの価値の最大化」のためには、要件定義の内容が重要なポイントなのではと考えるようになり、上村有子著・技術評論社刊『図解即戦力 要件定義のセオリーと実践方法がこれ1冊でしっかりわかる教科書』を読み、この中で International Institute of Business Analysis™ (IIBA®) による Business Analysis Body of Knowledge®ガイド (BABOK®ガイド) が紹介されていたことで、それを調べていく過程で「ビジネス・アナリシス」と、それを実践する「ビジネス・アナリスト」の存在を知ることになりました。
先日、このIIBAが実施するビジネス・アナリストの国際資格であるEntry Certificate in Business Analysis™ (ECBA™)の日本語CBT試験に合格しました。IIBA日本支部にて合格体験記も掲載いただいています。
この記事では、IIBA日本支部によるスライド資料などを参照しながら、「納品したプロダクトの価値の最大化」について考えてみます。
「価値」「ニーズ」と、その潜在性
そもそも「価値」とは何なのでしょうか。
BABOKによると、「価値」とは
あるコンテキストにおける、ステークホルダーに対する値打ち、重要性、有用性 価値は、潜在的または実現した利益、利得、改善と見なすこともできる。 また、損失の減少、リスクの減少、コストの減少が価値となる場合もある。
価値の源泉はステークホルダーのニーズにある そのニーズが満たされれば、ステークホルダーは価値を感じる
ここで、「ニーズ」とは
ステークホルダーに潜在的価値のある問題、機会、または制約
と書かれています。
ここで私が注目したのは、ニーズに含まれる「潜在的価値のある」の部分です。 価値の源泉はステークホルダーのニーズにあり、そのニーズが満たされれば、ステークホルダーは価値を感じる。
その価値の源泉たるニーズには、潜在的価値があると書かれています。
具体的に考えてみると、ステークホルダー、この場合は受託開発を発注されるお客様は、ご自身のニーズに、ご自身でも気づかれていない部分があると考えられそうです。
このあたりについては、羽山さんのスライドでも触れられていました。
つまりッツ︕ ユーザーは⾃分が 「本当に」 ほしいものを⾔葉にできない それどころか ユーザーは⾃分が 「本当に」 ほしいものを 知らない︕ しかもユーザーの声は オレたちのもとまで 正しく届かないッツ︕
プロダクトオーナーと潜在的価値のジレンマ
わたしたちは、開発期間中のさまざまな変化を受容し適切に対応するため、スクラム開発を採用することが多くあります。その場合、お客様のどなたかにプロダクトオーナーになっていただくことになります。
スクラムチームやスクラムマスターとしては、プロダクトバックログをReadyにするために、プロダクトオーナーに様々な質問をして開発を進めます。ここでは、要件の具体化が直近の目標になりますが、このタイミングで、ともすれば、プロダクトバックログの仕様を、プロダクトオーナーの発言を基準にしてしまう傾向があると感じます。
より近視眼的には、プロダクトオーナーの言うとおりのものを作ればOKと考えてしまいがちです。これは、冒頭で触れたように、プロダクト開発そのものの難易度が上がると、より顕著になると感じます。
このままの状態で開発を進めると、それは、プロダクトオーナーであるお客様が顕在的に意識しておられる仕様が、プロダクトの仕様になる可能性が高くなります。このため、プロダクトオーナーやエンド・ユーザの潜在的ニーズが実装に反映されない可能性が高く、それはプロダクトがもともと秘めていた可能性を小さくしていると考えます。
また、プロダクトオーナーであるお客様が、エンド・ユーザーから見てサービス提供側である場合、エンド・ユーザーのニーズを、必ずしも全て把握していない可能性もあります。
わたしたちスクラムチームも、プロダクトオーナーとの仕様に関するディスカッションの過程で、自分達のエンド・ユーザーとしての経験から、プロダクトの仕様について意見を出したりするような努力はしていますが、実際のエンド・ユーザーへのヒアリングに比べると十分ではないと感じます。
以上より、プロダクトオーナーであるお客様の発言のみを基準としてプロダクトの仕様を決めると、それはプロダクトのもつ潜在的な可能性を一部しか備えておらず、また、エンド・ユーザーのニーズとは異なる価値を実装した仕様になる可能性があると考えます。
このままでは、開発して納品したプロダクトが、エンド・ユーザーにあまり活用されず、お客様のビジネスのグロースに貢献しないような事態が起きる可能性も考えられます。
潜在的な価値を顕在化するために、受託開発を工夫する
ここまでの議論で、少なくとも、ステークホルダーが持っている潜在的なニーズを顕在化させ、かつ、エンド・ユーザーのニーズも引き出して仕様に反映させることで、プロダクトの価値をさらに向上させることができそうです。
これにより、より多くのニーズを満たし、お客様およびエンド・ユーザーの満足を引き出すことができそうなことがわかりました。
では、受託開発において、このような
- 潜在的なニーズの顕在化
- エンド・ユーザーのニーズの引き出し
は、どのように行えばいいのでしょうか...を書き出すと、ビジネスアナリシスの本がかけてしまうので、今回は「受託開発を工夫する」に絞ろうと思います。
受託開発を工夫するというのは、受託の受け方を変えたほうがいいのではという提言です。
まずは「潜在的なニーズの顕在化」のために、「顕在的ニーズ」と「潜在的ニーズ」についてお客様に提言することが考えられます。
受託開発となると「お客様の顕在的ニーズ＝開発プロダクトの仕様」と思われているお客様に対して、よりよりプロダクト開発のために、まずは一歩引いて、お客様のニーズをあらためて見直す機会を提案することから始めることになると思います。
次に「エンド・ユーザーのニーズの引き出し」については、まずはサービス提供側とエンド・ユーザーの認識ギャップについてご説明し、既存ユーザーへのアンケートの実施などの施策によって、このギャップを乗り越えて新たな発見を得ることをご提案することになるかと思います。
まとめると、受託開発において、すぐに具体化設計に着手する前にに、まずは「ビジネスアナリシス」や、それに続く「要件定義」のフェーズを経ることで、より最終的なプロダクトの価値を向上するご提案ができればと考えています。
まとめ
ここでは、受託して開発したプロダクトの価値は、納品後に、弊社にご発注いただいたお客様のビジネスや、それを利用するエンド・ユーザーにどのような価値を提供するのかが大切だというお話をしました。
この価値を最大化するためには、お客様が意識しておられる顕在的ニーズのみならず、潜在的なニーズの顕在化も重要と考えています。また、お客様がエンド・ユーザーにプロダクトを提供する場合、エンド・ユーザーとの間にギャップがある場合を考慮する方がよいと考えます。
受託開発案件において、潜在的ニーズの顕在化や、エンド・ユーザーのニーズの調査のためには、プロダクトの設計に着手する前に、ビジネスアナリシスや要件定義のフェーズを挟むことが有効と考えます。