引き継ぎの苦痛にペアプロで立ち向かう
はじめに
これは「子育てエンジニアAdvent Calendar 2023」 9日目の記事です。
引き継ぎの苦痛を考える
育児する上で、夫婦で協力する場面は多いと思います。今回はそんな中で自分的に難しいと思っている引き継ぎの苦痛について話します。
コンテキスト
私の持ってたコンテキストはここに記載があります。
ざっくりと - 子ども二人、愛犬が3匹 - 妻の１年のアメリカ出張に伴い、その間の家事、育児を担当 - 家事スキルがアップしたことにより、妻の出張後も基本的に家事を担当
です。
チームワークが活かしきれない
一人で家事をしていたところから、二人になって本来的にはパワーアップしているはずなのに、なかなか活かせずにいました。 その原因は引き継ぎに伴う苦痛です。
例えば下記の状況を考えます。
- 疲れたり酔っ払ったりして、洗い物をできずに寝落ちしてしまった
- シンクに残っている洗い物は下記の通り
- 鍋（小）
- 鍋（大）
- ご飯茶碗（４人分）
- 味噌汁のお椀（4人分）
- 大皿
- 調理器具（おたま、包丁 x 2、 菜箸）
- 食洗機があるが、全ての洗い物は一度には入らない
- あ、洗濯機もかけ忘れていた
- 洗濯物はうずたかく積もっており、何が洗濯かごに入っているのかは不明
この状況において、パートナーがフォローしてくれる目的で手伝ってくれようとした時、どのように行動したらいいかは自明ではありません。 暗黙的なコンテキストがしこたまあるからです。
ここに存在している暗黙のコンテキストは下記のものです。
- 明日は学校だから、もし洗濯物に学校の制服が入っているのであれば必ずそれを洗わなければいけない
- 割烹着や体操着などが不規則に混じることもあるので、その場合は本当に最優先
- もし割烹着が入っていた場合はアイロンかけも必要。明日の起床時間を早める必要がある
- 割烹着や体操着などが不規則に混じることもあるので、その場合は本当に最優先
- 朝食は基本的に親はバターコーヒ。なので親の茶碗などは後回しでOK
- 明日はパンを買ってないがご飯の冷凍は残っている。なので茶碗は洗う必要がある
- そうなると、汁物は味噌汁になるのでお椀も洗う必要あり
- そうなると野菜切るから包丁も入れないといけない
- 子ども二人分の味噌汁を作るために鍋（小）も同じロットで洗う必要あり
- それに依存してお玉も必要。菜箸は他のセットがあるので洗わなくても平気
- あ、２本あるうちの一本の包丁は果物用で鋼なので、食洗機かけるんじゃなくて手洗いしないと錆びちゃう
これらを理解していないと、次工程をスムーズにする行動をとることができません。普通に無理ゲーかと思います。
ちなみにですが、時折SNS上でパートナーが家事を手伝おうとしても足手まといといったコメントを見ることがあるのですが、それは夫婦どちらも問題がなく、ただこの暗黙のコンテキストが多すぎることが原因かと思います。
トライしていたこと
この悩みをママ友に相談してみたところ「料理するときに一緒にキッチンに二人で立ったほうがいいよ。何もしなくても」というアドバイスをもらいました。
これ、つまりペアプロしましょう、ということだと認識しています。 ペアプロだと最初は頻繁にペアを交代することが成功の秘訣だったりしますが、そのさらに手前にまずは一緒に場を共有するというのがあると思います。 結果、その行動の中に暗に含まれているコンテキストが、暗黙知としてそのままトランスファーできることに気がつきました。
結果として、今はだいぶ暗黙的なコンテキストが減り、ずいぶん油断して寝落ちするようになりました。妻には本当に感謝しています。
まとめ
暗黙知の多い業務を、ペアプロを用いて改善を試みている、というお話でした。
みなさんの知見もぜひ知りたいのでもし何かアイデアがあれば教えていただければ喜びます！
技術負債解消はEconomicsで語ろう
技術負債の解消〜みたいな話がチームで出た時に、話のスタートラインに〜ってので何度か投下したのでとっかかりの議論をまとめました。
そもそも技術負債とは
生みの親のWard Cunninghamがその背景を説明してくれている動画を id:t-wada さんが紹介してくれていて、 その内容はよく言われているものとは結構違います。
こちらのブログのt-wadaさんによる解説を引用します。(レイアウトの都合で改行足してます)
Ward の言う負債の悪影響とは、開発と共に得られていく知識や理解と 目の前のシステムとの乖離が引き起こす生産性低下のことであり、 自分たちが書いているコードの保守性（あるいは、雑さ）のことではありません。 むしろコードを書くときには常にそのときのベストを尽くせと言っています。 Ward にとって負債の返済手段はリファクタリングであり、 リファクタリングの目的は自分たちのドメイン理解と現時点のプログラムの乖離の解消です。 つまりこのリファクタリングとはドメイン駆動設計（DDD）における 「より深い洞察へ向かうリファクタリング（Refactoring toward deeper insight）」 のようなものと言えるかもしれません。
これを読んだ上で自分的なポイントは、一口に技術負債と言っても、それによるイメージは多義的になってしまっているということです。 なので自分が「負債解消」って言った時に、どういう意味合いで言ってるのかは自分の中できちんと理解しておき、場合によっては別な言い回しができるようになっておきたいところです（対象の理解）。 以降の部分では、基本的に「自分たちが書いているコードの保守性（あるいは、雑さ）」と言ったイメージで負債解消を使います。
技術負債の解消どうする？
さて、対象が理解できたとして、次にその負債は解消すべきなのかどうかを考えます。代表的な負債解消の方法はリファクタリングかなと思うのですが、ここで自分が意識しているのは、Mertin Fowlerの「リファクタリングはEconomicsで正当化せよ」というものです。こちらのトーク動画（Agile Singaporeのクロージングキーノート）から見られます。
雑にまとめると、リファクタリングをプログラマの嗜みや、正しい行いとして正当化してはいけない、リファクタリングはEconomicsで正当化せよ。というものです。
このトークは直接聞いていたのですが、衝撃を受けたのを覚えていて、以来意識するようにしています。
実践
正当化しなければならない（くらい大掛かりになってしまった）ケース
「リファクタリングをバックログに積みたくなった時点でもう負けが込んでる」って昔TDDBCでコメントもらった気がするのですがその通りで、もはやこれは厳しい、って場合はEconomicsで考えます。そしておそらくそのEconomicsは、少なくとも今起きている実害についてはある程度可視化できると思われるので、可能な限り可視化・数値化を頑張ります。その上でストーリー立てして、Economicsのまな板の上で議論して堂々とやりましょう。
例えば自分がやった取り組みとしては下記があります。
小規模なもの
先のt-wadaさんのブログにもあった通り、「むしろコードを書くときには常にそのときのベストを尽くせ」です。
同じ考え方はいろんなところで語られていて、例えばアジャイルサムライでは、「積極果敢なリファクタリング」って紹介されています。
積極果敢なリファクタリングとは、イテレーションの終わりにまとめてリファクタリングすることじゃない。 一日を通じてたゆまず、継続的にリファクタリングするってことなんだ。 物事がうまく運んでいれば、リファクタリングはほとんど目につかない。 手順は少ないし、改善内容も細かい。 だから作業工程としてリファクタリングなのか、新機能の追加なのかを明確に区別することはできない。
Mertin Fowlerも、「リファクタリングはTDDのコンテキストで教えられる」と言っています。日々の活動の中でTDDが入っていれば、リファクタリングは日々の活動に溶け込んでいる基本のキと言った扱いになります。
この場合は、そもそも小さすぎて説明不能だし、ただ全力を尽くしているだけです。説明せずに果敢にやりましょう。 ただし時間のかけすぎや過設計には注意、負債になります。
まとめ
負債解消について、まずは日々全力を尽くし、細かい日々の活動に溶け込んだリファクタリングをしておき作り込まないこと。それでも発生してしまうので、（元々の意味では世の中が変化するので絶対に発生します）その時はちゃんとEconomicsで正当化して倒すこと、です。
「負債解消」って言った時に、そのスタートラインから結構考えたり知らなきゃいけないことがあるなぁ、という印象です。 でもだからと言って必要なリファクタリングをしないのは、結局問題を先送りにしているだけなので果敢に取り組むべきだと思っています。
自分が何を参考にソフトウェアテストの勉強したんだっけ
チームのメンバーの人から、「ソフトウェアのテストの書籍」についての話をすることがあって、 自分って何を参考にソフトウェアの本探ししたんだっけなー、という意味で備忘。
まずこれ読んで
ここに書いてある書籍読み、コメントももらった記憶（感謝）
そしてこの辺を読んで焦燥感を得て勉強速度が上がりw
↑の本とかで引用されてるような本を芋づる検索していて読んだんだったはず。そこからは濫読派ですね。
最近の状況はあんまりキャッチアップできてなくて、どうなんだろうなーと思ってたのだけど、開発者テストって文脈でこの辺は考え方近いなと思った。
今回も新たな本を教えてもらったので、読み終わったらなんか書きます。
