被評価者が苦手

https://twitter.com/hokkai7go/status/1347466542603096066

 

以前から人事評価というプロセスが苦手で、アピール下手だし、評価面談では手が冷えたり変な汗をかくということが何年も続いていました。社会人経験が長くなるにつれて少しずつうまくなった部分もあるでしょうし、最近は過度な期待をしないように自分の中で調整したことや、日々目標を追えるようになってきたこともあり、だいぶ安心して評価面談にのぞめるようになりました。しかし、冒頭のツイートのように再発してしまっていたようでした。

リモートでの評価面談というものに慣れていないからなのかもしれないし、単に今日は寒かったからなのかもしれません。なんとか苦手意識を克服したいけど、なかなか手強いなと感じた一日でした。うまくやれる人の方法や考え方を学びたいですね。

 

 

子供の頃に持った苦手意識からの開放

最近、仕事終わりなど時間を見つけてプラモデルを作っている。JALB787-8のプラモデルだ。 小、中、高の学生時代のいつかは忘れたけど、ダッソーミラージュ2000のプラモデルを作ったことを覚えている。当時は慎重さもないし、手際も悪かったし、経験もなかったので組み立てにも塗装にもめちゃくちゃ苦労して、微妙なものが出来た覚えがあった。兄は手先が器用だったので、兄と比較してうまくできなかったことがすごく印象に残っていたので、プラモデルへの苦手意識があった。 家での過ごし方を考えているときに、プラモデル久しぶりに作るのいいかもと思ってやってみたのだった。慎重さとか、事前に入門記事調べたりなどをして、今回はそこそこのものが作れた。子供の頃の苦手意識に向き合い直してみると意外とおもしろい発見があるんだなと気がついた出来事だったので書いてみた。

2年経つ

https://blog.hokkai7go.jp/entry/2018/09/05/074008

転職してから2年が経っていました。1つの会社に2年いたことは人生初です。よく頑張っていますね自分。

長期プロジェクトとその振り返りが終わり、感情を供養することができてよかったなと感じています。Mackerelの前身である社内プロダクトの役目を終わらせるプロジェクトに関わってきました。

いろんなことがあったけど、この2年でプロジェクトをすすめる上でのタスク分解や見積もりや、実行についてうまくなったということを振り返りで確認できたのがよかったです。チームとして強くなっていることが確認できたということです。

2年という節目で成長を感じられてよかったねということで書き残しておくことにしました。

Jenkins依存からの卒業

この記事はつぶやきというか、あのときこんなことやっていたなと自分が後から思い出すための記事です。

Jenkinsとはかれこれ10年近くの付き合いになると思うのだけれど、仕事でChef関連のCI/CD(Test, Lint等)をやっていたJenkinsプロジェクトの中身をCodeBuildに移設することができた。 これで自分の部署で使っているJenkinsでは重要なものは動いていない状態になったはず。最近はこのような移設プロジェクトの見積もり、実施などを主にやっています。もうちょっと挑戦成分をまぶしていきたいところ

一つ前の記事がGitHub Actionsの記事なので、そこだけみるとモダンなものに囲まれているように見えるかもしれないが、こうした地道でかつ古びにくい仕組みへの移設をやっています。

GitHub organizationsのメンバー管理をするTerraformを整備して、そのCIをGitHub Actionsで実現した話

はじめに

GitHub Enterprise(以下GHE)から github.com へと移行するのが社内のトレンドになりつつあります。renovateの利用も活発です。自分は組織横断的なSREチームにいますが、インフラだけでなくGHEや github.com のorganizationsの管理もやっています。

なぜGitHub organizationsの管理をTerraformでやろうとしたのか

本質的な作業ではないと思うものの、入退社のたびに操作を行う人が発生します。属人化したいものではないのと、他チームメンバーでも操作しやすくするためにコード管理したいとおもいました。自分の所属している組織横断的なSREチームでは、ほかチームのメンバーの増減について詳しく知らないので、各チームからチームメンバーの追加/削除のPRがほしいと考えました。つまりセルフサービス化したいと思ったということです。terraformのGitHub providerがあったので、これでやってみることにしました。

なぜGitHub organizationsの管理リポジトリにCIが必要と思ったのか

GitHub organizationsの管理をTerraformで実現したタイミングではCI整備ができていませんでした。CI整備が遅れたのは、自分がGitHub Actions初めて触ったので、tokenの扱いや、Organizationを変更可能な権限を付与する方法にたどり着くのに時間がかかったことによるものです。CI整備が遅れたことで、github id 変更や、手作業でのメンバー追加などで簡単にtfstateとの乖離が出ていくものの、CI整備できてなかったので気がつけないことが課題になりました。

なぜGitHub ActionsでCIしようとしたのか

ここは興味本位です。社内外の流行りに乗っておくかというノリ。Terraform Cloudじゃないのは費用面の試算等が面倒だったため。

得られたこと

セルフサービス化することができました。GitHub Actionsでは、terraform fmt, init, validate, plan をやっていて、terraform applyは手元からやっています。github.comのorganization管理に自分ばかりが詳しくなっていき、属人化していくことが心配でしたがコード化したことでこの心配から抜け出すことができました。実際に自分がいなくてもコードレビューと適用が済んでいた事例が増えてきています。エンジニアの入社処理や、他職種の追加フローからもガイドされており、スムーズに回るようになったように思います。

困ったことや実現できなかったこと

この記事を書こうと思い続けている間に、hashicorp/terraform-github-actions がメンテされなくなったという出来事がありました。hashicorp/setup-terraformを使うことで解決できることは以下のメドピアさんのブログによりわかっているのですが、なかなか直す時間が取れていません…。

tech.medpeer.co.jp

LambdaでSisimaiを動かしてバウンスメールを解析するテスト

バウンスメール対策として、Sisimaiの利用を考えていました。ここで結論です。LambdaでSisimaiによるバウンスメール解析の仕組みが作れそうでした。LambdaでSisimaiを動かすような記事は見つからなかったのでアウトプットしてみることにしました。 libsisimai.org

"SisimaiはbounceHammerの後継となるバウンスメール(エラーメール)解析ライブラリ" です。

クックパッド開発者ブログにある以下の記事を興味深く読みました。 techlife.cookpad.com

読んだ結果、わりと壮大な仕組みなので、現在であればもう少し小さく仕組みを実現できるのではないかと思って試してみた記事です。できるだけマネージドな仕組みの上で実現したいのですが、バウンスメール解析のSaaSでピンとくるものはなさそうだったのでこの記事の内容を試しています。(できればコードは書きたくないのでマネージドバウンスメール解析SaaSほしい)

Sisimaiは標準入力、変数経由などいくつかの動かし方ができるのと、依存関係が少ないのでLambdaで動くのではないか?と思って試しました。デプロイのことは考えるのが面倒だったので最小の工数でやってみています。

手順

  • AWSのマネジメントコンソールでsisimai-ruby-testってfunctionを作っておきます。
  • 手元で以下のlambda_function.rbのコードを書きます

変数f の中身はsisimai作者のazumaさんが開発・デバッグ用に提供してくれているメールの中身をブチ込んでみています。検証用なのでいかにも雑です。(ここをS3 Eventの中身にすると、SES+S3で受信している仕組みで使えそうです。 https://github.com/sisimai/set-of-emails/blob/master/maildir/bsd/lhost-sendmail-32.eml

require 'json'
require 'sisimai'

def lambda_handler(event:, context:)
    f = 'Return-Path: <MAILER-DAEMON@nyaan.example.co.jp>
Received: from localhost (localhost)
    by nyaan.example.co.jp (V8/cf) id t91ECGic009238;
    Thu, 1 Oct 2015 23:12:16 +0900
Date: Thu, 1 Oct 2015 23:12:16 +0900
From: Mail Delivery Subsystem <poostmaster@example.co.jp>
Message-Id: <201510011412.t91ECGic009238@nyaan.example.co.jp>
To: <shironeko@example.co.jp>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
    boundary="t91ECGic009238.1443708736/nyaan.example.co.jp"
Subject: Returned mail: see transcript for details
Auto-Submitted: auto-generated (failure)

This is a MIME-encapsulated message

--t91ECGic009238.1443708736/nyaan.example.co.jp

The original message was received at Thu, 1 Oct 2015 23:12:15 +0900
from c135.kyoto.example.ne.jp [192.0.2.78]

   ----- The following addresses had permanent fatal errors -----
<nyaaan@neko.example.jp>
    (reason: 550 5.1.1 Requested action not taken: mailbox unavailable)

   ----- Transcript of session follows -----
... while talking to inbound-smtp.us-west-2.amazonaws.com.:
>>> RCPT To:<nyaaan@neko.example.jp>
<<< 550 5.1.1 Requested action not taken: mailbox unavailable
550 5.1.1 <nyaaan@neko.example.jp>... User unknown
>>> DATA
<<< 503 Error: need RCPT command

--t91ECGic009238.1443708736/nyaan.example.co.jp
Content-Type: message/delivery-status

Reporting-MTA: dns; nyaan.example.co.jp
Received-From-MTA: DNS; c135.kyoto.example.ne.jp
Arrival-Date: Thu, 1 Oct 2015 23:12:15 +0900

Final-Recipient: RFC822; nyaaan@neko.example.jp
Action: failed
Status: 5.1.1
Remote-MTA: DNS; inbound-smtp.us-west-2.amazonaws.com
Diagnostic-Code: SMTP; 550 5.1.1 Requested action not taken: mailbox unavailable
Last-Attempt-Date: Thu, 1 Oct 2015 23:12:16 +0900

--t91ECGic009238.1443708736/nyaan.example.co.jp
Content-Type: message/rfc822

Return-Path: <shironeko@example.co.jp>
Received: from [192.0.2.43] (c135.kyoto.example.ne.jp [192.0.2.78])
    (authenticated bits=0)
    by nyaan.example.co.jp (V8/cf) with ESMTP id t91ECEic009234
    for <nyaaan@neko.example.jp>; Thu, 1 Oct 2015 23:12:15 +0900
X-SenderID: Sendmail Sender-ID Filter v1.0.0 nyaan.example.co.jp t91ECEic009234
Authentication-Results: nyaan.example.co.jp; sender-id=pass header.from=shironeko@example.co.jp; auth=pass (CRAM-MD5); spf=pass smtp.mfrom=shironeko@example.co.jp
From: "Shironeko, Nyaaan" <shironeko@example.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Nyaaaan
Message-Id: <4CB0AF09-E358-4D06-82B8-B8344B55CE02@example.co.jp>
Date: Thu, 1 Oct 2015 23:12:10 +0900
To: nyaaan@neko.example.jp
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)

nyaaan

--t91ECGic009238.1443708736/nyaan.example.co.jp--

'
    v = Sisimai.make(f)
    v.each do |e|
      puts e.action
      puts e.deliverystatus
      puts e.reason
      puts e.diagnosticcode
      puts e.softbounce
    end
end
  • Gemfileを書きます
# frozen_string_literal: true

source "https://rubygems.org"

gem 'sisimai', '~> 4.25', '>= 4.25.7'
  • bundle installをします sisimaiが依存するojがNative extentionなのでAmazon Linux2上でビルドする必要があるのでこういう工夫が必要です。

docker run -v (pwd):/var/task -it lambci/lambda:build-ruby2.5 bundle install --path vendor/bundle

(かつての同僚が書いた記事に救われました。いい記事ですね。このチームでの楽しかったな~ Ruby on Lambdaで実現する、Eightの大規模画像処理基盤 - Sansan Builders Box

  • Zipをアップロードする形でLambdaにデプロイします

aws lambda update-function-code --function-name sisimai-ruby-test --zip-file fileb://function.zip

  • 空のeventを渡してLambdaをテスト実行します。下のJSONがSisimaiが返してくれた結果です。
[
   {
     "catch": "",
     "token": "b314cc8582c5f78c3381dbaf4b5e86d706d1c505",
     "lhost": "c135.kyoto.example.ne.jp",
     "rhost": "inbound-smtp.us-west-2.amazonaws.com",
     "alias": "",
     "listid": "",
     "reason": "userunknown",
     "action": "failed",
     "origin": "<MEMORY>",
     "subject": "Nyaaaan",
     "messageid": "4CB0AF09-E358-4D06-82B8-B8344B55CE02@example.co.jp",
     "replycode": "550",
     "smtpagent": "Sendmail",
     "softbounce": 0,
     "smtpcommand": "DATA",
     "destination": "neko.example.jp",
     "senderdomain": "example.co.jp",
     "feedbacktype": "",
     "diagnosticcode": "550 5.1.1 Requested action not taken: mailbox unavailable 503 Error: need RCPT command",
     "diagnostictype": "SMTP",
     "deliverystatus": "5.1.1",
     "timezoneoffset": "+0900",
     "addresser": "shironeko@example.co.jp",
     "recipient": "nyaaan@neko.example.jp",
     "timestamp": 1443708736
   }
 ]

とてもお手軽でしたね。SES+S3でメール受信して、S3 EventをトリガーにしてSisimaiが動いてバウンスメール解析するという仕組みを動かせそうな気持ちになってきました。よかったですね。

認定スクラムマスターになれました

こんにちは id:hokkai7go です。これまでSREチームでのスクラムの話をしてきておりましたが、スクラムマスターとしては無免許でした。社内のすくすく開発会(スクラムに興味のある人達の集まり)や知人に相談してやってきていたものの、スクラムについて深く知りたいと思う気持ちがありました。

blog.hokkai7go.jp

blog.hokkai7go.jp

そんな中、つい先日認定スクラムマスター研修を受けることができ、(試験に合格したので)無事に認定をもらうことができました。

研修を受けてみての感想

もともとはオフラインでの開催予定でしたがオンライン研修になりました。 講師のJames CoplienさんにはRegional Scrum Gathering Tokyo 2020で一度お会いして直接話すことができていたので、ある程度人となりがわかっていてよかった気がします。どの講師の研修を受けるとよいのかについても、社内のすくすく開発会で事前に相談できたのがよかったと感じています。

blog.hokkai7go.jp

2枚めの写真に私がいます

とてもパワフルな研修でした。4日間にわたって半日溶けると仕事のスケジューリングの面でも、体力もじわじわ削られていきました。しかしこれまで見様見真似でやってきていたことが、以後は自信を持ってやっていけるというのはとても心強いことだなと感じています。また同僚とともに受講できたのもよかったことでした。同僚のおかげで議論や質問が活発になっていきました。

これからの実践が大事だと思うので、今後も社内外のスクラム関連コミュニティに参加して理解を深めていきたいと思います。