プロダクトの品質を考える Part.1

どうも、大阪の梅田でIT企業に勤める鈴木といいます。
note を登録してはいたものの、なかなか継続できず今に至る感じなのですが、昨今の状況からリモートワーク推奨中ということで、日々考えていることを書いていこうかなぁ〜と思い再度始めました。
極力がんばっていきますので、よろしくお願いします。

プロダクト品質って何？

というわけで、仕切り直し1発目は「プロダクト品質」についてです。
ソフトウェアの品質を考える際に良く出てくるキーワードなので、ネットを検索すれば色々と出てくると思います。その辺りは有識者の人達にお任せするとして、今回は私の持論的な部分を説明したいと思います。

そもそもですが、プロダクト品質はその名の通り「創り上げた物の品質」ということになりますが、これってどうなれば良いか、もしくは悪いかが非常にわかりにくくないですか？
私も過去に「今回は割とがんばってテストしたし、不具合も言うほど出てないから怒られないで済むぜ！ヘヘンっ」と顧客打合せに向かったことがありますが、見事に撃沈した経験があります。

立場が違えば基準が違う！？

その時にはっと気づかされたのは、「重要視している点が違う...」ということでした。当時、我々が担当していたのはiOS/Androidのネイティブアプリ側のみで、いわゆるフロント側だったのですが、サーバー側も同時進行で開発していたため、「それはサーバー側の問題なので...」ということが結構残っていました。(もちろん、責任範囲としては問題ないのですが)
それを打合せで伝えると...「いや、製品としての確認ができない以上、どうにかしてくれないと困る」と紛糾...まぁその後の顛末はご想像にお任せします。(笑) ただ、このプロジェクトで改めて感じたのは、契約の責任範囲がどうのという話よりも、プロダクトとしてどうすべきか？その行動を取っているか？ということが顧客に伝わらないと意味が無いなということでした。

気がついたらきちんと伝える

今、このプロジェクトのことを振り返って考えてみると、やはりもう少しこちら側の意見をお節介でもしっかりと伝える必要があったなと思います。当時もBacklogを活用していてチケットベースでは連絡をしていましたが、あくまでも担当者レベルでのやりとりだけでしたので、この機能がちゃんと動いていないとか、局所的な視点での会話が多かったように思います。そうではなく、自分たちの責任範囲はもちろん、俯瞰してプロダクトとして最適な効率で改善するにはこうしたい！とグイグイ行っていれば、もう少し違った顧客の反応だったかもしれないですね。

というわけで、1回目はこの辺で終わりたいと思います。
次回もプロダクト品質関連のお話を書いて行こうと思っていますので、よろしくお願いします。