0時に寝て7時に起きた。疲れているせいか、よく眠れたと思う。わりと出張でよく眠れているので普段眠れていなかったのは体力が余っているからではないかという気もしてきた。

課題の洗い出し

一昨日の続きでわかっていることや進捗のあったものを確認しながら、追加で課題を作って整理していく。まだまだ課題が足りないのでどんどん作っていかないといけない。それと同時に go のソースコードを読みながら設計や改善の要点を私の中で把握していく。java に慣れたプログラマーが書いた go のコードなので java の考え方の影響が強いようにみえた。私がいくつかアドバイスする余地はあるようにみえた。google でコードレビュー時によくある指摘事項をまとめた有名な wiki がある。メンバーに聞いたらちゃんと読んだことがないということだったので2-3回かけてみんなで読んで学ぶ機会にする。私自身、数年前に読んで忘れていていることも多いだろうから学び直し。テストのページは2019年9月に追加されている。たぶん読んだことない。

• https://github.com/golang/go/wiki/CodeReviewComments
• https://github.com/golang/go/wiki/TestComments

課題管理勉強会

1時間分ぐらいの資料を用意したつもりが35分で終わってしまった。勉強会の雰囲気が固かったのか、慣れない場所での説明だったのか、マスクした状態で長々と話すことも過去に一度もやったことなくて話しにくかった。初めての試みであまりうまくいかなかったが、初めてやることでうまくいかないのは私にとって当たり前のことなので次の勉強会に向けて改善していきたい。どのぐらい伝わったのかわからないけれど、もっと参加者を巻き込んだ活気のある勉強会になるように努めていきたい。

リアル飲み会

19時から3年ぶりに友だちとリアル飲み会。せっかく東京に行く機会だからと5日のうち3日飲んでいたので後半になるほどバテていった。これは加齢による体力低下もあるのだろう。娯楽はどういうものか？という定義や在り方の議論が盛り上がって、私は暇つぶしの時間であって何もしないのでぼーっとしているのも退屈だからその時間を埋めるもの、楽しければいいけど楽しくなくても、どうせ何もしない時間なのであまり気にしないといった考え方をしている。私の友だちは楽しむために娯楽に集中するとか、その時間を無駄にしないようになるべく楽しめる娯楽を選択するとか、24時間のうち、1時間足りとも無駄な時間にはしないぞという姿勢がみえて、私からみたらそんな生活はしんどくないですか？みたいな気持ちになった。おそらく時間を無駄にしたことがストレスになるからそういう姿勢になるのだろうと推測する。娯楽をしながらだらだら時間を過ごすということはないらしい。オンライン飲み会はちょくちょくしていたものの、3年ぶりにオフ会をしたので飲食代をご馳走になった。感謝。前も会社を作った後の飲み会でご馳走になっていて、なかなか私からお返しできていない。それを覚えておくためにもここに書いておく。

本棚に埋もれて眠る

この日は 新宿 BOOK AND BED TOKYO に泊まった。前に浅草の同施設に泊まったことはあったけれど新宿は初めて。大雑把に言えば本屋とカプセルホテルが合体したような施設になる。この非日常の雰囲気が好きなので機会があれば泊まるようにしている。宿泊費は6,000円とカプセルホテルより高くビジネスホテルより安いという価格帯。ここに来て本を読んだり泊まったりしている人はコワーキングスペースもしくはコミュニティ的なスペースが好きで本も好きな人たちだと思う。勉強会に行く感覚と似ている。そういう自分と似た人たちが集まる空間そのものが価値観の共有だったり安心感につながっていて私はそういう空気も楽しんでいたりする。とはいえ、バテバテで疲れていたので少しだけ本を読んでわりとすぐに寝た。

1時に寝て7時に起きた。ホテルのビッフェ形式の朝ご飯は2回目のなのでうまくプレートに盛り付けて段取りよく配膳できた。昨日より改善できた。

課題の意思決定と割り当て

プロジェクトの初期なのでとにかく段取りを早め早めに決めてタスクを洗い出し、メンバーが目標に向かって作業しやすい状況をマネージャーとして作り出さないといけない。昨日からプロジェクトのリポジトリ構成を変更しようというイシューを作ってメンバーと議論していた。当初は私がちゃちゃっと作業して移行しようと考えていたが、私の移行イメージを書き出していたらメンバーからいくつか背景や要望が出てきて、メンバー集めて打ち合わせして合意をとって決断することにした。私が入ってからプロジェクトでの初の意思決定かもしれない。

既存のソースを読んだらリポジトリ統合は少し工数がかかるとわかって、私がやるよりもメンバーの方がいいだろうと意思決定だけ私が判断して、実作業はメンバーに割り当てた。初めてのマネージャーっぽいお仕事をできたとちょっと自己満足。その議論の過程で monorepo vs polyrepo という比較記事を読んでみた。monorepo から polyrepo に切り出すのは容易だが、polyrepo から monorepo に統合するのは大変ということが書いてあって、まさにプロジェクトの状況と合致してメンバー間で認識合わせした。いま (過剰な) polyrepo で管理されているのを monorepo に統合しようという決断をした。これをやるのにコミット履歴を維持するのはコストがかかるのでソースファイルをコピーして新規ソースとして移行してよいという判断も下した。こういう意思決定は即断即決でやりたい。

monorepo の対義語として polyrepo という言葉があるのか。勘と経験でリポジトリは複数に分割するので私がやってきたのは polyrepo ではあるのだけど、ちゃんと考えたことはなかったのでアーキテクチャとして議論する余地があるんやろな。 https://t.co/7LQY4cMteF

— Tetsuya Morimoto (@t2y) November 1, 2022

1on1

マネージャーとして1on1を行う。プロジェクト初期は毎週やって、その後はメンバーの要望を聞きながら隔週でもよいと考えている。1on1 の目的ややり方は様々だが、私が提供できるのは次の3つに含まれることかなと思う。

• モチベーションアップ
• 業務・組織課題の改善
• 能力開発／キャリア支援

初日から長時間の会議と懇親会などでチームのメンバーと話す機会が多かったので 1on1 もみんな気さくに話してくれてよかった。私はなるべく話さずに聞くことに専念しないといけない。私は圧倒的に自分の思ったことをがんがん話してしまう方なので他人の話を聞く姿勢を身につけるよい機会になると思う。今回は準備不足で雑談がメインではあったものの、1on1 の本なども読みながら勉強していこうと思う。

0時に寝て6時過ぎに起きた。朝からシャワー浴びてホテルのビッフェ形式の朝ご飯食べてた。初めてのオペレーションだと段取りわからなくて朝ご飯さえうまく配膳できなかった。経験のないことは全然できない。

課題の洗い出し

お手伝い先のワークフローや段取りを学ぶ。毎週火曜日がプロジェクトの定例会議。火曜日の終わりに週報を書く。メールで週報を提出するという、いまどきの会社からみると古い会社の慣習にみえる。郷に入れば郷に従えということで私も同様に行う。課題管理で日々の活動をひたすら書いているので週報はいつでもすぐ書けるので私は全く苦にならない。

プロジェクトのリポジトリ構成の変更や課題の洗い出しなどをやっていた。イテレーションは週1でマイルストーンを4週間(月1)で設定して、その区切りでふりかえりなども実施していきたいと思う。コミュニケーションコストが高いことから、私は開発方法論としてスクラムを採用するつもりはない。あくまで自分がやってきた経験による課題管理 + イテレーション開発で製品開発のワークフローを構築したい。お手伝い先ではチームで課題を共有して開発に取り組むといったことはこれまでやってきていないものの、課題管理システムを使って開発者間でやり取りするのは普通にやっていたそうなのでイシューのコメントへの返信がめちゃくちゃ速い。イシュー上で議論していて私がこうしましょうとコメントを書いたら最も速いメンバーは5秒後にリアクションがつくぐらいの速さ。他のメンバーも数十分以内には返信がつくので課題管理システムを使うところのなにかを教える必要はない。課題管理が身に着くのに半年から1年間かかるというのは、他人のアクティビティを監視するという日々の運用 (行動) の変化に半年ぐらいかかると私は想定しているが、このチームはもっと早く課題管理の考え方に適応しそうな気がする。イシューの他人のコメントに5秒でリアクションできる開発者はそうそういない。

私がまだまだプロジェクトの理解が浅いので1-2週間はそのキャッチアップをして、メンバーが遊ばないように課題をどんどん作って優先度付けしてメンバーが担当できるようにしていきたい。

2時に寝て7時に起きた。タスクが全然消化できなくてしんどい。ただ燃え尽き症候群は落ち着いて次に向けての気力が出てきた。

神戸お土産探し

3年ぶりに出張が増えそうなので神戸のお土産探しも始めようと思う。今回は リッチフィールド さんのバウムクーヘンと丹波みるく黒豆萬をもっていく。オンラインで注文すると取り寄せに1週間かかる。ちょうど発注するときのタイミングが悪くて間に合わない。店頭受け取りだとそのリードタイムが4日になる。明石駅に店舗があったので電車に乗って朝9時から受け取りに行ってきた。電車の待ち時間を含めて往復で約1時間で受け取れる。もっていくお土産は自分がおいしいと思うものをもっていきたいという考えもあって単品でも購入して食べてみた。バウムクーヘンはしっとりした食感で普通においしい。プレーンよりも黒糖の方が風味の自己主張が強いという特徴があって私は好きかな。丹波みるく黒豆萬は濃厚なミルク餡で丁寧で上品なお菓子という印象を受けた。甘いのが苦手な人はややしつこいかもしれないけど、普通においしいと思う。黒豆がちょこんとのっているのが他の乳菓子との差別化かな。(なんの認定にもならないが) 私の審査は軽く通るお土産だとわかった。

開発者として効果的に伝える方法

関心のあるタイトルをタイムラインでみかけたので読んでみた。

• How to communicate effectively as a developer

期待したほど私にとって参考になることが書いてあったわけではないけれど、読んでみて参考になることはいくつかあった。著者は「効果的に伝えることを共感的に文章の解像度を高めること」と定義している。私の周りでもエンジニアリングの文脈で解像度の高低というキーワードをよく聞く。一方で共感というキーワードを私は意識していなかったのでこれは素直に参考になった。読み手を想像してその人が共感できるように書くことの重要性に言及している。empathically=「共感して、親身になって」という意味だから日本語らしく訳すと相手の気持ちに寄り添って書くとか、相手のために親身になって書くとか、それ自体はよいことのように思える。高解像度、且つ共感性の高い文章を書くことは労力を要するものの、次のことから win-win-win だと著者は表現している。

• 読者はより深く理解し、レベルアップする
• 組織は知識の共有が進み生産性が向上する
• 自分の考えを伝えるのが上手になり、キャリアアップにつながる

いまとなっては後の祭りではあるが、私がいまの3倍速く巧く文章を書ければたしかにもっとキャリアップできていた気がする。書こうと思いながら筆が進まずに断念した文章はいくつもある。最後の結びの言葉も気に入った。

自分が相手の立場なら喜んで読んでくれるような文章を書きましょう。

課題管理の勉強会の資料作り

来週の出張で使うかもしれない課題管理の勉強会向けの資料の叩き台を作った。過去の資料を見返しながらスライドを作り直していた。過去に資料を作ったときは納得して作ったものを、いま見返すと誤解している箇所があったり、あまり重要とは思えなかったり、当たり前の話しだけど、スライドやドキュメントも時間が経って見返すと粗が目立つようになる。こういうとき私は自分を信じないと再確認できて慢心せずにすむ。常に課題管理システムに日々の学んだこと、考えたことを書き続け、チケットの構成を整理し直したり、チケットとチケットの関連を結びつけたりしているうちに過ちや無知に気付くきっかけになる。この暗黙知をいつか形式知として言語化できるようになりたい。

23時に寝て1時に起きて2時間ほどだらだらしてて6時に起きた。

最後のふりかえりイベント

最終週なのでこのチームでのスプリントのふりかえりは今日が最後になる。メンバーが気を遣ってくれてこれまでの活動に感謝を伝えてくれた。いくつか出たコメントをあげる。

• インフラを整備した
• チケット駆動開発の基礎を伝えた
  • 課題管理のよさもわかってきた
  • メンバーが課題管理を行う習慣化につながった
• 社内でもっとも backlog を使いこなしているチームになった

1年に渡って開発に参加して課題管理を見守ってきたので課題管理とは何ぞやの基礎をメンバーの大半は理解できるようになったと思う。(私からみて) ワークフローを洗練させるという視点で現状の運用は入門レベルではあるけれど、根っこの部分をちゃんと理解できているメンバーもちらほらみえてきたのであとは時間とともに上達していくのではないかと思う。このままもう2-3年取り組めばスクラムに頼らなくても高い生産性と迅速な情報共有ができるチームになるかもしれない。1年前はチームで課題管理がほとんどできていなかったのに、いまは大半のメンバーがやろうとするようになった。他のメンバーの行動を変えられたのが私としても嬉しい。いくつかの組織やチームで何度もやってきたことなので半年から1年あればできるというのは一定の信頼がおけて自信ももっている。今後の私の課題としてはこれを3ヶ月で達成する、1ヶ月で達成するための体系化やリーダーシップを作り上げていくことが考えられる。

hannali dao 始動

Hannali DAO に参加した。Metaアカウントへの移行(Workrooms向け) によると、2022年8月30日以降は meta アカウントではないと workrooms にアクセスできないらしい。ここ2-3ヶ月 workrooms を使っていなかったのでまとめてシステムのアップグレードや meta アカウントの移行なども行った。まったく難しくなくて手順通り作業を進めればアップグレード作業も含めて1時間もあれば完了するぐらいの作業量。当初は workrooms で開催する予定だったが、諸事情あって zoom 開催になった。とはいえ metamask の設定などをいろいろやっていたので結果的に zoom でよかった。

おがわさんが作った dao で利用できる PROG という名前のカスタムトークンをメンバーに配って受け取る。受け取る方も metamask で wallet と接続しないと受け取れない。polygonscan というサイトで自分のアドレスへの polygon ネットワークのトランザクションを次の uri で確認できる。PROG というカスタムトークンを 50 受領しているのがわかる。

• https://polygonscan.com/token/0x14e1bd8689c150509a14db70b2d8c8cd33747cdf?a=0xe1688b4b017ae362261f14415cc0db72b8b53e10

これだけのことをやるのにまったく作業の勘どころが働かなくてみんな四苦八苦していた。たったこれだけを2時間ぐらい。その後、dao や世の中の事例について雑談。お互いの情報共有になっておもしろかった。私は web3 関連に技術体系には否定的なスタンスを取る方だけど、技術そのものを否定しているわけではなく、なにかしら価値はあると考えているのでどういった用途に使うのがよいのかを探りたいという思いがある。最後にそれぞれのメンバーがもっている PROG トークンの比率に応じて投票権をもつ。みんなの投票結果を使って次の開催日を決めてみた。本当の投票は手数料がかかるトークンを使ったアプリになるのだろうけど、このアプリは手数料なしで使えるらしい。

• 次のDAO イベントいつやる？

0時に寝て悪夢で3時にうなされて7時に起きた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。話題が多くて予定していた時間に終わりきらなくて1つの話題は次回に持ち越した。今日話した内容は次の通り。

• 新しいお仕事の業務内容についての共有
• 旅費規定と就業規則についての話題
• 知人の社内ツールのフィードバックに向けての情報共有

知人が社内で使っているタスク管理ツールに招待してくれたので軽く触ってみた。想定していたよりもずっと作り込みされててすごいなぁと感心しつつ、知人の役に立つかどうかはわからないけど、課題管理の専門家としていくつかフィードバックをまとめて送付した。はらさんがその社内ツールは tailwind css を使って開発しているのではないかと予想していた。実際に当たっているかどうかは知人に確認しないとわからないが、tailwind css というフレームワークはユーティリティファーストな考え方で css は何も書かずスタイルの class だけを書けばよいので開発が早く、全体の統一感のようなものも作りやすいとのこと。私が使う機会があるのかどうかはわからないけど、そういうフレームワークがあるんだなと知って学びになった。

窓付きのオフィスの連絡

先日みつけた 窓付きオフィスの内覧前に 契約が決まってしまって断念したことを書いた。神戸旧居留地オフィス にはもう1つ窓付きの部屋があるのだけど、そこに空きが出たら連絡してくださいとダメ元でお願いしていた。なんでもお願いするものだとか、世の中親切な人がいるとか、そういう類の話しで本当に11月末で部屋が空くので引っ越しますか？といった連絡がきた。感謝。

7F-14 11月末空き予定・申込あり ￥62,700 ￥11,000 2名 6.08㎡ 完全個室/棚・窓あり

前回に内覧済みなのでその返信で申し込みもした。すでにサイトの情報が更新されていて「申込あり」とは私のことだ。既存の契約移行のやり取りをしていたら、いまのオフィスは個人名義で借りていることに気付いた。ちょうど会社を作るには会社の住所が必要で会社ができる前に契約する必要があったから個人名義での契約になっている。この機に法人契約に変えようと決めた。法人契約の手続きのために登記事項証明書を取り寄せる必要がある。登記ねっと からオンラインで申請したので水曜日までには郵送で届くはず。その書類を写真に撮って電子データに変換して手続きをしないといけない。法人の身分証明の用途で使うだけなので登記事項証明書そのものが紙である必要性はまったくないが、どうやらこの書類は電子データは提供されていないようだ。会社の手続きでよく使う書類の1つなので電子データとして扱うニーズは高いと思うのだけど、悪用とかセキュリティの側面から意図的に紙の運用にしているのかな？

ワクチン4回目接種

3回目は4月14日 に接種したのでちょうど6ヶ月が経過した。11月に東京出張するのでその保険の意味もあっていま接種するしかないと慌てて予約した。4回目のワクチンはオミクロン対応らしい。3回目と同じクリニックを予約して前回は待ち人おらずだったのだけど、今回は20分早く行ったら前に2人並んでいて予定の10分前ぐらいに注射してもらうことができた。いまこの日記を書いていて、接種直後は36.0℃だったのがその後5時間経って36.9℃になった。まったくしんどくないので平気だけど、そろそろワクチンも本気を出してきた感じか。

2時に寝て5時に起きて7時半に起きた。夜も眠れなくなってきた。

ストーリーポイント改善への再考

プランニングしていたときに調査チケットをスパイクにしようという話題がでたときにストーリーポイントを割り振るかどうかという話しになった。スクラムマスターは5ポイント割り振ればよいと以前話していた気がする。そのときは時間がなかったから反論しなかったけど、ポイントと工数は別だからそれはよくないと反論した。割り当てたストーリーポイントに対して「○○さんならどのぐらいの時間でできますか？」と質問しているのがすでにおかしい。便宜上、ストーリーポイントはベロシティを計測して時間にマッピングされるかもしれないが、ストーリーポイントを直接時間にマッピングし始めると、担当者の個人差で大きく運用が変わってきてしまう。ストーリーポイントとスケジュールのアンマッチな部分を実際のスクラム運用でどう改善するのか？をつぶやいていたら、みずおちさんが返信してくれた。

うーん、なるほど。。文脈によって色々ですが基本的に3か月以上先の見積もりについては妄想のようなもので、当てられないのではと自分は考えてますね。当てられるとしたら、何の技術的挑戦もないプロダクトなんだろうなと思ってしまいます。

— Mizuochi Keita 水落啓太 (@mizuochikeita) August 9, 2022

見積もる期間をなるべく小さくしてスケジュールを提示しないというのが戦略として正しいと思う。

あと実際には、打ち合わせの日程調整やレビュー待ちなどの待ち時間もあり、ストーリーポイントの複雑さや開発の工数だけでなく、リードタイムの概念もある。スケジュールは納期が決まっているけれど、リードタイムが伸びてしまったときに納期は伸びてくれないのでそのギャップもなにかしら反映する必要はあるが、ストーリーポイントではチケットの依存関係やリードタイムの遅れを反映することはできない。

リファレンス

• スクラムにおける技術的スパイクの進め方

0時に寝て8時に起きた。起きたら豪雨だった。梅雨明けが早かったから水不足の土地には恵みの雨だなとか思った。

「緊急対応」という種別

先週のリリースに際して発生した問題に「リリース時緊急対応」という種別が設けられた。当時、私はその種別を設けることそのものに否定的なコメントを発したのだけど、誰かがすでにその種別を作ってしまっていて、いくつかのチケットに設定されていたので成り行きで使うことになった。そして、もうリリースしてから1週間も経つのに未だに「緊急対応」というチケットがいくつも作られている。1週間も運用しているのに緊急もへったくれもないだろうと指摘して、明日から新しいスプリントが始めるので「緊急対応」という種別を付けるのはやめようと提案した。一般的な課題管理システムは緊急度と重要度の2つをもっているけど、backlog は優先度しかない。それでも優先度があるのだからそれを設定すればいいだけなのに優先度を使った運用をしていないのと、課題一覧をフィルターするのではなく、大半のメンバーがカンバンしか使えないといったスキル不足もあって、なくてもよい無駄な種別をまた増やしてしまった。

カンバンはシンプルな要件に使うならよいけど、一定以上の複雑さをもつ普通の会社の開発プロジェクトに使えるようなキャパシティをもっていない。それなら最初から使わない方がよいのではないかと考えるようになってきた。というのは、非開発者にとってカンバンは簡単に使い始められる分、そこからさらに高度な検索フィルターを使いこなすスキルアップを阻んでしまう。複雑な要件をカンバンで実現しようと考えてしまってバッドノウハウ的なアプローチをしていく。その典型例が「緊急対応」という種別作ればいいやんみたいな考え方。

クレジットカードの有効期限の更新

前に yj カードが paypay カードに置き換わったときに有効期限が更新されてクレジットカードの設定更新が必要になると書いてあった気がする。4月8日に paypay カードが届いたみたい。クレジットカードの引き落としタイミングのせいか、しばらくは有効期限が異なっていても paypay カード側で決済を許可していたのか、いずれにしても最近あちこちでクレジットカードの引き落としに失敗するという通知がくるようになった。気付いたら、クレジットカードによる セカンドハーベスト・ジャパン さんの寄付の引き落としも止まっていた。通常、有効期限前にクレジットカードが更新されることはないからサービス側で有効期限が近づいてきたときに更新依頼通知を送っているのだと推測する。寄付みたいなところは引き落とし失敗になると督促しないのかもしれない。もう1つ 国境なき医師団 さんにも寄付しているが、こっちは銀行口座からの引き落としだった。クレジットカードと銀行口座の違いとして有効期限の有無が違う。どちらもメリット・デメリットがあるからずっと払い続けるつもりなら銀行口座、自分が死んだ後にいずれ停止してほしいならクレジットカードを使った方がよいといった考え方もできると気付いた。

0時に寝て6時に起きた。だいぶ復調してきて朝起きれるようになってきた。

歯科検診

3ヶ月ごとの定期検診。前回 は2年ぶりにレントゲンをとったので新しい歯のレントゲン写真をみせていただいた。とくに変わりなく、親知らずにゴミが溜まるスポットがあるから、親知らずを抜いた方がいいのはいいけど、下側の親知らずを抜くのは大変だから痛くなってからでもよいかも？みたいな話しをした。いま3ヶ月ごとに定期検診して親知らずのゴミスポットの掃除をしてもらっているからそれでもしかしたら大丈夫なのかもしれない。あと1箇所だけ銀の詰めものと歯が精密に一致していないところがあって、その隙間にゴミが溜まりやすいとのこと。急がなくてもよいけど、いずれ付け直した方がよいらしい。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題は次の3つ。

• お手伝い先の契約更新についての話題
• カフーツさんとワーケーションの話題
• jjug ccc 2022 spring ふりかえり

先日の記事 でも「余白」という概念が個人的にはまったのであちこちで余白談義をしている。デザインで言うところの余白とは何かをはらさんに聞いてみたところ、次のようなものだという。

• 空白というコンテンツである
• 他に使ってはいけない領域である

開発における余裕とかゆとりのことを余白と言ってしまうと、デザインの文脈とは一致しないという話しになった。ワーケーションの文脈では予定調和じゃない時間を指すといとうさんは仰っていた。何かをやるための計画を立てた時間ではない。何もしなくてもよいし、思いつきで何かをしてもよい。先日の記事で、課題管理の文脈でメタ課題の抽出や他人のチケットにコメントしたりするのも余白の1つではないかと私が書いたのはその行動が必須というわけではない。誰かから指示されてやっているわけでもないという行動が、ワーケーションにおける予定調和じゃない行動と共通点があるのではないかと考えたから。

私が開発における余白を余裕やゆとりのように解釈して発言したので余っているものというニュアンスになってしまったけど、その時間は余っているものではなく、明示的に明けておくべき時間のように捉えたらデザインの文脈で言う余白にも近い概念になるかもしれない。開発だと想定外の追加作業や要件漏れなどのために確保しておく時間をバッファと呼んだりもする。例えば、開発の作業時間を1日8時間、1週間(5日間)で40時間と見積もるから余白がなくなってしまうであって、仮に1週間の余白を3時間と先に確保してしまって、37時間を開発の作業時間としてしまえば余白がなくなるということない。その余白時間に業務に関係ない勉強会をやってもいいし、自分の調べたいことに費やしてもいいかもしれない。私が金曜日を非稼働日として業務委託の作業をやらずに雑談していることにも通じる。

その後、余白談義からスクラムの課題や展望の話しなどにも発散して盛り上がった。スクラムには余白がないから。まだまだ私自身、余白の言語化に曖昧なところがあるので今後も意識しながら概念や価値を言語化していくように努めたい。

0時に寝て7時に起きた。前日は移動による運動量が多かったせいか、なぜかよく眠れた。

ストレッチ

今日は朝から調子よいなと思っていた通り、開脚幅は開始前161cmで、ストレッチ後163cmだった。ここ数週間は162cmが上限になっていたので久しぶりに163cmにになった。先週末に休息の時間を多めに取ったせいか、腰の張りもいつもよりは小さかったように思う。

カフーツさん訪問

ストレッチを終えてから神戸駅の近くのカフーツさんに行ってきた。コワーキングスペースのあるイベント でみかけた縁で ブログJelly Vol.120 に参加した。イベントの趣旨としてはブログを書いて、参加者に共有して、ブログの内容について参加者同士でコメントしあうといったもの。参加者は3人だったので必然的に濃いコミュニケーションになった。

私は、明日の jjug ccc 2022 の参加報告ブログの下書きを書いたものの、まだ公開はできないのでリポジトリにコミットした markdown を共有しつつ、既に公開済みのワーケーションの記事をイベントの参加者に共有してみた。いとうさんはワーケーションにも詳しい方なのでワーケーションの定義を間違えているよと教えてくれた。その間違いは私だけでなく、一般的 (日本？) にもよく誤解されているという。まず2泊3日のような短期の滞在をワーケーションとは呼ばない。

日本の「ワーケーション」という言葉の使い方は間違ってて、冒頭、お書きのように、海外で言うところのワーケーションは1ヶ月〜3ヶ月、そこに滞在して地元に溶け込んで観光ではなくて「余白」を作って楽しむ、というものなんですよね。バケーションなので。会社員はムリですが（はっきり言いますけど）、デジタルノマドなリモートワーカーは自分の時間と仕事をコントロールできるので全然OKなわけで、なのでみんな会社員やめたらいいのにと思ってます。

ぼくらの解釈は「余白」はあらかじめなにも予定しない時間、ということです。行った先の成り行きでやることを決める、そのための余剰の時間ですね。だから普段やらないことをやってもいいし、本読んで内省してもいいし、ボ〜っと一日過ごしてもいいし。でも、行った先の地元の人たちとつながる、そこに余白を使うことが望ましいと思います。でもそれも出会い頭が面白いですね。

ワーケーションについてなんやらかんやら雑談しているうちに、いとうさんもテンション上がってきて有料記事をプレゼントするからこれ読めってノリで記事を紹介していただいた。

• 106ヶ国からの入国許可と『絶対行くべき世界のコワーキング＆コリビングBEST20』が指し示すこれからのローカルコワーキング〜国内企業社員より海外のデジタルノマドにフォーカスしたコリビングのすすめ〜小さなコワーキングの作り方＃2

いとうさんと 「余白」 という概念について議論していて、ずっと自分の中にあった言語化できていなかった概念とも紐付いた。本当によいキーワードを知ることができた。ワーケーション中にはらさんと話していたときに 時間をかければできるものじゃないことをやった方がいい と感じことに言葉を割り当ててくれた。昔の開発と比べて、いまの開発は余裕やゆとりが全然ないと私は思っていて、開発者が自由に調査したり開発したりできなくなっているように感じている。それは「リーン」という概念が幅をきかせていて無駄を減らし、効率を上げることばかりを邁進した結果として「余白」もなくしてしまっているように思う。開発に限らず課題管理の文脈でも、メタ課題の抽出や分類・整理も、他人のチケットにコメントをすることも「余白」の1つと言えるかもしれない。

13時に訪問して、ブログを書き終わったのが15時過ぎで、それから17時過ぎまで適当に作業をやって、その後ビールを飲みながら3人で雑談していて、気付いたら23時20分になっていた。基本的に私は人見知りなので初対面の人たちとそんな長く話すこととかないんだけど、なぜか意気投合していろんな雑談をしていた。コワーキングやワーケーションという分野と課題管理の分野は交錯する点や共通点がいくつかあって、私が課題管理の文脈からこうじゃないか？と言うと、異なる視点からいとうさんが答えるみたいなやり取りになって盛り上がっていた。別分野の経験豊富な方と話すことで多くの気付きを得られるのも「余白」がもたらす価値と言えるのかもしれない。

2時に寝て6時に起きた。疲れていたからよく眠れた。

mvp（minimum viable product）で対応した

スクラムに限った話しではないと思うが、プロダクト開発をしていると mvp（minimum viable product）という言葉を聞くことがままある。昔ながらのイテレーション開発よりも、アジャイル開発の文脈でよく使われるように思う。というのは、短い開発期間でプロトタイプを作ったり、最低限の動く機能を作ったりすることをよしとする考え方があるから。昔ながらのやり方だと、イテレーション期間の中でそういった段階的な開発はするものの、外部からみたとき (もしくはマイルストーン) においてはそこそこの機能が提供されているので mvp といった言い方をすることはなかった。もしかしたらアルファとかベータとか呼んでいたかもしれない。最近ある lambda 関数の移行作業を行った。serverless framework でデプロイしていたリソースを cdk で一元管理する。その過程で既存のコードを読むと、ある id をハードコーディングで指定して FIXME がこんな感じに書いてあった。この id が指すリソースはその後なくなっており、本番環境で不要な処理が定期実行でずっと動き続けていたのと、本来は複数の id リソースに対して行うべき処理を実行していなかった。

# FIXME 対象 id 一覧を取得する。(Phase2までに対応します)
id = 'ABC001'

チームの開発リーダーはその存在を全く忘れていたし、このスクリプトを実装したさらに上位の開発リーダーからはこの処理の要否はよくわからないからチームで確認してという曖昧な返事が返ってきた。チームで確認したところ、この処理は必要だとわかり、この機に複数の id リソースに対して対応するようにした。何も知らない私が修正しても5分で対応を完了した。

mvp で対応したんで

このように実装者は話していたが、本当なのだろうか？と思えた。さらにこのスクリプトのエラーログのログストリームを監視して slack 通知する lambda 関数も移行対象で、コードの検証をしていたところ、slack 通知をするための lambda 関数が別途あり、その動作検証をしていたところ、その lambda 関数を呼び出す権限 lambda:InvokeFunction が足りないことに気付いた。これも実装者に問い合わせたところ、動作検証はやっていないし、過去に1度も slack 通知は発生していないという。状況証拠から考えると、権限が足りないために正常に動作していなかったと推測される。結果的に mvp で対応したという2つの lambda 関数は実運用で半年間、無駄にリソースを浪費して何の役にも立っていなかった。当然、引き継ぎも、課題管理システムのチケットも、ドキュメントも何ら残されていなかった。mvp で対応したという表現に開発で大事なものを誤魔化してはいないだろうか。