マーケター・ディレクター・営業・編集者・CS・BizDevがエンジニアと仲良く働けて、成果が更に上がるかもしれない7つのこと+1

株式会社LITALICOの亀田（エンジニア）です。
この記事は『LITALICO Advent Calendar 2017』 24日目の記事です。

はじめに

ここ1-2年で、複数のインターネット事業の立ち上げをやってきました。
エンジニアとしてプロダクト開発が中心の業務でしたが、さまざまな職能の方と事業全体の成長のためにいろんな仕事をしてきました。

営業行ったり、SNSやWeb/アプリマーケしたり、サービス開発のディレクションもしたり、Bizdevもしたり、簡単なUIUXデザインもしたり、文章を書いたり、CSもしたり、採用もしたり。
沢山の失敗とPDCAをみなと経験し、強い組織になっていくフローを、身をもって体感してきました。

その結果、私の「エンジニアでありながら、エンジニア以外の仕事も行ってきたこと」は
おそらく少しだけ貴重な経験で、自分だからこそ世の中に残せる文章が作れそうと考え

• "非エンジニア"が"エンジニア"とこう関わったら、組織も事業も幸せになれそう

をAdvent Calendar 2017のテーマにしました。

非エンジニアの方々はエンジニアを上手く巻き込むことで、仕事の成果を今以上に大きく上げることが出来る場合が多いと思います（実感しました）。
そして、そのためにはエンジニアに「助けたい」って思われることも（ぶっちゃけ人間なんだから）重要です。

少しでも世の中の生産性が上がり、皆が働きやすい社会につながればいいなという想いで「マーケター・ディレクター・営業・編集者・CS・BizDevがエンジニアと仲良く働けて、成果が更に上がるかもしれない7つのこと+1」を以下綴ります。

※大前提、組織は10-100名程度。インターネットのサービスリリース後のグロースフェーズを想定。

1. 「めんどくさい、同じこと何度もやってる」って思ったらとりあえずエンジニアに発信したらいい

「めんどくさいんだよねえ]「この仕事毎日5分やってるよー」 「毎月待つ3ヶ月くらいやってるよー」って現象がよく見ると多発

• 例えば「毎日のKPIの更新と確認」、「毎月の請求業務」、「毎月月初の売上/費用の確認」など
• オペレーションに慣れてくると（毎日なら1週間、毎月なら3ヶ月）続けると、"慣れ"により面倒くさくすらなくなってくる
• 5分の業務改善（自動化）の積み重ねで複利的に自身の出せる価値は爆増するのに

まずエンジニアに相談するといい理由

• 結局はオペレーションの改善の中で、どうシステムを組み込むかなので、エンジニアも一緒にどこまで出来るかを一緒に考えてもらった方が早い
• サクッと作れる場合もあるし、頑張ってでも作った方が経営的に良い場合もある
• 今あるシステムで解決出来たり、更には作らなくてもこのツール使ったらいいってのも、職業柄エンジニアは結構知ってる
• とはいえエンジニアの工数にも限りはあるので、その場ですぐ全ては解決されるとは思わない方が心は健全でいられる

2. ただ、スプレッドシートに"開発して欲しいリスト"を皆で作成して、優先度を付けて、エンジニアに渡して、運良く開発されても、あんまり自分たちの課題は解決されないから注意

課題の解決がされたことじゃなくて、リストが消化されたことに満足して終わる

• 大体が"すべき"じゃなくて、"あったらいいな"で、あったらいいなは業績も上げないし、労働時間も短くしない
• リスト上の日本語を見ても、大体詳細まで書かれていないし、直接のコミュニケーションは結果必要で、いちいち全部にコミュニケーション取ってらんない

やっぱり対象業務のマネージャーに課題を集約し、エンジニアと解決策をディスカッションしてもらうのが１番いい

• オペレーションを最も理解しているのはマネージャーのはずで、優先度を付けられるのもマネージャー
• マネージャーに情報を集約するためのスプレッドシートやTrelloを使うのは良いと思う

3. いきなり完全自動化をエンジニアに求めない。多少強引に回しながら、システムの導入を検討した方が、結果早い

力わざで進めた方が短期的には早く進むし、オペレーションの全体像が整わないといろいろ無駄になる

• 短期的には力技で動かすと人的コストがかかってしまうが、まずは本当にシステム化すべきか？のニーズを検証すべき（プロダクト開発でいう、sketchやprottなどと同じ）
• オペレーションが整備されていない状態でシステムをつくっても、どうせ変わるし、オペレーションによって必要なシステムは変わる。
• 更には、そのオペレーション自体が必要なくなる可能性も十分ある

とはいえシステムゼロは辛い。初めは多少手動が混じったくらいのシステムでいい。オペレーションを整備しながら、少しずつ導入の幅を拡げていくとスムーズ

• システムは万能じゃない、導入したら解決してくれる"魔法"では決してないことを知ること
• システムはオペレーションの中にどう組み込むかでしかない。オペレーションを手触りで分かった状態になって、ようやくシステムをどう入れるべきかが見えてくる。
• 幾千のPDCAの結果生まれたオペレーション&システムは事業の競合優位性になる場合が多いから、作るのは超重要

4. また、エンジニアに相談するときは「機能ベース」じゃなくて「イシューベース」で相談した方が幸せな解決策が出てくる可能性が高い

この機能が欲しいと機能提案を持ってきても適切な解決策には大体ならない

• システム化については、エンジニアが１番Howをわかってるから、非エンジニアが解決策を提示しても、そのアイディアがベストなことはほぼないし、ズレてる事の方が多い
• そもそも「これ作って欲しい。」って言ってくる"もの"でそれが本当にその人が欲しい"もの"であった例がない。本人が何を困っているのが分かっていないパターンが8-9割。あと1-2割も解決策（技術）を知らないがゆえに、大体ズレた依頼になる。

だから「自分の困ってることが何で、理想のオペレーションはどういう状態か」を明確にできるといい

• ここを明確にするにもかなりの時間はかかるし難易度が高い仕事という認識で取り組む
• エンジニアも初めに持ってこられた機能に縛られてしまう（アンカリング）し、忙しいと議論するよりも「はいはいこれね」ってなってしまう時もあって、結果微妙なアウトプットが出てきて、誰も幸せにならない

5. 受発注関係のコミュニケーションにならないように結構気を配った方がいい。例えば「この機能は大体これくらいの工数でしょ？」って一方的に言っても、エンジニアとは仲良くなれない

受発注関係の状態はエンジニアのモチベーションを下げるし、そんな文化は退職リスクを引き上げる

• 我々エンジニアは「技術力をあげたいし、新しい技術を使っていきたいし、面白いものを作りたい」もので、それは指示命令関係からは生まれない
• 例えば、「これくらいで出来ます？」って言われると「おいおい勘弁してくれよ」って思う。（手を動かすのは我々で、あんまり分かっていないのに、こっちの時間決めるなよと。）
• 運用フェーズに入っていると、同時多発的にいろんな人の案件をさばきながら、システムもどんどん複雑になっていて、見積もりはシンプルにいかない

ただ、経営上、ウォーターフォール的につくる事が必要になる場合も存在するから、それはエンジニアも理解すべきだし、それを分かってもらえるように説明コストはかけた方が良い。

• マネージメント層での話が中心かと思うが、明らかにこれ絶対必要じゃんって事はある
• とはいえ、「求める期限と機能」と「エンジニアの工数」でディスカッションしながら落とし所を見つけるプロセスが重要
• 内製せずに思い切って外注するってのも手

6. 開発後に、特定の目的で作られた機能を、別の目的で勝手にオレオレ運用しだしたらダメ

気付いたら「え、そんな運用してるの？」ってエンジニアが冷や汗書く瞬間は半年に1回くらいは見る（多い？）

• 例えば、ユーザー名を管理する所に、商品名や店名など入れてmixedな状態にしてしまう
• 結果、メンテナンスが効かなくなる。機能追加や削除で不整合が起きて、みんな不幸せになる

最悪やるにせよ、せめてエンジニアに相談してから運用すべき

• できれば作った方が良いが、コストの関係でありもので特殊な運用をせざるを得ない場合もある（あくまで経営的にアレな場合の最終手段だから避けたい）
• 一定のシステムリテラシーが必要だから難しいかもしれないが、「こうしちゃえ」って思ったときに一回立ち止まれるといい…

7. 他には、「日本語の意味」と「数値の定義」の認識がズレている場合も多いので、丁寧めに確認した方がいい

ユニークユーザー、ページビュー、セッション、滞在時間、新規ユーザー、読了、などの計測数値は扱うツールによって計測の定義が違うことを知っておく

• 自分の成果を正しく測る、顧客とコミュニケーションを取るときに間違った数値を見ては元も子もないが、後から「え、そこってそうだったんですね」って現象は意外とある
• 例えば計測方法が「GoogleAnalytics」と「自社サーバー」で計測、もまるで違う。計測方法別に1-5%程度違いが出る事も余裕で起きる
• 例えば、「読了率」もスクロール率って雑な所もあれば、コンテンツ量と時間で予測を立てて精度を上げにいっている所もある

作業完了、開発期間、出来る、出来ないもエンジニアのスキルと事業状況によって様々

• エンジニアが言う「作業完了 = リリース日」ではない、「開発期間終了日 = リリース日」ではない場合がある。確認工数やバッファまで入ってる人もいれば、入っていない人もある
• よく言われるが、「出来ます」って言ってもすぐ喜ばない、「出来ない」って言われても諦めない。出来るって言っても細かく詰めると大体抜けが出てきて時間意外とかかる
• 期待をするが、信用しすぎないこと。システムの完成ありきで重要な意志決定出来るだけしない方がいい

+1. 究極、自分でエンジニアリングを覚えちゃえば１番早いし、キャリアの未来も明るい

SQL叩いて数値出したり、管理ツールをスプレッドシートで関数組んで作ったり、必要な情報をスクレイピングしたり、くらいなら、多くの人は簡単に覚えられる

• Progateとか、Udemyとか、ドットインストールとか、学べる機会や教材はいくらでも存在する
• 周りにいるエンジニアにちょっと聞けば教えてくれる（はず）

エンジニアリングが出来るCS、エンジニアリングが出来るディレクター、エンジニアリングが出来るマーケター、の掛け算スキルも市場価値を高める大きな手段

• 各専門のスペシャリスト1本で追求するキャリアもあるし、掛け合わせのキャリアも同じくらい市場価値を高める可能性がある時代になってきている
• ちょっとやっておくだけでも、エンジニアの気持ちや業務フローが見えてくると、エンジニアとのコミュニケーションが非常にスムーズになる。プログラミング学習者とはものすごくコミュニケーションが取りやすい。
• 弊社でも「エンジニアリングが出来る編集者」や「エンジニアリングが出来るディレクター」がいるが、非常に大きな成果を出している

まとめると

頑張ってオペレーション回して、業務フローが見えてきたら対象マネージャーに集約し、エンジニアとディスカッションしてもらうと効率化される。困ったときは受発注関係にならないように注意（これ作って、期限これくらいでしょ？はNG）イシューベースで相談すると良い解決策を提示してくれるし仲良く慣れる。あと作ってもらったモノは勝手にオレオレ運用をしない。言葉や数値の定義がズレてる時あるからエンジニアに数値を出してもらう時は注意した方が良い。まぁ極論自分でつくれるようになると市場価値も上がるし、仕事も早くなると思うから気が向いたら学んでみるといい。

ってことでした。

ただ、そこまで多様な組織と事業を見てきたわけではないので、当てはまらない場合もあるかと思います。
「こんな場合はこうだよね」ってご意見も是非お願いします。

最後に

エンジニアからしたらうぜえなって思うコミュニケーションもあるかもしれないですが笑、私は皆に寄り添って共走できるエンジニアがいる組織が、強い事業につながると信じています。

もっと専門性をまたいで、分業相手が何をやっていて、自分の専門性が何か生かせないか、って考える機会、またげる機会は組織を強くする、そういう機会から大きな成果が生まれる瞬間を沢山見てきました。

みながクリエイティビティの高い仕事ができるように、気持ちよくみなが働ける環境づくりはどうやったら出来るだろう、を大切にしていきたいと思うLITALICOです。

さて、ラストの『LITALICO Advent Calendar 2017』は、我らがCTO 岸田さん（@takish） の「エンジニア組織がない会社でエンジニア組織を立ち上げるためにやった3つのこと」についての記事です。

下書き見ましたが、これは超大作。
お楽しみに！！