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 を作りました

genius.hateblo.jp

インタフェースデザインの心理学 ―ウェブやアプリに新たな視点をもたらす100の指針

Seleniumデザインパターン & ベストプラクティス

複数チームでのスクラムを改善するために、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になりそうな際、自チームの達成を犠牲にしてサポートするべきか、あくまでも役割分担の中でのベストを尽くすべきか（駄目なら駄目で改善していけばよいので、変に複雑にしない）、みたいなことが気になりました。

まあはっきり書いてないということは、ケースバイケースで、どちらもで良いってことなのかな〜

ディシプリンド・アジャイル・デリバリー　エンタープライズ・アジャイル実践ガイド

エッセンシャル スクラム

プロダクトオーナーとして開発チームと情報共有する際に注意していること

この記事はProduct Owner Advent Calendar 2015 23日目の記事です。 22日目はjoytomoさんによるPOなき開発現場のプロダクトオーナーシップでした。

（前提）SCRUMにおけるプロダクトオーナーと開発チームの役割について

私は普段、SCRUMで開発をしているチームのプロダクトオーナーをしています。プロダクトオーナーはwhatの担当で、情報収集してプロダクトバックログにアイテムを追加したり、優先順位を最新化したりすることが主たる役割です。開発チームはhowの担当で、プロダクトバックログの内容を実現するより良い方法を考えたり、実際に作ることが役割です。

また、別の言い方で、プロダクトオーナーは投資対効果を最大化することが役目、という説明を受けたことがあります。つまり、有限な開発リソースの中で最も効率の良い（プロダクトを目指す方向に成長させる）whatを選ぶことが重要になります。

そのためにプロダクトオーナーに必要な能力として、1番は決断する力、2番は情報収集する力だとスクラムマスター研修で教わりました。

スクラム　仕事が４倍速くなる“世界標準”のチーム戦術

プロダクトオーナーと開発チームの情報差による認識齟齬

最近思うこととして、プロダクトオーナーは情報収集が仕事なので色々な情報を把握できますが、それを全て開発チームに伝えることは難しく、結果、情報の差が出やすいな、ということがあります。

そのため、プロダクトオーナーとしては、情報収集して考えて出した結論でも、開発チーム側からすると結論だけ言われても納得できない、もしくは、プロダクトオーナーが意図した内容と異なる内容で理解してしまう（誤解してしまう）、という状態が生まれやすいのではないか、と考えています。

もちろん、そこがプロダクトオーナーの技量、ちゃんと要点をまとめて伝えることが大事、みたいな話はあると思うのですが、私自身、結構頑張って伝えているつもりでも齟齬が生まれる時があり、どう改善したら良いかなと悩んでいました。

いました、というか今でも悩んではいるのですが、ある程度考えたことがあるので、その内容を以下に書いていきます。

まずはプロダクトバックログ大事

改善の対象として真っ先に考えるのはプロダクトバックログかなと思います。プロダクトバックログにはユーザーストーリーを書くのが大事、とか、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のパターン

Paolo Perrotta氏のセミナー「アジャイルコーチへの道」に参加しました

「アジャイルコーチへの道」 とは

このセミナーです。整理と備忘のために纏めます。

LAND OF COACHING

アジャイルコーチに必要なスキルについての話がありました。

プロダクトマネージャーやスクラムマスターについて学んでいても感じますが、組織とか全体的なところに寄与する役割は、多能工さが求められる感が強いです。そうでないと、回らないとか効率が悪かったりするのかなと。大きく6つのスキルが定義されていましたが、その中で、印象深かったものを以下に記載します。

Conflict Navigator

Conflictにはレベルがあって、Lv0:Depressionだと、抑圧されていたり、自由に話せる雰囲気がないなど、チームとして問題がある可能性があります。

変に意識統一されてしまっていたり、思考停止してしまっている状態も恐らくこれに該当するのではないかと思います。

そういう場合、アジャイルコーチは、適度にコンフリクトが発生するようにNavigateする必要があるとのことです。本当にそれで良いの？とかなぜそれをやるんだっけ？とか、そういう感じですかね。

逆に、高いレベルに行き過ぎてしまったものは下げることも必要になります。（ただし、Lv5までいくとアジャイルコーチの扱うレベルではなくなるとのこと）

Problem Solver

問題を解決する人、ということですが、大切なのはtake it to the teamで、出来るだけ自分ではなく、チームに解いてもらうことです。

一方で、アジャイルコーチが正しい答えに誘導すること（していると感じること）は、とても不愉快に感じる、という意見もあり、なるほどな、と。

アジャイルコーチとしては、自分の中の仮説は持ちつつも、チームを誘導して答えを出す、という絶妙なバランスが必要なのかなと思いました。チームが出した答えは尊重しつつ、自分の中の仮説と照らし合わせて、矛盾があれば、それはどう考えるか聞く、みたいな感じかなー。

Collaboration Conductor

コラボレーションを誘発する（指揮する）存在という意味です。問題解決に必要な人を集めて、コラボレーションさせる役割。（必要な人が集まったら、勝手に問題が解決していく、ということらしい）

適切な人を見極めるとか、声をかけて呼ぶことが出来るとか、場をセッティングすることが出来る能力って感じかなと思います。

で、一番重要なスキルは？

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターンのLinda RisingさんいわくMind your manners.Be polite.ということらしいです。

礼儀正しく、感じの良い人であることが大事、ということですね。反省します。

Fearless Journey

続いて、Fearless Journey―組織を変革する48の影響戦略カードを使ったアクティビティを行いました。

自分が組織に対して変えたい課題を考え、それを解決する方法論として、Fearless Journeyのカードから選択し、その方法論を使ってどう実現するかを考えました。

同じようなカードを持つ2〜3人でチームになり、ワークを行い、最後にワークで見つけたInsightを共有しました。

自分のチームで見つけたInsight

課題

組織がコンフリクトレベルのLv0:Depressionになりやすいと感じていて、もっとコンフリクトが発生するように、変化を与えたいがうまく変化させられない

Fearless Journeyのカード

• 種をまく
• 成功の匂い
• みんなを巻き込む
• ステップバイステップ
• 経営層の支持者

当初の想定

• 良い機会がある度に種をまいて、変わるきっかけにならないか
• 現状よりも良くなる成功の匂いを感じてもらって、変わるきっかけにならないか

などなど

考えたこと

• 例えば、種をまいても変わる人と変わらない人がいる
• 変わる人は良いけど、変わらない人はどうすれば良いか
• 自分はなぜ変わって欲しいのか
  • （変わった方が良くなるとして）より良い状態に変化してもらいたい
  • もっと良い状態になると期待している
• 種をまくことは単に方法論やメリットを見せるだけになっているのでは
• まだ見せられていない期待を伝えられれば、変わろうという人がいるのでは

Insight

• 種をまくときは、相手に対する期待が分かるようにすると良い（のでは）

本当に良いかは検証してみないといけないですね・・・・

懇親会

セミナーの後はsushiパーティでした。セミナー参加者の方々が大変豪華だったので、参加者の方とお話するだけでも大変勉強になりました。

アジャイルとかスクラムをやっていると、「掘り下げ」とか「なぜなぜ」みたいな話が多くなりがちな気がしますが、そういう話ってとても性に合っているなと感じます。（懇親会とても楽しかったという意味です）

参考書籍

アジャイルコーチの勉強には以下の本が良いよ、と紹介してもらったので列挙します。

※紹介されていたのは全て日本語の本ではなかったですが、知ってる範囲で日本語版を貼っています

Agile Coaching

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Facilitator's Guide to Participatory Decision-Making (Jossey-Bass Business & Management Series)

Training From the Back of the Room!: 65 Ways to Step Aside and Let Them Learn

アイデアのちから

プロダクトオーナー祭り2015に参加して、プロダクトバックログについての話をしてきました

プロダクトオーナー祭り2015 ～世界を変えるのは俺たちだ！～にスピーカーとして参加させて頂きました。楽しかった！！

自分が発表してみての話と、他の方のセッションに参加してみての話を両方書かれて頂きます。

自分が発表した話

発表資料

プロダクトバックログビフォーアフター from bonbon0605

www.slideshare.net

発表のポイント

以下のような内容が主に伝えたかったことです。

• バッドノウハウの共有
• 課題との試行錯誤の様子を伝える
• 仮に内容が間違っていたとしてもTry大事

失敗の内容もその改善策も、企業やチームによって色々かとは思いますが、（そして自分も、もちろん正解に辿りついているわけではないですが、）同じようなことをしている方々に、何かしらヒントみたいなものになれば良いなという気持ちでした。

発表後に思ったこと

正直、若干後悔するぐらいプレッシャーを感じていたのですが、やった後はやってよかったと思うものですね。理由として、

• 自分の話にこんなに人が来てくれるのだという感動
• 「この内容あるある」みたいな共感が得られると嬉しい
• 「このやり方良いかも」とか言われると、報われた感が半端ない
• 発表後に色々な人に話しかけてもらえる（懇親会でぼっちにならなかった）
• 自分のやってることの整理になって、さらに色々考えられるようになる

などがあります。

ちなみに、大きなＡ会場と、Ａ会場と比較して小さめのＢ〜Ｄ会場で、発表が行われたのですが（私はＢ会場）、アンケートによると、Ｂ〜Ｄ会場で行われたセッションの中での投票数 第2位 ということでした。本当に感謝感激でした。田舎の両親に報告します。

他の方のセッションに参加した話

比較的自分は最初の方の発表だったので、発表後は主にワークショップに参加して楽しませて頂きました。その内容についても簡単にですが、触れさせて頂きます。

「プロダクトオーナー/プロダクトオーナーシップ」カイワヤ会(出張版)

カイワヤとは

「会話」＋「わや」という造語だそうです。「わや」というのは鎌倉ハムのＫウインナーで（私の出身）愛知県ではおなじみの、「駄目になる」みたいな意味の方言です。方言は知っているのに、会の意味がよく分からなかったのですが（笑）、たくさん（≒めちゃくちゃになるぐらい）話す会みたいな意味かなと想像しました。

内容

プロダクトマネジメントマニフェスト

こちらで扱ったのは、プロダクトマネジメントマニフェスト です。

ここに書かれた内容について、他の参加者の方と、「ここが素晴らしい」とか「これは難しいのでは」「自分はここまではできてるけど、これはできてない」みたいなことを、共有＆ディスカッションしました。

プロダクトマネージャに必要なのは「覚悟」

• 基本的に権限はない
• 製品に対するすべての責任を持っている
• 最も困難な仕事をしている
• すべての分野の専門家でなければならない

（そんなの現実的に無理でしょ、という意見もたくさん出つつ）。そんなプロダクトマネージャに必要なのは 覚悟 ではないか、という話をしていました。

別の機会で、実際にプロダクトマネージャをされている方と、 優れたプロダクトマネージャには、いわゆる「人間力」みたいなものが大事ですね というお話をさせて頂いたこととも通じるところがあるな、というのが自分の所感でした。

自分はまだまだ遠い・・・

『メトリクスによる「見える化」のススメ：No 見える化, No 改善』

課題解決のために、課題を「見える化」するためのメトリクスを考えて設定する、という内容のワークショップでした。内容だけでなく、ワークショップの進め方も大変勉強になる会でした。

ワークショップを通じて思ったことをざっくりまとめます。

メトリクスについて

• 「数値化」できて「問題の状況が分かる」項目の設定って結構難しい
  • 例えば「バグ数」って数値化はできるけど、問題の状況が分かるか。多くなったら良い？少なくなったら良い？
• 「問題の状況が分かる」ためには、解決したい問題が明確になった方が良さそう
  • 「優先順位が頻繁に変わる」が問題？「優先順位が変わるからスプリントが達成できない」が問題？「関係者が不満を持つ」が問題？
• 感情とか数値かできなそうなものも、挑戦してみると楽しそう
  • 「朝来たときの気分」とか「夕方帰るときの気分」とか「ありがとうの数」とか
• 「開発者が喜ぶメトリクスか」「マネージャが喜ぶメトリクスか」の両面を考えるのはとても良い視点
  • 片方だけに都合が良いメトリクスは、何か違っている部分があるのではないか、というヒントになりそう

ワークショップの進め方について

• チーム名を決めるのは良い
  • 連帯感が高まる。名前付けるの個人的にはとても苦手ですが
• 途中で一度発表して、他チームからフィードバックをもらえるのが良い
  • 自分たちだけでは気付きにくいことを言ってもらえる
  • チーム内でたくさんの人が発表できて、良い経験になる
• 複数のチームの進行状況によって、変化できる柔軟なシナリオ
  • 純粋に勉強になりました

反省

最後にちょっとした余談ですが、反省として、 名刺を持っていかなければ駄目 でした。。。

これまでエンジニア界隈の勉強会で名刺交換をした記憶なんてほとんどないのですが、今回は大変多くの方から名刺を頂きまして、普段念のため持っている名刺が一瞬で無くなった私は、ひたすらに頂くだけになってしまいました。。。

関係各位のみなさま、大変失礼致しました m(__)m

Inspired: 顧客の心を捉える製品の創り方

amazon-ecsでAmazon Product Advertising APIを使ってみました

背景

漫画本を扱うアプリを作りたいな、と考えていて、そのための調査として、AmazonのAPIはどんなことが出来るのかな、と調べてみました。

Rubyで使うためのgemを調べたらamazon-ecsというのが見つかったので、とりあえずそれを使いました。

触ったのは主に、商品検索関連です。

事前準備

AmazonのAPIが使えるようにユーザ登録しておく必要があります。

このページから行いました。

リファレンス

• amazon-ecs
• APIリファレンス

書き方・使い方

接続するためのキーなどを登録

Amazon::Ecs.configure do |options|
  options[:AWS_access_key_id] = '[your access key]'
  options[:AWS_secret_key] = '[you secret key]'
  options[:associate_tag] = '[your associate tag]'
end

商品を検索する

item_searchというメソッドを使います。　APIリファレンス

検索対象は、何も設定しないとデフォルトはBookになるようです。

res = Amazon::Ecs.item_search(
  '', # Keyword検索の内容を入力します
  :title => '僕だけがいない街', # titleだけで調べたい場合にはこちらを
  :sort => 'titlerank', # 取得された結果（レスポンス）の中でのソート順になるので、注意が必要です
  :tag_sort => 'Name', # 取得される結果をソートします
  :browse_node => '2250738051', # 検索対象をより細かく設定したい場合に使います。この値はKindleストアです
  :country => 'jp'
)

注意事項としては、一度のitem_searchメソッドでレスポンスとして受け取れるのは、最大10個までなので、全ての結果を取得するには、:item_pageのパラメータを使って、複数回問い合わせる必要があるようです。

取得されたデータから値を抽出する

上記のような処理を行うとAmazon::Ecs.Responseクラスが結果として返されます。この中身はXMLになっているようですが、準備されているメソッドで欲しい情報を取得できます。

流れとしては、Amazon::Ecs.ResponseクラスからAmazon::Ecs.Elementクラスを取得して、Amazon::Ecs.Elementクラスのメソッドでタイトルなどの値が抽出できます

res.total_pages # 検索結果が全部で何ページ分あるのか確認できます
res.items.each do |item| # itemsメソッドで、Elementの配列が取得できます
  puts item.get('ASIN')  #Amazonの商品コードを取得
  puts item.get('ItemAttributes/Title') # タイトルを取得
  p item.get_hash # Elementの内容をHashに変えて処理できるようになります
end

商品IDから商品を検索する

item_search以外にもitem_lookupというメソッドがあります。　APIリファレンス

こちらは、商品IDから該当する商品情報を取得するのに便利です

使い方としては、第一引数にASIN(Amazon Standard Identification Number)を渡してあげれば良くて、Responseから先はitem_seachとほぼ同じ流れになります

asins = ['B00UGU4LF4','B010N2825O'] # ASINはカンマ区切りの文字列で最大10個まで渡せます
Amazon::Ecs.item_lookup(asins.join(','),:country => 'jp').items.each do |item|
  puts item.get('ItemAttributes')
end

その他

item_searchもitem_lookupも:countryというオプションを使っていますが、このオプションはAPIリファレンスには無いものです。

amazon-ecsとして、リクエストを投げるURLを決めるのに使うようなのですが、APIリファレンスに無いために、私はよく書き忘れてしまいます。。。

対策として、最初のconfigureでoptions[:country] = 'jp'と書いてしまえば、毎回書く必要は無くなります。（何もしないとデフォルトはusになっているようです）

[まとめ買い] 僕だけがいない街

僕だけがいない街(6)<僕だけがいない街> (角川コミックス・エース)

SeleniumのActionBuilderを使ってみました

実践 Selenium WebDriverを読んで以来、使ってみようと思いつつ使っていなかったActionBuilderを先日使ったので、メモとして残します

リファレンス

Class: Selenium::WebDriver::ActionBuilder

環境

Rubyです

背景

あるページを開いて、そこにあるアンカーリンクを一通り順番に叩いて、リンク切れしていないか

を確認したい、ということがありました。結構リンク数があったので、Selenium使いたいなという感じです。

ちょっと話は逸れますが、リンク切れしていないかの確認でHTTP STATUSの200 OKを確認しようかと思ったのですが、どうやらSeleniumだとHTTP STATUSが取得出来ないようで、HTTP STATUSを確認する良い方法を模索中です。ちなみに、今回は、諸事情あって、かなり力技で、全部の画面キャプチャを撮りましたww。普通であれば、タイトルとかh1とかで値をチェックすれば大丈夫かなと思います。

話を戻しますと、アンカーリンクを一通り叩くというので、find_elementsを使って、aタグをごそっと取ってきて、ループさせようかと思ったのですが、1回叩くとページ遷移してしまうので、ループがうまくいきませんでした（ページ遷移したタイミングで、Elementがいなくなってしまうので）

なので、アンカーは別ウィンドウで開いて確認しようという考えになり、SHIFT押しながらクリックしたいなで、ActionBuilder使おうとなりました

使い方

正直、リファレンスそのまま使えば大丈夫なのですが、流れとしては、以下のようになります（今回の場合）

• Elementを見つける

element = driver.find_element(:id,'hogehoge')

# ちなみに、「アンカータグ全部拾う」は
elements = driver.find_elements(:tag_name,'a') # => 配列が返ってきます

• Actionの流れを作って、実行する

driver.action.key_down(:shift).click(element).key_up(:shift).perform

ポイントは、最後のperformですかね。それまでは、ひたすらActionを作っていくイメージで、最後にperformすると作ったActionを実行してくれます。

ちなみに、key_down(:shift)の後にkey_up(:shift)しないと、私の環境ではちょっと変な動きをしていましたので、しておいて方がおそらく良いかと思います。

あと、ページが大きかったりすると、Elementがウィンドウの中に見えていなくて、クリック出来ないということもありました。そういうときには、Actionの中にmove_toメソッドを入れて、そのElementのところに移動してからクリックするなど工夫する必要があります。

補足

過去記事もよろしければ参考にして頂ければ幸いです

genius.hateblo.jp

genius.hateblo.jp

genius.hateblo.jp