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

ストレッチ

今日の開脚幅は開始前158cmで、ストレッチ後162cmだった。まだ右腰と右股関節、両腕の張りは少し残っているものの、先週末の田んぼ仕事の疲労はかなり抜けた。今週は暑くて家に帰ってきたらエアコンをつけてだらだらしていたのであまり数値はよくならないんじゃないかと思っていて、実際に開始前の数値はいま一つだったんだけど、ストレッチを受けたらいつも通りに戻った。トレーナーさんと雑談しているときにふと「毎日パソコンを使いますか？」と質問を受けた。トレーナーさんからプログラマーの自分にとってそんな質問をされるとは予想外で思わず吹き出して笑ってしまった。その質問は「毎日水を飲みますか？」と私にとっては同じですよと答えた。トレーナーさんも愚問だったと理解して一緒に笑ってた。

もてなしだけではもう食えない

第7章 ホテルが客を動かせ

ホテル側が自分たちの問題を解決するために客の行動を制御するといった展開になっている。米国のスーパーマーケットでは Express Lane という、購入品目が少ない客向けに手早く決済するためのレジが設けられているらしい。日本にはないのかな？この運用には客に学習コストを強いるのが欠点となる。キャパシティ問題の問題解決のアプローチは次の3つになる。

1. キャパシティを増やす
2. 供給を変える
3. 需要を変える

本章の展開としては3番目の客側の導線や行動を変えてしまう方法で需要を変える手法が説明されている。本題ではないけど、さらっと出てくる説明にも納得感がある。ダメなホテルの共通点として、他社でうまくいった改善策、ベストプラクティスに飛びつき、それ以上考えようとせず、問題の本質を理解しようとしない。そういうホテルはコンサルタントが去ってしまうといずれでダメな経営に陥るとある。ホテルに限らず、ダメな会社の特徴だと思う。

客にピーク時の利用を避けてもらうための施策として次の2つがある。

• 混雑することをあらかじめ伝えておく
• 混雑を避けることのインセンティブをつける

ホテル側が客の行動をコントロールするのは構わないが、客にとってそれが不利益にならないように配慮する必要がある。人間の心理として混雑することがあらかじめわかっていればクレームにならず許容できたりする。人は不意に混雑に出くわして不満をもつことが多いという。そういった人の心理を利用して人の行動を制御して経営に生かすという考え方は比較的新しい研究領域である。行動経済学などもその分野の1つで、古典経済学では人は合理的に行動するとされてきた。しかし、現実では必ずしもそうではないことも行動経済学によってわかってきた。

第8章 リスクを知らないリスク

親会社の不動産会社からリスク管理報告書を提出しろという業務に沿ってリスクマネジメントについての話題が出てくる。契約の話しだったり、建築に関する話しだったり、あまり一般的な経営とは異なる内容にみえる。余談だけど、過去にうちの会社で業務内容が変わったにも関わらず、契約内容を更新せずに更新された新たな業務を継続してうまくいかなかった経験がある。うまくいかなかったときに原点に立ち戻る場所が契約であり、契約を曖昧に扱うと後でしっぺ返しがあるという失敗をまさに経験した。ふりかえりをするときにそもそもの基準が適切でないとその反省や改善点も曖昧になってしまうという話し。

さて、リスク管理報告書のアウトラインとして次の用語が出てくる。

• ハザードコントロール
  • ハザードとは危険を生じさせるもののこと
  • ホテル経営だと、食中毒を防ぐ施策とか、横領できないように決済承認に2名以上必要とか
• ペリルコントロール
  • ペリルとは事件・事故のこと
  • 起きてしまった事件・事故から最小限の損害・被害に食い止める施策
• ロスコントロール
  • ロスとは事故発生時に発生してしまった経済的損失のこと
  • 具体的には保険購入であり、どんな保険にどのぐらいの補償額で加入するかになるが、これがなかなか難しい

peril という英単語の辞書を引くと、差し迫った危険という意味が出てくる。リスク管理の文脈の用語と英語の意味はやや違うのかもしれない。

第9章 タイムバリューを理解せよ

親会社に投資ファンドからホテルの買収提案があり、ホテルの事業価値を測るコーポレートファイナンスの話題が出てくる。上場企業であれば株価 x 発行済株式数で時価総額がすぐにわかるが、未上場企業の価値を査定するのは難しいという説明からその手法が紹介される。

• 類似業種比準方式
  • 上場している同業者の株価を参考にする
  • 但し、ビジネスモデルを無視して業種だけで比較しようとしても単純比較はできない

不動産を所有しているかどうかで株式評価は大きく異なる。単純に不動産をもっていればよいというわけでもなく、資産と負債のバランスが取れているかが大事。「また貸し」のことを業界用語で転貸 (サブリース) と呼ぶ。

• 純資産方式
  • 会社のもっているものを全部売って借金を返した残りのお金という評価方法
  • 貸借対照表の資本がマイナスになっているとすべてを換金しても負債が残る = 債務超過

株価の利回りを株価収益率 (Price Earnings Ratio: PER) と呼ぶ。時価総額 / 純利益で計算される。この計算式から時価総額を知りたければ、純利益 x PER で計算できる。比較可能な会社の PER がわかれば未上場会社の株価を計算できる。但し、PER は会社が未来永劫事業を継続させることを前提としている。会社の継続性に疑義があると PER を用いる根拠がなくなる。株主に説明するときの利益とは、正式には 税引き後当期利益 になる。この金額から配当がなされる。うちの会社だとざっくり粗利から20-30%ほど (法人税 + 消費税) 引いたものが税引き後当期利益になる。会社が予定する配当額は同じだが、株価をディスカウントすることで配当の利回りをよくするという考え方を リスクプレミアム と呼ぶ。会社の展望や事業の不確実性を数値化したとみなすことができる。

• 株価1000円で配当額が20円だと、利回りは2.0%
• 株価500円で配当額が20円だと、利回りは4.0% (この 2.0% の差がリスクプレミアム)

いま現在もらえる現金の1万円は1年後もらえる1万円よりも価値が高いと言える。それは1年後にはもらえないかもしれないリスクや運用機会損失リスクが含まれるから。その価値をどの程度低く見積もるかを 割引率 と言う。この割引率を用いて将来の現金をいまの現金価値に置き換える評価方法を DCF (Discounted Cash Flow) 法 と呼ぶ。仮に割引率を10%とすると、1年後の100万円をいまの価値にすると、100 / (1 + 0.1) = 90.9 万円になる。2年後の100万円だと 100 / (1 + 0.1)^2 = 82.6 万円になる。

本文中ではこの計算式を使って年間の利益と割引率を考慮した現在価値をエクセルでモデル化している。python で書くと次のようになる。

>>> def f(profit, discount_rate, year):
...   return profit / pow((1 + discount_rate), year)
>>> for i, profit in enumerate([100, 120, 125, 130, 135, 140, 145, 150, 155, 160, 165], 1): i, round(f(profit, 0.1, i), 1)
... 
(1, 90.9)
(2, 99.2)
(3, 93.9)
(4, 88.8)
(5, 83.8)
(6, 79.0)
(7, 74.4)
(8, 70.0)
(9, 65.7)
(10, 61.7)
(11, 57.8)

例えば、割引率が10%で5年後の利益が135万円ならば、その現在価値は83.8万円になる。本文の中ではこの金額が投資ファンドが提示している金額だとだいたい一致していることから、これ以上の精度の高いモデルを作らないといけないみたいなストーリー展開になっている。いずれにしてもパラメーターの変数の精度が高くないと適切なモデルとは言えない。割引率を用いた現在価値を計算する考え方を タイムバリュー (時間の価値) と呼ぶ。意思決定が遅れるほどプロジェクトの収益化も遅れるため、割引率を計算する現在価値が小さくなっていくという考え方ができる。

0時に寝て6時に起きた。金曜日は非稼働日だけど、今週は月曜日が祝日だったから普通に働いてた。

spring-webflux とプロキシ

たまたま api client 周りを触っている。それらは spring の WebClient で実装されている。WebClient は spring-webflux プロジェクトが提供している http リクエストを扱うためのクライアントでリアクティブプログラミングを用いた設計になっている。リアクティブという言葉がピンとこなければ非同期フレームワークを用いた http クライアントと言い換えても大枠ではあっているのではないかと思う。spring-webflux プロジェクトそのものはノンブロッキング、バックプレッシャーといった機能をサポートする web アプリケーションフレームワークを提供するもの。

• Web on Reactive Stack

Reactor というコアライブラリを使って spring-webflux のフレームワークは実装されている。このデータ構造の1つに Mono と Flux が出てくる。初見の開発者はこの名前のデータ構造がよくわからんというところから始まる。私がそうだった。ドキュメントの説明によると、Mono は0から1、Flux は0からNまでのデータ列の概念を扱うという。おそらく json のようなレスポンスを返す場合は Mono を使い、ストリームを返すレスポンスは Flux を使えばいいんじゃないかと思う。

Reactor is the reactive library of choice for Spring WebFlux. It provides the Mono and Flux API types to work on data sequences of 0..1 (Mono) and 0..N (Flux) through a rich set of operators aligned with the ReactiveX vocabulary of operators. Reactor is a Reactive Streams library and, therefore, all of its operators support non-blocking back pressure. Reactor has a strong focus on server-side Java. It is developed in close collaboration with Spring.

WebFlux requires Reactor as a core dependency but it is interoperable with other reactive libraries via Reactive Streams. As a general rule, a WebFlux API accepts a plain Publisher as input, adapts it to a Reactor type internally, uses that, and returns either a Flux or a Mono as output. So, you can pass any Publisher as input and you can apply operations on the output, but you need to adapt the output for use with another reactive library. Whenever feasible (for example, annotated controllers), WebFlux adapts transparently to the use of RxJava or another reactive library. See Reactive Libraries for more details.

https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html#webflux-reactive-api

いまローカルの開発環境では vpn 接続をしてプロキシ経由でアクセスするサーバーがいる。WebClient のプロキシ経由で通信できないという問題があることを同僚から教えてもらった。プロキシ経由でアクセスしようとすると認可エラーになってしまう。なにかしらプロキシ経由の接続に問題がある。

Caused by: io.netty.handler.proxy.HttpProxyHandler$HttpProxyConnectException: http, none, /10.100.101.10:8080 => /192.168.201.35:18980, status: 403 Forbidden

同僚は WebClient のデフォルトでは http の CONNECT メソッドを使って通信しようとするが、それを squid がサポートしていないか、設定を変更しないとダメなんじゃないかと話していた。その内容が正しいかどうか、私は未検証だけどデフォルト設定では通信できないことがわかった。ここで WebClient の設定の1つに ClientHttpConnector があり、任意の http client ライブラリに置き換えられる。ソースをみると次の4つの ClientHttpConnector が使えるらしい。デフォルトが ReactorClientHttpConnector になる。

  private ClientHttpConnector initConnector() {
    if (reactorClientPresent) {
      return new ReactorClientHttpConnector();
    }
    else if (jettyClientPresent) {
      return new JettyClientHttpConnector();
    }
    else if (httpComponentsClientPresent) {
      return new HttpComponentsClientHttpConnector();
    }
    else {
      return new JdkClientHttpConnector();
    }
  }

試しに jetty-reactive-httpclient を使って JettyClientHttpConnector に置き換えてみたところ、プロキシサーバー経由のアクセスができるようになった。

public WebClient create(String proxyIp, int proxyPort) {
    var httpClient = new HttpClient();
    httpClient.setFollowRedirects(true);
    httpClient.getProxyConfiguration().getProxies().add(new HttpProxy(proxyIp, proxyPort));
    var connector = new JettyClientHttpConnector(httpClient);
    return WebClient.builder().clientConnector(connector).build();
}

23時に寝て6時に起きた。今日は淡々と web api の実装をしてた。

シュレッダーの解体結果から

少し前に誤った書類を裁断していて用紙を3-4枚を一度にやろうとして力いっぱいまわしたら空回りするようになってしまった。メーカーのために取説には1-2枚とあるのでキャパシティ以上の負荷をかけた私が悪い。シュレッダーの刃は頑強だと実感していた分だけ別のところに弱点があることを失念していた。分解して歯車の部分をみてみると、歯車の一部が欠けていることがわかった。刃は頑強だが、どうやら歯車はそうではなかった。こんな小さい歯車が欠けるんだということがわかった。

このシュレッダーは2020年1月25日に購入してもう2年以上使っていて、手動で手回ししながら裁断する。ぷちぷちをやるような気持ちになるのでちょっとしたストレス解消にもなってた。購入時に amazon の悪いレビューには空回りするようになるみたいなコメントもあったんだけど、私はこれまで2年以上問題なく使えてきた。裁断するものの量と負荷が蓄積していくうちに歯車が壊れて空回りするようになるのだろうなと、今回の失敗から理解できた。

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

EKS クラスターのノードグループと k8s の nodeSelector

先日 k8s の nodeSelector の調査について書いた。いまテスト環境でその調査結果の運用検証中。当初は k8s の機能だけを使いたいと考えていたが、いま eksctl コマンドで EKS クラスターを管理していて、k8s ノードの実体である ec2 のプロビジョニングはノードグループがもつ起動テンプレートとオートスケールポリシーにより制御される。そのため、ノードグループを分割してそれぞれにノードラベルが必ず付与されるように管理する方が簡単だとわかってきた。要はアプリケーションサーバー向けのノードグループとバッチ処理向けのノードグループの2つを作った。あと覚えておくとよいのが、Adding a custom instance role で任意のポリシーもノードグループの iam ロールに追加できる。設定例としてはこんな感じ。

  iam:
    attachPolicyARNs:
    - arn:aws:iam::${accountId}:policy/my-custom-policy
    - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
    - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
    - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
    - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

ノードグループの準備が整ったら nodeSelector を指定した pod をデプロイするだけ。k8s ノードがどんなノードラベルをもっているかは次のようにして確認できる。

$ kubectl get node --show-labels

意図したノードラベルが付与された k8s ノードに pod がデプロイされたかどうかは次のようにして確認できる。

$ kubectl get pod --output wide --field-selector spec.nodeName=${ノードラベルをもつノード名}

これらの環境構築、検証、wiki にドキュメントを書いて本番作業手順もまとめた。一通りきれいにまとまったインフラ作業を完遂できて気分がよい。

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

2つ目のサービスイン

スプリントの最終日が今日になる。しかし、今日はサービスインの作業でバタバタしているので主要な開発者は運用サポートしたり、PO もシステムの切り替え対応で fix したタスクの検証ができないといった理由でこれ以上タスクを進捗できそうにないことを容易に想像できた。スプリントゴールに掲げたタスクのうち、9項目中2つしか完了してないという状況だった。ちょうど夕方にスクラムのふりかえりもあったので、今回のスプリントは一体何なの？みたいな懸念から始まって、やる必要があるのかないのか曖昧な優先度設定はよくないという意見が出ていた。サービスインする週にスプリントをやるのもおかしいというのは前回も私はコメントしていたんだけど、今回も全く同じことが話題に出ていて、過去の失敗から学ばないチームになってた。

個人的に、開発のマネジメントにおいて、できもしない (やる気もない) 納期を設定するのが嫌い。私が古い人間なのかもしれないけど、納期が設定されてそれが大事なんだと認識したらどんな手段を使っても納期に間に合わせようとする。例えば、泊まりがけで開発したり、深夜早朝・休日に開発したり、大事なんだったら間に合わせる。しかし、労力を払って間に合わせたものの、他のメンバーやタスクはそうじゃなかったりして、遅れても何も起きないとがんばってやった人がしんどかっただけで終わる。過去にそういう状況を何度も経験してきてやる気をなくすことが多かった。

もてなしだけではもう食えない

第6章 営業予算の使い方

米国帰りのマーケッターという新たな登場人物。学部から米国の大学に留学すると米国史を英語で学ぶのが大変みたいな余談が出てくる。日本史は2000年を長く薄く勉強するが、米国史は200年しかないから内容が濃いのと最近の話だから史料も多く細かい史実を学ぶ必要があるという。全然、本題じゃないけど、歴史好きの私としてはおやと思えて楽しめた。いくら敏腕なマーケッターでも業務知識がないと空回りしてしまう。マーケティングの精度をあげるために必要ならば、その教育コストもマーケティング予算から捻出すべきだといった話しも出てくる。普段、会計システムに勘定科目を調べながら経費を入力している私にとってはなるほどなぁと、またまた本題ではないところで感心してしまった。

統計学のp値が5%以下ということは95%の確率でそのデータ上の差が実際に起き得る確率を表す。統計学は大事だとか、エクセルを駆使してデータ処理しろとか、そういう話題も出てくる。あとは古典的なマーケティングの手法として AIDMA モデルが紹介されている。基本的な考え方として知っておいたら役に立つときもあるかもしれない。

1. Attention (注目)
2. Interest (興味)
3. Desire (欲求)
4. Memory (記憶)
5. Action (行動)

例えば、Attention は情報誌に広告を出してみてもらうようなフェーズを指す。みてもらったら Interest に移る。口コミの内容で興味をもってもらうとか。興味をもってもらったら Desire として実際のサービスを体験してもらったりしてより強い欲求をもってもらう。一般論として Desire から Action へは間があくこともある。記憶させておいてそれを呼び戻すためのフェーズが Memory になる。最後の Action で成約を得て収益になるといった一連の流れを指す。

23時に寝て9時に起きた。昨日の疲労でよく眠れなくてバテてた。午後から会社の雑務をしていた。

もてなしだけではもう食えない

少しずつ読んでいく と書いてから3ヶ月読んでなかった。ホテルに限らず、ビジネス一般論としても通じるところが多かったように思う。経営の一般論とでも言うべきか。

第3章 お客さまは神様とは限らない

• ビジネスの世界は大学のケーススタディみたいに物事がきれいに整理されているわけじゃない
• 顧客満足度とは本来、企業収益と正の相関関係があるはず
  • 正の相関関係とはAが1増えたらBが1増える
  • 相関係数は-1から1まで
  • 1だと正の相関係数が最大で、0だと無関係、-1だとBが1減る
• 顧客のロイヤリティとは、再訪するか、他者に推薦するか、商品やサービスに対する信頼や共感を指す
  • ロイヤリティには2つの意味があって、これはマーケティングの分野で使われる意味
• 従業員満足度の向上が対外サービスレベルを上げ、それが顧客満足度を上げ、結果としてオーナー満足度を上げる
• 放置できる不満は放置される、経営学的にみて正しい行い

主人公は学生時代の成績が悪かったことから分からないと言えることが強みという説明文が出てきて、教授の説明が理解できないときにどんどん質問して丁寧に説明してもらうというやり取りになっている。この言葉を引き出すために主人公は仕事ができない人設定にしているのかとも考えられる。異世界モノにしてしまえば、こんな説明はいらないなとか読んでて思った。

第4章 「立ち入り禁止」の向こう側

会計は用途によって会計基準が異なる。

• 財務会計: 損益計算書や賃借対照表といった財務諸表に集約される
• 管理会計: 経営者が経営状況を把握するための会計書類作成の基準となる
  • 部門別損益やセグメント別の分析などをする
  • 会社ごとにばらばらでもよい
  • 経営者が知りたい情報が指標になっていればよい

ユニフォームシステムという部門別損益を計算するホテル業界の標準的な会計基準について紹介されていた。米国発祥なので日本での普及率は低いらしい。この話題の中でマネージャーの業績考課やボーナス査定の話しが出てくる。そして、マネージャーのコントロール外の非配賦費用を部門別会計に含めないのはマネージャーの実績を測れないからだと説明されている。つまり、ユニフォームシステムという管理会計の仕組みと人事システムはセットでないと業績改善効果が薄いという話しにつながる。人事というのは本当に難しいことが伺える説明だと思えた。

管理会計によって部門別の損益の悪いところが明らかとなり、そこに対する改善案が進みそうなストーリー展開になってきた。小説風なのでストーリーが進むと、その先の展開も楽しみになってくる。

第5章 数字を分解せよ

投資計画に対して懐疑的になる背景としてフィージビリティスタディの話題が出てくる。私は言葉を知らなかったので勉強になった。ここではセグメント別に分割して大雑把な小さい数字を推定していくことから始め、その数字の裏付けをより精度の高い手法で行うことで現実的な企画ができるみたいな組み立てになっていた。

• 投資がどのぐらいの経済効果をもたらすのかを予測することをフィージビリティスタディ (feasibility study) と呼ぶ
  • 日本語では事業化可能性調査、または採算性調査と呼ばれたりもする
  • 収益と投資額の2つの情報から利回りが何%かがわかる
  • できるだけ数字を分割して考えるのが基本
    • フェルミ推定を使って大雑把な数字から算出するやり方もある
  • 投資によって「追加的な売上」ではなく「追加的な粗利益」を測るべき
• RFP (Request For Proposal): 提案提出依頼書を作る
  • 専門家へ依頼するときにコンセプトデザインを明確にする
  • コンセプトを専門家に正しく伝えないと適切な提案を受けられない
• 自分の会社のリソースを確認し、その比較優位に従って企画を立てるのがマーケティングの王道の考え方

主人公からなぜ横文字を多く使うのか？という質問に対して、コンサルタントの教授が答える。まだ定着していない概念を的確に表すには英語のまま使っておいた方がよいという説明が出てくる。私もこのことは全く同意で、もっと言うとカタカナにせずにアルファベットのまま英語で使うとよいと考えている。本題ではないけど、大型連休はプロジェクトの進捗に影響を及ぼすので考慮にしとけよというやり取りが急に出てきてリアリティがある。私がいま手伝っているプロジェクトは GW の休暇を考慮せずにロードマップを策定していて、私が2回ぐらい指摘してあるとき修正されたことがあった。

1時に寝て5時に半に起きた。朝から夕方まで田んぼの草刈りをしていた。

草刈り

タイトルに1年と書いたけど、厳密には1年も経っていない。2021年10月以来の草刈り になる。本当は小まめに田んぼの手入れをしていれば、草場になんかならない。

6時から草刈り機を使って草刈りを開始。もう1時間早く起きて5時から始めたらよかったと思った。夏は10時まわると暑さが厳しくなるので作業は10時までに終わらせるのがよさそう。今回は6時から11時前まで草刈りをやって6割程度を刈り込んだ。草刈り機は2サイクルエンジンなので混合ガソリンを燃料に使う。ちょうど燃料切れになったのと同じタイミングだったので午前中の作業を終えた。11時の時点での田んぼの状況。

昼間は暑いので長くお昼休憩をとって14時から再開。本当はもう少し遅くてもよいけど、私が神戸に戻らないといけないから少し早めに始めた。まだ7月だったせいか、14時でも想像よりは暑くなくそれでよかったとも言える。午後から母がパートから戻ってきたのもあり、交代して休みを取りながら草刈りをして16時にはほぼ完了できた。この後、少し残っているところを母にやってもらって私は17時の高速バスで神戸に戻ってきた。

この時期の草刈りは、草刈り機を使うことそのものの疲労に加えて暑さでバテる。2人いて交代で草刈りすると、休んでいる時間を有効活用できて効率がよいことに気付いた。草刈り機のエンジンの回転数も全開にするよりも、少し弱めた方が振動量が減って、腕の負担も燃料消費も少なくなってよいことに気付いた。いままで全開で刈った方が早く刈れるのではないかと考えていたが、それは誤りだった。疲労度を下げて草刈り機を扱った方が休まずに長時間作業できる分、全体として作業を速くできることに気付いた。

この後、草を干して乾燥したら焼いて、トラクターで田んぼを耕す。それは9月の連休にする予定。

ストレッチ

今日の開脚幅は開始前154cmで、ストレッチ後158cmだった。あちこち筋肉痛やら腰が痛いやらでストレッチできるような状態でもなかった。ストレッチへ行ったときは暑さにやられて頭痛がひどかったんだけど、ストレッチしているうちに徐々によくなってましになった。暑さで頭痛がするのは血行が悪くなるからだそうだけど、ストレッチして血行がよくなるんだと推測する。腰の張りがひどくてストレッチしてもらって少し楽になった。田んぼ仕事の後にストレッチを受けられるのは疲労回復のためによかったと思う。

1時に寝て7時に起きた。実家に帰ってお見舞い行ったり親戚訪問したりしてた。

お見舞い

午後から父のお見舞い。少し前まで直接面会できるようになっていた時期があったそうだけど、またコロナの感染状況が悪化したため、リモート面会に戻ったらしい。面会時間は20分。たまたま父はお風呂上がりの時間だったらしくてそれで疲れたのか、10分ほどしてそのまま眠ってしまった。もともと父は気管切開していて話せないので起きていても寝ていても面会でやることは変わらない。顔色がよいことは確認できたという感じ。

博士ちゃん

たまたま実家に帰っていたからテレビをみていたらおもしろかった。生物の標本や骨に関心のある小学6年生が、国立科学博物館の収蔵庫を見学するといった番組だった。著名な研究者の方々が案内しながら子どもに研究のおもしろさを知ってもらうような作りになっていたように思う。出演していた12歳の子どもが本当によく勉強していて詳しくて、この分野の研究が本当に好きなんだなという想いがみてとれてよかった。好きなことを突き詰めてやっているのをみると楽しくなる。

• 約480万点の資料が収められた 国立科学博物館の巨大収蔵庫潜入 完全版！

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

煩雑な検証

昨日の続き。午前中に pr を作成してレビューしてもらってマージしてデプロイして検証した。いくつか既存の設計には課題があると思いつつ、工数かけて直してくれという依頼は来ないのもわかっていて、煩雑なコードに煩雑な検証をやるだけにとどめた。テスト環境での検証自体は成功したので問題はなさそう。一部、本番環境でないと検証できないらしい。

会社のテックブログ談義

最高のテックブログを書くために気をつけている3つのこと というブログ記事をみかけた。内容はとても素晴らしいと思う。一方で会社のテックブログでこんな品質を求められたら、品質を満たせない執筆者のモチベーションを阻害しないかということがやや気になった。そんなもやもやを、こみやさんとまさひとさんに共有したらテックブログ談義が始まっておもしろかったのでまとめておく。会社のテックブログと言えばクラスメソッドさんが有名なので引用する。

もちろん弊社では、ブログを書くことを業務上の成果としても評価していますので、このブログを書くこと自体が評価につながるモチベーションになっています。

…

どのように評価をしているかと言うと、1つは本数という指標です。弊社では月4本エンジニアがブログを書くことを推奨しています。これは罰則はないので、書けていないからといって減点をすることはありません。逆に書いてるからといって加点をすることもありませんが、月4本を推奨していますし、10本書く人は高評価ということで「ブログのプロ」と呼ばれることがあります（笑）。その月は「10本書いたからプロになったね」というようなことを社内で言われたりします。

…

業務上の評価ということで、先ほど「減点・加点しないよ」というお話をしたんですが、3ヶ月に1回、ブログの本数とSNSのシェア数とビュー数が多い人に対して表彰をしています。やはり継続的にアウトプットをしているとこういった場面で表彰される機会も増えるので、社内でも「この人はたくさんブログを書いてるんだ」「この人はすごく高いスキルを持ってるんだ」と認められ、評価にもつながります。もちろん上司からも、技術ブログを書いてアウトプットが多いことが高い信頼につながります。

なぜ技術ブログを書きまくるのか？　『Developers.IO』のクラスメソッドが伝える、エンジニアの成長サイクル

みよ！この評価しているのか、していないのか、はっきりしない曖昧な制度設計を！

「テックブログは開発者がやるべき業務とみなしていますか？」と尋ねると、多くの会社では業務時間に書いてもよいけど必須でもノルマでもないみたいな答えが返ってくるのではないだろうか。業務に含めたくないのは、本質的に優先度の低い業務だという事実と、一定以上のコストをかけてまでテックブログに価値があると会社も考えていないのではないかと思う。業務とは言い難いので区別のためにここではテックブログを書くという 活動 と呼ぼう。

そして、個人のモチベーションに期待した活動を安易に評価の対象にするのは想像以上に厄介な制度設計になる。メタ認知で〈学ぶ力〉を高める：認知心理学が解き明かす効果的学習法 を読んで私は理解できたことなんだけど、おそらくクラスメソッドさんの (曖昧にみえる) 制度設計の裏には認知心理学の知見がある。

• 外発的動機づけ: 金銭や物品などの物的報酬、よい評価を得るといった社会的報酬など
• 内発的動機づけ: 自分がそれをしたいからする、知的好奇心など

外発的動機づけは内発的動機づけと比べてずっと弱い動機づけであることがわかっている。ここで外発的動機づけの業務から始めて内発的動機づけの活動に変わっていくこと自体は問題ない。スクラムで言及している自己組織化や自律的な行動というのは内発動機づけによる活動に変わっていくことを期待している。会社の制度設計として難しいのはこの逆はよくないという話しがある。内発動機づけで行動していた活動を外発的動機づけに置き換えてしまうことだ。テックブログのような、本人が自己学習やアウトプットを目的に自律的にやっていた活動に、安易に金銭的な報酬を与えてしまうと、お金のためにやっている業務に置き換わってしまってやる気をなくしてしまうという懸念がある。余談だが、褒めることそのものは副作用のない安全な報酬と認知心理学の研究からわかっているらしい。クラスメソッドさんが表彰という制度設計にしているのは、本人のやる気をなくしてしまわない報酬を考慮しているからかもしれない。

またコンテンツの所有権という側面からテックブログは会社のものだから、自身のブランディング戦略とは相性がよくない。これは 限定合理性 の話しとも関係してくる。開発者に限らないが、転職を当たり前にする時代で個人ブログに記事を書く方が開発者にとってのメリットがある。「会社ブログに書く動機はなにか？」は、人それぞれの理由があるだろうけれど、その理由が明確でないと消極的に会社ブログは書かないという帰結になるのではないか。私の経験則においても、会社のテックブログを書く開発者は圧倒的に少数である。私は過去に会社のテックブログを書いてきたモチベーションは単純にアウトプットすることで自身の勉強になるなら書く場所はどこでもよいという考えがあった。補足としては、会社の利益 (採用) に貢献しようとか、会社のテックブログを書く開発者が少ないという希少性に着目して自身をアピールするとか、そういった考えもあったと思う。

若い開発者にアウトプットする習慣を付けてもらう取っ掛かりとしてテックブログはよいのではないかという話題も出た。開発者のスキルアップのために会社がどこまでコストをかけてサポートするかという話題でもある。その延長上に評価制度もあるなぁと voyage さんの技術力評価会の資料もみてたりした。会社のイベントや業務を通じて、自然とアウトプットに関するスキルが身に付いて行動できるようになるなら本人のキャリアにとってもよいことではある。私は 書く という行為は開発文化から影響を受ける側面が強いと考えていたけど、voyage さんの制度はその下地を組織として支えていく仕組みになっているのかもしれない。

• 5分でわかる技術力評価会

1時に寝て7時に起きた。久しぶりに HELLSING をみてた。アレクサンド・アンデルセンの狂信者ノリが好き。

煩雑な保守

昨日から着手した s3 とやり取りするアプリケーションの保守をしている。一通り機能は実装できたが、このアプリケーションの保守を今後どうやっていけばいいのかが私からはみえない。要件が変わる度に継ぎ接ぎで拡張してきて、意図をもった設計があるわけではないようにみえる。このまま保守することはできるかもしれないが、このロジックの説明もテストも検証もすべてが難しい。私がみても難しいのだから、経験の浅い開発者がみるともっと難しいのではないかと思う。

これを直すにはまず単体テストを直さないといけない。単体テストの大半がモックベースなので実際の振る舞いと異なる可能性がある。とくに s3 とやり取りするところの検証ができない。testcontainers の localstack があるので単体テストはモックからこのモジュールを使うように代替できそう。まずはそこからやるべきだが、2-3日はかかると見込まれるのでチームで承認を得られるかどうか、ちょっと聞いてみてから考える。

Job Summary を使ってみた

ちょっと前に github actions のワークフローの実行画面にサマリを出力できるようになったという記事をみた。

• Supercharging GitHub Actions with Job Summaries

自動でよさげなサマリを出力してくれるわけではなく、自分でサマリを作らないといけないので面倒だなと思ってそのまま放置していた。先週末に モジュール別のビルド・デプロイのワークフロー改善 を行った。ふとワークフローの実行結果をみていて、選択したモジュール名が表示されているとわかりやすくていいなと思えた。それを出力する手段としてサマリがちょうどいいやということに気付いた。inputs などで動的に変更するパラメーターをワークフローの実行画面で確認できるといちいちログ確認する手間が省けてよいという場面が他の用途でもある気がしてきた。もっと積極的にサマリを使っていこうと思えた瞬間だった。

1時に寝て5時半に起きて7時に起きた。夏バテなのか朝起きれなくなってきた。

localstack 入門

s3 とやり取りするアプリケーションの保守を手伝うことになった。いま開発環境向けに minio を使っていて、そのためだけにトリッキーな DI を実装している。そのコードがトリッキーなだけに知らない人がコードをコピペしてトラブルを起こす火種になってた。minio 使う必要性はまったくなく localstack を使えば解決できるのを、誰もその保守してなくて、仕方ないからこの機に私がやることにした。すぐにできるやろと思ったら意外にはまって2-3時間デバッグに時間を取られたので書いておく。

簡潔に言うと、(おそらく歴史的経緯で) minio は基本的に path style で s3 api を扱う。virtual hosted style でリクエストするとアクセスできなくてどうやって解決するのかが分からなかった。ググって出てきたどこかの開発者の言っている通りで path style は deprecated していて、aws も削除するとまで宣言していて、いつなくなるかもわからないのに未だにそれがデフォルトというのはどうなの？っていうお気持ちを表明している。

Beware accessing @_localstack using an AWS S3 client configured with virtual hosted style access: GET my-bucket.localhost:4566/prefix/my-object.txt wrongly 404 errors, but a path-style GET localhost:4566 /my-bucket/prefix/my-object.txt succeeds!

— James Shaw (@hertzsprrrung) October 27, 2020

私も同意見で issue をよくよく調べてみると次のエンドポイントに対しては virtual hosted style でアクセスできた。localhost に対しては path style で動いていて、virutual hosted style は localhost.localstack.cloud という、よくわからんドメインを使わないといけない。ドキュメントには書いてなくてググって辿り着く issue のコメントをみてたら気付いた。

• Support for s3 bucket subdomains #2631

mybuket.localhost.localstack.cloud 

aws-sdk-java v1 のコード例だと次のようになる。バケット名は実際にリクエストするときのパラメーターから s3 client がセットしてくれるのでこんな感じ。

var endpoint = new AwsClientBuilder.EndpointConfiguration("localhost.localstack.cloud:4566", "ap-northeast-1");
var client = AmazonS3ClientBuilder.standard()
        .withEndpointConfiguration(endpoint)
        .build();
return client;

こんな初期設定でつまづくと、このライブラリを使うのをやめようかという気持ちになる。ちゃんとドキュメントに書いておいてほしい。

窓付きオフィスの空きをみつけた

エリンサーブさんの内覧 に行ってきてから縁があればという感じでオフィス引っ越しは待ち状態になっていた。いま契約しているところの別オフィスで 神戸旧居留地 のサイトを、たまたま今日みたら窓付きの部屋が空き予定だと書いてあった。

7F-07 7月末空き予定 ￥69,300 ￥6,600 2名 6.22㎡ 完全個室/窓付き/棚付き

家賃はいまより 31,900 円増える。年間にすると 382,800 円のコスト増になる。高くはないけど、いまの環境でもう少し続けたら？と言われたらそれでもいっかと思えるぐらいのコスト感。優先度は高くないが、縁があるなら見逃す手もないといったスタンスで臨む。ひとまず明日、電話してまだ空いているなら内覧できるかを聞いてみるところから始める。内覧してよさそうな場所だったら引っ越しを検討する。7月末って急な話だけど、小さいオフィスなので本気出せば レントラ便 で2時間もあれば引っ越しできるはず。荷造りの準備に1時間、搬送に1時間といったところかな。