本日は、株式会社Macbee Planet（以下、Macbee Planet）のシステムクリエイティブ部部長 高原氏にお話しを伺いました！
Macbee Planet 高原氏 プロフィール
1989年、福岡県生まれ。2014年3月、早稲田大学大学院情報生産システム研究科を修了後、不動産物件ポータルサイトのシステム開発業務に2年間携わる。
その後、2016年4月、Macbee Planet初のWEBエンジニアとして入社。主に、自社プロダクト『ハニカム』『Robee（ロビー）』の開発に従事。現在は、システムクリエイティブ部部長を務めている。
■Macbee Planet
ビッグデータを基盤とした分析・予測・最適化のテクノロジーによってマーケティングソリューションを提供する企業。ビックデータ解析プラットフォーム『ハニカム』やWeb接客ツール『Robee』など独自プロダクトを提供している。
Macbee Planetへ入社するまでのキャリア
Q.Macbee Planetへ入社するまでの経歴を教えて下さい。
2014年から、不動産情報の総合サイトの一部を受託開発している会社でシステム開発の業務に2年間携わっていました。主には、追加機能の開発、運用保守等を行っていました。その傍ら、新規事業のアイディアコンテストで、自身のアイディアが採用され、事業化が決定したため、新サービスの開発も同時並行で行っていました。
Q.新規事業では、どのような仕事をしていたのですか？
エンジニアの業務を超えて、幅広く経験させてもらいましたね。
100ページ以上に及ぶワイヤーフレームの作成や、サービス普及のための営業活動です。当時は、エンジニアとデザイナーしかいない会社だったので、自分で営業するしかなかったですね。
開発したサービスは、インディーズのミュージシャンを対象にした楽曲の売買サイトなのですが、バンドをやっていた友人の意見のみを参考にして開発を進めていたので、いざ、営業してみると、訪問する営業先ではぼろくそに言われることが多くて。
サービスをただ作ればいいということではなくて、マーケットニーズを捉えたものを提供する必要性を学びましたね。
Q.その後、転職を決意した理由は何でしたか？
もともと、WEBの開発経験がない中で入社し、1年目で新規事業の立ち上げや、通常業務でもWEB系のスキルを幅広く身につける中で、今後の成長を考えた時に、自分が求めていることはこの会社ではできないと思いました。
前職は、新しい技術を導入する事に対して、あまり積極的ではありませんでした。学習コストとそれゆえにバグを生むかもしれないというリスクは理解できていたのですが、技術の発展が早いこの業界において、本当にそれでいいのかというのはずっと思っていました。
そのような社内状況ですので、お客様の要望に対しても、もちろん積極的ではなくて、数時間で終わるような依頼ですら、「仕様だから難しい。」と断ることも多々ありましたね。
もっと仕事に前向きで成長意欲の高い仲間と切磋琢磨したいと思い転職を決意しました。
Q.Macbee Planetへ入社を決めた理由は何ですか？
前職の経験もあり、最終的には、“働いている人”でMacbee Planetへの入社を決めました。面接を受けた時のMacbee Planetは、営業メンバー数名と役員だけで構成されエンジニアは全くいないという状況でした。
何度か面接があり、食事をしながらというのもあったのですが、どんな人達がどういう思いを持って働いているのかをすごく重視していたので、現場のメンバーにも参加していただきました。
食事会には営業メンバー3名が参加してくれたのですが、個人的には仕事に励む上で、どういう将来を見据えて取り組んでいるのかが大切だと考えていたので、夢や目標について質問しました。
するとその中の1人が、会社と共に成長していくことを夢や目標にして話されていて、このような小さな組織の中で、しかも、同じ年齢のメンバーがそんな想いを持てているのであれば、生ぬるいことを言わず、僕も一緒に切磋琢磨するしかないと思い、Macbee Planetへの入社を決めました。
エンジニア1人体制からスタートし、
2017年新サービス『Robee』をリリースするまで
Q.入社当初はどのような事をしましたか？
当時は、『ハニカム』という既存プロダクトの運用保守を行っていましたが、会社の成長を加速させる要素として、さらなるテクノロジーの強化が求められていました。
そこで2016年の9月、新サービス『Robee』の開発がスタートしました。
『Robee』の開発当初、外注のPM 1名、インターン生 1名の計3名のチームでした。ただ、専任で開発を進められるのは私だけでしたので、どうしても1人で開発を進めることが多くなってましたね。
経営陣には「2016年の12月までにベータ版を作ります！」と宣言していたので、かなり必死でやっておりました。終電間際まで残ることもしばしば。懐かしいです。
そしていざ予定通りにベータ版を完成させ、経営陣に見せたのですが、「管理画面って必要ないの？この機能って」などなど追加の要望が。
スケジュールに間に合わせるためかなり時間を使っていたということもあり「最初から言えよ。」と、正直、怒りすら覚えるぐらいだったのですが、『Robee』をプロダクトとして販売できるものにするにはこのままでは到底不可能だと考え、体制を変えることを提案しました。
Q.その後、体制はどう変わりましたか？
私とスタートアップのプロダクト開発を専門にしている外注先2名のチームで再スタートを切りました。スタートアップを専門にしているだけあって、開発スピードは早かったです。ただ、これは外注先ゆえの問題ではあると思うので当然といえば当然なのですが、プロダクトを作ることにコミットをしてくださっても、プロダクトの成長を考えたものにはなっていなかったんですよね。
詳細な要件定義がないと弊社の業務内容に合ったプロダクトにはならないですし、アルファ版をクライアント様へ導入したときのバグの対応についてもなかなか深刻さが感じられず。
新しく外注先とのチームで開発に取り組んだわけなのですが、プロダクトを成長させていくには、責任をもって臨める社内チームが必要だと強く感じまして、2017年4月にエンジニアの採用を始めました。
2017年、社内でエンジニアを持つべく、採用活動開始
Q.どのように採用活動を行いましたか？
よくある求人サイトやエージェント会社を経由して採用活動をスタートしました。次に入ってくるメンバーは、エンジニア2人目になるので、かなりこだわっていました。
まだまだ人数が少ないことを考えると、プロジェクト全体を任せていかなければいけないメンバーになるので、単純に「開発経験がこれくらいあって仕様をもらえれば開発できます！」というようなエンジニアはあまり求めていなかったです。
それよりも、会社の成長に貢献できそうな人や自分よりも優秀な何かを持っている人を探していたので、2017年4月から面接を始めましたが、結局業務委託が7月に1名、2人目の正社員を採用できたのは、9月でした。
Q.それ以降、開発メンバーはどれくらい採用できましたか？
正社員でいうと、2018年は、7月1名、8月1名、 9月1名入社（合計3名）採用しました。
Q.2018年は、どのような基準で採用を行いましたか？
2017年の段階で『Robee』の開発を進めていたのですが、私は『ハニカム』をメインにやっていたので、実際は2人（正社員1名と業務委託1名）でやっていました。
当時、競合他社やベンチマークしているサービスにおいてエンジニア数名レベルで開発しているところはなく、ちょっとした人数を採用しただけでは勝てないと思っていました。
なので、プロダクトの開発を加速させるため、すごくパフォーマンス（開発スキルに特化している、似たようなサービスの開発経験がある人など）が高い、ただの職業エンジニアではない人たちを採用していこうと決めました。また、最先端の技術も取り入れたかったので、機械学習ができるエンジニアも採用しました。
エンジニアも売上意識を持つべき
Q.エンジニア組織を作るうえで、どんなことを気を付けていますか？
エンジニアであっても売上意識を持つべきだと思っているので、エンジニアチームにはよくその話をしています。
前職では、お客様がいて、言われた仕様に応えるように開発を進めていたのですが、エンジニア1人目としてMacbee Planetに入社し、営業メンバーとのやり取りが多くなる中で、それを意識することが強くなっていきました。
実際、当時のMacbee Planetは、人数は少なかったですが、営業一人一人が上げる粗利はめちゃくちゃ多く、そのおかげで、働くことができているんだというのは常に実感していました。役割としてはエンジニアなのですが、会社の数字に貢献していかなければという使命感のようなものがありました。
Q.エンジニアにその意識をどう伝えていますか？
そこがとても難しいです。現在のエンジニアは、市場価値が高く、給料も良ければどこでも仕事があり、極論やりたくないことはやらなくてもよいという状況だと思っています。
だからあまり売上の話を言いすぎると反感を覚えてしまっていると思うのですが、とはいえ社員なので、貰っている給料以上のパフォーマンス出すことが根本的にコミットする内容なんだと話しています。
会社の売上目標が達成されなければ評価したくてもできないですし、ただ機能を作れば良いのではなく、それがどれくらいクライアント様に使われているかが重要ということは毎月の1対1の評価面談で伝えています。
またエンジニアのタスクを決める際にも売上につながる意識を持てるように、エンジニア各人が営業サイドと議論する場を設けて機能の全体感を把握できるようにしています。
Q.売上を意識する中で、エンジニアが身に着けるべき視点はありますか？
エンジニアサイドも会社でやっているビジネスが、業界のどの立ち位置にあり、どのような強みがあるのか、そして、今後、業界全体がどのように変わっていくのかを考えるようにすることが大事だと思います。
自社の売上、ひいてはクライアント様の売上をあげるということを考えると、クライアント様以上に業界のことに詳しく、先を見据えて施策を進めていく必要があると思っています。その意識さえあれば、技術的な側面でクライアント様に期待以上の価値を提供できるはずです。
「自分はエンジニアだからその仕事は関係ない。」ではなく、目標の達成のために何ができるか本気で考える、そんな熱意がほしいです。
エンジニアもPL管理で評価
Q.現在の評価制度を教えて下さい。
会社全体として、プロダクトごとに売上・粗利をPL管理しています。プロダクトにアサインされている人数、販管費から一人あたりが稼ぐべき粗利が算出できます。目標達成率を見ながら一人一人の貢献度をはかり、次の査定や賞与が決まるような取り組みをしています。稲盛和夫氏のアメーバ経営に近いものかなと思います。
対象としてはもちろんエンジニアメンバーも例外ではなく、売上に対してチーム一体となってコミットメントし、自身が作るプロダクトにしっかりと責任を持ってもらうようにしています。
Q.高原さん自身は、現在のPL管理に賛成でしたか？
PL管理を始める前は、エンジニアサイドと営業サイドで有機的なコミュニケーションが不足している雰囲気がありました。プロダクト全体の議論をしていても自分には関係ないみたいな感じがあり、そんなことでは絶対にうまくいかないので、抜本的に変えたいと思っていました。
エンジニアも営業も一緒になった少人数コミュニティなってしまえばそうも言ってられないので、良い取り組みだと思っています。
Q.エンジニアのプロダクトへの貢献度はどうやって見ていますか？
難しいところで、つまりは、エンジニアの評価につながるのですが、今だと定性的なところが強くて、スキルが高いとかももちろん重要ですが、プロダクト開発の側面でいかにチームを引っ張っていけるメンバーなのかというところが大きいですかね。
少人数コミュニティである以上、一人一人がプロダクトの成長を意識できないとやっぱりなかなか上手くいかないわけで。
「仕様をしっかり決めてもらわないと作れません。」とかエンジニアがやっていたら、いつまでも売りにいけず目標達成は到底無理ですし、一方で営業サイドの全ての要望に応えるなんてのも不可能です。
両サイドの意見をどういう風に整理して要件にまとめてタスクに落とし込んでいくのかなど、開発に至るまでの全体の流れを見て評価しています。
「技術だけを追いたい！」と言っているエンジニアは、このような評価に不満を抱くかもしれないですが、やはりまだまだ少ない人数の組織なので、一人一人が幅広くパフォーマンスを出してくれることの方が重要だと思っています。
