tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に

前回の「UXハニカム – UXデザインの正しい品質評価方法 –」では、サービスやプロダクトのUXデザインを評価する際に一般的に用いられている、UXハニカムを活用した方法を紹介した。加えて、実はもう一つユーザー体験のクオリティを測る方法がある。 ユーザー体験を構成する3つのポイント消費者がサービスを受けるとき、ユーザーがプロダクトを利用するときに受け取る体験の質を高めるのがUXデザイナーの仕事になる。 そして、その体験を左右するのが、1. 見た目の品質 (Look), 2. 感覚の品質 (Feel), 3. 使いやすさ (Usability) である。大きく分けてこの3つの要素のクオリティが高いほど、ユーザーに対してより優れた体験を提供することが可能になる。 実用性と利用感覚を測るUXピラミッドUXハニカムに加えて、もう一つのUXクオリティを測る手法としてUXピラミッドがある。6つの階層で構