見出し画像

#227 期待値コントロールで生産性は向上する

こへい／ITベンチャーエンジニア

こんにちは。ITベンチャーエンジニアのこへいです。
前回、プロフェッショナルの仕事は期待値をコントロールすることであると述べました。

これは、80％の力で求められる水準をクリア出来るように顧客の期待値をコントロールするということです。
このアプローチでは、クリアラインが下がることで業界全体のレベルが下がるのでは？という指摘をいただきましたが私の解答は「No」です。

ギリギリ最低限の労力で顧客の期待に応えるとういことは、クオリティを下げることやチャレンジを避けるということではなく、本当に価値のあることに集中するということであり、業界全体の生産性の向上や高付加価値の仕事作りを後押しすることに繋がると考えています。

ということで今回は期待値コントールがなぜ生産性向上に繋がるのかという話です。


◯顧客は要求を正しく伝えられない

顧客は自分が本当に必要とする要件について常に正しく表現できるとは限らない。つまり、ユーザーからの要求事項は絶対ではないということを表した「オレゴン大学の実験」のこちらの図は有名です。

顧客が本当に必要だったもの、すなわち真の要求事項は右下の絵にある「木にぶらさがったタイヤ」ですが、顧客が説明した要件は左上の絵にある「木にぶら下がった3段ブランコ」であり、顧客は自分が本当に必要であるものをそのまま伝えることができない例を示しています。また、それを聞いたプロジェクト・リーダーは左上の2番目の絵ととらえ、以下、アナリスト、プログラマへと続き、結果としてプロジェクトは悲惨な状態になってしまうということです。

エンジニアは誰もがこの認識のズレを体験しているため、みんなでこの図を見るとめちゃくちゃ盛り上がります。

これは、要求を伝えられない顧客が悪いのではなく、人間は誰しも頭の中にあるものを正しく相手に伝えることが苦手であり、このことをPMは常に意識しておく必要があります。そして、顧客の要望を100％信用するのではなく、真の顧客の要求とは何かを常に考える必要があるということです。

この期待値のギャップを埋めるには、顧客の要求をそのまま実現しようとするのでなく、真の要望を可視化しそれをどのように実現するかを考えることが重要です。ただ作業をするのではなく仕事を作るアクションころが期待値コントロールの第一歩です。


◯期待値コントロールは機能（要件）が必要な理由を明確化すること

前述の通り、顧客は真の要求を正しく伝えることが難しいため、聞いた内容をそのまま実現しても顧客からは「期待と違う」と言われてしまうと、期待と現実の差を埋めるための追加の対応が必要になります。

この手戻りを防ぐために、顧客の求める機能が必要な理由を深掘りすることが有効です。機能を求める背景には必ず理由があります。
「パンが欲しい」という要求の理由には「お腹がすいている」という理由があるでしょう。ではなぜパンでないといけないのでしょうか？「メールチェックしながらお腹を満たしたいからパンが良い」ということであればおにぎりでも要求を満たせるはずです。

このように、要求の背景を深掘りしていくことで、手がべとべとになり片手で食べるのが難しいパン（どんなパンでしょう？笑）を提供し「期待と違う」とやり直しをくらうことを回避することができます。

また、パンが欲しいと言われてもパンを作る材料やオーブンなどの器材がないとそれらを揃えるのに大きなコストがかかります。手元に炊き立てのご飯と梅干しとノリがあれば、おにぎりを提供するコストは握るだけです。（都合の良い状況ですね笑）

顧客の要求を満たす方法がよりお手軽である程、より少ない労力で求められる水準をクリア出来ます。このケースではおにぎりを提案し、「メールチェックしながらお腹を満たせる軽食」という期待を満たすことが、適切な期待値コントロールが出来ていると言えるでしょう。

◯出来ないことを明確にする期待値コントロール

パンの代わりにおにぎりを提供するという話は非常にシンプルでしたが、実際のプロジェクトはもっと複雑です。

ステークホルダーが多いほど真の要求は見えなくなり、プロジェクトの規模が大きくなるほど要求の量が増え、一つ一つの要求の背後にある理由の確認には多くの時間が必要になります。
また、要求を伝える人がシステム利用者でなく真の要求を理解していないこともあれば、偉い人が必要といっているから作って欲しいという意図のない要求などもあり、ただ時間をかけてるだけでは必要な理由を突き止められないため、あの手この手で情報収集する必要があります。

また、要求は時間と共に変化していきます。要求を出すのは人間なので、その人の考え方や立場、その人を取り巻く環境の変化によって、自然と要求も変化します。プロジェクトの期間が数年単位の長さであれば、市場の変化によって開発途中で求める機能や水準が変わることもあり得ます。

そんな状況で数百を超える要求の塊のシステム開発は炎上リスクの非常に高いプロジェクトとなります。
期間、費用、リソースに合わせて実現可能な範囲に期待値をコントロールすることが、炎上を防ぎ顧客に価値を提供することにつながります。

そのためには、まずは要求定義の時間管理をすること。要求を全て出し切る期間を設定し、その要求の分量に応じて要件の理由を明確化し要件の詳細化をする期間も定めます。また、プロジェクトは大抵お尻が決まっているため、お尻から逆算しスコープを調整します。

この要件定義期間で求められる要求、水準を明確化させます。出来ないことを曖昧にせずにハッキリと宣言することが重要です。代案の提案や、検討するにしても別プロジェクトに切り出すなど、とにかく要求に対する期待値を曖昧にせずに、明確化することに注力します。

曖昧な期待は勝手に膨れ上がるものなので、出来ないこと出来ないと明確に伝えて、曖昧な期待をそのままにしておかないことは非常に重要です。
要件が必要な理由の明確化よりも重要かもしれません。

やらないことを明確にすることで、やるべきことに集中でき、生産性の向上や本当に必要な価値の提供ができるようになります。


期待値コントロールとは、顧客の真の要求を80％の力で実現することと述べましたが、これは決してクオリティを下げることやチャレンジを避けることではありません。

ということで、今日は期待値コントロールで生産性が向上出来るという話でした。
最後までお読みいただきありがとうございました。

いいなと思ったら応援しよう！