冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

受入テストを整理したいと思ってやってること

その他 Programming

まだまだ途中なんですが、とりあえず今こういう方向性でツールを触ってますよ、といったあたり。この用途だったらこっち使うべきだろう、というのがあったら知りたかったり。

なお、今回はツールの切り出しをしていないのでリポジトリの納品はございません。ご了承ください。

受入テスト

今のポジション的に私が一番責任を持たなきゃいけないのはプロダクトの要求を決定することです。要求の決定といった場合、何が達成されていれば完了とみなすか、という検証事項の決定も含まれます。主に事前に予測されるシナリオベースでの検証項目となりますが、本エントリではこの検証項目のことを受入テストと呼びます。

これらは先日のエントリでも書いた通り、FeatureMapを使って内容の管理を行っているわけですが、シナリオって結構定型文を意識して書いちゃいますよね？でもって、そんなシナリオできっちりかけることって、自動化できそうなところ多いですよね？

というわけで、なるだけ自動化できるように頑張って整理してみることにしました。

やりたいことのイメージ

f:id:mao_instantlife:20160616052024j:plain

受入テストの組み合わせのベースとなるドキュメントと画面遷移図からUIテスト自動化フレームワークに必要なテンプレートを自動で出せればいいなあ、とそういう感じです。実際のテストを書くところについては人力でいいかな、と。ってか、そこまで定義できないし。

実際にやっていること

で、ここ数週間の成果です。

流れ

f:id:mao_instantlife:20160616052035j:plain

さっきの図に、使っているツールとどの辺に人力がかかってるか書き加えてみました。

もう、この辺のツール選定(テキストベースから生成する感じ)が、エンジニア上がりという感じですね。GitHubやBitBucketでPR送ってレビューできるということを前提にツールを選んでいます。

使っているツールについて

少し説明

受入テストについては、ケースの生成をPICTで管理しています。フィーチャーごとに以下のテンプレートに沿った形でPICTのモデルを作ってる感じですね。必要に応じてフィーチャーごとにケースの制約条件を細かく書いています。

目的:
操作:
状況:
結果:
リカバリ内容:

過去分をseedにして以前のケースを維持しながらテストケースを出力したり、とか細かいことは他にもやっています。ただ、FeatureMapのフィーチャーと1対1で対応づけるとあまりこのモデルがあってないので要改善です。seedの管理よりはGebのSpecテンプレートを生成するようにした方がいいのかな、と思いました。

また、テストケースに今の所PICTでなければならないほど複雑なシナリオのモデルにしてないのでオーバースペックです。状況を重ね合わせたケース漏れは防げると思ってますが。これだったら、シナリオの文章管理だけでもよかったんじゃないの？とか思ってます。テストシナリオを作る上でも要素が少なすぎて柔軟性がないですし。リリースを重ねて整理したいところです。

GebのPageクラスについては、guiflowの画面遷移図から画面の記載を抜き出して生成するようにしています。生成できるのはクラスのテンプレートのみで、 content や取り込むモジュールについてはデザイナからもらったHTMLをもとにコツコツ人力でやっています。アプリケーションの要件に応じてHTMLのタグにid要素つけていったりしないとテスト書きづらいので、このタイミングでやっているという感じです。

余談

この環境をコツコツ試している時に実行環境のJVMのバージョンをあげ忘れてて(1.8.0_11)、Groovyが古いバイトコードに対応しておらずにGebのテストがこけるなんてこともありました *1 。ちょっと前のMySQLのJDBCドライバといい、バージョン違いの罠を積極的に踏み抜いております。JVMのバージョンはちゃんとあげておきましょう。

これから

まだ、最初のリリースに向けた受入テストの整理ですし、リリース重ねることを考慮したらもっと改善したくなるポイントはあると思いますが、他にもやることあるのでこれ以上はちょっと手をかけすぎかな、と。ツールもまだ作り始めたばっかりなので、実案件でもう少し使ってプロセスから整理したいと思ってます。問題ないところはツールとして固めて、Githubにリポジトリ作ろうかと。

guiflowからGebのページクラスのテンプレート生成については、クラスの構造まで生成を自動化するのは無理なので、もうこれしかなかろうな、というところ。ここはしばらく手を入れる必要はなさそうです。

まあ、このGebのテストを自分で書くかどうか、というのはまた悩ましいところで。。。世のプロダクトマネージャの皆様方は受入テストにどこまで携わってるんでしょうかねえ？

*1:

groups.google.com

「スマートフォンアプリマーケティング　現場の教科書」を読みました

その他

PMJPでレビューに手を挙げて、著者のお一人である川畑雄補様よりご恵贈いただきました。

スマートフォンアプリマーケティング 現場の教科書

スマートフォンアプリマーケティング 現場の教科書

より深い理解は、会社に持って行って仕事で使いながら得ていかないといけませんが、まずは通読しましたので、ご紹介いたします。

私の背景

まずは、私がどういうポジションでこれを読んで、所感を書いているのか、評価の上で重要な項目だと思います。これを整理しておこうと思います。

  • エンジニアからチームのマネージャ、プロダクトマネージャというキャリア
  • エンジニアのキャリアはサーバサイド中心
  • 初めてのプロダクトマネージャ現在進行形
  • 担当プロダクトはWebサービスからスタート予定
  • アプリ化は未定

というところです。つまり、本書の内容全てについてすぐに関わるわけではないが、企画やマーケティングなど、プラットフォームに依存しない部分に関しては当事者として読める、というポジションです。

本書の内容

本書はスマートフォンアプリの企画などに携わる人を対象に(おそらくディレクターやプロダクトマネージャも対象)アプリを取り巻くビジネス環境から、企画、リリース後の運用改善までのライフサイクル全般を取り扱っています。ライフサイクルの各ステージに沿って章立てされ、そのステージで必要な現場のノウハウが具体的に書かれています。通読をすれば、時系列でわかるようになっています。

所感

通読での所感をまとめます。

まず、企画や調査に関するツールやサービスの情報がかなり具体的で、アプリの開発でなくても、このような仕事に初めて取り組む上では助けになる情報がありました。その分、これから先、どのタイミングで読むかによっては一部情報はアップデートが必要になるのではないかと感じました(特にルール面)。

ライフサイクルを一通り網羅しているので、プラットフォームに依存しない形でサービスを提供するという流れで読むこともできます。その分、専門性の高い知識に関しての記述という点では概要を抑えておくのみ、というレベルです。しかし、それらの情報へのポインタはしっかりあるので、必要になったタイミングでどんな情報を探さなければならないかに迷うことは少ないと思います。

ただまあ、率直な話、今のキャリアにおいてこれら全てを一人でやりきろうとするのは非常に辛いな、と感じます。面白い仕事であることには間違い無いのですが、どのくらい仲間を作って一人で追いすぎないようにしようかと考えています。どこにも「一人でやるべき」と書いてないので、チームでやること前提で読んでも良いのではないかと。

自分の仕事に対して

エンジニア出身なので、特にマーケティングや分析などビジネス面での打ち手を現場でどうすればいいのか、あまり具体的な情報が得られないところで不安がありました。もちろん、本当に不安が解消されるのはプロダクトが成功を収めた時なのですが、自分がやらなければと思っていた仕事の範囲がより具体的に見えたように感じます。特にChapter 10以降は、そろそろちゃんと考えておかないといけない箇所だったので、このように具体的に行動フローが見えてくる本の存在はありがたいところです。

とりあえず、UIステンシルとSketch欲しいな、と切に思いました。先に手書きできるようにしておいた方がツールに引っ張られすぎないと思うので、ステンシルから、と。Sketchは個人で買おうと思っているので、ライセンスを調べる必要がありますが。

時系列でまず通読した後に、自分が置かれているステージに合わせて、スコープを限定してやるべきことを整理していく使い方がいいのではないかと思います。

蛇足、URLの記載方法に関しての要望

注釈や参考資料に特定の記事やレポートに対するURLの表記が多いので、QRコードで表記してあると参照が楽だったかな、と思います。紙の本を読むときにはPC開いてサイトを調べるというのは少々面倒で、スマホでページを参照したいです。URLの長さがスマホだと打ち込むのが少し辛かったので、とりあえず後で、という感じになってしまいました。QRコードの利用は、「サービス・デザイン入門」という本で見たのですが、非常にうまいやり方だと感じました。

OSSAN力の高いGLIM SPANKYというバンドについて

その他

まあ、まずはこれを聴いてくださいよ。


GLIM SPANKY - 褒めろよ

なんでしょうねえ、この「テクノロジーだけアップデートしました」とでも言いたげな、生まれた時代を間違えた感。Janis Joplinみたいな声に泥くっさいギター。Led ZeppelinやらCreamやら70年代のロックが大好きなおじさんの心を鷲掴みにするOSSAN力、素敵です。

椎名林檎が出てきたときに、「ああ、70年代あたりの影響って出していいんだな」と思って、そこはかとなく安心した記憶があるのですが、そのときもこれほど「まんま」ではなく、結構新しめの感性で作ってたように感じていました。「無罪モラトリアム」と「勝訴ストリップ」をあれほどバランスの良いアルバムに仕上げた椎名林檎と亀田誠治はすごいな、としか言いようのない出来なわけです。が、彼らにはそういうものが全く感じられません。

心配になるのは、これだけOSSAN力を持ってる人のアンテナに引っ掛かりまくるバンドがわけー人に受け入れてもらえるのか、ということなんですが、メジャーでリリースしてるからそれなりには受け入れてもらえてるんでしょうね。これって、一周回って新鮮に感じ取ってもらってるんでしょうか？

まあ、ともあれ、今結構ヘビーローテになりました。ってか公式にMVないから貼れないけど、「踊りに行こうぜ」とか超ど真ん中ですよ。彼らの音楽聴いてると無性にギターを弾きたくなってきます。というか単純に弾いてて楽しそうな曲が多い。はやくレスポールをメンテに出したくなりましたとさ。

Amazon Prime Musicにアルバム入ってるので、Primeの人はみんな聴くべし。GLIM SPANKYとBABY METALでPrimeはもと取ったようなもん。

SUNRISE JOURNEY

SUNRISE JOURNEY

Mng.Strangelove

その他 結論もなくダラダラと

または私は如何にしてプログラミングをするのをやめてマネジメントを愛するようになったか。

すみません、言いたかっただけです。

engineer.crowdworks.jp

このポエムは、上記記事ではなくブクマの反応を見ての感想です。皆さんマネジメントお嫌いなんですね。まあ、タイトルはこのもにょりに対する煽りが少しだけ入ってます。

それと、マネジメントと一口に言っても対象によってアプローチも醍醐味も違うと思うので、ここはチームのマネジメントに絞って話をします。

マネジメントの面白さ

チームで仕事をすることって、私のように圧倒的クリエイティビティの欠如を劣等感にしている人間にとっては、クリエイティビティを発揮して貢献していくためのほぼ唯一の手段なんですよ。自分の働きかけでチームがより力を発揮できるようになって、チームが想定もしていなかったようなハイパフォーマンスを発揮し出す瞬間は本当に見てて楽しいです。AI作って学習させて行ってたら、いつしか自分を超えてしまった感覚ってこんな感じなんでしょうか？

で、このようにちゃんと機能するチームにはそのメカニズムがあり、それは人が集まっただけで出来上がるわけではないということです(タックマンモデルを例に出すまでもなく)。レベルの高いチームのパフォーマンス(生産性と創造力)が単純な総和ではなくそれ以上になるのは、個人のスキルやクリエイティビティの組み合わせが増えるからです。チームはカードを持っていればいるほど強くなるけど、組み合わせ方にコツがいる。マネジメントはそこに働きかける仕事だと思っております *1 。

ただまあ、実装依存とスキルセットの違いは激しいですね。これが悩ましいところといえばその通りですが、経験値はリセットされてもステータス自体がリセットされるわけではないと思ってます。

管理は支持統制じゃない

これは私にとって非常に大事なことなので、何度でも書きますが、管理は支持統制じゃないんですよ？同じだったらなんで「マネージャ」と呼んでるんですかね？「コマンダー」や「コントローラ」と呼ばないんですかね？管理は行動を規制することじゃありません。

そりゃ、手段の一つとして支持統制を使わざるを得ないことはありますが、あまり筋のいいものではありません。支持統制はそれが当たり前になると自分の頭で考えることを放棄します。そうなるとどんな小さなことでもトップが意思決定しなくちゃいけなくなるんですよ。チームにボトルネックを作ってしまって、パフォーマンスが頭打ちになります。

スキルセットが違うし。。。

おっしゃる通り。正直なところ、マネージャやろうと思ったらその前にどんな経験を積めばいいのかはよくわかっていません。チーム状況によって変わるので、チームが変わると必要なスキルセットが変わる可能性もあるし。

私は、マネージャにエンジニアリングスキルが必要という立場に賛同します。が、Tech Lead系の役割でなければ、メンバーとコミュニケーションをとる時のプロトコルというかS/N比というか、とにかくコミュニケーションの質を維持するために必要だという位置付けです。というのも、過去、一緒に仕事をしたマネージャを思い出すと、エンジニアリングスキルがなくてもエンジニアから信頼されているマネージャがいたからです。なので、エンジニアリングができるというよりは、エンジニアリングが何を根拠にしているのかを理解して話せるか、というのが重要だと思います。

メンバーがどういう考え方をベースにして仕事をしているのか、ということに対する理解と、それがチームの目的に反しないようにするためのスキルがコアとしてあり、そのサブセットとして、エンジニアリングがあったりということだと思います。

比較的実装依存がないのは、モデリングと図示するスキルではないかと思います。コミュニケーションする上でも、抽象化しながらそれをビジュアルで示すことの効果は絶大です。これって、割とプログラマが得意なことではないかと思ってるんですが(コードってそもそも抽象だし)。。。

チームの課題解決プロセスを設計、実装する

これは、どういうつもりでマネージャの仕事をしていたか、ということ。要はプログラミングと同じです。ライブラリや処理系はメンバーや置かれた環境。テスト環境がなくて常に本番環境で稼働していることが違うくらいですかね。

KPTで定期的にふりかえるとか、完全にTDDと同じ発想ですよ。KeepとProblemでRedとGreenを検知し、Tryでテストを書いて1週間動かす。そしたらまたKeepとProblemで計測するの繰り返しって、TDDでRed > Green > Refactoringを回すこととほぼ同じように感じています。

他のことにかんしても同じじゃないですかね？コードじゃなくて言葉や絵や態度で処理系とコミュニケーションするんですよ。

マネジメント楽しいよ？

なんか全く伝わってる気がしませんが、そんなにエンジニアリングから離れたことやってるとは思ってない、ってトコだけ感じ取ってくれればいいかな、と(ちょっとハードルを下げた)。デメリットは、十分成長しきったチームは自律してくるので、自分の居場所がなくなってしまうことくらいですかね。その時どうするか？他のチームを強くしに行けばいいんじゃないですかね。

*1:上との折衝やなんやらはマネジメントの仕事というよりは役職としての仕事だと思っております

2016年5月の読書メモ

その他

妻が退院したこともあって、生活面ではほぼ前のペースを取り戻すことができました。出かけることを少なくした分、読書に集中できている気がします。

5月の読書量

6冊ですね。ほぼやっと「夏への扉(原語)」をやっつけました。

ちょっと積ん読がたまってきているので、来月からは趣味分をもう少し読みたいです。

白暮のクロニクル 8巻

白暮のクロニクル 8 (ビッグコミックス)

白暮のクロニクル 8 (ビッグコミックス)

一人から始めるユーザーエクスペリエンス

一人から始めるユーザーエクスペリエンス

一人から始めるユーザーエクスペリエンス

デザイン思考が世界を変える

デザイン思考が世界を変える (ハヤカワ・ノンフィクション文庫)

デザイン思考が世界を変える (ハヤカワ・ノンフィクション文庫)

The Customer Journey

The Customer Journey 「選ばれるブランド」になる マーケティングの新技法を大解説

The Customer Journey 「選ばれるブランド」になる マーケティングの新技法を大解説

The door into summer

The Door into Summer (English Edition)

The Door into Summer (English Edition)

さよなら身体

さよなら身体

さよなら身体

今月のベスト本

ちょっと難しいですが、「一人から始めるユーザーエクスペリエンス」ですね。置かれている状況によってメソッドが使い分けられる作りになっているのがいいですし、何が何でもこれだけやれ、というメソッドのチョイスがいいです。

ただ、「さよなら身体」もかなり捨て難い。勧めるの難しいけど。