【メモ】企画やマーケッターに「コードも書けないおれの存在意義ってなんなの？」って思わせなきゃいけない

半分自分に言い聞かせるための記事です。

一人でWebサービスを運営できる時代のために

会社の勉強会でrubyistせんぱいが「アプリエンジニアやインフラエンジニアなどのエンジニア間の壁がなくなり、 一人で一サービスを担当できるような、エンジニア戦国時代が来る」という話をしていました。 「AWSやPaaSによってインフラが抽象化され、Docker等によってミドルウェアまで簡単にセッティングできるようになり、 Webサービスの面倒が一人で見られるようになる」 というような趣旨だった気がします。

これはエンジニアと隣接している（と個人的には思っている）企画やマーケッターも例外ではないと思っています。

blog.inouetakuya.info

現在、私は企画やマーケティングの人に頼まれてちょっとしたアクセス解析やプログラミングをする機会が多いのですが、 広告やアクセス解析のタグ(JS)の仕様を説明したり、「この指標は○○という仕様のせいで集計が難しいんですよ」伝えたり、 コミュニケーション中の時間のロスや負担が多くなってしまっています。

もちろん逆に自分が相手の目的を理解してなくて、余計な工数をかけてしまったこともありました。

例えば営業の方に「北海道のアクセス数を調べてほしい」と頼まれたところ、 自分は当初「北海道に住むユーザーのアクセス数」を調べていたのですが、 本当に集計すべきは「北海道で検索した際のページのアクセス数」でした。 そもそも商品を扱う出品者に営業する機会があったというのが依頼のきっかけで、 北海道産の商品ニーズの大きさを知りたいという目的さえちゃんと意識できていれば勘違いしなかったはずです。

極端な話ですが、一人でWebサービスもマーケティングも営業もこなせば、 コミュニケーションのロスが無くなり、このような余計な時間がかかることは無くなるはずです。 とはいえ学習コストや労働時間を考えると、そんなことは到底無理です。 そのため、他職種間で仕事をする際には「お互いに学び合う」必要があると思っています。

他職種との仕事では、「お互いに学ぶ」スタンスで

他人と仕事する際、「相手が本当は何を望んでいるのか」をうまく聞き出す必要があると思っています。 まず、同期に薦められた『Joel on Software』という本に次のような記述がありました。 これは一般的なソフトウェア開発の話ですが、エンジニアではない人と仕事する際も同じだと思います。

顧客は自分が何が欲しいか分かっていない。
顧客が何が欲しいかわかっていると期待することはやめることだ。

そんなことはありそうにない。そんな考えは捨てることだ。

代わりに、こう仮定することだ。いずれにせよあなたはなにか作らなければならず、そして顧客がそれを気に入る必要があるが、 おそらく彼らは幾分驚くはずだ。 あなたは調査をする必要がある。 あなたは顧客の問題を好ましい仕方で解決するデザインを見つけ出す必要があるのだ。

Joel on Software

営業の方はどんな技術が必要なのか分からないし、 アクセスログとしてどんなデータを取っているのか知っているはずもありません。 仕事をしながら、「相手の目的」と「技術によって実現できること」を相互に学び合うのが理想なんじゃないかと思います。

そのために、ユーザーインタビューとか人類学、社会学のフィールドワークなどの考え方が役立つんじゃないかと思って本読んでみています。 デザイナーの方に借りた『ユーザーインタビューの教科書』という本が面白かったです。 「相手に気持よく話してもらい、その人が望んでいるものを上手く聞き出していく」というスタンスが徹底している本で、 「ノートPCでメモを取ると相手じゃなく画面を見がちなので、紙のメモ帳のほうがベター」など、具体的なアドバイスも充実していました。

マーケティング／商品企画のための ユーザーインタビューの教科書 (Mynavi Advanced Library)

以前読んだ『文化人類学入門』でフィールド・ワークについて書いてある次のような記述がありました。 このようなスタンスを大事なんじゃないかと感じています。

私自身の考え方について言うならば、フィールド・ワークとは、その土地に入って、 そこの人びとの生活習慣、生活の知恵などさまざまなことがらをまさに教えてもらう、学習することなのだと思う。 （中略） 現地調査を行なうときには、やはりこうした考え方をつねに忘れず、 「教えていただく」という態度で相手に接しなければいけないのである。

【読んだ本】友だちに借りパク中の『文化人類学入門』が面白かった - 歩いたら休め

マーケッターの仕事を奪い取る

すこし話は外れてしまいますが、このような話を会社のオタク（データ解析の人）と話していたところ、 「企画やマーケッターに"コードも書けないおれの存在意義ってなんなの？"って思わせなきゃだめだよね」 と言われました。 つまり、自分で企画やマーケティングの仕事もでき、 「プログラミングできないおれの存在意義ってなんなの？」って危機感を持たせるようになるべきだということだと思います。

例えばマーケッターに対して「お前がExcelで2時間かけてやってる作業、おれがRで10分で終わらせたぜ」とか言って、 Rのプログラミングを覚えてもらえたらと思っています。 プログラミングによって効率化できる作業とがんばらなきゃいけない作業って、 少しはコード書けなきゃ分からないものだと思うので。

プログラマーの三大美徳（怠惰・短気・傲慢）にも繋がりますしね。

怠慢
全体の労力を減らすために手間を惜しまない気質。この気質の持ち主は、役立つプログラムを書いてみんなの苦労を減らしたり、同じ質問に何度も答えなくてもいいように文書を書いたりする。よって、プログラマーの第一の美徳である。

itpro.nikkeibp.co.jp

思ったより長文になってしまいました。以上です。