リリース判定こそが品質を高める最後の切り札

リリース判定のスケジューリング

「リリース判定会議は、本稼働の2週間前でいいですか？」

情シスの若手Aさんが聞いてきました。

この現場では、基幹システム導入を進めており、受入テストを開始しています。今後の詳細スケジュールを検討中です。

さて、このリリース判定（別名：本稼働判定／カットオーバークライテリア）は、とても重要です。

これを情シスがどう「コーディネート」するかで、プロジェクトの成否が大きく変わってくるからです。

しかし、Aさんと話してみると、リリース判定について3つの誤解を持っているようです。

リリース判定は、どう行えばよいのでしょうか？

2週間前に開催でよいのでしょうか？

【誤解その1】ベンダーがやる

リリース判定は「ベンダー」がやってくれると思っていないでしょうか？

これは非常に危険です。

昔、ある現場でベンダーがリリース判定会議を開催しました。バグが多発しており、受入テストが全く終わっていなかったため、「大半がNGだろうな」と思っています。ところが、配られた資料に目を移すと、全項目「OK」という文字が飛び込んできました。ベンダーは、堂々と開き直って「リリースしましょう！」と言ってきたのです。

当然ながら、その判定結果は却下し、リリース延期としました。ベンダーと揉めた末に、「今後は絶対にベンダーにやらせない」と心に誓いました。

なぜ、そうなるのでしょうか？

それは、ベンダーが「受注側」だからです。

受注側は1日も早く検収してもらい、代金を回収したいのです。もし延期にでもなれば、ベンダーは赤字になってしまいます。

絶対に延期したくないベンダーがリリース判定を行えば、すべてOKとなるのは当たり前です。

発注側であるユーザーが、きちんと受入テストを実施し、品質に問題がないことを確認し、ようやく「リリースOK」と判定できるのです。そして、代金を支払います。

つまり、リリース判定は明確に「ユーザー側」で行うべきです。

その上で、ユーザー側の誰が行うべきでしょうか？

それは、客観的かつ専門的にプロジェクトを推進する役割の「PMO」です。そして、そのPMOを担うのが、ユーザーとベンダーの橋渡しができる「情シス」となります。

リリース判定は、情シスの仕事なのです。

【誤解その2】一発勝負

リリース判定は「一発勝負」だと思っていないでしょうか？

これも間違いです。もし、本番直前にリリース判定が「NG」となった後をリアルに想像してみてください。

土壇場で「延期」とせざるを得ません。ユーザーとベンダーの双方に深刻なダメージを与えることでしょう。

あるいは、品質が不十分であっても、同調圧力で「見切り発車」となってしまう可能性もあります。その後、本番トラブルが発生して、ビジネスに大きな損失を与えるかもしれません。

どちらに転んでも、当事者には不幸となってしまいます。

そうならないためには、リリース判定は一発勝負ではなく「複数回」実施します。数ヶ月前から「予告」していくのです。

「1回目40点、2回目60点、3回目80点を目指しましょう。80点以上にならないとリリースできないですよ！」

と全員に周知し、現状を認識させるのが、正しい進め方です。

特に、品質が不安定なプロジェクトこそ、リリース判定は大きな効力を発揮します。

バグが多発し、先行きが見えなくなると、ベンダーは保身に走ります。目の前のバグだけを解決して「1日も早く検収して終わらせる」ことしか考えなくなる傾向があります。「後は保守フェーズでやりましょう」と詰め寄ってきます。

そのようなベンダーに対して、リリース判定で「牽制」するのです。

「判定に合格しないと検収されない」と認識させることで、ベンダーに危機感を持たせることができるからです。

なお、このリリース判定にふさわしい「場」はどこでしょうか？

それは、ステコミ（ステアリングコミッティ）です。

ユーザー側とベンダー側の責任者、プロジェクトマネージャー、リーダーが集まるステコミこそ、リリース判定を共有するのにふさわしい場所です。

それにより、判定NGとなる課題は「トップダウン」で対策が打たれていきます。これが非常に大きいのです。

【誤解その3】判定だけ

リリース判定は「判定だけ」だと思っていないでしょうか？

判定だけだと、単なる「批評家」になってしまいます。

あれこれケチをつけて、文句だけ言って、自らは「高みの見物」をしていては、誰も耳を傾けてくれません。

発表する本人は、品質不足のベンダーを痛烈に批判することで、すこし気分が晴れるかもしれません。ところが、攻撃されたベンダーと溝ができてしまいます。

リリース判定の目的は、無事にリリースすることです。

そのために、プロジェクト関係者に緊張感をもたせ、このままだと間に合わないと危機感をもってもらうこと。

その上で、判定結果に基づき、今後の「対応策」を決めて、状況を動かしていくまでが、リリース判定です。

表面的な「課題を減らしましょう」「バグを減らしましょう」だけだと意味がありません。

課題を減らすために「○○の施策を打ってください」と言い切り、その場で責任者の同意を取り付けるまでが仕事です。

例えば、ベンダーへの提言には以下が考えられます。
・類似バグが多いので、内部で横展開および影響確認を強化してほしい
・設計バグの場合は、設計書に反映してほしい（後回しにすると忘れる）
・テスト環境へのリリース頻度を上げてほしい
・非機能テスト結果は、一度説明してほしい（特に性能と可用性のテスト）
・起票後の放置が目立つため、起票後は3日以内に確認してほしい
・○○機能は説明を一度も受けてないので、説明の場を設けてほしい
・品質分析報告をしてほしい
・品質強化案を○○日後に説明してほしい

この提言には、いろいろなバリエーションがあります。リリース判定結果および状況に応じて、アレンジしてください。

客観性を保つ

この強化・対応策を依頼するときにポイントがあります。

それは、ベンダーだけではなく「ユーザー」にも提言すること。

プロジェクトに問題がある場合、「10対0」でベンダーに非があるということはありません。必ずユーザーにも反省すべき点があり、改善ポイントはあるものです。

もしベンダーだけを一方的に批判すると、ベンダーに恥をかかせる場となり、ベンダーは保身に走ります。最後の最後に、一枚岩になれなくなってしまいます。

たとえバグが多発して、ベンダーの落ち度が大きいとしても、ユーザーにも何かしら提言し、第三者の立場で「客観的」に判定しているという位置づけをとってください。

例えば以下のような提言です。
・「ユーザー確認待ち」が多いので、速やかに確認し「完了」にしてほしい
・ユーザー課題（業務課題や運用課題）は、障害管理表から切り離して、ユーザー側で管理してほしい
・バグが発生しても、そこでテストを止めないでほしい。まず「広く浅く」確認して、致命的なバグの検出を優先し、ノーマルパターンの品質確保を優先してほし
・バグの優先順位をつけてほしい。代替手段があるものは、優先度を下げてほしい
・○○機能についてベンダーが理解不足なので、一度説明してほしい
・ユーザー側で行ったシナリオテストの内容をベンダーに説明してほしい。ベンダー側でも今後ノーマル確認として行ってもらうため

ユーザー側も、探せば必ず見つかります。多忙なユーザーに提言しにくいかもしれませんが、ファクトベースの提言であれば、前向きに受け取ってもらえます。

このように、ベンダーとユーザーの双方に働きかけ、ゴールに誘導するのが、リリース判定です。

必ずカオスとなってしまうプロジェクト終盤において、全体をコーディネートする最後の切り札といえます。

情シスには覚悟が求められています。

踏み込みすぎると、反発を受けたり、人間関係にヒビが入ったりするかもしれません。それでも踏み込んでいき、提言後も寄り添い、フォローすることで、少しずつ好転し、ゴールが見えてきます。誰かがこのリスクを追わねば、深刻な状況は打開できないのです。

だけれども、この高難度な任務を達成した後に見える景色は格別です。

ぜひ、この景色を見ていただきたいと思います。

リリース判定（1回目）の開催

「それでは第一回目のリリース判定結果を説明します」

冒頭の情シス若手が、ステコミの場で堂々と説明を始めました。

まず、判定の位置づけを説明し、今回を含めて3回判定することを宣言します。

その後、「現在は30点」と説明し、ベンダーとユーザーの双方に改善策を提言しました。

ベンダー責任者は、事態を重く受け止め、体制強化と品質強化対策をその場で約束します。

ユーザー責任者も、受入テストの消化率を毎日チェックし、遅いところはテコ入れすると宣言しました。

このトップダウンが大きいのです。この後、2回目で60点、3回目で80点をとれるように、頑張っていきましょう！

貴社IT部門・情報システム部門は、リリース判定会議をうまく運用できていますでしょうか？

 

（リリース判定のサンプルはこちら↓）
リリース判定／本稼働判定の作り方_ステコミ発表用Ver.（サンプル画像付き）