SeleniumでChromeのデバイス指定を使ってスマホ表示させる方法
SeleniumでChromeのデバイス指定を使ってスマホ表示させる
SeleniumでChromeを動かす場合、ChromeOptionsを使ってデバイス指定をすることができます。デバイスにスマホ端末を指定することで、スマホ表示でのSelenium操作が出来るようになります。
リファレンス
- 作者: Dima Kovalenko,玉川紘子,太田健一郎,笹井崇司
- 出版社/メーカー: オライリージャパン
- 発売日: 2015/09/18
- メディア: 大型本
- この商品を含むブログ (4件) を見る
やり方
# mobile_emulation = { "deviceName" => "Google Nexus 5" } mobile_emulation = { "deviceName" => "Apple iPhone 6" } caps = Selenium::WebDriver::Remote::Capabilities.chrome("chromeOptions" => { "mobileEmulation" => mobile_emulation }) driver = Selenium::WebDriver.for :chrome, :desired_capabilities => caps
内容
Selenium::WebDriver::Remote::Capabilities
クラスのchrome
メソッドを使うことでChrome用のdesired_capabilitiesを作ることができます。このとき、chromeOptions
でmobileEmulation
を指定すれば、デバイスを指定することができます。
指定できるデバイスの一覧のようなものは特に見つけられなかったのですが、Chromeで使っているものはおそらく使えるのではないかと思います。ただし、名称一致は必要なようで、"Apple iPhone 6"
は、"iPhone 6"
ではエラーになりました。
システムテスト自動化 標準ガイド CodeZine BOOKS
- 作者: Mark Fewster,Dorothy Graham
- 出版社/メーカー: 翔泳社
- 発売日: 2014/12/17
- メディア: Kindle版
- この商品を含むブログ (4件) を見る
関連記事
SeleniumでChromeを起動した際に、デフォルトのダウンロード保存先を指定する方法
SeleniumでChromeを起動した際のデフォルトダウンロード保存先を指定する
SeleniumでChromeを使う場合に、デフォルトのダウンロード保存先を指定する方法が分からなかったので調べたメモです。
Win + Rubyで確認しています。
リファレンス
Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)
- 作者: 伊藤望,戸田広,沖田邦夫,宮田淳平,長谷川淳,清水直樹,Vishal Banthia
- 出版社/メーカー: 技術評論社
- 発売日: 2016/02/02
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
やり方
色々調べましたが、プログラム内で直接定義するやり方は分からず、Chromeで使うUserDataのファイルをプログラム内で指定することで実現しました。自分が普段使っているChromeのUserDataとは別のファイルを設定できるので、ファイルをリポジトリに入れて使うこともできます。
CHROME_USER_DATA_PATH = Dir.pwd + "User Data\Default" # 絶対Pathで指定 caps = Selenium::WebDriver::Remote::Capabilities.chrome("chromeOptions" => {"args" => ["user-data-dir=#{CHROME_USER_DATA_PATH}"]}) driver = Selenium::WebDriver.for :chrome, :desired_capabilities => caps
内容
Selenium::WebDriver::Remote::Capabilities
クラスのchrome
メソッドを使って、Chrome用のdesired_capabilitiesを作ることができます。
ChromeOptionsを使うことで、色々な細かい設定ができるのですが、ここでUserDataのパスを指定して、自分の好きな設定を読み込ませることができます。そのため、あらかじめChromeの操作でダウンロード保存先を希望のものに変更しておいて、それで生成されたUserDataを使うことで、SeleniumでChromeを起動した際のダウンロード保存先を任意のものに設定することができます。
ちなみに、ファイルとして置くのは(ダウンロード保存先を指定したい場合には)AppData\Local\Google\Chrome\User Data\Default\Preferences
のファイルだけで良いようでした。Macの場合には~/Library/Application Support/Google/Chrome/Default/Preferences
にあるようです。(Macの動作確認はしていないです)
- 作者: Dima Kovalenko,玉川紘子,太田健一郎,笹井崇司
- 出版社/メーカー: オライリージャパン
- 発売日: 2015/09/18
- メディア: 大型本
- この商品を含むブログ (4件) を見る
関連記事
SeleniumをChromeで動かす方法
SeleniumをChromeで動かす
Seleniumでブラウザ操作を行う場合、firefoxであれば特に追加設定なく動かせるのですが、他のブラウザを使う場合には、ちょっとした設定(環境構築)が必要です。
ここでは、Chromeのやり方について記述します。
- 作者: Satya Avasarala,Sky株式会社玉川竜司
- 出版社/メーカー: オライリージャパン
- 発売日: 2014/09/18
- メディア: 大型本
- この商品を含むブログ (5件) を見る
環境
私はWin7とLinux(Amazon Linux)+ Rubyで動作確認しました。
おおまかな流れ
- chromedriverのファイルを取得する
- chromedriverが使えるようにする
- 必要に応じてプログラムを修正する
chromedriverのファイルを取得する
こちらからダウンロードできます。
Seleniumを動かす環境に合わせて、ダウンロードしてください。
chromedriverが使えるようにする
Winの場合
C:\RubyXXX\bin
など、Rubyがインストールされているディレクトリにchromedriverのファイルをコピーしてください。
Mac,Linuxの場合
以下のような感じでシンボリックリンク作れば実行可能になります。
ln -s $HOME/selenium/chromedriver /usr/local/bin/chromedriver
必要に応じてプログラムを修正する
:firefox
みたいな感じでブラウザ指定しているところを、:chrome
とするなど、必要に応じてプログラムを修正します。
driver = Selenium::WebDriver.for :chrome
その他注意
基本的には、ブラウザ間の違いはSelenium WebDriverが吸収してくれると思うのですが、動かなくなる場合もあります。
例えば、私はFirefoxのプロファイルで書いていた部分をChrome用に書き換えるのに苦労したり、FireFoxでは押せていたボタンがChromeでは押せなくなって、Driver操作の記述を変更したりすることなどが必要でした。
Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)
- 作者: 伊藤望,戸田広,沖田邦夫,宮田淳平,長谷川淳,清水直樹,Vishal Banthia
- 出版社/メーカー: 技術評論社
- 発売日: 2016/02/02
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
関連記事
画像DIFFを取得するimgdiffというgemを作りました
コマンドラインで使えて画像DIFFが取得できます
https://github.com/bonbon0605/imgdiff
前から作りたいと思っていたのですが、一念発起して作成しました。
rubygemsの登録もしたので、gem install imgdiff
で使えます。
CLIにて、
$ imgdiff 対象のイメージ1 対象のイメージ2 (出力先)
という感じで使うことを想定しています。
同じところは黒くなるので、黒くないところが差分になります。 画像の差分取得には、rmagick(ImageMagick)を使っているのですが、 色の差の絶対値を取得しているようで、同じだったら差が0で黒、ということみたいです。
参考にさせて頂いた情報
この2つのサイトのおかげで、rubygemsに登録する勇気が持てました。多謝。
- GitHub - erikhuda/thor: Thor is a toolkit for building powerful command-line interfaces.
- Ruby gemでのコマンドライン・ツールの作り方 - IT探検記
はまったところ
コマンドラインツールのテストの書き方
CLIでのコマンド実行を前提としていたので、どうやってテストを書くのか良く分かっていませんでした。 コマンドライン引数も渡すし、、、ということで、
system "bundle exec imgdiff A.jpg B.jpg"
みたいに、外部コマンド実行の形で最初書いていたのですが、色々無理があるなと思い調べたところ
ImgDiff.new(["ImageA","ImageB"]).invoke(:method)
というような形で実行できることが分かりました。(newの引数の配列がコマンドライン引数になる)
travisのテストがpassしない
ローカルではテストがpassするのに、travisでテストが落ち続け、何故か分からずに嵌まりました。 DIFFの画像を保存する権限がないのかとか色々考えたのですが、解決せず、、、結局、全然違う理由でした。
テストとして、正解のファイルをリポジトリ内に用意しておいて、 それと比較して同じものかどうかで結果が正しいと判断しようとしていたのですが、 (出力結果「ImageC」は用意してある「ImageD」と同一のファイルだから正しい結果だ、というような考え)
どうやらリモートリポジトリの画像がちょっと期待しているものと違ってしまっていたようで、一致しなくてNGという内容でした。(正解が正解ではなかった)
なぜ違ってしまったのかはよく分かっていないのですが(劣化?)、「用意してあるファイルと同じ」という思想を改めることでpassできました。
rmagickでの画像差分について
こちらの記事を参照ください。
- 作者: Rubyサポーターズ,すがわらまさのり,寺田玄太郎,三村益隆,近藤宇智朗,橋立友宏,関口亮一
- 出版社/メーカー: 技術評論社
- 発売日: 2013/08/10
- メディア: 大型本
- この商品を含むブログ (22件) を見る
APIデザインケーススタディ ~Rubyの実例から学ぶ。問題に即したデザインと普遍の考え方 (WEB+DB PRESS plus)
- 作者: 田中哲
- 出版社/メーカー: 技術評論社
- 発売日: 2015/12/16
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
rmagick(ImageMagick)を使って画像の差分を取得する
画像差分が取りたい
修正前、修正後の結果を画像比較できるとテストの安心感が高まりそうという気持ちから、rmagickの機能を調べてみました。
参考にしたもの
- Webページを監視して表示崩れが起きていないか検出できるE2Eテストを実装しました
- https://github.com/rmagick/rmagick
- http://www.rubydoc.info/gems/rmagick/
確認環境
- ruby 2.2.3
- rmagick 2.15.4
rmagickのインストール方法
Githubのwikiを参照下さい。
画像取得について
Seleniumで画像キャプチャを取ることを想定していますが、今回は画像取得については触れずに別で書こうと思います
画像の差分を取る
rmagickで画像を読み込む
まずはrmagickで画像を読み込むところから。
require 'rmagick' img = Magick::Image.read('./sample.jpg').first
Magick::Image.read
の結果が配列で返ってきますので、first
としています。
画像がどのくらい違うか確認する:Magick::Image#difference
Magick::Image#difference
というメソッドがあるので、これを使うと同じ画像かどうかが分かるようです。リファレンスの説明にはCall the IsImagesEqual function.
という記述がありました。
使ってみる
require 'rmagick' img = Magick::Image.read('./sample.jpg').first p img.difference(img) # => [0.0, 0.0, 0.0]
同じだと0で返ってくるようです。
返ってくる値は何なのか
リファレンスを見ると
mean_error_per_pixel,normalized_mean_error,normalized_maximum_error
の3つの値だと書いてありました。
画像系に詳しい人だともしかしたらこれで分かるのかもしれませんが、私にはよく分からず。
ImageMagick側を見れば分かるかな、ということでImageMagickをキーワードにググってみたところ、このページを発見。
曰く、
mean_error_per_pixel: This value is the mean error for any single pixel in the image. normalized_mean_error: This value is the normalized mean quantization error for any single pixel in the image. This distance measure is normalized to a range between 0 and 1. It is independent of the range of red, green, and blue values in the image. normalized_maximum_error: Thsi value is the normalized maximum quantization error for any single pixel in the image. This distance measure is normalized to a range between 0 and 1. It is independent of the range of red, green, and blue values in your image.
ということみたいです。
違いがあるかないかという点では0であるかを見れば良さそうで、どのくらい違うかはこの値を見て判断することが出来そう(出来そうだけどどうやったら出来るかはいまいち分からない)
実際どんな感じになるのか
適当な画像を用意して比較してみました
全く同じファイル
上述の通り [0.0, 0.0, 0.0]
同じファイルをサイズを変えて比較してみる
- 640×480のGIFファイルを用意して320×240にサイズ変更したものと比較すると
[521.8944702148438, 0.0070885103517538675, 1.0]
ファイルの内容をちょっと変えてみる
- 元々のファイルに「テスト」みたいな文字を加えたものと比較すると
[37.7886962890625, 0.0004698213267336715, 1.0]
- 「テスト」の文字をとても小さくすると
[5.609326362609863, 5.188514493355332e-05, 0.9294117647058824]
- 「テスト」の文字をとても大きくすると
[5286.41259765625, 0.07936659467536895, 1.0]
- 背景色の色味をちょっと変えてみる
[8371.1787109375, 0.021862748084959475, 0.17254901960784313]
- 背景色の色味を強めに変えてみる
[30593.5625, 0.29990951254957343, 0.6313725490196078]
とりあえずの結論
はっきりは分からないのと、テストデータも手元のツールで簡単に使っただけなので、正確性があるかないが大変に怪しいですが、左端の値が一番感覚と近いかなぁという印象(違いが小さいと値も小さい)。本当は閾値みたいに使えたらと思ったのですが、ちゃんと使うには、今のところ値の意味を理解できていないがために難しそうです。もちろん、閾値ではなくて、「0じゃなかったら違う画像!」みたいには使えると思います。
差分を画像として確認する:Magick::Image#composite または Magick::Image#composite!
実際に、DIFFの結果が見たい、という場合にはMagick::Image#composite
またはMagick::Image#composite!
が使えます。DIFFを意識した重ね合わせができて、同じところは黒くなるので、黒くないところが違うところ、という形で確認できます。
使ってみる
require 'rmagick' img_a = Magick::Image.read('./sample-a.jpg').first img_b = Magick::Image.read('./sample-b.jpg').first img_a.composite(img_b,Magick::NorthWestGravity,Magick::DifferenceCompositeOp).write('./image_diff.jpg')
compositeメソッドについて
最初の引数は、合成する画像データです
2つ目の引数は、画像を合成する位置の指定です。
0,0
とかでも良いですし、左上からであればMagick::NorthWestGravity
、中央からであればMagick::CenterGravity
のようにモジュール内に定義してある定数を使うこともできるようです3つ目の引数は、重ね方の指定です。
Magick::DifferenceCompositeOp
の指定をすると、同じところが黒くなって重なります。DIFFでなければ、別の値を指定して画像の合成ができるようです
ruby gem を作りました
インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針
- 作者: Susan Weinschenk,武舎広幸,武舎るみ,阿部和也
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/07/14
- メディア: 大型本
- 購入: 36人 クリック: 751回
- この商品を含むブログ (28件) を見る
- 作者: Dima Kovalenko,玉川紘子,太田健一郎,笹井崇司
- 出版社/メーカー: オライリージャパン
- 発売日: 2015/09/18
- メディア: 大型本
- この商品を含むブログ (3件) を見る
複数チームでのスクラムを改善するために、Nexusガイドを読んでみました
背景
現在、スクラムで開発をしているのですが、諸般の事情によりスクラム2チーム体制になっているため、ところどころスクラムガイドから外れた内容になっていることが気になっていました。
そんな中、スクラムの規模を大きくしていくための手法として、LeSSやNexusなどがあることを知り、知見を得るために、Nexusの内容をまとめたNexus Guideを読んでみました。
知りたかったこと
いきなりNexusを導入する、というよりは、現在2チーム体制で試行錯誤している内容に対して、改善のヒントがないかな、というイメージで読みました。主に知りたかったこととしては以下となります。
- チーム間の情報共有
- プロダクトオーナーの人数/役割
- チームごとにプロダクトオーナーが必要か
- 全体で1人だった場合、チームとのコミュニケーションに問題がないのか
- スクラムで定義されていないチームがないか(基盤チームのような、全体統括のチームが必要にならないか)
Nexus Guideを読んでみての所感
チーム間の情報共有
チームごとにプロダクトバックログを分けるのか
Nexusガイドによると、
複数のスクラムチームが、ゴールを達成する統合インク リメントを構築するために、1 つのプロダクトバックログに取り組んでいる
とありましたので、プロダクトバックログは1つで良いみたいです。
あくまでも、1つのプロダクトバックログで優先順位を考え、それをどう実現するかを複数のスクラムチームで考えて実施する、ということかなと思います。エリアプロダクトオーナーみたいな考えでは、エリアプロダクトオーナーはプロダクトバックログを分けて持つ、みたいなことを聞いたことがあった気がしたので(違うかもしれないですが)、どっちなのかなと思っていましたが、やはり1つで良いのだなという気持ちです。
ただし、実施する際には各スクラムチームの担当ストーリーを決める必要があるとは思いますので、そういう意味では、一時的に分割されたプロダクトバックログは持つようになるのかもしれないです。
スクラムイベントは別々に行うのか、一緒に行うのか
必要に応じて全員集まったり、代表者が集まったりする、というイメージかなと認識しています。全体で調整が必要なものは代表者が集まり、そうでないもの(例えば、スプリントレビュー)は、全員集まるという形みたいです。まあ、いつも全員集まったら色々なコストがすごいことになるので、代表者が集まる、というのも分かる気はします。逆に言うと、全員集まれるぐらいの人数なら、代表者を集まる必要もないのかな・・・・
私のそもそもの疑問としては、全く交わらずに別々でイベントを実施する、という可能性もあるかなと思っていたので、そういう意味では、相互の影響を気にしながらイベントを実施していく、という考えのようです。(そりゃそうだよな、という気持ち)
プロダクトオーナーの人数/役割
チームごとにプロダクトオーナーが必要か
これは、はっきりは書いてなかったと思うのですが、Nexusガイドの表紙にも書かれている図を見る限り、各スクラムチーム内にもプロダクトオーナーが書かれているので、各チームごとにプロダクトオーナーが置かれるように定義されているのかなと思います。(もしかしたら兼任という可能性もあるかもしれないですが)
ただ、仮に各チームにプロダクトオーナーがいるとした場合に、その役割がよく分からないんですよね。プロダクトバックログが複数に分かれるなら、(プロダクト全体ではなくて)スコープ限定した範囲での価値の最大化を考える人、みたいに捉えられるかもしれないですが、1つのプロダクトバックログだとすると、その持ち主の代わりに何が出来るんだろうかと思います。。。
全体で1人だった場合、チームとのコミュニケーションに問題がないのか
これは、良く分からなかったですね・・・
1人だと情報伝達や問い合わせへの回答が大変になりすぎないのかな、と思います。
プロダクトオーナーには、複数のスクラムチームで統合され たプロダクトや作業の価値を最大化する実行責任がある。
プロダクトオーナーは、Nexus で作成する統合インクリメントの価値を最大化するために 、プロダクトバックログの順番とリファインメントに最終的な責任を持つ。そのやり方は、 組織・Nexus・スクラムチーム・個人によって大きく異なる。
などど書かれていましたので、プロダクトオーナーは引き続き、開発チームとうまくやらないといけないけど、具体的にどうするかはケースバイケースだから自分で考えて、ということかなと思います。
スクラムで定義されていないチームがないか(基盤チームのような、全体統括のチームが必要にならないか)
これはNexus 統合チームとして、思いっきり定義されていました。スクラムチームに共通する課題解決や仕組み作りについて、牽引していくチームなのかなと思います。
私のところでは、何となく開発チーム以外(プロダクトオーナーとスクラムマスター)で、こうした課題に取り組むか、プロダクトバックログに追加して、開発チームで対応するか、いずれかでしたので、Nexus統合チームのような存在を改めて定義していくのは良いな、と感じました。
ちなみに、Nexus統合チームに所属するのは、スクラムチームの人で良くて、かつ、通常のスクラムチームの作業よりもNexus統合チームの作業の方が優先される、と明確に定義してあるのが良かったです。(全体に関わるところだから、という理由のようです)
別の疑問(残件)
上記のこと以外にも、気になることが出てきましたが、まだ未消化です。
- 作業がプランニングよりも順調でなかった場合の考え方
- あるチームだけがNGだった場合、より優先順位の高いものがNGになる可能性もある。これをどう考えるか(仕方ない or 改善する必要あり?)
- スプリントの途中で、あるチームが別のチームを手伝うようなことが発生するのか(あくまでも、チーム内で作業は閉じる?)
複数チームいると、どうしても責任分界点みたいな話になりがちな気がするのですが、考え方としては、チーム力を合わせてプロダクトを成長させる、というのが健全かなと。そのために、より優先順位が高い案件を実施中のチームがNGになりそうな際、自チームの達成を犠牲にしてサポートするべきか、あくまでも役割分担の中でのベストを尽くすべきか(駄目なら駄目で改善していけばよいので、変に複雑にしない)、みたいなことが気になりました。
まあはっきり書いてないということは、ケースバイケースで、どちらもで良いってことなのかな〜
ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイド
- 作者: Scott W. Ambler,Mark Lines
- 出版社/メーカー: 翔泳社
- 発売日: 2013/11/20
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
- 作者: Kenneth S. Rubin
- 出版社/メーカー: 翔泳社
- 発売日: 2014/08/01
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
プロダクトオーナーとして開発チームと情報共有する際に注意していること
この記事はProduct Owner Advent Calendar 2015 23日目の記事です。 22日目はjoytomoさんによるPOなき開発現場のプロダクトオーナーシップでした。
(前提)SCRUMにおけるプロダクトオーナーと開発チームの役割について
私は普段、SCRUMで開発をしているチームのプロダクトオーナーをしています。プロダクトオーナーはwhatの担当で、情報収集してプロダクトバックログにアイテムを追加したり、優先順位を最新化したりすることが主たる役割です。開発チームはhowの担当で、プロダクトバックログの内容を実現するより良い方法を考えたり、実際に作ることが役割です。
また、別の言い方で、プロダクトオーナーは投資対効果を最大化することが役目、という説明を受けたことがあります。つまり、有限な開発リソースの中で最も効率の良い(プロダクトを目指す方向に成長させる)whatを選ぶことが重要になります。
そのためにプロダクトオーナーに必要な能力として、1番は決断する力、2番は情報収集する力だとスクラムマスター研修で教わりました。
- 作者: ジェフ・サザーランド,石垣賀子
- 出版社/メーカー: 早川書房
- 発売日: 2015/06/24
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
プロダクトオーナーと開発チームの情報差による認識齟齬
最近思うこととして、プロダクトオーナーは情報収集が仕事なので色々な情報を把握できますが、それを全て開発チームに伝えることは難しく、結果、情報の差が出やすいな、ということがあります。
そのため、プロダクトオーナーとしては、情報収集して考えて出した結論でも、開発チーム側からすると結論だけ言われても納得できない、もしくは、プロダクトオーナーが意図した内容と異なる内容で理解してしまう(誤解してしまう)、という状態が生まれやすいのではないか、と考えています。
もちろん、そこがプロダクトオーナーの技量、ちゃんと要点をまとめて伝えることが大事、みたいな話はあると思うのですが、私自身、結構頑張って伝えているつもりでも齟齬が生まれる時があり、どう改善したら良いかなと悩んでいました。
いました、というか今でも悩んではいるのですが、ある程度考えたことがあるので、その内容を以下に書いていきます。
まずはプロダクトバックログ大事
改善の対象として真っ先に考えるのはプロダクトバックログかなと思います。プロダクトバックログにはユーザーストーリーを書くのが大事、とか、INVESTが大事、とか言われます。こういうことが出来ているか再確認する(振り返る)ことがまずは大事なんだろうなと思います。
それ以外で自分で気をつけたこととして、あまり固い文章で書くのを辞めて、出来るだけ思いや感情を書くようにしました。
例えば、
Aという機能を実装する。 KPIは3%程度改善する見込み。
と書かれるより、
Aという機能を実装します。 KPIは3%程度改善する見込みですが、 不安要素もあるので、ちょっと怪しいです。
みたいに書いた方が、温度感が分かりやすいかなと考えています。
コンテキスト共有が大事
プロダクトバックログももちろん大事なんですが、どうしても書き漏れてしまうこととか、この書き方で理解されると思ったのに駄目だった、みたいなことは出てしまいます。というか、ちゃんと読み手が理解できる文章を書いていくのは本当に大変だと思います。
これを改善するのには、普段からコンテキスト共有していることが大事だと考えています。自分が何を考えているとか、どういう情報を得たとか、判断に影響する内容を、判断する前から共有しておくことが大切になります。
例えば
鈴木さんは案1が優れていると考えていて、佐藤さんは案2が優れていると考えているとします。プロダクトオーナーは案1と案2の優先順位を考えなくてはいけなくて、最終的に案2を優先することに決めました。
このとき案1が優れていると考える鈴木さんに説明する方法として
- 客観的なデータにより優劣を示す
- 定義した判断軸による評価結果を見せて説明する
などが考えられると思います。ただ、実際には、これでは鈴木さんが納得出来ないケースも結構な数あるのではないかと思います。(データの取得方法が違うとか、評価結果が間違っているとか)
一方で、鈴木さんが案1、佐藤さんが案2を選ぶのは、それぞれ立場が違うので優先するものが異なっているためで、実際プロダクト全体で考えても差はほどんどなく(どちらも大事で)、プロダクトオーナーとしては優劣を決めづらいというようなことも多いと思います。
こういうとき、両者の立場をしっかりを理解した上で判断していることであったり、どちらの案も甲乙つけがたい状態での決断であることなどが理解されている状態にすることも大事だと考えています。(具体的に何を共有するべきかはチーム文化によって変わるとは思いますが)
普段から共有していることが大事
両者の立場を分かった上で判断しているよ、と判断後のタイミングで急に言っても胡散臭いだけな気がします。なので、出来れば、このような情報は判断が必要に必要になる前から人となり・キャラ・価値観みたいな形で、普段から開発チームに把握されていた方が良いと思います。
やり方として分報がお薦め
以前、Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろうという記事が話題になったことで、これを真似て(idobataなので)個人のroomを作り、そこに自分の考えていることをどんどん書き込むようにしました。
これが想像以上に良くて、言語化しにくいのですが、阿吽の呼吸のような何となくわかる状態になります。
もちろん、最終的にはプロダクトバックログアイテムをしっかり作ることが大事なのですが、普段考えていることや大事に思っていることが開発チームと共有できるようになり、意思疎通をスムーズにしたり、書き漏れた際にも分かってもらえているセーフティネットのような役割になってくれたりしています。
また、同時に開発チームにも個人のroomで書き込んでもらっているので、認識齟齬が生まれたことが開発チームの発言からでも察することができます。
あとは、分報に限らず、プロダクトオーナーとして情報をアウトプットしていくことが大事だと思いますので、プロダクトが抱えている課題についてQiita:Teamの記事を書くとか、社長ラジオのプロダクトオーナー版、なども有用かな、などど考えています。(この辺りはまだ未実施です)
Product Owner Advent Calendar 2015 残り2日間はまだ空席となっておりますので、どなたか是非投稿をお願いします!!
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
- 作者: Mary Lynn Manns,Linda Rising,川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,安井力,山口鉄平,角征典
- 出版社/メーカー: 丸善出版
- 発売日: 2014/01/30
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (16件) を見る