この国では犬が

本と芝居とソフトウェア

『アジャイルリーダーシップ』発売です

アジャイルリーダーシップ: 変化に適応するアジャイルな組織をつくる』(原題: The Agile Leader : Leveraging the Power of Influence)という本を、会社の同僚3名と一緒に翻訳しました。

今日、発売です。

www.amazon.co.jp

僕が愛してやまないジュンク堂池袋店にも入荷してました。うれしい。

アジャイルラクティスを導入し、実践していく方法は20年以上前からさまざまな書籍で語られ続けていますが、チームや、さらには組織をアジャイルへと導いていく「リーダーシップのあり方」については、まとまった日本語の書籍が今までなく、ほとんどの人が関連書籍*1の記述を参考にしたり、隣接分野*2の知見を借りたり、各自で工夫したりしてきた*3というのが現状なのではないでしょうか。*4 *5

そんな中でも、2020年に邦訳が出版された『SCRUMMASTER THE BOOK』(原題: The Great ScrumMaster)は、非常に近いテーマを扱う日本語書籍として貴重な存在でした。
その著者であるZuzanaさんが書いた二冊目の本にして、スクラムマスターというスクラム固有の役割のコンテキストにもとづかない、より普遍的なリーダーシップについて語る書籍が『アジャイルリーダーシップ』です。

Zuzanaさんが実際に接してきた組織やチームでの事例も数多く掲載されており、読んで「あるある」と感じるものもあれば、中には「そこまでやるの!?」と感じるものもあるかもしれません。
チームや組織をよりアジャイルにしていきたいと考えているひとにとって、きっとヒントが見つかる本だと思います。

ぜひ、書店で一度お手にとってみてください。
また、以下の公式ページの「関連情報」タブからまえがきが読めるので、書店に行く予定のない方はそちらからご検討いただけると嬉しいです。

www.kyoritsu-pub.co.jp

献本させていただいた椎葉さんが、早速書評ブログを書いてくださいました。

bufferings.hatenablog.com

最後にもう一つ。
12/7に、Forkwellさんのイベントでお話しすることになりました。

含蓄の深いこの本のエッセンスを30分に凝縮してお伝えしようと思っていますので、こちらもご参加いただけると幸いです。
アンケート回答者の中から抽選で30名に、書籍のプレゼントもあるようです。

forkwell.connpass.com

*1:多くのアジャイルラクティス関連書籍にはリーダーシップへの言及がありますし、アジャイルと親和性の高い技術リーダーシップの書籍としてはたとえば『エラスティックリーダーシップ』が挙げられます

*2:サーバントリーダーシップコーチング、ファシリテーション、その他マネジメント関連書籍など

*3:私はあまり深く関わったことがありませんが、スクラムマスターやアジャイルコーチのコミュニティではこういった話題が活発に取り上げられているものと思います

*4:私が知らないだけという可能性ももちろんあります。これぞという本をご存知の方がいらっしゃったら教えていただけると非常に嬉しいです

*5:余談ですが、つい最近立て続けに出た『マネジメント3.0』および『マネージング・フォー・ハピネス』は、マネジメントという切り口ながら、いずれもかなりアジャイルリーダーシップに関連の深い知見が集まった良書だと思います。正直、読んで感動しました(『The Agile Leader』を読んだときと同じくらい :))。そもそもZuzanaさん自身もマネジメント3.0のライセンスファシリテーターであり、マネジメント3.0の考え方から影響を受けた部分も大きいものと推察されます

日記

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

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

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

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

であれば、何か。

最近アプリで漫画を読む。
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人は、次の仕事に取り掛かることにしたのだ。

f:id:enk_enk:20211225124023p:plain
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が通ればリリースできるので、パイプラインを確認して、通っていればリリースしてから次の仕事に取り掛かることになる。

f:id:enk_enk:20211225130031p:plain
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 本。

あとは自由

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