社内のマスコットキャラクターが人生の思わぬ扉を開く

こんにちは、PRチームの庄村です。
一年前に「社内の中心でマスコットキャラクターへの愛を叫ぶ」という記事を書かせていただきました。あれから季節がぐるっと一周回りましたが、もくにゃんへの愛は冷めやらず、今年もまたもくにゃんへの愛を語ろうと思います。

余談
当該記事は2022年アドベントカレンダーの中でもだいぶ色物記事だったのか、何を書いたらいいのか迷う人に対して提示されるある種のラインみたいになってました。草。

そもそも「もくにゃん」とは?

開発本部を盛り上げるために生まれたマスコットキャラクター。
なんだかニヒルな笑み、歩くとぽてぽて音がしそうな絶妙なシルエットが人々の心を掴んで離さないスーパーキャット。社内で圧倒的な人気を誇る(私調べ)

もくにゃんと私

2022年10月、社内で「もくにゃんを描きませんか?」というプロジェクトが立ち上がりました。要するに技術勉強会であるもくテクを中心とした発表の機会で使える画像素材を描いてくれる人を募り、弥生内のいらすとや的なデータベース化を目指そう!というものです。

もくにゃんが好きすぎて、業務中何か考え事をしている時などノートの隅に無限にもくにゃんを描き続けて来た私にとって、なんと素晴らしいプロジェクトだろう!!と思い、即参加を決めました。

プライベートで購入後、だいぶ持ち腐れていたiPadとApple Pencilを引っ張り出し、いざ、もくにゃん!

最初は真面目だった、はず……

「こんなもくにゃんが欲しい!」というリクエストを中心に、「使いやすそう」なもくにゃんを描いてきました。
おかげ様で数々の社内資料でもくにゃんが見られるようになり、ほくほく。

ストレートに「カレーを作るもくにゃん」というリクエスト
読書の秋!
アドベントカレンダーのカバー画像も!
もくにゃんにはあたたかい屋根の下でおいしいものをたくさん食べて穏やかで幸福な日々を過ごしてほしい……。(もくにゃんに対する思想が強いとよく言われる)

なにかがおかしくなってくる

そもそもゆるめのマスコットキャラクターが採用される時点で、こういった資料には抜け感(?)が求められているに違いない……。そう思ったことから、ちょっとずつクスリと笑えそうなネタに走ったもくにゃんが増えていきます。

「アーニャみたいなSlackスタンプほしい」「はい」
Mさん「(若干「酔っ払ったもくにゃん」に見えなくもない) 」私「そうです」
本当に悪気はない
そんなこんなでちょっとした色差分なども含めると、38件ものもくにゃんを納品しました。業務じゃないのになぜこんな熱量を……。
ちなみに知らぬ間にママ(デザイナー)が描いたもくにゃんの数を、私の二次創作の数が上回ってしまいました。突然現れて親のような顔をする第三者。怖すぎる。

もくにゃんのためにやったこと

  • もくにゃんをめちゃくちゃ描いた(たくさん練習した)
  • CLIP STUDIO PAINTを契約した
  • いろんなもくにゃんを描くため、ポーズ模写やいろんな資料を探した

得られた成果

  • もくにゃんがもっと好きになった
  • (たぶん)弥生の発表資料がかわいくなった
  • プライベートでも絵を描くようになった(趣味が増えた!)
  • 描いたファンアートをXにあげたら推しにRP(旧RT)してもらえた!!!!(!?)
  • しかもリプライまでもらった!!!!!!(!!???!)

嬉しすぎてスクショしましたが、特定を避けるため秘密(恥ずかしいので)

まとめ

愛が思わぬ形で人生を豊かにしてくれる。
ありがとう、もくにゃん。好きだ、もくにゃん……。

もくにゃんに会える「もくテク」はこちらから mokuteku.connpass.com


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

herp.careers

エンジニアがお客さまの声を聴いてみた

この記事は弥生 Advent Calendar 2023の15日目の記事です。

 はじめまして。「弥生会計」開発チームでエンジニアをやらせてもらっているOです。弥生に新卒で入社して3年目になります。

好きな勘定科目は「現金」です。弥生会計で科目選択のトップに表示されますし、手軽ゆえテストでもたくさん設定するからです。

この記事では「エンジニアがお客さまの声を聴いてみた」と題して、私のチームでエンジニアの顧客目線醸成を目指してやったことをご紹介していきます。

背景

先日、弥生では大きな組織改革があり、その一環で開発本部に新たな目標が追加されました。追加された目標の一つが「エンジニア目線と顧客目線の両立」です。

しかしエンジニア、お客さまと直接かかわる機会なんてないですよね。どうやって達成しましょう。

現状、エンジニアがお客さまの声を知るすべは限られています。更に、

  • 能動的に取りに行かない限り情報が入ってこない

  • お客さまの声は他本部の人を通して要求として上がってくるため、直接関わらずとも製品を作れるしくみである

このためエンジニアはお客さまに対する解像度がやや低めの状態です。

そんな状況から顧客目線を手に入れるため、2つの取り組みをはじめました。

やったこと

お客さまの声を聴いてみよう。

「お客さまの仕事をサポートする製品を作っている以上、お客さまの声を知りたいエンジニアは多いのでは?」と思い、「カスタマーセンターへのお問い合わせ音声を聴いてみたくないですか?」とチームメンバーに聞いてみました。

(補足)弥生は業界で最大規模のカスタマーセンター(コールセンター)を抱えています。そこではオペレーターが日々電話やメールなどでお客様対応を行っています。 

 

チームメンバーからは「お叱りが多かったら悲しいかも」という不安の声もありつつ、「お客さまのご要望を実際に聞いてみたい」「どんな機能が喜ばれているか知りたい」といった反応が多く寄せられました。

 

そこで「顧客対応音声を聞く会」を計画しました。

会の主目的は「お客様のお困りごとを知り、製品を改善するためにどうすべきかをエンジニア一人一人が考えるようになる」。つまりエンジニアの「顧客目線」と「オーナーシップ」の醸成です。

 

お客さまとオペレーターとの通話を聞くにあたって、「旬な問い合わせ(インボイス関連、最新の障害etc)、 問い合わせ頻度の高いもの、お客さまからのポジティブな声が含まれる音声を聞きたいです!」とカスタマーセンターに依頼しました。

該当するものをピックアップしていただき、そのうちの三本を聞いてもらうことに。それぞれ7分程度の短めの音声です。

  1. 「インボイス制度は自分(免税事業者)にどう影響する?」
  2. 「△△という内容のエラーが発生する」(※障害)
  3. 「××を〇〇することってできる?」(※できる!)

                                                                                                       

これを普段エンジニア全員で集まって作業しているZoom部屋で流しました。感想があれば、音声を聞きながら随時Slackに書き込みしてもらいます。

最後に少しだけ感想タイムを設け、終了後は匿名のアンケートを実施しました。

結果

Slackの感想用スレッドは予想以上に賑わい、アンケートも参加者20名のうち18名が回答してくださいました。一部をご紹介したいと思います。

 

モチベーションUP系

  • 自分の仕事がどう活きているかを知ることができて嬉しい。お客さまが喜んでくれている様子が励みになる。
  • 高度に組織化されている中で開発をしているのでユーザーの存在を忘れがちになるが、企画を通して思い出すことができた。

開発に対するメリット系

  • 情報表示の出し方ひとつでお客さまの反応が大きく変わることを実感できた。
  • 我々は開発の際にユーザーの目線を想像しながら開発を進めるが、その想像の解像度や質をより高められそう。
  • 開発サイドとして製品の扱い・仕様に慣れてしまうと、ユーザーの考えに対し乖離が生まれやすい。見つめなおすきっかけになった。

オペレータの対応への称賛系

  • 丁寧で無駄のない回答がすごい。自分より製品の仕様に詳しいのでは……?
  • カスタマーセンターにも弥生会計を支える力強い仲間がいることを実感できた。
  • オペレータの方が苦労しないようにしなければ。。

 

意図していた以上の良い刺激になったことが感想から伺えます。

 ➁お客さまのことがよくわからないなら、わかる人にお聞きすればよいじゃない。

やったことのふたつ目は顧客サービス本部とのオンライン交流会です。

顧客サービス本部(以下CS本部)はお客様対応のプロ、つわもの揃いのカスタマーセンターを運営している本部です。

ただ実のところ、エンジニアは「お客さまと直接かかわる機会なんてない」だけでなく他本部の方とも関わり少なめです。ぶっちゃけ大体のメンバーはお互いなにしているかもよく知らない状態です。

(補足)弥生本社が東京にあるのに対して弥生のカスタマーセンターは大阪と札幌の2拠点にあります。物理的にも遠い。何かある時はSlackでやりとりしています。

 

しかし顧客対応音声を聞いた今、エンジニアの間でオペレーターに対する感謝と尊敬の念が爆上がりしています。やるなら今ですね。というわけで思い切って交流会を企画しました。

交流会は2時間。今後本部をまたいで連携しやすくなるよう情報共有と対面コミュニケーションを主目的と決め、終始ラフな空気感で進めました。

 

参加メンバーは20名強、主なトピックは以下のとおりです。

  • 自己紹介/各メンバーの業務内容紹介
  • CS本部メンバーによる、お客さまの目線を交えた要求説明
  • オペレーターやそのリーダーによる「機能に対するお客様の反応」共有
  • エンジニアからの質問

やや固そうに見えるトピックですが、会は大いに盛り上がりました。製品への愛、お客さまへの思いが溢れて2時間があっという間に過ぎ、事前に予定していた質問を半分あきらめたほどです。

結果

後日実施したアンケートでいただいた感想をご紹介します。

エンジニアの感想

  • 私たちはお客様がどのように製品を使っているかが見えないので、それを知るいい機会になった。
  • ユーザーに接している方からの声が聞けてよかったです。 すぐに対応できそうな機能もあるので早くリリースできる仕組みがあるといいなと思いました。
  • 要求の背景、サポートの現場の苦労を知って、自分の開発の意味・意義への理解が深まった。要件定義で今までより一歩踏み込んだ考え方ができるようになったと思います。

 CS本部メンバーの感想

  • 製品や開発プロセスへの理解が深まりました。なぜこの機能があるのか?と思っていたことが、開発側の理由や背景なども知れてよかったです。
  • 現場から要望をお伝えしても伝わっているのか分からないし、一方通行のような気持ちでいたのですが、逆に自分たちも開発の方々の事情を知らないままだったと感じました。
  • 遠い存在で関わることは無いと思っていた開発の方々のお話を聞くことができ、前よりも近しい存在に感じられるようになりました。お客さまのお声をもっとお届けできるよう頑張ります!

 

立場は異なれど、同じ製品に携わる者同士での交流はお互いに大きな収穫がありました。

また、交流会以降、何かある時はテキストコミュニケーションだけでなく、Zoomで直接お話しするなど気軽に連携を取るようになりました。遠慮や不安による壁を取り除くことができたのかなと思います。

まとめ

同じチームの中だけでやりとりしていると思考が固定化され、どうしても新しいアイディアや改善策が生まれにくくなります。

今回私たちは実際に製品を使用するお客さまの生の声を聴き、日々お客さまと接する仲間からお客さま全体の反応を知り、我々エンジニアとは異なる観点での製品に対するフィードバックをいただきました。

これからも顧客目線醸成のための取り組みを継続し、エンジニア目線と顧客目線の両立による良い製品開発の土台にできればと思います。

 

ここまでお読みいただきありがとうございました!!

 おまけ:これからやろうとしてること紹介

余談ですが、現在弥生では「会計事務所訪問」を計画中です。

エンジニアが会計事務所を訪問し、製品がどのように使われているかを現地で見せていただいて改善につなげたいと考えています。いつか記事になるかもしれないのでお楽しみに!

 

⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒*⌒

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

herp.careers

エンジニア未経験の新卒が語る弥生の開発ってこんなところ

この記事は  弥生 Advent Calendar 2023の14日目の記事です。

こんにちは、弥生でエンジニアをしている福島です。

好きな勘定科目は「のれん」です。(バトンが渡されたか、拾ったかは分かりません。)
初めて習って、会計ってこんな事柄も数値に起こすのか!とビックリした印象があります。
あと、数少ない"ひらがな"なのと語感が好きです。

普段は、AWSを中心に使って開発を行いデータ分析基盤の構築を行っています。弥生がお客様に提供しているサービスの情報から社内のデータまでさまざまです。
いっちょ前にデータの構築と語っている私ですが、実はIT歴0年から始めた新卒エンジニアです。
今年4月に入社した当時は、「開発よりマーケティングをしたい!」と思っていた私ですが、研修を通して「開発っておもしろい!」となり、配属希望を開発本部にしました。

そんな入社半年ちょっとの私が紹介する弥生の開発ってこんなところを紹介します!

いい人が多い

これは多くの人が語るポイントかなと思います。
面接時や懇親会などで「弥生への印象は?」と質問すると、9割近い確率で「いい人が多い」と答えます。
(※筆者調べ)
新卒から中途まで多くの方が、そうおっしゃるので文化として根付いているのかもしれません。

また、実際に働いていてもそう感じます。私のような未経験のひよっこでも質問したら丁寧に答えてくれますし、困りごとや体調とかにも「無理していないか」と声をかけてくれるなど、優しさを感じる場面が多いです。働きやすいと感じる一面でもあります。

学べる機会が多い

入社して約3か月間は、マーケティングから開発に関わることまで希望職種関係なく新卒全員で学びます。
この期間に開発研修でチーム開発を行い、初めてプログラミングに触れた私は開発の沼にハマり、マーケティング本部から開発本部に配属先の希望を変更しました。また、データに興味があったので、データ分析基盤を構築する部署を志望しました。

さらに、開発本部に配属されてからも製品に対しての理解を深めたり、チームでの開発を学んだりなど手厚い研修を受けてきました。きっちりと土台を作ったうえで、業務に移ることができました。

(※研修内容については、変更がある場合がございます。筆者の体験した一例です。)

全体向けの研修

新卒向け以外にも、学ぶ機会がたくさんあります。

最近だと、AWSに関する研修が多い印象です。
私も「Architecting on AWS」というクラスルームトレーニングを先日受講しました。自身の知識の定着度を再確認できる良い機会となりました。

また、仕事をするうえで必要な知識を学ぶ研修も多く用意されており、希望制で参加できます。
新卒研修を終えてからも多くの研修が用意されており、学ぶ機会を得やすい環境だと感じています。

LTやもくテク

インプットだけでなく、アウトプットする機会もあります。それが、LTやもくテクです。
弥生には月に一度、LT大会というものがあり、5分間で個人やチームでの取り組みを紹介することができる貴重なアウトプットの場となっています。また、聞き手としてもさまざまな事例を知れて学びになります。

また、もくテクという社外向けに開催しているイベントもあります。もくテクは、「木曜日にテクノロジーを語ろう」が由来となっています。外部に向けて発表する機会はあまりなく、大変学びになります。次回は「読んでよかった技術書・ビジネス書LT」をテーマに行います。私も登壇しますので、興味が湧いた方はぜひご参加ください。

mokuteku.connpass.com

柔軟な働きかた

仕事するうえで学びなども大事ですが、働きやすさも同じくらい重要かなと思います。

開発本部に関しては、リモートワークが中心となっています。フルリモートで働いている人もおり、働き方の選択肢の幅を感じます。私も稀に出社しますが、席がほとんど空いていることもあります。オフィスに関しては、フリーアドレスとなっており、基本的には好きな席で仕事をすることができます。

昨年の記事になりますが、リモートワークについて詳しく書かれています!

tech-blog.yayoi-kk.co.jp

そして、柔軟な働き方を実現している大きな部分として、フレックスタイム制(コアタイム10:00~15:00)の導入があると思います。
私のように朝型な人は、早めに出勤して仕事ができます。また、中抜けして、病院や市役所などにもいけるのも嬉しいです。自身の生活リズムや事情に合わせて働けるのはありがたいと感じています。

やりたいことができる環境

未経験からエンジニアになったというところから、「やりたいことができる環境」でもあると感じています。

私の周りにも、若手でプロジェクトの中心にいる方や希望した仕事で成果を出している方もいます。また、そのような人たちからは、「周りの人が「やりたい」という思いに耳を傾け、実現に向けて手助けしてくれる」と聞きます。

そのような意味で、成長に貪欲になればなるほど、挑戦の機会が降ってくるような環境になっていると思います。

一緒に働く仲間を募集しています

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

herp.careers

出社したくなる環境を整えよう!(浪漫)

弥生のkurokiです。開発本部でプロジェクトマネージャーを担当しています。CTLというシステム開発部の落穂拾い役でもあります。
ちなみに好きな勘定科目は「現金」です。弥生会計の内部ID=4です。

さて弥生では、コロナ禍を機にフルリモートワークができるようになりました。今やすっかりリモートワークが定着しています。
コロナ前は秋葉原UDXに2フロア借りていましたが、リモート中心になったため1フロアに縮小。しかし、残ったフロアは大改装。

オフィスからスカイツリーが見えます。
フリーアドレスのオフィスレイアウトです。

好きなところに座って良いフリーアドレスのレイアウトになりました。
改装費用をどーんと投じて素敵オフィスになったので、もっと出社メンバーが増えてほしいところなのです。
そんなわけで、社員がもっと出社したくなる施策として、いくつか浪漫あふれる機材が導入されました。せっかくなのでご紹介します!

コーヒーマシン

今までこのコーヒーマシンを2台稼働していましたが、1台に絞りました。

弥生のオフィスには、このコーヒーマシンが設置されています。
オンデマンドで珈琲豆を挽いてコーヒーを淹れてくれる素敵マシンですが、今回、浪漫あふれるコーヒーマシンにアップグレードされました!

浪漫あふれるコーヒーマシン!

新規導入されたDaiohsのカフェラウンジサービス。カフェクオリティのドリンクが楽しめます!パチパチパチ!

チョコチーノ抽出中。

お気に入りのチョコチーノを淹れてみました。ふんわりミルクフォームもできあがります。
これを自宅で淹れるのはいろいろ大変ですが、弥生のオフィスに来れば手軽に楽しめますよ♬

ウルトラワイドモニター

仕事用のモニターには、これらのアプリを常時表示しています。

  1. Zoom
  2. Slack
  3. ブラウザー
  4. Outlook

これらを見やすく配置できるモニターとして、DELLの34インチのウルトラワイドモニター(21:9)を買った私。
めっちゃ快適なリモートワーク環境になったので、もうオフィスには行かなくていいかな?思ったほどでした。

そんな人が増えてきたので、自宅にはなかなか導入できないような、浪漫あふれるモニターが導入されました!

浪漫あふれるウルトラワイドモニター!

Dell デジタルハイエンドシリーズ U4919DW 49インチワイド曲面モニター
実測1.2m幅のモニターは、置く場所も選びます(汗)。

横から見るとかなり湾曲して見えます。

横から見るとかなり湾曲していると感じますが、真正面に座ると曲面を全く感じないのが不思議です。

解像度は5120x1440と広大です。

解像度は5120x1440。27インチQHD(2560×1440ピクセル)のデュアルディスプレイ相当。
めっちゃ広いので、Microsoft PowerToysのFancyZonesを使用して、広大なディスプレイを4分割にして利用しています。
デュアルディスプレイと違って、中央で強制的に二分割されないのも嬉しいですね。

ディスプレイレイアウトの一覧。

ちなみに、このモニターのレイアウト名は「浪漫砲グリッド」ですw

社員募集

弥生では一緒に働く仲間を募集しています!
リモートワーク&フレックスという柔軟性のある働き方ができる企業です。オフィスワークとリモートワークを組み合わせる「ハイブリッドワーク」も、社員の意思で選択可能です。

弥生で働くことに興味がありましたら、求人一覧をぜひご覧ください。

herp.careers

AWS認定合格に役立つ公式神リソースがこんなにあるって知ってました?

この記事は弥生 Advent Calendar 2023の13日目の記事です。

こんにちは、情報システム部の小坂です。

よし、AWS認定を取得しよう!と思っても
何を使って勉強するかは悩む点ではないでしょうか。
私は2023年3月にSAAを、7月にDVAを取得しました。
SAA受験時は参考書をメインで利用して対策を行いましたが、
DVAを受験した際には試験が改訂されたばかりで参考書がほとんど出ておらず、学習方法に悩みました。

しかし、実はAWS認定試験対策に役立つAWS公式のリソースが潤沢にあります。
これだけ潤沢な公式のリソースを活用しない手はないでしょう!

私もDVA受験時は、これから紹介するAWS公式リソースのみの対策で合格することができました。
そこで、AWS認定対策に役立つリソースを一挙ご紹介します!

試験ガイド

まずはここから始めるべき!といえるのが試験ガイドです。
例:DVA-C02の試験ガイド

「試験ガイド?そんなの確認するの面倒臭い」と侮ることなかれ。
試験でどんな能力が求められるのか、何が問われるのかこの試験ガイドを見れば概要を掴むことができます。

ガイドを一通り見て、あまり触ったことがないサービスや、理解が甘い観点が無いかチェックしておくとよいでしょう。
例えば、DVA-C02の試験ガイドには下記の記述があります。

• Amazon Cognito でのユーザープールと ID プールの比較

上の記述を見ると、次の質問には答えられる必要があります。

  • Amazon Cognitoとはそもそもどんなサービスか。
  • ユーザープールとIDプールはそれぞれどんな目的でどう使われるのか。
  • ユーザープールとIDプールの違いは何か。

どうでしょうか。上に挙げた質問に答えられるでしょうか。

答えられない場合、重点して学習すべき事柄であることが分かります。
このように、試験ガイドを利用して自分の理解が不十分である分野や観点をしっかり確認しておくことはとても大切です。

サンプル問題

AWS公式が提供しているサンプル問題です。
無料でダウンロードできるPDF形式のサンプル問題10問が解説付きで収録されています。

例:DVA-C02のサンプル問題

実際にどんな内容が出題されるのかを把握するのに役立ちます。
※同じ問題が本番の試験で出題されるわけではありません。

サンプル問題を解いて、どんな点に理解が不足していたのか把握しておくとよいでしょう。
付属の解説は詳しく、参考サイトへのリンクもあり役立ちますので、一通り目を通しておくことをおすすめします。

Exam Readiness

Skill BuilderのAWS認定用コンテンツです。
AWSの中の人が試験の全体像、各分野のポイントを映像で解説してくれます。
試験問題を扱った解説では、回答時の着目ポイントや解き方の例が分かりやすく解説されていますので、試験解答時の考え方が身に付きます。
注意事項としては、これを見れば合格できるといったものではなく、あくまで全体像を把握するためのコンテンツであるという点です。
全体像の整理におすすめです。

AWS BLACK BELT ONLINE SEMINAR

AWS鉄板のBLACK BELTもやはり認定対策に有用です。
各サービス毎に約60分の解説動画がYouTubeで配信されています。
AWS公式のサービス別資料から検索することができ、セミナーで使用されたPDFもダウンロード可能。
一部動画が無いサービスもありますが、主要なサービスは網羅されています。

例えば私の場合、試験範囲に「Amazon Cognito」が含まれるが、Cognitoをあまり理解していない 状態の時期があり、BLACK BELTでAmazon Cognitoの動画を見て学習しました。

サービス毎に理解を深めたい場合は利用しておきたいリソースです。

公式模擬試験

Skill BuilderのAWS認定用コンテンツです。
各試験毎に下記のコンテンツが用意されています。
AWS認定の問題は質問内容が独特なので、しっかり数をこなして慣れておくと本番でも落ち着いて試験に取り組むことができるでしょう。

コンテンツ 問題数 価格
Official Practice Question Set 20問 無料
Official Practice Exam 本番と同じ 有料

20問のQuestion Setは無料で解くことができます。
Practice ExamはSkillBuilderの有料サブスクリプション登録が必要ですが、本番と同じ問題数で対策ができます。

また、解説が充実しているので、熟読しておくことがおすすめです。
該当のサービスや仕様についてのAWS公式ドキュメントへのリンクが貼られていますので、解説を読み込むことでも様々な気づきがあり、勉強になります。

JP Contents Hub

JP Contents HubはAWS公式の日本語ハンズオンを集めたページです。
試験対策用のコンテンツではありませんが、あまり触ったことがないサービスを効率よく学習するにはうってつけです。

まとめ

今回はAWS認定合格に役立つ公式の神リソースをまとめました。
実は私、次の認定 AWS Certified SysOps Administrator - Associate(SOA-C02)合格に向けてまさに上記に挙げた神リソースを使って勉強を進めているところです。
次も合格できるよう頑張っていくぞ~!

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

エンジニアがAWS re:Inventに行くべき3つの理由

はじめに

こんにちは。弥生株式会社の田邊です。先日11月末、アメリカのラスベガスでAWS re:Invent2023が開催され、現地参加してきました。 普段はサービス開発チームのアプリケーションエンジニアをしていて、業務の中でAWSサービスを使う機会は多いです。

私はre:Inventに現地参加するのが初めてでしたが、とても良い体験になりました。ただ、ラスベガスでの開催ということもあり、金銭的・日程的負担から参加のハードルは少し高いのではないでしょうか。ちなみに私は高かったです。

この記事を読んでいる皆さんの中にも、re:Inventは知っているけど参加したことはない、参加しようか迷っているという方がいるかもしれません。そんな皆さんに、現地参加するとどんな良いことがあるかを知ってもらいたいと思います。

re:Inventとは

AWS re:Inventとは、AWSが主催する国際的なカンファレンスイベントです。世界各国からユーザーやパートナーが集まるカンファレンスになっています。 AWSやパートナー企業のEXPO(展示会)やAWSの講演に加え、例年新サービスの発表などもあります。 講演は6日間で3000近い数が開催され、ハンズオンやプレゼンテーション、参加型のディスカッションなど、形式も多岐にわたります。

世界的に注目されるイベントということもあり、新サービス発表などはインターネットで配信されます。発表された新サービスは日本語でも速報記事が出ることが多いです。

さて、そうなると「情報は日本にいてもキャッチアップできるんじゃない?現地参加しなくても日本で情報を追えば十分でしょ」「AWSが公開しているハンズオンも記事もたくさんあるし、わざわざ現地に行かないと得られないことってあるの?」と考えるエンジニアも多いのではないでしょうか。ただ、やはり現地でしか得られないものもたくさんあるなと参加して感じました。今回の記事では3つ抜粋してお伝えしようと思います。

なぜ現地参加するのか

セッション参加

セッションに実際に参加することで、日本では得られない多くの学びが得られます。確かにAWSは日本でも実施できるワークショップや閲覧できる記事が公開されていますが、AWSのオリジナルのワークショップや講演がたくさんあります。一例に、私が今回参加した講演は以下のものがありました。

  • Enhance your app’s security & availability with Elastic Load Balancing
    • ELBのセキュリティ、可用性向上のための設定方法を紹介するプレゼンテーション
  • Composable architecture using Amazon DynamoDB and domain-driven design
    • ドメイン駆動設計において、DynamoDBがどのように有効にアーキテクチャとして組み込まれるかを紹介するプレゼンテーション

どうでしょうか。かなり限定的な話題に感じませんか?

もちろんほかにも一般的な話題のワークショップもたくさんありますが、自分の興味や業務範囲に近い内容をピックアップして受けることができます。このように、自分が学びたい内容を深堀できることが参加のメリットといえると思います。

ELBのセッション概要

様々な人との交流

re:Inventには世界中から多くの人が集まっていて、様々な形で交流することができます。 例えば、EXPOでは気になる会社のサービスについての情報を聞くことができたり、参加型のディスカッションの講演では他社の事例を知ることができたりします。今回の私の場合は、re:Inventに参加した日本企業が集まるパーティに参加したので、そこでも他社での事例などの情報交換をすることができました。

日本企業が集まるパーティの様子。クイズ大会なども開催されました。

モチベーション向上

新サービスが発表されるのを実際に聞いたり、講演で新たな知見を得たりすることでAWSのサービスについて色々学びたいというモチベーションがかなり上がりました。日本で発表された情報を得るのと、現地で実際に聞くのでは得られるインパクトがかなり違うと思います。

もちろん前述のようにre:Invent自体で得られるものは多いですが、参加したのは11/27(月)~11/30(木)の4日間で、1年間の365日の中の1%に過ぎません。残りの99%の時間を過ごし方が変わるという意味では、個人的には一番これが大きいと感じました。

New LaunchのサービスAmazon Qの発表の様子

おわりに

いかがでしょうか。こちらの内容が、re:Inventへの参加を悩んでいるエンジニアのあなたへの参考になれば嬉しく思います。

また、弥生株式会社では一緒に働く仲間を募集しています!詳細は↓よりご確認ください。

herp.careers

ChatGPTのプロンプトテクニック

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

弥生の石橋です。開発本部でデスクトップ製品共通モジュールのエンジニアを担当しています。
突然ですが、皆さんChatGPTは使っていますか?
文章の校正やコーディングのお供はもちろん、YouTuberの挨拶を考えるなんてこともしてくれる頼れる相棒です。
職場によっては使用が制限されていることもあるかと思いますが(前職はそうでした)、仕事ではなくても勉強しててわからないことを聞いたり、一週間の献立を考えてくれたりと様々な場面で活躍します。
そんなChatGPTですが、効果的な質問の仕方(プロンプト)が存在するのをご存じでしょうか?
本記事ではプロンプトシステムと、それを使った例をご紹介します。

プロンプトシステム

深津式プロンプト

深津式プロンプトは、note株式会社のCXOである深津 貴之氏によって考案されたフレームワークです。
具体的な役割(例:プロのエンジニア)を命令して、指定した制約条件のもとで質問や指示を入力する形式となっています。

#命令書:
あなたは、<役割>です。
以下の制約条件と入力文をもとに、 最高の結果を出力してください。

#制約条件:
・最高の結果を出すために追加の情報が必要な場合は、逆質問をしてください。
・<文字数>字以内で回答してください。
・<その他制約条件>

#入力文:
<入力文>

#出力文:

おすすめの制約条件

命令書はほぼテンプレートで、入力文は質問や指示がそのまま入るので、いかに上手い制約条件を課せるかが深津式プロンプトにおいて重要です。
私がよく使う、おすすめの制約条件を紹介します。

小学生でもわかるように答えてください

質問全般で役に立つ制約条件です。
これを指定するだけでChatGPTの回答がとても易しくなります。
具体例を出すように入力した場合、例の内容が身近なものになり、理解しやすくなります。

PlantUMLの図が出力できるテキストを提供してください

ソフトウェア関係の質問で役に立つ制約条件です。
コードをそのまま入力し、「このプログラムのフローチャートを出力してください」と入力すればPlantUMLの図がすぐに手に入ります。(もちろん機密情報の取り扱いには注意してくださいね!)
ソフトウェアの勉強をしているときも、説明や具体例だけでなくUML図などもあわせて出力してくれるのでとても捗ります。

具体例と違反例を提示してください

これもソフトウェア関係の質問で役に立つ制約条件です。
具体例と違反例があるとグッと理解が深まります。
上記2つとの合わせ技で、小学生でも理解できるような例の提供とPlantUMLでの図の出力ができるのでおススメです!

深津式プロンプトの例(単一責務の原則を教えてもらう)

# 命令書:
あなたはプロのエンジニアです。
以下の制約条件と入力文をもとに、最高の説明文を出力してください。

# 制約条件:
・小学生でもわかるように答えてください。
・PlantUMLの図が出力できるテキストを提供してください。
・具体例と違反例を提示し、図もあわせて出力してください。
・回答は長くなってかまわないので、できるだけわかりやすく回答してください。
・回答の質を高めるためにもっと情報が必要な場合は、私に質問をしてください。

# 入力文:
単一責務の原則について教えてください。

# 出力文:

ChatGPTの回答例

単一責務の原則は、1つのクラスやメソッドは1つの責務(役割)だけを持つべきだという考え方です。これは、プログラムの保守性や拡張性を高めるための重要な原則です。

たとえば、レストランの例を考えてみましょう。料理人が料理を調理する責任、ウェイターが注文を受け取る責任、会計士が支払いを処理する責任などがあります。料理人が支払いを処理することは責務が混乱しています。

具体例として、単一責務の原則に従ったクラス図を示します。

@startuml

class 料理人 {
    + 調理する()
}

class ウェイター {
    + 注文を受け取る()
}

class 会計士 {
    + 支払いを処理する()
}

料理人 --> ウェイター : 注文
ウェイター --> 会計士 : 支払い

@enduml

違反例として、単一責務の原則に反するクラス図を示します。

@startuml

class 従業員 {
    + 調理する()
    + 注文を受け取る()
    + 支払いを処理する()
}

@enduml

この違反例では、1つのクラスが料理する責任、注文を受け取る責任、支払いを処理する責任を全て持っており、単一責務の原則に反しています。これにより、変更が必要な場合にコードの修正が複雑になり、保守性が低下する可能性があります。

単一責務の原則を守ることで、各クラスやメソッドが明確な役割を果たすことができ、コードの理解や保守がしやすくなります。

PlantUMLで出力した画像は以下になります。

具体例
違反例

いかがでしょうか?
身近な例で図付きで説明してくれるので、すごくわかりやすい回答が得られたと思います。
「入力文」だけを修正すればよいので、上記の例をテンプレートとして保存しておくと便利です。

ReActプロンプト

ReActプロンプトは推論、行動、最終的な見解の3ステップを踏まえて質の高い応答を得ることができるプロンプトです。
質問内容の後に、Thought、Action、Observationと記述するだけでよいため、簡単に回答の質を高めることができます。

<質問内容>
Thought :
Action :
Observation :

ReActプロンプトの例(ソフトウェア開発についての相談)

これからのソフトウェア開発において重要なことは何でしょうか?
Thought :
Action :
Observation :

ChatGPTの回答例

Thought(考え方):
ソフトウェア開発において重要なことは、持続的な価値提供とユーザー中心のアプローチです。ソフトウェアはただ動作するだけでなく、ユーザーのニーズや期待に応えることが不可欠です。また、テクノロジーの進化やビジネス環境の変化に対応し、持続的に価値を生み出すことが求められます。

Action(行動):
1. ユーザー中心の開発:ユーザーのニーズを理解し、使いやすい、価値のあるソフトウェアを提供するために、ユーザーのフィードバックを積極的に収集し、製品や機能を改善することが重要です。
2. アジャイル開発の採用:アジャイルなアプローチを用いて、継続的な改善を行いながら、柔軟かつ効率的にソフトウェアを開発・リリースすることが重要です。
3. 品質管理の向上:品質を重視し、テスト、コードレビュー、自動化されたデプロイなどのベストプラクティスを導入して、信頼性の高いソフトウェアを提供することが重要です。

Observation(観察):
これらのアクションを実践することで、以下のような効果が得られます:
- ユーザー満足度の向上:ユーザー中心のアプローチを取ることで、ユーザーのニーズに即したソフトウェアを提供し、満足度を向上させます。
- 迅速な変更への対応:アジャイル開発により、変化する要求や市場状況に迅速に対応し、価値を継続的に提供できます。
- 高品質なソフトウェアの提供:品質管理の向上により、バグの少ない、セキュアで信頼性の高いソフトウェアを提供できます。

このように、ユーザーのニーズを理解し、アジャイルな開発手法を採用し、品質管理を重視することが、今後のソフトウェア開発において重要なポイントとなります。

いかがでしょうか?
最初のThoughtから、具体的なActionが示され、Observationを踏まえて最終的に効果的な回答が得られていると思います。

おわりに

今回は深津式プロンプトとReActプロンプトの2種類を紹介しました。
まだまだ沢山のプロンプトシステムが存在する上、これからも新しく考案されていくと考えています。
上手にChatGPTを使いこなして、生産性を爆上げしていきましょう!

一緒に働く仲間を募集しています

弥生のエンジニアとして一緒に働いてみませんか?

herp.careers