女性の集まりに抵抗がある?あります。その理由をきちんと言語化したことがありませんでした。考えてみたいと思ったのと、同じように抵抗がある人の意見を聞いてみたかったので、参加をしました。参加したもののその場でうまく抵抗感を言葉にできなかったので、改めてまとめることにしました。私は、Womenというくくりをつくって女性が集まることはマイノリティーである現状を嘆くだけに思えていて、そこから発展する話題になることが想像できていませんでした。「うまくいかない現状について、同じ境遇の人が集まってブルースでも歌う気なのか?」と思っていたような気がします。※私はブルースが好きです。ブルースは歌で表現するしかない状況でうまれた魂の叫びだと思っています。音楽におけるブルースは1つのジャンルとして確立されました。Womenについては、歌ったり叫んだり嘆いたりするのではなく、技術書を開いて学習をすること、実践の場でチャレンジして改善すること、チームで対話をして必要とされていることに着実に対応していくことでしか解決しないのではないかと思っていました。2024に参加して、「Women」に対して偏見や特別視をしていた自分に気がつくことができました。全体を通してWomenをターゲットにしたAgileの集まりに懐疑的だった私ですが、非常に充実したのしい1日を過ごしました。Womenという会なのだから、おそらくほとんどが女性を自認する人があつまっているのだろうと考えていました。実際には、参加者の比率は男女比は半々程度とのことでした。実行委員としては男性の参加を呼び掛けてきました。ジェンダーギャップを生み出しているマイクロアグレッションなどの問題を考えるときに、男性や現行のマネジメント層の理解が重要になるからです。」というコメントをいただきました。ソフトウェアテストシンポジウムJaSSTでは地域名ごとの開催の他に、「Review」という名称でレビューに焦点を当てた会があります。これと同じような位置づけで、「Women」があるのだろうと考え始めました。若手をターゲットにした「アンダー30」があってもいいだろうし、第二のキャリアを考える「オーバー60」があってもいいでしょう。それと同じで「Women」が自然に存在し、みんなで在り方を考えていければよいのだと感じています。私は今まで「女性の割合」を見かけると「私が女性としてカウントされていいの?」と敬遠し、「だれかの数値目標が達成できるならまぁいいか」と深く考えていなかったということに気がつきました。2024参加をきっかけに、今まで避けていた「Women」について、多様性について、しっかり向き合って考えていきます。弥生では一緒に働く仲間を募集しています。エントリーお待ちしております。働き方こんにちは、カトです。昨年2023年、開発者向けの情報をお届けする弥生株式会社エンジニア情報のX(旧Twitter)アカウントを開設しました。フォローよろしくお願いします。んのかわいいアイコンで情報をお届けします。弥生株式会社のエンジニア向けアカウントです。これから、弥生株式会社のエンジニアのブログ・イベント・登壇情報を発信していきます。開発者向けアカウント開設のきっかけエンジニアに情報が届きにくい弥生株式会社が運用しているX(旧Twitter)は、すでに2つあります。弥生株式会社(公式)は、弥生からのお知らせや、スモールビジネス向けのお役立ち情報を発信しています。製品のご利用に役立つ情報を中心に発信しています。ブログの更新情報・エンジニアの登壇情報・SpeakerDeckにアップロードした公開資料などエンジニアに関する情報は、弥生株式会社(公式)にて投稿してもらっていました。多くのフォロワーがいるアカウントでたくさんの人に見てもらえていると実感する一方で、弥生株式会社(公式)のフォロワーが求める情報と違うのではないかと感じていました。情報を届けたい層であるエンジニアに確実に情報を届けるためには、エンジニア情報に特化したアカウントがあった方がよいのではと考えました。テックイベント中、運営情報を公式から送ることができない弥生が主催する勉強会もくテクのイベントページの注意事項のひとつに『配信トラブルのアナウンスはX(旧Twitter)でハッシュタグ「#もくテク」を付けてポストします』という記載があります。今のところ幸いなことに配信トラブルが発生することがなくスムーズに運営ができています。実際に問題が発生したらどう対応するのかをもくテク運営チームで考えた時、誰かの個人アカウントを使うしかないということに気がつきました。公式なイベントの運用に関して運営メンバーの個人に依存してしまうというのは仕組みとしてよくないですし、弥生株式会社(公式)を運営しているPRチームに何かあったときのために待機してもらうというのもコストがかかります。この問題は、エンジニアが弥生株式会社エンジニア情報というX(旧Twitter)アカウントを運用することで解決できると考えました。弥生株式会社エンジニア情報というX(旧Twitter)アカウントを運用することで、実況投稿も可能になりそうです。ブログの更新情報・エンジニアの登壇情報・エンジニアが作成した公開資料に関する情報を発信しています。re:Invent参加者の現地写真や、アドベントカレンダーの情報も発信しています。素敵な学びの機会になりますように。AWS関連が7件、ChatGPTが3件、キャリアチェンジが3件と、2023年の弥生エンジニアらしいラインナップです。見逃した記事、もう一度読みたい記事、ぜひご覧ください。2023年12月26日アカウントの運用ノウハウがなく運用メンバーも少人数のため、X(旧Twitter)上でコミュニケーションをとることは実施しておらず、発信した情報を見ていただくことや「いいね」やリポストで拡散していただくということから始めていこうと考えています。フォロワー数が少なく、弥生株式会社(公式)にリポストしてもらってはじめて人目に触れるということも多いアカウントではありますが、これから少しずつ拡散力を持てるように、アカウント運用メンバーで検討していきます。投稿する内容はオンラインホワイトボードにつくったカレンダーと付箋で管理しています。予定していた投稿が漏れることないように、そしてできるだけリアルタイムに情報を発信できるようにすることを考えています。おまけエンジニア情報のX(旧Twitter)の投稿は2023年11月28日からですが、実はエンジニア情報に特化して発信する場があったらいいなと考えたのは、2023年3月のことでした。このときは社内申請で戸惑ったり業務都合で頓挫してしまったのですが、2023年10月に始まった、業務時間の10%を使った「エンジニアの改善活動」で運用検討を再開し、投稿を始めることができました。「エンジニアの改善活動」って何?弥生のエンジニアは改善活動で何をしているの?というお話しは、また別の記事で書いていきます。弥生では一緒に働く仲間を募集しています。創意工夫をしながら働けるチームにご興味のある方、ぜひエントリーお待ちしております。イケてる組織を作るための開発生産性とは?」に登壇します告知こんにちは、開発本部のカトです。淳志(以下、佐々木さん)が登壇します。Engineering」です。開発生産性をテーマに開催されている勉強会です。登壇詳細タイトル:『より早く良いものを多くのお客様に使ってもらうために。登壇内容詳細:未定......??「どんな発表する予定ですか?」と聞いてみたところ、「まだ完成していない」というワイルドな回答が返ってきました。どんなLTになるのでしょうか?お昼休みの時間に、よりよい組織づくりをするための想いをぜひ聴いていただければと思います。開催終了時間までお申し込み可能です。参加をご検討ください。佐々木さんってどんな人?佐々木さんを取り上げている記事をぜひご覧ください。note.yayoi-kk.co.jpttj.paiza.jp佐々木さんが書いたブログ記事もぜひご覧ください。tech-blog.yayoi-kk.co.jpもくにゃんが説明するポーズのモデルになったとか、なっていないとか。ろくろを回すもくにゃん?弥生では一緒に働く仲間を募集しています。開発生産性を追求しているチームにご興味のある方、ぜひエントリーお待ちしております。「ぞうぐみ」って何?私は「ぞうぐみ」のメンバーです。私は現在、スマート証憑管理というプロダクトの開発に関わっています。このプロダクトはスクラム開発手法を使っていて、2つのスクラムチームで開発を進めています。2つのスクラムチームのうち、1つのチームが「ぞうぐみ」です。最近、発表資料にも「ぞうぐみ」を入れています。speakerdeck.comspeakerdeck.comチーム名?正直、私自身が「スクラムチームのチーム名って必要なの?」と思っています。オンサイトの研修では、「まずはじめに、チームごとに自己紹介して、チーム名を決めて、アイコンを作ってください」というお題がでることがあります。「お互いを呼び合うのに自己紹介が必要なのはわかる。チーム名とアイコンなんて、今日限りなんだからいらなくない?」「チーム名決めてる時間があるなら、研修の中身をはじめればいいのに」と、表面上は研修がうまくいくように笑顔で取り繕いながら、斜に構えていたひとりです。仕事はゲームだと思っているので、「決められた時間内に自己紹介を終えて、チーム名を決めて、アイコンを描いたらクリア!」と考えていた部分もあります。研修ではそんな感じで決めていたチーム名なので、自分がどんなチーム名に所属していたのかひとつも覚えていませんし、研修中にチーム名で呼ばれても自分のチームだと気づかず反応しなかったこともあったはずです。1日の研修ならチーム名がなくてもよいかもしれません。一方で、スクラムチームは、長く続きます。チームの一体感やコミュニケーションが重要です。チームが共通の目標に向かっていくために、メンバーのつながりを強化していく必要があります。チーム名をつけること自体が目標達成に直結することではないかもしれませんが、チーム名を全員で決めることが共感と愛着をもって業務を進めることの一つになるのではないかと考えました。CSM研修でチーム名をつけることを学んだ私は、チームみんなでチーム名案を出し、投票で決めることにしました。なんで「ぞうぐみ」?スクラムチームに所属するメンバーのうち2人が、幼稚園で「ぞうぐみ」だったというのが大きな理由です。「チーム名って必要なの?」と思っている私がチーム名を決めることになり、誰からも何の案も出ずに頓挫することを、何よりも恐れていました。事前にチームメンバーとの1on1の機会があり、「チーム名どうする?」と話題に出したところ、偶然そのメンバーが幼稚園で「ぞうぐみ」だったことが判明し、「私も!私も!」と盛り上がりました。全国各地に動物名の幼稚園があるのかな?「ぞうぐみ」のみんな、あつまれー!「付箋にチーム名候補を書いて」と言われても、何もないところからチーム名を出すのは難しそうです。「ぞうぐみ」はネタのひとつとして使えるかもしれないと考え、付箋に「ぞうぐみ」と書いてみました。「動物名いいね」から「うさぎさん」「カメさん」「アヒルさん」「北京ダック」...と動物に関連した付箋が並びます。これはこれで楽しいけれど発散しない?チーム名決まるかな?と不安になりつつ、他の案も見ていきます。「もう一つのスクラムチーム名が色の名前だから、併せて色の名前にする」という案や、外国語の単語案、チーム名を決める最中で出てきた会話からよさそうな単語を拾った案などたくさんの意見が出ました。みんなが一歩引いた感じで、「チーム名なんてスクラムマスターが決めればいいじゃん」と言わなくて本当によかった。素敵なチームのみんな、ありがとう。個人名が付箋にかいてあったので、ぼかしています途中で「呼びやすい名前がいいから声に出してみよう」や「長い名前だったら略称も考えた方がいいかも」とわいわいします。投票タイムでは、チーム名決めに参加していないはずの別のスクラムチームのメンバーがなぜか付箋にリアクションする場面もありました。ハプニングも含め、おもしろおかしくチーム名を決めることができました。私は、イタリア語の「sfida(スフィーダ)」が、音も意味もかっこよくて好きでした。以前所属していたスキーサークルの名前がドイツ語の「spitze(シュピッチェ)」だった記憶がよみがえってきます。私はスキーサークルでは30期で「spitze」の命名にまったく関わっていないのですが、おそらく「てっぺんをとろう!」みたいな意味合いだったのでしょう。チームの会話の流れが動物に行ってなかったら、「sfida(スフィーダ)」を推していたと思います。「スクラムチームにチーム名が必要なのかどうか」という点については、まだ結論は出ていません。スマート証憑管理は2チームで開発しているので、この2チームを識別する記号は必要です。それが、「チームA」や「グループ1」ではなく、「ぞうぐみ」である必要があるのか、ないのか。これについては、引き続き考えていきたいと思います。ひとつ言えるのは、チーム名を活かすも活かさないも、チームメンバー次第ではありそうです。ここからは、後付けでいいから、「ぞうぐみ」の名称を正当化していきます。ぞうさんスクラムには「3つ(プロダクトオーナー、スクラムマスター、開発者)の責任」や、「3つ(プロダクトバックログ、スプリントバックログ、インクリメント)の成果物」のように「3」がいくつか出ています。「3」は、スクラムにとって、キーとなる値です。都合よく解釈するべく、「5つ(スプリント、プランニング、デイリースクラム、レビュー、レトロスペクティブ)のイベント」を除外していることは把握しています。ところで、みなさんは童謡「ぞうさん」を知っていますか?おそらく日本で幼少期を過ごした多くの人にとって、初めて出会うワルツだと思います。(私が思っているだけです。間違っているかもしれません。)ワルツ......そう、3拍子です。童謡「ぞうさん」は、スクラムのキーとなる「3」にまつわる歌なのです。ぞうさんは、「お鼻が長いのね」と、周りと違うことに対して受けた指摘に対し、「母さんも長いのよ」と堂々としています。みんな違っていいんです。そんなぞうさんのように、私たちのチーム「ぞうぐみ」が「ぞうぐみ」流に進んでいくことに自信を持てる歌です。私は、CSM研修のときも、ワルツの話しています。スクラムマスター研修、2日間終了。三拍子が、3つの責任や3つの作成物の「3」と同じ。5つのイベントとはうまく絡められなかったけど、スクラムの時に聞くにはぴったり曲じゃないかと思う。2023年6月25日3拍子なら「こいのぼり」でも「赤とんぼ」でも何でもいいんです。チームがスクラムの「3つの責任-5つのイベント-3つの成果物」を定期的に思い出す、きっかけになれば。「ぞうぐみ」と、ちょっとだけ強引な連想ゲームが成立しました。象、死んだ魚、嘔吐スクラムの、「5つのイベント」のひとつに、「レトロスペクティブ」があります。私たちのチームは、ふりかえり手法KPT(A)をつかってスプリントごとにレトロスペクティブをしています。チームで活動してからの期間が短く、チャレンジしている最中なので、続けたいこと(Keep)や、失敗して問題だと思っていたりチャレンジできなかったこと(Problem)がたくさん挙がり、今後試すこと(Try)が尽きない状態です。ある程度の時間がたったら、Problemが見つからないことも、次のスプリントですぐ試せるようなTryが出てこなくなることもあるでしょう。そんな時「必ず1人1つ以上出してください」と強制するのではなく、別のふりかえり手法もやっていきたいと考えています。手段と目的を取り違えてはいけないですが、手段を変えることで今まで見えていなかったことが見えてくることもあります。KPT(A)では見えなかったチームのよいことや改善したいことが、別のふりかえり手法を使うことで見えてくるかもしれません。今後やってみたいふりかえり手法の一つに、チームの課題と向き合う手法「象、死んだ魚、嘔吐」があります。room(部屋の中の象)」からとっているそうです。部屋の中に象がいたら、明らかに異様で見えないはずはありません。触れることを避け、タブーな話題や重大な問題を見て見ぬふりをする状況を意味しています。そんな違和感のある象を「ぞうぐみ」として、自ら名乗ってしまうのです。「ぞうぐみ」はそれぞれの違和感を大事にするチームを目指します。言えるチームにしていきます。room(部屋の中の象)」に切り込み続けるチームという意味を込めてみます。「ぞうぐみ」でやりたいことスクラムチームとして、「3つ(プロダクトオーナー、スクラムマスター、開発者)の責任」「5つ(スプリント、プランニング、デイリースクラム、レビュー、レトロスペクティブ)のイベント」「3つ(プロダクトバックログ、スプリントバックログ、インクリメント)の成果物」に忠実に業務を進めることで、お客さまに価値のあるサービスを届け続けること、関連するサービスの担当者やビジネスチームと連携をとり誰もが迷わずに価値を届けるための業務に専念できることを目標としていきます。ここまでは、他のスクラムチームも似たようなことを掲げると考えています。「ぞうぐみ」というチーム名が決まった時、「ぞうぐみのアイコンつくりたい」「ぞうぐみTシャツつくりたい」という声が出たことを、私は聞き逃しませんでした。「難しいよね」「冗談でしょ?」とチーム内の雑談として閉じてしまって、このまま終了にしてしまうこともできるかと思いますが、私は、メンバーの声をぜひ実現したいと考えています。それは、CSMやCSPOの研修を受講した際に、「スクラムはゲームだ」「スクラムチームが目標を達成できた際はご褒美があるべきだ」という内容があったからです。動き出す前には、「本当にTシャツがほしい?実はパーカーの方が使い勝手がよい可能性は?」というような確認をした方がよいですし、グッズをつくるのに何から手をつけたらよいのかもわかっていません。アイコンをつくれる人も探さなきゃいけないし......。それでも、どんどんゲーム制を取り入れて、「ぞうぐみ」として、たのしんで業務に取り組んでいきます。これからの「ぞうぐみ」の活躍にご期待ください。弥生では一緒に働く仲間を募集しています。24日目のエントリーです。弥生株式会社の田邊です。普段はサービス開発チームのアプリケーションエンジニアをしています。re:Invent2023に現地参加し、AWSへのモチベーションが高まりました。Qの発表の様子AWSを使う開発者にとってかなり便利そうなサービスなので、今回はどの程度使えるのものなのかを実際に触って確認してみました。Qとは、生成AIを活用した業務向けのアシスタントサービスです。今話題になっているChatGPTやCopilotなどと競合するサービスです。応答形式の会話やチャットボット連携、ソースコードの変換サポートなど様々な機能がありますが、私が特に気になったのはトラブルシューティングの補佐です。AWSでの開発を行っていると、少しの設定ミスでアプリケーションが動かなくなることは少なくありません。そのようなケースの場合、大抵は発生したエラーから原因を予測し、設定を見直すことになります。十分に成熟した開発者でなければ、原因をすぐに特定することは簡単ではありません。Qを使えば、トラブル発生時の原因特定が簡単になるのでは!?」ということでした。本当にそれほど上手くいくのか、実際に触って検証してみることにしました。Qのチャットを使って検証してみます。Qは日本語サポートされていないため、以降の検証は英語となります。英語が分からない方にも伝わるように日本語で補足します。分かりやすくするために一部和訳を簡略化しています。AWSについての質問まずは軽くお試しとして、AWSのサービスに関する質問をしてみます。Scalingを用いた自動デプロイでもできます。高可用性の確保のため、ELBを使って負荷分散を実現します。データベースは、リレーショナルデータベースならMySQLやAurora、NoSQLデータベースならDynamoDBが使えます。Beanstalkを用います。DynamoDBを用いつつLambdaを使って実現できます。CodePipelineを用いてCDを実現できます。こちらが曖昧な質問をしているので仕方ないですが、一般的な答えが返ってきました。Qは対話式なので、↑の回答について追加で質問してみます。Scalingを用いた自動デプロイ」について、両者の違いが分からなかったとして質問してみます。Codeを実現するためのサービス。ScalingはEC2インスタンスを、必要に応じて自動でスケーリングするサービス。Scalingグループを含め、インフラ全体をモデル化することができます。Scalingグループ内のEC2インスタンスの操作のみを提供します。(省略)こちらも一般的な回答ですが、3.のように、「こういう違いがある」とピンポイントで説明してくれるのは良いですね。AWSの公式ドキュメントを読めばわかる内容ではありますが、特に日本語の公式ドキュメントは何を言いたいのか分かりづらい初学者には理解しづらいことも多いので、対話式で分かることも大きいのではないでしょうか(とはいえ、これらの内容であればChatGPTなどの競合サービスでも十分な回答が得られそうですが)。トラブルシューティング1:IAMロールそれでは本題に入りましょう。Storeの値をLambdaから取得するという以下の構成を作成しました。Store実際のコード等は以下になります。Storeに格納された値を取得し、その値を返すLambda関数(左)Lambdaが取得する対象のパラメーター(右)さて、この構成であれば、LambdaにはParameterStoreから値を取得するためのポリシーが付与されている必要があります。今回はあえて誤ったポリシーを付与しようと思います。「parameter/ParameterKey」となるべき箇所が、「parameter/ParameterKez」となっているポリシーを付与したロールをLambdaに紐づけました。Lambdaをテスト実行すると失敗します。テスト実行失敗の画面。権限が無いというエラーが出る。「getParameterPolicyのポリシーで権限を付与しているのに、なぜLambdaファンクションがPrameterKeyパラメーターを取得する権限を持っていないのか?」と質問しています。AWS内のリソースも参照してくれるようなので、ARNだけ渡して質問しているのがポイント。回答GetParametersを許可するロールは付与されているようですが、ARNで指定した特定のパラメーターを取得するための権限がありません。以下のことを試してください。特定のARNのパラメーターの取得を許可するようにポリシーを更新してください。広めのポリシーではなく、パラメーターを取得するための最小のポリシーを設定してください。Lambdaのロールに正しくポリシーがアタッチされているか確認してください。最新の許可が設定されているか確認するためにLambda関数を再実行してください。所々怪しい回答(実際には付与していないGetParametersのポリシーがあると言っていたり、権限が無いというエラーにもかかわらず権限を絞るように言っていたり)もありますが、ARNが間違っているということはある程度読み取れる回答が返ってきました。したらピンポイントで「この部分のスペリングが間違っていないか」と指摘をもらえるのではと期待して色々な聞き方をしてみましたが、そこまでは上手くいきませんでした。トラブルシューティング2:ネットワーク続いて、ネットワーク系のトラブルについても実験してみました。以下のように、パブリックサブネットにEC2インスタンスを配置します。EC2インスタンスにはWordPressがインストールされている状態です。IPを付与しているため、ネットワークが正しく設定されていればパブリックIPでアクセス可能です。今回はあえてセキュリティグループの設定を間違えてみます。EC2インスタンスに、インバウンドルールが存在しないセキュリティグループをアタッチします。インバウンドルールが存在しないセキュリティグループ当然、パブリックIPでアクセスしようとしてもアクセスできません。回答ネットワーク接続の問題です。Qがネットワーク接続の問題のトラブルシューティングに役立ちます。プレビュー版を試用できます。Qとつながっているようです。Analyzerを開きます。Q同様にチャットで質問できます。IPを使ってEC2インスタンスに接続できないようです。接続またはセキュリティの設定の問題がある可能性があります。分析結果の詳細を見てみます(ここは日本語)インバウンドルールが適用できていないということが分かりました。Analyzerと変わらないと思いますが、対話形式で分かるのでAWS初学者には使いやすいかもしれません。個人の印象ですが、ある程度のトラブルシューティングはできるものの、核心を突いた回答までは得られないかなと感じました。ある程度AWSを理解できている人にとってはサポートになると思いますが、少なくとも現状ではAWSがほとんど分からない人が使ってAWSを使いこなせるようになるものではないかもしれません。Qはここで紹介した以外にも様々な機能があるので、また様々な活用方法を探してみたいと思います。ここまで読んでいただいてありがとうございました。さいごに弥生株式会社では一緒に働くエンジニアを募集しています!詳細は↓よりご確認ください。