こちらを聴きました。

QAエンジニアとして、QAイネイブリング活動（開発チームなどに対して、品質を良くするための色々な施策を行ったり仕組み化したりする）を行っている身なので、とくに

開発プロセスを生真面目に型化しすぎることのリスク

の部分が刺さりました。

自分が読み取った（聞き取った）話・理解としては

  • 開発プロセスの中で属人化を防ぐために型化をしすぎると、結果的に優秀な誰かの創造性や生産性を下げてしまう可能性がある
  • 組織やビジネスのフェーズによっては、必ずしも型化が良いとは限らない
  • 型化で解決できることは、思っているよりも少ないのではないか

です。

Spotifyの文字起こしで言うと

きちんと型を作って、その型に沿ってやれば、一定のクオリティがちゃんと担保されることにして、例えば属人性をきちんと排除していってみたいな話って、まあ真面目に考えるとそれはそうっていう話に。

なんでもそうなんですけど、型化することによって何がいいかっていうと、ボトムラインが上がるっていうのはすごいやっぱあると思うんですよ。

型を作るルールを作ることによって、そのボトムラインは上がるんだけど、トップラインって引き上がらない、引き上がらないじゃないですか。

このあたりです。

QAエンジニアとしての活動を自分が行ううえで、とくにこの「型化」はむしろ注力しているポイントでもあります。品質を担保するうえで、プロセス品質を高めることで最終的には利用時品質にも影響しますし、開発プロセス自体を速く回すことにもつながると考えています。

一方で「型化しすぎるのも良くないよね」という主張に対しても直感的には賛同ですし、ボトムラインは上がるけどトップラインは引き上がらないよね、という話しもそう思います。

品質って、プロダクトでもプロセスでも、ボトムラインが全体の品質になる場合もけっこう多いような気がしています。じっくり考えると例外あるかもですが。エンタメ・ゲームとか。とはいえ、たとえばセキュリティがガバガバだったら、いかに便利だったとしても「品質悪いよね」という扱いにされるはずです。

なので、品質を保証するという観点からいえば、ボトムラインを上げることを優先するのは自然な発想なのかもしれません。

ただ、プロダクトとしてコキャクにカチを提供しようと思ったらトップラインを引き上げるのもまた大事なのもわかります。このあたり両立させるには、型化をしつつも一定の自由度をもたせるようなバランスが必要なんでしょうね。

型があることで、とりあえずそれに則っておけば最低限の品質は担保できる、と。ただ、型通りではなくて適切に＆意図を持ってテーラリングすることで、より良いプロセスを都度実現もできる。ポッドキャスト内では後者の土台になるものを「ガイドラインとしてのプロセス」と表現していましたが、まさにその通りだと思います。

ということは、QAエンジニアが提供するのはガチガチの型ではなく、ガイドラインとしての型であるべきで、開発組織が都度調整しながら＝ボトムを維持しつつトップを引き上げることも行いながら開発を進めていくのが理想ですね。

言うは易し～