スクラム開発エンジニア必見!エンジニアのためのオフラインイベント開催のお知らせ

はじめに

こんにちは。弥生でEngをしています、田邊と申します。今回は、弥生で開催しているもくテクのオフライン開催についてのお知らせです。 本イベントを企画している私が、開催の経緯やオススメのポイントをご紹介します。 スクラム開発に携わっている方・興味がある方はぜひお越しください。

mokuteku.connpass.com

どんなイベント?

スクラム開発についての知見共有イベントです。 スクラム開発経験のあるエンジニアが登壇し、スクラム開発についての悩みや工夫について語ります。 弥生の本社オフィス、秋葉原UDXにてオフライン限定で行うイベントです。 参加費は無料です!

開催の経緯

スクラム開発では、導入初期においては混乱が起こりがちですが、私がいたチームも例外ではありませんでした。 2023年の4月ごろから新たなサービスの開発チームが発足し、私もそのチームに所属することになりました。 弥生ではウォーターフォール型の開発が主流であり、発足したチームメンバーにもスクラム開発の経験のあるメンバーはほとんどいませんでした。

手探りの中でスクラム開発が始まるも、開発の進め方やスクラムイベントのやり方など、戸惑う部分が多かったです。 私もスクラム開発についての書籍を読むなど、キャッチアップしようとしていましたが、どうしても一般的に紹介されるケースと自チームのケースでは違う部分も多く、なかなか思うように進めることができませんでした。

チーム内でもどうしていくべきかという議論を続けながら進めていくなかで、時間が経つにつれて徐々に軌道に乗って行きましたが、他のチームはこういう悩みにどう対処してるんだろう?と感じ、それらを共有する場があればと思い、このイベントを企画しました。

オススメポイント

各エンジニアが持つスクラム開発についての知見を知ることができます。 パネラーとして登壇するメンバーは全員違うチームに所属するメンバーなので、それぞれ違う体験を聞くことができます。 また、パネラーの中には弥生の入社前にスクラム開発を経験したメンバーもいるので、弥生以外のスクラム開発についての話も出る予定です。

さらに、今回は弥生の本社オフィスの秋葉原UDXでのオフライン開催です。 当日のイベント内でも質問を募集する予定です。現在スクラム開発でお悩みの方は、直接質問や悩みをぶつけられる機会となりますので、特にオススメしたいです。 スクラム開発を始めたばかりの方はどうしても悩みがチーム内で閉じてしまうことが多いと思います。 他の人とスクラム開発について語れるこの機会をぜひ活用していただければと思います。

さいごに

イベントは05/30(木)19時からです。予約申し込みは↓から!

スクラム開発Engのお悩み相談 ~「これってどう解決してますか?」~ - connpass


弥生では一緒に働く仲間を募集しています。一緒に、進化するチームで働きませんか?

herp.careers

Scrum Fest Niigata 2024で登壇します

こんにちは、カトです。弥生でQAエンジニアをしています。
5月10日(金)~11日(土)開催のScrum Fest Niigata 2024(スクラムフェス新潟)にて、登壇をします。
このブログは、告知です。

スクラムフェス新潟のWomen in Agile 「New Voices」 : 新たな声、新たな視点 - スピーカー未経験の女性たちが語るアジャイルというセッションの中で、10分の登壇にチャレンジします。

Scrum Fest Niigata 2024 とは

開催要項

スクラムフェス新潟はアジャイルコミュニティの祭典です。 アジャイルやテストのエキスパートと繋がりを持ちましょう。この祭典は初心者からエキスパートまで様々な参加者が集い、学び、楽しむことができます。 また新潟の地場エンジニアコミュニティと、全国のエンジニアコミュニティを繋ぎ、活性化する「場」でもあります。 参加者同士でアジャイルやテストのプラクティスについての知識や情熱を共有し合いましょう。出会ったエキスパートに困りごとを相談し、明日への活力にしましょう。

www.scrumfestniigata.org

発表のきっかけ

2024年2月にWomen in Agile Tokyoに参加したことでした。
Women in Agile Tokyo参加報告ブログを投稿しています。ぜひご覧ください。 tech-blog.yayoi-kk.co.jp tech-blog.yayoi-kk.co.jp

今回、Scrum Fest Niigata 2024のWomen in Agileセッションへの登壇応募の条件は以下の3点で、私は、すべての条件を満たしていました。

  • ①女性であること(自分自身を女性と自認している方)
    • Yesです。
  • ②これまでに20分以上の登壇経験が1回以下。LTなどはカウントしません
    • 弥生で開催しているもくテクを含めた、いくつかのイベントで登壇経験はあります。
    • 10分を超える登壇は未経験です。
    • 社外でのオンサイトのイベントでの登壇は未経験です。
  • ③やりたいという気持ちがあること!(一番大事です)
    • 発表することの苦手意識をなくしたいです。
    • チームがチャレンジしているいろんなことを共有していくきっかけにしたいと考えています。
    • 新しいチャレンジをしてみたいという気持ちで溢れています。

スクラムとの出会いによって、私の仕事のやり方が変わってきたというお話しをする予定です。
仕事をする中で「できた」という気持ちをあまり持てていない人、部下や後輩を育成中に相手がどうしてうまくできないのかを掴めず困っている人にとって、ヒントになることがあると嬉しいです。

参加申し込み

スクラムフェス新潟のページから、チケット購入ページに遷移できます。
オンサイトのチケットは完売していますが、オンラインのチケットはまだ購入できるようです。
www.scrumfestniigata.org

イベントスケジュールは以下のページでご確認いただけます。
Scrum Fest Niigata 2024 - Program Schedule | ConfEngine - Conference Platform

ぜひ参加をご検討ください。


弥生では一緒に働く仲間を募集しています。一緒に、進化するチームで働きませんか?

herp.careers

132名を集客した外部向けエンジニアオンラインイベントの準備のしかた

はじめに

こんにちは。弥生株式会社でエンジニアをしています、田邊です。
先日03/28(木)に弥生で「インフラ構築、どうしてる? ~IaCの知見共有会~」という社外勉強会イベントを実施しました。

mokuteku.connpass.com

こちらのイベントでは、普段からIaC(Infrastructure as Code)でインフラ構築しているエンジニアに登壇してもらい、LTで知見を共有してもらいました。
また、後半はLTで登壇したメンバーに再び登壇してもらい、パネルディスカッションの形で、IaCについて用意したテーマについて語ったり、本番中に参加者から寄せられた質問に回答したりしました。

このイベントは非常に好評で、90人枠で開催したものの、申込者が多く、最終的には132名の方に申し込みいただきました。
弥生では「もくテク」というイベント名でこのような社外勉強会を不定期で8年近く開催しているのですが、これまでのイベントで2番目に多い動員数となりました。

このイベントはconnpassという主にIT勉強会のイベント開催・参加ができるサイトで参加者を募集しているのですが、そのconnpassでのイベントランキングにも一時37位にランクインしました。

私はこちらのイベントの企画・イベント司会・LT登壇・パネルディスカッション司会を担当していました。 今回のブログでは、大変盛況だったこのイベント舞台裏の準備の様子をお伝えし、イベントを開催しようと考えている方の何かしらの参考になればと思います。 後半ではイベントの内容やLT資料も紹介しますので、当日参加したけれどもう一度見返したい、当日参加できなかったのでイベントの内容や発表の内容を知りたいという方はぜひこちらをチェックください。

イベント準備

開催のきっかけ

ある日の社内でのインフラエンジニアの共有会で「IaC」がテーマになりました。普段私は共有会には参加していなかったのですが、CDKを業務で使っていて興味があったので飛び入り参加しました。
自分もCDKを使っていて悩みながら実装・運用を進めていたのですが、そこで話をする中で、各チームでも悩みがありつつもそれぞれが色々な知見を持っていることが分かりました。
せっかくなのでその知見を共有するような場を作りたいと考え、イベントを開催することにしました。

登壇者集め

CDKを業務で使っている人に登壇してもらいたかったのですが、現状弥生では自分のチームメンバーやチーム外の知り合いでは限界があります。
チーム外の知り合いに、自分のチームメンバーに打診してもらうなど、色々な人の伝手を頼りながら登壇者を探しました。
快く引き受けてくれる方が多くいたおかげで登壇者を集めることができました。ほとんど初めましての方もいましたが、広く知見を共有してもらうためにも、少しコミュニケーションを頑張って自分が普段関わらないチームのメンバーにも声をかけることができたのは良かったと思います。

イベント準備

「もくテク」というイベントは、不定期ではありつつも何度も開催しているイベントなので、社内の知見が多く溜まっていました。社内のもくテクの運営のメンバーに協力いただいたことで、Zoom等の企画内容にかかわらない準備について大きく困ることはありませんでした。
これからイベントを開催しようとしている人にとっては強くてニューゲーム的な参考にならない話ですみません。機会があれば弥生のイベント運営のしかたについても今後もしかしたら改めてご紹介するかもしれません。

イベントページ公開・X投稿

イベントページを準備し、connpassで公開しました。イベントページを作る際は「どういう人がターゲットなのか」「このイベントに参加すると何が得られるのか」が伝わるようにすることを心掛けました。
開催側としては大事なイベントですが、参加者からすれば有象無象のイベントの一つなので、興味がある人にはちゃんと伝わるように工夫しました。
今回は技術系の話の中でもややコアな話(全くの初心者では分からない話)なので、興味を持ってもらうことよりも伝えることを意識しました。

また、X(旧Twitter)で、弊社のエンジニア情報アカウント(@yayoikk_dd)を使い、開催の1週間前からLT登壇者一人一人の登壇コメントを投稿するという企画も行いました。
投稿から申し込みに結びついた方がどれくらいいるかは測定できていませんが、投稿からページのリンクに飛んでいる方は少なからずいたので、そこから興味を持ってくれた方もいたかもしれません。

投稿のアナリティクス。リンククリック数が一定数あることが分かる。

LT準備

LTについては内容は特に指定せず、「IaCに絡む話ならなんでもOK」として登壇者にお任せしました。今回のイベントの開催の目的やターゲット層などを事前に共有することで最低限内容がブレないようにしました。その結果IaCの事例だけでなく「IaCが無い状態だとこうなる」という内容のLTをしてくれた方がいたり、初心者向けの話をする人がいれば経験者向けの話をする人もいたりと、LTに多様性が出たと思いました。
LTの内容の確認については、必須とすると各自早めに完成させなければならず、作る側も確認する側も負担が大きくなるので、登壇者を信用して当日までに準備しておいてくださいという形で依頼しました。
もちろん確認した方が色々準備しやすいのは間違いないですし、企画側としては確認したい部分もありますが、事前確認が無くてもできないことはないという実感はありました。

パネルディスカッション準備

パネルディスカッションの司会は私は初めてでしたが、パネルディスカッションについても入念な準備は行いませんでした。
誰が何を話すか決まっている状態だと予定調和でつまらなくなってしまうので、あまり事前の打ち合わせはせず、どんなテーマだけ話すか共有して、あとは当日に話したい人が話してもらうという形式を取りました。
打ち合わせをしなかったことで生で話す盛り上がりは出せたと思いますが、ファシリテートをしていた私としては誰がどんなことを話したいのか分かっていないので、誰に話を振るか悩ましい部分もありました。
打ち合わせはしなくとも、事前にテーマごとにどんな話をしようと思っているか登壇者に教えてもらい、それをベースにファシリテート側でどんな形で進めるか検討しておくなどが良いかもしれません。

イベントの様子

LT

LT①「CDKでの自動構築が超簡単で感動した話(超初心者向け)」

CDKを始めて間もない(3カ月)状態の立場から、CDKを使ってどんな良い点があったのかを紹介してもらいました。
やってみないと分からない部分もあるので、使ってみた実感としての良かった部分はIaCを導入するか悩んでいる人にとって参考になる部分も多かったのではないでしょうか。

スライド資料はこちら

LT②「IaCがない環境でインフラ担当じゃない人がAWS触ってみた話」

IaC回であえてIaCを使っていなかった時の運用の話をしてもらいました。
インフラ構築を手動でやるとどういう辛さがあるのか語ってもらったことで、IaCのメリットについて考えるきっかけになったと思います。

スライド資料はこちら

LT③「CDKの実装のススメ方」

CDKの実装をどう進めるのが効率が良いかについての話をしてもらいました。
初心者は公式ドキュメントをちゃんと読まないと実装を進めにくい性質上、どうすれば実装しやすくなるかという観点は貴重なものだったと思います。

スライド資料はこちら

LT④「先人の教えに背いてCDKのスタックを分割した男の末路」

CDKで重要な概念であるスタックを分割するかどうかについてのLTでした(発表者は私です)。
スタックを分割したことで生じた問題点について語ることで、今後IaCを導入する人に同じ辛さを味わってもらいたくないという想いで話しました。

スライド資料はこちら

LT⑤「AWS初心者が苦労してCDKカスタムリソースを作った話」

CDKのカスタムリソースを使った感想について共有してもらいました。
初心者としてはなかなか扱いづらいポイントがあるという点は触ってみないと分からないので、業務で使った立場から話してもらえたのはとてもよいと思いました。

スライド資料はこちら

LT⑥「AWS CDK 経験者が CDK for Terraform 使ってみた」

CDK for Terraformを使って良かった点・苦労した点を話してもらいました。
苦労する部分はありつつも、CDKでの辛い部分を回避できる点があるなど、良い点も知ることができる発表でした。

スライド資料はこちら

LT⑦「Terraform v1.7のTest mocking機能の紹介」

TerraformのTest mockingの機能の紹介をしてもらいました。
知らなかった機能を知れるという観点に加え、こういった新機能の良い点・悪い点を実際に使った立場から語ってもらえてよかったです。

スライド資料はこちら

パネルディスカッション

パネルディスカッションでは「IaCの辛い部分」や「IaCをあえて使わずに構築するケース」などのテーマを基に登壇者に自由に話してもらいました。
また、Zoomの視聴者の皆さんからのコメントでの質問やXでの投稿から「こういうケースはどうしているか」「この機能は何か活用しているか」などの質問も多くいただき、それについても答えることができました。
LTだとどうしても一方的に話すことになるケースがありますが、パネルディスカッションをしたことで参加者の皆さんと双方向の会話をすることができ、視聴者の方々の満足度も上がったのではないかと思います。

さいごに

今回のブログでは「インフラ構築、どうしてる? ~IaCの知見共有会~」の準備の裏側の紹介と、イベントの様子の紹介をしました。
今回はこれまでのもくテクイベントと比較して多くの方々に参加してもらうことができました。
今回はある程度インフラの知識を前提としたイベントということもあり、どれくらいの人数になるのか不安もありましたが、ある程度の知識が前提となっていたことで、興味範囲が被る方から参加申し込みをしてもらえたのではないかと思います。
もくテクは今後も開催しますので、興味がある方はぜひ↓のconnpassのページから今後のイベント予告を楽しみにお待ちください。

mokuteku.connpass.com

一緒に働く仲間を募集しています

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

herp.careers

WordCloudで日本語文字が豆腐になる問題を解決する

こんにちは。R&D室のsiidaです。 R&D室には様々なミッションがありますが、その中でも主要なものとしてAI/MLプロジェクトの企画からMVPリリースまでEnd-to-Endに推進するというものがあります。最近はちょうどプロジェクトのPoCに力を入れていたため、データサイエンティストらしくJupyterを使ってデータ分析する機会も多くありました。今回はそのような中で遭遇したトラブルとその対処法を残していきたいと思います。

TL;DR

WordCloudで日本語が豆腐になる場合には WordCloud(font_path="/path/to/my-font.ttf") というように font_path を指定する。

問題

WordCloudを使用して日本語の単語をプロットしようとすると、豆腐(文字化け状態)になることがある。作り込んだ環境では特に意識せずとも正しく表示されるかもしれないが、Google Colab利用する場合など新たに立ち上げた環境においてはよく発生するトラブルである。

たとえばColab上でこのコードを実行すると、日本語の文字は豆腐になる。

from wordcloud import WordCloud

wordcloud = WordCloud().generate(" ".join(["hoge", "fuga", "piyo", "ほげ", "ふが", "ぴよ"])

wordcloud_bad

こういう場合のよくあるプラクティスは japanize_matplotlib を使うことや plt.rcParams['font.family'] を設定することだが、これではタイトルや軸ラベルは日本語になってもWordCloudでプロットされる単語は豆腐になってしまう。

続きを読む

Women in Agile Tokyo 2024に参加しました②-学び持ち帰ってやってみたこと編-

こんにちは、弥生でQAエンジニア兼スクラムマスターをしている、カトです。
2024年2月6日Women in Agile Japan 開催のWomen in Agile Tokyo 2024にオンサイト参加してきました。
www.wiajapan.org

「Women in Agile Tokyo 2024に参加」で1記事にしようと思ったのですが、いろいろと書きたいことが出てきたので、記事を分けることにしました。
tech-blog.yayoi-kk.co.jp 「Womenについて考えてみた編」を書いて1か月ほど経ちました。今回は、「学び持ち帰ってやってみたこと編」です。

開催前日は雪でオンライン参加にするか迷うほど

会場

会場に到着して最初にびっくりしたのは、椅子の配置でした。
講演を聞くので全員が壇上を見るように椅子が配置されているのかと思ったら、サークル型で配置されていました。

メインホールの椅子の配置図
画像は、Women in Agile Tokyo 2024 Opening, Keynote & OST - YouTubeより。
あまりにびっくりしたのと、すでに座っている人がいらっしゃったので写真はなし。

壇上を見るように並べると、参加している人の様子が見えにくかったり、真ん中付近の席になると出入りで周りの人に配慮しなければいけなかったりするのですが、サークル型に置かれた配置は、好きなところに座りやすく、どの席に座っても周りの人の様子が見やすく感じました。
「周りの人がどんなリアクションをするのだろう?」と後方、隅っこに座りがちな私にとって、新鮮な配置でした。

Keynote

1.5時間ほどの講演の中で、3つのミニワーク(参加者が考える時間)がありました。 これから動画を見たり話しを聞く人にネタバレにならないように書きます。

  1. お父さんとお子さんがお出かけ中に事故にあったシチュエーション
  2. 靴ひもを結ぶ
  3. バスケットボールのパスをカウントする

3つともはじめて聞いたり見たりする内容でしたが、私は1つ目と3つ目はどちらも解答にたどりつきました。
完全に失敗に終わり、悔やまれたのが2つ目の靴ひもを結ぶワークです。
ワーク以外の箇所でも、社内研修で聞いたことのある用語を改めて聞くことができたり、自分の普段の活動についてふりかえることがたくさんありました。

開発レベル

2つ目のワーク、「靴ひもを結ぶ」ワークについてです。


弥生では、SLⅡ(セルフリーダーシップ)をもとに、会話をしています。
www.blanchardjapan.jp

「"開発レベル"は人につくものではなく、タスクにつくもの」と常々意識して業務をしています。「タスク-1については"D1"だから"S1"でサポートする、一方で別のタスク-2については、"D4"だから"S4"でサポートする」というような会話がなされています。
自分自身も「今対応しているタスクは"D1"だから"S1"でサポートしてほしい」とサポートをしてもらう相手に伝えることがあります。

普段"開発レベル"意識して業務をしているにもかかわらず、靴ひもを結ぶミニワークでは、相手の"開発レベル"の確認をせず、おそらく"D4"であるにもかかわらず、最初から"S1"でサポートをし始めてしまっていました。
知っていても利用すべき場面で活用できていないことを実感しました。
業務中は意識して対応できていると思い込んでいても、使いこなせていない場面があるのかもしれないとも感じました。

はじめて会った相手に対しても最初から適切なサポートができるようになれればよいですが、まずはオープンクエスチョンとクローズドクエスチョンを使い分けながら、相手とコミュニケーションをとりながら、適切なサポートができるようにしていくことを意識し続けます。

みんなのバイアス

3つ目のワーク、「バスケットボールのパスをカウントする」ワークについてです。


私は、パスの回数を2回ほど少なくカウントしてしまっていましたが、動画を見ているときに本題となる事柄には気づいていました。
「この場所はエレベーターホールだろうか?体育館やグラウンドではなく、なぜこんな場所でバスケットボールのパスをするのだろう?」と思いながら動画を見始めたことがきっかけでした。
パスをしっかり数えなければならないとは思いながらも、場所についてや参加している人の様子が気になっていました。

動画を見ているときに本題となる事柄に気づくことができたのは偶然ではありますが、実務でもこのような場面に遭遇することがあったことに気がつきました。

普段、エンジニアのミーティングにQAエンジニアの私が参加する場面において、正直、エンジニアが話している内容について詳細まで理解できていないこともあります。
それでも「わからないので教えて」と聞いてみることが、エンジニアが検討している事項で漏れているかもしれないことや前提が崩れているかもしれないことを洗い出すきっかけにつながることがあります。
この発言を"QA観点"と言われることがあります。しかし私自身は「誰でも気づけそうなことを、偶然私が最初に発言してみただけ」と思っており、他のチームに参画した場合でも再現性があるのかないのかわからないままになっていました。
今参画しているチームでは"QA観点"を発動できるけれど別のチームにいったらそれができないのではないか、これはQAエンジニアや私のスキルではないのではないかといった漠然とした疑問や不安を持っていました。

今回、「バスケットボールのパスをカウントする」動画を見て、エンジニアのミーティングにおいて、ルールを把握してしっかりと正しくカウントする役割がエンジニアなのだとしたら、ボールの行方を追いながらも他のことを気にできるのがエンジニア以外の役割であり"QA観点"に近いことなのではないかと感じました。
「エンジニアのミーティングにQA・UXなど別のロールの人を呼ぶと、エンジニアには説明しなくてもよい前提を説明しなくてはいけなくなる」「QA・UXがエンジニアのミーティングに参加してもらっても時間を使ってしまうだけ」と考えて閉じたミーティングになってしまうことはよくあることだと思います。
すべてのミーティングに参加することは現実的ではないですが、「関係者ではないかもしれないから」「ミーティングの邪魔になってしまうかもしれないから」と遠慮してミーティングに参加しなかったり疑問を発しないことは、チームにとってよくないことにつながります。
私はみんなの論点になっている中心部以外のことを気にできるQAエンジニアにならなければいけないし、QAエンジニアのミーティングも広くたくさんのロールの人に見てもらって意見を取り入れていきたいと強く感じ、今まで以上にミーティングへの参加して発言することを心掛けています。


読み手に考えてもらう手順書

ワークではなく、Keynote後半でのお子さまのテニスのコーチングの話題についてです。


お子さまのテニスのコーチが、「質問をしてくれる。ずっと考えさせるようなことをやっていく。ものすごい1時間が濃い。」とお話しされていました。
一方で、「子どもでも平気で2、3時間の練習をしているのはなんでなんだろう?と考えた時、自分で考えていないからこそ時間を長くしないと定着しない」というお話しがありました。

実務ではどういう場面で当てはまるだろうと考えた時、私は自分たちのプロジェクトで作成している操作マニュアルがこの状態になっているかもしれないと思いました。


私が担当しているサービスは、数多くのサービスと連携しており、時に複雑な設定をしなければ動作させることができません。
根本的な問題の解決として複雑な設定をしなくても使えるような仕組みづくりを考える必要はありますが、現在の挙動も知らなければなりません。
複雑な設定に対応できるようにという思いで、手順書を作成していました。
手順書を作成した結果、特定のメンバー以外でも設定ができるようになったというメリットはありました。しかし、「なんだかわからないけれど手順どおりにやったら設定が完了した」といった状態になったり、 イレギュラーなことが起こった時にどの部分を確認すればよいのかがわからなくなったりしています。

この問題に対処するため「何のために実施するのかをメインで記載し、細かい手順は記載しない」という方針で手順書を作り変えました。
作成時に決めた方針は以下です。

  • テスト環境独自の設定については対外資料にはないので記載する
  • どのような機能を持っているのかについては記載する
  • 画面に則って進めればよいことは手順を記載しない

レビュー指摘の「記載を削りすぎてしまっていて、他の資料を見ないと操作を進められない」を反映したり、細かく書きすぎている点を調整したりと、まだ試行錯誤中です。
それでも「なぜこの情報を記載しているの?」といった質問からコミュニケーションをとって理解を進められたり、「今、自分が何の目的で設定をしているのか考えながら進められている」といったフィードバックを受けたりといった、「読み手に考えてもらう手順書」に一歩ずつ近づいているという実感を持っています。

オンボーディングの資料として使えるように、さらに更新をしていく予定です。

OST

QAエンジニア

私はQAエンジニアとしてスクラムチームでどのように立ち回ればよいのか、チームはQAエンジニアに何を望んでいるのかということを聞いてみたいと思って、「プロダクトオーナー、スクラムマスター、開発者以外のロールでスクラムで活躍するには?」というテーマだしをしてみました。

つたない進行の中、参加してくださったみなさんに感謝しています。
スクラム開発チームに参加しているQAエンジニアにも、QAエンジニア以外からみたQAエンジニアのことを聞く機会になりました。
そして、「スクラムマスター的な働きをしている」QAエンジニアと出会いました。どんどんミーティングに参加させてもらって、いろんなチームの情報を取りに行く姿勢は取り入れていきたいと思いました。
自チームのミーティングやペアプロモブプロの場に顔を出すことや、Slackのテキストコミュニケーションで自分がメンションに入っていなくても気になることについて確認してコメントしていくことはできています。しかし、まだ他のチームにお邪魔するのは心理的ハードルが高くて実践できていません。
少しずつでも姿勢を変えていかなければ、「思っている」で終わってしまいます。「参加しても情報得られないかもしれないよ」という反応があっても、関連するチームのミーティングに参加してみることから始めていきます。
QAエンジニアがふらりとミーティングに顔を出したときに「どうしたの?障害でも出た?」と一瞬ピリっとする空気になるところから、徐々にでも「覗きにくることが普通」の状態に近づけていければと考えています。

スクラムチームでのQAエンジニア活躍について考えたイーゼルパッド


まとめ

「Women」とタイトルにつく会で、Womenや多様性について考えることはもちろん、コーチングや自分の業務についてふりかえり、考えるきっかけにもなる会でした。
業務について視点を変えてみる日をつくることが、日々の業務の改善ポイントを見つけることにつながりました。
実践してすぐに結果が出ることばかりではないけれど、今回の学びを持ち帰って業務に活かし、さらなるサービス品質の向上とチームの発展に努めます。

さて、私は次回何色の髪で参加するのでしょうか?
最強ピンクになれるよう、日々精進してまいります。


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

yamoryについて調べてみた(SCA)

みなさん、セキュリティ対策していますか?弥生CTOの佐々木です。 セキュリティ対策にもDAST、SAST、SCAなど色々ありますが、今日は弥生でも利用中のSCA(Software Composition Analysis)の機能を持つオールインワン脆弱性管理クラウド「yamory」についてご紹介します。

yamoryですが「オールインワン脆弱性管理クラウド」ですのでSCA以外の機能も持っています。 SCA以外の機能もフル活用しつつ、重複なく漏れなく対策を行うためにセキュリティ担当者にyamoryで出来る事を調査してもらいました。 以下、調査結果です。

yamory とは

yamory は IT システムに潜む脆弱性を自動で検知し対応フローを構築する、脆弱性管理クラウドです。 利用しているサーバーホストのOSや開発言語やビルドシステム / パッケージ管理システムに合わせて、最適な脆弱性スキャン方法を提供しています。

yamoryが見るファイル等は以下のものです。

  • アプリケーションのマニフェストファイル
  • ホストのパッケージのメタデータ(パッケージ管理コマンドの結果)
  • コンテナのイメージにインストールされているパッケージのメタデータ
  • クラウド環境の設定
  • 詳細: https://yamory.io/docs/scan-targets/

スキャンについて

スキャン種別

現在(2024/02時点)、以下のスキャンが用意されています。

  • アプリライブラリスキャン
  • ホストスキャン
  • コンテナイメージスキャン
  • クラウドアセットスキャン
  • IT資産登録

目的と対応するスキャンの状況

脆弱性管理

  • OSSの脆弱性を検出・管理する機能です
スキャン種別 アプリ(ライブラリ) MW(パッケージ) OS(カーネル)
アプリライブラリスキャン × ×
ホストスキャン ×
コンテナイメージスキャン
クラウドアセットスキャン
IT資産登録

ライセンス管理

  • OSSのライセンスチェックが可能です(例:GPL、LGPL...)
  • ライセンス管理されるソフトウェアはアプリライブラリスキャンをされたもののみです。
スキャン種別 アプリ(ライブラリ) MW(パッケージ) OS(カーネル)
アプリライブラリスキャン × ×
ホストスキャン × × ×
コンテナイメージスキャン × ×
クラウドアセットスキャン × ×
IT資産登録 × × ×

EOL管理

  • 利用しているOSSのEOL(サポート終了)をチェックしてくれます。サポートがもうすぐ終わりそうなものも検出対象です。
  • EOL管理されるソフトウェアは、それぞれのスキャンの中でソフトウェアとして検知されたものすべてが対象です。
スキャン種別 アプリ(ライブラリ) MW(パッケージ) OS(カーネル)
アプリライブラリスキャン × ×
ホストスキャン ×
コンテナイメージスキャン
クラウドアセットスキャン
IT資産登録 × × ×

スキャンの網羅性

  • 以下、AWSの場合です。
- アプリ MW
(パッケージ)
OS(カーネル)
対象 EC2 ECR EC2 ECR EC2 ECR
アプリライブラリスキャン × × × ×
ホストスキャン × × × ×
コンテナイメージスキャン × × × ×
クラウドアセットスキャン※3 △※1 △※1 ○※2
  • ※1 クラウドアセットスキャンでEC2、ECRから検出するアプリライブラリは実モジュールから抽出できる情報を扱っているため、広く、素早く、簡単に検出することができますが、その分パッケージ管理マネージャー経由で抽出できるスキャンよりも荒いスキャンとなっております。現時点では置き換えるというよりは、アプリライブラリスキャンを補足するような位置付けになります。
  • ※2 インスタンスにAWS Systems Manager エージェント (SSM Agent)がインストールされている必要があります。
  • ※3 EBSスナップショットを取得するため料金がかかる可能性があります。

ライセンスについて

スキャン対象 カウント方法
アプリライブラリ パッケージ管理システムで管理している1プロジェクトを1アセットとします。
ホスト(Windows / Linux) 1台 / 1インスタンスを1アセットとします。
コンテナイメージ 1コンテナイメージを1アセットとします。
クラウド(CSPM) 1アカウントを1アセットとします。
IT資産 5レコード(ソフトウェア、ハードウェア)を1アセットとします。

Amazon Inspector とyamoryの違い

一緒に働く仲間を募集しています

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

もくテク「AWS re:Invent 2023 参加報告会」を開催しました!

こんにちは!もくテク運営岩佐です。
1月25日(木)にもくテク「AWS re:Invent 2023 参加報告会」を開催しました。

re:Invent 2023は今年もラスベガス開催でした

イベント概要

イベントページはこちら(※開催は終了) mokuteku.connpass.com 前半:re:Invent参加者によるLT、後半:全員でパネルディスカッションというスタイルでre:Inventについて語りました。

イベント動画

イベントのアーカイブ動画をYouTubeで公開しています! www.youtube.com

イベントの様子

イベントの内容については、ぜひ上記YouTube動画をご覧ください!
各LTの資料も公開していますので、興味のある発表があれば目を通してみてください。

LT1:re:Invent参加報告 by 明智 博司

speakerdeck.com

LT2:re:Invent 振り返り by イトー

speakerdeck.com

LT3:re:Invent2023 参加報告 by 津輕 真澄

speakerdeck.com

LT4:AWS re:Inventのここがすごい by 田邊 慎史

speakerdeck.com

パネルディスカッション

↓のリンクをクリックするとパネルディスカッションが始まるところからYouTube動画が再生されます。
司会(私)が気になっていたことをたくさん聞くことができて大変満足しました!
re:Inventが気になっているみなさまの参考になる情報盛りだくさんだと思います。
もくテク2024年1月会「AWS re:Invent 2023 参加報告会」 - YouTube

もくテクについてのご案内

次回は「インフラ構築、どうしてる? ~IaCの知見共有会~」

次回のもくテクは3月28日(木)開催です。
IaC(Infrastructure as Code)について、LTとパネルディスカッションをお届けします! mokuteku.connpass.com

メンバー登録お願いします

もくテクでは今後も様々なテーマで勉強会を開催していきます!
興味のある回へのご参加や、メンバー登録などしていただけると嬉しいです。
mokuteku.connpass.com

一緒に働く仲間を募集しています

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