「当たり前を疑う」ことで未知の領域のプロジェクトを成功に導く

リクルート初の金融サービスのシステム開発プロジェクト

今回紹介するのは、リクルートが2017年に提供を開始した金融サービスのシステム開発プロジェクトです。多くの方にとって、「リクルート」と「金融サービス」はなかなか結び付かないかもしれません。しかし、リクルートは創業以来、新しいサービスを生み出すためにチャレンジを続けており、実は金融分野にも裾野を広げています。

リクルートが2017年に始めた金融サービスは、リクルートのWebサービスを使って宿・店舗の予約や運営を行っている中小企業に対して融資を行い、資金提供を行うというものです。

これらの企業が日々Webサービスを通じて顧客からの予約を受け付けた履歴データは、リクルートのWebシステム上にすべて保管されています。旅行、美容院、飲食店といったさまざまなサービスを展開するリクルートだからこそ、金融機関にはない情報を持ち、これらのデータに対してAIを駆使して分析を行うことで、その企業の信用度と与信枠を自動的に算出し、人手を掛けずに小口の融資を迅速に行うことを可能にしました。

このプロジェクトは、会社全体として大きな期待がかけられていたと同時に、技術的にも新たな挑戦が多く、社内的にも大きな注目を集めていました。

リクルートのサービス開発においては、スピードや柔軟性を重視したアジャイル開発手法と堅実なプロジェクト進行を重視したウォーターフォール開発手法を使い分けています。本サービスの中核を担う基幹システムは融資と返済の金額計算を担い、かつ貸金業法を確実に遵守する必要があるため、品質を重視したウォーターフォール型の開発手法を採用しました。

ただし、プロジェクトメンバーに金融システムの開発経験者がほとんどおらず、かつ大半がプロジェクト立ち上げ直前に中途入社した者ばかりで、リクルートの開発案件自体にもまだ不慣れでした。プロジェクトは、さまざまな不安要素を抱えての船出となりました。

金融の予備知識がほとんどない中でのプロジェクトスタート

クリアすべき第1の関門は、「金融の業務知識の習得」でした。大半のプロジェクトメンバーが金融ビジネスはおろか、金融システム開発の経験すらありませんでした。そのため、まずメンバーに金融の知見教育を施し、システム開発に必要な業務知識を身に付けるとともに、もともと金融の知識を有しているメンバーを増員しました。

• 

  金融関連法令等に対する要件抽出

こうして順調に知見を蓄積していきましたが、一方で知識が身に付くことによる弊害も危惧していました。金融システム開発の慣習やセオリーについて知れば知るほど、「金融システムとはこういうものだ」という先入観にとらわれやすいのです。例えば、「パッケージ製品を使うか、スクラッチ開発を行うか」という点もそうです。

今回のように不慣れな領域のシステムを開発する場合、業界標準や業界慣行があらかじめ実装されたパッケージ製品を採用してリスクを回避するのがセオリーです。事実、「パッケージを採用するべきでは？」という意見も一部ではあったのですが、極力早くサービス提供を始めてノウハウを蓄積するには、無駄な機能はなるべく省きたいとも考えていました。

そこで、メンバー同士で「今回のサービスで本当に必要とされる機能は何か？」を徹底的に議論した結果、たとえ多くの金融システムに含まれる機能であっても「本サービスには不要である」「品質と納期の要件を満たすためには外した方がいい」と判断しました。既存の金融業務とは異なる革新的なサービス実現のために、既存に最適化されたパッケージではなく、必要最小限の機能だけをスクラッチ開発するという方針を定めました。

このように、単に従来の慣習やセオリーを踏襲するだけではなく、常にプロジェクトの本質的な価値を追求し、「ビジネスゴールを達成するために本当に必要なものは何か？」と問い続けることが、慣習やセオリーに縛られない大胆な決断を生むのだと思います。

ばらばらの方向を向いているメンバーをいかに束ねるか？

前述したように、プロジェクトのメンバーはほぼ全員が中途入社であり、金融システムの開発はおろか、リクルートの開発プロジェクトに関わることもほとんど初めてでした。そのため、当初はプロジェクト全体のまとまりに欠け、メンバー全員がなかなか同じ方向を向くことができませんでした。

そこでまずは、大規模システム開発においてリクルートが採用している「大規模開発向けプロジェクトマネジメントスキーム」の運用を徹底させることにしました。リクルートでは、過去の大規模開発のノウハウを基に独自に開発したプロジェクトマネジメントスキームを持っています。

今回のプロジェクトでもこれを採用したのですが、その運用を徹底させることでプロジェクト全体の方針を明確に打ち出し、全体の意識統一を図ったわけです。しかし残念ながら、これだけではプロジェクトの一体感を十分に高めることはできませんでした。

なお、プロジェクトのメンバーは、大きく事業やサービスの企画を担当する「企画チーム」とシステムの設計・開発を行う「開発チーム」に分かれていましたが、プロジェクト立ち上げ当初から両チーム間の連携に課題を抱えていました。企画チームはなるべく早いサービス開始や柔軟な仕様変更・追加を重視していました。一方で、開発チームは金融システムにふさわしい高い品質や安定性を担保するために、なるべく早くシステム仕様を確定し、堅実なウォーターフォール型開発を進めることを望んでいました。

この両者の異なる方向性がプロジェクト立ち上げ当初からぶつかり合った結果、4カ月経ってもシステム要件が確定しないという異常事態に陥ってしまいました。そこで、メンバー全員が同じ方向を向けるよう、両チーム間で何度も話し合いの場を持つなど、さまざまな施策を講じました。その結果、ある程度チーム間の連携は取れるようになったものの、依然としてプロジェクト全体の一体感は十分に醸成できませんでした。

そこで、既存の大規模開発スキームではカバーしきれない部分や、今回のプロジェクトにはそぐわない部分、あらためて強調したいポイントなどをシンプルな「17か条」のルールとして定め、メンバー全員に周知しました。こうしてシンプルなメッセージとルールをメンバーやステークホルダー全員に提示することで、ようやくプロジェクト全体の一体感が得られたとともに、既存の標準スキームではカバーできない部分を柔軟にローカライズすることで、プロジェクトに最適化したローカル標準を現場に浸透させることができました。

プロジェクトマネジメントにおいて、プロジェクト運営のルールをきちんと定めてそれを確実に運用していくことは極めて重要ですが、時にはこのように、組織標準であっても常に事業ビジネスやプロジェクトの特性を考慮して現場に最適な形でカスタマイズすることで、より価値の高いプロジェクト運営ができるのだということを実感しました。

時にはルールやセオリーを大胆に見直す判断力も必要

こうして幾多の困難を乗り越え、開発を進めていった結果、何とか当初の予定通りにシステムをカットオーバーさせることができました。開発コストは当初の想定内に収めることができ、そして金融システムにおいて最も重要である品質面においても目標を達成し、カットオーバー後1カ月間でシステムに起因するトラブルは1件もありませんでした。

立ち上げ当初は不利な条件ばかりが目に付き、その後もさまざまな困難に突き当たったこのプロジェクトでしたが、ここまで紹介してきたようにリクルートの伝統的なカルチャーである「常識にとらわれず、本質を追い求める姿勢」を貫いた結果、金融システム開発のセオリーに縛られない斬新な発想で、開発スコープを大胆に見直すことができました。

また、既存のスキームに盲目的に従うだけでなく、プロジェクトの事情に即して臨機応変にスキームをローカライズすることで、体制や運営面での危機を乗り越えられました。今後もこうしたポイントを意識し、プロジェクト運営を磨き続けていくつもりです。