数値だけの目標管理は危険
最近ふと思うことがあったので。
普段自分たちのやっていることを透明化、可視化しようとすると、数値化は切っても切り離せない。 数値化するので異常が起きているのか気づくし、数値化するから因果も見えやすくなるものも多い。
ただし、数値は万能ではない。 特に、単一数値指標を目標だけにして行動しているときは危ない。 (QCDなんて本当はない、上位の単一指標に集約されるはず、というのはその通りなのだけど、それで世の中がうまく回るか、というのはまた別な話。)
目標管理するときは、バランスの取れた、時には相反する数値指標を入れよう。 数値指標だけではなく、定性情報も入れよう。 それでいて、物事をもっと見えやすくするための数値化は続けていこう。
自分たちは日々色んなこと気づいているはずなんだから。
テストツールGaugeではページオブジェクトはアンチパターン?
はじめに
これはRecruit Engineers Advent Calendar 2019の5日目の記事です。 本日はテストツールGaugeについてです。
同僚のマネージャーさんとよもやましていたら、「受入テストをGaugeで書いてみたい」という話が出ました。 ひとまず宗教上の理由でGebをおすすめするわけですが、Gaugeは触ったことがなかったので触ってみました。
Gaugeとは
Toughtworksが開発している受入テストのためのテスト自動化フレームワークです。
日本でも利用例があるようです。例えば、 https://speakerdeck.com/takayukihayashi/gaugeniyorue2etesuto
早速使ってみようとすると?
というわけで、早速GaugeとGebを組み合わせて、WEBシステムの受入テストを試しに書いてみようとします。 まずはGaugeの利用法を知りたいなと思い、公式githubに乗っていたサンプルプロジェクトを眺めつつドキュメントを読んでみて動かしてみることにしました。
https://github.com/getgauge-examples/java-maven-selenium
と、ここでびっくり。このサンプルPage Ojbect Pattern使ってない。
画面遷移に対応するためにどうしているかというとWebDriverをstaticインスタンスとして保持するDriverオブジェクト経由で使いまわしています。 WebDriverインスタンスの生成は、Gaugeの機能である@BeforeSuiteでテストスイートが走る前に行なっています。 Gaugeではこういうお作法なの??と思って調べていくと、他のサンプルにも出会います。
https://github.com/getgauge-examples/java-gradle-selenium
そのReadmeには刺激的なメッセージが
Deprecation notice Do not use this sample. It's a reference on why page objects will burn your house. Gauge recommends not using page objects. Refer https://github.com/getgauge-examples/gauge-active-admin-example-maven and our blog
なんと、やはりページオブジェクトを使わないことがおすすめされていました。 Gebはページオブジェクトフレンドリーなフレームワークなので、とっても相性が悪そう。。 実際にGebと組み合わせて見ようと試みたのですが、Gebらしいメソッドミッシングをふんだんに利用した書き方だとDriverのハンドリングがかなり難しく、専用のアダプターが入りそうな感じでした。
今回は時間がないのでそのアダプター作りは今後に回して、 このエントリーではなぜページオブジェクトを利用しないのかという意図を探りに行きます。
そうすると公式ブログにその説明エントリーがありました。
https://blog.getgauge.io/are-page-objects-anti-pattern-21b6e337880f
明確に「ページオブジェクトアンチパターン」と書いてありましたね。
すごくざっくりいうとその理由はUIエレメントを基準にクラス分けをしてしまうのは、単一責任原則に反する(ログインの処理と検索の処理が混ざったりしてしまう)ということで、その対策として、「関心事」ごとにクラス設計するのを勧めています。 これにより、Gaugeではページオブジェクトを利用する場合に比べコードを40%削減しているとのこと。 Gaugeが
Less Code, Less Maintenance, More Acceptance Testing
という謳い文句をつけていることはこう言った部分にも出ているんだな、と感心した次第でした。 ただStepから定義されたテストケースに直接エレメント操作が書かれる可能性はあり、結構気をつけないとメンテコスト取られちゃうだろうなぁ、と想像しています。
ちなみに、Gebが微妙ならせめてGroovyで書きたいな、と思っていたら、ちゃんと公式がgroovyのexampleも乗せてくれていました。 (ただしちょっと古いものなので、このexampleはページオブジェクトパターンで書かれています。)
というわけで、GaugeとGebで遊ぼうと思っていたら気づいたらページオブジェクトパターンの設計議論に行き着いたお話でした。
DevLOVEXで登壇してきました。 #devLOVEX #devLOVEXC
いろんな楽しそうなセッションがある中、きていただいたみなさん、ありがとうございました。 スライドは会社確認してからアップしますのでお待ちいただければ(昨日テンション上がりすぎて膨大に修正してしまったので)
内容
これまでの数年間の活動の続きと、その振り返り的な内容でした。
アウトカムだけ出せばそれでいい?
自分としては、アウトカムへのコミットメントはここ最近はしっかりできている気がしていたのですが、 一方で、「チームって楽しいんだっけ? もし楽しくないとしたら、楽しさを犠牲にするアウトカムって本当にいいんだっけ?」 とずっとモヤモヤしていました。 それを、自分なりにチームと直接・間接的に関わりながら折り合いをつけていった話です。 なのでデブサミで登壇した事例の裏話&後日談といった内容になります。
タウンワークをドライブさせるためになんちゃってアジャイルをやめた話 #devsumi #devsumiB / devsumi2018 - Speaker Deck
なぜこの話?
実際にプロダクトの中で悩んでいたから、と言うのもあるのですが、ここ最近の自分の変化にも密接に結びついています。
マネージャーになってから初の登壇
この4月にマネージャーになって、どんな風に過ごしていきたいかなぁというのを数ヶ月模索していました。 その中で、自分の過去数年(特に失敗談)を棚卸ししておきたかった、というのが元々の意図です。
自分の決意表明として
棚卸ししていたところ、自分としてはまさに
実際にアウトカムを出すこと、価値を出すことと vs 楽しさ、やりがい
という対立構造になることが多くて、これをどうやったら解消できるんだろう、ってことに強い関心を持っていることに気づきました。 で、マネージャーになって色々と研修とか出ているうちに、この調整ってマネージャーとしての重要なポイントなんだなと学ぶことになりました。 なので、所信表明というか、自分はまずはこう言うのやりたくてマネージャーになったんだよ、と言うのを残しておきたくて、こういったセッションにさせてもらいました。
終わってみて
ちょっと前半部分に時間取りすぎて尻切れとんぼになってしまったんですが(すいません!)、同じような悩みを持っている人の参考になればいいなと思います。 スライドの中で引用させていただいた方、これまでお世話になった方に多くご参加いただき、あぁ自分は本当に色々な人に支えられてここまできたなぁと思い直した次第です。ありがとうございます。これからもホドボドに頑張っていこうと思います。
最後になりますが、改めて、参加してくださったみなさん、登壇する機会をくださった @papandaさんはじめ運営のみなさま、会場を提供してくださったNAVITIMEさん、ありがとうございました。DevLOVEはずっと話したかったコミュニティなので、とても光栄です。これからもよろしくお願いします。