---
title: 9ヶ月の娘のヘルメット治療をはじめた
slug: decided-to-start-helmet-molding-therapy
date: 2022/04/18
tags: 子育て, ヘルメット治療
wip: false
---

[Kyashではじめての育休を取得した話](https://pranc1ngpegasus.com/blog/first-maternity-leave-at-Kyash)で書いたとおり、第一子である娘が生まれて10ヶ月が経過した。
寝返り、ずり這い、ハイハイ、つかまり立ち、つたい歩きと順調に成長しているが、親としては少し頭が絶壁なのが気になっていた。
これを解決すべく、かなり遅いスタートではあるがヘルメット治療をはじめたのでまとめる。

# ヘルメット治療とは

https://japanmedicalcompany.co.jp/aimet/column/column11.html

ヘルメット治療とは赤ちゃんの頭にヘルメットのような矯正器具をかぶせて、頭蓋骨の成長とともに形状を矯正していく治療のことをいう。
ちょうどハート型とか星型の野菜づくりと同じ原理で頭の形を整えていく。

治療期間は変形の具合やヘルメット治療の種類によってもまちまちではあるが、我が家から通える範囲で取り扱っているものは装着期間が最長6ヶ月で、かわいい盛りの娘にかぶせるのは少し抵抗があった。
また、これから6ヶ月となると暑い時期にさしかかるため皮膚トラブルになるのはかわいそうだという気持ちがあった。

# 治療すると決めるまで

はじめに頭の形が気になりはじめたのは妻で、娘が２ヶ月くらいの頃から頭の形には気をつけてくれていた。
ドーナツ枕などでなんとかしようと頑張ってくれて、娘も基本的に抱っこで過ごしていたからか結果的に頭のゆがみ(斜頭)などはなかった。
それでもバウンサーやベビーシートなどのせいか後頭部が平坦になっていた。
ドーナツ枕ではもう改善が見られないため、ヘルメット治療が適用される月齢がすでにギリギリであることも踏まえて相談を持ちかけてきてくれた。

はじめはヘルメット治療を扱っている脳外科にて、絶壁になっている理由が病気ではないことを確認してもらった。
幸いなことに近くの病院で診察を受けるこができたし、病気ではないことも確認がとれた。
ここで医師からヘルメット治療が必要だという処方箋をもらい、補装具製作所に行くことにした。

これまた幸いなことに補装具製作所が車で1時間ほどのところにあり、詳細な頭の形の計測とヘルメット治療についての説明を受けることができた。
計測の結果、絶壁レベル2と診断された。レベル2だと治療しない人もいるぐらいで、なおかつ月齢が低いうちにはじめた例に比べると月齢が大きいことから完全には治りにくいとのこと。
はじめるのであれば9ヶ月のうちにはじめた方がいいと言われた。
早めに決断しなくてはいけないことと変形レベルが0~5の中の2だったためやった方がいいのか妻と2人で話し合った。
また妻から、娘が将来的に「頭の形が気になる」と言いだしても整形手術でしか解決してあげられないこと、頭の形がコンプレックスで好きな髪型ができない場合があることも教えてもらった。
個人的には現地に行くまでヘルメット治療をするかどうかすら決めかねていたが、理想の綺麗な頭の形の模型を触ったところ娘の頭の形がやはり気になった。
実際のところ気になっていたのは値段だけだったのでやることにした。

https://twitter.com/kingjim/status/1335870039824584705

# まとめ

娘はあと4日で10ヶ月になるギリギリ9ヶ月でヘルメット治療をはじめた。
これから6ヶ月間、定期的な経過観察のために補装具製作所に通ったり皮膚トラブルにならないようにこまめなケアが必要だったり大変なことがたくさんあるだろうが、よい機会だと思ってヘルメット治療にチャレンジしてみようと思う。
装着から１週間ちょっと経ったがすでに効果が出てきていて後頭部に丸みが出てきた。
これには僕も妻も大喜びだ。

これからのさらなる変化が楽しみである。


9ヶ月の娘のヘルメット治療をはじめた

---
title: こだわりを持ってつくられた製品に魅かれる
slug: fascinated-by-products-made-with-care
date: 2022/04/04
tags: こだわり, 工業製品
wip: false
---

"神は細部に宿る" と言うけれど、こだわって作られた製品ってほんとうによいなぁと感じる。
最近とくに魅かれた製品を紹介する。

# [Ambientec TURN+](https://ambientec.co.jp/products/turn-plus-stainless)

![](https://cdn.shopify.com/s/files/1/0507/2112/8630/products/7-1-4.TURNplus_stainless_up_on_e1b55736-0b3f-4464-9d67-c9d18a8ca162_1682x1261.jpg)

Ambientecのデスクライト。
ステンレス削り出しのボディとガラス面にぼやーっと光るLEDが魅力的。
十字のケージが継ぎ目なしにつくられているのが美しい。

# [SIGMA I Series](https://www.sigma-global.com/jp/special/i-series/)

![](https://www.sigma-global.com/jp/special/i-series/images/introduction_image.jpg)

SIGMAのカメラレンズ。
福島県会津地方にある唯一の工場で、外装の質感はもちろん調整ダイヤルのクリック感までこだわってつくられている。
岩崎一郎氏による統一感のあるデザインでつい揃えたくなってしまう。

# [BBS RI-D](https://bbs-japan.co.jp/products/1439/)

![](https://pbs.twimg.com/media/EgrKJjIVgAUVA1B?format=jpg)

BBSのホイール。
自動車のホイールなんて運転していたら見えない部分なのだけど、ついしゃがんで覗き込んだり触れてみたくなってしまう。
年数が経っても飽きのこないデザインと信頼されつづける性能も魅力のひとつ。

# まとめ

美しいものたち、ついほしくなってしまうのだけど部屋に置くとなんか思い描いていたほど美しく魅せられないのは部屋が汚いからなのだろうか。


こだわりを持ってつくられた製品に魅かれる

---
title: grpc-gatewayを利用したREST APIの提供がすごく便利な件
slug: introduce-to-grpc-gateway-for-produce-REST-API
date: 2022/03/31
tags: Go, gRPC
wip: false
---

REST APIを提供するとき、APIのスキーマ定義をどのように管理するか悩むことがある。
OpenAPI(Swagger)で定義してモデルを吐き出すこともあれば、コードとは別にMarkdownで書き出すこともあるだろう。
マイクロサービス構成をとった場合にはサービス間の通信にgRPCを採用している場合もあり、REST APIはSwagger、gRPCはprotobufなどスキーマ定義の管理にかかる複雑さは増すばかりである。

このような状況を解決できそうな方法があり、すごく気に入ったので紹介する。

# [grpc-gateway](https://grpc-ecosystem.github.io/grpc-gateway/)

![](https://grpc-ecosystem.github.io/grpc-gateway/assets/images/architecture_introduction_diagram.svg)

grpc-gatewayはgRPCで提供されているAPIをJSON APIに変換して提供するためのコードを生成するツールである。
Protocol Buffers定義からコードを生成するためのプラグインの1つとして提供されており、[buf](https://buf.build/)などを利用してシュッと導入できる。
grpc-gatewayで生成されたコードはプロキシの役目を担うため、gRPC APIを提供するサーバの他にプロキシサーバを動かすことで提供が可能になる。

# 実際に試してみた

https://github.com/Pranc1ngPegasus/grpc-gateway-practice

Protocol Buffers定義を以下のようにした。
リクエストボディに入っている文字列をそのままレスポンスに返すような形式とし、REST APIのエンドポイントを`/v1/echo`とした。

<details>
    <summary>api.proto</summary>

```
syntax = "proto3";

package grpc_gateway_practice.v1;
option go_package = "github.com/Pranc1ngPegasus/grpc-gateway-practice/proto/grpc_gateway_practice/v1";

import "google/api/annotations.proto";

service GrpcGatewayPracticeService {
  rpc Echo(EchoRequest) returns (EchoResponse) {
    option (google.api.http) = {
      post : "/v1/echo"
      body : "*"
    };
  }
}

message EchoRequest { string value = 1; }

message EchoResponse { string value = 1; }
```
</details>

grpc-gatewayを利用してOpenAPI定義ファイルを出力した様子が以下である。
`/v1/echo`にPOSTでAPIが切られていることがわかる。

<details>
    <summary>api.swagger.json</summary>

```
{
  "swagger": "2.0",
  "info": {
    "title": "grpc_gateway_practice/v1/api.proto",
    "version": "version not set"
  },
  "tags": [
    {
      "name": "GrpcGatewayPracticeService"
    }
  ],
  "consumes": [
    "application/json"
  ],
  "produces": [
    "application/json"
  ],
  "paths": {
    "/v1/echo": {
      "post": {
        "operationId": "Echo",
        "responses": {
          "200": {
            "description": "A successful response.",
            "schema": {
              "$ref": "#/definitions/v1EchoResponse"
            }
          }
        },
        "parameters": [
          {
            "name": "body",
            "in": "body",
            "required": true,
            "schema": {
              "$ref": "#/definitions/v1EchoRequest"
            }
          }
        ],
        "tags": [
          "GrpcGatewayPracticeService"
        ]
      }
    }
  },
  "definitions": {
    "v1EchoRequest": {
      "type": "object",
      "properties": {
        "value": {
          "type": "string"
        }
      }
    },
    "v1EchoResponse": {
      "type": "object",
      "properties": {
        "value": {
          "type": "string"
        }
      }
    }
  }
}
```
</details>

# どう便利なのか
## APIスキーマ定義

REST API用の定義もgRPC用の定義も全てProtocol Buffersで定義できる。
Protocol Buffersの記述はコード量が少なく済むうえ、複数ファイルなどに分けて管理することで見通しがよくなる。

## コード生成

gRPC APIのスタブは[protoc-gen-go](https://pkg.go.dev/google.golang.org/protobuf@v1.28.0/cmd/protoc-gen-go)などを利用すれば吐き出すことができる。
REST APIのプロキシはgrpc-gatewayが吐き出してくれるうえ、プロシキするためのコードは全て生成されるのでHTTPサーバを起動するコードだけ自前で実装すれば動作してくれる。

## APIドキュメント管理

gRPC APIのドキュメントは[protoc-gen-doc](https://github.com/pseudomuto/protoc-gen-doc)などを利用すれば吐き出すことができる。
問題はREST APIのドキュメントであるが、grpc-gatewayに内包されている`protoc-gen-openapiv2`を利用すればOpenAPIの定義ファイルを吐き出すことができるので、そのままSwagger-UIやReDocなどを利用してホストすることが可能である。

以下に今回生成されたOpenAPIファイルをReDocで表示してみた。

https://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/Pranc1ngPegasus/grpc-gateway-practice/main/openapi/grpc_gateway_practice/v1/api.swagger.json

# まとめ

gRPCで通信するマイクロサービス群と、HTTPで通信するWebフロントやモバイルアプリなどを共存させるときにサーバサイドのAPI定義やコード管理にかかる労力を大きく減らせる技術だと感じた。


grpc-gatewayを利用したREST APIの提供がすごく便利な件

---
title: Next.jsとesa.ioでブログを実装した
slug: implement-my-blog-with-nextjs-and-esa
date: 2022/03/28
tags: プログラミング, Next.js
wip: false
---

いままでブログははてなブログを利用していたのだが、勉強がてら自前で実装することにチャレンジした。
そんなに難しいことはしていないのだがやったことをまとめる。

# 技術選定

今回使った技術と用途は以下のとおりである。
- [Next.js](https://nextjs.org/)
  - ブログ全体を実装するフレームワーク
- [Vercel](https://vercel.com/home)
  - ブログをホストするサービス
- [esa.io](https://esa.io/)
  - ブログ記事の執筆を行うサービス
- [Canvas](https://github.com/Automattic/node-canvas)
  - OGP画像の生成
- [next-mdx-remote](https://github.com/hashicorp/next-mdx-remote)
  - MarkdownからHTMLの変換

# しくみ
[![](https://mermaid.ink/img/pako:eNptj7FOAzEMhl8l8tzrA1wnBAiGliJATFnMxeWuXJwqcaCo6kIlHoGVJ6jExgOdUF-D3B1FHerBsn9_-R2voHCGIIdHj4tSjW9GmkN86DsKOKycZpXiJErpvMoy1Ww-ms22efv6-fzebd-T5NQE_ZNxL5xeExvNByb35Auqe5N_8YqWMpyHXm1jb9Au4DTMrFlmnqwT6hZc3k3Go-P4KfIzho6aXlz_Qd0vUoIBWPIWK5NuXLUzDVKSJQ15Kg3NMNaiQfM6oXFhUOjcVOI85OIjDQCjuNtXLvZ9z5xVmC6xkM-wDrT-BfJOcMA)](https://mermaid.live/edit#pako:eNptj7FOAzEMhl8l8tzrA1wnBAiGliJATFnMxeWuXJwqcaCo6kIlHoGVJ6jExgOdUF-D3B1FHerBsn9_-R2voHCGIIdHj4tSjW9GmkN86DsKOKycZpXiJErpvMoy1Ww-ms22efv6-fzebd-T5NQE_ZNxL5xeExvNByb35Auqe5N_8YqWMpyHXm1jb9Au4DTMrFlmnqwT6hZc3k3Go-P4KfIzho6aXlz_Qd0vUoIBWPIWK5NuXLUzDVKSJQ15Kg3NMNaiQfM6oXFhUOjcVOI85OIjDQCjuNtXLvZ9z5xVmC6xkM-wDrT-BfJOcMA)

- 筆者はesa.ioでブログ記事を執筆する
- Vercel上でビルドされるNext.jsがAPI経由でesa.ioにMarkdown記事を取りにくる
- `next-mdx-remote`がMarkdownをシリアライズしHTMLに変換
- `Canvas`を使って記事タイトルなどからOGP画像を生成
- Vercelが生成されたHTMLやOGP画像をホストして公開

# 工夫したこと

## esaで記事をShip It!すると同時にデプロイ

esaには記事の更新に合わせてWebhookを送信する機能がある。これを利用してVercelのmasterブランチ再デプロイをキックして記事を公開できるようにした。

## 色の数を少なく

<img width="300" src="https://user-images.githubusercontent.com/23367170/167384743-80d6b5fe-0a73-4035-a4ca-b5e0f9ba86bf.png" /> <img width="300" src="https://user-images.githubusercontent.com/23367170/167399216-b8737dfd-8577-408c-a4e9-33dafc6135d3.png" />

シンプルな見た目にすることで記事の内容により集中できると考えた。モノクロ + 蛍光イエローな色遣いが特徴の[みんなの銀行](https://www.minna-no-ginko.com)などを参考にして、極力モノクロ + αな色遣いにした。

## デスクトップ表示で幅を狭めに

![Screen Shot 2022-03-28 at 23 21 06_macbookgrey_front](https://user-images.githubusercontent.com/23367170/167384748-f500633e-f4a4-4a54-a975-16aece1b0c22.png)

デスクトップ表示にしたときに幅いっぱいに記事が広がると圧迫感と感じるうえに目の動きが大きくなってしまい記事が読みづらいと考えた。記事や画像を画面中央に寄せて画面の最大幅を狭めにすることで記事の見通しをよくした。

# まとめ

普段はサーバサイドエンジニアをしているのでフロントエンドにはあまり馴染みがない。どちらかというと苦手意識のあるフロントエンドであったが、APIを通じた記事取得やMarkdownからHTMLの変換など普段は味わうことのできない領域をじっくり触ることができて楽しかった。これからも少しずつブラッシュアップしていきたい。


Next.jsとesa.ioでブログを実装した

---
title: ドストライクなPCケースを見つけた
slug: found-a-PC-case-that-is-just-right-for-me
date: 2022/03/14
tags: PC
wip: false
---

年の離れた弟がゲーミングPCを自作したいとのことで相談に乗っていたら自作したい欲を掻き立てられてしまい、調べていくうちに個人的ドストライクなPCケースを見つけたので紹介する。

# [Fractal Design Era ITX](https://www.fractal-design.com/products/cases/era/era-itx/titanium-gray-walnut/)

![](https://www.fractal-design.com/wp-content/uploads/2020/03/era_facebook.jpg)

このケースはmini-ITXサイズ用で、サイズは高さ31cm/幅16cm/奥行き32cmと非常にコンパクトに仕上がっている。
そのコンパクトさゆえ机の上に置いても圧迫感がなく、スピーカーなどと並べてもよさそうである。
マットな質感のアルミ製パネルと木製天板の組み合わせが特に魅力的で、そのスタイリッシュな外観に惹かれた。

実売17,000円ほどでドスパラなどで購入できる。
筆者はゲームをしないのでLinux開発機としてお迎えできるといいなぁと考えているところである。


ドストライクなPCケースを見つけた

---
title: 開発でよく使うツールたち
slug: tools-i-use-in-programming-development
date: 2022/01/21
tags: プログラミング,Vim
wip: false
---

プログラミング開発をするときによく使うツールを紹介する。

# ツールたち

- Terminal.app
    - 同じ役目のツールを複数インストールしたくないマンなので標準ターミナルを使っている
- [Homebrew](https://brew.sh/index_ja)
    - ツール群を一括管理するツール
- [tmux](https://github.com/tmux/tmux)
    - ターミナルのタブを使う派の人はそれでいいと思う
    - 左ペインでログ監視、右ペインでエディタとか使えて便利
- [fish](https://github.com/fish-shell/fish-shell)
    - シェル
    - コマンド補完してくれて便利
    - プラグインをたくさん入れても軽い (気がする)
- [Neovim](https://github.com/neovim/neovim)
    - いろんなプラグインを入れてカスタムしている
    - 好きなプラグインは後述
- [fzf](https://github.com/junegunn/fzf)
    - コマンドラインであいまい検索をするツール
    - vimプラグインとしても使えるので編集したいファイルを見つけるのに便利
- [pgcli](https://github.com/dbcli/pgcli) / [mycli](https://github.com/dbcli/mycli)
    - DBクライアント
    - クエリとかテーブル名を補完してくれるので便利
- [ghq](https://github.com/x-motemen/ghq)
    - ローカルリポジトリの管理ツール
    - fzfと組み合わせて編集するリポジトリの移動とかができて便利
- [asdf](https://github.com/asdf-vm/asdf)
    - いろんな言語のバージョン管理用ツール
- [tig](https://github.com/jonas/tig)
    - gitツリーをわかりやすく見れるツール
- [the_silver_searcher](https://github.com/ggreer/the_silver_searcher)
    - grepの速いやつ
    - fzfと組み合わせることでvim上でコード行をあいまい検索できる
- [httpie](https://github.com/httpie/httpie)
    - curlみたいなやつ
    - リクエストボディをファイルからパイプして読めるのでシェル履歴が汚れなくてよい
- [gh](https://github.com/cli/cli)
    - GitHub謹製CLI
    - PR作成とか諸々をこれでやっている
- [hub](https://github.com/github/hub)
    - GitHubの中の人がつくった非公式CLI
    - `hub sync`コマンドがremoteになくてlocalにあるブランチを勝手に掃除してくれて便利
    - `hub push`で`git push origin current_branch`をやってくれて便利
- [direnv](https://github.com/direnv/direnv)
    - `.env`とかから環境変数にexportしてくれるツール
    - `.env`を編集すると勝手に更新してくれて便利

# Vimプラグインたち

- [fzf.vim](https://github.com/junegunn/fzf.vim)
    - ファイル名であいまい検索
- [vim-github-link](https://github.com/knsh14/vim-github-link)
    - コード行からGitHubリンクをつくってくれるツール
    - Slackにリンク貼るのに便利
- [bufpreview.vim](https://github.com/kat0h/bufpreview.vim)
    - Markdownをローカルブラウザでリアルタイムにプレビューできるツール
- [vim-lsp](https://github.com/prabirshrestha/vim-lsp)
    - VimでLanguage Server Protocolを使えるようにするツール
- [vim-lsp-setting](https://github.com/mattn/vim-lsp-settings)
    - ローカルにLanguage Serverをインストールするヘルパー
    - ローカルに未インストールのLanguage Serverがあるとsuggestしてくれる
- [asyncomplete.vim](https://github.com/prabirshrestha/asyncomplete.vim)
    - 非同期でコードとかコマンド補完を実行してくれるツール
- [asyncomplete-lsp.vim](https://github.com/prabirshrestha/asyncomplete-lsp.vim)
    - ↑のプラグインでLSPからのsuggestをポップアップしてくれるツール
- [ale](https://github.com/dense-analysis/ale)
    - LSPと連携してコードの体裁を整えたりエラーを教えてくれたりするツール

# まとめ

たまには盆栽(vimrc)の手入れもしないとなぁ。


開発でよく使うツールたち

---
title: 2022年01月版キャッシュレス生活まとめ
slug: my-cashless-life-202201
date: 2022/01/07
tags: おかね,キャッシュレス
wip: false
---

ずいぶん前に書いた[私的キャッシュレス生活まとめ](https://pranc1ngpegasus.com/blog/my-cashless-life-202006)や、わりと最近書いた[お金の流れを図にまとめている話](https://pranc1ngpegasus.com/blog/family-money-flow-diagram)の続編。
 最近使っているサービスやカードなどをまとめる。

# どんな金融サービスを使っているの?

![https://raw.githubusercontent.com/Pranc1ngPegasus/moneyflow/2a1fec5c6865494d1fb9bbd111fb5573f9853b57/202201.drawio.svg](https://raw.githubusercontent.com/Pranc1ngPegasus/moneyflow/2a1fec5c6865494d1fb9bbd111fb5573f9853b57/202201.drawio.svg)

## 工夫している点

### 住信SBIネット銀行の振込無料回数の捻出

住信SBIネット銀行は通常、月2回の振込と月1回のATM利用が無料になっている。 住信SBIネット銀行では[スマートプログラム](https://www.netbk.co.jp/contents/lineup/smartprogram/)という優遇プログラムが組まれており、ランクを3にすると月10回の振込と月10回のATM利用が無料になる。 スマート認証NEOつまりスマホアプリの登録をしていれば自動的にランク2にランクアップし、月5回の振込と月5回のATM利用が無料になる。 これだけでも普段の生活ではなんら支障がないのだが、なにか振込が必要となった場合に余力がないことがある。 ランク3に上がるには銀行が指定する条件を2つクリアするとよいのだが、我が家では給与振込口座として指定しているほかに、外貨預金の南アフリカランドを1通貨分(約7円)買っている。

### SBI証券のつみたてNISA

SBI証券のつみたてNISAは銀行振込による現金積立のほかに、三井住友カードが発行するクレジットカードによる積立を指定することができる。 Amazon Mastercardは三井住友カードが発行しているのでクレカ積立に設定することが可能なのだが、毎月1日に買い付けを行う設定のみ可能となっている。 筆者は証券取引についてあまり知識がないのだが、クレカ積立が毎月1日しか指定できないということは毎月1日付近に株価が上昇してしまい、高値つかみをしてしまうのではないかと考えた。 この行いに意味があるのかないのか正直わからないが、現金積立で毎日買い付けを行うようにしている。


2022年01月版キャッシュレス生活まとめ

---
title: チームのふりかえりをGoogle DrawingsからTrelloに移行した
slug: change-team-retrospective-tool-from-google-drawings-to-trello
date: 2021/12/11
tags: Kyash,おしごと
wip: false
---

この記事は[Kyashアドベントカレンダー2021](https://adventar.org/calendars/6274)、11日目の記事です。
[Kyash](https://kyash.co)では1スプリントを1週間としたスクラム開発を行っており、スプリントのおわりにふりかえり会を開催しています。
今回はこれまでGoogle Drawingsを使って行っていたふりかえりをTrelloに移行して効率化した話をまとめます。

# これまでのふりかえり
![](https://user-images.githubusercontent.com/23367170/167379057-374a1536-0e9a-4c6a-9120-c21741a241b1.png)

これまでKyashのふりかえりではGoogle Drawingsを利用していました。
これはコロナ以前にオフィスでホワイトボードを使って行っていた手法をそのままオンラインに移植した方法で、ホワイトボードや模造紙などに付箋を貼っていくイメージで行っていました。
図にうっすらと見えているとおり4つの象限に分かれており、X軸にBad -> Good、Y軸にFeel -> Factのように分類して発表していく形式です。
発表は第一象限からFact Good -> Fact Bad -> Feel Bad -> Feel Goodの順に進んでいき、ファシリテータが発表者を指名し、指名されたメンバーは手札を出して話すというような流れで行っていました。

この手法には以下のような問題があり、ふりかえりに集中できる環境をつくることができていませんでした。
- ファシリテータが指名する時に「Fact Goodのカード」など手札を探す必要がある
- 発表時に手札を移動する時間がある
- 会話が途切れることによる流れの崩壊

これを改善したいと考えてTrelloというサービスを使うことにしました。

# これからのふりかえり
![](https://user-images.githubusercontent.com/23367170/167379066-c386c24a-e08f-40d2-9a61-ecc54c028398.png)

Trelloはいわゆる”カンバン”方式のチケット管理ができるサービスです。
今回はリストの名前をFact Good、Feel Badなどのカードを挙げるジャンル、カードのタイトルをメンバーが挙げるふりかえり内容としてふりかえりを行うようにしました。

この方法で大きく改善したのはファシリテーション負荷です。
これまではFact Goodに属するカードを画面全体から探して、指名してという流れだったものが、既にカードとして列挙されている状態になるので探す必要だけでなく指名する必要もなくなりました。
これによりふりかえり会の流れを崩すことなくサクサクと進められるようになりました。

Trelloにしたことでカードに書かれたふりかえり内容に対して議論したことをコメントに残すことができたり、APIを通じてカード情報を取得することでアーカイブ記事を作成することができるようになったりしました。Kyashでは実際に[TrelloをKibelaにアーカイブする君](https://github.com/Pranc1ngPegasus/trello-kibela-exporter)をつくってMarkdown記事としてアーカイブを行っています。

まだまだ改善できることがたくさんある取り組みなので、必要に合わせて形式を変えていきたいと考えています。

# まとめ
Google DrawingsだったふりかえりをTrelloに移行したことで以下の改善が見られました。
- ふりかえりの効率がよくなって所要時間が短くなった
- ふりかえりそのものに集中できるようになった

オフィス勤務やリモート勤務など、メンバーがおかれている状況に合わせて定期的にふりかえりのやり方をふりかえるのは大切なことだと感じました。これからもアップデートがあったら発信していきます。

We're hiring!

https://www.kyash.co/recruit

https://www.wantedly.com/projects/793421


チームのふりかえりをGoogle DrawingsからTrelloに移行した

---
title: レビュアーにやさしいPull Requestとはなにか
slug: what-is-easily-reviewable-pull-request
date: 2021/09/06
tags: GitHub
wip: false
---

チーム開発をしていると毎日のようにPR(Pull Request)をレビューしたりレビューしてもらったりする。
そのなかで目的や解決したいこと、その経緯がわからないものをたまに見かける。
レビューに時間がかかると後続のタスクに進めなかったり、積もり積もってリリースまでのリードタイムが長くなったりする。

これを改善するにはどうしたらいいのか。

答えはPRの質にあると感じるので筆者が日頃から気を付けていることをまとめる。

---

- PRのタイトルは短く簡潔に書く
  - たとえば「Userの名前を更新できるようにした」
  - パッとどんなことをしているPRなのかを伝えられるようにする
- PRのタイトルにないことは含めない
  - 「Userの名前を更新できるようにした」のPRで「Userの取得にtypoがあったので修正」はしない
  - ↑のような修正は別PRにする
- PRのdescriptionに詳しい経緯を書く
  - たとえば「苗字変更に対応するために名前を更新できるようにした」
  - バグ修正などは再現方法や修正前後の動作確認などがあるとよい
- 1PRで10コミットまで
  - 大量のコミットがあったらレビューする気が失せちゃう
  - 紆余曲折がんばった跡は`git rebase`などで消しておく
  - レビューする人の拘束時間が長くなる
- コミットメッセージにはWhyを書く
  - たとえば「Userに関するファイルをまとめるためにディレクトリ追加」
  - 「fix」とか「レビュー対応」は内容と経緯がわからない
- 依存している順にコミットを積む
  - 新設メソッドを叩くコード追加コミット -> メソッド追加コミットだと順番がおかしい
  - `git rebase`でまとめたり順番を整えたりする
- ぱっと見わからない工夫などをコメントする
  - 質問コメントに答える時間を省く
  - 経緯がわかればコードが読みやすい
- 指摘コメントに感謝の言葉と修正コミットのリンクを貼る
  - まずは感謝
  - 指定コメントに対する修正がパッと見れる

---

最後に筆者が教訓にしている記事を貼っておく。

https://tech-blog.yayoi-kk.co.jp/entry/2015/11/27/111136

https://tech-blog.yayoi-kk.co.jp/entry/2017/03/13/132014

いかがだろうか。

無意識にやっていて列挙できなかったものがあるかもしれないが、上記をようなことに気をつけてPRをつくるとレビュアーにやさしいPRをつくることができる。人間は忘れる生き物なので、あとから見てもわかりやすいものを心がけていきたい。


レビュアーにやさしいPull Requestとはなにか

---
title: どんなときに会社を辞めたくなるのか
slug: when-i-feel-like-quit-my-job
date: 2021/09/03
tags: おしごと
wip: false
---

いまは都内に本社を置くIT企業で働いている。
日々の業務をこなしているうちに心機一転新しい場所に身を置きたくなったり、ずっとこの会社にいたいなーと思ったりする。

同僚のブログを読んで、ある意味で辞めどきの判断基準というか企業に対して求めているものを現職に知っておいてもらうのは大事なんじゃないかと感じた。

https://konifar-zatsu.hatenadiary.jp/entry/2019/09/12/210130

まだ辞めませんと宣言しつつ、自分はどういうときに辞めたくなるか考えてみる。

# 筆者の性格

- 忘れっぽい
- 興味関心があることに没頭しやすい
- 熱しやすく冷めやすい
- アドバイスを率直に受けとめる
- 習得までに回数が必要
- 細かい調整や作業が疎かになることがある
- 単刀直入に伝えたいと思うあまりトゲのある言葉遣いになることがある

# どんなときに辞めたくなるのか

- 自分の成長を感じられなくなったとき
  - いままでやってきたことを再アウトプットしてるだけだなって感じたとき
  - ある期間で取り組んだ業務をふり返ったときに、なにも特別なことをしていないなと感じたとき
- 自分が雰囲気や士気の邪魔になっているのではないかと感じるとき
  - 自分の意思を伝えたいあまり相手を傷つけてしまったのではないかと感じるとき
  - 自分さえいなければスムーズに進んでいたのではないかと感じるとき
- xxさんさえいれば安泰だねって思われてるんじゃないかと感じるとき
  - ずっと専属でやっていたいわけじゃないしかかりつけ医じゃない
- 仕事に意味を感じなくなったとき
  - 指示された仕事をこなしてるだけになったとき
  - 自分の意思に反するような納得できない仕事をやる期間が続いたとき
  - べつに自分じゃなくてもいいよねと感じたとき
- ｼｭｯと決めてｼｭｯと解決したいと思っていることの意思決定に時間がかかるとき
  - Yes/Noだけ答えてくれたらあとはやるだけってときに仮説検証がー、とか運用コストがーとか言われるとき
  - 大企業のスタンプラリーみたいに承認プロセスが途方もなく冗長なとき
- 事業の未来を感じなくなったとき
  - 明らかに競合他者がデファクトスタンダートだよねと感じるとき
  - 自身が関わるプロダクトを自身が使わなくなってしまったとき

---

エンジニアとして在籍して企業が向かう先にコミットするにあたって、自分が持っているノウハウや技術をアウトプットするだけでなくインプットも大事にしたいタイプなんだと感じた。
じゃあ「事業ドメイン完全に理解した」ってなったら辞めたくなるのかというと、事業にどっぷり没頭していたいとか、事業の将来性とかに左右されそうだなと感じた。

5000兆円ほしい。


どんなときに会社を辞めたくなるのか

---
title: Kyashではじめての育休を取得した話
slug: first-maternity-leave-at-Kyash
date: 2021/08/31
tags: おしごと,Kyash
wip: false
---

はじめての子どもである娘が産まれてから慌ただしい日々を過ごしています。
産まれてからの2ヶ月間、育児にフルコミットするために会社で初の育児休業を取得したのでまとめます。

# 会社で初の育休を取得するまで

はじめての子どもを夫婦できちんと育てたいという気持ちが夫婦ともに強かったので、自然と育休取得の話が出てきました。

KyashにはSlackに#chat-childrenがあるくらい子育て世代のパパママがたくさん在籍しています。

![image](https://user-images.githubusercontent.com/23367170/167374743-9cb4ef20-041f-481e-8bb1-f8175c19a847.png)

普段からSlackでお迎えやお世話による早退や中抜けのコミュニケーションが多くされており、業務と両立して子育てをしているメンバーが多いです。
Kyashでは育休の制度は整備され始めてきていたものの、まだ育休を取得したメンバーがいなかったこともあり、実際に育休を取得する判断をするのは正直少し気がひけました。

当時直属のマネージャであった[こにふぁー](https://twitter.com/konifar)さんに相談したところ、背中を押してくれたこともあり2ヶ月の育休をいただくことにしました。

# 育休の前準備

育休に入ると、これまで仕事にあてていた時間を家事 / 育児にあてることになります。
育休に入ってからスムーズに生活を切り換えられるように、妻がひっそりと「旦那教育」をしてくれていました。

「ひとつのことに没頭しやすい」「家事全般はできる」といった自分の特性を理解した上で、産後のメンタルのインプットや役割の期待合わせなどができ、これは本当にやってよかったと思います。
長くなるので詳しくは別記事でまとめています。

https://pranc1ngpegasus.com/blog/what-kind-of-husbands-behavior-helps-his-wife

# あっという間の2ヶ月間

会社は育休の期間中、会社のメールアドレスや各種アカウントなどを停止状態にして、育児に集中できる環境を整えてくれました。
そのおかげもあって、育休中の2ヶ月間は**家事 / 育児以外のことなんもしない人**になりました。

https://twitter.com/pranc1ngpegasus/status/1404718630831411200

家事の中で特に気を遣ったのは食事です。
たんぱく質や鉄分、葉酸、カルシウム、各種ビタミンなどが足りなくなるようで、ほうれん草やひじき、季節野菜、焼き魚などを多めに取り入れたごはんをつくっていました。

https://twitter.com/pranc1ngpegasus/status/1406386581418627073

また我が家にはわんこがいます。
僕らの愛情を独り占めしていたわんこからすると、娘は僕らを取ってしまう急にきたよそ者です。
入院中から娘のガーゼの匂いを嗅がせて慣れさせたり、退院後は娘が泣いてもわんこを撫でてから抱っこしたり工夫をしていました。
いまは娘がぐずったら教えてくれるお兄ちゃん犬にレベルアップしました。

https://twitter.com/pranc1ngpegasus/status/1406222289574580226

夫婦がお互いに月に一回、半日ずつプライベートな時間を確保できるように工夫しながらあっという間に2ヶ月が終わっていきました。

ちなみに妻はNEWSの増田くんが好きで、よくライブDVDを見て気分転換をしていました。

https://twitter.com/pranc1ngpegasus/status/1416369047017443329

はじめての育児はなかなか一筋縄ではいかないもので、夫婦で役割分担を試行錯誤しました。

夜間の3回の授乳は基本的に妻が対応をしていました。
僕も最初の頃は初回を担当していましたが一度寝たら中々起きられず、妻に起こしてもらっていました。
でも翌日、眠気が強く家事に影響が出たので断念。

妻も寝不足でつらそうだったので育休中に2~3回ほど夜間のミルクを全て担当しましたが娘が泣いていてもいびきをかいて寝ていて、ぬいぐるみを投げつけられたことも。
そして翌日は案の定使い物にならず。

**夜間授乳をしている全国のお母さんたちに脱帽です。**

結局我が家では睡魔と闘う妻を横目に僕は寝て、翌午前中に妻が仮眠を取るという分担に落ち着きました。

# 育休は終われど育児に終わりなし

現在は仕事に復帰して、生活リズムも整ってきました。
育休中も寝かしつけ後の1~2時間はコードを書いてたので復帰も意外とすんなり出来ました。

育休が終わったからといって育児参加も終わりではなく、朝ごはんは僕の担当ですし午前中の妻の仮眠時間中は抱っこひもをしながら仕事をしています。
また沐浴、寝かしつけも妻と分担してやっています。

会社が育児に理解があるので、妻だけに任せることなく平日も過ごせています。

# 会社にがんばってほしかったところ

実は特に見つかりませんでした。

会社からはほしいだけとっていいよと言われていましたが、僕と妻は2ヶ月間を選択しました。
2ヶ月の育休は短いと思われるかもしれませんが我が家にとっては短くも長くもなく、妻の体調も回復して元の生活に戻るちょうどいい期間だったと思います。

会社としても僕としてもはじめての育休取得だったことから、育休前から何度もMTGの時間をもらって確認事項の突き合わせをしたし、書類のやりとりも多かったように思います。
これは慣れが必要なことだと思うのでしかたないと思います。

今後さらに運用がブラッシュアップされていくものと思いますが、その先陣を切る形で自分が育休の事例を作れたことはよかったんじゃないかと感じています。

# まとめ

まもなく生後3ヶ月になる娘は体重が出生体重の2倍近くになりつつあり、日々成長を感じます。

生後1ヶ月半を過ぎた頃が妻は一番つらかったらしく、一緒に育児をしてくれてすごく助かったと言ってくれて改めて育休を取得してよかったと感じました。

これからも家族3人と1匹で楽しく過ごしていこうと思います。


Kyashではじめての育休を取得した話

---
title: 妻が助かる旦那の立ち回りについて
slug: what-kind-of-husbands-behavior-helps-his-wife
date: 2021/08/28
tags: 子育て,育休
wip: false
---

6月に第一子となる娘が爆誕し、育児休業を取得した。
育児休業を取得した背景に昨今の家庭事情である核家族化があった。

どちらの両親にも頼れず、初めての育児に挑むのは丸腰の状態でボス戦に挑むようなもの。でもリトライできないのが育児。
ましてや相棒である旦那が育児に参加しないとなると丸腰+ステータス異常によりHPが半分以下の状態で戦闘開始するぐらい妻への負担大である。

そりゃあ **そんな相棒は必要ない!** って言いたくなる。けしからんですよ。
僕だってそんな状況ならパーティー再編集したくなってリセットボタンを押したくなる。

我が家では産後に起こりがちな家庭崩壊の危機を回避するべく妻がしれっと「旦那教育」をしてくれていた。
産後どのような行動をしてほしいか、どのような心構えでいてほしいか、など妻が考える「旦那にやってほしいこと」を旦那である僕に叩きこんだ「旦那教育」について一部をまとめる。

# 旦那教育のゴール

育休中に妻が育児と産後の体力回復にフルコミットできる環境作り

- 育休前に妻がやっていた家事全般
- 育児のサポート役にもまわる

# 旦那の特性

- ひとつのことに没頭しやすい
    - 家事が並行して消化できると自分の時間が取れるようになる
- 集中しだすと時間を忘れてしまう
    - タイムスケジューリングを意識づけさせる
- 習得までに回数が必要
    - n回教えても習得できない
    - たまにモノの場所があいまい
    - 言葉よりも動いて覚えさせる
- もともと家事全般ができる
    - 野菜の切り方ひとつから教える必要はない
- アドバイスを率直に受け入れる

# 意識して教えたこと

- 妻が監視しつつ効率化のアドバイス
    - 空き時間を見つけては家事全般をやらせる
    - 掃除の仕方も全て妻がやっていたことと同じように教える
    - 旦那が徐々に覚えてきたことに対して毎回フィードバック
        - 育休中に非効率にならないために短期間で教育
        - よかった点 / もうすこしな点 / 改善策など
- 買ってきたものの片付けを意識的に旦那にやらせてモノの位置を覚えさせる
- 冷蔵庫の中の在庫状況を意識させる
- 産後の身体の状態について教える
    - 育児本をいっしょに読む
        - 産褥期の回復の大切さ、無理した場合に起こることを知る
        - 「全治2ヶ月の交通事故にあった」状態を理解する
        - わからないことは妻に聞かずに自分で調べるよう習慣化させる
- 産後のメンタルの状態について教える
    - 産後はイライラしやすい
        - 普段とは比べものにならないくらい沸点が低い
        - 怒りたくて怒っているわけではないことを理解してもらう
        - 「わかった」「わかってる」言い方ひとつ間違えるだけでイライラしてしまう

# まとめ

旦那教育を受けてみて、僕がいつも仕事をしている間に妻はこんなに仕事をしていたんだとわかった。
だからMTGの合間の時間ちょうどに昼食を食べれるし、きれいな布団で寝れる。生ゴミは臭くないし、Tシャツも生乾き臭くない。
これで給料なし?と思うほどの仕事量だし、まわりにたくさん気をつかう。こんな求人広告があっても僕は絶対にやりたくない。
でもこれを全国のお母さんがやっていると思うと尊敬の意である。

出産後、妻が退院して実際に育休に入ってから旦那教育の成果を100%出せたかというとそうではない。7~8割というところだろう。
どうしても仕事があり妻に頼りがちになっていたところがあったのだと思う。座学だけでは実践がうまくいかないのと似ている。
とはいえ基本ができていたことで初日からまあまあうまく立ち回れたし、妻も「うまくできていたよ」と評価してくれている。

ご家庭によって奥さんがしてほしいことは異なるかもしれないが、余裕がある旦那さんは参考にしてみてはいかがだろうか。


妻が助かる旦那の立ち回りについて

---
title: 東京から地方に引っ越して1年くらい経った話
slug: one-year-spent-since-moved-to-countryside
tags: リモートワーク,田舎暮らし
date: 2021/05/16
wip: false
---

こんな状況になってからわりとすぐに、実は東京から地方に引っ越してました。
2020年7月に移住してから1年くらい経ったので暮らしの変化、よかったことなどを書き残していこうと思います。

# 筆者のこれまで

ド田舎生まれド田舎育ち、就職してから大阪、名古屋、東京と転職をしながら移住していました。2020年2月に結婚後、2020年7月から地方在住。

# これまでの暮らし

## 居住エリア

東京にてエンジニアとしてオフィスに通勤しながら働いていました。はじめは中央線沿線で一人暮らしをしていたのですが、転職や結婚を機に引っ越して東横線沿線で暮らしていました。東横線が毎日混んでいてつらかった思い出があります。

## 暮らし

嫁氏と僕は基本的にインドアでしたが、たまに気が向くとディズニー散歩(アトラクションに乗らず飲み歩き)をしにいったり、アフタヌーンティーを楽しんだりしていました。

# どうして地方移住したのか

2020年3月頃から会社がリモートワーク体制に入り、緊急事態宣言下の東京に住んでいる意味を感じなくなったこと、夫婦揃って田舎出身だったため子供は田舎で育てたいという気持ちが強かったことで地方移住を決めました。
会社がリモートワーク体制になったとはいえ、オフィス出社が基本の会社だったので移住に伴って転職を考えなきゃとか、イヤな顔をされそうとか心配をしていましたが、わりと快く移住を認めてくれました。ありがとう会社。

# 地方移住をするにあたって考えたこと

## クルマ

自転車だけで移動するには限界があるし、地方ではどこへ行くにも車が基本です。もともと車が好きだったので、嫁氏と相談しつつ最終的には自分の好きな車を妥協せず買いました。2020年冬には妻用の車も購入し、現在は2台所有しています。

## おうち

引っ越し先は嫁氏の地元で、土地勘があったのである程度エリアを絞ってもらい、犬をお迎えしたかったのでペット可物件を探しました。東京なら駅チカがいいとか、どの路線がいいとか考えますが、地方の場合は車があるので土地の治安がよいか、スーパーが近くにあるかなどを考えました。

# 地方移住して変わったこと

地方は家賃が安いから生活費にお金をかけられる!! と思われがちなのですが、車の維持費やランニングコストのことを考えると同程度なのかなと思います。

## 時間という束縛から開放された

一番変わったと感じることは時間に縛られなくなったことです。東京に住んでいるときは「何分発の電車に乗らなきゃ」とか「時までに行かないと間に合わない」みたいな感覚がなくなって心に余裕ができました。とはいえ「間に合わないから車を飛ばす」という感覚に変化したので実は変わっていないのかもしれません。

## 家族の時間が増えた

もうひとつ個人的な変化ではありますが、嫁氏が専業主婦になったことで家族の時間が増えました。僕は平日勤務、嫁氏は水日休みのシフト制だったので二人が一緒に過ごせる休日は日曜日しかありませんでした。ただでさえリモートワークで一日中おうちにいるので余計にそう思うのかもしれません。

# まとめ

地方移住したけど生活水準は全く下がらず、むしろ快適に暮らしています。
これからは子供のことを考えたり、家を建てたりすることを視野に入れつつ田舎暮らしを満喫したいと考えています。


東京から地方に引っ越して1年くらい経った話

---
title: Kyashに入社して2年くらい経った話
slug: two-years-spent-at-Kyash
tags: おしごと
date: 2021/04/15
wip: false
---

在職エントリです。
2019年4月に入社してからあっという間に2年くらい経ってしまいました。これまでやってきたこと、これからやっていきたいことなどを書き残しておこうと思います。

# やっていたこと

## Kyash Direct

Kyash DirectはKyashがウォレットアプリで培ってきたプリペイドカードの発行・Visaネットワークでの決済などの技術を決済プラットフォームとしてB to Bの世界にも提供するために生まれた新規プロダクトです。その立ち上げから事業譲渡が完了するまでのほぼ全ての期間で携わりました。実はKyashに入社するまで業務ではほとんどGo言語を触った経験がなかったので、開発スピードが要求される新規プロダクトのチームに配属されて間もない時期は「コードが全く書けない新入社員」をやっていました。初めてProduction環境にリリースをするまで半年間、一時は開発を離れてQA担当やKyash Direct導入企業様のテクニカルサポートを行いながらチームみんなで協力して本番リリースまで持っていけたのは貴重ないい思い出です。
その後はしばらく追加開発や運用をしていましたがKyash Direct事業譲渡の発表があり、幾度かの移管作業を経てつい先日全ての作業が完了しました。立ち上げから関わったプロダクトが終わった日は少し寂しかったです。

## WalletアプリKyash

Kyash Direct事業譲渡の発表があってすぐにWalletアプリ側の開発チームに配属されました。Kyashマネー残高を銀行に出金するプロジェクトにはじまり、マイナポイント、eKYCなどの開発に携わりました。開発スピードを保ちながら技術的負債をなんとか攻略して開発を進めるのはつらいと思うことがありますが、楽しいと思うことがほとんどです。これからもKyashが目指すプロダクトを実現すべく開発を進めていきます。

# チームの現状と課題

## チームなんでも屋

現在所属しているチームはCustomer Engagementチームといいます。チーム名からはなかなか業務内容が想像しにくいかと思いますが、簡単に言うとKyashアプリの中で「入金」と「決済」以外の部分のほとんどを担当するチームです。Kyashアプリの中で入金と決済以外の部分ってほとんどないとか言われてしまいそうですが、これまで銀行への出金機能、マイナポイント、eKYC機能の開発に携わりました。アプリを通じた接点という意味でユーザと関係性の深い部分の開発を一手に担っていて、なんでも屋と言えるかもしれません。

## 技術的負債との戦い

Kyashではマイクロサービスアーキテクチャを採用していて、チームごとにいくつかのサービスを担当しているのですが、Customer Engagementチームが担当する中に「api」と名のついたサービスがあります。このサービスはKyashアプリの中ではおそらく一番古くて、巨大で、複雑なサービスです。きっと、モバイルアプリからの通信を各マイクロサービスに割り振って、返ってきた情報を整形して返すのが理想的な形でしょう。現状はGET系リクエストに対してDBから情報を取ってくる部分から行っていたり、送金などPOST系リクエストに対して残高変動を伴う処理を行っていたり、かなり多くのドメイン知識を持ってしまっています。プロダクトの新規開発スピードを保ったままサービスやライブラリとして切り出すなどの改善をするのはかなり難しく、ほとんどできていません。たまには全力疾走してきた道を振り返る時間が必要ですね。

# これからの半年

実は、6月頃に家族が増えます。初めてなので生活リズムや習慣が大きく変化すると思われます。ちょうどこの4月に出産休暇という休暇制度ができたり、1~2ヶ月間の育児休業を取得したい話を進めていたりして、会社やチームが柔軟に対応してくれて助かっています。育児休業が終わって仕事に戻っても、フルリモートワークで普段から自宅に籠っているので可能な限り夫婦で分担をしながら育てていきたいと考えています。

Kyashのプロダクトにはいろいろな意見があるとは思いますが、Kyashが目指すところに向かってこれからもがんばります。

Kyash ID: pranc1ngpegasus


Kyashに入社して2年くらい経った話

---
title: ひろびろ一枚板でつくるすっきりデスク
slug: made-my-work-desk-with-genuine-wood
tags: おしごと,デスク
date: 2021/02/23
wip: false
---

# これはなに

みなさま、「デスクをすっきりさせるマガジン」はご存知でしょうか。
無数の工夫が詰め込まれた美しいデスクの数々……noteを見ているうちに「自分もこんなデスクをつくりたい!!」と思いつくってしまいました。

https://note.com/goando/m/me3ed2026f6ac

# これまでのデスク

![20210827154553](https://user-images.githubusercontent.com/23367170/167638889-ca0bf8d0-3301-4302-b034-398902e38a85.jpg)

この状況下になり社のリモートワークが始まってから家族とともに地方へ引っ越したため、これまでのデスクは折りたたみテーブルにディスプレイを載せただけのデスクでした。飲みものを置くと作業スペースが手狭になるくらいの大きさです。

# 今回のデスクに必要な要件

リモートで働くうえで必要になるデスクってどんなだろう? 高級チェアは必要? スタンディングデスクは? など多様な選び方があるデスク業界(な業界)ですので、主軸がブレないように今回の要件を定義しました。内容は以下の通りです。

1. デザイン性が高い
2. 立ったり座ったり、姿勢を変えながら作業ができる
3. ひろびろ作業がしたいのでなるべく広く

デザイン性は、まあせっかく作るならかっこいいデスクがつくりたい! という気持ちがあるので第一に挙げました。またリモートで夜遅くまで働いていたり、地方在住という特性上、運動不足になる可能性が非常に高いことから立ったり座ったりできることを挙げました。さらに、いままでのデスクが非常に手狭だったことと、過去に室内ドアをはずしたものをそのままデスクの天板として使ったら予想以上に使い勝手がよかったことから、なるべく広いスペースのデスクにしたいことを挙げました。

# デスク脚

デスク脚は以下の点を考慮して商品選びをしました。

1. 自分に合った高さに調整ができる
2. 天板を広くしたいのでその重量を支えられる

上記のような仕様を叶えられるデスク脚はかなり少なく、価格のことも考えて今回はFlexispot E3シリーズを選びました。
Amazonプライムデーを利用して購入したらかなりお得にゲットできました。

https://www.amazon.co.jp/dp/B074897V3X

# デスク天板

デスク天板は以下の点を考慮して商品選びをしました。

1. やっぱ憧れの一枚板でしょ
2. Flexispotが支えられるのは幅2000mm x 奥行800mmで100kgまで

本来は現地で木と向き合いながら好みの天板を見つけるべきかと思っていましたが、ご時世がご時世だったので通販で購入できる天板を探しました。
一枚板ってお高いんですね……希望のサイズだと数万円のものから数十万円のものまでたくさんあり、なおかつ品種選ぶことができます。
そんな中で比較的お安くかつ品質がよさそうなあきたの材木屋さんより幅2000mm x 奥行670mm~710mm x 厚み62mmの天然杉を購入しました。

https://akita-zaimokuya.com/products/%E5%A4%A9%E7%84%B6%E6%9D%89%E5%8E%9A%E6%9D%BF-524/

# 天板の加工

天板は一枚板ということもあり、一生使えるものに仕上げたいという思いから近くの木材加工店に研磨と塗装をお願いしました。

https://twitter.com/pranc1ngpegasus/status/1357929598961344513

いよいよ天板が届き車で運送業者の営業所まで受け取りにいったのですが、助手席を前方にめいっぱい移動させたり、一人で運べる重さではなかったので運送業者の方に載せるのを手伝ってもらったりしながらなんとか荷台に押しこめました。

https://twitter.com/pranc1ngpegasus/status/1363079673618395141

木材加工店か完成の連絡があり家まで運び込みました、すばらしい木目!! このあと二階にある自室まで妻に手伝ってもらいながら運び込み、翌日から執筆中の本日もひどい筋肉痛に襲われています。

[https://twitter.com/pranc1ngpegasus/status/1363119541283414023

いよいよケガキ作業に入ります。FlexiSpotは脚の幅を調整することができるためか正確な寸法を計測することができませんでした。そのため現物合わせでケガキを行いました。

https://twitter.com/pranc1ngpegasus/status/1363310088581091329

翌日、近くのホームセンターからインパクトドライバをレンタルしてきて、ケガキをした場所に鬼目ナットを埋め込みました。

https://twitter.com/pranc1ngpegasus/status/1363345335448260615

FlexiSpot付属の木ネジ寸法と、一枚板を固定するのに十分な固定力の兼ね合いから、今回はFlexiSpotモータ部の固定にM6x20mmの鬼目ナット、デスク中央部分の固定にM4x15mmの鬼目ナットを埋め込みました。ボルトは締めつけ強度の強い、六角穴つきボルトのM6x20mm、M4x15mmを選びました。

https://twitter.com/pranc1ngpegasus/status/1363409237624320003

鬼目ナットさえ埋め込めば、あとはFlexiSpot脚の上に天板を載せて、下からビスで固定するだけです! ついに完成🎉🎉

# まとめ

https://twitter.com/pranc1ngpegasus/status/1363413632030154757

FlexiSpotの恩恵により、姿勢を変えながらの作業はかなり快適で集中力がこれまでよりも長く続くと感じました。また、広いデスク領域があるので趣味であるカメラコーナーを設置することができたり、まだ計画中ですが観葉植物なども置きたいと考えています。ほんとうに作ってよかった!!


ひろびろ一枚板でつくるすっきりデスク

---
title: リモートミーティングに参加する前に読むポスト
slug: readme-before-attend-to-remote-meeting
tags: おしごと,リモートワーク
date: 2020/02/19
wip: false
---

# これはなに

社内外を問わず、リモートでミーティングをする機会が増えていることと思います。
これからリモートミーティングに挑むぞ! という前に読んでおきたい心構えやマナーについてご紹介します。

# 心構え編
1. **どんどん発言しよう!**<br/>
リモートミーティングで発生しがちなのが"会話の間"。
相手が話すかな? もしかして自分の番? とタイミングを伺っているとぎこちなくなってしまいます。
どんどん自分から話しましょう!

2. **明るくハキハキと**<br/>
リモートでの会話は、テキストでの会話以上に考えることが多いです!
相手に聞こえるように、明るくハキハキと話しましょう!

3. **ファシリテータが意見を引き出そう!**<br/>
リモートミーティングでありがちなシチュエーションとして、会議室×自宅があります。
会議室だけで話が進んでしまうと、自宅でリモートしている方が話についていけなくなってしまいます。
ファシリテータは全員に聞いて回り、相手の意見を引き出しましょう!

# 環境準備編
1. **背景はきれいにしよう!**<br/>
ビデオ通話を利用したミーティングでは、相手のいる場所や自宅スペースなど、興味をそそるものがたくさん。
それで話が脱線してはミーティングの効率が激減してしまうので、背景は片付けておきましょう!

2. **イヤホンを使おう!**<br/>
リモートミーティングを始めるときに、やってしまいがちな[ハウリング](https://dic.nicovideo.jp/a/ハウリング)。
ミーティングが大音量のキーン! からはじまるのはイヤなものです。
これを防ぐにはそもそもスピーカーを使わなければよいので、イヤホンを使いましょう!<br/>
**僕のおすすめは[EarPods](https://www.apple.com/jp/shop/product/MNHF2FE/A/earpods-with-35-mm-headphone-plug)(AirPods, AirPods Proも可)です**

3. **いいマイクを使おう!**<br/>
リモートミーティングで困ることが多いのが"音質"。
何度も聞き返していると時間がもったいないし、自分の気持ちも伝わりづらくなってしまいます。
リモート先の相手が聞き取りやすいように、いいマイクを使いましょう!

# 実践編
1. **話すとき以外はマイクをミュートにしよう!**<br/>
リモートミーティングでは、たくさんの場所から人が集まります。
その人がいる環境によって、周りの騒音が気になってしまい、肝心の声が聞きとれなくなってしまいます。
リモートミーティングに参加しているみんなが聞きとりやすいように、話すとき以外はマイクをミュートにしましょう!

2. **相槌は声を出さずにオーバーリアクションで!**<br/>
リモートミーティングで相槌を打つと、相手に届くときには既に相手は話し途中の場合が多々あります。
そんなときは、マイクはミュートのままオーバーリアクションで反応しましょう!

3. **画面共有を効率的に使おう!**<br/>
リモートミーティングで「あれ」「これ」は通じません!
そういうときは画面共有機能を使って、カーソルなどを動かして指し示しましょう!


リモートミーティングに参加する前に読むポスト

---
title: Merpay Tech Talk vol. 2に行ってきた
slug: went-to-merpay-tech-talk
tags: MerPay,TechTalk
date: 2019/12/21
wip: false
---

2019年12月18日、Merpay社主催のTech Talk vol.2に行ってきたので学んだことをまとめる。

# Merpay Tech Talkとは


> 毎回各テーマに興味のあるエンジニアたちが集まり、技術的な知見を共有しあうことを目的とした勉強会です。 - Connpass説明分より

とのこと。
今回のテーマは「[マイクロサービスの冪等性](https://mercari.connpass.com/event/157009/)」ということで、同じマイクロサービスを扱う身としてどんなことに気をつけて設計しているのか学んできた。


# Talk 1: 500万ユーザーを支える残高の冪等性

https://speakerdeck.com/kazegusuri/builderscon-tokyo-2019-open-skt

全体像はこの資料にある模様。
特に強調していたのは冪等性を担保するために検証する要素として冪等性キー(UUID v4を採用)の他にペイロードの中身も検証対象にしているという点で、冪等性キーだけを見て判断するのではなく、リクエスト内容も検証することでたまたま同じ冪等性キーが発行されてしまった場合にも冪等性を担保できることを考えて設計しているとのこと。
しかし、これを実現するにはチームや他のサービスとの協力が必要なので、チーム内外のコミュニケーションは大事である旨も強調していた。

# Talk 2: コード決済における冪等性と整合性

https://speakerdeck.com/susho/number-merpay-techtalk

エラーが返ってきたはずなのに実際には残高が動いていたとか、特にお金に関わる問題があるとサービスの信頼性を失ってしまうし、マイクロサービスアーキテクチャでサービス間の整合性を保つことはDBの点在など関連する要素が多く非常に難しいので、マイクロサービス間でリトライを何度しても不整合が発生してしまう状況を考えて定的にバッチで不整合を修復しているとのこと。
ある一定期間は不整合が生じてしまうが、最終的に整合がとれるようにするにはバッチ処理を使った修復は必須だと考えているとのこと。
同期的に処理をするのは決済リクエストを受けてからレスポンスを返す部分だけで、サービスごとに内部的なステートを遷移させる処理は非同期で行っている部分が興味深かった。

# Talk 3: バッチ処理と冪等性

https://speakerdeck.com/kaznishi/20191218-merpay-techtalk

バッチ処理は、常に動いていないサービスである分失敗しやすいからリトライしやすいように作っているとのこと。
バッチ処理を冪等に設計するメリットは、なにかバグを発見したときに原因を修正したらもう一回流すことで回復できる部分であるとのこと。たしかに、何度繰り返し処理をしても結果が変わらない設計をしていれば特別なリトライ方法を用意する必要がなくて運用がシンプルになると感じた。


# まとめ

冪等生の担保の前に、リトライは必ず必要になるという理解が必要だと感じた。
リトライ処理をいかにシンプルにできるかを考えると、おのずと冪等生確保につながると感じた。
常に冪等性を意識したサービス作りが保守運用をシンプルにしたり、もしものときに回復までの時間を短縮できたりすることに繋がると感じた。


Merpay Tech Talk vol. 2に行ってきた

---
title: Vue.jsとKonva.jsでcanvasに入門した
slug: introduce-canvas-with-vuejs-and-konvajs
tags: プログラミング,canvas
date: 2017/10/18
wip: false
---

# これはなに

Vue.jsとVue.jsに対応したCanvasラッパーであるKonva.jsを使ってCanvasに入門した話をまとめる。

# つかった技術

- Vue.js
- Konva.js (vue-konvaパッケージ)

# なにをつくった

時間とともに七色に変化する円をつくった。

![20210828211441](https://user-images.githubusercontent.com/23367170/167636478-47c1620b-0a96-40c5-a405-48841475595d.gif)

右側に表示されている16進数は2桁ずつのRGB値となっており、七色に変化させたかったので[HSB色空間](https://ja.wikipedia.org/wiki/HSV色空間)からRGB色空間に変換したものを使っている。

# つくり方

## 1. Vue.jsプロジェクトを作成する

[Vue CLI 3](https://cli.vuejs.org)を使ってプロジェクトを作成した。

プリセットをデフォルト(babel, eslint)、パッケージ管理ツールをyarnとした。

## 2. vue-konvaパッケージをインストールする

Vue.jsに対応したCanvasラッパーãKonva.jsしか見つからなかったので、[vue-konva](https://github.com/konvajs/vue-konva)パッケージをインストールする。

```shell
yarn add vue-konva konva
```

## 3. 不要なコンポーネントのお掃除をする

入門なので、余計な記述があると混乱するため不要な記述は削除しておく。
また、`src/components/HelloWorld.vue`も不要なので削除する。

```javascript
<template>
  <div>
  </div>
</template>

<script>
export default {
  name: 'app',
  components: {
  }
}
</script>
```

## 4. コンポーネントを作成して円を描く

`src/components`ディレクトリに適当な名前でvueファイルを作成し、以下のコードを記述する。

```javascript:src/components/Circle.vue
<template>
  <v-stage :config="configKonva">
    <v-layer>
      <v-circle :config="configCircle"></v-circle>
    </v-layer>
  </v-stage>
</template>

<script>
const width = window.innerWidth;
const height = window.innerHeight;

export default {
  data() {
    return {
      configKonva: {
        width: width,
        height: height
      },
      configCircle: {
        x: 200,
        y: 200,
        radius: 100,
        fill: "#00c800",
        stroke: "black",
        strokeWidth: 4,
        shadowBlur: 10
      }
    };
  }
</script>
```

```javascript:src/App.vue
<template>
  <div>
    <Circle />
  </div>
</template>

<script>
import Circle from './components/Circle.vue'

export default {
  name: 'app',
  components: {
    Circle
  }
}
</script>
```

この段階で以下のような円が描画されます。

![20210828211526](https://user-images.githubusercontent.com/23367170/167636487-3dbe9fac-1b5b-4f33-bb85-30bf7ae163c4.png)

## 5. 円の色を変える

### どこを変えたらいいの

`vue-konva`では、`v-stage`ディレクティブに`configKonva`オブジェクトを渡すことでcanvasの設定を行い、`v-circle`ディレクティブに`configCircle`というオブジェクトを渡すことで円を描画しているようでした。
円の中のè²を変えるためには、configCircleオブジェクトのfillプロパティを変えるとよさそうです。

```javascript
configCircle: {
  x: 200,
  y: 200,
  radius: 100,
  fill: "#00c800",
  stroke: "black",
  strokeWidth: 4,
  shadowBlur: 10
}
```

fillプロパティは`#`からはじまる6桁の16進数を指定することによりRGBの値を設定できるので、この値を上書きしていくことにします。

### HSBからRGBへの変換

今回、16進6桁のRGB値を七色に変化させるためにHSB色空間というものを使ってみました。
[HSB色空間](https://ja.wikipedia.org/wiki/HSV色空間)とは、色をH(Hue: 色相)、S(Saturation: 彩度)、B(Brightness: 明度)で表現する色空間のことです。
今回は、彩度、明度を100%にした状態で、色相を0~360まで変化させることで七色に色が変化させることにしました。

[HSBからRGBへの変換](https://ja.wikipedia.org/wiki/HSV色空間#HSVからRGBへの変換)ã参考に、変換するコードを実装したのがこちら。

Hに0~360までの値、Sに0~1までの値、Vに0~1での値を引数として与えることでRGBの値を16進2桁ずつの配列として返してくれます。

```javascript
hsv2rgb: function (H,S,V) {
  var C = V * S;
  var Hp = H / 60;
  var X = C * (1 - Math.abs(Hp % 2 - 1));

  var R, G, B;
  if (0 <= Hp && Hp < 1) {
    [R,G,B]=[C,X,0]
  }
  else if (1 <= Hp && Hp < 2) {
    [R,G,B]=[X,C,0]
  }
  else if (2 <= Hp && Hp < 3) {
    [R,G,B]=[0,C,X]
  }
  else if (3 <= Hp && Hp < 4) {
    [R,G,B]=[0,X,C]
  }
  else if (4 <= Hp && Hp < 5) {
    [R,G,B]=[X,0,C]
  }
  else if (5 <= Hp && Hp < 6) {
    [R,G,B]=[C,0,X]
  }

  var m = V - C;
  [R, G, B] = [R+m, G+m, B+m];

  R = Math.floor(R * 255).toString(16);
  G = Math.floor(G * 255).toString(16);
  B = Math.floor(B * 255).toString(16);

  return [R ,G, B];
}
```

### 実際に変えてみよう

RGBの値は16進6桁の文字列として与える必要があるため、`zeroPadding`関数を使って`hsv2rgb`関数の最後にRGBそれぞれの値を0埋めするコードを追加した。

```javascript
zeroPadding: function (num, length) {
  return ('0000000000' + num).slice(-length);
},
hsv2rgb: function (H,S,V) {
  // ここまで省略
  R = Math.floor(R * 255).toString(16);
  G = Math.floor(G * 255).toString(16);
  B = Math.floor(B * 255).toString(16);

  R = this.zeroPadding(R, 2);
  G = this.zeroPadding(G, 2);
  B = this.zeroPadding(B, 2);

  return [R ,G, B];
}
```

この2つの関数と`setInterval`を使って色を変化させてみます。

```javascript
var inthsv = 0;

setInterval( () => {
  inthsv++;
  inthsv %= 360;
  var strrgb = this.hsv2rgb(inthsv, 1, 1).join('');
  this.configCircle.fill = '#' + strrgb;
  console.log(strrgb);
}, 1/30 * 1000);
```

## 6. 完成形のコード

```javascript:Circle.vue
<template>
  <v-stage :config="configKonva">
    <v-layer>
      <v-circle :config="configCircle"></v-circle>
    </v-layer>
  </v-stage>
</template>

<script>
const width = window.innerWidth;
const height = window.innerHeight;
var inthsv = 0;

export default {
  data() {
    return {
      configKonva: {
        width: width,
        height: height
      },
      configCircle: {
        x: 200,
        y: 200,
        radius: 100,
        fill: "#00c800",
        stroke: "black",
        strokeWidth: 4,
        shadowBlur: 10
      }
    };
  },
  mounted() {
    setInterval( () => {
      inthsv++;
      inthsv %= 360;
      var strrgb = this.hsv2rgb(inthsv, 1, 1).join('');
      this.configCircle.fill = '#' + strrgb;
      console.log(strrgb);
    }, 1/30 * 1000);
  },
  methods: {
    zeroPadding: function (num, length) {
      return ('0000000000' + num).slice(-length);
    },
    hsv2rgb: function (H,S,V) {
      var C = V * S;
      var Hp = H / 60;
      var X = C * (1 - Math.abs(Hp % 2 - 1));

      var R, G, B;
      if (0 <= Hp && Hp < 1) {
        [R,G,B]=[C,X,0]
      }
      else if (1 <= Hp && Hp < 2) {
        [R,G,B]=[X,C,0]
      }
      else if (2 <= Hp && Hp < 3) {
        [R,G,B]=[0,C,X]
      }
      else if (3 <= Hp && Hp < 4) {
        [R,G,B]=[0,X,C]
      }
      else if (4 <= Hp && Hp < 5) {
        [R,G,B]=[X,0,C]
      }
      else if (5 <= Hp && Hp < 6) {
        [R,G,B]=[C,0,X]
      }

      var m = V - C;
      [R, G, B] = [R+m, G+m, B+m];

      R = Math.floor(R * 255).toString(16);
      G = Math.floor(G * 255).toString(16);
      B = Math.floor(B * 255).toString(16);

      R = this.zeroPadding(R, 2);
      G = this.zeroPadding(G, 2);
      B = this.zeroPadding(B, 2);

      return [R ,G, B];
    }
  }
};

</script>

<style>
body {
  margin: 0;
  padding: 0;
  overflow: hidden;
  background-color: #F0F0F0;
}
</style>
```

# まとめ

Vue.jsとKonva.jsを使ってcanvasに入門してみた。
Konva.jsがわかりやすくラップしてくれていてサクっと描画することができて好印象だった。


飛ばねぇ馬はただの馬。