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