「何かを読む会」はじめます

こんにちは。@junk0612 です。

今回は、ちょっと変わった読書会として「何かを読む会」というのを社内ではじめます、という記事です。

「何かを読む会」とは

「何かを読む会」の内容を一言でまとめると「各自で好きな本を持ち寄って内容を共有する会」でしょうか。

「何かを読む会」では、参加者が各自で読みたいものを設定します。それぞれ自分で内容を読んでまとめ、発表資料を作り、会の時間ではお互いに参加者向けに発表し、感想や質問を共有する、という内容で進める予定です。

普通の読書会との違い

普段、社内でよくやっている読書会は「読む対象とする本を決めて、項目や節ごとに区切って読み進め、内容について議論したり、感想を言い合ったりする」という形式が多いです。「何かを読む会」は、形式的には「読む本を1つに定めず、各自が好きなものを自由なペースで読んで良い」という点が一番大きな違いです。

例えば、社内で行っている読書会には以下のようなものがあります。

blog.agile.esm.co.jp

読書会はそれなりに時間を使うため、あらゆる本を対象にすることはできません。参加者を集めやすくするため必然的に「エンジニアならこれは読んでおけ」と言われる種類の名著に対象は絞られます。「何かを読む会」では、自分が何を読むか決めることで他の参加者の興味に縛られず好きなものを読むことができるというメリットがあります。

また、複数の参加者間で共通理解を形成しながら進む性質上、読書会では他者のペースにある程度合わせることを要求されます。個人的にはさらっと流したいところがあったり、逆になかなか理解が追いつかず他の参加者に申し訳ない気持ちになったりすることもあります。これも「何かを読む会」では、個人でそれぞれ読み進めるためわかりやすいところはさっと流し、わかりにくいところにじっくり時間を掛けることができます。

一人での読書との違い

一方で、「何かを読む会」は読書会という性質も持っているため、一人での読書とは「読んだ内容をまとめて持ち寄り、発表し合うことで共有する」という点が異なります。

他者に説明することで自分の中での理解が深まった経験は誰しも持っていると思います。「何かを読む会」においても、説明する参加者は発表資料を作り説明する過程で、内容に対する理解を深められることが期待できます。

また、聞く側の参加者にも読んでいない本の内容を聞くことでそれを読んだつもりになれるというわかりやすいメリットがあります。

終わりに

ということで、ちょっと変わった読書会をはじめます、という記事でした。今後月1のペースで開催していこうとしているので、しばらくしたら経過内容を記事にできるといいなと思っています。

リモートワークスタイルチェックをやってみた (永和システムマネジメント アジャイル事業部の場合)

エンジニアリングマネージャーの @koic です。富山Ruby会議01の主催者でもあった @mugi_uno さんがまとめられたリモートワークスタイルチェックを行ってみました。

ここ最近やった何件かのカジュアル面談を通して、"リモートワーク" のスタイルの認識に企業・個人によって大きく差がある印象を受けたので、ミスマッチを防ぐためにチェックリスト的なものを作ってみました（こういう観点もあるよ〜とかあれば知りたい）https://t.co/1faTEwNzKB

— mugi (@mugi_uno) 2022年3月22日

受託開発企業である弊社アジャイル事業部でのリモートワークのチェックリストとなります。サービス企業でない受託開発企業の、ひとつのリモートワーク度合いとしてご参考ください。それでは見ていきましょう。

リモートワーク比重度

リモートワークの導入期間

どの程度リモートワークを導入しているか (≒ 組織としてのリモートワークへの慣れ)

👉「5: 継続してリモートワークを5年以上導入している」

COVID-19 以前から、首都圏在住のメンバーはリモート (当時の呼称は「在宅勤務」) と出社を使い分けており、さらに一部メンバーは富山県、石川県、宮崎県でのリモートワークでした。現在は全員がフルリモートとなっています。

リモートワークの導入ポリシー

リモートワークを一時的なものとして導入しているか、恒久的に取り扱うか。 また、内容の変更がどの程度ありうるか。

👉「3: 恒久的な導入だが、根本的な制度変更が行われる可能性はある」

アジャイル事業部として、リモートワークの権限はおそらく恒久的な導入になる見立てです。ただし、感染状況に応じて出社を選択肢に含むことができるのが現状であり、それは継続した選択肢として残りそうです。このあたりは、社員として時代にあわせた働きやすさを考慮しつつの制度として調整中です。

リモートワークのマジョリティ度合い

全メンバーのうちどの程度がリモートワークに関わっているか。 リモートワークの課題が全員のものとなるか、「リモートワークのひと」の課題となるかの違いがある。

👉「4: 全員が常にリモートワークの可能性がある（出社している可能性もある）」

開発に関してほぼリモートワークですが、バックオフィスのメンバーなど稀に出社しているときがあります。

申請・許可の必要性

リモートワークを行うために何らかの手続きが発生するかどうか。 また、申請が必要な場合にはどの程度の頻度で申請を行う必要があるか。

👉「5: 申請や許可は必要ない」

リモートワークを前提としているため、申請不要です。

リモートワークの適用範囲

リモートワークが利用可能なのは誰か。

👉「5: 業務に関わる全メンバー（正社員以外も含む）がリモートワークを利用できる」

COVID-19 によるリモートワーク以前は一定職位以上のみがリモートワークの権限がありましたが、現在はすべてのメンバーにその権限があります。

出社義務

業務上必須とされる出社がどの程度発生するか。 「義務」としての出社のみ数える。出社が伴うイベントだとしても個々の判断で出社せずにオンライン参加が可能なケースなどは含めない。

👉「5: 出社義務は無い」

原則として出社の「義務」はありませんが、業務上、自己判断で出社を選択できるようになっています。

リモートワークで必要なサービス・アプリケーションの取り扱い

リモートワーク・非リモートワークで利用するサービス・アプリケーションに差異があるか。

👉「4: 業務で利用するサービス・アプリケーションは主にリモートワークを前提としている。一部リモートワークでは利用できないものがあるが、リモートワーク前提のものに移行中・または移行予定がある、あるいは何らかの代替手段によってすべて解決できる。」

原則として、すべてリモートワークで行えるため、事実上は「5」にできるかもしれません。ただ、一部クラウド移行できないものに関して稀に出社対応するメンバーがいるため「4」としています。

情報のアクセス範囲

リモートワーク時と非リモートワーク時に、アクセス可能な情報量にどの程度差があるか。 また、差がある場合にはそれをカバーする手段が用意されているかどうか。

👉「5: リモートワーク・非リモートワークでアクセスできる情報に差はない」

原則として開発メンバーが関わるものは、リモートワーク前提でアクセスできるため、情報に差はありません。

その他

その他リモートワークに関する制度や特徴的な情報など

• ✔︎社内において一定の権限を持つ人物（役員など）がリモートワークを実践している
• ✔︎5,000円/月以上のリモートワークに関する手当がある
• ❌オフィスが存在しない
• ❌対外的にリモートワークに関する発信・発表を積極的に行なっている

アジャイル事業部では事業部長以下、すべてのメンバーが原則としてリモートワークです。また全社としてリモートワーカーには在宅手当が毎月一律付与されているほか、アジャイル事業部では別途リモートワーク環境を整備するための予算を設けています。

リモートワークの文化

同期・非同期コミュニーションの割合

コミュニケーションが伴う業務において、同期・非同期のコミュニケーションはどういった割合か。

👉「B: 非同期コミュニケーションが中心だが、一部で同期的なコミュニケーションが必要」

プロジェクトによりますが打ち合わせやブリーフィングなどは同期的コミュニケーション、それ以外は非同期コミュニケーションが中心です。また社内行事や勉強会は同期的なコミュニケーションです。

テキストコミュニケーションの割合

リモートワークでのコミュニケーション方法において、テキストが占める割合はどの程度か

👉「B: テキストが主で、補助的にビデオ通話・音声通話を用いる」

前の設問に近いですが、非同期的コミュニケーションは Slack や GitHub、同期的コミュニケーションは各種ビデオツールや Slack のハドルなどが使われることが多いです。

コミュニケーション頻度

リモートワーク時に、どの程度他のメンバーとコミュニケーションを取るか （テキスト・ビデオなどの手段は問いません）

👉「B: ミーティングに加え、それ以外でも日々活発にコミュニケーションを取る。雑談もそこそこ。」

朝会、夕会以外でプロジェクトを横断した同期コミュニケーションでの勉強会や、非同期コミュニケーションでの Slack チャットなど使われることがあります。

働く時間

リモートワークで働くにあたって、どういった時間帯に仕事をするか。 これによって同期・非同期の割合が決まったり、非同期の場合もレスポンス速度が変わってくる。

👉「B: 全員働く時間は定まっていないが、コアタイムなどで重なる時間が存在する」

作業の開始時間はプロジェクトと調整する形でコアタイムの中で個人に委ねられます。概ね日中の時間帯はメンバーとのコンタクトがつきます。

スタイルチェックを行ってみて

いかがだったでしょうか？想定外にリモートワークできている印象かもしれません。これは、私たちがお仕事でも繋がらせていただいている Ruby コミュニティの企業はリモートワークが進んでいることで、弊事業部も事実上のフルリモートワーク化が実現できていると思います (リモートワークを推進していただいている皆様に感謝！) 。そして、@mugi_uno さんによるチェックリストは現在のリモートワークへの良いふりかえりの機会になりました。この記事が弊社をより知っていただくきっかけになれば幸いです。

リモートワークスタイルチェック用サービスを使った結果 (2022年5月19日追記)

@mugi_uno さんが公開された「リモートワークスタイルチェック用サービス」を行ってみました (公開ありがとうございます！) 。

mugi1.hateblo.jp

結果画像は以下になります。

---

このように永和システムマネジメント アジャイル事業部では、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいリモートワーカーのエンジニアを絶賛募集しています。

agile.esm.co.jp

全レコードのバリデーションをチェックするgemを作った話

こんにちは @color_box です。 仕事からアイディアを得てgemを作ったのでそれについて書きます。

rspec-all_records_validator

github.com

rspec-all_records_validator というgemを作りました。DB内の全レコードに対してvalidationを実行するgemです。

これを導入するとある種のバグをE2Eテストで検出可能になります。RailsとRSpecが入っているプロジェクトを前提としています。

作った背景

仕事で遭遇したとあるバグが、このgemを作成した背景にあります。

Active Recordのバリデーションにおいて、関連の個数を確認するようなバリデーションはすり抜けの可能性があります。

例として下記のようなクラスを仮定します。Humanオブジェクトはdogを一つ以上関連として持つべき、というバリデーションが設定されています。

class Human < ApplicationRecord
  has_many :dogs
  validates :dogs, length: {minimum: 1}
end

class Dog < ApplicationRecord
  belongs_to :human
end

この時、下記のようなコードを実行するとbreederのレコードはinvalidになります。

dog = Dog.new
breeder = Human.create!(dogs: [dog])

dog.reload
=> #<Dog id: 1, human_id: 1>

dog_owner = Human.new
dog_owner.dogs = breeder.dogs
dog_owner.save!

dog.reload
=> #<Dog id: 1, human_id: 2>

breeder.reload.invalid?
=> true

breederからdog_ownerへdogsオブジェクトが移動してしまっており、breederはdogsを持たなくなるためinvalidになります。 invalid であるにも関わらずbreederのvalidationは実行されないためそれに気づけません。

基本的にDBの中に永続化されているレコードは全てvalidであるはずなので、このようにinvalidなデータがDBに残り続けると別の箇所でバグを発生させます。

テスト実行後にバリデーションを実行できると、このような状況を防ぐことが可能です。rspec_all_record_validatorはそのようなバリデーション実行を簡易に追加できるgemです。E2Eテスト終了時、全レコードのvalidationをチェックすることでこの手のバグを検知しています。

ただ、E2Eテストの実行後に全てのレコードのvalidationを実行するため、当然ビルド時間が増えます。そういった課題は今後改善していければと思います。

まとめ

今回、仕事での気づきを元に作成したgemについて、その背景や作った理由などを書かせていただきました、この記事やgemがどなたかのお仕事の役に立てば幸いです。

Named pipe でコンテナ越しにお手軽プロセス間通信?

本日の TIL は、コンテナ間でデータをやりとりするために名前付きパイプ (named pipe, FIFO) を使ってみたことでわかった利点と注意点です。

先日、ある PoC のための簡単な web アプリケーションを作っている際に、2つのコンテナ間でちょっとしたデータのやりとりをしたい場面がありました。具体的には下の図のように、 ブラウザから入力されたテキストを web のコンテナで受け取り、それを別のコンテナ (仮に processor とします) に投げて処理させ、その結果を受け取り、最後にブラウザに表示する必要があります。

web と processor でのやりとりをどう実装するか少し検討してみた結果、名前付きパイプを使ってみることにしました。なぜなら、今回の用途には十分に感じられ、かつ簡単に実装できそうだったからです。ただし、もしこれが production 環境で向こう何年か動き続けるものだとしたら話は変わってきそうです。お手軽さを選択してみることができた背景には、このアプリケーションが主にプロジェクトメンバー達のラップトップ上で動く試作品で、通信方法もこのときの主眼ではなかったという点がありました。

そういうわけで実際に名前付きパイプを使ってみたところ、結論としては、確かにこの方法は簡単でした。また、シェルだけで実装できるため、実行環境に追加のソフトウェアをインストールする手間も不要という手軽さでした。しかし一方で、簡素な仕組みであるゆえに、少しでもデータのやりとりが複雑なものになると、より高級な既存のプロトコル (HTTP など) を採用する場合とくらべて、必ずしも手軽とは言いきれないということがわかりました。また、パイプを使う上での特有の注意点も見えてきました。

ここからは、より具体的な説明をするために、実際に動く例を使ってみたいと思います。その中で、この方法の注意点にも触れていきたいと思います。

どう実装したか

話を簡単にするために、冒頭の processor でやっていた実際のテキスト処理を、記事向けにスペルチェックツール aspell(1) で置き換えたサンプルアプリケーションを作ってみました。ブラウザから見ると「入力したテキストを submit したら、スペルチェックされた結果が画面に表示される」という動作になります。処理の流れは冒頭の図の通りです。

名前付きパイプを使っての web と processor との間のデータの流れは次のようなイメージです。図のように、input/output それぞれにひとつずつパイプを使います。

実装に必要なのは次の4つのファイルです。

$ tree
.
├── docker-compose.yml 
├── processor
│   └── worker.sh
└── web
    ├── index.html
    └── server.rb

2 directories, 4 files

2つのコンテナ (web と processor) は Docker Compose で管理します。以下の docker-compose.yml に、各コンテナや volume の情報などを設定します。

x-env: &env
  - PROC_INPUT=/var/run/sample/proc-in
  - PROC_OUTPUT=/var/run/sample/proc-out
  - PROC_LOCK=/var/run/sample/proc.lock

volumes:
  ipc:

services:
  web:
    image: ruby:3.1-slim
    ports: ['4567:4567']
    init: true
    working_dir: /work
    environment: *env
    command: ['ruby', 'server.rb']
    volumes:
      - type: volume
        source: ipc
        target: /var/run/sample
      - type: bind
        source: ./web
        target: /work

  processor:
    image: r.j3ss.co/aspell
    init: true
    working_dir: /work
    environment: *env
    entrypoint: ['/bin/ash']
    command: ['/work/worker.sh']
    volumes:
      - type: volume
        source: ipc
        target: /var/run/sample
      - type: bind
        source: ./processor
        target: /work

名前付きパイプではファイルを読み書きする要領で通信ができるので、シェルさえあれば実装できます。コンテナ間でやりとりする場合は、名前付きパイプの共有をどうするかを考える必要が出てきますが、実は普通のファイルと同様に volume で共有できます。上記では、そのために定義した volume ipc を各コンテナの /var/run/sample に配置しています。また、名前付きパイプのファイルパスなどを環境変数として定義しています。それぞれ次の用途です。

• PROC_INPUT: 入力用の名前付きパイプ。
• PROC_OUTPUT: 出力用の名前付きパイプ。
• PROC_LOCK: 排他制御 (後述) に使うための普通の空ファイル。

それでは各実装について、入力から出力まで処理の流れに沿って見ていきましょう。web 側は Sinatra で実装しました。 index.html は POST /process にテキストを投げるためのフォームです (ここでは省略します; gist)。

require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'
  gem 'sinatra'
  gem 'webrick'
end

set :static, true
set :public_folder, __dir__
set :bind, '0.0.0.0'

get '/' do
  content_type 'text/html'
  send_file File.join(settings.public_folder, 'index.html')
end

post '/process' do
  content_type 'text/plain'

  File.open ENV['PROC_LOCK'] do |lock|
    lock.flock File::LOCK_EX

    output = Thread.new { File.read(ENV['PROC_OUTPUT']) }
    File.write ENV['PROC_INPUT'], request.body.read

    output.value
  end
end

Sinatra::Application.run!

post '/process' のブロックで、次のような流れでパイプへの読み書きをしてブラウザにレスポンスを返しています。

1. 出力用パイプから読み込みを別スレッドで開始。
2. 入力用ファイルにテキストをすべて書き込む。

入力を書き込む前に出力を別スレッドで読み始めているのは、大きなテキストを渡す際に書き込みが止まってしまうことを防ぐための対応です。というのも、パイプには容量があり、その容量を超えるサイズのテキストを書き込むことはできません (ブロックするかエラーになる)。そのため、書き込みと同時に出力側からの読み出しも行なうことで、データの流れが止まらないようにしています。

また念のため、入力の書き込みから出力の読み込みまでの間に別のリクエストからの邪魔が入ることがないよう、IO#flock で排他制御をしています。ロック取得のために (入力用/出力用のパイプではなく) わざわざ別ファイルを使っているのは次のような理由で、名前付きパイプの特性上ロックの用途には使いづらいと判断したためです。

• 入力用のパイプに流したデータの末尾 (EOF) を読み出し側に知らせるには、書き込み側でファイルを閉じるという操作が必要。しかし、ファイルを閉じるということはロックも手放してしまうことになる。ロックは出力用のパイプを読み終わるまで手放したくない。
• 出力用のパイプを読み込むために開くには、書き込み側からもファイルを開く必要がある。しかし、ロックを取得したいタイミングは書き込み側がファイルを開くより前。

さて、上記でパイプへ書き込まれたテキストは、processor が worker.sh で読み込みます。そのテキストを入力として aspell を実行し、結果を出力用のパイプに書き込みます。

#!/bin/bash

set -e
test -p "$PROC_INPUT" || mkfifo "$PROC_INPUT"
test -p "$PROC_OUTPUT" || mkfifo "$PROC_OUTPUT"
test -f "$PROC_LOCK" || touch "$PROC_LOCK"

set +e
while :
do
  echo "Waiting input..."
  aspell -a < "$PROC_INPUT" > "$PROC_OUTPUT"
done

最初のあたりでは、各ファイルがまだ存在しなければ作成しています。あとはパイプに入力がある度に aspell をひたすら繰り返すだけです。

これで一通り準備ができました。起動してブラウザからテキストを送ると、期待した通り、スペルチェック結果が確認できます。ブラウザのスペルチェッカも反応しており、正しそうです。

どんな問題があるか

名前付きパイプを使うことで、サーバ側の実装をほぼシェルだけでお手軽に済ませることができました。簡単な仕組みで、手間もかからず、うまく動いています。しかし、この方法には少なくともひとつ潜在的な問題がありました。それは、現状では標準入出力のやりとりしかできないという点です。たとえば aspell の実行途中にエラーが発生し異常終了したとしても、この仕組みでは終了ステータスを受け取る方法がないので、気づくことができません。また、標準エラー出力に何かエラーが出ている場合も、出力用のパイプに流しているのは標準出力だけなので、web からはわかりません。

ここからもし標準入出力以外のデータをやりとりしたくなった場合には、そのための仕組みを用意する必要があります。例えば、出力用のパイプを増やせば終了ステータスや標準エラー出力も受け取れるようになります。または、パイプでやりとりするデータを単なるバイトストリームではなく、JSON のような構造化された形にすることでも対応はできそうです。とはいえ、もともとお手軽さを求めて選んだ方法が、こうなってくるとあまりお手軽に感じられなくなってきました。むしろ、 Sinatra か Flask でも入れて HTTP でやりとりした方がまだ楽かもしれません。

また、この仕組みのまま時間あたりの処理能力を上げることが難しいという点も、用途によっては問題となりそうです。現状では、外部コマンドの実行という比較的コストの高い処理をひとつずつ順番に実行しているからです。もしこれを parallel に複数実行できれば処理能力を上げることはできそうですが、その場合もやはり、現状よりも複雑になることは避けられません。

おわりに

今回わかったことは大きく分けて2つです。

• 名前付きパイプはちょっとした通信をお手軽に実装する手段として便利。ただし、やりとりが少しでも複雑になると相応の手数が必要になる。
• 名前付きパイプは普通のファイルと似ているが、使い方にコツがある。
  • パイプには容量があり、流れないと詰まる。
  • データの末尾 (EOF) を読み込み側に知らせるには、書き込み側がファイルを閉じる必要がある。
  • パイプを開くには、反対側からも開く必要がある。

使い方が分かってしまえばお手軽な半面、複雑なことは自前でやる必要があるので大変。だから先が読めない状況では、はじめからより高級な既存のプロトコルを使った方がいいというのが今回の感想です。

参考

• https://man7.org/linux/man-pages/man7/pipe.7.html
• https://linux.die.net/man/1/aspell
• https://linux.die.net/man/3/open
• https://www.lexico.com/grammar/common-misspellings
• https://unix.stackexchange.com/questions/68146/what-are-guarantees-for-concurrent-writes-into-a-named-pipe
• https://stackoverflow.com/questions/4624071/pipe-buffer-size-is-4k-or-64k

技術書（英語）読書会を継続している話

はじめに

こんにちは、エンジニアの 9sako6 です。

昨年の夏に社内で Patterns of Enterprise Application Architecture（以下、PofEAA と呼ぶ）を読む読書会が発足し、かれこれ半年以上継続しています。

本記事では、PofEAA 読書会の沿革や、主催としての学びをつづります。

動機

私はおそらく PofEAA という本を Martin Fowler's Bliki (ja) で知りました。PofEAA の著者 Martin Fowler 氏のブログを日本語化したサイトです。

"Patterns of Enterprise Application Architecture" というタイトルにある、"Enterprise" や "Architecture" という単語に惹かれました。 当時、エンタープライズアプリケーション特有の問題や解決策に興味があったのです。私は学生時代に競技プログラミングをかじっていましたが、エンタープライズアプリケーションでは競プロのプラクティスが通じないことがあったからです（永続化の必要性や、ハードウェア・ミドルウェアの性能などによるボトルネックの違い）。

とはいえ1人で読んで理解できるかわからないのと、途中で挫けそうな懸念があったので、複数人で読み進めたいと思いました。弊社では業務時間内の勉強会開催が認められているので、読書会を立ち上げることにしました。

PofEAA についてもう少し知りたい方は、高橋征義さんのレビューが参考になると思います。

NTTコムウェア C+ | ITジャーナリストや現役書店員、編集者が選ぶ デジタル人材のためのブックレビュー 第5回：『エリック・エヴァンスのドメイン駆動設計』、『エンタープライズアプリケーションアーキテクチャパターン』

読書会の方針

社内でお声がけして、PofEAA 読書会に興味を持ってくださった数人で集まって進め方を決めました。

読書会を開催するにあたり、私は2つの理念を持っていました。

1. 負担が少ない
   • 私たちの知識欲と好奇心はとどまることを知らず、学ぶべき事象はいくらでもあります。そんな中で読書会の負担が大きいとなると、他に学びたいことややりたいことができなくなってしまいます。
2. 人が集まる利点が活きる
   • 1人で読むより有益な体験をしたいと思っていました。わからない点について教えあったり、議論できる場を作りたかったです。

2つのお気持ちを共有した上で全員で議論し、読書会は以下のタイムスケジュールで進めることになりました。開催頻度は週に1回、1時間です。

時間	やること	説明
5分	チェックイン	雑談による、しゃべりのウォーミングアップ
15分	読書	読む。発表に備える
20分	発表と議論と質疑応答	ランダムで選ばれたどなたかに読んだ範囲について説明してもらう。要はどういう内容だったのかを説明してほしい。議論や質疑応答も適宜やっていく
5分	次回の計画立て
(15分)	バッファ	早く終わるでもよし、どこかに割り振るでもよし、次に進むでもよし

• その他ルール
  • オンラインで集まる（音声通話）
  • 英語の勉強をしたいわけではないので、翻訳ツールをガンガン使っていい
  • 途中参加、途中退出大歓迎。聞くだけの参加も大歓迎
  • 毎回議事録（学びや議論内容を簡単にまとめたもの）を共同編集で作る
  • 読書会後はできるだけ議事録にひとことコメントする
• ツール
  • 集まる場所：Google Meet
  • 議事録：esa

この進め方は、DMM さんの技術書の輪読会を定着させるまでの道のりで学んだこと記事にて紹介されている「その場で読んで、まとめて、発表するスタイル」にインスパイアされたものです。事前に読んだり準備する必要がないため、負担が少なくなっています。

始動から半年経って、ふりかえり

進め方を決めて、半年ほど特に問題なく読み進められました。 複数のメンバーが毎回参加してくれたこと、議論ができたこと、議事録に学びが残されたこと、解説役として koic さんが参加してくださったことが大きかったです。

PofEAA の章立ては以下のようになっており、この時点で "PART 1: The Narratives" の "Chapter 2" まで読み終えていました。

• Preface
• Introduction
• PART 1: The Narratives
  • Chapter 1-Chapter 8
• PART 2: The Patterns
  • Chapter 9-Chapter 18

いい機会だと思い、Google の Jamboard でふりかえりを行いました。画像はそのときのボードです。

ふりかえりボード

Keep

議論することで理解が促進されたといった意見が出ました。最初の私のお気持ち通り、複数人で集まる利点が活かされたようでした。

• 参加負荷がそこまで高くないので継続しやすい
• 当初の思惑どおり負荷なく参加できている
• koic さんの背景解説助かる
• よくわからない点について、他メンバからの補足やヒント、議論をもらえてソロで読むよりも解像度高く読めていそう
• 一人で読むと難しい内容だけど、みんなでこうじゃないかとか考えたり、解説してもらえることである程度理解できている
• 参加メンバーによる解説・議論が理解のたすけになっている
• マイペースで読んで読み終わったら、気になる部分を読み返したり、気になった周辺の調べ物をできたりするので、良い感じで同期/非同期で進めている感がある。
• 内容が難しいので、各自読んだ後に誰かに要約してもらえる形式が議論が進んでよい感じ
• ポストRailsの世界を生きる私にとって新鮮で面白い
• ディスカッションによる気づき
• みんな英文書読んでいてすごい。
• 現代の翻訳テクノロジーがすばらしい
• 難しい書籍コンテンツである中、きちんと継続されている
• 議事録っぽく書かれていて、感想も書かれており、足跡が残っていてよい

Problem

英語と内容の難しさが挙げられました。

• 英語ワカラナイ
• 実質英語版で読めていない！*1
• 用語だけ先に出てくることが多いので、理解してない部分がわりとある
• パターンの説明？使い所？について読んでいるが、パターン自体の説明（カタログ）は後ろの方に記載されているので、理解しづらい
• そろそろ、Google翻訳力が尽きてしまう。。。
• 難しい箇所を読むと要約に時間が必要になる
• 地の (英) 文によるファウラー節をスキップしてしまって、著者の言葉の選び方のニュアンスを味わえていない
• 最近の現場での設計思想について Active Record の影響が大きいため、理解に戸惑うことがある。
• RailsのActiveRecordと書籍内のActiveRecordを混同して混乱しがち
• 参加メンバーが増えなかった
• (良くも悪くも？) 固定メンバー化している
• 読んだ場所の難易度によっては議論時に沈黙で無の時間がすぎる
• 背景とか脱線した話で、説明が長くなってしまう時がある (自戒を込めて)

Try

3つの Try があがりました。

和じゃなど、人目のある場所でやってみて、入り口を開放する(旧リアル和じゃっぽく)

参加メンバーが増えなかったことに対する Try です。 「和じゃ」はアジャイル事業部メンバーが集まっている Slack の雑談チャンネルです。 「やってる感」を出して興味を惹くため、人目に付くハドルで開催することにしました。

無の時間が思考中なのか本当になにもわからんなのか発言して表明する(例:「これよくわかんないっすね〜」)

オンライン特有の問題に対する Try です。 議論中、たまにみんなが無言の時間がうまれます。音声通話をしているので、無言になるとやりとりされる情報が0になります。

「よくわかんない」などでいいので、適宜お気持ちを flush しようということになりました。

わからない部分がでてきたら、解説部分に派生して時間をとってみんなで読んでみる

内容の難しさに対する Try です。 PofEAA は PART I と PART II にわかれており、PART I にはパターンの概要、PART II にはパターンの詳細が書かれていることがあります。 PART I を読んでいる現在、概要だけでは理解しにくい部分があります。そういう場面で、理解を優先して PART II の詳細な説明をみんなで読みにいくことにしました。

読書会の現在の形

ふりかえりを経て、今はこの進め方で読書会を行なっています。

時間	やること	説明
15分	読書	読む。発表に備える
35分	発表と議論と質疑応答	ランダムで選ばれたどなたかに読んだ範囲について説明してもらう。要はどういう内容だったのかを説明してほしい。議論や質疑応答も適宜やっていく
(10分)	バッファ	早く終わるでもよし、どこかに割り振るでもよし、次に進むでもよし

• その他ルール
  • オンラインで集まる（音声通話）
  • 英語の勉強をしたいわけではないので、翻訳ツールをガンガン使っていい
  • 途中参加、途中退出大歓迎。聞くだけの参加も大歓迎
  • 毎回議事録（学びや議論内容を簡単にまとめたもの）を共同編集で作る
  • 読書会後はできるだけ議事録にひとことコメントする
  • 無の時間が思考中なのか本当になにもわからんなのか発言して表明する(例:「これよくわかんないっすね〜」) ← New!
  • わからない部分がでてきたら、解説部分に派生して時間をとってみんなで読んでみる ← New!
• ツール
  • 集まる場所：Slack 「和じゃ」（人が多い）チャンネルのハドル ← New!
  • 議事録：esa

主催して得た Tips

PofEAA の知識

いわずもがな、PofEAA を読むことで エンターブライズアプリケーション特有の問題や特徴、Layring、Domain Logic、DB とオブジェクトのマッピング等の知識が増えました。 PofEAA は例に出される内容が古い場合があるのですが、歴史を学んで温故知新という気持ちで読んでいます。

読書会をプロダクト（生産物）として育てる意識

私はツールや Web サービスを作るのが好きなのですが、読書会も同じように自分のプロダクトと見なせます。 読書会自体が価値となるように、また、読書会を通して価値を与えたいという思いで運営するようになりました。

おわりに

参加者がいる限り、これからも読書会を継続していきます。

---

永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。

agile.esm.co.jp

*1:メンバーによっては、日本語版を購入して英語版とあわせて読んでいます

Rails / OSS パッチ会オンライン 2022年3月のお知らせ

2022年3月の Rails / OSS パッチ会を 3月14日(月)に Discord でオンライン開催します。

この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS について、upstream にパッチを送る会です。

会には Ruby と Rails のコミッターである顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。

開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。

Discord の Rails/OSS パッチ会サーバーへの招待 URL は以下です👇

discord.gg

以下、前回の活動が関わる成果です。

koic: Rails

github.com

これからパッチ会に参加してみようという方も、ぜひどうぞ。Discord でお会いしましょう。

---

永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。

agile.esm.co.jp

【入社エントリ】はじめまして！ふーがと申します。

はじめに

はじめまして！ふーが(@fugakkbn)と申します。2022年3月1日に中途入社しました。
蒙古タンメン中本、餃子、コカコーラをこよなく愛する光の戦士です。どうぞよろしくお願いします。

入社エントリということで、僕がどのような想いで永和に入社し、実際に入社してみてどう感じているのかを書きたいと思います。永和の雰囲気が少しでも伝われば幸いです。

外から見た永和

僕が永和に抱いていた印象はおおむね次の3点です。このような点に魅力を感じて、永和に入りたい！と思っていました。
面接のときも似たようなことを言ったと思います(緊張しすぎて記憶がない…)。

技術力が高い / 技術が好き な人が多い

ブログの内容や登壇資料、周囲からの評判もあり、印象として1番強く持っていました。
僕自身も Ruby をはじめとした技術が大好きですし、技術者としてやっていくからには追求していきたいという想いがあります。
永和のような熱量のある環境に身を置けたらたくさんの刺激を受けられそう、と感じました。

コミュニティとの親和性が高い

これは何のデータにも基づかない勝手な持論で恐縮ですが、コミュニティの活性度と言語自体の盛衰には一定の相関があると考えています。
コミュニティを盛り上げることで Ruby の発展に貢献できたら嬉しいですし、Ruby が好きなので個人としても会社としても貢献できたらとても幸せです。

その点、イベントへの登壇や協賛をはじめ、メンバーのイベント参加を会社の制度として促している永和でなら、前述のような貢献ができそうで素敵だなと感じていました。

価値の提供

僕は"課題解決のためにどうすべきか"を考えられるエンジニアでありたいです。
なにかを作りきったという達成感も嬉しいものですが、それ以上に、お客様の「ありがとう」という一言でこの上なくやりがいを感じられると思います。

永和のホームページには「私たちのやり方」というページがあります。
ここを読むと、永和でならとてもやりがいを感じられる仕事ができるのではないかと思えて、魅力的でした。

中から見て感じる永和

そんな想いで入社して1週間余り。
「永和に入ってよかったなあ」と感じることばかりです。具体的に書いていきます。

議論が活発

この1週間でお茶会*1や開発者ブログのふりかえり会などに参加しました。また、Slackもやり取りが活発です。技術的な面でも事業部としての運営面でも、活発な議論がなされています。
議論の仕方も感情面や主観でなく「こういう理由でこうしたい」といった理論的な議論ですし、みんなで問題解決していこうという雰囲気が素敵です。

日々KAIZENが進んでいる

ドキュメントやマニュアルも、情報が古くなったり現状に即していないと役に立たなくなってしまいます。また組織としての運営も仕組みで解決できる場合がありますね。

そういった部分を"気付いたらやる"という感じでどんどんKAIZENされていっている印象を受けています。
スピード感にぜんぜん付いていけてないのですが、僕も気づいたこと・できることを積極的にやっていくことで貢献できればと思っています。

仲間を大切にしている

これは外からはあまり見て取れなかった部分ですが、チームの垣根を越えてメンバー同士のコミュニケーションを大切にしていると感じます。
例えば times*2 で何気なく疑問をつぶやくとアドバイスが集まったり、誰かのアクションをいいね！と思ったらお礼を言ったり褒めたりする文化があります。僕のちょっとしたアクションにもお礼を言ってもらえたりして、すごく嬉しかったです。

こういう文化があるとアクションを起こしやすかったりアイディアを出しやすいです。
永和はいわゆる"心理的安全性"の高い環境だと思うので、僕も積極的に前向きなフィードバックをしていこうと思います。

これからのこと

入社して日が浅いにもかかわらず、「すごいなあ」「素敵だなあ」と思うことがたくさんあります。外から見た永和の魅力だけでなく、入社してからもたくさんの魅力を感じています。
入社したばかりの僕だからこそ気づける"外から見えていない永和の魅力"みたいなものをうまく発信していけたらいいなと思います。

そして何より、これからどんなお客様、サービスや技術と関わっていけるのだろうととてもワクワクしています！
1つ1つの関わりを大切にしながら腕をみがき、楽しい"永和ライフ"を過ごしていけたら最高です。

最後までお読みいただきありがとうございます。
改めて、これからよろしくお願いします！

*1:各人が持ち寄った技術的トピックについてゆるく話す会

*2:分報。Slackに個人のチャンネルがある。