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

Amazon Qでトラブルシューティングしてみた【和訳付き】

この記事は弥生 Advent Calendar 2023 の24日目のエントリーです。

はじめに

こんにちは。弥生株式会社の田邊です。普段はサービス開発チームのアプリケーションエンジニアをしています。 今年の11月末にアメリカのラスベガスでAWS re:Invent2023に現地参加し、AWSへのモチベーションが高まりました。

(どれくらい高まったかは先日私が執筆した↓の記事をご覧ください) tech-blog.yayoi-kk.co.jp

AWS re:Invent2023でNew Launchとして発表されたサービスはたくさんありましたが、その中で私が着目したのはAmazon Qです。

KeynoteでのAmazon Qの発表の様子

AWSを使う開発者にとってかなり便利そうなサービスなので、今回はどの程度使えるのものなのかを実際に触って確認してみました。

Amazon Q

Amazon Qとは、生成AIを活用した業務向けのアシスタントサービスです。今話題になっているChatGPTやCopilotなどと競合するサービスです。 応答形式の会話やチャットボット連携、ソースコードの変換サポートなど様々な機能がありますが、私が特に気になったのはトラブルシューティングの補佐です。

AWSでの開発を行っていると、少しの設定ミスでアプリケーションが動かなくなることは少なくありません。そのようなケースの場合、大抵は発生したエラーから原因を予測し、設定を見直すことになります。 しかし、十分に成熟した開発者でなければ、原因をすぐに特定することは簡単ではありません。 私がAmazon Qについての発表を聞いたときに思ったのは、「Amazon Qを使えば、トラブル発生時の原因特定が簡単になるのでは!?」ということでした。 しかし、本当にそれほど上手くいくのか、実際に触って検証してみることにしました。

触ってみた

実際に業務支援Amazon Qのチャットを使って検証してみます。

※Amazon Qは日本語サポートされていないため、以降の検証は英語となります。英語が分からない方にも伝わるように日本語で補足します。分かりやすくするために一部和訳を簡略化しています。

AWSについての質問

まずは軽くお試しとして、AWSのサービスに関する質問をしてみます。

AWSサービスについての質問

「 データベースを持つウェブアプリケーションをデプロイするにはどうすればよいですか?」

回答

1. EC2を使います。手動でのローンチでもCloudFormationやEC2 Auto Scalingを用いた自動デプロイでもできます。
2. 高可用性の確保のため、ELBを使って負荷分散を実現します。
3. データベースは、リレーショナルデータベースならMySQLやAurora、NoSQLデータベースならDynamoDBが使えます。
4. 自動デプロイのためにElastic Beanstalkを用います。
5. サーバーレスアプリケーションであれば、API GatewayやS3, DynamoDBを用いつつLambdaを使って実現できます。
6. CodePipelineを用いてCDを実現できます。

こちらが曖昧な質問をしているので仕方ないですが、一般的な答えが返ってきました。Amazon Qは対話式なので、↑の回答について追加で質問してみます。 回答の1.の「CloudFormationやEC2 Auto Scalingを用いた自動デプロイ」について、両者の違いが分からなかったとして質問してみます。

追加質問

「CloudFormationとEC2 Auto Scalingの違いは何ですか?」

回答

1. CloudFormationはInfrastructure as Codeを実現するためのサービス。
2. EC2 Auto ScalingはEC2インスタンスを、必要に応じて自動でスケーリングするサービス。
3. CloudFormationを使うと、Auto Scalingグループを含め、インフラ全体をモデル化することができます。Auto Scalingはそれ自体ではAuto Scalingグループ内のEC2インスタンスの操作のみを提供します。
4. (省略)
5. (省略)

こちらも一般的な回答ですが、3.のように、「こういう違いがある」とピンポイントで説明してくれるのは良いですね。 AWSの公式ドキュメントを読めばわかる内容ではありますが、特に日本語の公式ドキュメントは何を言いたいのか分かりづらい初学者には理解しづらいことも多いので、対話式で分かることも大きいのではないでしょうか(とはいえ、これらの内容であればChatGPTなどの競合サービスでも十分な回答が得られそうですが)。

トラブルシューティング①:IAMロール

それでは本題に入りましょう。検証用に、Parameter Storeの値をLambdaから取得するという以下の構成を作成しました。

Lambda+Parameter Store

実際のコード等は以下になります。

Parameter Storeに格納された値を取得し、その値を返すLambda関数(左)Lambdaが取得する対象のパラメーター(右)

さて、この構成であれば、LambdaにはParameterStoreから値を取得するためのポリシーが付与されている必要があります。今回はあえて誤ったポリシーを付与しようと思います。

タイポしたポリシー

「parameter/ParameterKey」となるべき箇所が、「parameter/ParameterKez」となっているポリシーを付与したロールをLambdaに紐づけました。当然、Lambdaをテスト実行すると失敗します。

テスト実行失敗の画面。権限が無いというエラーが出る。

このエラーについて、Amazon Qに質問してみます。

エラーについて質問

「なぜLambdaファンクションがParameterKeyパラメーターを取得する権限を持っていないのか?」 「getParameterPolicyのポリシーで権限を付与しているのに、なぜLambdaファンクションがPrameterKeyパラメーターを取得する権限を持っていないのか?」と質問しています。AWS内のリソースも参照してくれるようなので、ARNだけ渡して質問しているのがポイント。

回答

GetParametersを許可するロールは付与されているようですが、ARNで指定した特定のパラメーターを取得するための権限がありません。以下のことを試してください。
1. 特定のARNのパラメーターの取得を許可するようにポリシーを更新してください。
2. 広めのポリシーではなく、パラメーターを取得するための最小のポリシーを設定してください。
3. Lambdaのロールに正しくポリシーがアタッチされているか確認してください。
4. 最新の許可が設定されているか確認するためにLambda関数を再実行してください。

所々怪しい回答(実際には付与していないGetParametersのポリシーがあると言っていたり、権限が無いというエラーにもかかわらず権限を絞るように言っていたり)もありますが、ARNが間違っているということはある程度読み取れる回答が返ってきました。もしかしたらピンポイントで「この部分のスペリングが間違っていないか」と指摘をもらえるのではと期待して色々な聞き方をしてみましたが、そこまでは上手くいきませんでした。

トラブルシューティング②:ネットワーク

続いて、ネットワーク系のトラブルについても実験してみました。以下のように、パブリックサブネットにEC2インスタンスを配置します。EC2インスタンスにはWordPressがインストールされている状態です。

EC2にはElastic IPを付与しているため、ネットワークが正しく設定されていればパブリックIPでアクセス可能です。今回はあえてセキュリティグループの設定を間違えてみます。

EC2インスタンスに、インバウンドルールが存在しないセキュリティグループをアタッチします。

インバウンドルールが存在しないセキュリティグループ

当然、パブリックIPでアクセスしようとしてもアクセスできません。

アクセス結果

そこで、このエラーについてAmazon Qに質問してみます。

エラーについて質問

「なぜ[パブリックIPのURL]でEC2インスタンスにアクセスできないのですか?」

回答

ネットワーク接続の問題です。VPC Reachable AnalyzerとAmazon Qがネットワーク接続の問題のトラブルシューティングに役立ちます。プレビュー版を試用できます。(バージニア北部リージョンで利用可能)

VPC Reachable AnalyzerというVPCのリソース間の接続を確認できるサービスがAmazon Qとつながっているようです。回答のリンクから AWS Q for Reachability Analyzerを開きます。 Amazon Q同様にチャットで質問できます。

Reachable Analyzerでの質問

「なぜ[パブリックIPのURL]でEC2インスタンスにアクセスできないのですか?」

回答

public IPを使ってEC2インスタンスに接続できないようです。接続またはセキュリティの設定の問題がある可能性があります。分析結果は以下。

分析結果の詳細を見てみます(ここは日本語)

インバウンドルールが適用できていないということが分かりました。 この分析結果は既存のVPC Reachable Analyzerと変わらないと思いますが、対話形式で分かるのでAWS初学者には使いやすいかもしれません。

まとめ

以上、Amazon Qの検証でした。個人の印象ですが、ある程度のトラブルシューティングはできるものの、核心を突いた回答までは得られないかなと感じました。 ある程度AWSを理解できている人にとってはサポートになると思いますが、少なくとも現状ではAWSがほとんど分からない人が使ってAWSを使いこなせるようになるものではないかもしれません。

Amazon Qはここで紹介した以外にも様々な機能があるので、また様々な活用方法を探してみたいと思います。 ここまで読んでいただいてありがとうございました。

さいごに

弥生株式会社では一緒に働くエンジニアを募集しています!詳細は↓よりご確認ください。

herp.careers