0時に寝て6時に起きた。朝活やってからまたちょっと寝てた。午後から高速バスで実家に帰った。

朝活: バッタを倒しにアフリカへ

金朝ツメトギ 2021-12-31 AM 6 金曜朝6時開催のもくもく会 に参加した。厳密には朝活のときは、はらさんの振り返りを聞いてた感じで、終わってから「第2章アフリカに染まる」「第3章旅立ちを前に」を読んだ。アフリカでの生活のあれこれが書いてあって、日本に住んでいる自分からは斬新でおもしろい。なにかの記事でアフリカが経済発展しない理由の1つに賄賂や汚職が横行していて云々みたいな記事を読んだことがある気がするけど、本書の中でもちょくちょく賄賂を要求されたり、不正に給料をもらおうとぼったくりされたこととかが書いてある。日本人からみると賄賂やぼったくりの金額もそんなに高くないので払ってしまったりしてそれが返って社会に歪みを与えてたりするのかな？とも思えた。

モーリタニアの公用語がフランス語で著者は英語しか話せなくて、言葉の通じない国で現地の人たちと仲良くなるのは相当の苦労が忍ばれる。著者は文章を読んでいてもおもしろい感じだけど、言葉のスキルとは別にコミュニケーション能力が高い人なんだろうということも伺える。言葉が通じなくても仲良くなれる雰囲気の人はいると思う。あとは日本と比べると生活環境がよくなくて、いまの自分は外国で暮らすとかできないだろうなと読んでて思うこともあった。

高校の同級生と飲む

毎年、大晦日に集まって近況報告をしたりしてた。コロナ禍があって自粛していたので3年ぶりに集まった。とくに変わりなくみんな元気でいた。18時頃から飲みながらだらだらしてた。私は前に焼き鳥屋さんのマスターのおすすめで飲んだ だいやめ を持っていった。そのとき飲んだお湯割もおいしかったけど、今回はソーダ割りを試してみて、それもおいしかった。友だちも初めてだいやめを飲んで、これ芋焼酎なの？と驚いていた。初めて飲んだら驚くという意味でもこの焼酎はお土産に向いている。

友だちの1人はゴルフにはまっているという話。調子がよかったら80台でまわれるぐらいで、私にはわからないけど中級者と言えるだけのレベルに達しているらしい。ゴルフは接待や出世のためのツールみたいなイメージが私にはある。したがって私とは無縁でやることはないような気がする。かなり歩くから健康のためにもよいという話もあるのでゴルフ自体を忌避しているわけでもない。スポーツとして楽しんでやっているのはよいと思う。

夜はテレビで RIZIN をみていた。出場している選手は全然わからないけど、大晦日っぽいなと思いながらみていた。

0時に寝て4時に起きて、なんとなくドラクエタクトしてたら6時になってそのまま朝活に出てた。sns のタイムラインを眺めていると今日で仕事納めにしている人をちらほらみかけた。私は外向けには月曜日が仕事納めで、内向けには水曜日までは働くかな。30日は実家に帰るか、ゆっくり休むか、まだ決めてない。

朝活: バッタを倒しにアフリカへ

先日たまたまみかけた記事から購入した ことを書いた。積ん読状態だったけど、技術書ばかりも疲れるので気分転換に読み進めることにした。

第1章サハラに青春を賭けるを読んだ。著者はおもしろい人だというのは文章から伝わってくるので何を書いてても驚きはしないが、それでもアフリカ(モーリタニア)の生活や状況などは全く知らないことばかりなので何を読んでも斬新には感じる。モーリタニア・イスラム共和国 という国すら私は知らなかった。

第1章は渡航してフィールワークに出掛けた内容が書いてあった。砂漠へ行くチームにコックが必要というのは、ドラクエ脳の自分には出てこない発想で現実は旅をしながらおいしいものも食べたいという欲求は強いのだなぁという学び？があった。

slack のマルチチャンネルゲスト

これまでお手伝い先では slack のシングルチャンネルゲストで参加していた。必然的に1つのチャンネルにすべてのプロジェクトメンバー20人がいる。技術的な話題を気軽に投稿しにくいし、システム通知などもかなり制限されていた。

人間が会話するチャンネルとシステムが通知するチャンネルは分けた方がよい

と、私はプラクティスとして常々言っている。きっと誰もが言っている。システム通知が認知負荷となるという声は業務側のメンバーからも届いていた。これは外部メンバーをマルチチャンネルゲストにすることのコストだけの問題なので、その価値をどう測るかという視点から、中の人がその予算を確保して外部メンバーがマルチチャンネルゲスト化された。その判断を支持する意図でも、slack のチャンネルが複数扱えることでどういった情報共有やシステム間連携の価値があるかというのを、私の経験からも提示していきたいと考えている。情報を監視するという概念、ならびに情報の一元管理にも関わってくるので、課題管理と並ぶ情報共有という文脈で私の強みが活きる分野でもある。いろいろやっていきたい。

0時に寝て4時過ぎに起きて2度寝して6時前に起きた。

朝活: バッタを倒しにアフリカへ

【三宮.dev オンライン】今年最後のリモート朝活もくもく会 に参加した。スクラム本を読み終えたので気分転換に バッタを倒しにアフリカへ を読むことにした。主に雑談してたら序文しか読めなかった。

課題管理システムを一本化する

お仕事でスクラム開発を実践している。プロダクトバックログを backlog で管理し、スプリントバックログを GitHub Issues で管理している。課題を複数のプラットフォームで管理することは情報の一元管理という側面からよくないといったことをお手伝いを始めたときから機をみて指摘していた。そういう状態が2ヶ月ほど続いて、GitHub Issues は機能的に厳しいという共通認識が開発者にはあるため、backlog へ一本化されることに決定した。スクラムと課題管理との関係を追究したい私にとっては朗報で、今後は PO も含めて課題管理システムの用途をメンバーにアドバイスしながら課題管理の高みを目指していきたい。但し、backlog は標準で github 連携機能を提供していないため、チケット駆動開発をするには自前で連携機能を作らないといけないらしい。

0時に寝て6時に起きた。ここ最近は晩ご飯作って食べてアイスクリーム食べてドラクエタクトやって寝るみたいな業後の過ごし方が多い。

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

金朝ツメトギ 2021-12-17 AM 6 金曜朝6時開催のもくもく会 で第11章スクラムと知識創造と第12章スクラムと実践知リーダーを読んだ。

第11章では知識想像モデルとして SECI モデルが紹介されている。ふと読んでいて、私が課題管理システムでやっていたのはこの「表出化」の活動で、多くのスクラムをやっているチームは「共同化」を主にやっているように思えた。ソフトウェア開発方法論の歴史的に、チケット駆動開発 → イテレーション開発 → アジャイル開発/スクラムの時系列に発展してきた経緯から、私のようなチケット駆動開発をがっつりやってきた開発者が言う対話が重要だと言うことと、最初からスクラム開発で「共同化」しかやらず「表出化」していない開発者が言う対話が重要だと言うことは、背景事情からして根本的に指している内容が違うのではないか？という仮説を思いついた。対話が重要だと言う開発者がドキュメントや文章を書くことをなおざりにするのを見かけて違和感を感じていた。チケット駆動開発をがっつりやってきた開発者は文章を書いた上でそれだけでは解決できなかった問題を解決するために対話が必要だと言っているわけであり、文章すら書けない開発者は対話だけで開発を進められるわけではないと考えると、これまでスクラム開発に抱いていた私の違和感の正体に近づいたように思えた。

第12章では実践知という概念とそのリーダーシップが紹介されている。以前 実践知 — エキスパートの知性 という本を読んで、メタ認知も含めた認知心理学の知見を踏まえた知識創造や実践知を獲得するに至る背景や教育と課題管理との間にある関係性を考えていたことがあった。スクラムにおいても実践知という概念を扱っているのを読んで、ここにはなにかしらの関係性を見出したり体系化を行う余地があるように考えている。やや哲学的な話題も出てくるので人によって賛否がわかれるかもしれないが、私は自分の考えている中長期的な思考や教育への考え方の価値観が合致していて、これが日本的な経営スタイルの鍵だという意見には一定の同意ができる。自分自身も中長期的な展望を大事にしながら課題解決していきたいという想いもあるからだ。

ワーケーション準備

ワーケーション準備 の残タスクを少しずつやっていく。宿泊先の きのいえ に電話してチェックイン前に駐車場にレンタカーをとめさせてもらえないかを問い合わせた。当日に宿泊客がいれば13時以降、いなければそれよりも早めにとめてもよいとのこと。スタッフがいれば声をかけていなくても勝手にとめてよいと教えてもらった。先方からも ふるさと応援！ひょうごを旅しようキャンペーン が本来は12月末で終了だったのが2月28日まで延長されたため、宿泊者が兵庫県在住であればその手続きをしたいとのこと。一旦、オンラインで決済済みの予約をキャンセルして、現地決済で兵庫県の割り引きの手続きをしてくれるという。メンバーは4人中3人が兵庫県在住なので4,000円/人の割り引きで合計12,000円の割り引きになった。

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時に起きた。

朝活: アジャイル開発とスクラム 第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時に起きた。

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

第7章の残りと第8章を読んだ。事例紹介なので軽く読み流した感じ。インタビュー記事のタイトルが気になった。

「合宿で、「仕事での同僚」から「チームの仲間」になれました

このタイトルと内容に私は違和感があるので反論としてそれを書いていく。

心理的安全性のつくりかた に書いてあったが、MIT のオスターマン教授によると、チームという概念は比較的新しいものらしい。

職場における、チームという概念は1980年以降、最も広まったイノベーションのひとつだ。

「心理的安全性のつくりかた」ではチームとグループの違いは次になる。

• チームは共通の目標に向かってともに問題解決やアイディアを出す集団
• グループはそうなっていない、ただの寄せ集めの集団

共通の目標に対して互いに対話や協働することでチームになっていく。この考え方は私の経験則とも合致するし支持している。実際の業務や作業を通してチームは築かれていくと私は考える。しかし、コミュニケーションの活性化や親睦を深めればチームになると誤解している人もいるように思う。

件のインタビュー記事では、次の内容があった。

合宿の最大の成果は、何だったのでしょう？

「仕事での同僚」から「チームの仲間」になれたことだと思います。昨今、ハラスメントやプライバシーの観点からなかなか個人の深い話ができないことが多いと思いますが、お互いを信頼した上で自分の生い立ちや経験から「私がなぜここにいるのか」を深掘りできたことが大きいと思います。

具体的には、誰とも話さず、自分を見つめる時間として三浦海岸の浜辺に全員を１時間放置しました（笑）。その時間で自分の今までをふりかえり、再集合したときに１人ずつ語り、お互いのことを尊重し受け入れることで心理的安全性が一気に高まったと思います。

私だったら転職を考えますね。浜辺に放置されて再集合して生い立ちとか語れとか言われて、そんな上司だと懸念を抱くと思う。その場で抗議はしなかったとしても。仕事を通して結果的に信頼関係が深くなって、同じ行動をするなら理解できるが、そうじゃない状態で職位の高い人がメンバーに合宿を半強制参加させてプライベートの内容を話させるのはハラスメントと紙一重かもしれない。おそらくこれはたまたまうまくいったケースだというだけで再現性のあるプラクティスにはまったく思えない。厳しい言い方をすると、偉い人の自己満足によるチームごっこではないかと思う。

「仕事での同僚」から「チームの仲間」になれたというインタビューが書かれていた。私の感覚ではやや違和感がある。グループではなくチームという概念が認識されるようになったのはわりと最近の話だというのはたしか心理的安全性のつくりかたに書いてあった気がする。 #金朝ツメトギ

— Tetsuya Morimoto (@t2y) December 2, 2021

本番リリース作業

今日は非稼働日なんだけど、インフラ周りの修正をしていたので本番リリースの作業を見守っていた。ハドルで画面共有しながらみんなでわいわいできるので、これはこれでリリース作業の雰囲気を学ぶ機会にもなる。私が本番リリースすることはないだろうけど、担当者がどういった作業でリリースしているかを知っておく方が運用に役に立つ仕組みも導入できるかもしれない。音声通話と画面共有さえあればフルリモートワークでもなにも困ることはない。よい世の中になったと思う。RabbitMQ と Dapr 周りで私が懸念に思っていたことを本番リリースを通して検証したり振る舞いを観察できたので新たな知見を得た。

1時から1時間ほど仮眠をとって2時から4時過ぎまで作業して帰ってお風呂に入ってそのまま6時から 【三宮.dev オンライン】リモート朝活もくもく会 の朝活に参加した。30分ほど雑談して眠くなって7時過ぎから9時前まで寝てた。

dapr の pubsub の dead letter サポート

お仕事で dapr を触っている。pubsub で dead letter queue の仕組みを導入しようとしているが、PubSub’s DeadLetter Topic #2217 によると v1.6 (2022年1月20日リリース予定) のマイルストーンになっている。本当にその予定ならそろそろベータ版が実装されていて、開発ブランチあったらテストしようかと考えていた。調べてたら rabbitmq はすでに v1.5 で dead letter のサポートがマージされているのを発見した。

• Add dead letter support for RabbitMQ pubsub #1844

たまたま、いま使っている pubsub も rabbitmq だった。ドキュメントをみたら確かにその設定が追加されている。

dapr RabbitMQ

Field	Required	Details	Example
enableDeadLetter	N	Enable forwarding Messages that cannot be handled to a dead-letter topic. Defaults to “false”	“true”, “false”
maxLen	N	The maximum number of messages of a queue and its dead letter queue (if dead letter enabled). If both maxLen and maxLenBytes are set then both will apply; whichever limit is hit first will be enforced. Defaults to no limit.	“1000”
maxLenBytes	N	Maximum length in bytes of a queue and its dead letter queue (if dead letter enabled). If both maxLen and maxLenBytes are set then both will apply; whichever limit is hit first will be enforced. Defaults to no limit.	“1048576”

enableDeadLetter=true に設定して、適当にエラーが発生しそうなリクエストを作って dead letter にメッセージが入るかどうかを検証してた。ひとまず dead letter にメッセージが入ること自体は確認できた。

bizpy 勉強会

Python で Slack のインテグレーションをやってみる勉強会 #3 を開催した。月曜日から2時間もあればできる資料作成をだらだら先送りしていて夜中に作った。なんか体調を崩しているのかもしれない。たまたま勉強会の前にせらさんから激励のコメントをいただいて嬉しかった。

今日の分も含めコンテンツ拝見しましたが、素晴らしいですね

私見だけど、slack インテグレーションで調べものをしているとせらさんの記事や issue のやり取りをみかけることが多い。twitter で slack インテグレーションに関してつぶやくと100%せらさんからレスポンスがある (個人の経験談) 。過去に私は外資の ISV で働きたいと思って活動したこともあったけど、せらさんをみていて自分のレベルでは無理だったなと得心がいった。なにがすごいって、bizpy の勉強会のようなところにもわざわざやってきて、講師にコメントしたりアドバイスしてくれるんだからね。

2ヶ月に渡り、slack インテグレーションのチュートリアルレベルの記事を実際に設定してみて、サンプルコード書いてみて、動かしてみて、slack でどんなことができそうかの理解を深めることができた。今回の内容はビジネスパーソン向けではなかったのでちょっと敷居が高かったかもしれないが、全3回でやり切ることができてよかった。終わってから運営に新たにわたなべさんが加わったことを参加者に紹介しつつ、次回の企画について雑談していた。次回はわたなべさんから機械学習入門のような勉強会をしてもらうことに決まった。

0時に寝て5時に起きた。昨日 slack で質問していた内容に5時頃に返信があるのをたまたまみかけた。この時間に起きているんだと思って返信にコメントしてたら別のメンバーからもコメントが書き込まれて、早起きは三文の得みたいな感じで朝5時から slack でやり取りしてた。いま私はだいたい8時から始業している。開発チームの半分ぐらいのメンバーはそのぐらいから始業しているのが課題管理システムや git のコミットログからわかる。このチームは朝早い人たちが多いなと感心した。

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

2021-11-26 AM 6 金曜朝6時開催のもくもく会 で第6章と第7章を読んだ。第2部は企業において実際にスクラムを導入していったときの四方山話が出てくる。私はあまり他社の事例に興味はないが、対談の過程で本質的に大事なことや難しいことなどがあぶり出されることもあるので、実務を通しての話題も参考になる場合があることは理解できる。大半の事例は実業務で使われているという結論がわかるだけでも十分だと思う。とくに大企業は様々な厳しい制約や要件の中で採用していると推測されるので、それだけで大きなメッセージをもつ。斜め読みでざっと読み進めながら興味のある話題があれば精読するといった程度で読んでた。

大企業あるあるな話しでスクラムイベントを通してお互いの距離感が縮まってうまくいったといった内容があった。開発者からすると距離感の遠近に関係なく、必要なら適切な相手を探し出してコミュニケーションを取るのが普通だけど、みんながみんなそうではないだろうし、(同じ会社の社員でも)よく知らない人とは話さないといった考え方をもつ人もいるだろう。ある人はこれを単純接触効果で説明していたけど、業務ではなく人間の側面からみてスクラムイベントが多いことにも意義があるのかもしれない。

ある事例でスクラムにおいてイベントがたくさんあってそれに参加することでお互いの距離感を縮めたという効果が書かれている。開発者は気になったことは何でも確認するという姿勢をとりがちだけど、関係者のみんながそうではないというのも理解できる #金朝ツメトギ

— Tetsuya Morimoto (@t2y) November 25, 2021

顧問さんと雑談

隔週で打ち合わせをしている。最近はお手伝いのお仕事が忙しいので今回は雑談になってしまったが、近況としてリーンキャンバス、スクラム実践の話題などを話していた。わりと盛り上がって1時間で切り上げるつもりが1時間半に伸びてしまって、別のお仕事の時間を圧迫したけど、それはそれで意義のある雑談になったので収穫はあった。

ある組織で新規事業を行う上で AARRR (あー) モデル をすごく重視しているといった話題が出た。バケツみたいなイメージがあって、そこに現実の数字を当てはめていってプロジェクト/プロダクトの改善やふりかえりなどに活かしているという。サービスのグロースに責任をもつ人には重要な概念だという。うちのプロダクトはグロースしなくてもよいけど、なんらかのフレームワークに当てはめて抜け・漏れがないかをチェックすることにも使えるかもしれない。世の中でよく使われているフレームワークを調査しておいて損はないと思う。私はビジネスに全く疎いのでリーンキャンバスを通じて、AARRR モデルの話題になって、それがどういった用途で使われているかというお話しは興味深かった。

具体的には AARRR モデルの他に、スクラムの話題からは野中郁次郎氏のオリジナルの論文、大規模アジャイルの方法論などが盛り上がっていくつかキーワードが出た。そういった雑談の中で感性に従って気になったことを深堀りしていくとおもしろい調査や知見になったりすることを経験的に実感しつつある。今後もそういう機会や内容を大事にしていきたい。

カスタム GitHub Actions の開発

先日 調査していたものをベースに、普通にやる方法と カスタム GitHub Actions の compoiste action で実装する場合の検討資料などを作って、カスタム GitHub Actions を実装してよいといった許可をもらった。企業における唯一の懸念は (原則) public リポジトリで運用するところで、CI のような処理に社外秘は含まれないが、public そのものに審査や承認を必要とするような組織では腰が重くなるようなこともあるかもしれない。ロードマップにも private リポジトリでカスタム GitHub Actoins を動かせるようにしようという課題は作成されている。

• Actions: Use actions from internal repositories #74

23時頃に寝て3時に起きて、そこから寝たり起きたりしながら6時に半に起きた。怖い夢をみて眠れなくなって中途半端に寝てた。

朝活: 雑談

【三宮.dev オンライン】リモート朝活もくもく会 に参加した。寝坊、、、というよりは起きてたけど、イベントを忘れていて6時45分ぐらいから参加して主催者しかいなかったのでそのまま7時半まで雑談してた。始めが悪いとだらだらしてしまう。気をつけねば。

三宮.dev の主催者や参加者の常連さんたちとはだいぶ身近に話すにようになってきた。コミュニティって人間関係だと思っていて、話したり顔をあわせたりする回数が増えるに従って身近な知人になっていって、それ自体が価値の1つだったりすると思う。いま忘年会の企画を三宮.dev でも行っているが、bizpy と合同でやっていいんじゃないかと考えている。

Testcontainers

DB を使ったユニットテストのために Testcontainers Postgres Module を使ってみた。docker hub からイメージを取得して JUnit のテストプロセスの中からアクセスできるようにするためのライブラリになる。コンテナの扱いをテストコードから管理したいときなどに便利。ちょっと調べて簡単に設定できたのでまた時間のあるときに会社のブログに記事を書こうと思う。

1時に寝て5時半に起きた。体調はよいが、新しい環境で働き始めたのと勉強会が続いたのでややバテた。今日は軽めの活動で休むことにした。今日は打ち合わせが3つ入って、作業が途中でズタズタになって集中力を書いた。打ち合わせするなら固めて連続的にやらないとなかなか難しいな。今週は新しい環境での仕事もあって疲れてたので17時にお仕事を終えて、夕方にお昼寝して、夜にオンライン飲み会でだべってた。

朝活: ミクロ経済学入門の入門

[金朝ツメトギ] 2021-11-12 AM 6 金曜朝6時開催のもくもく会 で第8章のリスクと保険を読んだ。用語を次にまとめる。

• 条件付き財: 将来に特定の条件が成立したときのみ特定の行為を可能とする財
  • 例) 保険、賭けごと、宝くじ、投資など
• 確実性等価: 不確実な対価と、それと無差別になる確実な金額における経済価値
  • 例) 50%の確率で1万円もらえるくじを、千円払って購入するときのくじの価格を確実性等価という
  • 人々のリスクへの態度を分類する上で便利な概念になる

ある人は、それぞれの金額 m について、満足度の指標 U(m) をもっているとする。このとき U(m) を効用、U を効用関数と呼ぶ。

m が増えると U(m) 、つまり効用も高まるが、それには限界がある。増える量は 限界効用逓減 の形になる。次の図では U(5) から U(10) になると m は2倍になるが、効用は2倍にはならない。ここで 期待効用理論 では「人は条件付き財を、効用を発生確率で加重和した 期待効用 で評価する」と考える。この 期待値 は 0.5 * 1万円 + 0.5 * 0円 = 5千円となる。効用は 0.5 x U(10) + 0.5 * U(0) となる。

確実性等価が期待値より高いか低いかは個人によって異なり、少額でも確実にもらえるお金を好むと確実性等価が期待値より低くなる。これを リスク回避的 と呼び、多くの人々がリスク回避的だからこそ保険という商品が成立する。その逆で確実性等価が期待値より高くなることを リウス愛好的 と呼ぶ。また確実性等価が期待値が等しいときは リスク中立的 と呼ぶ。そして確実性等価と期待値の差額を リスクプレミアム と呼ぶ。

保険会社がある疾病の保険を提供し、顧客が加入する。顧客は自分がその疾病にかかりやすいかどうかを知っているが保険会社からはわからない。そのため一律の価格で保険を販売する。これを 情報の非対称性 と呼ぶ。この状態で疾病のリスクが高い人たちが増えていくと、保険会社はさらに保険料を引き上げる。それによってリスクの低い人たちが加入しなくなり、さらにリスクの高い人たちの割合を高めてしまう。これを 逆選抜 と呼ぶ。逆選抜の解消方法は、個々人のリスクとは無関係に強制的に保険に加入させてしまう。これが日本の国民皆保険制度と言える。さまざまな人のリスクを社会全体でヘッジ (低減) する仕組みであり、リスクの社会化と言える。

民間の保険会社が遺伝子検査などにより、利潤の追求のため、ハイリスクな顧客を除外しようとすることは不当なのかどうか、保険倫理に関わる難問である。この難問の存在が公的保険制度の意義が高めている。