ISID テックブログ

ISIDが運営する技術ブログ

技術系イベント登壇における資料作成のコツ

みなさんこんにちは、電通国際情報サービス(ISID)Xイノベーション本部ソフトウェアデザインセンターの佐藤太一です。

少し前になりますが4/23に、私はGo Conference 2022 SpringにおいてGo で RDB に SQL でアクセスするためのライブラリ Kra の紹介というタイトルで登壇しました。

登壇時の資料はこちらです。

このエントリでは、スライドを作成する際に私が考えていることや、情報を整理する方法について説明します。

伝えたいメッセージを作りこむ

私が技術系のイベントに登壇する際に最も重視しているのがメッセージの作りこみです。 視聴者の皆さんにどんなことを伝えたいのか強く意識することで、資料の方向性を決めています。

最初にきっちりと決められれば一番いいのですが、実際には資料を作成しながら少しずつ変わっていきます。 自分自身と向き合い何を伝えたいのかを考えるのは、何度やっても大変な作業です。

アイディア出し

今回の登壇で説明するのは、データベースアクセスライブラリであるkraの紹介です。 つまり、要素技術の紹介をするわけですね。

要素技術の紹介をする際には、その技術が前提とする課題設定をきちんと理解するのが望ましいでしょう。 あらゆる要素技術は何か解決したい問題があります。そして、その問題には何らかの状況が付随しているはずです。 視聴者が持つ課題と、要素技術の解決する課題が一致すれば、それは非常に優れたプレゼンテーションになるでしょう。 また、視聴者が将来遭遇する課題について説明するなら、それもまた繰り返し参照されるより良いものになります。

問題が発生する状況を上手く抽象化しつつ、理解しやすい形で整理できれば、その課題が身近なものであると気が付いて貰えるでしょう。

アイディアだしをする時点では、要素技術が持つ機能に着目します。 自分の理解のために30文字くらいで言いきる形の機能説明をできるかぎりたくさん並べます。 それらが、どういう状況で役に立つのか自分なりに理解していきましょう。

初期のアイディア出し例

  • ドット区切りでプロパティアクセスできるNamed Parameterサポート
  • Named Parameterのプレフィックスとして:や@が使える
  • DB非依存なNamed Parameterサポート
  • IN句におけるプレースホルダの自動展開
  • ANTLRで実装されたSQLのパーザAPI
  • 結果セットを構造体やmapにマッピングする
  • database/sqlと酷似したAPI
  • sqlxにある複雑さをできるかぎり排除したAPI
  • database/sqlの薄いラッパーAPI
  • pgxの薄いラッパーAPI
  • カスタマイズ性の高い振る舞い
  • context.Contextを引数に取らないAPIは存在しない
  • context.ContextをKra自体は触らない処理構造
  • 脱出口付きのAPI
  • データ送信時のリフレクション処理とデータ受信時のリフレクション処理を共通化

アイディアの統合

アイディアを出しきったら、次は統合です。45分の講演では全てを説明できません。 何か優先順をつけたり、類似する事柄をまとめることで話す内容をまとめていく必要があります。 また、要素技術の提供者にとっては意味があっても、利用者にとってそれほど重要でないことはあります。 そういったものは、あえて伝えないという判断をする必要もあるでしょう。

そうやって、要素技術が解決する課題やその根源的な価値について理解をすすめていきます。

アイディアの統合例

  • Named Parameterのサポート
    • ドット区切りでプロパティアクセスできるNamed Parameterサポート
    • Named Parameterのプレフィックスとして:や@が使える
    • DB非依存なNamed Parameterサポート
  • IN句におけるプレースホルダの自動展開
  • ANTLRで実装されたSQLのパーザAPI
  • 結果セットを構造体やmapにマッピングする
  • 分かり易いAPI
    • database/sqlと酷似したAPI
    • sqlxにある複雑さをできるかぎり排除したAPI
    • context.Contextを引数に取らないAPIは存在しない
    • context.ContextをKra自体は触らない処理構造
  • 薄いラッパーAPI
    • database/sqlの薄いラッパーAPI
    • pgxの薄いラッパーAPI
  • カスタマイズ性の高い振る舞い
    • 脱出口付きのAPI
  • データ送信時のリフレクション処理とデータ受信時のリフレクション処理を共通化

メッセージの絞り込み

大抵の技術系イベントでは複数の演者がそれぞれ異なった話をするため、その話を聞く人達はたくさんのメッセージを受けとります。よって、多くのメッセージをスライドに盛り込んでも聴講者の皆さんは覚えていられません。

これは私の経験則ですが、伝えたいメッセージは3つくらいに絞り込むのが望ましいと考えています。 情報を構造化し、話の流れを作り、その3つのメッセージに集約されるようにスライドを作るのです。

アイディアだしの時点では「~~しない」や「~~ではない」みたいなものがありますが、それらを一つずつ丁寧に肯定表現に入れ替えていきます。

メッセージの例

今回の講演では聴講者の皆様にKraを覚えて貰いたいので、Kraがどういうものかにフォーカスして2つの方向性でメッセージをまとめています。

  • Kraの機能を説明したい
    • Named Parameterのサポート
      • ドット区切りでプロパティアクセスできるNamed Parameterサポート
      • Named Parameterのプレフィックスとして:や@が使える
      • DB非依存なNamed Parameterサポート
    • IN句におけるプレースホルダの自動展開
    • 結果セットを構造体やmapにマッピングする
    • 薄いラッパーAPI
      • database/sqlの薄いラッパーAPI
      • pgxの薄いラッパーAPI
  • Kraの思想を説明したい
    • 分かり易いAPI
      • database/sqlと酷似したAPI
      • sqlxにある複雑さをできるかぎり排除したAPI
      • context.Contextを引数に取るAPIだけが存在する
    • カスタマイズ性の高い振る舞い
      • 脱出口付きのAPI

今回のメッセージ

今回の例では伝えたい内容を明確にするために、アイディア出しから統合、削り込みを十回以上繰り返しています。

そうしてできあがったのが、以下の二つのメッセージとその内容です。

  • Kraの機能
  • Kraの特徴
    • 標準ライブラリを理解している人が実装を想像できる
    • 細かい勘違いによる動作不良を起こしづらい
    • 置き換え可能なAPI構造

できあがったものを見ると、恐らく明解で当たり前のように感じることでしょう。 そのようになるまで、メッセージを磨くことで分かり易い講演になります。 私の講演を視聴したら「Kraの機能と特徴を説明する講演だった」と一言で説明できるはずです。

伝えたい事柄をこのレベルまで磨ければ、資料を作るのはほぼ終わったといえるでしょう。

ちなみに、この状態にするためには今後説明するスライド作成の作業を並行して実施します。 情報の構造化やビジュアルデザインを作りこむ過程で、伝えたいことが明確化するのはよくあることです。

伝えたい情報を構造化する

ここでいう構造化とは木構造のことです。まずは、今回作ったスライドがどのような構造なのか確認してみましょう。

一番左の箱が、このスライド全体を表しています。そこから一段右側にある3つの箱は上から「はじめに」「主題」「まとめ」となっています。

「はじめに」の中身を分解したものがその右側の二つです。「自己紹介」と「アジェンダ」です。続けて、「主題」の中身を分解したものが、今回伝えたいメッセージである「Kraの機能」と「Kraの特徴」です。最後は、「まとめ」を「振り返り」と「宣伝」に分解しています。

これは、大きな塊を小さく分解して扱いやすくするというプログラミングでよく使う方法論です。 この方法論で論理を構成すると、ソフトウェア技術者は、おおむねこの思考様式に慣れ親しんでいるので受け入れやすい講演になります。

構造のテンプレート

概念を構造化するのは、それなりに難しいものです。慣れるまでは以下のようなテンプレートを使って考えると良いでしょう。

検討している項目の下に、何も考えずに「前提」、「主題」と「結論」を置いてしまうのです。 例えば、最初に見せた構造の中で「Kraの機能」という話題をブレークダウンしてみましょう。追加した部分には、赤い色を付けています。

ここでは、頭の中でブレークダウンするのではなく、このように見える形で箱を置いてしまうことです。 見える形で箱を置いたら、これらを声に出して読み上げます。

  • Kraの機能における前提
  • Kraの機能における本題
  • Kraの機能における結論

視覚と聴覚に刺激を与えることで、ある種の違和感が発生するはずです。その違和感を言語化すると概念の構造を明らかにする手掛かりとなります。例えば、以下のようなことが思い浮かびます。

  • Kraの機能における前提とはなんだろうか?設計か?思想か?課題設定か?
  • Kraの機能における本題は簡単。単に機能の一覧を説明すればいい
  • Kraの機能における結論とはなんだろうか?便利とかそういうことか?それとも、ここまでの説明を単にまとめるのか?

これを繰り返していくことでテーマを深掘りします。

ここで重要なのは、視覚に対して与える刺激の種類を増やすことや、声を出すことで聴覚に対して刺激を与えることで脳の様々な部分を働かせることです。散歩や入浴もおすすめです。

論理の順序を整理する

論理の構造を明らかにすることと並行して、論理の順序について考えましょう。

要素技術を説明するには、抽象度の高い事柄を最初に説明して、それを徐々に具体化していくのが基本的な手順です。 抽象度の高い事柄とは、例えば以下のようなものです。

  • 要素技術の背景にある技術的な思想
  • 要素技術が最終的に解決したい課題
  • 要素技術を実装した意図

こういったものを最初に説明すると、視聴者が混乱する可能性を低減できます。 そこから導き出される具体的な事柄とは、例えば以下のようなものです。

  • ライブラリやフレームワークのコードを使った動作説明
  • ライブラリやフレームワークの使い方を説明するサンプルコード
  • スクリーンキャプチャやCLIの出力を例示するツールの操作説明

今回は45分の枠でお話しましたが、私を含め普通の視聴者は概ね最後の5分から10分くらいで聞いた話が印象として残ります。 つまり、講演の終盤で短期的に利益のある話、分かり易い話をする方が良い印象を残せます。

まとめ

記事として少し長くなり過ぎてしまったので、今回の説明はここまでとします。 例えば、ビジュアルデザインや時間管理の方法、PowerPointの効率的な使い方については説明できていません。 そういった話題について、ご興味のある方はTwitter等のSNSで続きを読みたい旨を投稿して貰えるとありがたいです。

このエントリを読んだ皆さんが技術系のカンファレンスに登壇する助けになればうれしいです。

執筆:@sato.taichi、レビュー:@yamashita.tsuyoshiShodoで執筆されました

BlazePoseを用いてダンスの類似モーションを取得する

こんにちは。電通国際情報サービス(ISID) 金融ソリューション事業部の若本です。AIを活用した新規事業に取り組んでおり、業務では主に自然言語処理の実装に携わっていますが、今回は画像処理分野の記事になります。

私は趣味でブレイクダンスを練習しているのですが、自分の練習動画を見ていると「この動きは最近癖になっているな」ですとか、「あの動きは最近していないな」といった気付きを得ることが多々あります。しかし、過去の動画をいちいち見返すのはかなり億劫な作業です。
そこで、過去の自分の練習動画から同じような動きを取得することを考えました。BlazePoseを使い、他の動画の中から似ている動きを検索します。

BlazePoseとは?

Googleが開発した、動画から骨格情報を検出するAIモデルです1。BlazePoseを使用することで、手軽かつ高速に骨格検出を実施できます。奥行情報の推定やセグメンテーション(人が映っている場所だけを切り出すこと)も可能です。それでいて、リアルタイム検出に対応できる動作速度を持ち合わせています。
類似の骨格検出AIにはMoveNet2などもあります。こちらはモーションブラー(動きのブレ)に強いことが特長です。
動きの激しいブレイクダンスを解析対象としているため、本来であればMoveNetを使いたいところですが、今回は奥行の情報も使いたいためBlazePoseを採用しました。以下がBlazePoseの出力例になります。

類似度の計算

以前に撮影した複数の練習動画を入力として、他の動画に似た動きがないか検索します。処理の概要は以下の図のようになります。

1つの動画内には多くの動きが含まれているため、まず動画を小分けに保存してBlazePoseにかけています。
BlazePoseを使い、小分けにした動画の各フレームの骨格情報を取得することができれば、あとは骨格情報の推移から類似度を計算するだけです。
これらを以下の手順で実装します。
① 座標の情報を変換する
② 他の動画と比較して類似度を算出する

① 座標の情報を変換する

BlazePoseで取得した骨格情報は、部位ごとに空間座標(X、Y、Z)の情報を持っています。
このとき、全く同じ動きをしていても空間座標の値は異なります。なぜなら、動画を撮影している角度や位置などが動画ごとに異なるからです。
これらを統一するため、座標を以下のようにして変換します。

  • 基準となる1つの部位を決め、その部位が原点になるよう全ての空間座標を平行移動させる
  • 基準となる部位をもとに全ての空間座標を回転させる

ここでは、体の場所と向きの情報をそろえています。体の向きさえ一致させることができれば、上記の方法でなくとも問題はありません。

② 他の動画と比較して類似度を算出する

ブレイクダンスについて、以下のような特徴を考慮して類似度を計算します。
Ⅰ. 動きに個人差の大きい部位がある
Ⅱ. 同じ動きでも早かったり遅かったりする
Ⅰ. には部位ごとの重みづけを、Ⅱ. には類似度計算にDTW(Dynamic Time Warping)を使うことで対応すればよさそうです。このとき、類似度の計算は以下のように行います。

  • 部位ごとにDTWを計算する
  • 部位ごとに設定した重みをスコアにかけ、総和を取る
  • 総和が閾値より小さければ、類似している動画とみなす
  • 上記を小分けにした動画のすべての組み合わせについて繰り返す

また、BlazePoseから出力される骨格情報は33箇所もあるため、特定の部位の情報のみを使用して類似度を算出しています。

結果

以下が類似と判定された動きのキャプションになります。

服装が似ていることもあってわかりづらいですが、別動画から類似モーションを取得することには成功しています。ただ、BlazePoseで取得した奥行の情報が不正確なためか、似た角度の動画が多く見られました。現時点のロジックでは、少なくとも撮影角度が似ているほうが有利になる傾向はありそうです。

おわりに

今回はブレイクダンスの練習動画をもとに、類似モーション検索のチューニング・検証を行いました。
今後はより複雑な動き・速い動きでも類似モーションを取得できるよう改良したいと思います。また、撮影角度によっては類似モーションの見逃しが発生していることも今後の課題です。とはいえ、近年の骨格検出AIの発展は目覚ましく、より安定して骨格情報を捉えられるようになってきているため、改良するより早く解決してしまうかもしれません。

今後も単眼カメラの情報をベースとした様々な骨格検出モデルの登場が予想されます。今後どのように技術が発展していくのか、そしてどのように応用されていくのか、非常に楽しみです。

執筆:@wakamoto.ryosuke、レビュー:@sato.taichiShodoで執筆されました


  1. BlazePose: On-device Real-time Body Pose tracking(https://arxiv.org/abs/2006.10204

  2. MoveNet: A Deep Neural Network for Joint Profile Prediction Across Variable Walking Speeds and Slopes(https://ieeexplore.ieee.org/document/9406043)

TexAIntelligenceにWRIMEデータセットを学習させて感情分析してみた

お疲れさまです。XI本部、AIトランスフォーメーションセンターの徳原 光です。

この記事で2回目の投稿になります。今回は所属センターで開発しているAI製品、TexAIntelligenceを使用して、SNSでの投稿に感情ラベルを付与したデータセットであるWRIMEデータセットver.2をAIモデルに学習させた結果をまとめたいと思います。

感情分析とは?

感情分析はNLP自然言語処理の一手法で文章に込められた感情をAIによって検出する技術です。

例えば、「お風呂の水漏れが治らない・・・。今月でもう3度目だよ」という文章には「悲しみ」が込められていますよね(もしかしたら「怒り」もあるかも)。

「〇〇大学に合格できた!春からはれて大学生だ!!」という文章だったら「喜び」でしょうか?

もし、「〇〇大学に合格できた!春からはれて大学生だ!!嬉しいなぁ」というように「嬉しい」とか、「やったー」という言葉が含まれていれば、ルールベースによる手法や従来の機械学習の手法で文章が意味する感情を判別することが可能です。

しかし、そのような感情を表す言葉が含まれていない場合、文章の文脈を理解する必要があるので、感情分析はNLPのタスクの中でも難しい課題と言えます。

WRIME 主観と客観の感情分析データセット

こちらのデータセット愛媛大学梶尾先生が作成されたデータセットです。

BERTの学習用のデータセットとして作成されたので、機械学習で使用するデータセットとしては非常に使い勝手がいいデータセットになります。

ver1では43,200件、ver2では35,000件のSNSから収集した文章データに基本8感情(喜び、悲しみ、期待、驚き、怒り、恐れ、嫌悪、信頼)の感情極性が書き手と3人の読み手ごとに4段階(0:無、1:弱、2:中、3:強)でラベル付けされています。

さらに、ver2では肯定的か否定的かのラベルも5段階で付いていて、今回はそれを利用しました。

NLPの世界では、いつの世でも学習データが不足してしまうものですが、数万件の文章データがあるのでデータ数で困ることはありません。しかも、一つの文章に複数のラベルが付けられているので、アイデアしだいでいろいろな応用ができます。

また、ver1では80人、ver2では60人の書き手から文章を収集しているのでいろいろな文体の文章が収録されており、さらにSNSの特性上、内容のジャンルは様々なので非常に汎用性の高いデータセットになっています。

TexAIntelligence

TexAIntelligenceは、私が所属しているAIトランスフォーメーションセンターで開発している、文章分析のためのアプリケーションになります。

AIに知見がない人でも高度なAI技術を使いこなせるというコンセプトのもと開発を進めていて、webの画面をポチポチ操作するだけで、AIモデルを構築し利用できます。

使用できるアルゴリズムはTF-IDFと日本語の文章認識に特化したBERTモデルであるISID-BERTの2つです。

ISID-BERTを利用する場合、予め学習により日本語の認識精度を高めた状態のモデルをユーザーが用意したデータセットで転移学習(ファインチューニング)させ、目的のタスクを実行するAIモデルを構築することになります。

今回の場合では、WRIMEデータセットを予めアップロードしておき、データセットに含まれる感情に関するラベルをISID-BERTに学習させることで、TexAIntelligence上で感情分析を実施していきます。

感情分析をやってみる

新人研修の一環として今年度の新入社員向けに、NLPと社内製品であるTexAIntelligenceを紹介することになり、ISID-BERTを使うメリットがわかりやすく説明できる題材を探していました。

あまりにも簡単だと、高度な深層学習を行うISID-BERTを利用する意味が伝わらないので、単語レベルではなく文脈を理解しないと正解できないタスクに挑戦する必要があり、感情分析がベストだと思いました。

さらに、新入社員の人も自分でTexAIntelligenceを使いたくなるような汎用的なユースケースにしたかったので、 文章が肯定的なものか、否定的なものか、中立的なものか判断するタスクを実施します。

セミナーやイベントで集めたアンケート回答の自由記述欄が肯定的な意見なのか、否定的な意見なのか分類したいというニーズは社内でもありますし、お客様向けに開発しているシステムにも取り入れやすい機能だと思います。

## データ準備 WRIMEデータセットには肯定的か否定的かのラベルが5段階(肯定強、肯定弱、中立、否定弱、否定強)でついていますが、そのまま5段階での分析をAIモデルにさせると、かなり肯定的な文章とちょっと肯定的な文章の区別をAIにさせることになり、タスクの難易度が上がってしまいます。

人がこれらのタスクをやる場合でも、肯定しているのか、否定しているのかの判断は容易にできますが、どのくらい肯定しているのか、否定しているのか判断は難しいですよね・・・。WRIMEデータセット上でも3人の読みての判断が一致していないことが多々あります。

なので、タスクをよりシンプルにするように、肯定強、肯定弱は同じ肯定的に、否定弱、否定強は同じ否定的にまとめて、肯定、中立、否定の3段階にラベルを作成しておきました。

また、WRIMEデータセットには書き手と読み手の合わせて4人分の文章の評価が記録されていましたが、読み手の3人の評価を平均したものをISID-BERTに予測させるラベルとしました。

学習データのアップロード

ここからはTexAIntelligenceの画面上で操作を行います。 学習データ数は10,000件で実施しました(実際はそのうち2割が評価用になるので8000件が学習データになります)。データセットにはそれ以上のデータが収録されていますが、学習時間の都合上1万件としました。

学習実施

GUIの画面上の操作について軽く説明します。ただし、この記事は製品紹介ではありませんので詳細な操作方法については割愛しています。

学習の設定としてやることは、文章に対応する行と、AIに判定させたい感情を表すラベルを指定するだけです。細かい学習パラメータを設定することも可能ですが、今回は特にこちらからパラメータを指定しませんでした。

BERTの学習が走るVMによってかかる時間は変わりますが、この時利用した環境(K80搭載)では10,000件の学習を約2時間で完了しました。

もうちょいマシなGPU(例えばT4やV100、RTX3080 tiやRTX 3090)を積んだ環境を利用すればもっと早く学習が終わると思います。

学習結果

64%正解という微妙な結果になってしまいましたが、今回は肯定的、中立的、否定的と3段階のラベル付けを行っており、肯定的を否定的に、もしくは否定的を肯定的に間違えた件数は2000件中、68件だったのでそれほど多くありませんでした。

学習データを工夫すればもうちょっと精度をあげられるかもしれませんね。

例えば、学習データに含まれる肯定的、中立的、否定的の割合を調整するとか、評価者によって判断が分かれているデータを除外するなど、やりようはいくらでもあると思いますが、今回はあくまでお試しなのでこれで良しとします。

また、アンケート分析というユースケースでの利用を検証するために、自分で一文一文作成したアンケート回答の自由記述のサンプルデータを使ってモデルをテストしてみました。

結果は83%正解。まずまずの結果だと思います。アンケートのサンプルデータは30回答分しかないので明らかにデータ数が足りませんが、試した結果だけ見ると自由記述のサンプルデータの方が精度が高いようですね。

理由は単純にアンケートの自由回答よりも、WRIMEデータセットSNSの投稿文のほうが、感情を分析するのが難しいからでしょうか。

SNSの文章は前後の投稿の関係性や投稿された時節、投稿者の気分によって言葉のニュアンスが変化してしまいます。

ちなみに、書き手ではなく読み手の評価をラベルとして採用したのもこれが理由で、投稿者の評価をラベルにしてしまうと完全に同じ文章なのにラベルが違うってことが増えてしまうんですよね。

ここら辺の話は梶原先生のこちらの論文で考察されているので気になる方は読んでみてください。

アンケートの自由記述は他人に読まれることを前提に書かれた文章なので、その文章単体で読み手が意味を理解できるように必要な情報は全て盛り込まれているはずです(そうじゃないこともありますが・・・)。なので、AIが文章のみから肯定的か否定的かを判断するのは比較的に簡単だったんだと思います。

以下はアンケートのサンプルデータの文章と正解ラベル、予測ラベルの一部になります。

文章 正解ラベル AIが予測したラベル
UIが素晴らしいと思う。直感的に操作できるので操作方法を調べなくても利用できる positive positive
直近で大量のアンケートを集計する必要があり、このソフトを用いたことろ効率的にアンケート集計ができた。便利だったので今後も利用したい。 positive positive
日本語の認識精度が高くて驚いた positive negative
最高! positive positive
ぜひ継続して利用したい positive positive
他の製品と違いはないと感じた neutral neutral
価格は普通だと感じた。 neutral neutral
月に3回ほど利用した。費用頻度はそれほどでもないと思う。 neutral neutral
AIについて今後勉強したいと思う neutral positive
ノーコメント neutral neutral
競合のA社も利用しているのでしょうか neutral neutral
利用していない neutral negative
特になし neutral neutral
利用方法が理解できなかった。もっとマニュアルを整理しないと活用できないと思う negative negative
精度が低い、使いものにならない negative negative
機能に対して利用料金が高すぎると思う。また、クラウドに文章データを送るのでセキュリティも不安に思っている negative negative
導入する意味はない negative neutral
UIがわかりにくい。使っているとイライラする。 negative negative

ちょっと考察

唯一、肯定的を否定的と間違えたのは下の文章でした(否定を肯定に間違えることはありませんでした)。

日本語の認識精度が高くて驚いた

この文章は肯定的な文章ですが、認識精度が高いことが良いことなのか悪いことなのか判断できないと、文章全体が肯定なのか、否定なのか判断できないですよね。ちなみに、学習データの中には「認識精度」という言葉は含まれてなく、「精度」という言葉も2回しか出てきません。

上の図はTexAIntelligenceに搭載されているSHAP(AIの判断根拠を可視化する技術)によって単語別の否定の判断の寄与度を表したものです。「高くて驚いた」の部分が否定の判断根拠になっています。例えば価格が高い場合この文章は否定的なものになりますよね。

肯定的と中立的、もしくは中立的と否定的の区別で他にも間違えはありましたが、共通して言えることは文章が短いと間違いやすいということです

SNSの文章は短いと書き手のメタな情報を理解していないと意味がわかりづらくなるので、AIがその文章だけで正解のラベルを判断するのは難しいのだと思います。

逆に長い文章ならば、主張の背景的な情報も投稿に含まれるようになるため、AIが文章から感情を推測することも可能になります。

例えば、「ヤバかった!」と一言だけの文章では、ポジティブなヤバいなのか、ネガティブなヤバいなのかわかりませんが、もしこの投稿に文章をたして、

「一昨日ライブで披露された新曲がマジでヤバかった!」

となっていれば、AIはライブでの出来事だったことや、新曲に対する意見ということでヤバいが肯定的な評価だと推測できるわけです。

ただ、これはSNSに限った話で、一般的にビジネス文章に関しては文章が短いと精度が上がると言われていいます。

それは、ビジネス文章は読み手に正しく伝えたいことを理解してもらうことが目的に書かれるため、メタな情報も含め判断の根拠となる情報は全て文中で述べられることが多く、推測に必要な情報が不足しにくいからです。

逆に、文章が長いと主張とは関係ない補足情報が増えていくため、文に含まれる単語数が増えるほどAIは文脈の流れを見誤る可能性が増えます。サンプルのアンケート文章はどちらの特性が強いかというと、ビジネス文章に近いと言えます。

個人的にはアンケートの回答と趣が違うSNSの文章を学習して、ここまで精度が出たのが驚きですが、SNSの文章のほうがより多くのジャンルや概念を含んでおり汎用的だったということだと思います。

すこし実験

日本語の認識精度が高くて驚いた

先程、これを間違えて否定的と捉えたのは「〇〇が高い」だけでは肯定か否定か判断できず、「認識精度が高い」 という組み合わせが学習データになかったので正しい判断ができなかったと書きました。

それなら、同じような文章を学習データに仕込んでおけば正解できるはずです。そして、TexAIntelligenceに搭載しているISID-BERTは日本語のコーパスを学習させているので、完全に同じ言葉ではなくても似た意味を持つ単語が含まれていれば文脈の意味を理解できます。

ということで、文章:「予測の正確性が高水準になっている」ラベル:肯定的というデータを学習データに追加しました。

これで、間違えてしまった「日本語の認識精度が高くて驚いた」も正しく文意を捉えられるはずです。

結果は・・・

素晴らしいですね。スッキリしました。これで今日もよく眠れそうです。

まとめ

WRIMEデータセットはめっちゃイカしたデータセットでした。

今回はサクッと使わせていただきましたが、それだけでも十分な結果が得られました。

豊富なデータ数と複数のラベルが存在しているので他にもいろんな応用の仕方ができると思います。

研究目的で作成されたデータセットということでビジネス利用は難しいかもしれませんが、NLP技術の研究にはかなり有効なデータセットですね。

これだけのデータセットを作成するのはとても大変だったかと思います。構築に関わった方々に感謝です。

それでは。

執筆:@tokuhara.hikaru、レビュー:@sato.taichiShodoで執筆されました

AuroraクラスタのパスワードローテーションをCDKで実装する

こんにちは。X(クロス)イノベーション本部 ソフトウェアデザインセンター セキュリティグループの耿です。
CDKでAmazon Auroraデータベースクラスタを作成し、Secrets Managerで管理しているパスワードをローテーションしてみました。
ローテーションはSecrets Managerのマネジメントコンソールからでも設定できますが、CDKでも非常に簡単に書けました。やり方は公式ドキュメントには書かれているものの、日本語の情報があまり見当たらなかったため書き残しておきます。

※この記事のサンプルコードではAurora Serverlessを作成していますが、プロビジョンド版でも同じ方法でパスワードローテーションを実現できます。

公式ドキュメント

CDKの aws_rds モジュールの Rotating credentials セクションにクレデンシャルのローテーションに関する記載があり、これを参考にしました。
https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_rds-readme.html#rotating-credentials

マスターユーザーのローテーション(シングルユーザーローテーション)

以下のCDKコードでリソースを作成します。

import { Stack, StackProps } from "aws-cdk-lib";
import * as ec2 from "aws-cdk-lib/aws-ec2";
import * as rds from "aws-cdk-lib/aws-rds";
import { Construct } from "constructs";

export class MyStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    // プライベートサブネットを持つVPC
    const vpc = new ec2.Vpc(this, "MyVpc", {
      cidr: "10.0.0.0/16",
      enableDnsHostnames: true,
      enableDnsSupport: true,
      subnetConfiguration: [
        {
          name: "myPrivateSubnet",
          subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
          cidrMask: 20,
        },
      ],
    });

    // VPCエンドポイント用セキュリティグループ
    const VpceSG = new ec2.SecurityGroup(this, "MyVpceSg", {
      vpc: vpc,
      allowAllOutbound: true,
    });

    // Secrets ManagerへのVPCエンドポイント
    vpc.addInterfaceEndpoint("SecretsManagerEndpoint", {
      service: ec2.InterfaceVpcEndpointAwsService.SECRETS_MANAGER,
      subnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
      securityGroups: [VpceSG],
      privateDnsEnabled: true,
    });

    // Aurora Serverlessクラスタ
    const auroraCluster = new rds.ServerlessCluster(this, "MyAuroraCluster", {
      engine: rds.DatabaseClusterEngine.AURORA_MYSQL,
      vpc: vpc,
      vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
    });
    // パスワードのローテーションを設定
    auroraCluster.addRotationSingleUser();
  }
}

Aurora Serverlessクラスタを以上のサンプルコードで作成すると、マスターユーザーの情報はSecrets Managerに保存されます。
マスターユーザーのパスワードをローテーション設定しているのは次の一行のみです。これだけでローテーションが有効化され、ローテーションを実行するLambda関数などのリソースが作成されます。非常に簡単ですね。

auroraCluster.addRotationSingleUser();

マネジメントコンソールでSecrets Managerのシークレットを確認すると、確かにローテーションが有効になっていることがわかります。 ローテーション有効

addRotationSingleUser() 関数で有効になるローテーションは「シングルユーザーローテーション」と呼ばれ、ユーザーのパスワードをそのまま更新するだけの単純なローテーションです。

Secrets Managerにアクセスできない場合のエラー

デフォルトでは、ローテーションを実行するLambda関数はデータベースクラスタと同じサブネットにデプロイされます。Lambda関数がSecrets Managerにアクセスできるようにする必要があり、今回はそのためのVPCエンドポイントを作成しています。

Lambda関数がSecrets Managerにアクセスできない場合、マネジメントコンソールから手動でローテーションを実行すると以下のエラーが表示されます。 ローテーションエラー

シークレット「MyAuroraClusterSecretD92700-ozDfy6jZIGiv」をローテーションできませんでした。 A previous rotation isn't complete. That rotation will be reattempted.

また、Lambda関数のCloudWatch Logsロググループには次のようにタイムアウトが記録されます。

START RequestId: 3031c3a5-9624-49ed-994e-db8f0cb14d63 Version: $LATEST
END RequestId: 3031c3a5-9624-49ed-994e-db8f0cb14d63
REPORT RequestId: 3031c3a5-9624-49ed-994e-db8f0cb14d63  Duration: 30035.14 ms   Billed Duration: 30000 ms   Memory Size: 128 MB Max Memory Used: 70 MB  
2022-05-24T04:28:30.600Z 3031c3a5-9624-49ed-994e-db8f0cb14d63 Task timed out after 30.04 seconds

シングルユーザーローテーションで作成されたリソースを見てみる

auroraCluster.addRotationSingleUser();

この一行でどのようなリソースが作成されているのか見てみました。

ローテーションを実行するLambda関数

まず、 MyStackMyAuroraClusterRotationSingleUser~ という名前でLambda関数が作成されていました。
このLambda関数はデータベースクラスタと同じサブネットに配置されています。
ローテーションを実行するLambda関数

Lambda関数のセキュリティグループ

Lambda関数のセキュリティグループも新規に作成されていました。インバウンドルールはなく、アウトバウンドルールは全ての通信を許可しています。
Lambda関数のセキュリティグループ

また、データベースクラスタのセキュリティグループは、Lambda関数のセキュリティグループから3306ポートのインバウンド通信が許可されていました。 データベースクラスタのセキュリティグループ

Lambda関数の実行ロール

Lambda関数の実行ロールが作成され、4つのポリシーが付けられていました。

  • AWSLambdaBasicExecutionRole(AWS管理)
  • AWSLambdaVPCAccessExecutionRole(AWS管理)
  • SecretsManagerRDSMySQLRotationSingleUserRolePolicy0(カスタマーインライン)
  • SecretsManagerRDSMySQLRotationSingleUserRolePolicy1(カスタマーインライン)

インラインポリシー SecretsManagerRDSMySQLRotationSingleUserRolePolicy0 は次のようになっていました。(ネットワークインターフェースの操作を許可しているのですが、なぜここで必要なのか分かりません)

{
    "Statement": [
        {
            "Action": [
                "ec2:CreateNetworkInterface",
                "ec2:DeleteNetworkInterface",
                "ec2:DescribeNetworkInterfaces",
                "ec2:DetachNetworkInterface"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

インラインポリシー SecretsManagerRDSMySQLRotationSingleUserRolePolicy1 は次のようになっていました。Lambda関数からSecrets Managerへのアクセスを許可しています。
Resourceは該当リージョンの全てのSecrets Managerシークレットを指しており、広めの許可です。

{
    "Statement": [
        {
            "Condition": {
                "StringEquals": {
                    "secretsmanager:resource/AllowRotationLambdaArn": "arn:aws:lambda:ap-northeast-1:<アカウントID>:function:MyStackMyAuroraClusterRotationSingleUser4A86DF55"
                }
            },
            "Action": [
                "secretsmanager:DescribeSecret",
                "secretsmanager:GetSecretValue",
                "secretsmanager:PutSecretValue",
                "secretsmanager:UpdateSecretVersionStage"
            ],
            "Resource": "arn:aws:secretsmanager:ap-northeast-1:<アカウントID>:secret:*",
            "Effect": "Allow"
        },
        {
            "Action": [
                "secretsmanager:GetRandomPassword"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

全体の構成は次の図のようになっています。
構成図

シングルユーザーローテーションのオプション

auroraCluster.addRotationSingleUser();

シングルユーザーローテーションはこの一行で書けますが、いくつかオプションを渡すこともできます。

import { Duration } from "aws-cdk-lib";

auroraCluster.addRotationSingleUser({
  automaticallyAfter: Duration.days(30),
  excludeCharacters: " %+~`#$&*()|[]{}:;<>?!'/@\"\\",
  vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED },
  endpoint: endpoint,
});
  • automaticallyAfter: ローテーション間隔(デフォルトは30日)
  • excludeCharacters: パスワードから除外する文字。デフォルトは「 %+~`#$&*()|[]{}:;<>?!'/@\"\」
  • vpcSubnets: ローテーション用Lambda関数を配置するVPCサブネット(デフォルトはデータベースクラスタと同じサブネット)
  • endpoint: ローテーション用Lambda関数がSecrets Managerにアクセスするために使うVPCエンドポイント。プライベートDNSVPCで有効なら特に指定不要

マスターユーザー以外のユーザーのパスワードローテーション(マルチユーザーローテーション/交代ユーザーローテーション)

アプリケーションからデータベースにアクセスするときはマスターユーザーではなく、権限を制限したユーザーを使うのが望ましいです。
addRotationSingleUser() 関数はマスターユーザーのローテーションのみを行うため、マスターユーザー以外のユーザーのパスワードをローテーションする場合、少し書き方が異なります。

// 「user」というユーザー名でパスワードを自動生成する
const userSecret = new rds.DatabaseSecret(this, "MyUserSecret", {
  username: "user",
  secretName: "MyAuroraClusterUserSecret",
  masterSecret: auroraCluster.secret,
});
// データベースの接続情報を追加する
const secretAttached = userSecret.attach(auroraCluster);

// ローテーションを設定
auroraCluster.addRotationMultiUser("MyUserRotation", {
  secret: secretAttached,
});

ローテーションには addRotationMultiUser() 関数を使います。これは「マルチユーザーローテーション」もしくは「交代ユーザーローテーション」と呼ばれるローテーション方法です。
ローテーション実行時はユーザーのパスワードをすぐに上書きするのではなく、元のユーザーと同じ権限を持つユーザーを新たにデータベースに作成します。同時に2つのユーザーが有効になるため、データベースにアクセスするアプリケーションがクレデンシャル情報をキャッシュしている場合でも、ローテーションによって急に接続できなくなる事態を回避できます。そして2回目以降のローテーションでは新規にユーザーは作成せず、2つ前のユーザーのパスワード情報を上書きすることで、古いパスワードを利用できなくします。
マルチユーザーローテーションを行うには、ユーザーをクローンする権限が必要であるため、マスターユーザーのシークレットを渡しています。

masterSecret: auroraCluster.secret,

以上はあくまでもシークレットの作成とローテーションの設定であり、別途データベースに接続し、同じユーザー名でユーザーを作成する必要があります。作成するユーザーにはSecrets Managerに登録された自動生成パスワードを設定します。

1度ローテーションを実行した後のデータベースユーザー一覧を見ると、user という名前のユーザーに加え、 user_clone という名前のユーザーも存在することがわかります。これ以降、 useruser_clone のパスワードが交互に変更されていきます。

データベースユーザー一覧

マルチユーザーローテーションで作成されたリソース

マルチユーザーローテーションを設定すると、シングルユーザーローテーションと同じく以下のリソースが作成されます

  • ローテーション用Lambda関数
  • Lambda関数のセキュリティグループ
  • Lambda関数の実行ロール

Lambda関数の実行ロールは、シングルユーザーローテーションの時と若干異なり、以下のポリシーが付いていました。

  • AmazonRDSReadOnlyAccessAWS管理)
  • AWSLambdaBasicExecutionRole(AWS管理)
  • AWSLambdaVPCAccessExecutionRole(AWS管理)
  • SecretsManagerRDSMySQLRotationMultiUserRolePolicy1(カスタマーインライン)
  • SecretsManagerRDSMySQLRotationMultiUserRolePolicy2(カスタマーインライン)
  • SecretsManagerRDSMySQLRotationMultiUserRolePolicy3(カスタマーインライン)

インラインポリシー SecretsManagerRDSMySQLRotationMultiUserRolePolicy1SecretsManagerRDSMySQLRotationMultiUserRolePolicy2 は、シングルユーザーローテーションの時のインラインポリシーと同じ内容でした。

インラインポリシー SecretsManagerRDSMySQLRotationMultiUserRolePolicy3 はシングルユーザーローテーションにはなかったポリシーで、マスターユーザーのシークレットへのアクセスを許可しています。(~UserRolePolicy2 で該当リージョンの全シークレットへの GetSecretValue を既に許可しているため、冗長であるように思えます)

{
    "Statement": [
        {
            "Action": [
                "secretsmanager:GetSecretValue"
            ],
            "Resource": "arn:aws:secretsmanager:ap-northeast-1:<アカウントID>:secret:MyAuroraClusterSecretD92700-ozDfy6jZIGiv-iVeG0u",
            "Effect": "Allow"
        }
    ]
}

マルチユーザーローテーションのオプション

マルチユーザーローテーションではパラメーター secret にローテーション対象のアタッチ済みシークレットを指定する必要があります。

auroraCluster.addRotationMultiUser("MyUserRotation", {
  secret: secretAttached,
});

その他のオプションはシングルユーザーローテーションと同じものを指定できます。

  • automaticallyAfter
  • excludeCharacters
  • vpcSubnets
  • endpoint

まとめ

CDKでAuroraクラスタのパスワードをローテーションする設定を非常に簡単に書けました。マスターユーザーはシングルユーザーローテーション、それ以外のユーザーはマルチユーザーローテーションとなるのが個人的に面白かったです。
今回は試していませんが、公式ドキュメントによるとAurora以外のRDSデータベースでも、同じような方法でパスワードのローテーションを実現できそうです。

執筆:@kou.kinyo2、レビュー:@sato.taichiShodoで執筆されました

新人研修にFactorioを導入してみた!

はいどーもー! Xイノベーション本部の宮澤響です! 本記事では、株式会社電通国際情報サービス(以下、ISID)の新人研修にFactorioを導入した話を紹介します!

そもそもFactorioって何?

Factorioとは、自動化された工場を建設して様々なアイテムを生産していく、サンドボックス型のシミュレーションゲームです。 資源の採掘、技術の研究、インフラストラクチャの構築、生産の自動化などを行い、最終的にはロケットで人工衛星を打ち上げ、プレイヤーが不時着した未知の星から脱出することが目的となります。 最初は手動での生産に始まり、そこから様々なアイテムを駆使して生産を自動化、効率化していく点が、このゲームの大きな特徴であり醍醐味となっています。

(画像はSteamのFactorioのページより)

この研修を導入するに至った背景

きっかけは、新入社員同士のアイスブレイクの場を内製で提供できないか、という人事部からの依頼でした。 もちろん、リモートでの研修が主体となる新入社員にとっては、対面でアイスブレイクができる場というだけでも十分価値があります。 しかし、新人研修の一環であるため、せっかくなら楽しむだけでなく学びを得てもらいたい(具体的には、論理思考力を強化してもらいたい)ということになり、この研修を企画することになりました。

そこで、何か良い題材がないか探していたところ、このISIDテックブログの発起人でもある佐藤太一さんにFactorioを紹介いただきました。 先述のとおり、Factorioは自動化や効率化がキモであることから、SIerの営みと関連させて論理思考力を強化できるのではないかと考え、Factorioを題材とすることに決定しました。

ちなみに、研修担当者である私自身はFactorio未経験であり、このようなジャンルのゲームのプレイ経験もほとんどありませんでした。 そのため、まずはFactorioを休日に触るところから始めました。

Factorioの実行環境を巡る紆余曲折

研修を導入するまでにはいくつかの紆余曲折がありましたが、その中でも最も大きかったものが、Factorioをプレイするにあたり、Factorioをどこで実行するか、というものでした。

最初に検討したのは、Factorioを新入社員の社用PCにダウンロードさせ、ローカル環境で実行する形式です。 こちらは単純明快で技術的な問題も発生しない形式ではありますが、社用PCにゲームを入れるのはいかがなものか、という懸念もあり、代替手段がないか検証することになりました。

続いて検討したのは、新入社員69名分の仮想マシンを社内に用意し、新入社員には社用PCからそこに接続してもらう、という形式です。 この形式であれば新入社員の社用PCにFactorioをダウンロードさせる必要がないため、先述の懸念は解消されます。 しかし、人数分の仮想マシンを用意することはリソース的に難しいと担当者に断られてしまったため、別の代替手段を検討することになりました。

次に検討したのは、クラウドサービスを利用する形式です。 社内の仮想マシンの代わりに、Amazon EC2インスタンスAmazon WorkSpacesのデスクトップを用意し、それらに接続する形式の検証を行いました。 ですが、操作の遅延により快適にプレイできない、社内ネットワークの都合によりFactorioに必要なUDPでの通信ができない、などの問題点が発覚し、これらも現実的でないことが分かりました。

ここまでの検討の結果を踏まえ、一時はFactorioの導入自体を白紙に戻す案まで浮上しました。

しかし、人事部との相談の末、「そもそも遊び目的でなく研修のために実施するという大前提があるため、必要情報(今回が特別であること、社用PCはログを取られていること、など)をインプットすれば、大きな問題にはならないだろう」という判断をいただき、一周回って新入社員の社用PCにダウンロードさせる形式で研修を実施することとなりました。

迎えた研修当日

そんなこんなで迎えた研修当日です。 当日は、以下のような流れで研修を進めました。

  1. 導入
  2. 操作説明・ハンズオン
  3. 実習ルール説明
  4. 実習1
  5. 振り返り1
  6. 実習2
  7. 振り返り2
  8. 解説とまとめ

導入

自己紹介、Factorioのダウンロード、研修の目的や内容の説明を行いました。 目的は、以下の力の基礎を身につけることとしました。

  • 筋道立てて物事を考える力
  • 自動化、効率化できる部分を考える力
  • ドキュメントを読んで仕様を理解する力

また、通常の研修や業務において、社用PCに不要なゲームやアプリをダウンロードする行為は禁止である旨の注意喚起も行いました。

操作説明・ハンズオン

ハンズオン形式で基本操作を説明しました。 公式のチュートリアルは少し難易度が高く、今回の実習でプレイするチーム生産シナリオには不要な要素(研究、蒸気機関による電力の確保、バイターとの戦闘など)も含まれることから、今回は弊社独自のハンズオンを実施しました。

実習ルール説明

今回の実習でプレイするチーム生産シナリオのルールを説明しました。 このシナリオでは、プレイヤーはいくつかのチームに分かれて、共通のお題として指定されたアイテムを納品します。 それぞれのチームは同一の条件(生成されるフィールドや初期アイテムなど)の下でアイテムを製作していき、最終的に最も早く納品を完了させたチームの勝利です。

今回、このシナリオを選択した理由は以下です。

  • ゴールまでの道筋が明確で、難易度が初心者にちょうど良い
  • チームで競い合える
  • 以下の特徴により、自動化、効率化に専念できる
    • 研究が進んだ状態で開始する
    • 初期アイテムを豊富に所持している
    • 最初から電力を利用できる
    • バイターが出現しない
    • ゲーム時間の概念がない(夜時間がないので暗くならない)

今回は、3台のヘッドレスサーバを用意し、それぞれのサーバに4チームずつ接続してもらう形式としました。 つまり、それぞれのサーバごと、4チームの中での勝負となります。 それぞれのサーバは同一のセーブデータから起動しているため、お題は全12チーム共通です。

実習

チーム生産シナリオでの実習を行いました。 納品完了までの時間の使い方は完全にチームに委ねたため、善は急げとすぐに資源を採掘し始めるチーム、急がば回れと全員で作戦会議をするチーム、間を取って戦略立案組と採掘組に分かれるチームなど、チームごとに様々な戦略で実習を進めていました。 運営側としては、このようにチームによって戦略がばらけているほど、振り返り内容の共有によって得られる気づきも大きいと考えていたため、目論見どおりといったところでした。

なお、実習1と実習2のお題は以下です。

  • 実習1
    • 駅:50
    • 銅板:400
  • 実習2
    • レーダー:50
    • 自動車:10

想定ではどちらの所要時間も60分程度の見込みでしたが、それを上回るペースで納品を完了させるチームも散見されました。

振り返り

実習での良かった点、改善点などをチームで振り返ってもらい、その内容を簡単に発表してもらいました。 最終的に必要になる資源の数に応じてリソースの配分を意識すべきだった、初期アイテムに何があるかとその使い方を確認しておくべきだった、など、重要な気づきが多く生まれていました。

解説とまとめ

研修冒頭で提示した、以下の力の基礎を身につけるという目的に沿って、それぞれの力が今回の研修で必要だった場面と、実際の業務で必要になる場面を例に挙げて解説を行いました。

  • 筋道立てて物事を考える力
  • 自動化、効率化できる部分を考える力
  • ドキュメントを読んで仕様を理解する力

最後には、再度注意喚起を行った上で、新入社員のPCからFactorioを削除して終了となりました。

実施してみてどうだったか

率直な感想としては、無事に研修を実施できてホッとしているというのが正直なところです。

企画、技術的な検証、各種準備、当日の運営、振り返り、アウトプット(本記事)に至るまでの一連の業務を担当できたことは、私にとって非常に貴重で有意義な経験でした。 特に、検証の過程では、仮想サーバやAWS、Dockerなどの知識を深めることができたため、私自身の技術的な学びにも繋がりました。 また、私自身、人前で何かを説明したり、ハンズオンを実施したりといったことが好きであるため、当日も楽しんで運営することができました。

新入社員からも、ただ楽しかったというだけでなく、SIerに必要なスキルに関する学びを得られた、といったフィードバックをいただいており、この研修で伝えたかったことはしっかりと伝えられたのではないかと思います。 何から何まで初の試みでしたが、研修としては成功だったんじゃないかなと思います。

一方、ダウンロードに時間がかかる、回線が重く稀にサーバとの接続が切断される、1チームが納品を完了させてしまうと同じサーバに接続している他のチームは納品完了できずに途中で終了してしまう(これに関しては事前に承知の上で許容していたことではありましたが)など、改善すべき点も見つかりました。

今後は内定者研修などに応用したいという話にもなっているので、そのあたりの対応方法は引き続き検討していきたいと考えています。

まとめ

本記事では、ISIDの新人研修にFactorioを導入した話を紹介しました! 紆余曲折はあったものの、研修としては成功裏に終わり、新入社員からも高評価をいただけました。 皆さんもぜひ、所属企業の研修にFactorioを取り入れてみませんか?

ということで、今回も最後までお読みいただき、本当にありがとうございました!

執筆:@miyazawa.hibiki、レビュー:@sato.taichiShodoで執筆されました

"ピープルアナリティクス"のcertificationを取得しました!

みなさん、こんにちは。コーポレート本部コーポレートHRユニット人事部の今村と申します。

私自身、人事部ではここ10年ほどは人材開発、組織開発にどっぷり関わってきたのですが、今年から「ピープルアナリティクス」というテーマに取り組んでいます。

「HRアナリティクス」とか「データドリブン人事」とか表現はいろいろありますが、要は「人」に関する取り組みの判断においてこれまで重視されがちだった「勘と経験」だけではなく、「人」のデータを収集/可視化/分析して様々な意思決定の確度を向上させようということをねらいとしたものです。マーケティングを始め、日常のビジネスプロセスではごくごく当たり前の取り組みが、昨今、ようやく人事の領域でも本格的に注目されてきました。

個人的にこの領域には以前から興味があり、少なからず業務の中で取り組んできたこともあったのですが、ここに来て改めて新たな領域へ本格的にチャレンジなので、まずは体系的に学ばねば、ということで、今年に入ってからから本格的にピープルアナリティクスの勉強を始め、先日、Academy to Innovate HR(略称AIHR)が認定している「People Analytics Specialist」のcertificationを取得することが出来ましたので、その内容について紹介いたします。

AIHRという学習機関

この「Academy to Innovate HR」は2016年に設立されたオランダの学習機関で、HR(人事)プロフェッショナルとして必要なスキルをオンラインで学べる学習プラットフォームです。 ※AIと略しているので一瞬あのAIと勘違いしがちですがもちろん別物です。 https://www.aihr.com/

その名の通り、HR全般を学べる学習機関で、People AnalyticsやDigital HR、OD(組織開発)等11のcertificationに加え、Hiring & Recruitment Strategy、Employee Experience and Design Thinking等の学習コースがあり、中にはBlockchain and HRと言った、日本ではなかなかお目にかかれないコースもあります。

そもそも日本ではなかなか「ピープルアナリティクス」という領域にフォーカスして体系的に学べる場が見つからなかったのですが、私が社外活動として理事も務めている人材育成のグローバルな会員組織である「ATD(The Associaton for Talent Development)」日本支部(https://www.atdj.jp/atd-imnj)の方から紹介され、ここに来て業務上の必要性にも迫られたことあり、覚悟を決め本格的に学び始めることにしました。日本ではまだ全くと言っていいほど馴染みがないので、ちょっとレア感もあるのが自分好みだったということもありチャレンジしてみましたが、予想以上に価値のある学びの多い内容でした。 もしかすると、日本人でこのcertification取得したのはまだほとんどいなさそうなので、そういう意味でも心地よい達成感があったりします。

AIHRの特徴

なお、このAIHRは、

・すべて英語(但し、字幕付き) ・すべてオンライン ・費用は、こんな感じ。

いくつかコースのオプションがあり、個々人の学習スタイルに応じて選択できる点も学習しやすい点だと感じました。

People Analytics certificationのカリキュラム

このPeople Analytics certificationで学べる内容は、以下のとおりです。

「Statistics in HR」のパートがいわゆる分析手法をやや深めに学ぶパートです。深めと言っても、数学に全く明るくない私にも無理なく理解できる内容で、実際にデータを自分でいじりながら学ぶこともできるので、実務で活用するイメージも湧きやすくできています。(そもそも統計で使われている専門用語って「英語だとこう言うんだー」という素朴な発見もありました) なお、このパートについては、日本語で統計を解説している一般のサイトも並行して使いながら学ぶと、より効率的に学べると思います。

認定取得に要した学習時間

ちなみに、今回certificationを取得するまでに要した時間ですが、おおよそ毎日30分~1時間の勉強で、約3か月かかりました。一つのLessonの動画がおおよそ15-20分程度(+ボーナスレッスンや推奨動画/記事等もあり)なので、比較的無理なく学習できるペースでした。(もちろん期間中は何度でも視聴可能です)

この学習コースから学んだこと

前述したように、カリキュラムとしては、 1.HR Analytics Leader 2.Statistics in HR 3.HR Data Analyst 4.Capstone Project

という4つのモジュールに分かれていて、People Analyticsの基礎的な考え方や、分析プロセス、フレームワーク、そして具体的な分析手法等を学びました。「People Analytics」という名前の印象から、「Analytics」の手法を掘り下げて学ぶイメージがあるかもしれませんが、全体を通して、再三、強調されている(と私が感じている)点は、「ビジネス課題」へのアプローチの重要性とビジネスインパクトを重視する、ということです。

こう書くととても当たり前の話なのですが、単に人事関連のデータを分析する、そしてインサイトを出す、予測をする、ということはもちろんPeople Analyticsの大事な要素であり、プロセスではあるものの、そもそもの目的はビジネスゴール(組織目標)を達成することである、というメッセージが何度も出てきます。 さらに言えば、ビジネスゴールを達成するためには、いくつかの課題があり、その課題と人のパフォーマンスの関連をしっかりと紐づけた上で、その課題が生まれた背景やコンテクストも正しく理解することが重要ということです。要は「チェンジマネジメント」のプロセスそのものだよ、ということもメッセージの一つでした。 また、Agileで進める、small-winを積み重ねる、という点もキーメッセージの一つだと感じました。

なお、「どこから手を付けていいかわからない」という人のために、実務上の推進プロセスの整理の方法として、「The HR Value Chain」というフレームワークが紹介されていました。 とてもシンプルではありますが、今後、People Analyticsを進めていく上では実践的で活用しやすそうです。 https://www.aihr.com/blog/hr-value-chain-essential-tool-for-adding-value-to-hr/

今後実践していきたいこと

今回のcertificationの取得によって、私自身もこれから「ピープルアナリティクス」の実践スキルを高めていく上での前準備ができたという段階なので、これからさらに実践していきながらこのスキルを磨いていき、少しでも早くビジネス成果につなげていきたいと考えてます。 とはいえ、この取り組み自体はスタートしたばかりなので、まずは一つ目のsmall-winに向けて社内外での仲間を少しずつ増やしていければと思っています。

<参考>こんなデジタル証明書がもらえます。

執筆:@masayuki、レビュー:Ishizawa Kento (@kent)Shodoで執筆されました

Service CloudとTwilio Flexでコンタクトセンターをクイックにスタートする

みなさん、こんにちは。ISID CIT事業部の石際です。

コンタクトセンターのクラウド化が進んでいますが、Salesforce Service Cloud(以下「Service Cloud」)のような顧客管理(CRM)アプリケーションと連携することでのカスタマーエクスペリエンス(CX)の向上も重要視されています。

Service CloudでCTI(Computer Telephony Integration)機能を具備したコンタクトセンターを構築する場合、Salesforceが提供しているOpen CTIというライブラリを利用して各テレフォニーベンダーが作成したCTIとService Cloudを連携することで実現できます。

コールセンター構築と聞くと複雑で構築に時間が掛かる印象ですが、Twilioが提供しているクラウド型コンタクトセンターのTwilio Flexであればクイックスタートが可能です。

今回はService CloudにTwilio Flexを連携させることで、CTI機能を具備したコンタクトセンターを構築してみました。

1. Twilio Flexとは

Twilioは、電話やSMS・ビデオ・チャット・SNSなど世の中にある様々なコミュニケーションチャネルをWeb・モバイルアプリケーションとつなぐクラウドコミュニケーションAPIサービスです。そのTwilioの各種サービスを組み合わせたプログラマブルクラウド型コンタクトセンタープラットフォームがTwilio Flexになります。マルチチャンネルに対応し、オペレータの画面のUIはもちろんIVR1やACD2などのフルカスタマイズが可能となっています。

2. Service CloudとTwilio Flexを連携してみる

今回は Integrate Twilio Flex with Salesforce を参考に設定を行いました。

Service Cloudに電話を連携する場合、一番メジャーなのはAmazon Connect CTI Adapterだと思います。Amazon ConnectはSalesforceのAppExchangeからパッケージのインストールが必要です。

一方で、Twilio Flexとの連携ではパッケージのインストールが不要です。Twilio Flexの設定とTwilioで用意されているコールセンター定義ファイルをSalesforceにインポートしSalesforceの設定を行うだけで完了します。10分程度あれば完了してしまうという驚きの簡単さです。

では、さっそくセットアップをしてみましょう。

(事前にTwilioで電話番号を取得しておきます。電話番号の取得方法はTwilioコンソールから電話番号を購入する方法を参考にしてください。)

2-1. セットアップ

Twilio Flexの設定

まずは、Twilio Flexの設定を行います。

Flex管理画面から [INTEGRATIONS] をクリックしCRM連携設定の画面に遷移します。

CRM連携設定の画面で [Salesforce] を選択し、Salesforce連携の設定を行っていきます。

Twilio_Salesforce_Integration_Setting.png

1. 設定を有効にする

[STATUS] のセクションでトグルを [Enabled] にして、連携の設定を有効化します。 (こちらは公式ドキュメントに書いていないのでご注意ください)

2. パラメータを設定する

[CONFIGURATION] のセクションで下記の項目を設定します。

  • Workflow SID(任意):エージェントのルーティングルール(Workflow)を指定します。デフォルトの場合は空欄にしておきます。
  • Task Channel SID(任意):音声チャネルとは異なるチャネルを使用したい場合にチャネルを指定します。
  • Agent Caller ID(必須):SalesforceからClick to Dialで発信するために使用する発信者IDを指定します。(上記の画像ではこの項目が表示されていませんが、初回の設定でのみ項目が表示されます。設定後はTwilioコンソールの [Flex] > [Manage] > [Voice] 画面の [Flex Dialpad] にて設定が可能です)
  • Salesforce Base URL(必須):Salesforceドメインを登録します。(初回の設定後はTwilioコンソールの [Flex Settings] 画面で設定を行います)
  • SSOSalesforceがIdPとしてSSOの設定が可能です。(今回は設定していませんが、利用する際は Configure Salesforce SSO With Twilio Flex などを参照して必要な設定を行ってください)
  • LOG:ログをSalesforceに記録したい場合はチェックを付けます。

それぞれの項目は設定後変更が可能です。

3. コールセンター定義ファイルをダウンロードする

最後に [FILES] のセクションの [DOWNLOAD] からコールセンター定義ファイルをダウンロードします。

Salesforceの設定

次にSalesforce[Setup] にて設定を行います。

1. コールセンター定義ファイルをインポートする

[Call Centers] の設定画面から [import] ボタンをクリックし、Twilio Flexからダウンロードしたコールセンター定義ファイルをインポートします。

インポート後、[Call Center Users] のセクションにある [Manage Call Center Users] ボタンをクリックし、ユーザーを追加します。

Salesforce_Call_Centers_Import.png

Salesforce_Call_Centers.png

2. 着信時のアクションを設定する

[Softphone Layouts] の設定画面から着信時の挙動を必要に応じて設定します。

Salesforce_Softphone_Layout.png

3. ソフトフォンを追加する

[App Manager] の設定画面からTwilio Flexを表示させたいアプリを選択します。今回は [Service Console] にTwilio Flexのソフトフォンを追加します。

[App Settings] から [Utility Items] を選択します。

[Utility Items] のリストに [Open CTI Softphone] を追加し、下記の内容で項目を設定します。

Salesforce_Utility_Items.png

はい、これで完了です!すべてGUIベースでクイックに連携ができました。

Service Consoleを見てみると、Twilio Flexのソフトフォンが表示されるようになっています。

Salesforce_Service_Console.png

2-2. 連携すると何ができるか

さて、Service CloudとTwilio Flexを連携することで何ができるでしょうか。

着信時の動作を確認してみる

Twilio FlexはコールフローをStudioで設定できます。動作確認では着信があるとすぐにオペレーターにつなぐフローを使用します。

早速、Twilioで取得した電話番号に電話をしてみます。

1. 着信がポップアップする

まず、着信があるとFlexのソフトフォンをポップアップします。

Incoming_Call.gif

2. 着信を受けると顧客情報ページを表示する/新規登録ページを表示する

着信している電話番号をクリックすると電話番号からオブジェクトを検索し、画面に表示します。

Contact.gif

電話番号がヒットしない場合は、新規登録ページが表示されます。この時、電話番号がフィルされます。

New_Contact.gif

3. タスクにログを記録する

Twilio FlexSalesforce Integrationの設定でログを有効にした場合は、タスクにログが記録されます。

Log.gif

このように、デフォルトの設定で必要最低限の機能が実装されています。

カスタマイズが必要な場合はTwilio StudioやSalesforceの開発が必要になってきます。

3. 簡単なコールフローを作ってみました

Studioを使って少しコールセンターっぽいコールフローを作ってみました。

Twilio_Studio_Flow.png

フローの流れは上記のようになります。"sfdcSearchString": "{{widgets.getInput.Digits}}" をセットすることで、グローバル検索に値を渡すことができます。

オペレータが見ているSalesforceの画面では、

  • 会員番号がある顧客は会員番号でグローバル検索される

Salesforce_Global_Search.png

  • 会員番号がない顧客は電話番号で検索され、なければ新規登録画面が表示される

Salesforce_New_Contact.png

という動きになります。

このように、Studioをカスタマイズすることでオペレータにとっては効率的な、顧客にとっては便利で親切なコンタクトセンターの構築が可能です。

4. 感想

想像以上に簡単にService Cloudとの連携ができました!Amazon Connect CTI Adapterを使った連携よりもシンプルな構成のためクイックにスタートできる点が良いところだと感じました。

また、Twilio Flexを利用するメリットとしては、

  • 対応チャネルが豊富
  • APIや開発用のライブラリなどが充実
  • コンタクトセンターの総合的な改善が可能

などが挙げられます。

機能の拡張性も優れているため、クイックにはじめた後、業務に応じて開発を柔軟に行っていくことも可能です。Service Cloudでコンタクトセンターを構築する際、Amazon ConnectだけでなくTwilio Flexも検討してみてはいかがでしょうか? 最後までお読みいただきありがとうございました。

執筆:@ishigiwa.yumi、レビュー:@higaShodoで執筆されました


  1. IVR (Interactive Voice Response) 自動音声応答:コールセンターなど企業の電話窓口で、音声による自動応答を行うコンピューターシステム。発信者のダイヤル操作に合わせて、あらかじめ録音してある音声を発信者側に自動的に再生する。音声認識機能を備え、相手の発話に応じて再生内容を決める製品もある。

  2. ACD (Automatic Call Distribution) 自動着信呼分配機能:着信したコールを自動的に管理、コントロールする装置。次々に入る着信コールを、その時点で空いている、あるいは次の応答を最も長時間待っている適切なスキルを持ったテレコミュニケーターから順次均等に配分できる機能を備える。