おもてなしのススメ

どうも〜。お昼に家の残り物とはいえ、パンと納豆を食べた私です。

仕事柄、仕様書の類を作ったり読んだりすることは多いのですけど、こういうものは本当に読まない人が多いです。

だいたい仕様書なんて100ページ以上は当然にあります。
下手したら100ページ以上の仕様書が数冊あって、ちょっとした百科事典クラスのボリュームです。
そんなもの、きちんと読んでいる人なんていないですよ、きっと。

またソフトウェア開発の人に限らず、一般の人もたとえば家電を買ったときに添付されてくる説明書をきちんと読みますか？
ざっと目を通す人が半分、ほとんど読まないのが半分、という感じがします。

ということで、結論はちゃんと仕様書・説明書を読め・・・

ということではありません。

仕様書・説明書を読まなくてもいいような製品を作ることを心がけようじゃないか、みんな！というのが私の意見です。

消費者は説明書を読まなくても理解できる製品を利用してハッピー、というメリットがあります。
強調したいのは売り手である企業側のメリットです。
思いつくだけで、これだけあります。
・製品保証のコストが削減できる*1
　保証のサービスに対するコストは高い！
・消費者へのイメージアップ
　「あの会社の製品って使いやすいから、あの会社の別の製品も買おうかな」ということも考えられる
・その他、もろもろのコスト削減
　仕様書作成コスト、営業から顧客に対する説明(わかりにくい製品は説明も長く、顧客がその製品を理解するための壁も高い)

まぁ、つまりは「おもてなし」が大事ということなんですね。

これにより買う側も売る側もハッピーになっていく、と思うのです。

以下のような光景、私は頻繁に見るのですけど、いかがでしょうか。

(顧客)「〇〇のように利用していたら、こういう故障が発生したのですけど」
(企業)「申し訳ございませんがそういう風に利用しないで下さい、って説明書に記載しておりますが？」
(顧客)「ごめん、そこまで読んでなかった。でも保証期間中だから直してくださいよ。」
(企業)「かしこまりました。配送手配をいたしますので・・・(略)」

こういうことって買う側、売る側ともになくしたいと思っているでしょう。
地道にがんばっていきましょう。

以上、開発者のはしくれの一言でした。

*1:故障原因とその対応方法等が保持されたデータベースを持っているはずだから、過去の製品のそれとを照らし合わせた製品開発を心がければいいですね