ホーム ブログ ページ 12

初めてのAdobeXDで優秀だと思ったプラグイン【9選】

0

デジタルビジネス部所属、20卒の武田です!
入社してから早半年が経ちました、あっという間ですね。
優しい先輩たちに助けられながら、業務にも少しずつ慣れてきたかなと思います。
(トライアンドエラーの日々です)

本日はワイヤーフレームやデザインカンプの作成でよく使われるAdobeXDのプラグインについてご紹介していきます。
XD自体は入社してから初めて使ったのですが、

さすがAdobe製品

PhotoshopやIllustratorなどを使っていたからか、直感的でスムーズに操作方法を学習することができました。
パワーポイントやエクセルなどで作成するよりも圧倒的に時間短縮できて作業効率も上がるのですが、もっと便利に使いたい!と思いたくさんのプラグインを試してみました。
その中で、使う頻度が高いものや便利!と感じたおすすめプラグイン9個を紹介していきます☆


パーツ おすすめプラグイン(3選)

1. Calendar|カレンダー

カレンダーを一から作るのって大変ですよね、こちらのプラグインは指定した月のカレンダーをXD上に生成することが可能です。
セルのサイズ変更や週の曜日始まり、曜日の表示形式なども調整できるとてもシンプルで使いやすいプラグインです。

2. unDraw|イラスト素材

シンプルでおしゃれなイラストが揃っていて、配色を変えることもできるプラグイン。
イラスト数は多いのに無料で会員登録も不要なのでとっても優秀です。ファイルはSVG・PNGの2種類の形式から選ぶことができます。統一性のある見た目になるため、ガラッとプロフェッショナルなデザインへと変わります。

3. Icondrop by Iconscout|アイコン素材

アイコンに限らずイラストや写真まで、数百万個あるライブラリから検索し、アートボード上に簡単に挿入することができるプラグイン。無料・有料とあるのですが、無料素材でも量が多いため簡単にお目当ての素材を見つけ出すことができます。また、無料版ではPNG形式のみの利用が可能です。
※利用する際にはメールアドレスとパスワードを記入するだけの簡単な会員登録が必要です


効率化 おすすめプラグイン(3選)

1. Artboard Plus|アートボード整列機能

アートボードの整列に関しての効率化を図るためのプラグイン。
ばらばらになっているアートボードを均等に配置したり、選択したオブジェクトのサイズと同じアートボードを作成したり、レイヤーを名前順に並び替えることもできます。

2. Resize Artboard to Fit Content|コンテンツ量に合わせてアートボードをリサイズ

コンテンツ量に合わせてアートボードの高さを変更するのは意外と面倒で時間がかかりますよね。
その時に使っていただきたいプラグインはこちらです。
サイズ変更したいアートボードを全て選択し、プラグインを起動させると一瞬でリサイズされます。

3. Swapper|オブジェクト入れ替え

2つのオブジェクトの位置を逆にしたい、シンプルなことですが意外と面倒。そんな時はSwapperを使うとオブジェクトの位置をサッと簡単に入れ替えることが可能です。グループ化されているオブジェクトも対象なので作業効率が一気にアップします。


その他 おすすめプラグイン(3選)

1. Stark|色盲・色弱シミュレーション

色盲や色弱のシミュレーションをしたり、コントラストをチェックすることができるプラグイン。
こちらは無料版、有料版とあるのですが、無料版で使えるのが「Color Blind Simulation(カラーブラインドシミュレーション)」と「Check Contrast(チェックコントラスト)」の2つ。

カラーブラインドシミュレーションは様々な症状の色盲/色弱を持ったユーザーにはどのように見えるのかをチェックすることができます。
チェックコントラストは選択しているオブジェクトの背景色とテキスト色のコントラスト比を数値で確認することができます。

2. Confetti|背景パターン作成

Confettiを使うと、1クリックで簡単にインパクトがある背景パターンを生成することが可能です。指定した図形を複製し、複数の機能を合わせることにより、このブログのメインビジュアルのような図を作ることができます。
(業務であまり使う事はないのですが、覚えておいても損はないと思います!)

3. Whiteboard|コミュニケーション

XD上でアイデア出しや意見などを交わせるプラットフォームを用意しているプラグイン。
テンプレートとしてホワイトボード、ブレインストーミング、フローチャートやマインドマップなどといったコミュニケーションメソッドが備わっていて、さらに各メソッドの使い方まで書いてあるので初心者でもとても使いやすいです!
リモートワークでもコミュニケーションの大切さを忘れないよう開発されたプラグインですね☆


おわりに

Adobe XDのアップデート頻度は月に1回ぐらいで、その度に便利な機能がたくさん追加されています。
それに伴い、新しいプラグイン既存プラグインのアップデートもよくあるので、常にチェックしておいたほうが良さそうですね。
プラグインを使いこなすことで、手間の改善や作業効率を上げられること間違いなし!
ストレスフリーな作業環境を目指すために、是非積極的に取り入れてみてください♪

iWGAN-LCを用いたロゴ画像生成

0

概要

GANを応用したiWGAN-LC(LayerConditional)というモデルを使ったロゴ画像生成を行いました。 ロゴ画像生成にはiWGAN-LCの実装である https://github.com/alex-sage/logo-gen を使いました。 はじめに、iWGAN-LCとその元となったモデルの簡単な説明をしていきます。

GAN

敵対的生成ネットワークと呼ばれるモデルで、教師なし学習で画像生成などが行なえます。 GANの特徴は、贋作を作るモデル(生成器)と、贋作か本物か見分けるモデル(識別機) の2つのモデルが使われる点です。贋作を作るモデルは、本物そっくりの贋作を作るように訓練され、見分けるモデルはより偽物を見破れるように、切磋琢磨する形で訓練されていきます。

ただ、GANには以下の問題点がありました。

  • 勾配消失が発生する
  • モデルの良否を判断する明確な指標がない
  • モード崩壊が起こる

これらを改善しようとしたモデルがWGANになります。

WGAN

WGANはWasserstein GANの略で、GANとの違いは以下になります。

  • GANでは損失関数にJSD(Jensen-Shannon divergence)が使われていたが、WGANではWasserstein距離を使用している。(勾配消失問題への対処)
  • Wasserstein距離を使うための制約として、重みのクリッピングをしている。

WGANには以下の問題点がありました。

  • 重みのクリッピングを行ったことで、学習が不安定になる。

学習の不安定性の解消を図ったのがiWGAN-LCになります。

iWGAN-LC

iWGAN-LCはWGANを拡張したモデルで、WGANとの主な違いは以下になります。

  • ラベルを事前にクラスタリングし、ワンホットベクトルとして、潜在ベクトルに追加
  • 追加の特徴マップを各畳込み層と線形層(生成器、識別機の両方)の入力に追加

実行環境構築

ロゴ画像生成処理にはGPUを使用するため、EC2のGPU利用可能なインスタンスを使う前提で環境構築を行います。また、今回はゼロからモデルの訓練は行わず、公開されているpretrainedモデルを利用します。

まずはDockerfileの作成と、必要なソースを用意していきます。それらが準備できたら、EC2上でDockerビルドしていきますが、ソースをEC2に配置しやすいように、適当なgitリポジトリにpushしておくと楽かもしれません。また、データセット、pretrainedモデルはファイルサイズが大きいので、EC2上で直接ダウンロードして配置するほうがよいかもしれません。(お好みで)

EC2インスタンスの設定

利用するインスタンスは以下になります。

  • AMI
    • Deep Learning AMI (Ubuntu 18.04) Version 36.0 – ami-0bc87a16c757a7f07
  • インスタンスタイプ
    • g4dn.xlarge (GPUが使えるものであればOK)

logo-genの環境要件

python 2系
tensorflow 1.3
tensorflow-gpu 1.3
cuda 8.0
cudnn 6

上記のpython、cuda、cudnnが入っているnvidiaのdockerイメージを利用して環境構築していきます。cuda, cudnnのバージョンは、tesorflowのバージョンにあったものを選択する必要があるため、別のバージョンだと動かない可能性が高くなります。tensorflowなどについてはDockerfile内でpipでインストールしていきます。Dockerfileは以下の内容で作成します。

Dockerfile
FROM nvidia/cuda:8.0-cudnn6-runtime-ubuntu16.04

SHELL ["/bin/bash", "-c"]

ENV APP_ROOT /app
ENV LANG=C.UTF-8

RUN apt-get update -qq && \
   apt-get install -y --no-install-recommends \
   build-essential \
   libboost-all-dev \
   wget \
   vim \
   openssh-client \ 
   graphviz-dev \
   pkg-config \
   git-core \
   openssl \
   libssl-dev \
   libffi6 \
   libffi-dev \
   cmake \
   unzip \
   python-dev \
   python-pip \
   python-setuptools \
   curl && \
   apt-get clean && \
   rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* && \
   mkdir /install

RUN pip install --upgrade pip
RUN pip install backports.functools-lru-cache==1.5 \
  backports.shutil-get-terminal-size==1.0.0 \
  backports.weakref==1.0rc1 \
  bleach==1.5.0 \
  cycler==0.10.0 \
  decorator==4.3.2 \
  enum34==1.1.6 \
  funcsigs==1.0.2 \
  h5py==2.9.0 \
  html5lib==0.9999999 \
  ipython==5.8.0 \
  ipython-genutils==0.2.0 \
  kiwisolver==1.0.1 \
  Markdown==3.0.1 \
  matplotlib==2.2.3 \
  mock==2.0.0 \
  numpy==1.16.1 \
  pathlib2==2.3.3 \
  pbr==5.1.2 \
  pexpect==4.6.0 \
  pickleshare==0.7.5 \
  Pillow==5.4.1 \
  prompt-toolkit==1.0.15 \
  protobuf==3.6.1 \
  ptyprocess==0.6.0 \
  Pygments==2.3.1 \
  pyparsing==2.3.1 \
  python-dateutil==2.8.0 \
  pytz==2018.9 \
  scandir==1.9.0 \
  scipy==1.2.1 \
  simplegeneric==0.8.1 \
  six==1.12.0 \
  subprocess32==3.5.3 \
  tensorflow==1.3.0 \
  tensorflow-gpu==1.3.0 \
  tensorflow-tensorboard==0.1.8 \
  tqdm==4.31.1 \
  traitlets==4.3.2 \
  wcwidth==0.1.7 \
  Werkzeug==0.14.1 \
  --no-cache-dir

COPY src $APP_ROOT/src

WORKDIR $APP_ROOT/src

Dockerfileと同じディレクトリに、log-genリポジトリのソースを含めて、srcという名前で配置します。以下のような配置になります。

my-src/
  Dockerfile
  src/

次にデータセット配置用のディレクトリを作成します。

mkdir src/wgan/data

データセット、pretrainedモデルの配置

データセット をダウンロードして、上記で作成したsrc/wgan/dataに配置します。次に pretrained model をダウンロードして、 src/wgan/runs に配置します。pretrained modelはzip圧縮されているので解凍し、中の設定ファイルの修正をします。

unzip model_WGAN_LLD-icon-sharp_rc_128.zip
vim model_WGAN_LLD-icon-sharp_rc_128/config.json

"DATA": "LLD-icon-sharp.hdf5" を以下のように修正
↓
"DATA": "data/LLD-icon-sharp.hdf5"

Docker ビルド

Dockerfileのあるディレクトリで、以下のコマンドを実行します。

docker build -t logo-gen .

GPUの確認

コンテナに入ってGPUが認識されているか確認します。

docker run --gpus all -e NVIDIA_DRIVER_CAPABILITIES=all -v $PWD/src:/src -it logo-gen /bin/bash
nvidia-smi

GPUが1つ認識されていることが確認できれば大丈夫です。

画像生成

実行するディレクトリに移動して、ipythonを起動します。

cd src/wgan
ipython

以下のコマンドで画像生成を実行します。

import tensorflow as tf
import numpy as np
import vector
from logo_wgan import WGAN

session = tf.Session()
wgan = WGAN(session, load_config='LLD-icon-sharp_rc_128')
vec = vector.Vector(wgan)
vec.show_random(save="./result.png")

result.png に以下のようなロゴ画像群が出力されていれば成功です。(以下の画像と同じ画像は出力されません。)

まとめ

  • EC2のGPUインスタンスを使ってロゴ生成ができた。
  • 今回出力されたロゴ画像群は、品質的にそのままロゴとして使えるわけではなさそう。
  • ただし、シェイプや色、その他の特徴をなめらかに変化させることが可能なモデルなので、調整を行うことで、使えるロゴが出力できる可能性はありそう。

参考

https://github.com/alex-sage/logo-gen

【SEO効果あり!?】記事執筆の際に参考になる文字数のこと

0

◆はじめに

 記事をいざ書くときにどうやって書こうか考えたときに
 スピリッツ元気玉Q&Aを確認したところ

 Q:どんな記事を書けばいいのか?
 A:内容、文字数、言語、すべて自由です。

 と、書いてあるのを拝見しました。
 「とはいいつつ文字数とか決めてくれた方が」と思ったり
 「あんまり文章を書くのが得意じゃないから」と思ったり
 そういった方もいらっしゃるのではないでしょうか。

 かくいう自分もそう思った中で、記事を書こうとしたときに「文字数」について調べていたら
 「文字数」のことだけで記事になりそうだったので方針を変更しました。 
 これから執筆される方の参考になればと思います。

本記事でわかること:記事を書くときにちょっとだけ役立ちそうな「文字数」のこと

◆結局何文字書けばいいの?

 記事を書く際に最適とされる文字数はどれくらいなのでしょうか。
 まず、最適云々関係なく1ページの文字数は600文字以上が目安ともいわれています。 
 その中で、人を集める記事の目安は1,000~2,000文字といわれているようです。
 記事読み慣れていない人からしたら1,000文字!2,000文字!と言われたところで
 どのくらいの長さかわかりませんね。頭の片隅にでも入れておきましょう…。

 (ちなみに人間は1分間に500文字、早い人で1,500文字を読むことができるそうです。)
 
 と、言われているものの無理に2,000文字にしたらいいわけではないのが難しいところです。
 記事に人を集めるには、あくまでコンテンツとしての充実が重要になります。
 500文字で終わって気持ちの良い記事を、無理に2,000文字にしてはいけないということですね。
 鮮度が大事な情報記事などは、パッと読める長さが重要といえます。
 
 なお、SEOにおける観点では、Googleは文字数は関係ないと表明しています。
 SEO関連のサイトにも「SEOと文字数には因果関係はありません」と書いてあります。
 しかし、SEO上位のページをたくさん調べた方の調査結果は、
 「SEO順位の高い記事は、ある程度の文字数を有していることは確かである」とのことです。
 人々が役立つ充実したコンテンツを執筆したらそれなりの文字数になっているのでしょう。

 

 それでも文字数に縛られたい方は、600、1,000、2,000などの文字数を目安に執筆しましょう。
 思わぬSEO効果があるかもしれません。

◆タイトルの文字数の目安は?

 本文の次はタイトルの文字数を考えましょう。
 一般的にSEOにおけるタイトルタグは30文字前後がよいとされています。
 これは検索結果が表示されたときに、そこまでであれば省略されずに表示されるからです。
 記事ページ自体のSEO順位で上位を狙うには、参考にしてもいいかもしれません。

 もう一つの考え方に「一度に人間が認識できる文字数」というものがあります。
 これもまた個人差はあるでしょうが、12~13文字といわれています。
 アピリッツ魂のサイトを回遊してる人に瞬時に見つけて興味を惹いてもらうためには
 この数字を気にしてもいいかもしれません。
 Yahoo!のニュースタイトルなどにもこの考え方が使われており、
 興味関心を引きクリックしてもらいやすくする工夫がみられます。
 この文字数の話は、プレゼンに使用するスライドでも同じことが言えます。
 1スライド、1テーマ、12文字のスライドを作る方もいるかもしれません。

 そのほか新聞の見出しは9~11文字、
 TV番組のテロップは1行15字以内を意識しているとの情報もありました。

 今ではYouTubeの方が主流でしょうか。サムネイルや字幕にも活かせそうですね。
 やや脱線しましたが、記事タイトルは簡潔で伝わりやすいことであればいいでしょう。
 読み手が必要な情報がコンパクトに収まっていることが美しく、伝わりやすいです。

◆1文の文字数って気にしたことある?

 本文やタイトルの話をしてきましたが、次はもっと細かい話です。
 文章を書き連ねていく中で、気づかないうちに1文がながーくなってしまっていたり
 短い文の繰り返しになってしまったりしていることがありませんか?
 平均的に、1文は平均40文字ほどが良いと言われています。
 また、文章内容や、出てくる単語にもよりますが
 60字を超えると読みづらくなってしまう傾向があるらしいです。
 数字がたくさん出てきたり、タイの首都の正式名称を書かなければいけない場合は
 60文字なんか気にしていられませんが…

◆まとめ

 ①本文②タイトル③1文
 今回は、こちらの3つについて、ちょっとだけSEOに効果があるかもしれない、
 ちょっとだけユーザーが読みやすくなるかもしれない文字数のことを書きました。
 あくまで参考です、ご了承ください。
 そういえば、目安で出てきた2,000文字ってどれぐらいなんでしょうか。


 本記事は約、2,000文字です。

意外と知られていない?アピリッツのクリスマスツリー担当に密着!

0

今年もいよいよ寒くなってきましたね!アピリッツでは会社の雰囲気をより良くするために、クリスマスの時期が近づくと毎年クリスマスツリーを飾ります。

また、内定者同士が知り合うきっかけ作りを目的として毎年内定者インターンのみなさんに各フロアのクリスマスツリーの飾り付けをお願いしています。今年も 続々とインターン生が会社に来てくれています!本日はそのクリスマスツリー作りの当日の様子をお届けします。

さっそく、まずはなにも飾りのない木から組み立てていきます!

どんなツリーになるか楽しみですね!
徐々にできあがってきました……!

飾りつけをしているうちに、いつの間にかチーム戦になり「どこのチームのツリーが5F受付に飾られるか!?」という勝負に……

仕上げに取り掛かる様子。

クリスマスソングをBGMにかけながら皆で協力してできあがりました!

5階の受付に飾られたツリーはコチラ!受付がとても華やかになりました。せっかくなので他のツリーが気になる方は2階、3階も是非のぞいてみてください!インターン生の皆さんありがとうございました!

最後に記念撮影!

今年もあと少しですが2020年ラストスパート頑張りましょう!

「自分だけの物語で感動を生み出そう」夢中になれる物語の作り方講座

0

はじめに

アピリッツが日々開発しているようなゲームを作る上でも、面白いストーリーというのは素晴らしい強みになります。
もし面白いストーリーが自分で考えられたら、とても楽しそうですし、役立ちそうですよね。

でも、読者のみなさんの中に多いのは、こんなタイプかなと思います。

・面白いストーリーとつまらないストーリーがある事はたくさん体験してきている
・ただどういうものが面白いストーリーなのかは、うまく説明できない
・どうすれば面白いストーリーが書けるのかは、もっとよく分からない。

実は自分はアピリッツにプランナーとして入社する前、ライトノベルの小説家として活動しているキャリアがありました。
今回はその経験も活かして、上記のようなタイプの方々を主な対象に、
自分が思う「面白いストーリーの考え方」について話していきたいと思います。

今回のテーマはこちらです。

「いかにして夢中になれるストーリーを構築していくか」

これを、主にエンターテイメントのストーリーを対象にして書いていきます。

夢中になれるストーリーに必要なもの

夢中になれるストーリーとはどういうストーリーでしょうか?
これについては実に色々な考え方があるのですが、自分は一つの答えとして以下を信頼しています。

夢中になれるストーリー:「主人公の間違いが正される事を通じて、人生の隠された性質(テーマ)が体感できる物語」

これが、物語の書き手が最初に目指すべき地平だと、自分は考えています。
もちろん、他にも読み手を夢中にさせるのを加速させていく要素は存在します。
たとえば物語に「謎」や「驚き」といった要素を加えていく事(情報のコントロール)で、読者をより熱中させていく事ができます。
また物語から得られる感情が、大きくアップダウンのカーブを描いている事(感情のコントロール)も、読者をのめり込ませる力を発揮します。

ですが、これら情報のコントロールや感情のコントロールは、実は一番本質的な面白さではないと自分は考えています。

では、物語を読んで一番本質的な面白さを感じる瞬間とは何なのか。


それは「カタルシス」を感じた瞬間です。

カタルシスとは、「精神の浄化作用」の事であり、心の中に貯まっていた鬱積した感情が、物語を見る事によって解放され、それによって強い快感を得る事を指します。

このカタルシスを感じさせる事が出来たら、ストーリーとしては合格点が与えられるといっていいでしょう。
このカタルシスを感じさせるための一つの型となるのが、先ほどの「主人公の間違いが正される事を通じて、人生の隠された性質(テーマ)が体感できる物語」という表現です。

特に重要なのがクライマックスです。
上記の型におけるクライマックスでは、自分の間違いに気づいた主人公が、間違いによって起こっていた問題を乗り越えるため、自分の力の限りを尽くします。
その際に主人公の感情が爆発し、全力を超える全力を尽くして、ついに何かを乗り越える。その瞬間、観客は強いカタルシスを感じる事が出来るのです。

なぜカタルシスを感じるのかを説明します。
ここで主人公が抱いていた間違いというのは、多くの読み手にとっても心当たりがある間違いが、書き手によって選ばれている事が多いです。
そんな、読み手にとっても仇敵である、あるいは仇敵であった間違いに、主人公が最後にはちゃんと気づいて、何かの問題を乗り越える。
そんな姿を見ると、観客は人生の隠された性質が体感でき、それが自分にとっても関係がある間違いだからこそ、観客自身の精神も浄化されるのです。
これこそ、上記の型の物語がカタルシスを感じる理由です。

確かに、情報のコントロール、感情のコントロールを行う事で、物語の面白さをさらに増す事はできます。


ですが、あくまでゴールは観客にカタルシスを感じさせる事。
そう考えた方が、いい物語に仕上がる可能性は高いと自分は感じています。

具体的なストーリー構築手順

さて、では具体的にどうすればストーリーが書いていくのでしょうか。

ここでは、以下のような手法を採用していきます。

1.ログライン集め・選択
2.ログラインを膨らませてあらすじに・テーマ決め
3.キャラクター設定・世界設定を簡潔に考える
4.あらすじを膨らませてプロットに
5.キャラクター設定・世界設定をしっかりと書く
6.本文を書く

1.ログライン集め・選択

最初にやる事は、いわゆるログラインをたくさん作る事です。
ログラインというのは、物語のアイデアを、ツイッターのつぶやき程度の文字数で表現したものです。

例えば、桃太郎だったら以下のような感じです。
「川から桃とともに流れてきた桃太郎が、きびだんごで猿、鳥、犬を仲間にし、鬼を退治する物語」

こういうものをいくつもいくつも考えます。

ここでいきなり目新しい物語の種がいくつも思いつく人は、才能がある人だと思います。
ただ思いつかなくても面白いストーリーを書く事は全然可能です。

・アイデアの浮かべ方

アイデアというのはそもそも組み合わせの事です。
自分の好きな物語の要素、自分が現実で感情を動かされたものなどを、たくさん紙に書いて、その組み合わせを試して、アイデアを着想していきましょう。

それから、それらを検討していきます。

検討過程で考えるのは以下のような事です。

1.自分が強く興味を持てる事であるか、自分に密接にかかわったテーマを含んでいるかを確かめる
2.そのログラインを実際にもう少し長いあらすじに発展させてみて、可能性を見る
3.そのログラインをストーリーにする上で、何が問題になるのか、何が分からないままなのかを考える

この工程で一つ「これだ!」というログラインが決まったら、次に、それを1000文字前後のあらすじに発展させるのですが、それと並行してテーマを決めます。

2.ログラインを膨らませてあらすじに

さて、ログラインからあらすじを作りましょう。
あらすじは、起承転結を意識して作ります。起承転結にはそれぞれポイントがあります。

・起承転結のポイント

起では「主人公が間違えている事をうっすら描きつつ、主人公に目的を与える」というのを行います。
承では「主人公が目的に向かいながら間違え続ける→間違えのせいで事件が起こって、流れが変わる→主人公が現実を知り、新たな認識を得る」という流れを描きます。
転では「クライマックスに向けて読み手を驚かせつつ展開を盛り上げて、主人公が全力を出さないと勝てない壁との闘いに向かう」という形で結の準備をします。
結では「主人公が全力を出す過程で感情が盛り上がっていき、全力を超える全力を出してついに間違いを正し、観客にカタルシスを与える」という形で綺麗に終わります。

これらを、
起:200文字
承:400文字
転:200文字
結:200文字
くらいを目安に書いていきます。

さらに、この起承転結で主人公が間違いを正す過程で、観客は「今まで知らなかった人生の性質」を体感します。
それは「主人公の間違いが間違いであるという事の自己発見」とも言い換えられます。
ここで描かれている人生の性質を、今回は「テーマ」と定義します。
このテーマを、自分の考えた話に合った形で発見してあげましょう。

3.キャラクター設定・世界設定を簡潔に考える

ここで、キャラクターや世界の設定を本格的に考え始めます。これを考えると、しばしば前の段階のあらすじ・テーマが変わったりしますが、全く問題ありません。
クリエイティブな仕事というのは、ガチガチに順番に作っていくものではなく、フィードバックを受けて行ったり来たりしながら進んでいく方が、よりクオリティが高いものに仕上がりやすいからです。

キャラクターの設定、世界の設定にはそれぞれポイントがあります。

・キャラクターの設定のポイント

キャラクターは、バラバラに一人一人思いつくのではなく、メインキャラクター全員をセットで考えていく方が、物語にまとまりが出ていき、一貫してテーマ、つまり「人生の性質」を表現できます。

まず、キャラクターがストーリーでテーマに対して果たす役割を考えていきます。
理想は、それぞれのメインキャラクターが、同じテーマに対して異なるやり方でアプローチしている形です。
そして、それぞれのキャラクターに対して、何を間違えていて、どのように間違いに気づいて(あるいはどのように間違いに気づかず)、どのように変わるのかを設定していきます。
このメインキャラクターはライバルとか敵対者などと呼ばれる、主人公と対立するキャラクターを含んでいるべきです。
そしてこの敵役も、テーマを違った形で反映していたりすると、味わい深いストーリーになりやすいです。

・世界の設定のポイント

まず世界の設定の変化は、主人公の変化と対応している事が望ましいです。
ただし、単純に主人公が幸せになるから世界も幸せな雰囲気になればいいというわけではなく、主人公が死んだおかげで世界は幸せに包まれた、とかそういう形でも構いません。

また、世界設定は、「テーマをどのように描くか」という事を突き詰めていった結果生まれる形が望ましいです。
また、これを考える上では「環境、人間、技術」というフレームワークで、3つをそれぞれ組み合わせて考えていく形がいいでしょう。

例を一つ考えるとするなら、以下のような感じです。実際はそれぞれをもっと長く書き込んでいきます。
環境:氷でできた森
人間:イヌイット風の文化の魔法使いたちが少数で暮らしている
技術:氷でできた森から魔力を汲み出す装置で、熱を生み出せる

こんなセットを一欠片として、この欠片をいくつも生み出して、それらの間の関係性を構造化していきます。
いわゆるキャラクター間相関図みたいな形で、世界の欠片同士の関係性を図にするのです。
この欠片には人間が含まれるので、前の段階で考えたキャラクター設定やあらすじにも影響する事でしょう。
それらを上手くフィードバックして整えたら、次に進みます。

4.あらすじを膨らませてプロットに

あらすじを膨らませて、個々の出来事を順番に書いたプロットを書いていきます。
プロットを考える上でも、やはりポイントはあります。

・プロットのポイント

「どの出来事を取り除いても、全体が台無しになるように作る」という名言のようなものがシナリオ界にはあります。
これはつまり、重要でない出来事を極限まで省く事が大事だという話です。

また、個々の出来事がバラバラにあるのは望ましくありません。
因果関係で結ばれた出来事だけで構成していきます。
さらに、それでいて、プロットは自然な、リアルなものでないといけません。
作者の都合で有り得ない展開ばかり繰り返されるようなものは避けるべきです。

キャラクターが意志を持って自然とそう動いていくように誘導していく必要があります。

これらはかなり難しいようにも思えます。
実際難しいです。

という事で、これを目標とはしつつ、最初は自分なりに出来事を並べる所から始めるのがいいでしょう。
逆の事を言うようですが、物語は少しくらい寄り道しているくらいが、余裕があって面白かったりする場合もあります。
もちろんその寄り道にも意味があった方がいいですが。

ここでの結論としては、まずは自分の感性を信じて出来事を並べていき、それから上記の注意に従い、論理的に調整していきましょう。
自分は、ここでの並び替えを簡単に行うため、エクセルのセルに出来事を書いていくスタイルでプロットを進めたりしていました。

5.キャラクター設定・世界設定をしっかりと書く

プロットを書くと、色々キャラクター設定・世界設定に変化が出たり、詳細が決まってきたりします。そういった事柄を、どんどん自分の設定に反映させていきましょう。

6.本文を書く

ついに本文を書きます。
ここは、自分が書きたい物語がマンガなのか小説なのかゲームシナリオなのか、といった所でだいぶ書き方が変わってくる部分もあるので、
詳しくは興味があるジャンルの専門の本を探して読んでもらう形に任せたいと思います。

一つアドバイスをするとしたら、本文をある程度まとまって書いたら、必ず見直しを入れましょう。

これは極めて重要で、バランスが悪くないか、書きたい事が書けているか、内容や文章の間違いや食い違いはないかなど、無数にチェック項目があります。
何度も自分で読み直して、気づいた事をどんどん直していきましょう。

最後に

長々とハウツーのような事を書いてきましたが、正直言って、この世界は「面白いものを書いたもの勝ち」です。
いくらやり方が分かっていても書かなければ意味がないし、やり方が理解できてなくても、とりあえず書き続けていれば、だんだんいい感じに書けるようになったりします。

また、あくまで自分の感想になりますが、感覚の赴くがままに筆を走らせるのは、慣れてくるととても楽しいです。

という事で、陳腐にも思える言葉ですが、「習うより慣れろ」です。
少しでも興味があったら、上記は参考程度に、自分なりのやり方でストーリーを作ってみましょう。
一人でも多くのみなさんが、実際にストーリーを作ってみて、ストーリーを作る楽しさに目覚められるといいなと考えて、自分はこの記事を書きました。

よければ読者のみなさんも、ストーリーづくりにチャレンジしてみてはいかがでしょうか?

そして、さらにそのストーリーをゲームにしてみたいと強く思ったとき、このアピリッツの門戸をくぐってみるのも、面白いかもしれません。

ではでは、お読みいただき有難うございました。

強化学習の基礎

0

AI技術を学ぶ上で理解必須の強化学習の基礎的な内容を数式を使わずに簡潔に説明します。

  • AIに興味がある人
  • 強化学習の基礎的な仕組みを知りたい

という人向けの記事です。

そもそも強化学習とは?

ある環境でエージェントが行動を選択し環境を変化させ、その状態を確認し 最終的に報酬が最も多く得られるような方策を学習します。
まずは単語の意味から説明していきます。

そして今回はイメージがつきやすいように自社ゲームのゴエティアクロスを例に説明します。
その前にゴエティアクロスの説明を簡単にするとプレイヤー(魔導師)と魔神と呼ばれるキャラクター達が協力して敵を倒すゲームです。
魔神にはスキルやレベルがあり、戦闘時は前衛、後衛などの編成を考えながら戦っていきます。
この記事はゲーム紹介の記事ではないので詳しい説明は省きます。

環境

今回はこのゴエティアクロスそのものが環境です。

エージェント

今回はプレイヤー(魔導士)がエージェントになります。

状態

魔神達のHP,レベル,コスト,などです。

行動

ゴエティアクロスでは基本的に敵との戦闘はオートで進行するので出撃させる魔神を変える、レベルをあげる、セットしてるスキルを変更するなどが行動になります。
今回は魔神の編成を変えるだけにします。

報酬

敵を倒す、レアアイテムを取る、短時間でクリアするなどが報酬にあたります。
環境によってはマイナスの報酬もあります。
例えば敵から受けたダメージが大きければマイナスの報酬を与えるなどです。
今回は分かりやすく敵に与えたダメージが前回より多ければ報酬を 少なければマイナスの報酬を与えます。

方策(ポリシー)

方策とは貰える報酬を最大化するために行動ルールです。
今回は敵に与えるダメージを増やすにはどのように編成を変えるべきか?というのが方策になります。

基本的な流れ

単語の意味が一通り分かったところで実際に学習の流れを説明していきます。
強化学習で学習をする際にはゴールが設定されます。
今回はこの深淵の森の受注できる全てのクエストクリアをゴールとします。

エピソード1

環境 水霊、火霊討伐

#01 行動

水霊、火霊討伐から開始します。
エージェントが方策を元に行動。
1回目は敵と戦闘をしていないので編成もランダムで組まれます。

#02 環境の変化

戦闘が終了しました。
これにより現在の環境が
水霊、火霊討伐 → 火霊、氷翼竜討伐に変わりました。

#03 状態の確認

与えたダメージ5828

戦闘したことによってHPなどが減っています。
エージェントはこの時点の与えたダメージと残りHPを確認し前回の戦闘より与えたダメージが多ければ報酬が与えられます。
しかし、逆に前回より与えたダメージが前回より少なければマイナスの報酬が与えられます。

#04 方策の更新

この与えられた報酬を使って方策を更新します。
1回目は前回与えたダメージとの比較ができないので報酬はなしです。
なので方策の更新も行いません。
このまま残りのクエストも進めていきます。

環境 火霊、氷翼竜討伐

与えたダメージ7377
環境 火霊、氷翼竜討伐 → 氷翼竜、白蛇討伐
報酬 なし
方策の更新 なし

環境 氷翼竜、白蛇討伐

与えたダメージ6744
環境 火霊、氷翼竜討伐 → クリア
報酬 なし
方策の更新 なし

ゴール設定は深淵の森の全てのクエストクリアなのでここで1回目の学習は終了です。
この行動開始からゴールまで1ステップをエピソードと言います。
まずはエピソード1終了です。

エピソード2

環境 水霊、火霊討伐

#01 行動

エピソード1と同様に編成はランダムで組まれます。

#02 環境の変化

ここもエピソード1と同じです。

#03 状態の確認

与えたダメージ6096

エピソード1の5828ダメージより多いので報酬を与えます。
エージェントが与えたダメージと残りHPと報酬を確認しているのはエピソード1と同じです。

#04 方策の更新

エピソード2では報酬が貰えたので方策を更新します。
環境 水霊、火霊討伐では今回の編成の方がより多くダメージを与えたので次回の戦闘時ではこの編成が選ばれるように方策を更新します。
このまま残りのクエストも進めていきます。

以降から#02 環境の変化は同じ流れなので省略します。

【環境 火霊、氷翼竜討伐】

#01 行動

#03 状態の確認

与えたダメージ6998


エピソード1では7377ダメージだったので与えたダメージが少なくなってしまいました。
この場合はペナルティとしてマイナスの報酬を与えます。

#04 方策の更新

この編成では与えたダメージが少なくなってしまったので選ばれないように方策を更新します。

環境 氷翼竜、白蛇討伐

#01 行動

#03 状態の確認

与えたダメージ8195

エピソード1の6744より多いので報酬を与えます。

#04 方策の更新

この編成が選ばれるように方策を更新します。
ここでクエストは全てクリアしたのでエピソード2は終了です。
次からはエピソード3です。

エピソード3

【環境 水霊、火霊討伐】

#01 行動

今まではどの編成を組めばより多くのダメージを与えるか分からなかったので
編成はランダムで選ばれていましたが今回からは方策を参考に編成を組めそうです。
水霊、火霊討伐ではエピソード2の編成の方がより多くのダメージを与えることが分かっているのでエピソード2の編成が選ばれました。

#03 状態の確認

与えたダメージ量はエピソード2と同じなので報酬はありません。

#04 方策の更新

報酬がなかったので方策の更新もなしです。

環境 火霊、氷翼竜討伐

#01 行動

エピソード2の編成では与えたダメージが少なくなってしまったのでエピソード1の編成が選ばれました。

#03 状態の確認

与えたダメージ量はエピソード2より多いので報酬を与えます。

#04 方策の更新

この編成が選ばれるように方策を更新します。

環境 氷翼竜、白蛇討伐

#01 行動

エピソード2の編成の方が選ばれました。
#02~#04は環境 水霊、火霊討伐と同じ流れです。
これでエピソード3は終了です。

エピソード4以降でもこれを繰り返し最終的にはどの編成が最もダメージを与える事が出来るか学習していきます。
実際の強化学習では、何もしないと特定の編成ばかり選ばれて他の編成がどのくらいダメージを与えるか試さなくなるので、一定の確率で方策を無視してランダムで行動するというテクニックが使われます。

関連:ゴエティアクロス

GA Next Generation : Google Analytics4

0

In October, Google announced the release of Google Analytics’ new generation: Google Analytics 4. Previously known as “App+Web Property” in its beta version. With this new generation, Google Analytics focused more into the customer journey, so that businesses understand better needs and behavior of their customers.

Why Google Analytics 4?

You might have been confused by why the new generation of Google Analytics was called Google Analytics 4 (GA4). GA4 is the result of the 15 years of Google Analytics’ development, different way of implementation and major changes.

  • 1st generation: Urchin tag (when Google buy Urchin company, urchin.js)
  • 2nd generation: Traditional Google Analytics, the base of the current GA (ga.js)
  • 3rd generation: Universal Analytics, start of cross domain tracking (analytics.js and gtag.js)
  • 4th generation: New Google Analytics 4, with improve analysis and new property default model (gtag.js)

What is Google Analytics 4?

Google new generation analytics is based on the property introduced in beta version last year called App+Web property. With the GA4, the app+web property becomes the default property setting.

The App+Web property is a property enabling the measurement of website, app or both. In last years, mobile users have increased, and the data generated by mobile users cannot be overlooked anymore, while keeping in mind that users might have different devices (PC, tablet…). In Universal Analytics, making data collected from website and app working together was difficult. When the web activity was measured on session-based, app data (Firebase) was measured using an event-based model. With App+Web property and now GA4, both data are unified on event-based model enabling a better and more accurate analysis.

What the differences between Universal Analytics and Google Analytics 4?

1/ Event-based model

From a session-based measurement with UA, GA4 is switching to an event model.

What does it mean? In UA, data was collected into session. During a session (given time frame), Analytics stored user interactions as hits (pageviews, events, eCommerce, social interactions). In GA4, every interaction on the website or app are events. From events, you get to know what is happening in your platforms (pageviews, user actions, clicks, conversion, system events).

To be sure that every tiny or big interactions are collected, GA4 has 3 different types of events:

Events type in GA4

  • Automatically collected events (pageviews, clicks, inApp_purchase)
    • Enhanced measurement for Web data stream
    • Automatic
  • Recommended events:
    • for all website/app : login, purchase
    • specific for your activity (game : level_up, level_start)
  • Customized events (to use when you cannot find any automatic or recommended events that match your needs).

With events, Analytics collects bit of information to specify the event called parameters (3 types as well: automatic, recommended, or customized). Website and app having the same measurement enable you to better understand how users engage with your business across devices and platforms, giving you richer insights.

2/ Full cross-device and cross platform

Being able to identify your users during their interactions with your platform, is very important to understand them better and to develop more accurate marketing ways to target them.

Reports in UA were mainly focused on device-ID (browser cookie), which gave an incomplete view of the user, for example you could not know if the same user was using different platforms. Even if other identification means (User-ID and Google signal) were enabled, the data was collected and viewed in different reports, limiting cross device and platform analysis.

In GA4 and by default, the data is processed by using all available identity information possible. First, by using the User-ID, the ID given by your business from authentication/sign-in method; by Google signal, when the user is signed in its google account and allows its data to be shared; then the device-ID. Despite the default use of all available identification, you can choose to focus on device ID only and ignore any other identification.

In GA4, user identification is key to be able to know how your customer engage with your brand across platforms or devices, and the information is integrated to all reports. You can even create audiences around identified users to better target and personalized their customer’s experiences.

What are the merits of GA4?

1/ Better Analysis tools

a/ Reports

Even if the report panel in GA4 looks mostly like UA, you can get news reports and insights from it. In GA4, reports are newly organized to better focus on the key element of your business: the user and its behavior.

After the Home and Realtime reports, giving you major information about what’s going on your website in general or in Realtime (in the last 5 seconds to 30 minutes), you will have access to the newly organized report category called “lifecycle”. The lifecycle reports enable you to focus on your users during the different stage of its interaction with your website or app: introduction, engagement, conversion, and retention.

New reporting (Google Marketing Platform)

User reports will get all the information you need to know better the user itself: its characteristics (age, country, interests) and the technology they are using to access your platforms.

User Report (Google)

Event reports will focus on every interaction that is happening on your platforms and you will be able to quickly choose your most important interactions/events by making them conversions in a click.

Conversions can be selected from your event list

b/ Analysis tools

The newest category on the panel is the analysis tool! In Analysis, you have all bunches of reports to give you better insights about your business and about what you can improve in your marketing and website so your user can have a better experience while on your platforms.

The first tool is Analysis Hub, where you can create, from scratch or using template, your own report to study what you really need. In a dashboard that looks a bit like Data Studio, you can easily select the dimensions and metrics you want and organize them into various and easy to read graphs. You can add, create your own segment, or compare data between different ones just by clicking and selecting the data you want to use. You can then decide to share or download your masterpiece.               

To analysis your data, you can also choose one of the defined techniques:

  • Exploration > dynamic table layout to enable you to select the metrics you need
  • Funnel analysis or Path analysis > insights about how users are moving around your platforms
  • Segment overlap > how your segments relate to each other and enable you to target very specific audience
  • User explorer > help you personalize the user experience by studying a specific group of users
  • Cohort analysis > analyze the behavior of a group over time on your platform

New Analysis tools in GA4

2/ BigQuery and Google Ad’s stronger connection

In GA4, BigQuery can be linked to your account for free! When you wanted to link UA propriety and BigQuery, you needed to have a 360-account meaning you needed to pay the upgrade of your analytics account. In GA4, it is free!

You will be able to export, collect and store your data in the BigQuery cloud and integrated it with other data sources, or move your GA4’s data to other sources you want to use. You will be able to automatically use the data over to BigQuery pushing even further your analysis.

GA4 and Google Ads are also better connected to automatically update audience to match you user behavior: this user bought a product? Great, Google Ad will not show him the ad to push him to convert anymore. No wasted money and no annoyed customers!

3/ To the future: machine learning and User privacy

While you could get insights using machine learning in UA, the new GA4 gave you new insights and predictions features to make your data work for you. Machine learning can now be used to predict outcomes, trend in demand of a specific products, churn rate (percentage of users that will stop using your services in a given time period), potential revenue by identifying specific segment to focus on high value customers.

In future years, marketers will also have to relate less and less on third party data (cookies from other people than the website you are using), implementing GA4 will help you follow this trend closely as Google said it will start using machine learning to fill out incomplete data resulting from this trend.

GA4 makes it also easier to protect user privacy as well as to comply with the main data control regulation (GDPR, for the European countries with strict control about collecting and storing data from European users; CCPA American regulation). GA4 give you better management tools to collect and retain your data, as well as optimizing or limit the use of it in Google Ads.

How does it work?

So technically speaking, how do you set up the GA4? Well, if you are new to Google Analytics, as GA4 is the new default property, you just have to sign up for an account and fill out the main information, and you will automatically be invited to set up the new property.

Setting up Data stream in GA4

As in the app+web property beta version, when setting the new GA4, you will create data stream: web, iOS or Android. The data stream is the container that received your data. You can have up to 50 data streams for the same property, so if you have a website, and both iOS and Android apps, everything can come under the same property.

When creating the data stream, Google will guide you to tag your website or setting up the app via Firebase new project automatically connected to your account. If you are using Google Tag Manager, you will easily be able to select the two different GA4 tags: GA4 settings for the basic set up (included automatic collected events and enhancement events- pre-setup events for web data stream) and GA4 event to set up recommended and custom events and their parameters.

GA4 tags type in GTM
GA4 tags in GTM are connected to the type of event your platforms use

If you are already using Universal Analytics, you can choose to upgrade to a GA4 property by either create a new GA4 property or connecting to an existing one. This upgrade will not change anything in your UA property, and it will continue to collect data that you can analyze as before. After tagging your website or setting up your app for the new GA4 property, it will start collecting data and you are ready to take advantages of its new features. As it will not change anything for your UA property, it will be clever to start your GA4 property as it may become the norm in the future. This way you will also get to explore the new environment and collect data to be able to analyze future trends from your already accumulated data.

docker上のブラウザで画面キャプチャをとる

0

今回やること

docker上にchromium+ruby+capybaraをいれてキャプチャをとって遊んでみます。
dockerはインストール済みとします。

ソースコードの用意

Dockerfile

FROM ruby:2.7.1-alpine3.12
RUN apk add --update --no-cache \
        g++ \
        libxslt-dev \
        make \
        unzip \
        chromium \
        ttf-freefont \
        chromium-chromedriver

# 日本語フォント
RUN mkdir /noto
ADD https://noto-website.storage.googleapis.com/pkgs/NotoSansCJKjp-hinted.zip /noto
WORKDIR /noto
RUN unzip NotoSansCJKjp-hinted.zip && \
    mkdir -p /usr/share/fonts/noto && \
    cp *.otf /usr/share/fonts/noto && \
    chmod 644 -R /usr/share/fonts/noto/ && \
    fc-cache -fv && \
    rm -rf /noto/*

# 出力用ディレクトリ
RUN mkdir /dist

WORKDIR /app
COPY . /app
RUN bundle config build.nokogiri --use-system-libraries
RUN bundle install
RUN apk del \
        g++ \
        libxslt-dev \
        make \
        unzip
ENTRYPOINT ["bundle", "exec", "ruby", "capture.rb"]

Gemfile

source "https://rubygems.org"

git_source(:github) {|repo_name| "https://github.com/#{repo_name}" }

gem "selenium-webdriver", "~> 3.0"
gem "capybara", "~> 3.0"

capture.rb

Bundler.require

base_args = %w{--headless --no-sandbox --disable-gpu --disable-extensions --disable-dev-shm-usage --disable-infobars}
Capybara.register_driver :chrome do |app|
  args = base_args.dup << "--window-size=1900,1080"
  driver = Capybara::Selenium::Driver.new(
    app,
    browser: :chrome,
    desired_capabilities: Selenium::WebDriver::Remote::Capabilities.chrome(
      "chromeOptions" => {
        'args' => args,
        'w3c' => false #selenium-webdriver 3系の場合これを付けないとエラーになる
      }
    )
  )
end
Capybara.default_driver = :chrome
browser = Capybara::Session.new(:chrome)
browser.visit ARGV[0]
browser.save_screenshot '/dist/capture.png'

ビルド

docker build -t chrome-capture .

使い方

docker run --rm -v $PWD:/dist chrome-capture https://appirits.com

コマンドを実行したディレクトリにcapture.pngという画像ファイルが作成されて
キャプチャ画像が保存されていれば成功です。

ポートフォリオの作り方・考え方

0

こんにちは。デジタルビジネス部webデザイナーのIです。最近アピリッツへ中途入社させていただきました。
突然ですが、皆さんはポートフォリオ作りは得意でしょうか?周りの方に聞いてもあんまり…といった反応が多いように感じます。
私自身も学生時代に作ったポートフォリオは「作品を並べただけ」と言われてしまい、どう改善をしたら良いのか苦戦しました…

つい苦手に感じて後回ししてしまいがちなポートフォリオですが、新卒の方ですともう半年もしない内に就活が始まるので余裕を持って後悔のないように準備を進められるよう、今回はポートフォリオの作り方・考え方についてご紹介させていただきます。

そもそもポートフォリオって何?

・ポートフォリオ(英語:Portfolio)とは、書類を運ぶ平らなケースの意。
・紙入れ、札入れを意味するイタリア語: portafoglio が語源。

就活においては「作品集」、デザイナー自身を知ってもらうために重要なものです。

作品掲載について 

■作品写真:見せ方は適切か
サイトであればPCやスマホの画面に、ポスターであれば街頭広告に画像を合わせて実際その制作物が使用されている様子が想像できるように加工して載せていました。

■概要:どういった課題があってどのように解決したのか
どういうプロセスで制作を行ったかを書く事で、デザイン的思考ができているかなど自身の考え方について知ってもらう事ができます。

■使用ツール:持っているスキルと会社の業務内容はマッチしているのか
一口にデザイナーと言っても使用ツールは様々です。何を使えるのかを示す事で相手に理解を深めてもらいます。

■制作時間:仕事として制作が出来るのか
どんなにクオリティの高い作品でも、完成するまでに何年何十年とかかってしまうと仕事としては成り立ちません。
そのためどれくらいの期間かかるのか、何時間で完成できるのかなど書いておくと親切です。

■担当領域:何をする人・できる人なのか
複数人で動くプロジェクトに参加した時は自分の担当領域を載せましょう。
ディレクターなのかデザイナーなのかエンジニアなのか、何も書いていないと見る側も判断できかねますし、能力理解にズレが生じる可能性もあります。

全体について

■自己紹介
どんなものが好きなのかや今後どうなりたいのかなど、少しでも自身を知ってもらうポイントを作ります。
面接の時に触れられなくても、読んでもらえる可能性はあるのでチャンスは盛り込みましょう。

■目次
相手は面接に関する書類に目を通す他に通常の業務も抱えている事がほとんどです。
どこに何があるのか、見て欲しいものはどれなのか、案内ができると良いです。

■掲載順
どの業種・会社を受けるのかによって変わります。
私はwebデザイナーとしての応募だったので、制作したサイトの割合を一番多く、手前にしました。
また、こういう事もできますよというアピールをするためにポスターや冊子、果てはデッサンまで後ろの方に入れていました。※バランスには気をつけましょう。

■配慮は足りているか
列は揃っているか、使用フォントや文字の大きさ、色はページ毎にバラバラになっていないかなど。気を付ける点はたくさんあります。
ポートフォリオは全部で一つの制作物という意識を持って、一貫性のある制作をする事が大切です。

■色々な人に確認してもらう
ポートフォリオを見るのはデザイナーだけではないので、色々な人にも見てもらいましょう。
これは就活だけでなくずっと続く課題ですが、多くの人にわかりやすい見せ方を考える事が大切です。

レイアウトはどうしたら良いのか

悩んでいる方はまずポートフォリオが作れるサービスやテンプレートなどを参考にしたり、お気に入りの雑誌などからどう見せると魅力的に見えるのかを考えたりすると良いです。
私は作品が縦でも横でも入れられるような汎用性の高いレイアウトを作ってから、画像や情報を流し込んでいました。

紙とデータはどっちが良いのか

受ける会社によって変わりますが、どちらもあると安心です。
データだと、クラッシュした。ネット環境が悪かった。
紙だと、持ってきたポートフォリオを電車に置き忘れた。不慮の事故で折れた。など…
どのようなトラブルに見舞われるかわかりませんので、どちらも用意して出せるようにするのをおすすめします。

まとめ

改めてポートフォリオを制作した際、下記の2点を意識しました。

1.見る方への分かりやすさと思いやり
2.業種・会社に合わせて何ができるのかを示す

ポートフォリオ作りの考え方はその時だけでなく、日々の業務にも繋がる所が多くあります。
気負いすぎず、まずは1つの作品作りだと思って気軽に取り組んでみてくださいね。

マイグレーション後もDX推進のお付き合いを。クラウドインテグレーション部設立記念、西脇学 × 剣持大介 対談

0

アピリッツは2020年11月1日に「クラウドインテグレーション部」を新設しました。「DX推進のためのクラウドインテグレーション」を謳うこちらの部署の設立背景や展望について執行役員の西脇学とクラウドインテグレーション部 部長の剣持大介がお話します。(2020年10月 取材)

サーバは社員の足元に転がっているほうが安心?

執行役員 西脇学(以下、西脇):クラウドインテグレーション部のお話の前に、雑談がてらちょっと教えてもらいたいのですが、今、クラウド技術の市場はどんな感じですか?

クラウドインテグレーション部 部長 剣持大介(以下、剣持):オンプレミス環境からクラウド環境への移行(=マイグレーション)のニーズが高いです。ただ、監査やセキュリティの観点から二の足を踏んでいらっしゃる企業様も多くいらっしゃいます。

西脇:ああ! わかります! 会社の規模を問わず「サーバが社内のどこかにあるのはOK。でもクラウドはダメです」という企業様は昔から少なくないんですよね。

そういった方に「なぜ社内にサーバがあるのは大丈夫なのですか?」とお尋ねすると、「みんなが見えるところにあるから安心」という答えをいただくんです。これが昔からすごく不思議で。

僕としては、セキュリティの観点から言うと、会社のどこかや担当者の足元でサーバがゴロンと転がってるほうが危ういんじゃないかなと思うわけです。

剣持:一人で何もかも出来てしまうリスクはありますね。

西脇:でしょ? 誰でもさわれちゃうし、目の前にサーバの端末があったら何がどこまでできるかわかっちゃう。だから、クラウドのようにそれぞれの担当者の「できること」を限った状態のほうが、安全性の思想としてはより堅牢だと思いますね

“三菱ショック”から潮目が変わった

―― クラウドへの抵抗もありつつ、それでも新規のお話は全案件クラウドです。やはり流れが変わりつつあるのでしょうか。

西脇:はい。ゲームチェンジがおきたなと肌で感じたのは2017年1月の“三菱ショック”ですね。これは三菱UFJフィナンシャル・グループがAWS(Amazon Web Service)を採用した、って話なんですが、当時国内の、とくに歴史ある企業に衝撃が走ったわけです。

三菱ショック以来「AWSに全力で行きます!」という流れができました。すぐさま“クラウドユーザー向けサイバーリスク保険”が登場したり。

剣持:さらにSIPサーバやVoIP系の機能がクラウド上で使えるようになり、オンプレミスでなくてはならない要因が減りました。これによってAWSに移行しても大丈夫という流れもできたと感じています。

なつかしの三菱ショックを語る西脇さんと剣持さん。

DXの波で「AWSに詳しいからアピリッツに発注する」となった

―― 「クラウドインテグレーション部」を設立したのもそういった流れをうけて、ということでしょうか。いつごろ「部署を作るぞ!」となったのでしょう。

西脇:もともとクラウド導入事業をアピリッツはやってきたのですが、それは、クラウドのみを扱う専門業者としてではなく、アプリケーションを動かすためのものでした。

剣持:「アプリケーションのアピリッツ」、ですからね。

西脇:そうそう(笑)アプリを作って動かすためには土台が必要で、インフラとしてAWSも当然欠かせないよね、技術を磨かないとね、というスタンスで長年やってきました。

ですから、オンプレミス環境からAWSへの移行は、アプリケーションの開発・移行とセットだったんです。大手メディアサイトさんの大掛かりな移行ですとか。

最新のマイグレーションの手法に則って仕事をするので、クラウド導入の経験値もたまります。

やがて「アプリケーションに加えて、とにかくAWSに詳しい人が必要」というご要望を頂戴することが増えました。「アピリッツにはAWSに詳しいエンジニアがいるから」という理由で仕事が発生するんです。

なので、剣持さんや浅田さん(※2020 APN AWS Top Engineers)などベテランのエンジニアたちはそれらのプロジェクトに関わってきました。たとえばAWSの新機能を使う時は浅田さんに必ず入ってもらったり、みんなで解決してきました。

剣持:この流れは2018年頃から予兆があって、2019年には需要の高さがはっきりしました。

西脇:そうだね。で、2020年のDX推進のビッグウェーブが来たわけです。経産省のDXレポートの影響力は大きかった。毎日いろんなDX関連のニュースが出てますよね。補助金が出ますよ、関連銘柄がストップ高ですよ、とか。

結局、ずっとインハウスで抱え込んでいたものをクラウドに載せないと、もう自分たちのビジネスは世の中の変化の速度についていけない、ヤバい、って認識され始めたんですよね。

AWS、GCP、あらゆるクラウド技術を提案する

―― アピリッツでもDX支援のためのデジタル人材を育成していまよね。

西脇:はい。古くからお付き合いのあるAWSはもちろんのこと、アピリッツはGCP(Google Cloud Platform)のパートナー認定も取得しました。

AWSやGCPはこれからも進化していくはずです。技術に対する投資規模がまるで違うのですから、そこを私たちが活用しない手はありません。勉強を続け、お客様のビジネスにとって最適なものを提案できる状態を常に保つ。そういったことがアピリッツの役目です。

……という経緯で、まずは専門チームをかためて育成もする部署を作ることにしました。やっとクラウドインテグレーション部の話になったね!(笑)

剣持:ゆくゆくは、部にとどまらず「アピリッツ全体の仕事のやりかた自体、クラウドインテグレーションが基本」とお客様からご認知いただけるよう進めたいです。

クラウドインテグレーション部にいてほしい人

―― 西脇さんにお尋ねします。剣持さんを部長に選出した理由は何でしょうか。

西脇:まず、古いシステムを扱える経験値があることです。さらにクラウドの経験値もある。マイグレーションって、いわゆるレガシーなものをクラウドに移す場合だってあります。ですから、若い人たちと古いシステムを紐解いて、最新のクラウド技術と適合させていく舵取りにふさわしい人物だと考えました。

剣持:今、世の中では「最初の一歩のDX」の需要が高い。なので、まずは私が「橋渡し」となって、そこをドンと打ち出していきたいです。

西脇:僕らはマイグレーションをやったあとも、DXを進めるお付き合いがしたいです。まずはDXの入り口として必要なことをご提供して、次にやるべきことに対応できるよう備えるのが、私たちの使命だと考えています。

剣持:アピリッツの強みは「Webアプリケーションをワンストップで」提供できる点です。開発、UX/UIデザイン、コンサル、Webマーケティング、すべてをご提供できるのがモットー。これからは「DXをワンストップで」ですね。

西脇:一方で「すべてをモノリスにアピリッツがやる」というのではなく、お客様のオーダーにあわせて、外部の会社さんと一緒にやっていくことも柔軟に考えます。それって「必要なものを必要なだけ」使えるクラウドサービスと似てますよね。

―― クラウドインテグレーション部をどんなチームにしたいですか?

剣持:いろんなサービスやクラウドや基盤の技術があります。それらを最適な形で組み上げられる レゴブロックのように組み合わせられる部署にしたいです。

ですから、一点に詳しいだけじゃなく、いろんな知識を持ち、それらを組み合わせる想像力のあるエンジニアが理想です。

西脇:そうだね。「最初からスクラッチ開発を前提に設計するんじゃなく、これ使えば解決できるんじゃね?」という閃きで突破する人が必要ですね。「あるならもってくる、なければ作る」ってところもクラウドの思想と近いかもしれません。

「そのままのアナタでいて!」と願っている

―― クラウドインテグレーション部が求める仲間のイメージがつきました。他に求めることはどんなことでしょう。

剣持:西脇さんのように「しゃべれる人」ですね。お客様と共に課題に取り組むわけですから、いろんな人を説得する局面があります。

ですから、単にトークスキルが高くて陽気、という意味では当然なくて(西脇・苦笑) 。本質的な理解とアウトプットができることを求めます。お客様のビジネスを損なわないレベルでアウトプットができることは、エンジニアにとって大きな強みです。

―― そういう人はどうすれば育つのでしょうか。

剣持:まずは視野の広さが大切です。面接でもそこを重視します。

西脇:自分の場合は、多能を目指したわけじゃなく垣根がなかった。とにかく、やらない理由や、やらない仕事は作っちゃダメです。

スポーツと一緒だよね。だって、サッカーでフォワードが「俺、キーパーじゃないからキーパーが何する人か知らん」とかありえないでしょ? 全部合わさってサッカーなんだから、全体理解を持った専門性じゃないと。他の仕事を理解しないヤバさってそういうこと。

いつだって垣根のない西脇さん。

IT業界に慣れれば慣れるほど、専門職だから専門外には関わらなくて良い、という傾向になりがちな気がしています。

なぜなら、新卒の研修で彼らにキャリアデザインを書いてもらうと、多くの子は複数のことをやりたがるんですよ。もちろんスペシャリストとして突き抜けていく人は絶対必要ですし、素敵なキャリアですが、そうじゃない人はデザインやマーケティングにも興味を持つ。

もうね、「そのままのアナタでいて!」と思います。それこそが多能の可能性ですから。

アイコと記念撮影。検温と消毒を徹底して働いています。

剣持:我々が目指すのは「クラウドインテグレーション」です。クラウド専門部隊と思われるかもしれませんが、むしろ逆で、「クラウドに持っていく理由を考える」チームです。

お客様と一緒に考え、並走するには、お客様のビジネスやシステムを理解する力と、最適化を考える企画力が必要です。弱点を強みに変えるチャンスを考えて「なんとかする」んです。そこに多能の要素は求められますし、鍛えられます。

DX推進の波を乗りこなし「機を見るに敏に動く」チームにしていきます。

関連記事:アピリッツのその他の役員インタビュー

SaaS業界で「カスタマーサクセス」が重視されている理由を考える

0

自社SaaS型プロダクトのサイト内検索エンジン「Advantage Search」とプッシュ配信CRM「PushTracker」、口コミ投稿管理ツール「VoiceLog」のマーケティングやセールス、本記事でご紹介するカスタマーサクセスの担当をしているWaYです。

現在、SaaS業界で注目されている「カスタマーサクセス」について、重視されている理由を簡単にご紹介したいと思います。

-Chapter1- そもそも「SaaS」とは?

SaaSとは「Software as a Service」の略語で、インターネット経由で各種サービスや機能を提供するビジネスモデルです。
従来は、何かソフトウェアを使う際には自分のPCにインストールすることが主流でしたが、今は自宅のPCからでも全く同じ機能を使うことができますよね。

メールや勤怠管理などのように、実は私たちの身の回りには多くのSaaS型サービスが存在するんです。

「SaaS」のココがすごい!

1.導入が手軽にできる

すでにあるモノを利用するので、一から開発するより導入コストが安くスケジュールも短くなります。

2.手厚いサポートを受けられる

サービス提供会社から常にサポートを受けることができるので、担当者さんも安心してサービスの導入・運用ができますね。

3.最新の機能を常に使える

個人的にはこれが一番アツいと思っています。
サービスのメンテナンスやバージョンアップ含め開発・保守は全て提供会社が行うので、サービス利用者は最新の機能を使い続けることができます。

-Chapter2- 「カスタマーサクセス」って何?

「カスタマーサクセス」とは、何かお問い合わせがあれば回答する”受動的”なサポート体制ではなく、”主体的”に向き合い二人三脚でクライアントのビジネス成長を目指していく考え方を指します。

利用者は高機能で安価なサービスを利用し、提供者はその対価を月額費用として受け取ります。
つまり提供者からすると、そのサービスをより多くの利用者に長く使い続けてもらうことがそのまま利益になるのです。

ただし、今は世の中に様々なSaaS型サービスが普及しているので、そのサービスが「使い続ける意味がない」「有益ではない」と評価されてしまうと利用をやめられてしまいます(=解約)。この”解約”を防止し、利用者のビジネス課題と向き合い続けていくことこそがカスタマーサクセスの最重要課題なのです。

-Chapter3- カスタマーサクセスの存在意義

・クライアントKPIの設計

クライアントがサービスを導入する際、導入作業をサポートするだけではなく導入した後のことも見据えることが重要です。
サービスを利用することで何を目指していくかを設定することが必要となります。

・サービスの活用促進

導入した後、数ヶ月後にはもう使われなくなっている…なんてこともあってはなりません。
より長くサービスを有効活用してもらうためには常にクライアントの利用状況を把握し、よりよい運用のレクチャーや改善提案を行い続けることが重要です。

・クライアントの満足度向上

サービス提供者は、ビジネスパートナーとして課題解決をし続けることで様々な恩恵を受けられます。
解約防止だけでなくアップセルやクロスセルにつながりやすくなり、ひいては他部署や他会社にサービスを紹介してくれることがあるかもしれません。

-Chapter4- カスタマーサクセスの取り組み例

クライアントの満足度向上やプロダクトの有効活用のためにSaaS業界では様々なことが行われています。実際に他社で実際に行われている方法を2つ紹介したいと思います。

1.クライアントが集まるコミュニケーションの場を作る

個人的には、コミュニティを作る、というものが最も印象に残っています。
そこに所属していること自体に価値を感じることができたり、更なる有効活用法などが共有されるとビジネス上のメリットを創出できたりもします。他企業との繋がりを築くことができるのも大きなメリットになると思います。
自社内に専用のラウンジを作ってしまったり、オンラインのコミュニケーションツールへクライアントを招待したりと各社様々な方法で実現しているようです。

2.定期的にアンケートを実施する

全てのクライアントに対し、1年/回、6ヶ月/回、3ヶ月/回などの頻度でアンケートを実施して、満足度を集計するといった取り組みもかなり多く行われています。
そうすることで日頃のやりとりだけではなかなか聞くことができない不満やプロダクトの改善点が見えてきますね。
更にできるだけ回答してもらうために、NPS(※)計測ツールを利用している会社も多いようです。

※:ネット・プロモーター・スコアの略。主にプロダクトやサービスに対する顧客の満足度を計る指標。

最後に

SaaS事業の一番の面白さは、導入・発注してもらうことがゴールではなくむしろそこからがやっとスタートであることだと思っています。
自分たちが企画・開発しているプロダクトを通じてクライアントのビジネスを直接的にサポートし、それを通じてプロダクトも成長することができるのはSaaSでこそ味わえる唯一無二の醍醐味であると言えるでしょう。

私たちSaaSグループは、これからもクライアントのビジネス価値を創出できるよう日々サービスを開発・提供していきたいと思います。

私たちのグループでは、3つのSaaS型プロダクトの企画・開発・保守を行っています。

■自動学習型サイト内検索エンジン「Advantage Search」
 https://search.appirits.com
■CX型プッシュ配信CRM「PushTracker」
 https://push.appirits.com
■口コミ投稿管理ツール「VoiceLog」
 https://voice.appirits.com

新卒ランチ会開催中!~明治神宮前、原宿、表参道付近のおすすめランチ情報~

0

全社会でもお知らせしましたが、現在アピリッツでは20新卒のみなさんに会社付近でランチをご馳走するというランチ会を開催しています!「気軽にコミュニケーションをとれる場がほしい」、「リモートワーク中に入社して、他部署との交流が少ない」などの声を聞き、新卒同期同士の親睦を深めるため企画しました。また、入社してもうすぐ半年ということで仕事で困っていることや悩みなどを気軽に話せる機会になればと思っています。

そこで今回はせっかくなので新卒の皆さんと行った、明治神宮前、原宿、表参道のおすすめの会社周辺ランチをご紹介します!

記念すべき第1回は……

原宿焼肉 KINTAN

食べログ:原宿焼肉KINTANはコチラ

夜はちょっとお高目な高級焼肉屋さんですが、ランチでは1000~2000円で食べられます。また、ご飯、サラダ、スープ、もついていてどれもお替りし放題というバランスとコスパの良さ。最後にデザートまでついてくるので大満足間違いなしです。

みんなから1番人気だった牛タン&KINTAN塩ハラミセット

また、週替わりで期間限定メニューが変わるので毎週通っても飽きません。ランチスタンプが貯まれば2000円オフクーポンが貰えたり、ネットで予約したらドリンク1杯無料という裏技もあります。JR原宿駅寄りなので少し会社から歩きますが気分転換にお散歩がてら行ける距離なので焼肉が食べたくなったら是非行ってみてください♪

続いて……

おばんざい鉢屋

食べログ:おばんざい鉢屋はコチラ

この日は鯖の蒲焼と鶏団子のみぞれ煮、生卵や味海苔もついています。

明治通り沿いを渋谷方面にまっすぐ行くとご飯屋さんしか入っていない通称・飯ビルがあります。(GEMS渋谷)そこに入っているおばんざい屋さんですが、ランチメニューは日替わり定食1種類のみ。平日は850円で香の物・味噌汁・サラダ・おばんざい・コシヒカリごはんお替わり無料という破格的なコスパ。美味しくてバランスもとれてお腹も一杯!メニューを選んだり注文する過程がそもそもないため時間がない日にも便利です。

続いて……

MIZUcafé

食べログ:MIZUcaféはコチラ

上から熱々のチーズをかけてもらいました。

会社から比較的近くて雨の日にもおススメなオシャレなカフェです。名前の通り水にこだわったお店でオランダ発祥のパンネクックという珍しい薄焼きパンケーキが食べられます。

最後に……

しゃぶしゃぶKINTAN

食べログ:しゃぶしゃぶKINTANはコチラ

お出汁の種類も豊富です。

ちょっと会社からは歩きますが、寒くなってきた今にピッタリのしゃぶしゃぶランチです!価格帯は1000円~1500円程度で白米、十六穀米、本日のお惣菜、お野菜、すべてお替り自由で最後に日替りデザートが出てきます。

今回は20新卒限定ランチ会ですが、今後社歴の浅い社員の皆さんや内定者向けにも計画中です!皆さんもぜひ周りの同僚を誘ってランチに行ってみてください♪

「管理系が事業に返せるものっていっぱいある」アピリッツ 取締役 CFO 永山亨 ロングインタビュー

0

「あの役員は誰だ?と思われている人も多いかも」と、2020年4月に入った執行役員 CFOの永山は冗談交じりで言いますが、全社会でおなじみの方が多いはず。入社の経緯と、CFOの役割についてたっぷり語ります! (2020年10月 取材)

永山 亨
取締役 執行役員 CFO
2020年4月入社
20代後半で会社を辞めて1年間バックパッカーの経験あり。旅の目的は自分探しではなく「体力のあるうちにペルーやエジプトを観光したかった」から。
理由はなんでもいい。

IRのTwitterはじめました!

責任者として上場を成し遂げ、「鐘」を鳴らしたい

―― 永山さんは2020年の4月にアピリッツへCFOとして入社されました。ご入社の経緯を教えて頂けますか?

まず、なぜ自分がアピリッツにいるかといいますと、上場準備の責任者として働くためです。当社の社外取締役である喜藤さんとご縁がありまして、ご紹介いただき入社しました。

前々職の求人広告会社で東証マザーズ上場から一部上場までの成長期を経験しました。そちらでなにをやっていたかというと、まずは経理メンバーとして一連の業務経験からキャリアを始め、経営企画として予算策定、IR、資金調達、東証一部への申請業務……つまり会社の数値に係るすべての仕事をやっていました。

その次に入ったスタートアップ企業でも上場申請にトライしていましたが、当時どうしても難儀な課題があり、その課題解決に時間を要することになってまったんです。その会社のことはとても好きでしたが、自身のキャリアを考えると、どうしてもある年齢までに責任者として上場を成し遂げたかった。その際に縁があってアピリッツに声を掛けてもらったんですね。

―― 「責任者として上場する」というのは、どういうことなのでしょう?

数値系の業務を一定経験すると、新しい分野の事にチャレンジするってなかなかなくて、そうなった際に責任者として上場を経験するなんてキャリアはそう多くの人が積めるものではないですし、ほら、上場するときに東京証券取引所で「カーン!」って鐘を鳴らしたり、会社の上場記念パーティーで大きな樽酒とかバコーンと割ってますよね? あれを体感したいんです。前々職では中心として動きましたけど、あれ役員しかやらせてもらえない。「ずるい! 俺が死に物狂いでやったのに」って(笑) 子供みたいですよね。

でもエンジニアさんとかってモノづくりだし、そのサービスが世の中で使われたり、営業の人だったら販売しまくって表彰されたりってスポットライトあたるじゃないですか? でも管理系ってどうしても縁の下の力持ちで、もちろんそれは素敵な事なんですけど、人生で1回くらいスポットライト浴びたいなって。高尚な理由じゃないですよね(笑) でも自分はやりたい。夜遅くまで必死で準備して、審査に臨んで、上場をはたすなら、自分の手であの鐘をカンカン鳴らしたい。

……ということで、自分はここにいます。

ちなみに、今年の4月といえば新型コロナウイルス感染症によって政府から緊急事態宣言がでて、当社も全社リモートワークを実施していた頃でした。なので入社したての頃はオフィスにほとんど人がいない状態で、和田さん(アピリッツ代表取締役社長)や管理部門の一部メンバーとしか顔を合わせてなくて。だから社内では「いつのまにか現れた役員」という印象になっちゃっているかもしれません。

管理系が事業系に返せる「付加価値」は沢山ある

―― CFOの役割はどういうものなのでしょうか。今は「IPOの舵取り役」という印象が強いですが……

そうですね、今は上場準備に注力しているので、何してるんだ?って思いますよね(笑) それと同時にもちろん、決算を締めることや、取引先へ支払いをしたり、資金調達したり、はたまた内部統制やコーポレート・ガバナンスの強化も役割としてありますが、そこは当たり前の話なんです。営業の人が営業すること、エンジニアの人が開発するのと同じ。

もっと重要なのは「会社がしたいこと」を実現するための手助けをする役割です。会社の事業側の人が何かをしたいときに、それを叶えるための「お金、モノ、人」をいかに準備するか。そこを考えて動くのが私達の仕事です。

たとえば、未来のことは誰にもわからないですが、過去はわかりますよね。過去は分析できる。つまり、過去の実績推移、市場関係の情報から当社がどんな状態だったのか?良かった点は何か?悪かった点は何か? ……こういう情報は、意思決定の指針になるんです。そこから未来を見据えて管理系からネタを提供して、事業系の役に立ちたい。

だからこそ、事業のことを一番理解しないといけないのが実は管理部だと思います。

なので、自分は社内との距離が近いCFOでありたいです。みんなのことを理解しないと。管理系から社内のみなさんに「お願い」することも沢山ありますし、お願いごとをする時って距離感が大事ですし。

距離感! (撮影のためにマスクをはずしています)

「あれっ? ケンカにならないぞ?」と思った

―― 入社して半年がすぎましたが、和田社長や社内の印象はいかがでしょう?

CFOや経営企画は、社長に近いところで仕事をするのですが、和田社長は物静かで優しい印象です。でも軸がしっかりあるのは話していて感じました。昔はとがってたんだろうなってわかります(笑) あと途中入社で社長って珍しいなと思います。

会社全体は、実は最初「あれっ? 待てよ、ひょっとして自分は今すごく気を遣われている?」と戸惑いました。上場準備中ってコンプライアンスやガバナンスのために今までやっていなかった事を事業部の方にお願いしないといけない場合が多くて、普通はケンカになるんですよ。忙しいときになんでそんな面倒なことをしなきゃいけないんだ、なんの意味があるんだよ、って。面と向かって「それはお前の仕事だろ。チッ」て言われたり(笑)よく前職や前々職では言い合いしてました(笑)

でもそういった取り組みって「上場するため」ではなく、「パブリックカンパニーとして会社をよくするため」に大切なことですし、それが実は後々「よい会社の土台」になるんですよね。それは前々職や前職ですごく経験しました。売上至上主義だった会社が上場準備をしていく過程で、だんだん働き方や環境整備やいろんな事を整備して、いわゆるホワイト企業になっていった経験をしたので、だからこっちも本気です。

ということで、カオスを覚悟して入社したんですが、蓋を開けてみると皆さんとても協力的。落ち着いてるし、強みと弱みをみんな冷静に捉えているなあって感じます。和田さんも執行役員や部長の方々もみんな優しくて冷静。ちゃんと会話ができるし、人の話を聞いてくれるし、誰もケンカ売ってこない! って思いました。

なんでもいいから「うちの会社で何かをしたい」を意識してほしい

―― アピリッツを成長させていくうえで、どんな人が必要だと思いますか?

いろんな人がいてOKな会社にしたいです。たとえば「定時で帰って合コン行きたい」って人だっているでしょ。いろんな働き方がありますから、そういうひとも会社には必要。

ただ、会社ってひとつの船だから、会社から求められた仕事をするのは大前提で、かつ会社のベクトルに沿ってないなら、それは考えないとですよね。会社がこっちに行きたいっていっているのに、そこには行きませんではバラバラになってしまいますから。もちろんベクトルを合わすために話をすることは必要です。そのベクトルがあっている前提であれば、どんな働く価値観でもよいと思っています。多様性って実は大事です。多様性がないと間違った方向にいった際に気づけないんですよね。

それと目的意識はあったほうが幸せだろうなと思いますね。目的ってなんでもいいんです、高尚な理由じゃなくて。よくキャリア本に書いてあるような「将来を見据えて点と点を繋げて~」なんて出来る人はそうそう居ません。そんなもの出来たら世の中の人みんな立派になってますよ(笑)目の前のことを一生懸命頑張るとか、やってみたいことをチャレンジするとか、それこそ「上場の鐘をカンカン鳴らしたい」とか(笑)それを繰り返した先に、やっていた点が繋がる時が来るんです。それが経験っていうんだと思います。これはジョブズもいってたから間違いないと思いますよ(笑)

ですから、「うちの会社で何かをしたい」を意識してほしいです。その目的を叶えるために、みんなで会社をそれが出来るように良くしていきましょう、って思います。自身のベクトルと会社のベクトルが同じなら、実は多少大変だったとしても目標に向かっている時って人間はつまらない事に捕らわれないです。

日々のささいな事が気になって、終わらない愚痴が続くのって、実は会社がどうこうじゃなく本人にとって不幸なことです。会社や仕事に費やす時間って人生で膨大なんですよね。であれば漠然と過ごすのではなく、目的もったほうがいいに決まってますよ。人生の2/3近くを漠然と過ごすなんてよく考えたら恐ろしい。

もちろん、仕事って楽しいことばかりじゃないですし、大変なことも沢山あります。でもその大変な事の先に達成があるわけで。ホントは「ありがとう」って言われたいけど、まあなかなか言われないですよね。だってその仕事任されてるんだからやるのは当たり前で。特に管理系にいたので、それはすごく体感しました。しかもミスなんてしたら逆にむちゃくちゃ怒られて酷いことをいっぱい言われる(笑) 

まあ後で「見てろよ!」って思ってましたけど。

永山さんが鐘をならすときは沢山写真をとろうと思いました。

ただ、大変だけど、目的のために突き詰めると面白くなったりします。ずっと体育会系でスポーツをしてきたんですけど、勝負事を楽しむには一定のレベルまでいかないと楽しめません。でも大変な中でいまやっていることは何に繋がる?って思うと意外に苦労に感じない。これって何の役にたつんだ?っていう人いますけど、実はそれって当人が決めつけてるだけなんですよね。または気づけてないだけ。無駄な事なんてひとつもなくて面白くするのは自分次第です。

業務でも人間関係も同様ですね。「苦手」や「きらい」を自分は否定しません。それは誰だってありますよ。相手の価値観否定したって何も変わらない。でも苦手な対象との関わり方は自分次第です。自分が折れると損した気持ちになるかもしれませんが、そんな意地を張って仕事がうまくいかないと結局自分にストレスがたまりますし。

そして、自分がやりたいことと、会社がやってほしいことが合致しているかどうか。求職者の方にはその目線で探していただきたいです。

相手がわかる言葉で「規程」を伝える

―― いま会社にいるメンバーに対して求めることは何ですか?

自分の思考を変えて仕事に取り組んでほしいなと思います。固定観念や過去に縛られて「どうせ無理」とか「以前からこうだから」、「ルールだから」や「NGを出されるのが怖い」といったマインドが少しあるかもなと客観的に思います。これは時間をかけてみんなでチャレンジする雰囲気を作っていきたいです。

年齢を重ねて思うのは、今まで自分が見てきた世界や会社なんてほんの一部だってことです。もっと沢山の世界はある。それに世の中も会社も常に変化しています。実際に当社だって上場準備するステージの会社になって、去年やっていなかった事をやってみたり、またやらなきゃいけなかったり。コロナだっていい例ですよね。コロナでいろんな事が変わってきてる。常に変化してる。

実は誰だって「変化」って大変です。めんどくさいことはめんどくさいですし、でも杓子定規に固定観念に捕らわれていてもうまくいかないことが多いです。じゃあそれを超えた先はどうなるんだ?って事をきちんと話をしながらやっていきたいですね。ちゃんと相手がわかる言葉で伝えて、腹落ちしてもらうことが大事です。

たとえば、規程を作って守ることは、実は社員だけじゃなく会社が法律違反しないためや、理路整然に動くためにはらなきゃいけないですけど、同時に、規程に興味を持ってもらわないといけないんです。「ココに、ルールが、書いてありますっ!」って言ったって、読むわけがないんですよ。だってみんな忙しいから。だから、どうしたら守ろうって思ってもらうか作戦や伝え方を考えないといけない。

規程を定めるのが仕事でなく、守ってもらうまでが仕事ですから。だから相手がどんな事を考えているのか?どんな状態なのか?じゃあそのために自分はどのような伝え方をしないといけないか?って考えて、伝えないと。そのためには自分が変化しなきゃですよね。自分の考え方に固執したって伝わらない。

だって考えてみてくださいよ、長く一緒にいる家族や恋人のことだって、なかなか変えられないし、分かり合うには話をたくさんするでしょ? それはみんな薄々気づいてるはずなのに、会社では不思議とやっちゃうんですよね、相手のこと見ないで、一方的に何もしないで「あの人、なんでわかってくれないんだろう?」って。そりゃ相手のことわかろうとしてないし、自分も相手にちゃんと伝えてないのだから実はそうなるのは当然なんですよね。

会社にいるのは、年齢も性別も経歴も育った環境も価値観も仕事もちがう、めちゃくちゃ赤の他人です。何もせずに「わかってくれる」なんてない。わかってもらうためには工夫が大切。そしてそれって実は巡り巡って自分のためになるんですよね。

会社って別に偉い人がどうこうしていくものではないです。みんなで一緒に作っていくものですよね。そしてその中でメンバー1人1人が目的を持てて活き活きしているのが会社も本人も幸せ。同じ会社で出会えたのだから、みんなでもっともっとよい会社にしていきたいです。その為には自分も含めてみんなが固定観念に捕らわれないでチャレンジする、相手の事を考えてコミュニケーションをとっていける環境にしていきたいです。もっとみんなを知りたいので声かけてほしいです。

―― ありがとうございました。最後に締めの一言を……!

「あの鐘を鳴らすのはあなた」(笑)

関連記事:アピリッツのその他の役員インタビュー

雲の呼吸 参ノ型~AWS設計の勘所:マネージドサービス・後編~

0

はじめに

データイノベーション部浅田です。

人気漫画「鬼滅の刃」に仮託して、「雲(クラウド)の呼吸」と題しまして、AWS(Amazon Web Services)を用いたアーキテクチャ設計の勘所を数回にわけて書いていきたいと思います。

なお、AWSに関するサービス名に関しては、この記事内で初出時は正式名称をつけ、以降は明確な場合は省略系を用いる方針で記述しています。

第三回目は「マネージドサービス・後編」です。

続・マネージドサービスの利用

前編で登場したハンニバルが戦った第二次ポエニ戦争(通称ハンニバル戦争)の前半のハイライトは何と言っても「カンナエの戦い」です。空前絶後の大勝利を納めたハンニバルですが、その後の戦況は徐々にローマ優勢に傾いていきます。原因の一つにローマの将軍スキピオ(大スキピオ)がカルタゴ優勢の要の一つであった「ヌミディア騎兵」を自軍に組み込んだということがあります。

「ヌミディア騎兵」は当時地中海世界最強の騎兵と目されていましたが、ハンニバルの騎兵戦術の要でもありました。スキピオはこれを味方に組み入れることで、歩兵戦術主体であったローマ軍に騎兵戦術を行える基盤をあっという間に整えました。そして、後半のハイライト「ザマの戦い」で、スキピオは攻守ところを変えて「カンナエの戦い」を再現、カルタゴ軍に勝利します。

AWSのマネージドサービスは、IT企業においてトップレベルにあると言っても過言ではないAWSの技術の粋が集められています。それらを利用することで、トップレベルの機能を利用することができるようになります。さらに、マネージドサービスを利用することで空いたリソース(手間・時間)を自社の独自の強みの構築に集中することができるようになります。

続・代表的なマネージドサービスとその用途

Amazon CloudWatch

CloudWatchはシステム監視向けのマネージドサービスになります。

CloudWatchは大きくわけると2通りのサービスになっていて、

  • メトリクス(プロセスの数やリソースの使用状況の収集)
  • ログ(アプリケーションのログの収集)

があります。

メトリクス

可視化によって、人間が現在のリソースの状況を把握するのにも使えますし、ある閾値を超えたら、Amazon SNSを経由してメールを送信したり、HTTPのエンドポイントにリクエストを投げたりするなどができます。また、Lambda経由でSlackに通知を行うことも可能です。第一回で出てきたAWS AutoScalingもこれらのメトリクスの値を元に、スケーリングを制御します。

サービスによって様々なデフォルトのメトリクスが提供されますが、CloudWatchエージェントを使用したり、直接送信することで好きなメトリクスを収集することもできます。たとえば、ある特定の機能の使用回数などをアプリケーションからCloudWatchになげることによってCloudWatchで一元管理を行うことができます。

ログ

アプリケーションのログの保存先として使用できます。コスト面ではS3にログを保存するほうが費用対効果は高いですが、検索が可能であったり、特定の文言の出現回数をメトリクスとして可視化できたり(もちろんその結果として通知などもできます)しますし、LambdaやAWS Fargateなどのサーバレスサービスをはじめとして、AWSのいくつものサービスのログの出力さきともなっています。

メトリクス同様、CloudWatachエージェントなどを利用することで、好きなログを収集することが可能です。

Amazon SES

メールによる通知は、会員登録であったり、メールマガジンであったり、はたまた障害通知であったり、ユーザへの連絡手段として昔から一般的に用いられています。

ですが、メール通知を行うためにメールサーバを運用することは、そう簡単な話ではありません。OB25問題に代表されるように、古くからある仕組みのために問題を抱えているので、迷惑メールの温床にならないように注意して運用する必要があります。

そこで、SESを使用することでメールサーバを運用することなく、システムからメールを送信することができるようになります。

AWSではメールサーバを運用して25番ポート(SMTP通信に使用するポート)でメールを外に送る際には、事前申請が必要になりますが、SESを使用することでその問題も回避できます。

SNSでもメール通知を行うことはできますが、SNSは事前にサブスクリプションを行う必要があるので、システム管理者への通知には使えますが、一般ユーザへの通知には向いていません。

Amazon EMR & AWS Glue & Amazon Athena

Hadoop、Spark、 Hive、HBase、Flinkなどの分散処理フレームワークの実行環境のためのマネージドサービスです。ユーザはアプリケーションの処理を作ることに集中できます。

タスクノードにスポットインスタンスを使用するよう設定できるので、コスト面などでメリットを受けられます。同時に、EMRFSを使用することで、処理結果などをS3に保持することができ、処理が必要ないときにはEMRクラスターを削除するなど、柔軟な運用を行うことができるようになります。

また、EMRはインスタンスなどをある程度意識する必要がありますが、分散処理フレームワークの技術をサーバレスにより利用できるサービスもあります。

例えば、GlueはSparkによるETLをサーバレスに実行できるサービスであり、AthenaはPrestoライクに、S3のデータをクエリで検索、加工することができます。

Amazon Kinesis Data Streams & Amazon Kinesis Data Firehose & Amazon Kinesis Data Analytics

大規模データをリアルタイムに処理するためのマネージドサービスがKInesisシリーズです。

ビッグデータの時代と言われるように、スマートフォン、IoTデバイス、各種センサーなどから絶え間なくデータが生成されています。それらを従来のバッチ処理の手法では処理しきれなくなり、常にデータが生成されるなら常に処理し続ける、というのがストリームデータ処理の考え方ですが、そのための基盤として利用できるのがKinesisシリーズになります。

Kinesis Data Streams

その中でもKinesis Data Streamsは、ストリームデータをもっとも柔軟に扱えるサービスになります。

データをストリームに投入するプロデューサーと、ストリームからデータを取得して処理するコンシューマーに分かれて処理を行うので、SQS同様にシステムを疎結合に保てるというメリットもあります。あと、コンシューマーを複数用意することで、一つのデータに対して複数の処理を行えるので、かたやデータ変換し、かたやS3にデータ保存し、みたいなことも可能です。なので、あとから機能追加が行いやすいというメリットにもなります。

Kinesis Data Firehose

リアルタイム性では若干劣るもののS3、Amazon Redshift、Amazon Elasticsearch Serviceへのデータ投入など、投げられたデータを保存する場合には、Kinesis Firehoseが威力を発揮します。Streamsがストリーム領域に応じて一定金額がかかるのに対し、Data FIrehoseは処理されたデータに対しての課金であるのに加えて、コンシューマの処理を実装する必要がありません。また、ビッグデータ処理のデータ形式としてよく使われるParquetやORCといったデータ形式にも対応しているので、ビッグデータ処理のためのデータ収集のサービスとしても優れています。

Kinesis Data Analytics

Kinesis Data Analyticsはストリームに対して、標準SQLでデータを集計、処理することができるサービスになります。Streamsがデータを逐次的に処理するのに対して、Analyticsはストリーム全体(および期間などで絞った一部)に対して、一括でデータ処理を行えるという点がことなります。「まさに今」のデータに対して、集計、可視化したいなどの用途に向いています。

最後に

以上、AWS上で設計を行う際に利用できるマネージドサービスの勘所でした。ここで紹介したのはマネージドサービスのごく一部で、この他にもAWSには便利なマネージドサービスがたくさんあります。それらを有効に活用することで、開発のコストも抑えつつ、スピーディにサービスを提供することができるようになるはずです。

関連:

雲の呼吸 壱ノ型~AWS設計の勘所:コスト編~
雲の呼吸 弐ノ型~AWS設計の勘所:マネージドサービス・前編~
AppiritsのAI研究者が『2020 APN AWS Top Engineers』に選出!資格取得に対する取り組みを紹介!

雲の呼吸 弐ノ型~AWS設計の勘所:マネージドサービス・前編~

0

はじめに

データイノベーション部浅田です。

人気漫画「鬼滅の刃」に仮託して、「雲(クラウド)の呼吸」と題しまして、AWS(Amazon Web Services)を用いたアーキテクチャ設計の勘所を数回にわけて書いていきたいと思います。

なお、AWSに関するサービス名に関しては、この記事内で初出時は正式名称をつけ、以降は明確な場合は省略系を用いる方針で記述しています。

第二回目は「マネージドサービス・前編」です。

マネージドサービスの利用

方法は見つける。なければ作る。(Aut viam inveniam aut faciam)」

古代ローマと戦ったカルタゴの名将ハンニバル・バルカは、当時不可能と言われていたアルプス越えを行って、ローマの度肝を抜きました。上記の言葉は、その際に部下から「アルプス越えが不可能である」と諌められた際に発した言葉とされています。

さすがはハンニバル、他の人間にはできないことをやってのける。そこに痺れますし憧れますが、彼の言葉の裏返しとして「方法がすでに存在するならば、それを利用すればよい」ということでもあります。事実、ハンニバルは地元の人がアルプスを越えている道があることを調査した上で、アルプス越えに挑んでいます。

AWSに限らず、クラウドとオンプレミスとの違いの一つとして数々のマネージドサービスがあげられると思います。実際、AWSが最初に産声をあげたとき(2004年)、提供されたサービスはAmazon Simple Queue Service(SQS)でした。SQSに限らず、現在にいたるまで色々なマネージドサービスが提供されています。AWSを用いてよい設計を行うということは、それらのマネージドサービスをいかにうまくつかうかということでもあります。

なぜマネージドサービスを積極的に利用すべきなのか

マネージドサービスを利用しない場合、同等の機能を自前で構築していくことになります。たとえば、SQSであれば自前でキューイングのシステムを構築するということになります。

確かに自前で構築を行えば、高度の柔軟性を維持しつつ臨機応変に対処することができるかもしれません。ですが、AにはAに向いた話、BにはBにふさわしい任務というものがあるはずで、マネージドサービスと同等に作り込めるような技能が必ずしもあるとは限りません。仮にあったとしても、相応の時間をかける必要があります。

しかも、必要な技能を身につけ、必要な時間をかけて構築したとしても、マネージドサービスより優れている点がなければ、マネージドサービスを利用しているユーザと同じ土俵にやっと立てた、ということにしかなりません。

マネージドサービスを利用することで、人的、あるいは時間的コストを削減し、競争優位を生み出す作業にリソースを集中することができるということが、マネージドサービスを利用する最大のメリットであり、クラウドを使うメリットでもあると言えるでしょう。もちろん、その方が楽でいい、ということもあるでしょう。

そして、多くの場合、コストも安く済む

AWSのマネージドサービスを利用することは、多くの場合コストを抑えることにも繋がってきます。それは、多くのマネージドサービスがサーバレスで提供されているからでもあります。第一回目のコスト編で述べたように、サーバレスの利用はコスト削減を図れる可能性が高くなります。

Amazon RDSや、Amazon ElastiCacheのように、起動時間で課金されるようなタイプのものは、Amazon EC2で作り込んだよりも運用費用が高く見えるマネージドサービスもありますが、冗長性を担保し、障害時に自動でフェイルオーバを行うように構築する手間や時間にかけるコストと費用とを天秤にかければ、結果的には安くなるケースが多いでしょう。

代表的なマネージドサービスとその用途

さて、前置きが長くなりましたが、AWSの設計を行う上で、代表的なマネージドサービスとその用途について、概観していこうと思います。

Elastic Load Balancing

ロードバランシングをおこなってくれるサービスです。デフォルトで冗長化されていますし、負荷に応じて自動でスケーリングしてくれます。

その名の通りアプリケーションの負荷を分散し、サービスの障害性を高めるというロードバランサー本来の機能に加えて、以下のようなメリットもあります。

  • AWS Certificate Managerとの連携によりSSL終端処理を行うことで、HTTPSでのサービス提供を容易にする
    • 無料でSSL証明書を取得できる
    • HTTP/2に対応しているので、サーバ側で何もしなくてもHTTP/2のメリットを享受できる。
    • HTTP to HTTPSなどのリダイレクトもリスナールールで提供できる(ALB)。
  • パスベース(L7)でのルーティングに対応(ALB)
  • 固定IPでのロードバランシングを提供(NLB)
  • AWS WAF & Shieldによるセキュリティ対策
  • AWS Lambdaの実行
  • スティッキーセッションによるセッション維持

なども利用できます。

冗長性を担保することをベストプラクティスとするAWS設計において、EC2を使用する環境においては、マストなサービスといえるでしょう。

ただし、スケーリングに関しては、スパイクアクセスに対応できない場合があるので、事前の暖気申請を行うなど対応が必要なケースもあるのは注意が必要です(NLB以外)。

Amazon S3

AWSにおけるストレージソリューションの第一候補にあがるといっても過言ではないS3は、代表的なマネージドサービスといっていいでしょう。

S3のマネージドサービスの利点としては、

  • 無制限の保存容量
  • 耐障害性(複数の箇所にデータをレプリケーション
  • データのバックアップとしてのレプリケーション
    • 同じリージョンへのレプリケーション海外リージョンへのクロスリージョンレプリケーションも設定可能
  • バージョニングによるデータの保護
  • ライフサイクルポリシーによるオブジェクトの自動削除
  • バケットポリシーによるクロスアカウントの利用

などを簡単に利用できてしまいます。

また、データレイクとして、数々のAWSサービスと連携する起点になっています。

Amazon RDS & Amazon ElastiCache

RDSやElastiCacheはよく使われるマネージドサービスでしょう。

RDSはMySQL、MariaDB、PostgreSQL、SQLServer、OracleといったRDBMSのマネージドサービスであり、RDBMSを利用するケース非常に多いでしょう。

ElastiCacheはRedisや、MemcachedのNoSQLのマネージドサービスになります。セッション情報や、キャッシュなど、レイテンシの低さを利用した用途や、あらかじめ構造化できないデータを保存するなどのように向いているので、これもよく使われるかと思います。

これらのマネージドサービスを使うと、

  • 可用性を考慮したMultiAZの構成および、フェイルオーバ
  • 定期的なバックアップによるデータ保全
  • 暗号化によるデータ保護
  • リードレプリカ 追加による読み取り能力のスケーリング

などをオプション一つで実現できます。

Amazon SQS

SQSはメッセージキューイングサービスのマネージドサービスになります。メッセージキューを使うことで、システムを疎結合にすることができます

例えば、あるシステムAからシステムBに処理を依頼するときに、直接AからBのAPIを実行してしまうと、BはAがどれぐらいAPI実行を依頼してくるかを想定して、リソースを確保したり、処理途中で失敗した場合などにエラーハンドリングをどうするかをA側も気にしなくてはいけなくなります。

ですが、間にキューを挟むことによって、B側のリソースの都合に応じて依頼(キュー)を処理することができるようになります。エラー時も再度キューを処理しなおすなどB側だけでコントロールが効くようになります。A側もキューに入れることだけを考えればいいので、Bのリソースや実装に依存しなくて済むようになります。

このようなメッセージキュを利用するにあたって、自動スケーリングによる拡張性と低コストの運用を行えるのがSQSになります。

同じメッセージが1度以上(つまり複数回もありえる)、メッセージの順序を保証しないなどの特徴がありますが、FIFO(First In First Out)というメッセージが重複せず、順序も保証してくれるタイプも出ています。

——————————

マネージドサービスはAWSの要でもありますので、一気に紹介すると多くなってしまうので、この辺で前編を終了したいと思います。
<= To Be Continued…

関連:

雲の呼吸 壱ノ型~AWS設計の勘所:コスト編~
AppiritsのAI研究者が『2020 APN AWS Top Engineers』に選出!資格取得に対する取り組みを紹介!

ロジカルシンキング~ピラミッドストラクチャーを使ってみる~

0

はじめに

業務システムやゲームアプリなど、何かしらのシステムを作るときは色々な話し合いをします。
仕様の調整や工数の見積もりなどエンジニアが説明や交渉を行う機会は意外と多いです。
また、設計段階での気付きから改善の提案を行う事もよくあると思います。

久しぶりにクライアントとの仕様調整会議などに出席する機会があり、「うまく説明が理解してもらえないな」と思う事がありました。
伝えたい事が伝わらない時は、だいたい伝える側に問題があるものだと思います。

数年前に受講したロジカルシンキングの研修を思い出し、ピラミッドストラクチャーについて再勉強したのでご紹介します。

ピラミッドストラクチャーとは?

ピラミッドストラクチャーはコンサルタントの育成や報告・文章能力の向上を目的に元マッキンゼーのバーバラ・ミント氏によって体系化されました。
論理的に提案や報告をする基本スキルとして世界中の企業や大学などに採用されています。

結論が論理的に妥当である事を説明するには、それを証明する複数の根拠が必要になってきます。
これを図にするとピラミッドの構造になるため「ピラミッドストラクチャー」と呼ばれています。
結論や仮説の妥当性を証明したり、他人への説明や説得に活用することができます。

うまく伝えられるようになりたいという目的があるので、今回は複数あるロジカルシンキング手法の中からこちらを再勉強することにしました。

ピラミッドストラクチャーのメリット

ピラミッドストラクチャーを活用するメリットとしては下記のようなものがあげられます。

  • 論理の妥当性が確認しやすい
    • 論理構成を図にすることにより、妥当性が確認しやすくなる
    • 論理が甘いと感じれば結論を見直し、再構築する事で精度が上がる
  • 主張に説得力がでる
    • その結論に至った理由を明確に説明できるようになる事で主張に説得力がでる
    • 頂点にある結論に常に立ち返る事ができるため、論点がずれたり、的外れな主張にならない
  • ロジカルな説明がしやすい
    • ピラミッドを頂点の結論から順に説明していく事でロジカルな説明をする事ができる
  • 会議がスムーズに進む、結論が出る

クライアントとの会議で上手く伝えられなかった提案を実際に当てはめて考えてみると、私の話には根拠が少なく具体例が欠けていると分かりました。

ピラミッドストラクチャーを使ってみる

実際にピラミッドストラクチャーを作成してみたいと思います。
エンジニアっぽく、今回は「クラウドで構築するか?」と言う題材にしてみます。

①結論を決める

まずはピラミッドの頂点にあたる結論を決めます。
曖昧な問いや結論になっていないか注意します。

下記のように決定しました。
 問:クラウドで構築するか?
 結論:クラウドで構築する

②設定した結論を補強するための根拠を挙げる

伝えたい相手が重視しそうな点を「根拠」として書き出していきます。
これは3つくらいが適当なのだそうです。
多すぎると話が長くなり、余計にわかりにくくなるからです。

③根拠を裏付けるデータや事実を3段目に追加する

根拠に対して事実と付き合わせ妥当性を検証していきます。
「たとえば〜」とはなせるような実例を2〜3つほど挙げていきます。

④全体的に整合性を確認する

ロジカルシンキングの基礎である「Why So?(なぜ?)」「So What?(つまり?)」の関係が成立しているかを確認していきます。
下に向かって「Why So?(なぜ?)」が成立しているか?
上に向かって「So What?(つまり?)」が成立しているか?
矛盾のない論理になっているかを確認します。

⑤実際に報告や説明をする

設定した結論に対する根拠が明確になりました。
このピラミッドに沿って説明する事で分かりやすく伝える事ができます。
ただし、説明する相手によって最終的に色々な配慮は必要になってきます。

  • リテラシーレベルを把握し、レベルにあった話し方をする
  • 専門用語はわかりやすい言葉に置き換える
  • ピラミッドの上から説明するか下から説明するか効果的な方を選ぶ

まとめ

ピラミッドストラクチャーを作成するのは意外と難しかったです。
つまり、相手にうまく伝えるということがそれだけ難しいことなんだなと実感しました。
事前の練習が欠かせないと書かれている解説も多く、実際にそうだと思います。

直近の案件で、実際にピラミッドを作って提案をしてみました。
いつもよりスムーズな説明になり、その案は無事採用していただくこともできました。

職種に関わらず、説明や説得・提案を行う機会は多々あると思います。
上手く伝えられないと思ったら、ピラミッドストラクチャーで思考を整理する練習をしてみてください。

(参考)
https://studyhacker.net/pyramid-structure
https://www.missiondrivenbrand.jp/entry/thinking_pyramidstructure
https://jobrouting.jp/257/

KUSANAGI環境でSSL(Let’s Encrypt)が自動更新されなくてspiritsがプライバシーエラーになってしまった件について

0

2020年10月14日、9時42分頃から12時頃まで、SSLの期限切れによって当サイトが『プライバシーエラー』という閲覧しづらい状態になっておりました。本件の原因調査と対応をOSDN室の青井室長に依頼し、無事解消いたしました。お騒がせしました。「せっかくだからこの話を記事にして共有しましょうよ!」とアピリッツの社内からも声があがりましたので、青井さんが今回の原因と、それをどうやって解決したかについて即まとめてくれました。(アピスピ編集部 白石)

本件の発生時刻は本日(2020年10月14日)、午前9時42分から11時43分で、後述しますがKUSANAGI移設作業の90日後にあたります。

この事象はKUSANAGIを利用されている方すべてに起こり得る内容であり、またWordPress・KUSANAGIの構成に限らずLet’s EncryptによるSSL証明書を利用している方のお役にたてるかもと思い記事公開するものです。

まず、原因はLet’s Encryptが「自動更新されていなかった」ことによるSSLの期限切れ。
「手動更新による解決」を実施の上、改めて「自動更新を設定」した事で同じ理由での再発は防げるかと思います。

原因:「自動更新されていなかった」は本当か?

元々spiritsはAWSの弊社開発環境の片隅を間借りして細々と動かしていましたが、「元気玉作戦に向けて管理画面のレスポンスを高速化しないと書いてくれる人に無用なストレスを与えてしまう」との理由で高速化する事になりました。

高速化の手法はEC2から『超高速CMS実行環境 KUSANAGI』への移設に決まり、7月の中頃にその移設作業を行いました。

移行作業時のチェックに『自動更新の設定』がなされているかを確認したはずなのにおかしいな……。
さっそくコンソールに入って確認しました。

[root@ip-XX-XX-XX-XX log]# crontab -l
#* * * * * /root/.kusanagi/provision-check.sh > /dev/null 2>&1
07 03 * * 0 /usr/bin/kusanagi update cert

やはり自動更新の設定はしてありました。

自動更新設定してあるはずが……

では、cron自体が実行されていないのでしょうか。確認してみます。

[root@ip-XX-XX-XX-XX log]# less /var/log/cron
Oct 11 03:01:01 ip-172-31-43-185 run-parts(/etc/cron.hourly)[8069]: starting 0anacron
Oct 11 03:01:01 ip-172-31-43-185 run-parts(/etc/cron.hourly)[8078]: finished 0anacron
Oct 11 03:07:01 ip-172-31-43-185 CROND[8422]: (root) CMD (/usr/bin/kusanagi update cert)
Oct 11 03:10:01 ip-172-31-43-185 CROND[8789]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Oct 11 03:20:01 ip-172-31-43-185 CROND[9303]: (root) CMD (/usr/lib64/sa/sa1 1 1)

cronは動いている……。

OKOK、ワカッテキタヨー! kusanagi update cert で調べたらいっぱいエラー報告出るモンネ!

[root@ip-XX-XX-XX-XX log]# /usr/bin/kusanagi update cert
完了しました。

ん?何事もなく通った。

更新されたSSLを見て絶望する自分

アイエエエエ!? クロン!? クロンナンデ!?

という事で調査でわかったのは「自動更新は設定されていたが、失敗し続けていた。しかも手動実行では成功した」という事実でした。

手動で実行して通るものが、2ヶ月あまり失敗しつづけた原因とは……。

困った時はやっぱりアピリッツ

そうだ、困った時はアピリッツに頼んでみよう!ということでWebシステム開発部隊に相談してみることに。

すると、数分でトップエンジニアの浅田さんなど、数人のエンジニアから様々な救いの手が!

一瞬で返ってくる的確なアドバイス

cronのログ、rootへのメール、letsencryptのログそれぞれを一緒にチェック。

ログから次々と読み解かれる情報

という訳で cron の設定を変更することにしました。

[root@ip-XX-XX-XX-XX log]# crontab -l
#* * * * * /root/.kusanagi/provision-check.sh > /dev/null 2>&1
07 03 * * 0 /bin/bash -lc "/usr/bin/kusanagi update cert"

総括

というわけで、総括です。

  • KUSANAGIを(特にAWS上)利用している皆様。cronでPATHが読めていない恐れがありますので、crontabを見なおしてください。
  • KUSANAGI側の修正を祈ります(後ほど報告予定)
  • 困った時はアピリッツ!

以上!ご迷惑おかけしました。

蛇足

浅田さんの今回の名言です。

オススメの記事です。是非読んで浅田さんのチャーミングさを感じてください。

脆弱性診断ツール OWASP ZAP について

0
Owasp ZAP

エンパワーメントサービス部所属セキュリティエンジニアの綾城です。
今回は、オープンソースの脆弱性診断ツール OWASP ZAPについて極々簡単に紹介していこうと思います。

はじめに

OWASP ZAPは、使い方によっては攻撃とみなされますので、取り扱いには十分に注意してください。

OWASP とは

“OWASP – Open Web Application Security Project とは、Webをはじめとするソフトウェアのセキュリティ環境の現状、またセキュアなソフトウェア開発を促進する技術・プロセスに関する情報共有と普及啓発を目的としたプロフェッショナルの集まる、オープンソース・ソフトウェアコミュニティです。The OWASP Foundationは、NPO団体として全世界のOWASPの活動を支えています。” OWASP Japanウェブサイトより

OWASP Japan
https://owasp.org/www-chapter-japan/

OWASPというのは団体なんです、そしてOWASP Flagship Projectsというのがありまして、OWASPが特に力を入れているプロジェクト群です。日本でも有名なものがいつくかあると思います。ASVSやTop 10、チートシートシリーズなどがあります。
(なので、OWASP ZAPやその他プロジェクトなどを、OWASPって略さないでほしいですね。)

ボランティアで成り立っているので、スポンサーや会員になって支援することができます。
人気のイベントに優先的に入場できたり、メールアドレスがもらえたり特典もありますよ。
https://owasp.org/membership/

OWASP ZAP とは

正式名称は、OWASP Zed Attack Proxyです。ザップと読んだりしてます。
フリーでオープンソースのウェブアプリケーション脆弱性スキャナーです。
Javaアプリケーションなので、Windowsでも、macOSでも問題なく動作します。
クライアントとサーバ間の通信を、アプリケーションレベルで確認することのできる、ローカルプロキシとして動作します。

ローカルプロキシは、Fiddler EverywhereBurp SuiteCharlesmitmproxyPacketProxy などがあります。
それぞれ一長一短があるので、用途や目的、プラットフォームなどによって選ぶとよいでしょう。
ちなみに、アピリッツのウェブアプリケーション脆弱性診断では、Burp Suiteがメインで使われています。

OWASP ZAPは、IPAの文書にも登場したことがあります。
IPAテクニカルウォッチ 「ウェブサイトにおける脆弱性検査手法(ウェブアプリケーション検査編)」
https://www.ipa.go.jp/security/technicalwatch/20160928-2.html

OWASP ZAP のインストール

OWASP ZAPは、Javaアプリケーションです。現在は、JREが付属していないので、別途導入しましょう。
インストール時や、アドオン導入時など、ウィルス対策ソフトが反応することがあるので、あらかじめ対処しておきましょう。

無料Javaのダウンロード
https://java.com/ja/download/

OWASP Zed Attack Proxy
https://www.zaproxy.org/

少しわかりにくいところにあるのですが、メニューの[ヘルプ] [アップデートのチェック]、[マーケットプレイス]タブから、各種アドオンを投入することができます。release、beta、alphaの表記で、そのアドオンの完成度合いを知ることができます。目的や好みで入れてみてください。

下記の画面は、導入済みになってますが、マーケットプレイスのタブを選択し、そこから必要なもの導入してください。

インストール自体は普通のアプリケーションとあまり変わりません。体系的に学ぶ 安全なWebアプリケーションの作り方Webセキュリティ担当者のための脆弱性診断スタートガイド などの書籍でもOWASP ZAPのインストールに触れていますので、わからない場合は参考にした方がよいでしょう。

OWASP ZAP の簡単な使い方

自動診断

一応、紹介はしますけれど、推奨はしません。プロテクトモードにして、スコープを定めないと、この機能自体を使えないように指導している方もいます。気軽に始められる分、デフォルトの診断範囲、クローリングやスキャンの速度、スキャンの強度で診断を始めてしまいますし、自動のため意図しない診断になる場合もあり、事故が起こる危険性があるため推奨していないわけです。なので自己責任でお願いしますね。例えば、ローカルに立てた自分のウェブアプリケーションなどに対して、お試しでやってみる程度にしてください。下部のアラートタブの中に、誤検知を含め検出した脆弱性が表示されているかと思います。

即クローリングが始まり診断が開始されるので注意してください。

手動診断

本格的に脆弱性診断やるためには、ブラウザを複数プロファイルに分け、それぞれのブラウザにローカルプロキシの証明書をインポート、プロキシ切替用のアドオンを導入します、FirefoxならFoxyProxy Standard、chromeならSwitchyOmegaなどが有名です。

今回は、HUDを切ります。(私が使い方に慣れていないだけ)HUDのボタンをオフにして、隣のFirefoxアイコンを押すと、各種設定済みのブラウザが立ち上がります。

そのブラウザに診断対象のURLを入力すると、下部、履歴に通信の状態を見ることができます。これに対して、再送を設定などしてパラメータを改変などして送信しなおしたり。手動診断を始めることができます。(今回は詳しく触れられなくてすいません。)

OWASP ZAP 多彩な使用方法の紹介

私は主に脆弱性診断にしか使わないのですが、OWASP ZAPは、APIを使用することができます。Jenkinsと連携してCIツールとしても利用することができます。(Official OWASP Zed Attack Proxy Jenkins Plugin)また、OWASP ZAP Docker版もありますので、組み合わせで多彩なことが可能になります。

弊社内の方で、こんな使い方してみたよとか、こんな使い方をした実績がありますとかあれば、社内Slackの #security でお知らせいただくと、いいナレッジにもなりますし、私が喜びます。

また、初心者から高度な使い方まで、脆弱性診断研究会の脆弱性診断ええんやでというOWASP ZAPの勉強会が定期的に開催されています。(新型コロナウィルスの影響で中断中)和気あいあいとした雰囲気で参加しやすいですが、多少緩いところがあるので、複数回参加してみるとよいかと思います。

OWASP ZAP の日本語訳

私は、微力ながらOWASP ZAPのローカライズ作業に参加してます。
https://www.zaproxy.org/docs/desktop/credits/#zap-localization

本体の方も修正を入れようかと思ったのですが少し難しかったです。
起動時やぱっと見でわかるメニュー類などちまちまと日本語化していきました。
現在は、スキャン結果など長めの英文がまだ残ってるので、協力してくださる方を待ってます。

おわりに

アピリッツでは、セキュリティに興味があり脆弱性診断をやってみたいセキュリティエンジニアを募集しています。興味ある方は、下記の採用情報からセキュリティエンジニアの職務内容・応募資格を確認してみてください。またコミュニティ活動やOSS活動に積極的な方、オープンソースを活用して開発をしてみたいWebエンジニアを歓迎します。下記ボタンからぜひ確認ください。

アピリッツの「社内公募制度」、実際に挑戦した人に話を聞いてみました

0

アピリッツには「社内公募制度」という人事制度があります。アピリッツに所属する社員にむけて、アピリッツの各部署が人材募集の情報を開示し、社員自らの意思でこれらに応募する制度です。”社内転職”とも呼ばれるこの制度を利用して新しいキャリアを築いている2名の方に、今回匿名でお話を伺いました。(2020年 9月取材)

「やってみたい」「環境を変えたい」 勇気を出して応募

ーー 「社内公募制度」に応募したキッカケを教えてください。

Aさん:自分が「やりたい」と思う仕事が募集されているのを見つけて、そこでまず社内公募制度に興味をもちました。もともとゲーム系の仕事に興味があって、そちらを志望していたんです。でも当時はゲームではない開発の仕事に携わっていました。そして当時の上司との定期的な個別面談のときに、思い切って「ゲーム開発に挑戦したい」と相談しました。

私が応募した職種は「上司の許可」は不要だったのですが、とても迷っていたので、思い切って相談したんです。とても親身に相談に乗ってくださいました。今でも感謝しています。

求められるスキルに自分があっているか、どういう仕事の進め方になるのか、仕事の詳細……そういった不安を上司に聞いてもらって、気持ちの整理をつけて応募しました。

ーー 勇気を出して「社内公募制度」に応募されたのですね。Bさんはいかがでしたか?

Bさん:私の場合は、公募のリストのなかに自分が携わったことのある業務があったので、応募することにしました。実はそのとき転職も視野に入れていたんです。当時携わっていた仕事と自分は、マッチしていないのではとかなり悩んでいたので……。

そういうときは、仕事へのモチベーションやコンディションにも影響が出ます。だから、今のままで自分はいいのだろうかと考えていました。

社内公募制度に挑戦しようと決めたときはもちろん緊張しました。でも「ダメでもともと。採用されたらラッキーくらいに考えよう」と言い聞かせて、気負わず応募できたと思います。用意されている応募フォームに申し込むだけで始まりますし。

とはいえ、自分の状況や環境を変えるチャンスでしたし、その後の選考フローは全力で臨みました。

社内にいながら転職の面接

ーー 面接はどのような雰囲気ですすみましたか?

Aさん:面接は、応募した部署の部長や役員が担当します。社内の知っている方々との面接なので、とても和やかな雰囲気で進みました。こちらの意図をくみとり、真摯に話をきいてくれるので、改めて「安心できる職場だな」と感じました。

Bさん:私の場合も同じです。査定面談よりもうんとフランクですね。

見知った方々との面接なので、緊張しすぎず、自分の思いや熱意をよりダイレクトに伝えることができたと思います。だから「あなたのスキルなら、この職種もいいかも。興味はある?」と逆に提案をいただいたり……。私のキャリアを一緒に考えてくれているなと感じました。

ーー 人事とのやりとりもスムーズでしたか?

Aさん:はい。「次のステップはこういうものです」と説明していただいたので、不安を感じずに面接を受けることができました。

Bさん:サクサクと次に進むイメージでした。応募そのものも、フォームに記入してクリックひとつで始まりますし、すべてがスムーズでした。

ーー 転職活動との違いはなにでしょう?

Aさん:正式な履歴書は不要ですし、転職活動の準備よりはるかにラクだったと思います。選考にあたって、自分のスキルを説明する資料を作りました。

Bさん:私の場合は課題提出がありました。今までの仕事の経験も活かせる内容でしたし、「いつかやりたい」と思っていたことだったので力が入りました。

転職活動と違って移動時間も必要ありませんし、社内の会議室に行くだけです。心身の負担はだいぶ違いますし、そのぶん選考に全力をかけることができました。

転職の一歩手前、今の半歩先の挑戦

ーー 新しいお仕事はいかがですか?

Aさん:仕事に対する姿勢は少し変わったと思います。自分で選んで、自分で勇気を出して飛び込んだ世界なので、モチベーション高く働けています。

じつは、ちょっと転職を考えていたので、よいタイミングで挑戦できたなと考えています。

こういった機会が用意されているのは、自分のキャリアデザインの選択肢が増えるということです。だから良い制度だなと思いますし、最初はかなり迷いましたが、自分の意志を自分の人生に反映させることができてよかったです。

Bさん:前向きに穏やかに仕事に集中できています。守秘義務がかなりしっかりしているので、周囲にも「社内公募制度を利用して異動した」ことはわからないですし。

それに、社内公募制度で採用となっても、会社が変わるわけではないので、大きな手続きもありません。なんならPCの設定もそのままです。ですから、人生の大きなイベント感は少ないです。なめらかに環境を変える感じです。

もちろん選考はありますし、簡単にパスできるものでもないようです。応募までにいろいろ悩むこともあります。でも、転職で見知らぬ人に自分をアピールするよりも、自分の良さを知ってくれている会社に改めて自分をアピールできるのは、会社だけじゃなく自分にとってもメリットが大きいと思います。

もしまわりに自身のキャリアや仕事について悩んでいる同僚がいたら、転職の一歩手前の選択肢として、現状から半歩先の挑戦として、社内公募制度への挑戦を考えてほしいです。

サイト内検索のコレジャナイ候補”すし”と”ロースしょうが焼き”問題に迫る

0

サイト内検索ASP AdvantageSearch(以下、AS)のテクニカルサポートを担当している高橋です。全文検索で起こりやすい問題とその対策について、ECサイト内検索を例に記載します。

まず、多くのECサイト内の検索では商品名や商品説明などのテキストに対しては部分一致でヒットするようになっているかと思います。特に、弊社サービスのASでは、検索キーワードの入力が中途半端な状態でもフレーズが一致していればヒットするようになっています。

例えば「おいしいロースしょうが焼き」という商品名に対して「おいしいロース」「ロースしょう」とかで検索してもヒットします。これにより検索ユーザーが欲しい商品を途中までしか覚えていなくても、入力が面倒になっても、検索結果から漏れずヒットしやすいようにしてなっています。

すし・ロースしょうが焼き問題

一見普通の仕様ではありますが、懸念点もあり、「すし」で検索しても「おいしいロー”スし”ょうが焼き」がヒットしてしまいます。それだけでは問題にはならないのですが、悪い場合、検索結果一覧が寿司商品ではなくロースしょうが焼きで埋もれてしまう可能性があります。本来寿司商品が一覧に表示されてほしいのに、もしロースしょうが焼き商品が先に表示されてしまうと、使いにくい検索となってしまいます。

このようにキーワードの中に別の意味のキーワードが含まれていると、両方のキーワードがヒットしてしまい、検索結果が荒れてしまう原因となります。特に日本語は英語みたいに単語ごとに文章が分かれていないので、意図しない結果が起きやすいです。この問題の対策として、キーワードを分解してつながりをなくすことで関連度を調整する方法があります。

関連度

関連度とは、検索キーワードとヒットした商品がどのくらい関連しているかを表す指標です。この関連度が高いと検索結果の上位に表示されるようになります。関連度を上げる方法は様々ありますが、その1つとして検索キーワードを含むテキストの量を増やす方法があります。

単純な例ですが、「すし」というテキストが1つしか含まれていない商品と、9つ含まれている商品では、9つ含まれている商品の方が関連度が高くなりやすいです。(もちろん様々な観点から評価されますので必ずしも上がるわけではございません。)

キーワードを分解し関連度を調整することで対策

この計算方法を利用し、「ロースしょうが焼き」を「ロース」と「しょうが焼き」に分解して「すし」に一致しないテキストを作成します。一方「寿司」はこれ以上分解できないため「すし」のままとなり「すし」で一致するテキストが作成されます。これらの関連度を並び順に反映すると、検索結果の上位に寿司商品、下位にロースしょうが焼き商品が表示されやすくなり、使いやすい検索となります。

ASではこれらの”テキストデータの分解・抽出を自動で行う”機能(キーワード抽出機能)が備わっており、簡単に検索結果の改善を行うことができます。

パン・フライパン問題

キーワードを分解することで「すし」「ロースしょうが焼き」問題は解決できましたが、「パン」「フライパン」問題は解決できておりません。「フライパン」はこれ以上分解することができない単語なので「フライパン」のまま抽出されてしまい「パン」でヒットし関連度が上がってしまうためです。この場合は「キーワード抽出機能」と「完全一致型」を使用すれば対策可能です。

キーワード抽出機能+完全一致型による対策

先に完全一致型とは、登録されたキーワードと検索キーワードが完全に一致しないとヒットとならない型です。例えば「フライパン」が登録されている場合「パン」などで検索しても一致しません。「フライパン」と検索した時のみヒットし、関連度が上がります。

これを利用してキーワード抽出機能と組み合わせることで、パン商品には「パン」、フライパン商品には「フライパン」というテキストを完全一致型で作成し、「パン」で検索しても”フライパン”の関連度は上がらず、”パン”商品のみ関連度を上げることができます。

宣伝

最後に宣伝となりますが、このようにサイト内検索は問題点は目に付きやすいですが改善には様々な技術や対応が必要となります。改善コストの軽減の一つとして、AdvantageSearchをご検討いただければ幸いです。

ANGEL Dojo Season2 アピリッツチーム 成果発表

0

前書き

デジタルビジネス部所属の渡邊と申します。

私は2020年6月12日より、AWS 主催のエンジニア向けイベント ”ANGEL Dojo Season2″ にアピリッツチームとして参加しており、2020年9月4日に最終発表を行いました。そこで発表をした、私たちが企画から開発までを行ったサービスについてを、本記事で紹介します。

ANGEL Dojo についての詳しい概要は、過去の記事を参照ください。

関連:出てこい!AWSネイティブ世代 ~若手エンジニアがAmazon Web Services 主催 ANGEL Dojoに参戦!~

関連:新卒も参加中! AWS主催 “ANGEL Dojo Season2” 若手エンジニアインタビュー

関連:AWS主催イベント“ANGEL Dojo Season2” 最終成果発表会 レポート


会社に入りたての頃、困ったときに誰かに相談できましたか?

皆さんは会社に入ったばかりの時に、困ったことがあった場合に気軽に誰かに相談できる環境があったでしょうか?

例えばエンジニアであれば、プログラムでエラーが発生し自分では解決できなさそうだけど、いつも相談している先輩が忙しそうで聞きづらい。また、会社のルールについてわからないときに誰に聞けばよいのかがわからず無駄な時間を過ごしてしまう、なんて経験したことのある方々も多いのではないかと思います。

弊社では社内コミュニケーションツールとして Slack を利用しています。仕事中にわからないことが出てきた場合は、社員全員が参加しているチャンネルや部署のチャンネルで相談を投げれば解決するのかもしれません。

でも、発言とともに自分の名前が出ると思うと「こんなこともわからないの?」と思われてしまうのでは…と身構えてしまったり、個人的な内容を全体チャットに投げてみんなに通知が行ってしまい迷惑になるのではないか、と不安となってしまったりなど、入りたての頃は正直恥ずかしくて気後れしてしまいますよね(勿論、そんなこと無いって方もいるかもしれませんが)。

また、相談する側だけでなく回答する側にとっても、多くの人が見える中で間違った情報を伝えてしまうと恥をかくリスクがあったり、発言するハードルは低くはないはずです。

このように、相談する側と回答する側のお互いがチャットでの発言を遠慮をしてしまった結果失われる時間は非常にもったいないと私たちは考え、課題と捉えました。

そこで、私たちはこのようなサービスを考案しました。

こまっち 【困っている社員と相談できる社員をマッチング!】

名前を明かさずに相談を投げ、相談に乗ってくれる人が居たらマッチングするというSlackbot、その名もこまっちです。

こまっちを使えば、困っている人は気軽に相談を投げることができるし、誰に聞けば良いかわからないような内容でもこまっちが相談相手を探してくれます。また、相談を受ける人も1対1での会話になるので人目を気にせずアドバイスをすることができます。

また、今まで話したことのない社員同士がつながるきっかけとなる可能性も生まれます。

それでは、こまっちの仕組みを説明していきます。

マッチングするまでの流れ

まず、困っている人はこまっちに相談を投稿します。

すると、こまっちは投稿された文章から特徴的なキーワードを解析・抽出し、それを元に答えられそうなユーザを数人探します。その後こまっちは探し出したユーザに対し、相談投稿者の名を明かさずに相談内容のみを送ります

相談内容が送られたユーザーは、相談に乗ることができる場合はOKを、そうでなければNGを選択できます。

OKを選択したユーザーは、こまっちによって投稿者とマッチングし、相談投稿者に対して Slack アカウント情報が伝えられます(この時点ではまだ相談投稿者の名は明かされません)。

あとは相談投稿者から DM でやりとりしたり、直接会って相談するなどアクションを起こし、自由に連絡をとることが可能です!

実際の見た目はこのような感じです。こまっちのAppを追加し、こまっちのホーム画面を開くと「相談相手を探す」ボタンが表示されるので、押して出てくるフォームに相談の概要を書いて投稿します。

アーキテクチャ紹介

ANGEL Dojo は AWS 主催のイベントということで、Slack 以外の部分は全て AWS のサービスによってこまっちを作り上げました。

こだわったポイントは、保守運用を簡単にするためにフルサーバレスな構成としたところです。今回、サーバーレスなアプリケーションの構築のために、AWS サーバーレスアプリケーションモデル、通称 SAM ( Serverless Application Model )を用いて開発しました。

相談が投稿されてからマッチングするまでの処理ごとにどのような動きになるのかを具体的に見ていきます。

1) Slack で相談が投稿される → 他のユーザーへ相談内容を通知する

Slack で相談が投稿されると、 Amazon API Gateway からリクエスト受付AWS Lambda が起動します。

リクエスト受付AWS Lambda は、リクエスト情報から次に実行する AWS Lambda の振り分けを行いますが、リクエストが相談投稿の場合は、相談投稿を処理するための、内容解析相談登録相談相手取得通知、の4つの AWS Lambda 群を管理する AWS Step Functions が実行されます。

1つ目の内容解析 AWS Lambda では、 Amazon Comprehend を用いて投稿された内容からキーワード抽出を行います。

例えば「EC2について教えて下さい。」といった相談投稿がされたとします。すると、「EC2」のようなキーワードを抽出し、2つ目の相談登録AWS Lambda に、抽出したキーワードを渡します。

この相談登録AWS Lambda では、渡されたキーワードや相談概要、また相談投稿者の情報を、まとめて Amazon DynamoDB に登録します。

相談登録の処理が終わると、3つ目の相談相手取得AWS Lambda が呼ばれて、キーワードをもとに通知を送るユーザーを5人ランダムに選び、4つ目の通知AWS Lambda に情報を渡します。

最後にこの通知AWS Lambda で、選ばれたユーザーに対してこまっちから Slack のメッセージを送信します。

2) マッチングが成立する

選ばれたユーザーに対して送られる Slack のメッセージには「OK」と「NG」のボタンが表示されていて、「OK」を押すと、リクエスト受付AWS Lambda からOKした人を通知する AWS Lambda が起動します。

この AWS Lambda では、「OK」を押したユーザーの情報を相談投稿者に対して、こまっちから Slack のメッセージを送信します。

3) 相談が解決する

相談投稿者に対して送られる、「OK」を押したユーザーの情報のメッセージには、「解決」ボタンも含まれています。相談投稿者が解決したと判断した場合にはこの「解決」ボタンを押してもらいます。すると、リクエスト受付AWS Lambda から解決処理AWS Lambda が呼ばれ、相談が誰によって解決されたのか、また、解決したユーザーに、最初に相談概要から抽出されたキーワードを紐付け、 Amazon DynamoDB に登録します。

つまり、相談が解決されればされるほど、解決した人がどんな分野に長けているかの特徴付けがされていくという仕組みです。

その他) Slack ワークスペースのユーザー情報の取得

相談概要を他のユーザーへ通知するために、前提として Slack ワークスペースの全ユーザー情報を Amazon DynamoDB に登録しておく必要があります。そのため、 Amazon EventBridge を用いて、ユーザー登録AWS Lambda を1日に1回実行させ、 Slack から取得できるユーザー情報をもとに Amazon DynamoDB へ登録をしています。


後書き ~ ANGEL Dojo で学んだこと ~

ANGEL Dojo が始まる前は、様々な AWS のサービスに触れることが主な目的と捉えていました。しかし本当は、 AWS という会社がどのようにサービスを生み出しているかのノウハウを吸収させてもらえる場ということがわかりました。実際に私たちのワークショップは、具体的に実在しそうな人物象を設定し(ペルソナ設定)、その人がどんな課題を抱えていてその課題を解決するにはどんなものが必要か、という設計から始まりました。これは今までやったことない経験であり、ほかチームよりも難航してスケジュールが遅れるほど苦労しましたが、「ただ要件通りにシステムを作るプログラマー」ではなく、「今、どのようなシステムが求められていて、そのシステムを当初の要求から逸れずに完成させる」、という流れに触れた経験は非常に大きかったと、私は思います。

また、もちろん技術的な面でも得られるものは大きかったです。私はこれまでの業務の中で AWS に触れる機会はあったものの、アプリケーションサーバーとマネージドデータベースとクラウドファイルストレージの構成といったものの経験しか無く、今回サーバレスなアプリケーションに挑戦したことにより、サービス構築時のインフラストラクチャーの選択肢を広げることができたと思います。

この場で恐縮ですが、 ANGEL Dojo を主催してくださった AWS の方々、また、 ANGEL Dojo に参加できるように手配してくださった社内の方々にお礼を申し上げます。

現時点でまだまだこまっちは完成したとは言えない状態です。例えば、最初相談を投げてから誰も相談相手が見つからなかった場合の考慮や、よくされる相談はデータとして蓄積しナレッジツールとしても使えるようにしたいなど、課題が残っています。ただ、こちらに関しては、 ANGEL Dojo は終了したもののチームメンバーは引き続き完成させることを目標に動くことが決まりました。また、ゆくゆくはチームメンバー以外で有志を募り、実際に運用していくことを目指しています。続報があれば本ブログにてお伝えしていければと思います。

最後に、 ANGEL Dojo の最終発表時のプレゼンテーションファイルを添付して本記事は以上とさせていただきます。

最後までご覧いただきありがとうございました!

アピリッツ_ANGEL_Dojo_2nd_最終発表

最近人気な記事