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 がなかった時代もあって、そのときは物理的な付箋紙をホワイトボードに張りながら作業をしていたから、本来は同期したいという概念もなかったはずという意見も出た。たしかにツールがデジタルになって電子データとなった瞬間からデータの再利用を考えるようになるんだなと私も思えた。あと付箋紙をホワイトボードに貼り付けていた時代は何週間もその状態のまま放置するといったこともなかったのではないか？という気もした。

0時に寝て6時半に起きた。

github actions の並行ビルド

1-2日でできると思ったら想定したよりややこしくて3日かかった。既存処理でかかっている時間を40-50%ほど短縮できた。1つの job で複数モジュールのビルドや docker イメージの生成、aws ecr への登録、eks の pod 更新などをしている処理を複数の job に分割する。job を分割すると、ビルド成果物を共有できなかったり、env のスコープも変わってくる。独立した job 環境で効率よく処理できるよう、ビルドキャッシュを導入したり、カスタムの composite アクションで処理を共通化したりと、あれやこれやを変更する量が増えていった。変更すること自体は問題ないけど、動作検証は github actions 上で動かさないと分からないところがあって、その検証に時間がかかる。複雑なワークフローを実装していると、github actions のかゆいところに手が届かないのにも気付けた。まだまだ circleci は企業向けに使われるのかもしれないなと思えた。

• ビルドキャッシュを削除できない
• workflow レベルの env は参照できないフィールドがあったり job の steps で動的に更新できない
• workflow の再実行で途中の job から再実行できない
• カスタム action で run.if は使えない

23時に寝て5時に起きたが、だらだらしているうちに2度寝して6時半に起きた。

log4j2 セキュリティ対応

CVE-2021-44228 が金曜日のお昼から私のタイムラインを賑わしている。私がお手伝いしているお仕事はイントラのシステムなのでやや余裕をもって情報を眺めていた。issue のコメント をみても log4j 1.x にも影響があると書かれて、その後に実際には影響ないと書かれて、さらにその後に条件付きだけど影響はあると二転三転してた。自分で実際に試してなくて世の中の開発者の情報をみているだけ。そのため、公式の情報を信頼するといったポジションでしかない。関係者の方々には敬意を払いたい。私は spring の公式ブログで公開されている Log4J2 Vulnerability and Spring Boot を読みながら対応した。

ターコイズ

ふとしたきっかけで ターコイズ の記事を読んだ。12月の誕生石らしく、それでいまの時期に紹介されることも多いのだと推測する。別の記事でターコイズは喉によいと書かれていて、以前 喉に違和感がある ことを書いた。日常生活に困るほどではないけど、もうこの歳だから体調が良くなることはなく悪くなる一方だろうという見通しも含めて験担ぎのような感覚で喉というキーワードでつながったから購入してみた。

近所の原石屋さんに行って尋ねてみたら1-2cmぐらいのサイズ1個240円ほどで売っていたので3個買って、近所のダイソーで入れものを買って、それっぽくオフィスに置いておくことにした。うちのコーポレートカラーはグリーンとブルーなんだけど、ターコイズも ターコイズグリーン と ターコイズブルー の2種類の色がある。創業も12月なので誕生石としても合致する。共通点があって相性がよさそうなのでうちのコーポレートストーン (そんな言葉ない) はターコイズでいいや。

2時半に寝て7時に起きた。なんか眠れなくてだらだらしてた。

ワーケーション予約

参加予定者に最終確認をとって3人参加してくれることになった。感謝。私を含めて4人で行ってくる。レンタカーと きのいえ の予約を確定させた。1月28-30日で 城崎温泉 でワーケーションしてくる。宿泊は金曜日の夜しか予約があいてなくて4月まで土曜日の夜はすでに予約が埋まっていた。もし金土と連泊で予約するときは3ヶ月以上前に予約をとらないといけないということがわかった。宿泊人数によって料金が変わってくるため、多少の人数変更に対応できる条件で予約できるのが望ましい。今回泊まることでオーナーの人とやり取りできればそういったことも聞いてみようと思う。その後、旅のしおりを作り始めた。まだ1ヶ月あるので調べながらゆっくり準備を進めていく。移動や作業のための時間、食事、親睦会などタイムラインを作りながらやり方を検討していく。

ショコラ・シュバルツ

山梨県北杜市のふるさと納税 の返礼品として ショコラ・シュバルツ（Chocolat Schwartz） が届いた。試しに1本飲んでみた。香りがよくて黒ビールなんだけど、普通の黒ビールとは異なる風味でそれがショコラなのかどうか、私にはよくわかってないけど、あまり味わったことのない黒ビールという点からはおいしかった。毎日飲むようなビールではないと思うが、イベントや記念日など普通のビールとは異なるビールを試したいときには向きそう。お土産などにもよさそう。

1時に寝て7時に起きた。久しぶりに遅くまで飲んでたのでやや気分が悪い。全体としてあまり大したことしてなかったんだけど、日記のふりかえりしたり、スクラム談義したり、log4j の脆弱性のその後の状況を静観したりしてた。

ストレッチ

今週もお仕事に注力してたらストレッチは2日/週とあまりできなかった。夜も外に出掛けるのが億劫になったり、勉強会に参加してたりしてウォーキングもやってない。今日の開脚幅は開始前167cmで、ストレッチ後169.5cmだった。さぼってたわりにはまぁまぁだった。特別なことはなにもしてなかったけど、右太もも後ろの筋がやや張っていて右足はあまりよくない。一方で右股関節の不可動領域がよくなっていることが自分でストレッチしててもわかるようになってきて半年以上やってきた甲斐があったと言える。

ワーケーション計画

参加者の目処がついてきたので城崎温泉に出掛けるワーケーションの計画をシミュレーションしていた。たとえば電車とレンタカーでどのぐらい料金の差になるかというと、三ノ宮発でレンタカーを借りて移動 (2泊3日) するときの料金 (高速道路/ガソリン代含む) は 35,648 円、電車は往復11,000円/人になる。3人いればレンタカーと同じぐらいの料金で、4人いればレンタカーで移動した方が安くなる。3人だったとしても移動の勝手の良さを考慮するとレンタカーの方がよさそうに思えた。

0時に寝て6時に起きた。

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

金朝ツメトギ 2021-12-10 AM 6 金曜朝6時開催のもくもく会 に参加した。今回はてらださんも来られていた。第9章を読んだ。KDDI さんの事例紹介で2013年から取り組みしているらしい。フラクタルスプリント を実際の業務で実践している稀な事例としておもしろかった。1週間のスプリントの中に1日のスプリントが4回あるといったフラクタル構造のスプリント。また金曜日は「仕事をしない日」としてレトロスペクティブと OST (オープンスペーステクノロジー、自由な発表と議論の時間) に割当てている。20%ルールに近いものと言えるかもしれないが、自己研鑽のための時間をスプリントの中に組み込むという、組織の理解があってこそできる取り組みを実践していてすごいなと感心した。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。スクラムの話題として だいくしーのスクラム Bar #1 や Scrum Masters Night! Online 〜第10夜〜 に参加してやり取りした内容や考察したことなどをいろいろ話してた。そのうちの話題の1つに、スクラムマスターの役割とは何だろうかがある。スクラムマスターはプロダクトをよくすることに責任をもち、メンバーが働きやすいように支えるような役割である。ここまでは共通認識として、その範囲がどこまでかは人によって意見が異なるように思えた。あくまでプロダクトやチームの範囲内で行動するスクラムマスターと、スクラムを組織全体に広めたり、人事・評価制度や経営にも参加していくスクラムマスターがある。スクラムマスターは社外の人間でもできるという考え方があるが、必然的に後者の役割も担うなら社内の人間に限定される。後者の役割は越権行為ではないか、いやいや、チームのために働いたメンバーの評価が下がってしまえば現場でよりよいプロダクト開発はできないから大事ではないかという意見も出た。便宜上、前者を (普通の) スクラムマスター、後者を「意識の高い」スクラムマスターと呼ぶ。私の考えでは、意識の高いスクラムマスターの言わんとしていることはわかるが、それをやりたいなら部長や役員などになってから職責とともに改善すべきであり、スクラムマスターという組織におけるラインではない人が経営に口出ししたりすることによる、組織の歪みはまた別の問題を引き起こすのではないかとも思えた。私も経営をやっていて経営側の視点でみるとやはりおかしい。

その後にワーケーションについて相談した。城崎温泉にある きのいえ でワーケーションをやってみようかと考えている。参加のお誘いややり方についていくつか相談しながら前向きに検討しようということになった。

忘年会

【初参加大歓迎】三宮.dev＆bizpy 合同忘年会 に参加してきた。忘年会の前に運営に入ってもらった、わたなべさんと軽く bizpy の運営について話してきた。1月はわたなべさんに機械学習の勉強会をやってもらう。私は昨年も三宮.devの忘年会に出てた。昨年は3人だったのが今年は4人になった。名物の大きなポークカツレツ。4人とも勉強会の常連みたいな人たちなのでお酒を飲みながらわいわいやって、コロナ禍になる前のコミュニティの勉強会の飲み会を思い出したりしてた。ワーケーションの話をしたら2人は興味を示してくれて、メンバーが4人集まったので開発合宿の企画をしてみることに決めた。

0時半に寝て6時半に起きた。久しぶりに22時までお仕事やって区切りもよかったからそれからお惣菜を買って23時頃から晩ご飯を食べてた。生活が乱れるなぁ。

dapr の分散トレーシングと W3C trace context

お仕事で dapr の分散トレーシングを検証してた。知らない人は Dapr Advent Calendar 8日目 - DaprとZipkinで分散トレーシング のチュートリアルをお勧めする。dapr は W3C Trace Context を使って分散トレーシングを扱う。rest api では、具体的には traceparent と tracestore という http ヘッダーにトレース用途の情報を付けて転送する。すごいところは pubsub のメッセージングを経由してもそれらの情報を転送できる。pubsub 間でこれらの情報は CloudEvents という標準化されたデータのフォーマットでやり取りされる。実際には CloudEvents の中に traceparent と tracestore の値を含めて通信するけれど、外部からみたら http ヘッダーを転送できているようにみえる。しかし、http ヘッダーの任意の値を転送したい場合、それができない。tracestore はトレースのためのベンダー独自情報を付与できるとあったので、ここに任意の値をセットして送ってみたけど、http ヘッダーの付け替えは行われなかった。あとで dapr のソースを読んだら publish するときはそのまま送っているけど、subscribe するときに tracestore の仕様を満たしているか検証しながらパースしていて、任意の値を送っても仕様に沿っていなければ捨てられてしまうことがわかった。dapr の issue でも要望として登録されてた。誰もやってないならコントリビュートするチャンスかもしれない。

• Propagate arbitrary/configurable http headers from publisher to subscribers #3642

創立記念日

今日が会社の創立記念日。無事に2周年を迎えた。創立記念日をお休みにするしないを考えたのだけど、いま休日も普通に働いている状況で、且つ役員は勤怠管理をする必要はないので平日になんの意味もなく休むメリットが何もないということに行き着いた。創立記念日だから休むのではなく、いつでも必要なときに休めばいい。もっと言うと、休む理由がなければ働くという逆転現象が生じていて、休む理由は私用か疲労ぐらいしかなくて、基本的に疲れてない限りはずっと働くみたいな理屈になってしまっている。社員が増えて会社に余裕が出てから創立記念日は休みみたいな制度を作ればいい。それまではたぶん来年もそれ以降も普通に働いていると思う。

1年目は訳分からず働いていたから経営的なことは全くわからなかったけど、2年目は経営上の諸問題が出てきて、経営的な意思決定や考察も増えてきて、行政手続きも熟れて、会社の実績も増えていっていて、会社を育てるという意識もかなり出てきた。率直に言えば、いまの経営状態は可もなく不可もなくといったものなので何もアピールすることはない。しかし、経営したことない人間が経営というキャリアを積み重ねていることには大きな意義があって、自身のキャリアアップには確かな手応えも感じつつある。これからもがんばっていこう。

0時に寝て5時に起きた。今日はがんばって起きた！久しぶりに7時半から始業してた。

トヨタの5S

スクラムイベントのふりかえりをしていて トヨタの5S の話題が出た。聞いたことがあるようないような、スクラムを勉強しているいま見返すとじわじわ聞いてくる。玄人ぶって「そうそう、こういうのが大事なんだよ」とか言いたくなりそうな雰囲気がある。普通にやっていたら当たり前のことなのに、忙しかったり複雑な問題に対応してたりすると、普通の状態を維持できなくなって混沌がもたらされる気がする。そういう状況のときに初心に戻るにはこういった原則や標榜を使って啓蒙することに意義があるんだと、いまは思うようになってきた。これ自体をよいとかわるいとか言うのは適切ではなくて、うまくいっていない状態からより戻すときに活用するといった考え方の方が正しいのかもしれない。

0時に寝て6時半に起きた。5時台には起きているんだけど、起き上がるところまではなかなかいけない。

恒大集団のデフォルト

11月から利払の期日の日はチェックしていて、支払うときは2-3日前には支払いを完了したというニュースが出ていたように思う。今日の支払いは前日に支払いしたというニュースが出ないからダメなんだろうなと様子をみていた。

• 中国恒大、猶予期間終了までにオフショア債利払いできず＝関係筋

1つの債務がデフォルトした場合、残りの債務も一括返済しないといけないことを クロスデフォルト と呼ぶらしい。契約書にクロスデフォルト条項として書いてあるらしい。記事によると、クロスデフォルトによって約190億ドル (約2.1兆円) のオフショア債の返済を一括でしないといけないらしい。リーマンショックのようなことは起きないという見通しだけど、うちみたいな零細企業は世の中の影響を諸に受けるのでお仕事に影響がでなければいいなぁといったところ。

アプリケーションログの調査

昨日の続き。ecs-logging-java で JSON Lines でログを制御するところで spring-boot の設定で tomcat のアクセスログの設定ができる。tomcat のアクセスログを log4j のレイアウトの仕組みを使って ecs-logging-java が提供する EcsLayout に変更できないかを3時間ほど調査して、どうもできないようだというのを教えてもらった。tomcat は apache のログを出力するという目的で実装されているから log4j の柔軟なログに対応していないという理屈。

じゃあ、どうやって apache のアクセスログを JSON Lines にするかというと、PatternLayout のパターンに json のフォーマットを直書きしてしまうというやり方がある。なんかプログラミングでスマートに解決したいところだけど、その仕組みがないなら仕方ないかって感じでこれでやろうと思う。

• apacheのaccess_logをjson化しtd-agentで集約サーバへ収集する

1時に寝て7時に起きた。

アプリケーションログの調査

お仕事でログの整理をやろうとしていて、そのためのライブラリとして ecs-logging-java を調べてた。

• ECS Logging Java Reference 1.x » Get started
• ecs-logging-javaつかってみた

一番のモチベーションは JSON Lines でログを管理したいというところ。この手の実装や読み込んでログ分析したりとかはあちこちでやってきたので親近感はある。既存のログからの移行も含めていろいろ設計していかないといけない。私の感覚だとアプリケーションの開発初期にログの設計や出力周りを作り込むものだけど、そうじゃない文化の開発もあるんだなという印象。あとからログ設計するとか、移行や既存のコードに手を入れたり、開発初期に作り込むより手間暇かかる気がするんだけど、そんな時間もなく開発してたってことなのかなぁ。

0時に寝て7時に起きてだらだらやってて午前中は 頭文字D のアニメをみてた。漫画 (アニメも？) はすでに完結しているのでいつか読もうと思いつつ最後まで読んでいない。ゴッドフットやゴッドアームが出てくるぐらいまでは読んだ気がする。その後どうなったのかを知らない。イニシャルDをみていると、ストーリーも絵も演出もまったく派手さはなくて普通なんだけど、なぜかおもしろくて続きをみてしまうという人間の娯楽の本質をついている気がしてくる。なんでなんだろうなぁ。

頭文字D

たまたま思い出したので夜に漫画喫茶行って頭文字Dを最後まで読んできた。全48巻で、31巻ぐらいから読み始めて3-4時間ぐらいで読み終えた。漫画なので仕方ないけど、対戦相手がどんどん強くなっていって勝ち方が玄人好みというのか、単純に抜いた・抜かれたの話しではなく、タイヤマネージメントがどうこうとか、恐怖に対する心理がどうこうとか、ドライバーと車のセッティングも含めた駆け引きが強くなっていって、どちらが速いかというよりは戦略通りの展開にもっていって最後はそれがうまくはまるみたいな、これまでもずっとそうだったんだけど、ここからはよりトップレベルのほんの僅かな差が勝敗を分けるといった描き方になっていったように思う。それはそれで現実に近い気はするけど、漫画的には派手な演出にならないので玄人好みなストーリーになっていった気がする。但し、そこまでやってきて最後の対戦相手だけは、個人的には納得感がなくて、ここまで緻密に作り上げてきた理論や個々のドライバーの修練の積み重ねが圧倒的天才の前にひれ伏すみたいな切り口が急展開していて、頭の切り替えができなかった感じがした。とはいえ、最後まで読み終えられてよかったし、作品としてはすごくおもしろかった。作者はモータースポーツが本当に好きなんだろうなというのが伝わってくる漫画だと思う。

ふるさと納税

あまり欲しいものもないし、ふるさと納税の行政手続きも一通り理解したから今年はやらなくてもいいかとも思っていた。しかし、paypayボーナスキャンペーン をみてやってみるかという気になった。paypay はいろんなものと連携していて見かけるたびにすごいなと思う。お得だからと必要もないものを買うことはないけど、ふるさと納税はやらなかったとしても、どのみち納税は必要なものなので還元があるということは節税につながるのかな？理屈はよくわからないけど、言いたいことは paypay はすごいという話でした。

dapr の api トークンを使った認証

Enable API token authentication in Dapr を一通り読んだ。内容はとくに難しくなく、こんな風に dapr の manifest を書けば JWT トークンを設定できますということを書いてある。私はずっとサーバーサイドばっかりやってきたからフロントエンドで使われる技術や仕組みに弱い。JWT トークンもその1つで、自分でちゃんと実装したことがないからちゃんとよく分かってない。これが OAuth2 なら provider を実装したこともあるからその仕組みも意図も理解できる。一度どこかで自分で JWT も実装してみないといけないのだろうな。

少し前にお仕事で kubernetes の secret の移行作業をやった。既存の secret にキーバリューを追加するときは patch を使う。

$ kubectl patch secret mydata -p='{"stringData":{"mykey": "myvalue"}}'

secret の内容を確認するときも2つのやり方がある。キーだけを確認するならこれでよい。

$ kubectl describe secrets mydata

キーに対応する値もデコードして確認するならこうする。但し、閲覧注意。

$ kubectl get secret mydata -o json | jq '.data | map_values(@base64d)'