（2）ITを知る「賢い発注者」になりチームの力を引き出す

――ITについての知識はマーケターとしての説明能力を圧倒的に強化してくれる。

柿野：はい。そして、 ITでどんなことができるかがわからないとイノベーションのモデルが創れなくなる時代になっています。

　先にお話しましたようにコンカーも「Sansan」や「駅すぱあと」、「ぐるなび」などの外部サービスとの連携を進めてきました。誰かに頼んでAPI連携の仕組みを作ってもらうにしても、発注側である私がAPIの仕様をわかっていると、チームに無駄な働きがなくなるんです。

　広告代理店の過重労働問題の根底にあるのは、発注側において成果物に対するイメージが固まっていないことなんじゃないでしょうか。クライアント側に、発注力が欠如しているんです。もやっと頼むと、代理店側も「こんなもんかな」と忖度して作らざるをえない。

　ところが、忖度してできてくるアウトプットは、残念ながらクライアントが求めているものと全然違うんです。だから作り直して再納品して、ダメ出しして、というやりとりを繰り返しているうちに予算と時間を使い尽くしてうまくいかない。

――発注側が、仕事上のパートナーに何ができるかを知った上で、自分たちは何を実現したいのかを相手に正確に伝えることは本当に大事なんですね。

柿野：そう思います。小さなことでもより具体的に依頼する。パワーポイントでいいので、こういう画面が出て、これは入力必須で、画面遷移するとこういうふうになって、と明確に頼めばアウトプットの精度は格段に上がるんです。

　アメリカのITベンダーは内製志向が強くて、内部にITスキルのあるマーケターを抱えています。一方で、日本はスペシャリスト社会ではないので、社内の部署を転々として社内のことには詳しいけれど、特定の強みはなくて社外では通用しないような人が多くなってしまう傾向にあるように感じます。

　そういう人が、テクノロジーやパートナーへの理解が不十分なままに「社長はこんなのが欲しいんだろうな」と忖度して、あいまいなイメージでSIerや代理店に発注をかけ、迷走が始まることが多いのでは。

　今回TECH:CAMPで学んで改めて感じたことですが、エンジニアの人たちって優秀な人が多いです。優れたエンジニアの力を引き出そうと思ったら、マーケターは「賢い発注者」である必要があります。自分自身が技術を理解していないと、「チームで一緒にやろう」という姿勢にならない。その意味で発注者であるマーケターは、エンジニアの立場になって考えるためにプログラミングスキルをつけるべきだと感じています。

――柿野さんはTECH::CAMP法人プランでRubyによるアプリ開発を学ばれたわけですが、その知識はエンジニアとのコミュニケーションに役立っていますか。

柿野：API連携の話がしっくりくるようになりましたね。コンカーの技術文書を見るとRubyを学んでいた時と同じ体験をすることがあります。社内のエンジニアに「このデータはこうやって呼び出せるんだよね」と技術的な背景をふまえて話せるようになりました。そうするとエンジニアが「詳しいんですね」と言ってくれるようになるんです。

　エンジニアに「詳しいんですね」と言われることのメリットは結構大きいです。社内での自分に対する信頼も増しますし、コミュニケーションの精度が上がって、チームとしての働き方がよくなってきた実感があります。

（3）どんな仲間がいればアイデアを実現できるかがわかる

――どんな人がどんなスキルを持っているかについての知識も大切でしょうね。

柿野：そうなんです。アイデアがあっても、誰を巻き込めば実現可能かわからないと話が進みませんから。

　そのためにも、情報を取る力をつける必要があります。プログラミングと語学は習得するための障壁が高いですが、そこをクリアすると格段に情報がとれるようになってくる。この2つはトレーニングを受けるか、必然的にスキルが得られる環境に飛び込むかしかしないと獲得できない。

　最近、イノベーションを生むための業務モデルとして、デザイン思考が話題ですよね。いろいろな価値観の人が集まってモックアップを作るわけですが、その本質は、自分の足りない知識を他人に借りて、自分が実現したいものを考え、実現していくことにあります。

　その際に、「誰に参加してもらうか」「どのようなことを頼むか」が明確だと、話の運びが早くなってきます。ITの知識があると「この技術だとこれはできるだろう」というあたりがつくので、アイデアの実現に向けてぐっと有利になります。