億単位のビジネスを支える最後の砦　リクルートテクノロジーズ“大規模プロジェクトマネジメント”の裏側とは

リクルートグループにおける大規模プロジェクト開発の取り組み

辻純一氏：リクルートテクノロジーズのプロジェクト推進部でマネジャーをしている辻と申します。今日はよろしくお願いします。

僕は中途入社で、この12月で入社して丸6年になります。前職は、メーカー系のSIerで、コンビニやスーパーの発注システムの開発をやっていました。いわゆるSEの階段というのを登って、プロジェクトリーダーになって、「なんかやれてるじゃん」って思っていました。

しかし、自分がやっていることのインパクトをふと考えてみると、とあるスーパーの発注業務の効率化。それはそれで大事なことなんですけど、もっとビジネスインパクトが大きく、自分がやったことが新聞に載るようなことに関わりたいと思うようになりました。

であれば、そもそもどういうプロジェクトをやるかを決める「生み出す側」に行かないといけないと思い、事業会社と呼ばれる会社をいくつか受けました。その中でもリクルートは住宅や飲食、旅行などいろいろやっているので、1つの会社にいながら異なる複数のビジネスに関われると思って転職しました。

今日はまず、外から見たときのリクルートのイメージと、中に入ったときのイメージのギャップ、「あ、そうなの？」と感じたことからお話しできればと思います。

1つ目のギャップが、「仕事へのスタンス」という観点です。これがものすごく違っていた。僕がイメージしていた情シスの人というのは、“御用聞き”みたいな感じで、彼らがプロジェクトをマネジメントしていという印象があまりなかったので、「リクルートでもそんな感じなのかな？」と思って入ったのですが、実態は大きく違いました。

実際には各メンバーがかなりの意思を持って案件の舵取りをしている場面が多く、御用聞きではまったく仕事にならないことがすぐにわかりました。

ここからは、「リクルート流プロジェクトマネジメント」の中でも、こだわりを持っている部分を簡単に説明していきますね。

リクルートテクノロジーズの位置づけ

前段として、リクルートグループにおけるシステム開発とITの取り組みについて説明させていただきます。リクルートホールディングスというくくりのなかで、リクルートの各サービスは、それぞれの事業会社で独自に運営されています。

そのなかで、我々リクルートテクノロジーズは、ITとWebマーケティングの専門家集団として、ITの側面からリクルートの事業をより成長させていくというミッションの下、各事業会社のIT戦略の策定や施策の実行、システム化案件の推進など、いわゆる情報システム部門に似た役割を担っている会社です。

今日ご説明するのは主に、（スライド）左上の「大規模プロジェクト推進」の部分についてです。

リクルートグループにおいて、絶対失敗してはいけないような大規模開発や高難易度案件を専門的に対応する部署として、5年前にプロジェクト推進部が誕生しました。

部のメンバーは、現在は45人ぐらいで構成されています。部の役割をひと言で表すと「プロジェクトマネジメントのプロ集団」、「最後の砦」みたいなイメージです。もうどこでも開発できないような難易度の高いプロジェクトを一手に引き受けるという感じです。

仕組みとしては、リクルートグループ内で共通の開発ルールを敷いていて、開発の規模やセキュリティなど規定の項目にチェックが入った案件はすべて、プロジェクト推進部でやるかどうかという経営判断を行います。

各事業単位で「できるよ」と見立てた案件であっても、リスクの高さや移行の難易度など複雑性を見極めた結果、「リクルートテクノロジーズのプロジェクト推進部で実施する」という経営判断がされるケースもあります。そういう意味での最後の砦となる部隊です。

うちの会社には、他にも、オフショア開発やアジャイル開発、スマートデバイス開発、ビッグデータ、SEOなどのWebマーケなど、リクルートのサービスにとって価値のあるIT専門部隊が集まっていて、場合に応じてこうした各部の専門家とタッグを組んで進めることもあります。

余談になりますが、僕が入った5〜6年前は、ビッグデータやセキュリティの部門なんてなかったんですね。でも今ではけっこう当たり前のようにやっていて、人もどんどん増えていますし、組織も機能分化され、より強化されてきています。

何が言いたいかというと、リクルートグループの各サービスが、競合となる他社のサービスに勝っていくためにITの要素で足りないところがあれば、我々が専門部隊を作り、貢献価値を高めていく仕組みになっているということです。

プロジェクト推進部が抱える案件について

ようやく（笑）、今日の本題のプロジェクト推進部の話をします。プロジェクト推進部は、先ほどお伝えしたような難易度の高さを図る基準に沿って案件を受け持つため、必然的に投資額や開発規模が大きいプロジェクトが多くなります。そのため、基本的にある程度成熟したサービスの案件が多いです。

一方で、大規模開発といってもサービスサイトの開発だけではありません。例えば、フロントエンドのリニューアルを行う際は、バックエンドの大きな業務システムも共にリニューアルをしています。複数サービスで同一のシステム基盤を共有している場合もあるので、その場合の難易度は格段に上がります。

あえて分類するなら、カスタマー向けの商用サービスと、裏を支える営業支援システムや入稿システムも守備範囲ですし、人事とか顧客管理、会計システム、勤怠管理システムといったリクルートグループ全体の基幹システムも対象になります。

今、プロジェクト推進部は10案件ぐらいを並行してやっていますが、そのうちの1つにリクルートグループ内のビジネスインフラの刷新という類の案件もありますし、過去には高度セキュリティオフィスの構築という案件もありました。

なので、先ほどのプロジェクト推進部の基準に合致すれば、別に商用のWebサービスだけではなくて、業務系の大刷新や会計システムの大刷新をやる可能性も十分あるわけですし、システム開発要素が少ない案件もごくまれにあります。

なので、システム開発のプロというよりは、プロジェクトマネジメントのプロという役割を担っているとご理解いただければと思います。

大規模開発メソッドの仕組み

さて、今日のメインの大規模プロジェクトの開発スキームについてです。

我々のなかでは、「大規模開発メソッド」という呼び方をしていますが、僕の今の仕事は、スライド中央の「プロジェクト」という立場で案件を推進することです。我々のスキームには、この他にもさまざまな機能、役割があります。

メソッド全体を見ると、プロジェクトを支える仕組みや、我々のプロジェクトマネジャーとしての専門性を磨くための仕組みで成り立っています。

例えば一番左、「組織担保の仕組み」というのは、要するに監査部隊で、プロジェクトに伴走する第三者機関として機能しています。「プロ推運営会」と言っているのは、いわゆるゲートレビューですね。「要件定義ここまで進んだか？」という話や、見える化のサポート、アラート出しなどです。

ちなみに、アラートは僕ら自身の過去の失敗経験を活かして仕組み化しています。「このタイミングでこれぐらい遅延している場合は、大抵このフェーズが延びて遅れている」という感じで知識を数値化して貯めていき、そういった要注意ポイントを自動集計して、プロジェクトリーダーにアラートが飛ぶ仕掛けをつくっています。

「案件担当による支援」という機能が何かというと、先ほど説明した第三者機関から必ず1人が各プロジェクトに派遣されて、進捗を把握しているんですね。そして、その各案件担当者が集まって週1で会議をして全体でリスク把握をしています。

モノだけ見て「うん、なんか大丈夫そう」といったあいまいな判断は基本的に許さず、実際の状況がどうかを見て総合的に判断する仕組みになっています。

前職でも第三者機関はあったのですが、ゲートレビュー時になにか1つ文句を言わないと気が済まない人たちで、ちょっと煩わしいなと感じてしまうことも正直ありました（笑）。リクルートで働くようになってからは、味方というかプロジェクトと一体となってサポートしてくれるので、逆にかなり頼りにするようになりました。

あと説明していないのは……「ガイドと標準」についてですね。

例えば「いわゆる要件定義フェーズって、この観点について、こういうプロセスで、こういうふうに組み立てるのが正攻法だよね？」というような方法論をガイドとして用意しています。

その中でも我々が関わることが多いのが、上流工程ですね。要件定義よりも前の、事業会社ならではの「ビジネス検討フェーズ」と言われるフェーズです。

「何のビジネスをやりたいんだっけ？」「それに対してどういう投資をして、どう開発していくだっけ？」というプロジェクトを固めるフェーズに我々も当事者のひとりとして参加します。

初めてやるときって、そこをいきなりやれと言われても、たぶんやれないです。

なので、「リクルートにおいてビジネスを立ち上げるフェーズでは、こういう考え方で物事を固めていくべきだ」といったフローをガイドとして用意しています。あくまでも方法論ですが。

プロジェクト担当者のサポート機能

右側に「ナレッジマネジメント」や「育成」があります。一つひとつの案件規模がけっこう大きいので、平均1年ぐらい同じ案件をやることが多いんですよね。

そうなると、リクルートグループ全体ではいろんな案件が走っている中で、その人は1年間で1つの案件の経験しかできなくなります。

経験が大事だと言われるプロジェクトマネジメントにおいて、経験を積むのに1年サイクルかかってしまうのです。

こんなにいろんな事業があって、開発パターンも一概には決まっていない環境において「それってもったいないよね」という発想から、「知見共有会」や「PROKAN研修」など、育成の仕掛けをけっこう気合を入れてやっています。

例えば「今、こんなことを考えていて、こんなことがやりたいんだけど」というアイディアを投げると、事務局が過去の知見などを全部まとめて返してくれる、そんな仕掛けがあるイメージです。要するに、プロジェクトを行っている人たちをサポートするだけでなく、その経験値や能力をさらに上げていく仕組みをたくさん揃えています。

ちょっと言い方に語弊があるかもしれませんが、1人の優秀な人がいて、その人だけに依存して進めていくようなプロジェクトマネジメントは、我々プロジェクト推進部の理想ではありません。

ある意味、底上げの力学を働かせて、組織全体がより品質の良いプロジェクトマネジメントを担保できるような仕組みを考えてサポートしているという感じです。

プロジェクトを整理する、大規模開発ガイド

詳細は割愛しますが、先ほど紹介した、「方法論をまとめる」という型は、この1個1個につきパワポが20枚ぐらいあるイメージです。

Ａ群からＤ群は、「プロジェクト定義フェーズ」と呼ばれる領域ですが、そこの方法論だけでもざっと4×20で80枚ぐらいのパワポがあります。

当然今まで慣れ親しんできたタイプの案件と新しい要素を多分に含んだ案件では、同じやり方をしてはダメなのですが、やっぱり大規模なプロジェクトを立ち上げるときのメソッドってある程度は知っておきたいですよね？　基本というか定石はガイドから学んで、それを案件の内容に応じてアレンジして使う感じです。

とくに、我々がプロジェクトを失敗するときって、だいたい「移行」でつまづくことが多いです。よく「現ママの罠」なんて言われますけど、サービスオーナーである事業の企画者が「現行のままなんでよろしく」と、詳細のオーダーがない状態で移行を求めてくる場合は、たいてい何か新しいものを作るよりもずっと難しい傾向にあります。

また、単に「移行」と言っても、データ移行・システム移行・業務移行といったパートに分かれるので、「上流工程で何を見ておけば、どの移行の難易度がどれだけ高いと判断できるのか」といったことも気になるところです。

こうした疑問に答えるべく、我々のこれまでの知見から、「データ移行の難易度を測るためのチェック項目」といったノウハウを一つひとつまとめています。

プロジェクト定義フェーズの設定

次に、大規模開発メソッドの中で重視している観点を紹介しますね。まずは、「上流に力を入れている」という部分です。

「システム開発のプロマネ」という文脈からするとこの書き方はちょっと特殊だとは思うものの、ウォーターフォールでいう「ビジネス検討フェーズ」「プロジェクト定義フェーズ」に非常に力を入れています。

意外に思われるかもしれませんが、プロジェクトマネジメントの専門家として、ビジネス要件について真剣に議論します。「このプロジェクトの目的って本質的になんなんだ？」ということを考えたときに、「この要件が本当にいるのか？」という疑問を事業の担当者に促す。

あるいはその要件に応じて、後ろのフェーズを含めて、「カットオーバーはいつにするべきなのか」「カットオーバー後のサービス運用は円滑に進むのか」「どの体制で進めるのがいちばん効率的か」といったことを、事業の担当者と我々が協力しながら決めていきます。

この「ビジ検フェーズ」でビジネス検討段階をリードすることが、リクルートのプロジェクト推進部において、個人的には一番おもしろい、やりがいがある部分だと思います。システムだけではなく、サービスを作っているという手応えをいちばん感じられる瞬間です。

ビジネス検討フェーズの重要性

とはいうものの、「本質的な目的ってなんだろう？」「この機能、本当にいるのか？」みたいなことを言葉で言うのは簡単なのですが、これが意外と難しい。

事業担当者としてはそこに命を懸けているので、やっぱり「他社のサービスが持っているんだから、あんな機能もこんな機能も……」みたいに次々に実装したい機能が浮かんできます。

そういう状態の中で、システム的なリスクや実装後の運用イメージなどをすり合わせ、「こういうリスクとのトレードオフなら実現できるのではないか」といったことを判断し、伝えていかないといけません。

そういうことをいかに提案できるかというのが我々の力の見せどころだと思っています。「こういうラインナップを作りにいく」「成果物としてはこういうものを作りにいく」というのが、このフェーズでやることですね。

よく想いが先行して、何を成し遂げたいのか最終目標があいまいなまま話が進むこともある中で、我々は絶対に失敗させたくないという想いから、「そこ大丈夫？」「その考えで正しい？」という確認をし、要件を固めにいく責任を負っているのです。