2時に寝て6時半に起きた。運動しているせいか、よく眠れるようになってきた。

今日の運動は腕立て,スクワット,背筋をした。統計を 運動の記録 にまとめる。

日々の運動の記録

すでに縄跳びは筋トレじゃないし、平時より多く歩いたら散歩として記録しておきたいし、今後も既存のメニューに飽きたら新しい運動項目が増えると思う。そこで「筋トレ」から「運動」にクラスチェンジした。そしてやった回数は google sheets に記録していく。「表示」設定で計算式を表示するようにすると、ちょうど何セットやったかのような見栄えになる。

いつか運動の記録を統計的に処理したいときに使えるようにデータを溜めておく。複数の項目を1つのグラフにきれいに描こうと思ったら日付の集約や値のスケーリングなど、いろいろ加工しないといけない。google sheets だけでは (できなくはないけど) 難しいと思う。こういうところは、私の見たいグラフを作るためにコードを書いて、適当なフロントエンドのアプリケーションを作ってみてもよいかもしれない。いますぐやるわけではないけど、いずれ余裕ができたらそういうのも作ってみたい。

ストレッチ

先週に引き続き、筋トレを継続しているので軽い筋肉痛を引きずったままストレッチを受ける。ふくらはぎの後ろの張りが一番辛かった。他にも腰の周り、全身的に筋肉痛の軽い疲労があるなとは感じた。トレーナーさんに縄跳びで膝の後ろの骨みたいなところが痛いというのを相談してみた。ジャンプは日常生活で行うことではないし、着地したときにひざや足首に大きな負荷がかかるとのこと。痛いのならしばらく休んで直してから縄跳びした方がよいとアドバイスしてくれた。そりゃそうか。今日の開脚幅は開始前153cmで、ストレッチ後157cmだった。

ダイニングテーブルセットの引き取り

ジモティーで「ダイニングテーブル + ベンチ + 椅子2脚」を3,000円で購入した。ググってみたらニトリのダイニングテーブルセットで当時の販売価格は3万円弱とのこと。実物の品質もとてもよい。おそらく1-2年しか使っていない。これがコワーキングスペースで必要なテーブルと椅子の最後の1ピースになると思う。テーブル／椅子はこれで十分。一昨日問い合わせて今日引き取りに行くぐらいのスピード取り引き。

メールでやり取りしていて相手が女性なのはなんとなくわかっていて、ダイニングテーブルセットを出品しているのだから結婚されている方なのだろうと推測していた。今日引き取りに行って、マンションの部屋まで上がってきてくれと言われて、お宅訪問してリビングからダイニングテーブルを外へ運び出すところまでやった。さらに驚いたのが20代後半ぐらいの奥さんと2歳ぐらいの子どもの2人しかいなかった。過去にも奥さんがジモティーをやって、マンションまで引き取りに行ったら旦那さんが駐車場まで品物をもってきてくれるということがあった。それが普通だと思う。旦那さんいなくて、私が家にあがってテーブルの脚を外す作業もして、すぐ側にいる小さい子どもが人見知りして泣き出すんじゃないかとハラハラした。今月末でそのマンションを退去しないといけないらしく家具をすべて処分しようと、いろいろ大変だと話されていた。切羽詰まっていたのかもしれない。土曜日の19時に訪問して旦那さんがいないという状況だけで死別したのかな？離婚するのかな？とか変な想像もしてしまった。こんなこともあるんやとその状況に驚いたけど、お礼を伝えてすんなり引き取ってきた。

23時に寝てこわい夢をみて1時半に起きて、そのまま寝たのか寝てないのかよくわからない仮眠状態で5時半に起きた。

朝活: アジャイル開発とスクラム 第2版

【三宮.dev オンライン】リモート朝活もくもく会 で第10章 竹内・野中のスクラム論文再考を読んだ。1986年に竹内氏と野中氏によって書かれた The New New Product Development Game から得た概念や理論的背景をスクラム創設者のジェフ・サザーランド氏がソフトウェア開発の方法論として体系化したものがスクラムになる。そのため、原点はこの論文にある。第10章ではオリジナルに書かれている内容とスクラム開発を比較している。オリジナルの論文にある TypeC (キヤノンやホンダの新製品開発) のようなチームの特徴として次の6つをあげている。

1. 不安定な状態を保つ

   最初に綿密な計画や指示があるわけではない、チームは自由な裁量と同時に困難なゴールを目指す

2. プロジェクトチームは自ら組織化する

   チームは不安定な状態から自己組織化し、対話の中で自律状態を作り出す

3. 開発フェーズを重複させる

   開発フェーズを重複させることで、メンバーは専門分野を超えてプロジェクト全体で責任をもつようになる

4. 「マルチ学習」

   メンバーはグループ全体として学習し、専門を超えて学習する

5. 柔らかなマネジメント

   無管理でも強い管理でもない自主性を尊重した柔らかなマネジメントが重要である

6. 学びを組織で共有する

   過去の成功を組織に伝える、もしくは意識的に捨て去る

オリジナルの論文の解説を読んでいると、古きよき日本の家族ぐるみの職場やチームの働き方のように思えてくる。時代が違うのでいまからこういった働き方に戻るのは現実的ではないだろうが、その中で重要だった概念や要素を、いまソフトウェア開発方法論としてのスクラムで実践できるのはいろいろと私の中でも思うことがある。私の考える課題管理の方法論にも竹内・野中氏のオリジナルの論文の概念は影響を受けるように思えた。章末にコラムとしてジェフ・サザーランド氏のインタビュー記事もあった。マイクロファイナンスのプロジェクトを通して、小さなグループに小さくお金を貸し出すことが、貧困から抜けすための小さなきっかけ (ブートストラップ) になるという体験からスクラム開発の動機づけになったという話しは哲学として印象に残った。なにかを成すには哲学が大事だと思う。

データがあると同期したくなる

お仕事でスクラムのふりかえりをやっていて miro と backlog のデータ同期という話題が出た。業務チームはブレインストーミングで要件を洗い出したりする作業のときに miro を使っていて、miro ベースでメモを記述した後でバックログアイテムとして backlog に登録する。このとき backlog に登録した後で miro を捨てるならいいが、残したまま次の展望や要件の洗い出しにも再利用したりしていると、miro と backlog のバックログアイテムの内容が乖離したり不整合が発生したりする。チームとしてはバックログアイテムに書いてある内容が正という運用をしているため、miro のみに最新の情報がある状態が続くと課題になる。私の知る限り、miro と課題管理システムのデータ連携のツールはないと思う。

私からみたら最初からすべてバックログアイテムに文章で書けばいいやんで話が終わってしまうが、人によって使い慣れたツールは異なるため、そんな単純な話しでもない。一方で昔は miro や backlog がなかった時代もあって、そのときは物理的な付箋紙をホワイトボードに張りながら作業をしていたから、本来は同期したいという概念もなかったはずという意見も出た。たしかにツールがデジタルになって電子データとなった瞬間からデータの再利用を考えるようになるんだなと私も思えた。あと付箋紙をホワイトボードに貼り付けていた時代は何週間もその状態のまま放置するといったこともなかったのではないか？という気もした。