数字でふりかえる2021年。

## アウトプット

### 勉強会の登壇数

外部公開していないものも合わせると**4**回。

全部オンラインだしLTだったけど、まだ慣れた気はしない。

### ブログ記事

ブログ記事も**4**つ。

技術的な匂いのするものに限っては2つだけ。

もう駆け出しでもないんだし、いい記事を書こうとカッコつけている自分がいる。

読書しながらツイートするのは楽しかったから、ああいう感じでできればいいんだろうけどな〜

<Twitter tweetId="1447438855355789313" />

## インプット

### 読書

**23**冊。

去年を計測していないからわからんけど、単純計算で月に2冊のペース。

買って積む本の数のほうが多い気がするな。

## 面白かった本2021 BEST 3

### [アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~](https://amzn.to/3FGZgIW)

チームでスクラム組んで開発をしていたときに、嘗てのScrumMasterから言われた数々の言葉や意図がすべて書いてある。

スクラムマスタ当人以外のチームメンバーも、この一冊を読んだ後はよりスクラムガイドの理解に拍車が掛かり、より良いスプリントが過ごせるだろうと確信した。

### [Real World HTTP 第2版 ―歴史とコードに学ぶインターネットとウェブ技術](https://amzn.to/3FPmjkw)

Web業界で働いている身としては、聖典として何度も手に取りたいと思う一冊だった。

HTTPのheaderやbodyの概念がメール由来なことは初耳だったし、認証・認可まわりやセキュリティ周りにも触れつつ、HTTP2やHTTP3についても書かれていて兎に角ボリューミーな一冊だった。

### [なぜデジタル政府は失敗し続けるのか 消えた年金からコロナ対策まで](<https://amzn.to/3sGW0cB>)

よくある時事本だと思いきや、IT業界あるあるな失敗例がたくさん載っているような一冊だった。

対岸の火事として見過ごすのではなく、失敗している事実から反省する視点から見るとかなり面白かった。

## まとめ

**インプット** ＞ **アウトプット** な一年だった。

本はまあまあ読んだと思うし、アーカイブを含めて勉強会に参加もした。

エンジニアとして小さく歩みを進めているという自覚もある。

来年はプライベートが少し忙しくなる事もあって、インプット・アウトプット共に圧倒的な数値向上は難しいかもしれない。

今年くらいのペースは最低限保ちつつ、もう少し技術書の感想や、調べたことのメモなどを残していきたい。

2021年師走。この一年のインプットとアウトプットを数字でふりかえってみた。引き続きリモートワークを行っている中、インプットした時間は確実に増えた。アウトプットとしての勉強会もリモートで参加することができた。特にインプットした中で印象に残った3冊の書籍を紹介し、来年の見込みを想定した上で大晦日に入ろうと思う。

2021年のふりかえり

エンジニアあるある。

無駄なコードは絶許だけど、無駄なガジェットは買っちゃう。

あると思う。

先日AppleWatch⌚️は第7世代が、OuraRing💍は第3世代が発表された。

特にこの2つはエンジニアの玩具としてはそこそこ優秀だ。

どちらのデバイスもおじさんが気にする曖昧な関心事を数値化してくれる。

* 運動
* 睡眠

自分も実際に使用し、生活に溶け込ませた上で恩恵を大いに預かっている。

そんなユーザである自分が実際に使ってみた感想を比較しながら綴ろうと思う。

※当記事は、以下のモデルを使用した上での感想であることをご了承頂く。

* AppleWatch⌚️
 * 第4世代44mmモデル
* OuraRing💍
 * 第二世代

## 付け心地について

AppleWatch⌚️に関して言えば3年以上使っており、睡眠時にも着用しているが特に問題はない。

少なくともAppleWatch⌚️は時計である以上、人体に対する接着面積は指輪よりも大きいにもかかわらずだ。

購入前は寝てる時間に装着するなんて考えもしなかったが、全く違和感がない。

対してOuraRing💍である。

こんな小さなリングに、自分のバイタルデータや睡眠時間をトラッキングするような各種チップが埋め込まれているなんて、誰が想像できるだろうか。

しかしOuraRing💍は、日常生活において、 **時と場合によっては邪魔** になる。

指輪である以上、何かを握る際などには邪魔に感じることが往々にしてある。

電車の吊り革やダンベル、ベンチプレスのバーを握る時。

何かを洗うときに自分は、AppleWatch⌚️と比較して顕著にストレスを感じた。

## バッテリー周りについて

言うまでもなく圧倒的にOuraRing💍に軍配が上がる。

体感でいうと、AppleWatch⌚️は長く持って **2日** 。OuraRing💍は **4日** 程度持つんじゃあないかと思っている。

※あくまでも筆者の体感である

充電周りの環境は、どちらも専用の充電装置を用いる必要があるため変わらない印象である。

AppleWatch⌚️に関してはサードパーティ製の充電デバイスが出ていて、Type-Aの端子もType-Cの端子も存在する。

OuraRing💍は付属のType-C専用のものが一般的だと思われる。

## 睡眠記録について

睡眠に関して言えば、[狩野モデル](<https://ja.wikipedia.org/wiki/%E7%8B%A9%E9%87%8E%E3%83%A2%E3%83%87%E3%83%AB>)でいうところの性能品質は満たせていると思う。

寝るときにデバイスを装着していれば、割と正確な睡眠時間を記録できる。

宿泊施設に高級なドライヤーが置いてあったら満足度が上がる、といったような魅力品質に関してはAppleWatch⌚️が優勢だである。

理由は、AppleWatch⌚️はApp Storeを通じて様々なアプリが手に入る点にある。

自身のデータを円グラフで見たい人もいれば棒グラフで見たい人もいる。各々のニーズに合ったアプリを通して自分の睡眠データを確認することができる。

ところが、OuraRing💍については公式アプリしか存在しない。

我儘なユーザとしては、選択肢が少ないように思う。

## 運動記録について

例えば、あなたが散歩をしたとしよう。

AppleWatch⌚️にとっては、「運動開始」と宣言されたわけではないため万歩計の歩数だけが記録として残る。

OuraRing💍にとってはどうだろう。

「散歩も運動かもしれない」という感じで、アクティビティの数値として計上される。

上記のような、些細だが大きな違いが両者には存在する。

読者にとって散歩が人生においてとても大切であり、うっかり計測を忘れてしまうようであればOuraRing💍はとてもいい相棒になると考える。

ただ睡眠のトピックでも扱ったように、よりカスタマイズ性のある使い方をしたければAppleWatch⌚️にアプリをインストールしたほうがいい場合もある。

ジムへ汗を流しに行っても、OuraRing💍は具体的な種目などの記録ができない。

AppleWatch⌚️を使うと何が良いかという点に関して。

自分は[Fitness Point Pro](<https://apps.apple.com/jp/app/fitness-point-pro-%E3%82%B8%E3%83%A0-%E3%83%9B%E3%83%BC%E3%83%A0/id573916046>)を使っているが、トレーニング後すぐに記録できる点がとても素晴らしいと思う。

スマートフォンと異なり、記録のために毎回認証は不要で、人差し指でタップするだけで記録ができる。

## 最後に

今でこそ、どちらのデバイスも少し背伸びをすれば手に入る価格帯になったのではないかと感じる。

自分の健康を気にしていて、ある程度それらの曖昧なものを数値化したい人に当記事が役立てば幸いである。

エンジニア向けにはなるが、OuraRing💍はWeb APIを外部公開している。

[OuraRing Developer: API Documentation](<https://cloud.ouraring.com/docs>)

自分のヘルスケアデータをｺﾞﾆｮｺﾞﾆｮしてみたい人にとっては、OuraRing💍のほうがエンジニアの玩具としては優位かもしれない。

歳を取れば取るほど体は衰えていく。ある日突然身体がエラーを発しないように、モニタリングすることはエンジニア的には急務であると最近感じるようになった。健康といえばAppleWatch⌚️やOuraRing💍がナウでヤングな感じなんだろうか。玩具として両方使っている自分が、生活に溶け込んで噛み締めた感想を、両デバイスで比較した感想を綴ろうと思う。

AppleWatch⌚️とOuraRing💍を両方使ってみたので感想を書く

タイトルどおりである。

『OAuth徹底入門』というOAuth何もわからん人間にとってありがたい技術書を読み進めているのだが、ちょっと開発環境を準備したほうが良さそうだったため記事に纏める次第である。

## 開発環境の準備が必要だと思った理由

理由は2つあって、1つは開発をすすめるにあたって _コンソールを3つ準備せよ_ と技術書に書いてあるからである。

正しい言葉ではないかもしれないが、 **認証サーバー** と **クライアント（サーバー）** と **保護対象リソース管理サーバー** の3つを監視する必要があった。

仰ることはごもっともだが、律儀にコンソールを3つ開き、それぞれのサーバーの起動コマンドを叩くなんてことは大変申し訳ないが面倒くさい。

もう1つの理由は、技術書で紹介されているコードが古いことに起因する。

ES5時代のNode.jsが利用されており、現在（2021年6月26日）の最古のLTSであるversion-12ですら、依存ライブラリが動かないのである。

その問題のライブラリがデータを保存するライブラリであるために、格納するためのストレージやクライアントライブラリを別で導入する必要があると考えた。

## 構築した開発環境

今回の目的は、**技術書の読破**である。

よって**動けばいい**という大変敷居の低い環境構築を目指した。

動作させたいするソースはこちら。絶賛開発中であるが、大まかな環境の実装は変える予定はない。

[https://github.com/hyroky867/oauth-in-action-code](https://github.com/hyroky867/oauth-in-action-code)

実際に作った環境はこちら。

[https://github.com/hyroky867/docker-oauth-in-action-code](https://github.com/hyroky867/docker-oauth-in-action-code)

```yaml
version: '3.9'
services:
  db:
    build:
      context: .
      dockerfile: ./docker/mysql/Dockerfile
    container_name: db
    ports:
      - 3306:3306
    restart: always
    volumes:
      - ./docker/mysql/conf:/etc/mysql/conf.d/:ro
      - mysqldata:/var/lib/mysq
      - ./docker/mysql/sql:/docker-entrypoint-initdb.d
    networks:
      - default

  client:
    build:
      context: .
      dockerfile: ./docker/node/Dockerfile
    container_name: client
    tty: true
    ports:
      - 9000:9000
    restart: always
    volumes:
      - ../oauth-in-action-code:/app
    working_dir: /app
    command: yarn client
    networks:
      - default
    depends_on:
      - db

  authorization:
    build:
      context: .
      dockerfile: ./docker/node/Dockerfile
    container_name: authorization
    tty: true
    ports:
      - 9001:9001
    restart: always
    volumes:
      - ../oauth-in-action-code:/app
    working_dir: /app
    command: yarn authorization
    networks:
      - default
    depends_on:
      - db

  resource:
    build:
      context: .
      dockerfile: ./docker/node/Dockerfile
    container_name: resource
    tty: true
    ports:
      - 9002:9002
    restart: always
    volumes:
      - ../oauth-in-action-code:/app
    working_dir: /app
    command: yarn resource
    networks:
      - default
    depends_on:
      - db

networks:
  default:

volumes:
  mysqldata:
```

Nodeサーバー3台とDBサーバー1台の構成。

コンテナが立ち上がると同時にそれぞれのサーバーがlistenを始めるという流れである。

`docker compose logs -f` を叩いておけば、各サーバでエラーが出た場合1つのコンソールでデバッグすることが可能。

## 最後に

毎回コンソール3つ準備して、1つ1つ狭い画面を見ながらデバッグすることが辛かったため記事に残したいと思った次第。

お困りの方がいらっしゃるのであればコピー&ペーストなりして、各々技術書読破に努めて頂ければ幸いである。


『OAuth徹底入門』というOAuthについて何もわからない人間にとっては、とてもありがたい技術書を読み進めているのだが、本を読み進めることが辛い。というのも、紹介されているソースコードが古く、その関係でデータを保存するためのストレージも必要になったことが理由だ。dockerを使い、孤軍奮闘して開発環境を準備したため、その紹介を行う。

『OAuth徹底入門』をするためにdockerで開発環境を作った

先日、PHPアプリケーションの速度改善を見越して情報収集を行っていた際に、以下の記事を見かけた。

[【PHP】array_uniqueよりもarray_flip2回の方が早い件を検証してみる
](https://qiita.com/Canon11/items/d87ec0200a9a930b1e45)

[@Canon11
](https://qiita.com/Canon11) さんのコードを拝借しつつ、PHPのバージョンや細かい試行回数を見つつ自分自身で検証してみる。

## array_unique() VS array_flip() 2回の比較

今回調査したい条件としては以下に当たる

- 配列の中身の違い
 - int\[]
 - string\[]
- PHPのバージョン
 - 7.3.27
 - 7.4.15
 - 8.0.2
- 試行回数
 - 10回

## 【結論】

バージョンによらず、だいたいarray_flip()2回のほうが早い

## 【検証1】 int\[]のリスト

検証用のコード

```php
<?php

declare(strict_types=1);

echo " int[] のケース\n\n";

$a = [];
for ($i = 0; $i < 400000; $i++) {
 $a[] = $i;
}

$b = [];
for ($i = 0; $i < 100000; $i++) {
 $b[] = $i;
}

$c = array_merge($a, $b);

// array_unique
$array_unique_start = hrtime(true);
$array_unique = array_unique($c);
$array_unique_end = hrtime(true);

$array_unique_time = number_format($array_unique_end - $array_unique_start);
echo "{$array_unique_time} ナノ秒 <= array_unique \n";

// array_flip2回
$start = hrtime(true);
$array_flip = array_unique($c);
$end = hrtime(true);
$array_flip_time = number_format($end - $start);
echo "{$array_flip_time} ナノ秒 <= array_flip 2回 \n\n";

if ($array_unique !== $array_flip) {
 echo 'array_unique !== array_flip';
 exit;
}

if ($array_unique_time > $array_flip_time) {
 echo "👉";
} else {
 echo "👈🏽";
}
```

* * *

### int\[], 7.3.27

```shell
% php -v
PHP 7.4.15 (cli) (built: Feb 20 2021 22:21:18) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
```

| int\[] | array_unique() | 👈🏽 OR 👉 | `array_flip(array_flip())` |
| :----: | :------------: | :--------: | :------------------------: |
| 1回目 | 39,924,560 | 👉 | 38,278,594 |
| 2回目 | 41,701,888 | 👉 | 34,106,540 |
| 3回目 | 46,447,539 | 👉 | 35,899,159 |
| 4回目 | 40,528,544 | 👉 | 33,938,650 |
| 5回目 | 43,149,254 | 👉 | 33,013,175 |
| 6回目 | 41,316,784 | 👉 | 33,131,897 |
| 7回目 | 41,564,186 | 👉 | 34,608,568 |
| 8回目 | 42,697,274 | 👉 | 32,825,526 |
| 9回目 | 39,809,918 | 👉 | 33,483,374 |
| 10回目 | 41,855,005 | 👉 | 33,985,603 |

※単位（ナノ秒）

array_flip() 2回が **10/10（回）** 早く処理処理を終えた。

* * *

### int\[], 7.4.15

```shell
% php -v
PHP 7.4.15 (cli) (built: Feb 20 2021 22:21:18) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
```

| int\[] | array_unique() | 👈🏽 OR 👉 | `array_flip(array_flip())` |
| :----: | :------------: | :--------: | :------------------------: |
| 1回目 | 42,446,711 | 👉 | 34,340,522 |
| 2回目 | 39,557,223 | 👉 | 35,170,749 |
| 3回目 | 40,918,524 | 👉 | 34,122,717 |
| 4回目 | 40,598,070 | 👉 | 34,339,807 |
| 5回目 | 40,781,877 | 👉 | 33,821,185 |
| 6回目 | 41,243,461 | 👉 | 33,253,481 |
| 7回目 | 40,894,658 | 👉 | 34,246,423 |
| 8回目 | 40,349,946 | 👉 | 35,537,478 |
| 9回目 | 39,701,355 | 👉 | 32,938,723 |
| 10回目 | 41,872,130 | 👉 | 35,027,995 |

※単位（ナノ秒）

array_flip() 2回が **10/10（回）** 早く処理処理を終えた。

* * *

### int\[], 8.0.2

```shell
% php -v
PHP 8.0.2 (cli) (built: Feb 20 2021 23:07:52) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.2, Copyright (c) Zend Technologies
```

| int\[] | array_unique() | 👈🏽 OR 👉 | `array_flip(array_flip())` |
| :----: | :------------: | :--------: | :------------------------: |
| 1回目 | 41,711,361 | 👉 | 36,266,186 |
| 2回目 | 40,616,063 | 👉 | 33,497,900 |
| 3回目 | 42,032,852 | 👉 | 33,828,179 |
| 4回目 | 40,980,778 | 👉 | 32,783,743 |
| 5回目 | 43,650,128 | 👉 | 33,658,338 |
| 6回目 | 41,534,503 | 👉 | 38,546,987 |
| 7回目 | 41,454,526 | 👉 | 32,587,730 |
| 8回目 | 47,364,202 | 👉 | 35,620,441 |
| 9回目 | 40,300,602 | 👉 | 34,827,210 |
| 10回目 | 41,764,275 | 👉 | 40,286,484 |

※単位（ナノ秒）

array_flip() 2回が **10/10（回）** 早く処理処理を終えた。

* * *

## 【検証1の結果】 int\[], のリスト

バージョンに依存せず、全ての検証に於いて **array_flip() 2回** のほうが早かった。

## 【検証2】 string\[], のリスト

検証用のコード

```php
<?php

declare(strict_types=1);

echo " string[] のケース\n\n";

$a = [];
for ($i = 0; $i < 400000; $i++) {
 $a[] = "{$i}";
}

$b = [];
for ($i = 0; $i < 100000; $i++) {
 $b[] = "{$i}";
}

$c = array_merge($a, $b);

// array_unique
$array_unique_start = hrtime(true);
$array_unique = array_unique($c);
$array_unique_end = hrtime(true);

$array_unique_time = number_format($array_unique_end - $array_unique_start);
echo "{$array_unique_time} ナノ秒 <= array_unique \n";

// array_flip2回
$start = hrtime(true);
$array_flip = array_unique($c);
$end = hrtime(true);
$array_flip_time = number_format($end - $start);
echo "{$array_flip_time} ナノ秒 <= array_flip 2回 \n\n";

if ($array_unique !== $array_flip) {
 echo 'array_unique !== array_flip';
 exit;
}

if ($array_unique_time > $array_flip_time) {
 echo "👉";
} else {
 echo "👈🏽";
}
```

* * *

### string\[], 7.3.27

```shell
% php -v
PHP 7.3.27 (cli) (built: May 15 2021 13:05:42) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.27, Copyright (c) 1998-2018 Zend Technologies
```

| string\[] | array_unique() | 👈🏽 OR 👉 | `array_flip(array_flip())` |
| :-------: | :------------: | :--------: | :------------------------: |
| 1回目 | 25,032,597 | 👉 | 23,836,284 |
| 2回目 | 26,146,482 | 👉 | 22,800,712 |
| 3回目 | 24,092,338 | 👈🏽 | 24,349,596 |
| 4回目 | 24,238,268 | 👉 | 23,215,178 |
| 5回目 | 24,959,272 | 👉 | 22,473,821 |
| 6回目 | 24,316,842 | 👉 | 22,567,803 |
| 7回目 | 24,798,343 | 👉 | 22,618,631 |
| 8回目 | 23,636,989 | 👈🏽 | 28,538,049 |
| 9回目 | 25,322,614 | 👉 | 22,541,054 |
| 10回目 | 24,216,736 | 👉 | 23,221,753 |

array_flip() 2回が **8/10（回）** 早く処理処理を終えた。

* * *

### string\[], 7.4.15

```shell
% php -v
PHP 7.4.15 (cli) (built: Feb 20 2021 22:21:18) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
```

| string\[] | array_unique() | 👈🏽 OR 👉 | `array_flip(array_flip())` |
| :-------: | :------------: | :--------: | :------------------------: |
| 1回目 | 23,675,921 | 👈🏽 | 23,868,674 |
| 2回目 | 23,968,903 | 👈🏽 | 24,036,017 |
| 3回目 | 24,567,797 | 👉 | 22,794,134 |
| 4回目 | 24,515,078 | 👉 | 23,251,968 |
| 5回目 | 23,256,640 | 👉 | 22,946,272 |
| 6回目 | 24,115,697 | 👉 | 22,854,102 |
| 7回目 | 24,829,761 | 👉 | 23,704,954 |
| 8回目 | 23,586,749 | 👈🏽 | 23,781,844 |
| 9回目 | 28,308,592 | 👈🏽 | 28,424,148 |
| 10回目 | 25,636,730 | 👉 | 23,211,889 |

array_flip() 2回が **6/10（回）** 早く処理処理を終えた。

* * *

### string\[], 8.0.2

```shell
% php -v
PHP 8.0.2 (cli) (built: Feb 20 2021 23:07:52) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.2, Copyright (c) Zend Technologies
```

| string\[] | array_unique() | 👈🏽 OR 👉 | `array_flip(array_flip())` |
| :-------: | :------------: | :--------: | :------------------------: |
| 1回目 | 24,539,993 | 👉 | 22,264,153 |
| 2回目 | 24,319,872 | 👉 | 23,243,458 |
| 3回目 | 26,612,392 | 👉 | 22,236,680 |
| 4回目 | 25,049,251 | 👉 | 24,314,740 |
| 5回目 | 27,373,260 | 👉 | 25,949,451 |
| 6回目 | 24,049,559 | 👈🏽 | 24,681,024 |
| 7回目 | 31,865,255 | 👉 | 30,057,690 |
| 8回目 | 25,588,660 | 👉 | 23,097,318 |
| 9回目 | 24,527,231 | 👉 | 21,870,357 |
| 10回目 | 24,028,025 | 👉 | 22,569,080 |

array_flip() 2回が **9/10（回）** 早く処理処理を終えた。

* * *

## 【結果まとめ2】 string\[], のリスト

バージョンに依存せず **array_flip() 2回** のほうがほとんど早かった。

PHPには公式の関数よりも、他の関数やループ処理を組み合わせたほうが早く処理が可能であることが多々ある。今回は array_unique() と array_flip() 2回のどちらが早いのかを調査した。

# PHPのarray_unique()とarray_flip()2回はどちらが早いのか調べてみた

コロナ禍に際して、人々の暮らしが大きく変わった。対人との関わり方や食事に対する価値観、そしてワークスタイルも大きく変容した。

僕は最も大きく仕事のやり方が変わった社会人の一人だろう。

識者と対面で向き合えない中で始まった **新規機能開発チーム** で取り組んだスクラム。

その中でも開発者に焦点を当てて、 **モブプロ** で培った経験をブログに残そうと思う。

## 物理モブプロとリモートモブプロの違い

先に読者には謝っておきたいことがある。僕たちが経験した新しいカタチのモブプロは今まで提唱されていたモブプロとは全く異なるということを。

当記事では、[モブプログラミング・ベストプラクティス](https://amzn.to/3igpGq1) に記載してあるモブプログラミングの手法を **物理モブプロ** と。

僕たちがリモート環境で経験した方法を **リモートモブプロ** と定義致す。

リモートモブプロと物理モブプロの違いを表に纏めた。

| | 物理モブプロ | リモートモブプロ |
| :---------: | :-------: | :--------: |
| 利用するツール | なくても開発可能 | 🙆‍♀️ |
| コーディング環境 | 1つ | 参加者にそれぞれ依存 |
| 開発者だけの空間 | オフィス環境に依存 | 自身の作業環境に依存 |
| ドライバーとナビゲータ | 🙆‍♀️ | 🙅 |

参考： [モブプログラミング・ベストプラクティス](https://amzn.to/3igpGq1) より引用

### 利用するツール

残念なことに、リモートモブプロを始めるためには専用のソフトウェアが必要だ。

簡潔に説明すると、**ホストの開発環境を他者に共有する** というものだ。

2021年1月17日現在では以下のツールが選択肢として挙げられる。

- [Visual Studio Live Share](https://docs.microsoft.com/ja-jp/visualstudio/liveshare/)

- [Code With Me](https://plugins.jetbrains.com/plugin/14896-code-with-me)

ソースコードを同時編集できたり、ホストのコンソールを操作することができる。

細かい説明や仕様については割愛する。

### コーディング環境

コードを書くプログラマにとって、キーボードやディスプレイどの物理環境は生産性や開発者体験によって大きな影響を与える、と僕は考える。

この点に関しては、物理もモブプロとリモートモブプロで圧倒的な違いが存在する。

物理モブプロの場合、モブメンバー全員が納得し、決めたコーディング環境を整えなければならない。

- 開発マシンのOS
- エディターのキーバインド
- エディターのテーマ
- キーボード
- ディスプレイ

### 開発者だけの空間

リモートだろうと物理だろうと、エンジニアだけの空間は必要不可欠だ。

それはソフトウェア開発に集中するために、ヘッドホンで世界の断絶を図ることと同じ意味を成す。

物理モブプロでは **会議室** が使われることが多く、リモートモブプロでは自分自身が作業環境を選ぶ自由と裁量がある。

何れにせよ、開発に集中できる環境を整えることは可能だ。

### ドライバーとナビゲータ

これは公式のモブプロのやり方に倣っていないアンチパターンである。だが僕たちはそれを承知でチームに合わないと結論を下した。

そのため [MobSter](http://mobster.cc/) や [mob timer](http://mobtimer.zoeetrope.com/) は一切利用していない。

## モブプロとして取り組んだこと

### 設計

設計で大切にしていたことは、 **具体的な実装方法やコーディング内容は決めない** ことだった。

僕たちにとっての **設計** とは方針決めであり、メソッド内の関心事については別タスクで進めるようにした。

_ユーザ情報1件取得するAPI_ を例にとってLaravelの場合の設計方法をサンプルとして挙げる。

```php
<?php

public function __invoke(
 GetUserService $service,
 $user_id
): JsonResponse {
 // TODO: サービス
 // $service = 
 
 // TODO: バリデーションで落ちた場合、422

 // TODO: DBに存在しなかった場合 404

 // TODO: 存在した場合 200
}
```

このようにメソッド内の具体的な実装はせずに、開発メンバーでコメントを残した。

設計が終わった段階で、僕たちはコメントのとおりにチケットを切り、スプリント・プランニングの時点でおおよその実装時間を見積もった。

### 実装

設計時点で残したコメントをもとにそれぞれ実装を進めた。

勿論、設計の時間とは別の時間軸で対応した。

例えば、以下のような役割分担を割り振ることもできる。

- メソッド名を考える人

- メソッドの引数を書く人

- ロジックを書く人

これはキーボードとマウスポインタがひとつしかない、従来の物理モブプロではありえない役回りである。

### 開発者ふりかえり

隔週で30分程度、開発者のふりかえりを行った。

毎日リモートモブプロを続ける中で **毎日する必要はない** というチームとしての答えが出たことが理由だ。

開発チームが馴染むまでは毎回やってもいいかもしれない。

ちなみに、物理モブプロではもっと頻度が高い。

## モブプロを継続してよかったこと

### ほぼ属人化した開発環境

あらゆる文脈において **属人化** という表現はポジティブな表現ではないが、ここでは前向きな意味合いである旨を表明する。

開発者にとって、開発環境（物理）は譲れないものが各々あると思っている。

キーバインド、エディタやコンソールのテーマ、フォントサイズ、物理的なディスプレイの数や大きさ。

数え切れないほどのこれらの項目は、カスタマイズされた開発者個々人に依存しており、物理モブプロに挑戦したときは皆ここがストレスポイントになっていた。

大人数になればなるほど、ディスプレイまでの距離は皆が等しくないため文字が見づらい。

普段日本語配列でタイプしている人にとって、英字配列は _ワケワカメ_ である。

この物理モブプロを経験したことのあるエンジニア以外理解されない問題が、上述したツールを利用することで解消できる。

自分の好きな開発環境で開発に向き合いつつ、チームとしてプロダクトコードを書くことができるのだ。

### 主語が「個人」ではなく「開発チーム」に変わった

チームが結成されて初めは様々な書き方や設計方法が飛び交った。

喧々諤々と議論が盛り上がるが、時間は永遠ではない。

だからこそ **開発チーム** として、答えをどうするかという結論に帰結するようになった。

今までは個人がコードを書き、プロダクトを開発していくものだと思っていた僕にとっては雷に打たれたような衝撃であった。

チームで開発しているから、誰が書いても **チームとしてのコードの書き方** になる。

もちろん、長年の悲願であった **正しいユニットテストの文化醸成** も果たすことができた。

コードの実装内容もチームに問い合わせがあるが、チームの誰もが実装方針を知っているため、**実装に関する属人性は、チームの輪に広がる**。

つまり、誰かがその場に居合わせなくても他のチームメンバーによって実装内容が補完されているため、ステークホルダーの安心材料になった。

## 最後に

きっと、緊急事態宣言下で人と会えない寂しさが募ったのだろう。寂寞の心の堰が切れた音がした。

とりとめもない話を自分がすればするほど、チームメンバーもたまには四方山話を聞かせてくれた。

リモートになって感じた、人の温かみ。己が、チームの一員であることの自覚。

結果、**相手へのリスペクトを大前提** として開発メンバーの皆が自分の意見を表明はする文化が根づいた。

「最高のプロダクトをこのメンバーと作り上げたい」

開発方針に不満があったり、取り組んで善かったことに関して _開発者ふりかえり_ の時間をとって振り返ることで抱えていた問題を **代謝** することができた。

一人で抱え込まずに **チームとして課題を解決する** 意識を持ち続けたい。

コロナ禍に際して、人々の暮らしが大きく変わった。対人との関わり方や食事に対する価値観、そしてワークスタイルも大きく変容した。仕事環境はオフィスから自宅に変わり、コミュニケーションの方法は対面からビデオミーティング変わった。仕事の方法はリモートでモブプロをすることになった。変化に対応した一年の中でモブプロを経験して、良かったことを纏めた。

# 一年間スクラムの中でリモートモブプロを続けて取り組んだこと、よかったこと

本日を以って、 2020年の業務を終業した。

今年は全世界的にコロナ禍に苛まれた。仕事・プライベート共に大きく変わった一年を過ごした。

このタイミングでブログが立ったから、1年の振り返りをする。

## 仕事のふりかえり

先ずは仕事に関するトピック。僕の現場では日本政府による緊急事態宣言が布告されたと同時に *出社禁止* となった。

つまり、 **物理的な通勤電車による通勤** から開放された。電車に乗ることがなくなって前よりも早起きする必要性が減った。

起床時間から出社までの時間が圧縮されたことによって、男の僕は起きて5分後にはPCの電源を点けて仕事に取り掛かることができるようになった。

絵に書いたようなエンジニアっぽい仕事風景だが、実際やってみると善かったことや悪かったことがあっていい経験ができた。

### 自宅が仕事場になった

もともと我が家は、一日当りの滞在時間が長いことを想定して借りていない。在宅ワークが始まって間もなく **身体にガタが来た**。

最低限映画を見るためだけの安いパイプのソファーとローテーブル、そしてベッドくらいしか持ち合わせていなかった。

身体は資本のため無視するわけにはいかず、様々な策を検討した。

1. 広い作業空間を求めて、引っ越す
2. 今までどおり家の外で業務ができるようなワーキングスペースに通う
3. 知恵を絞り尽くし、て今の狭い家にデスクを置く

結局、3の `知恵を絞り尽くして、今の狭い家にデスクを置く` ことにした。

理由は、 **自分のデスクを持ちたい** という男のちっぽけな夢を叶えたいがためである。

実際、妥協せずに各機材を揃えた。

身体には特に気を配り、椅子には **80,000** 円かけた。

今の所払っただけのリターンを特には感じないが、つらみを何も感じていないから大満足である。

時間とカネをたんまりかけて、納得し尽くして作ったデスクでの仕事まあいい感じだ。

夢を叶える機会をくれた点に関して、コロナに感謝したい。

### たくさんコミュニケーションをとった

何を言っているのかわからないだろうが、ありのまま起こったことを話すぜ。

具体的には、出勤していたときよりもチームメンバーと喋った。

というのも、コロナ禍のWork from homeが始まった瞬間に新規プロジェクトチームの一員として僕がアサインされた。

様々な不安要素に煽られながら、onboardingは始まっていく。

僕の所属するチームのWorking Agreementのひとつに **常時通話ツールを繋げておく** というルールができた。

ルールや制度とは、必要な時と場合に熟知した上で利用しなければ宝の持ち腐れである。

 *「たくさん話して心理的安全性高めれば、チームとしての力は強くなるっしょ😎」*

隙間さえあれば公開可能な情報を用いて、チームメンバーの笑いを取ることを目標にして喋りまくった。

また別の記事で書くが、このコミュニケーションが功を奏して開発のコミュニケーションが捗りすぎた。

初めてのスクラムにも、臆せず挫けず突き進むことができた。

## プライベートのふりかえり

実際に仕事で挑戦したことなどの細かいことは別の記事で書くとして、緊急事態宣言のお布施でお家時間が増えたプライベートを振り返る。

### 自主学習をするようになった

今までの僕が家に抱いていた責任は `疲れを取るための場所` であった。それが家具を一新し、魔改造した結果手にした **俺の夢の結晶デスク** によって意義が大きく変わった。

今まで叱咤激励を頂いていた先輩方には申し訳ないが、僕はコロナ禍になるまで技術に関して自主的に学習したことがなかった。

勉強する暇があったら職場に籠ってチームメンバーと設計談義をしたり、粛々とタスクやIssueを消化している質だった。

デスクとキーボード、ディスプレイとマウスがデスクの上にあるだけでたま〜にコードを書きたくなるようになった。

新しい技術に触れる土壌が整ってこのブログもその一環で実装した。

毎日開発できているわけじゃないけど、ゼロだったエンジニアとしての勉強時間を確保できるようになった環境変化は喜ぶべきだろう。

### 読書量が増えた

勉強のトピックと少し被る。だが同じではない。

朝遅く起きて、仕事して、ランチする。
仕事に戻って、シャワーを浴びて、寝る。

こんな生活をずっとしていると、色々な意味合いで刺激が少ない。気分もだんだん落ちてくる。

どれだけアニメを見てもどれだけ酒を飲んでも、満たされなかった渇き。

久々にゲームをしたときにも同じ飢えを感じた。

この渇きを、最も潤したことのひとつが読書だった。

今まで読書をしてこなかったわけではないが、読書による **知的欲求の充足** に改めて意義を感じることができた。

巨人の肩に乗って知の海を見渡すことは、人間の尊厳を満たしてくれる。

技術書やビジネス書との邂逅の数が増えた。是非ブログにアウトプットしたい所存だ。

## 今年のむきなおり

年を越す前に、エンジニアとして良き来年を過ごすため向き直るべきことを残しておく。

### 自主開発をもっとうまくやる

自主勉強を全くといっていいほどやってこなかったエンジニア人生だった。

だからこそ今年は自主勉強エンジニア一年生。

ブログ実装は、8月から始まっていた。

納得する形でデプロイ、リリースできたのが師走である。

*エンジニアのブログ開発、サグラダ・ファミリア説* を僕は推しているが、 *アウトプットのための土壌であるブログをアウトプットできない* というループをさっさと抜け出す必要があった。

当たり前の当たり前だろうが、タスクリストを組んでひとつずつチェックボックスを潰したり、 Issueを立てて実装を勧めていくべきだったなあと反省をしている。

同じアウトプットが同じタイミングでなされるのであれば、一日ずつコミットを刻んでいったほうがGithubの草的にも見栄えがいい。

今、このことに気づけてよかったと思っている。

### やっぱり日記を書く

実はブログとは全く別のフォーマットで日記を書いていた。去年の12月まで。

日記をやめた一年を過ごして、振り返ってみるとある事実と対峙する。

**成長の度合い** が去年までの其れよりも少ないのではないか。

事実、朝起きて日記と一日のTodoを敢えて紙のノートに書く儀式は僕にとっていい影響をもたらしていたのだ。

紙で書くから忘れてはいけない業務も覚えているし、困ったら日記を見ればいい。

今となっては歯磨きのように筋トレを習慣化したが、今思えば日記の助力を借りていた可能性がある。

また始めてみる。

## ふりかえりまとめ

ダラダラと四方山話のように今年一年をふりかえり、来年に向けてむきなおった。

一年のふりかえりを通して、業務で学んだことや悩んだことも年末年始休暇を使ってアウトプットできたらいいなと考えている。



2020年はコロナが世界中を襲い、今までに体験したことがなかったような一年になった。「変化」という言葉はいい意味も悪い意味もある。それはどう転んだとしても、我々は追従する必要がある。自分なりに受け止め変化した一年の集大成をこの記事に纏める。

# エンジニアとしての、2020年の `ふりかえり` と `むきなおり`

主人公の成長ストーリー。鑑賞者が最も興奮を覚え、感情が滾るジャンルのひとつである。

五体満足の主人公が酸鼻を極めるような困難に遭遇し、次々と襲い掛かる試練に乗り越えた後、ハッピーエンドを迎える物語が大抵のものであろう。

つまり、*壱から十* に成長する物語。

だがヴァイオレット・エヴァーガーデンは、そうではない。

マイナスからゼロへ。そしてプラスに成長する物語である。

## 僕らが持っているものを持っていない

初っ端から肉体的・精神的に五体不満足な状態をもって、此の物語の嚆矢こうしとされている。

具体的には以下の通り。

*両腕ともに義手* という不満足は肉体的な不満。

戦争の時、こちらは自分の意志で上司を庇ったことにより失っている。

*喜怒哀楽の感情が理解できない* という不満足が精神的な不満だ。

こちらは 生まれつき持ち合わせていない。

ここの線引は作中でもはっきりしており、ヴァイオレットは義手に関しては特に後悔の念などは抱いていないと思われる。

我々鑑賞者がそれを思い出す時は、彼女が腕を動かしたりタイピングをするときに軋む音を知覚した時だ。

さも当たり前のように義手を覆っている手袋を外し、訝しげに見つめる相手に淡々の経緯を説明する。

対して感情は言うまでもなく、明らかに空虚そのものである。

人らしい感情を持ち合わせていない為に、本作のキーワードである *愛している* がわからない。

持っていて当たり前の、人としての *感情* を持ち合わせていないのだ。

故にマイナススタートであり、成長する姿に僕たち鑑賞者はのめり込む。

## 「書き手紙」という再発明

*愛している* を知ることが本作のメインテーマだとすれば、サブテーマは何だろうを模索すると、僕は *手紙の再発明* が妥当だと考える。

片方のどちらかが欠けても、此の物語は成り立たない。

情報通信・暗号化技術が発達した現代社会において、手紙という通信手段は廃れつつある。

日本のお家芸である年賀状も形だけは残っているものの、受け取り手を想像しながら葉書の背面をデザインするような人は極僅かだろう。

最大限相手に敬意を払い、自分の思いを言の葉に乗せることは、大変で面倒なことだ。

スマホや PC を用いて素早くタイピングができる現代に於いても、*早い* とは言えない。

代筆屋がタイピングを行い、言葉を引き出して完成度を早くして書くにしろ、時間は要する。

だからこそ多大なコストをかける価値を値踏みし、没入する。たかが作られた物語の他人事であっとしても美しいと感じ、陶酔してしまう。

## 手紙の中に生きる人格

手紙が持つ、最も強力な特徴のひとつが *言霊* であると考えられる。なにも宗教的な話を使用ってわけじゃあない。

書き手が死んでいようと、生きていようと関係ない。

様々な理由で読み手に晒すことができない書き手の人間性が、手紙に憑依する。

本編を覗いてみると、そのような場面が散見される。

手紙の中に生きる人格の存在を薄っすらと経験したことがあるからこそ、僕たちは共感し魂を突付かれる。

普段感じることのない、手紙の中の世界で生き続ける他者の一面を感じ取る。

書き手の人間味を味わうことができ、舌を唸らせる。

時代や空間を超えて、在り続けるできるのだ。

## 最後に

大人の階段を登るに連れて、人は素直じゃなくなってしまう。

自分や誰かの体裁や一ミリも役に立たないプライドを守るために小さな嘘を吐くようになる。

そんなご時世だからこそ、正直に本当の自分に向き直って手紙を書くと色々学びがある。

自分自身ですら知らなかった己のすがた。お世話になっている人へ伝えたい想いが零れてくるときもあるだろう。

手紙だからこそ表現できる人格の存在を大切にしたらいい。

ヴァイオレット・エヴァーガーデンを鑑賞して、とても良かった。ただ直向きにその感想を綴りたいと心から思った。エンジニアリングに従事する身として、技術革新に伴って生活の在り方も日に日に変化している。だからこそ歴史を省みたり古の文化を見つめ直すことは、いち人間としての見聞を広げるためにも大いに役立った。そんな手紙にまつわる感想を纏めた。

Volare Viah