開発部門管掌役員とVPoEが語るレコモットの開発組織について～組織・風土編～

こんにちは。レコモット採用担当です。

この記事は、エンジニアの皆さんにレコモットの開発組織について、もっと知っていただくためのインタビューです。今回は、開発部門管掌役員の吉田とVPoEの眞野にレコモットの開発組織についてインタビューを行いました。

～経歴紹介～

開発部門管掌役員：吉田

コベルコソフト神戸（現：コベルコソフトサービス）に入社し、業務システム開発に従事。
その後、ITベンチャーの海外拠点において開発業務を経験。2004年にイノシス研究所に入社、複数プラットフォームのアプリ開発を牽引。2006年7月にレコモットに参画し、2020年6月にデベロップメント部並びにプロダクト管理部の管掌取締役に就任。現在は開発責任者として、会社のプロダクト開発を牽引。

VPoE：眞野

SI企業に入社し、業務系システム開発に従事。その後、ITベンチャー企業にてiOS、Androidアプリ開発を経験し、いくつかベンチャー企業でサービスの立ち上げや、開発部門の責任者を経て、2021年1月にレコモットに参画。VPoEとしてエンジニア組織全体の採用・育成・マネジメントを担当。

～それぞれのレコモットでの役割について～

ーまずお2人のレコモット開発組織における役割を教えてください。

吉田：開発の全体スケジュールやロードマップの作成やステークホルダーとの調整・他部署との連携などをメインに行っています。いままでは、開発組織の体制づくりに開発組織の体制づくりも大きなミッションの一つでしたがその部分は現在眞野にリードしてもらっています。

眞野：開発組織の体制づくりや採用をメインに行っています。他にも、キャリアパス策定や開発組織におけるカルチャーや様々な仕組みづくりにも関わっています

～二人から見たレコモットの開発組織の特徴について～

ー2人から見たレコモットの開発組織の特徴にはどのようなものがありますか？

吉田：サービス全体を俯瞰して見られるフルスタック思考の開発組織です。チーム構成はあるものの、比較的自由度の高いチーム体制です。弊社のサービスにmoconaviというものがありますが、基本的にはmoconaviを主軸に機能要件を追加し、サービスの拡充を図っています。そのため、どこか特定の分野にだけに特化しているというよりも、複数のチームを横断して様々なジャンルを手がけてもらうことが多いです。

最初はフロントエンドをやっていた方が、途中からバックエンドもやりたいということでチームを組み換えたり、iOSだけ出来るということで入社された方が、Androidにも挑戦してみたりといったこともよくあります。どこかのプラットフォームで得た知識というのは、他の分野でも必ず活かせます。それに、その方が自分自身の経験値や視野も広がるかと思います。

眞野：既存メンバーはもちろん、最近採用した若手メンバー含めて、成長意欲の高い方々が集まっている印象です。有志で技術的な勉強会を催すこともあって、最近だと「AtCoder」という世界でも有数の競技プログラミングに出場しようということで、6名ほどが集まって勉強しています。決して私たちが強制した訳ではないのですが、自然とそうなる空気感が組織全体としてあるように感じます。

ー普段はどのような就業スタイルですか？

吉田：基本的にはフルフレックスなので、決められた就業時間は厳密にありません。もちろんデイリーMTGや打ち合わせには出席してもらいますが、例えば個人の都合でMTGの出席が難しい際には調整するなど、柔軟に対応でき、自由度高く働ける環境です。

眞野：普段リモートワークでの作業がメインとなりますが、必要に応じてオフラインを組み合わせています。対面でお互い話し合ったほうが効率よく業務が進むこともあるため、そういった場合には、メンバ―同士相談して出社するスタイルをとっています。

～現状の開発組織の課題と、改善に向けて現在動いていること～

ー現状のレコモットの開発組織の課題と、改善に向けて現在動いていることは何ですか？

吉田：先程お話したmoconaviは、2007年にプロダクトが誕生しました。随分歴史も長くなってきているため、今は使われていない古いコードが残ったままでいることがあります。それが残った状態のままでいると、バグが発生してプロダクト開発の生産性が下がってしまいます。こうした都度発生するバグの改修は、開発組織における課題です。現在は、バグ改修と機能追加を行いつつ、技術的な課題の根本的な解消に向けても取り組んでいます。

基本的には、チームやプロジェクト毎にデイリーMTGを行っており、そこで気になる点や引っかかる点などは共有し、抜け漏れのないようにしています。あとは、Teamsというコミュニケーションツールを活用して、メンバー同士で気軽に相談できる環境を整えています。

チーム全体としていかにプロダクトの質を向上できるかという視点で考えているため、バグや古い機能を見つけた人や、改善しようとした人が損をせずに、チーム一丸となって課題に取り組む姿勢を大切にしています。

眞野：レコモットでは、日々新しいメンバーが増えています。彼らがいかに早く組織に馴染めるか、プロダクトの理解を深めていけるかは大きな課題であり、そのための体制づくりにも力を入れている最中です。最近、レコモットの開発組織内で取り入れたものに「メンター制度」があります。OJT期間中に先輩メンバーが付いて1対1で作業をサポートするものです。

入社したばかりだと作業中に生じた疑問を、誰に聞いたらよいか分からない場面があると思います。しかし、いつでも相談できるメンターがすぐ側にいることで、新メンバーにとっての安心感につながります。また教える側としても、作業しながら一緒に理解を深められるため、相互に高め合えるように良い仕組みにしていきたいと考えています。他にも、リーダーがいま抱えている属人化した知識を手放し、組織に配分してスムーズに作業が行えるように業務移譲を行っています。

～今後どんな組織を作っていきたいか～

ー今後どんな開発組織を作っていきたいですか？

吉田：レコモットが掲げるValues（バリューズ）※にもありますが、変化を愉しみながら、新たなことにもチャレンジしていくことができる開発組織を作っていきたいです。セールスチームや顧客からの要望にただ答えるだけの受け身の組織ではなく、メンバー自らが意思を持って、積極的なアプローチでプロダクト開発に携わっていく。そうした中で、自らも成長することができるような組織にしていきたいです。

もう1つは、思ったことを躊躇なく言い合える心理的安全性のある組織です。「ちょっとこのコードおかしくないですか？」や「ここを直してみましょうよ」とか、発言してくれた人が居心地がいいと感じてくれる環境でありたいです。

眞野：吉田からもありましたが、言われたものをただ淡々と作るのではなくて、メンバーが自分で考え、自分ならではの答えを見出しながら開発に打ち込める組織でありたいです。セールスチームや顧客の要望を聞き入れ反映する必要があるため、エンジニア組織はどうしても受け身の姿勢になってしまいがちです。

しかしながら、エンジニアは本来自分たちの手で”ものづくり”が出来る人材です。相手の要望の内側にある意図をしっかりと理解した上で、「顧客にとって一体何がいいのか？」そんなところを思考しながら、プロダクトを作れる組織でありたいです。

※レコモットで大切にしている3つのValues（バリューズ）

『Fun to try ～変化を愉しみ、まずはやってみる！～』

『Take initiative ～誰かではなく、自分が動く！～』

『Beyond the team ～チームを超えて、違いを生み出す！～』

ー「自立」「自発」というキーワードを大切にされている印象です。そう思われる背景にどんなことがありますか？

吉田：ただ言われたことをやるよりも、「そのプロダクトがどう成長すればいいのか」や、「プロダクトによって顧客がどう喜んでくれるか」など、いま行っている作業のもっと先にある姿をイメージしながら仕事をしたほうが、単純に愉しいと感じるためです。

毎日沢山のタスクをこなしていると、時にストレスだと感じることもあるかもしれません。しかし、その作業の先に顧客がいて、価値を提供するために作業をしているのだと考えることにより、タスクに対する捉え方も変わるのではないでしょうか。私としては、そう考えて仕事をするほうが、市場からもより求められる人材になると考えます。仕事に取り組む視点を変えれば、エンジニアとしての市場価値を更に高められます。

眞野：レコモットは、私が入社した当時から自立した組織を大切にしていました。元々は少人数のエンジニアでやっていたところからのスタートなので、創業メンバー含めて自分たちで”ものづくり”をしてきた原体験があります。それは、組織が大きくなった今でも変わらずに大切にしていることです。

だからこそ、レコモットはいまでもフルスタック思考な開発組織であり、さまざまなジャンルに分け隔てなく興味のある人達が集まっています。今後メンバーが増えても分業はし過ぎずに、なるべく一人一人がチャレンジできる組織体制を大切にしていきたいです。

ーメンバーとのコミュニケーションで工夫されている点はありますか？

吉田：レコモットは複数の現場を経験されている経験の長い業務委託の方々にも入場いただいていますが、みなさん同じように「これまで経験してきた会社の中でも、すごく居心地がいい」と言われることが多いのです。開発現場に長く身を置いている立場として、どういうコミュニケーションの取り方であれば、エンジニアが心地いいと感じられるかは理解しているつもりです。