日記

なんとなくなにか書きたくなったので書く。

何のために生きてるんだろう、みたいなこと。

いや、違う。
別に生きる意味なんてものはないというか、なくていいというか、そういうことはわかっている。と思う。

では、生きるのが嫌になったとかそういうことかというと、そんなこともまったくない。

であれば、何か。

最近アプリで漫画を読む。
Twitterで気になったアプリを入れては読んでいるうちに、なんだかんだ10くらいのアプリが入っていて、うち5つくらいは毎日見ている。

漫画を読んでいると、色々な人生があるな、と思う。いや、フィクションだけど。
そして、漫画にはたいてい人と人とのことが書かれていて、人と人とのあいだで、いいことがあったり、悪いことがあったり。
人が何かいいことをしたりなどする。

なんか、たぶんそういう風にありたいんだな。
なんとなくいるのは嫌で。いや、なんとなくいるのがいいという人はもちろんそれはそれでよくて、というか人のことをいいとか悪いとか判断する権利自体ないんだけど。

そうじゃなく、自分は、なんとなくあるのは嫌だと思っている。
たぶん。

つまり、何かしていたい。何かを感じていたい。何かを得ていたい。
そういう感じ。

まあ、たいていの人はそうなのかな。いや、そうでもないかも。
たとえば、何もせずだらだらしてたい、みたいな人もふつうにいる。だから、まあ、そのへん色々と人によって程度の差があるんだろう。

で、自分の話。何かしていたい、感じていたい、得ていたい。

だから、こういう風に何かを書くんだと思う。

昔から、何かを得たり、感じたり。
そしてそのために、ということが多かったけど、何かをしてきた。

世界が美しい場所で、美しいものが多いといいと思っている。
ああ、最近世界が美しい場所じゃなくなってきた、何かそういう風に感じているのかもしれない。

世界とは何か。
私が認識しているもの。私にとって世界だと感じられるもの。私が知っている限りにおける、全宇宙。

大人になったと思う。生物学的というか、社会的というか。その両方かな。
「いい年」だし、肉体的・機能的にも大人といって何の疑いもない状態だと思う。（そこそこ前から）

「社会人経験」をそれなりの年数重ねてきて、なんていうか人並みの社会性とか、生産性とか、そういうものも持っているような気がする。
それは単に、平均的なところと比べて外れ値ではない、程度の意味だけれど。

そろそろ、世界を美しい場所にする頃合いなのかもしれない。

別に、これまでもする気がなかったわけじゃない。
ただ、自分の役割は限られているというか、あくまで自分がしたい範囲でする、そういう風に考えていた。
たとえば音楽を作るとか、短歌を作るとか、プログラムを書くとか（これは仕事でもあるけど）そういうことを、あくまで自分がしたい範囲でしてきた。

世界を相手にしよう、そう意気込んでみたとき、ほとんどただちに自分の無力さを感じる。
結局のところ、私が何かをしたとき、世界がどう変わるか。

たぶん、必要なのはそこをつなぐ何かだ。
一歩も動かずに手の届く範囲で満足するのでもなく、かといって、一人で地球をまるごと動かそうと試みて絶望するのでもなく。

世界の話をするなら避けて通れない（別に避けて通る必要もない）のが、今所属している会社の話だ。
そこでは、「経済情報で、誰もがビジネスを楽しめる世界を作る」ことを目指している。

うん。半分くらいだ。

誰もが楽しめる世界を作る。
これはいい。本当にいい。誰かが楽しめる世界じゃだめだ。楽しめない世界もだめだ。誰もが楽しめる世界じゃなきゃ。

これは本当に、心からそう思う。

では、経済情報で、ビジネスを。これはどうだろうか。
実は、と前置きする必要もないのかもしれないけれど、どちらでもいいと思っている。

つまり、誰もが楽しめる世界であれば、経済情報であっても、ビジネスであっても、なくても、何でもいいと思っている。本心では。
「気象情報で、誰もが短歌を楽しめる世界を作る」。今思いつきで考えたただの（ほとんどナンセンスな）語呂合わせだけれど、直感的には同じくらいはいいと思う。

ビジネス的な実現性とか、具体性とか、そういうのをいったんほっぽっての話ですよ。
念のため。

こういう風に、自分に正直になったほうがいいと思っている。
結局のところ、私に責任を取れるのは私だけだ。だから、私に（そして、私だけに）は、私に正直になる責任がある。

世界を美しいものにするための力の不足を感じているのかもしれない。
いや、本当は不足なんてものはない。勝手にそう設定するからそうなるだけだ。

では、逆に今に生きてみてはどうだろうか。禅というのか。マインドフルネスというのか。
別に、「世界を美しいものにする」という「目的」から逆算する必要はないはずだ。

そもそも、普段からそうしている。
そうしている折に、ふと思考がさまよったから、今この文章を書いている。

一つ思いついたキーワードは、アライメントだ。それから、統合。Authenticityであったり、Integrityだ。
いわゆる「きれいごと」だ。

何かを妥協したくない。あれもほしいし、これもほしい。
別に自分が特別欲張りだとも思っていないけれど。いや、欲張りなのかもしれない。

自分に嘘をつきたくないのだ。何かをごまかしたくない。
これは性分だと思う。自分を限りなく尊重したいし、その裏返しとして他者を限りなく尊重したい。*1

嘘をつくことはある。きれいごと100%でこの世に存在し続けることはできない。*2
ただ、その場合も、嘘をついていることに自覚的でいたいのだと思う、たぶん。

子供の頃、初詣で神社にお参りするとき、「世界が平和になりますように」と願っていた。
今思い返しても、そのときの気持ちに嘘はなかった。

私にとって、世界が平和になるとはどういうことか。
たぶん、今もそれを探しているんだな。

何かをしていたい。
であれば、それを探していればいいのだろう。

世界が美しいものにしたいという思いと、個人の生活を統合できる道を、日々、少しずつ選び続ければいいのだろう。
この文書を書いたことは、その道に沿うものだったと思っている。

*1:自分が尊重される限りにおいて。

*2:たぶん。

2021年のふりかえり

やったこと

3 冊

修正した目標「2 ヶ月に 1 冊以上技術書を読む」について、2021 年に読んだ技術書は 3 冊。*1
修正後の目標に対しても 50% の結果となってしまった。

技術書以外の本であれば、30 冊程度は読んでいる。
まあ、こんなものだと思う。

3 本

修正した目標「3 ヶ月に 1 本以上記事を書く」について、2021 年に書いた記事は（この記事を含めて）3 本。

だいぶ下方修正した目標（そして半分はふりかえりの記事）ではあるが、なんとか達成できた。

ちなみにこの記事、かなり希少性の高い（ここまで具体的にXPチームの働き方を記述したものを僕は見たことない）良記事だと思っているので、もっと読まれてほしい。

enk.hatenablog.com

具体的すぎて、実際に体験した人以外には伝わりづらいのだろうか……？（もっと抽象化、理論化する必要がある？）

翻訳している

『The Great ScrumMaster』（日本語版は『SCRUMMASTER THE BOOK』）の著者である Zuzana Šochová さんが書いた『The Agile Leader』という本の翻訳を進めている。

greatagileleader.com

わかったこと

技術的に急成長しなくなっている？

年初に「1 ヶ月に 1 冊以上技術書を読む（のち、2 ヶ月に 1 冊に変更）」という目標を立てたことが年間 3 冊読む結果につながり、よかったとも言える。
0 よりはずっといい。

この程度の学習ペースでも、技術力の維持はできているかもしれない。
ただ、このペースだとこの先大きな成長はないかな、という感覚もあるのが正直なところで、「もし技術的に大きな成長を目指さないのであれば、では何を目指すのか？」という重要な問いが目の前にあるようだ。

どうすれば、みんな幸せになれる？

今読んでいる『リーダーシップ進化論』という本では、自己組織化という自然の作用によって破滅に向かってしまう人間社会を、どのようなリーダーシップによって救えるか、といった問題意識が語られている。（筋としてはタイトル通りリーダーシップの「進化」の歴史を辿る本だが、通底する問題意識はそこにあるように思える）

www.amazon.co.jp

僕は「みんなが幸せ」になるといいなと昔から思っていて、そのためにはなによりまず自分自身の幸福を確保することだ、と信じているところが大きかった。

この本を読んでいて、僕が組織であったり、リーダーシップといったことに興味があるのは、「みんなが幸せ」になれる道を見つけたいからなのかも、ということに気づいた。
つまり、「自分自身の幸せ」を保ちながらも、「みんなが幸せ」になるように行動できるようになるためのツールが、組織論であったり、リーダーシップなのではないか、ということ。

みんなすごいなあ

ふと見渡してみると、Twitterやブログ、イベントでの発表などで、色々な専門家の発信を目にすることが昔（たとえば10年前）よりもずっと増えたような気がする。
昔よりもITエンジニア自体の数が増えたからかもしれないし、他にも理由があるかもしれない。

みんなすごいな、と思う。
わざわざ外部に目を向けなくても、会社の中にも自分にはできないことができる人が山ほどいる。もちろん昔だっていたんだけど、昔より自分にできることがそれなりに増えた今でも、山ほどいるんだよなあ、という感覚。周りに山が山ほど（山だけに）あって、その山のほとんどには登れずに終わるだろうな、という感覚。

なんかこう、僕もなんかの専門家になろうとか、なった方がいいんじゃないかとか、思わないでもない。登れない山の一つになるというか。
でも一方で、ならなくてもいいんじゃないか、とも思うのだ。

世の中の役に立つものを作りたい、という気持ちは、働くようになってから変わらず一貫してある。
だからそこだけは大事にして、世の中の役に立つものを作れていれば、それでいいんじゃないかなと。

幸いなことに、今のところそれでそれなりに会社というのか、社会というのかからも評価してもらえている。
そうである限りは、これでいいんじゃないかなと思っている。

次にやること

「今までの延長線上にない、なにか」をやる

「今までの延長線上にない、なにか」をやる。
いったんは、もうこれだけでいいかな、と思った。

たぶん、目標で縛らなくても、生きたいように生きられそう、基本的には。
ただ、それだと停滞してしまうかもしれない。（しないかもしれないけど）

今までも、それなりに色々と今までの延長線上にないことをしてきた。
たとえば東京に出てきたり。演劇をやったり。スクラムに取り組んだり。スクラムマスターをやったり、プロダクトオーナーをやったり、デザイナーの真似をしてみたり。（2度）転職したり。関数型言語を学んでみたり。組織の「経営チーム」に参加してみたり。翻訳に取り組んでみたり。

劇的ではないけど、それなりには。この程度でいいから、何かしら新しいこと、今までの延長線上にないなにかには取り組むようにしたい。
1 年に 1 つくらいは、なにか。そうすれば、それなりにいつも新しくいられるだろう。

あとは自由。

*1:実はまだ1冊だが、読みかけの2冊を明日中に読み終える。絶対にだ。

チームフロー

この記事は、Uzabase Advent Calendar 2021の25日目の記事です。
昨日は、sefwgweoさんの「Androidアプリのログが正しく送信されていることを担保する」でした！

---

私たちは、ソフトウェアエンジニアとして、日々チームで成果を届けている。そこには、「（個人の）フロー」ならぬ、「チームフロー」とも呼べるものがあるように思える。
その生活の様子を覗いてみよう。

〜〜〜

朝9:30。チームの4人が集まってきた。

みんな「おはようございま〜す」

いわゆる朝会をやる。

4人それぞれがなにか一言二言喋ってから、共有事項があれば共有する。
ここで質問したり、助けを求めたりすることは少ない。そういう事案が生じたら、いつもその場で解決しているからだ。
だから、朝会はたいてい5分以内、短いときは2分くらいで終わる。

チームのタスクボードに、今やっている仕事と、これからやる仕事が並んでいる。
さっそく、それぞれのペアで何をやるかを決めよう。私たちはいつもペアで仕事をしているので、2つの仕事を選ぶことになる。*1

Aさん「あ、僕このWIP*2のやつやりたいです。Clojure触りたいんで」
Cさん「Bさんどうします？」
Bさん「じゃあ私がそっち入ろうかな」

Aさんがやりたいというので、あとの3人はその意志を尊重することにする。
昨日その仕事に仕掛っていたBさん、Cさんの2人のうち、Bさんがそちらの仕事に残ることにした。

Cさん「おっけ〜」
Dさん「じゃ、僕らはこっちですかね」

ちょうど昨日帰る前に1つの仕事を終えたところだったので、WIPは1つしか残っていなかった。
残されたCさん、Dさんの2人は、次の仕事に取り掛かることにしたのだ。

AさんとBさんが仕掛中の仕事、CさんとDさんは新しい仕事

Cさん「なるほどこれね〜」
Dさん「じゃE2E書いてきますか」
Cさん「ほいー」

仕事は常にテスト駆動開発、アウトサイドインで進めているので、新しい仕事はE2Eテストから始まる。*3
事前の仕事の洗い出しと見積もりはチームでやっているので、だいたいの内容は既に把握できている。

Bさん「今ハンドラからユースケース呼ぶとこまでできてて、ユースケースのテストからって感じです。書いていきますね」
Aさん「了解でっす」

こちらも始まった。
個々のモジュールもやはりテスト駆動開発、アウトサイドインなので、仕事を再開するときはだいたいこういう会話になる。

【10分後】

Bさん「あれ。ネストしたmapの値置き換えたいときってどうするんだっけ？　assoc-in？　update-in？」
Aさん「update-inじゃないですか？　でも自信ないんでClojureDocs見ますか」
Bさん「（見る）んー、この例の(update-in p [:age] inc)ってどういうことなんだっけ……」
Aさん「Cさんに聞いてみますか。Cさ〜ん」

CさんはClojureが得意なので、Cさんに聞けばすぐにわかると思ったのだ。

こんなしょうもないことを聞くのか？　ClojureDocsをちゃんと読めばわかるようなことを。
こんなしょうもないことでも聞く。それがチームの学習とフローを最大化させる、最善の選択肢だと信じているからだ。

Cさん「何？」
Aさん「ネストしたmapの値置き換えるのってupdate-inでしたっけ」
Cさん「そうだよ」

話の内容を耳で半分だけ聞きながら、この間もDさんはE2Eを書き続けている。
ClojureのことならCさんに任せておけば安心だし、DさんもClojureは苦手ではないので、しっかり手を止めてまで聞くほどの内容ではなさそうだと判断したのだ。

Aさん「置き換えたいだけなんですけど、最後の引数がよくわかんなくて」
Cさん「最後の引数は関数だから。元の値を受け取る関数。どういう値で置き換えたいの？」
Aさん「別のmapから取ってきた値で」
Cさん「関数だから、無名関数書けばいいよ。あ、でも、元の値使わないならassoc-inでいいんじゃない」
Aさん「！　あ〜。そういうこと。そっか。完全理解。ありがとうございます」
Bさん「ありがとうございまーす」

この間30秒。
一方のDさんの仕事は少しだけ進んだみたいだ。

Dさん「さっきのアサーション書いてみたんですけど、ちょっと迷ってて……」
Cさん「お〜それね。そうなるよねえ」

Dさんは2人の（Cさんと、Dさんの）仕事のコンテキストを保持し続けているので、Cさんは瞬時に元の仕事に戻ることができた。

こうして、2つのペアの仕事は淀みなく続いていく。

【50分後】

Aさん「っしゃ通った〜い」
Bさん「通りましたね〜」

テスト駆動開発なので、テストが通ったら完了だ*4。CI/CDパイプラインを流して、通ればリリースできる。

終わった仕事の付箋を、タスクボードのDoneのレーンに移動する。

Aさん「休憩しましょう！」
Cさん「おっけ〜」
Dさん「はいー」
Bさん「パイプライン流しときました」
Aさん「では10分後」

だいたい1時間くらいで休憩を入れる。都合よく今やっている仕事が片付いたので、みんな休憩することにした。
Cさん、Dさんの仕事は完全に仕掛り中だが、常にペアはローテーションしていくため休憩後はペアを交代したいので、仕掛り中でも構わず休憩に入る。どちらかは同じ仕事に残れるし、離れた方も近くに座っているからわからないことがあれば聞けばいいので、あまり気にしない。

【10分後】

休憩が終わって、みんなが集まってきた。

Aさん「じゃ、やりますか」
Bさん「次これですかね」
Cさん「そうだね」
Dさん「どうします？」

Aさん、Bさんがフリーになるので、どちらかが新しい仕事に取り掛かり、どちらかはCさん、Dさんがやっていた仕事を引き継ぐことになる。

Cさん「うーん、残りたいかな」

Cさんは仕掛りの仕事を続けたいようだ。

Dさん「いいですよ、じゃあ新しい方やります」
Bさん「お。じゃあ私もそっち行きますね」

Bさんは新しい方の仕事を選んだ。
仕事の内容というよりは、昨日Dさんとペアにならなかったので、Dさんとペアになれる機会を選んだのかもしれない。

Aさん「おっけー。さっきのやつそっちでリリースしてもらえます？」
Bさん「了解です」

先ほどDoneにした仕事のリリースはBさんのペアで担当することにした。
流しておいたパイプライン*5が通ればリリースできるので、パイプラインを確認して、通っていればリリースしてから次の仕事に取り掛かることになる。

AさんとCさんが仕掛中の仕事、BさんとDさんはリリースしてから新しい仕事

こうして2コマ目が始まった。

【20分後】

Eさん「Dさんちょっといいですか？」

別のチームのEさんがやってきた。

Eさん「Kotlinのlistを連続してmapしたときって、都度新しいリストのオブジェクト作られるんでしたっけ」
Dさん「そうですね」
Eさん「あれ、作られないようにするやり方なかったですか？」
Dさん「それやりたかったらasSequence呼びますね。ただ件数がそんなになければ気にしなくていいかなと」
Eさん「あ〜、あったなそういうの。うーんなるほど。件数ってどれくらいかわかります？」
Dさん「昔パフォーマンス見てみたことあって、〇〇件とかなら誤差のレベルだったと思います」
Eさん「なるほど、じゃあ大丈夫ですね。ありがとうございます〜」

この間やはり30秒。

EさんはDさんがKotlinに詳しいことを知っていて、別のチームから聞きにきた。
この間も、Bさんは2人の（Dさんと、Bさんの）仕事を進めている。

最初にチームの4人と言ったが、実は、他のチームのメンバーも同じチームという意識で仕事をしている。
だから、当然のようにちょっとしたことを聞きに来たり、聞きに行ったりする。それがチームの学習とフローを最大化させる、最善の選択肢だと信じているからだ。

【同じ頃】

Aさん「あれ、この値ってそもそもどういう範囲を取るんですっけ」
Cさん「んーわかんないですねえ。たしかXXXチームが前やってましたよね。FさんかGさんいるかな」
Aさん「いってみますか。あ、いた。Fさ〜ん」

AさんとCさんは、データの仕様でわからないところが出てきたので、2人でFさんのところへ聞きに行った。
このように、2人で行動することもある。今やっている仕事についての情報を得たいときは、そうすることが多い。

...

そうこうしているうちに、お昼になった。

Cさん「昼行きますか」
Aさん、Bさん「はーい」
Dさん「いってらっしゃ〜い」

お昼はチームで一緒に行くことが多い。日によっては、それぞれ自由に他のチームの人と行くこともある。
Dさんはお昼を食べないタイプなので、いつも席で本を読んだりしている。そのあたりはもちろん自由だ。

...

そして午後も開発は続く。
今は再びAさんとBさん、CさんとDさんのペアで開発しているようだ。そんな折。

Bさん「あれ。ちょっと思ったんですけど、この持ち方だと市場変更のケースで困りません？」
Aさん「おお……？　確かに。更新すると古いほうが消えちゃうし。まいったな」
Bさん「そのケース想定できてなかったんですかねえ」
Aさん「ですかねえ。変更したほうがいいかなあ」
Bさん「相談してみますか。CさんDさん、ちょっと相談したいことが……」

ちょっと大きめの設計の議論が必要になった。（今回は、DBのスキーマの設計だ）

仕事の細部はペアで決めてどんどん進むことの方がずっと多いが、今取り組んでいる仕事の全体に関わるような設計の議論は、4人集まってすることが多い*6。
そういうときも、こういう風に気軽に声をかけてその場で議論を始める。

Cさん「はい」
Bさん「今って、（おもむろに立ち上がって、ホワイトボードに書く）こういうスキーマになってるじゃないですか（みんなも立ち上がってホワイトボードに集まる）。で、この持ち方だと市場変更のときうまく対応できないんですよね」
Cさん「おお〜。確かに」
Dさん「ふむふむ」
Aさん「そもそも市場変更したときってどうなるのがいいんですかね」
Dさん「戻ってくることがあるのかとかも気になりますね」
Bさん「ていうか、そもそも企業と証券って1対1なんですっけ？」

スキーマの設計というよりは、ドメインの理解に話が波及していきそうだ。
そういうときは、エンジニアに限らず、そのドメインに詳しい他職種の人を呼んでくることも多い。

【30分後】

Cさん「お〜。完璧じゃん」
Dさん「やりましたね〜」
Aさん「Bさんのアイデアが完全に天才でしたね」

議論に30分かけて、ドメインの理解が進み、発展に耐えられそうなDBスキーマの再設計を行うことができた。

その間開発は止まってしまったが、チーム全員のドメイン理解が深まり、今後不安なく開発を進められることを思えば安い代償だ。
ときには、このように勇気を持って立ち止まることも重要だ。

Bさん「いったん休憩入れましょうか」
みんな「ですね！」

...

このあとも何度かペアを交代しながら、開発を進めていく。やがて18:30になった。

Aさん「時間ですねえ」
Dさん「これ通ったら勝ちなんだけどな〜！」
Aさん「5分だけやります？」
Dさん「そうしましょう」

AさんとDさんのペアは、もう少しで今やっている仕事が終わるようだ。

この働き方は体力を使うので、いつも8時間働いたら終わりにしている。
とはいえ、このように5分程度は融通をきかせることもある。

Bさん、Cさんも2人の会話を聞いていて、あわせてあと5分だけ続けることにした。

【5分後】

Dさん「ぐわー！　こっちのポートが未実装だった」
Aさん「でしたね〜」
Dさん「まあでもキリはいいかな」
Aさん「終わりますか」

これで終わりだと思っていたら、もう一箇所開発が必要な箇所が残っていたようだ。残念。
とはいえ定時を回っているので、これ以上の深追いはせず今日は潔く終わりにする。明日もまた一日、元気に働くためだ。

Bさん「はいー」
Cさん「おつかれ〜」

もう一つのペアもあわせて終業。
今日もいい汗書いた*7。解散、また明日。

〜〜〜

こんな感じで日々仕事をしている。

4人のチームで、常にコミュニケーションを取りながら淀みなく成果を届けていくイメージだ。*8

さらに、他の多数のチームとも常にゆるくつながっていて、いつでも気軽に連絡を取り合う。
Eさんが来たときや、Fさんのところへ行ったときのように。

だから、結局のところ「4人のチーム」というよりは、むしろそういったチーム、「の集まり」がチーム、といったイメージのほうが適切かもしれない。その「チーム全体」で、フローを生み出し続けている。

ここでは描かなかったが、もちろん、チームでビジネスサイドの人たちと話したり、ふりかえりをしたり、時にはユーザと直接話したりといった時間もある。開発だけでなく、サービスの運用も行っている。
言われたものを作る開発チームではなく、ビジネスに直結したプロダクトチームになろうと日々努力している。

この働き方は、楽しい。

たぶん、自然で、無理がなく、かつ連続的に小さな成功を繰り返していけるからだ。

この働き方は、持続性が高い。

ドメイン知識も技術力もある1人のエンジニアがヘッドフォンをつけてひたすらコードを書き続けたほうが、もしかしたらデリバリーのスピードは早いかもしれない。
しかし、そのエンジニアもいつかはいなくなる。そのエンジニアが長期休暇を取れば、その間仕事は止まる。そのエンジニアはドメイン知識と技術力をさらに深めていくかもしれないが、その知識が他のエンジニアに（少なくとも自然に）広がることはない。そのエンジニアが他のエンジニアから学ぶこともない。

私たちのやり方は、日々を楽しく過ごし、個人としても組織としても持続可能なかたちで成果を届け続けるやり方だ。
このやり方は、XP（Extreme Programming）と呼ばれている。*9

---

こういうチームで仕事をしてみたい！　という方、もしいたらぜひ一緒に働きましょう。

apply.workable.com

いきなり応募するのはハードルが高い、まずは気軽に話を聞いてみたい……ということであれば、Twitterでメンションいただけると幸いです。

twitter.com

最近出たこの記事で紹介している「組織のカオスエンジニアリング」が支障なく行えているのも、こうした働き方に負うところが大きいと思います。

hatenanews.com

*1:ここで「仕事」と呼んでいるものは、実際にはユーザーストーリーだ（タスクではない）。ただし、かなり細かく分割していて、1つのユーザーストーリーをだいたい半日〜一日でリリースすることが多い

*2:Work In Progress。仕掛り中、ということ。タスクボードにそういうレーンがある

*3:『実践テスト駆動開発』で示されているようなワークフローに近い

*4:テストが通ったあとにリファクタすることもある。ただ、リファクタ自体もこまめに行なっているので、最後の最後はテストが通ったら本当に終わりというケースも少なくはない

*5:ビルド、ユニットテスト、E2Eテスト、イメージのタグ付けという一連の流れを自動的にやってくれる。ちなみにこれもチームで作ってメンテしている

*6:よくあるのは、APIのリソースのパス、DBのスキーマ、コードのドメインオブジェクトの集約の切り分け方、マイクロサービス間での責務分担等

*7:残念ながらあまり身体は動かさないので、頭に汗かいた、という感じ

*8:4人というのは平均的な数で、実際には3人の場合もあれば、5人の場合もある

*9:もちろん、この1日にXPのすべてを表現し尽くせたわけではなく、コミュニケーションの価値を中心にごく一部を表現したにすぎないので、その旨ご了承ください

2021年前半のふりかえり

やったこと

1 冊

目標「月に 1 冊以上技術書を読む（※アジャイルの本など、コードが出てこないものは除く）」について、2021 年前半に読んだ技術書は 1 冊。

1/6。
なるほどね？

アクティブに読みかけの技術書は複数ある。

1 本

目標「月に 1 本以上記事を書く」について、2021 年前半に書いた記事は 1 本。

1/6。
なるほどね……？

引っ越した

引っ越して人と一緒に住み始めた。

翻訳をやることになった

『The Great ScrumMaster』（日本語版は『SCRUMMASTER THE BOOK』）の著者である Zuzana Šochová さんが書いた『The Agile Leader』という本を、会社の人数名と一緒に翻訳している。

greatagileleader.com

わかったこと

生活が変わると、習慣も変わる

引っ越して人と一緒に住み始めたことで、生活習慣が色々と変わった。

直接的ではないものの、結果として、本を読む数がぐっと減った。
具体的には、6 ヶ月で 18 冊しか読んでいない。去年の 42 冊に比べて実に半分以下である。
この数の少なさが、読んだ技術書の少なさ（1 冊）にも響いているし、書いた記事の少なさとも関連があると思う。

翻訳は楽しい。そして、時間がかかる

翻訳は（特に、複数人での翻訳は）想像以上に楽しかった。
そして、想像以上に時間がかかる。

これも、読書や、（翻訳以外の）アウトプットに時間が取れていない一因になっている。

次にやること

本を読んだり、アウトプットするための時間を作る

生活習慣が変わったことで、結果として、本を読んだりアウトプットしたりすることが満足にできていないのが現状だけれど、感覚としては時間が絶対的に足りていないわけでは（今のところ）ない。
なので、新しい生活習慣に合わせてそれらの活動をするための時間を明示的に確保すればおそらくリカバリーできると思う。

具体的には、毎週土曜か日曜のどちらかでまとまった 2 時間を取ることにしようかな。それくらいなら、無理なく、着実に進めていくことができるだろう。
本を読むのか、アウトプットに使うのかは自由で、都度決めることにする。

目標は下げる

翻訳に時間がかかることは簡単には変えられない現実で、そちらをできるだけ優先的に進めたい意向でもあるので、年初に立てた 2 つの数値目標は潔く下方修正することにする。
具体的には以下の通り。

• 月に 1 冊以上技術書を読む
  • 「2 ヶ月に 1 冊以上技術書を読む」に変更。インプットはできるだけ減らしたくないが、6 ヶ月分のビハインドを取り戻すのは難しいと考えた。
• 月に 1 本以上記事を書く
  • 「3 ヶ月に 1 本以上記事を書く」に変更。都合あと 2 本書けば達成になる。たぶん年末のふりかえり記事を書くので、それ以外でもう 1 本。

あとは自由

昨年末にも感じたような、自由でも大丈夫な感覚は今のところ続いている。
だから、続ける。

シンプルに実装することと、実装をシンプルにすること（シンプリシティについての断章）

XP の 5 つの価値のうちの 1 つに「シンプリシティ（シンプルさ）」があります。

このシンプリシティについて、気づいたことがあるので記します。要点は以下の 2 つです。

• XP での開発におけるシンプリシティの実現には、「シンプルに実装すること」と「実装をシンプルにすること」という 2 つの側面がある
• XP での開発において、シンプルに実装することと、実装をシンプルにすることは車の両輪

シンプルに実装すること

XP での開発におけるシンプリシティの第一の側面は、シンプルに実装すること（implement simply）です。

今取り組んでいる目の前のストーリーの実現にあたって、「もっともシンプルで、うまくいきそうな設計・実装」だけをする。

その判断のために役に立つ原則（経験則）もあります。以下のものです。

• すべてのテストをパスする。
• コードの重複がない。
• すべてのコードについて、プログラマの意図を明確に表現している。
• 最小限のクラスとメソッドを備えている。

この原則にのっとって、「もっともシンプルで、うまくいきそうな設計・実装」を判断し、それ以上のことをしたくなる誘惑に負けないように、自分を厳しく律します。

これが「シンプルに実装すること」です。

実装をシンプルにすること

XP での開発におけるシンプリシティのもう一つの側面が、実装をシンプルにすること（simplify implementation）です。

いわゆるリファクタリングですね。

XP では継続的にリファクタリングを行いますが、中でも特にリファクタリングに適したタイミングが 2 つあります。以下の 2 つです。

• テストファーストで書いたユニットテストがパスしたとき。（レッドからグリーンになったとき）
• 新たな機能の実装に取り掛かるために、既存のコードを訪れたとき。

どちらも重要ですが、特に 2 つめの機会について意識的であることが重要だと思います。
というのは、1 つめの機会については「レッド→グリーン→リファクター」というフレーズがよく知られており、比較的見落としにくいと思いますが、2 つめの機会については 1 つめに比べるとあまり語られることがないように思えるからです。

2 つめの機会では、前回このコードを訪れたときに十分「シンプルに実装」していたとしても、その実装をさらにシンプルにできる可能性があります。
それは、前回と今回では、前掲の原則にも出てきた「プログラマの意図」が異なるからです。前回は、前回実装しようとしていた機能が「プログラマの意図」でした。今回は、「前回実装しようとしていた機能だけでなく、今まさに実装している機能も加わったとき、それは何なのか？」というのが「プログラマの意図」ということになります。

これが「実装をシンプルにすること」です。

シンプルに実装することと、実装をシンプルにすることは車の両輪

そして、ここがこの記事の核心なのですが、シンプルに実装することと、実装をシンプルにすることは車の両輪だと思います。つまり、どちらか片方だけではバランスを崩し、うまく走ることが難しくなります。

「シンプルに実装すること」は、「実装をシンプルにすること」に依存しています。より正確に言うと、今「シンプルに実装」しようとしている人（便宜的に Alice と呼びます）が、のちに前述の「リファクタリングの 2 つめの機会」に触れる人（便宜的に Bob と呼びます）が「実装をシンプルにしてくれる」に違いない、と信じることに依存しています。

なぜなら、「Bob が（のちの機会に）実装をシンプルにしてくれるに違いない」と信じられなければ、Alice はあらかじめ「Bob が実装に取り掛かるタイミングになったとしても、十分シンプルであり続けられるであろう設計・実装」を想定して作り込みたくなってしまうからです。結果として、「シンプルに実装」することはかなわなくなります。

ひるがえって、「実装をシンプルにすること」もまた、「シンプルに実装すること」に依存しています。Alice が「シンプルに実装」してくれていればこそ、Bob は「実装をシンプルに」することができるからです。

もし Alice が「そのときにシンプルな実装ではなく、先々も十分シンプルであり続けられるであろうと考える設計・実装」をしていたとして、いざ Bob が実装しようとしたときには Alice の想定していたものとは違うものが必要になってしまっていたら、どうなるでしょう。Bob は、まず Alice の過去の想定を読み解き（直接聞いた方がよいとは思いますが）、現時点の最新の知識にもとづいて修正し、それから実装を（その時点での）シンプルなかたちにやり直す必要があります。それでも「実装をシンプルにする」こと自体は可能ではありますが、「Alice の作業がムダになる」「Bob が本来必要のなかった修正作業をするはめになる」という 2 つのムダが生じてしまいます。

だから、Alice は Bob を信じて常に「シンプルに実装」し、Bob は Alice が残してくれたシンプルさに報いるため、そして将来そのコードを触る人（それは Bob 自身かもしれないし、Alice かもしれないし、また別の誰かかもしれません）のために必ず「実装をシンプルに」するのです。そうすれば、車の両輪がバランスよく回り、XP による開発がもっともよい価値の流れを生み出すことができます。