チームスピリットデベロッパーブログ

チームスピリット開発者のブログ

【ラットプルダウン】入社エントリを書いて徳を積んでいこうと思います。【インクラインダンベルカール】

こんにちは!私、3月にジョインしたアシスタントエンジニア(FE)渡邉です。

f:id:watanabe_wataru:20190628171014j:plain
こっちは腹筋をしているdevリーダー達と私のトレーナー!

ジョインしてしばらくたったので、入社エントリを書いていきたいと思います。

突然ですが、簡単な自己紹介から、プロフィールはこんな感じです。

■出身地: 千葉県

■趣味: DTM・音楽鑑賞

■コーディング歴: 1年

■最近ハマっていること: 朝プロテインを飲み自分は健康であると錯覚すること

■最近気をつけていること: マルチビタミンの飲み忘れ、typo

■おすすめの筋トレ: ラットプルダウン、インクラインダンベルカールでひたすら肩、上腕、背中をいじめあげること

今回は、TeamSpiritにジョインさせていただいた新米プログラマがいろいろ語っていきたいと思います。 よろしくお願いいたします!

作業環境や開発環境の話

作業環境や開発環境ですが、基本的に各個人が心地よく開発できるようになっています。作業環境に関してはエンジニア自身が作業しやすいように、キーボード等々は自分で持ってきてます。特にフロントエンドは各個人のこだわりを感じます。
開発環境についても同様で、自分でエディタ選んだり作業しやすいようにいい感じにカスタマイズしてます!
それでは作業環境や開発環境を具体的に見ていきたいと思います。

作業環境

まずは、作業環境ですがモニターが一人一台提供され、デスクは広いです!
こんな感じです。

f:id:watanabe_wataru:20190704201053j:plain
私のデスクです。汚いオブ・ザ・イヤー3年連続受賞って感じ、しますね

PDチームの部屋には昇降式スタンディングデスクがあり
立ったり座ったり出来ます。

f:id:watanabe_wataru:20190701132616j:plain
昇降式は未来なので、未来を感じながら立ったり座ったりしてます。
全然関係ないですが、写真もうちょいどうにかならなかったのか。
f:id:watanabe_wataru:20190701132430j:plain
スタンディングデスクにはこんな感じの熊さん方がお出迎えしてくれます。
くまかわいい。

f:id:watanabe_wataru:20190704192520j:plain
この未来を感じるキーボードはdevリーダー様の手作りです…!
ものすごくかっこいいですね。興奮でおかしくなりそう…ッ!

これはMk-IIなので、時間があればMk-IIIが来るそうです。 ビーム的なものが出る感じになるんですかね?是非なってほしいです。

f:id:watanabe_wataru:20190704201839j:plain
これは僕の仲間、ねこと会話することで救われるそうです。

f:id:watanabe_wataru:20190704202031p:plain
福利厚生の一環でジュースが冷蔵庫にあるときは飲んでもいいことになってます
2本飲むことによって自分が健康であると錯覚していますね。素晴らしい。

他にも大きな空気清浄機があったり、イヤホンつけて作業してよかったり
いろいろ快適な環境が整えられています。

作業環境はこんな感じです。みなさん楽しそうに作業してます。

開発環境

続いて、開発環境です!
まず、PCですがWin or Macを選択することが出来ます。
エディタやターミナルは自分の好きなものを選択できます。
私はVSCodeを使っていますが、IntelliJを使って開発しているメンバーもいます。憧れますね!
バージョン管理はgitでリポジトリはBitbucketで管理しています。

フロントエンドの開発環境としてざっくり以下の様な感じになっています。

  • パッケージマネージャ - yarn

  • JSフレームワーク - React

  • CI環境 - CircleCI

  • 型解析&構文解析 - Flow&eslint

FEの開発環境は流行り廃りや移り変わりが激しい側面があるので、今はこの環境ですが、強いライブラリが登場したら他のライブラリに移行することも検討していたりします。臨機応変に対応して強いチーム、強いプロダクトを作っていく的な感じです。筋肉的な感じです。

チーム全体に言えることなのですが、コードの品質には気をつけて開発を行っています。
フロントエンドでは、commit時にlintやflowで問題を見つけた場合はcommitできなくなっています。
エディタで動的にエラーは確認出来るのですが、人間なので気づかずにcommitしてしまう時がやっぱりあるんです、助かっています。人は弱いのです。

プルリクエストを出してコードレビューをする文化もあります。 フロントエンドのエンジニア全員で見る、というルールになっています。

ちなみに勢いでプルリクエストを作成すると

f:id:watanabe_wataru:20190704200856p:plain
こうなります。

こうならないために私は対策をしました!
marketplace.visualstudio.com

こうやって人は成長していくのです。最近typoがめっきりなくなりました。えらい!

プルリクエストのコメントは、私のレベルに合わせて書いてくださっていてとても助かります。わからない事や解決できない事は、わかるまで、解決できるまで相談に乗ってくれたり図解して説明してくれたりで、涙でディスプレイが見えません。

開発環境はこんな感じです。

まとめ

作業環境や開発環境の話をしていたら尺がべらぼうな事になってしまったので
ここらへんでおしまいにしたいと思います。

さいごに、おすすめのプロテインを紹介しておきます。

これはEAA(必須アミノ酸)配合、カロリーや脂質も抑えられていてとてもいいプロテインなんです!
Amazonだと高いのでiHerbで買うことをおすすめします! あと、なんといってもこのプロテイン、スプーンが見つけやすいんですよね!

かがくのちからってすげー!

渡邉でした!

FDL×KPT×Lean Coffeeで、スプリント振り返りのマンネリ化を防ぐ!

こんにちは。プロダクト開発チームの松田(id:a-matsuda)です。

今回は、プロダクト開発チームで行っているスプリント振り返りの様子をレポートします!

スプリント振り返りとは

そう、スプリントレトロスペクティブですね!

私たちは、アジャイル開発を実践しており、スクラムのプラクティスを取り入れています。スプリント振り返りは、スクラムのプラクティスの一つで、スクラムチームの成長やプロセスの改善を行うことを目的にしたイベントです。

アジャイル開発を実践しているチームであれば、お馴染みのイベントですよね。

スプリント振り返り、うまくいってる?

でも、このスプリント振り返り、うまくいってますか?マンネリ化していないでしょうか?

スプリントが順調に回り始めてしばらく経つと、振り返りであまり意見が出てこなかったり、場が活性化しないこともあると思います。逆に、課題について話をしていたら、なかなか振り返りが終わらず、時間がオーバーしていたなんてことも。そんな状態が続いてしまっているというチームのみなさんに朗報です!

私たちは、そんな状況を打開するために、FDL、KPT、Lean Coffeeを組み合わせた振り返りを実施しています。

FDLとは

FDLは、Fun/Done/Learnの略で、Scrum Coaches Retreat in Okinawa に集まったアジャイルコーチたちが作ったアクティビティだそうです。 やり方はとてもシンプル。Fun、Done、Learnの3つの輪を書き、チームでやったことを付箋で貼って振り返っていきます。 FDLのいいところは「Done(達成したこと)」だけでなく、「Fun(楽しさ)」や「Learn(学び)」にもフォーカスしている点だと思います。チームとして、前向きに成長を続けていくためのヒントが、たくさん出てきそうな振り返り方法です。 FDLのやり方は、下記の記事が参考になります。

qiita.com

www.ogis-ri.co.jp

KPTとは

KPTは、日本でもかなり広まっている振り返り手法ですね。Keep・Problem・Tryの3つからなるフレームワークで、続けるべきこと、抱えている問題、次にトライしたいことという軸で振り返りを進めます。 KPTの元になっているのは、Alistair Cockburn氏が「Reflection Workshop」の中で提唱した「The Keep/Try Reflection」だそうです。

Lean Coffeeとは

Lean Coffeeは、アジェンダのないミーティング方法です。詳細は、以前にブログにしていますので、ぜひチェックしてみてください!

teamspirit.hatenablog.com

3つを組み合わせた振り返りの実践!

5/24(金)に行われた、あるチームのスプリント振り返りの様子をご紹介しましょう!

流れはこんな感じです。

  1. FDLのフレームワークを使ってスプリントでやったことを振り返る
  2. FDLで出てきたことを、KPTに分類してみる
  3. チーム目標の達成度を確認する
  4. ProblemやTryについて、Lean Coffeeで議論する

1. FDLのフレームワークを使ってスプリントでやったことを振り返る

さあ、FDLのスタートです!!

FDLの輪を描く

まず、ファシリテーターを担当する開発リーダーが、ホワイトボードにFDLの輪を書いていきます。3つの輪の一部を重ねて書くのがポイントです!

f:id:teamspiritinc:20190607190638p:plain

個人ワークでじっくり2週間を振り返る

それぞれが付箋を持ち、じっくり2週間を振り返っていきます。 私たちは2週間のタイムボックスでスプリントを回していますが、2週間前のことは結構忘れていたりするものです。個人ワークでじっくりやるのがポイントです。

f:id:teamspiritinc:20190607185712p:plain

付箋を輪に貼る

付箋を書き終わったら、それぞれが輪に貼っていきます。

f:id:teamspiritinc:20190607185558p:plain

チームで輪をチェックする

続いて、チームで輪の内容を確認していきます。

今回はFDLの中心にたくさん集まっていますね!達成でき、学びになり、かつ楽しかったことがたくさんあるのは、とても素晴らしいことです。

付箋の内容を一つずつ振り返りながら、ホワイトボードの余白に、メンバー共通で挙がってきていたり、大事な内容を記載していきます。

f:id:teamspiritinc:20190607185846p:plain

2. FDLで出てきたことを、KPTに分類してみる

次に、FDLで書き出した内容を、KPTで分類していきます。Keepには「モブプロの実施」や「嵐の日はリモートワークしよう」、Problemには「情報共有の仕方」や「バックエンドとフロントエンド両方の変更があるプルリクエストの対応をどうするのか」などが挙がっていました。「モブプロの実施」の様子は、またの機会にブログ記事にしますのでお楽しみに!!

f:id:teamspiritinc:20190607194344p:plain

3. チーム目標の達成度を確認する

このチームでは以下のような目標を持っており、今回のスプリントで目標に近づくことができたかを確認していきました。

  • メンバーそれぞれが範囲を狭めず、色々なタスクができるようになる
  • より汎用的に、使いやすくなるように意識して仕様検討する
  • 計画時点でタスクが溢れないようにする

4. ProblemやTryについて、Lean Coffeeで議論する

最後に、Problemとして出てきた「情報共有の仕方」と「バックエンドとフロントエンド両方の変更があるプルリクエストの対応をどうするのか」について、Lean Coffeeで話し合いました。話し合いの時間は、1テーマなんと「7分」!

どう解決していくかを話し合い、アクションまで決めて終了しました。

なお、1テーマあたりの時間の長さは毎回調節しており、話したい話題数が多い場合は短く、話題が少ない場合は長めにとっています。 Lean Coffeeのやり方は、上でご紹介したブログを参照してくださいね。

まとめ

3つを組み合わせた振り返りに参加をして感じたことは2つです。

  • 学びや楽しさにもフォーカスすることで、チームの成長を意識した振り返りができていました。KPTでは、どうしても目の前の課題にばかり目が行き、成長や学び、楽しさなどを忘れてしまうことが多いです。

  • 時間が長くなりがちな振り返りが、時間を区切って話しやすい Lean Coffeeを採用することで、テンポよく進んでいきました。

ぜひ皆さんも、振り返りがうまくいっていなかったり、マンネリ化を感じていたら、3つを組み合わせた振り返りを実践してみてください!!

エンジニア募集♪

チームスピリットでは、アジャイルなプロダクト開発を共に推進してくれるエンジニアを募集しています。少しでも興味を持っていただいた方、ご連絡ください!(直接メッセージでも、下記の応募フォームからでも構いません)

https://www.teamspirit.com/ja-jp/recruit/r_d.html

ほろよいてっく〜令和直前!平成最後のほろよいてっく〜 参加レポート

初めまして!4月15日にフロントエンドエンジニアとしてチームスピリットにジョインしました、小熊です!

23歳で社内最年少です。よろしくお願いします!

今回は、4月25日に開催された『ほろよいてっく〜令和直前!平成最後のほろよいてっく〜』の様子をレポートします!

ほろよいてっくとは

チームスピリットではお酒を飲みながら自由なテーマでLTをする「ほろよいてっく」を定期的に開催しています。

社外の方の飛び入りLTも大歓迎です!

前回のほろよいてっくのレポートもぜひご覧ください。

teamspirit.hatenablog.com

スタート!

弊社QAエンジニアの生井さんの乾杯からほろよいてっくスタートです!

f:id:yuni3s:20190524105132j:plain

1. 「シェル芸入門」

f:id:yuni3s:20190524104959j:plain

フロントエンドエンジニアの中畑さんによるシェル芸についての話でした。

シェルでいかにしてワンライナーで問題を解くかというシェル芸!

シェルでワンライナーで問題を解くために様々なテクニックがあり、自分が思っていた世界よりとても奥の深い世界で聞き入ってしまいました。

シェル芸の問題が直接業務に役に立つことはないかもしれませんが、シェルスクリプトのスキルを楽しみながら向上できるのは良いなと思いました!

シェル芸入門 - Speaker Deck

2. Hey! Say! "2拠点×英語×ScrumQA"

f:id:yuni3s:20190524105144j:plain

弊社では日本とシンガポールの2拠点での開発を行っています!

QAエンジニアの角さんからは二拠点に分かれたチームでのスクラム、SGとの分担や情報共有、JPメンバーの英語力など様々な課題があった中、チームがどう成長してきたかという話でした。

最近ではZoomで常時ビデオ通話が繋がって別拠点チームの様子がすぐにわかるのがとても良いです!

今後2拠点開発チームがどう成長していくかとても楽しみですね!

3.Lottieを使ってみた

f:id:yuni3s:20190524105149j:plain

3月に入社したフロントエンドエンジニアの渡邊さん。

UI・UXやデザインといった分野にも興味関心があるという渡邊さんからはLottieというアニメーションライブラリについての発表でした。

Lottieで実装されたアニメーションはとてもリッチでわくわくするようなものでした!

リッチなアニメーションを軽量に、且つ気軽に実装できるのが良いですね!

4. Automation; Test

f:id:yuni3s:20190524105153j:plain

QAエンジニアの生井さんからはこれまで経験してきた自動テストの歴史や自動テストを成功させるためにはどうすれば良いかという話でした。

QAエンジニアの楽しさというのも知れたのが良かったです!

Automation; Test - Speaker Deck

5. エモいとは

f:id:yuni3s:20190524105204j:plain

バックエンドエンジニアの鶴岡さんによる「エモい」とは何なのかという話でした。

技術からは離れて「エモい」という感情を考察するというテーマはとても盛り上がりました。

普段何気なく「エモい」という言葉使っていますが、鶴岡さんの「エモいもの」=「未完成なもの」という仮説はとても納得感がありました。

6. Heroku X Confluence APIで技術検証

f:id:yuni3s:20190524105214j:plain

バックエンドエンジニアの中屋さんからはHerokuとConfluence API、そして大学図書館で司書をしていた経験を生かしてTeamSpiritのAI司書システムを作ろうというお話でした。

ConfluenceAPIでスペース内のドキュメント取得できるのでいろいろなことができそうですね。

個人的には開発資料について深く考えるという機会があまりなかったのでいい機会となりました!

7. ロゴについて語る

f:id:yuni3s:20190524105224j:plain

デザイナーの松本さんによるロゴについての話でした。

ほろよいてっくでは初のデザイナーによるLTです!

デザイナーならではのテーマで、松本さんの人柄もあり会場は盛り上がっていましたね!

個人的にはスライドが綺麗で読みやすく構成されていたのが印象的でした。さすがデザイナーです!

8. ソビエトロシアではキーボードがあなたを自作する

f:id:yuni3s:20190524105235j:plain

Devリーダーの新上さんによる自作キーボードの話でした。

MacBookのキーボードがよく故障する新上さんが自作キーボードに興味をもってから実際に作るまでの軌跡をおもしろおかしく話していただきました!

思っていたよりも敷居は高くなく、パーツは無数にあるので自分に合ったものを選ぶのが楽しそうでした。

エンジニアにとってキーボードは仕事道具なので拘りたいですよね!

個人的にもキーボードには拘りがありよくキーボードを購入するのですが、自作キーボードは考えたことがなかったのですが興味が湧きました!

まとめ

私はほろよいてっく初参加でしたが、お酒の飲みながら技術ネタの話をするのはすごく盛り上がります!

次回以降のほろよいてっくでは登壇したいですね。

社外から参加してくだっさた方々もありがとうございました!

次回は8月に開催予定です、社外からの参加&飛び入りLTも大歓迎ですので是非ご参加ください!

エンジニア募集

チームスピリットではエンジニアを募集しています。

チームに興味を持っていただいた方、ご連絡ください。(直接メッセージでも、下記の応募フォームからでも構いません)

https://www.teamspirit.com/ja-jp/recruit/r_d.html

【大腿】入社して4ヶ月、私ブログ書きます【四頭筋】

はじめまして! 1月にデザイナーとしてチームスピリットに入社しました松本です。 首が太いです。肩幅も広めです。

入社して約4ヶ月が経過したので、エントリーブログなるものを書きます。
(入社月に書いて欲しいなぁと言われたのはナイショの話)

といってもあまりブログを書いたことのない私は何を書けばいいのかわからず、気づいたら約4ヶ月経過していました。
4ヶ月も経過しちゃったので、私がチームスピリットに入社して驚いたこと、良かったことなどを中心に書いていこうと思います。

働き方について

柔軟な働き方ができます。 フレックスタイム制を導入しており、コアタイムは11:00〜16:00。
1日平均8時間労働を目安に、割と自由に時間を決め、そして調整しながら働くことができます。ステキ
また週に1度のリモートワークも推奨しています。ステキ
私はまだリモートしていませんが、いつかはかっこよく

「明日、自分リモートっす」

とかっこよくキメる日を夢見てお仕事しています。

健康面

フレックスタイム制でコアタイムが11:00〜16:00なので、混雑した電車を避けることが容易です。ステキ
前の会社では10時出社でしたが、チームスピリット では10:30〜11:00くらいに出社しているので、朝の時間に余裕が生まれ、その余裕から調子に乗って朝ごはんなんかを作っちゃったくらいにして、結局11:00ギリギリになることがほとんどです☆
ですが、朝ごはんを食べるようにしたことで、頭の回転も良くなり、以前よりパフォーマンスは上がっていると信じたいです(信じたいです)。

また、社内には筋トレ部という部活があり、週3回筋肉を痛めつけています。 自分一人で行うよりも誰かと一緒に筋トレする方が長続きしますよね。これにより肉体的にも健康になってきています(気がします)。

道具を使用して筋トレすることもできます。

f:id:yuyamatsumoto:20190426114149j:plainf:id:yuyamatsumoto:20190426114312j:plain
見よ、この腹筋ローラーとプッシュアップバー、そしてマットの数を
ただ以前、大腿四頭筋を追い込みすぎた結果、恐ろしいほどの筋肉痛に襲われ歩行することが困難になり、階段を降りることがどうあがいても絶望。という危機に陥りました。
トレーニングで筋肉を追い込み、筋繊維を破壊し、超回復をすることは筋トレにおいて重要なことではありますが、日常生活に支障が出るレベルでの筋トレはほどほどにした方がよさそうです。
大腿四頭筋は人間の体の中でも特に筋肉量が多いところです。大腿四頭筋を集中して鍛えることにより、筋肉の総量が増えるので結果的に代謝が上がりやすいと言われています(松本が勝手に言っています)

自分が所属しているチームの人たちの印象は

  • 様々な情報へのキャッチアップ力の高さ
  • プロダクトに対して熱い思いを持っている
  • しっかり意見を言い合える
  • 筋トレが好き

全部良いですね。チーム内の雰囲気もとても良いです。みなさん優秀な方なので、ついつい質問してしまいます。
ロールの壁がなく、松本満足です。

まとめ

柔軟な働きかた、健康面、そしてチームの雰囲気、4ヶ月経って感じたチームスピリットの良いところを簡単ではありますがスーパー主観でご紹介させていただきました。
ほぼ筋トレの話でしたが、私が何が言いたいかというと、鍛えるなら大腿四頭筋ということです。

まだ入社して日が浅いですが、やりたいこともたくさんあります。 まずは新しいデザインツールの導入!
すべて実現できるように、これからチームスピリットでもがいていこうと思います。

以上、松本でした。

Agile QA Night!!登壇レポート

こんにちは、QAチームの生井(id:riririusei99)です。

今回は私、生井が登壇しました、『Agile QA Night!!』のイベントをレポートします!

Agile QA Night!!とは

株式会社ビズリーチ様が開催する、「D3(ディーキューブ)」というプロジェクトチームでは、たくさんのイベントや勉強会を開催しており、今回は「Agile QA」というテーマで勉強会が開催されました。

Agileな組織が多くなっている昨今、QAはどのようにAgileに入っていくべきなのでしょうか。 今回はAgile開発に上手に入り込んでいるQAの方々をお招きし、以下のような話をしていきたいと思います。 (Connpassより)

d-cube.connpass.com

きっかけ


前回のブログで発表した内容が好評で、今回の勉強会の開催・参加が決まりました。

本当にありがとうございます。

参加レポート

さっそく発表の内容のレポートをします。

発表1:チームスピリットにおける品質保証の仕組み:リターンズ


speakerdeck.com

前回の発表の再演を依頼されていましたので内容はほぼ同じですが、AgileQAというテーマに則したように若干構成をいじっています。
また、前回の発表で話きれなかった部分などの補足などを追加しています。

発表した感想ですが、120人入る会場で登壇することは人生で初めてで非常に緊張しました。
といいつつも、社内のメンバーに向けてリハーサルを行った際盛大に失敗した発表をしていたおかげで幾分かリラックスして臨めました。
協力してくれたメンバーに感謝です。

※質疑応答の時間がとれなかったため、パネルディスカッションの質問については後述します。

発表2:伝統的な文化が根強い組織がAgileな感じにQA戦略を組み立てた


※資料は共有され次第、添付します

speakerdeck.com

次は認定スクラムマスター、認定スクラムプロダクトオーナーを所持されているacchanさんの発表です。
私も認定スクラムマスター取りに行きたい。

発表では既存の開発がいわゆる「なんちゃってスクラム開発」になっていたところに対して、

  • Heuristic Test Strategy Model
  • A new model for test strategies
  • MicroSoftによるScale Agile to Large Teams
  • QA2AQ

といった考え方をベースにしてスクラムと品質保証に取り組んでいるという内容でした。

個人的には、「開発、QAという境はなくチームがスプリント内で開発、テスト全てやる」という考え方と弊社の「QAは開発チームの1メンバーなので、スプリント内で開発・テスト全てやる」という考え方はとても近いかなぁと思いました。

参考リンク
Heuristic Test Strategy Model danashby.co.uk docs.microsoft.com www.wirfs-brock.com

発表3:Agile開発に入り込むQAの方法


3番目の発表については、開催・会場提供していただいているブロッコリーさんです。 Agile開発に入り込むQAというテーマで初めはQAの開発組織の関わり方について発表した後、モブプログラミングを開発者とテストエンジニアが行うというテーマで発表されました。

speakerdeck.com

  • 時間の経過を意識したテストケースの命名
  • テストエンジニアは指摘事項を言い切るべきか

といったテーマについては、日々の業務に直結するような内容で非常に参考になりました。

参考リンク nihonbuson.hatenadiary.jp

発表4:Agileな開発におけるテスト観点のお話(仮)


speakerdeck.com

発表の最後は「アジャイルな気持ち」と「テスト観点」について発表したなそさんの発表です。

アジャイルな現場とは居酒屋だというなそさん

  • 「スプリント:入店から退店まで」
  • 「プロダクトバックログ:伝票」
  • 「完了の定義:料理を提供し、お金を払う」

たしかにこの居酒屋に置き換えると理解が進みそう…積極的に使っていこうと思います。

さすがテストラジオを運営しているなそさん、発表が上手く、数々の名言が飛び出して来ました。

パネルディスカッション


さすがに、壇上で話していたのでここは若干、割愛。 詳しくはtwitterで「 #D3QA」で検索お願いします。 ここでは、パネルディスカッションで答えられなかった質問にいくつか答えていきます。

なまいさんのテスト計画書の具体例が見たいです。イメージを掴みたい!

すごーく簡素に書いてみました

項目 項目例 説明
品質 デモ利用可能なプロトタイプのの出荷 PM・ステークホルダーの要求を書く
リリース判定項目 優先度High以上のチケットが全て解決済み
シナリオテストの実施が完了している
実施体制 QA2名で実施
戦略 プロダクト品質のリスクを洗い出し優先順位を決めて実施する
QualityBacklog 以下に必要なタスクを計画する
(強化テスト) シナリオテスト,ユーザビリティテスト デモ利用のため性能テストは行わない
(手動テスト) テスト設計改善 上がったバグチケットを分析し、多発する観点をチェック項目に組み込む
(自動テスト) E2E基盤作成 本番機能開発に備えて基盤作成
スケジュール

以前書いた内容はこんな感じです。
teamspirit.hatenablog.com

Agileはいつも短いスプリントでの検証なので、たまに大きな検証漏れも発生する場合があり、それは解決するために何か素晴らい方法提案できるのでしょうか?

まずは大きな検証漏れがどんなものがあるか明らかにすること&合意するのが大事だと考えています。
プロダクトにおけるNever(絶対にやってはいけないこと), Must(できること),Want(できたら嬉しい)をPM・ステークホルダー・QAでそれぞれ出し合って合意しましょう。
そうすることで想定している大きな検証漏れが発生しづらくなります。 合意した内容は一度作ったら作りきりにせず、都度メンテナンスが必要です。

アジャイルでQAやっているのは楽しいですか?楽しいとしたらどのあたりが楽しいですか?

楽しいと思う瞬間はたくさんあります。個人的に思う3点を書きます。

  • 仕様作成から参画できるので自分のアイディアが反映されることがある
  • 機能実装の進め方もチームで決めるため、テストの量を(ある程度)コントロールしながら開発を進めることできる
  • チームで作ったものという意識が感じられるため、リリースのときはやっぱり嬉しい

開発者がQAが行うテストを日常的に行う(手伝う)ことってありますか?

実装するメンバーもQAも等しく開発チームの一員なので手伝う・モブテストやることはよくあります!

おわりに


組織の状態によってスクラム開発におけるQAエンジニアの働き方は違うのだなぁと感じました。
その上で、組織が成長することで自分たちの組織の中でも品質保証のやり方を変化させていかないといけない未来が見えてきました。
特に開発メンバーのテスト支援という部分で挑戦できる部分がたくさんあることがわかったので今後は、そういった部分でも注力したいと考えています。

f:id:riririusei99:20190315155130p:plain
発表の様子

We're Hiring!!


チームスピリットではQAエンジニア/開発エンジニアを絶賛募集しています!! 興味をもった方、詳しく話を聞いてみたい方は、以下のリンクからお問い合わせください!

www.teamspirit.co.jp

以上、登壇レポートでした。

"サービス品質向上しナイト ~みんなでテスト!10年続くチームと品質~" 参加レポート

こんにちは!
みなさん、品質もりもりあげていますか?(謎

チームスピリットデベロッパーブログ初登場のQAエンジニア角(id:naomi-s)です。

今回は弊社シニアQAエンジニアの生井(id:riririusei99)が登壇した、
『サービス品質向上しナイト ~みんなでテスト!10年続くチームと品質~』のイベントをレポートします!

サービス品質向上しナイト ~みんなでテスト!10年続くチームと品質~とは?

株式会社ウィルゲート様がいろんなテーマでエンジニアのための勉強会・イベント『Hacker's GATE』を開催されており、 今回は”品質”をテーマに、「組織」として品質向上に取り組む 3 社の発表とパネルディスカッションをする、というものでした。

小さなチームのうちは「個」の力で賄えていたソフトウェアの品質担保のプロセスが、組織の拡大に伴って属人化していしまい均一ではなくなってきた……そんな悩み、あると思います。

今回のイベントでは「組織」として品質向上に取り組む 3 社に発表・パネルディスカッションをしていただきます!(Conpassより)

f:id:naomi-s:20190215014311j:plain
弊社で開催され、開始時点で会場は熱気に包まれていました!

1.ウエディングメディアを支えるQAチームの取り組み

トップバッターは株式会社ウエディングパークの 斉藤 健太さんです。
斉藤さんは同社にエンジニアとしてジョインされたあとQA部門を立ち上げ、現在はエンジニアマネージャ兼QAマネージャをされているということでした。

f:id:naomi-s:20190215015329j:plain
ハートの公式キャラクターがかわいい♡

同社のQAチーム立ち上げ前には、

  1. サービス拡大による不具合の増加 
  2. ナレッジが蓄積できない 
  3. 改善しなければいけない危機感 

という開発の課題があったそうです。 この中で今回は1の課題への取り組みについてお話いただきました。

サービスが拡大するにつれ機能の増加や仕様の複雑化が進むことで、メンバーの「機能の把握度」や「仕様の理解度」が開発品質を大きく左右する状況となったため、 サービス仕様理解を深めることが大切!と様々なアクションを実施されたそうですが、そのひとつがなんと仕様の理解度を計測するための筆記テスト!それも役員まで含めた全社員に行っているとおっしゃっていました。

工夫ポイントとしては、筆記テストにすることで仕様の理解度を定量的に把握できるようにしただけでなく、障害分析に基づいて問題を作成することで社員の納得感が生まれるようにしたそうです。その結果、仕様や影響範囲を知っておかなければいけないという危機感がメンバーにうまれ、開発・テスト時の影響範囲漏れが減少した効果があったとか。

このような開発の課題に対する様々な施策の結果、最終的な成果はなんと障害発生率が(障害件数の減少により)前年度の半分に減ったのこと!すごい! (これには参加者の皆さんからも、おお!という声がもれていました)

speakerdeck.com

2.品質向上に向けた組織改革と成功失敗例

続いては、今回のイベントを企画された株式会社ウィルゲートの鶴飼 吉行さん。 執行役員 兼 開発グループ ゼネラルマネージャー 兼 開発グループ ソリューションユニット マネージャーの鶴飼さんが、同社の品質向上のための組織改革についてご説明くださいました。

f:id:naomi-s:20190215023753j:plain
熱く語る鶴飼さん

同社は2つの事業に対して3プロダクトがありそれぞれの事業フェーズが異なることから、求められるプロダクト品質が異なるという状況の中で、 開発チームとしての課題としては大きく以下の3つがあったそうです。

  1. エンジニアのキャリアパスがない
  2. 組織としてナレッジを蓄積する場所がない
  3. 品質という言葉でくくってはいけない問題(品質ってなに?という状況)

これらの課題のうち手として、事業部と紐付かない横断的組織である開発本部を発足させたとのこと。

その結果、開発本部発足1年後には新技術の導入による開発の生産性の向上・エンジニアのキャリアが多様化し、成果としては障害件数が1/3にまで減少したそうです。
一方で、事業フェーズの違いやピンポイントすぎるものなどの理由で横展開出来なかった、上長が組織ラインとセクションラインで2重になり意思決定が割れた、などの失敗もあったということでした。

このような経緯を踏まえ昨年は

  • 開発側から研究開発の提案実行
  • 他事業部との共同R&D
  • バグが混入しづらい仕組みづくり(アーキテクチャを刷新)
  • 技術の見える化(スキルマップと評価を策定し、見える化した)

などに取り組まれたとのことでした。

まとめとしては、品質向上に向け組織改革を進めるには『まず自社が求めていることとエンジニアができることを明確化すること』、つまり事業フェーズにあわせて品質というものを分解することが必要、そしてその後に事業に対してコミットできるようにする必要があるということでした。

speakerdeck.com

3.チームスピリットにおける品質保証の仕組み

最後の事例は弊社の生井から、チームスピリットにおける品質保証の仕組みについての発表でした。

f:id:naomi-s:20190215134943j:plain
TeamSpiritのTシャツ&パーカー&TSIカラーのスニーカーという勝負服で登壇!

まずは、チームスピリットが目指す未来のQA組織の説明から。 大きく『継続性・再現性』と『適応』の2つを達成したいということでした。 一見相反するようなこれら2つはそれぞれ、

  • 継続性・再現性:サービス開発に終わりはない。全体感を意識した仕組みを作る(属人化させない)←ルール・戦術
  • 適応:チームの変化や適応できる余力をもつ←得意な分野で勝負する

ということを意味しており決して相反するものではなく、チームとしてベースとなるルールや戦術を共有しつつ、品質向上のために個々人の得意な分野を活かすという在り方を提案していました。

その後、現在のチームスピリットのスクラムの特徴について説明を行いつつ、スクラム×QAについて熱く語りました。 様々な工夫などの紹介が、多くの方の気づきにつながることができたようです。

speakerdeck.com

パネルディスカッション

休憩を挟んで行われた登壇者3名によるパネルディスカッション。 事前に参加者アンケートから選ばれた質問を登壇者に回答していただきました。

その前に、このイベントの参加者の属性を簡単に調査すると、

  • エンジニア:約半数
  • QAエンジニア:約1/3
  • PM:1割程度
  • その他:数名

そして、自社にQAチームがある方はおよそ半数でした。想像より少なかったので、開発エンジニアの兼務もしくはこれから立ち上げを検討している方々が多かったのでしょうか。

f:id:naomi-s:20190215210428j:plain
皆さんの質問を真剣にきいてます

いくつかの質問に真剣に回答、ときにはパネラーからパネラーへ質問するというシーンもありました(笑)

イベント終了後は生井の乾杯のかけ声で懇親会も開かれ、ピザをつまみつつ皆さん交流を楽しんでいました。 生井に多くの方が声をかけてくださり、様々な話ができたようです。 f:id:naomi-s:20190215210819j:plain

イベント後の様子

イベント後は全パワーを使い切っていた生井。 翌日に感想を聞いてみました。

『チームスピリットのQAチームはスクラムに寄り添って活動していることを紹介できたと思います。
沢山の人に興味を持っていただけたので、今後も発信できればと思います。
発表については社内でのリハーサル・当日の運営などたくさんの協力がありました。
結果として、喜んでもらえる勉強会になったので会社のメンバー・運営の方には感謝でいっぱいです。』

f:id:naomi-s:20190218110627j:plain
開催中のヒトコマ

We're Hiring!!

チームスピリットではQAエンジニアを絶賛!募集しています!!
興味をもった方、もっと詳しく話を聞いてみたい方は、ぜひ以下のリンクからお問い合わせください! 一緒に品質をもりもり上げていきましょう!!!

www.teamspirit.co.jp

Salesforce コミュニティ合同イベント「Japan Dreamin' 2019 」に参加してきた

こんにちは、プロダクトディベロップメントチームの倉谷(id:a-kura)です。

Salesforce コミュニティ合同イベント「Japan Dreamin' 2019」が2019年1月26日(土)に開催、「繋ぐ」をキーワードに日本全国のコミュニティが大集結しました。簡単ですが、参加レポートを書かせてもらいました。

www.trailblazers.jp

Dreamin' とは

Dreamin' とは、全世界で開催されている Salesforce の Community Conferences になります。大きなイベントでは企業スポンサーをつけて2日間開催する、など活発に活動しています。

Japan Dreamin'

今回は、その Dreamin' を日本で開催しました。公式の紹介はこちらです。

「繋ぐ」をキーワードに全国のコミュニティが大集結!!

User、Admin、Developer、自身の壁を少し超える事で繋がりができ、お互いの理解が深まり、より一体感を持てることができるかと思います。

地域、会社をも跨いで繋がって行きましょう!!!

続きを読む