SageMaker ProcessingJobのCLIからのジョブ管理方法

AWS

TL;DR

こんにちは。弥生R&D室の飯田です。R&D室ではSageMakerを使用して機械学習 (ML) のプロジェクトを進めていますが、SageMakerにはProcessingJobというサービスがあり、モデル訓練のような重い処理に適しているため大変便利です。

しかし計算用インスタンス上で実行しているプロセスの管理には直接 ps や kill を使うことができず、独自のコマンドが必要となるため、よく使うものをこの記事で紹介したいと思います。

実行環境

AWS CLI が動作する環境、および利用するSageMakerのドメインに対応したアクセスキーの設定が必要です。

コマンド集

現在動いているジョブを確認する

ローカルにおける ps に相当するコマンドです。非常によく使います。

aws sagemaker list-processing-jobs --status-equals InProgress

https://docs.aws.amazon.com/cli/latest/reference/sagemaker/list-processing-jobs.html#list-processing-jobs

ジョブを作成する

ジョブを作成するためのコマンドです。

実は list-processing-jobs と違い、こちらを使うことは少ないです。

オプションの変数が多すぎるためコマンドラインやシェルスクリプトで管理するのが割と大変で、Pythonラッパーを使って書く方が便利であり、個人としてはそちらをよく使います。

一応、この記事だけでジョブの監視・作成・削除を一通りこなせるようにするために記載します。

aws create-processing-job \
  --processing-job-name $JOB_NAME \
  --processing-resources $RESOURCES \
  --app-specification $APP_SPEC \
  --role-arn $ROLE_ARN

https://docs.aws.amazon.com/cli/latest/reference/sagemaker/create-processing-job.html#create-processing-job

不要なジョブを削除する

ローカルにおける kill に相当するコマンドです。こちらも list-processing-jobs との組み合わせでよく使います。

aws sagemaker stop-processing-job --processing-job-name $JOB_NAME

https://docs.aws.amazon.com/cli/latest/reference/sagemaker/stop-processing-job.html#stop-processing-job

まとめ

  • ジョブの確認には list-processing-jobs が便利です
  • ジョブを作るには Pythonラッパー がおすすめです
  • 不要なジョブが生きてたら stop-processing-job でお掃除しましょう

本記事は下記の記事と同じ内容です。 アクセス解析を目的としてマルチポストしています。

qiita.com

また弥生では一緒に働く仲間を募集しています。 ぜひエントリーお待ちしております。

herp.careers

Pythonで扱うS3のパスをs3pathlibでイケてる記述にする

Python AWS

こんにちは。R&D室のsiidaです。R&D室ではストレージとしてS3を使用し、分析環境としてSageMakerを使用しています。そのためPythonからS3を使用することが多いのですが、今回はその際に便利な s3pathlib についてご紹介します。

TL;DR

PythonでS3のファイルパスを扱う場合には s3pathlib が便利です。組み込みモジュールの pathlib では s3:// から始まるS3のパスをパースすることができませんが s3pathlib なら pathlib と同じように扱うことができます。

from pathlib import Path
from s3pathlib import S3Path

local_dir = Path("./my_dir")
s3_dir = S3Path("s3://my_bucket/my_dir")

if local_dir.exists():
    print(f"ローカルのディレクトリ {local_dir} は既に存在します。")

if s3_dir.exists():
    print(f"S3上のディレクトリ {s3_dir} は既に存在します。")

私は s3pathlib を知る前は str 型でS3上のパスを処理していたのですが、 str 型でパスを記述することは型の安全性の観点から推奨されませんし、上記の exists() や joinpath() , parent といった pathlib で実装されている機能を代替するのに手間がかかることからフラストレーションを感じていました。

そんな悩みも s3pathlib で解決です。

s3pathlib.readthedocs.io

続きを読む

弥生で第22回Quesを開催してよかったこと

QA

こんにちは、かとあず（@kato_az）です。弥生でQAエンジニアをしています。

第22回Quesから1か月以上が経ちました。

数多の技術イベント、日々たくさんこなしていくタスクに追われて、1か月前の第22回Quesの記憶が薄れてきてしまっている人もいるかもしれません。
ques.connpass.com 改めて、第22回Quesを弥生で開催してよかったと感じているエピソードをまとめてみます。

よかった点は3点です。

  1. 弥生のメンバーに勉強会参加の機会を作ることができた
  2. 弥生の勉強会や全社イベントの運営メンバーにハイブリッド開催イベントを見てもらう機会ができた
  3. 弥生にQAエンジニアがいること、弥生で内製開発していることを知ってもらう機会ができた

それぞれについて書いていきます。

よかったこと

1. 弥生のメンバーに勉強会参加の機会を作ることができた

私自身はconnpassで開催しているイベント、ソフトウェアテストシンポジウムJaSST、スクラムフェスに参加をしています。
他のメンバーも自分の業務領域に関する勉強会に参加したり、書籍を読んだりといった自己研鑽をしています。
しかし、それぞれの学びの情報がうまく社内で共有できていません。このため、Quesに関しても他のイベントに関しても、「知る人ぞ知る」という状態になってしまっていました。
イベント情報をSlack等社内のたくさんの人が見れるツールで情報共有するという方法もありますが、たくさんのイベントをすべて流すと情報過多になりますし、一部を共有するにしてもどのような基準で共有するのかしないのかを決め切れていません。このため、共有したイベント情報を見ることで参加したいと思う人に届けるということができていません。

オンサイトでのイベントは現地での空気感を知ったり交流ができたりしてたのしいのですが、社外で開催するイベントに誘うには相手の住んでいる場所やライフスタイルを把握できていなくてハードルが高いこともあります。
また、自分の業務領域であれば参加しやすいですが、あまり知らない分野の勉強会だと、急に問いかけられたり難しい質問をされたりしないかと不安になって参加を見送ってしまうこともあります。
オンラインイベントでも「きっと面白いから見ておいて」とだけオススメしあっても、どのような学びがあるのか伝えられず、参加につながらないこともあります。

今回弥生の本社でQuesを開催したことで、「弥生でやるなら」と現地で参加をするメンバーが何人かいました。
フルリモートワークをしている各地のメンバーは業務後のイベントに参加のために東京に来ることが難しいので、オンラインで参加をしていました。
QAエンジニアはもちろん、エンジニア、プロジェクトマネージャー、スクラムマスターなど、職種によらず、Quesに参加をしてもらうことができました。
その中で、プロジェクトマネージャー1人、エンジニア2人が参加ブログを書いて、学びを共有しました。
▼プロジェクトマネージャー シダさんの記事▼
tech-blog.yayoi-kk.co.jp ▼エンジニア Oさんの記事▼
tech-blog.yayoi-kk.co.jp ▼エンジニア ウエタケさんの記事▼
tech-blog.yayoi-kk.co.jp ブログを通してメンバーの人となりを知ることができたり、コミュニケーションのきっかけを作ることができたりしました。
「交流しましょう」「一緒の会社の仲間で仲良くしましょう」だけではない技術を通したコミュニケーションは、日々の業務効率化の一助や成長のきっかけにもなりそうです。

今回の参加でQAエンジニアの業務に興味を持ったメンバーもいますし、次回のQuesにも参加してみたいという感想をもったメンバーもいます。

次回の開催場所はまだ決まっていないようですが、おそらく弥生以外の場所で開催します。
一度Quesに参加したメンバーにはQuesの雰囲気が伝わったので、次回開催の際に誘いやすくなりました。
一緒に現地にいって参加してもよいですし、各自がオンライン参加で申し込んで、弥生オフィスでサテライト会場のように大きなスクリーンやモニターでみんなで見ながらわいわいするのもたのしそうです。
弥生でQuesを開催したことをきっかけに、この学びの輪を広げていきたいと考えています。

2. 弥生の勉強会や全社イベントの運営メンバーにハイブリッド開催イベントを見てもらう機会ができた

弥生では、もくテクという名前の勉強会を開催しています。2020年1月まではイベントスペースを使って開催をしていました。
Misocaチームが主催した何回かのもくテクはオンサイトとオンラインのハイブリッド開催をしていましたが、もくテクのほとんどがオンサイト会場のみでの開催でした。
オンサイト会場のみでもくテクを開催していた当時は、今のオフィスより場所が広く執務室とは別にイベント開催が可能なフロアがあったこと、社内でのルールがあまり定まっていなかったことから、受付の仕組みもきちんとしていない状態で開催していました。

現在のオフィスになってからは、執務室内で50人以上集まるイベントの開催経験やハイブリッド開催イベントの開催経験がなく、ノウハウは全くありません。
ですが今後、オンサイト会場でのもくテク開催や、社員が集まるイベントを開催していく計画が全くないわけではありません。
すでにハイブリッドイベントはたくさん開催され、今後開催を検討していく弥生は"後発組"となります。
後発組は、参加していただくみなさまの「当たり前品質」の基準が上がってしまっている中でイベント開催をしなければなりません。主催としては初めての開催になるにもかかわらず参加いただくみなさんに満足していただくハードルがあがってしまっているという難しさがあります。一方で、"先発組"のノウハウを得て開催できるというメリットもあります。
Quesは年2回イベントを開催し、オンサイト・オンライン合わせて200人以上集まる人気イベントですし、ハイブリッド開催のノウハウをたくさん持っています。
実際、弥生では準備できなかったマイクをはじめとする機材を持ち込んでいただき、スムーズに画面を切り替えながら会が進行されていました。
声を張り上げなくても会場のみなさまに声を届けることができ、オンライン参加のみなさまにも見やすい資料や聞こえやすい音量をお届けできていました。

今回Quesを弥生のオフィスで開催したことは、もくテクをはじめとするイベントを弥生のオフィスで開催する予定の人たちにとってたくさんの学ぶチャンスでした。
もくテク運営チームには、「会の内容はわからなくてもよいし、手伝い要員としてでもよいから、ぜひ現地に来て参加してほしい」とお伝えし、参加をしてもらうことができました。
参加人数が多いオンサイトイベントや、オンサイトとオンラインのハイブリッドイベントをする際に必要となる機材の購入を検討したり、会場設営の準備をしたりする際のノウハウを得られる機会になったことと思います。

第22回Quesとあわせたキラキラもくにゃんと、お話しするもくにゃん

3. 弥生にQAエンジニアがいること、弥生で内製開発していることを知ってもらう機会ができた

ここまでの2点については、イベントを開催したことによる弥生の中でのよいことをお伝えしてきました。
3点目は、弥生以外のみなさまに弥生のことを知ってもらえたということです。

「就職活動や転職活動をするまで弥生を知らなかった」という人もいますし、「弥生という会計ソフトを販売している会社があることは知っていたが内製開発していることを知らなかった」という人もいます。
カジュアル面談をはじめとする採用に関わっていると「弥生は社名や社歴から、もっとお堅い会社かと思った」というお話しを聞いたことがあります。最近入社したメンバーから「思っていたより自由で働きやすい」という感想を聞いたこともあります。

弥生のこと、弥生の魅力が知られていないということを痛感する意見です。

今回Quesを弥生で開催し協賛として会社名を連ねました。当日は5分間の会社紹介をさせてもらいました。たった5分で弥生をみなさまに知っていただくきっかけを作ることができました。

QAエンジニア以外でQuesに縁がない人、時間の都合でQuesには参加できない人もたくさんいらっしゃると思います。
弥生開発者ブログにて、開催前と開催後に記事を書くことで、Quesに興味がある人以外にも弥生のことをお伝えする機会を作ることができました。
▼Ques開催告知ブログ▼ tech-blog.yayoi-kk.co.jp ▼Ques開催後ブログ▼ tech-blog.yayoi-kk.co.jp ブログをとおしてQuesのことや弥生のことを知ったという人もいらっしゃることと思います。
また、弥生株式会社エンジニア情報X（旧Twitter）でも情報発信をしました。

弥生のエンジニアの活動を知ってもらうきっかけにもなったかと思います。

おわりに

第22回Quesを弥生オフィスで開催したことでのデメリットは1つもなく、本当に良いことづくめでした。
Ques事務局のみなさま、パネルディスカッションで学びの多いお話しをしてくださった湯本さん 河野さん、本当にありがとうございました。

Ques事務局はイベント開催できる場所のある企業を毎回探しているとのことなので、「自社でイベントできる」という方がいらっしゃったら、ぜひQues事務局へコンタクトをとってみてください。
Quesの中の人のX（旧Twitter）アカウント：https://x.com/Ques_staff

第23回Quesは2024年11月開催予定とのことです。チーム弥生で参加したいと考えています。
ぜひ次回のQuesでお会いしましょう。

第22回Quesは、YouTubeにてアーカイブ公開されています。「第22回Quesの開催を知らなかった」という方も、もう一度内容を見たいという方も、ぜひご覧ください。

youtu.be



弥生では、一緒に働く仲間を募集しています。 herp.careers

Scrum Fest Niigata 2024 現地参加してきました-発表チャレンジ編-

QA

こんにちは、かとあず（@kato_az）です。弥生でQAエンジニアをしています。
5月10～11日に開催された、Scrum Fest Niigata 2024 に現地新潟で参加しました。

快晴の新潟の空とWhat’s NiiGATA モニュメント

前回、参加したセッションでの学びを書きました。 tech-blog.yayoi-kk.co.jp 今回は、発表にチャレンジについてです。

プロポーザル書いてみた！

書いてみないことには始まらない

私がスクラムフェスの存在を知ったのは、1年前2023年のScrum Fest Osaka 2023です。
弥生でスクラムマスターをやっている たろけん がプロポーザルを書くと発言したのが、一番はじめです。
この話をきいたとき、実は「スクラムフェス」も「プロポーザル」も何かわからないまま「がんばって」と言っていました。
その後、プロポーザルが「三河トラック」で採択されて発表をするということで、応援を兼ねて参加をしてみることにしました。

Scrum Fest Osaka 2023 たろけん 発表資料
speakerdeck.com
Scrum Fest Osaka 2023 たろけん 発表Youtubeアーカイブ
スクラムを通じてアジャイル開発の良さに気づいたPMのはなし ～だが、情熱はある～ - YouTube

Scrum Fest Osaka 2023では同時並行でたくさんの発表がありました。
地名のトラック名が何を意味しているのかすら解っていない状態で参加していましたが、みんな楽しそうだし、私もこの仲間になっていきたいなと感じました。

Scrum Fest Osaka 2023から半年ほどが過ぎ、私は2023年の年末にJaSST'23Tokai 2ndでLTをしました。
LT前に告知ブログ書きました。⇒ JaSST'23 2nd TokaiでLT登壇します - 弥生開発者ブログ
 LTを聞いていただいた方からスクラムフェスでも話してみたらどうかというお話しをいただき、自分でもチャレンジできるかもしれないと、2024年2月に開催されたWomen in Agileにプロポーザルを出してみました。
これが私のはじめてのプロポーザル作成でした。

Women in Agileの次の週に2024年にQAに関するイベントに現地参加しました。
イベントの場でScrum Fest Niigata 2024はQAに関する内容が多いイベントだからQAエンジニアにプロポーザルを書いてほしいと思っているというお話しを伺いました。
そこで、Scrum Fest Niigata 2024に向けてプロポーザルを書いてみることにしました。

スクラムフェスを知ってから1年の間に、私は2回プロポーザルを出しました。

書いても始まらなかった

はじめてプロポーザルを書いたのは、2024年2月に開催されたWomen in Agile。
「書き始めたらきっとどうにかなるだろう」と思ってプロポーザル投稿画面を開いたのですが、「どの項目に何を書くの？というかどうすればいいの？」という状態になってしまいました。完全なる事前調査不足。
過去のプロポーザルをいくつか見ましたが、「決まり」のようなものはないように見えてしまいます。
話せる内容についての経験がこれから増えることはないので、テーマはある程度決まっています。ひとまず、項目を埋めてみましょう。
なんだか物足りないような、いいたいことが言えていないような気がしますが、下書きで熟成させても発酵してよい味を出すようにも思えないので、そのまま確定をしました。

2回目は、2024年5月に開催されたScrum Fest Niigata 2024に向けての作成です。
初回の経験でプロポーザルが自力で書けないことはなんとなく気づいています。
それでも書いてみないことには指摘をもらうこともできません。さっそく「QAエンジニアがスクラムマスターを兼任したこと」をテーマに書き始めてみました。
やっぱり「どの項目に何を書くの？」から抜け出せません。

レビューしていただいた

Women in Agileのプロポーザルは「書きっぱなし」のまま投稿して終わってしまいましたが、もう一歩どうにかしたい気持ちになってきました。
何の前触れもなく たろけん に「プロポーザル書いてみた」とリンクを送ってみたところ「こんな話を入れたらよさそう」というアドバイスをもらったり、Women in Agileを通して知り合った人と一緒に構成を練り直したりしました。
自分ひとりでは、項目を埋めることだけで終わってしまいましたが、レビューをしてもらうことで少しずつ書き方に対する理解が進んできました。
「無名の人が何も書いていないとどんな発表になるのかわからないから採択のしようがない。出し惜しみせず全部書く。」というのは非常に納得感のあるアドバイスでした。
「ネタバレになったり、当日プロポーザルをなぞっただけの発表だと面白みがないのでは？」と思ったりしましたが、それはプロポーザルをしっかり書けるようになってからの段階です。
あせらず一つずつステップを登っていくことにします。

結果的に、Women in Agileに続きScrum Fest Niigata 2024でもプロポーザルは採択に至りませんでした。
「例えば、常夏の国でダウンコートは売れない。どんなに質のよいプロポーザルだったとしても、採択されるかどうかはその時次第。だから採択に至らなくても落ち込む必要はない。」と言ってもらいましたが、常夏の国でも極寒の国でも、"ボロ雑巾"は売れ残ります。
私のプロポーザルは、今回のテーマに合わなかったのではなく、他の人に伝えるべき経験ができていなかったり、伝えたいことがうまく書けなかったりしています。

採択された発表について、プロポーザルの内容と発表や発表資料を見比べてみました。
どれも聞く前に内容の方向性がわかりますが、事前の情報をなぞっただけの発表というわけでもありません。プロポーザルで詳しく聞いてみたいと思うことが発表で具体化されていて、聞いてよかったと感じる発表でした。

チャンスが巡ってきた！

ありがたい、初心者枠

Scrum Fest Niigata 2024でもプロポーザルは採択に至らなかったので、現地参加者として思いっきり楽しもうと思っていたところ、「Scrum Fest Niigata 2024のWomen in Agileセッションでお話ししませんか？」と声をかけていただきました。
発表は10分。
20分や45分の1セッションは発表経験がないのでどうやって話を組み立てたらよいか難しく感じていましたが、10分であればチャレンジが出来そうです。
私はスクラムチームのQAでの経験で仕事の取組みが変わってきたことを話すことにしました。
tech-blog.yayoi-kk.co.jp 張り切ってプロポーザル風にまとめてレビューをしていただきました。
「10分の発表にしてはボリュームが多い」「言いたいことが散らばっていてつながりがない」といったレビュー指摘をうけ、大幅に修正をしながら準備を進めました。
悪いところだけではなく、「こういうことが言いたい？とするとこの辺を膨らませるとよさそう」と言ったアドバイスも大変役に立ちました。
私はLTをする中で「発表資料を作るときに最初からパワーポイント等の資料作成ツールを開かない。まずは準備をする。」というのを経験から学んでいます。
今回、発表の準備をするにあたり「プロポーザルを書くからと言って最初からプロポーザル投稿画面を開くのではない。まずは準備をする。」ということを学びました。

いざ発表

弥生が主催するもくテクでは、現地で発表経験がありますが、これはいわばホーム。
知っているメンバーが多く参加されていて、温かい雰囲気を作ってくれている場での発表です。
質疑で詰まっても他のメンバーがフォローしてくれることもたくさんあります。
今回、Scrum Fest Niigata 2024の発表は、知らない場所で初めてお会いする人が多い場所での発表です。
Scrum Festは初参加の人にもやさしくて、決してアウェイな雰囲気というわけではないですが、「この人は何者なんだろう？」と思われているような気になります。
準備した内容を超えることはできませんが、準備した分はしっかりできたと思います。
Scrum Fest Niigata 2024 発表資料
speakerdeck.com
Scrum Fest Niigata 2024 発表Youtubeアーカイブ
Women in Agile 「New Voices」 : 新たな声、新たな視点 - スピーカー未経験の女性たちが語るアジャイル - YouTube

現地で発表して気づいたのは、まったく緊張しなかったということです。
活舌がよくないとか、笑顔がないとか、ふりかえることはありますが、それは緊張のせいではなく、普段からのことです。毎日のふるまいが発表にも出るのだなと気づいたので普段の生活から気をつけていかなければいけないなと思っています。

今後

初心者枠は何度も使えるチャンスではないですし、いろんな人に初登壇を経験してほしいと思っています。
私は、これから納得できるプロポーザルを書けるように、そしていつか採択していただけるように、日々の業務を通していろんなチャレンジをしていきます。


弥生では、一緒に働く仲間を募集しています。 herp.careers

Quesに参加しました！―チームでのイベント参加がもたらす相互理解―

QA

はじめに

こんにちは、エンジニアのウエタケです。 先日開催されたQAエンジニア向けイベント『Ques』に参加しました。

ques.connpass.com

イベントの後日、チームのQAエンジニアと話してみたら想像以上に収穫があったので
その学びを共有したいと思います！

参加のきっかけ

同じチームのQAエンジニアから"弥生のオフィスでこんなイベントやるよ"と教えてもらったのが参加のきっかけでした。

自身は開発エンジニアなので、QA専門イベントだと内容ついていけるかな？とも思いましたが、今回自社のオフィスが会場とのことで "オフライン開催の雰囲気を見てみよう"という軽い気持ちで参加することにしました。

後日話すことになった経緯

イベントの中でQAエンジニアの役割や現状について話がありました。
イベントの内容を聞いて"こういうことかな？"という一定の理解はしたものの、私自身はQAエンジニアの経験がなく、もう少し具体的に理解を深めたいと思いました。

同じチームのQAエンジニアもイベントに参加していたので、"具体的にイメージできなかったことがあるので話したい"とお願いしたところ、快く受けてくれました。

チームのQAエンジニアと話したこと

作業範囲が広く大変？

イベントの中で、

「QAの役割=テスト」ではない。要件検討や開発チームの作業、CS部門の作業にも入り込んでいくことで、品質を管理する方法もある。

といった話がありました。

自身のチームのQAエンジニアはテスト以外の役割も担っており、作業範囲が広いため結構負荷が高くて大変なのでは？という点が気になりました。

QAエンジニアの回答：

  • 作業範囲が広いことで大変なのは事実。ただ、メリットも大きい
  • 要件検討の最初から参加しているほうが要件や仕様の理解が進むので、テスト設計もしやすい。早い段階から品質を作り込める
  • テストの段階で要件の検討不足が見つかり、テスト設計もやり直して..となると、結果として作業負荷が上がってしまう

品質を管理するためには大事だと思いつつ、"作業負荷が高く大変そう"と思っていたため、
QAエンジニアとしての業務自体もやりやすくなる、という点は意外でした。

プロダクトだけではなく人も見るってどういうこと？

QAエンジニアは、プロダクトだけではなく人も見ることが大事。

という話がありました。 "出来上がったプロダクトだけでなくプロセスも見る"という理解はしたものの、具体的にはどういうポイントを見ているのか気になりました。

QAエンジニアの回答：

  • チームの状況をみることで、例えば「ここは急いで作っていたな」とか「途中で要件が変わったな」という"品質の穴"になりそうな箇所が分かりやすくなる
  • 日々の会話などから、どこを注意してテストしたらよいか、といった観点が拾えることもある
  • 開発チームと作業場所が同じかどうか、というのも意外と大事

日々の作業や会話の中からテスト設計に活きる情報がある、という点が新たな発見でした。QAエンジニアが開発チームと別の作業場所になるケースもありますが、それだけでも情報を拾いづらいとのことでした。

自身は開発エンジニアなので、基本的には開発チームのメンバと別の作業場所になることはありません。そのため、役割の違いがあることでそういった苦労がある、という点は想像できていませんでした。

スクラム開発とウォーターフォール開発の違いってある？

私の所属チームはスクラム開発を行っています。QAエンジニアの業務に関して、スクラム開発とウォーターフォール開発の違いが気になりました。
"短い期間でテスト設計、テスト実施を回さなくてはいけない"という点が一番の違いではないかと考えていたのですが、聞いてみるとそれだけではないとのことでした。

QAエンジニアの回答：

  • スプリント単位で機能が出来上がってくるので、傾向分析する材料が少ない
  • ウォーターフォール開発の場合は出来上がる機能の単位が大きいため欠陥の偏在を分析しやすいが、スプリント開発では出来上がる機能が小さいため品質分析のやり方が変わる

ここは自分の発想になかった観点だったので、なるほどと思いました。
だからプロダクトだけでなく人やプロセスを見るのがより大事なんだ、という点がつながり、とても腹落ちしました。

イベント参加＆話してわかったこと

自身以外の役割を理解することの大事さ

イベントで話を聞いた時点では、"QAエンジニアの役割はテストにとどまらない"点は理解したものの、
とはいえ、実際は"テスト以外にも入り込んでもらうのは大変そうだし、色々巻き込むのはどうなのかな？"と考えていました。

ただ、後日チームのQAエンジニアと話をしたことで、"同じ情報を共有することでQAエンジニア側にもメリットがある"ことを知りました。
このように、チームの周りのメンバがQAエンジニアに対する理解がないと、私が感じたような遠慮だったり、QAエンジニアの業務範囲ではないと勝手に判断し、必要な情報を一方的に遮断してしまう可能性があると思いました。

チーム内でお互いの役割に対する理解がないことでこういったデメリットも起こりうると知り、互いの役割と業務を理解することの大切さを感じました。

チームでイベント参加オススメ

今回チームのQAエンジニアと話をしたことで、イベントで聞いた内容をより掘り下げることができました。

複数人で同じイベントに参加することでお互いの解釈を確認できますし、今回のように自分以外の役割のイベントに参加して「双方の役割としてどう思った？」という意見交換してみるとチームメンバの相互理解にも繋がると感じました。

いきなり「お互いの役割を理解しよう！」と言っても題材無しに話すのは難しいので、同じイベントにチームで参加して会話してみることで、チームの相互理解を深めてみてはいかがでしょうか！


弥生では、一緒に働く仲間を募集しています。 herp.careers

開発エンジニアが予備知識0でQAイベントに参加してみた

QA

こんにちは。「弥生会計」開発チームでエンジニアをやらせてもらっているOです。弥生に新卒で入社して4年目になります。

先日、弥生で開催されたQAエンジニア向けオフラインイベント『Ques』に予備知識0で参加しました。

ques.connpass.com

この記事は「ソフトウェア開発エンジニア目線でこんな共通点や学びがあった」という内容のQues参加レポートです。 QAエンジニアの方もそうでない方もお気軽にお読みいただければ幸いです。

Quesのここが面白かった

今回のイベントは参加者から事前募集したQA関連のおたよりに対して、2名の登壇者がディスカッションしていく形で進んでいきました。 お話を聞く中で（これわかるな～）とか（自分も気を付けたいな～）など思ったことをピックアップしていきます。

1.『QAとテストは何が違う？』

QAとは求められる品質を保証することである。 品質が十分かを見るのにわかりやすいのが「テスト」であり、QAの中にテストが含まれる。 その他品質の管理に関連すること、お客さまからの評価をフィードバックして開発そのものの質を上げること、組織をよくすることなどもQAの仕事である。

「品質保証」という言葉はよく耳にしていたが、テスト関連の業務を除いてどんな仕事が該当するかは全然知らなかった。 開発の質の向上や組織の改善など含むならかなり幅広い。私も製品の品質向上を目指してチーム内であれこれ試してみているが、そういったことも品質保証、QAのひとつであるとは知らなかった。

tech-blog.yayoi-kk.co.jp

弥生の開発本部では、組織を改善するために自由に活動できる時間がエンジニアひとりひとりに割り当てられている。 「QAエンジニアだけが品質のことを考える。他のメンバーは従う」でなく、QAエンジニアを含めた全員が品質に意識を向け、様々な活動に取り組めているのは良いスタイルなんじゃないかなと思った。

2.『QAとしてのスキルをどうやって身につければいい？』

QAエンジニア自体が少ないためそもそも身近に先輩や上司がいない人が多いそう。そんな中でどのようにスキルを身につけたらよいか？というテーマ。

自分が教わる立場なら、上司の行動や発言をただ受けとめるだけでなく、常に「自分だったらどうする？」とシミュレーションする。

新人だったころに教わったことを思い出した。上司がなぜそのように指示するかを考えながら仕事への取り組むことで取り組み方や成長速度が変わってくるそう。

アジャイルでも求められるQAのスキルセットは変わらない。 アジャイルでもウォーターフォールでも、品質を上げるのがQAの仕事である。ただアジャイル開発ではスピード感を大事にするので、フットワーク軽く作業し、こまめにアウトプットすべき。

「どうしたらアジャイル開発を上手に進められるか」という話は最近よく聞く。QA界でもアジャイルに対する関心は高い様子で面白かった。

私のチームではウォーターフォールで開発しているが、方向性の確認や進捗報告という意味で成果物をこまめに共有することは同様に大事だと思っている。

3.『不具合を有効活用するには？』

QAの業務のひとつに不具合分析がある。そこで分析した結果をどう活用したらよいだろうか？というテーマ。

そのバグを直す必要があるか？優先度はどのくらい？その認識は周りとすり合わせられている？

こちらは「見つけたバグが優先度低しと判断されてアーカイブされてしまうことがあるがどうしたらよいか」に対するコメント。

私の立場でも自分のやりたいことが独りよがりな「こだわり」になってしまっていないかは常に気を付ける必要があると思った。周りとの認識すり合わせ大事。

要望は根拠とともに伝える。提案の際にはいろんな人を巻き込む。却下されてもチャンスが巡ってきたら再度提案する。

要望を採用してもらうためには伝え方や提案者の信用（？）が大事というお話。一度採用されなかったとしてもあきらめないことが重要、という点が強調されていた。

本当に必要なことならまたチャンスが巡ってくる。そこで採用してもらうために改めて声を上げる。その積み重ねが信用となり、「この人の言うことはちゃんと聞かなきゃ」と思ってもらえるようになる。

これは自身の意見を伝えるうえで大切なことなので、すべての社会人が心得ておいたほうが良い。

4.『QAとして気を付けるべきこと』

謙虚たれ。一緒に仕事をしやすい関係性を築くことが良いものを作ることに繋がる。

バグを「指摘する」立場はどうしても上から目線っぽくなりがちだけどそれではいけないよ、とのこと。

最近私も他のメンバーの成果物のレビューを担当するようになり、指摘の難しさに気づいた。伝え方、言葉の柔らかさも注意すべきだが、一番気を付けたいのは指摘するという立場に溺れないことである。決して「自分が正しい」と思いこむことなく、相手がなぜそのようにしたか考えながら対等な気持ちでこれからも取り組んでいきたい。

参加の感想

今回のQuesはコロナ禍真っ最中に入社した私にとって初のオフラインイベントでした。 これまでイベント会場に足を運ぶ勇気が出ませんでしたが、このたび自社で開催するというお知らせが舞い込んできたので「QAのことは良く知らないけど困っても誰かにこっそり聞けそう！」という他力本願な気持ちで参加を決めました。

結果、畑違いかと思っていたジャンルのお話もたいへん勉強になりましたし、他社のさまざまな立場の方と交流することもできてとても新鮮でした。お声掛けくださった方、イベントを運営してくださったみなさまに感謝します。ありがとうございました！

ブログの宣伝

弥生の新卒エンジニアはこんな感じで働いているよ～という記事を書きました。良かったら読んでみてください。 note.yayoi-kk.co.jp


弥生では、一緒に働く仲間を募集しています。 herp.careers

元QAエンジニアが、PMの立場でQAエンジニアのイベントに参加してみた

QA

こんにちは、弥生のシダです。 私は弥生でsubPM*1として活動しています。 また、私は2023年9月まではQAエンジニアとして働いていました。

先日、弥生で開催されたQuesというイベントに参加しました。 そこで新たな気づきを得ましたので、この場にてお伝えしたいと思います。

Quesについては以下の記事を参照ください。 （なお、現地で初めて知ったのですが、こちらは”キューズ”と読むのが正解のようです。直前まで"クエス"と口語していたため、開始2秒で恥ずかしくなりました。）

tech-blog.yayoi-kk.co.jp

YOUは何しにQuesへ？

前述の記事にもあるとおり、弥生内でQuesが開催されることとなりました。 開催が決まったときには私はQA業務から距離を置いていたため、参加の予定は無かったのですが、当日の会場設営や写真撮影などの手伝いを行うこととなり、その流れで話を聞くこととしました。

QAエンジニアとPMの作業内容には少なからず親和性があることは知っていたため、今のPM業務をより良くするヒントがあるのでは、と思ったことも一因です。

予想以上に賑わっていてワクワク

今回ピックアップする話

今回第22回のQuesではいくつかのセクションがあり、いずれも興味を惹かれる内容でした。 特に、私は前職で第三者検証会社に所属していたため、「事業会社のQAに求められるものと、第三者検証会社から安定的に供給できるQAエンジニアのGAPを埋めるにはどうすればいいか」という話題については、とてつもない"わかりみ"を感じました。

その話をしだすといくらでも語れる気がしますが、今回の目的はそこではありません。（というよりも、ただの昔話になってしまう）
そこで今回は「チームで求められるQAの役割」という話題にフォーカスして話したいと思います。

「チームで求められるQAの役割」の内容

※一部、私の意訳も含まれます

テストについて

QAの業務には、勿論テストは含まれる。 ただ、目の前の物だけ見てもいいテストは出来ない。具体的にいうと、完成した設計書やシステムを見るだけでは、表面的なテストにしかならない。それを解消し、QAとしての価値を高めるためには2つ案がある

開発プロセスを観察する

開発の様子を観察することは、効果的なテストをするうえで非常に大切である。観察を通じて以下のような問題点が明らかになる。

  • 仕様決定に四苦八苦した点
  • レビューで何度も差し戻しがあった点
  • コミュニケーションが不十分なまま進んだ点

これらの問題点を見つけ出すことで、QAはプロセスの改善に切り込むことができる。また、これらの観察結果をテスト観点に取り入れることで、より良い品質を実現することが可能となる。

利用者側の目線を持つ

QA本人が仕様やプロセスに明るくない場合、あるいは開発内部に親しみが無い場合は、ユーザー側の立場なるという点が効果的である。多くの開発メンバーは、実際に利用される背景を十分に理解していないことが多いため、ユーザー目線での意見は開発メンバーにとっても貴重なものとなる。このユーザー目線のフィードバックを開発側に還元することで、品質の向上が期待できる。ユーザーの視点を取り入れることで、より使いやすく、実際のニーズに合った製品やサービスを提供できるようになる。

いずれも、とても共感できる内容でした。私自身、QAエンジニアとして出来ていたことも出来ていなかったこともあると思います。
ただ、これだけだと単なるレポートになってしまうので、もう一歩踏み込んで考えたいと思います。

PMとして何ができるか

QAエンジニアの理想の動き方は分かりました。
では、PMとしてはこの内容を踏まえ、どういったことが出来るでしょうか？

1. QAエンジニアが開発プロセスを観察できる環境の構築

開発プロセス全体を透明化し、QAエンジニアが開発の進捗や変更点を常に把握できるような環境構築が必要だと考えます。 日次のMTGで生の声を聴いてもらうことも必要ですし、タスク管理ツールなどを最新化してQAエンジニアが開発の進捗状況をリアルタイムで確認できるようにする、というのも効果的だと考えます。

2. 要求元とのMTGへのQAエンジニアの参加

要求定義や仕様策定の初期段階からQAエンジニアにも参加してもらうことで、品質要件を早期に把握し、後のプロセスでの問題を未然に防ぐことが期待できると考えます。 また、QAエンジニアが要求を正確に理解するための質問や確認ができる場としても活用できます。 QAエンジニアが要求元とのMTGに参加することで、ビジネスニーズや実際の利用背景を深く理解し、それに基づいたテストケースの設計や品質保証が可能になると考えます。

3. 開発エンジニアとQAエンジニアの対等な関係構築

上記1、2のような施策も、QAエンジニアの声が開発エンジニアに届かないと意味がありません。そのため、開発エンジニアとQAエンジニアのパワーバランスを適切に保つのが大事だと考えます。（前職でのQAエンジニアとしての経験論ですが、開発エンジニアと距離を感じることが度々ありました。）
それぞれの役割と責任を明確にし、お互いに尊重する環境を作り出すことで積極的な意見交換に繋がり、結果的に品質の向上が期待できると考えます。


貴重な学びをありがとう

まとめ

改めて考えると、QAエンジニアが最大限に力を発揮できるよう、PMとしても出来ることはあると思います。 現在の私のチームには上記のような課題は無いものの、今後チームや環境が変わることはあるはずなので、後学のために覚えておきたいと思います。

今回の参加を通して、QAエンジニアとしての視点も持ち続けるべきだなと改めて感じました。 また、機会があれば次は開発エンジニア向けのイベントにも参加してみたいとも感じました。私自身もまだまだ成長が必要だなと思える、大変良い機会でした。
開催のために動いてくれた皆様に、この場を借りてお礼申し上げます。


弥生では、一緒に働いてくれる仲間を募集しています。 herp.careers

*1:subPM…サブプロジェクトマネージャーの略