この記事は ギルドワークス Advent Calendar 2019 14日目の記事になります。
プロダクトの開発者がプロダクトの正しさをどう背負うかを考えてみます。

プロダクト開発における正しさは色々な種類が考えられます。プロダクトとして提供したい価値観の正しさもあれば、コンセプトがきちんと伝わっているかといった情報伝達の観点もあります。

開発者の目線では、「設計として正しいか」や「コーディングとして正しいか」のような実装の正しさを中心に置きます。エンジニアの責務であり、担保しないといけない範囲です。しかし、エンジニアが見ている視座・視野を固定していいわけではないと思っています。コンセプトやユーザーの目線に切り替えて、自分の手で開発しているプロダクトを見る必要があります。プロダクトの実現を担っている開発者だからこその発見があり、デザイナーやプロダクトマネージャーと協力してプロダクトのあるべき姿を探す重要なインプットになるからです。

開発している時は他の視点に切り替えることは難しいです。なので、私は時間を区切って行っています。1時間のうち30分は開発し、残り30分はユーザーとして触ってみるみたいなイメージです。後半30分のなかでプロダクト（機能）と向き合うときに頼りにするのは自分の正しさの基準になります。自分の基準が低いと全て正しく感じてしまいます。基準を上げるためにはユーザーがどんな状況にいるのか、プロダクトは何を目指しているのか理解してないといけないです。これらを知るためにプロダクトの世界観を自分なりに俯瞰して抽象化、言語化します。手法としてはプロダクトのビジネスや実現手段を言語化した仮説キャンバス、リーンキャンバスやユーザーの体験を描いたカスタマージャーニーマップがあります。最初に自分だけで作ってみると自分がどれくらいプロダクトを考えられているのかを知ることができます。すでにプロダクトマネージャーが作成していれば、自分で作ったものと比較してみると認識の違いを把握することができます。ここまでくると開発者がやることなのかと疑問に思うかもしれません（私自身最近まで考えてもみなかったです）。開発者の役割は機能を実装することではなく価値のあるプロダクトを早く市場に出すことだと考えています。早く出すことだけではなく価値を高めることにもコミットしていかないといけないです。

毎日自分の基準を磨きつつ開発することは大変です。自分の限界を突破するためにはチームでプロダクトに向き合う時間をとらないといけないです。ギルドワークスではプロダクトレビューと呼んでいます。チームが集まり、確認したいプロダクトの観点（UIや体験）を決めて議論します。この場では各々の役割は関係なく、それぞれが感じたこととその原因からチームで正しさを探していく。チームでやることで1人でたどり着けなかった高さまで登ることができます。

正しさは日々自分のなかの基準をアップデートしながら、チームで高め合っていきたいです。