「プロトタイプ開発と本番開発の並行稼働」で新規開発のリスクを早期に排除

不確実性が極めて高い新規開発のリスクをどう管理するか？

今回紹介するのは、リクルートが運営する大規模Webサービスに新たに投入する新サービスの開発プロジェクトです。

リクルートのサービスの多くは、情報を提供するクライアントと、情報を受け取るカスタマーという2つのお客様をマッチングする「場」を提供しています。そして、情報を提供するクライアント側には、多くのパートナーが存在します。

本プロジェクトでは、マッチングの「場」をカスタマー・クライアントに双方にとって、より便利なサービスにするために、パートナーに新たな業務支援サービスを提供することを目指したプロジェクトです。

Webサービスの開発プロジェクトには、大きく分けて「既存システムの機能強化・エンハンス」と「新サービスの新規開発」の2種類があります。今回のプロジェクトは後者にあたり、インフラやフレームワークも含めて完全に一からすべてを設計・開発する必要がありました。

このようなプロジェクトの場合、当然のことながら既存システムの機能強化やエンハンスなどと比べ、不確実性がより高まることになります。既に稼働実績があるものに手を加えるのではなく、一からすべてを作り上げなくてはならないため、設計を少しでも誤れば「完成したはいいが、まともに稼働しない」ということも十分にあり得ます。

加えて、これまで採用したことがない技術やサービスもいくつか導入する予定になっていました。具体的には、電話の応答を自動的に行うIVR（自動音声応答装置）や、FAXを自動的に読み取るOCR（光学的文字認識）といった技術を新たに導入する必要がありました。これらの中には外部のクラウドサービスを使うものもあり、実際にこちらが意図した通りに動いてくれるかどうか、正確に予想するのは簡単ではありません。

このように、本プロジェクトは不確定要素が極めて高いため、本来ならじっくり時間をかけて事前検証を行い、その結果を基に慎重に要件定義や設計を進めていきたいところです。

しかし、今回のサービスは、多くのパートナー企業が共用するプラットフォームサービスであるため、いち早くサービスを市場に投入し、より多くのユーザーを獲得することに成功した企業が、業界のデファクトスタンダードになるという側面があります。そのため、競合他社も多い中でいち早くサービスをリリースしたいというニーズもありました。

要件定義とプロトタイプ開発を並行して行う

このように、本プロジェクトはスタート前から「時間をかけて不確実性を排除したい」「時間をかけずに開発していち早くリリースしたい」という2つの相反する要件を抱え込むことになってしまいました。「一体どうすれば、この相反する2つの要件を両立させることができるのか……」

当初は、アジャイルのイテレーション開発で段階的に開発することを考えました。しかし今回、われわれは、どのようなシステムを顧客に提供すべきかイメージできており、最終的なシステムの姿は見えているので、リソースを有効活用し、システムを一気に開発する方が、最終的なリリースが早くなるのではと考えました。

では、どのような不確実性を排除すれば、システムの開発を進めることができるのか。それは上述した「採用したことのない新たな技術・サービスを利用すること」でした。この新技術・サービスがわれわれの意図した通りに動かすことができると確証が得ることができれば、リソースを最大限に有効活用し、一気に開発を進めることができると考えました。

こうして頭を悩ませた結果、最終的にたどり着いたのが「事前にプロトタイプ開発を行う」という方法でした。本格的な開発を始める前に、まずは簡易版のプロトタイプの開発を行い、「この技術・サービスは意図した通りに動くのか？」「この設計方針で果たしてきちんと稼働するのか？」といった懸念点を事前に取り除いておくことにしたのです。

こうしたやり方は特に珍しいものではなく、多くのプロジェクトで採用されているものです。ただ本プロジェクトの場合は、とにかく時間が限られている点がネックでした。通常のやり方のように、「まずプロトタイプ開発を行い、その結果を待ってから本番開発の要件定義に進む」というやり方では、期日までに到底間に合いそうにありません。そこで今回は、通常のプロトタイプ開発とは若干異なる方法をいくつか取り入れてみました。

まず1つ目は、「本番開発とプロトタイプ開発を並行して行う」というものです。プロトタイプ開発が終わるのを待ってから本番開発の要件定義を始めるのではなく、プロトタイプ開発と要件定義を同時並行で進めるようにしました。

通常の開発では、要件定義フェーズで主に上流工程を担当するSEがユーザーにヒアリングを行いながらビジネス要求を抽出していきます。そしてその間、下流工程を担当するSEやプログラマーは、開発工程に備えた準備作業に時間をあてています。

しかし本プロジェクトでは、この要件定義フェーズの時間を使って、下流工程の担当者に先行してプロトタイプ開発を行ってもらうことにしました。その目的は既に述べたように、実現性に不安のある機能や技術の事前検証にあります。したがって、まずはそれらの機能にターゲットを絞って開発を行いました。その代わり、それ以外の主要機能や周辺機能、例外処理などの開発は後回しにして、とにかくスピードを重視して開発を行い、少しでも早く検証結果を出せるようにしました。もちろん、並行して進められている要件定義において決まった新たな要件や仕様は、適宜プロトタイプ開発チームにも伝えられ、その内容がプロトタイプに反映されます。

このようにして要件定義フェーズの段階で、予想される懸念点をあらかじめクリアにしておけば、後工程での手戻りも防げますし、通常のプロトタイプ開発のようにプロジェクト全体の工程が伸びてしまうこともありません。

プロトタイプ開発の成果をそのまま本番開発へと引き継ぐ

2つ目のポイントは、プロトタイプ開発の成果物を検証作業に限って利用するのではなく、そのまま本番開発につなげられるようにした点です。

通常のプロトタイプ開発では、検証用途に特化した簡易的なソフトウェアを開発しますが、そのソフトウェアは検証作業が終われば「お役御免」となります。そして本番開発でまた一から本番用のソフトウェアを開発することになります。しかしそれでは、プロトタイプ開発と本番開発で二度手間が発生してしまうため、短納期は実現できません。そこで、要件定義の結果を待たずとも開発を先行して進められる部分、特にシステムの骨格部分に関しては、当初から本番開発を意識したプロトタイプ開発を行いました。あくまでもプロトタイプですから機能は限られるものの、要件定義が終わって開発作業に入る際には、このプロトタイプにさまざまな機能を載せていくことでそのまま本番開発が行えるようにしました。

このような工夫を凝らした結果、結果的にこのプロジェクトは当初予定より開発期間を3割ほど縮めることができ、短納期のうちにシステムを開発できました。あらかじめプロトタイプ開発でシステムの骨格部分をほぼ完成させていたことに加え、開発者があらかじめプロトタイプ開発を通じてシステムの仕様に熟達していたため、本番開発でも通常より早く仕様を理解できたことが功を奏したのだと思います。

もちろん、当初の目的であった「不確実性をあらかじめ排除する」という目的も達成できました。先に挙げたIVRやOCRといったこれまで実績のなかった技術やサービスに関して、プロトタイプ開発であらかじめ動作を入念に検証した結果、幸いにも当初の見込み通りの効果を得られることがわかりました。逆に言えば、もしここで問題が発生していたら別途対策を検討する必要がありましたから、開発期間をここまで短縮するのは難しかったと思います。

しかし、もし後工程で問題が露見していたとしたら、かなりの手戻りを強いられるため、さらに多く時間や手間を強いられていたことでしょう。そのことを考えれば、やはりプロトタイプ開発で先行して懸案をクリアにしておくことは、極めて有効だったと考えています。

• 

本番開発とプロトタイプ開発を適切につなぐ体制が重要

ここまで読んでいただいた限りでは、本プロジェクトで行ったプロトタイプ開発は極めて簡単に運んだように思われるかもしれません。しかし実際にはさまざまな工夫を凝らし、いくつかの条件が幸運にもそろった結果、幸いにもいい結果を生むことができたのだと思います。今振り返ると、もし何も考えずに単に要件定義とプロトタイプ開発を並行して行っただけでは、今回のようにうまくはいかなかったでしょう。ここで重要だったのは、本番開発とプロトタイプ開発を適切につなぐ体制でした。

もし、要件定義の担当者がプロトタイプ開発にも参加するとなると、要件定義の作業に遅れが生じてしまう恐れがあります。かといって、要件定義とプロトタイプを完全に独立して進めると、開発者の勝手な思い込みで実際の要件とはかけ離れたプロトタイプが出来上がってしまう恐れがあります。これでは技術検証の効果が薄れるばかりか、開発の成果をその後の本番開発に生かすこともできなくなってしまいます。

このジレンマを解決するには、要件定義とプロトタイプ開発の間をうまく橋渡しして、要件定義の内容を適宜プロトタイプ開発にフィードバックできる人材が必要です。本プロジェクトでは幸いなことに、社内のオフショア開発担当者がこの役割をうまく演じてくれました。

よりコスト、スピードを重視するため、開発はベトナムのオフショアベンダーと協働しましたが、この担当者が、要件定義の内容を適宜ベトナムのプロトタイプ開発チームにフィードバックし、後にプロトタイプ開発を本番開発と合流させることを意識しながらゴール設定を的確に行ってくれました。

その結果、当初の目論見通りにプロトタイプ開発を進め、その成果を本番環境開発に引継ぎ、一気に開発スピードを上げてシステムをリリースすることができました。

本番開発とプロトタイプ開発の並行稼働は、今回紹介したプロジェクトのように、不確実性が存在する開発プロジェクトにおいては特に有効だと思われます。ただしこのやり方を成功に導くには、並行稼働を適切にマネージできる体制作りが重要になってきます。今後は本プロジェクトから得た学びを生かして、プロトタイプ開発のメリットをさらに追及していければと考えています。