AWS re:Invent 2024 参加報告会 開催します!

こんにちは!弥生でエンジニアをしている中尾です。

皆さん、もくテク はご存知ですか?
もくテク は弥生株式会社が主催している社外向け勉強会です。

久しぶりにもくテク運営より開発者ブログを書いてみました。
好評であれば継続していこうと思います!
よろしければしばらくお付き合いください!

イベントの概要

https://mokuteku.connpass.com/event/340760/mokuteku.connpass.com

2025年1月29日()19:00 から、もくテク1月会「AWS re:Invent 2024 参加報告会」を開催いたします!

「AWS re:Invent」はAWSが毎年開催している全世界規模の学習型カンファレンスになります。
例年ラスベガスで開催されていますが、実は弥生の選抜メンバーが毎年現地まで行き参加しています!

今回のもくテクでは、LT&座談会形式で実際に参加したメンバーに「AWS re:Invent」の思い出や普段の業務でのAWSの利用シーンについて語ってもらいます!

LTの概要

もくテク定番のLT(Lightning Talk)になります!
タイトルを紹介するので気になる発表があった方はぜひお申し込みください!

LT1

「フロントエンドとバックエンドの非同期連携パターンと弥生Nextの事例紹介 (仮)」になります。
発表者の木村さんが re:Inventの記事を投稿しているので、ぜひご一緒にご覧ください。

tech-blog.yayoi-kk.co.jp

LT2

「Amazon OpenSearchのコスト最適化とZeroETLへの期待」になります。
発表者の今泉さんも re:Inventの記事を投稿しているので、ぜひご一緒にご覧ください。

tech-blog.yayoi-kk.co.jp

LT3

「re:Inventで学んだWebシステム運用のBad Dayへの備え方(仮)」になります。
発表者の宮崎さんも re:Inventの記事を投稿しているので、ぜひご一緒にご覧ください。

tech-blog.yayoi-kk.co.jp

LT4

「AWS re:Inventで感じた世界に見る生成AIの競争」になります。
re:Inventとは別ですが、発表者の髙瀬さんが社内の勉強会について記事を投稿しているので、ぜひご一緒にご覧ください。

tech-blog.yayoi-kk.co.jp

座談会

本イベントではLT登壇者による座談会を行います。
イベント中に視聴者の皆様から質問を募集しますので、遠慮なくご質問ください!

イベント申込ページ

イベントの申し込みはconnpassのイベントページからお願いいたします!
ほかの媒体は取り扱っておりませんのでご了承ください。 https://mokuteku.connpass.com/event/340760/mokuteku.connpass.com

過去のイベント

もくテクでは、過去のイベントをYou Tubeで公開しています。

一覧はこちら もくテク配信アーカイブ - YouTube

昨年度のre:Invent回はこちら

youtu.be

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

herp.careers

AWSイベントに登壇します

インフラチームでAWSの運用保守をしているねぎです。こんにちは。

1月30日(木)開催の2025クラウドガバナンスはこう変わる!マルチアカウント運用のre:Invent最新情報と活用例にて、登壇をします。

aws-startup-lofts.com

このブログは告知です。

2025クラウドガバナンスはこう変わる!マルチアカウント運用のre:Invent最新情報と活用例 とは

タイトルにもありますが、昨年行われたAWS最大規模のイベント「re:Invent」の最新情報をAWSさんからお話いただき、その後各社の事例として今回は「マルチアカウント運用」をテーマに活用事例をお話するイベントとなっております。

イベント前日にはもくテクで、弥生社員が昨年参加したre:Invent参加報告会も予定されています。こちらも是非ご参加いただければと思います。

発表のきっかけ

2022年5月のもくテク発表です。この時に「マルチアカウント運用」に関して発表していました。

mokuteku.connpass.com

その時の発表資料をAWS社内でも活用いただいているということで、今回のイベントテーマにも沿っていて、その後2年間でどういう進化を遂げたかをお話して来ようと思っています。

speakerdeck.com

発表概要

タイトル:「少数精鋭で200+アカウントを支える!弥生の「CSGO活動(Cost、Security、Governance、Other)」とは」

2年前のもくテク発表時は、AWSアカウントが100アカウント近くなってきた時のお話でした。

そこから倍以上のアカウント数となりました。。。(あっという間に)

2年前までは私一人で運用をしていましたが、今では私含めて3人!!(人数は3倍に)

それでも少人数だと思いますので、少人数でこの規模を運用していくポイントとして4つの取り組んだ内容をイベントでは紹介します。

  • コスト最適化(Cost)
  • セキュリティ強化(Security)
  • ガバナンス強化(Governance)
  • 未来を実現するためのインフラ基盤整備(Other)

上記4つのポイントはCSGO活動(Cost、Security、Governance、Other)として、それぞれの頭文字を取って勝手に社内で呼んでいます。

これからAWSでマルチアカウント環境を検討されている方、すでにマルチアカウント環境を運用されている方の気づきやヒントになると思っています。

弥生では、一緒に働く仲間を募集しています。
herp.careers
弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp

弥生アドベントカレンダー2024ふりかえり

この記事は弥生 Advent Calendar 2024のシリーズ2、25日目の記事です。

プレゼントもらえた?
こんにちは、かとあず(@kato_az)です。
弥生でQAエンジニアをしている傍ら、弥生開発者ブログの運営や弥生株式会社エンジニア情報X(旧Twitter)の中の人をやっています。

弥生アドベントカレンダー2024 とは

今年もQiitaの「Organization」カテゴリーでアドベントカレンダーを作成し、弥生メンバーがブログリレーをしました。
「業務に直接関係あること、ないこと」を書いた弥生エンジニアのたくさんのブログが公開されました。
ぜひご覧ください。
qiita.com

ふりかえり

「弥生アドベントカレンダー2024」を「弥生アドベントカレンダー2024」でふりかえる件について

弥生アドベントカレンダー2024ふりかえり

当初は、アドベントカレンダーが12月25日に完了後、外部発表として弥生の取り組みを紹介する予定でした。
しかし、急遽12月23日に開催した弥生社内の部門でのLTでお話しすることになりました。

「12月25日までアドベントカレンダーが続くのに23日にふりかえりをテーマにLTをするの?」と感じる人もいたかもしれません。
それでも、「鉄とふりかえりは熱いうちに」。タイミングを逃さないことをモットーに、 実行しながらふりかえっていくスタイルです。

部門でのLTに関しては、弥生アドベントカレンダー2024の20日目と23日目で、新卒入社1年目の野溝さんと矢谷さんが紹介されています。
ぜひこちらの記事もご覧ください。 tech-blog.yayoi-kk.co.jp

tech-blog.yayoi-kk.co.jp

弥生アドベントカレンダーの参加者情報

去年2023年までは「シリーズ1」25記事の登録が完了するのが11月の最後だったのですが、今年2024年は11月12日に25記事の登録が完了していました。すごい。
このため、弥生のアドベントカレンダーとしてははじめて「シリーズ2」を作成し26記事以上の参加を募集することになりました。

アドベントカレンダー記事数と参加者数(見込み)
大盛況のアドベントカレンダー、弥生は2018年から参加しています。
最初の2年は複数の会社が合同で実施しているところに参加している状態で、3年目の2020年から主体となって実施しています。
アドベントカレンダー実施は連続7年
年々アドベントカレンダーが浸透していって参加が増えている印象がありました。しかし、数値で見ると、2018年と2024年ではエンジニア人数が約2倍、アドベントカレンダー参加人数も約2倍ということで、参加割合の推移はあまり変わっていないということがわかりました。
2018年から2024年でエンジニア数が2倍、アドベントカレンダー参加者数も2倍
何年か続けているうちに「常連だけの内輪ネタお祭り」になりそうですが、「弥生アドベントカレンダー2024」は参加者のうち、過半数は初参加でした。
初参加が半分以上

運営メンバーがやってきたこと

寄稿者に向けての取り組み、運営内の取り組み、それぞれ3点紹介します。

寄稿者に向けての取り組み

  1. とにかく周知
    複数の場で周知し、社内でアドベントカレンダーを全員が知っている状態を目指しました。
  2. 個別にアプローチ
    「●●さんのあのLTについて、もっと読みたい」「社内で表彰されていたこと詳しく教えて」などなど、普段のみなさんの活動を見ながらブログに書いてほしいことをお願いしました。
  3. Slack、はてなブログで盛り上げ
    公開後には意識的にリアクションして社内での盛り上げを意識しました。ブログを書いてよかったと思えるようにしていきました。
    寄稿者に向けての取り組み3点紹介

運営内での取り組み

  1. 準備は10月から
    「弥生でアドベントカレンダーやると思わず他のアドベントカレンダー登録しちゃった」や「急に周知されてもブログ書くのが間に合わない」ということにならないよう、入念に準備し、11月早々に参加表明してもらえるように準備しました。
  2. みんなで参加を
    エンジニアだけのお祭りに閉じないよう、全社のSlackで見えるようにしたり、絵が描けるメンバーにカバー画像をかいてもらいました。
    もくにゃんかわいい。
  3. 接点を増加
    弥生開発者ブログやアドベントカレンダーの存在に気づいてもらうため、弥生株式会社エンジニア情報Xにてブログ情報を投稿しています。
    まだまだフォロワー数の少ないアカウントではありますが、知っていただくために試行錯誤しています。
    運営内の取り組み3点紹介

偶然発生したこと

運営が狙っていたわけではないことでもよいことがたくさんありました。
特に、フルリモートワークを採用している弥生では部門が異なる人同士のコミュニケーションが難しいと感じます。
ブログをとおしてレビューアーとレビューイーでZoomミーティングをしたり、投稿記事のリアクションから話が広がったりしたのは、よいことだったと感じています。
今後、業務上で連絡を取り合うときに「ブログのあの人」と思い出すことでスムーズに会話が進むかもしれません。

狙っていたわけではない、よかったこともたくさん。

今後の取り組み

12月以外のブログ投稿数が増えていないこと、公開までのフローが煩雑になってしまっていること、運営メンバーの交代が発生するので引継ぎが必要なことを挙げています。
2025年改善ネタです。

次の施策を考えないといけない
完成形ではない状況ではありますが、それでもアドベントカレンダーは大盛況でした。

まとめ

弥生開発者ブログ運営で、弥生開発者ブログとアドベントカレンダーの取り組みをふりかえりました。
2025年はどんな1年になるでしょうか。お楽しみに。

弥生アドベントカレンダー2024まだ読んでいないという人は、ぜひ気になるタイトルの記事を1つ読んでみてください。
qiita.com

また1年後!



弥生では、一緒に働く仲間を募集しています。
herp.careers
弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp

S3バックアップ見直し ~AWS BackupからCRRに変更しコストを月額1600ドル削減しました~

メリークリスマス、弥生でエンジニアをしているおおもりと申します。今年5月に中途入社してからスマート証憑管理というサービスの運用改善を行っています。
今回、スマート証憑管理で実施したAWSコスト削減施策で行ったDR(ディザスタリカバリ)対策で利用しているS3バックアップの見直しについて紹介します。
昨今、円安の影響でいろいろな物が値上げしています。日用品だけでなくAWSサーバー費用もドルで計上されるため円安の影響を受けます。
弥生では、全てのサービスのサーバー費用などのコストを役職に関係なく知ることができるオープンな状態になっています。また全社集会の場でもサービスごとの収益、費用、利益等が目標通り進んでいるかの報告が行われます。
そのためエンジニアの立場でもコストを意識して日々仕事に取り組んでいます。

スマート証憑管理のサービス説明

スマート証憑管理は、領収書・請求書・納品書・見積書などの証憑をクラウド上で保存・管理できるサービスです。
保存された証憑が電子帳簿保存法の保存要件を満たした状態にできるようにサービスが提供されています。
保存された証憑データを「11年4ヶ月」保存すると規約で定めています。
これらのサービス要件をAWSのS3を使って実現しています。電子取引のデータ保存の保存要件によりデータ削除できないため日々S3のデータは増えていきます。
現在は、TBを超える膨大なデータ量になっています。

DR(ディザスタリカバリ)対策

スマート証憑管理のサービス説明で記載した通りサービスの要は、お客様から預かっている証憑になります。
DR対策としてAWSの東京リージョンで万一何かあったときにも対応できるように大阪リージョンにもS3のデータを複製しておく必要があります。
AWS Backupを使ってバックアップ対応を行っていたのですが、費用が高いという問題がありました。
データ量が多いため毎月2000ドルを消費しており、今後データ量が増えるとさらにコストがかかるという問題がありました。

AWS社からのS3バックアップ改善提案

弥生ではAWS社のTAM(テクニカルアカウントマネージャー)やSA(ソリューションアーキテクト)に相談しサポートを受けることができます。
今回コスト最適化のテーマだったためTAM担当者の方からS3のCRR(クロスリージョンレプリケーション)機能を使えば安くなるというご提案とCRR機能を使った場合と現状のままAWS Backupを利用し続けた場合を比較したグラフを提示いただきました。

開発環境での改善提案の検証

以下の3つの条件を開発環境で検証しました。

1. 現在運用しているAWS Backup  
AWS Backupは各サービスのバックアップを一元管理・設定できるサービスです。  
定刻でバックアップを取得するよう設定を行い、S3バケットのスナップショットを作成し、大阪リージョンへ送信するようにしていました。  

 結果  
バケット内の全オブジェクトを東京リージョン内でスナップショットにしてから大阪リージョンにスナップショットを送信していました。  
そのためオブジェクト量に比例して、毎日コストがかかることがわかりました。  
さらにスナップショットを復元した際にオブジェクトの日付が復元した時間になってしまっていることも判明しました。

2. 改善案のCRR +CRR Batch  
CRR(クロスリージョンレプリケーション)はS3で設定できる機能です。  
設定するとほぼ同期的にオブジェクトが作成・変更・削除されたタイミングで連携先のS3バケットで同じようにオブジェクト操作が行われます。    
CRR Batch(クロスリージョンレプリケーションバッチ)はCRRを設定する際に今まで貯めていたデータを一括で連携先のバケットに送信できる機能です。    結果  
CRR Batchで連携されたオブジェクト含め大阪リージョンのオブジェクト日付は、東京リージョンと同じ日付になることを確認できました。  
また開発環境では少量データで検証していましたが、CRR Batchはデータ量に比例して転送時間がかかることがわかりました。  
結果から本番データでは、膨大なデータ量のため数日かかるという予測をあらかじめ立てることができました。

  3. 改善案のCRR +CRR Batch +ストレージクラスGIR
ストレージクラスGIR(Glacier Instant Retrieval)は、S3標準よりも安いストレージクラスです。
S3標準ストレージクラスよりも安いストレージクラスGIR(Glacier Instant Retrieval)を大阪リージョンで利用するように設定します。

結果
ストレージクラスGIRを利用する場合には、オブジェクトサイズが128KB未満だと逆にコストが多くかかることがわかりました。
ストレージクラスGIRからオブジェクトを取り出す必要があり、以下の2点の課題があることがわかりました。
・ストレージクラスGIRからオブジェクトを取り出す仕組みを構築する必要があります
・ストレージクラスGIRから取り出した日付がオブジェクト作成日になってしまいます

開発環境での検証結果まとめ
開発環境での検証結果からCRR +CRR Batchに変更することを決定しました。

本番環境でのCRR +CRR Batchへの変更対応

事前の認識合わせ

AWS BackupからCRR +CRR Batchへの変更にあたってTAM担当者の方から連携された数値も利用してコスト改善の見積を行いました。
CRRの設定をする際に今までのオブジェクトデータを送信する1度しか動かないCRR Batchで2000ドルかかり、CRRでは毎月400ドルかかるということを見積として出しました。改善前のAWS Backupでは2000ドルかかっており、CRRに変更すれば400ドルになるため1600ドル削減できます。
そのため初回に投資する2000ドル含め2カ月ほどでコスト削減するという見積りをたてることができました。
コスト見積りを事前に出し、初回には一時的に費用は上がるが毎月の削減で改善できることを示したおかげでPMや開発部関係者とすぐに合意が取れリリースに進むことができました。

実施結果

CRR Batch費用
CRR設定開始前のデータを一括で転送するCRR Batchにより大阪リージョンへの連携に2日かかりました。青色のS3のコストは約2000ドルの費用でした。
データ量が多いこともあり失敗せずに完了するか不安がありましたが無事予想通りのコストで完了しました。

CRR効果
CRRの設定によりS3の費用は、予想通り数十ドル増えましたが、緑色のAWS Backupが丸々費用として削減されました。
結果から、毎月1600ドルの費用を削減することができました。

今後の取り組み
AWS Backupの費用削減に成功したので、次に費用がかかっているECRの費用削減に今は取り組んでいます。現在弥生では、AWS費用を削減することに力を入れています。
大規模なユーザデータを扱ったコスト改善などに興味がある方がいればぜひ弥生に入社していっしょに頑張りましょう。

herp.careers

DAPツール「Pendo」の海外イベントに参加してきました

この記事は弥生 Advent Calendar 2024 の24日目の記事です。

こんにちは。弥生でプロダクトデータ分析をしている yayoi_sd です。

わたしが所属している次世代本部では「Pendo」というツールを導入しており、そのイベントに参加しにアメリカのノースカロライナまで行ってきました。 jp.pendo.io

Pendoとは

ひとことで言うと「ソフトウェアのユーザー体験を向上させるための、分析・ガイド・フィードバック機能を備えたツール」です。

ガイドは、ユーザーが製品内で操作を直感的に学べるようにオンボーディングや機能紹介のサポートを提供できる機能で、フィードバックはアンケート機能です。

このような、ユーザーがソフトウェアやデジタルツールを効果的に利用できるよう支援するためのプラットフォームを一般に「DAP(Digital Adoption Platform):デジタルアダプションプラットフォーム」と呼び、弥生では製品改善に活かすべく複数製品でPendoを活用しています。

参加したイベント:PENDOMONIUM(ぺんどもにあむ)

Pendoは外資系のツールで、本社はノースカロライナにあります。

毎年そこでユーザーイベント「PENDOMONIUM」を開催していて、今回そこに参加をしてきました。 www.pendo.io

イベント会場の Raleigh Memorial Auditorium。コーポレートカラー「ピンク着用推奨」ちらほら見かけました

キーノートでは、Pendoの今後の戦略や方向性を学んできました。

いちばん印象に残ったのは「これからのソフトウェア体験では、AIによるパーソナライゼーションを通じてユーザーによりよい体験を提供していくのである」といった趣旨の発言です。

キーワードとして「AIによる自動化(自律型エージェント)」、「インサイトと推奨」、「会話型インターフェイス」の3つが挙げられており、今後の機能拡張もこの方向でなされていきそうに思いました。

わたしがPendoの開発をしているわけではないので「思いました」みたいな言い方になりましたが、実際に紹介された機能拡張予定で「集めたフィードバックからインサイトを得るために会話型ユーザーインターフェースを組み込む」といった話があったりしたので、「そう思いました」

Opening Keynote(CPOのTrisha氏)。上述の3つのキーワードがスライドで触れられています

Pendoユーザー事例セッション

PENDOMONIUMでは、ユーザーによる活用事例のセッションも数多く実施されています。

ここでは、Pendoのガイド機能を使いユーザーのオンボーディング完了率を改善させていた企業の取組事例を一部抜粋・共有します。(キーノートのような大きな話だけでなく、ユーザー向けの地に足のついた事例紹介も充実)

Pendoユーザー事例:アプリ内のオンボーディングガイドの「利用率」を2倍にした方法
この事例の紹介企業では、ビジネス向けに、オンラインで図表作成ができるツールを提供しています。

話者のロールはマーケティングマネージャーで、マーケティングリサーチや行動経済学にバックグラウンドを持たれている方でした。

もともと、図表作成ツールの初回利用ユーザーに向けオンボーディングガイドを提供していたようですが、ガイドの利用率の低さが課題となっていました。

  • ガイドを利用するユーザーの割合:14%
  • ガイドを半分地点まで閲覧するユーザーの割合:11%
  • ガイドを全て閲覧するユーザーの割合:9%

初期ガイドの反省点として、「内容が基本的すぎる」、「ステップが多い」、「テキストが多い」といったことが挙げられていました。
そこで、下記のような改善を加えられています。

ガイド改善点の例

  • ガイドの開始位置の変更 & A/Bテストによる検証(画面右端 vs 画面中央)
  • ガイド導入にアンケートを追加(どんな図表を作りたいか?)
  • ガイドの分岐機能の活用 & アンケート回答に応じた詳細化(作成したい図表に応じ、その後のガイドをパーソナライズ)
  • ガイド利用を促すCTAボタン(Call To Action:ユーザーに特定の行動を促すためのボタン)の文言変更(before:show me around ⇒ after:Yes, show me around)
  • 社会的証明の活用(例:xxユーザーが、先月この図表を作成)

改善版のガイドでは、以下のような結果が見られていました。

  • 中央表示の方が、ガイド利用の開始がされやすい(+15%)
  • アンケートには、39%のユーザーが回答
  • ガイドを利用するユーザーの割合:29%
  • ガイドを半分地点まで閲覧するユーザーの割合:18%
  • ガイドを全て閲覧するユーザーの割合:15%

この結果をもって、「小さな変更が大きな成功に繋がる」点を強調されていたのが印象的でした。
この事例の要点は以下の通りです。

  • パーソナライゼーションとガイドの目的の明確化が必要
    • ユーザーは製品に何を求めているか?「アハモーメント」を早く体験させること
    • ユーザーに過剰な負担を求めないこと

講演は野外ブースで実施されていたものも(雨ふったことないねん、と聞きましたが本当でしょうか )

参加してみて

印象に残ったこと、よかったことは以下です。

  1. PendoにおけるAIの取組について、本気度を感じることができた
  2. ユーザー事例から「やってみなはれ」的な前向きなパワーを感じた
  3. シンプルに非日常な体験ができた

1点目。さきほど「集めたフィードバックからインサイトを得るために会話型ユーザーインターフェースを組み込む」という機能拡張例を挙げました。
こちら、実はPendo社によるZelta AIという企業の買収がPENDOMONIUMでも発表されていました。
www.pendo.io

自社で使い方を模索していくのではなく、既にAIで成功した事例でシナジーのある会社を買収し機能に組み込むというやり方にPendoの本気度を感じます。

2点目。Pendoというツールの性格もそうだなと思っているのですが、「やってみて検証して改善」といった取り組みをファンクション横断で進めているユーザー事例を多く聞いたように感じています。
弥生ではPendoを導入して2年目。社内ユーザー数も増えてきており、どんどん使い倒していきたいな~と気持ちを新たにしました(Pendoも、しれっとどんどん機能改善・拡張されている..!!)。

3点目。通常業務から離れ遠く外国の地でインプットを得る時間、とても貴重な機会だったと思います。年1イベントなので、弥生としても毎年恒例参加にしたい気持ち。

左:アフターパーティにてCEOのToddさんと弥生メンバーとで 右:Pendo新機能の名が冠されたビール

海外イベントへの参加:気になる英語のこと

わたしも、一緒に行ったメンバーも、簡単な応答はできるといった英語レベルでした。
講演となると難度が高く、そこはAIの力を借りました。AI、とても優秀で十分実用に足ります。

  • Otter.ai:リアルタイムでの書き起こしや、ファイル出力
  • Deep L:書き起こしファイルをアップするとほぼノータイムで和訳
  • ChatGPT:要約

1講演あたり40分ほどあったので、ChatGPTに要約をさせました。
要約させると具体例が抜け落ちてしまったり、この点は少し課題感あるな~と思いましたが、要点は十分に拾うことができます。

おまけ

実は、今回のイベントはPendo日本法人に現地でのアテンドいただく形で参加をしてきました。
ご縁がありイベントに合わせてGoogle NYC Officeを訪問させていただいたので、その様子をポストして記事を締めくくります。

Google NYC Office(外観のみですみません)

ハイラインから眺めるNYの街並み(建物がデカい!)


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

herp.careers

新卒1年目エンジニアが伝える「弥生ってこんないい会社」

この記事は弥生 Advent Calendar 2024シリーズ2の23日目の記事です。

こんにちは。弥生株式会社の新卒1年目エンジニアの矢谷と申します。
今年の10月から先行体験プログラムを開始している「弥生会計 Next」の開発に携わっております。

www.yayoi-kk.co.jp

「弥生会計 Next」も私自身も日々進化し、より良い価値体験を提供できるよう努力を重ねています。

さて早速ですが、この記事では入社してから8ヶ月ぐらいが経過して、それなりに会社に慣れてきた私が考える弥生のいいところを忖度なしで4つ紹介します!

少しでも弥生に興味がある方、エンジニアという職種に興味がある方は参考にしていただけると幸いです。

1. 成長できる環境

弥生には成長に繋がる様々な環境、制度が揃っています。

新卒教育が充実している

弥生では新卒の研修期間が4ヶ月ほどあります。
そのうちの3ヶ月間程度は主にエンジニア職だけで基礎からじっくりとプログラミングの研修をします。
プログラミングの研修では、HTML、CSS、JavaScript、JavaやGitの使い方などの基礎的なプログラミング技術を体系的に学んだ後に、同期たちとチームを組んで簡単なWebアプリケーションを作成します。
時には切磋琢磨しつつも、楽しく協力しながら実務に繋がる力を養うことができるので、未経験の方でも問題ありません。

また研修以外の精神的なサポートも手厚いです。
弥生では、新卒1年目の社員が安心して成長できるよう、ブラザーシスター制度を導入しています。この制度では、新卒で入社した先輩社員がメンターとして1年目の社員一人ひとりに寄り添い、精神的なサポートを含めた伴走を行います。メンターとは毎週面談を実施し、研修での悩みや疑問、会社の様々な制度の利用方法について相談することができるため、新しい環境でも安心して業務に取り組むことが可能です。
入社時の不安や戸惑いを理解しやすい先輩がサポートすることで、1年目の社員は自信を持って一歩ずつ成長できる環境が整っています。

やりたいことをやらせてもらえる環境

弥生の魅力のひとつは、「やりたいことをやらせてもらえる環境」が整っていることです。

一見すると、古い技術を使っているイメージがあるかもしれません。しかし実際は、最先端の技術にも積極的に取り組んでいます。その一例として、「弥生会計 Next」ではAIを活用した機能開発を進めており、業界のトレンドに即したプロジェクトに携わるチャンスがあります。

また、新卒3年目でプロジェクトマネージャー(PM)を務めている社員もおり、若手でも意欲次第で大きな役割を任される風土があります。エンジニアとしても、入社1年目から実際の開発業務に参加できるため、早い段階で実務経験を積むことが可能です。

さらに、弥生では働き方も選択肢があります。安定した組織基盤のもとで、じっくりと技術を身に付けて成長できる部署がある一方で、自分から積極的に挑戦していける部署もあります。どちらが自分に合っているか、またどちらを選びたいかはあなた次第です。

安定と挑戦、どちらも備えた弥生の環境はよく「大手とベンチャーのいいとこどり」と表現されています。

書籍購入制度

一部の部署限定ではありますが、業務に関連する内容の書籍の購入費用を全額負担してもらえる制度があります。動画よりも書籍派の私にとってこの制度は経済的にも非常にありがたいです。
動画派の方は「Udemy Business」での学習をすることもできます。
個々人のスタイルに合わせた学習を会社が全面的に支援してくれています。

アウトプットの機会が多い

弥生では業務や自己学習の中で得た学びをアウトプットする様々な機会が設けられています。
その代表的なものが、「部門でのLT(Lightning Talks)大会」と「もくテク」です。

部門でのLT大会

弥生では、社内向けに技術やナレッジを共有することを目的としたLT大会が毎月1回開催されています。
開発職の社員であれば基本的には誰でもエントリーすることができ、5分間の「Lightning Talk(稲妻ぐらい短いお話)」をする場が設けられます。
私も1年目のうちに1度は挑戦しようと思います。

もくテク

もくテクは、弥生株式会社が運営する勉強会「木曜日にテクノロジーを語ろう」の略称で、定期的に社外向けイベントとして開催されています。

もくテクでは上記のLT大会同様に、経験豊富なベテラン社員から新卒1年目の社員まで、誰でも登壇することが可能です。
発表内容も技術的な話に限らず、失敗談など幅広いテーマを取り上げており、聞く側も話す側も多様な視点で学びを深めることができます。

次回の開催日時は12/26(木) 19:00~20:30前後で、テーマは「読んでよかった技術書・ビジネス書LT」です。少しでも興味を持っていただけましたら、ぜひご確認ください。

https://mokuteku.connpass.com/mokuteku.connpass.com

もくテク公式キャラクターのもくにゃん


2. いい人が多い

これは社内外問わず多くの人が口をそろえて言っています。
私自身、弥生に入社する前は、「嫌な先輩にいびられたりするんこともあるんだろうなあ」とか考えていましたが、実際にはそんなイヤな奴は一人もいませんでした(マジで)。
先輩方は皆さん親切丁寧に教えてくださいますし、同期も全員仲が良く、定期的にご飯に行ったりします。
「心理的安全性」という言葉がよく社内で飛び交っているところからも、全社的にハラスメント撲滅に取り組んでいるのを感じます。

3. 働き方がかなり自由

私が一番推しているポイントといっても過言ではないのは、やはり「働き方の自由度」です。
働き方に関する弥生の最高の制度を3つ紹介します。

フルリモート勤務

弥生では現在、フルリモートで働くことが可能となっています。
私も新卒研修が終わって、現在のチームに配属された8月以降は多くても週一回しか会社に行っていません。
出社回帰が進む中で、新卒1年目からこんなに自由に働ける会社はなかなかないのではないでしょうか。

フレックスタイム制

弥生ではフレックスタイム制を導入しており、コアタイムを10:00~15:00として、柔軟に勤務時間を前後させることが可能となっています。
朝型の人も夜型の人も自分の最高のパフォーマンスを発揮できるように勤務時間を調整できるだけでなく、飲み会があった次の日はゆっくり出社するといった選択も可能です。

中抜け制度

中抜け制度はコアタイム外の勤務時間中に休みの時間を作ることができる制度です。
病院や市役所、銀行に行ったり、子どもの送り迎えをしたりするために利用されていることが多いと思います。

4. 会計ソフトってかっこいい

正直な話、私は弥生に入社するまでは会計ソフトというものにそこまでテンションが上がりませんでした。
なんだかよく分からないし、地味で古臭いものという認識があって、もっと「かっこいいサービス」の開発をしたいと思っていました。

でも今は違います。
会計って面白いし、会計ソフトってかっこいいんです!

それは、会計ソフトが単なる記録のためのツールではなく、日本の中小企業や個人事業主の課題を解決し、より良い未来を創るための強力なパートナーになりうると分かったからです。
例えば、煩雑なバックオフィス業務を効率化することで本業に使える時間を生み出したり、数字の見える化で経営の意思決定を助けたり。
そんな場面を想像するたび、「こんなに人の役に立つサービスを作れるんだ」とワクワクします。

地味だと思っていたこの分野が、実は多くの人の夢を支える「縁の下の力持ち」であると気づいたとき、会計ソフトの新しい魅力が見えてきました。

終わりに

最後までお読みいただきありがとうございました。
弥生では現在、一緒に働く仲間を募集しております!
この記事を読んで少しでも弥生に興味を持っていただけた方はぜひご連絡ください。

herp.careers


新卒採用(26卒)はこちらから

www.yayoi-kk.co.jp

バグゼロに陥らないためのQA活動

この記事は 弥生 - Qiita Advent Calendar 2024 - Qiita の 21日目の記事です。

こんにちは、鈴木です。

「安易にバグゼロを目指してはいけない」という話をします。

バグゼロとは

バグゼロとは以下のいずれかとします。

  • リリース後に発見されたバグがゼロ件だった
  • バグ修正により検出済みのバグがゼロ件になった

なぜバグゼロになるのか

リリース後に発見されたバグがゼロ件になるのはなぜでしょう。
リリース前のテストで全てのバグを見つけ出せばそうなります。
それは、テストが過剰だった可能性があります。

検出済みのバグがゼロ件になるのはなぜでしょう。
バグ修正を高い優先度で対応するとそうなります。
それは、バグ修正より価値のある開発タスクが存在しない可能性があります。

テストが過剰だとバグゼロになる。
価値のある開発タスクが存在しないとバグゼロになる。
バグゼロは良いことだと思っていたのに・・。

※念のためですが、クリティカルなバグを残してよいという意味ではありません。

バグゼロが示す兆候とは

テストが過剰な状態。
それは、テストのコスパが悪い状態です。
プロダクトの価値を高める開発に時間を奪っていると言えます。

価値のある開発タスクが存在しない状態。
それは、プロダクトが新たな価値を生み出せない状態です。
プロダクトが終焉に向かいかねない危機的状況だと言えます。

バグゼロはプロダクトが悪い状態に陥っている兆候です。
できれば「バグゼロになりそうだ」というタイミングで気付きたいところです。

注意として、バグゼロはあくまで兆候です。
実際に悪い状態に陥っているか落ち着いて確認し、必要ならば手を打ちます。

バグゼロに陥らないための行動と心構え

バグゼロの原因は「テスト過剰」と「価値のある開発タスクが存在しない」でした。
この原因から考えることで、バグゼロに陥らないための行動は見えてきます。

  • コスパのよいテストをおこなう
  • 価値の高い開発タスクを作り、着手可能にする

しかし、実際に行動するには心理的な壁があるかもしれません。

  • そうはいってもバグは出したくない
  • バグを放置して新規開発することに抵抗感がある
  • 品質を担う QA がバグを放置するなんて無責任だと思う
  • 「バグってる」とか「バグが残ってる」とか「バグバグ」言われたくない

この心理的な壁を乗り越えるには、プロダクトの視点で考える必要があります。

  • NG: 自分にとって、バグを放置することに抵抗感がある
  • OK: プロダクトにとって、軽微なバグ修正より機能開発する方が価値が高い

以下の心構えがあれば、心理的な壁を越えやすいと思います。

  • プロダクトの視点で考える
  • プロダクトの価値を最大化する行動を考える

QA は何をすればよいのか

ここからはプロダクトの品質に深く関わる QA の立場で考えます。
チームとしてやるべきことは以下でした。

  • コスパのよいテストをおこなう(クリティカルなバグを見逃さない)
  • 価値の高い開発タスクを作り、着手可能にする

コスパのよいテストはイメージしやすいと思います。
それでは価値の高い開発タスクを作り、着手可能にするとはどういうことでしょうか。

「弥生請求 Next」を開発しているチームの実例を 2 つ紹介します。

  • 要件や仕様を決めるための材料を出す
  • 運用や非機能に関する要件を出す

要件や仕様を決めるための材料を出す

計画中の機能を開発着手可能にするには、要件や仕様を明確にする必要があります。
そこで、次のような情報をまとめてプロダクトオーナーに渡します。

  • 要件や仕様に含めた方がよいことの一覧
  • 要件や仕様の具体案や選択肢

プロダクトオーナーは多くのことを意思決定しなければなりません。
また、判断材料を集めることに意外と時間も期間もかかるものです。
「これを決めてください」「あれを教えてください」では負担を増やしてしまいます。
意思決定に必要な材料を準備し、あとは判断すればよいだけの状態を目指して行動します。

  • NG: 「要件は何ですか?」
  • NG: 「仕様を教えてください」
  • OK: 「メール送信機能の要件に DMARC 対応を入れてほしいです」
  • OK: 「予約実行系の機能は “○時に実行” ではなく “○時台に実行” という仕様にしてほしいです」
  • OK: 「非機能要件を決める材料として販売計画から 1 年後の想定データ量をまとめました」

意思決定に必要な材料は、全てを自分で集める必要はありません。
次のように調査タスクを作れば、分担して進めることができます。

調査タスクを作る

次のように少しでも前に進めることを意識します。

  • 要件が未検討の状態 → 要件が検討可能な状態
  • 仕様が未検討の状態 → 仕様として決めるべきことが明確な状態
  • 何を調査すべきか分からない状態 → 何を調査するべきか明確な状態
  • ...

「QA はテスターとは違い上流工程にも参加する」と説明されることがあります。
この「上流工程に参加する」を「上流工程に同席する」に取り違えないように注意します。

  • NG: 要件や仕様を決める場に同席し、思いつくままに指摘するだけ
  • OK: 適切な要件や仕様を決められるように、先手先手で判断材料や案を出す

ミーティングに同席し、聞くだけの存在になってはもったいないです。
反対に、問題を指摘するだけのご意見番ではマイナスになりかねません。
上流工程で品質を作りこめるように、口だけではなく、手を動かします。

運用や非機能に関する要件を出す

プロダクトオーナーは顧客に価値を提供するために頭を悩ませます。
そのため、運用や非機能を十分に考慮する余裕がないこともあります。
運用や非機能に含まれるものはいろいろあります。

  • 十分なパフォーマンスを出してほしい
  • 十分なセキュリティを確保してほしい
  • 適切なサービスレベルを設定してほしい
  • 障害対応などの運用体制を整えてほしい

例えばパフォーマンスについては以下をおこないました。

  • 1 年後の想定データ量・アクセス数を試算する
  • パフォーマンステストに対する要件(達成基準)を作成する
  • パフォーマンステストのシナリオ案を作成する

要件(達成基準)として出した内容は以下です。

要件

以下のいずれかを満たすこと

  • (1) 2025年10月時点の想定データ量・アクセス量に耐えることができる、またはアーキテクチャを変更せずに対応できる
    • 例: 現時点で耐えることができる
    • 例: ECS のタスク数を増やせば対応できる
  • (2) アーキテクチャ変更が必要であることを事前に検知でき、余裕のあるスケジュールで対応できる
    • 例: DynamoDB によるセッション管理が破綻する 3 か月前に検知でき、3 か月あれば余裕のあるスケジュールで対応できる

要件に対する補足:

  • アーキテクチャ変更が必要になった場合でも1年あれば計画的に対応できると考え、正式リリースの1年後である2025年10月を基準とした。
  • ただし、余裕のあるスケジュールで対応できれば猶予期間が 1 年である必要はないため、(2) を加えた。

シナリオ案として以下を作成しました。

テストシナリオ

シナリオに含めること

  • 同時ログイン
    • セッション管理に使用している DynamoDB がボトルネックになるかどうか確認するため
    • オンデマンドで負荷に耐えられない場合はプロビジョニングモードに変更するか、DynamoDB をやめる判断が必要となるため
  • ホーム画面
    • 大量データを登録した場合に十分なパフォーマンスを出せるか確認するため
  • 請求書の新規作成
    • 参照系よりも負荷が高くなる登録系の処理を 1 つは含めたいため
  • PDF ダウンロード
    • キャッシュしていることで十分なパフォーマンスを出せるか確認するため

これをプロダクトオーナーとすり合わせました。
次に開発メンバーと相談し、内容を確定させるという流れで進めました。

おわりに

この記事ではバグゼロに陥ることの意味と対策についてお話ししました。
チームはメンバーの経験やスキルセットによって特性が変わるものです。
チームに合ったバグへの向き合い方ができるとよいですね!

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

herp.careers