リモートワーク環境における社内コミュニケーションのくふう

Da Vinci Studio サーバー部の伊藤です。今回は Da Vinci Studio の社内コミュニケーションについて紹介したいと思います。

まず初めに、現在の Da Vinci Studio の働き方は、基本的に全社員リモートワークとなっており、必要に応じてメンバーが出社しています。

とはいえ、ほとんどのメンバーがほぼフルリモートな状態かなと思っております。

東京に本社がありますが、メンバーの中には関西からリモートワークしている人もいます。

そんなリモートワーク環境下で行われている、社内コミュニケーションについていくつか取り上げようと思います。

よもやま

リーダー以上の人とそのチームメンバーで、評価とは関係のない雑談を1対1で行うような時間を取っています。評価に関わる面談とは違い、気軽に自分が思っていることを話したり相談できたりする場です。

頻度や時間はチームによってそれぞれですが、最近あったことや困りごとなどを話していることが多く、仕事以外のことを話すこともあります。

自分自身の状態の整理につながったり、プライベートや業務に関係なく、こういうことをやってみるといいのでは？というアドバイスをいただけたりもするので、個人的にはとてもありがたいなと感じている文化の1つです。

Discordのようなコミュニケーションツールを利用

冒頭にも書いたとおり、現在のDa Vinci Studioではほぼフルリモートで働いているメンバーばかりです。

出社していた頃とは違い、ちょっと近くにいる人に質問してみたり、雑談してみたりということが難しい状態になっています。

そこで、サーバー部ではDiscordというコミュニケーションツールを使うようにしています。 Discordでは音声での会話はもちろん、画面共有もできるので、困っている部分を共有しながらペアプロしたり、時にはモブプロなような状態で開発することもあります。

オンラインになるもならないも特に縛りはないので、出社している時の気軽に相談できるような状態は作りつつ、抜けたい時に抜けて自分の作業に集中もでき、個人的には良いとこ取りをしているなと思っています。

2週に1回の井戸端会議(いどばた！)

「いどばた！」は日頃なかなかできない議論を部をまたいでディスカッションするための場として設けられています。

お題を集め、5名程度のメンバーがランダムで選ばれ、そのお題について話しているのを自由に見聞きできます。

直近では、ランダムに3~4名程度でグループ分けを行い、それぞれで雑談するというような方法も試しています。自分のグループでは美容室の話や、買い物などで獲得できるポイントについての話で盛り上がりました。

Slackチャンネルの利用

テキストコミュニケーションについては、Da Vinci StudioではSlackというメッセージツールを利用しています。

各メンバーは分報チャンネルを作成しており、メンバーによって投稿頻度は変わりますが、業務についてや自分が得た知見、今日お昼に何食べた、今夜はお酒が飲みたいなどジャンル問わず様々なつぶやきをしています。

業務や知見についてつぶやいていると、直接その業務とは関わりが無い人からの知見が入ってきたり、なんとなく状況を察知して助けのメッセージが来たりとリモートワークで直接姿が見えない部分を補うようなことも発生しています。

出社していた時に先輩や同僚などが自席付近を通りがかった時に、困っていそうな雰囲気を見て相談に乗ってくれるという状況に近く、これが結構良いなと思っています。

他にもSlackではメッセージに対してリアクションを付ける機能があり、"GJ"というGood Jobの意味を持つリアクションを追加しています。

リアク字チャンネラーアプリとの連携で、"GJ"のリアクションが付いたやり取りは、good-jobチャンネルに転載され、良い仕事をしてるというやり取りが共有されるようなくふうもしていたりします！

リモートでもリモートでなくても見えにくい他の人の動きが見えるのはもちろんのこと、自分のやり取りに"GJ"が付くと気分がいいです(笑)

相手が見えづらいリモートワークだからこそ、リアクションでの感情の表現や文面での何気ないやり取りって大事だなと感じている日々です。

さいごに

今回は社内でのコミュニケーションを取る方法として取り組んでいる事例を紹介をしました。

また、Da Vinci Studioデザイン部が発信するnoteやサービスの開発ストーリーもあるので、こちらも読んでみてください。

Da Vinci Studio では一緒に働く仲間を絶賛募集中です。興味のある方は recruit@da-vinci-studio.net までご連絡ください。

2022-09-13

Slackに定期投稿してくれるBotをGASとSlack APIで作成してみた

こんにちは。 Da Vinci Studio サーバー部の長嶺です。

当社ではチャットツールとして Slack を利用しています。Da Vinci Studio のワークスペースにも多くの Slack Bot やアプリが追加されており、日々の小さな雑務を自動化しています。会議の定期連絡など、普段手動で行っている小さなタスクは自動化してしまうことで、うっかり忘れてしまうことも防げるようになり、さらに本来そのタスクに使っていた時間を別の作業に利用できます。

Bot そのものを実装するのにある程度の時間はかかりますが、実装にかかった時間以上に大きな恩恵を受けることができると思います。

そこで今回は、毎週の会議の前にファシリテーターと議事録担当者を通知してくれる Slack Bot を作成したので紹介します。 GAS(Google App Script) と Slack API, Google スプレッドシートの3つを用いることで簡単に作成ができます。

作成したもの

毎週の会議の前にファシリテーターと議事録担当者をお知らせしてくれる Bot です。プロジェクト参加メンバー内で役割をローテーションしており、次回の各自の担当を Slack メンションで教えてくれます。

手順

大まかな手順は以下です。

Slack App の作成
GAS Script の作成
GAS へ Slack App ライブラリを導入
GAS から Slack API を叩く
GAS を定期実行するトリガーの追加

Slack App の作成

まずはじめに、Slack apiのページから「 Create an App 」をクリックし、 Slack App を新規作成します。

クリックするとモーダルが出現します。今回は From scratch を選択します。 From an app manifest をクリックすると、アプリの構成を YAML 形式で記述できるようです。manifest は Slack アプリの設定のようなものだそうです。

アプリの名前と、 Slack ワークスペースをそれぞれ入力し、「 Create App 」をクリックしてアプリを作成します。

アプリを作成すると、基本情報が表示されるページへ遷移します。次に、アプリに Slack ワークスペースを操作するのに必要な権限を与えてあげます。サイドバーから OAuth & Permissions を選択し、権限設定ページを開きます。

下にスクロールし、 Scopes の設定項目へ行きます。 Bot Token Scopes の項目に設定を追加します。「 Add an OAuth Scope 」のボタンをクリックし、 chat:write を選択し追加します。これで、チャンネルへのメッセージ送信の権限が与えられました。

※Bot Token Scopes と User Token Scopes の項目があるので注意してください。今回設定を追加するのは Bot Token Scopes の方です。

ワークスペースにアプリをインストールします。同ページの1番上に戻り、「 Install to Workspace 」をクリックしてください。すると、 Slack の連携確認画面へ遷移します。

内容を確認して問題がなければ、「許可する」をクリックします。これでワークスペースへのインストールが完了です。

連携が完了すると再び OAuth & Permissions の画面へ遷移します。そこで Bot User OAuth Token が発行されているかと思います。これは後ほど GAS Script の方で使用しますので、コピーしておいてください。

アプリに与える権限を変更するたびに、ワークスペースへの再インストールが必要となります。再インストールするたびに Bot User OAuth Token も変更されるため、トークンを利用している箇所は更新してあげる必要があります。

GAS Script　の作成

次に GAS Script を作成していきます。今回は、データを Google スプレッドシートで管理したいため、はじめにスプレッドシートを新規作成します。

保存したいデータをスプレッドシートに入力します。 1行目をヘッダ(カラム名)、2行目以降をレコードとして扱っています。今回は通知させたい Slack ユーザーのメンバー ID , 定例での役割(ファシリテーター、書記など)、名前を保持しています。

続いて、GAS Scriptを作成します。「拡張機能」から「 Apps Script 」をクリックします。クリックすると、 Apps Script のページが開かれ、 GAS が作成されます。

GAS の コード.gs 内にコードを記述します。スクリプトの中身全体はこんな感じです。リファクタリングの余地が多々あるところはお許しください🙏

function getFacilitator(ranges) {
  const facilitator = ranges.find(range => range[1] === 'facilitator');
  return facilitator[0];
}

function getSecretary(ranges) {
  const secretary = ranges.find(range => range[1] === 'secretary');
  return secretary[0];
}

function updatePosition(sh, ranges) {
  const position = ranges.map(range => [range[1]]);
  // 書記→ファシリ→休みの順番で巡回
  const lastPosition = position.pop();
  position.unshift(lastPosition);
  sh.getRange("B2:B4").setValues(position); // 定例参加メンバーが変わったらここの範囲を変更する
}

function sheet() {
  const ss = SpreadsheetApp.getActiveSpreadsheet();
  const sh = ss.getSheets()[0];
  return sh
}

function getMessage(ranges) {
  const facilitator = getFacilitator(ranges);
  const secratary = getSecretary(ranges);
  return `次回定例\nアジェンダ作成＆ファシリ: ${facilitator},\n 議事録: ${secratary}`;
}

function postSlackbot(message) {
  //SlackAPIで登録したボットのトークンを設定する
  let token = "xoxb-xxxxxxxxx-xxxxxxxxx-xxxxxxxxxxxx";
  //ライブラリから導入したSlackAppを定義し、トークンを設定する
  let slackApp = SlackApp.create(token);
  //Slackボットがメッセージを投稿するチャンネルを定義する
  let channelId = "#slack_channel_name";
 
  //SlackAppオブジェクトのpostMessageメソッドでボット投稿を行う
  slackApp.postMessage(channelId, message);
}

function main() {
  const sh = sheet();
  const ranges = sh.getRange("A2:B4").getValues(); // 定例参加メンバーが変わったらここの範囲を追加する
  const message = getMessage(ranges);
  postSlackbot(message);
  updatePosition(sh, ranges);
}

処理の流れとしては、以下のようになっています。

スプレッドシートを読み込む
ファシリテーターと書記のメンバーを選出
Slack へメッセージを送信
シートを更新

GAS へ　SlackApp ライブラリを導入する

GAS から Slack API を叩くには、 SlackApp のライブラリを導入すると簡単にできます。サイドバーのライブラリ(+)をクリックします。

スクリプトIDの入力を求められるので、

SlackApp のスクリプト ID：1on93YOYfSmV92R5q59NpKmsyWIQD8qnoLYk-gkQBI92C58SPyA2x1-bq

を入力して、「検索」をクリックしてください。

すると、 SlackApp が検索されるので、最新のバージョンであるかを確認し、「追加」をクリックします。今回はバージョン22を利用します。

AppSciprt のエディタページサイドバーのライブラリの下に SlackApp が追加されていることが確認できるかと思います。これでライブラリの導入は完了です。

Slack API を叩いてチャンネルにメッセージを送信する

GAS で以下のように記述すると、 SlackApp ライブラリ経由で Slack API を叩いてメッセージを送信できます。

前提として、 SlackApp が作成されており、アプリに必要な権限が与えられていることが必要です。 token には、 SlackApp をインストールした際に取得した Bot User OAuth Token を入力してください。

初回実行時に「承認が必要です」と確認を求められることがあると思うので、その場合は権限を確認して許可をしてください。

function postSlackbot(message) {
  //SlackAPIで登録したボットのトークンを設定する
  let token = "xoxb-xxxxxxxxx-xxxxxxxxx-xxxxxxxxxxxx";
  //ライブラリから導入したSlackAppを定義し、トークンを設定する
  let slackApp = SlackApp.create(token);
  //Slackボットがメッセージを投稿するチャンネルを定義する
  let channelId = "#slack_channel_name";

  //SlackAppオブジェクトのpostMessageメソッドでボット投稿を行う
  slackApp.postMessage(channelId, message);
}

Slack 側ではチャンネルにアプリを追加する必要があります。 Slack でアプリを検索し、「チャンネルにこのアプリを追加する」から追加したいチャンネル名を選択して、アプリを追加してください。

GAS を定期実行するトリガーの追加

ここまでの実装で、GAS から Slack の特定チャンネルへメッセージを送信できました。今回は定例の前にメッセージを送信してお知らせして欲しいので、このコードを定期実行させたいです。

これは GAS のトリガーを設定してあげることで実現できます。 GAS エディターページのサイドバーからトリガーを選択します。

ページ右下にある「トリガーを追加」をクリックし、トリガー追加モーダルを表示します。

今回実行して欲しい関数は main なので、 main を選択します。実行するデプロイは Head のままで大丈夫です。

「イベントのソースを選択」で「時間主導型」を選択すると、時間ベースのトリガーのタイプを選択するフォームが出現します。今回は週1回のペースで通知して欲しいので、「週ベースのタイマー」、「毎週火曜日」、「午後3~4時」を選択します。

最後に「保存」をクリックすることで、トリガーの設定が完了です！

これで、Slack チャンネルに定期通知してくれる Bot を作ることができました！🎉

さいごに

GAS(Google App Script) と Slack API, Google スプレッドシートの3つを用いた Bot の作成について紹介しました。定期的にリマインドしたい、カレンダーと連携したい、などの需要がある場合にこの Bot を作成すると、効果が得られそうです。スプレッドシートでデータを管理できるので、メンバーに変化があった際も操作しやすいですし、社内のメンバーが触れる場所に置いておけるのも良いところだなと思いました！普段タスクに起こすほどでもないけど地味にやっている小さい業務などは自動化のチャンスなので、機会があれば取り組んでいきたいです。

なお、Da Vinci Studioでは本ブログの他、デザイン部が発信するnoteやサービスの開発ストーリーもあるので、こちらもぜひ読んでみてください。

Da Vinci Studio では一緒に働ける仲間を絶賛募集中です。興味のある方はこちらか recruit@da-vinci-studio.net までご連絡ください。

2022-09-05

シノニム辞書追加による検索機能改善

Da Vinci Studio サーバー部の吉延です。今回は社内ドキュメント管理ツールで行った検索機能改善の方法について説明します。

背景

くふうグループ内では社内ドキュメント管理ツールとして Da Vinci Studio が自社プロダクトとして開発している kajero (エスペラント語でノートと言う意味) が使用されています。kajero では全文検索エンジンとして Amazon OpenSearch Service を使用しており、社内から出る様々な要望を聞きながら機能改善をしています。ある日採用に関わる方から「'ジョブポスティング'というワードを'ジョブポス'で引っかかるようになれば嬉しい」という要望がありました。そこで今回はその要望を満たすために行ったシノニムの追加による検索機能改善について書こうと思います。

シノニムとは

シノニムは日本語で類義語という意味でワードをグルーピングしてそれらのワードであればどのワードでもヒットさせるようにします。今回の例でいうとジョブポスティング・ジョブポス・ジョブがそれぞれのワードでヒットされるようにします。

シノニムの追加の方法について

シノニムを追加する方法としてインデックスベースとファイルベースの2種類あります。インデックスベースはインデックスに直接シノニムを書き込む方法です。一方でファイルベースはシノニムをテキストファイルに書き込み、そのファイルをインデックスに登録する方法です。インデックスベースは辞書の管理が大変でしたが、2020年4月21日から Amazon OpenSearch Service でファイルベースのシノニムユーザー辞書などに対応するカスタムパッケージが利用可能になっている(Amazon Elasticsearch Service がカスタム辞書ファイルをサポート開始)ということだったので今回はファイルベースでシノニムを追加しました。

辞書について

まず .txt 形式シノニムファイルを用意します。シノニムの書き方は以下のように類義語をカンマ(,)区切りで記入します。

ジョブポスティング, ジョブポス, ジョブ

登録方法

続いて上の工程で作成したファイルを対象の Amazon Simple Cloud Storage(AWS S3) バケットにアップロードします。次に Amazon OpenSearch Service にアクセスし、パッケージのページからパッケージのインポートを行います。パッケージとは AWS S3 にアップロードしたシノニムファイルのことです。

インポートが完了すると、一覧画面に登録したパッケージの情報が追加されます。パッケージの情報ができたらパッケージの詳細ページからパッケージとドメインの関連付けを行います。次に「ドメインへの関連付け」から関連付けたいドメインを選択し関連付けます。最後に関連付けられたドメイン情報から関連付けのステータスがアクティブになっていることを確認します。リファレンスパスは後ほどインデックスの設定で使用します。

インデックスの設定

まずシノニムを適用していないインデックスで検索結果がどのようなものになるか確認してみます。画像のようなインデックスを作成し、

ジョブポスティング、ジョブポス、ジョブの文字列が書かれているドキュメントを用意してみます。

検索するとジョブポスティングのクエリの場合はジョブポスが書かれたドキュメントがヒットしないことがわかります。逆もまた然りです。

それでは先程設定したパッケージを紐付けたインデックスを作成してみます。 synonyms_path には上記で作成したリファレンスパスを記述します。シノニムの詳しい設定方法は Synonym token filter を参照してください。

検索してみると、ジョブポスティングというクエリでジョブポスやジョブが書かれたドキュメントがヒットするようになりました！

インデックスは更新できないので、インデックスの設定を変更する場合はインデックスを新規作成する必要があります。すなわち、シノニムの追加や内容更新をする場合は、インデックスを新規作成する必要があります。

インデックスの作成は上記の方法で行ったので、残り必要な工程は

元インデックスから新インデックスにデータをコピーする(ドキュメントの再インデックス)
webアプリケーション側で新インデックスを参照するようにする

を行う必要があります。

ドキュメントの再インデックス

ドキュメントの再インデックスには時間がかかる場合があり、その間に登録されたドキュメントが新インデックスに登録されないという事態をなるべく避けるため、サービスログ等からアクセス頻度が低い時間帯に行う必要がありますので注意してください。ドキュメントの再インデックスは以下のようなリクエストで行うことができます。 source には元インデックス名、 dest には新インデックス名を指定します。詳しくは Reindex API を参照してください。

POST _reindex
{
  "source": {
    "index": "pages_production"
  },
  "dest": {
    "index": "pages_production_20220620"
  }
}

これで後は参照するインデックスを変更すれば作業は完了になりますが、インデックスを更新する際にデータ破損や障害発生によりインデックスの切り替えが失敗するリスクを回避するためスナップショットからの復元方法も事前に調べておくとよいです。Amazon OpenSearch Service ではスナップショットを2週間前まで1時間ごとに自動で取得してくれています。下記のリクエストでスナップショットのデータを確認できます。

GET _snapshot/cs-automated/_all

上記の結果から復元したい時点のスナップショットデータと復元したいインデックス名を指定することで復元できます。

POST /_snapshot/cs-automated/スナップショットデータ/_restore
{
  "indices": 復元したいインデックス名
}

終わりに

今回は初回ということもあって手動でシノニムを追加しました。今後はシノニムの内容の増加やインデックスの作成や再インデックス、インデックスの切り替えなどが自動化できるとより使いやすいシステムになっていくと思っています。

Da Vinci Studio では一緒に働ける仲間を絶賛募集中です。興味のある方はこちらか recruit@da-vinci-studio.net までご連絡ください。

2022-08-31

「セキュリティ人材の会」の活動紹介

Da Vinci Studio インフラ基盤部の坪井です。当社では、セキュリティ人材の会というセキュリティを学び実践する会が存在します。活動を始めて1年半以上が経ちました。この会で行ってきたことを紹介したいと思います。

活動概要

CEO吉川を含めアプリ開発、バックエンド開発、SREと社内各部から1〜2名の計8名で構成されています。活動の趣旨は、この会を通じてWeb開発に携わる身として、セキュリティに詳しい人材となって活躍していくことを目指しています。最近ではくふうカンパニー法務部のメンバーも加わり活動に幅で出てきました。

活動内容

会の立ち上げ以降、月1回のペースでリモート開催しています。これまで1年半の活動において学習と実践的な活動へと移行してきました。

学習フェーズ：2021年1月〜 2021年12月
実践フェーズ：2022年1月〜

学習フェーズ（2021年1月〜2021年12月）

毎回1〜2名が最近気になる技術や事例について調査および発表し、内容について話を深堀りしていくという活動を続けてきました。

発表テーマの一例
- 認証認可とOauth2.0
- 脅威モデリング( STRIDE )について
- 解析ツールを使ってハッシュ値から元の文字列を復元
- JWTによるセッション管理
- 脆弱性検査ツールについて

筆者はこの会で初めてJWTを知りました！

自分が担当する領域以外の技術に触れる事でセキュリティに関する知見が得られたと思います。テーマについて個人が発表するだけでなく、「セキュアな設計または実装をするにはどうしたら良いのか？」というテーマについて、グループワークを行いました。アプリケーションとインフラストラクチャーの観点で何ができるだろうか？という視点で自由に出し合いました。その後、付箋を確認しながら、具体的にはどういうことだっけとか、他にもこういうことがあるよねなどざっくばらんに話し合いました。

余談ですが、とあるプロジェクトにてこのグループワークで話し合った内容を実装に取り入れたというフィードバックを聞いて、活動の意義を見いだせてきた気がしました。

実践フェーズ（2022年1月〜）

社内開発サービスへの検査の実施

翌年から学習だけでなく実践的な活動への取り組みを開始しました。この頃、Da Vinci Studioで開発したKotorにセキュリティ検査を実施し、検査結果レポートを作成して開発チームへフィードバックしました。KotorはiOSとAndroidのネイティブアプリとバックエンドで構成されています。セキュリティ人材の会は、各部のエンジニアで構成されており、自分たちで検査可能なツールを検討し実施しました。

Amazon ECR enhanced scanning
OWASP ZAP CLIとTrivyを利用した脆弱性検査
OWASP MASVSに沿ったセキュリティレベル要件のチェック
アプリのリバースエンジニアリングと静的解析（Mobile Security Framework）

社内の他サービスに対して日常的に利用しているものから、今回始めて利用したツールまでありました。ここでは詳細は割愛しますが、検査の結果、利用ライブラリーに重大度が高いCVEが検出されました。ネイティブアプリの静的解析のスコアも低かったので、チームへのフィードバックを通して改善してもらっています。

インシデント発生のロールプレイング

グループ内で発生したインシデントを題材に挙げ、その際行われた対応履歴を元に「良かった点」「ここはこうすればよかった点」などを議論しました。この会の後、社内インシデントを想定したロールプレイングを実施しました。とあるAWSリソースの費用が急激に高くなっている事をきっかけに、その謎を紐解いていくという内容です。

ボードゲームを通じた体験学習

IPA(情報処理推進機構)が提供しているボードゲームがあるということが話題に挙がったので、希望者向けにCSIRTの活動を体験してみる会を実施しました。現在IPAから提供されているボードゲームは以下の3つです。（CSIRTとは「Computer Security Incident Response Team」の略語で、「シーサート」と読みます。「コンピュータに関するセキュリティ事故の対応チーム」の事を表します。）

この内、ABCIRTとマルウェアスイーパーの2つを社内で体験してみました。ABCIRTは、工業部品を販売する会社のCSIRTメンバーとして、月曜日から金曜日までの1週間、インシデントへの対応を行ないます。1日の工数は8hと限られており、工数内で必要と判断した取り組み対応カードを選択し、ポイントの合計点を競うゲームです。対応カードは0〜100ptのポイントが割り振られています。1日の対応を選択し終わった後に、カードを裏返してポイントを確認していきます。月曜日から木曜日の間の1日のみ残業が可能であり、工数を6h増やすことができます。金曜日は、今までの状況を整理して振り返りを行う日です。

2チームに分かれ点数を競ってもらいました。

今回は、Bチームの勝利です。0ptの対応カードを選ばず着実にポイントを増やしていったのが勝負の明暗を分けました。Bチームはセキュリティ人材の会のエンジニア2人なのでさすがと言ったところです。

毎日の行動を意思決定していくというゲーム性が非常にシンプルでわかりやすかったです。誤った選択をした場合は、大きく時間を割かれてしまうので、現実の世界でインシデントが発生した際は、その時々において何が最適な行動か判断していくことが重要だという事が学べたと思います。ABCIRTは体験者に好評でした。日頃、業務でセキュリティに触れる機会が無い人たちにとっても有意義な体験となったと思います。

筆者は３つのボードゲーム全てを何度か体験しましたが、どれも学びがある内容でした。このようなゲームを通じて体験をすることで、セキュリティ意識を高められる活動を今後も続けていきたいと思います。新卒研修に取り入れる事も検討しています。

最後に

発足当初は、書籍ではセキュリティ対策を読んだことがあるけど、実務では経験したことが無いというメンバーが多かった中、いまでは安全にアプリケーションを作るにはどうしたらよいか、運用するためにはどうしたらよいかという意識が実務でも活かされるようになり、会のメンバーを頼もしく感じます。これからも粛々と活動していくと共に、セキュリティ意識を高めていく活動を、Da Vinci Studio全体へ、ひいてはくふうカンパニーグループへ波及させていく事が今後のミッションです。

セキュリティ人材の会、いかがでしたでしょうか。Da Vinci Studio は、くふうカンパニーグループの開発会社です。グループ内外の受託開発の他、自社でもサービス開発に取り組んでいます。わたしたちが携わったサービスを安心して利用してもらえるよう、これからも活動を続けていきたいと思います。 Da Vinci Studio では一緒に働ける仲間を絶賛募集中です。興味のある方はこちらか recruit@da-vinci-studio.net までご連絡ください。

2022-08-26

エンジニア採用における面接初心者の心得3か条

Da Vinci Studio 第 2 サーバー部の冨田です。

唐突ですが、「Da Vinci Studioでは一緒に働く仲間を大募集しております！」 Da Vinci Studioに興味のある方はこちらか recruit@da-vinci-studio.net までご連絡ください。（いきなり宣伝すみません）

上記のようにDa Vinci Studioでは積極的に採用活動をしているのですが、最近私が1次面接を担当させていただく機会が増えてきました。その中で採用面接初心者なりに気をつけた方が良いことや感じたことなどがありますので、お話しさせていただければと思います。

エンジニアの採用を担当している方やエンジニアとして採用されたいと思っている方のお役に立てれば幸いです。上記に当てはまらない方でも読んでいただければ、ブログ更新の励みになりますので何卒よろしくお願いいたします！

1次の採用面接について

ではそもそもDa Vinci Studioの採用面接がどんな流れで行われているかというと

自己紹介
会社紹介
コーディング試験
質疑応答
逆質問

上記のような順番で行われております。（2022年7月現在）
あまり他社でのエンジニアの採用面接フローを知らないのですが、そこまで変わった流れではないのかなと思っております。
参加するメンバーは、
面接者：２人（私・上司）
候補者：１人
になっております。
ただ、私は人とお話しするのがあまり得意ではない上に、進行役もこなさないといけないため、最初の頃は候補者の方以上に緊張してました（笑）
とはいえ、回数をこなすうちに気をつけた方が良いこと3つがみえてきたので、その件について今回はお話しいたします！

1. 頑張りすぎないこと

1つ目の気をつけた方が良いことは頑張りすぎないことです。
採用面接も立派な仕事なのに頑張りすぎない？コイツ何言っているんだろう？って思いますよね（笑）
きちんと理由はあるんです。
それは候補者の方にも背伸びするわけでもなく、緊張して実力が発揮できないといったことがないようにしてもらいたいからです。
私は面接者と候補者って鏡だと思うんですよね。そのため私（面接者）が緊張していると候補者も緊張すると思っています。
実際に私が初めて1次面接を担当した時には非常に緊張しておりましたし、なんとか話しやすい雰囲気にしようと頑張っておりました。結果としてはそれが空回りしており、候補者の方も非常に話しづらそうで、面接後のフィードバックでも上司から雰囲気が良くなかったことを指摘いただきました。
そのため、私は頑張りすぎて焦るより、頑張りすぎずにリラックスして、自分のできる範囲で面接をしていきたいと思っています。結果として候補者の方もその方が自分らしくお話しできるのかなと思っています。

2. 採用面接しすぎないこと

2つ目の気をつけた方が良いことは採用面接しすぎないことです。
採用面接するのに採用面接しすぎない？コイツ何言っry
これは面接者と候補者でお互いをよく知るために対等に進めたいと思っているからです。
面接の際に面接者と候補者って下手すると上下関係になりかねないのかなと思っています。
面接者が候補者の合否を決めるので、面接者が候補者より上のように感じる方が、どちらの立場でもいらっしゃるのかなと思います。（本当はそんなことないです）
余談ですが、これは学生生活が影響していると思うんですよね。先生と生徒みたいな形が面接者と候補者に近い気がして、採用面接にも影響しているのかなと。
私は採用面接はお互いを知る場だと考えているので、上下関係とはいえなくてもそれに近いような認識で進めてもお互いを知ることができないのではないかと思っております。
そのため面接者と候補者を対等な関係でに進められるように、「採用面接」感を全面に押し出す（会話をせずに質問を多くするなど）ことはしない方が良いのではないかなと思いました。

3. 面接者として候補者の方を適切に評価できるようにすること

3つ目の気をつけた方が良いことは面接者として候補者の方を適切に評価できるようにすることです。
質問を投げかける際の例としてあげますと、
NG：「自動テストは書けますか？」
OK：「この実装に自動テストを書くとしたらどう書きますか？」
NG：「リーダー経験はありますか？」
OK：「リーダーシップを発揮した経験についてご説明お願いします」
となります。
NGの場合は候補者の方がなぜそれができると考えたのか、面接者からするとわからないため、評価しづらいですが、OKの場合は具体的な行動を聞いており、それに対して自動テストやリーダーとして、できているかどうかを面接者が判断できるためです。
まとめると候補者による自己評価を聞くのではなく、面接者である自分が評価できる候補者の行動を聞けるとよいと思います。
正直これは1や2よりもさらに難しいのではないかと思います。(少なくとも私は3に一番苦戦しています)
それでも意識していくとだんだん良くなっていくと思うので是非是非試してみてください！

終わりに

今回はDa Vinci Studioで、最近1次面接を担当させていただいている私が気をつけていること3つをご紹介させていただきました。
私が考える採用面接で大事なことは、

候補者の方にDa Vinci Studioやその社員を知ってもらうこと。
面接者が候補者について知ること。

です。これらができるように３つを気をつけておりますので参考になれば幸いです！

また、最後にしつこいようですが、大事なことなので宣伝させてください（笑）
そんなDa Vinci Studioでは一緒に働く仲間を絶賛募集中です。
興味のある方はこちらか recruit@da-vinci-studio.net までご連絡ください。

2022-08-03

AWS JumpStart にサーバー部7名で参加した話

Da Vinci Studio 第 2 サーバー部の桃原です。 6月16〜17日開催の AWS JumpStart という初学者向けのワークショップに参加したので、内容や学んだ事をまとめていきます。

AWS JumpStart について

今回参加した AWS JumpStart は AWS 初学者のエンジニアを対象とした実践的なプログラムです。単なるAWSサービスの学習だけでなく、要件に合わせて適切なアーキテクチャを検討・設計する経験を積む部分にフォーカスした内容です。

参加の経緯

弊社のインフラは AWS をメインとして使っているのですが、インフラ基盤部とやりとりする際のサーバー部の AWS 知識量の差が課題に挙がっていました。ちょうどそのタイミングで AWS の方からワークショップの案内があったので、サーバー部のメンバーが上司に確認したところ希望者は業務時間内で参加させてもらえることになり、サーバー部から7名が参加してきました。

事前準備

イベント開催前に事前学習として2つで合計3時間半の動画を共有していただきました。どちらの動画も分かりやすく AWS やアーキテクチャ設計について網羅的に学ぶ事ができました。 1つ目の動画では、機能要件と非機能要件についての説明の後、アーキテクチャ設計で意識すべき観点についての内容でした。 2つ目の動画では、よく使われるサービスについて学ぶ事ができました。

イベントの概要

イベント当日にも軽い事前学習動画の振り返りがあり、その後に4人チームに別れてアーキテクチャ設計を行なっていきました。このアーキテクチャ設計がメインコンテンツで、2日目には発表会もあり、他のチームが設計したアーキテクチャ図を見ることもできました。

ハンズオンもあり、AWS コンソールを使って予め用意していただいた単純なアーキテクチャ図から実際にアプリをデプロイしてみたり、可用性の確認のために RDB をフェイルオーバーさせてみたりしました。「設定次第では高い料金が発生してしまうかもしれない」や、「1年の無料枠をまだ使いたくない」等のハードルがある方には貴重な経験になるかと思います。

チームでのアーキテクチャ設計

流れやチームの雰囲気

アーキテクチャ設計の時間では4人のチームに振り分けられ、チームごとに AWS の会議ツールの Chime でワークショップを進めました。普段の業務では通話のみという方が多かったので終始ビデオオフでしたが、自己紹介の時から発言も多く、楽しく議論しながら進める事ができました。アーキテクチャ設計にはホワイトボードツールの BlueSpace を使いました。よく使われるサービスのアイコンが準備されていたので、すぐに設計に取り掛かる事ができました。 AWS の方に20分×3回質問したりフィードバックをいただけるオフィスアワーという時間があったので、疑問を解消できたり新しい発見がありました。

要件

アーキテクチャ設計をするにあたって、サービスやシステム要件の説明がありました。

LINEのようなチャットサービス
想定提供規模
- 平均チャット流量: 500re/sec
- メッセージ保存期間: 1年
- ピーク時間帯: 日本時間の夕方
- 提供エリア日本: 日本
- 提供プラットフォーム: web
必須機能
- チャット機能
  - 数秒以内のリアルタイム性
- 友達管理/グループ管理
- 画像/動画
オプション機能
- 通知
- 既読管理
- スタンプ
- チャット検索

アーキテクチャ設計とオフィスアワー

アーキテクチャ設計が始まると、チャットサービスの実装事例について各自で調べて共有するところから始めました。「友達機能は RDS、チャットはリアルタイムの読み書きが必要なので NoSQL や AppSync を使った方が良さそう。」「アプリプッシュ通知には PinPoint が便利そう」など使えそうなサービスのイメージを固めました。 1回目のオフィスアワーでは、マルチ AZ についてまだ考えられていなそうというフィードバックをいただいたり、質問にも答えていただいて、WAF を設置した方がいい場所や VPC の外側に置けるサービスについて等知る事ができました。

2日目は DB 設計や DynamoDB、CloudWatch の検討から進めていきました。 2日目のオフィスアワーでは、S3 に認証機能がついていないというフィードバックや設計をシンプルにする提案をいただきました。開発環境についての質問をして、環境毎に AWS のアカウントを作った方が料金管理やロール付与が楽になるというベストプラクティスを教えていただきました。 2日目の後半には発表の準備をしながらオプション機能や要件を満たしているかについて議論していきました。

設計したアーキテクチャ図とくふうした点

最終的に私たちのチームで提案したアーキテクチャ図は以下のようになりました。

チャット機能に AppSync と DynamoDB、友達/グループ管理に EC2 と Aurora、画像/動画を保存するために S3 を採用しました。オプション機能であるスタンプ機能、チャット機能までは組み込まれていません。

このような構成にした理由やくふうした点は以下になります。

可用性
- アベイラビリティゾーンを2つに分けて(Multi-AZ にして) EC2 や Aurora を配置する事で、1つのアベイラビリティゾーンに問題があった場合もサービスを継続できるようにしました。
- また、Aurora を使っているのでマスタに問題があっても、レプリカへの自動フェイルオーバーをしてくれます。
スケーラビリティ
- 運用をしながらの調整という形になるのですが、CloudWatch を確認して EC2 と Aurora のオートスケールやスケジュールを設定する方法を考えました。
セキュリティ
- ELB、CloudFront、AppSync に WAF(ファイアウォール)を適用する事で不正なアクセスを制限するようにしました。
- S3 には Cognito を使用して、認証されたユーザーにのみ画像や動画を見れるようにしました。
パフォーマンス
- リアルタイムの読み書きが求められるチャット機能には DynamoDB を使用しました。
- 読み込みがメインの友達機能は Aurora のレプリカを使って負荷分散するようにしました。

また、将来の改善余地についても議論しました。本番環境のみのアーキテクチャ図になっていたので、環境毎にAWSアカウントを用意して、開発環境やステージング環境を作成したいという話が出ました。CI/CD も導入したいという話もしていました。

成果発表

2日目の後半には4チームずつに別れて成果発表会がありました。私たちのチームはオフィスアワーで指摘していただいた所を修正して新しく指摘される部分も無かったので、最低限考慮するべきところはできたのかなと思います。オプション機能までは設計できなかったのと、私たちのチームとはかなり構成の違うチームもあったので、様々な構成からメリットやデメリットを書き出して議論できるようになりたいと思いました。

私のチーム以外でも Da Vinci Studio メンバーが参加したチームが2つあるので、そちらで提案したアーキテクチャ図も紹介します。

私たちのチームと大きく違うのはサーバーレスな点で、Lambda などのマネージドサービスを利用した構成にしていました。私たちのチームではオプションであるチャット検索機能まで考慮できていなかったので、OpenSearch の説明は勉強になりました。

4人全員が Da Vinci Studio のチームのアーキテクチャ図です。こちらもサーバーレスで、機能ごとに Lambda を使っているのが印象的でした。運用や開発のしやすさも考慮していて、バックエンド側は SAM (サーバーレスアプリケーションモデル)を採用する事で CloudFormation を使ってインフラ構成をコード化し、デプロイをテンプレート化できるという事でした。

まとめ

今までは AWS サービスの理解度が足りず、社内のインフラ構成を見てもサラッと流してしまっていたのですが、今回のワークショップで主要なサービスであれば AWS のアーキテクチャ図を見て何のサービスが使われていて、設計の意図も分かるようになりました。さらに、小さい機能やゼロからサービスを作る際には自分でアーキテクチャ設計をしたくなりました。

最後になりますが、Da Vinci Studio では一緒に働く仲間を絶賛募集中です。興味のある方はこちらか recruit@da-vinci-studio.net までご連絡ください。

2022-06-28

21 卒エンジニアが半年間の新卒研修で学んだこと

21卒新卒研修

Da Vinci Studio 21卒入社、第1サーバー部の小林です。今回は、半年かけて行われた新卒研修について紹介します。これまでの簡単な経歴としては、情報理工学部の大学を卒業し、大学では主にPythonを使っていました。Rubyの経験は無く、RubyやRuby on Railsは内定者向けに出された課題で触り始めました。

人事研修

4 月

クリティカルシンキング、ロジカルシンキング
グループワーク
ビジネスマナー講習
健康経営観点で生産性を高めるためのサービス設計を行ったプロジェクトワーク
くふうグループの紹介と各社代表との交流会

技術研修

5 月

課題図書

読む課題図書から手を動かすことのできる課題図書まであり、今後の各研修を進めていく上での基礎知識を身につけることができました。具体的には「プロを目指す人のためのRuby入門」「パーフェクト Ruby on Rails」「達人に学ぶDB設計徹底指南書」などがありました。

Rails チュートリアル( 1 month )

Railsチュートリアルの内容に沿ってプルリクエストを出しレビューをもらいながら1ヶ月ほどかけて進めていくという研修でした。この研修を通してRailsについて学びを深めました。ユーザー登録やログイン機構、メールを使ったアカウント認証やパスワード設定といったwebサービスを開発する上での一般的なトピックを中心に、RailsでのCRUD操作の基礎を学びました。

6 月 ~ 7 月

マークアップ研修( 10 days )

読めるHTMLが書ける
読めるCSSが書ける
デザインが読める

という目標のもと、19 卒の先輩にHTML, CSSについて教えていただきました。最終的には、くふうカンパニーのコーポレートサイトのスタイルをHTMLとCSSを用いて実装しました。 BEMを使った命名規則をもとにクラス名の命名をし、FlexBoxを用いてフレキシブルにレイアウトを組み、レスポンシブデザインに対応できるようなHTML, CSSの書き方ができるようになりました。

研修前まではCSSはただ見た目の再現をするものという認識でした。研修を通して、パーツや幅は何を基準にしたデザインなのか、画面幅が変わった時の挙動はどうなるのか考え、デザインの意図を汲み取り実装するものという認識に変わりました。

DB設計( 3 days )

テーブル設計とトランザクションについて、座学で学びました。実際に手を動かした点で言うと課題に対して実際にER図を作ってみてそのER図に対してレビューをもらう、というのも行いました。 DB設計の基礎的な部分ではありますが、正規化をしてテーブル設計をしたり、リレーションを考えながらER図を作成できるようになりました。

自動テスト( 4 days )

Everyday Railsを用いてRSpecについて学び、実際に用意されているコードに対してテストを書くという研修でした。様々なマッチャを使ってみたり、mockを使って実装をしました。 RSpecでのモデルテスト、コントローラテスト、システムテストの基本的な部分とweb開発におけるテストの役割を知ることができました。

Web セキュリティ( 1 day )

Rails セキュリティガイドを読みながら適宜補足説明を受けるという内容です。 Webアプリケーションにおけるセキュリティの問題とそれらに対するRailsでの回避方法を学びました。

7 月 ~ 9 月

パイロットプロジェクト( 5 weeks )

パイロットプロジェクトは技術的制約や要件をもとにTODO管理アプリを作成するという研修です。テーブル設計、ER図を作成し、タスクの洗い出しと見積もりをした上で開発をしました。

ユーザーはGoogleアカウントを利用してログインできる。
ユーザーはTODOを登録できる
担当者は別ユーザーをTODOにアサインできる
TODOは複数の担当者をアサインできる
担当者はTODOを完了ステータスに変更できる

という要件をもとに実装を進めました。 Google認証を使った実装を経験できたのと、これまでの研修を活かしつつ実装を進め、学んだことを実践することでより理解を深めることができた研修でした。

プロジェクトワーク( 2 weeks )

プロジェクトワークは社内のドキュメントツールである kajero の改修タスクを行うという研修でした。この研修で初めて社内で動いているプロジェクトに関わらせていただくことになり、2つのタスクを担当しました。 1つ目は更新情報をSlackに通知する/しないを選択できるようにする実装。 2つ目は下書き保存機能の追加実装。この研修で初めて開発環境だけでなく、ステージング環境や本番環境にも触ることになったので、それぞれの環境へのデプロイ方法やその際の注意点などを学びました。他の人が書いたコードを読み解くという点で苦労した部分もありますが、様々な実装の方法を知ることができ、良い経験になりました。

9 月 ~ 10 月

最後の研修( 2 months )

グループ会社の方から案件の説明をしていただき、それに対して実現可能な機能を考え、提案から実装、リリースまで行うという研修でした。具体的には、不動産の買取再販サービス「おうちのくふう」が保有する物件の情報をkajeroを使ってグループ内に展開するという内容でした。バッチを使って最新の情報を毎日取得する、スプレッドシートとの連携をする、ヘルパーメソッドを活用できた研修になりました。またそれ以外にもクライアントと自分との認識に齟齬が出ないようなコミュニケーションの取り方を考えて試していました。自分の言葉で確認をし、質問の内容によって同期コミュニケーションや非同期コミュニケーションを使い分けていました。クライアントがいて、納期も設定していた研修だったのでこれまでの研修とは違った緊張感を持ちながら進めていました。

感想

研修の中では、基礎的なことのインプットとアウトプットがあり、また組み合わさって少し応用したアウトプットをしていました。インプットとアウトプットの連続が大変でした。新卒は自分ひとりだったので、当初わからない点があったときに気軽に同期に聞く、ということができませんでした。上司や先輩に質問するというのは最初躊躇してしまう部分ではあったのですが、そうするとわからないまま時間だけが経ってしまうので上司や先輩に質問する抵抗が薄れ習慣ができました。

研修の設計として、それまでの研修や課題図書がこなせているというものが前提に組まれていました。なので座学で得た知識を次の研修で実際に手を動かして学ぶことができたのでより深い理解に繋がりました。また、良かった点や反省点は次の研修で活かせるというのも個人的には良い部分だなと感じています。
毎週金曜日の夕方に振り返りをKPT法というやり方を使って行っていました。その週の良かった点、悪かった点を洗い出し、その次の週にトライとして目標を設定していました。行動ベースで振り返りができ、小さく目標を立てることができました。定期的に自身のことを振り返ることができていたことに加え、細かく具体的なフィードバックもいただいていました。
リモートワークで入社当初からオンラインでのコミュニケーションということで少なからず不安はありました。しかし、SlackやGithubを使った非同期コミュニケーション、MeetやDiscordを使った同期コミュニケーションの使い分けができるようになり、質問などがあった際にもスムーズに聞くことができました。また、人事研修を通して多くの方とコミュニケーションを取りつつワークを行ったので、心理的なハードルがかなり下がりました。

さいごに

今回は21卒の新卒研修について紹介しました。

また、Da Vinci Studioデザイン部が発信するnoteやサービスの開発ストーリーもあるので、こちらも読んでみてください。

Da Vinci Studio では一緒に働ける仲間を絶賛募集中です。興味のある方はこちらか recruit@da-vinci-studio.net までご連絡ください。

よもやま

Discordのようなコミュニケーションツールを利用

2週に1回の井戸端会議(いどばた！)

Slackチャンネルの利用

さいごに

作成したもの

手順

Slack App の作成

GAS Script の作成

GAS へ SlackApp ライブラリを導入する

Slack API を叩いてチャンネルにメッセージを送信する

GAS を定期実行するトリガーの追加

さいごに

背景

シノニムとは

シノニムの追加の方法について

辞書について

登録方法

インデックスの設定

ドキュメントの再インデックス

終わりに

活動概要

活動内容

学習フェーズ（2021年1月〜2021年12月）

実践フェーズ（2022年1月〜）

社内開発サービスへの検査の実施

インシデント発生のロールプレイング

ボードゲームを通じた体験学習

最後に

エンジニア採用における面接初心者の心得3か条

1次の採用面接について

1. 頑張りすぎないこと

2. 採用面接しすぎないこと

3. 面接者として候補者の方を適切に評価できるようにすること

終わりに

AWS JumpStart について

参加の経緯

事前準備

イベントの概要

チームでのアーキテクチャ設計

流れやチームの雰囲気

要件

アーキテクチャ設計とオフィスアワー

設計したアーキテクチャ図とくふうした点

成果発表

まとめ

21卒 新卒研修

人事研修

4 月

技術研修

5 月

課題図書

Rails チュートリアル( 1 month )

6 月 ~ 7 月

マークアップ研修( 10 days )

DB設計( 3 days )

自動テスト( 4 days )

Web セキュリティ( 1 day )

7 月 ~ 9 月

パイロットプロジェクト( 5 weeks )

プロジェクトワーク( 2 weeks )

9 月 ~ 10 月

最後の研修( 2 months )

感想

さいごに

GAS Script　の作成

GAS へ　SlackApp ライブラリを導入する

21卒新卒研修