チャレンジからの撤退。苦渋の決断から学んだプロマネの流儀

リクルートグループで、大規模かつ高難易度のプロジェクトマネジメントを専門的に担当するための組織が存在します。それは、リクルートテクノロジーズに存在するプロジェクト推進部(通称：プロ推)です。組織発足から8年が経ち、さまざまなプロジェクトにおいて困難な局面に直面し、それを乗り越えてきた中で、リクルートの大規模プロジェクトは進化してきました。

本連載では、そのような局面において、プロ推としての進化や学びにつながったプロジェクトを紹介していきます。

今回取り上げるのは、プロジェクト推進部が組織された初期に担当した人材領域ビジネスのネットサービスリニューアルプロジェクトです。生産性向上に向けてマネジメント方針を大きく見直すチャレンジを行いましたが、結果として仮説通りにいかず、プロジェクトの途中でその方針を転換しています。ただし、結果自体は想定通りでなかったものの、その過程で組織運営に影響を与えた知見を得ることができました。

開発生産性を高めることにチャレンジ

このプロジェクトは経営ボードにおいて通常のエンハンスの規模をはるかに超える、高リスク案件と判断されたことから、プロ推が担当することになりました。

同時に経営ボードからは「これまでのプロ推の開発は評価できる。人材領域という激しい競争環境を勝ち抜くためにも、 今回の案件でこれまでを超えるようなチャレンジを行えないか」といった打診がありました。リクルートの文化としてさらなる伸びしろを求めて、どんどんチャレンジしていくことが常に求められており、プロジェクトチームとしても望むところでした。この話を受け、過去実績より一段高い開発生産性を追い求めることにチャレンジすることにしました。

目指す生産性を達成するには各フェーズのタスク工数を少しずつ削る努力も必要ですが、それだけでは届きません。 フェーズの考え方を見直し、やり方を大きく変えるしかありません。この方針に沿って調査を進めました。

• 今回の要件はエンハンス要件の積み上げが多い構成である
• 単体、内部結合テストのケースはエンハンスで蓄積したものを流用できる
• また過去のプロジェクト経験者をアサインでき、実際に実装やテストを実施したメンバーである

以上の背景を整理して議論を重ねた結果、「過去のテストケースや仕様書を流用し、単体テスト観点を内部結合に統合して同時に実施する。それにより期間と工数を圧縮できる」と仮説を立てました。

一方で、通常必要とされる期間と工数をどちらも圧縮した上で一定の品質を保つことは、失敗のリスクも高まる、という危機感がありました。そこで、予防的なリスクヘッジ策を検討するだけではなく、ある程度失敗することも計画に組み込んだ上で、生産性向上へのチャレンジをすることにしました。

具体的には、通常移行作業において検討するようなコンティンジェンシープランを、今回のチャレンジ対象であるテストフェーズでも準備することにしました。

進捗の遅れからコンティンジェンシープラン発動

出来上がったプランは、企画部門の先にいる営業部門のスケジュールにも変更を加える必要があるなど、問題が起きてから伝えるとステークホルダーとの調整が難航することが想定される施策ばかりでした。そのため、案件オーナーである事業会社のボードメンバーや要件の責任組織とコンティンジェンシープランについてあらかじめ説明し合意を取り付けました。

このように綿密にコンティンジェンシープランを計画、ステークホルダーと合意の上で、圧倒的な生産性の向上というチャレンジにいよいよ踏み出しました。

要件定義・基本設計が終わり、詳細設計・製造フェーズに差し掛かるあたりから、現場の雲行きが怪しいという報告が上がり始めました。単体テストと結合テストを重ねるという誰も正解を知らないフェーズの準備に差し掛かり、準備作業に遅れが見え出しました。過去に同じシステムを担当した経験豊富なメンバーを中心にして臨んでいましたが、やり慣れたテストの実施方法や感覚が通じない中でそれ以上に苦戦をしていました。そして、次工程のテストケースの準備につられる形で、製造の進捗も遅れが出始めました。

なんとかテストケースをそろえ、単体テスト観点を含んだ結合テストがスタートしました。やっと進捗が正常な状況に戻るかと思った矢先、今度は品質面での懸念について報告が入り出しました。テストフェーズの立ち上がりでの混乱が解消されても、不具合は継続して発生していました。事前に一部先行しプロトタイプ的に検証を行っており、一定品質を確保できる想定でしたが、その想定を上回る勢いで不具合が発生していました。すぐに部門PMOも連携して、テストフェーズ序盤で品質の傾向分析に取り掛かかりました。

分析の結果、下記のような傾向が見て取れました。

また想定以上の不具合発生により、テスト実施の進捗にも影響が出始めていました。

この状況に対し、現場リーダーが中心となって、このチャレンジを成功させようと品質向上のための追加レビューや各種対応に走っていました。しかし、同時に明らかな高稼働の状況を生んでいました。すでに頑張りでなんとかなる範囲を超え始めていました。

このチャレンジを行うにあたり、現場メンバー一人ひとりの高稼働の積み重ねで対応することになった時点で、このチャレンジは見直すべきと考えていました。

そうした事前に設定した撤退基準もあり、プロジェクトとして関係者と膝詰めでこの状況について議論を行いました。 チャレンジを継続しながらリカバリーを図るのは難しいと、主要メンバー全員が認識していました。ここまでの頑張りを無駄にするようで悔しいという雰囲気もありましたが、プロジェクトとしてチャレンジをストップすることを決断しました。同時に準備していたコンティンジェンシープランの発動を決めました。

スケジュールを組み替え、無事にカットオーバー

プロジェクトのステアリングコミッティにおいて事前に想定した状況が発生したことにより、コンティンジェンシープランを発動する旨を報告しました。少々揉めることも覚悟していましたが、事前に内容を合意していたため、即座に承認をもらえました。

承認後は、コンティンジェンシー施策を矢継ぎ早に実行に移しました。

• 後続のフェーズにおいて不具合傾向に沿った追加ケースの作成とテスト実施のためのエンハンス側の要員を即時投入(一部エンハンス要件の対応延期)

• 遅れている現状のテストスケジュールを、実際の進捗度合いに合わせて引き直し

• あらかじめ準備していたプロジェクト後半のテスト工程組み換え案をプロジェクト全体のスケジュールに反映。関係者にその旨を宣言

• 部門PMOによる詳細な品質分析を定期的に実施

• システムテストフェーズにおける強化テスト推進メンバーの追加アサイン （エンハンスメンバーとは別に追加アサイン）

まず、進捗の状況は実際のテストの進み具合に合わせ、プロジェクト全体スケジュールを引き直したことにより即座に解消しました。品質の問題も、上記の取り組みを短期間で集中的に行えたことにより、2週間で解消させることができまし た。

その後は、大きな問題が発生することもなく、組み替えた全体スケジュール通りに、無事にカットオーバーを迎えることができました。

コンティンジェンシープランによってリスクを事前に検討し発生時の対策を計画に組み込んでいたことにより、最終的にはプロジェクトのストレッチ目標であった高い生産性こそ達成できなかったものの、当初設定した目標には無事着地させることができました。

チャレンジは実らずも、ベストプラクティスを体得

このプロジェクトでチャレンジは実りませんでした。しかし、結果的に「チャレンジをする際は、事前検証を行うこと」、「その検証でも拭えないリスクに対して、コンティンジェンシープランをセットにしてプロジェクトを計画すること」は、組織のベストプラクティスとなりました。

これ以降のプロ推のプロジェクトではこの枠組みが引き継がれ、アーキテクチャ刷新や、パッケージの変更といった大きな変更を伴う場合のプロジェクトマネジメントにおいても実践されています。

プロジェクトからの学び

• プロジェクトにおいてチャレンジやストレッチ目標を含める場合は、必ず、事前検証を行う。合わせてストレッチ目標をあきらめる際のコンティンジェンシープランをあらかじめ計画しておく

• 作成したコンティンジェンシープランは切羽詰まってから関係者に共有するのではなく、事前にステークホルダーと合意しておく

• 埋没コストに引きずられて判断を誤らないように、あらかじめ撤退判断の基準を定めておく