品質だけじゃない、事業特性に合わせた本質的なプロマネとは?

事業展開ステップとシステム化方針の整合性を取る

今回取り上げるプロジェクトは、あるビジネス領域の「新規事業」に対する「新システム開発」です。当社の企画部門とプロジェクト推進部（以後、プロ推）で行った初期検討において、さまざまなビジネス要件を盛り込んだ結果、初期開発が500人月を超える規模に膨らんでいる状況でした。この人月は、リクルートにおける新規事業の過去開発事例と比較しても相当大きい状態でした。

その背景には、競合に対して後発での事業展開となっている中で新規ビジネスとしてどのようなアプローチで登っていくのかについて十分な議論ができていなかったことが、開発規模が大きくなっている根本原因としてありました。

この状況において、まずは「システム利用者への提供価値と競合に対するリクルートの優位性」をどのような順番とタイミングで事業展開していくのかを言語化することに企画側と共に注力しました。その上で、プロジェクトの目的・システム化の方針をプロジェクト計画書としてアウトプットすることを始め、企画部門から開発者まで含んだプロジェクト全体で同じ方向を向いている状態を作ることに多くの時間を使いました（下図参照）。

こうした取り組みの結果、個々の各論検討の中で「これは初期開発に本当に必要なのか？」、「システム利用者への提供価値を考えた時にこうした方が良いのではないか？」といった会話が繰り返されていきました。最終的な総工数としても当初見積りの40%程度に圧縮することができました。

開発特性に合わせた開発スキームを選択する

今回のプロジェクトは「新規事業」に対する「新システム開発」という内容であったため、企画部門では類似のプロジェクトと同様にアジャイル型の開発なんだろう、という漠然とした雰囲気がありました。しかし、プロ推としてはそうした前提や思い込みにとらわれず、整理された開発スコープと企画側との会話の積み重ねから、このプロジェクトの開発特性を整理することを行いました。その結果、次の2つの開発特性が見えてきました。

特性1：開発規模が大きい（後発のため競合と同レベル以上の機能提供が初期スコープに求められたため）

特性2：作るものが明確（はじめにリリースすべき機能が明確）

アジャイル開発のメリットは「作るべきプロダクトが不明確で、早期リリースしてマーケットからのフィードバックを得ながら改善（アジャスト）していく必要があるもの」だと思います。

今回の開発特性を考慮すると「MVP（Minimum Viable Product）が明確で規模が大きい ＝ アジャイル開発ではなくウォーターフォール型で一気に作りこみつつ、推進を工夫して早期にマーケットに出したほうがよい」という判断に至り、経営陣ともウォーターフォール型で開発を進めることを意思決定しました。

事業特性を踏まえてカットオーバーの時期を決める

開発スコープ・開発スキームが明確になり、カットオーバー（サービスイン）をいつにするかについて決める必要がありました。

企画部門としては新規サービスとしてなるべく早くリリースし、後続マイルストンまでになるべく長いフィージビリティスタディ（企画段階の仮説の証明）期間を確保したいたいという要求があり、工期の余裕はあまりありませんでした。プロジェクトとしてQCD（Quality、Cost、Delivery）の優先順位を定義し、「D（納期キープ）を最優先」とする方針を掲げることにしました。

リクルートにおける大規模開発では、詳細見積りを確定させる要件定義の終了から基本設計中盤までのタイミングで、ある程度のバッファを含めてカットオーバー日程を確定させて進めることが通例になっていました。さらに、新規事業では想定外のリスクが発生する可能性が高いため、通常よりも多くバッファを積んでおきたいという意識が働く状況でした。

しかし、先ほど触れた通りカットオーバー後にフィージビリティスタディに期間を長くとりたいという要求が出ているため、早いタイミングでバッファを含めた形でカットオーバー時期を確定させるわけにはいきませんでした。開発スケジュールにバッファを含めずに管理を行い、プロジェクト全体を通して許容できるギリギリのタイミングでカットオーバー日の決定を行う、という方針にしました。

上記を進めるにあたり、開発以外の組織（営業/業務支援/広報 など）が担当しているタスク、依存関係、スケジュールをプロ推が開発で行っている見える化の枠組みと同じ枠組みでとらえることにしました。ステークホルダーのスケジュールと開発側のスケジュールが横串で見ることができるようになった結果、プロジェクト全体のクリティカルパス・判断内容が明確になり、適切な判定ポイントを関係するステークホルダー、経営ボードとも合意することができました。

プロジェクトからの学び

「ウォーターフォール開発＝品質重視で遅くて重い」という考え方は必ずしも正しくなく、特性に合わせた推進を行うことで、ウォーターフォールの良い面を保ちながら柔軟性を持って開発するということを実現できました。

今回のプロジェクトにおいては、事業特性を踏まえたプロジェクト計画を作ることが、高い柔軟性を持ったマネジメントを行う上で大切なポイントでした。また、スピード感を持った運営において個々の判断の精度を落とさないために、進捗や課題の可視化は基礎的な武器として効果を発揮しました。

最後になりますが、ユーザー企業のIT部門としてシステム開発も経営の一環であるという意識を持つことが非常に重要だと考えています。結果として、杓子定規な開発マネジメントではなく、開発・事業特性に合わせて「われわれに求められていることは何なのか? 今回のプロジェクトにおいて最適なプロジェクトマネジメントはどういったものなのか?」ということを個々のメンバーが考え抜くことが、より強い組織として成長していくことにつながっていくのだと思います。