「品質よりもスピード」と唱えるだけの人

スピードは大事だ。試行錯誤は大事だ。 トレードオフは存在する。やってみないとわからない。 知ってる。もちろん同意してる。

例えば、プロトタイプを一気に作って全体像を掴むのはとても良い。 それは、作る時に考えが少なくてもそのあと考えている。

ここでのスピードは「どうせ考えるなら 見渡せる範囲を広げてからやれ 」って話なんだと思う。

失敗しても受け入れられるし苦労も増えないから問題ない。 これを踏まえると、スピード大事な人が「1回目はダメ元」と考えていたり 失敗時の保険を持っていたりするかで大きく印象が変わる。

厄介なことに「品質よりスピード」って言葉を盾に思考停止した仕事を求める人がいる。 特にマネージャーがそういう人だと非常に面倒になる。

そもそも、そんな大雑把な言葉では軽重を判断するなんてできない。

なので、そういう人と衝突した時は「あなたが言っている省略できる品質とは何か」と訊いてみる。 たいていコードの見た目とか小さい話が出てくる。 酷い場合は「多少の失敗は大丈夫」とか問いに答えず無自覚に主張を繰り返すだけの場合もある。

絶望する。

そういう場合は、悪い品質な時に起きそうな問題は何か訊いてみる。 絶望するような人が相手の場合、これでも大体は何もでてこない。 そしたら、(システムや具体的な要件を仮定してないから曖昧だけど)下みたいな事を挙げてみる。

  • データに不整合が起きて正しい形に戻せなくなる
  • 簡単な故障やトラブルでシステムが停止する

  • 通常のサービス運用に時間がかかる

  • 変更や修正に複数箇所の習性と計画的なデプロイが必要になる

そこから、どの程度の状況なら受け入れたり諦めたりできるか話してみる。 SLI とか SLO とかを組み立てる。日常的な作業がどれくらい増えるか考える。 さらに受け入れられない状況になった状況を仮定する。

誰に連絡するのか・お金は払うのか・プレスリリースは打つのか・事業停止するのか・調達しないといけないリソースは何か、とかとか。

ぶっちゃけると、その場ではっきり結論を出せなくてもいい。

でも、それをやってからスピードだか締め切りだかの話を進めることにしている。 失敗や故障はあるし、お金や信頼が大きく関わってると実感してもらえるだけで、だいぶ楽になる。 懸念や疑問の定時に対して聞いてもらえる可能性が高まる。

結局のところ闇雲に「品質よりもスピードが大事です」って言う人はスキルや知見が足りずに想定や計画ができない場合が多い。 結果として、火消しはできず他人に任せたりするから、ますますそこから抜け出せずに繰り返す。

でもリスクと基準を想像する事を通せば、リスクと品質の管理に参加してもらえるようになり、ついでに矢面に立ってもらえる。 (まぁ、そこまで優しくする必要もないので、裏でマネージャーから外せないかといった政治活動をする場合もある)

comments powered by Disqus