見出し画像

【密着取材】リクルートのサービス開発を成功に導く、IT企画のプロ・開発ディレクター

リクルートは、就職、転職、いろいろな働き方の支援、結婚、住まい探しといった人生の大きな決断から、旅行や買い物、食事などの日々の楽しみまで、さまざまなサービスを通じて「まだ、ここにない、出会い。」をお届けしています。その裏側で、サービス開発に取り組むエンジニアへの密着取材記事をお届けします。

リクルートのサービスは立ち上げ間もないスタートアップから成熟期に差し掛かったものまで、ジャンルもフェーズもさまざま。その数、なんと200以上ものサービスが存在しています。言い換えれば、ビジネスの状況に合わせて必要な開発スキルやマネジメント能力を磨くことができる環境が整っています。

本日取材するのは、サービス企画担当者とタッグを組んで、各サービスにおけるIT企画から開発、リリース後のシステム改善までの責務を担う専門部隊、「ディレクションユニット(以後、ディレクションU)」。

この部隊のミッションとは。そこでの仕事の面白みや、キャリアの積み方の可能性はどのようなものなのか。ディレクションUで住まい領域・マーケティングパートナーズ領域のユニット長を務める志田に密着です。

IT企画(システム開発)のプロとして

――企画から開発、リリース後のシステム改善まで一気通貫で担われているとのことですが、もう少し詳しく役割を教えてください。

ディレクションUは、HR(人材)、住まい、マーケティングパートナーズ、ライフスタイル、SaaS、と領域ごとに編成されています。ビジネス側のニーズにあわせて、サービスとリクルート内のソリューション(UX/UX・アプリ・インフラ・大規模プロジェクト推進など)をうまくつなぎ合わせ、ハブとなる役割を担っています。開発規模は大きいものだと数千万〜数億程度、開発フェーズにおいては十数人から百人超のエンジニア体制をディレクションしています。

画像1


ディレクションUの醍醐味はなんといっても、ビジネス検討やその前の戦略のフェーズといった「超上流」から関われること。

その役割は広く、戦略・企画・開発・保守と、ひとつのプロダクトの全てのフェーズを担っています。戦略フェーズでは、その事業の現状、競合他社との関係性などを踏まえ、事業の成長のためにIT投資をどう進めていくべきか、個人情報保護の観点からセキュリティをどう考えるかなど、ITに関わる施策を進めていきます。

画像2


他にも、各プロダクトのプロデューサーに伴走して商品や施策の実現方法を一緒に考えたり、経営層への提案も行ったりもします。施策を「どうやるか」だけでなく、「なぜやるか」もサービス企画担当者と一緒になって考えるため、目的に見合わないと判断すれば「やらない」という決断をすることもあります。

――「やらない」判断をすることもあるのですね?

まさにそこがディレクションユニットの仕事の面白いところだと思っていて。事業会社ならではの裁量権があるんです。リクルートでは自分たちのシステムをどうしていくかを自分事として考え、決断し、実行する全てのフェーズが経験できる。

ちなみにリクルートはシステム開発を外販していないんです。どうすればITの力でリクルートをもっと良くできるか、ということに集中できる立場だからこそ、ビジネスの成功やサービスの成長に本当にコミットできると思っています。

――言われたことをただ開発するのではなく、意思を持ってサービス作りに関われるんですね。

そうですね。あとは、開発の実行の選択権も自由度が高いと思います。内製開発でやるのか、オフショアでやるのか。ベンダーさんにお願いするのか、もしそうならどのベンダーさんにお願いするのか。開発手法もウォーターフォールでやるのか、アジャイルでやるのか、などなど。

会社で規定がガチガチに決まりすぎていてそれ通りに絶対やらないといけない、といったことはないから、いろいろな選択肢を検討できるというのは面白みのひとつだと思います。

ディレクションUに入った後のキャリアの広げ方

――「プロダクトの開発マネジメントだけでなくIT戦略へも染み出せる」とのことでしたが、ディレクションU内での役割の違いを教えてください。


意思決定のフロー順に、「IT戦略」「BA(ビジネスアナリティクス)」「プロダクト開発マネジメント」「プロダクト運用マネジメント」と大きく4つの役割に分けています。開発ディレクションというと、Cの開発の部分を想起されやすいけれど、その領域を軸にどのような仕事があるのか説明します。

画像4

A)IT戦略
IT戦略を考えることはもちろん、経営陣と話してビジネス戦略に落とし込んだり、ITガバナンスの方針策定や財務・サプライヤー管理をも担うことがあります。

B)BA(ビジネスアナリティクス)
IT戦略の実現に向け、案件を進める上での優先順位をつけたり、実行計画に落としたりします。案件ごとにビジネス検討を主導し、プログラムマネジメントとビジネス側との合意の主導も行います。

C)プロダクト開発マネジメント
「企画立案・業務設計・要件定義・基本設計・詳細設計・製造・試験・リリース」を主導し、開発要件を満たすプロダクト開発を実現します(アーキテクチャ機能、エンジニアリング機能含む)。案件によっては、ビジネス側やA・B領域からではなく、このC領域から企画の立案をすることもあります。

D)プロダクト運用マネジメント
ITの維持・保守、継続的運用改善を主導します。


――ビジネス側やA・B領域ではなく、Cのディレクション起点で企画立案する時とは、具体的にどんな案件になるのでしょうか?

例えばEOSL(※)対応など、「この時期までにこれをやらないとシステム動かなくなるよ!」みたいなものですね。技術的負債の解消は、ディレクションUが責任を持っています。

それ以外にも、自発的にログを見て、自ら企画立案するメンバーもいますね。特に事業企画担当者は機能要件までを考えるので、非機能要件については我々が担当しています。「実は徐々に処理スピードが落ちてるんです」「このままだと大量データが規定の時間までに間に合いません」という声があがると、対応を行う。ROIを考えながら、どうソリューションを選択し実現するかを考えるのが、Cの大事な仕事になります。

※EOSL(End Of Service Life):過去に販売された製品のサポートやサービス提供が終了すること

――なるほど。そのような過程を経て、システム構築が終わると運用フェーズに入っていくんですね。

そうですね。ただ、開発と同等、いやそれ以上に大事なのがDの運用だと考えていて。当たり前だけど、作ったものは放っておけない。「作ったものを正しく運用し続ける」というのが一番大事であり、宝の源泉だと思うんですね。

作ったもののモニタリング設計がどこまでできているかで、組織の成熟度もがらっと変わると思っています。日々モニタリングをしているから変化に気づくことができ、変化に気づけるから次の戦略に紐づくというサイクルがあるので、モニタリング機能やガバナンスの設計は本当に要だと思います。

――作るだけでなく運用まで。そしてそれを戦略に反映することで良いプロダクトになっていくんですね。これをひとつの人格で全てやりきるのは難しいかと思うのですが、Cの開発を軸にどうキャリアを広げていくのでしょうか?

基本としてはCの開発とDの運用を兼任している人が多いです。作って終わりではなく、保守までぐるっと。これができるようになると、より上流のBA(ビジネスアナリティクス)を担当して、見える視座を高くする人もいるし、より開発運用の専門性を深める人もいる。

ビジネス企画(プロダクトマネージャー)などに志向が向いている人は、特にBAのスキルが必要になってくるように思います。ROIを正しく選定できるスキルは、開発でもビジネス企画でも等しく重要になるので。

画像4


あとは、サービスのディレクションというと『じゃらんnet』『ゼクシィ』などの商用サービスを想起されやすいけれど、他にも『じゃらんnet』に掲載するための原稿を入稿するシステムだったり、店頭で結婚式場探しの相談ができるゼクシィカウンターで、スタッフがお客様に提案する際に使う業務用のシステムもあったりします。

それぞれシステムの特性が多岐に渡るからこそ、いろんなシステムを経験することもキャリアの広げ方のひとつだと思います。

例えば、住まい領域においても賃貸と戸建てでは、システムの作り方が全然違っていて。住まい領域から旅行、結婚の領域に行ったら、プロダクトはもちろん、提供価値も、必要な業界知識も全然違います。実際に異動した人は、「転職したみたいだ」って言ったりするほど(笑)ひとつの会社にいながら、いろんな業界のプロダクトに関われるのは面白いんじゃないかなと思います。

ちなみに、若手にはいろんな経験を積んでもらうために、意図的にディレクションU内での担当領域を変えたり、プロダクトデザイナー側に異動させたりしています。自分がやりたいこと(WILL)って、自分が見ている世界でしか想像できない部分もあると思うから、その人の適性を考え、強みを活かして弱みを克服できる環境を用意しています。

――ありがとうございました。

■バックナンバー・関連記事はこちらから

※掲載内容は取材当時のものです。


みんなにも読んでほしいですか?

オススメした記事はフォロワーのタイムラインに表示されます!