SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

スクラム開発における理想のプロダクトデザイナーとは PdMが期待する役割とそのための行動を解説

  • X ポスト
  • このエントリーをはてなブックマークに追加

スプリントレビューでの貢献

 世の中にデザイナーという職種で働く人は多くいますが、SmartHRではアプリケーション開発に従事するデザイナーを「プロダクトデザイナー」と呼んでいます。

 数多あるデザイナー職とプロダクトデザイナーとを分けるものはなにか。それは、開発チームの一員として恒常的にアプリケーション開発に従事するか否かの一点です。そのためプロダクトデザイナーはチームメンバーから、アプリケーション開発を進めるうえで開発の効率性に貢献することを暗黙のうちに期待されています。

 効率性に関してはさまざまなアプローチがあります。デザインシステムでコンポーネントライブラリを用意する手立てもありますし、デザイナーがフロントエンドの実装を担って作業工程を短縮するのも手段です。

 また、もし参加しているプロジェクトがスクラム開発を採用しているのだとしたら、スプリントレビューとバックログリファインメントは、プロダクトデザイナーがスクラムに寄与できる大きなポイントとなります。

 スプリントレビューは、スプリントにおける成果物を検査し、設定したゴールの達成度合いを確認することを目的としていますが、同時にステークホルダーから成果物に対してのフィードバックを得る大きな機会でもあります。ステークホルダーの選定は限定されていないので、開発チーム外の社内メンバーや、可能であればドメインエキスパートを探して参加してもらうのも良いでしょう。

 スプリントレビューを有益なものにするためにはステークホルダーの観察と共感、そしてチーム内の対話を生むことが重要です。この役割はプロダクトデザイナーが担える部分が多くあります。

 スクラムガイドで定義されているように、スプリントレビューは「ワーキングセッション」であることが望まれています。

 ただ、エンジニアは自身が開発した成果物を提示するので、どうしても「プレゼンテーション」という側面が入り込まざるを得ません。そこで、プロダクトデザイナーがステークホルダーを観察し、時には質問をしながら行動を掘り下げ、客観的な事実として提示することで開発チーム内での対話を促す起点を作っていくことが可能となります。

 このような役割はプロダクトマネージャーが行うことも可能ではあります。ただ私の個人的見解では、ステークホルダーの観察と共感はプロダクトデザイナーの方が得意であることが多いように思います。また、初期工程における要件定義の齟齬がスプリントレビューで発覚した際などには、役割を分担することでプロダクトデザイナーがプロダクトマネージャーを適切に批評できる役割も担うことができます。

 スクラムチームの三権分立の確立という意味でもプロダクトデザイナーがスプリントレビューに率先的に取り組んでいくことに大きな意味があるのです。

バックログリファインメントでの貢献

 バックログリファインメントは、開発内容を計画するスプリントプランニングに向けてバックログアイテムの透明度を上げるための場を指します。

 もし、あなたがスクラムチームの一員として参加しているならリファインメントには必ず参加するべきです。なぜなら、バックログリファインメントはスクラムチームで対話を行い、共通理解を生み出すために必要なものだからです。

 バックログリファインメントではプロダクトオーナーが開発内容と優先度を説明し開発内容の対話を行います。この対話は当然、交渉可能なものとして存在し、バックログアイテムの不透明性を取り払うためにさまざまな角度から精査(リファインメント)される必要があります。

 そのような場にプロダクトデザイナーがいない損失は計り知れないものがあります。

 まず、開発者が感じたUIに対する不透明性を払拭する機会は失われるでしょう。プロダクトデザイナーが何かしらの形で用意した成果物はスクラムチームの議論の対象とはなりますが、なぜそのようなデザインになっているかの背景を確認することはできません。また変更可能なものなのか、変更するとしたらどのような形に変更するのかの意思決定の機会も失われてしまいます。

 そして何より、リファインメントにおける対話はバックログアイテムの細分化・詳細化を行っているので、開発内容のコンテキストを決定づけています。そのため、もしプロダクトデザイナーがリファインメントに参加していないとしたら、それはスクラム開発に参加していないことと同義であると言っても差し支えないでしょう。

 プロダクトマネージャーは、常に自身が作成したバックログアイテムに対して批評的な視点を求めています。批評的な視点は多角的であればあるほど良いです。プロダクトデザイナーはバックログアイテムのレビュアーのひとりとしてリファインメントに参加し、バックログアイテムの透明度を上げることに貢献しましょう。

 なお、リファインメントの議論内容がエンジニアリングに寄りすぎてデザイナーにはわかりづらくなることはよくあることです。

 その際は、デザイナーもスクラムにおける開発者のひとりであることを伝え、理解できる内容に言い直してもらうことを臆せず要求しましょう。リファインメントは対話のためにあり、対話は全員に開かれているもの。対話に参加できるよう、共通言語の獲得に努めましょう。

この記事の続きは、「CreatorZine」に掲載しています。 こちらよりご覧ください。

※CreatorZineへの会員登録(無料)が必要になる場合があります。

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/14281 2021/06/01 08:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング