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

Women in Agile Tokyo 2024に参加しました①-Womenについて考えてみた編-

こんにちは、カトです。
2024年2月6日Women in Agile Japan 開催のWomen in Agile Tokyo 2024にオンサイト参加してきました。
www.wiajapan.org 弥生では女性リーダーの育成を掲げ、リーダーの割合に目標値を設定しています。
確かに女性リーダーの割合が少ない部署があったり、社内役員に女性がいなかったりといった現状はあります。
note.yayoi-kk.co.jp 1年ほど前、2023年4月に公開された弥生公式note記事です。サムネイル画像に写っているのは男性。

弥生に限ったことではなく、どこの組織やチームにおいても、リーダーや役員をやりたい人が、女性という理由だけでその役割ができない、やりにくいのであれば変えなければいけません。
しかし、本当にそうなのでしょうか?性別問わず希望する仕事に就けることは重要だろうとは思います。
一方で、チームメンバーの構成、就業者、リーダーの人数、あらゆる男女比を1:1にしようとすることは、他の歪を生むことになるのではないだろうか?と考えていました。
そんな中「Women in Agile Japan」の開催を知りました。
アジャイルを推進するのにMenもWomenも関係ないだろうと思いながらも、せっかくの機会だから参加してみることにしました。

開催前日、東京では珍しく雪が降りました

Keynote

概要

タイトル:
個が輝く社会に向けて〜スポーツ界での挑戦〜
登壇者:
伊藤雅充さん 日本体育大学体育学部教授、博士(学術)、コーチングエクセレンスセンター長

登壇者の伊藤さんを紹介される際、司会である主催者が「登壇をお願いした理由」として以下をお話しされていました。

  • スクラムという用語自体もスポーツのスクラムから来ていて、アジャイルとスポーツとには親和性の高さがある
  • 開発の現場にある身体性や人間の関係性について別の視点から学べることがある

スポーツに関わっている方が、アジャイルのイベントでどういうお話しを展開していくのか、わくわくしました。

女性らしさ?

今までこの弥生開発者ブログで私の性別を明示したことはありません。今回は記事の特性上、性別を明記しておきます。私は女性として生まれました。
「首都圏ではない地方出身だから」「女の子だから」という理由で、習い事や進学に関して制限があったり強制があったりという経験はほとんどしていません。
私の意識や努力は関係なく、本当に環境に恵まれたことです。 この環境で育ったことで、私は、自分は性別に対してフラットな考え方をしていると思っていました。

今回のKeynoteを聞いて、幼少期の出来事を思い出しました。

  • 同い年の幼馴染だけでお菓子を買いに行く場面で「男の子は女の子をしっかり守って、いってらっしゃい。」と大人に見送られたこと
  • ルールがあいまいなヒーローごっこを横目に見ながらひとりで黙々とパズルをやっていたら、男の子の親御さんが「女の子は静かでいいね」と発言した場面に遭遇したこと

男の子は女の子を守る存在で、女の子はおとなしくしているべき存在なのだと、幼いころから少しずつ刷り込まれ続けていました。

私が最初に就職活動をした学生の時にも自分が女性であることを意識する機会がありました。

  • 「女性としてがんばってほしい」と期待の言葉をかけられたこと
  • 面接で「IT企業は男性が多いけれど、女性として男性の中で働くことはどのように思いますか?」と質問があったこと

働くのに男女は関係ないし、組織にどのような貢献の仕方をすることが女性としてがんばることになるのだろうか?と疑問に思っていました。
その後、プログラマからテスターにキャリアチェンジする際にも女性というワードが出てきました。

  • 異動前の所属の上司から「テスターは、女性には向いている職種だと思う」と納得のいかない背中の押され方をしたこと
  • 異動先のテスト部門の上司が「女性だけで構成するチームをつくってみたい、あなたを歓迎している」と言っていたこと

キャリアチェンジではなく、男性社会からのドロップアウトのように扱われたような気がしました。
不満のように書き連ねてしまっていますが、私は私と接して育ててくれた周りの大人や上司を責めるつもりはまったくありません。
Keynoteを聞いたことで、女性だからと制限や強制を受けることなくやりたいことを自由にやってきたと思っていた私にも「女性」というくくりの中で窮屈な思いをしたり過度な期待をされたことがあって、それに気づかないままだったり、違和感に蓋をしたりして過ごしてきたことを感じました。

男女平等を意識していた私の親世代は、男女平等に関する教育を受ける機会が少ない中で、それでも手探りで男女平等を考えてくれていたのでしょう。
それが女性就業率の推移として、確かに結果が出ています。
www.gender.go.jp

男女平等の教育を受け始めた私は、この考え方や推移をさらに前に進めなければいけない、それが女性リーダーの割合という目標になっているのだと理解しました。
「女性の活躍はリーダーになることだけなの?」という疑問はあります。
それでも一歩動いて新しいチャレンジをしていくことが必要なのだ、具体的に何をするのかは個々でも組織でも考えて実践していかなければいけないと強く感じました。

OST

オンサイトのOST (オープン・スペース・テクノロジー)に初めて参加しました。
Womenに関連するテーマを挙げるのかと思っていましたが、限定することなくテーマが挙がっていきます。
お昼ご飯を一緒に食べていた初対面の人たちからも後押しをしていただき、私もテーマを挙げました。

はじめて見たイーゼルパッドにもテンションが上がります。初心者にもやさしいOSTで安心感がありました。サポートしてくださったみなさま、ありがとうございます。

「OST初心者集まれ」イーゼルパッド

私がWomenに関するテーマで参加したのは、「女性の☓☓の集まりは抵抗ある。と女性に言われた。その心は?」です。

女性の集まりに抵抗がある?

あります。大いにあります。しかし、その理由をきちんと言語化したことがありませんでした。
しっかり考えてみたいと思ったのと、同じように抵抗がある人の意見を聞いてみたかったので、参加をしました。
ただ、参加したもののその場でうまく抵抗感を言葉にできなかったので、改めてまとめることにしました。

私は、Womenというくくりをつくって女性が集まることはマイノリティーである現状を嘆くだけに思えていて、そこから発展する話題になることが想像できていませんでした。
「うまくいかない現状について、同じ境遇の人が集まってブルースでも歌う気なのか?」と思っていたような気がします。
※私はブルースが好きです。ブルースは歌で表現するしかない状況でうまれた魂の叫びだと思っています。

音楽におけるブルースは1つのジャンルとして確立されました。
Womenについては、歌ったり叫んだり嘆いたりするのではなく、技術書を開いて学習をすること、実践の場でチャレンジして改善すること、チームで対話をして必要とされていることに着実に対応していくことでしか解決しないのではないかと思っていました。

今回、Women in Agile Tokyo 2024に参加して、「Women」に対して偏見や特別視をしていた自分に気がつくことができました。

全体を通して

WomenをターゲットにしたAgileの集まりに懐疑的だった私ですが、非常に充実したのしい1日を過ごしました。
Womenという会なのだから、おそらくほとんどが女性を自認する人があつまっているのだろうと考えていました。
実際には、参加者の比率は男女比は半々程度とのことでした。
イベントの終盤に「Womenとイベントタイトルをつけて、Womenをターゲットにして呼びかけてようやく女性が半分なのか」と感じたのですが、主催者から「Women in Agile Japan の実行委員としては男性の参加を呼び掛けてきました。ジェンダーギャップを生み出しているマイクロアグレッションなどの問題を考えるときに、男性や現行のマネジメント層の理解が重要になるからです。」というコメントをいただきました。

ソフトウェアテストシンポジウムJaSSTでは地域名ごとの開催の他に、「Review」という名称でレビューに焦点を当てた会があります。
これと同じような位置づけで、「Women」があるのだろうと考え始めました。
若手をターゲットにした「アンダー30」があってもいいだろうし、第二のキャリアを考える「オーバー60」があってもいいでしょう。それと同じで「Women」が自然に存在し、みんなで在り方を考えていければよいのだと感じています。
私は今まで「女性の割合」を見かけると「私が女性としてカウントされていいの?」と敬遠し、「だれかの数値目標が達成できるならまぁいいか」と深く考えていなかったということに気がつきました。

Women in Agile Tokyo 2024参加をきっかけに、今まで避けていた「Women」について、多様性について、しっかり向き合って考えていきます。


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

X(旧Twitter)に弥生株式会社エンジニア情報を開設しました

こんにちは、カトです。
昨年2023年、開発者向けの情報をお届けする弥生株式会社エンジニア情報のX(旧Twitter)アカウントを開設しました。
アカウント名は「弥生株式会社エンジニア情報」、IDは @yayoikk_dd です。
ぜひフォローよろしくお願いします。

もくにゃんのかわいいアイコンで情報をお届けします。

開発者向けアカウント開設のきっかけ

エンジニアに情報が届きにくい

弥生株式会社が運用しているX(旧Twitter)は、すでに2つあります。
弥生株式会社(公式) と、弥生カスタマーセンター(公式) です。
弥生株式会社(公式)は、弥生からのお知らせや、スモールビジネス向けのお役立ち情報を発信しています。そして、弥生カスタマーセンター(公式) は、製品のご利用に役立つ情報を中心に発信しています。

弥生株式会社エンジニア情報X(旧Twitter)を開設するまで、弥生が主催する勉強会もくテクの開催情報・弥生開発者ブログの更新情報・エンジニアの登壇情報・SpeakerDeckにアップロードした公開資料などエンジニアに関する情報は、弥生株式会社(公式)にて投稿してもらっていました。
多くのフォロワーがいるアカウントでたくさんの人に見てもらえていると実感する一方で、弥生株式会社(公式)のフォロワーが求める情報と違うのではないかと感じていました。
情報を届けたい層であるエンジニアに確実に情報を届けるためには、エンジニア情報に特化したアカウントがあった方がよいのではと考えました。

テックイベント中、運営情報を公式から送ることができない

弥生が主催する勉強会もくテクのイベントページの注意事項のひとつに
『配信トラブルのアナウンスはX(旧Twitter)でハッシュタグ「#もくテク」を付けてポストします』
という記載があります。
今のところ幸いなことに配信トラブルが発生することがなくスムーズに運営ができています。
ただ、実際に問題が発生したらどう対応するのかをもくテク運営チームで考えた時、誰かの個人アカウントを使うしかないということに気がつきました。
公式なイベントの運用に関して運営メンバーの個人に依存してしまうというのは仕組みとしてよくないですし、弥生株式会社(公式)を運営しているPRチームに何かあったときのために待機してもらうというのもコストがかかります。
この問題は、エンジニアが弥生株式会社エンジニア情報というX(旧Twitter)アカウントを運用することで解決できると考えました。
また、弥生株式会社エンジニア情報というX(旧Twitter)アカウントを運用することで、実況投稿も可能になりそうです。

アカウントの運用

2023年11月末にアカウントの運用を開始し、順調に、弥生が主催する勉強会もくテクの開催情報・弥生開発者ブログの更新情報・エンジニアの登壇情報・エンジニアが作成した公開資料に関する情報を発信しています。
AWS re:Invent参加者の現地写真や、アドベントカレンダーの情報も発信しています。

アカウントの運用ノウハウがなく運用メンバーも少人数のため、X(旧Twitter)上でコミュニケーションをとることは実施しておらず、発信した情報を見ていただくことや「いいね」やリポストで拡散していただくということから始めていこうと考えています。
フォロワー数が少なく、弥生株式会社(公式)にリポストしてもらってはじめて人目に触れるということも多いアカウントではありますが、これから少しずつ拡散力を持てるように、アカウント運用メンバーで検討していきます。

投稿する内容はオンラインホワイトボードにつくったカレンダーと付箋で管理しています。

2023年12月・2024年1月の投稿カレンダー

予定していた投稿が漏れることないように、そしてできるだけリアルタイムに情報を発信できるようにすることを考えています。

おまけ

エンジニア情報のX(旧Twitter)の投稿は2023年11月28日からですが、実はエンジニア情報に特化して発信する場があったらいいなと考えたのは、2023年3月のことでした。
このときは社内申請で戸惑ったり業務都合で頓挫してしまったのですが、2023年10月に始まった、業務時間の10%を使った「エンジニアの改善活動」で運用検討を再開し、投稿を始めることができました。

「エンジニアの改善活動」って何?弥生のエンジニアは改善活動で何をしているの?というお話しは、また別の記事で書いていきます。


弥生では一緒に働く仲間を募集しています。
創意工夫をしながら働けるチームにご興味のある方、ぜひエントリーお待ちしております。
herp.careers

CTOが「早くすることだけが正解じゃない - イケてる組織を作るための開発生産性とは?」に登壇します

こんにちは、開発本部のカトです。
1月29日(月)に開催の「早くすることだけが正解じゃない - イケてる組織を作るための開発生産性とは?」にCTO 佐々木 淳志(以下、佐々木さん)が登壇します。

「早くすることだけが正解じゃない - イケてる組織を作るための開発生産性とは?」

Findy Team+が主催の勉強会「開発生産性 Developer Productivity Engineering」です。
開発生産性をテーマに開催されている勉強会です。

登壇詳細

タイトル:『より早く良いものを多くのお客様に使ってもらうために。勘ではなくデータで判断する改善プロセス作り』
登壇開始時間:12:30
登壇者:弥生株式会社 CTO 佐々木 淳志
登壇内容詳細:
未定……??

「どんな発表する予定ですか?」と聞いてみたところ、「まだ完成していない」というワイルドな回答が返ってきました。
いったいどんなLTになるのでしょうか?
お昼休みの時間に、よりよい組織づくりをするための想いをぜひ聴いていただければと思います。

参加申し込み

developer-productivity-engineering.connpass.com 開催終了時間までお申し込み可能です。
ぜひ参加をご検討ください。

CTO 佐々木さんってどんな人?

佐々木さんを取り上げている記事をぜひご覧ください。 note.yayoi-kk.co.jp

ttj.paiza.jp

佐々木さんが書いたブログ記事もぜひご覧ください。 tech-blog.yayoi-kk.co.jp

もくにゃんが説明するポーズのモデルになったとか、なっていないとか。

ろくろを回すもくにゃん?


弥生では一緒に働く仲間を募集しています。
開発生産性を追求しているチームにご興味のある方、ぜひエントリーお待ちしております。
herp.careers

「ぞうぐみ」にかける思い

こんにちは、弥生でQAエンジニア兼スクラムマスターをしている、ぞうぐみ カトです。

「ぞうぐみ」って何?

私は「ぞうぐみ」のメンバーです。
私は現在、スマート証憑管理というプロダクトの開発に関わっています。
このプロダクトはスクラム開発手法を使っていて、2つのスクラムチームで開発を進めています。
2つのスクラムチームのうち、1つのチームが「ぞうぐみ」です。

最近、発表資料にも「ぞうぐみ」を入れています。 speakerdeck.com

speakerdeck.com

チーム名?

正直、私自身が「スクラムチームのチーム名って必要なの?」と思っています。

オンサイトの研修では、「まずはじめに、チームごとに自己紹介して、チーム名を決めて、アイコンを作ってください」というお題がでることがあります。
「お互いを呼び合うのに自己紹介が必要なのはわかる。チーム名とアイコンなんて、今日限りなんだからいらなくない?」「チーム名決めてる時間があるなら、研修の中身をはじめればいいのに」と、表面上は研修がうまくいくように笑顔で取り繕いながら、斜に構えていたひとりです。
仕事はゲームだと思っているので、「決められた時間内に自己紹介を終えて、チーム名を決めて、アイコンを描いたらクリア!」と考えていた部分もあります。
研修ではそんな感じで決めていたチーム名なので、自分がどんなチーム名に所属していたのかひとつも覚えていませんし、研修中にチーム名で呼ばれても自分のチームだと気づかず反応しなかったこともあったはずです。

たった1日の研修ならチーム名がなくてもよいかもしれません。
一方で、スクラムチームは、長く続きます。チームの一体感やコミュニケーションが重要です。
チームが共通の目標に向かっていくために、メンバーのつながりを強化していく必要があります。
チーム名をつけること自体が目標達成に直結することではないかもしれませんが、チーム名を全員で決めることが共感と愛着をもって業務を進めることの一つになるのではないかと考えました。
CSM研修でチーム名をつけることを学んだ私は、チームみんなでチーム名案を出し、投票で決めることにしました。

なんで「ぞうぐみ」?

スクラムチームに所属するメンバーのうち2人が、幼稚園で「ぞうぐみ」だったというのが大きな理由です。
「チーム名って必要なの?」と思っている私がチーム名を決めることになり、誰からも何の案も出ずに頓挫することを、何よりも恐れていました。
事前にチームメンバーとの1on1の機会があり、「チーム名どうする?」と話題に出したところ、偶然そのメンバーが幼稚園で「ぞうぐみ」だったことが判明し、「私も!私も!」と盛り上がりました。
全国各地に動物名の幼稚園があるのかな?「ぞうぐみ」のみんな、あつまれー!

「付箋にチーム名候補を書いて」と言われても、何もないところからチーム名を出すのは難しそうです。「ぞうぐみ」はネタのひとつとして使えるかもしれないと考え、付箋に「ぞうぐみ」と書いてみました。

「動物名いいね」から「うさぎさん」「カメさん」「アヒルさん」「北京ダック」…と動物に関連した付箋が並びます。
これはこれで楽しいけれど発散しない?チーム名決まるかな?と不安になりつつ、他の案も見ていきます。
「もう一つのスクラムチーム名が色の名前だから、併せて色の名前にする」という案や、外国語の単語案、チーム名を決める最中で出てきた会話からよさそうな単語を拾った案などたくさんの意見が出ました。
みんなが一歩引いた感じで、「チーム名なんてスクラムマスターが決めればいいじゃん」と言わなくて本当によかった。素敵なチームのみんな、ありがとう。

個人名が付箋にかいてあったので、ぼかしています

途中で「呼びやすい名前がいいから声に出してみよう」や「長い名前だったら略称も考えた方がいいかも」とわいわいします。
投票タイムでは、チーム名決めに参加していないはずの別のスクラムチームのメンバーがなぜか付箋にリアクションする場面もありました。ハプニングも含め、おもしろおかしくチーム名を決めることができました。

私は、イタリア語の「sfida(スフィーダ)」が、音も意味もかっこよくて好きでした。
以前所属していたスキーサークルの名前がドイツ語の「spitze(シュピッチェ)」だった記憶がよみがえってきます。私はスキーサークルでは30期で「spitze」の命名にまったく関わっていないのですが、おそらく「てっぺんをとろう!」みたいな意味合いだったのでしょう。
チームの会話の流れが動物に行ってなかったら、「sfida(スフィーダ)」を推していたと思います。

「スクラムチームにチーム名が必要なのかどうか」という点については、まだ結論は出ていません。
スマート証憑管理は2チームで開発しているので、この2チームを識別する記号は必要です。それが、「チームA」や「グループ1」ではなく、「ぞうぐみ」である必要があるのか、ないのか。
これについては、引き続き考えていきたいと思います。
ひとつ言えるのは、チーム名を活かすも活かさないも、チームメンバー次第ではありそうです。



ここからは、後付けでいいから、「ぞうぐみ」の名称を正当化していきます。

ぞうさん

スクラムには「3つ(プロダクトオーナー、スクラムマスター、開発者)の責任」や、「3つ(プロダクトバックログ、スプリントバックログ、インクリメント)の成果物」のように「3」がいくつか出ています。
「3」は、スクラムにとって、キーとなる値です。
都合よく解釈するべく、「5つ(スプリント、プランニング、デイリースクラム、レビュー、レトロスペクティブ)のイベント」を除外していることは把握しています。

ところで、みなさんは童謡「ぞうさん」を知っていますか?
おそらく日本で幼少期を過ごした多くの人にとって、初めて出会うワルツだと思います。(私が思っているだけです。調査はしていません。間違っているかもしれません。)
ワルツ……そう、3拍子です。童謡「ぞうさん」は、スクラムのキーとなる「3」にまつわる歌なのです。
ぞうさんは、「お鼻が長いのね」と、周りと違うことに対して受けた指摘に対し、「母さんも長いのよ」と堂々としています。みんな違っていいんです。
そんなぞうさんのように、私たちのチーム「ぞうぐみ」が「ぞうぐみ」流に進んでいくことに自信を持てる歌です。

私は、CSM研修のときも、ワルツの話しています。

3拍子なら「こいのぼり」でも「赤とんぼ」でも何でもいいんです。チームがスクラムの「3つの責任-5つのイベント-3つの成果物」を定期的に思い出す、きっかけになれば。

ということで、スクラム → キーとなる値「3」 → 3拍子 → ぞうさん → 「ぞうぐみ」と、ちょっとだけ強引な連想ゲームが成立しました。

象、死んだ魚、嘔吐

スクラムの、「5つのイベント」のひとつに、「レトロスペクティブ」があります。ふりかえりです。
私たちのチームは、ふりかえり手法KPT(A)をつかってスプリントごとにレトロスペクティブをしています。
チームで活動してからの期間が短く、チャレンジしている最中なので、続けたいこと(Keep)や、失敗して問題だと思っていたりチャレンジできなかったこと(Problem)がたくさん挙がり、今後試すこと(Try)が尽きない状態です。
しかし、ある程度の時間がたったら、Problemが見つからないことも、次のスプリントですぐ試せるようなTryが出てこなくなることもあるでしょう。
そんな時「必ず1人1つ以上出してください」と強制するのではなく、別のふりかえり手法もやっていきたいと考えています。
手段と目的を取り違えてはいけないですが、手段を変えることで今まで見えていなかったことが見えてくることもあります。
KPT(A)では見えなかったチームのよいことや改善したいことが、別のふりかえり手法を使うことで見えてくるかもしれません。

今後やってみたいふりかえり手法の一つに、チームの課題と向き合う手法「象、死んだ魚、嘔吐」があります。
手法名に出てくる「象」は、慣用句「The elephant in the room(部屋の中の象)」からとっているそうです。
部屋の中に象がいたら、明らかに異様で見えないはずはありません。ですが、あえて触れることを避け、タブーな話題や重大な問題を見て見ぬふりをする状況を意味しています。
そんな違和感のある象を「ぞうぐみ」として、自ら名乗ってしまうのです。

「ぞうぐみ」はそれぞれの違和感を大事にするチームを目指します。
そして、レトロスペクティブを含むチーム活動の場で、「こんなことをいったら空気を読めていないと思われるかな?」「進めにくいと思っているのは自分ひとりだけかもしれない」ではなく、「自分はこう思うけれどみんなはどう?」と 言えるチームにしていきます。
ということで、かなり強引ですが、「The elephant in the room(部屋の中の象)」に切り込み続けるチームという意味を込めてみます。



「ぞうぐみ」でやりたいこと

スクラムチームとして、「3つ(プロダクトオーナー、スクラムマスター、開発者)の責任」「5つ(スプリント、プランニング、デイリースクラム、レビュー、レトロスペクティブ)のイベント」「3つ(プロダクトバックログ、スプリントバックログ、インクリメント)の成果物」に忠実に業務を進めることで、お客さまに価値のあるサービスを届け続けること、関連するサービスの担当者やビジネスチームと連携をとり誰もが迷わずに価値を届けるための業務に専念できることを目標としていきます。
ここまでは、他のスクラムチームも似たようなことを掲げると考えています。

「ぞうぐみ」というチーム名が決まった時、「ぞうぐみのアイコンつくりたい」「ぞうぐみTシャツつくりたい」という声が出たことを、私は聞き逃しませんでした。
「難しいよね」「冗談でしょ?」とチーム内の雑談として閉じてしまって、このまま終了にしてしまうこともできるかと思いますが、私は、メンバーの声をぜひ実現したいと考えています。
それは、CSMやCSPOの研修を受講した際に、「スクラムはゲームだ」「スクラムチームが目標を達成できた際はご褒美があるべきだ」という内容があったからです。

動き出す前には、「本当にTシャツがほしい?実はパーカーの方が使い勝手がよい可能性は?」というような確認をした方がよいですし、グッズをつくるのに何から手をつけたらよいのかもわかっていません。
アイコンをつくれる人も探さなきゃいけないし……。
それでも、どんどんゲーム制を取り入れて、「ぞうぐみ」として、たのしんで業務に取り組んでいきます。



これからの「ぞうぐみ」の活躍にご期待ください。

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

herp.careers