UUUMエンジニアブログ

UUUMのエンジニアによる技術ブログです

自己研鑽補助ってなに?

UUUMのシステムユニットのしだです。
GWが明け、久々の仕事で何から手をつけるんだっけ? となっている方も多いのではないでしょうか。私もそうです。
2022年はなんと今日から7/18まで祝日がありません。どうにか日々を乗り切りましょう。

はじめに

UUUMのシステムユニットは勉強会・輪読会が盛んで、週に3、4回、もしかしたら毎日なにかしら開催されているのではないかなという状況です。
もちろん全てに全員が参加しているわけではありませんが、チームで開催されたり、個人が宣言して有志で集まって開催されたり、結構自由に行われています。
社内だけではなく、社外のセミナーや勉強会に参加される方も多く、自主的に学ぶことに意欲の高い人が多くいる印象です。


私が以前いた会社では、私のいた部署はもちろん、システム部でも特に勉強会などはなく、恥ずかしながら外部セミナーなどに参加する発想自体がありませんでした。完全に、自身の文化資本にない状態ですね。
本を読むことは頭にあっても、身銭を切るにあたって一番良さそうな本はなんなのか、金額的にどうなのかなど調べていると、もうネットでいいかとなってしまったり。
そういった人間でも、業務に関連する本をなんやかんや毎月買って読んでいたり、社内外の勉強会やセミナーに参加するようになりました。
単純に、業務時間内に勉強会が開催されていることや、学習意欲の高い人たちがたくさんいるから影響されたのも要因ですが、私にとって一番影響があったのが、自己研鑽補助という制度でした。


ということで、自主的に学ぶ文化形成に寄与しているんじゃないかと思われる、自己研鑽補助について紹介します。
ちょうど前回sawada_yさんが『Udemyの動画と書籍については、自己研鑽補助の制度を利用し購入しました』と書いていましたが、その制度がこちらです。

自己研鑽補助とは

エンタメに触れ、情報を集め、体感すること、ビジネススキルに繋がることなど 常に感度を高め、自己研鑽に励む社員を会社がサポートする制度で、 毎月利用上限を1万円とし、ビジネススキル向上やエンタメ情報収集のための書籍購入などを経費申請できるUUUM独自の補助制度です。

全社的なルール

全社的には、下記の用途で利用OKとされています。(※2022年5月時点)

  • サブスクリプション(サブスク系映像、ニュースコンテンツ等)
  • 書籍購入(ビジネス書籍、マンガ、雑誌、新聞)
  • セミナー参加(セミナーへの参加)
  • 資格取得、教材購入(スクール・資格取得、教材の購入等)
  • ビデオ・コミックレンタル
  • 映画鑑賞
  • ステージ・音楽鑑賞(コンサート、芸術鑑賞等)
  • その他(上記項目以外 アミューズメントパーク等)

システムユニットでのルール

システムユニットでは業務内容を考慮し、以下のルールで運用されています。

  • 技術・ビジネス書・小説系の書籍や雑誌可
  • 紙・電子書籍のマンガは「マンガでわかるRuby」など、ノウハウ系のもののみ可
  • 映像系円盤(DVDなど)は、レンタルのみ可
  • 映画(劇場・配信)・ステージ・芸術鑑賞など可

※記載がないものは全社ルール適用(サブスクリプションや資格取得など)

具体的にどう利用しているか

私自身は主に、システム関連の知識を得るための本を買ったり、業務知識に関連する本を買うことに利用しています。
会社からの補助が1万円まであるからと、比較的高額な書籍も含めて買う習慣がつきました。
先にも書いたとおり、自分で買うとなると、あれもこれも買う余裕がないので選りすぐりの1冊を求めて探す時間が発生してしまうんですよね。
迷って探している時間は、気軽に買って読み終わる時間と同じかもしれない。そういった意味でも、かなりメリットの大きい制度だと思っています。
そして、買えば読むので、結果的に業務外の時間でも業務の学習をすることが増えました。

これが私だけなのか、みんなそう思っているのか、そもそもどれくらいの人がこの制度利用しているのかが知りたくなったので、システムユニット内でアンケートを取ってみました。

アンケート結果

有効回答数は18件、システムユニット全体で40人ほど在籍しているので、およそ半数に回答いただきました。
設問は下記の通りです。

  • 自己研鑽補助、毎月使ってますか?
  • 使わないことがある方は理由を教えて下さい
  • 使っている方、使用用途を教えて下さい(複数選択可)
  • 自己研鑽補助があったからやったこと・買ったものがあれば教えて下さい
    • 例:受験料を補助申請できるから〇〇資格を取った、技術系書籍は補助があるから気軽に買うようになった、毎月映画を見る習慣ができた、など
  • 自己研鑽補助を利用して得たもので、自分にとってよかったもの
    • 得たものの具体的な内容(書籍の場合は書籍名、体験・経験の場合は概要など)と、よかった理由を教えてください
自己研鑽補助、毎月使ってますか?

毎月使っている人が12名、基本的に使っているも含めると16名で、全体の88.9%が利用している状況です。
「利用していない」も選択肢として設けていましたが、0でした。
全社では利用率が7割程度らしいので、システムユニットは比較的利用率が高いと言えそうです。

利用しない理由

回答6件のうち、申請忘れや締切によるものが3件、あとは主体的な理由です。
その他でいただいたうち、「前月の本を読み切れていないため」という回答があって誠実な人だなと感心しました。
私は積ん読することへのためらいが一切ないので、読んだかどうかに関わらず欲しい本はとりあえず買ってしまいます。

利用用途

予想通り、ほぼ全員が技術系書籍の購入に利用していました。
全社的にはエンターテインメントに関する補助という側面の強い制度ですが、システムユニットではかなり実務に即した利用が行われているのが見て取れます。
とはいえサブスクリプションや映画などにもかなり利用されているので、業務以外にもいい影響がありそうです。

自己研鑽補助があったからやったこと・買ったもの

ここは自由記入枠で、回答が15件ありました。
項目内に理由を複数記載してくださっていた方もいたので分割した上で、大きく分けて以下の通りの内容です。

  • 技術書を買うようになった(10件)
  • 技術以外も含めた学習(4件)
  • サブスクで音楽や動画に触れる(3件)
  • 資格取得・受験(2件)

技術書を買うようになった、には、以前と比較して何冊も買うようになったも含んでいます。
頂いた中には以下のようなコメントもありました。

自身が持っているスキル領域以外に対して気軽にチャレンジするようになった
どうしても自身の業務に関わることが優先になりがちですが、会社から補助があることで、ちょっと他のことも試してみようという気になれるのは確かにそのとおりです。
オーディオブックを聞くようになり、ランニングが続くようになった
これは副次的な効果ですが、健康にも寄与している例ですね。

自己研鑽補助を利用して得たもので、自分にとってよかったもの

ここも自由記入枠で、回答が12件ありました。
いくつかコメントをピックアップします。

毎月技術書を買おう、読もうという気になれる
技術書を買うハードルが下がった。ちょっと高い分たまに1冊買う程度だったのが、すすめられたものを気軽に買えるようになった。
学習習慣がついた

このあたりは私が感じていたのと同じく、この制度によって習慣に影響があった例ですね。
また、それに加えてこういったコメントもありました。

技術的な成長はもちろん、美術館鑑賞など興味の幅が広がった
英語が以前より流暢に読めるようになり、業務でドキュメントを読むときに役立っています。また、 人から勧めてもらった映画などでコミュニケーションに役立ちました。

こちらは自身の業務スキルのみではなく、人とのかかわり合いや自身のプライベートにも影響があった例ですね。
さらに、具体的に書籍名などを上げてくださった例もありました。

PMBOK 第7版。高いので補助がなかったら絶対自主的に買わなかったと思うので。
「闇の西洋絵画史」山田五郎さん独自の視点で西洋絵画の主だったモチーフを解説してくれます。ちょっと高い

PMBOKは私も補助を利用して購入しました。
現在輪読会でこの本を読んでいますが、かなり高額なので補助がなかったら輪読会で読む本に上がらなかったのではないかなと思います。

「闇の西洋絵画史」、面白そうだなと思ってピックアップしてしまいました。業務とは直接関わりませんが、こういう本も気軽に買えるのがありがたいところです。(とりあえず1巻買いました)

まとめ

アンケートの設問がいまいちでしたね……特に最後2つは似たような内容になってしまったので、意図が明確な質問を考えるべきでした。
そんな反省点はありつつも、回答内容を見るに、身も蓋もない話で恐縮ですが、お金面での補助は学習習慣にかなり影響があると言って良さそうです。
かつ、この制度は用途を業務勉強のみに限っていないところが肝なんじゃないかなと感じました。
技術書を買って勉強する合間に、サブスクで映画を見てリフレッシュしたり、楽しみにしていた小説の新刊を読むとか、そういう余地があることで、業務も頑張れる。
ワークライフバランスという言葉自体はあまり好みませんが、結果的にそこに寄与する制度なんじゃないかなと思いました。

さて、そんなわけで、こういったユニークでありがたい制度もありつつ、勉強会なども盛んなUUUMのシステムユニットではエンジニアを募集しています。
気になる方はぜひ。 www.wantedly.com

【GAS】GoogleDrive内のcsvファイルをスプレッドシートに一括インポートする

こんにちは、UUUMシステムユニットの sawada_y です。 第2回オンラインハッカソンにて、シェルスクリプトを使用して月次作業を自動化したことについて発表させていただきました。その後、別の月次作業においてもGASを使用して自動化することができましたので、そのことについて書きたいと思います。

はじめに

担当業務の中で月次でGoogleDriveにあるcsvファイル(50~60位)をスプレッドシートに手動でアップロードするという、とても面倒な月次作業がありました。そこで、GAS(Google Apps Script)を使用してGoogleDriveにある複数のcsvファイルをスプレッドシートに一括でインポートすることができたので、そのことについて書きたいと思います。※GASの環境構築についてはまとめて下さっている記事が多数あったので、省略します。

自動化する前の作業内容

Google Driveに格納されている複数のcsvファイルをスプレッドシートに手作業で1つ1つインポートする作業を月次で行なっておりました。csvファイルの種類については最近になって増えてきて、その数50~60ファイル程度になっています。ポチポチと1つ1つファイルを選択して[データをインポート]を押すというイメージです。

これは面倒。。。

ということでこの作業を自動化することにしました。

自動化した後の結果イメージ

GoogleDriveの指定フォルダにcsvファイルを格納しておいた状態で

スクリプトを実行すると、複数のcsvファイルがスプレッドシートに一括でインポートされます。

要件

結果をイメージできたところで、具体的に要件を整理します。

  • Google Driveに格納された複数のcsvファイルを該当のスプレッドシートに一括でインポートしたい

  • 1つのファイルの内容が1つのシートに反映されるようにする。(50ファイルあったら、合計50シートになる)

  • それぞれのファイルの内容が、特定のシート名(そのファイルの一部が名前となっている)のシートに反映されるようにする

    • ex)13tokyo_2202.csvなら13tokyoという名前のシートに、11saitama_2202.csvなら11saitamaという名前のシートに反映されるようにする。(細かいですが、前月のスプレッドシートのデータが残っていることを前提にそのデータをクリアにしてから反映するようにします)
  • 特定のシート名(そのファイルの一部が名前となっている)のシートがなければ、特定のシート名(そのファイルの一部が名前となっている)のシートを新たに作成しそこに反映されるようにする。

コード内容

上記の要件を満たした、GASで記述したスクリプトを以下に記載します。 初学者向けにコードの内容を書いたコメントアウトも細かめに記載しております(参考にさせて頂いた記事のコードを読み解くのに時間がかかってしまったので)。 このスクリプトを実行すると、[2.実行イメージ]のようにインポートされます。

// 書き込む対象のアクティブなスプレッドシート(スクリプトにバインドされているシート)を取得
let ss = SpreadsheetApp.getActiveSpreadsheet();

function Import() {
  // getFoldersByIdでフォルダを取得
  let folder = DriveApp.getFolderById("格納フォルダのID");
  
  // ドライブの指定フォルダの全てのファイルのコレクションを取得
  let files = folder.getFiles();
  // ()内の条件式がtrueの間、{}内の処理が実行
    // hasNextで次のファイルが存在していたらtrueを返す。全て処理をしていればfalseを返す(未処理の場合、true。処理が終わればfalseとなる。)
  while (files.hasNext()){
  // nextで未処理の次のファイルを取得
  let file = files.next();
  // ファイル名を取得
  let fileName = file.getName();
  // _で区切って配列にする
  let fileNames = fileName.split('_');
  // 0番目から最後の要素以外をアンダーバーでくっつけたシート名にする。(13tokyo_2202.csvというファイル名なら13tokyoが返ってくる。)
  let sheetName = fileNames.slice(0,fileNames.length - 1).join('_');

  // ファイル名から抽出したシート名のシートがあるか判定
  let sh = ss.getSheetByName(sheetName);
    if(sh == null)
    {
      // なければ、引数の名前の新しいシートを挿入し、取得
      ss.insertSheet(sheetName);
      sh = ss.getSheetByName(sheetName);
    }
    else
    {
      // あればシートの値や数式や書式をクリアする
      sh.clear()
    }

  // getBlobでBlobオブジェクトとして取得(Blobとはデータの内容を操作したり、データを交換する為のオブジェクト)
  // getDataAsStringでブロブをエンコーディング。charset(文字コード)による文字列として取得
  let data = file.getBlob().getDataAsString("UTF-8");
  // 文字列データcsvを区切り文字 delimiterで分割して二次元配列を取得
  let csv = Utilities.parseCsv(data);

  // セルA1からCSVの内容を書き込む
  // getRangeで書き込む範囲を指定(開始セルは1行目の1列目、書き込み行数は配列数、書き込み列数は1次元配列の要素数)
  // setValuesは配列を対象のセル範囲に入力するメソッド
  sh.getRange(1,1,csv.length,csv[0].length).setValues(csv);
  }
}

コードの細かい内容はコメントに書いておりますが、ざっと以下のことを行っています。

  • 書き込むスプレッドシートを取得

  • csvが格納されているフォルダを取得し、そのフォルダ内の全てのファイルを順番に処理していく

  • ファイル名から一部抽出したものをシート名とする。

    • 13tokyo_2202.csvなら13tokyo、11saitama_2202.csvなら11saitamaをシート名として抽出。また、13_tokyo_2202.csvと途中で (ハイフン)がついていても 2202だけ削除し13_tokyoだけ抽出できるようにしている
  • 抽出したシート名のシートが既にあればクリアしてから、csvの内容を書き込む

  • 抽出したシート名のシートがなければ、その名前で新しいシートを作成し、csvの内容を書き込む

最後に

簡単なスクリプトにはなりますが、月次でインポートする作業を手動で行う手間と間違うリスクを少しばかり削減できたので、やって良かったなと思いました。ただ一旦インポートできた!という段階なので、より使用・管理しやすいように今後改良していきたいと思います。

参考にしたもの

(Udemyの動画と書籍については、自己研鑽補助の制度を利用し購入しました。)

MySQL DBインスタンス バージョンアップの進め方

みなさんこんにちは!UUUMシステムユニットの ぶち です。

桜の季節ですね。4月になり新しい環境に変わった方もいらっしゃるのではないでしょうか。 実はUUUMのサービスの中にも新しいバージョンに生まれ変わっていた DB がいました🌸

はじめに

少し遡り雪解の候、 MySQL のメジャーバージョンアップを実施しました。 具体的なオペレーションについては素晴らしい記事が世の中に多数ありました(大変お世話になりました)。

本記事では、実作業レベルの具体的なバージョンアップ手順については述べません。

サービス提供やステークホルダーとの擦り合わせなどの観点で実施した、周辺業務を主題に記載します。

対象の DB 環境

今回のバージョンアップ対象の環境について軽く触れておきます。

  • AWS RDS に構築している DBインスタンス
  • レプリカ無し
  • MySQL 5.6 から 5.7 へのアップグレード
  • アプリケーションのテストカバレッジは向上途中

事前に準備したもの

バージョンアップ情報ドキュメントの作成

作業全体像の把握と他メンバーへの共有を主目的として、バージョンアップ手順を作成しました。 最終的に把握した項目は以下の通りです。

DB について
  • バージョンアップ後に変更される仕様の概要
  • DB のみで必要なダウンタイム
  • 公式バージョンアップドキュメント等の情報
  • 事前構築すべきリソース( Parameter Group 等)
アプリについて
  • テストの必要な機能
バージョンアップオペレーションについて
  • バージョンアップ作業内容
  • 万一バージョンアップ失敗した場合の切り戻し
バージョンアップ後の注意事項について
  • 不要なリソースの処理(旧DBやオペレーション用に構築したものなど)
  • IaCの修正
  • モニタリング対応

この中で特に、「万一バージョンアップ失敗した場合の切り戻し」は大切だと感じています。 その理由は2点あります。

まず、当然のことですが、メンテ時間の延長はユーザーの予定を狂わせる可能性があります。 サービスの信頼性や継続性は事業を継続する上で非常に重要な要素です。

また、切り戻しが必要な場面に遭遇する時点で、既に想定外の事態と対面していることでしょう。 事前に準備しておけば、想定外の上さらに想定外のオペレーションを重ねず済みます。

勇気ある撤退の判断も視野に入れられるよう、可能な範囲で準備はしておきたいですね。

作業チェックリストの作成

正直手間がかかるため、チェックリストまではやらないケースも多い印象はあります。 ですが作成することで受けた恩恵があったため記載しておきます。

バージョンアップのオペレーションを、実作業レベルでスプレッドシートにリストアップしました。 実際に利用した項目(と作業サンプル)を以下に記載します。

実施チェック 手順No. 概要 予定開始時刻 備考欄
ぶち 1 Terraformからメンテイン 18:00 -
ぶち 2 DBスナップショット取得 18:05 -

特に「実施チェック」と「予定開始時刻」は記載して良かったです。

「実施チェック」は、作業分解することのメリットがありました。 まず各メンバーに分担できるレベルに落とし込むため、作業が明確になります。 また分担の結果全員が作業者として関わることになるため、事前の打ち合わせを同じ目線で細かく議論することができました。

「予定開始時刻」は、タイムマネジメントと実績としてのメリットがありました。 現在の作業が予定時刻に対してどの程度順調か理解できる上、今後類似作業が生じた際の参考値になります。

もし次回があれば、実績の精度を上げるため「作業完了時刻」を追加してもいいかもしれません。

作業内容

開発環境でバージョンアップの実施

準備した内容を踏まえ、実際にオペレーションを行いました。 この時点で、バージョンアップがプロダクトに対してどう影響するのかを判明させました。

実施結果を受けて、ドキュメントに必要事項があれば追記します。

今回は、念のため主要機能を手動テストするようチェックリストに追加することになりました。 全機能の手動テストは現実的に不可能に近いため、事業的なインパクトの大きい部分を重点的に確認するようにしました。

サービスダウンの事前周知

作業チェックリストからバッファを含めた所要時間を見積もり、関係者にダウンタイムをアナウンスしました。

本番環境でバージョンアップの実施

ここまでの流れを踏まえて作業を実施します。 準備の甲斐もあり、予定より早めに完了できました。

バージョンアップ後の残タスク処理

一番気を遣う作業が終わり安心しがちですが、ここでミスすると大変なことになる可能性があります。

例えば DB を Terraform で構築している場合、新しいものに修正しないと差分として認識されます。 バージョンアップのやり方次第では、修正しないまま誤って apply してしまい、、、という状況の発端になりかねません。

また、 DB は比較的コストが大きくなりがちな部分だと思います。 利用しなくなった古いインスタンスなどは折を見てコストのかからない形にしましょう。

そしてもう一つ。一定期間は予期しない挙動をしていないか普段よりモニタリングに気を遣うと良いと思います。

さいごに

今回担当したバージョンアップは、概ね以上のように実施しました。

こうした業務の一部を取り上てげも様々な進め方があると思います。 当然組織やシステム構成に応じて必要な対応は異なりますが、安全性を高める取り組みは大切だと感じています。

また、今回はプロジェクトやチームにとっても良い方法を模索しながらの業務だったため、組織で取り組むという点でも勉強になりました。

本ブログが何かの参考になれば幸いです。

BIツール (AWS QuickSight)の活用紹介

UUUMシステムユニットエンジニアの5n4wasa6です。

先日、実家に帰った際、ふきのとうやタケノコが生えており、春を感じる今日この頃です。 大きなイノシシにも遭遇して戦々恐々としております。

はじめに

UUUMでは現在、中期IT計画というプロジェクトが進行しており、社内の各種サービスの連携や点在しているデータ(Excelやスプレットシートでの管理)を集約しマスタ化して、社員の業務効率化を図ろうとしております。

私が携わっているHerokura(ヘロクラ)というサービスでは、主に、Ruby (Ruby on Rails), JavaScript (Vue.js)を使用しております。

インフラ周りはAWSで構築しており、CI/CDはCircleCI (一部 Github Actions)を活用してます。

Terraform (IaC化)やサーバレスでの実装 (Lamdba)も行っております。

Herokura(ヘロクラ)の一部で、BIツールを活用して会社のKPIを全社員が認識できるような実装があるので、今回そちらをご紹介します。

弊社で活用しているBIツール

弊社では、BIツールとしてTableauやAmazon QuickSightを活用しております。

Tableauは、Youtubeの再生数やトレンドなどさまざまな分析に活用しております。

Amazon QuickSightは、前述の通り、社内のKPIを全社員が認識できるよう、実装/活用しております。

Amazon QuickSight選定の経緯

当初グラフ描画は、JSライブラリで実装することを検討しており、以下3つが候補に上がっておりましたが、単純なグラフ描画をサンプル実装して、事業部側の反応を見るということだったので、chart.jsを採用することになりました(一部Vue-good-table利用)。

  • chart.js
  • Google Charts
  • Highcharts

chart.jsでも描画そのものには大きな問題はなかったのですが、データが増えるにつれストレスなく描画することが辛くなっていきました。 また、今後運用するに当たって簡単に手間なく事業部からの要望や開発側から提案ができる必要があるため、BIツールの検討が始まりました。

弊社内で利用していたTableauと、Amazon QuickSightの比較になりましたが、 価格優位であるAmazon QuickSightで検証することに決まりました。

Amazon QuickSightの設定

QucikSightの各種設定は公式ドキュメントを見るのがベストです。

こちらの動画もわかりやすかったです。

データセットを作成することからスタートするのですが、RDSやS3、Salesforce、ファイルアップロード(csv, tsv, json)、etc...のデータから作成することが可能になっております。

自動更新の頻度は、最短で1時間毎なので準リアルタイムで描画が可能と言ったところでしょうか。

データは、「直接SQLを記述するパターン」と「テーブルを紐づけていくパターン」があるので簡単に作成することが可能です。

直接SQLパターン

f:id:always_protein:20220401113613p:plain
SQL

紐付けパターン

f:id:always_protein:20220401134518p:plain
結合設定

f:id:always_protein:20220401113040p:plain
全体

紐付けパターンの場合、「計算フィールドを追加」ボタンから新しいフィールドを作成することができます。 さまざまな演算子が用意されているので、こちらから欲しいデータ(描画したい項目)を作成することができますが、個人的には直接SQLを書いてしまった方が早いかなと思います。

f:id:always_protein:20220401114021p:plain
計算フィールド

データセットが作成できたら、分析タブから描画したいグラフパターンを選択していきます。

f:id:always_protein:20220401135221p:plain
グラフ描画 (分析)

作成できたらダッシュボードへの公開をして設定は終了です。

アプリケーションからAmazon QuickSightの呼び出し

AWS SDK for Ruby V3を使用して、Amazon QuickSightのダッシュボードを呼び出しています。

RoRの実装

  • 各Controllerからget_dashboard_embed_urlを呼び出す
require "aws-sdk-quicksight"

class Provider::Quicksight
  def initialize
    @client = Aws::QuickSight::Client.new(
      region: Settings.aws[:region],
      access_key_id: Settings.aws[:access_key_id],
      secret_access_key: Settings.aws[:secret_access_key]
    )
  end

  def get_dashboard_embed_url(dashboard_id, user_arn, identity_type = "QUICKSIGHT", namespace = "default", additional_dashboard_ids = nil)
    @client.get_dashboard_embed_url(
      {
        aws_account_id: Settings.aws[:account_id].to_s,
        dashboard_id: dashboard_id,
        identity_type: identity_type, # IAM or QUICKSIGHT or ANONYMOUS
        session_lifetime_in_minutes: 60,
        undo_redo_disabled: false,
        reset_disabled: false,
        state_persistence_enabled: false,
        user_arn: user_arn,
        namespace: namespace,
        additional_dashboard_ids: additional_dashboard_ids
      }
    )
  rescue StandardError => e
    logger.error(e)
  end
end

Vueの実装 (Vue2)

  • クリックするボタン部
<template #graph>
  <div ref="embeddingContainer" />
  <v-button v-if="isDisplayGragh" class="btn btn-success" text="グラフ表示" @action="getQuicksightUrl" />
</template>
  • クリックアクションからの非同期処理
methods: {
    getQuicksightUrl() {
      handleHttp
        .get(this.$appRoute.quicksight_api_v1_report_sales_costs_path())
        .then((ret) => {
          this.embedDashboard(ret.data.url)
        })
        .catch((err) => {
          this.$toasted.error(err)
        })
    },

    embedDashboard(url) {
      const containerDiv = this.$refs.embeddingContainer
      const options = {
        url: url,
        container: containerDiv,
        scrolling: "no",
        height: "800px",
        width: "1000px",
        footerPaddingEnabled: true,
      }
      QuickSightEmbedding.embedDashboard(options)
      this.isDisplayGragh = false
    },
  },

Amazon QuickSightでの悩みポイント

閲覧している人によって、閲覧可能なデータを分けたかったが簡単に保守コスト低く実装ができなかった。 理由としては以下2点です。

  1. 任意のパラメータを渡すことができない

AWS SDK for Ruby V3

システム側にある制御リストを活用できない。

2 行レベルのセキュリティでのアクセス制限

1ができないので、Amazon QuickSightの機能である、行レベルのセキュリティー(RLS)を使用することで

アクセス制限の実現可能ではありました。

docs.aws.amazon.com

f:id:always_protein:20220401144308p:plain
Amazon QuickSight で実現するセキュアなBI環境 資料より抜粋

実際に実装してみると、制限するためのデータの持ち方に少しクセがありました。

f:id:always_protein:20220401143745p:plain
データセット設定画面

また、行レベルのセキュリティー(RLS)を使用するうえで、以下2点が難点でした。

Ⅰ. フィールドの文字数制限 各フィールドには、最大 2,047 文字の Unicode 文字しか含めることができない。 docs.aws.amazon.com

Ⅱ. Amazon QuickSightユーザー作成が必要 自己プロビジョンまたは事前のユーザー招待により Amazon QuickSight にサインインを行うAmazon QuickSight ユーザー(or IAM)を登録する必要がある。 ユーザー登録はこちらの記事が参考になります。

その他、IdP フェデレーションを利用した認証など検討しましたが、ユーザー作成は必須とのことでした。

Amazon QuickSightの活用

以下、元々の実装とAmazon QuickSightでの描画比較になります。(同一データではないのでざっくりでの比較になります)

使用しない(うまく活用できなかった)描画で実装を削除したものもあります。

  • chart.jsでの描画 (テストデータ)

    f:id:always_protein:20220325124822p:plain
    chart.js実装時

  • Amazon QuickSightでの描画 (テストデータ)

    f:id:always_protein:20220325132253p:plain
    quicksight実装時

  • Vue-good-tableでの描画 (テストデータ)

    f:id:always_protein:20220401120304p:plain
    vue-table実装時

  • Amazon QuickSightでの描画 (テストデータ)

    f:id:always_protein:20220401120034p:plain
    quicksight実装時 (table)

終わりに

今回はAmazon QuickSightの活用を紹介させていただきました。 BIツールに限らず業務効率化が図れるよう事業部とコミュニケーションをとりながら実装しております。

最後にUUUMでは、好奇心旺盛なエンジニアを募集しております。 https://www.wantedly.com/projects/861137

チームにScrumを導入してみての振り返り

みなさんこんにちは!

UUUMシステムユニットの sawa__it です。

10ヶ月の子どもが全然離乳食を食べてくれません。どうしたらいいですか?(ガチ)

自己紹介

UUUMには2020年の12月に入社しました。

最初は社内の数値管理システムを担当し、現在ではクリエイター管理システムの担当をしております!

役割はPMです。

PMといってもコンテキストが定まっておらず実態はプロダクトマネジャープロジェクトマネジャーエンジニアリングマネジャーが混ざったようなことをしております。

前職では順番待ちシステムの会社で主に某大手回転寿司チェーン向けにオウンドアプリやアプリ内のスマホオーダー順番待ちタッチパネル配席管理システムの開発及びPMをやっておりました。

2019年にScrumAllienceの「認定スクラムマスター」を取得しており、各種イベントや勉強会にも参加しているので見かけたら声をかけてくれると嬉しいです!

振り返り

上記の通り、役割がいろいろ混ざったようなことをしているためどの立場で何をやってきたかというのは曖昧になりますが参考になれば幸いです。

前提

チームの状態として自分が入る前はこんな感じでした

  • チームは5人(PM含む)
  • なんちゃってアジャイル
  • タスクはアサイン形式
  • 要件が降りてくるだけで自社開発なのに受託開発っぽいという意見があった
  • エンジニアとユーザの関わりが少ない

Scrumの導入

「Scrumは銀の弾丸ではない」とはよくいうもののソフトウェア開発をする部署や人においてアジャイルソフトウェア開発宣言アジャイル宣言の背後にある原則は大事な考え方だと思っており

弊社の経営理念である「セカイにコドモゴコロを」や経営戦略である「もっとアソビナカマを」にもマッチした考え方だと捉えています。

チームにはジュニアエンジニアもいたため今後のキャリアにも備えてフレームワークに則った開発経験がある方がよいと思い、2021年の6月からScrumを導入しました。

導入後にチームとして得て欲しいと期待する点は以下です。

  • フレームワークに則った開発経験
  • 開発の自分ごと化するマインドセット
  • ドメイン知識の吸収
体制について

アンチパターンから入るのも申し訳ないのですが

チームとしてScrumを経験したメンバーが他にいなかったため現在においても自分がプロダクトオーナースクラムマスターを兼務しております。

正直、導入してから半年以上たった今ではチームも成熟し振り返りでチーム自らカイゼンできていると思っているので不都合を感じないのですが、チームのカイゼンにフルコミットできるわけではないのでやはり兼務はしない方が良いです。

特にScrumの導入とチーム異動によってプロダクトを担当したタイミングが近かったこともあり、導入や変更は少しずつと思いつつも「よくわからない奴が急にプロダクトの決定権を持ち開発体制にまで口を出してきた」というような印象を与えたと思います。見え方伝え方にバイアスがかかってしまったのかなと感じているので、やむを得ず似たような状況になってしまう場合には注意が必要です。

スプリントは1週間

最初は「納期に追われるみたいで辛い」「2週間にしたい」という意見もありました。

その都度「1週間の計画が立てられないチームが2週間の計画を立てられるわけがない」と説明し今ではリズムも定着し週ごとに事業の優先度に対応した開発ができていると思います。

これはスクラムマスター研修での江端 一将さんの受け売りでもあります。

スプリントの開始と終了

最初は月曜始まり金曜終わりのスプリントでしたが、祝日でイベントがずれて調整コストが高かったり、月金で休みをとりにくくなってしまったのでおすすめしません。

次に水曜始まり水曜終わりに変更しなるべくオフラインで行うように変更しました。

オフラインはコミュニケーションの観点ではよかったのですが、コロナに阻まれて結局オンラインで1日中MTGとなりました。

水曜日が近づくとプレッシャーがしんどくなってきたという声や、シンプルに座り続けるのがしんどいという理由で曜日を分ける判断をしました。

現在では木曜始まりの水曜終わりのスプリントで回しています。

水曜日に関連プロダクト含めた意思決定の場があるので翌日に計画を反映できるのでちょうどよくやれていると思います。

リファインメント

リファインメントはスプリントプランニングの前に時間をとって行っておりましたが、デイリーでも新しく作った要望に対して説明をするようにしていきました。これによってプランニングの場で改めて説明する必要がなくなりました。

プランニング

プランニングではストーリーポイントを使っていません。

導入時に徐々にScrumに切り替えていこうとする中でストーリーポイントを使った見積もりへの変更を後回しにしてしまったため未だに時間で行っております。

フィボナッチ数を使った時間見積もりって何それ美味しいの

釈明をさせていただくと時間で行っているもののフィボナッチ数で進めているため単位が違うだけで相対的ではあるし、ベロシティの観測にも影響はありません。

そのため、感覚的には長く時間がかかってしまっており結果としてプランニングが時間通りに終わらないことがしばしばあります。

一方で、タスクの見積もりが8以上になると取りかかった際に「朝のデイリーから夕方までに終わらないということになるので分割した方がいいよね、4以下になるようにしよう」という気づきも得られたのでそこはよかったと思います。

タスクはサインアップ方式で行っているため興味のあるタスクについて自ら選択することができます。

旧来のトップダウンのマネジメントには見られない「自分たちで見積もって自分たちでタスクを決定し自分たちで進める」形式はある種逃げ場がないようですが、これまで以上にチームに責任感が生まれたように思えます。

エンジニアとユーザに直接会話してもらう

Scrumではチームが「自己組織化(作業を成し遂げるための 最善の策を、チーム外からの指示ではなく、自分たちで選択する。)」することを目指します。

実はそんな高尚なことを目指しているわけではなく

「大枠はプロダクトマネージャが考えるけど、詳細は手戻りがなるべく発生しないように自分たちでフィードバック受けた方が身になるよね。」であったり「やらされている感」の払拭がメインでそうしていたのですが

実際に行ってもらうと直接話をしてもらうことで以下のような意見が出ました。

  • 要件を落としてもらうだけではわからない課題感や温度感、背景が伝わった
  • ドメイン知識が深まることで既存のコードの意図やおかしい点が分かる

社内とはいえユーザ側と直接会話することでこちらも責任感を高める要因になったのではないかと思います。

ところでスクラムガイドの2020年版に「自己組織化」という言葉が出てこないのはなんでなんでしょうかね。

デイリーは朝と夕方の2回

異動した当初は毎日夕方にデイリーを実施してました。

12月頃からメンバー追加で時間の制限があることから朝に移動しました。

チームの課題としてレビュー待ちの状態のタスクが残ってスプリントバックログを完了できないことが多かったため、バーンダウンチャートをデイリー毎に確認するようにしました。

それはそれで効果があったのですが、朝とったアプローチが上手くいったのか確認するのが24時間後になってしまうため、夕方にも行うようにしました。

また、チームではスプリントに影響を及ぼすような過小見積もりと技術的リスク、不具合、差し込み、体調不良などのリスクを「あばれる君」と称して報告します。「あばれる君」が発動されると、チームは手を止めてリスクを共有し計画を組みなおします。課題が大きければその時点で諦めるタスクを決定します。

Among us の緊急会議みたいな感じですね

「Slackで報告すればいいのでは」という意見もありますが、強制的にコミュニケーションポイントを作ることで報告の流れで課題を報告しやすかったり、アプローチを見直すことができたのでよかったと思います。

スプリントレビュー

スプリントレビューについては特筆するようなこともないのですが、コミュニケーションが増えたことで終わらないものが事前に分かっていることが多いため短い時間で済んでいるように思います。

振り返りはKPT

最初はポジティブに進められそうなYWTを採用しホワイトボードツールで行いました。しかし振り返り慣れをしておらず、課題であれば出しやすいということでKPTをテキストで行うように変更しました。

KPTに切り替えてからもやはり最初は主に自分を主語にした表面的な振り返りばかりでチームに対しての意見は出てきませんでした。

が、「なぜ上手くいかなかったのか」「どうすれば次うまく行くのか」などを半年以上繰り返すことによって徐々にメンバーからもチームに対しての意見が出せるようになってきました。

最後に

このような感じでチームにScrumを導入した流れを振り返ってみましたがいかがでしたでしょうか。参考になるところがあれば幸いです。

最初は一人で頑張っている感じがしましたが、だんだん理解を得られて周りにも評価される実感が得られるのでチームのみならず部署全体に広まれば良いと思ってます。

 

ではでは!

UUUM エンジニア デスクツアー vol.1

みなさんこんにちは!

UUUMシステムユニットエンジニアのendo_tです。

春花粉の猛威にやられて目薬を消費しながら、必死に書かせていただきます🙇‍♂️

はじめに

最近、コロナの影響で在宅での業務が増える中でUUUMではほぼフルリモートの環境に変わり2年弱が経過しました。

2年も経てば在宅での作業環境もそろそろ確立され、充実したエンジニアライフを送っていることと思い、

今回、UUUMエンジニアデスクツアー[vol.1]と題してUUUMシステムユニットメンバーの作業デスクを覗き見ちゃおうと企画しました🥰

この記事は以下のような人におすすめ!

  • 作業環境に満足いってないから改善したい
  • 誰かのデスクを参考にしてもっと充実した環境を整えたい
  • UUUMのエンジニアってどんな人がいるのか気になる

今回は、システムユニットメンバーから3名にインタビューし、 デスク周りはもちろんこだわりポイントや趣味、エンジニア歴・在宅ワーク歴も共に紹介していきたいと思います。

1人目

まず1人目は、社内数値管理システムの開発に携わっているsendo111さん。 Ruby,Rails,Python,Vueをメインに業務で使用しており、使用しているエディタはVS Codeだそうです。

  • エンジニア歴
    • 7年目
  • 在宅ワーク歴
    • 2年目

デスク全体

そんなsendo111さんのデスクがこちら。

デスク全体(sendo111)

綺麗に配置され、ワイドモニターとサウンドバーの存在感があるデスクですね。

ディスプレイ

DELLの34インチワイドモニター
DELLの34インチワイドモニター

以前までは、Macをクラムシェルモードで使用しデュアル・トリプルディスプレイ体制をとっていたそうですが、 最終的にワイドモニター + Macディスプレイの形に落ち着いたそうです。

ワイドモニターほしい...

sendo111さん曰く、ワイドモニターの荷重に耐えられるアームとデスクは気をつけた方が良いとのこと🤔 (彼のデスクは5mmほどたわんでるそうです。)

キーボード/トラックパッド

BAROCCO MD770(クリア軸)/Magic Trackpad
BAROCCO MD770(クリア軸)/Magic Trackpad

キーボードはMISTELの左右分離型、クリア軸のモデル。 クリア軸は、打鍵音が少なく個人的に静かな方が気が散らなくて好みだからだそうです。 トラックパッドを真ん中に配置しているのは、できるだけMacBookと配置を近づけたかったからとのこと。

開発のお供

チキチキボーン/ドルチェグスト(カフェオレ)
チキチキボーン/ドルチェグスト(カフェオレ)

業務中のお供は、どハマりしているというチキチキボーンの鶏かわチップスと最近導入したというドルチェグストでカフェオレだそうです。

2人目

2人目は、UUUMクリエイターのサポートシステムを開発しているmukaiyama_tさん。 業務では、Laravel,Reactを使用しておりプライベートではWeb3(Web3.0)、ブロックチェーンのインプットが多いそうです。

  • エンジニア歴
    • 6年目
  • 在宅ワーク歴
    • 3年目

デスク

そんなmukaiyama_tさんのデスクがこちら。

デスク全体(mukaiyama_t)

L字のデスクを使用しており、業務用PC・プライベートPC・趣味用タブレットを配置しているそうです。

L字デスクであるのは、椅子の回転だけで簡単に別環境に転換できるところがこだわりポイントとのこと✨

真ん中のメインモニターは↓画像のHDMIスイッチャーを使用して、業務用のPCとプライベートPCを切り替えてるそうです。

HDMIスイッチャー
HDMIスイッチャー

液晶タブレット

液晶タブレット(mukaiyama_t)

以前は、仕事でイラストレータをされていたそうで、今では趣味としてデジタルイラストを描くそうです。

開発のお供

そんなmukaiyama_tさんの開発のお供は、ねこちゃんだそうです😻 仕事中には、膝のうえに乗ってきてくれるそうで羨ましい...

cat(mukaiyama_t)

3人目

今回、最後のメンバーはLMNDの開発をされているnoraworldさん。 業務では、Railsをメインに使用していて、プライベートでは最近GithubActionsにハマってるそうです。

  • エンジニア歴
    • 4年目
  • 在宅ワーク歴
    • 2年目

デスク

デスク全体(noraworld) デスクはFlexiSpotのE8。電動昇降デスクを使用していて気分転換にスタンディングで作業しているそうです。 スタンディングでの作業は3割ほどで気分転換にはちょうど良さそうですね☺️

PCはクラムシェルモード、モニターはデュアルで使用しているようです。

キーボード/マウス

BAROCCO MD600v3 RGB/logi MX Ergo
BAROCCO MD600v3 RGB /logicool MX Ergo

キーボードは、MISTELの左右分離型を使用してみたそうですが左右分離型は合わなかったそうで次の相棒を探してるそうです。 マウスは筆者も3年ほど使用しているMX Ergo。角度を二段階に変えられて手首への負担を軽減できて重宝してます。

マイク

SHURE SM7B
SHURE SM7B

趣味でゲーム配信もされるそうでマイクにもこだわったそうです。

このマイクはSHUREのSM7Bと呼ばれるモデルで、これのオリジナルであるSM7は、マイケル・ジャクソンの「スリラー」の録音でも使用されたモデルだそうで、こだわりMAXの一品✨

開発のお供

PCで動画をみることがときどきあるそうで、自身で開発したChrome拡張を使用しているそうです。

Video Commander

僕もインタビュー後に使用させていただいてますが、キーコマンドの操作だけで再生速度の変更や繰り返しみたい部分をLoopしたりととても便利でした。 ウェブストアからインストールでき、Youtube以外の動画のあるサイトで使えるそうなので気になる方はチェックです💁‍♂️

まとめ

今回は3名のシステムユニットメンバーにインタビューさせていただきデスク周りや業務のお供を紹介させていただきました! 在宅ワーク経験が2年目となると自身の環境が確立されていてインタビューしていてとても楽しい時間でした。

UUUMシステムユニットにはまだまだ発掘できていないデスクがあるので、次回も楽しみにしていてください。

個人的興味からはじまった今回の記事でしたが、読んでいただけた方のデスク環境充実の参考になれば嬉しいです。

ハッカソンで優勝を勝ち取ったプレゼンの話

UUUMシステムユニットでPMをやっているエムです。 前々回、前回に続き、今回もハッカソンについての話題を書きたいと思います。

第二回オンラインハッカソンでは私が参加したチームが見事総合優勝をいただき、美味しいご飯を食べることができました。

私は非エンジニアなので開発はしておらず、主に発表資料の作成と当日のプレゼンを担当したのですが、優勝を勝ち取るために工夫したことのお話をつらつら書いていこうと思います。

なお、今回の記事は開発についての内容ではないので、箸休め的にお読みくださいませ。

同じチームのエンジニアendo_shizukaさんが開発の裏話を書いているので、こちらも是非ご覧ください↓ system.blog.uuum.jp

非エンジニアが開発に参加しようとしてみたものの…

私が参加したチームはメンバーが3人いて、発案者と開発者がバラバラだったので、ハッカソンの日を迎える前に事前に何度か集まり打ち合わせを行いました。 作りたいもの、ゴール設定、開発要件のすり合わせ、当日の進行、役割分担など、実業務で行うように結構本格的な話し合いができていたと思います。

当日どのように開発を進めるかの話で、私もエンジニアさんと一緒に画面共有しながらコードいじったりしてみようということになりました。

そして当日。 リポジトリをクローンしたり、 Google Apps Scriptでコード書いてみたり、教えてもらいながら色々やってみたのですが…

意外と時間足りなくね?

ってことに気づき、これじゃ作りたいものすら完成しない=賞金がもらえないので、途中からスピード効率重視で開発を進めることにし、PMエムへの伝授タイムは一旦中止に。

開発に貢献できない私は、発表にパラメータを全振りすることにしました。

どんな発表資料にしようかな

発表資料の作成に時間を確保することができたので、まずは世に溢れているプレゼン資料の記事を読む。 構成、情報量、デザイン…抑えるべきポイントがたくさん出てきます。

それらを意識したうえで、今回の発表では特に大事だと思った下記を重点に資料作りをしようと思いました。

・成果物の必要性をアピール
・ターゲットを意識する
・目を惹く資料、関心を引く発表

成果物の必要性をアピール

私の参加したチームでは、Google Meet上でミーティング招待者の参加状況をひと目で確認できる機能を開発したのですが、これは私が日頃業務で感じている不便さや不満を解消したい思いをぶつけた機能です。 なので、どうしてこの機能が必要か、この機能がないと何故困るのか、のWhyは自分の中ではっきりしていました。

ただ、それをつらつらと文字で説明しても短い発表時間では伝えきれないので、 「機能がないと損すること」「機能があれば得すること」の観点で簡潔に伝え、この機能が必要だと思ってもらう印象付けをしました。

▼この機能がないと時間が無駄になっていると思わせる

↑この時ネットミームになっていた「45秒で何ができる?」という曲が可愛くて好きだったので挿絵的に盛り込みました

▼作業量のbefore afterを並べ、やることが劇的に減ることを分からせる

ターゲットを意識する

今回のターゲットは誰か。 外部向けの発信ではなく、UUUMのシステムユニット内での発表。つまり、内輪ネタが使える範囲です。

UUUMのシステムユニットは、ちょっとボケてもリアクションしてくれる、寛容に受け入れてくれる、いじってくれる素敵な雰囲気のメンバーで構成されています。(※個人の感想です)

なので、発表を流し聞きしていても耳に止まるようなネタ(知っているネタ)を挟むことで、興味が沸き、発表内容にも関心を持ってもらえると思いました。

僭越ながら、特に関心を惹きそうなシステムユニットの偉い方々に勝手に出演していただき、スライド上で今回の成果物を盛り上げていただきました。

▼普段温厚なNさんやTさんをキレさせてみたり…

▼ガッチリなYさん、ワイン好きのNさんの特徴を表してみたり…

▼Iさんがいつも愛用しているヘッドホンの色にもこだわりました

このくだりの時が一番ウケていた気がします。はい。

目を惹く資料、関心を引く発表

当たり前情報ですが、スライドに書く内容は目で見た時に入る情報量に抑え、細かい情報や補足は口頭で伝えるように、発表のシミュレーションをしながら情報を整理して資料を作成していきました。

また、発表の際に心をつかむためには、話し方の強弱や補足の入れ方が大きく影響すると思うので、テンポ良く発表できるように絵を多めに入れて、ストーリーを意識した構成にしました。

非エンジニアの私が作る資料なので開発寄りの詳細な情報は書けない…ということも逆に割り切って、細かい開発過程には触れず、この機能を使った時のことを重点的にアピールして、堅苦しくならない説明にまとめました。

これ大事。発表前のイメトレ

私は緊張しいで、ぶっつけ本番だと絶対に噛んでグダる!と分かっていたので、余った時間でひたすらイメージトレーニングしてました。

各チームでもらえた発表時間が5分ずつだったのですが、オーバーした場合は強制終了になってしまうので、きちんと時間通りに収まるようにタイマーをセットしてイメトレしてましたw

リモートで参加していたので自宅にいたのですが、シーンとした部屋で自分の声だけがブツブツ響いて…すごく恥ずかしい状況でした。 でも、これをやっておいたおかげで、発表の流れがスムーズになり、時間もピッタリでグダることなく思い描いた通りの発表ができたかなと思います。

いざプレゼン!

発表資料は作り込んでいましたが、それをそのまま読み進めても多分聴いている人の心には響かない。 なので、スライドに書いてあること以外にも、自分なりのコメントを挟んだり、文字起こししていない図の解説を口頭で補足したり、少しふざけてみたり…

発表中は緊張してぶっちゃけ頭が真っ白でしたが、笑いやツッコミなどいいリアクションをもらうことができて、手応えを感じることができました。 (でもまさか優勝できるとは思ってませんでした)

振り返り

偉そうにつらつら語りましたが、結局私が難しい開発の話ができなかったり、説得力のある説明が苦手だったりするので、自分ができそうな発表をイメージして資料作成した結果、このようなプレゼンに落ち着きました。

結果論にはなりますが、変に背伸びせず自分が納得した形でプレゼンができたことで、アピールポイントが伝わり最終的に評価いただけて、良かったかなと思います。

それと、今回ここまでプレゼンにこだわれたのは、チーム内でしっかり役割分担ができていたこと、安心して開発を任せられるエンジニアさんがいたこと、そのおかげで時間が確保できたからだと思います。

毎回この状況に恵まれるとは限らないので、どんな時間がない状況でも良いプレゼンができるようになりたいです。