Spring Fest 2018に参加してきました

Spring Fest 2018 に参加してきました。

参加したセッションは以下の通りです。
キーノートが結構盛り上がっていたのですが、子供を保育園に送ってから行ったら間に合わず…

  • 決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
  • 実際のプロジェクトでSpringアプリをKotlinで開発して得た気づき集
  • Knative: Serving your Serverless Java Service on Kubernetes the 12-Factor way
  • 500+のサーバーで動くLINE Ads PlatformをささえるSpring
  • Spring Boot with Kotlin, functional configuration and GraalVM
  • Micrometer/Prometheusによる大規模システムモニタリング 〜ヤフーインターネット広告システムでの導入事例〜

それぞれ聴講した感想を。

決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発

自身のキャリアとして、クレジットカードの基幹システムや決済システムに多く携わってきたのでとても興味があったセッションです。

内容としては、開発をベンダーに任せきりだった状態から、

  • 運用作業の自動化
  • 開発基盤の整備(GitHub Enterprise、Slack、Confluence、Jiraの導入)
  • サービス監視の導入(Elastic Stack)
  • CIの導入(Jenkins, Nexus, SonarQube)
  • Spring Boot、Spring Cloudへ

と身近なできるところから進め、体制を増やしながら改善を進めてきたという前振りから始まりました。 正直、ここまでで十分すごいなって感じだったのですが、その後プラットフォームとして Pivotal Application Service(PAS) を採用、Concourse CI でビルドパイプラインの構築、開発環境では常にCI/CDが実行され、Productionへはワンクリックでデプロイされるというモダンな構成まで持っていっていて凄いですね…。ベンダーに任せきりから2,3年でここまで来るって思うと、エンダー(SIer)側の立場から見て色々思うところがありました。

資料でわかりやすかったのは、開発プロジェクトの体制と責任分界って箇所。アプリケーション開発者はアプリケーションとデータまで、The Twelve-Factor Appを守ること、ってところが明快で理解しやすかったです。

そのほか、

  • Javaの複数バージョンでCIを実施している
    • バージョンアップ前から実施しているので、バージョンアップする際に安心してあげられる(なるほど!)
    • 本番のJavaバージョン以外でCIが失敗していても本番のバージョンのCIが通っていればOKとした場合、いつコケた箇所を直すんだろう?(すぐに、だと思うけど優先順位が低くなりがちになりそうに思えて、放置されないのかなーとか)
    • Javaのバージョンアップについていく姿勢良い。 攻めて守る !!
  • JMeterでの性能テストを毎日継続して実行、Slackにレポートを送るの良い
    • AWSなどを使うと難しそう(コスト面や申請などで)
  • アプリケーション構成の章のわかりみが凄かった
    • 他加盟店に影響がでないように作り込んだことあるなーとか
    • 接続先多いと大変だよねーとか
    • 決済機関とか特殊な プロトコルでやりとりしたり、色々面倒や苦労があると思うんだけど、そこらへんも聞きたかった。懇親会出ればよかったー

などなど色々感想が出てきて、とても楽しかったです! まだ新システムをリリースしていないとのことだったので、リリース後にどうなったか聞いてみたいと思いました。

実際のプロジェクトでSpringアプリをKotlinで開発して得た気づき集

最近AndroidアプリをKotlinで書いてたりするので(めっちゃ初心者)、興味のあったKotlinのセッションへ。

セッションは、SpringとKotlinの関係(仲良し!)からKotlinのおさらいとSpring利用時の注意点、Spring WebFluxとCoroutinesあたりの話し、Springのアノテーションを減らす、Kotlinでのテスト、といった内容でした。

SpringをKotlinで利用する場合の注意点などは、初心者な自分にもわかりやすく、とてもありがたかったです。

Spring WebFluxでCoroutinesを使う話しあたりはじっくり資料読んだりドキュメント読まないと自分には厳しいですね(´・ω・`) ただ、KotlinのCoroutinesを利用するとスッキリして読みやすく、書きやすくなることは分かったので機会があった際の選択肢にはなるかなと思います。 仕事上、ここらへんの技術を使う機会があるのか怪しいですが…

アノテーションを消していくってところは、いまいちモチベーションが分からなかったですが、起動速度が早くなるのは良いなと思いました。

テストについてはJUnit5を利用しており、モックはMockKを利用している。 特定の文脈でしか呼び出せないCoroutineの呼び出しだったり、デフォルト finalになるクラスもモックにできるのでMockKは便利(というかこれ以外良い選択肢がなさそう?)。

コーディングは ktlint: An anti-bikeshedding Kotlin linter with built-in formatter に従っており、それ以外についてはUbie社でKotlinのコーディングスタイルガイドを作成し、それに従っているとのこと。あ、lateinitとか普通に使ってたな…

Knative: Serving your Serverless Java Service on Kubernetes the 12-Factor way

Knativeの話しが聞きたくて行ったのですが、ほとんど無くて残念でした。 しかも、前半の前振りで疲れて肝心のKnativeの説明部分を集中して聞けず…

ServerlessやFaaSの説明はほどほどに、Knativeの話しをもっとしてほしかった…

500+のサーバーで動くLINE Ads PlatformをささえるSpring

LINEの広告プラットフォームの話。 LINEの広告は7800万人(MAU) にリーチできる(凄い…)プラットフォーム。広告は様々なバリエーション、レイアウト、フォーマットで出す必要があり、しかも50ms以内にオークションしてレスポンスを返さなければならない厳しいシステムとのこと。

広告系の単語が多く、理解しづらい点もありましたが、そこそこ面倒なことを爆速でやらなければならない大変さが滲み出ていました。

アーキテクチャ周りは、基本的にはメモリに乗るものは乗せる、ダメならRedis、みたいな感じで速度をかなり意識している感じです。 サービス間の連携はKafkaを使っていて、かなり使い倒しているようです。

GCが気になるからGoにしたって話しと、ヒープを増やして対応したって話しがあって、Goにせずともどうにかなったのでは?とか思いました。 ちなみに、G1GCを選択していたようですが、ヒープ増やす前の4Gは少ないんじゃないかな?と思いました。

Spring Boot with Kotlin, functional configuration and GraalVM

甲府ー、じゃふー。 Spring Bootでアノテーションで設定しているところを関数(lambda)で設定する、設定はKofu, JafuというDSLで記載する…って感じ?

翻訳するとヤバイ

f:id:tenten0213:20181105221735p:plain

たろうさんのセッションでもあったように、クラスパススキャンが無くなるので起動速度が早くなるという点と、メモリ消費量が少なくなる、GraalVMネイティブイメージフレンドリーといった特徴があるようです。

キーノートでデモしたのかな?相当起動速度が早いようなので、コンテナだったりFaaSの領域で活きてくると面白いなーと思いました。 普段の開発時はさすがにネイティブイメージをビルドじゃなく、ふつうにサーバ立ち上げるのかな?開発、デプロイのプロセスってどうなるんだろう?

Micrometer/Prometheusによる大規模システムモニタリング 〜ヤフーインターネット広告システムでの導入事例〜

MicrometerとPrometheusを使って、3000以上のSpringアプリ、数先インスタンスの監視を行っているとのこと。 プラットフォームは多様で、OpenStack、k8s、PCFなどを利用している。処理の方式も、Web、Web API、バッチ、Pub/Subなど様々。

その監視・運用で困ったことや工夫したことなどを語っていました。 具体的なハマりポイントと、どう解決したかが語られていて、Micrometer, Prometheusを利用している人には参考になりそうでした。 メモはしてあるのですが、合っているか不安なので…資料公開されるのを期待しています!

おわりに

各社の事例と、尖った技術の話しを中心に聞きました。 事例は凄いなって思うものや、参考になるものが多く勉強になりました。尖った技術の話は理解できない箇所も多かったですが、来年、再来年あたりどう変わっているかな?と考えると面白かったです。

運営をしてくださったみなさん、JSUGのみなさん、ありがとうございました!!

AWS 認定ソリューションアーキテクト – アソシエイトに合格しました。

これです↓

@kiririmode さんのブログ 見て、自分も受けようって思ってたら半年近く経ってた…

業務でぼちぼちAWSに関わる機会が増えてきて、体系的に学びたいって思ったのが受験したモチベーションです。

ちなみに、受けたのは2018/8/12 までの旧試験です。 モチベーション的には新しい方を受けたほうが良かったと思うのですが、範囲広がっているし対策的なのも旧バージョン多いし…自力だけじゃ受かるか不安!ってことで旧バージョンを受けてきました。

学習期間は半月ほど、時間は30h程度でしょうか。 会社で業務中に勉強していいよって時間を使って20hくらい、プライベートで10hくらいです。

学習は以下のような感じで進めました。

対策本でざっくり概要を把握する

唯一?出ている対策本でテストだったり対策のイメージを掴みました。 これだけだと全然内容的に足りていないので、これだけを頼りにしていたら落ちていたと思います。

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

AWSのウェビナーで試験のポイントを掴む

AWSのウェビナーでソリューションアーキテクトアソシエイトの対策がちょうどいいタイミングで開催されていたので、ウェビナーを見てポイントを押さえました。 出題の雰囲気や、どう考えて解いていくのがいいのかみたいなポイントが分かったので良かったです。

あとはひたすら公式資料を読み漁る

知識が足りていない箇所、出題割合が高い箇所を重点的に、以下をざーっと読みました。 資料集の方はポイントがまとまっているので、これを読むのが一番かと。

最後は模試で理解度確認

2,160 円で模擬試験が受けられるので、心配な人は受けるといいかと。 自分は受験当日の午前に受けて、「えっ、そこも範囲なの…」って軽く絶望しましたがw

模試、問題の傾向とかレベル感を把握するには良いんですけど、合否の結果しか出ないので、どこが間違っていたかわからないし、試験後に試験問題を見直せないのがちょっと厳しいですね…

理解が足りないと気づいた点や、苦手な箇所に気づけたのでテストまでの2時間くらいで知識を詰め込みました。。。

いざ本番

身分証明書のスキャンの向きを間違えてアワアワしたりしました。 テスト自体は模試と同じ形式だったので落ち着いて取り組めましたが、テスト用のアプリ?が80分の試験中に3回落ち、内2回はWindowsの再起動を伴ったりしたのでストレスが半端じゃなかったです。

同時に受けた人もそんな感じだったので、これから受験する人はそんなものかと思ってイライラしないようにしてもらえればと思います。 ちなみに、再開するまでの時間は時計が止まっているはず。(というか、むしろちょっと伸びていた気が…)

自分はメモ用の紙?に HELP! m(_ _)m とか書いて気を紛らわしていましたw

トラブルは多かったですが、時間に余裕があったので1周見直して、もう良いかなってタイミングで終わらせました。

ふりかえり

なんとなくサービスの概要くらいは知っていて、雰囲気で話していることはわかるって感じだったのですが、AWSをうまく使う方法、可用性を上げる、コストを抑える設計の方法などを体系的に学ぶことができました。

旧試験が公開されてから多くのサービスが増えているので、差分は別途キャッチアップしないといけないですね。

ぼちぼち業務で触れる機会も増えてくると思うので、業務で使いつつプロフェッショナルの取得でも目指そうかと思います。

鼻の粘膜焼いた

生まれてからずっとアレルギー性鼻炎で、いつのまにか花粉症にもなっていて、一年間通してなかなか生きるのがツラい。 風邪かなーって思って数日大人しく寝ていても熱が下がらないことが多くて、そんなときは大体、副鼻腔炎が悪化して熱が出ている感じだった。

看護師やっている奥さんに「それ風邪じゃないんじゃない?耳鼻科行ってみたら?」と言われてからは、熱が出ても大体耳鼻科行けば治る感じになって生きやすくなった。もうアレロックとオノン無しの生活は考えられない…!

って感じで薬漬けの生活送ってたんだけど、3ヶ月分の薬貰って大体5,000円とかかかっていたので中々医療費が嵩んでいた。 薬飲むのは習慣になっていたけど、2,3ヶ月に1回は鼻炎悪化してツラいし鼻の粘膜焼いてみることにした。

ホントは3月くらいに焼こうとしたんだけど、副鼻腔炎悪化したり花粉で粘膜腫れてたりしたから花粉が減ってきて鼻炎が治まったタイミングで焼くことにした。

ちなみに、花粉症だったりの治療で有名なものには他に、舌下免疫療法だったり皮下免疫療法なんかがある。 舌下免疫療法は舌の下に薬を垂らしたり、錠剤を置いたりする。大体3年〜5年くらい治癒もしくは長期寛解までにかかる。大体2,4000円/年くらい薬やら通院でお金がかかる。基本的には1回の治療で1つのアレルゲンにしか対応できない。複数のアレルゲンを持っている人は効果が出にくくオススメされないこともある模様。(自分はアレルゲン多そうだったので止めといた)

ってことで、焼いた。

事前に治療方法については聞いていたから、説明もほどほどに麻酔から。

麻酔はガーゼに麻酔を染み込ませたものを鼻の穴の奥まで突っ込むという力技。今回の治療で1番キツかったのがこれだった。 麻酔は1回15分、ガーゼを取り替えて2回行った。2回目はすでに麻酔が効いていたのであまり痛くなかった。

麻酔が完了したら、いよいよレーザー治療。 レーザー用のメガネを着けて、それでも危険なので治療中は目を閉じろと言われたので閉じていた。 麻酔のおかげかレーザーは全然痛くなく、鼻の中を細い棒で押されているような感じだった。匂いは、なんか燃やしちゃマズいものを燃やしたような臭いがした…

治療自体は10分〜15分くらいで終わった。体調も問題なかったので、痛み止めやら抗生物質を貰ってすぐに帰ることができた。

術後は鼻水、鼻閉がひどくなり、鼻がダラダラ出てくる…
数日でこの症状は改善するらしい。2、3日は鼻をかんではいけない、4、5日は飲酒、スポーツ、長湯禁止、1ヶ月は鼻をすすってはいけない、プール、海は禁止など色々注意が必要。

ちなみに、費用は1,0000円ちょいだった。効果の持続期間は人によりけりで、半年から2〜3年続く人もいるらしい。

麻酔をした後鼻腔が広がり、人生で体感した記憶が無いほど鼻の通りが良くなったのだが、「レーザー治療でこの状態に近づくよ」と言われたので、効果が出るのを期待して待ってる。

はじめてのスクラムマスター振り返り

去年の12月から約半年間、はじめてスクラムマスターを担当したので振り返りです。 プロジェクトの概要や技術的なアレコレはQiitaのSIの現場のiOSアプリケーション開発 - Qiitaという記事にまとめてあります。

チーム構成

開発チーム

開発チームは5人で、(アンチパターンですが)自分がスクラムマスターと開発者を兼任していました。 5人中スクラム経験者は1人のみ、技術的にもiOS開発経験者が1人というメンバー構成で、若手中心(2年目2人、3年目1人)かつ開発経験浅めのメンバーが多いチームでした。

また、2スプリント目から1人追加になったり、他プロジェクトの対応で2人抜けて戻ってきたりと、プロジェクト途中での人数の増減が何回か発生しました。

f:id:tenten0213:20170605171349p:plain

スクラムマスター

スクラムマスターは自分が担当しました。 タイトルの通り、初めてのスクラムマスターでした。

2011年頃から社内のアジャイルサムライ読書会に参加したり、社外の勉強会に参加したりして興味を持って勉強していたので、なかなか感慨深いものがありました。 f:id:tenten0213:20170605142727p:plain

仕事でスクラムを採用するのは初めてでしたが、予備知識があったのでわりとスムーズに開始できたように思います。

プロジェクト開始直後の12月に認定スクラムマスター研修を受講し、認定スクラムマスターになりました。 プロジェクトの序盤での参加でしたが、課題に感じていたことや改善したい点を持って研修に参加することができ、学ぶことが多かったように思います。 プロジェクト中、何度も研修時のノートを開いて参考にしていました。

スクラムマスターと開発者の兼任

若手中心(2年目2人、3年目1人)かつ開発経験が浅いメンバーが多かったため、それなりに開発経験がある自分が開発者とスクラムマスターを兼任しました。

ずっと兼任していた訳ではなく、アーキテクチャが固まり、開発のリズムが出てきた4スプリント目以降はほとんどタスクを担当せず、ほぼスクラムマスターに専念(プロジェクトとは別の仕事もしていましたが)することができました。

兼任で苦労したのが、同じ開発者でもあるはずなのにスクラムマスターとして「開発チームとしてどう思う?チームとしてどうしたいの?」と自分が開発チームから抜けているような立ち位置から発言しなければならないことでした。

上記については、自身の立ち位置を明確にしてから話したり、スクラムマスターとして発言する際はチームの決定を左右するような発言は極力避け、チームに考えてもらうようにするなど工夫することで混乱を回避しました。 プロジェクト完了時の振り返りでもチームに混乱しなかったか確認しましたが、混乱するようなことは無かったようです。

ただ、個人的にはやりづらく、「大丈夫?混乱したりしない?」と頻繁にチームに確認していたように思います。

また、担当するタスクの量も専任の開発チームメンバーよりは少なくなるため、チームから不満がでないかヒヤヒヤしていました。 他の仕事や新卒のリクルータ、人事的なアレコレであまり時間が割けなかった時期もあったのですが、プロジェクトに関係ないことでも何をやっているかを表明し、透明性を保つように意識していました。

兼任でチームメンバーもやりにくい面が多々あったと思いますが、協力してくれ、理解を示してくれたメンバーに感謝です。

プロダクトオーナー

プロダクトオーナーは顧客側から出すことができず、社内からアサインしました。 基本的にはプロダクトオーナーに優先順位をつけてもらって開発を進めましたが、適宜顧客へのデモや優先順位の確認などを実施しました。

プロダクトオーナーの時間が取れなかったため、プロダクトバックログの作成、メンテナンスはすべて開発チームで行い、スプリントプランニング時にプロダクトオーナーに説明・合意するようにしていました。

プロダクトオーナーと他案件の兼任

プロダクトオーナーが他案件との掛け持ちや障害対応などで忙しく、スプリントプランニングやスプリントレビューの時間をなんとか確保できる、といった状況でした。

ただ、チームに対しては協力的で、必要な情報は声をかければすぐに貰えていました。 以下で書いてあるように、プロジェクト特性上あまり優先順位などが変化しなかったので、どうにかなったようにも思います。

顧客との関係

関係は悪くなかったですが、積極的に関わるような感じでもありませんでした。

プロジェクト序盤はあまりコミュニケーションが取れませんでしたが、一通りの動くものが出来てからはデモなどを通して関わる機会が増えたように思います。

今後どう顧客を巻き込んで行くかはスクラムマスターとしての課題だと思っています。

時系列での振り返り

2週間1スプリントで9スプリント実施しました。

もともとスケジュールが決まっていたプロジェクトだったので、予定通りのスプリントを実施して完了した感じですが、成果が出なければもっと早く中止になっていた可能性もありました。

プロジェクト開始前

初めてのアーキテクチャ開発プロセスということもあり、バタバタしていました。

アーキテクチャ周りはプライベートで勉強したり調べ物を予めしておいた内容をまとめ、唯一のiOS開発経験者にPoCをお願いし、アーキテクチャを固めていきました。

今まで担当してきた案件で作成していたようなプロジェクト計画に該当するものは、インセプションデッキとスプリント全体計画で代替しました。

お客様もあまり興味がなさそうだったので、設計書などの成果物はかなり省力化しています。

Qiitaの記事を書いた時点ではMarkdownで、と書いていましたが、途中からホワイトボードに書いた内容を写真で取ることで代用するようになりました。

プロジェクト序盤(1〜3スプリント) ⚡️

1スプリント目の開始翌日に、緊急で対応してほしいという案件の割り込みが入り、いきなり開発チームから自分と唯一のiOS開発者が一旦離脱という羽目に。

スクラムマスターとしてはチームを守らなければならないのですが、なかなか難しいです…

スタートを切った直後のタイミングだったので、再度スプリントプランニングを行い、縮小した体制でリスタートしました。 しかし、1スプリント目は開発経験の浅いメンバーのみで実施したため、成果はほぼゼロという状態になってしまいました。

課題としては、設計・実装スキル不足、ストーリーの設計〜実装を1人で担当することによる属人化といった感じでした。

このタイミングで認定スクラムマスター研修を受講しています。

チームへの正式な復帰は3スプリント目からだったのですが、研修で"スプリントプランニング中に全員で設計を行い、1h以下のタスクになるように詳細化する“という方法を学んだので、チームに取り入れてみました。これがかなり有効でした。

2スプリント目ではまだチームに復帰していなかったのですがスプリントプランニングには参加することにし、自分がホワイトボードの前で実際に設計を行ってみせ、タスクの詳細化を行うことで設計の考え方やポイントなどを伝えることで設計スキル不足を補いました。

設計はかなり詳細に行い、必要に応じてコードを書いて挙動を確かめたりもしていたので相当時間を使っていました。ちなみに、最長340分スプリントプランニングを行っていたこともあります。

プランニングに時間がかかるのですが、その後のタスク消化は迷うことなく進めることができるようになりました。

また、全員の前で設計を行いタスクを詳細化することで全員がどのタスクでも実施することができるようになり、朝会(デイリースクラム)でタスクをプルできるようになりました。

実装スキル不足はチームでSwiftの勉強会を行ったり、ペアプロを行うことで解消していきました。

チームのルールとして"同じストーリーのタスクは連続で実施しない" などを定義して、属人化を防ぐ工夫も行いました。(やり過ぎると生産性が上がらないのでほどほどに)

他には"15分ルール"、"ボーイスカウトルール"など自分たちで考え、ルールを導入していきました。

ルールの中には途中で外したものもあり、適宜チームに合わせて選択するようにしていました。

プロジェクト中盤(4〜6スプリント) ⛅️

メンバーのアーキテクチャへの理解が深まってきて開発のリズムが出てきたので、少しづつ"タイムボックス"や"Doneの定義"など厳しく守ってもらうようにしていきました。

朝会や振り返りが長引きがちだったので、朝会は15分、振り返りは1.5時間のタイムボックスをしっかり守るように伝えました。 “会議には必ずファシリテーターとタイムキーパーを配置する"というルールが追加になりました。

また、ストーリーやタスクによって完了条件が曖昧なものがあり、メンバー毎の認識齟齬によるタスクの漏れが出ていました。 これに対してはストーリーに前提条件や完了条件を記載し、必ずレビューをしてもらうようにし、対策しました。

4スプリント目ではプランニング時に約束したストーリーが実施できる状態でなかったことがスプリント開始後にわかり、プロダクトオーナーに謝ってストーリーを入れ替えさせてもらいました。これはプロダクトバックログのメンテナンスが出来ていなかったことが原因だったので、このスプリント以降プロダクトバックログリファインメントを実施するようになりました。

スクラムのプラクティスやルールを一気に全て守ってもらうのではなく、一歩一歩確実に理解を深めてもらうようにしました。

特に、安全に失敗させ、自分たちで考えて改善してもらうように意識しました。

プロジェクト終盤(7〜9スプリント) 🌞

ここまでのスプリントは開発者とスクラムマスターの兼任、スクラムマスターとしてのティーチングという役割を担ってきましたが、6スプリント終了時点でかなり自律的なチームになっていました。 なので、7〜9スプリント目では困ったときに頼ってもらう程度の関わりに抑え、自分たちで考えて進めてもらいました。

関わりを薄くしても自分たちで改善を続けベロシティを上げていたのでかなり頼もしく、安心して任せることができました。

その他

スキルマップの導入

以下のようなスキルマップを作成し、得意な人と苦手な人でペアプロやペア調査などを行うことでチーム全体の戦力の底上げをしました。 また、習得したいスキルに印が付いているものに関連するタスクは優先的にその人に担当してもらうようにし、個人のキャリアや志向も重視するようにしました。

http://www.ryuzee.com/contents/blog/images/7065/01.png スキルマップ作成のすすめ | Ryuzee.com

特に2年目の2人には、初めてお客様との打ち合わせや説明する機会を設けることができ、かなり成長してもらうことが出来たと思います。 上司からも半期前と比べて見違えるようだと言ってもらえたので、かなり嬉しかったです。

ニワトリとブタ

タイトルはスクラムで有名な寓話です。自分のチームでも意思決定権のないお客様の意見に振り回され、計画変更を余儀なくされる事態が発生しました。 立場としてはお客様なので言っていることを信じて要望に応えようとしてしまいがちなのですが、お客様の中でも意思統一が出来ていない場合があります。

お客様の総意なのか、意思決定権をもっているお客様の意見はどうなのかを確認する必要があることを身をもって学ぶことができました…

振り返り

振り返りはKPTA で行いました。 KPTだとTryに上がったものの実施されない、みたいなことが経験上多かったのでKPTAを採用し、確実に改善Actionが実施されるようにしました。

以下は9スプリントで出たKPTAの数です。

  • KEEP: 92
  • PROBLEM: 153
  • TRY: 83
  • ACTION: 71

細かいものも出ていましたが、かなりの数の改善が実施されました。

はじめてのスクラムマスターをやるにあたり参考にしたもの

まとめ

まとめてブログに書こうとしたら膨大な量になってしまいました。 もう少し短いスパンでアウトプットしないとダメですね…

はじめてのスクラムマスターとしての経験を振り返ってみました。 はじめてということもあり探り探りでしたが、自律的で自慢できるチームにすることができました。

今後は他チームや別部門など組織を跨いだ影響を与えていくこと、お客様を巻き込んで進めていくことが課題だと思っているので、そこらへんに取り組んでいこうと思います。

Concourse CI/CD Meetup Tokyo #5 でConcourseでiOSアプリのビルドをする話しをしてきた

このイベント。

発表資料はコレです。

元ネタはコレで、

コードとかはここに置いてあります。

Pivotal社でビール飲みながらConcourseの実運用のノウハウを聞けてサイコーだった。

SEを父と夫に持つ奥さんへ

妻・夫を愛してるITエンジニア Advent Calendar 2016 - Adventar の19日目です。

今日は奥さんの誕生日だ。おめでとう。生まれてきて、出会って、結婚してくれてありがとう。

奥さんは高校の同級生で同い年なので、2ヶ月弱お姉さんになる。若い頃は「お姉さんだから言うこと聞いてね」とか話していたけど、最近は「おばさんになっちゃったー」とかふざけながら話している。付き合いだしてから10年弱、結婚してからは3年弱。こうやって同じ時間を過ごして歳を重ねていけるのが愛おしい。

タイトルにもしているけれど、奥さんのお父さん、義父は現役バリバリのSEとしてまだ働いている。 子供の頃は起きている間にほとんど家に帰ってこなかったらしく、母子家庭のようだったと話している。

自身もプロジェクトの状況次第では帰宅が遅くなることがあり、終電帰りや深夜の帰宅が続くこともたまにある。今年の1月から3月くらいは終電帰りが多くて家庭を任せきりだった。

忙しいと心身共に疲れてくるのだが、帰って奥さんと息子の寝顔を見ると疲れも吹っ飛んで、日々働くことができた。大変なプロジェクトだったけど、なんとか終わらせることが出来たのは奥さんと子供のおかげだと思う。ありがとう。

義父もSEということもあり、ガジェットや技術書への理解があるのもありがたい。 特に技術書は増える一方なのだが、仕事に必要なんでしょ?と理解を示してくれる。最近はさすがに多すぎだと怒られたので、先輩から頂いた裁断機でPDFに取り込もうと思う。 奥さんは看護師で、SEと同様に日々の勉強が必要なので理解があるのだと思う。

看護師といえば…最近鼻炎の治療を続けているのだけど、息子の胃腸炎を貰って39度の熱を出し、嘔吐したことがあった。 病院で診てもらい薬を貰ってきたのだが、飲み合わせが心配で胃腸炎の薬だけ飲もうとしていたら、奥さんが飲み合わせについて薬局に問い合わせてくれた。 普段はごはんを冷凍し忘れたり、安売りしてた肉を買って使い忘れたりするボケボケな奥さんだけど、スラスラ症状や鼻炎で飲んでる薬名、胃腸炎で貰った薬名を説明していて流石だった。うん、惚気だ。

子供はまだ2歳だけど、自分が使っているMacBookに興味を示してキーボードを叩いたり、iPadiPhoneでゲームやyoutube見たりしている。 あまり画面ばかり見せたくないのだけど、父としては自分が好きなことに興味を示してくれるのは嬉しい。 将来、親子3代でなにか出来たら面白いなーと思っている。

とりとめのないブログになったけど、これから2ヶ月の年下期間を楽しみつつ、また同じ時を過ごしていこうと思う。

いつもありがとう。これからもよろしく。

UIテスト自動化でSIerのExcelスクショは滅びるのか

先日 JJUG CCC 2016 Fall に参加してきたってブログに書いたとおり、JJUG CCC 2016 Fallに参加してきました。

直接セッションは聞いていないのですが、 @backpaper0さんの 「Selenideを試行錯誤しながら実践するブラウザ自動テスト」というセッション中に流れてきたツイートがきっかけでタイトルの内容について考えてみたので書いてみます。

@backpaper0 さんの当日の資料は以下になります。

考えるきっかけになったのは、@khasunuma さんの以下ツイート。

@khasunumaさんは同イベントで Payara Micro の設計と実装 という発表をしています。Payara Microを利用している人には有用な情報が目白押しなので、見ることをオススメします。

8年間SIerにいますが、Selenideを導入すればそれで大量の失業者が発生するとは思えないってのが自分の考えです。

ただ、新人や若手がテスト要員(≒スクショ要員?)としてプロジェクトに突っ込まれ、死んだ目をしたテスト実行エビデンス取得マッスィーンになっているのを何回も見ているので心が痛いところです。

ツイート見ると蓮沼さんもツラい経験を多くしてそうですね(´;ω;`)ブワッ… エビデンスの偽造…うっ頭が…

エビデンスの作成は面倒ですし、出来ることならスクショを撮ってExcelに貼り付けて…なんてことはやりたくは無いというのには同意です。

とはいえ、そんな簡単に撲滅できるような話ではないと考えています。

以下自分のツイート。

別のプロジェクトにいる後輩とやり取りをしているのですが、UIテストの自動テストはテストスクリプトの作成にそれなりにコストがかかります。

UIの変更が頻繁に入る場合、パッケージやサービスとして提供するので回帰テストの頻度が多い場合などはテストスクリプト作成コストを回収できる、もしくは回帰テストを行えるメリットが大きい場合などは採用を検討すれば良いと思います。

採用を検討すれば良い と書いたのは、そこには組織文化や、プロジェクトのコンテキスト、メンバーのスキルセットなど絡んでくるので、そこも含めて検討する必要があるからです。

そして、全てにおいて適用する / しない ではなく、特定のページのみ採用するメリットがあるのであれば部分的に導入するのも良いと思います。

自分がテスト戦略や計画において採用するテスティングフレームワークを決定でき、コスト度外視で採用できるならすれば良いですが、それで顧客や会社からの信用が得られるかは別の話です。

例えばUIの自動テストがコスト的に採用が難しい場合、手動でテストを行い、必要であればエビデンスとしてスクリーンショットを取得します。

その作業は単純作業でツラいものになりますが(どう感じるかは人によるでしょうが)、そういった作業は以下のようなツールを利用することでツラミを和らげてくれます。

手動テストは嫌だからUIテストを自動化する、ではなく、コストのバランスなどを見ながら自動化可能なところを自動化していけば良いのではないでしょうか。

また、そもそもエビデンスとしてスクショが必要なのかどうか顧客に確認することも大事です。 伝統的に取得しているから今回も…ではなく、本当に必要なのかどうか確認しましょう。 スクショにかかっていたコストを新機能の開発に充てられればお互い幸せになれます。

まとめ

思考停止でUIテスト自動化を する / しない の二元論で考えず、自分たちに合った手法やツールを検討・採用すれば良いと思います。 タイトルに対しての今現在の個人的な回答は、顧客がエビデンスとしてスクショを望み続ける前提で コスト度外視すれば可能だが、そんなことは有り得ないので滅びない です。

とはいえ、各ブラウザの仕様が統一されていき、Selenideのようなフレームワークがもっと洗練され導入コストが下がってくれば未来はわかりません。(全く別の素晴らしいソリューションが出てくることもあるかもしれません)

そんな未来がきたとき、死んだ目をしたテスト実行エビデンス取得マッスィーンのままだと新しい仕事に有りつけず失業してしまうので、そうならないようなスキルを身に着けておくようにしましょう。

…そんな未来が早く来ると良いですね(遠い目)