2018年4月に入社した新卒エンジニアの堤です。前回に引き続き、入社後に新卒メンバー全員で初めて企画・開発した「シャッフルランチ」の取り組みについてご紹介します。
▲2018年の新卒入社は総合職3名、エンジニア4名の計7名。職種を問わず新卒メンバー全員が参加する研修が2週間ほど行われました
1. シャッフルランチトライアル後のシステム改善
まずは、トライアルでのシャッフルランチ導入後の改善について。
主に、
- 構成の刷新
- シャッフルロジックの改良
についてお話します。
(1) 構成の刷新
前半でもお話しましたが、シャッフルランチの実施初期はGASを利用していました。ただ、運用していく上で大きく2点課題がみつかり、構成を刷新することになりました。 具体的には下記の2点です。
- GASがチーム開発に向かない
- Slackボタンが使えない
1について、GASが標準ではバージョン管理に対応していません。基本的にはWeb上のIDEからGASのソースコードを直接編集する形になります。この場合、
- 複数人で開発するときに編集箇所が競合し、編集が適用されないなどの面倒が生じる可能性がある
- バージョン管理がされないので、以前の状態に戻すことが難しい
という状況になります。 トライアル開発時は完全に分担しており、開発量も多くなかったので問題になりませんでしたが、運用にあたって加えたい機能が次々と出てきたため、このまま開発を続けることが難しくなりました。 ちなみに、GASとローカルを同期する機能は以下にまとめられているので、個人開発であればバージョン管理の問題は解決されそうです。
https://techblog.recruitjobs.net/development/maneged_google-apps-script_by_github
2つ目の課題は、Slackボタンが使えない点でした。 背景として、アンケートや出欠確認でSlackのボタンを使いたいよね、という話が上がっていました。ただ、Slackのボタンには3秒以内にレスポンスを返さないとTimeoutする仕様があり、GASだと3回に1回程度はTimeoutしてしまいました。 これに関してはGASを使っている以上はどうしようもないので、トライアル時にはボタンの利用を諦めました。 その他にも、GASのJavaScriptが古い(ECMA Script 5)だったり、動作時間に制限(1度に6分まで)があるなど、今後の運用を考えると移行したほうが良さそうだという話になりました。
以上の理由から、最初のトライアルを終えて2度目のトライアルまでに、主に新卒エンジニアの神(こう)と諏訪が以下の状態にお引越ししてくれました。
- バックエンド
- Botkit (Node.js)
- 開発環境
- GitLab CI
- Rancher
BotkitはNode.jsによるbot作成フレームワークの一つで、Slack以外にも様々なChatBotを作成することができます(https://botkit.ai/)。 また、GitLabを立て、CIツールとしてGitLab CIを用いることで、Docker Image作成の自動化を図っています。GitLab CIについてはこちら(https://qiita.com/bremen/items/f47f383b9931a840a25c) に詳しく書かれています。 さらに、Rancherを利用することで、GitLab CIによって作成されたDocker ImageのデプロイをGUIから簡単に行えるようにしています(https://www.slideshare.net/recruitcojp/rancherrancher)。 これによって、
が実現されました。
(2) シャッフルロジックの改良
トライアルを実施してみると、「よく話す人と同じグループになったためシャッフル感がない」「同じ部署の人と一緒になった」などという意見が散見されました。 今までは完全にランダムシャッフルを行ってグループを作っていましたが、「似ている社員が違うグループになるようにシャッフルしたほうがいいのではないか？」という話が上がりました。 そこで、社員の下記の属性を利用し、似た社員が同じグループになりにくいようなシャッフルを行うこととしました。
- 社員属性
- チーム
- 職種
- 性別
- 勤続年数
要件はこちらです。
- 属性の似た社員が同じグループになりにくい
- メンバーは毎回異なるようにしたい
「属性の似た社員が同じグループになりにくい」ということで、確率を利用したロジックを用いることにします。今回は「焼きなまし法(Simulated Annealing)」1という方法を用いることにしました。 焼きなまし法は組み合わせ最適化問題に対するアルゴリズムの一種で、巡回セールスマン問題(TSP)などを解決するときに利用されます。 今回は
- 条件
- 同一グループに属する社員同士の類似度をコストとする
- 制約
- 全体のコストを低下
と設定し、ロジックを作成しました。 ロジックの大まかな流れがこちらです。
- 全体のコストが小さくなるように、以下のようにSwapをR(=2000)回程度繰り返す
- 別々のグループからランダムに2人選ぶ
- 2人を入れ替えたときのコスト変化を計算する
- コスト減少ならSwap、そうでなくても確率PでSwap
焼きなまし法では、こちらの「確率P」が徐々に下がっていくことで、最初はコストが増加するSwapも許容しつつ、だんだんコストが減少するSwapのみ許容に変化していき、最適な解に近づけていきます。 今回は「メンバーは毎回異なるようにしたい」という要件があったため、確率Pの値は割と高い値を保ったままにしています。そうでないと最適解に近い値を求めてしまい、毎回メンバーが固定されてしまうからです。 今回はこちらのロジックを採用することにより、属性の似た社員が同じグループに固まることを防ぎつつ、メンバーが毎回異なるようなシャッフルを実現できました。
補足 今回のコストは以下のように設定しています。 グループgのコストは以下のように定義する - groupCost(g) := (baseCost(g) / groupSize(g) ** 2) ** 2 ただし、 - baseCost(g) := グループgに属するメンバー同士の類似度合計 - メンバー(a, b)の類似度 := sameJob(a, b) + sameTeam(a, b) * 2 + sameSex(a, b) + distHist(a, b) - sameXXX(a, b) := XXXが同じなら1、そうでないなら0 - distHist(a, b) := 勤続年数が近いほど大きくなる値 このとき、全体のコストは各グループコストの合計である。
その他、出欠の自動化であったり、取得に時間のかかるSpreadSheetのCache作成など、課題が上がるごとに機能を追加していきました。 現在もシャッフルランチの運用をより良く、より楽にするために改善を重ねています。
2. 本格運用を開始
2018年4月に新卒でRettyに入社し、Webプランナーを担当している山田陸です。
新卒メンバーみんなで試行錯誤を重ね、トライアル期間に見つけた課題も解消し、７月より全社でシャッフルランチの本格運用を開始しました。 新たな課題が出る一方で、社内ではポジティブな変化もありました。
(1) 課題：参加率の低下
トライアル期間中は、出席者に直接声をかけることも行なっていたため多くの社員が参加してくれましたが、自動化するために出席確認をbotで送る仕組みに変えたところ、大幅に参加率が低下してしまいました。
原因は、シャッフルランチの目的やメリットが社内に浸透しきれていないことや、既に予定が入っていて参加できない人を含めて選定している点などが考えられます。 完全自動化からは少し離れてしまいますが、社内でのアナウンスなど、シャッフルランチが定着するための取り組みも行なっていこうと考えています。
(2) ポジティブな変化：社員同士の声のかけ合いやすさ向上
一度ランチをしたことで、その後も社内で声をかけやすくなったという声がありました。ランチを通じて、仕事だけでなくお互いのプライベートなども知れば、互いの距離はグッと縮まります。シャッフルランチをきっかけに、仕事でのコミュニケーションにもつながることを垣間見ることができたことは、非常に嬉しいです。
3. 今後のシャッフルランチについて
Rettyはこれからも事業の拡大に伴い、社員の数も増えていくことが予想されます。社員同士の交流は、会社全体が「チームRetty」として成果を生み出していく上で欠かせません。 社員同士の交流を活性化するためにも、シャッフルランチの改良を重ね、参加率を向上させていきたいと思います。
私たち新卒メンバーが企画した「シャッフルランチ」によって社内のコミュニケーションが活性化され、サービスやビジネスの成長に貢献できたら嬉しいです。
