書籍"Product Operations" 読書メモ１: プロダクトオペレーションの３本柱とは
「ビルドトラップ本」の著者 Melissa Perri と、もう一人の共著者 Denise Tilles による、Product Ops の本。
スケールするプロダクト組織において、PdMが本来の役割に集中し、全部門が同じ方向を向いてプロダクトライフサイクルを回すための基盤として、なぜプロダクトオペレーションが効果的か、どのように実践すべきか？
読書メモの第１弾として、まず Part I. Introduction to Product Operations の内容を紹介します。
Part I. プロダクトオペレーションの紹介
プロダクトオペレーションとは
- プロダクトマネジメント機能をうまくスケールさせるための規律
- PdMとプロダクトチームが、根拠に基づいた意思決定・戦略立案・優先順位付けを合理的に行うために必要なすべてのインプット・情報のインフラを提供する
- プロダクトオペレーションはイネーブルメント機能であり、それ自体が意思決定を行うわけではない
なぜプロダクトオペレーションが必要か
- 以下のニーズに応えるため
- 全部署が一番となって価値あるプロダクトを提供したい
- 正しい情報に基づいて戦略的な意思決定を行いたい
- すべての関係者がプロダクトライフサイクルにどのように貢献すればいいか理解できるようにしたい
- プロダクトマネージャー（PdM）がやればいいのでは？
- PdMが担う役割は多岐に渡り、各PdMがすべてをカバーすると組織がスケールできない
- プロダクトオペレーションを構築することで、PdMが本来の役割（企業の成長、事業目的の達成、顧客価値の創造等）に集中することができる
プロダクトオペレーションの3本柱
第1の柱：ビジネスデータとインサイト
第2の柱：顧客と市場のインサイト
- 社外リサーチの推進と集約
- 顧客・ユーザからのインサイトにアクセス可能とする
- 競合分析やTAM/SAMなどの市場調査の手段を提供する
第3の柱：プロセスとプラクティス
- プロダクトマネジメントの価値をスケールさせるための継続的・機能横断的な実践とフレームワーク
- 組織がどのように戦略を立てて実行するのか、機能横断チームがどのように戦略と実行に向けて協業するのか、プロダクトマネジメントチームがどのように機能するかを特定する
- プロダクトのガバナンスとツール管理を含む
（Part II へ続く…かも）
macOS Sierra で Remote Desktop Connection Client でリモート接続できなくなった件
少し前に macOS Sierra にバージョンアップしたら Remote Desktop Connection Client で Windows へのリモート接続が失敗するようになってしまっていたが、以下のナレッジで解消した。
Remote Desktop Client App on macOS Sierra / 10.12 will not connect after upgrade
[環境設定] の [セキュリティ]タブで、「認証が失敗した場合も常に接続する」を選ぶとのこと。
YAPC::Asia Tokyo 2015 に行ってきました
なんと去年の YAPC 以来、このブログ更新していなかったことに気づいて愕然。アウトプットの少なさを反省しながら、今年の見聞をせめて簡単にでもメモしておきます。
私は数ヶ月前にエンジニアから PM 職にジョブチェンジ(社内)したので、去年とはちょっとだけ違う目線で見えたような気がします。技術や技術を使ってできることが好きでたまらないエンジニアたちの発表は大変刺激になります。自分はエンジニアとしてはそこまで突き抜けることができなそうだったのでポジションを変えてみたわけですが、コード書いたり技術に触れたりすることから離れたくないし、離れるべきではないなと思いました。
ビッグサイトに行ったのも久しぶりでした。
以下、セッションごとのメモ(自分用)です。
Day 1 (8/21)
Web由来の組み込みエンジニアの半年間のすべて 〜WebとiOSとBLEとハードウェアデバイスのこと〜
- 鍵サービス Akerun (ワールドビジネスサテライトで見たことあった)、週末PJから起業、半年で量産へ
- 組み込み時の問題検知にWeb技術 (「監視社会」w)
- BLE 端末が会場に多いと通信失敗してデモがうまくいかない場合あるらしい？
- セキュリティ、識者によるレビューと専門業者による実際のアタック(スニッフ)の両面でテスト
- その道のプロに会いに行く大事
Conway's Law of Distributed Work
- 透明性をデフォルトに。より頻繁により多くを共有、インデックス化してだれでも見える探せるように
- 意思決定の背景、理由=なぜそうしたのかを残す
- 画面共有ツールの Screenhero (for Slack) よさげ
Electron: Building desktop apps with web technologies
- Atom や Slack のデスクトップ版のベースにもなっている Electron
- Web 版の資産活用してデスクトップアプリ組めそうな予感、場合によって選択肢になるかも
esa.io - 趣味から育てたWebサービスで生きていく
- 「モチベーションとか楽しさは直接コントロールできない」やれることをやる
- bug fix time attack = ゲーミング的に
- weekly active member を計測している
Day 2 (8/22)
実はホットでオープンな Microsoft Azure
- ストリームデータ処理、BI、機械学習などのためのデータ解析系サービスがいろいろある
- 豊富なサンプル
- DC: 60万 コンテナ(物理)ごと入れる、メンテせず壊れたらコンテナごと捨てる(!)
- インターネット人口に沿ってDC・リージョン配置
- 1日140円から使える
データ分析基盤を支える技術
- 先の MS Azure につながる話、データ分析系の全体像
- Data Lake というデータをプールする場所という概念
- 分析要求と、リアルタイム性の強い要求に対してはそれぞれ別の処理系で対応
辛いことをやめる！から始まる業務改善とInfrastructure as Code
- メンバーに対しては具体的なメリットを説明する
- 理想 = 社訓やビジョン vs 現実 のギャップ、みんなで理想に向かうように
- 難しさとコストの２軸でマッピングして、優先順位づけ
- CTO に号令かけてもらう (個人の意見ですよね？にならないように)
- 改善導入後の、現場の「あれ？」という声に即反応
- ドキュメント必要、本筋と Tips の２部構成
- ハンズオン大事
- 削減できた時間コスト＞＞投資時間 であったことを示す
- 技術を広める、底上げをするところは上層から評価されやすい
YAPC::Asia 2014 に行ってきました
8/29, 8/30 の2日間、 YAPC::Asia in Tokyo 2014 に行ってきました。
YAPCは以前も一度行ったことあったよな？と思い返してみたら、それは 2006 年だったようで、なんと 8 年ぶりの参加でした。 それだけ久しぶりに参加してみたら、昔はほんと Perl の濃いお祭りという印象だったのが、今年はベストトーク賞 1 位が PHP のセッションというようなイベントになっててなんとも浦島気分でした。実際、自分も今回はやや意識的に Perl 以外のトークを多めに選択したので、特に言語の垣根を超えたイベントだった印象が強いです。 それでも、全体的には昔からの Perl Mongers たちのギーク感あふれるノリが感じられ、とても楽しかったです。
いくつか、聴講したトークのメモや感想など簡単に記しておきます。
Go For Perl Mongers
Golang のハマりどころなど。「Go かじってみたけどしっくりきてない人」が対象で、かじってもいない自分にはいまいち実感として分からないところも多かったが、むしろ Go さわってみたくなった。 オブジェクト指向は忘れろ、例外(Exception)は存在しない、POSIX のプロセス処理とは違う、など、いろいろパラダイムの異なる言語のようで興味深い。この先も、用途に応じて発展する言語がいろいろ共存する世界がくるのかなと漠然と思う。
お待たせしました。Perl で BDD を簡単に実践する最高にクールなフレームワークができました
QA エンジニア出身で開発エンジニアやってる身としては個人的に一番興味のあったもの。 Test::Builder2 が頓挫してしまったので Test::Kantan というテストフレームワークを作ったというお話。 Builder をベースにしていないが、 Test::Exception とかのためにフックはしているという。インタフェースは Jasmine インスパイア。 テスト最終結果の出力は 1 か 0 で出る(何分の何とかではなく。成功なら OK 1..1)。確かに何％通ったかって基本気にしない。100%通ったか否かが重要。 ちなみにテストの出力をキレイにするモジュールは Test::Pretty というものがある。 Test::Builder2 が出るまでのつなぎとして位置づけてたらしい。既存のテストで、キレイで読みやすい出力を得たい場合はこれを使うとよい。
Scala In Perl Company : Hatena
はてなでの Scala 利用の話。静的型システムを求めての選択。 しかしウワサで聞いたことあるとおり、コンパイルは長くてしんどいらしい。
One layer down below.
Booking.com では一見、車輪の再発明にもみえるものを独自に作っていたりするけど、そうではなく、目的に特化したものを作っているよ、という話。 たとえば HTTP Client として Hijk (ハイク)というものを作っているが、単純なデータ取得目的に特化した 200行くらいのコンパクトな実装で、 LWP の 1万倍早い (あるケースでは C で書かれてる curl コマンドよりも早いとか)。 一般的なモジュールやフレームワークはあらゆるケースを網羅するために主にパフォーマンスが犠牲になってることがままある。 問題解決にはトレードオフが必要で、1つレイヤーを掘り下げて、そもそもの仕組みをしり、自分たちが必要なものだけを実装するということが大事だよ、という。
いろんな言語を適材適所で使おう
組織の技術選択には時間を追うごとに変化していく環境への不確実性に対処する必要がある。そのために 1. 技術的分散: "Microservices" by Martin Fowler 2. 組織能力の涵養 (フレームワークへのコミット, OSSアクティビストのサポート, エコシステムへの join, etc) の2軸が大事だという話。 不勉強で Microservices という単語は今回はじめて知ったのだが、 Amazon の方針としては知っていた。巨大な1システムではなく、複数の小さいサービスの集合体として製品を実現する、それぞれのサービスごとに小さいチームを編成して、サービス間はインタフェースを決めてやりとりする。 大きなシステムは開発効率よいようにみえて非常にハイリスクであること(技術環境が変わっても何も変えられなくなる)は目の当たりにして知っているので、もう、ですよねーとしか言えない。
O2O/IoT/Wearable時代におけるWeb以外のネットワーク技術入門
こちらもあえて馴染みのない分野の話をきいてみようと思って参加。 機械間通信だと省エネが厳しく要求される中で、もともとは HTTP でデバイス間通信しようとしたが、テキストでのやりとり前提でキツく、そこで一方では HTTP ではない PubSub システムとして MQTT が策定され、もう一方では CoAP という HTTP ベースで改善したものが作成されたらしい。 プライバシーとセキュリティの課題を克服していけば、インターネットのパラダイムがもう一段進化するのかもしれないが、このへんはまだまだ進化中の領域なのだなと感じた。モノがネットワーク、システムに加わった世界で、テストとかますます難しそうになる気はする。。 Selenium の作者が(リアルな)ロボットによるテストに走る理由もよく分かる。
Dockerで遊んでみよっかー
Docker もなんとなく概要くらいしか知らずに参加してみたが、具体的なデモでだいぶイメージができた。 具体的なビルド手続きの作り方として、 - 前回から変更のない部分は再ビルド時に省略されること (実行したい場合はノーキャッシュのオプション指定) - COPY コマンドでは対象のファイルに変更があったら再実行され、それ以降のコマンドも再実行されること - それを利用して、毎回実行したいコマンドの前に COPY をおくこと - 変更されにくいファイルだけを先のほうで COPY しておくこと など、だいぶ細かいけど参考になった。 あとは、Docker Hub 上のイメージの選択基準として、 Dockerfile が公開されてて内容がちゃんとしてるかということや、 Automated Build で作られたリポジトリかどうかなど。
Perl Mongersのためのstrace入門
こちらも具体的なチュートリアル。 strace 聞いたことある、くらいの初心者なので、使いドコロとか使い方のイメージをつかめてよかった。 パフォーマンス系の問題などで調査に使えるかもしれない。 - Web サーバは基本的に accept コマンドでブロックしてリクエスト待ってる - 最初の accept の返り値 がそのリクエストのファイルディスクリプタなので、そのFDをおうとそのリクエストへのレスポンスがおえるのでそれが基本 - ちなみに event driven だと accept ではなく epoll で待ってたりする - memcached には sendmsg でコマンド送ってる - strace -p $pid -e "trace=sendmsg" みたいにして既に走ってるプロセスにアタッチして特定コマンドを追う
Plack for Fun and Profit (But Mostly Profit)
既存のコードを rewrite したり refactor すべきかどうかは場合による。セットアップ(環境とか)の変更もコストがかかる。 お金を生むコードを消すわけにはいかない。 既存のレガシーなシステムを維持しつつ、どう新しい仕組みを導入していくか？ １．全部スクラッチで書きなおす → コスト倍以上かかる、ムリ ２．新しいものは新しいフレームワークで ３．なにもせず泣き寝入り → 人生つまらなくするのでナシ
というわけで 2. を実現する("decoupled divergence")ために Plack の Middleware のしくみで複数のシステムを共存させる。 旧フレームワークの仕組みにも、新しいシステムにもルーティングするようにする。
いくつかの Tips: - prefork preloading - async cleanup - smart auth (認証の切替。開発用とか) - SanityDestroyer (メモリリークをふせぐ？)
Plack をそう利用するという視点はなかった。 今仕事で扱ってるシステムの今後の方針のおおきなヒントになった。 microservices の方向にシフトするための手段となるやもしれぬ。
Perl For (Non?) Perl Mongers
scope::guard は go でいうとこの defer Test::mysqld もガードオブジェクトかえす 互換性を保つ＝小さいパーツを組み合わせる
Changing the tires on a moving car: a case study in upgrading legacy architecture
GitHub での、アーキテクチャ移行の話。 同時通訳なしで聞いてたのもあって、ちょっと理解が怪しい。
ローカルシステムなら簡単だが、ストレージが分散すると大変になる。 裏側では git コマンドを直接操作するのではなく Grit という Ruby 製のラッパーがあるらしい。 これをさらに分散ストレージに対応させた Smoke (= Grit in cloud)に発展させた。 また、shared lib つかうのつらい & license 問題があり、 libgit2 (= 再配布可能な git)ができた。 またそれに対し、Rugged という Ruby 製のラッパーをできた。 さらに encode も扱う GitRPC (Git 自体は encode 気にしない (Smoke も)) backscatter というプログラム仕込んで、新旧へのコールの割合をトラックして、新しいほうに移行してないやつをつぶしていく。
といった話だったと思う。 これも、先の Plack の話と同様で、既に動いてるものを維持しながらどう新しい仕組みにシフトしていくかの話。 やはり、どちらでも使い分けられるようにした上で新しいものを追加していく、置き換えていく、というのが定石のようである。
OAuth/OpenID Connectを用いてID連携を実装するときに気を付けること
少し前に OAuth 認証のプロジェクトに関わってたので聴講。ふむふむという感じで、概ね自分の理解や考え方がずれてないっぽいことがわかった。
UX的注意点: - キャンセル時 → ユーザ意図をくむ エラーじゃない - 未登録ユーザ→ メッセだしつつ新規登録へ誘導など - 過去のログイン情報 → 一度認証につかったサービスおぼえとく (e.g. janrain)
セキュリティ: - CSRF: 攻撃者は、認可コードもどってきた時点で別のユーザのセッションで処理させる → 対策: state パラメータをセッションと結びつけておいて戻ってきたら検証。外部におくるので session id そのものは使わない
- ネイティブアプリの場合: 方式1. SDK で取得した access token を使う、バックエンドサーバでユーザ識別子得る → バックエンドはまず access token の発行先が自分かどうかを idp に確認 方式2. WebView で認可コードつかう この場合バックエンドは安心、だけど クライアントサイドがフィッシングぽくなる Google の場合、クライアント登録しておくとネイティブアプリ側で 認可コード取得できる
どうやって導入していくか: - 強度の低いとこだけソーシャルログインに置き換えるのもあり - メールアドレス確認の省略にもなる - 導入の優先順位: 対象は既存ユーザを先に、 デバイスはスマホブラウザを先に
Perlの静的解析入門とPerlリファクタリングツールApp::PRTのご紹介
内容はタイトルのとおりだが、独特かつ小気味よいテンポでかなり笑いの起きていたトーク。 静的解析では、やはり PPI 使って構文分解したうえでいろいろ調べるというのがよいようである。 「git grep のいいやつ」は、ちゃんと関数名のものだけ拾ったりなど、便利そう。 デモ用に用意されたクソコードｗ を実際に App::PRT 使って関数置き換えたりクラス名変えたり。 これもかなり実践で使えそうな予感。 コツとして、対象ファイルをあらかじめ絞ったほうがよい、というのはやはり PPI で解析した場合、ファイル数多いとそうとう時間かかるということだろうか。
おわりに
ライトニングトークの内容はさすがにひとつひとつ書けないですが、やはりライトニングトークが YAPC の醍醐味のひとつかなと感じました。
Perl 以外の内容が多くても、 YAPC の文化は Perl コミュニティの文化をまんま反映していて、どんな変わり者でも受けて入れてくれそうな懐の深さを感じさせる、なんだか居心地のいいイベントでした。
とりあえず以上、雑ですがまとめでした。
「第1回 日本Seleniumユーザーコミュニティ勉強会」参加メモ
1月18日 第1回 日本Seleniumユーザーコミュニティ勉強会(東京都) に参加してきたので、そのメモです。
コミュニティ開催のごあいさつ: TRIDENT 伊藤望さん
日本Seleniumユーザーコミュニティは半年ほどで現在のメンバー 200弱。 海外だと 14000 超えるユーザーグループが。
今日の参加者アンケートでは、 - WebDriver, Selenium IDE, WebDriver と Selenium IDE 両方を使ってる、という人が 1/3ずつくらい - WebDriver 書くのに使ってる言語は Java が圧倒的に多い
招待セッション: Selenium Co-Founder/SauceLabs Jason Huggins さん (通訳付き)
ほんとは去年の 11 月に来るはずだったのが延期になって申し訳ない。でも、イイ言い訳があるんだ。HealthcareGov.com の問題対応のため、ワシントンDCに缶詰にされてた。おかげで何とかなったので、オバマも君たちに感謝してるよ :)
Selenium について
2004 年当時、Gmail とか GApps とか AJAX が出始める直前、JavaScript 安全で使えるよ！となってきた時代に Selenium 作った。「テストしてくれるロボット」だと人には説明してきた。 "FOXX" という、パソコンの前に座って操作してるロボット画像をたとえに使ってるんだけど、画像の出自が分からなくなってしまった。関係者いたら教えてね。
Job Trend の推移では、QTP (現在の UFT) を逆転。 そもそも Selenium という名前はジョークで、当時 QTP 作ってたのが Mercury (=水銀) で、化学物質 Selen は Mercury Poisoning (=水銀中毒)を緩和するというところから来てる。実際、できてるね :)
Appium について
2004年当時は Web といえば基本的にデスクトップPCだった。2007年に iPhone、 2008年に Android が出て、どんどん Mobile が増え、無視できないものになった。 Appium はもともと大企業向けに作った、モバイルテスト用のフレームワーク。去年オープンソース化
Appium の方針: - marketplace に出すものと同じアプリをテストする - 言語、フレームワークにとらわれない - standard automation spec = Selenium API - open-source community effort
ちなみに、W3C で WebDriver をデファクトとして標準化しようと進めている理由は、クロスプラットフォームなテストのために余計なコード書かなくていいようにするため。標準化することで、ブラウザごとの差異の解決をブラウザーベンダーのしごとにしたい。
Appium は HTTPサーバである。テストクライアント = WebDriver では HTTP でやりとりする。 iOS では、 Appiumは UIAutomation in Instruments とやりとりする Proxy である。 Android では同様に、 UiAutomator とやりとりする。
デモ
ライブデモは危険なので動画でやるよ :) - デモ1: Appium デモ (テスト実行するコンソールと、Appium が走ってるコンソールと、対象デバイスのエミュレータ) - デモ2: HealthcareGov.com での一幕 -- 政府の CTO と言われる人が議会での証言で、サイトを画面で見せているが、アカウント作成ボタンが動かないｗ → その日のうちに修正される こんなことがないようにテストしようと思ったという
Appium の使い方: Appium に対象アプリを教える方法: zip が置いてある appUrl を渡す Selenium と同様、 desired capability をセットして、WebDriver セッションを開始して、テストコメンドを実行する
ロボットについて
文字通りのロボット。スタイラス持たせたアームを動かしてスマホやタブレットの画面さわるようなもの。 (このコーナーが、 Jason さん一番イキイキしてたように見えましたｗ)
2011年: レーザーカットした、レゴ互換の部品で作った (実際一部レゴの部品も使ってる) 2012年: スイスの delta アーム？的な技術採用、高速化 (ゲーム操作させようと思ったらスピードないとダメだよね :) 2013年: 3Dプリンタ製にバージョンアップ。けっこうスゴいって言ってもらえるんだけど、日本の税関で見せたときは何このプラスチック？みたいなリアクションだった :)
新しいものが出てくるとテスト、特に自動化されたテストを作るのはムズカシイ。 実際、モバイルに対しても Appium のようなものが出てくるまで時間かかった。 手動テストでやってることそのものができれば、新しいものにも対応できる。
手動テスターは手と目を使う。今のロボットはまだ手しかないので道半ば。 最終的には Selenium や Appium でロボット動かしてテストできるようにしたいと思ってる。今の API はまだだいぶローレベル。 「ここにいけ」という人間的な指示をロボット的に表現しようと思うと、全部角度や距離で表現しないといけない ＝ ムツカシイ言葉でいうと inverse kinematics
デモ
(座標とか角度とかハードコードしたコマンドらしきものをコンソールにコピペして順番に実行、Angry Bird を操作させる)
SauceLabs 社について
営業じゃないよ、と前置きしつつ :)
SauceLabs は大量のテストをクロスプラットフォームでメンテするためのサービスを提供してる。 以前 Google では、2, 3人のチームで 「Selenium ファーム」をメンテしていた。 そのままテスト増やすとテストの数だけ時間がかかってしまうのを、複数マシンに分散させる。 SauceLabs 使わなくても Selenium Grid 使えばできるようにはなってるよ。
質疑応答
Q: たとえば Chrome など、ブラウザの変更にどうついていく体制なのか？
A: (WebDriver の W3C 標準化の話でも言ったように) ブラウザの対応はブラウザベンダーにまかせる方向。Selenium コミッターが責任もたなくていいように。 Chrome だったら Google に文句がいくようにｗ
Q: Seleinum3 はいつでるの？
A: http://code.google.com/p/selenium/wiki/ShippingSelenium3 などウォッチしといて
Q: Appium は Selenium 3 に含まれていく？
A: Selenium3 は Proxy の集合みたいになっていく(？)
Q: RC とか中身的には実際はどうなっていく？
A: JS も残っていくとは思う。(JSによる) emulation ではなく実際の動き = native event に近いほうがよい。とはいえ、使えない場合のフォールバックとして残す必要はあるだろう
Q: Selenium3 の新機能？
A: (Web テスト向けに)特にメジャーな変更はない。機能を関連させるのではなくプロトコルの共通化を重視したい。モバイル独自の API は追加される
Q: ジェブ？という groovy の Selenium ラッパー的なもの使ってる、IE 遅いのとかどうにかならないか
A: 基本原則はマシン増やすこと。Selenium 外のことはどうにもならないが、 HTTP プロトコルは改善の余地あり、 SPDY、protocol buffer とか。
Q: いろんな Selenium (IDE とか Builder とか)はどうなっていくのか (だったか。質問ちょっと聞き逃し)
A: それぞれコミュニティとして残っていく。ただ IDE は Firefox しばりであり、Selenium1 と同じ問題に直面している。 Selenium Builder は ブラウザ固有の実装を極力少なくしようとしている。 仕組みとしては Builder のほうがいいが、今は IDEのほうが機能が豊富な状態。 記録再生ツールの倫理、という点では、プロトタイプ作るにはいいが、作ったケースはすぐに Java などのプログラムにエクスポートすべき(というのは Selenium コミッター的な意見)。 とはいえ、記録再生ツールをベースにテストしたい人も多いので、Selenium プロジェクト内でどう位置づけていくかは不透明でもある。 Builder は undo とかもできないが、よりよいものにすることにはコミットしていく。
Q: Appium、日本語とかモバイルのキーボード使って入力するのが難しい、テキスト直接いれられる？
A: 入れられる。デモでは見栄えがいいのでキーボードで入れる版を見せている :)
Q: Selenium の発音？
A: 元素記号のこというときは セリーニアムっていうけどアメリカでそれいうとイギリス人ぽい :) (結局、「セレニアム」って感じの発音が正しい感じ？)
Q: テストの分析や設計といったところの自動化は対象としない？
A: Selenium はテストの実行に特化している。結果出力なども別。テスト実行だけでも、いろいろなプラットフォーム対応などたくさん仕事があるので、それにスコープを絞っている
Q: Jenkins との関係とか？
A: 前の質問と関連で、結果出力などは Jenkins 使うといい。JUnit, TestNG などの形式とからめて。 スクリーンショットをとるのは大事、最初は結果を信じたくないと思うからね :) それで JUnit で結果をみるとよい。ケースで失敗したときや、ポイントごとでスクショとる。GIFアニメとして見るのもよい。テキストだけじゃなくビジュアル情報も大事。
Q: モバイルのテスト作るのもうちょっと楽にできないか？
A: iOS 用には Appium Inspector というのがある。エレメントを調べたりとかできる。 Android 向けにはまだなので、興味があれば参加してね :)
ライトニングトーク
LT1: 浦山さつき さん
- マニュアルテスター向けの自動化入門
- 手動テストが当たり前のテスト部門には自動化導入するハードル高い
- デモ: Excelマクロによる、入力データと確認結果の組み合わせでIDE用のケース生成＝データドリブンテストという位置づけ
- TABOK の Test Automation Framework の定義でいうとデータドリブンテストは レベル2 とされている
LT2: 大田尾一作さん
- エンタープライズ向け活用事例
- 2006年 Selenium 0.7 の頃から使ってます/記事書いてる
- テスト作成・保守大変 → データ駆動(画面項目を自動取得、コマンドひとつでそのテスト読み込む)・スクショ1行で・DB作成
- IE 複数バージョン対応、ただし工数は削減されず、初期実行時のみ不具合あったり課題も
- オフショア受け入れ、工数は 40%削減、ただしポップアップやセッション制御で苦労
- 某ERPが生成したHTMLは input タグに name がなく、IDも都度変わる、カスタマイズする時間なく適用見送り
- 工数は数10％から2倍ほど初期コストかかるので長期での回収を見込む
- 部分適用でも意味ある
LT3: 玉川紘子さん
- Selenium & Jenkins
- seleniumhq plugin: IDE で作成したHTMLのテストを実行
- selniumhtmlreport plugin: 結果表示(特に複数)
- Selenium plugin: Grid 実行サポート(ノード起動&ブラウザ設定)
- Tips -- 専用環境、データ初期化の仕組み、機能カテゴリごとのジョブ、失敗解析のためのスクショ
LT4: 岩室元典さん
- Selenese Runner
- RC ベースだとバージョンアップで急に動かなくなったり、ログが足りなかったり。かといってWebDriver にしちゃうと IDE に戻せなくてメンテできる人限られるなど。
- WebDriver 指定、ロギング、スクショ、結果出力(JUnit 形式 or HTML)、条件分岐機能追加等
- FF, Chrome, Safari, phantomJS, HTMLUnit に対応
- 実行時、操作中のエレメントをハイライト
LT5: わたなべさん (飛び入り)
- Mixer2 というテンプレエンジン作ってる
- Mixer2 使うと Selenium に親切なHTML(ID が必ずあるとか)が生成される
- テストケース記述も Mixer2 方式で書けるので、開発とテストで同じ書き方できる
個人的な感想など
- WebDriver が W3C 標準になろうとしてる理由が、ブラウザごとの差異をテスト作る側が気にしなくていいようにするため、というのはとても腑に落ちた
- Jason さんは Selenium RC 捨てて WebDriver に移行すべき、って言ってたけど、ライトニングトークでは IDE や RC ベースのテスト実行の話があったりするあたり、まだギャップがあるのかなと感じた。実際、僕のいる会社でも WebDriver ベースでごりごりプログラムとしてテストケース作ってるのはまだ少数だし
- なんでロボット？って思ってたけど、 Jason Huggins さんがロボット大好きだから、というのがよく分かったw それは別としても、新しいデバイスとか出てきた時、結局人間ができることができるようになってれば対応が出来るというのは極論だけどそうかもなーと思った。しかし、Google Glass とか、 iWatch (仮) みたいなものが出てきたらどうテストするんだろうなーとか思ったりした
第8回Jenkins勉強会に参加してみたのでメモ
1日間が空いてしまいましたが、 12/20 (金) に開催された 第8回Jenkins勉強会 に参加してみたので、完全に個人的なメモのレベルですが公開します。
(ちなみに参加者宛に事後メールでお知らせされた、お弁当箱を忘れたアカウントはこちらになります。。。関係者にご迷惑おかけし申し訳ございません。。)
Jenkins勉強会 自体はじめての参加で、 Jenkins もあまり使いこなせていないので、正直ちょっと不安もあったのですが、ビールとおつまみもいただけたし、発表者の皆さんの Jenkins 愛が伝わってきたし、とても楽しくためになる勉強会でした。
メモ
1. 川口さん：「2013年Jenkinsの歩み」
2013年
- 年間コミット数は Linux kernel (5万超)の半分ほど(2万超)に
- 内部エンジンが Winstone から Jetty になって早くなった
- Credentials プラグイン: プラグインごとにキー情報もたなくてすむように
- "高度な(マニアックな)機能" トグルでまとめた
Cloudbees のプロジェクト
"文芸的ビルド"
- README.md の Build セクションを Jenkins が理解してブランチごとのジョブを自動で作ってビルドする
X1K
- ＝ 1000 executer でもだいじょうぶなように
- slave １つにつき 4ssh + 1exe = 6
- SSH 接続の改善、マスターから返す ACK のための帯域 200K いるけど 128K に制限されていたので 4M に拡張
- メモリ改善: 大量リポートの処理
安定化
Jenkins Operations Center
社内Jenkins をまとめた管理するようなやつ、マスターのマスター、SSOなど
Mac OSX のための高速化
2. ヤフー石川さん
- GithubEnterprise から web hook で Jenkins マスターをキック
- Jenkins マスタ 3台、それぞれに対して スレーブ 10 台、構成管理などと連携
Fabric / Capistrano / Rundeck 使い分け検証中
ボトムアップで CI/CD 進めた
- 継続的デリバリ本的なパイプライン
まだ完全自動ではない、社内ワークフローのため。ワンクリックではできる
手動で 2日かかっていたデプロイが 数時間で済むように
- 今は 2 人でまわせる
ハマった1: SCMポーリングで GHE に負荷が集中
→ Web Hook でやるようにした ("Polling must die")
ハマった2: 予算ないと slave 増やせない
→ Jclouds プラグイン: * OpenStack ベースの社内 PaaS と連携で物理サーバ不要に * ビルド終わったら仮想環境も削除、リソース削減
まとめ
質疑応答より
(Web hook よりポーリングがよい場合があるという話に対して) Web hook でビルド実行数が多くなりすぎる場合は "quiet period" 使うとよい (川口さん)
かつてはプライベートクラウドもってたが古くなったので Open なほうに移行していった ** そのほうが社内(セキュリティ)ルールにあわせてカスタマイズしやすい
3. 株式会社シフト 玉川さん：Jenkinsエンタープライズについて
- シフトさんは Cloudbees とパートナー組んでる
- CI や 自動テスト導入のお手伝い
- Jenkins Enterprise 版、売ってます
Enterprise 版は何がうれしい？
- サポートうけられます
- Enterprise only のプラグインつかえます (特に大規模向け)
Enterprise 版のプラグイン紹介
稼働率向上: ジョブ増えすぎたときに
- High Availability: マスタ落ちたときスタンバイ機が自動的に機動 ** Operations Center がそれのさらに高度な管理アプリ
- Folders Plugin ** フォルダごとコピーしてジョブ管理、ビルドフローごとコピーできる、環境変数フォルダ単位で定義
- Templates Plugin ** 親テンプレートから変更を伝播、 Builder & Job Template、ビルド手順で Builder Temlate のもの選択・テンプレで指定したパラメータ使える、ジョブテンプレでジョブ定義のXMLで一部を変数化・実ジョブでは変数部分だけ設定・テンプレの定義変えると実ジョブも変わる (テンプレというか継承っぽい感じ？)
安全
- Role-base access control ** 柔軟な権限管理、ロール→グループ→ユーザ、グループは入れ子にできる、ジョブに対してできること
- Secure copy ** Jenkins 間で成果物をセキュアにコピー
- Custom Update Center ** 社内アップデートセンターみたいな
リソース最適化
- Even Scheduler ** Jenkins はデフォルトではやったことあるスレーブにジョブわりあてるらしい、それを今あいてるやつ使うように
- VMware vCenter Auto-scaling ** VMware 連携
- Skip Next Build ** 指定した期間、ビルド実行しなようにするなど
LT発表
LT のほうは各発表者さんがスライド/ブログ公開されてるので、そちらへリンクさせていただきます。
@akiko_pusu さん：『おひとりさま〜』の1年後 おひとりさまから1年後。
@superbrothers さん：Jenkins with Docker 第8回Jenkins勉強会で「Jenkins with Docker」というLTをしました #jenkinsstudy
感想など
Cloudbees のサービスや、Jenkins Enterprise など、組織的に Jenkins フルで活用していくなら欲しくなるであろう機能が、まさに痒いところに手が届く感じでニーズ汲み取ってるなーと思った
Enterprise 版のプラグインは一部フリーで公開されていると知ったのでこちらは近いうちに試してみたい ** → https://wiki.jenkins-ci.org/display/JENKINS/CloudBees+Free+Enterprise+Plugins
少し前に参加したシステムテスト自動化カンファレンスと参加者層は多少なりともかぶってたのかなという印象
一方で、内容的にはテスト自動化というよりは構成管理とからめた自動化 (仮想化や Docker など)の話も多く、 Jenkins の利用シーンの広がりも感じた ** 個人的にまだあまりよくしらない領域なので、今回興味をもついいきっかけになった
ビール配られた後の歓談タイムではなんとなく隣の人と話すような雰囲気で、人見知りな僕はちょっと戸惑いましたが、幸い話しかけてもらえて、なおかつ共通の知り合いがいることなど分かり、Jenkins どう使ってるなどいろいろ話せたのでとてもよかった
運営および発表者の方々、ありがとうございました。 また機会があれば参加してみたいです。(今度は忘れ物しないように。。。)
ストーリーポイントで開発実績を測っていいのか
Scrum によるアジャイル開発を行っていると、チームごとでストーリーポイント使って見積もりを立てて Velocity を計測、ということをやるわけですが。
そこに、開発全体のアウトプットを定量化したいから、各チームのストーリーポイントのスケールが何倍違うのか知りたい、できればチーム間で同じ基準にしてほしい、という欲求が降ってくる。
しかし、見積もりのためのストーリーポイントによって成果を測ること、また、チームごとの指標であるストーリーポイントをチーム間の比較することのについては、誤りであることがいくつかの記事で指摘されている。
直感的にも、見積もりのための指標が成果・実績を測るものになるのは違和感があるし、そのための指標として計測すること自体が見積もりとしてのストーリーポイントを歪めてしまう危険は想像できる。
そもそも、ストーリーポイントは単位を持たず、 Velocity とセットでなければ意味を持たないはずであり、単純に時間に換算できるものでもない。ただ、実際は、1ポイント≒1日のような、理想日による認識で捉えて議論してしまっている場合がある。アウトプット計測のために用いるという発想も、そのような認識から出てくるものではないかと思う。
では、開発のアウトプット量、言い換えると生産性は、どうやって計測すればいいのか。 おそらく、以下の記事にあるような、 TOC に基づくプロセス全体の価値計測がヒントになるのではないか。
リーンソフトウェア開発でいうバリューストリーム、 DevOps 的な、開発・QA・運用までトータルなプロセスで捉えた、顧客に製品価値を届けるまでの全体を対象とした指標でなければ、部分最適に陥りかねない。
