ユニファ開発者ブログ

ユニファ株式会社システム開発部メンバーによるブログです。

Amazon SQSとShoryukenを使ったバックグラウンド処理を検討してみる

Webエンジニアのほんまです。

弊社ではインフラの管理コストを極力減らすため、AWSのマネージドサービスへの利用を推奨しています。(例:RDS -> Aurora)

その中の一つに「バックグラウンドジョブに使うキューストアに Amazon SQS を使う」というものがあります。 SQSを使うことで急な負荷増減やデータ消失への対応といった悩ましい問題から解放されます。

Ruby on Rails で Amazon SQSをストアとするバックグラウンドジョブフレームワークだと Shoryuken がよく使われている印象です。 今回、Amazon SQS と Shoryuken でバッググラウンド処理を動かす方法、そして本番運用を見据えて検討が必要な事項を調査したのでシェアしたいと思います。

続きを読む

新型コロナウィルス(COVID-19)環境下における保育施設の利用状況の分析

はじめに


こんにちは。研究開発部の島田です。今回は新型コロナウィルス(COVID-19)環境下における全国の保育施設への影響について、ICTサービスキッズリーの連絡帳機能のデータを使って調査・分析を行いましたので、その結果をご報告いたします。

分析条件


本調査では、ICTサービス「キッズリー」を利用している保育施設(全国2000施設以上)に対して、各施設における登園・欠席情報を元に、2020年2月1日〜2020年5月31日の期間で分析を行いました。

キッズリーに登園または欠席情報どちらも入力されなかったユーザーのデータは分析には含まれていません。

10都道府県における園児の登園状況


新型コロナウィルスの感染拡大を受け、日本政府は2020年4月7日に緊急事態宣言を発令しました。対象地域は、7都府県(埼玉県、千葉県、東京都、神奈川県、大阪府、兵庫県、福岡県)。さらに、4月16日には対象地域を全国に拡大し、その後5月14日、5月25日と段階的に全国で解除されました。

本調査では、10都道府県(東京都、大阪府、神奈川県、千葉県、愛知県、兵庫県、北海道、埼玉県、福岡県、京都府)それぞれについて以下4つの期間(平日5日間)における保育施設への園児の平均欠席率を算出し、ヒートマップで可視化しました。

  1. 2020年3月23日〜3月27日
  2. 2020年4月13日〜4月17日
  3. 2020年5月11日〜5月15日
  4. 2020年5月25日〜5月29日

結果は下図のようになります。

f:id:unifa_tech:20200603172838p:plain:w700 図1 : 10都道府県における保育施設の園児の平均欠席率

地域差はありますが、緊急事態宣言が出されて以降、多くの地域で園児の欠席率が増加傾向にあり、特に宣言が発令された直後の4月13日の週(期間2)では関東を中心に平均欠席率は80%近い状態であったことがわかります。

また、直近の5月25日の週(期間4)においては、平均欠席率が関東でも60%程度まで下がってきており、緊急事態宣言が解除されたことによって、少しずつ登園する園児が増えてきていることが見てとれます。

10都道府県における緊急事態宣言期間の保育施設の稼働状況


本調査では、10都道府県(東京都、大阪府、神奈川県、千葉県、愛知県、兵庫県、北海道、埼玉県、福岡県、京都府)において、緊急事態宣言が発令された直後の2020年4月13日〜4月17日を対象期間とし、その期間における保育施設の稼働率を算出しました。

なお、今回の調査における保育施設の稼働率の定義については、対象期間内に1人以上の園児が登園された場合を稼働しているとし、登園園児数が0人だった場合を未稼働としました。

f:id:unifa_tech:20200603155702p:plain:w700 図2 : 10都道府県における緊急事態宣言期間の保育施設の稼働率

新型コロナウィルス感染拡大が続く中においても、いずれの地域も75%以上もの保育施設が稼働しており、地域によっては90%以上稼働していることがわかります。

欠席コメント欄への記入率の推移


キッズリーでは園児が欠席する際には保護者がコメントを残せる機能があり、そのコメント欄への1日ごとの記入率を算出しました。なお、本調査では全国の保育施設のデータを対象とし、分析対象期間は2020年2月1日〜4月30日としました。

f:id:unifa_tech:20200603160824p:plain 図3 : 欠席コメント欄への記入率

横軸は日付、縦軸が欠席コメント欄への記入率[%]を表しています。

土日に登園する園児数が少なめであるため、周期的にデコボコしているグラフになっています。

2020年4月7日以前では、平日における欠席コメント欄への記入率はおよそ55%前後で推移していますが、緊急事態宣言が発令された2020年4月7日以降では欠席コメント欄への記入率がおよそ75%程度で推移しており、これまで以上にキッズリーの連絡機能を使って園と保護者間でのコミュニケーションツールとして活用されていることがわかります。

欠席コメント欄の頻出単語を可視化


緊急事態宣言が発令されて以降、欠席コメント欄に書かれた内容にどのような変化があったか分析をしました。なお、本調査では全国の保育施設を対象とし、分析対象期間は以下の2期間としました。

  1. 2020年2月1日〜2020年2月29日
  2. 2020年4月1日〜2020年4月30日

頻出単語の分析には自然言語処理(MeCabによる形態素解析)を施しました。

頻出単語の上位20位がこちらになります。

2020年2月 f:id:unifa_tech:20200602214119p:plain

2020年4月 f:id:unifa_tech:20200602214545p:plain

図4 : 欠席コメント欄の頻出単語上位20位

緊急事態宣言が出される前後では、欠席コメント欄への記入内容に明らかに傾向が違うことがわかります。4月はコロナ、コロナウィルスといった単語だけでなく、在宅や自宅といった単語が上位に来ており、緊急事態宣言期間においては多くの家庭が家庭保育をしていたことが示唆される結果となっています。

最後に、頻出単語をその頻度に応じた大きさで可視化した結果がこちらです。

f:id:unifa_tech:20200602201555p:plain 図5 : 欠席コメント欄の頻出単語の可視化

本データの引用について


本記事中の調査・分析結果を引用される際は、必ず下記問い合わせページからご連絡ください。

その上で、引用される際は「ユニファ株式会社調査結果」の明記とリンクをよろしくお願いいたします。

unifa-e.com

最後に


本記事では新型コロナウィルス(COVID-19)環境下における保育施設の利用状況について、ICTサービスキッズリーの連絡帳機能のデータを使って調査・分析を行いました。

本調査から、保育現場は新型コロナウィルス感染拡大が続く中においても子どもたちの安全と安心を守るために最前線で対応していることがデータからも明らかになってきました。

こういった状況を踏まえ、ユニファ株式会社では最前線で働く保育者をはじめとする保育現場スタッフと保育施設を応援するため、以下の二つのプロジェクトを実施中です。

unifa-e.com

unifa-e.com

是非ご協力をよろしくお願いいたします。

Terraform内でGithubのreleaseをダウンロードして利用する

おはようございます、こんにちは、こんばんわ ユニファでインフラみてますすずきです。

緊急事態宣言も解除されましたがリモートワークで引きこもり中です。

そんな中、TerraformでGithubからパッケージをダウンロードしながらLambdaにアップロードできるのか試してみたのでそれを書いてみます。

今回ダウンロードしてみるものはDatadog Forwarderです。
プライベートな話ですが、DatadogでLambdaのEnhanced Metricsを取得する記事を書いていたりするのですが(リンクは載せない)、それに利用するのがこのDatadog Forwarderです。
Datadog ForwarderをTerraformで導入しようとすると、Terraform使ってるのにCloudFormationを呼び出してYAMLを食わせるパターンになってしまいます。それはやりたくないということでダウンロードしてみる方法を試してみました。

※ 今回の最終的なコードGist

続きを読む

サーバ / アプリ担当者が混在するチームにおける、ベロシティ計測・リファレンスストーリーの考え方

突然ですが、バーンダウンチャートを眺めていると、あれやこれやを考えて、「あぁ、あのときこうしておけば…」「おっしゃ!良い感じ良い感じ!」「次が楽しみだなぁ…」「こう来られたら、こんなアプローチで…」なんて思ったりしますよね。

…これ、まるで恋をしているようではありませんか?

そうなんです、私達はバーンダウンチャートに恋をしているのです。

本題

改めましてこんにちは、スクラムマスターの渡部です!

今回は、サーバ / アプリ担当者が混在するチームにおける、ベロシティ計測・リファレンスストーリーの考え方について説明していきます。

「サーバ / アプリ担当者が混在するチーム」と記載しましたが、要はそれぞれで専門領域があり、お互いの作業を代わることができない場合のことです。

考えれば納得なのですが、自分も迷いましたし、なかなか言及している記事も見つからないので、同じ悩みを抱える方のためにも残しておきます。

  • 本題
  • 結論
    • 前提
  • ベロシティ計測
    • パターン①:同じチームなんだし、サーバ / アプリの見積もりをまとめて表示しちゃおうよ!案
    • パターン②:担当する作業ごとに分けて表示しようよ!案
  • リファレンスストーリー
  • まとめ
  • さいごに

結論

はじめに結論ですが、同じチームと言えど、お互いの作業を代わることができないのであればリファレンスストーリーは別々で用意し、ベロシティ計測も異なるチームとして扱うべきです。

では何故そうすべきなのか?については、以降のセクションで、「ベロシティ計測」「リファレンスストーリー」の順に図を使いながら説明していきます。

前提

なお、以降の説明では下記の前提条件を使用していきます。

  • 人数
    • サーバ担当:3名
    • アプリ担当:2名
  • 合計見積もり
    • サーバ:250pt
    • アプリ:50pt
  • 1 sprintで一人あたり、 5pt を消化できる
    • サーバ:3名 × 5pt = 15pt
    • アプリ:2名 × 5pt = 10pt
続きを読む

Create SlackBot using AWS API Gateway and Lambda

By Maimit Patel, Software Engineer at ユニファ

In this blog I am going to create SlackBot using AWS API Gateway, AWS Lambda and Slack Event API.

What is SlackBot?


A SlackBot is a regular app that is designed to interact with the user via conversation. When user mention the SlackBot app from anywhere in the slack then it will access the APIs and do all of the magical things that Slack App can do.

Let's get started


1. Setup Slack App

  • Go to the Slack apps home page and click Create New App button.

    f:id:unifa_tech:20200519115444p:plain
    Create Slack App

  • Add scopes under the OAuth & Permissions menu

    f:id:unifa_tech:20200519155321p:plain
    Bot scopes

  • Installing App to Workspace

    f:id:unifa_tech:20200519162951p:plain
    Install App to Workspace

  • This will create Bot User, check it on App Home page

    f:id:unifa_tech:20200519163139p:plain
    Bot User on the App Home

2. Configure Docker Image to run the Lambda function in the local environment

  • Pull the lambci/lambda:ruby2.7 docker image
# Open command prompt in your local machine and 
# hit this command to pull the docker image of Lambda with runtime Ruby-2.7 
$ docker pull lambci/lambda:ruby2.7

3. Create a Lambda function that responds to the Slack

  • Setup application directory to store the Lambda ruby function
# Creating directory
$ mkdir greeting-bot 

# Move to directory
$ cd greeting-bot 
  • Create file greeting_bot.rb under greeting-bot directory
# Creating ruby file under greeting-bot directory
$ touch greeting_bot.rb
  • Set environment variables

    • Find Bot User OAuth Access Token under the OAuth & Permissions menu from Slack App

      $ export BOT_OAUTH_TOKEN='bot_oauth_token'

    • Find Verification Token under Basic Information menu from Slack App

      $ export VERIFICATION_TOKEN='verification_token'

  • Update the file greeting_bot.rb

class GreetingBot
  def self.main(event:, context:)
    new.run(event)
  end

  def run(event)
    case event['type']
    when 'url_verification'
      verify(event['token'], event['challenge'])
    when 'event_callback'
      if event['event']['type'] == 'app_mention'
        process(event['event']['text'], event['event']['channel'])
      end
    end
  end

  private

  # Verify request from the slack
  def verify(token, challenge)
    if token == ENV['VERIFICATION_TOKEN']
      { body: { challenge: challenge } }
    else
      { body: 'Invalid token' }
    end
  end

  def process(text, channel)
    body = if text.strip.downcase.include?('hello')
             'Hi, How are you?'
           else
             'How may I help you?'
           end
    send_message(body, channel)
  end

  # Slack API response to the mentioned channel
  def send_message(text, channel)
    uri = URI('https://slack.com/api/chat.postMessage')
    params = {
      token: ENV['BOT_OAUTH_TOKEN'],
      text: text,
      channel: channel
    }
    uri.query = URI.encode_www_form(params)

    Net::HTTP.get_response(uri)
  end
end
  • Run this Lambda function in the local environment and response back to the mentioned channel from request
# Make sure the mentioned channel(i.e greeting-channel) has already invited the greeting-bot that we have created in step 1

 docker run \
  -e BOT_OAUTH_TOKEN=$BOT_OAUTH_TOKEN \
  --rm -v "$PWD":/var/task lambci/lambda:ruby2.7 \
  greeting_bot.GreetingBot.main \
  '{"type": "event_callback","event":{"type":"app_mention","text":"<@U>hello!","channel":"greeting-channel"}}'
  • Result in local f:id:unifa_tech:20200519164324p:plain

4. Upload Lambda function to the AWS Lambda

  • Make sure you have created a Lambda function in AWS.

  • Upload Lambda function from the local machine using AWS CLI

# Creating zip file
zip function.zip greeting_bot.rb

# Upload zip file to the Lambda
$ aws lambda update-function-code --function-name slack-greeting-bot --zip-file fileb://function.zip
# add `--profile profile_name` if you got the AccessDeniedException
  • Set environment variables BOT_OAUTH_TOKEN and VERIFICATION_TOKEN in Lambda

  • After upload to Lambda, it looks like this

    f:id:unifa_tech:20200520180607p:plain
    Lambda Function

5. Create REST API end-point using API Gateway that calls the lambda function

  • I have created API Gateway

    • How to create REST API using API Gateway? read more
  • Add trigger to Lambda function

    • Click the Add trigger button from the designer pane of the Lambda function
    • Select the trigger(i.e API Gateway) from options
    • Select the REST API created in the step 5

f:id:unifa_tech:20200520100910p:plain
Added API Gateway Trigger to Lambda function

6. Set the API Gateway end-point to Slack Event Request URL

  • Go to Event Subscriptions menu from the Slack App and enable the event subscription
  • Enter and Verify the Request URL on same page
    • Request URL is API Gateway end-point that we have done in step 5
      f:id:unifa_tech:20200520111454p:plain
      Enable event subscription & Verify RESR API end-point

7. Test the SlackBot by calling from #greeting-channel

f:id:unifa_tech:20200520173725g:plain

For full implementation refer GitHub repository
Thank you for reading

新型コロナウイルスと多国籍チーム

みなさんこんばんは。

ユニファでエンジニアのマネージャーをしている田渕です。

これまでユニファの開発者ブログでも、何回かに渡り新型コロナウイルスに端を発した 在宅勤務に関する記事やインフラ関連の記事などを公開してきましたが、 今回は新型コロナウイルス による非日常をマネージャー視点で見たときの気付きについて書いてみました。

まずは前提

本日の内容を理解頂くにあたっては、現在私がマネジメントをさせてもらっているメンバー/チームの構成について まずは説明する必要があります。

  • 現在、私を除くと全部で17名のエンジニアが居ます。

  • そのうち、国籍が日本ではない方は、12名です。

  • 参考までに国名を記載しておくと、中国、韓国、台湾、フィリピン、インド、バングラデシュ、スペイン、イギリス、ポーランド、ロシアです。

  • 他の記事でも触れられているように、現在の勤務は基本的に在宅勤務です。

実は日本国籍のメンバーの方が少ないのです。

日頃のコミュニケーションはどうしているかと言うと、人によってまちまちです。 英語で話す人、英語と日本語を混ぜて話す人、日本語で話す人。 同じ国の出身の方々はそれぞれの母国語でお話したりもしています。

会議などはそのときの参加者によって、話す言葉やドキュメントに記載する言語を変えます。 私自身も英語は微妙なのですが、そこはもう開き直って話しますし、書きます。

f:id:unifa_tech:20200515192510j:plain
ミーティングの様子

不穏な空気が流れはじめた1月末

この数ヶ月、色々なことがあり、なんだか既にとても遠い昔のような感覚ですが。。。 日本国内で「新型コロナウイルス 」の話が本格的に聞かれるようになったのは、1月下旬くらいだったでしょうか。 その頃、まだ日本人はどこか対岸の火事のような感覚だった方が大半ではないかと思います。

先に記載した通り、ユニファには中国国籍のメンバーも居ますし、私自身にも中国人の友人が居ることもあり、 かなり早い段階でそれらの方々から「これはヤバイ。」と言うことを具体的なエピソード付きで言われて警戒していたのを覚えています。 その頃から少しずつ、メンバーのそれぞれの国に関しての情報を集めはじめました。

この環境下でやってきたこと

色々な国のメンバーがいる環境下での非日常は、気をつけることがたくさんあります。 この状況下で、具体的にどんな取り組みをしてきたのかを書いていきたいと思います。

なるべく孤立を防ぐ

背景

メンバーの中には「ユニファに入社するために初めて日本に来た」と言う方もいます。(ありがたいことです。) そのような慣れない環境の中で経験したことのないパンデミック、しかも自粛で部屋に籠もらなければならないと言うのは、なかなかに厳しい状況でした。 やはりメンバーからは「寂しい」と言った声を聞くようになりました。

やったこと

日頃やっている1 on 1などで、日々の生活についてこれまで以上に気にかけて聞くようにしています。 また、月に一度やっているBeer bash(エンジニアのLT会)などを通じ、オンラインで他のメンバーと交流できる機会を作っています。 このあたりはまだケアが足りていないと思っているので、もう少し気軽にコミュニケーションが取れないかと模索しているところです。

情報を届ける

背景

新型コロナウイルスに対する警戒度や対策は、国によって大きく異なります。 日本はどのようなスタンスで、どのような対策を行うつもりなのか、と言うことを知りたいとみなさん思っていることでしょう。 ですが、刻々と変わるこれらの情報に対し、当初は外国語による説明が充分ではありませんでした。 日本語が不得手なメンバーにはやはり情報が届きづらい状況が続きました。

基本的にメンバーは自分の母国のニュースを日々見ていますし、そこに書かれている日本に関する情報が本当ではないこともあります。 また、今回の新型コロナウイルスへの対応を通じて多くの方が感じたように、文化、政治、宗教などの要因により、国によっても考え方が全く異なります。 「日本では法律に基づいた強制的なロックダウンが出来ない」と言うことは、この状況になるまで私を含む多くの方は知らなかったことと思います。 そう言う「日本ならでは」の部分は、外国籍メンバーにとってはそれまでの自分の生活環境、常識とのギャップになります。

やったこと

政府や会社から出された取り組み、方針に対して、都度英語で情報をまとめ、発信するようにしました。 また、その背景、他の国々との違いまで丁寧に伝えるように努めました。 例えば、「日本では海外でやっているような強制的なロックダウンは出来ない」と言ったような部分です。

何が出来て、何をしてはいけないのか。 日本人同士では意外と曖昧にできる線引きを、細かく具体的に伝えるようにしました。

情報収集

背景

様々な国のメンバーがいるので、メンバーのケアのため、またそれぞれの国と日本の違いを説明するためにも、 各国がどのような状況かを把握しておく必要がありました。

やったこと

海外のニュースサイトなどを日常的にあちこち見て回りました。 やはり日本のニュースサイトで記事にされている海外の情報は限定的なので、色々な国の情報を集めるためにはあちこちに飛ぶ必要がありました。 また、それぞれのメンバーから、聞ける範囲で母国の状況を聞くようにしました。 それらの情報はサイトなどを見るよりも一層リアリティ、信憑性があり、色々なことを考えるきっかけになりました。

気付き

自分自身にとっても初めての経験で、色々と試行錯誤しながらここまでやってきましたが、気づいたこともありました。

その気になると意外と海外の情報が手に入る

今まではそこまで真面目に海外のニュースサイトを見ることはなかったのですが、 今回改めて見るようになると、国による報道のスタンスの違いや考え方の違いなども感じることが出来ました。 また、思っていた以上にその気になるとちゃんと情報が拾えるんだな、と言うことも感じました。 これはインターネットの環境が整い、文章だけでなく動画まで含めてストレスなく閲覧できる環境になっている、と言うことが大きいと思います。

さいごに

全世界的に、「新型コロナウイルスとの戦いはまだまだ長いだろう」と言う空気が出始めています。 長期化が予想される中、どのようにすればよりストレスを低減し、安心して働くことが出来るのかと言うことについて、 更に模索していかねばならないと感じています。

一日も早く、元のような日常に戻ることを祈りながら、今後も色々と地味だけれど新しい取り組みを続けて行こうと思います。

ユニファでは一緒に働いてくれる仲間を募集中です!

unifa-e.com

Manager README ver.20200502

皆さんこんにちは、ユニファでCTOをしてます赤沼です。

最近改めて、自分が何をする人間であり、どういうタイプの人間なのかを見つめ直してみようと思う機会がありました。そんな時に下記の yoshiori さんの manager README を目にしたので、私もそれを真似て README を書いてみました。目的は yoshiori さんと同様で、これを公開することで、みんな(=社内の開発メンバー)に私がどういう人間なのか、どういうところでみんなにも力を借りたいと思っているのかを理解してもらい、一方的なトップダウンではなく、お互いの強みを活かしてより良いチームを作っていけるようにしたいというものです。

github.com

yoshiori さん同様に、これによってみんなに何かを強制するものではないですし、自分としてはこうありたいと思うことを書いていますがまだまだ不十分なところも多いです。

My Role

経営陣の1人としてユニファの提供するシステムの責任を負いますが、基本的にプロダクト開発はみんなに任せます。「CTO = 組織内で一番技術力のある人」ではありません。 Ruby や Rails については毎日プロダクションコードを書いているサーバサイドエンジニアメンバーの方が知っているでしょうし、AWSなどのインフラ技術についてはインフラエンジニアの方が詳しいです。デザインについてはもちろんデザイナーの方がセンスも技術もあります。それ以外の職種のメンバー含め、開発チームはそれぞれの領域のプロが集まっているので、みんなの方がそれぞれの領域において私よりレベルが高いですし、高くあるべきと思っています。なのでどうやってプロダクトを作るかはみんなの判断を尊重します。

では私は何をする人なのかというと、そういったプロ集団がチームとしてより良いアウトプットを出すにはどうすれば良いのかを考え、環境や体制をつくり、アウトプットを最大化するためのことをする人です。また、良いプロダクトを作るという視点に、経営としてのビジネスの視点を加え、チームが目指す方向を考えます。ユニファには VPoE がいないこともあり、要素としては技術面よりもメンバーのマネジメントやチームアップなど、 VPoE の役割にあたる要素が多いと思います。また、クリエイティブなことやドキュメント作成は苦手分野で、ビジネス領域には疎いので、そういった部分はみんなに助けてもらいたいと思ってます。

みんながいないとプロダクトは作れないので、力を貸してください。

市場価値を上げたい

もちろんみんなとはずっとユニファで一緒に仕事をしていきたいと思っていますが、この業界では転職も珍しいことではないですし、いずれはユニファを離れていく人も多いかと思います。そうなったときに、ユニファでやってきたことが無駄ではなく、それぞれ個人としての市場価値を上げて次に移れるようになっていて欲しいと思っています。そのためには極力やりたいことやスキルアップにつながるような仕事のアサインをしたいと思っていますし、みんなにも向上心を持って取り組んで欲しいと思っています。

フィードバック

私に対して思うことがあれば気兼ねなくフィードバックください。これは間違ってる、もっとこうして欲しいなど、意見があればいつでも声をかけてください。私もできるだけみんながどう思ってるかは汲み取りたいと思いますが、どうしても言ってもらえないと気づけないこともあります。また、良いと思ってるところも言ってもらえると、そこは変えずにキープしておくのが良いとわかるので助かります。

リスペクトを欠いた言動は嫌います

ユニファのようなスタートアップに来る人は部署問わずみんな頑張れる人ですし頑張って当たり前です。面接でもそういう人を採っているつもりですので、みんな最大限頑張ってくれていると信じてます。頑張った結果、結果が伴わないことや、進め方が良くなかったこと、他の領域のプロからしたらセオリーを無視した形になることもあり得ます。それに対しての嘲笑やリスペクトを欠いたネガティブな発言やslack等での書き込みは問題視します。表面的な結果だけでなく、その裏にある事情も想像しましょう。もちろん建設的な議論やフィードバックは大歓迎です。

縛りたくないしマイクロマネジメントもしたくない

基本的にみんなには自由にやってもらいたいと思ってますので、それぞれやりやすいやり方で、私が細かいことに口を出さなくてもよしなにやってくれるのがお互い楽で良いと思っています。そのためにもみんなには自主性とアウトプットを求めます。リモートワークも相まって、アウトプットがないと私からはみんながどれぐらい仕事をしてるかは見えません。JIRAコメントによるステータスアップデートや Bitbucket のコミットなど、日々の成果はあまりため込まずこまめに積極的にアウトプットしてアピールしてください。

いつでも声かけてください

日々タイトなスケジュールでプロダクト開発をしてくれているみんなに比べたら私なんて暇なので、いつでも声をかけてください。運悪くミーティングの直前や急ぎの仕事があるときに当たってしまった場合は時間をずらさせて欲しいと言うかもしれませんが、気兼ねなく声をかけてもらってOKです。 Slackでの私へのメンションも夜間や休日でもOKです。むしろメンションしてもらった方が見落としがなくなるので助かります。

その他やってること

  • システム開発本部予算検討

    • 毎年の予算計画でシステム開発本部として必要な予算(プロダクトのインフラ費用や開発環境、外部への委託費用などなど)を検討し、会社全体の予算計画の中ですり合わせをします。
  • 技術ブランディング

    • ユニファ開発チームがどんなことをやっているか、どんなメンバーがいるかを外向けに露出する機会を増やし、技術的な信頼度の向上や、採用のためのブランディング活動をしています。
  • 採用関連

    • 人材紹介会社の方にどんな人材を求めているかを説明して打ち合わせしたり、応募者の書類選考、面接、オファー面談などを行っています。
  • 社内インフラタスクサポート

    • 社内インフラチームは1人しかいないので、対応可能なタスクはサポートしています。
  • データ基盤構築での技術検討など

    • データ基盤を構築していくためのアーキテクチャ検討にあたって GCP や AWS において何を使っていくのが良いのかの検討を行っています。

パーソナリティー

  • 内向的&人見知りで自分から話すのは苦手なのでパーティー等ではぼっちになりがちですが、話しかけられるのは大歓迎です。
  • 気弱ですがそのくせ時々勢いで色々始めてみたりします。
  • O型なので大雑把で楽観的です。

これは常にWIPです

この内容は 2020/05/02 現在のスナップショットなので、役割や考え方が変われば今後内容の変更や大幅な修正も大いにあり得ます。