Wiz テックブログ

Wizは、最新のIoTやICTサービスをお客様に届ける「ITの総合商社」です。

LINEBotのメッセージ形式あれこれ

Laravel PHP Web技術 バックエンド
https://kazzstorage.com/wp-content/uploads/2019/10/trial-messaging-api-00-300x300.png

こんにちは、バックエンドエンジニアの米山です。

前回、LINEBotの自作をするための環境構築について書きました。

LINE DevelopersサイトのMessaging APIの頁を見ていたければわかるのですが、「イベント」という概念があり、このイベントごとに自分で処理を作り「メッセージ」を返します。

今回はこの「メッセージ」についていくつかパターンがあるので紹介したいと思います。

開発言語は、前回に引き続きPHP(Laravel)を使います。

テキストメッセージを返す

一番の基本ですね。ユーザーが入力したメッセージをオウム返ししても良いですし、挨拶のようなbotを作っても良いかもしれません。

$bot->replyText($reply_token, 'おはよう');

一番簡単にテキストメッセージを返せるのはreplyText()メソッドを使った返し方です。

$reply_tokenにはLINEユーザーがbotに対して送ってきた時のトークンを取得し、返却時に使います。(以降同様)

実はテキストメッセージはいくつか返し方があり、一番簡単なのは上記の通りなのですが

$builder = new TextMessageBuilder('おはよう');
$bot->replyMessage($reply_token, $builder);

でも返せます。

仕組み的には、replyText()メソッドの中でもTextMessageBuilderが使われており、同じような処理をしているからです。

選択肢ボタンのメッセージ

アンケートなどで「どちらか選んでください」という選択肢のボタンをメッセージとして返すことができます。

$button1 = new MessageTemplateActionBuilder('ラベル1', 'ぼたん１');
$button2 = new MessageTemplateActionBuilder('ラベル2', 'ぼたん２');
$buttons = array($button1, $button2);
$builder = new TemplateMessageBuilder('タイトル', new ButtonTemplateBuilder(null, 'タイトル', null, $buttons));
$bot->replyMessage($reply_token, $builder);

ちょっと複雑ですが

  • 1つ1つのボタンを作成する
  • ButtonTemplateBuilderでまとめる
  • TemplateMessageBuilderで返す(中身はボタン) という作り方になります。

クリックリプライボタン

LINE Developersサイトでボタンとは別に解説されているのが「クイックリプライ」です。

最大13個までの横に並ぶボタンを定義できます。

こちらも選択肢と同じような使い方ができるものです。

$button1 = new QuickReplyButtonBuilder(new MessageTemplateActionBuilder('ラベル1', 'ぼたん１'));
$button2 = new QuickReplyButtonBuilder(new MessageTemplateActionBuilder('ラベル2', 'ぼたん２'));
$buttons = array($button1, $button2);
$builder = new TextMessageBuilder('タイトル', $buttons);
$bot->replyMessage($reply_token, $builder);

若干使い方が異なりますね。

他の返し方

テキストメッセージ、選択肢ボタン、クイックリプライと紹介してきましたが慣れてくると、他の返し方もできるようになります。

  • タップしたらLINE内部ブラウザでWebサイトにアクセス(返信メッセージにURLを埋め込む)
  • 日付を選択させるメッセージを返す(Date Picker)
  • 画像で返す、音声で返す、動画で返す
  • スタンプを返す(ただし使える範囲は限られている)
  • 位置情報を返す

などなど。また、これらは入れ子にすることができ

  • 選択肢ボタンの１つ目を選ぶとWebサイトに飛ぶ、２つ目を選択した時はメッセージを返す
  • クイックリプライの１つ目をタップするとメッセージが出る、２つ目の場合は画像が送信されてくる のような挙動も作ることができます。

おわりに

いかがだったでしょうか。

LINEというアプリとこのSDKを用いた技術は覚えておいて損はないと思います。

twitterなど、他のSNSのDeveloperにもなれる可能性がありますしSNS関連の知見も増えていくことでしょう。

ここまで読んで頂き、ありがとうございます。

Wizではエンジニアを募集しております。

興味のある方、ぜひご覧下さい。

careers.012grp.co.jp

LINEBotをPHPで自作する

PHP Laravel Web技術 バックエンド
https://kazzstorage.com/wp-content/uploads/2019/10/trial-messaging-api-00-300x300.png

こんにちは、バックエンドエンジニアの米山です。

今回はPHP(Laravel)を使ってLINEBotを自作するための環境を作ってみようと思います。

実は、社内で先日リリースしたシステムがこれを実施しています。

LINE公式アカウントを作成し、LINE Official Account Managerで自動応答を作ることは可能です。

ですが、このコンソールで受け答えの設定ができるのは一部の機能で、返し方もある程度決められているため

より柔軟に自動応答させるにはbotの自作が必要なのです。

ライブラリをインストール

PHP(Laravel)のライブラリ管理ではおなじみの、Composerを使います。

composer require linecorp/line-bot-sdk

これでインストール完了です。

Tokenを設定する

LINEBot(LINE Messaging API)を利用するには「ビジネスアカウント」というものを作成し

LINE公式アカウント(コンソール内で「チャネル」と呼んでいるもの)を作成し

「チャネルトークン」「チャネルシークレット」というものを取得し、環境変数として設定する必要があります。

公式アカウントの作成方法はググれば沢山出てくるので、ここでは割愛します。

インストール後の状態だと、vendor/linecorp/line-bot-sdk/src/Laravel/config/line-bot.phpで

<?php

return [
    'channel_access_token' => env('LINE_BOT_CHANNEL_ACCESS_TOKEN'),
    'channel_secret' => env('LINE_BOT_CHANNEL_SECRET'),
];

とあるので、.envファイルで設定してあげれば良さそうです。

(私の場合はこのファイルの存在を知らず、プロジェクト内ファイルとしてconfig/line-bot.phpに作ってしまいました。笑)

LINEBot用のコントローラクラスを作成

通常のLaravelで、RESTfulな処理を作る時と同様にAPIを作成します。

php artisan make:controller LINEController

ルーティングも設定します(HTTP MethodはPOSTで作ります)

Route::post('/line/callback', [LINEController::class, 'callback']);

LINEControllerは全体的にこんな感じで作ります

public function callback(Request $request)
{
    $bot = app('line-bot');
    // LINE シグネチャのチェック
    $signature = $_SERVER['HTTP_' . LINEBot\Constant\HTTPHeader::LINE_SIGNATURE];
    if (!LINEBot\SignatureValidator::validateSignature($request->getContent(), config('line-bot.channel_secret'), $signature)) {
        abort(400);
    }

    // ここに自動応答処理を書く

    // JSONでステータスコード=200のレスポンスを返す
    response()->json(['return-data' => 'data'], 200);
}

ステータスコードは常に200を返すように作ります。

何故こんなことをしているかと言うと、開発ガイドラインで指示されているからです。

https://developers.line.biz/media/partner-docs/LINE_BOT_Development_Guidelines.pdf

ここまで作れると、こんな感じのイメージになるかと思います。 (下図のYour Systemの部分がここまで構築した内容になります)

https://cdn-ak.f.st-hatena.com/images/fotolife/s/shirakiya/20160530/20160530104247.png

まとめ

PHP(Laravel)で、自作のLINEBotプログラムを作る場合は

  • ComposerでSDKをインストールする
  • LINE公式アカウントを作成し、ChannelToken・ChannelSecretを取得。環境変数として設定する
  • APIを作る要領で、ルーティングの設定、Controllerを作成する
  • Controller以降を実装する(レスポンスは必ずHTTPステータス=200を返すようにする)

こんなところですね。

ここまでの内容はあくまで疎通レベルのものなので、実際はDBを使ったり、サービスクラスを作ったりしながら、特定のキーワードや挙動に反応する処理を作っていくことになります。

ここまで読んで頂き、ありがとうございました。

Wizではエンジニアを募集しております。

興味のある方、ぜひご覧下さい。

careers.012grp.co.jp

PHP(サーバ)上からWebSocketにアクセスする

Laravel PHP Web技術 バックエンド

https://koenig-media.raywenderlich.com/uploads/2020/08/Screenshot_2020-08-10_at_15.08.19.png

こんにちは、バックエンドエンジニアの米山です。

前回、WebSocketの導入・構築について書きました。

その中で、

onMessage() : クライアントのsend()時に発火するイベント。クライアントにメッセージを返すところまでここで実装する。

と書きました。

これで気づいた方がいたかもしれませんが、onMessage()はクライアントからの送信で発火するイベントであり、サーバから発火できるものではない、ということです。

「えー矛盾してるじゃん！？WebSocketはお互い任意のタイミングでやりとりできるんじゃないの？」

という声が聞こえて来そうです。

この辺りは私もまだ学習中の身でして、Google先生曰く「redisを使おう！」とか「ブロードキャストイベントが〜」

などのご教示を頂くことが多いのですが、私は「１クライアントとしてサーバ上でWebSocket接続する」という道を選択しました。

前回の記事の通りに構築すると、PHP(apache)が稼働しているポート(80)とは別にWebSocketサーバを立ててListenすることになります(8282)

ですので、PHPから8282ポートに向けて接続してやろう、という考え方です。

WebSocketクライアントソフトのインストール

方向性を決めたところで色々探していたら、先輩からこちらを紹介いただきました。

Textalk
https://github.com/Textalk/websocket-php

composer textalk/websocket

でインストール可能です。

PHPでWebSocket接続！

GitHubの例にあるように

$client = new WebSocket\Client("ws://localhost:8282/");
$client->text("Hello WebSocket.org!");
echo $client->receive();
$client->close();

WebSocketクラスをnewするタイミングでWebSocketのURLを渡してあげます。

前回構築した環境では、PHPを動かす環境とは別にサーバを立ててますので「ws://localhost:8282」とします。

将来的に、WebSocketサーバを独立して立てる場合のことを考えても、PHPからクライアント接続できることはメリットだと考えます。

おわりに

いかがだったでしょうか？

PHP(サーバ)を１クライアントとしてWebSocket接続する方法を紹介しました。

他に追加のミドルウェア(redisやfirebase等)を入れずに、シンプルな考え方で接続できるので、私はスッキリしました。

今後時間があれば、これらのミドルウェアの知見を伸ばしつつWebSocketを構成してみたいですね。


今回はここまでです。ありがとうございました。

Wizではエンジニアを募集しております。

興味のある方、ぜひご覧下さい。

careers.012grp.co.jp

LaravelでWebSocket(Ratchet)を使ってみた

PHP Web技術 Laravel バックエンド

https://image.slidesharecdn.com/asyncphpdrupalcampla-140908080505-phpapp02/95/asynchronous-php-and-realtime-messaging-39-638.jpg?cb=1410262331

こんにちは。バックエンドエンジニアの米山です。

今回開発案件で、WebSocketを使ったシステム開発に携わることになったので、導入時のメモや困ったことetc...を書いていこうと思います。

まず、WebSocketとは？

Socketを使った技術は、古くからJavaなどの世界で存在していましたが、WebSocketはこれをインターネット上で可能にしたものです。

【従来のWeb通信】

https://create-it-myself.com/wp-content/uploads/study-websoket-spec-image1-768x536.png

従来のWeb通信は「１回のリクエスト」に「１回のレスポンス」で処理を行なっていました。

キャッチボールをイメージしてもらえたら良いと思います。

【WebSocketによる通信】

https://create-it-myself.com/wp-content/uploads/study-websoket-spec-image7-768x535.png

これがWebSocketになると「双方向通信」となり、ソケットが開いている間は任意のタイミングでクライアント<-->サーバ間通信が行えます。

WebSocketを導入するために

今回実施した開発案件では、以下の環境・条件で構成を考えました。

  • サーバ側の開発言語はPHP(Laravel)であること
  • フロントエンド側にサーバ側の言語仕様を押し付けないこと
    • PHP(Laravel)の設計思想や概念に依存するコードをフロント側に強要しない。フロントはフロントで技術選定できる環境にする。
  • なるべく、サードパーティ製のツール(firebase等)を使わず、リアルタイム性を実現できること

以上のことから、今回は「Ratchet」というライブラリを選択しました。

LaravelでWebSocketを構築しようとすると、必ずと言っていいほど「Laravel-Echo」が検索ヒットします。

しかし上記に挙げた条件の通り、フロントエンドはフロントエンドで技術選定を行いコーディングするので、依存しないRatchetを選びました。

早速Ratchetを導入！

では、LaravelプロジェクトにRatchetを導入してみましょう。

LaravelではComposerを使ったライブラリ管理が可能ですが、Ratchetの公式ページに導入方法が記載されています。

http://socketo.me/docs

ComposerでRatchetをインストール

公式ページに書いている通り、composer.jsonを書き換えても良いですし

composer require cboden/ratchet

でも良いです。（執筆時点でのVer.はv0.4.3を使用しています）

WebSocketサーバを作る

Webサーバ内で別のサーバが動くイメージで実装します。

Webサーバ(apache)内でアプリサーバ(tomcat)が動く感覚に近いです。

Java使いはイメージしやすいかも。（厳密には異なる概念です。あくまでイメージね）

require 'vendor/autoload.php';


$app = require 'bootstrap/app.php';
$app->make(Kernel::class)->bootstrap();

$server = IoServer::factory(
    new HttpServer(
        new WsServer(
            new Chat()
        )
    ),
    8282
);


$server->run();

ここでは、Laravelのメソッドや環境変数等を使うために「require 'vendor/autoload.php'」したり色々やっています。

これを自作artisanコマンド等で、自動実行できるようにするとこの記述は不要になります。

Laravel上で動くようになるからですね。

コードを見ておや？と思った方がいるかもしれません。

WebSocketはHTTP技術を拡張したものなので、HttpServerクラスでListenを行います。

このHttpServerクラスはRatchetで作られたものですが、RequestオブジェクトはPSR-7 HTTP message interfacesで拾うことができます。

従って、その引数に渡しているWsServerインスタンスやChatインスタンスも同様です。

Chatクラスの中身は、公式ページにも記載がある通りMessageComponentInterfaceを実装する形にします。

これを実装することでWebSocketの各イベントが使用可能になります。

今回、私が実装したのは以下の４つです。

  • onOpen() : クライアントから初めてWebSocketに接続された時に発火するイベント
  • onMessage() : クライアントのsend()時に発火するイベント。クライアントにメッセージを返すところまでここで実装する。
  • onClose() : クライアントから切断(close()時、もしくはブラウザの×ボタン押した時)に発火するイベント
  • onError() : WebSocket通信中に何らかのエラーが発生した時に発火するイベント

まとめ

LaravelでRatchetを扱う時は

  • Composerでライブラリをインストール
  • ListenするWebSocketサーバ(クラス)を作る
  • 各イベントを理解する

をわかっていれば実装できると思います。

まだまだ資料は少なめですが、Ratchet関連の解説記事もそこそこあるので、調べたらいくつか出てきます。

今回はここまでです。良きSocketライフを！(笑)

Wizではエンジニアを募集しております。

興味のある方、ぜひご覧下さい。

careers.012grp.co.jp

Webアクセシビリティ検証フレームワーク「acot」を導入してみた。

アクセシビリティ フロントエンド

acotのロゴ画像

はじめまして。フロントエンドエンジニアの内田です。

最近福岡では日中30℃を超える気温でぐったりです。アイスがとろけております。

さて突然ですが、この記事をご覧になっている皆様はアクセシビリティについて悩んだ事はありますでしょうか？

Wizでは残念な事にWebアクセシビリティに対して、まだまだ高水準な品質を維持出来ていないのが現状です。

アクセシビリティとは

どのような環境にいても人々が平等にアクセス可能で、全てのコンテンツや機能が利用できる状態の指標です。

また、似た言葉としてユーザビリティがあります。

ユーザビリティとは

ユーザビリティは、ユーザーにとっての使いやすさを表す概念です。

ここで言う使いやすさとは、ユーザーがストレスを感じない操作性、わかりやすい導線設計を施し、成約に至るまでに必要な労力の少なさなどを指します。


今回はアクセシビリティについてお話させていただきます。


Webアクセシビリティにおいて意識する必要のある代表的なハンディキャップ例としては下記が挙げられます。

■全盲

全盲の方は画面上の文字を音声で読み上げるスクリーンリーダーや点字で表示する点字ディスプレイなどを利用して読み取っていますので画像とテキストの位置関係やどんな画像が表示されているのかが明確に把握できるような工夫をしなければいけません。

■ロービジョン

視力が低下している方や視野が狭くなっている場合（視野狭窄）、視野の真ん中が見えない場合（中心暗点）などの弱視の方を指します。

Webページを利用する際、ロービジョンのユーザーは次のような使い方をしている為、サイズ感やコントラストなどの視覚的表現、視覚以外の方法で情報取得ができる対応が必要になります。

  • 画面拡大ソフトやOSに標準で搭載されている機能を用いて画面表示を拡大する
  • 画面の色を反転する
  • OSやブラウザの設定によって、文字サイズを変更する
■色覚多様性

色の見え方は人によって異なり、その割合は日本人の男性で５％、女性で0.2％と言われています。

よく言われる例だと正常と異常の状態を赤と緑の色だけで表現しているUI等は区別が難しくなります。対応方法としては下記のような配色を目指すべきでしょう。

  • 赤と緑は見えづらいので青やオレンジを使う
  • 色に頼らない、色数を増やさない
  • コントラストを強くしすぎない
■上肢障害

手や腕に障害がある場合はマウスやトラックパッドなどが利用困難でありホバーやドラッグ＆ドロップが難しかったりするのでトラックボールを利用するパターンが多いようです。 なので、クリックポイントを近くしすぎるとトラックボールのほんの僅かな動きで通り過ぎてしまったりするので、リンクやアイコンなどのクリックできる位置をある程度余白をつけて配置する等の配慮が必要です。

■聴覚障害

近年では動画をコンテンツに含んでいる場合がありますが、その動画内で情報説明したりする場合には手話通訳をつけたり、字幕情報を付与したりして併用することが望ましいとされています。

例えば、動画の中で問い合わせ先などを示す場合には、問い合わせ電話番号などを音声だけで伝えず、視覚、聴覚の両方で具体的な情報を提供する必要があります。

また、最近では警告音の見える化などの対応もAppleでは配慮されています。 www.apple.com




ですが、これら全てを意識してエンジニアが対応していくのは困難です。

そこで、W3Cが標準化しているWCAGガイドラインを参照して全世界のエンジニアはこのガイドラインに準じて対応していく事になっているのですが、 このWCAGは正直何書いてるのか把握しづらく、「で？どうしたらいいの？」といった気持ちになる上、達成基準が設けられておりA (最低レベル)、AA、AAA (最高レベル)という基準があり、正直AAAに対応するにはかなりきびしい道のりです...

waic.jp

ではどうするか？

これらの問題を対応しなければいけない事はわかってはいるのですが、全ての項目を一つ一つ把握しつつDevToolsのLighthouseを実行して目視でチェックしていくのは非効率で地獄です。

そこで、弊社では一部メディアにてWebアクセシビリティー検証フレームワークであるacot-a11y/acotを導入してみました。

github.com

導入手順

acot 自体は puppeteer ではなく puppeteer-core へ依存するため、別途インストールが必要な構成となっています。

$ npm i --save-dev @acot/cli puppeteer

インストールが完了したら、以下のコマンドを実行する事で設定ファイルの構築を行うことができます。

$ npx acot init

すると下記のようにコンソール内にて対話形式で設定を進めていくと、acot.config.jsという設定ファイルが生成されます。カンタン！！！

✔ What is the origin for the audit target? · http://localhost:3000
✔ What kind of server do you want to connect to? · command
✔ What is the command to start the server? · npm run dev
✔ Do you want to use the config recommended by acot? · no / yes
✔ Which runner do you want to use? · default
✔ Which format do you prefer for the config file? · javascript
✔ Which is the npm client used to install the dependent packages? · npm

■acot.config.js

module.exports = {
  extends: ['@acot'],
  connection: {
    command: 'npm run dev',
  },
  origin: 'http://localhost:3000',
  paths: ['/'],
};

では早速実行してみましょう！！

$ npx acot run

すると下記のようなサマリーが表示されました。

acotの結果キャプチャ

エラーの数が絶望的ですね。まぁこれは開発途中のものなのでご愛嬌。

さくっとErrorをPassできそうなものとしては@acot/wcag/img-has-nameあたりですかね。

ログを追うと

✖  img element or img role MUST has name.  @acot/wcag/img-has-name
   ├─ <img src="/_next/image?url=%2Fimg%xxxxxxxxxx.png&w=1920&q=75" decoding="async" style="visibility: visible;…
   ├─ at ".contentsBox--keyVisual__img > div > img"
   └─ see https://www.w3.org/WAI/WCAG21/Understanding/non-text-content.html

と表示されており、おそらく画像に対してalt属性による代替テキストの設置、またはロールを付与し忘れるといった基本的な箇所が抜け落ちていたようです。

尚、このときのLighthouseによるアクセシビリティの数値としては87でした。

f:id:romeoromen:20210629014150p:plain

では対象箇所をさくっと修正して再度実行してみます。

f:id:romeoromen:20210629021151p:plain

お！@acot/wcag/img-has-nameが見事Passになりました！🙌🏼

ちなみにLighthouseで再度計測してみたところ指し示した値としては94！！たったこれだけで爆上がり！！

f:id:romeoromen:20210629022056p:plain

今回は単体ページでのチェックとなりましたが、acotのrunnerにsitemapのパスを指定することで複数ページに渡ってチェックしてくれる事も可能です。 ですが、おそらく数百のページを対象としたメディアサイトの場合は相当処理が重くなるかと思いますので要注意です。

module.exports = {
  runner: {
    uses: '@acot/sitemap',
    with: {
      source: 'http://localhost:3000/sitemap.xml',
    },
  },
};

現段階の実行タイミングとしてはプレコミット時等のアクションを検知したオート実行ではなく任意のタイミングで実行する運用方法で対応しています。

まとめ

まだまだアクセシビリティについてはやらなければいけない事が山積みの状況ではありますがこのように一歩一歩着実にPassしていく事で本当のWebの世界というものが広がっていくような気がしてきます。

全世界のなるべく多くのユーザーに正しくわかりやすい情報を伝えていく事が自身の喜びでありWizの目標の１つです。

最後に

Wizではエンジニアとして一緒に働く仲間を絶賛募集しております。

ご興味のある方、是非ご覧下さい..！！

careers.012grp.co.jp

【エンジニア社内LT会】第6回

社内活動 LT会

f:id:nakamoto03:20210628111924p:plain

第6回LT会レポ

今回のLT会の内容は

発表者: 3名

制限時間: 自由

テーマ: 自由

コメントツール：CommentScreen

で行いました。

それでは1つずつ発表を紹介していきます。

技術選定をしてみたという話

1人目の方には「技術選定をしてみたという話」という内容を発表していただきました！

新しいプロジェクトを始めるにあたって、フロントエンドの技術選定を行いその中で学んだことを発表していただきました。

実践した技術選定フローにより、今回行うプロジェクトにあった技術選定、所属しているチームにあった技術選定を行えたようです。

今回行った技術選定フローもスライドの方に記載されていますのでぜひ一読していただけますと幸いです。

React v18 alpha 発表

2人目の方には「React v18 alpha 発表」について発表していただきました！

いくつか機能があったのですが、以下の3つの項目を紹介していただきました。

  • ConcurrentRendering

  • Automatic Batching

  • StrictModeでのuseEffect

EMなった時に感じたしょぼい点

3人目の方には「EMなった時に感じたしょぼい点」について発表していただきました！

EM・・・エンジニアリングマネージャー

以下のしょぼいと感じた点とその点に対しての対応について発表していただきました。

  • 文章がしょぼい

  • スライドがしょぼい

  • 見積もりがしょぼい

  • 自分がやりたくなるのがしょぼい

すべて「うっ。。」となるような内容でした。発表を聞いた方は意識しなきゃと感じたのではないでしょうか。

今までのLT会はこちら~

tech.012grp.co.jp

最後に~

第6回はこのような内容でした。

第10回が近づいてきましたね。何か盛大にやりたいところです。

Wizではエンジニアを募集中です。

興味のある方は是非覗いてみてください!↓

careers.012grp.co.jp

 

様々なコミュニケーションについて〜営業部との違い〜

フロントエンド

f:id:daigo2895:20210618143719p:plain はじめまして！フロントエンドの久保です。

今回は【営業部 → エンジニア】へジョブチェンジした話を実体験に基づいて書いていきたいと思います。

ジョブチェンジの経緯

単刀直入にいうと新型コロナウィルスです。
今、どういう事？？と思いましたよね。笑

正確には在宅ワークになり自分の時間が増えたとき、ふと自分の人生設計について考え直したのがキッカケとなります。

営業をバリバリやっていた自分に「本当は何がやりたいの？」と聞きました。
すると「WEBサイトを作りたい」と返ってきました。

はい。すこし誇張しました。

異動して感じたすごいこと（本題）

ズバリ、『コミュニケーション』です！！！

どういうことか、大きく３つのすごいをまとめました。

① 心理的安全性の高さがすごい

② アウトプット力がすごい

③ 情報や技術の共有力がすごい

１つ１つ営業部との違いと共に解説させてください。

① 心理的安全性の高さがすごい

営業部時代は、
基本的に担当商材が決まっていて、それを日々販売するという毎日でした。 大きく商材が変わらないのと、大切なお客様を相手にしていますので、あまり挑戦的な試みというのが出来ませんでした。
また、個人的にどうしても役職が上の方には頻繁に質問をしづらく、同僚内で解決するループもありました。
今思うとまだまだ関係値(心理的安全性)が出来ていなかったのかもしれません。


対してTech事業部では、
異動した初日に上司から『上司と部下はリーダーとメンバーという風に置き換えてほしい』と言っていただきました。
違いを体感で説明すると、「上下関係」から「先輩後輩」になったみたいな感じです。(感じてください。)
※もちろん営業部が上下関係厳しいとかいう話ではないですよ！

組織内では雑談の時間もかなり大切だという共通認識があり、そこから生まれるものの価値を重視しています。
また、定期的に交流する時間も設けており、趣味や好きなことを通して色々な人と距離が縮まります！ 僕もおすすめの椅子ありますか？とかプロテインはこれ飲んでますとか話しかけてます笑

現在oViceというバーチャルオフィスで働いているのですが、驚くことに出社していたときよりもコミュニケーションが密接になりました。
どんな意見も尊重して「いいねそれやってみよう！」という文化が当たり前のようにそこにあるので、新人の僕でもガンガン意見や質問が出来る安心感がありとてもいい環境だと思いました。
馴れ合いではなく、「互いにリスペクトしている仲の良さ」というのがポイントです。

② アウトプット力がすごい

営業部時代に何をアウトプットしていたか考えましたが、
びっくりすることに答えが出てきませんでした・・・。（サボってはいません笑）

どちらかといえば人それぞれのインプットをし、自分なりの成功体験を元に感覚で受注を取っていた気がします。
お客様(外部)へ情報のアウトプットをしていたということですね！


対してTech事業部では、
定期的に組織内(内部)でアウトプットタイムというものがあります。
そこでは技術的な事、マインド的な事、とにかく吸収したことを他者へ説明するというものです。

アウトプットすることで本質的に理解していない部分などが自然と見えてきます。
更に定期的に行うことによってアウトプットが習慣化されます。
結果、自主的にアウトプットをし合う文化が出来上がっています。

③ 情報や技術の共有力がすごい

これが１番文化の違いを感じ、衝撃を覚えました。
営業はある種格闘技で、もちろん全てではないですが数字に左右される毎日でした。
プレイヤーごとに自分なりの型を持っており、弱肉強食な世界でもあります。
自らアウトプットするというよりは、強者の分析をし真似をする文化のほうがあります。
この力もすごく重要なんですけどね！


Tech事業部では
面白そうな記事があれば都度slackで共有し、情報共有やアウトプットをすれば共有アプリに蓄積する。
さらには過去の話題でも簡単に検索出来るように種類分けされているので、どのタイミングで入ってきても同じ情報を取得出来ます。
これは営業部にはなかった衝撃的な文化であり、すごくありがたいものでした。

営業部時代の自分が気づけなかった、どこかもどかしい感覚はここに答えがありました！

最後に

いかがでしたでしょうか！
ご覧の通りフロントエンドチームでは互いをリスペクトし、助け合う文化が強く存在しています。
この記事を書いて、営業部とエンジニアの両方の目線を持つ自分だから出来ることが見えた気がします。
それは営業部とエンジニアを繋ぎ、お互いの文化の良いところを組織に反映させていくといった「架け橋」になっていくことです。
まだまだエンジニアとしては未熟ですが、この素晴らしい文化の中で成長し、Wiz全体を前進させていけるように頑張っていきます！

そして…

Wizではエンジニアを募集しております。
興味のある方、ぜひご覧下さい！

careers.012grp.co.jp