便利だったライブラリとか

目的

何かひさしぶりにアウトプットしたくて、書いてみた。

aws-sdk-rails

https://github.com/aws/aws-sdk-rails

SESを利用したメール送信

ActionMailer にSES利用が可能

今まではこんな感じで設定して使っていたが、必要なくなった

  def initialize(settings)
    ...
  end

  def deliver!(mail)
    ...
   end
end

非同期システム

とりあえずQueueに投げて、裏側で処理するシステムがめちゃくちゃ簡単にできた

こんな感じで送って、

YourJob.perform_later(args)

非同期処理がすぐ実現できる

class YourJob < ApplicationJob
  self.queue_adapter = :amazon_sqs

  def perform(*args)
    ...
  end
end

失敗したらリトライももちろんできるし、Lambdaもいいけど、RailsとAWSアカウントだけで非同期処理がすぐ構築できるのが感動した...

その他

まだ使ってないけど、DynamoDBをsession storeや、データストアとして簡単に使えるそう！

やっぱり、痒いところに手が届く感がすごくて、AWS & Railsはリソースが限られてる時に非常にいいなーと思う。

CDKを使えば、Schedule TaskもECS Schedule & Rails Runner で簡単に実装できて楽だった。

sentry-ruby, sentry-rails

https://github.com/getsentry/sentry-ruby

というかsentryが良い...Slack通知と組み合わせて検知もめっちゃ楽。

active_support_logger というオプションがあると、詳細まで自動で入れてバグ修正がすぐ完了できる。

ただ、Rails Runner の時は、バッググラウンドタスクが動いてないので、 hint: { background: false } オプションを追加する必要がある。

ちょっとだけ、はまってしまったのでメモ。issueみたらすぐ書いてあった。

prisma

https://github.com/prisma/prisma

本番運用はまだだけど、触った感じめちゃくちゃ良さそう。

TypeORMは結構使ってて、あまり不満はないけど、prismaの方が簡単に思えた。

TypeORMもprisma もActiveRecordみたいに経験がないので、今後はこちらに力入れていきたい。

特に、ActiveRecordと比較すると、サジェストがすごく有り難いのと、indexとかもちゃんと考えなきゃいけなくて、経験が少ない新人に触ってもらうには、とても良いと思った。

ベテランばかりの環境なら、Rails最高！書いてて楽しい！こんな書き方があるのか、すごい！とか思うけど、Rubyのようないろんなかっこいい書き方がある言語で、新人にレビューや教えるのが辛い。。。

だから積極的にTSを使っていきたいと思ってる

CDK

GitHub - aws/aws-cdk: The AWS Cloud Development Kit is a framework for defining cloud infrastructure in code

今まではずっとコンソールでポチポチしてたけど、最近先輩が導入したのを参考に、副業先でインフラを担当させてもらった。

ECS入れるだけならCopilotとかいろいろあるけど、特に制限なくなんでもAWS resource をコードで定義できるのはすごくよかった。

RDSを作って、そのIDとpasswordをSecretsManagerに入れるのがサンプルコードにあったり、普段コンソールでみてる設定が改めてドキュメント化されたりしてて、AWSリソースの理解につながった。

あと、やっぱりTSで書けるのはめちゃくちゃよかった。

終わり

最近は副業でしかフロントエンド触らなくなってきて、サーバーサイドとクラウド中心になって知識が少しづつ深まってきた感がある。

やっぱり便利なライブラリはある程度の正解を教えてくれるから、すごく勉強になる。

また、今まではPHP、Rails中心だったのが、最近はTSも半分くらい触ってるから、型付き言語の良さもわかってきた。

チームメンバーによるけど、WEBサービス系だったら、最初はRails & Reactとかで突っ走って、途中からBFFでTS入れて、マイクロサービス 化をそれぞれで適した言語で作っていくみたいなのが、（採用できるスキルセット的を考えても）最近の風潮なのかなーと思った。

あとは、APM周りの導入があまりできてないから、そこを勉強して、ある程度のパフォーマンス改善もしていきたい。

Flutter & Firebase のBackendをRailsで作る

目的

Flutter & Firebase を利用したBackendのAPIをRailsで作ってみる。

やったこと

Railsの初期セットアップ

bundle init して、生成された Gemfile の railsをコメントアウト

$ bundle config set path 'vendor/bundle'
$ bundle install
$ bundle exec rails new . --api
$ echo vendor >> .gitignore
$ git init
$ git add .
$ git commit -m "first commit"

$ bundle exec rails s

で、localhost:3000 番でRailsが開ける

DBのModelを作る

$ bundle exec rails g model members
$ bundle exec rails migration

認証を作成

Flutter から Firebase で呼ばれるので、firebaseIDをSDKから取得する。

firebaseToken を検証するRubySDKはないので、こちらをそのまま利用。

RubyでFirebaseのidトークンを認証に使ってみる - Qiita

tokenの取得については、こちらを参考に実装。

【Rails】RailsでAPIの簡単なトークン認証を実装する - Qiita

  def authenticate
    if ENV['DEBUG'].present?
      @firebase_id = DEBUG_FIREBASE_ID
      return
    end

    authenticate_or_request_with_http_token do |token, _|
      @firebase_id = _verify_id_token(token)
    end
  end

Flutter 側の呼び出しを作成

import 'package:firebase_auth/firebase_auth.dart';
import 'package:http/http.dart' as http;
import 'dart:convert';

Future<http.Response> getApi(String path) async {
  final token = await FirebaseAuth.instance.currentUser.getIdToken();

  Map<String, String> headers = {'authorization': "Bearer $token"};

  return await http.get("http://localhost:3000/$path", headers: headers);
}

Node js を用いたTwitter Login

本文

Twitterログインを作成したかった。

passport-twitter というのが有名だったが、session が必要だった。

session 使わずに作りたかったけど、断念したので経緯をメモ。

やりたかったこと

session をサーバーに保存するのは仕様上できない。

だとすると、redis に入れるとかあるけど、それもめんどい。cookieに入れる方法もあるけど、それはそれで...

というわけで、sessionに情報を保存せずに、twitter ログインを実装したかった。

結論

Twitter ログインは、セッション（相当のもの）の利用が必須ではなかったけど、諦めて利用する方法にした。

OAuth1の仕様としては、request_token 取得時に返ってくる token_secret を sessionかどこかに保存する必要がある。

passport-twitter では、passport-oauth1 を内部で利用してる。

で、この内部で node-oauth ってライブラリでは、request_token_secret を access token 取得時に必要としており、passport-oauth1 では、これを session に入れるようにしている。

ただ、twitter-lite というライブラリを使って、自分で試したところ、この request_token_secret を access token 取得時に利用しなくても、リクエストが返ってきた。

こちらの記事によると、twitter では必要ないらしい。

Twitter Login にも CSRF 脆弱性ができやすい罠が!? - OAuth.jp

ということで、twitter ログインをするためには、セッションへの保存が必要ないが、passport-twitter を利用するなど正しい方法でOAuth1を利用する場合は必要ということが分かった。

で、そんな網の目を通すような実装をすると、後の人に怒られそうなので、今回は passport-twitter を使い、session に request_token を保存する方法で実装することにした。

ちなみに、Facebookや、Google は OAuth2 に対応してるので、そもそもこの話は当てはまらない。

Twitter の APIは OAuth2 に対応してるものとしてないものがあるから、こういう話になっている。

authentication - Why passport-twitter requires session support - Stack Overflow

といった経緯のため、まず cookie-session を利用して実装し、その後 redis利用に変更したいと考えている。

Twitter での ログインについて

Twitter の APIを叩くための認証は app auth と user auth の２種類ある。

app auth は client key と client secret だけでAPIを叩ける（これはtwitter developer tool から取得できる。）

一方、user auth は、client key, client secret に加えて、access token, access token secret が必要。

この access token を取得するには

Log in with Twitter — Twitter Developers

  1. POST oauth/request_token を叩き（この時にcallback url を設定する）、oauth_tokenを取得する。

  2. oauth_token を get query につけて、GET oauth/authenticate を開く。

  3. そうすると、twitter が callback url に oauth_token と oauth_verfier を query としてつけて遷移してくる。

  4. この oauth_token と oauth_verfier を使って、POST oauth/access_token を叩く。

  5. そうすると、oauth_token, oauth_token_secret, user_id, screen_name が返ってくるので、このoauth_tokenたちとclient key たちを利用して好きなAPIを叩く。

  6. passport-twitter では、GET account/verify_credentials を叩いて、ユーザーの情報を取得してる。

OAuth1 の仕組みを利用している。

ただ、oauth/access_tokenを叩く時に、reqest_token_secret を利用する必要がないため、そこは仕様と違うっぽい？

OAuth2 の仕組み

OAuth 2.0 の仕組みと認証方法 | murashun.jp

実際の実装

const express = require('express');
const app = express();
const cookieParser = require('cookie-parser');
const cookieSession = require('cookie-session');
const passport = require('passport');

.....

async function start() {
  app.use(cookieParser());

  // authnicate周り
  app.use(
    cookieSession({
      name: 'passport-session',
      keys: ['qwwn3io2'],
      maxAge: 60 * 5 * 1000 // 5分
    })
  );
  app.use(passport.initialize());
  app.use(passport.session());
  const authnicate = require('./router/authnicate');
  app.use('/authnicate', authnicate);
  ......
}

start();
const { Router } = require('express');
const router = Router();

const passport = require('passport');
const TwitterStrategy = require('passport-twitter').Strategy;

passport.serializeUser(function(user, done) {
  done(null, user);
});

passport.deserializeUser(function(user, done) {
  done(null, user);
});

passport.use(
  new TwitterStrategy(
    {
      consumerKey: envSet.TWITTER_CONSUMER_KEY,
      consumerSecret: envSet.TWITTER_CONSUMER_SECRET,
      callbackURL: envSet.TWITTER_CALLBACK,
    },
    async (_token, _tokenSecret, profile, done) => {
      const params = {
        type: 'twitter',
        id: profile._json.id_str,
        name: profile._json.screen_name,
        image: profile._json.profile_image_url
      };
      // こうすると、session に params の情報が保存される。
      done(null, params);
    }
  )
);

// TwitterLogin
router.get('/tw', passport.authenticate('twitter'));

// TwitterLogin Callback
router.get(
  '/tw/callback',
  passport.authenticate('twitter', {
    successRedirect: '/account/social'
  })
);

// passport-session を利用すると、勝手にreq.user でsessionに登録したuserにアクセスできる。
router.get('/social_user', (req, res) => {
  if (req.user) {
    res.json(req.user);
  }
  res.status(404);
});

module.exports = router;

最後

もし間違ってたら教えて欲しいです！

技術選定等反省点メモ

概要

入社して２年経過したので、技術選定などでの現時点での経緯や感想をメモする。

技術選定

フロントエンド

Nuxtを選んだ。Reactと比較したが、SSRしたくて、その時Nuxtの事例が結構あったからVue & Nuxtにした。

現在では社内向けを除くWEBのフロントエンドはほぼNuxtに移行してる。（1個だけまだだけど、Nuxtを選びそう）

NuxtでSPAもSSRも統一することで、複数のアプリケーションを新規学習コストを押さえて、修正できるようになった。

また、RailsのSlimとかと比べて、hot reloadingは便利だし、どんな動きでもJSでばっちり解決できるし、CSSやJSのスコープがその中で閉じてくれるしで、とても楽。

なので、今考えても、ある程度正しい技術選定ができたとは思う。

ただ、もし今の知識を持ったまま戻るのであれば、今後TypeScript化は避けられそうにないので、あの時からTSが利用しやすかったReact & Next を選ぶ可能性確かそう。（Nuxtを選定時にTSで書いてみたけど、当時はサポートが弱くて、辛すぎてやめた）

テストに関しては、先輩が作ってくれた puppepper でのE2Eテストのみしかやってないけど、今の所は結構十分な感じがする。

storybook とか atomic design とか試したけど、基本一人で開発するし、コンポーネント作っても微妙に使うところでデザイン違う時多いし、アプリケーション毎で流用しようとしても、結構デザインや機能違うので、特にメリットを感じなかった。

まとめると、反省点としては、Next & TypeScript を選んだ方が結局開発工数を削減できたのではないかぐらいかな。（それはそれで苦労はありそうだけど...）

サーバーサイド

WEBサイトにおいては、SSRのNuxtから、Railsで作ったAPIを呼ぶようにしている。そして、そのRailsから、一部機能はsinatraで作ったマイクロサービスっぽいものを呼び出している。

ここに関しては開発はめっちゃしてるけど（先輩とかは基盤設計とか事業企画とかあるから自分が一番開発してると思う）、自分が技術選定の中心ではない。

ただ、今思えば、WEBから呼ばれるAPI（自分担当部分）と、ネイティブアプリから呼ばれるAPIをまとめて開発すべきだっと思う。

自分が入社前までは、一つのPHPでViewも含めたWEBサイトと、APIを運用していたので、WEBとAPIで必要なデータが大きく違うという問題があったらしいので、分けて開発することはCTOからの依頼ではあった。

ただ、事業の成長予測的に既存事業よりも新規事業に人が割り当てられるようになった結果、ネイティブアプリ側のAPIを保守する人がいなくなり、CTOが片手間でやってる感じになっている。このAPIが昔からのコードかつ、様々なアプリケーションが同じソースで動いているので、修正時の影響範囲が分からず、修正が辛い。

技術的に正しいかっていうのも大事だけど、今回の場合はNuxt化したことで、WEBとAPIのフロントである程度共通化は可能だったので、将来の売上予測的なものはあの頃から考慮できてたから、将来的にどこにどれだけの人員が当たるかを踏まえて、設計を考えるべきだったなと思う。あんまり二つの方法に差がないなら、チーム構成を予想して設計するべきだと学んだ。

Railsや sinatra での開発については、別にLaravelやGoとかでもよかったとは思うけど、大きく問題となってはない。（Goは試してみたけど、まだ速度とか型とかがチーム的に求められてなかったから、実運用ちょっとだけして、すぐRubyに戻した。）

むしろ、Rails というかActiveRecordで、ほとんどのアプリケーションが動いているので、開発効率は良いと感じる。JSかRubyのどちらかしか基本使ってないので、業務委託の方が参画してすぐ開発始めやすいというメリットを日々感じている。

WEBとかのテストに関しては、Rails側はNuxtとまとめてE2Eテストをしていて（単体テスト書いてるところもあるけど結局DBやAPIとの連携部分ばかりだからあんまりない）、Sinatraで作ってるマイクロサービスっぽいものは、単体も結合もちゃんとかいてる。今のところは、これぐらいがちょうどいいかなって感じがしてる。

やっと自分とかがネイティブアプリ側のAPIに力を入れられる環境になってきたので、他のアプリケーションと同じくらいの保守はしていきたい。

他には、API間での通信部分がGraphQLとか grpcとか使えてなくて、規格がない。jBuilderとかgemでとりあえずは困ってはないけど、人が増えてきたら考えないといけないなー...（ネイティブアプリとアプリAPI間は独自の規格で運用してるのでそっちは安心）

ネイティブアプリ

最近ようやく触り始めた！

今までWebViewでいいじゃんと思ってたけど、ARKitとか調べてたら触ってみたいなーと。

来年には仕事で使えるレベルまでかけるようになれればいいなー。

クラウド

自分がみてるものは、ECSを主に使ってる。

B向けのユーザー数がそんな多くないサービスとしては、fargate spot でお金的にも安くなったし、とてもやりやすい。

が、C向けのWEBサイトに関しては、予期せぬ大量のアクセスがきた場合に対応が難しいので、Lambda化を提案されている。

この時に、Nextだと海外にLambdaの知見が多いし、RailsじゃなくてGoだったらよかったのかなと思うことがある。

ここは反省というより、いかにLambdaの知見を今後蓄えて、数年後はどういうサーバー構成が主流になるかを楽しみに待っていたい。

ベンダーに関しては、GCPよりAWSの方がBigQuery以外は人気ある気がするので、AWSで正解だったなとは思ってる。（Azureは使ったことない）

k8sは触っただけで、全然使ってないので、試してはみたい。けど、Lambda or ECS で不満がない（困ったらAppMeshとかX-rayとか使えば良いかなと思ってる）ので、後回しになってる...

データ基盤

ここに関しては、自分はほぼ関与できてなかった。（最近はちょっと関与したけど）

現在はBigQueryに揃えようとしてるけど、とあるデータはRedshift、あるデータはBigQuery、あるデータはS3とかで、結構散ってる。

先輩方が最適なものを都度選んでるので、自分が関与しても結果は変わってはないと思うけど、今の流れ的には、早めにBigQueryを中心に使う方法でデータ基盤を構築するのが正しかったのかなと思う。

今後他の会社に入ってもここは大事になってくるところだと思うので、しっかり意識していきたい。

コミュニケーション

他チームとの接点

コミュ力鍛えるとかあんまり好きじゃないけど、やっぱり関係性を持っていた方が仕事は進むし、相談がくるし、結果は出しやすいよなと感じている。

2年たって、仕事で関わる人も増えて、いろんな人と仕事しやすくなった。最初のうちはチーム内の人と仲良くなれればいいやって感じでやってたけど、もっと意識して他チームの人ともコミュニケーションとるべきだったんだなって思う。

前職は、むしろ他チームの人から話しかけてくれてたから流れるままでよかったけど、それに慣れちゃダメだと思った。

マネジメント

最近、二人の業務委託の方の進捗管理的なことをしてる。

今でもマネジメントというのは偉そうで好きじゃないけど、二人とも良い方（というか出会った業務委託の人みんな良い方）だし、一人で仕事してるより圧倒的に早く他チームとか自チームの仕事をこなすことができてるし、食わず嫌いしなければよかったと思ってる。

というかマネジメントって、指示するというよりは結果を出すサポートをするみたいなのが、今の主流というのを早めに知るべきだった。

今の所、お互いの情報を積極的に共有することと、困ってることをすぐ相談しあえるようにしっかりお願いすることで、自分に負担が全くなく、ある程度うまく回ってる気がする。朝会をdiscordですることで、他のチームメンバーが聞いてくれてるから、自動で他メンバーへの進捗共有ができてめっちゃ楽。

けど、もっと人が増えてきて、目標設定とか、評価が仕事に入ってくるのは辛いなと思う。そう思うと今まで嫌いだったけど、画一的な評価制度って、評価する人のメンタル的に楽そう。

リモートワーク

これに関しては反省点0で、スムーズにコロナによるリモートに移行できた。

会社の人とは、関係性がある程度できている状態だったから、もはやリモートの方が効率がいい。

今まで情報共有するための会議が無駄だと思ってて、廃止してもらってきたけど、今は移動もせずにラジオ的に聞けるから何のストレスもない。

むしろ仕事しながら、今まで出られなかった他チームのMTGを聞けるから、今までみたいに議事録を漁るとかしなくて良くてすごく楽。

懸念点としては、新しく入社されたかたと関係性0だから、お互い相談するのに心理的な障壁あるよねって思う。慣れてくるのかな？

終わり

この2年で考え方いろいろ変わったけど、来年とか再来年はどう考えてるんだろうか

SwiftUI使ってみた

目的

WEBばっかりやってきたので、ネイティブアプリにも手を出そうと思い、今の会社のクローンアプリを作ってみた。

github.com

こんな感じの画面とか、ページ遷移が一通りできた。

f:id:okadak1990:20200621021858p:plain f:id:okadak1990:20200621023514p:plain

思ったことメモ

  • なんかReactみたいな感じ
  • Swift UI に沿って作るだけなら、tutorialとかqiitaとかstackoverflowとかみながらやればいいから、そんな難しくない
  • tutorialとかでパッと見つからないことも、WEBでやりたいこと考えて、その単語で検索すると大体出てくる。
  • optional型というやつにちょっとつまづいた
  • 勝手に定義したクラスや構造体を呼び出してくれてるっぽい（だから同名のファイルは作れなさそう）
  • EnvironmentObjectとか、Storeとか、Bindingとか使ったけど、その辺がまだよくわかってない。
  • VScodeに慣れた身としては、XCodeがめっちゃ使いにくい...
  • 型がない言語をずっと触ってるので、build時間が気になる...暇。テスト書けばいいはずなので勉強する。

大きい感想としては、iOS開発今までやったことなかったけど、SwiftUIを使うと書きやすいし、読みやすいし、簡単だった。 ネイティブアプリエンジニアの道も開けてきた気がする...

全然関係ないが、このブログに関して、放置してたけど、先輩が読者になってくれていたので、もう少し書く頻度を増やそうと決意した。

Nuxt + Firestore やってみた

目的

新年度となるので、保育園の新担任の予想を投稿して、共有するアプリを作った。

いつもReact x Firebase はやるけど、Nuxt でやったことなかったのでやってみた。

GitHub - okadakk/class-devide

Firebase関連のところだけ

~/plugin/firebase.js

import firebase from 'firebase/app'
import 'firebase/firestore';
import 'firebase/analytics'

if (!firebase.apps.length) {
  firebase.initializeApp({
     // 設定を記載
  })
}

// 無駄にanalyticsもONにしてみた。
firebase.analytics();

export default firebase

~/store/index.js

import Vue from 'vue';
import firebase from "~/plugins/firebase.js";
const db = firebase.firestore();

export const actions = {
  initItems (context) {
    db.collection("items").orderBy("like", "desc").get()
      .then(querySnapshot => {
        querySnapshot.forEach((doc) => {
          context.commit('addItem', {
            id: doc.id,
            item: doc.data()
          });
        });
      })
      .catch((error) => {
          console.log("Error getting documents: ", error);
      });
  },
  fetchItem (context, id) {
    db.collection("items").doc(id).get()
      .then(doc => {
        const data = doc.data();
        context.commit('setTitle', data.title);
        context.commit('setSelectedUsers', data.users);
      })
      .catch((error) => {
          console.log("Error getting documents: ", error);
      });
  },
  deleteItem (context, id) {
    context.commit('removeItem', id);

    db.collection("items").doc(id).delete().then(function() {
      console.log("Document successfully deleted!");
    }).catch(function(error) {
        console.error("Error removing document: ", error);
    });
  },
  async addLike(context, param) {
    await db.collection('items').doc(param.id).update({
      like: param.count + 1
    });
  }
}

やっぱりFirebaseは楽！楽しくなって、無駄にいいね機能とかもつけた！

しかし、３日後担任が発表されたので開発から3日でお蔵入り...悲しい。

採用スライド調査

目的

採用担当の人と二人で採用スライドを作ろうということになったので、他社さんのスライドの調査をして、その感想を書き起こしておく。

一旦3社について見てみる。

項目調査

ミラティブさん

ミラティブCTOからの採用候補者様への手紙 / mirrativ-letter-from-CTO - Speaker Deck

  1. CTO紹介 & メッセージ
  2. ミッション & プロダクト紹介
  3. 目指す開発組織、文化
  4. チーム構成、メンバー紹介
  5. 技術スタック、開発環境、開発フロー
  6. 募集ポジション

自分はあんまりライブ配信をみることに興味ないけど、ずっとゲームしてるから、楽しそうだなーと思う。

チームメンバーもしっかり顔出し（してない人もいるけど）してて、いけいけのベンチャーって感じられる。

こういう資料って投資家受けとかもいいのかな。

プロダクト紹介とかチーム紹介とかのコンテンツが厚くて、技術スタックとかって薄めに感じる。

特徴が出せる部分って、プロダクトと一緒に働く人、組織文化ってところで、そこを強調するのが良いのだろうなと思う。

逆に言えば、技術で何を使ってるでは、東大発AIベンチャーみたいなところじゃないと差別化できないのが現状だと思った。

ただ、ミラティブさんのその社風とプロダクトがあるからこそ、こういうワクワクするような資料が成り立つような気もする。

とても好きなスライドだけど、同じ感じにするのはもちろん無理だなと感じた。

リンクアンドモチベーションさん

リンクアンドモチベーション ソフトウェアエンジニア向け紹介資料 / Introduction to Link and Motivation for Software Engineers - Speaker Deck

  1. 会社紹介
  2. プロダクト紹介
  3. 開発チーム紹介
  4. 技術スタック、開発環境

とても読みやすくまとまっている。18枚で他の2社より少なくて、最後までさらっと読める。

プロダクトを4つ持っていて、それぞれ技術スタックが異なる

= 新しい技術に積極的なんだろうなとわかる

ただ、あんまり他の会社と比べて、このスライドで認知を取ってやろう的な感じがしなかった。

あくまで、採用候補者に対して、自社の情報を正しく伝えるための資料みたいな感じ。

採用スライド作る際は、こちらの会社のように、自社に興味がある人に対して情報を伝えたいのか

あるいは、ミラティブさんみたいに、このスライドを使って自社への興味をしっかり訴求したいのか

ってことを考える必要があるなと思った。

Delyさん

dely会社紹介資料 / クラシルに関わるエンジニア募集 / dely - Speaker Deck

  1. 募集職種
  2. 会社紹介、サービス紹介
  3. 会社の取り組み紹介
  4. 開発チーム紹介、カルチャー紹介
  5. 取り組み事例
  6. 評価制度

スライドにあったように、全スライドを通して情報の透明性を大事にしてるんだなということを感じた。

確かに大事にしてる会社の文化は、採用スライドからも感じ取れるのが普通でないとおかしいんだろうなと感じた。

誰かの課題を解決しているよっていうのを載せるのは、すごい大事だと思った。

エンジニアって価値提供してる相手が見えにくいってとこがあるから、弊社もそうだけど、良いレビューとかもらえると嬉しい。

個人的にはどこでマネタイズしてるんだろうってことが気になったけど、ヤフーの子会社ということだからユーザー伸ばすことだけ気にしてれば良いのかな？

とりまとめ

好きな資料は、ミラティブさんやdelyさんの資料だけど、まず作るべきなのはリンクアンドモチベーションさんのような資料だと思った。

書きたいことはたくさんあるけど、まずは作るってことと、最後まで読んで、弊社を知ってもらうことを優先したいなと思った。

そして、応募時点である程度、認識に相違がない人がきてくれるようにしたい。

何の技術を使ってるかを強調するというより、どんなプロダクトを使ってて、どういう風に社会に価値提供しているかを主に書きたいと思う。ユーザーの声も入れたい。

一方で、個人的に一緒に働く人がだれだれだから、その会社に行くって感覚が分からないし、そういう引き合いになる人を作れてないし、自分も全く認知ない。だから、人の部分は、そこは人数構成だけ書いて、会って判断して欲しいって感じにしたいなと思った。

また、採用資料からは会社文化みたいなのを感じるなと思ったから、弊社の文化を明言してそれを意識しながら作れたらと思った。

あと、応募障壁として、インテリアを好きじゃないといけないのではないかと思われちゃいがちというのがあるけど、そこをどうするかもありそう。

他社と比べて明らかに劣ってるところがあるけど、書くべきなのか。その辺も自分で変えてくれればいいところで、別に禁止されてるわけでないし、書かなくて良いのかも。