X（Twitter）でリリカルさん（たち）と少し会話したのでメモがてら記事にします。

プロセス改善をするといいプロダクトが作れるのか？

会話に参加した方々と私とでたぶん全員意図していることは一緒で、「効果はあるけど、プロセス改善すれば完璧ってわけではないよね」が総意だったと思っています。

一方で私自身、仕事では「プロセス改善しようぜ」という趣旨のことを呼びかけることも多いです。そこには、先のツイートでも触れた「再現性」が関係しています。

プロセス品質が高いほうが、プロダクト品質を底上げできるはず

だと考えています。

つまり、プロセス品質が高ければ、担当者やその時の状況などさまざまなパラメータから負の影響を受けづらくなり、最低限の品質は担保されるはず、という意味です。

先のツイートのつづきとして、普段私が使っている料理の例を挙げました。

料理の作り方がいい加減だと、美味しかったり不味かったりする可能性があります。一方で作り方（＝プロセス）がしっかり定まっていると、出来上がる料理というのは少なくとも不味くはならないでしょう。普通は美味しいものが出来上がります。この、「コンスタントに美味しいものを作る」を実現するためには、プロセスが必要、というのが私の主張です。

※ここで「職人がその日の気温や湿度に応じて微妙な調整をして～」みたいな話をし始めると例え話の枠を超えるので、そこまでは想定しません。

このあたりの話はSQuBOKなどでも・・・

Image from Gyazo

ISO/IEC 25010から引用されているものがSQuBOKに載っているのでこのあたり見るのが一番しっくりくるかもしれません。

プロダクト品質に相当する、上の図の右側に対して、プロセス品質は「影響」しています。なので今回の話は

  • プロセス品質が低い→プロダクト品質も低い
  • プロセス品質が高い→プロダクト品質が高くなる可能性が増す

という、十分条件とは言えないけど必要条件だよね、というのが一番端的な答えかなと思います。

余談：現場レベルの実態としては「やってみないとワカラン」な部分もありそう

プロセス品質を高める、プロセス改善をするとプロダクト品質に良い影響がありそう。というのはいいとして、実際に効果があるかどうかはやってみないとわからない部分というのもあると思います。

もちろん、開発フローが決まっていなくて人によってテストしてたりしてなかったりします、というレベルであれば、GitHubでプルリク送ってレビュー受けないとマージできないようにするとか、そのような改善で効果が出そうです。

一方でもっと普通の開発チームにおいては、開発業務を進めるうえでの困り事や課題を出して、それらを改善することで少しずつ良くしていく、というのを普段からやっていると思います。その中には定量的に測れるものもあれば、単独の施策では定量的に測りづらいもの、短期的には定量的な効果が出にくいものなども含まれるでしょう。

あまりプロセス改善をプロダクト品質向上に結びつけすぎないほうが健康的というか、仕事している自分たちが「こっちのほうが健やかだね」と思えるくらいでも良いのかなと。