デザインスプリントを導入して主要機能の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 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'))]"
    }
  }
}

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

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

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

この記事は  弥生 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