期待値調整におけるギャップとシステムの不具合解消の対比

田部井勝彦

2022.03.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちわ。従業員体験( EX ) の向上がミッションのエンジニアリング統括室に所属しているてぃーびーです。

従業員体験の向上において、会社と従業員、マネージャーとメンバー相互の期待値がマッチしていることが重要になります。

期待値調整におけるギャップとシステムの不具合解消を対比してみようと思います。

ギャップの構造対比

システム開発において不具合が発生したとき、本来期待される仕様と実際の動作結果が異なる状態ということになります。

期待値調整に関わるズレにおいてもそれは同じで、片方が相手に期待していることと相手が実際に行動した結果が異なるという状態になります。

システム開発において、不具合を解消していく流れは

のようなものだと思います。

一方で、期待値調整に関わるズレを解消する場合、必要となるのは同様のプロセスだと思いますが、現実はそうでもないことが多いと思います。

例えば、

のようなことがよくあるのではないでしょうか。場合によっては

ということもありそうですね。

Aさん、 Bさん、 Cさんの話はあくまで1例で、Aさんと経営の場合もあるでしょうし、経営と従業員全体ということもあるでしょう。

相互に協力してこの種の問題を解決するためには期待の明示が必要になります。

例えば前述の例で考えると

BさんはAさんが心のなかで考えている暗黙の期待を元に、それを満たせていないから不満だと思われている

という状態です。これはシステム開発に置き換えていうのなら

顧客が今まで全く開示していなかった要件を、まるで最初から存在するものであるかのように「この要件を満たしていないのでこのシステムはバグっている」と言ってきた

というような状態です。しかし、こと期待値調整の問題に関してはこういった状態はよくあるのではないでしょうか。

自分だけが考え、相手に伝えていない 暗黙の期待 が抱える問題です。

だからこそ会社と従業員、マネージャーとメンバーは相互にお互いの期待値を明示しあうのが大事になります。開発において明確な仕様が大切であるのと同じになります。

期待値調整について、ジュニアな人に対しては丁寧にしてもいいが、一定ベテランになった人たちには不要と考える場合もあるかもしれません。

ベテランが相手の場合も期待値を減らす・なくすというのではなく、期待の抽象度を高くする、 How に近い領域は任せる、などの変化が好ましい変化でしょう。期待値の抽象度が高くなったとしても、それが相手に伝わっているかの確認も必要であり、伝わるまで質問を歓迎するスタンスが必要になるでしょう。

会社において期待値ときくと会社から従業員、マネージャーからメンバーという方向が思い浮かぶケースが多いかもしれませんが、従業員から会社、メンバーからマネージャーへの期待も暗黙では伝わりません。どちらからも期待を明示していくことが好ましいでしょう。

期待値調整におけるギャップとシステムの不具合解消の対比してみました。

期待値調整においてもシステムにおいても暗黙から明示への変換が大切です。

自分が相手に持つ不満。その不満のもととなる相手への期待は事前に相手に伝えたのか？
相手に伝えた場合もただ伝えただけではなく「伝わったのか？」「納得してもらえたのか？」まで確認できていたか？
実は相手にはその期待を満たせない理由となる制約がないか？それは相手1人では解決が難しく周囲の協力が必要ではないか？
毎回単発のやりとりごとに期待値のすり合わせを実施するのを避けるため、チームで共通の期待を予め整えることができているか？
- 例えばチームの意思決定のガイドとしてチームの MVV やを用意すること
相互に期待の明示をするには土台に信頼関係が必要であり、仮にそれがすでに失われている場合に第三者の協力を得るか？

など掘り下げる点が色々ありますね。