2023-12-24

Amazon Qでトラブルシューティングしてみた【和訳付き】

AWS

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

はじめに

こんにちは。弥生株式会社の田邊です。普段はサービス開発チームのアプリケーションエンジニアをしています。今年の11月末にアメリカのラスベガスでAWS re:Invent2023に現地参加し、AWSへのモチベーションが高まりました。

（どれくらい高まったかは先日私が執筆した↓の記事をご覧ください） tech-blog.yayoi-kk.co.jp

AWS re:Invent2023でNew Launchとして発表されたサービスはたくさんありましたが、その中で私が着目したのはAmazon Qです。

AWSを使う開発者にとってかなり便利そうなサービスなので、今回はどの程度使えるのものなのかを実際に触って確認してみました。

Amazon Q

Amazon Qとは、生成AIを活用した業務向けのアシスタントサービスです。今話題になっているChatGPTやCopilotなどと競合するサービスです。応答形式の会話やチャットボット連携、ソースコードの変換サポートなど様々な機能がありますが、私が特に気になったのはトラブルシューティングの補佐です。

AWSでの開発を行っていると、少しの設定ミスでアプリケーションが動かなくなることは少なくありません。そのようなケースの場合、大抵は発生したエラーから原因を予測し、設定を見直すことになります。しかし、十分に成熟した開発者でなければ、原因をすぐに特定することは簡単ではありません。私がAmazon Qについての発表を聞いたときに思ったのは、「Amazon Qを使えば、トラブル発生時の原因特定が簡単になるのでは！？」ということでした。しかし、本当にそれほど上手くいくのか、実際に触って検証してみることにしました。

触ってみた

実際に業務支援Amazon Qのチャットを使って検証してみます。

※Amazon Qは日本語サポートされていないため、以降の検証は英語となります。英語が分からない方にも伝わるように日本語で補足します。分かりやすくするために一部和訳を簡略化しています。

AWSについての質問

まずは軽くお試しとして、AWSのサービスに関する質問をしてみます。

AWSサービスについての質問

「データベースを持つウェブアプリケーションをデプロイするにはどうすればよいですか？」

回答

1. EC2を使います。手動でのローンチでもCloudFormationやEC2 Auto Scalingを用いた自動デプロイでもできます。
2. 高可用性の確保のため、ELBを使って負荷分散を実現します。
3. データベースは、リレーショナルデータベースならMySQLやAurora、NoSQLデータベースならDynamoDBが使えます。
4. 自動デプロイのためにElastic Beanstalkを用います。
5. サーバーレスアプリケーションであれば、API GatewayやS3, DynamoDBを用いつつLambdaを使って実現できます。
6. CodePipelineを用いてCDを実現できます。

こちらが曖昧な質問をしているので仕方ないですが、一般的な答えが返ってきました。Amazon Qは対話式なので、↑の回答について追加で質問してみます。回答の1.の「CloudFormationやEC2 Auto Scalingを用いた自動デプロイ」について、両者の違いが分からなかったとして質問してみます。

追加質問

「CloudFormationとEC2 Auto Scalingの違いは何ですか？」

回答

1. CloudFormationはInfrastructure as Codeを実現するためのサービス。
2. EC2 Auto ScalingはEC2インスタンスを、必要に応じて自動でスケーリングするサービス。
3. CloudFormationを使うと、Auto Scalingグループを含め、インフラ全体をモデル化することができます。Auto Scalingはそれ自体ではAuto Scalingグループ内のEC2インスタンスの操作のみを提供します。
4. （省略）
5. （省略）

こちらも一般的な回答ですが、3.のように、「こういう違いがある」とピンポイントで説明してくれるのは良いですね。 AWSの公式ドキュメントを読めばわかる内容ではありますが、特に日本語の公式ドキュメントは~~何を言いたいのか分かりづらい~~初学者には理解しづらいことも多いので、対話式で分かることも大きいのではないでしょうか（とはいえ、これらの内容であればChatGPTなどの競合サービスでも十分な回答が得られそうですが）。

トラブルシューティング①：IAMロール

それでは本題に入りましょう。検証用に、Parameter Storeの値をLambdaから取得するという以下の構成を作成しました。

実際のコード等は以下になります。

Parameter Storeに格納された値を取得し、その値を返すLambda関数（左）Lambdaが取得する対象のパラメーター（右）

さて、この構成であれば、LambdaにはParameterStoreから値を取得するためのポリシーが付与されている必要があります。今回はあえて誤ったポリシーを付与しようと思います。

「parameter/ParameterKey」となるべき箇所が、「parameter/ParameterKez」となっているポリシーを付与したロールをLambdaに紐づけました。当然、Lambdaをテスト実行すると失敗します。

このエラーについて、Amazon Qに質問してみます。

エラーについて質問

「なぜLambdaファンクションがParameterKeyパラメーターを取得する権限を持っていないのか？」「getParameterPolicyのポリシーで権限を付与しているのに、なぜLambdaファンクションがPrameterKeyパラメーターを取得する権限を持っていないのか？」と質問しています。AWS内のリソースも参照してくれるようなので、ARNだけ渡して質問しているのがポイント。

回答

GetParametersを許可するロールは付与されているようですが、ARNで指定した特定のパラメーターを取得するための権限がありません。以下のことを試してください。
1. 特定のARNのパラメーターの取得を許可するようにポリシーを更新してください。
2. 広めのポリシーではなく、パラメーターを取得するための最小のポリシーを設定してください。
3. Lambdaのロールに正しくポリシーがアタッチされているか確認してください。
4. 最新の許可が設定されているか確認するためにLambda関数を再実行してください。

所々怪しい回答（実際には付与していないGetParametersのポリシーがあると言っていたり、権限が無いというエラーにもかかわらず権限を絞るように言っていたり）もありますが、ARNが間違っているということはある程度読み取れる回答が返ってきました。もしかしたらピンポイントで「この部分のスペリングが間違っていないか」と指摘をもらえるのではと期待して色々な聞き方をしてみましたが、そこまでは上手くいきませんでした。

トラブルシューティング②：ネットワーク

続いて、ネットワーク系のトラブルについても実験してみました。以下のように、パブリックサブネットにEC2インスタンスを配置します。EC2インスタンスにはWordPressがインストールされている状態です。

EC2にはElastic IPを付与しているため、ネットワークが正しく設定されていればパブリックIPでアクセス可能です。今回はあえてセキュリティグループの設定を間違えてみます。

EC2インスタンスに、インバウンドルールが存在しないセキュリティグループをアタッチします。

当然、パブリックIPでアクセスしようとしてもアクセスできません。

そこで、このエラーについてAmazon Qに質問してみます。

エラーについて質問

「なぜ[パブリックIPのURL]でEC2インスタンスにアクセスできないのですか？」

回答

ネットワーク接続の問題です。VPC Reachable AnalyzerとAmazon Qがネットワーク接続の問題のトラブルシューティングに役立ちます。プレビュー版を試用できます。（バージニア北部リージョンで利用可能）

VPC Reachable AnalyzerというVPCのリソース間の接続を確認できるサービスがAmazon Qとつながっているようです。回答のリンクから AWS Q for Reachability Analyzerを開きます。 Amazon Q同様にチャットで質問できます。

Reachable Analyzerでの質問

「なぜ[パブリックIPのURL]でEC2インスタンスにアクセスできないのですか？」

回答

public IPを使ってEC2インスタンスに接続できないようです。接続またはセキュリティの設定の問題がある可能性があります。分析結果は以下。

分析結果の詳細を見てみます（ここは日本語）

インバウンドルールが適用できていないということが分かりました。この分析結果は既存のVPC Reachable Analyzerと変わらないと思いますが、対話形式で分かるのでAWS初学者には使いやすいかもしれません。

まとめ

以上、Amazon Qの検証でした。個人の印象ですが、ある程度のトラブルシューティングはできるものの、核心を突いた回答までは得られないかなと感じました。ある程度AWSを理解できている人にとってはサポートになると思いますが、少なくとも現状ではAWSがほとんど分からない人が使ってAWSを使いこなせるようになるものではないかもしれません。

Amazon Qはここで紹介した以外にも様々な機能があるので、また様々な活用方法を探してみたいと思います。ここまで読んでいただいてありがとうございました。

さいごに

弥生株式会社では一緒に働くエンジニアを募集しています！詳細は↓よりご確認ください。

herp.careers

2023-12-23

re:Inventに参加した、ぶちょーの話

AWS

この記事は弥生 Advent Calender 2023 の23日目の記事です。

みなさまこんにちは。弥生の情シスでぶちょーやってます、あけちです。

エンジニアに紛れてre:Invent2023に参加してきました。

2023年も前年に続き弥生エンジニアが #reinvent に参加しています。
素敵な学びの機会になりますように。#aws #reinvent2023 pic.twitter.com/BrdxQrBzXo
— 弥生株式会社エンジニア情報 (@yayoikk_dd) 2023年11月29日

キーノートを中心に見つつ、Innovation Talkなど今後出てくる技術の勉強です。
キーノートではこれまでのAWSの取り組みをふりかえりながら今後のロードマップの説明があるため、なぜそれをリリースするのか、どこに向かっているかをよく理解できます。
（実際には英語力が足りないので理解があとでリリースされる日本語訳とセットで理解です。）
今回のキーノートで一番熱かったのは「Amazon Q」の発表でした。
Amazon Qはコーディング支援やコードの自動変換、コンタクトセンター支援など幅広くサポートしてくれる生成AIです。
これは開発からお客さまに提供しているサービス、社内のシステムへの応用など全方位で活用できるサービスと感じました。
発表を聞いている間は、Amazon Qはお客様にこんなサービスを提供できるのではないか？社内でこんな活用をしたら面白いかも　といった想像を掻き立てるには十分な内容でした。
これからエンジニアにAmazon Qをしっかり勉強してもらって社内外に活路を見出していってほしいと思います。

参加してよかったと思うこと

技術的なことは参加したエンジニアに任せるとして、ここからは私の観点でre:Inventに参加してよかったなと思うことを3つ挙げたいと思います。

イベントの規模の大きさ、パワーを直に感じられる

世界中から約40,000人のエンジニアが集まるイベントは他に聞いたことがありません。この空気感は現地でしか感じられないものだと思います。

会場の大きさ（街中が会場）や、対応するスタッフの多さなどこれだけの準備をするのは相当な工数がかかるのは容易に想像できました。
本当に すごい の一言に尽きます。
一番驚いたのは早朝に開催された5kmマラソンでした。片側2車線の結構大きな道路を通行止めにして開催されていました。早朝とは言え道路を貸切るというのはただただ驚きでした。

参加したエンジニアのモチベーションがかなり上がる

イベント期間中は常に最新情報に触れ、普段聞けない話を聞けるというのはエンジニアにとって刺激的だと思います。
滞在期間中一緒にいったエンジニアはみんな本当にいい顔をして当日のセッションの情報共有をしていました。

チーミングができる

滞在期間中は嫌でもコミュニケーションをとる時間が増えます。
普段の業務では話さないメンバー同士が事前の準備を含め、当日得た情報からプライベートなことまで多くのことを会話するようになります。
会話が増えることで、その人の人となりがわかるのでチーミングには最適だと感じました。
これから新しいことを始めたい、大きなプロジェクトを推進したいというチームがあれば、チームで参加するのは大きな意義があるのではないかと感じています。

まとめ

とりとめのないことを書いてしまいましたが、私から伝えたいのは3点です！

いくとめっちゃテンション（＋モチベーション）あがるよ！
いきたいけどどうしようかな、、、と迷っている人は絶対手を挙げたほうがいいよ！
（英語が…　と思っている人でもなんとかなるよ！）
（特に上司の方向けに）行かせたいけどお金が…　と思っているなら行かせたほうがいいよ！
かかるお金以上のものを持って帰ってきてくれます

迷っている方は是非来年立候補してみてください。
来年は2024/12/01～12/06に開催するようです。もう来年の予定が決まっているってすごいですよね。それだけ準備に時間がかかるものだと思っています。

おまけ

今回の渡航にあたってのメモを書き留めておきますのでなにかの参考になればと思います。
（英語が苦手なおじさんの観点で書いていますので当てはまらない場合があります。）

英語

一緒にいくメンバーに1～2名英語ができる人がいると安心だが、日本人の現地スタッフの方もいるので、なんとかサポートはしてもらえる。
いざとなったらGoogle先生に頼れる。（私も何度もお世話になった。）
同時通訳してくれるセッションもあるので、必要に応じて翻訳レシーバーを借りられる。
ただ、熱気を感じるのであれば、わからなくても直接英語で聞く方がおすすめ。

食事

朝、昼は会場で用意されているため、特に考慮する必要はない。
※がっつりアメリカンを楽しみたい方は各自で考える必要あり。
※軽食があるため、食べることには不自由しない。
夜は滞在期間中のイベント（今回はJapanツアー、re:Playに参加）があるため、毎日必要なわけではない。
イベントではステーキは出てこないため、ステーキは別途確保する必要あり。
軽食（お菓子＋コーヒー、ジュース）も常に用意されているので小腹も満たせる。
現地で水を買うと高いのでドラッグストアでペットボトル複数本がパックになっているものを買ってみんなで分けるのがおすすめ。
会場にはいたるところに給水所があるので、ボトルに補給するのもおすすめ。

体力

日本からの移動に相当時間がかかるため、体力もそれなりに使う。
時差ボケがボディブローのように効いてくる。
日中英語を聞き取ろうとして脳が活性化、海外にいる緊張感からか睡眠が浅く、時差ボケがなおらない。
（日中眠くなる）
ホテルにバスタブがなかったので、疲れがとれない。

夜眠れず、疲れがとれないため、日に日に疲れていく感はありましたが、なんとか1週間乗り切れました。

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

herp.careers

2023-12-22

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

AWS

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

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

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

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

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

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

結論から言うと、

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

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

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

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

入国審査が英語

いきなり鬼門である

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

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

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

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

トランジット待ち時間（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の入場があるため）

セッション参加

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

基調講演（Keynote）

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

会場で提供される食事

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

Expo

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

re:play

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

お土産や買い物

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

チェックアウト

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

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

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

2023-12-21

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

UX/UI

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

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

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

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

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

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

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

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

当時の私たちの思考は、

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

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

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

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

固定観念がぶっ壊される

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上昇していくイメージ図

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

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

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

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

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

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

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

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

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

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

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

デザインスプリント ―プロダクトを成功に導く短期集中実践ガイド

作者:Richard Banfield,C. Todd Lombardo,Trace Wax
オライリージャパン

Amazon

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

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

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

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

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

1. シナリオの作成

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

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

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

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

2. プロトタイプの作成

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

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

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

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

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

検証・改善のイメージ図

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

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

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

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

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

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

今後の展望

今後の展望イメージ

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

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

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

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

2023-12-20

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

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

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

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

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

形について

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

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

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

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

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

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

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

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

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

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

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

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

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

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

面白いインプット

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

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

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

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

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

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

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

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

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

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

見えない形

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

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

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

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

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

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

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

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

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

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

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

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

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

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

見えない形を見る

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

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

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

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

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

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

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

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

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

2.抽象化する

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

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

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

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

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

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

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

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

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

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

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

あとがき

いかがでしたか。

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

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

2023-12-19

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

ChatGPT

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

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

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

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

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

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

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

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

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'))]"
    }
  }
}

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

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

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

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の所でエラーになりましたね。

エラー箇所を調べてみるとが学習元と思われる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となっています）

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

結果

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

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

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

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

おわりに

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

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

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

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

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

herp.careers

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

2023-12-16

AWS社内イベントに登壇（AWS MMSA Townhall meeting）

AWS

こんにちは！弥生株式会社で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がイベントで語られている内容は、実際の利用者のニーズが反映されているものなのだと感じました。

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

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

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

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

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

herp.careers