提案:エンジニアに気軽に「バグ」というのはやめませんか?

もしかしたら私だけかもしれないです。ずれているかもしれません。
一般論ではないかもしれません。

でも、同じような気持ちになっているエンジニアがいるかもしれないので、
代表して言わせてください。

エンジニアに、気軽に「バグ」と言うのをやめませんか?

最近立て続けに以下のようなことが起こっており、私と同僚が消耗しています。心がすり減ってます。ワーカーエクスペリエンスが低下しています。。。
~~~~~~~~~~~~~~~~~~~
「○○さん、この数値がバグなんだけど直してもらえる?」
→調べたらその週は祝日影響で、営業日が少ないだけだった。

「あのデータのバグはいつ直りますか?」
→データの集計定義の変更の依頼があり、変更前の状態をバグと呼ぶ

「この前入ってなかったバグなんだけど、次の開発に入れてもらっていい?」
→スコープ外のこと(担当がそれを忘れていた)をバグと呼ぶ
~~~~~~~~~~~~~~~~~~~

言った本人からしたら、「想定通りになってないこと」=「バグ」と言っているのだと思いますし、何原因かよくわからないから、とりあえず「バグ」と言っているのだと思いますが、実は、これがかなりの心理的ダメージをエンジニアに与えることがあります。

「バグ」と言われると、私にはさまざまな負の感情が押し寄せます。

●事象の確認中
・何がおかしかったんだ、どこで間違っているのか(不安と焦り)
・やばい、迷惑かけた、叱られる、非難される(恐怖)
・影響範囲は?なんでもっとしっかりテストをやらなかったんだ(後悔)

↓結果
●確かにバグだった場合
・ごめんなさい。すぐに直します。(反省、罪悪感) ←これも当然起こります。この場合は謙虚に受け止めます。少なくとも「仕様です」とかは言いません。
●バグではなかった場合
・とりあえず良かった(安堵)
・てゆうか、気軽にバグって言ってほしくない、てゆうか、なぜ彼がバグ判定ができるんだ?(怒り、不信、脱力感)

この「バグではなかった場合の心の乱れ」が想像以上に大きいのです。
「大した確認も取らずバグって断定されること」がとても辛いのです。

心あるエンジニアは、バグを出さないように、迷惑かけないように心を砕いて作っています。人間なのでバグは出してしまう点は恐縮ですが、その点をご理解いただけるととてもありがたいのです。

ちなみに、「バグ」の定義は、以下のうち、狭義のバグは4、広義だと3も入る場合があると思っています。
(要するに、エンジニアの責任範囲がどこかということ。)

1:そもそもユーザーの認識が間違っている。
2:要望のことをバグという。
3:要望を仕様に落としたところが間違っている
4:プログラムのミス

 

上記を踏まえたうえで、「あれ?おかしいな」と思ってもらった場合は、以下のように言っていただけると大変ありがたいです。(こう言ってくれたら、嬉しいです。消耗しません。)
●基本スタンス
・明らかにバグと断定できる場合以外では、自分から「バグ」と言わない。(自信がないなら、「バグ」という言葉自体を使わないでも大丈夫です。)
・起こっている事象と、再現方法を説明し、確認を依頼する。
●伝え方例
「このページに出ているこの数値なんだけど、○○だと思っているのだけど、その認識で合ってるかな?ちょっと確認してもらってもいい?」
「ここのボタン押すと、TOPページに戻ってしまうのだけど、確認してもらっていい?」

何が違う?と思う方もいるかもしれませんが、「伝える側が間違っている可能性があることを踏まえて伝える」「バグかどうかの判断はこちらに委ねてもらう」だけで、受け取り手(特に私)の心理的負荷は下がります。

めんどくさくてすみません。


最後に、たぶん蛇足ですが、心理的負荷がどの程度かを例をあげて伝えさせてください。

「○○さんバグじゃない?」といきなり言われることは心理的負荷は、例えるなら、
「○○さん口が臭くない?」といきなり言われるのと同じぐらいです。そこでおたおたしていたら、「ごめん。私が放置したごみが腐ってた。気にしないで」と言われる感じです。適切な例えではないかもしれませんが、伝わったでしょうか????

私たちもすべてのバグをつぶせるわけでもなく、ユーザーの方に指摘をしていただけるのはとてもありがたいのですが、伝えるときにちょっとだけ、ご配慮いただけるとありがたいです。

 

私のくだらない独白を、最後まで読んでくれてありがとうございました。

 

「ESが上がるとCSが上がる」という都市伝説。というか疑似相関について。

「CSの向上のために、まずはESを上げるべきだと思う。」「ESは上がった気はするのだが、業績に結び付いている気がしない。なぜだろう?」という相談をよく頂きます。

多くの方との会話を通じて、私個人としては、「ESが上がれば(自動的に)CSが上がる」は都市伝説であると考えるようになったので、今日はそのことを書きます。

 ■よく伺う相談内容

ざっくりいうと、「ESを上げるために、有休促進やリモートワークやフレキシブルな勤務形態を導入したが、かえって生産性が下がり、顧客クレームも増えた。」
「CSを上げるには、まずはESからということで、一律でベース給を上げようと思うのだけど、どう思いますか?」的なことが多いです。

この話を図示するとこんな感じでしょうか。

f:id:workerexperience:20171021134904p:plain

この時、ES向上とCS向上の因果関係の話になると、ふわっとした会話になることが多いです。(「従業員がご機嫌に働くと、顧客もご機嫌になる。。。」とか)

私の個人的な考えになりますが、その背景には、「ESが上がると(自動的に)CSは上がる」という思い込み(固定観念?認知スキーマ?)があるのではなないでしょうか?

■上記を顧客目線で考えてみると

当たり前のことですが、CSが上がるのは、提供されるプロダクトやサービスから得られる価値が上がった時なので、極論すると、顧客から見たときの、取引先の従業員のESはどうでもいいと思います。
(楽しそうに働いている人が担当なのは、顧客にとっての一つの価値ではありますが。。)

f:id:workerexperience:20171021135200p:plain

■ESが上がるとCSが上がるを実現するには

結論から先に言うと、従業員に対して、「より楽に、より顧客に感謝される/売れる状態**を提供できたときに、「ESが上がるとCSが上がる」状態になるのではないかと考えています。

従業員に提供するものは「システム」「ツール」「情報」「他のメンバーからのサポート」などいろいろなものがありますが(仮にこれらを「支援の仕組み」と命名します)、いずれも、従業員の業務をより生産的なものにするということで共通しています。

■ESが上がるとCSが上がるフロー

従業員に「支援の仕組み」を提供

従業員が「より楽に顧客に喜んでもらえそう」と展望が持てる。テンションが上がる(ES向上)

顧客が実際に喜ぶ(CSの向上)

顧客からの感謝の言葉で従業員が喜ぶ(ES向上)
業務が楽になる場合、さらに多くの顧客に商品サービスを提供

喜ぶ顧客が増える(CS向上)

売上UP、従業員の報酬増える(ES向上)

■ESが上がるとCSが上がる疑似相関の正体

上記ケースの場合、ESとCSの背後に「支援の仕組み」があり、これがまずはESを向上させます。その後、実際の業務を通じてCSが向上がするので、傍から見ると「ESが上がるとCSが上がる」ように見えるのではないかと考えられます。 

f:id:workerexperience:20171021135135p:plain

■まとめ

・報酬や休みを増やして仮にESが上がったとしても、CSは上がらない。
・「ESが上がるとCSが上がる」状態が実現されるのは、CSを向上に繋がる支援の仕組みを従業員に提供できたとき。

 

最後に、CSの向上のためには、ESの向上が必須な訳ではありませんが、
支援の仕組みの導入による「ESが上がるとCSが上がる」構造は、事業成長の強力な推進力となる、かつ、競合がマネしにくい隠れた競争優位に繋がるので、ご一考の価値はあるかと存じます。

本日は、以上です。

■補足

*「楽に」と言う言葉はあまり上品ではなく、「効率的に」と言った方が上品かもしれませんが、現場の実感からすると、やはり「楽に」の方が実態に近いので、その言葉を使いました。

合同会社ワーカーエクスペリンスを設立しました。

合同会社ワーカーエクスペリエンスという会社を作りました。
本日登記が完了しました。

 

今後、細々と活動についてブログを書いていければと思っています。

もし、業務内容や、これまでの活動、研究結果にご興味を持っていただけたら、適宜報告に伺うので、ご連絡よろしくお願いします。

そもそも、なんで会社を作ったか

以前の事業で多くの企業を見てきたのですが、変化が進めば進むほど、幸せになる人が減っていく世の中になる。そして仕事はつまらない(人がやっている意味がない)ものになっていくという感覚を持ちました。

一方で、幸せになる人が増える変化もあり、方法論的なものが少しずつ見えてきたので、それを社会で実証して行きたいと考えたからです。

ワーカーエクスペリエンス(WX)の定義

UXの働く人版。WXが高い状態を平たく言うと、
「この仕事をやっていてよかったな、これからもやっていきたいな」と思えること。

ES(employee satisfaction)という言葉を使わないのは、ESが語られる際に、「経営者が与えるもの」というニュアンスを感じるからです。(給料とか地位とか。。。)

WXは、経営が与えるものではなく、従業員が仕事を通じて自分で獲得する主観的な感情や体験などを指したものと考えています。

WXの構成要素

よくあるWXの上昇/低下に強く寄与するものを挙げます
 (ヒアリングや自分が担当している事業を見て感じた個人の一意見です。)

・自身の顧客(社内外問わず)や同僚に評価、感謝されているか

・顧客に対する後ろめたさはないか

・業務プロセスが効率的か(無駄な作業、手続きが多くないか)、効率は継続的に向上しているか(現状良くない状態でも、良くなる希望が持てれば○)

・上長の指示は、顧客価値や自身の成長につながるものか(社内でのポイント稼ぎが目的ではないか)

・今の仕事を続けていることが、スキルUP、報酬UP、雇用の安定に繋がりそうか

・経営層は、業績だけではなく、顧客価値UP、業務、育成に関心をもっているか(いわゆるBSCの下3つです)

業務内容

業務の効果/効率を上げるためのツール開発を中心に行っていきます。
(大変恐縮ですが、HRM関連のコンサル案件はお断りさせていただいています。)

これまでは、以下のようなことを行ってきました。
(もともとデータサイエンスの世界にいたため、データ領域での仕事が多いです。)

・データマネジメントの仕組みづくり
 >みんなが簡単にデータを使うためのデータマートの整備、集計ツール作成
 >担当者のスキルUP支援、利用者サポートなど

・業務自動化ツール開発
 >定常集計業務をVBAで自動化 

・営業効率化システム作成、業務フロー設計
 >顧客との会話に必要な情報をワンストップで使えるようにする
 >ベストプラクティスをまとめて、全員に共有するシステムの構築、運用設計、浸透

・データサイエンティスト、データ担当育成支援
 >SQLaccessexcelVBA含む)などのツール利用スキルUP
 >データの構造的理解、確率、統計などの数学的なスキルのサポート

 

これからよろしくお願いします。