部署の全体会でLTしました!

こんにちは、情報システム部の飯田です。

昨年のAdvent Calendarで私がコロナ禍に入社してからの話を投稿していました。そこで「情報システム部の全体会でLTをしました」と書いており、少し時間が経ってしまいましたが今回はこのことについて書いていきたいと思います!

とその前に、簡単に前回以降のお話

入社から11か月が経ち、来月でいよいよ1年になります。前回は組織についてはまだ見えていない部分も多いと書いていましたが、新年会などの全体イベントがあったり他チームとの関わりが増えてきたりして、だいぶ組織に馴染めたと感じています。

ちなみに昨年末の時点では、本社への出社=チームメンバーと直接会ったのは3回だけでしたが、それが今年に入ってなんと!まだ3回のままです(笑)。あの後にまた緊急事態宣言が発令されてしまったので完全リモートワークを継続中なんですよね。ただ、近々2回ほど出社が決まっているので、久し振りの通勤を楽しみにしています。(あ、緊急事態宣言が明けたので出社勤務に戻るというわけではありません。私は引き続きリモートメインの働き方で行く予定です!)

きっかけ

それではLTの話に戻ります。私のいる新課金チームでは、主に弥生のオンラインサービスの契約に関する画面や裏でのバッチ処理の開発・運用・保守を行っています。同じチームのいっしーさんも過去に記事を書いているので興味のある方はぜひ読んでみて下さい。

私も最近は設計から保守まで幅広くやらせてもらっているのですが、その中でちょっと手間だなと思うことがあり、独自に改善策を調べたり試してみたりしていました。そしてそれをチーム会※で話してみたら思っていたよりも好評を頂けたようで、「今度の全体会で発表しようか!」という流れになったのです!

※週に数回チームで集まって、30分ほど仕事に関する共有や仕事とは関係のない雑談などをする会です。リモートワークでのコミュニケーションの場という役割もあります。

1回目:契約作成と画面キャプチャの自動化

実は上のような流れで既に2回LTを行っていまして、1回目が昨年の11月末の「契約作成と画面キャプチャの自動化」でした。

弥生にはマイポータルと呼ばれるアプリの利用や契約の管理などを行う画面があり、新課金チームではその中の一部の画面を開発しています。新課金のシステムをテストするにはマイポータルにログインして契約の作成や変更を行うのですが、これに結構な画面操作や情報入力が必要で手間となっていたのです。1件だけなら数分で終わりますが、パターンテストのために数十件作るとなるとそれだけで午前が終わってしまいます。

そこで使用したのが画面操作の自動化で有名なSeleniumです。画面のシナリオテストで使われることが多いツールですが、純粋にブラウザ操作をプログラミングすることによって任意の動作を行うことが可能です。手間のかかるアカウント登録や契約作成もボタン1つでできます。

f:id:tatsuki_iida:20210413151455p:plain
自動で作成された画面キャプチャ

もちろんシナリオテスト的な使い方も有用で、システムのデプロイ後にいつも行なっている画面やサービス起動の確認も、自動で操作して画面キャプチャ(エビデンス)まで撮ってくれます!画像ファイルがどんどん作成されていくのは見ていて楽しいです。

※SeleniumはHeadlessモードで動かしているので他の作業を邪魔することもありません。終了処理が不適切でSeleniumのプロセスが残り続けてPCが重くなったことはありますが(汗)

実際にこの後、大量のアカウントと契約が必要となるテストが行われ、作成したツールが役に立ちました!今は他のチームメンバーが汎用ツールを作成してくれたので、今後の新課金のテストはそちらを使って効率化されていくことでしょう。

2回目:アプリのデプロイ自動化

2回目は今年の2月末の「CodePipelineを用いたビルド・デプロイ自動化」でした。

f:id:tatsuki_iida:20210412150409p:plain




終わりません!!(笑)

今の新課金システムはデプロイを手作業で行っている部分があります。手順化はされているので誰でもできるようになってはいるのですが、これだけ手順が固まっているのであれば自動化したいと思うのがエンジニアです。

f:id:tatsuki_iida:20210412150202p:plain
AWS CodePipelineの画面

そこで現在考えているのがAWS Pipelineの導入です。LTでは自分で簡単なアプリを作って、それに対してボタン1つ(設定によってはこれすらも不要に!)でビルドとデプロイが完了するところを実演しました。

実際に新課金システムに導入するには、検討事項が色々あるのですぐにとは行きませんが、チームメンバーにもいいねと言ってもらえたので、これからインフラチームも巻き込んで導入に取り組んでいきます!もし導入できたらまた記事にしたいと思います。

色んな取り組みを広めていきたい!

こんな感じで私の取り組みや検討を情報システム部の全体会で発表してきました。このようなちょっとした取り組みや考えを気軽に話せる雰囲気があり、それが今回のように部署の共有に繋がって周囲から色んなフィードバックを貰うことができました。

ちなみに今回のLTもリモートで行ったのですが、私自身そんなにプレゼンに慣れているわけではないので結構緊張しました。昨年の転職活動でのリモート面接の時の緊張にも近かったでしょうか(笑)。聞き手の反応が分かりづらいのでなんとなく不安になるなど、リモートならではの難しさもあるんですよね。この辺は徐々に慣れていきたいと思います。

リモートワークで他チームやメンバーの状況が見えづらくなっている部分もありますが、これからも色んなことをやってみたいと思います。(そしてそれに触発されて他の方も発表して、このブログに投稿してもらえないかな?)それではまた!

私たちと一緒に会社を盛り上げてくれる人を募集しています! www.yayoi-kk.co.jp

JaSST'21 Tokyoに参加して、テスト技法の必要性を考察してみた

こんにちは、カトです。
2021年3月15日~16日に開催されたJaSST'21 Tokyoに参加してきました。

私が参加したセッションはこちらです。

セッション番号 タイトル
A0) オープニングセッション
A1)基調講演 Being Agile about Architecture
B2)テクノロジーセッション JSTQB AL テスト自動化エンジニア
シラバスの概要&見どころ!
F3)チュートリアル1 価値につながる要件・仕様からテストを考える
F5)チュートリアル2 JSTQB Advanced Level テストアナリストのシラバスでテストプロセスとテスト技法を学ぼう
F6)基調講演/招待講演者チュートリアル QA2AQ – Being Agile at Quality: Values, Practices, and Patterns
D8)一般公募セッション 仕様整理のためのテスト設計入門
A9)招待講演 パターンQA2AQによるアジャイル品質のマインド、体制、プロセス、技術


F5とD8で、テスト技法に関するセッションを聴講し、テスト技法の必要性を再認識しました。
そこで、「テストケースとセットで、テスト技法を残した場合とテスト技法を残さなかった場合に、どんな差が生まれるのか」をテーマにして、社内でQAエンジニア向けに共有会を実施しました。

共有内容

ワークショップで使われたカレンダーの仕様がわかりやすかったので、「カレンダーの色分け」を例に考えていきます。 f:id:yayoikato:20210329122538p:plain
カレンダーの日付を確認して、表示色が仕様通りかを確認するテストケースを作成していきます。

テストケースを作成する

今回は、テスト技法としてデシジョンテーブルを使います。

テスト技法とテストケースをセットで残した場合

f:id:yayoikato:20210329122643p:plain
これを見た人の反応はどうなるでしょうか?
きっと、テストケースを確認しやすいと感じるはずです。

テスト技法とテストケースをセットで残さなかった場合

f:id:yayoikato:20210329122707p:plain
これを見た人の反応はどうなるでしょうか?
f:id:yayoikato:20210329122732p:plain
「そんなおかしなことをするなんて、ありえない」と思いますか?
この例では、テスト対象が慣れ親しんだカレンダーで仕様も複雑ではないので、そのように思うかもしれません。
しかし、実際に業務で扱う仕様は複雑で入り組んでいるので、予定外なテストケースを追加してしまう可能性もあるのです。

翌年のケースにメンテナンスする

無事に2021年対応のテストが完了したら、2022年対応に向けてメンテナンスをしていきます。

テスト技法とテストケースをセットで残した場合

デシジョンテーブルに変更はありません。
デシジョンテーブルをみながら、テストケースを修正していきます。
f:id:yayoikato:20210329122821p:plain
はい。スムーズです。

テスト技法とテストケースをセットで残さなかった場合

f:id:yayoikato:20210329122847p:plain
混沌としてきました。

仕様追加が発生する

カレンダーの仕様としては違和感があるかもしれませんが、色分けを追加することにします。
製品・サービスの開発現場では、新規開発だけではなく、追加開発することが多いので、例題として対応してみます。
f:id:yayoikato:20210329122904p:plain

テスト技法とテストケースをセットで残した場合

水曜日の確認のため、デシジョンテーブルを更新します。
デシジョンテーブルに合わせて、テストケースも更新します。
f:id:yayoikato:20210329122923p:plain
迷うことなく、追加に対応できました。

テスト技法とテストケースをセットで残さなかった場合

f:id:yayoikato:20210326110255p:plain
翌年に変更した時点で、何をテストしたいのかわからなくなってしまっています。
何をテストしたいのかわからない状態のテストケースに対して、仕様追加に合わせたテストケースを追加することが難しくなってしまいました。

結論:テスト技法とテストケースはセットで残す

レビューイにとってのメリット:
テスト技法を成果物として残すことで、レビューイである初回の作成者の思考整理だけではなく、メンテナンス実施者にとっても迷いがなくなります。

レビューアにとってのメリット:
レビューアは、テストケース1つずつを見なくてもテスト技法を見ることでテストケースの過不足を確認できるようになります。

テスト技法を共有し受け継ぐことは、レビューイにもレビューアにも効果があります。

JaSSTに参加し、さらにJaSSTの学びを社内のQAエンジニアと共有することで、テスト技法の必要性を再認識する機会になりました。
場面にあったテスト技法を使うことは、テスト工程だけではなく、仕様検討や設計の際にも有効になる手段です。

私は、QAエンジニアが製品開発のすべての工程でテスト技法を使いながら関わっていけるチームをつくっていきます。

障害ふりかえりに向き合ってみた話

この記事は、弥生 Advent Calendar 2020 24日目のエントリーになります。

障害のふりかえりについて、私が感じていた課題と取り組んだことを書きます。

はじめに

私はいくつかのサービスについて品質保証の仕事をしています。ちょっと前までプロジェクトマネージャーを担当していました。どのような立ち位置でも、品質やテストに関して計画をし、実行をリードし、評価するということをやってきました。うまくいかないこともあるし、うまくいったこともあります。 その中で、個人的にうまくできないなとおもっていた、障害のふりかえりについて感じていた課題と取り組んだことを書きます。

なぜこれを書くか

障害が発生する、もしくはミスが起きるとふりかえりをして、次に同じことが起きないように対策を立てる、教訓にするという活動を行っているチームは多いと思います。私も、次に生かすためにふりかえりを行うことは大事、と思っています。障害が起きればふりかえりを行い、次に向けた対策を考え、次のプロジェクトでは同じことが起きないように対策を実行するということを行ってきました。

その一方で、私自身はふりかえりという活動がうまくできないなと思っていました。大きく分けると以下の2点に課題を感じていました。

  • 事実の抑えや原因をすっとばして、再発防止策を先に考えてしまう
    • 対策が先にあって都合がいい原因を選んでいるイメージ
    • 事実という土台がしっかりしてないからそこから導き出される再発防止策もふわふわしている
  • わかりやすい原因、対策を思いついたらそれ以外の発想が出ない
    • 誰かに説明をすることが決まっていると、わかりやすいに加えて、説明しやすいも加わる
    • ストーリーとしてこれだ!ってのがあると、それ以外目に入らなくなる、思いつかなくなる

 客観的に考えればできるはずでしょ、という話はありますが、私にとって、思い込み、思惑、心理的抵抗を排除して考えるということはそんなに簡単なことではありません。ましてや当事者の立場であれば、もっと難しいと思います。ということで、私がやってみたことをこれから書きます。

読んでもらいたい人

  • 障害のふりかえりをやってはいるものの、うまくいってないなと思っている人
  • 障害のふりかえりについて深く考えたことがない人

課題を整理

 はじめに、にも記載しましたが、ここで私の感じている課題を整理します。

  • 事実の抑えや原因をすっとばして、再発防止策を先に考えてしまう
    • 順を追って考えられていない
    • 次に向けた教訓を得ることを目的とするあまり、結論を急ぐ
    • 事実⇒原因⇒再発防止策の順で積み上げるべき
  • 事実の把握をおろそかにしている
    • 担当者、レビューをした人の話を聞いて、原因を考えていた
    • 現物を見れてない、記憶ベースの時もあった
  • わかりやすい原因、対策を思いついたらそれ以外の発想が出ない
    • 障害の原因となる欠陥を作りこんだ原因は1つではなく、複数の要素が絡まっていることがほとんど
    • 本来は原因が複数出てくるべきだが、ほかの原因はないか?という問いに対する答えが出てこない

やったこと

やったことは大きく分けて2つです。

  • 障害ふりかえりで考える項目を挙げた。挙げた項目について考える順番も決めた。
    • 経緯を現物で抑える
      • 混入した経緯
      • 検出できなかった経緯
      • チケットや成果物の格納場所のリンクを載せる
    • あるべき姿
    • 今のやり方の課題は?
    • 今度こう変える
  • 上記で挙げた項目をマインドマップの1つ目のノードにした。考えた内容は各ノードにぶら下げて書けるようにした。

f:id:yharuta:20201218110655p:plain
障害ふりかえりのマインドマップ

工夫したポイント

ここでのポイントは以下の3つです。

  • 考えるべき項目を挙げて、順を追って考えるようにした
    • 再発防止を先に考えない
  • 経緯を現物で抑える
    • 関わった人の話を聞く場合でも、現物をみながら経緯を追うようにする
  • 違う切り口の意見を考えやすいように、Excelなどのフォーマットではなく、マインドマップにした
    • マインドマップはExcelなどと比べて、意見をたくさん出す、というときに使いやすいと感じていたため

どうだったか

良かった点、改善が必要な点がそれぞれあります。

良かった点

  • 経緯を現物ベースでやると混入した経緯、検出できなかった経緯が腹落ちする
    • 複数人で行うときには皆が同じ経緯を認識して始めることができたので効果的だった
  • 原因や対策は決めうちにならず、いくつか意見が出た
    • 個人で考えるときにも、複数人で行うときにも、意見が出やすくなったと感じました。マインドマップの良いところが出た

改善が必要な点

  • 事実はおさえられたが、今度こうしよう!を先に考えてしまうのは変わらず
    • あるべき姿、こうすればよかったを軽く考えて、結論をいそいでしまう傾向は変わらずあった
      • 手法だけでカバーではなく、他の工夫も必要。たとえば、複数人で行うときはファシリテーションをうまく行う、一人でやるときは推敲の時間をとるといったこと

最後に

 ここまでで、障害ふりかえりについての取り組みの話は終わりになります。

 最後にもう1つ、取り組みのご紹介をします。障害の再発防止という意味では、ふりかえりして教訓を得るということも大事だけど、その教訓を忘れずに引き継いでいくという取り組みも大事であると考えます。ふりかえりした、というだけでは、次のプロジェクトの対して貢献することができないためです。 これに対する取り組みを最後に紹介します。プロジェクト開始のキックオフで、過去の障害の話をして同じことが起きないようにしようというのを伝えるという取り組みです。弥生の他のチームでは同じ取り組みをしていまして、先日行った自分のチームのキックオフでも取り入れてみました。 このように、障害が起きたらきちんとふりかえりをする、さらに、そこから得られた教訓を折に触れて思い出すこともセットでやっていくとチームに教訓が浸透していくのではないか、と思っています。まだまだ改善できる余地はあるので、今後も取り組んでいきます。

 ということで、障害ふりかえり、というややニッチなテーマではありますが、私が取り組んだことをご紹介しました。誰かの参考になればうれしいです。ここまで読んでいただきましてありがとうございました。