- 陥りがちな罠
- 罠のどこが罠なのか
- 何を軸に管理したいのかを考える
- 軸の決め方
- 単位はなんなのかを検討する
- 管理の軸には固有のIDを持たせる
- 管理の軸(固有のID)はどのデータでも常に一番左におく
- 管理の軸の取得方法を考える
- ゆるおすすめ本コーナー
陥りがちな罠
皆さん忙しいので、割と何も考えずにスプレッドシートを作って、とりあえずなんとなくで管理を始めます。必要に応じて列や行を増やしながら。私もそうでした。
やめてください。それは絶対に失敗します。笑
私がよく目にするのはこういうシートです。
何がダメか。
- 法人単位で管理するのなら法人名列には法人が複数回出てくるような作りにはしてはいけない
- 同じ法人名なのに表記揺れしている
- 施策は施策単位で管理する(ケースバイケースですが)
- 施策名が統一されていない(「ウェビナー」と「ウェビナー施策」など)
- 施策が複数管理されることで、対応状況にいろんな要素ができてしまい、どんな状態か一目でわからない
- 施策単位で管理したい項目が違うため、メール施策でのみ有効な「開封状況」のような列がどんどんできていく
罠のどこが罠なのか
これらの何がダメかというと、管理できているようで何も管理できていないのです。
施策の効果を確かめようにも一筋縄では何も出せません。似たような法人名の顧客が複数いた場合にわからなくなります。結局このスプシから他の場所にコピーしていろんな計算式を入れて・・みたいなことを毎週とか毎月おこなって無理矢理進捗を出すわけです。無駄な時間をかけて。
そしてある程度やっていくと、これ非効率だなと感じるわけですが、ある程度決まってしまった運用を覆すことは心的な負担が大きいものですから、後戻りがどんどんできなくなるわけです。
しかし、スプレッドシートは最大が500万セルと決まっているものですからあっという間に入力ができなくなります。
そうするとどうするか?同じ運用で新しいシートを作ります。これで過去とは分断されるので、分析のようなことは非常に難しくなる。そこで[ importrange ]のような一見魔法のような関数に出会うことでしょう。ガンガン多用していく。そうすると何も読み込まなくなる・・日常業務がスプシの読み込みとの戦いになる・・・
これ私が体験したことです。皆さんは同じような罠にはまらないで欲しいのです。
何を軸に管理したいのかを考える
じゃあどうしたらいいのか?って話ですが、
- そのスプレッドシートでは何を管理したいのか?
- そのためには何を軸に管理すべきか?
ということから考えましょう。
軸の決め方
本当にこれはまちまちだと思うのですが、スプシで管理しようと考えるような状態っていうのは会社やプロジェクトなどがかなり初期で定まらない時だと思います。
おそらくそのような時に管理したい項目は、どの顧客にどのような施策を行い、結果としてどのような状態になったのか、などだと思います。ですので管理をしようと考え始めた時の軸には基本的に「企業」や「顧客」で考えることをお勧めします。
軸さえしっかり押さえておけば、後から変化があってもある程度柔軟に対応していけるためです。
ただし、それはどのような管理をしたいかという全体像にもよります。
- メール施策のように各顧客単位での状況があまり重要視されず、開封率や件名だけを管理し、顧客単位ではメールを送付したかだけを把握したい
- ウェビナー施策の場合はどのウェビナーに何人くらい参加したかや、アンケート評価がどの程だだったのかを把握して次回のウェビナーに活かしたい
など、管理することには目的があります。施策の大小や、管理の目的が全く異なる場合はスプシを別にすることが望ましいでしょう。やっていくうちにわかると思いますが、何を管理しているのかわからなくなり、最終的に非常に使い勝手の悪いものになります。
単位はなんなのかを検討する
管理軸が決まった場合にその中でも単位を考えます。私の在籍していた会社の場合、法人の下に施設が紐づいていました。
飲食店で考えると、和民という会社との契約は1法人との契約ですが、実際にはその下部に何百店舗も紐づいていたりします。そうすると法人で管理すべきか、店舗で管理すべきかということになります。
各法人単位で管理したりやりとりするのであれば、法人を中心として管理すべきかもしれませんし、上の図でいう、飲食店単位で管理しなければならないのであれば、飲食店舗単位での管理が必要となるでしょう。
顧客の平均単価や、対応人数などでおそらく対応方針がおおよそ決まってくるかと思いますが、悩ましい場合は最小単位(飲食店舗)で管理しておくのが無難かなと思います。
管理の軸には固有のIDを持たせる
そしてこれ地味に重要なのですが、管理の軸には必ず「固有のID」を持たせておきましょう。先ほども書きましたが、名称だと絶対に表記揺れがおきます。これにより正しいデータが取得できないっていう失敗は一度やってしまうと結構長い間つきまといます。
これだけ、早期にやってあるだけでも将来のスケールのしやすさは全く違うと思います。
管理の軸(固有のID)はどのデータでも常に一番左におく
管理の軸が決まり、固有のIDを設定したら、特段の理由がない限りは、固有のIDは常に一番左に設置しましょう。
これは、恐らくスプレッドシートで管理する上で絶対に必須となる「VLOOKUP関数」の仕様によるものです。このタイミングでお話をすると混乱すると思うので、詳細は別の機会に解説いたしますが、とにかく軸が左にないとめっっっちゃ使いにくい!!!!と覚えておいてください。笑
ここまでのお話を整理すると、
こんな感じでしょうか。こうなるとだいぶ先々の発展性や、施策の状況が把握しやすくなります。
管理の軸の取得方法を考える
最後に考慮しておいて欲しいのが、この管理の軸(法人名、飲食店名)と固有のIDはどのようにこのシートにもれがなく持って来れそうかということです。この辺りしっかりフロー化されていないとほぼ確実にもれます。笑
開発や営業とすり合わせておく必要があるかと思いますので、各部署にとって良い方法を検討してみてください。
ゆるおすすめ本コーナー
ランダムで過去読んで何かしらのためになった本を何冊かお勧めします。
【1984/ジョージオーウェル】
ある全体主義的な国家で全てが管理されている世界が舞台です。小説としての面白さもさることながら、この国で使われている言語「ニュースピーク」というものが凄いのです。「ニュースピーク」は元あった言語を破壊します。どういうことか。言葉には色々な意味がありますよね。「良い」「悪い」みたいな言葉一つ取っても、「素晴らしい」「完璧」「最低」「好ましくない」など近しいけども違う言葉というものがたくさんあります。それらを通して人は思考しているわけです。しかし「ニュースピーク」では「良い」という言葉を基準にもっと良い場合は「加良い」もっと良い場合には「極良い」など不要な言葉を排除し、序列を表す言葉と、ベースとなる言葉で全てを表現しようというのです。言葉の機微は失われ、徐々にそれを使っている人々の思考をも奪われていくのです。