デバッグしていて遅くなり、帰ってから慌ててスーパーに買いものへ行ったりしていて時間がなくなったので今日はバドミントン練習をお休み。

データベースとメッセージキューの整合性を考える

昨日の続き。トランザクションを導入したことで mongodb と mq でのデータフローが意図せず変わってしまっていることが調査してわかった。

従来は次のように動いていた。

1. api サーバーがエントリー情報を受け取る
2. api ハンドラーがエントリー情報を mongodb に保存する
3. api ハンドラーがメッセージを管理するジョブ情報を mongodb に保存する
4. api ハンドラー内の producer が rabbitmq にメッセージを送信する
5. consumer がメッセージを受信する
6. consumer が mongodb からジョブ情報を参照する
7. api ハンドラーがレスポンスを返す
8. consumer がメッセージを処理する

トランザクションを導入したことで mongodb にデータが保存されるタイミングが変わってしまった。

1. api サーバーがエントリー情報を受け取る
2. api ハンドラーがトランザクションを開始する
3. api ハンドラーがエントリー情報を mongodb に保存する (この時点では未コミット)
4. api ハンドラーがメッセージを管理するジョブ情報を mongodb に保存する (この時点では未コミット)
5. api ハンドラー内の producer が rabbitmq にメッセージを送信する
6. consumer がメッセージを受信する
7. consumer が mongodb からジョブ情報を参照するが、トランザクションがコミットされていない可能性がある
8. api ハンドラーがトランザクションをコミットする
9. api ハンドラーがレスポンスを返す
10. consumer でエラーが発生する

処理の流れを見直して次のように改修した。内部実装の都合があってやや煩雑な変更となった。

1. api サーバーがエントリー情報を受け取る
2. api ハンドラーがトランザクションを開始する
3. api ハンドラーがエントリー情報を mongodb に保存する (この時点では未コミット)
4. api ハンドラーがメッセージを管理するジョブ情報を mongodb に保存する (この時点では未コミット)
5. api ハンドラーがトランザクションをコミットする
6. api ハンドラー内の producer が rabbitmq にメッセージを送信する
7. consumer がメッセージを受信する
8. consumer が mongodb からジョブ情報を参照する
9. api ハンドラーがレスポンスを返す
10. consumer がメッセージを処理する

これは単純にトランザクションのコミットタイミングと mq へのメッセージ送受信のタイミングを見直せばよいという話しではない。本質的に mongodb で管理しているジョブ情報と rabbitmq へ送信しているメッセージの整合性を保証することはできないということを表している。producer はメッセージ送信に失敗する可能性があるから、そのときにジョブ情報を書き換える必要はあるが、その前にトランザクションをコミットしてしまっているため、api ハンドラー内でデータのコミットタイミングが複数になってしまう。トランザクションを導入したメリットが失われてしまい、Unit of work のパターンも実現できない。consumer の処理に必要な情報を mongodb にあるデータとメッセージの2つに分割しているところが整合性の問題を引き起こしている。アーキテクチャ上の設計ミスと言える。consumer の処理に必要な情報はすべてメッセージに含めてしまい、メッセージを処理した後に mongodb に結果を書き込むといった設計にすべきだった。

初期実装のときからジョブ情報を mongodb で管理する必要はあるのか？という懸念を私はもっていた。要件や機能が曖昧な状況でもあり、メンバーもなんとなく db に管理情報を残しておいた方が将来的な変更に対応できて安心といった理由だったと思う。当時は整合性の問題が起きることに、私が気付いていなかったためにこの設計を見直すように強く指摘できなかった。トランザクションを導入したことで consumer が必要な情報を db に保持すると、db とメッセージ処理のタイミングにおける整合性の問題が生じるという学びになった。

いまとなってはこのジョブ情報を使う他の機能もあるため、この設計を見直すことはできない。今後の開発プロジェクトで db とメッセージを扱うときはこの経験を活かすためにふりかえりとして書いておく。

今日のバドミントン練習はエアシャトルでリフティングを10分、連続最大回数は322回だった。その後にショートサーブ30回、フットワーク10分の練習をした。リフティングは連続回数よりもラケットコントロールの質を求める練習に変えていく。昨日と同様、みなとのもり公園をジョギングで4週走った。fitbit によると 1.8km 走ったそうな。

プロジェクトマネージャーが手を動かすことの功罪

朝からお手伝い先の社内インフラサーバーが落ちていて待ち時間があったのでふと思い返してつらつら考えごとをしていた。

お客さんが選ばなければ、逡巡と葛藤の結果、最終的に私は品質を優先する

開発合宿の課題管理の雑談から引用

私はもっと仕組みを作るところに注力すべきだった。私自身がコンサル嫌いの、実務をやっている姿勢をみせてメンバーが参考にしてほしいという意識が強過ぎた。また開発は楽しいことから必要以上に手を動かし過ぎてコアな開発に入り過ぎたことで、自分がやらないと他のメンバーが担当しにくい体制になってしまった。「任せる」はずが「任される」ことになってしまった。バックエンドの品質は大事だから責任感もあった。もしかしたらお客さんが求める以上の過剰品質なモノづくりをしてしまったのかもしれない。そして、仕組みづくりの後はメンバーへ委譲すべきだった。いまメンバーへマネージャーを委譲しているが、マネージャーという業務はもともと得意でもなくこだわりもなかったがためにすんなりと委譲できた。

しかし、開発の方は得意分野、且つ好きであるために品質にこだわってしまう傾向があることを認識できた。そのことが裏目に出てしまった。これが自社プロダクトの開発ならばすべて自社の資産になるためにそれでもよかったかもしれないが、他社プロダクトでやってしまうと、自分の時間を必要以上に注ぎ込むことになってしまった。その結果、お客さんの信頼を得られてはいるものの、自社プロダクトの開発に着手できず、クロージングの時期が遅れて微妙な状況になってしまった。もしかしたら、お客さんもうちの会社との契約を終了できなくなってしまって困っているという考え方もできる。

rabbitmq の autoAck (noAck) の振る舞い

先週の続き 。id 連携のリクエストをし続けながら compose サービスを down させたときの振る舞いを検証する。理想的にはそれぞれのモジュールのサービスが graceful に振る舞って、それぞれの永続化する場所でデータが溜まってくれることを期待している。その1つがメッセージキューでもある。Persistence Configuration によると、rabbitmq のメッセージを永続化するには queue に対して durable の設定を行い、producer が送信するメッセージに対しても persistent の属性を付与すればよい。しかし、実際に検証してみると、サービスの再起動時にメッセージキューからメッセージが消失していることがわかった。consume メソッドに渡す仮引数に autoAck というパラメーターがある。コメントにもそれっぽいことが書いてある。

When autoAck (also known as noAck) is true, the server will acknowledge deliveries to this consumer prior to writing the delivery to the network. When autoAck is true, the consumer should not call Delivery.Ack. Automatically acknowledging deliveries means that some deliveries may get lost if the consumer is unable to process them after the server delivers them. See http://www.rabbitmq.com/confirms.html for more details.

ConsumeWithContext

autoAck という名前からメッセージを取得したら自動的にそのメッセージに対して ack を返すようなイメージで私は考えていた。しかし、どうやら consumer が subscribe して接続した時点で consume 扱いとなり、consumer がメッセージを実際に取得したかどうかに関係なく consumer の終了時にそのときに溜まっているすべてのメッセージが消失しているようにみえる。余談だが、rabbitmq のドキュメントにも noAck と autoAck という2つの用語が存在する。どうやらもともと noAck という名前だったのを autoAck という用語に変更したようにみえる。メッセージを永続化するには autoAck=false にしてメッセージに対する処理を完了した後に consumer が必ず ack を返すという実装にしないといけないことがわかった。このパラメーターは2年前から同じ設定だったので私がいま検証するまで誰もこの振る舞いに気付かなかったんやと驚いた。

部屋の掃除

19時に閉まる業務スーパーへ買いものへ行くために18時過ぎにお仕事を終えて、移動して買いものをして、炊飯開始して、ジョギングして、戻って晩ごはんを食べて、バドミントン練習をして、お風呂に入って、ストレッチして、なんとなくベッドに入って休もうとした。ここで22時半ぐらい。まったく眠れなくて寝室の掃除を始めたら、これが捗ってやる気が出てきて、部屋のレイアウト変更したりして少し片付けもできた。引っ越してからまったく進めていなかった部屋づくりが突発的に急に少しできた。これまでも時間がなかったわけではないが、まったくやる気がなくて手をつけられていなかった。それがなぜできたのかはわからないが、手をつけられていなかったことに手を入れられたことで心理的に楽になった気がした。明日も帰ったら少しだけ部屋づくりの作業をしようと思う。

今日のバドミントン練習はお休み。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日は先週末の開発合宿のふりかえりをした。

• 1週間前ぐらいに参加者を集めて事前打ち合わせをして過ごし方の共有をした方がよかった
• 周りと雑談してしまうので資料を合宿中に作るのはほとんど時間を取れない
• もう3回目なのでお風呂へ入るのにも慣れが出てきてお気に入りの外湯へ行くようになった
• 人数はどのぐらいが適正か？
  • 5人という人数は中途半端だったように思える
  • 8人は多過ぎた気はするから6人がちょうどよいのではないかと思える
• 周辺の体験イベントにみんなで参加してみるのもよいかもしれない
  • あらかじめ希望をとっておく
• 発表の時間を初日と2日目に分割したのはよかった
  • 夜に発表を固めなくてもよい
  • お昼でも夕方でもみんなが集まっている時間帯にさらに分散させるのがよさそう

細かいところはいろいろあるけれど、覚えているうちに意見をもらった。いつもはらさんが来てくれるから私の負担が低くなり本当に助かっている。

compose サービスの停止の振る舞い

昨日の続き 。それぞれのサービスに depends_on を指定することで依存関係を定義できる。サービス起動時と停止時に依存するサービスが先に起動または停止するように順番を制御してくれる。但し、起動時のデフォルトはコンテナ起動をトリガーにするため healthcheck などを指定しないと厳密にサービスが起動しているかどうかはわからない。

• Control startup and shutdown order in Compose

compose サービスの起動は次の2つのコマンドがある。

• up: すべての依存関係を調べてコンテナサービスを起動する、停止しているコンテナがなければ作成する
• start: 停止しているコンテナのみを起動する

基本的には up を使っておけば運用上の問題は起きない。start を使う理由がなければ up を使うといった感覚でよい。一時的なメンテナンスなどで stop を使ってコンテナを停止し、そのコンテナだけ起動すればよいことがわかっていれば start を使った方がオーバーヘッドが少ないといったメリットはあるだろう。up と start の違いはそれほど気にしなくてもよい。

次に compose サービスの停止は次の2つのコマンドがある。

• down: コンテナを削除する、関連するリソース (volume や network) もすべて削除する
• stop: コンテナを削除せずに停止する

運用上どちらか一報を覚えておくなら down を使えばクリーンに再起動できると言える。コンテナが使うイメージのバージョンアップをするときなどはコンテナを削除する必要があるから down する方が手間がいらない。stop で停止したコンテナがあると、up でも start でもバージョンを自動的にあげてくれたりはせず、ただ停止したコンテナを起動するといった振る舞いになる。そのため、バージョンアップをするときは stop で停止した後に rm でコンテナを削除する必要がある。それなら最初から down で削除してしまってもよいと言える。compose の logs コマンドを使うと複数サービスのログを1つのストリームで監視できる。この状態で stop や down を実行してどういった振る舞いになるのかを検証できた。

• Docker compose stop VS down

$ docker compose logs -n 3 -f

今日の運動はジム筋トレ,縄跳び(両足跳),散歩,ジョギング,ハンドグリップ,ダンベルをした。統計を 運動の記録 と 筋トレの記録 にまとめる。ジョギングの後に 右股関節の改善体操 をした。どこかのタイミングで今月からは運動を監視するのをやめて別のことへ移行していく。

隔週の雑談

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

• お手伝い先のプロジェクト近況

今週の出張でお手伝い先でのふりかえりや進捗報告の要旨などを共有しつつ、うちの会社の課題管理ビジネスへの取り組みについて雑談したりした。ここ2-3ヶ月は私がバテてしまい、休日もオフィスへ足を運んでいるものの、運動したり日記を書いたり趣味の調べものをしたりと、のんびり過ごしていることが多い。課題管理ビジネスへの集中力が途切れてしまった。はらさんも上半期は自分のプロダクト開発などをやろうと考えていたものの、あまり想定したように進捗せず、下半期は他社のお仕事のお手伝いで忙しくなってくるらしい。はらさんは よりひろいフロントエンド を作ったり、最近は Apple Vision Pro のアプリ開発をされている。私と似たような状況だなと話しを聞いていて次のようなことを話された。

歳をとると自分を騙すのがうまくなる。うまくいっていない言い訳を、もっともらしく、自分で受けいられるように作ってしまう。
危機感をもたなくなる。うまくいっていないことや結果が出ていないことを直視しないといけない

まさに私にも当てはまることでこの2-3ヶ月の自分をみているみたいだ。私自身、今年はほとんど休まず会社のことばかりやってきたから、たまにはだらだらする時期があってもいいのかな程度に自分への言い訳をしていた。はらさんとは隔週で雑談する機会を設けている。こういう話しをするだけでもこの雑談には意味がある。これが自分ひとりだと、自分への言い訳をして、何もしないままどんどん時が過ぎ去っていくだけだったと思う。誰だって自分のネガティブな側面を直視するのはつらいから無意識に目を背けてしまう。信頼できる人たちからそういうことを指摘してもらって自身を省みるきっかけになればと思う。

いそがみの筋トレ

前回の所感 。19時過ぎから出掛けて、トレーニング器機の待ち時間などもあって21時前まで筋トレしてきた。出張中ずっと運動していなかったので行く前はやや面倒に感じていたが、やりきったら達成感があって行ってよかったと思えた。週2-3日のペースで筋トレや運動を継続していくのが心身ともによさそう。慣れてきたモノへのやる気はやり始めてから出てくる。なによりも大事なのはやり始めること。

体育館のトレーニングルーム通いも気付いたら5回目になった。少しずつ成果は出ていて、器機によっては重りをあげたり回数を増やしたりできるようになったのもある。そして終わってから外で縄跳びをして、ハンドグリップをしながら帰ってきた。これも筋トレした後だとややカラダがだるいのもあるけど、跳び始めてしまえば出来てしまう。毎日の運動は時間を取られて他のことが疎かになってしまった現状があるため、今後は週2-3日の筋トレの機会に集中して運動していくよう、日々の生活を変えていく。

日経平均株価の急落

fin-py という金融関係者向けのコミュニティがあり、数年前から参加している。何人か仲のよいメンバーもいるし うちの会社の顧問税理士さん もそのメンバーの1人でもある。老後の心配が出てくるのか、日々の生活が安定すると将来の生活に目を向ける余裕が出てくるのか、人生においてお金の話しは歳をとってから関心が出てくる話題の1つだと思う。

• 株価 終値2200円以上値下がり 終値では過去2番目の下落幅

下落幅は1987年のブラックマンデー以来、史上2番目らしい。一方で下落率でいうと 5.81% で史上30番目になる。2008年のリーマンショックでは下落率が11.41%と、この倍以上であったことからそこまで不安を煽る状況でもないが、メディアは不安を煽った方がニュースバリューになるからこういう見出しになるのは仕方ないらしい。米国の経済事情だったり、為替の円高転換などの要因で日本株が急落している。fin-py で時事のニュースなどをやり取りしていたのもあり、為替の円高転換は Exclusive: BOJ to weigh rate hike next week, detail plan to halve bond buying, sources say の記事が出た7月24日ぐらいから注目していた。私の投資のポートフォリオも徐々に含み益の保有株を売ったりして、円高になって株価が下がってもよいように準備していた。今日の急落にも備えていたから投資資金の50%ほどは含み益の状態で売却できた。今日の取引終了後も為替は円高に進んでいるし、日経平均先物も悪化しているので月曜日もさらに下がりそうにみえる。これでしばらく為替は円高へ進んでいくのかな。その状況を確認しながら追加でポートフォリオを変更してもよいかもしれない。しばらく為替や株価の変動が大きいだろうから落ち着くまで見守ろうと思う。fin-py で日々の経済のニュースなどを見聞きしているうちにその先の展望を推測して対策を講じたり準備したりできるようになってきた。これまでは起こった状況で気付いて含み損になってしまって何もしていなかった。急な変動が起こりそうな気配や背景を知っていると、準備ができていて、ポートフォリオを機動的に変える決断を早くできる。

たまたまこんな日に 任天堂 2025年3⽉期第1四半期 決算発表 があった。もともと2025年3月期の通期の業績は前期よりも悪くなることが以前からわかっていたのになぜか株価は高止まりしていた。今回の為替の急な円高 (任天堂は海外の売上比率の方が大きいため、円高になると為替差益が減る) と、第1四半期の業績も市場予測よりも悪かった？せいか、月曜日は株価が急落するようにみえる。以前から株価が高過ぎるのと、どこかで為替の円高転換もあるだろうと、2月頃から少しずつ空売りしていた。最悪の時期は任天堂の空売金額が-10%ほどの含み損になっていたものの、(想定したよりも過激な円高がやってきて) 今日の時点で3%ほどの含み益になっている。おそらく月曜日から任天堂の株価は急落すると推測される。

以前 オプトラン という会社について書いた。ここも半導体産業、且つ為替で業績に影響を受ける会社になる。ずっと観察してきたし、ボラティリティが高いのでポートフォリオに入れたり出したりする定番の会社になっている。今日の時点では、おそらく思惑？だけで1711円と株価が急落している。過去の最安値が1420円、年初来最安値が1561円になる。1500-1600円台まで株価が落ちれば2-3年後のために投資していくのによいんじゃないかと注目している。

今日は出張中で飲み会があったので運動はおやすみした。

4次開発の大きなふりかえり

前回の大きなふりかえり 。約4ヶ月の開発フェーズが終わってからの大きなふりかえり。もう4回目なのでメンバーも慣れてきたし、過去の知見もたまってきた。そして、私がいまあまり調子がよくないのもあってなにか目新しさがなくなってきたところでもある。今回の開発は2つの大きな失敗があった。

• 想定していた開発機能を1つ落とした
• QA 検証を網羅的に進めることができなかった

これらは私のマネジメントの失敗になる。これまでうまく進み過ぎていたと言えるのかもしれない。プロジェクトマネジメントは毎回うまくいくとは限らない。スクラムガイドにもある見積もりより経験主義の重要性を認識する開発期間でもあった。これまでの順調な進捗に、私自身マネジメントの驕りがあったのだとも思う。次の開発フェーズでまた気を引き締めてプロダクトの品質を担保していく。

いつも通り gitlab の統計情報を眺めながら定例イベントのふりかえりなどもやっていった。UI 周りのふりかえりを口頭での報告や文章で表現するのが難しくなってきたという意見があった。UI は画面の操作をみないと本当の意味で理解するのは難しい。テックブログを読む会も、自分が読みたい記事をすぐにみつけるのが難しいから事前に読みたい記事を探しておくといった「準備」をするメンバーもいる。実は私もたまにその準備をしているのでその気持ちはわかる。記事を探すという作業には一定の時間を取られるという事実がわかってきた。

記事を読んだ後に軽く雑談する時間があってもよいのではないかという意見もあった。これはこれであってもよいとは思う。ふりかえりは隔週でもよいが、メンバー間での確認事項は毎週やった方がよいのではないか？という意見も出た。これは話す必要があるときにハドルすればいいでしょうというところで一旦は見送った。みんなで集まる会議時間はコストが大きいので慎重に判断する。1on1 の隔週30分もそろそろ調整や見直しがあるかな？とも考えていたけど、逆にメンバーからはなんやかんやで30分話すことはあるからこのまま継続した方がよいといった意見も出ていた。

開発のやり方がだいぶ定着してきて、大きなふりかえりも1つの型ができて落ち着いてきた感じはある。よくもわるくも。

同期との飲み会

たまたま新卒で入った会社の同期から連絡がきて、関西で働いている同期が2年ほど単身赴任で東京出張になるらしく、久しぶりなので飲みにいこうという話しになった。本当は4人で飲む予定だったのが、1人がお仕事でドタキャンになって3人で飲んできた。10年以上会っていなかった同期だから近況を話すだけでもおもしろかった。今日会った3人に見た目は昔とあまり変わってなかった。私は体脂肪コントロールした後でよかった。ある同期は課長になっていて、単身赴任である省庁へ出向になった。外からみたら国家公務員やね。本当は話したらダメなんだろうけど、同期というよしみもあって飲みながらいろいろと話しを聞いてた。ここには書けないが、おもしろかった。飲み過ぎた。

私は最初の会社を3年でやめたものの、飲んだ同期たちはもう20年以上、1つの会社で働いているわけで価値観もだいぶ違うだろうと思う。同期って本当によいもので、価値観が違っても会社が違っても未だに仲良く気軽に話しができる。私はたまたま新卒で入った会社が大企業のグループ企業だったから100人ほど同期がいて、5つのクラスに分かれて30人ぐらいのクラスで4ヶ月ほど研修を受けた。いまとなってはその頃の同期とはほとんど会わないし、みんながいま何をしているのかも知らない。おそらく半分以上はその会社をやめてしまっていると推測する。やめた同期とも会う機会があれば楽しく話せるとは思う。

引っ越し当日のため、運動はお休み。今日の消費エネルギーは 5,862 カロリーを記録した。観測史上最大の値となる。引っ越しはしんどい。

引っ越し当日

4時頃に起きて、荷造りは完了できていなかったが、夜中に往復して疲れていたからそのまま寝た。7時台に起きて荷造りを続けて、9時半頃に段ボールが足りなくなった。大サイズの段ボールを10個購入していて十分だと考えていたが、見積もりが甘く、1-2つ足りなかった。10時から慌ててダイソーへ行ってやや小さめの段ボールを5つ買って、すべての荷造りを終えることができた。荷造りのやる気がなくて、だらだらやりながら、荷造りを終えたのが11時頃、引っ越し開始の1時間前だったと思う。

そして、見出しに大げさな表現を使った。しかし、私にとってはそのぐらいの偶然、反省、感謝、想定外といったさまざまな所感をもつ引っ越しとなった。こんな紙一重な綱渡りで引っ越しすることは後にも先にもないだろう。引っ越しはいつもの レントラ便 さんにお願いしていた。結果から言うと、12時に開始して13時43分に引っ越しを完了した。レントラ便の業者さんを12-14時で依頼していたため、結果だけをみればちょうどよい時間におさまった。しかし、これは奇跡の結果だと言えた。

• 退去側も入居側も管理人から養生の不備について怒られる
  • 仕方ないからその場の勢いで誤魔化して引っ越しを敢行した
  • 管理人さんが怒り出さないよう、なるべく愛想よく振る舞って機嫌をとった
• ながいさんとわたなべさんの2人が手伝いに来てくれたから荷物運びを効率よくできた
  • 部屋から荷物を出す・入れる係 (私)
  • 台車で部屋からトラックへ運ぶ係 (ながいさん・わたなべさん)
  • 荷物をトラックの荷台に積み込む係 (業者さん)
• レントラ便では1tバンを依頼したのに、業者さんは2tアルミバン車で来てくれた
  • すべての荷物を積み込み、1回で荷物を搬送できた
    • 当初の予定は近所だから1tバンで2往復するつもりだった
  • 搬出・搬入経路を養生しないといけないことから2往復は物理的に不可能だった
    • 2箇所に養生シート／テープを設置する分量も時間もなかった
• 搬入時に業者さんの養生シート／テープの分量が足りないという状況が発生した
  • 業者さんによると、管理人さんから台車は使うなと怒られたとのこと

もともと私の頭の中に想定していた引っ越し作業では間違いなく完了しなかった。

• 引っ越し前日の夜が快晴でなければ非定形の荷物を運べなかった
• 引っ越し当日は引っ越しを終えてから雨が降り出した (14時15分ぐらいから)
• 退去／入居先マンションで養生を強制されること (時間／作業) を考慮していなかった
• ながいさんとわたなべさんがいなかったら荷物の搬出・搬入にもっと時間がかかっていた
• 業者さんが2tアルミバン車で来なければ時間内に搬出・搬入を完了できなかった

引っ越し前日からの天候が悪ければ引っ越しに失敗していた。手伝いを依頼した知人が来てくれなかったら引っ越しに失敗していた。業者さんが2tアルミバン車で来てくれなかったら引っ越しに失敗していた。これらのうち、どれか1つでも叶わなかった場合は引っ越しに失敗していた。私の想定した引っ越し計画は杜撰でトラブルプロジェクトそのものだった。過去これほど余力のないぎりぎりの引っ越しをしたことはなかった。引っ越しは滅多にやることではないからふりかえりをしておく。次に引っ越しするのはまた数年後になるだろうから。

• マンションで台車を使うときは養生を強制される
  • 管理人がいるようなマンションだと引っ越し作業を監視される
    • 書類の提出も要求され、事後に提出して先方の機嫌が悪くなった
  • 養生が稚拙だと管理人に怒られたり、台車の使用を止められる
  • これまで養生を強制されるマンションに住んでいなかったから私が気付かなかった
• マンションによって搬出・搬入口が正面玄関ではない場合がある
  • あらかじめ搬出・搬入のための経路を管理人に相談して確認しておく
• 搬出するときに大きい荷物を先に出すから荷室の奥に配置される
  • 荷物を搬入するときは大きい荷物が後半になる
• 賃貸マンションの契約はたいてい退去時は月割り、入居時は日割りとなる
  • 退去は月末にする方がお得になる
  • 入居はいつでも調整できる
• 引っ越しの1週間ぐらい前に入居先の部屋を借りておく
  • 非定形の荷物を自分の車に積んで深夜などにあらかじめ運んでおくと引っ越し当日の効率がよい
  • 段ボールが足りない状況でも、あらかじめ運んでから荷解きすれば段ボールを再利用できる
  • 引っ越し当日を段ボールのような定型的な荷物にすると搬出・搬入の効率がよい
  • 雨があまり降らない時期や季節に引っ越しする
    • 今回は梅雨入り後、たまたま雨の予報が外れて運がよかった
• 洗濯機を搬出するときのホースの水処理が出来ていないと床を水浸しにしてしまう
  • 事前に傾けて水出しをしておく
  • 念の為、水が漏れても拭き取りできる雑巾を用意しておく
• 段ボールのサイズは販売元によって違う
  • 引っ越し屋さんからもらった大サイズの段ボールと amazon で購入した大サイズとはサイズが異なっていた
  • 過去の引っ越しで大サイズの段ボールを10個も使い切ったことはなかった
• レントラ便経由で業者さんに依頼するときは手伝いとして2人雇う
  • 養生作業を業者さん1人で行うと時間がかかる
    • 養生時間が待ちとなって効率が悪い
  • 今回の反省から次の引っ越しは2tアルミバン車にする
    • 退去先と入居先での養生を考慮すると往復なんてできない
    • 今回は1tバンの料金で2tアルミバン車を利用して取り引きが不公平だった
      • 支払い時に2tアルミバン車の料金を支払うと申し出るべきだった

ひどい引っ越しながらも結果として作業は完了した。夕方にカフーツさんへ行って引っ越し祝いと称して、やや羽目を外して飲み食いしてたくさん喋って楽しかった。運動を始めてから飲みに行くことも外食もほとんどなくなっている。たまにそういう機会があるとストレス発散できてよかった。

今日の運動は腹筋ローラー,腕立て,スクワット,縄跳び(両足跳)をした。統計を 運動の記録 にまとめる。

コレクションデータの再定義

ある mongodb のコレクションのデータ定義で _id に ldap の dn の値を使っていた。dn は一意な値なので主キーとして使ってもよさそうに思えたが、ここで運用上 dn の値が変更されるケースがいくつかあることがわかってきた。例えば、dn に姓名が含まれる場合、結婚して姓名が変わると dn の値が変わることはありえる。他にも dn に含まれる ou の値が現実の組織名を表している場合、組織変更によって ou の値が変わったときに dn の値も連動して変わってしまう。一意な値というだけでデータベースの主キーにするのはよくないということがわかってきた。主キーは一意な値、且つ immutable が望ましい。

たとえば mongodb では _id を主キーとして使う。mongodb は主キーの値を変更することはできなくて実装上は delete & insert になる。

• How to update the _id of one MongoDB Document?

delete & insert の運用上の問題は更新時にトランザクションを使わないといけないため、パフォーマンスが悪い。さらに id 連携という業務に特化して言うと、たとえば、姓名の変更は名前が変わったというだけでその人が退職したわけではない。これをシステム上 delete & insert で扱うと、古いユーザーデータを削除して、新規にユーザーデータを作成するといった振る舞いになってしまう。そうすると、古いユーザーがもっていた権限やデータなどを移行しないといけないわけだが、それらをすべて自動化できるか？という難しい課題も積み重なってしまう。本質的に rename を delete & insert で扱うことそのものが誤っているのだ。

メンバーと相談して _id に uuid を発行して dn はフィールドに unique 制約を課して保持するよう設計を変更することに決めた。コレクションのデータ定義の主キー変更なのであちこち修正してテストコードも修正しないといけない。一意な値、且つ immutable な値のみを主キーとして使うのが今回の学びとなった。私自身、初期の設計に関わったときにこのことに気付かなかったから、これは私のレビューの失敗・見逃しでもある。

2時過ぎに寝て6時に起きた。いつも通りよく眠れた。

今日の運動は腕立て,スクワット,縄跳び(両足跳)をした。統計を 運動の記録 にまとめる。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。1時間を10分ほど超えてしまった。

• fun/give/learn を miro に移行した話し
• 城崎温泉の開発合宿ふりかえり
• 睡眠時無呼吸症候群の重症だった話し

はらさんが城崎温泉の開発合宿ふりかえり記事を書いてくれて嬉しい。参加者がもっとどんどん書いてほしいけれど、なかなか難しいみたい。私自身も書こうと思いながらまだ時間を取れていない。ざっくり次のようなことをふりかえりした。

• 城崎温泉／きのいえはよいところなので今後も継続したい
• 最大13人泊まれるが、うちらは屋内で作業するので8人程度がちょうどよい
  • みんなでご飯を食べに行ったり、外へ出掛けたりする上でもこのぐらいが限界
  • 2つの鍋で晩ご飯を食べるのも8人がちょうどよかった
    • 量も味もよくて成功だったと思われるが、🦀は値が張る、近くの市場まで出掛けたらもう少し安くなる？
• 毎年イベントを開催するとしてメンバーをどうするか
  • 既存枠6人、新規枠2人といった内訳で新しい人も入れていきたい
  • イベントの半年前には予約しないといけないため、既存枠は先着にしてしまう
• 一晩ですべての発表をやるのは時間がかかる
  • 発表の後にいろいろ質問する時間をもっと取りたい
  • 1日目と2日目にわけて4人ずつ二晩かけて発表するのを次回試してみる

あと、なにかの話題から発散したときに余談で次のクソ記事について議論した。

• 「MPがすぐに尽きてしまう人」は、企業では救えない。

私もいまマネージャーとして若いメンバーを指導したりしている。その中で人は個人差があって、画一的には扱えないことを実感している。こんな雑で横柄な論調で書けるわけがない。この記事で言及されている、仕事ができない人たちの背景はみんなバラバラだろうし、職種や業態、その人の得意・不得意によっても成果も変わってくるだろう。それを 「いわゆる MP」 のような、用語の定義もない意味不明なキーワードに括って論じてよいわけがない。著者の主張する重要なメッセージがボケているだから、周りの論理も成り立たない。久しぶりにひどい記事をみた。

ふりかえり

一昨日から jamboard 移行 ならびに隔週のふりかえりの運用変更についてまとめていた。せっかくだからそのノウハウなどをテックブログに書いておこうと雰囲気で思い立って、木曜日の夜から着手して、金曜日の午前中いっぱいかかって書き終えた。うちの会社の顧問さんやお手伝い先でも任意でレビューをお願いして、あちこち推敲して次の記事を公開した。ふりかえりの手法ややり方に言及している記事はあまりみかけないから、にっちに受けたりするかな？と思ったものの、まったく受けなかった。いつもは数日寝かしてから sns に投稿したりしている。それは後になって内容の不備に気付いたときに修正する時間を取れるようにという意図でそうしている。今回は3人もレビューしてくれて、文章のわかりにくいところを推敲できたので公開と同時に sns にも投稿してみた。しかし、ほぼスルーだったのであまり関心をもたれる内容ではなかったようだ。残念。

• チームのふりかえりの改善

家族信託の公正証書の作成

15時30分から弁護士さんと母と公証役場で公正証書の作成を行う。旧居留地のど真ん中に 神戸公証センター がある。きらびやかなビルの雰囲気とは変わって、ビル内の公証役場の事務所は普通の役場のオフィスって感じだった。私は公証役場に入るのは初めて。

弁護士さんに作っていただいた家族信託の契約書の内容を、公証人がすべて読み上げ、母と私が正本を見聞きして、最後のその内容を承諾して署名・捺印するという儀式を行う。だいたい1時間弱で手続きが終わった。とくに大変でもなかった。契約書の原本は公証役場で保管するため、公証人から公正証書の正本 (原本と同じ効力をもつ書類) という書類を、母と私がそれぞれに受け取った。この契約書に関する手続きをするときはこの正本を使う。公正証書の保管期間は20年と規定されている。保管期間を過ぎた後に公証役場で破棄されたら無効になってしまう。もし保管期間を過ぎても実は保管し続けている場合もあるし、(理由があって) 連絡すればさらに延長して保管しておいてもらうこともできるらしい。家族信託の契約書が20年後も必要になるのかどうかはわからない。ひとまず1ヶ月以内に正本を使って信託銀行に信託口座を開設しないといけない。来週、三井住友信託銀行の担当者とやり取りする。

公証人と雑談していて、遺言の公正証書は特別な扱いだと教えてもらっておもしろかった。もともと公証役場における遺言の保管期限は120歳だったものの、遺言の場合は亡くなってからも親族でごだごだする可能性があるため 公正証書遺言の保管期限は遺言者が170歳を迎える日まで になったという。例えば119歳で亡くなったと仮定して、相続で親族が揉めてしまうと1年で決着がつかないかもしれない。そのときに遺言の効力がなくなってしまうと遺言者の意図とは変わってしまうため、遺言者の死後も十分に長い期間として50年足して170歳までとなっているらしい。

バッテリー上がり

公正証書の作成し終えたので母を実家へ送り届ける。駐車場にある車に乗り込もうとしてエンジンが全く反応しない。ディーラーさんに電話して症状を伝えると、おそらくバッテリーが上がっているのだろうとのこと。保険会社のサポートセンター経由でロードサービスの方に来てもらった。17時前に保険会社のサポートセンターに連絡して、ロードサービスの担当者が来られたのが17時37分、それから30分ほどでバッテリーを復旧していただいた。エンジンがかからないことに私がパニクってから1時間半ぐらいでトラブルを解決できた。サポートの関係者さんに感謝。

バッテリー上がりの原因は数日前に私が車に荷物を積み込んだ際にルームランプを点けっぱなしにして消すのを忘れていたせいだった。ルームランプは車のロックをかけても消えないという。ロードサービスの担当者もバッテリーを上げてしまう原因として多い原因だという。こんな失敗をするんやなと自分自身でちょっとショックを受けた。今後はなるべく駐車場でルームランプを点けないようにしよう。夜間荷物の出し入れをやめたり、狭いスペースで出し入れせず、広くて明るいところに車を出すなりして、ルームランプを使わない運用にしようと思う。

fitbit の日々の目標の1万歩と2900カロリーの消費を達成するため、23時過ぎから散歩に言って0時前に達成して戻ってきて、CPAP のセットアップする前に疲れてそのまま寝てしまった。

今日の運動は水中ウォーキング,散歩をした。統計を 運動の記録 にまとめる。

google jamboard の移行先

サービス終了するので移行しないといけない。

• Google Jamboard の提供終了について

前にお手伝いしていた会社でよく使っていた Miro でいいんじゃないかと思って実際に評価して、機能性と使い勝手がとてもよかったので、やっぱり miro でいいんじゃないかと結論付けた。お手伝い先では miro を使っていない。偉い人に miro の管理者になってもらって、私のアカウントを招待してもらって、開発メンバーのチームを作ってもらうことにした。

• 付箋に絵文字を付けられる
• 付箋の作成者を表示、確認できる
• 付箋にコメントを付けられる

この3点だけでも jamboard ではできなかったことを実現できて好感触。今後の fun/give/learn のふりかえり は miro のボードを使う。

プール

前に行ったのが2月16日なので約1ヶ月経ってしまっていた。最近は週の半分ぐらいは夜に予定が入っている。打ち合わせや勉強会が入ったり、ちょっとお仕事を残業していたりすると全然余裕がない。プールに入った後に時計をみたら19時19分だった。1時間は運動しようと思って途中に5分休憩があるので20時25分で引き上げてきた。歩いたり平泳ぎしたりを1時間ずっとやってた。プールは空いていたのでほぼ1コースを貸し切りで自分のペースで歩いたり泳いだりできて快適だった。しかし、プールでは fitbit を外しているのでこの1時間のアクティビティは記録されない。これだけが残念。

隣のコースで外国人がバタフライで泳いでいて、すごいダイナミックで迫力があってカッコよかった。バタフライとかどうやって泳ぐのだろう？と軽く真似してみたけど泳げる気がしない。4泳法の中では一番難しいみたい。

バタフライは、クロールや平泳ぎ、背泳ぎと並んで、水泳の「4泳法」のひとつです。両手を回すように動かしたり、両足を揃えて上下にうねらせたり、非常にダイナミックなフォームで泳ぎます。4泳法の中ではクロールの次に速く泳げる一方で、泳ぎ方にコツが必要なため、最も泳げない人が多い泳法といわれています。

【水泳】バタフライを上手に泳ぐコツは？ 泳ぎ方の基本を押さえよう

プールを終えて晩ご飯を食べて歩数が9000歩を超えてたり、消費カロリーが2700カロリーぐらいだった。プールのアクティビティを含めると実際は軽く超えているけれど、データ上の目標を達成していないのが気に食わないと思えたので夜に散歩に出掛けて、データ上も日々の目標値を達成した。しんどかったけど、余分に運動したのでよしとしておく。

今回は寝台列車であまり寝付けなかったのか、fitbit に睡眠時間が記録されていなかった。おそらく2-3時間は寝たと思う。

今日の運動は合宿明けと移動疲れがあるのでお休みにした。統計を 運動の記録 にまとめる。

会議の準備

この3日間で私が主催の打ち合わせが5つある。主題だからそのすべてに私が資料を作らないといけない。もちろん先週から準備はしていたものの、完全ではなく、週末には城崎温泉でいっぱいいぱいになっていて余裕がない状態のまま出張になってしまった。打ち合わせの成否はそれまでにかけた準備時間に比例する。私の持論だ。最低限このぐらいの資料や段取りを組んでやらないといけないという私なりの基準がある。今回はぎりぎりまで資料を作ったり、打ち合わせ内容を練ったりして自身の基準すら満たすのにとてもしんどかった。

定例会議

いつものマイルストーン単位の定例会議。

特定の path 配下の web api にミドルウェアで認証や認可を適用している。こうしておけば認証しなければいけない web api の認証設定を実装し忘れるということが絶対に起きない。一方で未認証の web api もある。/auth/login や /status/ping といったものだ。これらは未認証で呼び出せるのでトップレベルの path をわけたい。そうすると、既存のトップレベルに設定してある /api/xxx という名前が論理的におかしい。web api は他にもあるのに認証を要するものだけ api というトップレベルの path を付けるのは奇妙に思えてくる。

/api/ping

チームで話し合ったり、私が思いついた最終結論としては1文字の path を設けることにした。ミドルウェアを適用したいという目的なので path さえあればよい。認証を要することを表す単語をつけると path が長くなってそれはそれで違和感を感じるし、開発者はタイプ量が増えることを嫌う。そこで一文字にしようと提案した。

/p/ping

permit, private, protected の意図で p という文字を使う。

3次開発の大きなふりかえり

事前に資料を作っておいた 開発の大きなふりかえり。2時間を使ってふりかえりを行う。前回の大きなふりかえり を経て、今回も若手のメンバーが大きく成長してくれて、その成長度合いが課題管理システムの統計からみてとれた。私がプロダクト開発に参加してチームを組んで1.5年経った。初期からのメンバー2人はどちらも十分に課題管理をうまくできるようになった。その結果、チームがよい開発文化を形成するようになった。

今回は新たに入りかけた若いメンバーはうまく立ち上がらなかったという反省があるだけで、その他のことについては開発全般うまくいっているし、プロダクトの品質も上がっているし、バックログの課題もたくさん自分たちで見つけられるようになってきた。私からみてもこのチームは十分によい開発チームに育ったと思う。マネージャーとしての私にとっての次の課題は途中からチームに参加するメンバーをいかに早く開発に馴染んでもらうか、よい開発文化を形成するようになってもらうかという取り組みになる。

スライドのあちこちに次の文言を埋め込んである。

ふりかえりなくして成長 (改善) なし

初期から課題管理に取り組んでいる2人のメンバーはどちらも成長が著しいし、ふりかえりの効果を実際の業務で体感してもらえていると思う。私自身も初めてのマネージャー経験、初めての課題管理をプロジェクトマネジメントとして導入するという経験、それらの PoC としての答えは出たと思う。間違いなく、課題管理は開発プロジェクトをよりよくするものだし、適切に課題管理すればプロダクトの品質も高くなっていく。今回のふりかえりは課題管理をビジネスにすることへの確信につながった。

1時に寝て6時に起きた。ここ数日2-3時に寝てしんどかったので数日ぶりに早く帰って寝た。最近は5時間眠れるようになってきた。健康大事。

今日の運動はレッグレイズ(椅子),腹筋ローラー,スクワットをした。統計を 運動の記録 にまとめる。

3次開発のふりかえり資料作り

昨日の続き 。一通り資料を作り終えてメンバーに共有した。QA テストのときに指導した ことに加え、3次開発をふりかえると新規メンバーがまた落ち込むかもしれない。しかし、経営者から開発に参加させてほしいと依頼されて、3ヶ月間なにもしなかったという事実を隠すことを私はしないし、あえてその背景を深堀りしないけれど、私のプロジェクトで次からこんなことを認めないという判断基準 (クライテリア) を設けて次の開発へ臨む。具体的にはフルタイムで時間を取れないのであれば開発に参加させないし、1ヶ月間を開発に取り組んで何も実績をあげられないときは開発から外す。今回は隔週で「来週からやります。」という言葉を3回ぐらい聞いて何もしなかったということが起きた。チームの規律を守るためにそんな人もいるとわかったのでその対策を講じる。

ぷち前夜祭

明日からの開発合宿に関東組が4人参加する。そのうち2人が前泊で神戸入りしたので軽く晩ご飯でもいくかと思っていたものの、いろいろ予定があわなくて、よしださんがうちのオフィスで別イベントのオンラインミーティングに参加するといった形になった。言うてもオンラインイベントなので mute にしながら会議室で軽く一緒に晩ご飯を食べた。阪急百貨店のデパ地下でお刺し身とお寿司とサラダ2種を買ってみた。18時前に行ったらお寿司とお刺し身は2割引だった。これで税込4,843円になる。このぐらいあれば2人で十分だった。オフィスの会議室も8人ぐらい入れる。数人規模の飲食イベントならすぐできそう。あとオフィスの冷蔵庫のスペースを奪ったままになっている缶ビールも3本消費できた。私はもう体重落とすことに専念しているので1人ではお酒を飲まないし、外へ出掛けてもなるべく飲み食いしないようにしている。体重を落とすゲームが楽しくなってきて、摂取カロリーよりも消費カロリーの方を大きくしていれば必ず痩せる。完全攻略に取り組んでいるような趣き。