会計知識ゼロから始めるプロダクトデザイナー生活

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

プロダクトデザイナーの "1000old" です。

弥生株式会社では、2024年の10月から「弥生会計 Next」先行体験プログラムを提供しており、私はその開発チームの一員として、プロダクトデザインを担当しています。

www.yayoi-kk.co.jp

昨年の Advent Calendar では、Web 業界からキャリアチェンジした経験談を書きましたが、今年はプロダクトデザインの少し泥臭い部分にフォーカスしてみます。

具体的には、会計知識ゼロだった人間が、どうやって会計システムのプロダクトデザイナーとして「しがみついている」かを書いてみようと思います。

お金と弥生と私

弥生に入るまでは、簿記はおろか、お金の計算自体が好きではなく、毎月定額のお小遣いでちまちまと趣味のものを買うことにささやかな喜びを感じていました。

大事なことですが、お金が嫌いなわけではないです。
むしろ大好きです。愛していると叫ばせてください。
ただ、お金の「計算」に興味がないんです。

じゃあなんで弥生を選んだのか。

これは昨年書いたように、Webディレクターの経験が活かせそうなことに加え、面接でお会いした方々と「一緒に仕事をしてみたい」と思えたからです。

専門用語、資格との格闘

こんな調子なので、入社早々に挫折を味わいます。
これまで聞いたことがない専門用語のオンパレード。

  • 仕訳って何?仕分けと違うの?
  • 貸借対照表?損益計算書ってナニソレオイシイノ?

でも、実際に画面を考えるならそのまま放置するわけにはいかず。
弥生に入社が決まった時点で簿記3級の勉強を始め、入社後1ヶ月半くらいで取得しました。

これで資格が取れたと意気揚々だったのですが、天狗の鼻は早々にへし折られます。

決算や固定資産など、専門性が高い機能の検討には、3級の知識では役に立たず、2級を一部分だけ勉強しました。

これが意外にスムーズに理解できたので、もしかして2級イケる?との勘違いから資格取得にチャレンジしてみました。

本格的に勉強を始めたら後悔しかなく、何度も止めようと思いましたが、「諦めたらそこで試合終了ですよ」の名言を心に、半年かけて簿記2級を取得しました。

※ 名言の載っている漫画自体はよく知らないんですけどね。

タスク、業務フローの把握

無事に資格は取得できて教科書的な知識を得たものの、会計事務所や経理のタスク、実際の業務フローは全く知らない素人です。

まず最初に、弥生の中にいる業務を熟知した仙人に教えを請い、本で得た知識と自社サービスの各画面の関係を把握しました。

その後、複数の競合他社サービスを使ってみると、同じ条件のタスクでも、完了までのフローはサービスごとに結構異なることがわかり、会計アプリケーションにおけるユーザー体験の判断基準が少しできた気がします。

(検討中のイメージ)


また、起業して間もない新設法人の代表へのインタビューなどで、会社の日常と経理業務のつながり、会計アプリケーションへのダイレクトなニーズを知ることもできました。

この時点で、さまざまな利用文脈の把握とともに、自社サービスのペインポイントもおぼろげながら見えてきました。

※ 利用文脈 = ユーザーがサービスを使用する状況やその背景、それに付随して起こるさまざまなできごとのつながり
※ ペインポイント = ユーザーが「お金を払ってでも解決したい」と考えている悩みや課題

プロダクトへの反映

業務理解の過程で整理したカスタマージャーニーマップ、ペルソナやサイコグラフィックは、主に以下の2種類のユーザーのさまざまな利用文脈を想定しています。

① 弥生に入りたてのころの私のような「会計初心者」(新設法人の起業家など)
② ①のような人をサポートする会計事務所や税理士などの「会計のプロ」

「弥生会計 Next」は、②をターゲットとする手入力中心の高度な機能だけでなく、新たに自動化などを取り入れて①もターゲットとしているため、初心者向けの分かりやすさと、プロ向けの効率性や柔軟性とのバランスを取る必要があります。

両者の利用シーン、頻度、利用文脈やペインポイントなどは当然かけ離れていますが、ユーザー体験や機能、提供価値などで分類して、それぞれを最適化するための取り組みを行いました。

①の初心者向けの機能は、同じチームのメンバーが昨年の Advent Calendar で公開した「デザインスプリント」を導入して改善を進めました。

tech-blog.yayoi-kk.co.jp

私は②のプロ向け機能を担当することが多いのですが、チームの中に弥生会計を使う会計事務所での勤務経験があるメンバーがいて、会計業務で感じる問題点や課題をヒアリングしました。

(業務フローの洗い出し過程)


その中で弥生会計について聞いてみると、大きな不満はないものの、

  • ○○の機能は、付随する機能が不足しているため、実はあまり使っていない
  • △△の機能は、高機能すぎて逆に「要らぬおせっかい」で使いにくい
  • □□機能の一覧は、デフォルトでこういう情報が出ている方がありがたい

のように、意外に多くの改善点やペインポイントが見つかっています。

ヒアリングで得た情報や実際の業務フローをもとに、期待される解決策を検討し、プロの評価やフィードバックから改善を行い、最終的にプロダクトとしてリリースできる形までブラッシュアップを繰り返しました。

また、関連性が高い複数のデータのつながりや、裏側の計算ロジックなどを検討する際には、改めて簿記の知識が役に立ちました。

進化は続くよ、どこまでも

ここまで書いてきた通り、会計知識ゼロで弥生に入社して、離脱することなく、なんとか「弥生会計 Next」先行体験プログラムのリリースを迎えられました。 辛うじて振り落とされていなくても、引きずられてケガだらけかもしれませんが。

リリースは「ゴール」ではなく「スタート」である ー 今さらな言葉ですが、先行体験プログラムをご利用中のお客様からはさまざまなお声をいただいており、それらを検証、改善につなげる動きを開始しています。

それと並行して、いずれ迎える正式リリースに向けた追加機能の開発も着々と進行中です。

まだまだ産まれたてのヒヨコ状態の「弥生会計 Next」ですが、今後どんどん進化していきますので、ぜひご期待ください。


弥生では一緒に働く仲間を募集しています。興味のある方はぜひご連絡ください。

herp.careers

英語ができない人間のAWS re:Invent 2024 初日体験記

はじめに

こんにちは、商用インフラチームのいまいずみです。
このブログは弥生 AdventCalendar 2024 の18日目の記事です。
本記事では英語が全くできない私が re:Invent に参加し、初日をどのように過ごしたのかお伝えできればと思います。

AWS re:Inventとは

AWS re:Inventは、AWSが主催する学習型カンファレンスです。AWS re:Inventでは、基調講演、トレーニング、認定資格、2,000以上のテクニカルセッション、Expo、時間外イベントなど、様々なイベントが開催されます。 AWS re:Invent 2024 FAQs | Amazon Web Services

ざっくりタイムスケジュール

時間
05:00 起床
06:30 ~ 07:00 移動(MGMで迷子 )
07:10 Venetian 到着
07:25 Wynn 到着
08:00 ~ 10:00 セッション 1
11:30 ~ 12:30 セッション 2
14:00 ~ 認定者ラウンジで意見交換
16:00 ~ Expo
19:00 ~ KeyNote 初日
25:00 就寝

起床

朝は早いです。アメリカにいる間は平均5時起きとか。
別日に5Kレースも参加しましたがその日は4時半起きとかだった気がします。

移動

私は初日の8:00からワークショップを予約していたため、いきなりメンバーとは別行動でした。
会場の1つであるMGMグランドホテルに泊まりましたが広い。
ここで30分迷い、ゆっくり朝ごはんを食べる時間が無くなりました。。。
会場のホテルにはAWSのTシャツを着た方がいるので、英語が喋れないとか関係なく恥ずかしがらずにさっさと聞きましょう。
ちなみにMGM ~ 他会場 はどこに行っても最速でバスで10分程度かかります。
会場内を歩くだけでもかなりの歩数となるので、目的の会場まで歩くなんて馬鹿な事はやめましょう。
いや、ほんとまじで。

移動中のバスからの風景。F1開催の名残がありました。

Venetian到着

SWAG(記念品)受け取るためにVenetianにバスで移動しました。
(会場の詳細は本ブログでは説明を省きます)
パーカーと水筒がもらえました!(照明が薄暗く青いのでパーカーが青く見えますが、実際はベージュのパーカーです。)

SWAGの水筒とパーカー

ちなみに水筒に関しては初日に口が開かなくなってしまいました( ;∀;)
一緒に参加していた弊社パワー系エンジニアの木村さんでも開けられなかったため泣く泣く現地で処分しました。(パワー系エンジニアのブログはコチラ
中に水も入っていて、結局空港のセキュリティに引っかかるししょうがない。。。

Wynn到着

WynnはVenetianとは徒歩移動できるので、その辺のスタッフにめっちゃ聞きながら移動。
朝から迷ったせいで朝食の時間がなかったので、5分でクロワッサンとベーコンと卵とコーヒーを流しこみました。

XNT306 : From diagram to code: Automate IaC Code generation with Bedrock

最初のセッションはこちらでした。

Learn how to use generative AI to automate code generation, reduce manual effort, and increase development speed. In this workshop, get hands-on experience developing an end-to-end .NET 8 application using Amazon Bedrock, AWS Lambda, and Amazon API Gateway. Use Amazon Bedrock to generate infrastructure as code (IaC) directly from architecture diagrams and then, with agents, use the code to automatically create the infrastructure. Learn security best practices and how to use Amazon Bedrock within your .NET applications to enable seamless integration with generative AI models. You must bring your laptop to participate.

Bedrockでの基礎モデルとの対話とカスタマイズとAmazon Q Developerでの Visual Studio Codeの統合機能としてコードの理解と生成についてのワークショップに参加しました。
ざっくりいうとアーキテクチャ図からIaCコードを生成、もしくはそのままリソースを作成するようなシステムを作成を体験するワークショップとなります。
同じテーブルに日本から来た方がいたので談笑や会話しつつワークショップを進めていました。
ちなみにワークショップは最後まで終わりませんでした。残念。。。

ケータリング

日本のイベントだとなかなか見られない光景ですね。
当たり前のように飲み食いしながらみんな移動していました。このあとコーヒー片手にCaesars Forumへ移動。

ケータリング

ARC308 : Harnessing generative AI to create & understand architecture diagrams

2つめのセッションとなります。またワークショップに参加してきました。

This builders’ session explores using generative AI to create and comprehend architecture diagrams, a critical aspect of software design and communication. Diagrams are often image data, custom formats of drawing programs, or text-based representations from diagram-as-code tools. Techniques are used from two different layers of the generative AI stack, Amazon Q Developer and foundational models on Amazon Bedrock. Chat-based workflows first understand and analyze existing diagrams, and then ask follow-up questions about best practices. New diagrams are created using diagram-as-code formats. Leave with practical strategies for harnessing generative AI in your software architecture workflows. You must bring your laptop to participate.

生成AIを使ってアーキテクチャ図やの分析や作成を実施するセッションでした。
1つ目のワークショップと似ていますが、今回はアーキテクチャ図を作成するために生成AIを利用するワークショップとなります。
私のテーブルではディスカッションや質問が多く、翻訳機を駆使しながら内容は理解できましたが会話の中には入れず。。。
次回行く機会があるなら、英語を頑張ってコミュニケーション取れるようにしていきたいなと強く思いました。

昼ごはん

よくわからずランチボックスを選択。
さすがアメリカと言わんばかりのサイズ。あとリンゴ丸々1個⁉
写真には入っていませんが、これにフランスパン1本分のサンドイッチ入ってました。
お腹いっぱいです。

認定者ラウンジ

Venetianに戻り、認定者ラウンジに行きました。
特典をもらって、たまたま前職の先輩であるAWS Ambassadorの方がラスベガスに来ていたのでお会いしました。
その方の紹介で日本の他の AWS Ambassador の方たちと名刺交換、意見交換していました。
一番盛り上がったのが今回のre:Inventで発表されたAWS Data Transfer Terminal について。
こちら用意されている広い部屋に机と光ケーブルしかなく、機器の持ち込みなどは自分で運び込むらしい。(笑)
他にもいろいろ意見交換でき、楽しかったです。

特典。全冠目指して頑張ります。

2年ぶり前職の先輩との写真

Expo. のレセプションに参加

初日のExpo. ではウェルカムパーティーのような感じで、軽食とお酒も配られていました。
会場内まわっていろいろグッズをもらってきました。
中でもRed Hatの赤帽はインパクト強かったですね。
ちなみに会場で赤帽被っているのは日本人ばかりでした。

ExpoでもらったTシャツや赤帽

KEY001 : Monday Night Live with Peter DeSantis

1回目の基調講演はAWSのデータセンターに設置されているハードウェアやストレージを詳しく説明した内容でした。
たまたま隣に自治体で勤務されている日本人の方が座られていたので、KeyNoteはほどほどにいろいろ意見交換させていただきました!

KeyNoteの様子

食事、買い物、就寝

この後、イベント参加した弥生メンバーと合流し、食事・あと水を買いました。
結局就寝したのは25時くらいだったかと思います。
また次の日も 5:30 には起床です。

まとめ

今回は初日に絞ってre:Inventの過ごし方を紹介させていただきました。
運に恵まれいろいろな方とコミュニケーションを取ることができ、最高に楽しいイベントでした!
なかなか他社の方とビジネス抜きでAWSの技術について話せる機会もないので、それだけでも参加した価値のあるイベントだったなと思います。

移動やセッションでは英語翻訳も精度が上がっているので、英語はそこまでできなくても心配ないと実際に参加して感じました。
買い物などのコミュニケーションもボディランゲージとかで何とかなります。
ただ英語ができれば世界中のエンジニアとコミュニケーション取れたので、もし次回行く機会があれば英語で会話したいですね。
これを読んでいる方で、もしre:Inventに参加できる機会があるのであればぜひ参加してみてください!

参加報告会のお知らせ

1月のもくテクでre:Inventで学んだ内容について話します!ぜひご参加ください。

mokuteku.connpass.com

社員募集

弥生では一緒に働く仲間を募集しています! 弥生で働くことに興味がありましたら、求人一覧をぜひご覧ください。

herp.careers

PMが頼ったり頼られたりするために気をつけていること

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

クリスマスツリーは準備OK?
みなさん、こんにちは。弥生でプロジェクトマネジャー(PM)をしているナカシマです。
好きな犬種はシーズーです。(好きな勘定科目を言うシリーズから脱線してみました。)

今回はPMとして業務を進める上で気をつけていることを紹介したいと思います。なお、スキルではなく心構えに近い内容ですので、気軽に読んで頂ければ幸いです。
また、本記事は過去に弥生の社内報「ヤヨイロ」に投稿した記事をリサイクルしたものとなっています。
Let's SDGs!

頼るために気をつけていること

PMの仕事は1人で完結することがほぼなく、誰かに作業をお願いすること、つまり誰かを頼ることが多々ありますが、その際に気をつけていることがあります。

必要な情報はまとめて伝える

情報はまとめて

まず、依頼された相手が作業に入りやすいように必要な情報はいっしょに提示するようにしています。
例えば、弥生ではSlackでテキストコミュニケーション、Backlogでタスク管理していますが、SlackでBacklogの課題(以降はチケットと表現します)に関する作業を依頼する場合は

  • チケットのタイトルも記載する →どのような作業であるかパッと見でイメージしてもらいやすくする
  • チケットのURLのリンクを設定する →作業者が詳細を確認するためにチケットにすぐに遷移できるようにする

といった具合です。
※なお、2024年12月現在、Backlogに用意されたコピー機能を利用することでリンクと件名を一度にコピーしてSlackにペーストすることが可能です。

自分の課題、最近見た課題、ガントチャートのサイドパネル、ボード、課題をまとめて操作の課題詳細と課題検索で「表示中の課題キーと件名をコピー」を押すと課題キーにHTMLリンクが付くようになりました

アップデート情報 | チームで使うプロジェクト管理・タスク管理ツールBacklog 2024年10月30日アップデート情報より

すごく些細なことのように思えますし、実際にそうだと思いますが、これがチケットの番号やURLだけしかないような場合と比べて依頼を受けた方の作業の入りやすさが変わると思っています。

受け手が気持ちよく作業できるように伝える

お互いに気持ちよく

次に、特にテキストによる依頼(Slackやチケットのコメント)の場合はそれが受け手にとって快く対応してもらえる文章になっているかを気にしています。
仕事なのである程度の割り切りはあると思いますが、それでも前向きに作業できるかどうかでパフォーマンスも変わると思いますので、お互い気持ちよく取り組めることを大事にしています。
対面の場合は声のトーンや表情で印象に気を配ったりできますが、テキストの場合はそれができないため、特に気をつけるようにしています。

ChatGPTにも聞いてみる

教えて!ChatGPT

と、ここまで書いてみましたが、自分でも全然大したことしてないなと感じましたので、ちょっとChatGPTにも聞いてみました。

ナカシマ

誰かを頼るときに気持ちよく動いてもらえるコツを教えて

ChatGPT

誰かに頼るときに気持ちよく動いてもらえるコツは、
相手へのリスペクトや感謝の気持ちを示しながら、コミュニケーションを円滑にすることです。
以下のポイントを参考にしてみてください。

1.相手を理解し、適切なタイミングを選ぶ
タイミングを考慮する相手が忙しそうなときや疲れているときは避け、リラックスしているときを選びます。
相手の得意分野を意識する:相手が興味を持っていたり得意とすることなら、快く受けてくれる可能性が高まります。

2.具体的で簡潔な依頼をする
はっきりと伝える:何をお願いしたいのか、具体的で明確に伝えます。
負担を減らす:「これだけ手伝ってくれると助かります」と、範囲や時間を明確にしておくと相手が安心します。

3.相手を尊重する言葉を使う
感謝の姿勢を示す:例えば、「いつも助かっています」「○○さんならではの意見が聞きたいんです」など、
感謝や信頼を伝えると、相手も気持ちよく動いてくれます。
相手の都合を確認する:「今お願いしても大丈夫ですか?」と
相手の状況を気遣う言葉を添えると配慮が伝わります。

4.動いてくれた後はお礼を忘れない
具体的なお礼:「○○してもらったおかげで、すごく助かりました!」と
具体的に伝えることで、相手の努力が認められたと感じてもらえます。
追加の感謝を示す:メッセージや小さな贈り物など、
相手の行動に感謝の気持ちを示すとさらに良い関係が築けます。

5.自分も「助ける姿勢」を持つ
相手が自分に頼ってきたとき、気持ちよく応じることで、良い循環が生まれます。
「お互い様」の関係を築くと、自然と助け合えるようになります。

相手への敬意と感謝を軸にすると、頼む側も頼まれる側も気持ちよく関われますよ!

なるほど、2と3は意識できてそうです。1も大事ですね。トイレに行こうとしているときに「ちょっといいですか?」と言われて30分足止め食らうとイラっとします。
4も意識したいですね。僕自身も「ありがとう」の言葉をもらうことでやって良かったと思えたことが多々ありますし、後出しじゃんけん的になってしまいましたが、言われてみれば意識してる気もします。
5もまさにですね。忙しそうなときなどにも親身になって対応してくれると、逆の状況になったときにも積極的に助けてあげようという気持ちになりますね。

頼られるために気をつけていること

PMは頼るだけでなく頼られることも必要です。なぜ頼られる必要があるのか?それは頼られると気持ちがいいからです!
ウソです。いや、個人的にはウソでもないのですが、もっと大事な理由があります。それは仕事を円滑に進めるためです。
仕事では大なり小なりトラブルや困りごとがつきものだと思います。予期せぬことが一切起こらずに予定通り終えられることの方がむしろ少ないくらいではないでしょうか。そのような困った状況になってしまったときに必要になるのがチームの力で、個人では越えられない壁があったとしてもチームでなら越えられると思っています。
そして、チームとして機能するために調整役、つまりPMが必要であり、PMが気軽に相談できる相手である必要があり、頼られる必要があるという考え方です。

前置きが少し長くなってしまいましたが、では頼られるために気をつけていることは何か? それは「ご機嫌を取ること」です!ただし、その相手は他者ではなく、自分自身です。例えば、困りごとがあったときに相談したい相手が
A:不機嫌そうな顔をしている
B:機嫌が良さそうな顔をしている
だとしたら、どちらが声をかけやすいでしょうか?よほどマニアックな人でもない限りはBの機嫌が良さそうな状態のときに声をかけやすいと思うのではないでしょうか。

声をかけやすいのはどちら?
でも体調が悪かったり、朝子供がわがままを言ったり、犬にいたずらされて部屋を掃除しないといけなかったり、膝が痛かったり・・・きっかけは人それぞれですが、自然と不機嫌になってしまうこともあるでしょう。(僕自身は子供が3人、犬が3匹いて毎日何かしら起きますし、両膝の半月板を軽く損傷していて日々痛みと戦ってます。)
日々いろんなことがあります
だからこそ、意識的に「『自分』のご機嫌を取る」必要があると思っています。疲れているときこそ、忙しいときこそ、大変なときこそ、みんなが自分のご機嫌を取ってチームで大きな壁を乗り越えられると最高ですね。
いかがでしたでしょうか?特別なことでもなんでもない内容だったと思いますが、でも大事なことだと思いますので、今後も気をつけながら仕事をがんばりたいと思います。 最後まで読んでいただき、ありがとうございました!
ありがとうございました!

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

herp.careers

弥生公式noteのインタビュー記事もぜひご覧ください。 note.yayoi-kk.co.jp

R&D室が出来て1年経ちました

このブログは弥生 AdventCalendar 2024 の17日目の記事です。

こんにちは。弥生R&D室でMLエンジニアをやっているsiidaです。 時が経つのは本当に早いもので、弥生にR&D室が結成されてから1年と少しが経過しました。

研究開発部門のチームビルディングという非常に貴重な経験ができた1年でしたので、これまでの1年を振り返ってみたいと思います。

設立に至るまで(2023夏)

ここ数年のテクノロジーの進歩は著しく、弥生も先端技術への適応を迫られるフェーズに面していました。 そこでAIにフォーカスして弥生の新たな価値を創出する、という目的のチームを立ち上げることが決定しました。

立ち上げメンバーは以下の通りです。

  • MLエンジニア
    • わたし(2023年夏に中途採用)
    • 同僚(同じタイミングで中途採用)
  • マネージャー/アドバイザー
    • 室長(基本いない)
    • CTO(たまにいる)

たった4人で、かつ新人と工数の僅かなマネージャーだけ。 果たしてどこまでできるのでしょうか。

R&D室設立直後(2023/10~2023/12)

何もわからない。

直近の仕事も今後の1年の計画も社内のこともとにかくなーにもわからない。 決まっているのは中途研修の予定だけ。空いてる時間も多いし、あとはいったい何をするんだ??

まずメンバーで集まって相談しました。自己紹介からはじめて、それから次のことを決めました。

  • チームのミッションとスコープ
  • 年間の目標とスケジュール
  • 仕事の枠組みや進め方

仕事の枠組みとしては、社内のニーズを元にテーマを選定し、数か月単位のプロジェクトとしてPoCを実施するという形としました。

そこで「どのようにニーズを集めるか」という課題となり、そのための具体的な取り組みが直近のタスクとなりました。 たとえば社内のどなたが課題を抱えていて、関連するプロダクトは何になり、どこに活用できるデータがあるか......といった情報を調べていきます。 入社したばかりのエンジニアがいきなり部署横断的な仕事に取り組むこととなり、「わからん!」と悲鳴をあげては周りの方々に助けていただきつつ、 どうにかテーマ選定のための仕組みづくりを整えていきます。

やがてニーズ収集と整理が終わり、PoC(Proof of Concepts)に取り掛かるための精査が済み、ようやくR&D室として取り組む最初のテーマが決定しました。

PoC実施(2024/1~2024/3)

PoCの期間は3か月という短い期間でしたので、様々な工夫(と高いモチベーション)が必要でした。

例を挙げると、

  • MLエンジニアリングに関する技術的な試行錯誤
  • PaaSや業務ドメインの専門家とのディスカッション
  • 徹底的に効率よく業務を回すための仕組みづくり

といった取り組みを実施しました。また仕組みづくりです。これが非常に大事です。自分たちで責任をもって仕事のやり方を決めるというプロセスが、スピードとエンゲージメントに直結します。誰かの言うことに従うだけでは、目標を達成できなかったでしょう。多くの方々を巻き込みご助力いただきつつも、メンバー2人で走り切りました。

後始末と準備(2024/4~2024/9)

ひとつPoCを終えてここで一息、、、と思いきや。逆に終えたPoCを元にして、様々なタスクが発生しました。

  • 実運用時の条件を見据えた分析
  • 多角的なパフォーマンスの効率化
  • 実運用するシステムへの組み込み方法の検討

PoC実施時においては限られた時間の中で精度を追求しました。しかし実運用を見据えると、多くの問題点が浮き彫りになりました。たとえばユーザからの入力値が想定通りでない場合に不適切な振る舞いを起こしてしまう、精度をわずかに上げるための時間のかかる処理がある、といったものです。他にも、単純に技術的負債や、ドキュメントの不備などといった問題も発生しました。

こうした問題に対処するための後始末に多くの時間を費やすこととなりました。PoCの結果は直ちに製品実装できるものではないのです。。

一方で、新たなプロジェクトに取り掛かるための準備も並行して進めていました。メンバーそれぞれが興味のあるAI企画を各々の方針で推進し、今後の自分の取り組むテーマを決めていく。指示された要求を実装するのではなく、自分で要求を決め自分で実装する。それがR&D室のMLエンジニアです。

スケーリング(2024/10~現在)

弥生は10月が期首となるので、秋に大きなイベントが発生します。R&D室ではメンバーがなんと8人になりました。これに伴い、並行して進められるプロジェクトも増加しました。R&D室の組織としての力が飛躍的に高まり、この1年はさらに大きな目標にチャレンジします。

ふりかえり

指示された要求を実装するのではなく、自分で要求を決め自分で実装する

このための体制を1年かけて整備することができたかなと思います。テーマ選定にPoC、その後の後始末を含めて、全社横断的に様々な方とのつながりを作ることができました。弥生という大きな企業が蓄積しているニーズやデータ、ノウハウといったリソースを少しずつ活かせるようになってきています。

今後ともMLエンジニアが実力を発揮するための最高の組織にできるよう、進み続けたいと思います。

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

herp.careers

不具合の可視化のためにやっていること

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

こんにちは!弥生で会計NextというサービスのQAエンジニアをしているはるたです。 担当している会計Nextというサービスは、新規でサービスを開発して、先日リリースをしたサービスになります。

開発をしているときから、検出する不具合の情報をチームがわかるようにするために可視化の取り組みをしてきました。 どのようなことをしてきたかを書きたいと思います。

不具合の可視化の取り組みをはじめたきっかけ

最初に、なぜ、この取り組みを始めたかということを書きたいと思います。

私が担当するサービスは、開発チームが4~5チームに分かれていて、多くの人たちが開発にかかわっています。このようなチームで進めていると、かかわる人たちの人数が多いゆえに、正しい情報が良いタイミングで全員にいきわたらなくなりがちです。開発にかかわる人たちが、今の状況がどういう状況なのか、ということをいつでも分かるようにしておくことが、品質を良くしていくための基本になると考えたため、この取り組みを始めました。

弥生では、不具合管理はBacklogというサービスを使っています。Backlogに所定のフォーマットで不具合情報を登録しています。登録した不具合情報をMicrosoft Power BIというサービスを使って任意の条件で集計結果をグラフで表示できるようにしています。PowerBIのグラフをもとに、各チームで傾向分析をして、その後の改善につなげられるようになっています。新しい仕組みの検討や導入をするより、この仕組みを活用したほうが早くやりたいことが実現できるため、極力この仕組みを活用して進めようと思いました。

どのようにすすめたか

ざっくり不具合情報の可視化をしましょうといっても、考えられる観点はいくつもあります。

思いつく切り口で傾向を出しても、有益な情報を伝えることにはならないと思いました。まず知りたいことの問いを立てて、その問いに答えるような切り口で傾向を出すようにしてきました。 どんな問いに答えるような分析をしたのか?ということについて、具体的にやったことを以下に記載していきます。

プロダクトのどこがどのように弱いのか

毎月、不具合の傾向をConfluenceの記事にまとめて、簡単なコメントを添えてチームに共有するということをやっています。大きなリリース向けのテスト期間中は毎日、不具合の傾向を伝えるようにしています。ここでこたえる問いは「プロダクトのどこがどのように弱いのか」です。

たとえば、下記のようなことを記事にまとめています。

  • 不具合数の推移
    • 月や日単位で時系列の推移を示すことで、いまどのぐらい不具合が出ているのかを把握できるようにしています。
  • 不具合の深刻さごとの内訳
    • 重大なものがどのくらいあるのかを把握できるようにしています。
  • 機能ごとの内訳
    • 開発チームごとに担当機能が分かれているため、それぞれのチームのメンバーに伝わりやすいように機能ごとの内訳を入れています。
  • デグレード発生状況
    • 自動化を行う範囲を決めるときに、どこの部分でデグレが発生したかということを参考にして決めています。そのため、どの機能でデグレードがどのくらい起きているかということをわかるようにしています。
    • 自動化についてはこちらの記事に詳しく書いています。

tech-blog.yayoi-kk.co.jp

記事に記載する内容は、その時の状況により変えていっているところもあります。大切なのは、大勢のメンバーが開発にかかわっているという環境で、「プロダクトのどこがどのように弱いのか」を皆が知りたいときに知ることができる状況になっていることなので、その状況になるように続けています。

「○○の不具合が多い気がする」「△△が心配」といった感覚は本当にそうなのか

定期的にチームにフィードバックをしているのは上であげた「プロダクトの弱さ」にかかわる情報です。もう1つの別の考え方で不具合情報のフィードバックをしていることがあります。

開発をしていれば、「最近、○○に関する不具合が多い気がする」「△△は結構難しいところだから心配」という感覚をもつことがあると思います。不具合の件数など実際の数字を見てみたら、その感覚は当たっていることもあれば、そこまででもないこともあります。なんとなくの所感や感覚の裏を取っていくということは大切だと思います。 そこで、実際の不具合情報をもとに「本当にそうなのか?本当にその傾向があるとしたらどの程度なのか?」といったことをまとめて共有するということをしています。

例えば、下記のようなことです。具体的な内容はオープンに記載するのが難しいため、イメージとして例を挙げます。

  • ここ最近、特定の業務の計算処理の不具合が多い気がするがどの程度か?
  • 特定のサービスが複雑な処理を担っていて、不具合の混入が多くなりそうだが本当にそうだったか?

上記のような問いに対して、データとしてはどうなっているかをさくっとまとめて、Slackなどでチームに伝えています。定期的に周知するというのではなくて、気になることを見つける都度、その時点のデータでまとめています。

まとめ

不具合情報をチームに伝えていくために行っている取り組みを書いてきました。不具合に限らず、「品質の可視化」という取り組み自体は新しいことではなくて、どこのチームも色々な形で取り組んでいることと思います。私の場合は、チームの状況を考えつつ、どういう情報をつたえていくのか、ということを考えるのが思ったよりも難しかったです。まだまだ改善したいことはあるものの、プロダクトがどういう状況なのか?について、チームが知ることができる状況にはなっていると思います。今後、仕組化や傾向分析の観点の見直しなど、取り組んでいきたいと思います。



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

オンラインでも現地でも!re:Inventを楽しむ方法

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

qiita.com

こんにちは、会計Next のエンジニアをしている 木村 です。

AWS re:Invent 2024に参加させてもらったので、その楽しみ方を紹介する記事になります。

AWS re:Inventとは

AWS re:Inventは、AWSが主催する学習型カンファレンスです。AWS re:Inventでは、基調講演、トレーニング、認定資格、2,000以上のテクニカルセッション、Expo、時間外イベントなど、様々なイベントが開催されます。
AWS re:Invent 2025 | December 1 – 5, 2025

2024年は12/1 ~ 12/6に開催されており、私もラスベガスに行ってまいりました!

日本でもセッションを視聴できる

そんなre:InventのセッションがAWSの公式 Youtubeで見ることができます。
トピックごとに再生リストになっているので、興味のある項目から探してみてください。
https://www.youtube.com/@AWSEventsChannel/playlists

AWS EVENTS Youtube Channelの再生リスト

また、re:Inventの公式のサイトにセッション情報の一覧があるので、こちらから探すのもおすすめです。
https://registration.awsevents.com/flow/awsevents/reinvent24/public/page/catalog

英語苦手でも字幕をつければなんとかなる

私は英語が得意ではないので、日本語字幕と英語の文字起こしを見比べながら見ています。

日本語字幕を表示する

  1. 字幕ボタンを押す
  2. 歯車マーク(設定)ボタンを押す
  3. 「字幕」 > 「自動翻訳」 > 「日本語」を選択する

字幕ボタンを押してから歯車マークを押す

英語で文字起こしを表示する

  1. 「もっと見る」を押す
  2. 「文字起こしを表示」ボタンを押す

「もっと見る」を押下

「文字起こしを表示」をクリック

日本語字幕と英語の文字起こしが出ました!

AWSのrecapイベントでおさらい

セッションを見る時間がないという方は、AWSさんがまとめのイベントを行ってくれてるので、こちらに参加するのもよいでしょう。
pages.awscloud.com

現地でしかできないこと

日本でもセッションは見れますが、やはり現地にいかないとできないことはたくさんあります。

AWS GameDay, AWS Jam

GameDayとJamに参加してもらったステッカー

実践型・競技形式のハンズオンセッションで、1人でタスクをこなすものもあれば、チームで作業しスコアを競うものもありました。
今回、わたしはGameDayを2つ、Jamに1つ参加してきました。

チームで競うものは、1人で参加すると他の参加者とランダムマッチするので、強制的に英語で会話をするイベント発生します。
翻訳機を駆使しながら万国エンジニアあるあるをおしゃべりしてきました。

アクティビティのイベントもたくさんありました。

APJ on Tour

アジア太平洋地域のメンバーが参加するパーティー
多くの日本人参加者と交流し、名刺交換も行いました。

5K run

ラスベガスの道路を5km走れる(歩く)イベント
道路の一部を封鎖してくれるので、こんな経験はなかなかできません。

re:Play

re:Play 最終日のパーティー
ライブで楽しみすぎてあっという間の時間でした。

おわりに

ラスベガスでも日本でもre:Inventは楽しめるというテーマで記事をかいてみました。
(来年は参加できなさそうなので、re:Inventの時期に開発合宿しながらキーノート見るとかしたいなあ...)

飛行機でのフライトは往復で24時間オーバー、セッションのたびに大きな会場を移動するので一日2万(多い日は3.5万!!)歩も歩くハードな旅でしたが、お祭りのような高揚感があり、疲れよりも楽しさが勝りました。。

英語ができなくても現地の空気を味わうだけでもモチベーションが上がるので、行けるチャンスがある人はぜひトライしてみてください!!

参加報告会のお知らせ

1月のもくテクでre:Inventで学んだ内容について話します!ぜひご参加ください。

mokuteku.connpass.com


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

herp.careers

自動テストは繰り返し実行だけのためじゃない。MagicPodを使って大量データ登録をやってみた。

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

クリスマスまであと何日?
こんにちは、かとあず(@kato_az)です。弥生でスマート証憑管理のQAエンジニアをしています。好きな勘定科目は未払金です。
「未払金」は、「みらいきん」と読みます。私は本名の漢字が読みにくく、よく読み間違えが発生します。「みらいきん」と読まれがちな「未払金」に同族意識を持っています。
他にも未払金が好きな理由はいろいろあるのですが、それはいつかまた別の機会に。
今回はMagicPodを使ってデータ作成をしたお話しです。

それはある日突然に

とある金曜日のこと。私は朝9時頃にPC起動して業務を開始。
前日私が退勤したあとにSlackのメンションがいくつか入っていたため、内容を確認し始めました。

すると、1通のメッセージが目に入ってきました。

スマート証憑管理に取引先をたくさん登録したいです。700件とか1,000件とか。
(実際のメッセージは、きちんと書かれていました。私のフィルターを通した理解はこんな感じです。)

単純作業、繰り返し作業が大好きな私は、「今日の仕事はデータ登録か?」と、さっそく肩をあたため始めました。

日頃の筋トレはデータ登録に役立つ?
そして、当日の自分のスケジュールを確認しました。
あれ?あまり作業時間がない……
こうなる未来はすでに見えている
依頼者は木曜日の夜に依頼しています。たくさんデータ登録がされている画面を鑑賞することがゴールではなく、たくさんデータ登録した先にやりたいことがあります。
当日のスケジュールを見ると、私が集中して作業できる時間を確保できるのは午前中の少しと、金曜日の夜の時間帯です。とすると、データ作成が完了して、データをつくった環境で次のステップに進めるのは翌週月曜日になってしまいます。
依頼者は別に「私に」データをつくってほしいわけではありません。すでに条件を満たすようなテストデータを持っている可能性や、はやくデータを作る方法を考えられるだろうということで連絡がきたのです。
「誰が作った」は関係しない
手元に、取引先が大量に登録されているデータは存在しません。ではどうする?選択肢はいくつかありそうです。

  • 私が作成する。
    • 金曜日の夜に作成に着手、月曜日の朝までにデータが登録されたアカウントを渡すことをお伝えする。
      • 遅い。
    • ミーティングに参加しながらデータ作成をする。データ作成完了時間は未定。
      • ミーティングの内容を聞き漏らすのでよくない。
  • チーム全員で作成する。
    • 手分けして作成をする調整をする。何人の調整がつくかは未定。10人集まったとしても1人あたり100件程度の作成が必要。
      • 調整に時間が必要で、他の開発作業に遅延が発生する。
  • テスト自動化ツールを使う。
    • 自動実行の準備をして、ミーティング参加中に実行する。
      • デメリットはなさそう。

選択肢は天使と悪魔……ではない。

MagicPodを使ったデータ作成

私は「テスト自動化ツールを使う」ことを選択しました。MagicPodで作成した、「取引先を3件登録する」シナリオはあります。
この時までMagicPodで実行するシナリオは毎日動かすテストを作るものだと思っていました。しかし、繰り返す目的ではなくてもテスト自動化ツールが使えそうです。
継続的に使うシナリオは可読性やメンテナンス性を考慮する必要がありますが、今回はデータがたくさんある状態をなるべく早く作ることを第一目標としました。

既存のシナリオをコピーして、シナリオを作り変えること約30分。

シナリオの変更概要
決してきれいなやり方ではないことはわかっていますが、データを180個つくるシナリオができました。

さっそく実行開始。
無事に動き始めたので、実行の様子をたまに確認しつつ、予定通りにミーティングに参加します。
データを180個作成しシナリオ実行が完了したら、再度実行ボタンを押します。
午前の業務時間終了時間が近くなってきたタイミングで600件を超えるデータが登録されていることを確認し、この後の作業を相談しました。
「1度この件数で挙動を確認したい」というコメントだったのでテストデータ作成をストップしました。そして、データを作成したアカウントを引き渡します。
しばらくすると「予定の件数よりは少ないが、やりたかったことは確認して達成できそう」ということで、追加のデータ作成はせずここで作業完了です。
できた。

まとめ

作ったシナリオはきれいとは言い難く、そして、もっと効率的なやり方があったとは思っています。
それでも、「自動テストは繰り返し実行してリグレッションテストに使うもの」という思い込みを捨て、今チームが必要なことを実現するための手段として考えられたことはチームにとってよかったことでした。
手動でデータ登録をした場合、データ作成完了が金曜日の夜になりデータ登録したアカウントを使った確認開始が翌週月曜日になっていたはずですが、MagicPodを使って自動化したことで金曜日の午前中にデータ登録対応が完了し、金曜日の午後にはデータ登録したアカウントを使った確認ができました。データ登録の完了を半日分早めることができました。 そして、データ登録したアカウントを使った確認は、金曜日のうちに完了しました。週をまたがずに確認を終えられ、チームはすっきりと週末を迎えられました。

MagicPodで必要なテストを作って運用し続けるとともに、デプロイごとのテスト以外にもMagicPodを利用できるタイミングで活用することを考えていきます。



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