「天敵はGoogleスプレッドシート」という誤解。PdMが実務で学んだDXの本質
こんにちは！
RENOSYで不動産取引のオンライン化に向けて、企画開発を鋭意推進中のプロダクトマネージャー小野寺です。社内では「でらちゃん」とか「でらさん」などと呼ばれています。
今回のnoteは、RENOSYで理想の顧客体験を目指すために実務オペレーションを変更しようとしたら、Googleスプレッドシートが立ちはだかった、というお話しです。
これまであまり外部に発信することはしてこなかったのですが、不動産取引オンライン化のこの過渡期にPdMとして関わらせていただいているので、その裏でどのようなことが起きているのか、ということをPdM視点でお伝えできればと思っています。
先にお伝えしておくと、noteでは不動産業界特有のマニアックな話をするつもりはなく、どちらかというと、PdMとしてプロダクトの企画開発や事業推進に携わる中での学びがメインになります。
今回のnoteも、プロダクトの企画開発で陥りがちな、あるあるな話だと思いますが、それだけでは何の役にも立たず面白くないと思うので、その先の話にまで踏み込んで、自戒も込めながら「で、どうしたのか」といった部分までを書いていきたいと思います。
自己紹介
その前に「そもそもお前だれ？」という感じだと思いますので、軽く自己紹介させていただきます。
私は静岡県浜松市出身の28歳です。少し前まで30代半ばとか酷い時には40手前とかと言われることもありましたが、最近は徐々に歳相応の見た目に近づいてきています（自称）。
GA technologiesに入社する前は、大学時代まで含めるとベンチャー2社にいました。
※その辺りのことは、こちらのインタビュー記事でも詳しく話させていただいてますので、ご興味ありましたらこちらをご覧ください！
私がGA technologiesに入社したのは上場する2年前の2016年。社員数はまだ70名ほどでした。入社当時はオウンドメディアの運営を担い、その後すぐにデジタルマーケティングチームに異動して、3年ほど広告業務に携わりました。
当時のデジタルマーケティングチームは私含めて2人しかおらず、内製する社内リソースも当然なく、広告代理店や制作会社の力を借りながら試行錯誤の毎日でした。
その2人体制というのも半年くらいでもう1人の方が転職されてしまい、デジタルマーケティングチームと言いつつ、メンバーは私1人の状態が1年続きました。
急に1人で月数千万円の裁量を持って広告を回すことになり、私はまたと無いチャンスと意気揚々と1人体制を謳歌していましたが、社内はアイツ1人で大丈夫かなとかなりヒヤヒヤだったと思います。
心配した他の社員の協力もありなんとかなりましたが、樋口社長に毎週レポートして直接進捗を追われるなど、毎月毎週毎日をやり抜くためにひたすら目の前の数字と戦うという感じで、この時期が一番社会人として鍛えられた気がしています。
その後、現CMO（Chief Marketing Officer）の田吹さんが入社され、集客や分析、企画デザインなどの機能を持つPPD（Product Planning Divisionの略）という組織ができ、現在はRENOSY不動産投資サービスのプロダクトマネージャーをしています。
↓こちらの記事でインタビューに答えているのが田吹さんです。
目下はPdMとして、不動産取引のオンライン化を実現すべく企画開発を推進しています。
冒頭でも少しお伝えしていた「不動産取引のオンライン化」は、決算説明資料を引用してお伝えすると、以下の①〜⑤に該当する部分をすべてオンラインでお客様が能動的に進行できるようにすることを目指しています。
まさに、お客様への不動産取引プロセスのオンライン解放です。
※この辺りのことはまた別のnoteで詳しく執筆しようと思っています。
オンラインでもリアルの実務オペレーションが鍵を握る
さて、ようやくこのnoteの本題なのですが、不動産取引のオンライン化をしていく上で切っても切り離せられないのが、それを裏で支える社内の実務オペレーションです。
PdMとしては、表面となる顧客体験をゼロベースで考えていくわけですが、その実現のためには当然ながら、その裏面となる実務オペレーションも考える必要があります。
「お客様のマイページではこの表示をしよう、そのためには管理画面でこう入力できるようにしよう」
「オフラインではこの案内をして、マイページではこの案内を通知と共に出そう」
といった具合に。
入力と出力という見方をすると表裏一体なので当たり前なのですが、その中で悩みの種になってくるのが、実務の現場で使われている「Googleスプレッドシート」の存在です。
「天敵はGoogleスプレッドシート」という誤解
業務の進捗管理をする上で便利過ぎて半端ないGoogleスプレッドシートは、私も毎日使っています。ですが、この表と裏の関係を理想の顧客体験に合わせて成立させようとした時には、天敵のような存在に思えてきます。
（※個人情報は当然CRMで管理されています！）
なぜなら、
「その情報、最新で正しいものはGoogleスプレッドシートにあります！」
「じゃあGoogleスプレッドシートからお客様のマイページに情報を表示しようか！」
なんてことはできないからです。
（やろうと思えばできるとかという問題ではなく！）
だからと言って、実務側の管理画面にその機能を実装しても、今度は業務が回らなくなる。
だって業務管理する上では、動作も軽く、網羅性にも検索性にも優れ、その上カスタム性のあるGoogleスプレッドシートが最強で便利すぎるんですもん。。
もしも管理画面に代替できる機能があったとしても、Googleスプレッドシートの方が便利であれば、実務の生産性をあげたい現場からしたら無慈悲にもGoogleスプレッドシートを選択せざるをえない。
たとえ、管理画面の機能で代替できたとしても、現場ではまた別の用途のGoogleスプレッドシートが誕生していたりします。
そしてそれに対して、Googleスプレッドシートを敵対視し、それに代替する機能で解決しようと、Googleスプレッドシートとのイタチごっこが始まってしまうわけです。
しかし、天敵はGoogleスプレッドシートというのは誤解であり、それを解かない限り理想の顧客体験を実現するために、実務側に不便なオペレーションを強い続けることになります。
それをライバル視している限り勝てない
Googleスプレッドシートの役割を代替する機能を作る思考では、実務を担う現場メンバーからすると苦痛でしかない。
機能としてはたしかに代替するかもしれないけど、使い勝手がまるで違うから。
いくらGoogleスプレッドシートを代替する機能を管理画面で実装し続けても、Googleスプレッドシートをライバル視している限り、Googleスプレッドシートには追いつけないし、ましてや勝てるはずがない。
実務メンバーからしたらGoogleスプレッドシートじゃなくて、
「こっちを見ろぉぉぉぉぉっ！！そう言ってんだよ、小野寺」
（※TBSテレビ日曜劇場『半沢直樹』シーズン1 第8話より）
というところである。
見るべきはGoogleスプレッドシートではなく、実務メンバーそのもの。
そして、機能ありきではなく、動作ベースでの解決が求められている。
しかし、動作ベースでの解決策を考えることは、実務メンバーへのヒアリングや使用しているツールを共有してもらうのみで把握することは非常に難しい。
実務メンバーにとっては日々の習慣や癖のようなものもあり、同じチーム内でも人によって違うなど、すぐに言語化して上手に伝えられるようなもではないからです。
そのために、今実務で使用しているツールを観察し、使い方を聞いて代替する機能を手っ取り早く実装するということをしがちになってしまいます。
私のやらかし
実務側の管理画面を企画開発しなければならなくなった時、私は恥ずかしながら「実務で使われているGoogleスプレッドシートはやはり手強いなー。管理画面でこれをどう代替しようかなあ。」ということばかりを考えていました。
まさに、「天敵はGoogleスプレッドシート」状態です。
実際、周りの同僚にも「スプシー最強過ぎて困るわー」的なことを吹聴していたと思います（笑）。
そうして企画開発してみたものは、一画面に表示する項目が多く、表示速度や表示件数の限界から、メイン利用で実務に耐えるには正直厳しいものになってしまいました。
この管理画面をリリースした時、運用サポートという名目で実務メンバーの席の隣で肩を並べて働くことにしたのですが、それがこのnoteの主題に気づくきっかけとなる体験となります。
もはやGoogleスプレッドシートは問題ではない
実務メンバーの席に常駐する際、このGoogleスプレッドシート問題を一緒に解決する同志になれたらいいなという思いもあり、運用サポートという部外者的な立場ではなく、せっかくなので実務タスクを一部担うなど、少しでも貢献できる業務体験をしようと思いました。
直属の上司にも「自分とメンバーの工数の大部分について、実務側の業務に割きたい」と伝え、「いいね、行ってきな！」と快諾いただきました。きっとこの振り切り方を面白がっていたと思います。
ちなみに、こちらの転職エントリーを書かれている木原さんが私の直属の上司です。
実際に常駐を開始し、具体的な実務タスクを担い、例のGoogleスプレッドシートやリリースした管理画面を触っていくと、みるみる解像度が上がっていきました。
実務メンバー個々の役割や動き、連携箇所なんかも見えてきます。
「チームSlackでは今日対応する案件一覧を流して、Slack上で作業を分担しているのか！」
「この作業は案件ごとの個別対応ではなく、案件またいで横断的にやっていたのか！」
「ソート目的でしか使わない項目が結構あるな！」
などなど。
そして、実務での具体的な動作が分かってくると、同時に管理画面で求められる操作やその結果出力させたいものなども見えてきます。
「当日対応の案件一覧を簡易に取り出して、そのままチーム内でシェアできるようにできないかな」
「そのシェア画面で担当をアサインするオペレーションに変えられないかな」
「この項目はソートに使うだけだから、検索欄にさえあればよさそうだな」
「この作業は案件横断してやるから、一覧で編集できるように残したほうがいいな」
といった具合です。
Googleスプレッドシートどうこうという問題ではなく、単に実務の動作にハマる機能をきちんと管理画面に用意し、余計なものは削り表示パフォーマンスを上げるという、動作ベースでの思考ができるようになっていました。
「見るべきは実務そのもの」を肝に銘じる
「最初からそういう思考で企画しろや！」と思われるかもしれませんが、その時に集められる情報をもとに企画開発をしていくことになるので、業務体験するまではそこまで思考がいききれていませんでした。
むしろ、ヒアリングは繰り返していたので、Googleスプレッドシートの役割や用途、使われ方はだいたい分かった気になっており、その機能を管理画面で代替し、Googleスプレッドシートではできない機能を付け加えることで利便性をあげよう、という程度に構えていました。
使われ方や動作の目的・結果は分かっていても、その肝心な動作自体が見えていなかったというか、そんな感じです。
見るべきはGoogleスプレッドシートではなく、実務メンバーそのもの。
そして、機能ありきではなく、動作ベースでの解決が求められている。
改めてこのことを肝に銘じて、引き続き不動産取引のオンライン化に取り組んでいきたいと思います。
なお、業務体験をするのが一番いいとは思いますが、対象ユーザーによってはなかなかそのようなことをするのは難しい場合も多いと思います。時間もかかりますし。
そのような場合は、同僚である野浪さんのこちらのnoteも参考にしていただければと思います。
業務体験は「憑依力」を高めるための材料の一つに過ぎないと思いますので！
※GoogleスプレッドシートはGoogle LLC の商標です。
最後に
最後まで読んでいただきありがとうございました。
今回のnoteのエピソードにあるように、リアルとテックとが一体となって一つのプロダクトを作っていけるのは、私の働くGA technologiesの大きな特徴であり、強みの一つだと思っています。
そして、取り扱う商品が不動産ということもあり、一つのプロダクトが与える事業インパクトも非常に大きい分野だと思います。
PdMもエンジニアもデザイナーも、積極募集中ですので、もし少しでも興味あるかもという方は、以下のリンクからぜひお気軽にお声がけください！
今すぐ転職は考えてないけど、話を聞いてみたいとかそんな感じでもOKです！
この記事が気に入ったらサポートをしてみませんか？