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

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

プレゼントもらえた？

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

12月1日から25日まで弥生アドベントカレンダー2024を実施します
ぜひ弥生エンジニアのブログをご覧ください。#弥生開発者ブログhttps://t.co/qYumUbR0f5 pic.twitter.com/XXirdPcAw8

— 弥生株式会社エンジニア情報 (@yayoikk_dd) 2024å¹´11月22æ—¥

弥生アドベントカレンダー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による自動化（自律型エージェント）」、「インサイトと推奨」、「会話型インターフェイス」の３つが挙げられており、今後の機能拡張もこの方向でなされていきそうに思いました。

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

左：アフターパーティにて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

新卒エンジニアは配属後1ヵ月間で どのようなフィードバックを受け、それをどのように改善していくのか

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

はじめまして！今年2024年弥生に新卒入社した野溝と申します。

2024年10月に初回リリースされた「弥生証憑 Next」の開発チームに、エンジニアとして加わって早くも3か月が経ちました。今年の8月末にこのチームに配属されて以来、日々多くの学びと成長を実感しています。本日はそんな私が配属1ヵ月のタイミングで社内向けに発表した「新卒エンジニアは配属後1ヵ月間でどのようなフィードバックを受け、それをどのように改善していくのか」をリライトして、お届けします！

この内容は配属されてから約1ヵ月後に社内で行われた部門でのLT（Lightning Talks）大会で発表したものです。

「部門でのLT大会」とは……

• 毎月1回、開発本部・次世代本部合同で開催している会
• エントリーした人が、5分間のLTをする場
  
• LTのエントリー対象は、開発本部・次世代本部の「本部長、統括グループ長、CTO、フェロー、表彰委員長以外」の全社員
  
• LTは、「部内の技術啓蒙活動や、技術力を上げる為に活動を行った」または「お客様（社外・社内）視点で自身の製品開発や運用業務を行い、成果を部内に展開し、啓蒙活動を行った」ことについて
  

この内容を社内の人だけでなく、社外の人にも届けたい！と思ったのでリライトさせて頂くことにしました。

CONTENTS

1. なぜこの内容で記事を書くのか
2. どのようなタスクを行ったのか
3. コードレビューを分類してみる
4. 改善に向けて
5. 伝えたいこと
6. 雑談：配属後1ヵ月が経って感じたこと
7. 雑談：LT大会に参加して感じたこと

1. なぜこの内容で記事を書くのか

記事の執筆理由ですが2つあります。

1つ目は私が受けたコードレビュー内容や心構えは、他の新卒エンジニアも同様に当てはまるのではないかと考えたからです。コードレビューの内容は先輩エンジニアの方々にとっては当然のことかもしれませんが、新卒エンジニアである自分にとってはそこから気が付くことが多くありました。もちろんこの記事が全ての新卒エンジニアに刺さるとは思っていませんが、少しでも多くの方の業務に役立てば嬉しいです。

2つ目はこのような記事が思いの外存在しないことに気づいたからです。新卒として入社したエンジニアの皆さんは、配属直後何に気を付ければ良いのか不安に思った場面はなかったでしょうか。そんなときに、新卒エンジニアの心構えを記載したこの内容が助けになると信じています！

2. どのようなタスクを行ったのか

コードレビューの内容をよりイメージしやすくするために、ここでタスクの概要を簡単にご紹介します。以下が配属後1ヵ月間で行ったタスク（一部）になります。

• ログアウト機能の新規実装
  • C#/FastEndPointsを使ったWebAPIの新規作成
  • WebAPIを呼び出すTypeScript/Remixを使用したフロントエンドの実装
• 開発環境で認証機能を提供するダミーサイトの修正
  • ASP.NET Coreを使用したバックエンドの実装
  • Blazorを使用したフロントエンドの実装

3. コードレビューを分類してみる

前置きが少々長くなりましたが、ここからが本題になります。先ほどのタスクに対するコードレビューを分類してみました。

1.コメント不足や不適切な命名（33%）

コメントが不十分 コード内での説明が足りず、他の開発者が理解しにくい状態になっている。

命名規則の不適切さ 変数名やメソッド名がその役割や内容に適していない。

2.エラーハンドリングやロジックの理解不足（23%）

エラーハンドリングの不足 例外処理が不十分で、予期しないエラーに対応できていない。

ロジックの理解不足 コードの追加や修正による影響範囲を正確に把握できていない。

3.技術的理解の不足（13%）

Reactの理解不足 コンポーネントの基本的な概念が理解できていない。

HTTP仕様の理解不足 headerやbodyに指定できる要素を正確に把握できていない。

4.その他（23%）

Gitの理解不足 コンフリクトの修正や、リベースなどの技術に対する理解が浅い。

コードの不適切な配置 必要であれば処理を関数としてまとめたり、ファイルを分けたりするなどの判断ができていない。

4. 改善に向けて

以上の内容を振り返ると、「3. 技術的理解の不足」は経験を積むことで改善されると思いますが、それ以外の項目は自分の意識次第で改善できそうです。そこでこれらの改善に向け次のような指針を定めました。

1. コード全体を正確に把握せよ

実装ではロジックの中心となるコードに集中しがちです。そのため別ファイルで定義された変数や関数の理解が曖昧なまま実装が進んでしまうことがありました。実装に関係するコード全体を正確に理解できるよう意識する必要があると思いました。

2. 実装目的を正しく理解せよ

チケット（タスクの説明）に記載された実装方針を理解したつもりになっていても、誤解していることはあるはずです。その誤解によって不適切な関数名や変数名を付けてしまうことがありました。理解に不安があるときは自分の理解不足を自覚し、適切に質問・確認を行うことが大切だと感じています。

3. リファクタリングを意識せよ

例えば一見軽微な修正でも、安易に該当箇所をベタ書きで修正することが好ましいとは限りません。処理のまとまりをメソッド化した方が良いときもあります。本当にその実装がベターなのか立ち止まって考える癖を付けたいです。

5. 伝えたいこと

冒頭の繰り返しになりますが、先ほど挙げたコードレビューの内容が全ての新卒エンジニアに当てはまると思っていません。また改善に向けた指針について、意識する必要がない方もいるかもしれません。一方でこの記事は多くの新卒エンジニアに当てはまる一般的なことを述べているとも思います。記事の内容を含め、皆さんも各々の指針をもって行動することで、より大きくエンジニアと成長できるのではないでしょうか。

6. 雑談：配属後1ヵ月が経って感じたこと

一言で言えば、入社してから最も成長を感じた1ヵ月間でした。というのも配属されてから、理解すべき内容が膨大だったからです。

まず技術的な観点で言えば、言語やインフラ、開発環境など多岐にわたる知識を吸収する必要がありました。配属前にプログラミング研修で基礎的なことは学んでいましたが、それは文字通り基礎的な知識に過ぎませんでした。また当然のことですがドメインの知識も学ぶ必要がありました。

このように書くと配属直後から勉強ばかりで大変という印象を抱かせてしまうかもしれませんが、新人ながらに配属まもなくプロダクトコードに触る機会をもらい、それを何とかやり遂げようとしたからこそ学習すべき量が多かったわけです。そのため、その過程は全く苦ではありませんでしたし反対に充実した毎日だったと振り返ることができます。

これらの知識をまだまだ吸収している過程ではありますが、特に詰め込んだ最初の1ヵ月間では自分の著しい成長を感じました。

7. 雑談：LT大会に参加して感じたこと

新卒エンジニアの中で1人目の部門でのLT大会登壇ということで、最初はエントリーするかどうかも迷っていたというのが正直なところです。

これまでオーディエンスとしてLT大会に参加する中で、先輩方が技術的な話を中心にされていることは知っていたので、正直このようなトピックで発表して良いのか不安でした。しかしいざ発表してみるとオーディエンスからの反応は良く、そのような不安は杞憂であったことに気づきました。

振り返ってみれば、今回のLTは自分が受けたコードレビューの内容をまとめてアウトプットする良い機会になりました。今後もアウトプットの機会として積極的に活用していければと思います！

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

herp.careers herp.careers

AWS re:Invent期間中のラスベガスでの過ごし方

こんにちは！弥生でエンジニアをしている宮崎です。
この記事は 弥生 Advent Calendar 2024 の20日目の記事です。

12月第1週にアメリカのラスベガスで開催されたAWS re:Inventに参加してきました。
本記事では現地での過ごし方や各セッションの様子をふりかえっていきます。
AWS re:Inventやその他の国際カンファレンスに興味をお持ちの方の参考になれば嬉しいです。

5日間お世話になったMGM Grand Hotelのライオン像

ラスベガスでの過ごし方

現地で過ごした12/2～12/5の時間の使い方をまとめてみました！
（re:Invent自体は12/2～12/6で開催されていますが、移動の関係で参加したのは4日間でした。）
空白の時間は会場のホテル間を移動したり、食事を取ったりしています。
改めて思い返しても、とても充実していますね。

Day1～3は日の出前に起床。頑張った…！

参加したセッション

技術系（ワークショップ）

実際に手を動かしながら技術習得を図ることができました。
初めて触るサービスを体験したい場合などはワークショップが適していると思います。
個人ワークだと思って参加したら同じテーブルのメンバーで協力・分担する形式で、英語でコミュニケーションが取れるかドキドキする場面も。
結果的にはメンバーに恵まれ、終了後も雑談で盛り上がるくらい仲良くなることができました。

技術系（その他）

Breakout SessionやChalk Talkを中心にたくさん参加しました。
自分の興味のあるテーマについて専門家から深い話を聴くことができるため、ピンポイントで求めていた情報が手に入る可能性も。
ユニークなセッションタイトルに惹かれて参加したものが予想以上に面白かったり、逆に期待していた内容と少し違うな…というものもありました。
思い通りにいかない部分も含めて良い経験になりました。

ビジネス系

AWSの技術に関するものだけでなく、企業文化や経営戦略に関するものなど様々なセッションがあります。 私は各分野で活躍する女性たちによる、Inclusion & Diversityをテーマにしたパネルディスカッションを視聴しました。
普段エンジニアとして働く中で性別を意識することはほとんどありませんが、自分と同じIT業界の女性たちが世界中から集まって熱心に参加している様子に圧倒され、元気をもらいました。*1

ふりかえり

良かったこと

1. セッションやアクティビティに積極的に参加した
   Keynoteから交流イベント的なアクティビティまでバランスよく参加できました。
   私はre:Invent参加時点でAWSの業務経験が1年に満たなかったので、Advancedレベルのセッションって難しすぎるのでは？など不安もありましたが、参加してみたら案外大丈夫なことが多かったです。
   5K Runやre:Playなどのイベントも、日本ではなかなか味わえない体験ができて楽しめました。

2. 他の参加者とのコミュニケーションを楽しめた
   EXPOで同じ列に並んだ人や、セッションで出会った人たちと交流できました。
   英語はそれほど得意ではないのですが、何度も聞き返したり言いたいことが表現できなかったりしても、みんな笑顔で付き合ってくれました。優しい世界。
   同じツアーで参加していた日本人の方と仲良くなって連絡先を交換したりもしました。

3. 空き時間に観光もできた
   ベラージオの噴水ショーやステーキハウスなどラスベガスらしい体験ができました。
   夜に大通りを散歩するだけでも、街中キラキラで非日常感が味わえます。
   観光スポットやレストランを調べてくれた仲間に感謝。

反省点

1. ちょっと予定を詰めすぎた
   行きたい場所は全部行こう！と欲張ったら、予想よりだいぶハードなスケジュールになりました。。。
   もう少し空き時間を作って休息や情報整理に充てたかったなと思います。
   幸い体は丈夫なので、ときどき眠気はありましたが最後まで元気でした。

2. 食事の時間を考慮していなかった
   1.に関連しますが、Day1, Day2の日中をセッションで埋めてしまい「いつご飯食べるの？」状態に。
   各会場でおやつを提供してくれるので、オレンジとグラノーラバーを食べて夜まで乗り切りました。
   その分（？）、Day3, Day4は食堂でおいしいランチを食べることができ、とても幸せでした。

   

   ポテトチップスはおかず

まとめ

計画性が大切。でも思い切り楽しむことも大切。
AWSの知識や英語力をつけて、いつかまた参加したいです。

一緒にはたらく仲間を募集しています

herp.careers

*1:女性限定のセッションではないので、男性参加者も少数ですがいらっしゃいました。