クライアントの内部会議に参加：驚きの舞台裏

みなさまどーも！
歌とスポーツをこよなく愛する、ガジェログディレクターの岡崎です。

実はつい最近、ひょんなことからクライアントの内部会議に参加させて頂きました。

突然、しかも直前にお声かけ頂いたその会議の議題は「ベンダーに依頼する改善要望をまとめよう」。
つまり、ガジェログに何をどうやって依頼しようか？ なのですが、なんとその場に参加してしまいました(笑)
そこで感じたのは、大手企業の内部会議、意外にも走り出しは超ラフなんだってこと。普段あまり見る機会のないクライアント側の舞台裏、ちょこっとだけご紹介させて頂きます！

起案に至る内部プロセスの謎に迫る

『岡崎さん、13時からの起案会議に参加して頂けますか？』

その機会は突然やってきた。

僕らベンダーは通常、案件の見積もり依頼を頂くところから始まるが、当然ながらクライアント様内部の検討プロセスについては見えない。
いったい開発要件というのはどうやって起案されるのか、内容はどういう風に詰められていくのか、とても興味があったので2つ返事で参加させて頂いた。

検討会議スタート、そこで知った意外な事実

にGoogle meetのルームに入室すると、マーケティングチームから2名、システムチームから4名の計6名がすでに集まっていた。 長くお付き合い頂いているクライアント様なので、みな知った顔。
早速主幹の方から提示された今回の議題は、アウトバウンドマーケティングの改善とのこと。
僕は当然、UI（ユーザ・インターフェース）およびシステム側の実現可能性について意見する役割として呼ばれたのだと自覚して座っている。
まずはマーケティングチームからざっくりとしたRFP的なものが説明され、それに対してシステムチーム（岡崎はこっちチームだと勝手に思ってた）が質問や意見を述べるという流れで進むのだろうと予想し、勝手に心の準備をしていた。

しかし実際は、僕が思い描いていたのとは違った形で始まった。

マーケAさん
『今回考えているのは、CRMツールを有効に使ってもっと効率的にメールマーケしたい、具体的には、お気に入り登録している入荷待ちアイテムの、他店在庫が入荷されたタイミングでお知らせしたいという内容です』
マーケBさん
『それは、システム側とCRM側の各DBにある、どのデータをどう活用してトリガーにしようと考えてるんですか？』
マーケAさん
『商品IDをキーにして対応できないかと考えていたが、システム課の回答は、CRMのDBにそのIDを持っていないのでできないと。ではどうしようか。。。と案が尽きたのでお集まり頂きました。』
なるほどー。こんなにざっくりラフな感じで始まるのか。。。
なんとなくイメージにあったのは、まず主幹の方が、ある程度の実現可能性を整理した上でラフ案として机上に挙げ、各担当がその分野の目線で意見しブラッシュアップしていく、という流れだったが、確かに分野外の部分をヒアリングしながら自分なりに整理したとしても、あとで覆されたら時間のロスになる、であればこの粒度で各々気になったところに発言していく方が、時間の使い方としては効率的かもしれない。

ガジェログ岡崎も参戦

当初、マーケティングチームのざっくりRFP的なものに、システムチームとして質問や意見を述べる予定だった僕だが、こういう感じなのであれば、システムチームとしてではなく、個人的に思ったことをどんどん発言していこうとスタンスを改めた。

ガジェログ岡崎
『すみません、キーにしたいとおっしゃっている商品IDは、すでにCRMのDBには日次で送っているので、持ってるはずですが。。。』
マーケAさん
『え？そうなんですか？システム課からは持ってないと言われたので。。。』
シスAさん
『持ってはいます。持ってはいますが、マーケティング用にカスタマイズしたテーブルからは、項目上限数の兼ね合いで除外してるため、持ってないと答えました。』
ガジェログ岡崎
『というかそもそも、今実現したいと考えていらっしゃる仕組みは該当の商品IDでは実現できないです。ふさわしいキーは、その一つ上のレイヤーにある親IDの方になるかと思います。』
シスAさん
『それなら持ってます。』
ガジェログ岡崎
『そうですか。それであればキーの問題は大丈夫そうですね。』

うん、商品IDの件は大丈夫そうだ。
続いて気になったのは、メールの送信条件。
このクライアント様の商品は色違いやバージョン違いが多い。ゆえに商品IDが親子になっている。
何も考えずに実装すると、入荷待ちしている商品とは違うバージョンや、色違いなどの入荷情報がトリガーになってしまう。しかも全国60店舗の入荷情報。
さらには一点ものが多いという特徴もあり、メール通知したものの、サイトに訪れた時にはすでに売り切れている、という事態も少なくないと予想できる。
ガジェログ岡崎
『（上記の懸念点について）マーケ部ではどうお考えですか？』
マーケAさん
『それは気にしなくていいかと。機会を増やすという意味では、多少通知が多くても期待効果の方が大きそうなので。』
マーケBさん
『え！？それはユーザからしたらウザくない？色んなバージョンを入荷待ちしてるならともかく、バージョンを指定して待ってる人に対して、違うバージョンですが入荷しましたーって通知が何件も飛んできたらウザい。』

 ・・・ 今回は皆様の次の予定があったため、この時点で終了。 宿題としては、お気に入り登録しているユーザと平均登録商品数の直近1年間の月別グラフを出してみよう、というところで終わった。

会議に参加した率直な感想

初めて参加したクライアントの起案会議。それも第一回目から。
そこで感じた率直な感想は、「こんな大手でも最初はあまり内容固めずに始めるのか」という感じ。
ほとんど何も固まってない、フワフワした状態で結構な人数が集まり、ほぼ何も進展がない、という結果だった。
しかし個人的に、開発ベンダーという目線での収穫はあった。
まず一番印象に残ったのは、みんなそれぞれが自分の業務範囲や考えに対して一定以上の熱量を持っているということ。
熱くなりすぎてしまい、若干ピリピリした空気になった瞬間も。。。
次に感じたのは、他部署の管轄業務に関してはほんとに知らないんだなーと。とてもキッチリ縦割りになっている。
こういった各担当者の心情や横の関係値を理解しているかしていないかで、我々ディレクターが取るべき行動や気遣い・気配りは大きく変わり、それに伴い結果も変わってくるのではないだろうか。

内部プロセスへの理解と新たな視点

我々ディレクターは、ガジェログのMISSONである
【本気で考える　本気で発言する　すべてはお客様のために】
という考えに沿い、なぜ、なんのために作るのか？に向き合わなければならない。
『三河屋はよくない』とは新人の頃から耳が痛くなるほど言われたものだが、しかし現実問題として、起案されたRFPを額面どおりに受け取り、見積もりを算出し発注を受け、開発する、という流れで進めてしまうケースも少なくはない。
今回、起案前の内部会議に参加させてもらったことで、なぜ、なんのために作るのか？という根幹の部分に間近で触れることができた。
実際、会議内で議論していく中で棄却されたり、重要度が上がったりした要件があったが、ほとんど別チームからの意見によって起こることが多かった。

それはつまり、対岸を客観視することで気づけることは多い、ということ。
であれば、パートナーとして完全に対岸にいるガジェログが、本気で考え、発言することは、まさにクライアントのサービスを高めていくことに直結するのだと改めて感じた。