遅く帰ってきたわけではないが、うまく眠れなくて3時に寝て7時に起きた。

開発方法論／開発ガイドの更新⌗

今週が開発の谷間の最後の週。毎週いろいろ資料を作ったり、あちこちのドキュメントを更新したりしていた。最後に残ったものの1つ (を2つに分割した) として、うちのプロダクト開発における開発方法論と開発ガイドを仕上げた。開発方法論は開発のマネジメント手法やプロセスの概念などを抽象的な表現で説明したもの。簡単に言えば、アジャイル開発とかスクラムとか、そういった概念の説明やなぜそれが大事なのかの意図や背景を説明したドキュメントになる。当初はこの1つしかなかったのだけど、実際に課題管理システムを使ってイテレーション開発をする具体的な話しと抽象的な話しを一緒に書くのはまとまりが悪いように思えてきた。抽象的な内容と実務に近い内容は分けて書くことにした。

  • 開発方法論: プロダクトで採用している開発方法論の概念をまとめる
  • 開発ガイド: 開発方法論を具体的に実践する方法についてまとめる

例えば、開発ガイドにはマージリクエストの運用について書いてある。どこの会社へ行っても私は次のような「マージリクエストを作成しなくてよいもの」という文章を書いている。

すべての修正にマージリクエストを要求すると開発がとても遅くなる。それは人間が介在するトコロがもっともコストを要求するからである。とくにコミュニケーションコストは開発の中でも最も大きいコストの1つである。レビューしなくてもコミット履歴は誰でも把握できる。修正内容が気になる開発者は自分でコミット履歴を確認すればよい。

従ってレビューの必要がないと想定される修正は直接 main ブランチに push してよい。例えば、軽微な修正は CI/CD の自動化により品質を担保できるように努める。テストを失敗させる修正を push してしまったとしてもデプロイできないために障害を発生させることはない。

この運用は軽微な修正だと思って push したものが不具合を発生させてしまうリスクを許容している。そのときは気付きの学びとして「ごめんなさい」で終わらせる。稀に不具合を発生させることよりも、開発の速度を上げる方を優先する。

カフーツさんイベント⌗

カフーツ13周年Jelly〜カクサク（やりたいこと宣言）第1弾〜 に参加した。私がカフーツさんへ遊びに行ったときに人がたくさんいたことはない。記念イベントだったので参加者多いかな？と思って行ってみた。10人ぐらいいた。参加者の大半は私と同じぐらいか、それ以上の年配の方にみえた。やや年齢層が高め。13年やっているコミュニティなので同じぐらい歳をとったんだと思う。みんなでわいわい話しながら0時前まで飲んでた。ここ行くと基本飲み会w

YOHAKHU というクラフトジンがあってロックと炭酸割りで4-5杯ほど飲んでいた。これまでジンをあまり飲んだことがないので、普通のジンとの比較はできないが、強烈なインパクトのある風味で圧倒されてしまった。おいしいかどうかというよりもこれは強烈やなぁという所感が先にくる。さらに「余白」という名前がよい。いとうさんに影響を受けて私が「ゆとり」と呼んでいた概念にいくつか補強がされて、最近は私も余白という言葉を気に入って使っている。人生に必要な余白を忘れない飲みものがこれだと言えるかもしれない。なんだか酔っ払ったようなコメントになってしまった。