カテゴリー
Amazonサービスのレビュー webライター アパレル サブスクのレビュー プログラミング 仕事 体験談・レビュー 働き方 北海道のライフハック 北海道の話 北海道の風景 好きな作品レビュー 札幌移住の話 楽に生きる考え方 買って良かった物のレビュー 転職 辞め方 退職代行
期待値調整とは？必要性や具体的な方法を考えてみた
当ページのリンクには広告が含まれています。
どうも、たくろーです。
主にクライアントワークや開発の現場で「期待値調整」という言葉が使われます。そしてどんな業界でも、この言葉を使わないにせよ、多かれ少なかれ「期待値調整」は行われているように思います。
でも本質的には必要のない作業ですし、けっこう不思議な概念だなと思ったので、今回はそんな「期待値調整」の意味や必要性、本質について考えてみました。
目次
期待値調整とは
期待値調整とは「相手に求められていることと、現実的に提供できることとの差異をなくす作業」を指す言葉です。開発や制作の現場でよく使われる言葉で、あとになって上司やクライアントから怒られないためにおこないます。
例えば僕みたいな、個人でライティングをしたりWebサイトを作ったりアプリ開発をしたりするスケジュール感が染み込んでる人間は「まあちょっと難しいアプリ開発って言っても、プロトタイプならとりあえず1ヶ月くらいで用意できるよね」みたいな感覚を持っています。僕は実際に、趣味としての個人開発で2ヶ月少々で2つのアプリをリリースしています。
しかしチーム開発でいくつものグループが動くような現場だと、まずはエンジニア全員が足並みを揃えるために学習しなきゃいけなかったり、環境構築をしないといけなかったり、仕様を決めないといけなかったり、デザインを決めていかないといけなかったりと、様々な工程が発生します。ログインして個人情報を扱うようなサービスなら、セキュリティ面の工夫も必要ですし、1ヶ月どころか3ヶ月くらい下準備で過ぎたりもします。
でもエンジニアじゃない人には、そんな常識はわかりません。普通に「いや学習とかじゃなくて、その言語を触れる人間がさっさと作れよ」と思われてしまいます。
このように、スケジュール感や提供クオリティの認識には、人それぞれ育ってきた環境により大きな差が出ます。
「やってほしい側」と「やる側」にそれぞれ色々な状況がある中で「完成はいつで、クオリティはこのくらいですよ」という認識をすり合わせておく作業を「期待値調整」と呼びます。
期待値調整が必要な理由
クライアントや上司（というか人間）は、基本的に都合の良いように解釈するものですから、その点で期待値調整が必要になります。
具体的なシチュエーションを考えてみます。
例えば8月くらいにプロジェクトを開始した場合に、営業やPMが「そうですね、半年でとりあえずプロトタイプはできそうです」とざっくりしたスケジュール感をクライアントに伝えたとします。
そしたらだいたいクライアントは「半年でいけるなら、じゃあ年内とかで作れない？1月には出してよ」と言います。これが世の常です。
そして、それを受けて「いや、絶対に6ヶ月必要です」とは言いにくいため、そのままなんとなく仕事を受けてしまう。これですでに納期が1ヶ月ショートしました。
そして1ヶ月ほどなんとなく下準備で過ぎて、やっと開発がスタートし始めた頃に、突然「どのくらい進んだ？1月には完成するんだよね？」と言われます。（この時点で、さらっと認識が「プロトタイプじゃなく完成品ができる」と変換されていたりします。）
そして「今準備が終わったところで、これから開発スタートです。まだ見せられるものは何もありません」と報告すると、もうデスマーチが確定します。デスマーチをしたところで、多分1月に見せるのは無理で、だいたい来年の8月くらいまで伸びます。
このように、最初から色々と認識をすり合わせしておかないと大変なことになるので、仕事をする上での処世術として「期待値調整」という作業が必要になるのです。
期待値調整の方法
期待値調整の方法として、まずは「相手が理解できるように伝える」という基本的なことをおこなう必要があります。
こんなことを言うと差別だ！と言われるかもしれませんが、エンジニアという人種には「相手にとってわかりやすく説明する心意気」が著しく欠けている人が多くて、多くの場合その点でイザコザが発生します。例えば専門用語をつかったり、なんか意識高そうな言葉を使ったりしても、同じ界隈の人しか理解できません。
「相手のことを考えてわかりやすく伝える」を前提として、想定品質とスケジュールを具体的に伝えていきましょう。
想定品質を図表で伝える
口頭で説明するだけでは、だいたい認識に齟齬が生まれます。納期までに用意できる提出物の品質について「認識がずれそうだな」と思ったら、パワポやGoogleスライドなどで図表をつくって説明しましょう。
たとえば「現時点・提出時点・理想」の3つのブロックを用意して、それぞれどの程度の実装が完了している予定なのか、ある程度具体的にまとめます。
なんなら提出時点では少し低めに出しておけば、上回ったら上回っただけ褒めてもらえます。「この人はちゃんと期待を超える仕事をしてくれる人なんだな」と思ってもらえれば、次から期待値調整の必要がなくなってきます。
スケジュールと作業内容を図表で伝える
スケジュールも図表で伝えます。口頭やテキストだけでは理解できませんし、仮に長文テキストなんて渡したところで、依頼する側の忙しい人は読みませんしので、パッとわかる図表が必要です。
どのくらいのスケジュールが必要で、1ヶ月ごとくらいでどんな作業おこなわれるのか整理しておきます。
なお作業内容としてギチギチにテキストを埋めておけば、詳細は読まないにせよ「ああ、こんなにやることが多いのか。大変だな」とわずかながらでも理解してもらえます。
とにかくわかりやすく、理解しやすいものを用意して説明することが大切です。
期待値調整は本来必要がない作業である
個人的な意見として、期待値調整はけっこう無駄な作業だなと思っています。
本質は信頼とコミュニケーションです。お互いに信頼性があって、ある程度普段からコミュニケーションが取れていれば「期待値調整」ほど不要なものはありません。
とはいえ難しいのが「期待値調整が不要な関係性になるには、まずはお互いがお互いの期待値を超える仕事をしなきゃいけない」というところです。
なので「仕事のできる人同士、あるいは作業側がすごく仕事ができる場合」では期待値調整は不要で、どちらか一方、あるいは両方が相手の期待を越えられる仕事ができていない場合に、期待値調整の必要性が発生します。
（なおここまでに例に出してきた「開発スケジュール」において、だいたいは「開発側の説明不足」「依頼側の知識不足」の両方に問題があります）
一緒に仕事をして、期待値調整がいらない関係性の人とだけ仕事ができれば、それが一番いいような気がします。
そんなふうに、自分の満足いく仕事をすれば納得してもらえる環境を目指してみてはいかがでしょうか。
