1
/
5

meetup対談:我々が思うエンジニアの生存戦略とは【後編】

 2016年12月13日、リクルートマーケティングパートナーズ(以下、RMP)×Quipperの技術対談を聞きながら、おいしいご飯やお酒を楽しむことができるイベント「【RMP×Quipper】Food&Drink meetup #4」を開催致しました。トークセッションでは、RMPでマネジメントを担当されている金谷 祐季(@soplana)とQuipperの開発者である大庭 直人(@ohbarye)が、今後必要とされるスキル等、エンジニアにおける生存戦略を語りました。

▼KPIツリー上にエンジニアが入りこむことが内製開発の価値である

大庭:内製開発のプロダクトマネジメントみたいな形で枠組みみたいなものを作っている?

金谷:そうですね、それが人を育てる枠組みですね。そういった所を本日のタイトルでもある生存戦略に紐づけて話していきたいなと思います。

 話を続けると、先程話していた相談ベースで仕事が振っていける内製開発的な考え方を、日々の業務レベルまで落とすと、どう回っているのが理想的な状態だっけという話になります。例えば会社というのは、基本的にはKPIツリーみたいなものが描ける構造になっているはずです。ある会社では500億の売上を作りますというのがKGIだとして、それを要素分解していきます。あるプロダクトで50億、別のプロダクトで100億という具合です。その100億の売上をあげるプロダクトも、同じように売上構造を分解していけるはずです。

 この考え方は、どこまでズームイン・アウトしても絶対に同じ構造が保てるようになっています。ということは、社長であったとしても、新卒エンジニアだとしても、根本的に働き方は何も変わらないと思うんです。目標を明確にし、関連する数字をモニタリングし、沢山失敗しながら方向性を是正しつつPDCAサイクルを回していく、と。これはどういう職種で仕事をしていても変わらないんじゃないかなと考えています。

 またちょっと別の話ですが、何事も1つの施策を打って、それが当たって目標達成できましたという事はあまりないと思うんですね。1つの成功があるとしたら、その裏側には99回失敗があるとか、50回60回の失敗がある上で、40回とかの小さな成功がいくつも積み重なって達成していくものだと思っています。これが内製開発の最大のメリットになってくるところです。つまり何かを達成する時に考えるべきアプローチとしては、その99回の失敗をいかに柔軟に素早く繰り返すかという仕組みが重要になってきます。そう考えると、外注開発的なフローだとコミュニケーションコストや成果物の確認コストなどが発生することになり、その中で99回の失敗を柔軟に積み上げる事はなかなか難しい。

 一方で、内製開発のエンジニアが自分で考えて自分で実装して「あ、これ失敗だわ」と判断できPDCAサイクルを自分自身で回せるなら、それが一番早いんですよ。 つまり、KPIツリー上にエンジニアがちゃんと入り込んでいて、自律的に目標を追って試行錯誤できている状態が、内製開発の正しいあり方だと。外注開発というのはKPIツリー上にいる人たちがその数字を達成する為に必要な機能やタスクを考えて、予算を使って外部のエンジニアなりにお願いする事です。ただ、それが全てではないとは思っています。技術を極めたという人や、それそこ外注開発的な存在の人達も一定数いないといけないと思っている。割合の問題だとは思うんですけど、例えば全員が全員技術を極めたい人、或いは外注開発的手法での開発スタイルをずっと取っている、という状態だと内製開発のエンジニアを雇っても意味がないよねという話です。

大庭:まさにその、KPIツリーの中にって考え方にピンとくるものがありますね。自分がSIerで受託開発やっていた時も受注して製品を納品してという中で、その先にやっぱり見えるんですよね。お客様が目指している数字とか何かあるんですよね。ただ立場として、深入りできない線がある。

金谷:そうですよね。こうしたらいいじゃん、って構想があっても言いづらいですし、自分で手を動かすこともできないんですよね。

大庭:そうです。それがジレンマですよね。その頃エンジニアとして生き残るのなら、やはりその部分を直接できるようにならないと厳しいなと感じました。それが、Quipperに転職したら、やはり、みんな素でできているのですよね。

金谷:ベンチャーなので、自分がやらなきゃいけないという当事者意識が生まれてくるんでしょうね。

大庭:守備範囲の広さというか、周囲の問題・課題を拾っていくということを自然とやっていくと身に着くスキルになりますね。

▼様々な大企業が内製開発化していく可能性がある

大庭:内製化を始めるに当たり、KPIツリーの一部を外注にお願いして達成することから、自社のエンジニアに任せていくことが正しいのかに関してもきちんと評価しなくてはいけないのは結構難しいところですけどね。

金谷:そうですよね。外注開発用の予算を使ってプロダクト作成・運用して成功できるのであれば別にそれでいいんですよ。でもRMP・Quipperは一部のプロダクトでは内製開発でやっていくという選択をし、実際に内製開発で進めている訳です。会社がそういう戦略を取り、私達がこうして組織にいる以上、我々の力でプロダクトを成功させなければならない。そのためには粘り強く一つのプロダクトで小さな失敗を繰り返しつつ成功に繋げていく事と、新規事業の芽もチャンスがあれば内製開発のエンジニアが入り込む形で育てていく事が必要になってきます。

 前者にしても後者にしても、やはり先程話した、如何に柔軟に99回の失敗を積んでいけるかというアプローチを考えることが重要になってくるはずです。新規事業にしても粘り強くやったからといって当然全てが上手くいくという訳ではなく、いくつかの失敗の上に成功するプロダクトがうまれてくる構図のはずだ、ということですね。

大庭:そのやり方を大企業でできるのはいいですよね。ベンチャーだと、プロダクトが当たらなければ終わってしまいますが、大企業だとその他にもいくつもの柱があるので思い切りできますよね。

金谷:まさにその辺りの話から、生存戦略の話に繋がっていくわけです。

 先日Ruby World conference 2016に参加したのですが、そこでGitHubの方に話を聞きました。今海外ではインナーソース開発と呼ばれるOSSの開発手法を、ウォルマートやトラクターの会社なんかでも取り入れていて内製開発を強化していっていると。日本でも日経新聞社が内製開発に踏み切って、WEB媒体で3億PVを稼いでいるそうです。今後大企業もどんどん内製開発化、インナーソース開発化していくのではないかという話です。

 今、日本だとweb・アプリ開発における所謂「技術力がある人」がその技術力を十分発揮して働く場合の選択肢としては、スタートアップやメガベンチャーがメジャーなのではないかと思います。ですが今後は、リクルートや日経新聞社もそうですが、大企業が内製開発に踏み切る事例がどんどん出てくると思います。

 ただこれまで話した通りで、エンジニアを雇ったら、それだけで内製開発かというとそうではない。内製開発と外注開発の違いを理解できていて、それをベースに会社毎に応じた形で自分や開発組織の働き方・振る舞いを考えられるエンジニアだと、その世界では価値が高いわけです。現在RMPでも、そのような振る舞いが出来るエンジニアを育てていく仕組みを作り、実践している最中です。

大庭:自分の中の生き残り像にまさに近いです。(笑)

 生存戦略の話に立ち戻ると、実は今、結構楽観視しているところがあります。Quipperに移って自社プロダクトをやってみたことで、事業会社固有の問題をエンジニアリングで解決するシーンを日々見ていますし、そういう人たちが絶対に必要ですよね。「生存戦略」とググった時に上位に出てくるようなパレート最適でいう8割の生産性を担うスーパーエンジニアに対して、残り2割のKPIを追いかけるプロセスに強かったり事業領域やプロダクトへの理解が深いエンジニアも事業会社としては大事ですよね。

▼キャリアパスと人事制度

大庭:RMPもそういう組織なのですか?

金谷:まだ4年目の組織ですし、そういった取り組みが始まったのも実際のところは最近の話だったりはします。RMP全体が今日話したような働き方をしていける状態にあるのかというと、大きな会社なのでそうでもないのですが、少なくとも私のグループに関してはフィジビリスタディとして取り組んでいて、将来的にはRMPやリクルートグループ全体に浸透させていきたいとは考えています。Quipperはそういう部分、結構出来ちゃっているイメージですがどうですか?

大庭:今はQuipperの組織図としてCTO直下に50名ほどのエンジニアが並列になっていますが、人数比率として限界を感じたため、CTOとエンジニアメンバーの中間にポジションがあっても良いという話が出ていますね。人事制度に関しても、2016年4月からリクルートで使用しているミッショングレード制度をちょっとアレンジして採用することになりました。

金谷:勿論RMPもミッショングレード制度です。グレードが同じであれば、年収も大体同じという(笑)

大庭:一番下だと小さい機能の担当から、登っていくと1プロジェクトをリードする等、どんどん職務内容のレベルが上がっていくんです。ただ、必ずしも現実の組織構造と対応するわけではないんですよね。そもそもQuipperのプロダクトチームのフラットさだと中間管理職みたいなのがいないので対応させようがない。レベルに対する要件を満たしていれば、いちエンジニアであろうが、テックリードであろうが、あくまでも同じレベルなんです。

金谷:ミッショングレード制度は、しっかり運用できていれば働いている側にとって明確ですよね。私のグループは2~3週間に1回面談をするのですが、本日話したKPIツリーや内製開発の取り組みが始まる前だと、どうやったらミッショングレードが上がるのか、どういうキャリアパスを描けばよいのか、などの質問がよく出てきていました。

 今だとそういった取り組みが始まり、KPIツリーとミッショングレード制度が紐づくような形で今の仕事と今後のキャリアパスを話せるようにしたことで、あまりそういった質問は出てこなくなってきました。全員が全員そのKPIツリーをベースとしたキャリアパスの考え方というわけではないのですが。

大庭:確かに。そこが見えている・見えていないで動き方が変わってきますよね。ちなみに面談で結構アドバイスとかするんですか?

金谷:するほうだとは思います。しっかり欠点を指摘することもあります。

 難しいことだと思うのですが、彼・彼女らを思うと、アドバイスしない方が誠実じゃないなと考えて言うようにしています。リクルートは卒業させていく文化のある会社ですから、今後彼らがRMPを卒業していって活躍してくれることで、RMPのプレゼンスが高まり、また優秀なエンジニアが入社してくれるという循環を作っていかなければならないと思っています。そう考えると、メンバーに対し短期的だったり組織からの都合だけで対話やマネジメントをするのではなく、人となりやスキル・志向性なども併せた上で、中長期を見据えた成長戦略を立て、日々の働き方に落とし込んでいく必要があると考えています。個人個人の強みと弱みを分析し、一緒に生存戦略を練ることがマネジャーとして大事かなと勝手に思っています。

▼事業とエンジニアリング、両方の面白さを兼ね備えた会社での挑戦

ー【質問】 どういう人と一緒に働きたいと考えているのか知りたいです。

金谷:そうですね 、繰り返しにはなりますが、一つの流れとして今後、大企業を中心に内製開発を始める動きが出てくるという話があり、その中で重宝されるのはしっかりKPIを意識した開発がしていける人材だという事があると思っています。現在のRMPは、大企業で且つそういった取り組みに挑戦しているフェーズとなっているため、ここでの経験は後々絶対に活きてくるものだと考えています。もし今回お話した生存戦略に共感を持っていただいた方がいらっしゃれば、RMPという会社はおススメです。

大庭:Quipperでは、ある数字の達成が会社としてのミッション(Distributers of Wisdom)の達成に通じているという実感があり、そこに胸を張ってやっていける感じです。エンジニアとしてある程度高い給料を貰えても、事業に貢献できなかったり、事業自体に持続可能性がないとそもそも自分のキャリアよりも先に事業が潰れてしまう可能性がありますよね。そのレールに長期間乗り続けるのは生存戦略として正しくないと思っています。

 Quipperが取り組むのは教育事業なので本質的には何かを良くしようという想いで始まっていますが、その善性に取り憑かれず冷静にやっていこうというのが我々のスタンスです。最近はCTOが「正しいものを正しく作ろう」と良く言っています。「正しいもの」の意味はそれぞれ解釈してもらってよいのですが、私がQuipper流に捉えると「ミッションと照らし合わせて価値があるもの、持続性があり胸を張っていけるもの」だと思います。

 また、「正しく作る」は、個々のエンジニアリングの力をもって問題をどういう風に解決していけるか、どうあるべき姿に近づけられるかということで、フラットな組織の中でQuipperの各エンジニアに委ねられているところです。事業とエンジニアリング、両方の面白さを兼ね備えた会社ですので、Quipperに興味がある方は是非ともご応募ください。

(完)

≪meetup対談:我々が思うエンジニアの生存戦略とは【前編】はこちら

--------------------------------------

▼リクルートマーケティングパートナーズではエンジニアを募集しております!一緒に働きたいと思った方はこちらから!

▼Quipper日本オフィスでは仲間を募集しています。是非お気軽にご応募ください。

- サーバーサイドエンジニア募集

- iOSエンジニア募集

- UIデザイナー募集

◆株式会社リクルートマーケティングパートナーズの採用情報はこちら

◆Quipperのプロダクトチームのブログはこちら

株式会社リクルートマーケティングパートナーズでは一緒に働く仲間を募集しています
9 いいね!
9 いいね!

同じタグの記事

今週のランキング

Ai Muramatsuさんにいいねを伝えよう
Ai Muramatsuさんや会社があなたに興味を持つかも