本当に英語(英会話)ができないエンジニアがre:inventに参加しても楽しめるのか?

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

お久しぶりです。イトーです。
本年は縁あって、AWS re:invent2023へ参加することができましたのでその振り返りとなります。

とはいっても、新サービスやらなんやらはすでにいろいろなところで出ているでしょうからこれまたよく見かける内容ですが、 英語が全くできないエンジニアがre:inventに参加するとどうなるのか?について私視点で振り返ってみます。

他で見かける英語ができない、なんてレベルじゃないぐらい英語が苦手なので(読むのはなんとなくわかる事もある)同じく英語が苦手な方へ向けた応援メッセージ的になものになれば!という気持ちで記載します。

ちなみに私はこんな感じの状態です。

  • AWS歴:7年ぐらい
  • 英語:まったくダメ。信じられないぐらいダメ。多分英語アレルギー。いつかものにしたいと思っている。
  • 海外経験:今回が2回目

結論から言うと、

英会話できなくても楽しい!楽しめる!刺激にもなる!

が結論です!!
捻りも何もないですが、本当だからしょうがないんです。

とはいえ、本当に英語ができないとどうなっちゃうのかを実体験に基づき書いていきますので、何かの参考になれば幸いです。
ちなみにできるだけやり取りした後とかは「thank you」 など言うのがよいです。とりあえず言っておきましょう。

一つ注意というかこうしたほうが良いという意味で、間違ってもわからなくても会話するようにする、のが絶対的におすすめです。
後述の通り、会話しないでも突破できることは結構あるのですが英会話の練習を少しでも、ということを考えればネイティブと気軽に話せる機会を逃がす手はありません。

いよいよ始まる

入国審査が英語

いきなり鬼門である

初日から立ちはだかる壁。入国審査。英語で聞かれ、英語で答えなければいけません。
英語超苦手(というか経験不足なだけな気がする)勢からすれば、簡単な英会話でもそれはもう敷居の高いもの。
事前に準備しようとも、緊張して言葉が出ない。
さらに悪いことに緊張しているせいか簡単な英語で言ってくれても理解(解釈)できないんですよね・・・。
振り返って思い出してみるとあの時こう言ってたな、ってなるんですが。

入国審査はぶっちゃけ英語ができなくても問題ないので、テンプレ回答はできるだけ頭にいれるかメモしておき、聞き取れなかった場合には「I'm not good at speaking English」(私は英語が苦手です)と伝えれば、ゆっくり話してくれるか、日本語と英語が書かれた紙を出して指差しで質問してくれます(優しすぎるやろ)。笑
回答はもちろん英語で言わないとダメなのですが、単語で答えればOKなケースも多いので私はこれで乗り切りました(プライドもクソもありません)。

乗り継ぎ便のチェックイン、荷物預け

ニコニコしながらパスポート渡して、名前伝えただけでなんとかなりました。
ただ、前の方は別の人の搭乗券が発券されて問い合わせしたりしてたのでトラブル時は会話が必要になりそうです。

トランジット待ち時間(To米国内線)

搭乗時刻になるとアナウンスしてくれるが何言っているのかまったくわからないので、搭乗時間近くになったらゲート近くで待機。
ディスプレイにどのグループが搭乗手続きしているか表示されているので、ディスプレイで状況確認する。
ツアー参加の場合、アジア系の人を見つけてついていくでも良い。

海外空港(乗り継ぎ空港)での保安検査

周りの人に合わせればOK。
PC出してるか?タブレット出してるか?管理官がtablet , ipad みたいなこと言ってるか耳傾けてればなんとかなる。
(ちなみに米国は靴脱ぐのも必要です。)

海外航空会社のドリンクオーダー

ドリンク持ちながら来て何か話しかけてくれるので、ドリンクオーダーのことや!とわかる。
持ってきてくれているドリンクの中から言えば大丈夫(apple juice とか)

来たぜ・・・ラスベガス・・・!

ホテルチェックイン

私の時は自動チェックイン(端末操作)だったので、読めばなんとか。
気が短い端末だったので、ゆっくり読んでるとタイムアウトするぞ、とすぐ脅してくるのがなかなかシビアでした。
今回はKNTさんのツアー参加でしたので、側に現地スタッフさんが同行してヘルプしてくれていたため、分からなければ聞けばサポートしてもらえました。

レストランでの注文、清算

結構難しい。難易度☆☆☆☆。
ジェスチャーと単語でなんとか。
店員さんが何言ってるかわからない場合は「Sorry.」とか、もう一回言ってもらったりゆっくり話してもらう。
わからなければジェスチャーでなんとかする。
チップ注意。(チップについてはここでは触れません。)
店員さんも観光客相手に慣れていることが多いので、臆せず何度聞いてもちゃんと対応してくれます。

必ずフレンチフライあった気がするぞ

会場に入る時のセキュリティチェック

英語不要ですが、チェックに引っかかるとすぐ横にある方を指さされるので指示に従う。
基本的にバッグの中見せて、っていうことがほとんど。
何も言われなければそのまま先に進んでOK。
注意点は各会場で実施しているので、会場間の移動があると毎回セキュリティチェックをクリアする必要がある点。

re:inventのBudge Pikup

端末操作+パスポート見せるだけです。
アプリは事前に入れておくことをおすすめします。写真の登録も事前にやっておきましょう。
写真登録していないとその場で撮ることになりますが、それはつまり英語でのやり取りが発生するということなので要注意です。
(とは言っても、フォローしてくれるのでなんとか進められます。)

記念撮影ポイント。時間によっては列ができてる

re:inventのCertification登録

なんと日本人の方が日本語で対応してくれた。(とてつもない安心感である。)
レーン入る時に、Budgeの提示とCredly見せて、って言われるので先に開いて準備しておく。
確認(スマホ見てたり)する仕草をしていたら必要だと思って、見せればすぐにわかってくれます。
確認してもらったらBudgeを出すとシールを貼って貰える。これで認定者ラウンジに入れるようになります。

認定者ラウンジ

特に英語不要で入れます。入る時にBudgeに認定シールが貼ってるかの確認とBudgeの確認されるだけです。
見せれば特に問題なく入れます。
レゴブロックもらったりするのも基本は英語なしでGetできます。

おやつ時間で各会場でもおやつとコーヒー提供されますが認定者ラウンジはずっとある

セッション開催ホールの場所

ホテルの場所ではなくホテル内の会場の場所、です。
ホテルがバカ広く、ホテル入り口からre:inventの会場にたどり着くまでに15分~20分かかるのはザラ。
だいたいカジノ通る。
ところが、会場、さらに会場の中の開催ホールが結構わかりにくい。
ask me な方々に聞けば優しく道順など教えてくれるのですが、英語できないと聞けないので常に時間に余裕を持ち、余裕があるときは会場の場所を先に確認しておく。
慣れるまでが結構大変なので注意が必要です。

ちなみにシャトルバスですが、英語できないと乗りにくいな・・・と思ってましたが、できなくても問題なく乗れました。
流れにのればOK。だいたいは行き先の看板か、宛先表記もった方がいるのでそこに行けば大丈夫。

会場の表記がホテルによって異なるが同じ2Fを指してたりするので注意したほうが良いです。

  • UPPER LEVEL → 2F
  • LEVEL2 → 2F

ホテル間の移動も時間かかるので、スケジュールの組み方は特に注意したほうが良いです。
セッション開始10分前までに行かないと予約入れていてもキャンセルされます。(Walk-Upの入場があるため)

1つ1つの会場も広い

セッション参加

セッション開催の場所に行くと、カードチェックさせてねーと言われるのでカードチェックしてもらう。(Reserveしているかの確認)
セッション始まると、ところどころわかる単語が出てくるのみで話している内容だけだと・・・ちょっとわからないことも多い。これはどうしようもない。
これが即理解できるならそもそもこんな記事書いてない。
たいていはスライドに言いたいことは書かれているのでなんとなくこれがいいたいんだな、というのはわかるのでスライドよく見る。
不明点はOtterで文字起こしして、DeepLで翻訳して対応しましょう。リアルタイムはできないのがネック。
今年はChatGPTで翻訳してる方もいました。
いつか技術力で解決していきたい分野である。(言語の壁、いつかなくなるといいな)
AWS使っていると知ってる単語やワードは結構出てくるので、普通の英語よりわかった気になれる。
ちゃんと調べてないのですが、どうやらセッションも翻訳があるっぽい?みたいです。

セッション参加中

基調講演(Keynote)

re:inventの目玉となるコンテンツですが、当然英語です。
しかしながら、Keynoteはリアルタイム翻訳のサービスもあります。
会場に入ってすぐ右に行くと突き当りで翻訳サービス用のレシーバーとヘッドフォンを貸してくれてます。(数量限定)
人の流れにそっていくと右に行かずまっすぐ行ってしまい会場の奥へ向かい、受け取れなくなってしまうので流れに歯向かう勇気が必要です。
セッションに比べて英語はわかりやすい(らしい)。スライドも丁寧に作りこまれているので、なんとなーくわかった気になれるはず。
周囲が声上げたり、拍手したら新サービスの発表だったり、面白い発表だったりするので流れに乗ればOK。
個人的にKeynoteは翻訳機使わずに英語で聞いていたほうがその気になれるので、わからなくても英語にチャレンジするのがオススメです。
たいていのことはスライドでわかりますし。

Keynote

翻訳サービス

デカいクエリ投げて溢れることを表現したスライド。会場ではうけていた

会場で提供される食事

朝とお昼は会場で食事が提供されます。それ以外の時間でもおやつが提供されたりします。
給水所もかなり多く設置されてますが、いずれも特に会話の必要ないのでなんとかなる。
コーヒーやドリンク(コーラなどの炭酸飲料)も随所に設置されていて、自由に飲むことができるので節約もできます。
朝とお昼は各会場で食事もあります。
時間になったら会場に行って流れに乗ればOK。英語も特に不要です。
Mealと書いてある場所に行きましょう。

Meal

見事な赤いリンゴが丸ごと入ってたりする豪快なお昼

Expo

AWSパートナーだったり、協賛会社のブースがあります。
SWAGをたくさん配っていてユニークなものもたくさんあります。
ドーナツ配ってたり、時間によってはお酒もふるまったりとなんでもあり。
ただ、基本は英語で会話する必要があるので難易度は高め。
ブースによっては日本語対応してくれるところもあるようです。
日系企業もありました!!

re:play

とりあえず会場に行って、列に並べばOK。オリジナルグッズ(今年もTシャツ)も貰えます。
ここもほんとど会話なくてOK。周りに合わせていればなんとかなります。
卓球やドッジボールならみんな楽しんでいたので、勇気を出して参加するといい思い出になります。

re:play会場は派手

お土産や買い物

たいていはレジに商品を持って行きクレジットカードを手に持って待機していれば、そのまま端末でカード決済できるはず。
特に会話の必要はないです。(受け取る時にサンキュー!は言うとよい)

ラスベガスにはエッフェル塔も

チェックアウト

チェックイン時同様、端末操作だったのでなんとかなりました。

そんなこんなで個人的に得られたもの

re:invetへ行く前は結構ビクビクしていましたが、実際に行ってみると「行ってよかった・・・」「また行きたいな」と思えたのでとてもよかったと思っています。
英文見るだけで「うっ・・・」となっていましたが英文に関してはアレルギー無くなった気がします😂。
次回チャンスがあれば英語の勉強もっとしてから行くぞー!というように考え方が変わりやる気も出てきました。

実際に現地で見て、聞いて、触ったサービスなどは積極的に活用・導入していきたい!と感じる部分も多くとてもよい経験となりました。
(帰ってきてすぐにSAさんにQやAurora Limitlessについて問い合わせしました😂)

まとめ

細かく場面別に経験したことを書いてみました。英語が苦手だけどre:inventに行ってみたいあなたの背中を押す助けになれば幸いです。
できれば簡単な英会話ぐらいは絶対できたほうがいいので行くことを早めに決められるようであれば早めに決めてしまって、英語の勉強や英会話スクール行くのがおすすめです。

そんなこんなでなんとか渡り歩いてきましたが、結果的にはわからないことは多く大変ではあったものの世界のENGたちに囲まれ、彼らの熱いパッションにとても刺激を受けました。
大きなイベントといえば某コミ〇など参加したことも行ったことはありますがどちらかというとこれらはホームだったわけで、完全アウェーで日本人が(相対的にみて)少ないイベントは新鮮で刺激的なものでした。
繰り返しになりますが、世界中のENGたちと一緒に盛り上がれる貴重な機会です!機会があればぜひ行ってみて欲しいです!
現地でしか味わえない空気感、ワクワク感は得難いもので大切にしたいポイントではないかと考えています。
これは現地に行かないとわからないと思うので、英語できなくて不安でも是非参加して現地の熱気・空気感を体験して頂きたいと思います。
中でもKeynoteはre:inventの目玉コンテンツであり、一番盛り上がるので英語ができなくてもとりあえず参加するのがおすすめです。

セッションとは別に少しラスベガスを散策したりもしましたが英語ができればなあ、と思うことはやはり多かったので(間違いなく英語ができればもっと楽しくなる)英語の勉強がんばりたい、と思ったのも事実でした。

なお、

  • re:invent初参加
  • 英語が全くできない(ほんとにできないレベル)
  • 一人で参加

だと精神的に辛い(心細い)ので、ちょっと英語できる人と一緒に参加するかチームで参加するのがおすすめです。
これはre:inventに参加するだけなら英語できなくても問題ない(実際チームで行っても、参加するセッションなどは個々人で異なるはずで別行動になる)ですが、 re:invent以外で英語が必要になる場面がどうしてもあるためです。
(その場合は自分で解決しなければならない)

英語ができる場合はさらにre:inventの重要性が増すと思っています。(サービスを作成しているSAや、サービスの責任者に直接質問できる機会があるため)
チョークトーク等は配信も行われないので、英語ができる方は通常のセッションよりもお勧めです。

ちなみに、私はなぜか会場でたくさん外国人ENG達に話しかけられました。英語わからんのに😂。


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

herp.careers

デザインスプリントを導入して主要機能のUXを改善してみた

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

こんにちは。弥生のUXデザイナーのツダです。
好きな勘定科目は、月並みですが「売上高」です。

弥生入社前はもともとフリーランスで仕事をしていたのですが
(いまも会社員兼個人事業主を続けています)
自分で商売をしていると、帳簿付けをしていて売上高を計上できる瞬間が、
やはり一番テンションがぶちあがります。

あと、「旅費交通費」も好き。地方出張が続いて旅費交通費がいっぱいかかった月は
頑張ったな~~と自己満足に浸れます。新幹線や飛行機は経費に計上できる金額としてデカいのも良き。
「交際費」も好きですね。帳簿をつけるたびに楽しい記憶がよみがえり幸せな気持ちになれます。
それからそれから・・・
前置きだけで終わってしまいそうなのでこのへんで止めておきます。

この記事は、今年の夏に弥生のUXチームがデザインスプリントの手法について学び、
実際の開発フローに取り入れていった流れについてまとめています。
順を追って振り返っていきたいと思います!

デザインスプリントイメージ図

なぜデザインスプリントをやることになったのか

デザインスプリント導入前にやっていたこと

私たちのチームでは、製品の価値を高めるために日々UI/UXの改善を進めています。
ある画面の検討を開始した頃、私たちは既存製品の機能を備えること+αの改善検討という方針で
デザインを進めていました。

当時の私たちの思考は、

📌 バックオフィス業務は難しくて煩雑なもの
📌 そのために高機能な業務ソフトが必要
📌 お客様に、複雑な機能を使いこなして膨大な業務を完遂していただくにはどうすればよいか

というふうに、高機能な製品ありきで画面検討を行っていました。

転換点となった起業家インタビュー

3人で議論をしているイラスト

固定観念がぶっ壊される

デザインと並行して、サービス全体像の理解の一環で、
ターゲット像に近い起業家様へのインタビューも並行して実施していました。
そこで思いもよらず、私たちは発想の大転換を迫られることになりました。

バックオフィス業務に対する起業家のリアルな声 起業家のリアルな声

このインタビューを経て、UXチームメンバーが抱いた感想はほぼ全員同じでした。

「今作っている画面、全然使ってもらえる気がしないぞ・・・!」

2人でがっかりしている画像

根性論的フルマラソンから、ロールプレイングゲームへ

起業家さんは普段事業のことに頭を使っているのであって、
バックオフィス業務にはとにかく頭も時間もリソースを割きたくない。興味がない。意識もしたくない。

いま思うと至極当たり前のことなのですが・・・

📌 便利な機能がいっぱいあれば、お客様は嬉しいに違いない
📌 業務ソフトとして正しいのはこういう姿

という思考にとらわれるあまり、

📌 お客様が本当に必要としているものは何か

の視点がいつの間にか置いてけぼりになっていたことを、痛烈に気づかされました。

思い込みのイメージ図

起業家インタビューを転換点に、

「自分たちの発想を根本から変えないと製品を使っていただけない」

という危機感を強く持った私たちは、

「これからの業務ソフトがお客様に提供できる価値とは何か?」

を徹底的に議論し、デザインの方針を大きく変えました。

上昇していくイメージ図

旧デザインでは、いわばお客様に42.195kmのフルマラソンをいかに完遂してもらうか
考えていたようなもの。その発想を捨てて、

📌  とにかくすぐ使い始められる

📌  はじめは簡単なタスクからはじめて、使うたびに便利さを感じられることで
  小さな成功体験を積み重ねる

📌  お客様が使い方を覚えるのではなく、自動取得したデータが蓄積すればするほど
  業務ソフトがお客様についてより深く習熟し、事業を伴走するパートナーとして成長していく

そんなロールプレイングゲームのようなワクワクできる体験を、業務ソフトで描けないだろうか?

と、デザインの方針を大きく変更しました。

Afterの図 Afterの図

デザインスプリントについて知る

目指すべき方向は決まりました。そして、具現化する手法として様々な手法が検討された中、
私たちはデザインスプリントの手法を開発に取り入れることにしました。

デザインスプリントとは、GV(旧Google Ventures)が開発した手法で、
かんたんにいうと、以下の図のフローを、スクラム開発のように短いサイクルで繰り返して、
プロダクトをブラッシュアップする手法です。

デザインスプリントの概要図

課題図書を1冊選び読書会を実施することで、チーム全体で基礎的な知見のキャッチアップを行いました。

そのほか、Webの記事等でもデザインスプリントの実際の導入例について調査を行いました。
知見を集めるうちに、デザインスプリントは各フェーズには細かく作業が定義されているが、
検証内容に合わせて柔軟に対応してよいものらしい
ということが理解できました。

それならば私たちの開発状況にあったやり方で取り入れるができそう!ということで、
機能ベースですでに作られた画面案をもとに、まずはPhase5. テストからデザインスプリントを
回しはじめてみようじゃないか
ということが決まりました。

デザインスプリントのスケジュール図

デザインスプリントの実施

私たちはさっそくユーザビリティテストのための準備を始めました。
何度かスプリントを回していくうちに、定型の準備フローのようなものが作られていきました。

1. シナリオの作成

シナリオのイメージ図

ユーザビリティテストのシナリオを作成し、必要な情報を質問シートにまとめます。
この資料を作ることが事前準備の主な仕事になります。

質問シートは以下のような手順で作成しました。

  • 「この画面にはこんな機能が必要なはず」という画面ごとの仮説を立てる
  • 各画面が「お客様の成功体験・行動成果を達成できるものになっているか?」を確認するための
    検証ポイントを洗い出す
  • 検証ポイントを通過するシナリオを作る
  • シナリオの中に、画面上で操作してもらいたい「タスク」、画面の仮説を検証するための「質問」などを
    まとめ、レビューの際に使用する

その他にも、事前になりきってもらう人物像などを提供するなど、検証の精度を上げる準備も行いました。

2. プロトタイプの作成

プロトタイプのイメージ図

整理したシナリオをもとに、ユーザビリティテストで触っていただくプロトタイプの画面をFigmaで作っていきます。
自然な操作を再現するために、できるだけ画面のどこを押しても反応するように作り込みました。
スプリントを回すたびに、プロトタイプはレビューで得られたフィードバックを取り入れて
どんどんブラッシュアップされていきます。

3. ユーザビリティテスト実施

 ユーザビリティテストのイメージ図

すべての準備が整ったら、ユーザビリティテストを実施します。
今回は社内のカスタマーセンターのご協力のもと、日々お客様に応対しているメンバーに
テスターとして画面を操作いただき、その時の声、表情、言葉などを観察して質問シートにメモして
いきます。
さらに操作後のディスカッションで、操作時には拾いきれなかった心理面などを深掘りしていきます。

4. 仮説の検証、改善案をディスカッション

検証・改善のイメージ図

ユーザビリティテストのあとは、UXチーム関係者のみで振り返りを実施します。
レビュー時の記録は、検証結果を感覚ではなく論理的・客観的に見るために役立ちます。

ここで仮説に対する答え合わせや、テスターさんの予想外の操作などを中心にディスカッションして、
その内容が次のデザインスプリントの仮説・検証項目へと繋がっていきます。

デザインスプリントをふりかえって

UXチームでは、主要機能についてデザインスプリントを3回実施し、ブラッシュアップを行いました。
その結果、画面デザインは大きく生まれ変わりました。

詳細はお見せできないのが大変残念なのですが、どのぐらい変わったのかのイメージ図をご覧ください。
画面構成や情報量がガラリと変わっているのがお分かりいただけるのではないかと思います!

実施前・実施後の比較図 デザインスプリント開始前と比べると、新しい価値を体現したデザインに進化させることができたと考えています。

今後の展望

今後の展望イメージ

今後、デザインスプリントを通して完成した画面が実際に世の中に出れば、
私たちの考えた新しい価値が本当に正しかったのかという大きな検証結果が得られることになります。
価値をさらに高めるために、デザインスプリントを継続的に実践していこうと考えています!

この記事の内容は、取り組みのごく一部でしかありません。
デザインスプリントが気になる!もっと話を聞いてみたい!軽く雑談してみたい!などのご要望は、
ぜひコメントなどでお気軽に声をかけてください!

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

最後までお読みいただきありがとうございました! 弥生では一緒に働く仲間を募集しています! herp.careers

採用担当者に「インプットが面白い」と評された新卒の脳内

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

こんにちは、新卒1年目エンジニアの齋藤です。

早速ですが今回は、私の脳内について共有します。 半ば論理的で、半ば変わっている考え方をするので、記事にすれば面白いだろうという目論見です。

脳内の共有という事で、今回は技術的な要素からは離れ、ややマーケティング寄りの内容になっております。 創造性を豊かにしたい、息抜きしてみたい、見たことのないものに触れてみたいという方、ぜひお楽しみください。

形について

形とは、とても面白いものです。

それはある日の業務中のことでした。

机上のディスプレイとパソコンとエトセトラとにらめっこしていた時、ふとこのように思いました。

「ん?やけに机の上が四角いなぁ」

見れば、ディスプレイ、パソコン、本、卓上カレンダー、エクセルのセル、全てが四角いのです。

また、後日水族館へ行った際にはこのように思いました。

「おお、どの生き物も四角くないなぁ」

群れを成すイワシ、直立するペンギン、飛び跳ねるイルカ、全てが四角くありませんでした。

後で考えて分かったことがあります。

四角という形は人工物の形として向いているのです。

例えば、大きな円形のディスプレイを作ったとしましょう。 しかし、大きすぎたということで、このディスプレイから小さい円形のディスプレイを切り出したとします。 これでちょうどよい大きさのディスプレイが出来ました。
では、残った三日月形のディスプレイはどうしますか?

四角以外の形では、このようなデッドスペースが生まれ、生産の効率を悪くします。 他にも理由はありますが、人工物は四角で構成されていることが多いです。 ぜひ、周りを見渡してみてください。机上以外にも窓、部屋、ビルなど、世界にある四角が見えてくるはずです。

一方、イワシやペンギンなど、生物たちの親は人間ではないので、各々生存に有利な形に変化していきます。 その中で、空気や水の抵抗を受ける四角という形は、淘汰され少なくなっていったのでしょう。

さて、実はここまでが序章です。 ここからさらに思考を巡らせていきましょう。

面白いインプット

私は弥生の採用担当の方に、「なぜ私を採用しましたか?」と伺ったことがあります。 その際、このように言われました。

「インプットが面白い人だと感じた」

褒められちゃった。やだ、うれしい。ありがとうございます。

そして、私もそのように思います。

面白いインプットとは?と言いますと、前段のお話では次の箇所です。

「おお、どの生き物も四角くないなぁ」

面白い捉え方ですね。その上変わった捉え方です。

普通イワシを見た時、人は「四角くないなぁ」ではなく、「魚の形だなぁ」と捉えます。 理由として、魚をわざわざ四角くないと認識する必要がないと、脳が判断するからでしょう。

しかし、ここではあえて別の理由を提唱したいと思います。

それは、我々が水槽のイワシを見るとき、四角を見ないからです。

見えない形

人間の摂取する情報の多くは視覚情報と言われています。

そのため、目に見えていないものを想像することは難しいものです。

ここで、さらに小話を一つ。

一人暮らしの友達の部屋へ、3人ほど連れて初めて遊びに行った時のこと。

ある一人が重要なことを口にしました。

「あれ?この部屋冷蔵庫ないの?」

確かに、言われてみれば、その部屋には冷蔵庫がないのでした。

さらに、そのことに彼以外が気づくことはありませんでした。

視覚情報にとらわれていれば、そのようになることもうなずけます。冷蔵庫はそこにないので、視界に入ることもできません。目に見えないものは脳で0から想像する必要があります。

つまり、「トーテムポールが置いてある」など、通常部屋にないものがあることには当然すぐに気づきます。しかし、部屋にあるべきものがないことには気づきにくいのです。

イワシの場合も同様です。我々がイワシを見るとき、その水槽に四角は泳いでいません。四角が見えない限り、脳に四角という言葉自体が浮かびにくくなります。その結果、我々は「四角くないなぁ」などとは捉えず、イワシを見たままの「魚の形」として捉えます。

見たままの形でとらえることは、生活上必要かつ効率的な考え方です。しかし、時に、見えない形を想像する必要性も出てきます。「もっと速い馬が欲しい」という要望に自動車で応えたフォードがいい例です。

さて、ではなぜ先ほどの彼は、冷蔵庫の不在に気づくことができたのでしょうか。ここに、見えない形を見るヒントがあるはずです。

その理由は、彼がペットボトル飲料を持っていたからです。

見えない形を見る

彼はペットボトル飲料を冷やしたかったのでしょう。当然考えとして、冷蔵庫が浮かびます。そして、見えない冷蔵庫に気づくわけです。

つまり、彼は目に見えるペットボトルを通して、見えない冷蔵庫を見ていたのです。

ここから考えられる見えない形を見る方法がいくつかあります。

1.様々な知識や経験を積む

見えない冷蔵庫も、ペットボトルという関連物によって、見えるようになります。さらに言えば、色々な物を持っていれば、見えてくるものが増えるということです。

しかし、人の両手やリュックサックには限界があります。

そうであれば、色々な物を脳に持っておこうということです。

多種多様な知識や経験は想像を助けます。人に見えないものが見えるようになり、おのずと視野が広がります。燕の飛び方から天気を、何気ないガレキから大昔の生活を捉える人もいます。

知識という名のペットボトルです。

2.抽象化する

ペットボトルを持っていた彼には、まず「冷やしたい」という願望がありました。そしてその実現方法に冷蔵庫を思いつきました。

フォードも同様に、速い馬を「速い移動手段」に置き換え、自動車を作りました。

考えを一度抽象化してみましょう。そうすれば、考えは一旦「目に見える形」から離れます。

そして、再度「目に見える形」に戻した時、その形は思ってもみなかった形をしていることがあります。

また、抽象化する上で、「なぜこの形なのか」を常に考えることも有効かもしれません。

3.改善できることを信じる

たとえペットボトルを持っていたとしても、「冷やしたい」という不満がなければ、冷蔵庫は見えません。

不満は時に原動力です。現状への不満は、改善への糸口です。

人は改善したい物事に出会うと、自然と改善できていない理由に目が向きます。この段階ですでに「2.抽象化する」ができています。

しかし、改善の余地はないだろうと考え始めてしまうと、改善をやめるどころか、現状を許しはじめ、不満自体を持たなくなっていきます。

改善できると信じてください。世の中はうまくできていますが、まだまだ改善の余地はあります。

あとがき

いかがでしたか。

概念のガラクタ箱のようなお話で、私もまとめ作業にやや苦労しました。

この記事がマーケティングや要求定義などの、創造的な作業の一助になればと思います。

インフラエンジニアがChatGPTを触ってみた

インフラエンジニアがChatGPTを触ってみた

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

こんにちは。弥生のインフラチームでエンジニアをしているツジノです。いつもはクラウド環境のインフラをメインで担当しており、たまにオンプレ環境も触っていたりします。

さて、最近技術系のトレンドによくAIに関するワードが多いですよね。

その注目度はあのビル・ゲイツもAIはグラフィカルユーザーインターフェース以来の革命的な進歩といったコメントを残しているぐらいです。

今回はその話題なAI関連の中からChatGPTをインフラエンジニアが触れてみた記事となります。

チーム内のMTGでも『これはAIを活用できないか』といった会話が増えて来ており、一度触れてみたいと思っていたところにAdvent Calendarの時期となったため、それなら記事にしちゃえ!と思ったのがきっかけです。

よければ最後までお付き合いください。

ChatGPTでIaC

AzureやAWSにはIaC*1に使用できるARMテンプレートやCloudFormationがありますが、今回は私が良く使用する環境であるAzureのARMテンプレートで試そうと思います。

まずは簡単なAzureStorageAccountを作成できるか試してみます。

入力情報:Azure上でAzureStorageAcountを作成するARMテンプレートを作成してください。

出力情報

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2019-06-01",
      "name": "[parameters('storageAccountName')]",
      "location": "[resourceGroup().location]",
      "sku": {
        "family": "A",
        "name": "Standard_LRS"
      },
      "kind": "StorageV2",
      "properties": {
        "accessTier": "Hot"
      }
    }
  ],
  "parameters": {
    "storageAccountName": {
      "type": "string",
      "metadata": {
        "description": "Name of the Azure Storage Account."
      }
    },
    "resourceGroupName": {
      "type": "string",
      "metadata": {
        "description": "Name of the Azure Resource Group."
      }
    }
  },
  "outputs": {
    "storageAccountId": {
      "type": "string",
      "value": "[resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]"
    }
  }
}

単一リソースの作成だったので問題なくリソース作成することができました!

storage-001

次は複数リソースを必要とする指示を出してみます。

内容としては、以下を試してみます。

VnetとSubNetを新規作成し、そのサブネットにプライベートエンドポイントを持つAzureStorageAccount

入力情報

Azure上で以下リソースを新規作成するARMテンプレートを作成してください。
・リソース
Vnet:vnet001
Subnet:subnet001
StorageAccount:acstorageaccount001
PrivateEndPoint:pep001(subnet001に属し、acstorageaccount001に紐づけるリソースとする)

出力情報

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    // 1. Virtual Network (VNet)
    {
      "type": "Microsoft.Network/virtualNetworks",
      "apiVersion": "2021-05-01",
      "name": "[parameters('vnetName')]",
      "location": "[resourceGroup().location]",
      "properties": {
        "addressSpace": {
          "addressPrefixes": ["10.0.0.0/16"]
        }
      }
    },
   
    // 2. Subnet in the Virtual Network
    {
      "type": "Microsoft.Network/virtualNetworks/subnets",
      "apiVersion": "2021-05-01",
      "name": "[concat(parameters('vnetName'), '/subnet001')]",
      "dependsOn": [
        "[resourceId('Microsoft.Network/virtualNetworks', parameters('vnetName'))]"
      ],
      "properties": {
        "addressPrefix": "10.0.1.0/24"
      }
    },

    // 3. Storage Account
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2019-06-01",
      "name": "[parameters('storageAccountName')]",
      "location": "[resourceGroup().location]",
      "sku": {
        "family": "A",
        "name": "Standard_LRS"
      },
      "kind": "StorageV2",
      "properties": {
        "accessTier": "Hot"
      }
    },

    // 4. Private Endpoint
    {
      "type": "Microsoft.Network/privateEndpoints",
      "apiVersion": "2021-05-01",
      "name": "[parameters('privateEndpointName')]",
      "location": "[resourceGroup().location]",
      "dependsOn": [
        "[resourceId('Microsoft.Network/virtualNetworks/subnets', parameters('vnetName'), 'subnet001')]",
        "[resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]"
      ],
      "properties": {
        "subnet": {
          "id": "[resourceId('Microsoft.Network/virtualNetworks/subnets', parameters('vnetName'), 'subnet001')]"
        },
        "privateLinkServiceConnections": [
          {
            "name": "[parameters('privateEndpointConnectionName')]",
            "privateLinkServiceId": "[resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]",
            "groupIds": ["blob"]
          }
        ]
      }
    }
  ],
  "parameters": {
    "vnetName": {
      "type": "string",
      "metadata": {
        "description": "Name of the Virtual Network."
      }
    },
    "storageAccountName": {
      "type": "string",
      "metadata": {
        "description": "Name of the Storage Account."
      }
    },
    "privateEndpointName": {
      "type": "string",
      "metadata": {
        "description": "Name of the Private Endpoint."
      }
    },
    "privateEndpointConnectionName": {
      "type": "string",
      "metadata": {
        "description": "Name of the Private Endpoint Connection."
      }
    }
  }
}

PrivateEndpointの所でエラーになりましたね。

error-001

エラー箇所を調べてみるとが学習元と思われるMSのドキュメントが見つかりました。

StorageAccountのPrivateEndpointのドキュメントを見てみると構文が異なるようです。

修正しデプロイしてみます。

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    // 1. Virtual Network (VNet)
    {
      "type": "Microsoft.Network/virtualNetworks",
      "apiVersion": "2021-05-01",
      "name": "[parameters('vnetName')]",
      "location": "[resourceGroup().location]",
      "properties": {
        "addressSpace": {
          "addressPrefixes": ["10.0.0.0/16"]
        }
      }
    },
   
    // 2. Subnet in the Virtual Network
    {
      "type": "Microsoft.Network/virtualNetworks/subnets",
      "apiVersion": "2021-05-01",
      "name": "[concat(parameters('vnetName'), '/subnet001')]",
      "dependsOn": [
        "[resourceId('Microsoft.Network/virtualNetworks', parameters('vnetName'))]"
      ],
      "properties": {
        "addressPrefix": "10.0.1.0/24"
      }
    },

    // 3. Storage Account
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2019-06-01",
      "name": "[parameters('storageAccountName')]",
      "location": "[resourceGroup().location]",
      "sku": {
        "family": "A",
        "name": "Standard_LRS"
      },
      "kind": "StorageV2",
      "properties": {
        "accessTier": "Hot"
      }
    },

    // 4. Private Endpoint
    {
    "type": "Microsoft.Network/privateEndpoints",
    "apiVersion": "2023-06-01",
    "name": "[parameters('privateEndpointName')]",
    "location": "japaneast",
    "dependsOn": [
        "[resourceId('Microsoft.Network/virtualNetworks/subnets', parameters('vnetName'), 'subnet001')]",
        "[resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]"
    ],
    "properties": {
        "privateLinkServiceConnections": [
            {
                "name": "[parameters('privateEndpointName')]",
                "id": "[concat(resourceId('Microsoft.Network/privateEndpoints', parameters('privateEndpointName')), concat('/privateLinkServiceConnections/', parameters('privateEndpointName')))]",
                "properties": {
                    "privateLinkServiceId": "[extensionResourceId(resourceGroup().Id , 'Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]",
                    "groupIds": [
                        "blob"
                    ],
                    "privateLinkServiceConnectionState": {
                        "status": "Approved",
                        "description": "Auto-Approved",
                        "actionsRequired": "None"
                    }
                }
            }
        ],
        "manualPrivateLinkServiceConnections": [],
        "subnet": {
            "id": "[concat(extensionResourceId(resourceGroup().Id , 'Microsoft.Network/virtualNetworks', parameters('vnetName')), '/subnets/subnet001')]"
        },
        "ipConfigurations": [],
        "customDnsConfigs": []
    }
   }
  ],
  "parameters": {
    "vnetName": {
      "type": "string",
      "metadata": {
        "description": "Name of the Virtual Network."
      }
    },
    "storageAccountName": {
      "type": "string",
      "metadata": {
        "description": "Name of the Storage Account."
      }
    },
    "privateEndpointName": {
      "type": "string",
      "metadata": {
        "description": "Name of the Private Endpoint."
      }
    },
    "privateEndpointConnectionName": {
      "type": "string",
      "metadata": {
        "description": "Name of the Private Endpoint Connection."
      }
    }
  }
}

デプロイ成功しました!(StorageAccountはリソースを作り直している際に削除しても001、002が既に使用されてしまったため003となっています)

storage-002

StorageAccountを見てみるとちゃんとプライベートエンドポイントが紐づいており、プライベートエンドポイントもVnet/Subnetと紐づいています。

storage-003

結果

簡単な指示でも単一リソースならば出力結果をそのままデプロイしても問題なくリソースを作成できましたが、複数リソースとなると簡単な指示では手直しが必要となりました。

実際にサービスが稼働する環境を作ろうとした場合、今回の作成したリソースの数倍はリソースが必要となる事が普通です。

そのためまだ簡単な指示だけではサービスを稼働させられるような環境を構築する出力は難しそうです。

しかし、今回のような簡単な指示で手直しが必要とは言え複数リソースの作成とその紐づけをデプロイできるということは、作成・削除が頻繁に行われる検証環境作成などには十分活用できると思いました。

おわりに

今回はChatGPTでIaCができないか簡単に触ってみました。

最新版ではない無償版のChatGPT3.5を使用してみましたが、思ったより精度の高い出力結果が出てきて驚きました。

本記事ではIaCを試しましたが、構築だけでなく監視や分析など他の仕事でも活用できる場所がないか探っていきたいと思います。

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

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

herp.careers

*1:IaC(Infrastructure as Code)とは、サーバーなどのシステムインフラの構築を、コードを用いて行うことです。

AWS社内イベントに登壇(AWS MMSA Townhall meeting)

こんにちは!弥生株式会社でCTOをやっている佐々木です。

CTOの業務は多岐にわたるのですが、その中には外部イベント登壇も含まれます。私はココ2年ほど、マイグレーション/モダナイゼーションの事例を紹介する各種イベントに登壇してきました。
その中でも今回はちょっとマニアックな「AWS MMSA Townhall meeting」というAWS社員を対象としたAWS社内イベントについてご紹介します。
社内イベントなので内容の詳細については公表することは出来ないのですが、「ユーザの意見を取り入れるためにこんな取り組みもやっているのね!」という所からAmazonのOLPを感じていただければと思います。

  • AWS MMSA Townhall meeting (2023/9)

喋っているところ

MMSAは「Migration and Modernization Solution Architect」です。
Townhall meetingは「対話集会」なので、「AWSのマイグレーションやモダナイゼーションを担当しているSAが、AWSの利用者と直接対話する集会」というイメージです。
平たく言うと「お客様の声を聴こう!」的なイベントでして、私は「AWSの利用者」の立場でAWSに対して率直な意見や感想を伝える役割でした。
聴講者はマイグレーションとモダナイゼーションを担当しているAWSのSAを中心にCustomer Solutions Manager、APJ Migration and Modernization Business Development(事業開発)、Head of APJ Migration and Modernization Solution Architect、さらには、Global Modernization Tech Leadなど錚々たるメンバー、総勢40名にお集まりいただきました。
今年5月に海外のMMSAリーダーとビジネス開発のリーダーからモダナイゼーションの他社事例紹介とQ&Aセッションを受けており、この時のご縁から弥生のモダナイゼーションの取り組みが海外でも注目されています。

Publicなイベントでは話し難い、込み入った内容を中心にお話してきました。
あまり細かい内容はここには記載できないのですが、以下のような話題についてディスカッションしています。

  • なぜマイグレーションが必要なのか
  • なぜモダナイゼーションが必要なのか
  • なぜパッケージソフトからSaaSにビジネスを広げる必要があったのか
  • 弥生のお客さまや社内からの期待値は?
  • 実際に発生した問題とそれに対する対策は?何が効果が高かったか?

「なぜマイグレーションが必要なのか」「なぜモダナイゼーションが必要なのか」などはAWS自身がイベントなどでも語る事が多い内容ですね。
AWSがイベントで語られている内容は、実際の利用者のニーズが反映されているものなのだと感じました。

AWSのメンバーと記念写真

「実際に発生した問題とそれに対する対策は?何が効果が高かったか?」については、AMA/EBAを実施した成果を紹介しています。
AMA/EBAについては実際に参加したメンバーのブログも出ていますので詳細についてはコチラをご覧ください。
弥生×AWS×モダナイゼーション - 弥生開発者ブログ

※2023年12月現在、AMAはMODA(Modernization Assesment)に名称が変わっています

弥生で実施したAMA/EBAは、かなり盛り上がったとAWS内で話題になったそうです。
さて、何事も数字を見て語るAWSですが「盛り上がった」という定性的な内容をどうやって定量化したのでしょうか?
なんと!「カウベルを鳴らした回数」をカウントしていたそうです。そんなところまでデータを取って定量化しているのが流石だなと思いました。
弥生でやたら盛り上がったAMA/EBAですが、弥生から見た成果としては「AWSのクラウドインフラアーキテクチャの設計やアジャイルに関する知見を得られた」という想定通りの成果もありましたが、チーミングに対して想定以上の効果がありました。
チーム全員が一カ所に集まりカウベルを鳴らしながらワイワイお仕事をした結果、チーム内でのコミュニケーションが改善しています。
ちなみに「チーム内でのコミュニケーションが改善」を何で測ったかというと、「発言回数」と「メンバーの発言比率」です。

こんな感じで様々な事を試行錯誤しながら製品開発、マイグレーション、モダナイゼーション、SaaS開発を進めている弥生ですが、スモールビジネスのインフラとして日本の発展に能動的に貢献してくれる仲間を募集中です!


弥生では一緒に働く仲間を募集しています。一緒に、進化するチームで働きませんか?

herp.careers

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

こんにちは、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