一般的に取られる対応
このような状況に陥ったとき、まず現場で取るアプローチは、「ぎりぎりまで納期優先、リリース後に回しても問題ない不具合はどんどん後回しにする」という方針です。
サービスが利用できない、利用はできるが利用者に不利益が生じるなど、致命的な不具合とそれ以外を分類し、致命的なものから順に対処していく。
この考え方はもちろんどの現場でも対応するでしょう。
また、不具合内容次第では一定レベルのスキルを持つエンジニアであれば改修できるケースもあるので、可能な限りリソースを追加することで対応出来ることも十分あります。
限られたリソースで最大限の品質を確保しようとする、現実的な判断です。
しかし、この対応だけでは限界があるケースが存在します。
例えば、業務やサービスの内容そのものが難しいケースや、特殊なアーキテクチャや言語を使っていることで簡単にリソースを追加して対応できない場合、1つのモジュールが大きく複数のエンジニアが分担して作業することが難しいケースなどがこれに当たります。
さらに、上記に該当しない場合でも、テストするたびに不具合が次々と検出され、過去動作していた機能も動かなくなる。
このような場合、既にプロジェクトの制御が非常に困難な状況になっているため、不具合の分類やリソース追加をすることだけでは対処しきれません。
このようになってしまうと、現場には品質への不安、リリース後の炎上の恐怖がどんどん醸成されていきます。
そのような状態になったとき、どうするかが本当の問いです。
「究極の選択」に向かう予兆
まず、このような危機的状況に陥る予兆として、現場がどのような状態になっているのか整理しておきます。
まず、不具合の横展開ができない状態が続いています。
不具合の対応はしているものの、その内容から同様の事象が他にないかといった横展開をする余裕がない状況が続いているという状態です。
問題の根本を断ち切れないまま、個別の不具合対応をモグラたたきのように繰り返すことになります。
次に、不具合修正が新たな不具合を生み出し始めます。
不具合修正が、「その不具合事象をただ直すだけ」になりはじめ、ソースコードレビューもその点検だけになっていきます。
その結果、周辺処理を十分に加味できず、新たな不具合を作りこんでしまうケースが発生し始めます。
そして、リグレッションテストをする中で、偶発的に新たな不具合を発見し、過去にはその機能は動いていたことが判明する。
このような事態に陥ると、徐々に全体的な品質の不安が現場に漂い始めます。
その結果、テストケースを消化しても安心できなくなります。
計画していたテストケースの消化は進んでいくものの、横展開していないから他の機能も実はダメな部分があるのではないか、以前は動作していたが今は動かないのではないかと疑心暗鬼の状態になっています。
実態としてそうなっていることも多く、品質が担保できているとは言い切れない状況です。
加えて、メンバーの稼働が増加し、体調不良等を理由の休みや離脱がで始めます。
エンジニアの多くは愚直に目の前の不具合修正に対処してくれます。
ただ、いくらやっても終わらず、稼働が上がり、週末対応も増える。
休日の振替を取れる状態にもなく、身体を壊して休みになる。
また、最近のプロジェクトはエンジニアを外部のパートナーに依頼するケースも多く、契約の切れ目で離脱してしまうケースも発生し始めます。
このような状態が起きると、究極の選択の場面に迎える可能性が高くなるでしょう。
PMとして「品質優先」と言い続ける理由
では、このような状況になりつつあるとき、PMとしてどういうスタンスを取るべきでしょうか。
私がPMであれば、究極の状況下であっても品質を優先できる余地が少しでもあれば、「納期ではなく、品質を優先したい」と言い続けます。
なぜなら、どのようなプロジェクトも「品質は捨てていい」とはならないからです。
納期優先という判断になった場合でも、「品質もできる限り高く」という考えがプロジェクト関係者全員に付きまとい続けます。
その結果、チームは疲弊し、一体感は損なわれていきます。
また、現在はSNSやApp store、Google Playでの口コミがサービスブランディングに大きな影響を与える時代です。
リリース直後にクリティカルな問題が発生することでサービスの価値は下がり、一度下げた評価を取り戻すには大きな労力が必要になります。
結局は使われないサービスになっていく。
そのリスクを常に念頭に置いておく必要があります。
ただ、ここで残念なのは、PMにできることは「優先すべき」ではなく「優先したい」と訴えることまでしか出来ない点です。
延伸コストが甚大で追加予算が確保できない、事業運営に大きく響くのであれば、納期必達という経営判断が下ります。
PMが、予算権限のあるプロジェクトオーナーや経営者でない限り、この究極の選択に対して判断まで担えないことは残念ではありますが、現実として受け止めておく必要があります。
納期優先となったときにPMが取るべきアクション
では、経営判断として納期優先が決まった場合、PMとして現場でどのようにあがいていくべきでしょうか。
一般的に行うべき、不具合の優先度付けと後回し判断はもちろん対応しつつ、それ以外に有効と考えられる事例をいくつかご紹介します。
第一に、プロジェクトとして「諦めること」を明確に決断する。
「やるといいつつやれていない」状態が一番消耗します。
例えば、バグ分析とそれに基づく横展開は諦める、再現性がないようなシステム異常系のテストは諦めるなどと明確に決めることで、リソースを別のことに集中させられますし、何より参画しているメンバーの精神的な負担も減ります。
第二に、「要件有識者」を集めてサービスのメインルートを再整理をする。
このような状態に陥ると、まずはリリース時点で基本的に利用される要件・パターン、つまりメインルートに集中して品質を高めることが重要です。
逆にそれ以外はある程度諦める。
具体的には、要件有識者を集めて、サービス利用者のメインユースケースの再点検、決済に関わることなど絶対に品質を落とせない要件を整理し、リソースを集中させることが大事です。
有識者だからこそわかる感覚を最大限に活用することが目的です。
第三に、「設計有識者」「テストリーダー」を集めて経験値を引き出す。
メインルートは抑えるとはいえ、それ以外の機能ももちろん使われますし、そこの品質が非常に悪い状態ではリリースできません。
そこで、設計有識者には設計思想上気になる機能、そしてテストリーダーには「なんとなく品質が悪い」と感じている機能を洗い出してもらいます。
実際に作業をしてきたからこそわかる品質不安を効果的に洗い出すことが目的です。
第四に、上記に基づき有識者がモンキーテストを実施する。
本来であれば仕様書を作成した上でテストするのが正道ですが、そのような時間はありません。
そこで、有識者がひたすらモンキーテストをして品質を高めていきます。
もちろん、これにより本来有識者がやるべき対応が後回しになるかもしれませんが、背に腹は代えられません。
重要なのは、テスターが対応しても効果的ではないということです。
上記の情報だけを共有し、テスト仕様書なしでテストするには、有識者が持つ知見をもとにテストを実施することが不可欠だと思います。
最低限の時間で最大の品質強化をすることが目的です。
このようなテストをしたとしても、恐らく不具合数は収束しないと思います。
触れば触るほど様々な不具合が発生するでしょう。
しかし1週間、2週間と続けることで、最初はクリティカルな不具合が多かったものが、徐々に「最悪リリース後に対処でもよい」と判断されるものが増えていきます。
その結果、現場にも「最低限の品質にはなってきているかもしれない」「サービスリリースしても何とかなるかも」という空気感が生まれ、チームの雰囲気も前向きに変わります。
このアプローチを実践する際の注意点
最後に、このアプローチを実践する際の重要な注意点をお伝えします。
まず、これはあくまで緊急事態の対処です。
品質を積み上げていく正道のアプローチを取らなくても何とかなる、という考え方は間違いです。
やはり、一定規模の開発は、各工程で適切に品質を積み上げていく必要がありますし、このアプローチの結果としての品質は最後まで不安はぬぐえないものになります。
究極の選択に直面し、納期優先となった場合にとれる1つのアイディアだと思っていただきたいと思います。
次に、管理工数が肥大化するので、マネジメント機能強化も必要です。
この対応を行うことで、当初計画の工程以外に、多くの作業や不具合が出てくる状況を作ることになります。
そして短期間にそれら不具合の優先順位を切り分け、修正や再テストを実施する必要があります。
そのためのコントロール機能を強化しておかなければ、結局不具合に忙殺されることになり、チームの負荷や雰囲気改善にはなりません。
エンジニアを追加することばかりに目が行きがちですが、管理機能強化も非常に大事な要素です。
最後に、一定期間モンキーテストを実施しても不具合の「温度感」が変わらないのであれば、リリースはやはり出来ないと判断すべきです。
クリティカルな不具合の割合が減り、現場の空気感が前向きに変化してきていない場合、このアプローチの効果が出ていないサインです。
品質としてはさらに致命的でしょう。
その場合は、改めて納期延伸を改めて経営層に訴えることも視野に入れる必要があります。
## PMとして「品質優先」を訴え続ける姿勢
品質か納期か。
この問いに正解はありません。プロジェクトの状況、ビジネス上の制約、経営の判断によって結論は変わります。
私自身、炎上案件をいくつか経験したことはありますが、そこでの対処が本当に正解だったのか、それ以外によりよい方法がなかったのかは、結局のところわかりません。
ただ、PMとして持ち続けるべき姿勢は一つです。
究極の状況下であっても「品質を優先したい」と訴え続けること。
そして納期優先と決まった後も、できる限りの手を尽くして品質向上策の検討にあがくこと。
その姿勢がチームを鼓舞し、最悪の事態を回避する可能性を少しでも高めることに繋がると、私は考えています。
