事業者と開発者の壁はどう壊す？　リクルートテクノロジーズの大規模プロジェクトメソッド

開発側と事業側の役割の違い

辻純一氏（以下、辻）：みなさんへの質問なのですが、プロジェクトを実施する際、要件定義フェーズの前に、「この案件の目的はそもそもなんだっけ？」という、検討フェーズを設けている方はいらっしゃいますか？

回答者1：私自身は担当していないのですが、別の担当が企画構想というかたちで、プロジェクトのターゲット、目的、KPIを発表して、承認をもらって進めています。

辻：システム企画の人が1人で全部書きあげるイメージですよね。

回答者1：そうですね。なので、時間がかかってしまいます。

辻：大変ですよね。「こういうシステムを作りたい」という構想をする企画寄りのスキルと、「そのシステムにはどんなリスクがあって、どのぐらいの工数がかかるのか」を見極めるシステム寄りのスキルは、異なるスキルなので、同じ人がどちらも兼ねるというのはなかなか難しいと思います。そもそも必要なスキルが違うんですよね。

我々は、「企画構想は、システム開発の専門家とプロジェクトマネジメントの専門家と商品企画の専門家の合作として作らなければいけないよね」という発想でやっています。さきほどお話ししていたように、それを1人でやるのはしんどいです

回答者1：今のところ、1人の方が走り回っているという状態です。

辻：それがさらに大きな規模になると、余計に大変ですよね。

開発側の立場と事業側の立場がどういう関係性なのかというのは、外から見るとよくわからないと思いますので、そこをお話しできればと思います。

プロジェクト推進部の案件において、システム開発にまつわることすべてをリードすることが基本的には我々の役割だと自負しています。ですが、体制を描くのは難しい場合が多いです。

新しいサービスを立ち上げようという案件になると、サービス設計とシステム開発のダブルマネジメントになる場合も多いので、まずは「誰がここの意思決定をするのか」「開発のトップと事業のトップで決めるべきはどこか」というところを定義します。

時と場合によりますが、基本的にはプロジェクトオールの体制を1枚描きます。

案件の特性にもよりますが、「こういうレイヤーでの意思決定が必要だ」とか「こことここの会議体はこう設計するべきだ」という意思の下、スケジュール・体制・会議体の基本3点セットを描いていきます。

基本的に、誰にどんな価値を提供するのかといったサービスの骨格は事業側で検討しますが、やはり「業務設計から見たときに、システムはどうあるべきなのか？」というところは、我々も入らないとうまくいかないこともあるので、事業の担当者と「このフェーズでは、こういうことを考えなければいけないですよね」という話をしながら、そのフェーズを推進していきます。

このあたりは、5年間の長い歴史のなかで、プロジェクト推進部の活動がだんだん認知されてきて、今は「この部署のメンバーに任せておけば」という信頼関係ができ上がっていますが、やはり最初は衝突することもありました。

何度も事業との話し合いを繰り返すなか、我々が提供できる価値を伝え、実績を積み上げ、それをもとにした説得力のある対話を続けていくことで、やっと今、我々に任せてもらえるようになり、それぞれの価値が発揮できる土壌が整い出したという感じです。

ここでさらにみなさんに質問ですが、開発する立場から見て、事業の担当者に対し「さすがにここまではやってよ」ということがあると思いますが、そういう場合はどこまで踏み込みますか？

回答者2：ケースバイケースです。あるところではうまくいったコミュニケーションが、また別のところではそうはいかない……。

辻：けっこう難しいですよね。僕らは、「プロジェクトが成功するために言ったほうがいいのであれば言おうよ」というスタンスを大事にしています。事業との壁が生じるのは多少これまでの文化的な要素もあるとは思いますが、リクルートテクノロジーズでは、そういう壁となるそれぞれの文化や当たり前を5年間の中でだんだんと壊しながら今の関係を作ってきたという感じです。

数億円規模のプロジェクトのスケジュール作成

辻：次はメソッドの紹介です。

例えば、大規模案件のプロジェクトリーダーに任命されたときに、スケジュールの組み立てというのはけっこう難しいと思います。

プロジェクトを推進する際、「最初の計画が大事だ」といわれており、我々の要件定義フェーズは通常3ヶ月としています。

2週間ぐらいまでならタスクを引ける感覚があると思いますが、3ヶ月先までとなった場合、どういう組み立て方をすると計画が成り立ちやすいかについてこれからお話しします。

全体でみると、Level0〜3の4段階のスケジュールを作成し、管理していく方法があります。Level0は、いわゆるマスタースケジュールと呼ばれているものです。パワポ1枚で、プロジェクトの最初から最後までを俯瞰できるものになります。

ビジネス側がやること、開発側がやることなど、それぞれの担当者がやるべきことの大枠を書いていきます。

その上の方にフェーズが書いてあって、「論理的にはこういうことが組み合わさって、カットオーバーまでいくよね」という内容がわかるようになっています。

我々はその後、Level2へ飛び、それぞれの該当フェーズにおけるタスクを具体的に書きにいきます。「1週間以内の単位で、タスクを全部組み立てなさい」と。

要件定義フェーズが3ヶ月だったら「3ヶ月分を全部想像で書きましょう」「前後関係を論理的に組み立てながら書きましょう」ということをやります。

その後、Level0とLevel2をベースに、Level1を書きます。

Level0のマスタースケジュールでは整合性が取れていたはずなのに、各チームのリーダーに書いてもらった詳細スケジュールを突き合せてみると、それぞれの感覚の違いやどれだけバッファを含めるかといったことから、ズレが発覚するわけです。そのズレを確認するなかで、「このフェーズでこんなにかかっていたら、ここ進められないから全体遅延するよね」など、いろいろな課題が見えてくるんですよね。

そこを精査して詳細な全体スケジュールに落とし込むのが、プロジェクトリーダーの腕の見せ所です。最初のプランニングがとにかく後あと効いてくるので、このプロセスでスケジュールを矛盾なく組んでいくことで、リスクが予見でき、後フェーズでつまずく場面がぐっと減ります。

また、Level2のうち同一作業明細で構成されるものがLevel3と言われます。基本的にはLevel2とLevel3に対して、双方の進捗を確認し、アラートを検知していきます。

このように、スケジュール作成にも独自の工夫をしています。規模が大きくなって、長い未来までスケジュールを引かなければならない時って簡単にはいかないので、こういったメソッドがしっかりあるんだというのも、転職してけっこう驚いたことの1つですね。

リクルート流のチームビルディング

辻：次に、チームビルディングです。個人的には、ここがいちばんミソなんじゃないかと思っていたりもするところです。

よくお客様に対して「○○様」と付けたりしますが、我々は事業側の役員も、ベンダーの現場の方も含めて、立場を超えてチームでやっていきましょうという意味で、基本的に「様」というのはやめて、「さん」付けで呼ぶようにしています。ちなみに僕にはあだ名があるんですが、パートナーの若い人からも普段、あだ名で呼ばれたりしています。

このように、コミュニケーションルール1つをとっても、「我々が大事にしていることは何で、それに対して1つの目標に向かってがんばりましょう」という空気をあえて醸成していくことを大事にしています。開発プロジェクトといっても、人と人のつながりが根幹にあるので。

プロジェクトを成功させるために必要なこと

司会者：コンテンツは以上となります。今までお話ししたことでも、関係ないことでも、辻自身に関することでもなんでもけっこうです。何かご質問があればお願いします。

質問者1：実際にプロジェクトを行っていく中で、組織構成としては、もとは別々のチームで、プロジェクトが始まるといろんなチームから人が集まってくるというイメージですか？

辻：そうです、プロジェクトが立ち上がったら「プロジェクト推進部○○グループ」のように組織を新たに作ります。その案件をやるために必要なメンバーを、人事発令を出してアサインするかたちになります。

基本的には、プロジェクト推進部の中の、プロジェクトマネジメントをやるメンバーから編成しますが、例えば僕のグループでは、アプリケーション基盤の専門組織からその領域のプロフェッショナルである3名にも入ってもらっています。

基本的に我々がやる案件というのは、ミッションクリティカルなので、リクルートテクノロジーズとしても、“負けてはいけない戦い”だという認知があります。

例えば、僕がある案件を受けて、「こういう案件だから、このあたりに○○さんの力を貸してくれない？」とか「こういう人をアサインできない？」という話をして、上長同士のOKが出れば、「来月の組織はそれで発令しよう」となります。

僕の立場としては、プロジェクトを成功させるために必要なことであれば、人の異動であろうが、物の購入であろうが、「事業側の体制を確保してくれ」というお願いであろうが、全部やります。

例えば、プロジェクト体制の中で、アーキテクチャチームを作り、プロジェクトメンバーをチームリーダーにして、配下はそこの組織から作るということを行っています。プロジェクトに必要であれば、事業側の体制についても、このようにお願いすることもあります。

また、UI・UXなど事業側に担当者がいる場合でも、「自分たちの視点からも付加価値を出せる」と感じたら、「うちのメンバーを入れてよ」という話をすることもあります。

そのあたりも、先ほどお話しした「ビジネス検討フェーズ」と「プロジェクト定義フェーズ」で、体制やスケジュールを決める中で話し合います

質問者1：ありがとうございます。

ビジネスの背景を共有する

質問者2：質問というより感想になってしまいますが、自分が今携わっているところでは、事業側の方とIT部門の方、あとはシステム開発側の間でのコミュニケーションロスというか、ズレがすごく大きいです。

リクルートテクノロジーズでは、その３つが一体となって企画段階から進められているというところで、うちの組織との差がすごいなと思いました。

辻：例えば、先ほどの「さん」付けの話がすごくわかりやすいと思いますが、全員に背景や目標を理解してもらった上で、「同じ方向に向かってがんばりましょう」という空気をあえて醸成していくことがポイントです。

例えば、プロジェクトのビジネス背景や競合サービスと比較した状況などをリアルな情報として事業側に「説明してください」とお願いし、開発の方やベンダーの方にも集まってもらって、事業側の偉い方から「こういうミッションで、今回は失敗できないから、みなさんお願いします！」というようなことを伝え、全員のモチベーションを上げる会を開いたりもしています。

難しい状況にぶつかったときにも、事業背景を知って「リクルートのために」「この事業のために」と思える人が100人の体制のなかで何人いるのかということが最後に効いてくると思います。

また、普段の何気ないコミュニケーションも大切にしていて、座席表ひとつとってみても、プロジェクトにおいて重要なポジションにいる人とは、他のメンバーも常に意思疎通が取れるよう配慮しています。

プロジェクトにアサインされた以上はチームメイトとして、立場に関わらず積極的に意見を言ってもらいたい。それがプロジェクトの成功に直結してくるので。チームづくりが重要な役割だと思っています。

質問者2：ありがとうございます。

プロジェクトマネージャーに求められる資質

質問者3：プロジェクトマネージャーをするにあたって、必要な資格はありますか？　例えば「PMBOK」とか。

辻：資格がないとやれないということはありません。我々は、そういう見方はまったくしていません。PMBOKを持っていたからといって、事業目標に対して正しいプロジェクト計画が書けるかというと、そこは一概には言えないと思っています。

もちろん、関心や意欲があって、PMBOKや情報処理のプロジェクトマネージャーの資格を自分で取っている人はいます。ですが、「この資格が必須」というのはうちの会社の場合、まったくありません。それよりもどんな経験を積んできたのか、ということが大事だと思っています。

質問者4：私はSIerなのですが、先ほどの事業側の方との関係に関して、私も事業側に入り込みたいときがあるのですが、やはりSIerだと「いただいたお金に対して必要以上にやりすぎたらいけない」というしがらみが強いです。

辻：リクルートテクノロジーズでは、事業側に対して価値の高い動きをしてくれるかどうかが何よりも重要な評価軸となります。そのアクションは、プロジェクトの成功、ひいては、サービス、事業にとってどんな価値があるのか、が問われるわけです。

金額が問題になることもありますが、ビジネス上、本当に必要であれば、金額が高いとしても、事業側に説明を行うことで、相手も納得してくれることが多いです。

たまに事業側とぶつかり合うこともありますが、お互い事業背景を知って「リクルートのために」「事業のために」と同じ方向が見えているので、最終的に問題はないと思います。

司会者：お時間となりましたので、終了とさせていただきます。本日はありがとうございました。