2020年の活動報告_事業内容は業務生産性向上・DX案件が8割でした。
8月末で3期目が終わります。
ここまで事業が続くと思ってなかったので、正直自分でも驚いています。
皆様のご支援や応援のおかけだと思っています。いつもありがとうございます。
最近「どのような事業をやっているのですか?」と質問いただくことが増えてきたので、この1年で行った業務を報告いたします。
※詳細な資料は今後作るので、興味がある案件があった場合は、Facebookなどにメッセージください。
●WXの事業の大分類と構成費
事業内容は、大きく5つに分かれました。
A:業務生産性向上1、日常業務の改善 (50%)
B:業務生産性向上2、新しい業務の導入、R&D、DX(30%)
C:データ運用体制の構築、担当者の育成、マネジメント支援(10%)
D:投資家、経営ボードとの円滑なコミュニケーション支援(5%)
E:その他:ビジネスグロース支援、データ分析・ロジック作成(5%)
8割がA、Bの「業務生産性向上支援」です。(業務生産性を向上させる対象は営業、スタッフ、企画など様々ですが。。)
私は生産性が向上することに大きな喜びを感じるため、それも影響しているからかもしれません。
以下でA、Bの概要を記載します。(C~Eはニーズがあったら書きます。)
※事例をそのまま出すのは問題があるので、複数の事例を1つにまとめて記載しています。
A:業務生産性向上1、日常業務の改善 (50%)
A-1:スタッフ向け、モニタリングの自動化
業務内容・お困りごと
経営ボードへの報告資料を毎月作成しているが、
「様々なデータソースからデータを取得」「スタッフが属人的に集計」しており、
データミスが頻発&スタッフが疲弊。効率的に間違いない報告書を作成したい。
対策
・データソースの構造化(入力欄の定義、リレーションを張れるキーを追加)
・データ集計の自動化(エクセルVBAで集計)
・報告フォーマットに貼り付け自動化(エクセルVBAでパワーポイントを作る)
現状の結果、成果
・不備発生率は1/3程度、工数は1/5程度
・今後の課題は営業への入力ルールの徹底のところ(守らない人が一定数含まれる)
A-2:営業向け、顧客提出レポートのセントラルキッチン化
業務内容・お困りごと
・営業が顧客に提出するレポート(振返り資料、利用率など)を自作する必要があった
・1通1時間×営業人数1500人×月8件=12,000時間/月の業務工数が発生
・工数が取れず資料を作成しない営業も存在。顧客との会話ができてないケースも散見
対策
・汎用的な顧客向けレポートを一括で作成して、担当営業に配信する
・また営業からの要望を受けて、汎用レポートを改善していく。
現状の結果、成果
・業務時間が、6割程度削減
・顧客との会話数も増加(インタビューベース)
・顧客向けレポートの最低品質は担保できるようになってきた。
・今後は、レポートを使い、次の商談につなげるやり方を模索
B:業務生産性向上2、新しい業務の導入、R&D、DX(30%)
B-1:営業向け、提案用BIシステムの作成
業務内容・お困りごと
・営業が顧客と会話するときに必要なデータをそろえるのが時間がかかる(1社2時間)
・準備して持って、商談時にいろいろ聞かるとデータを出せない。
・(特に新人ほど)データで顧客からの信頼を担保できないと売れない
対策
・相場情報やマーケット情報などを検索して顧客に提示できるシステムを作成
>Rails、AWS
※体制は私+外部のエンジニアの計2人
現状の結果、成果
・営業の準備時間は平均2時間→30分程度に圧縮
・10%程度の売上UP寄与(インタビューベース、独立で計算することが出来ないため、営業の印象値の合計です。)
・今後は、R&Dの体制から本格運用の体制に移行。顧客内で体制を作ってもらうことが新たな課題です。
B-2:スタッフ向け、営業との情報確認ツールの作成
背景・お困りごと
・メディアを取り扱う企業で、表記や掲載基準について営業からの問い合わせに対してスタッフが回答
・当初メールで行っていたが、メディアが成長するにつれ、メールが膨大になり多大な工数が発生
対策
・問い合わせ業務の再設計
>問合せフォーマットに記載、受け付け締め切り、回答期間を設ける
・問合せフォーマットの作成、営業現場への展開・回収、問い合わせスタッフへの展開のツールを作成
>アクセス+エクセルVBA
現状の結果、成果
・問い合わせスタッフの体制は縮小できそうなことが見えてきた。
・締切り日については多少チューニングが必要。今後調整していく。
以上です。
【経営層向け、1分読了ver】現場のオペレーションの問題を放置すると、自分の首が絞まるという話
2か月間で、結構多くの経営層(部長以上)の方々に
「オペレーションの問題の放置が、あなたに与える悪影響」という話をしてきました。
なるほどと言ってくれた方が多かったので手短かに共有します。
●「経営者の首が締まる」構造(個人の経験からの考察)
1:ビジネスは「業務の連鎖」で構成されている。
2:職場で権力を持つのは、「偉い人」ではない。
「業務の連鎖を前に進める人」「業務の連鎖の問題を解決できる人」が権力を持つ
3:オペレーションが非効率だと、現場の作業者の属人性が上がる確率が高い
4:属人性が上がる、その作業者なしでは事業が回らない。(彼らの権力が上がる)
5:結果、その作業者の業務が優先され、目標・戦略変更、それに伴う業務変更などの実行が困難になる。(→経営者の首が締まる)
「現場のオペレーションは自分には関係ない」「オペレーションと戦略は別」的な
対応をしていると、組織が動けなくなるリスクが高まるのでご注意ください。
●予防策、解決策例
・1人しかできない業務を探して複線化する
>人が足りないのであれば、アサインしたほうがよいと思います。
ここを放置すると、問題が大きくなり始めます。
・現場の「困った」を放置しない
>作業者が属人的なやり方で解決して、属人性が上がる
>作業者のヘイトが溜まり、組織信頼が下がる。(誰も助けてくれない。。)
・自分しかできない業務を、他の人ができるようにすることを評価
>評価基準を変える。
・定期的にチームで業務を棚卸する
>効率化の要素がないかを確認して修正
>誰ができるかをチェックしてローテーション
※経験的には複線化の非効率より、属人性排除・業務効率向上の恩恵が大きい
●補足(個人な意見)
・「コストの都合上、作業者をアサインできない」という声もよく聞きますが、
問題を放置するほうがコスト高/機会損失高になると思います。
・作業者は権力を「持ちたい」というか、「持ってしまっている」ケースが多い
(「自分でなんとかしなきゃ」ってなる)
属人性をゼロにはできませんが、オペレーションにおける「非属人性度」は
経営者が見るべきKPIの一つだと考えています。
「データ活用」成功のコツは、冷蔵庫にある食材で手早くご飯を作る感覚に近い。
最近「データの活用」に関する仕事が増えてきたので、
今日はその中から見えてきた、成功率を上げるコツを共有します。
「商品開発に顧客視点を取り入れたいので、顧客情報を収集・活用できる仕組みを新たに作りたい。」などの相談が多いのですが、
まずは、プロジェクトの開始を再度検討する/場合によっては見送る方が良い場合から説明します。
やめた方がいいケース1
・現在手元にないデータを新たに取得することから始める。
顧客情報の取得方法は、Twitterを見る、店舗に立つ、お客様インタビューなど、いくらでもあるのに、現状データがないのであれば、実は顧客情報がそこまで必要だと思ってない可能性が高い。
あと、自動で貯まり続けるデータでない場合は、取り続けることに多大な労力がかかることが多いので、継続的にデータが取れないことが多い。
やめた方がいいケース2
・活用目的と取得するデータが明確に決まっている。(決まりすぎていて、変更できない)
データが何に活かせるかは、実際にデータを取得してみて初めてわかることが多い。
やってみる前に目的とデータをガチガチにすると、
プロジェクトの途中で身動きが取れなくなることがある。
(場合によっては成功を演出するという不毛な努力をすることになってしまう。)
プロジェクトを開始する前に、まずは「本気で必要としているのか?」「当初の目的とは異なる結果になることを受け入れられるのか?」を正直に確認することが重要だと思います。特に「事業の戦略上の要請」「これからの時代はデータ活用」等の言葉からプロジェクト検討が始まった場合は、特に念入りに確認した方がよいかと。
上記をクリアした上で、コツ編に移ります。
まずは1つ目のコツはプロジェクトのはじめ方です。
コツ1:ゴールは多く、データは幅広く、手軽に始める
成功したプロジェクトの勝因を振り返ると、共通して3つの要素がありました。
・担当者が 現場のお困りごとをたくさん知っている。
(現場に詳しい、現場スタッフと仲良し。)
・自社にあるデータを広く自由に使える。
(使えるデータが制限されていない)
・できそうなことから手軽に始める。
(大規模投資しない、現場に「データ収集して」とか言わない、難しいことはしない。)
理由は、当たり前なのですが、以下の通りかと考察しています。
・現場で解決したいお困りごとが多いほど、「的」が増える。
・扱えるデータが増えるほど、出せるアウトプットの幅が広がる。
・手軽に始められると、試行錯誤や失敗が許されたり、少しでも役に立ったら何でもいいと評価されるので、現場の役に立つことを素直に追求できる。
図示すると、以下のとおり
続いて、2つ目のコツはプロジェクトの成果を大きくするコツです。
コツ2:最初は小さな成果から、成果は徐々に大きくしよう。
プロジェクトの最初の方はリソースが足りないため、大きな成果を狙ってもうまくいきません。
↓リソースが足りない例
・データが足りない
・現場の信頼がない(お困りごとが集まらない、データの取得/利用の協力が得られない)
・経営からの信頼がない(人、金、時間の投資が限定的)
・担当者のスキル・経験が足りない
なので最初のうちは、「現場の具体的な問題を、手元にあるデータで解決する」ことに注力して、小さな成果を積み重ねながら、上記の4つリソースを増やしていくことが重要だと思っています。
いつもこの感覚がうまく伝えれないので、料理の例で例えると、
自分が料理人で、お腹がすいているお客様が来たとして、
「作れるかどうかわからないご馳走を時間をかけて作ろうとして失敗する」よりも
「冷蔵庫の中にあるもので自分が作れるものを速く作って出す」ほうが
次に繋がる(≒再来店)の可能性が高いことと一緒だと思います。
お腹が減っている人(困っている人)を探して、ありもの(今あるデータ)を使って、
速く料理を出す(出せるレベルで集計・分析結果を示す)ことが重要です。
(伝わるでしょうか。。。)
小さく始めてリソースを集めながら、大きくしていくアプローチは、遠回りに見えますが、このやり方が結果として一番速くプロジェクトの成果が大きくなりました。
大きな成果をすぐに出したくなる気持ちはわかりますが、「出来ないことは置いておき、できることに集中する」ことをぜひ心の片隅に置いておいてください。
余談:経営者の皆様へ
若干蛇足ですが、経営者の善意が、成功し始めたプロジェクトを失敗に追い込んでしまったことを少なからず見てきたので、最後に触れさせてください。
それは、「過剰な期待・投資をプロジェクトにしてしまうこと」です。
例えば、
・プロジェクトの人数を倍にする
当初のメンバーが新人のサポートで忙殺される、チームワークが崩れる、新人に仕事を敢えて作る必要が出てくる。
・多額のお金を投資する
金額が大きいほど、成果・説明責任が大きくなる。探索的な仕事なので、
成果が出ないと、無理に成果を演出しなければならなくなる。
また、お金を使うのも時間がかかる。
データ活用プロジェクトは、担当者の経験・スキル、担当者内や現場とのチームワーク、データ取得の仕組み構築など、時間がかかるものが多く、成長スピードを予測するのは当初困難です。
なので、「欲しいものがあったら言って来いよ」くらいの緩さで暖かく見守っていただけると良いかと思います。
最後に、データの活用は多くの企業にとって価値のあるものだと思いますが、
探索的であるため、直接的な投資を増やしても成果に直結しないという難しさがあります。
ただ、無理のない範囲で、一歩ずつ薦めることで、顧客価値の向上や、従業員の生産性向上/楽しさ向上を生み出す大きな可能性があるものだと信じています。
もっとデータを活用したいと思っている方々にとって、
少しでも役に立ったなら幸いです。
最後まで読んでいただき、ありがとうございました。
提案:エンジニアに気軽に「バグ」というのはやめませんか?
もしかしたら私だけかもしれないです。ずれているかもしれません。
一般論ではないかもしれません。
でも、同じような気持ちになっているエンジニアがいるかもしれないので、
代表して言わせてください。
エンジニアに、気軽に「バグ」と言うのをやめませんか?
最近立て続けに以下のようなことが起こっており、私と同僚が消耗しています。心がすり減ってます。ワーカーエクスペリエンスが低下しています。。。
~~~~~~~~~~~~~~~~~~~
「○○さん、この数値がバグなんだけど直してもらえる?」
→調べたらその週は祝日影響で、営業日が少ないだけだった。
「あのデータのバグはいつ直りますか?」
→データの集計定義の変更の依頼があり、変更前の状態をバグと呼ぶ
「この前入ってなかったバグなんだけど、次の開発に入れてもらっていい?」
→スコープ外のこと(担当がそれを忘れていた)をバグと呼ぶ
~~~~~~~~~~~~~~~~~~~
言った本人からしたら、「想定通りになってないこと」=「バグ」と言っているのだと思いますし、何原因かよくわからないから、とりあえず「バグ」と言っているのだと思いますが、実は、これがかなりの心理的ダメージをエンジニアに与えることがあります。
「バグ」と言われると、私にはさまざまな負の感情が押し寄せます。
●事象の確認中
・何がおかしかったんだ、どこで間違っているのか(不安と焦り)
・やばい、迷惑かけた、叱られる、非難される(恐怖)
・影響範囲は?なんでもっとしっかりテストをやらなかったんだ(後悔)
↓結果
●確かにバグだった場合
・ごめんなさい。すぐに直します。(反省、罪悪感) ←これも当然起こります。この場合は謙虚に受け止めます。少なくとも「仕様です」とかは言いません。
●バグではなかった場合
・とりあえず良かった(安堵)
・てゆうか、気軽にバグって言ってほしくない、てゆうか、なぜ彼がバグ判定ができるんだ?(怒り、不信、脱力感)
この「バグではなかった場合の心の乱れ」が想像以上に大きいのです。
「大した確認も取らずバグって断定されること」がとても辛いのです。
心あるエンジニアは、バグを出さないように、迷惑かけないように心を砕いて作っています。人間なのでバグは出してしまう点は恐縮ですが、その点をご理解いただけるととてもありがたいのです。
ちなみに、「バグ」の定義は、以下のうち、狭義のバグは4、広義だと3も入る場合があると思っています。
(要するに、エンジニアの責任範囲がどこかということ。)
1:そもそもユーザーの認識が間違っている。
2:要望のことをバグという。
3:要望を仕様に落としたところが間違っている
4:プログラムのミス
上記を踏まえたうえで、「あれ?おかしいな」と思ってもらった場合は、以下のように言っていただけると大変ありがたいです。(こう言ってくれたら、嬉しいです。消耗しません。)
●基本スタンス
・明らかにバグと断定できる場合以外では、自分から「バグ」と言わない。(自信がないなら、「バグ」という言葉自体を使わないでも大丈夫です。)
・起こっている事象と、再現方法を説明し、確認を依頼する。
●伝え方例
「このページに出ているこの数値なんだけど、○○だと思っているのだけど、その認識で合ってるかな?ちょっと確認してもらってもいい?」
「ここのボタン押すと、TOPページに戻ってしまうのだけど、確認してもらっていい?」
何が違う?と思う方もいるかもしれませんが、「伝える側が間違っている可能性があることを踏まえて伝える」「バグかどうかの判断はこちらに委ねてもらう」だけで、受け取り手(特に私)の心理的負荷は下がります。
めんどくさくてすみません。
最後に、たぶん蛇足ですが、心理的負荷がどの程度かを例をあげて伝えさせてください。
「○○さんバグじゃない?」といきなり言われることは心理的負荷は、例えるなら、
「○○さん口が臭くない?」といきなり言われるのと同じぐらいです。そこでおたおたしていたら、「ごめん。私が放置したごみが腐ってた。気にしないで」と言われる感じです。適切な例えではないかもしれませんが、伝わったでしょうか????
私たちもすべてのバグをつぶせるわけでもなく、ユーザーの方に指摘をしていただけるのはとてもありがたいのですが、伝えるときにちょっとだけ、ご配慮いただけるとありがたいです。
私のくだらない独白を、最後まで読んでくれてありがとうございました。
「ESが上がるとCSが上がる」という都市伝説。というか疑似相関について。
「CSの向上のために、まずはESを上げるべきだと思う。」「ESは上がった気はするのだが、業績に結び付いている気がしない。なぜだろう?」という相談をよく頂きます。
多くの方との会話を通じて、私個人としては、「ESが上がれば(自動的に)CSが上がる」は都市伝説であると考えるようになったので、今日はそのことを書きます。
■よく伺う相談内容
ざっくりいうと、「ESを上げるために、有休促進やリモートワークやフレキシブルな勤務形態を導入したが、かえって生産性が下がり、顧客クレームも増えた。」
「CSを上げるには、まずはESからということで、一律でベース給を上げようと思うのだけど、どう思いますか?」的なことが多いです。
この話を図示するとこんな感じでしょうか。
この時、ES向上とCS向上の因果関係の話になると、ふわっとした会話になることが多いです。(「従業員がご機嫌に働くと、顧客もご機嫌になる。。。」とか)
私の個人的な考えになりますが、その背景には、「ESが上がると(自動的に)CSは上がる」という思い込み(固定観念?認知スキーマ?)があるのではなないでしょうか?
■上記を顧客目線で考えてみると
当たり前のことですが、CSが上がるのは、提供されるプロダクトやサービスから得られる価値が上がった時なので、極論すると、顧客から見たときの、取引先の従業員のESはどうでもいいと思います。
(楽しそうに働いている人が担当なのは、顧客にとっての一つの価値ではありますが。。)
■ESが上がるとCSが上がるを実現するには
結論から先に言うと、従業員に対して、「より楽に、より顧客に感謝される/売れる状態**を提供できたときに、「ESが上がるとCSが上がる」状態になるのではないかと考えています。
従業員に提供するものは「システム」「ツール」「情報」「他のメンバーからのサポート」などいろいろなものがありますが(仮にこれらを「支援の仕組み」と命名します)、いずれも、従業員の業務をより生産的なものにするということで共通しています。
■ESが上がるとCSが上がるフロー
従業員に「支援の仕組み」を提供
↓
従業員が「より楽に顧客に喜んでもらえそう」と展望が持てる。テンションが上がる(ES向上)
↓
顧客が実際に喜ぶ(CSの向上)
↓
顧客からの感謝の言葉で従業員が喜ぶ(ES向上)
業務が楽になる場合、さらに多くの顧客に商品サービスを提供
↓
喜ぶ顧客が増える(CS向上)
↓
売上UP、従業員の報酬増える(ES向上)
■ESが上がるとCSが上がる疑似相関の正体
上記ケースの場合、ESとCSの背後に「支援の仕組み」があり、これがまずはESを向上させます。その後、実際の業務を通じてCSが向上がするので、傍から見ると「ESが上がるとCSが上がる」ように見えるのではないかと考えられます。
■まとめ
・報酬や休みを増やして仮に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で自動化
・営業効率化システム作成、業務フロー設計
>顧客との会話に必要な情報をワンストップで使えるようにする
>ベストプラクティスをまとめて、全員に共有するシステムの構築、運用設計、浸透
・データサイエンティスト、データ担当育成支援
>SQL、access、excel(VBA含む)などのツール利用スキルUP
>データの構造的理解、確率、統計などの数学的なスキルのサポート
これからよろしくお願いします。