先輩が作っていた売上管理のスプレッドシートを、ちゃんとしたデータベースに作り直したことがあります。
Cloudflare の D1 を使って、リレーショナルにデータを整理して、管理画面もつけて。正直そこそこいいものができたと思っていました。結果、誰にも使われませんでした。
毎週不満が出るスプレッドシートだった
Web制作会社で働いていて、社内でいくつか自社ツールを作ってきました。CLIで動くだけのPythonスクリプトから、Electronで動くアプリ、Cloudflareにデプロイするもの、Cronで定期実行するものまで、形式はいろいろです。
その中の一つが、先輩が作った売上管理のスプレッドシートを置き換える話でした。
正直、見にくかったんです。構造にも改善の余地があって、そもそもスプレッドシートで管理すること自体が限界に来ているような状態でした。毎週のミーティングで、他のメンバーからも「これ直した方がいいのでは」という声が上がるくらいには。
継ぎ足し継ぎ足しで場当たり的に直しても、もう無理だなと思って、自分の方で作るかとなりました。D1でリレーショナルデータベースを組んで、オブジェクト指向っぽく整理した管理ツールを出しました。使いにくいところがあればすぐコードで直せる、という体制も整えて。
それが、全く使われませんでした。
「これは自分の仕事の否定だ」と思わせてしまった
なんで使われなかったんだろう、と後から考えて、理由は2つあるなと思いました。
一つは、先輩がこれまで作ってきた仕組みを、否定するような形で作ってしまったこと。しかも先輩と直接すり合わせたわけではなく、「他のメンバーからも不満が出ているし、作っておくか」くらいのノリで動いてしまったんですよね。先輩に「どうします?」と相談するところから本来は入るべきだったのに、動くプロトタイプを先に作ってしまえばいいだろう、と思ってしまった。
要件は分かっていたんです。仕事内容も把握していたので、何を作ればいいかは見えていました。でも、使い手の気持ちというところが完全に抜け落ちていました。先輩からすれば、自分が作り上げてきたものを否定されるような感覚になるし、受け入れるとしてもかなり気持ちを整理してからじゃないと無理な話だったと思います。
もう一つは学習コスト。スプレッドシートは、多少不便でもみんな使い方が分かっているものでした。いくら使いやすさを意識したとはいえ、新しいツールを覚える必要がある、というだけでハードルは上がります。
この2つが重なって、いくら中身がいいものでも、そもそも受け入れられる土俵に乗っていなかったんだと思います。完全にコミュニケーション不足でした。
逆に、めちゃくちゃ喜ばれたものもある
一方で、すんなり受け入れられたものもありました。
あるクライアントワークで、毎日相手先のサイトを確認して、そこに書かれている金額をコピーしてHTMLに貼り付けて修正する、という単純作業がありました。毎日30分くらいかかるタスクです。これをスクレイピングで自動化して、完全に手を離れる形にしました。
これは普通に感謝されました。誰もやりたくない作業がゼロになっただけで、仕事を奪われたと感じる人は誰もいなかったんです。
社内の別の部署が関わる業務でも似たようなことがありました。個人的には「これブルシットジョブなのでは」と思うようなタスクがあって、担当しているメンバーもやる気が起きずに滞留していました。そこに手軽に使えるツールを作って配布したら、これも割とすんなり受け入れられました。
仕事を増やす提案と、仕事を減らす提案
並べてみて、自分の中で一つ確信になったことがあります。人の仕事を増やすものは受け入れられなくて、人の仕事を減らすものは受け入れられる、ということです。
一般化するとそれはそうだろう、という当たり前の話ではあるんですけど、本当にこれに尽きるなと思っていて。もちろん「仕事は増えるけどクオリティが上がる」という提案が一概にダメというわけではないです。ただ、通りにくいのは確かで、特に新しい職場に入ったばかりで信頼をまだ積んでいない段階だと、仕事を増やす方向の提案は控えて、まず信頼ポイントを貯めることを優先した方がいいなと思うようになりました。
売上管理ツールの一件は、良かれと思って作ったものが、先輩の仕事へのリスペクトを欠いた形で出てしまった失敗でした。スクレイピングの自動化やブルシットジョブの削減は、本人もやりたくないと思っている作業を完全に奪い切ったから受け入れられました。
いいものを作れば使われる、わけではなくて、それを使う人がどう感じるか、というところに結局全部かかっているんだなというのが、今のところの実感です。