少人数でプロセスを反復させる「スクラム開発」

リクルートでは従来、開発プロジェクトを「要求定義」「設計」「開発」「テスト」「運用」などの作業工程に分割し、トップダウンで進捗管理を行う「ウォーターフォール型開発プロセス」を中心に開発を行うことが多かった。最初に開発対象とゴール地点を定め、それを達成するために人員・時間を投入していくウォーターフォール型開発プロセスに比べ、スクラム開発には以下のような特徴があるという。

図を拡大

「最初に開発期間を決めて、その期間内で出来るところまでとスコープを切って開発します。開発期間を2週間と決めたら、その中で優先度の高いものから作ってリリースする形です。あくまで2週間でできることだけやりますね。最初のリリース後もこのサイクルを繰り返していき、2週間単位でソフトウェアを進化させたり、改善したりと運用していきます。こうすることで、最初のリリースを早めるだけでなく、途中で起きたシステムの問題点も修正できます」（志田氏）

予め決められたリソースと期間内で作れるものだけ作った状態でリリースしていく。そしてリリース後も、ABテストなどの手法を用いてそのPDCAサイクルを回し続ける。これにより、たとえばウェブサイトやアプリの公開後も、OS対応やサイトリニューアルといった「1→10」の改善を機敏に行えるようになった。

志田氏は、「今の社会は、1年前に考えたことが陳腐化しやすい、先の読みにくい時代」という。その激動期の中では、長期間で作ってリリースする一発勝負の開発プロセスよりも、短期でサイクルを回して臨機応変に進化させていくほうが、確実なROIと投資抑制という意味においても意義が大きいと捉えている。

さらに、スクラム開発には「クロスファンクション型の少人数のチーム体制」という最大の特徴がある。サービス企画者とシステム開発者を同じチームに配し、人員規模を最小限にとどめることで、セクショナリズムによって発生する無駄なプロセスを排除し、スピードと品質を高めるという狙いだ。

「スクラムエンジニアに求められるケーパビリティは大きく2つあると思います。アプリ開発やインフラ構築など幅広く、かつ深さを備えた技術力。継続的なプロセス改善能力。そしてそのチームの支援役となるスクラムマスターには、For The Teamの精神に基づくチームビルディング能力が必須となります。チーム全員が等しく状況を共有し、全部の作業に関わることが理想ですね。インタラクティブな企画・要件検討を推進し、システムに即反映できる。そのために、共通ゴールのもと、1つのチームとして機能できることでサービスを企画・開発するスピードはより速くなると考えています」（志田氏）

このような背景を受け、同社ではこの開発体制について、社員の理解度を上げようと努めている。たとえばそのひとつとして、「ScrumAliance」という認定制度を活用。リクルートグループ各社のサービス企画責任者も巻込んで研修を実施するなど、組織の枠を越えてグループ全体のサービス進化という目的のもと、スクラム開発やその概念の理解促進を図っている 。