23時に寝て2時に起きてその後どうしていたかあまり覚えていないが気付いたら8時だった。

ストレッチ

今日の開脚幅は開始前160cmで、ストレッチ後163cmだった。今週も全然ストレッチできなかったのになぜか数値はよくなっていた。ストレッチを受けていて調子の悪さも感じなかったので気候が過ごしやすくなってきて体調がよくなった結果として普段の生活における活動量や新陳代謝などにも影響を与えているのかもしれない。トレーナーさんからは涼しくなったのだから運動をしてくださいと言われた。ほんとその通り。

知識と経験

• You’re Not a Senior Software Engineer

たまたま目を通した medium のおすすめ記事に出ていて、タイトルにひかれて斜め読みしたらおもしろかったので後で deepl を使って精読した。最近は英語の記事を deepl で訳して読んでいる。まず deepl で全訳した後に文脈から訳文の意味をとれなかったり、明らかにおかしいところだけを手直しする。著作権的に機械翻訳を公開はできないため、その翻訳内容は課題管理システムのイシューで管理している。この記事だと手直し数回ぐらいで大意を読める。普段、英語の記事を日本語アカウントで紹介することはないんだけど、これは素晴らしい内容だったのでそのまま共有することにした。軽く所感も書いてあるが、課題管理システムのイシューにはさらに詳細な分析やコメントも残している。

知識とはやり方を知っていることで、経験とはやってはいけないことを知っていること。素晴らしい記事だった。 / You’re Not a Senior Software Engineer by @repsofsunshine https://t.co/3qitFOFTJp

— Tetsuya Morimoto (@t2y) September 10, 2022

多くの若いチームでは課題管理の重要性を理解していない。その無理解の原因の1つとして、ものごとを検討したり判断したりした時点では正しかったことが未来のある時点で誤りになってしまう可能性を想像できないからだと私は考えている。記憶と忘却の仕組みから前日のことですら半分以上忘れてしまうので数ヶ月前の詳細など、ほとんどの人は覚えていない。にも関わらず、日々の小さい判断の積み重ねや意思決定の履歴を記録として残さないのはなぜだろうか？それはその詳細があとで重要になるかどうか、多くのケースでその発生時点ではわからないからだ。例えば、システムのアーキテクチャに関して言えば Architectural Decision Records (ADRs) というドキュメントが提唱されている。アーキテクチャのような大きなものでさえ、明示的に残さないと経緯がわからなくなるのに、もっと小さい粒度である日々の開発や運用の誤りを、一般の (普通の) 開発者がその発生時点から数ヶ月や数年経ってふりかえって見直すことができるだろうか？いやできないというのが、多くのチームやメンバーをみてきた私の所感だ。多くのメンバーは過去のある時点の見逃しや判断ミスをなかったことにしようとする。それは無意識にしろ意識的にしろ起きやすい。客観的に詳細を確認できればなかったことになってしまうのは仕方のないことでもある。

私は課題管理システムのコメントに、こういう状況からこう判断したとか、誰それと相談してこういう事情でそうしたとか、自身の感覚からとくに意味もなく決めたとか、常々なぜに相当する内容を残している。そして、あるとき過去の経緯を見返して、そのときの判断は適切だったか、過去のある時点で気付けたはずのことを見逃してなかったか、見逃していたとすればどうすればその時に気付きを得られたか、というふりかえりを日常的なチケット整理の一環として実践している。件の medium の記事にはなぜそれが重要なのかの概念を書いてあるように私には受け取れた。課題管理 + 情報共有の需要な概念の1つだと認識して寝かせておこうと思う。

1時に寝て7時に起きた。開発の作業しようかと思っていたけど、なんか気分が乗らなくて本を読んでただけだった。

ストレッチ

今日の開脚幅は開始前158cmで、ストレッチ後162cmだった。まずまずの数値でストレッチを受けていても調子がよかった。気温が下がって暑さが和らいできて体調もよくなってきた感じがある。以前から姿勢があまりよくないといったアドバイスを受けていて、前側の筋肉に比べて後側の方が相対的に強いから後側の筋肉を多用しようとして腰に負担がきているといった話しがある。姿勢を保つときに腹筋を使うように意識した方がよいといったアドバイスをトレーナーさんからもらった。

正史 諸葛亮孔明

「第四章 赤壁の戦い」を読んだ。

孔明が軍事の指揮をとるのは劉備の死後になるので、劉備の生前に起こった赤壁の戦いで伝えられる孔明の逸話は基本的にすべて嘘になる。演義では十万本の矢、東南の風、龐統による連環の計までもが創作らしい。赤壁の戦いの功労者は呉の都督だった周瑜の戦略によるもので戦う前から結果がみえていた。周瑜が用意周到に準備した戦略通りに魏軍がはまり、そこに周瑜の部下である黄蓋が提案した火計が成功をおさめたという。これはこれでおもしろくて戦いとはその前の準備の段階で決着がついているという見方ができる。周瑜は都督で全体の戦略を描くものの、実際の戦場における戦術は積極的に部下に任せるというスタンスをとっていた。また実際にはこれは大きな戦ではなく、小競り合いと決定打だとなった火計はあったものの、魏軍で流行した疫病による撤退というのが史実だと言えるらしい。演義における赤壁の戦いが大創作になっている背景として、三国志演義が編纂された時代 (実際の赤壁の戦いから千年後) にあった 鄱陽湖の戦い がモデルになっているのではないか。また孔明の神算鬼謀も朱元璋に仕えた 劉基 からきているのではないかという話しでもあるらしい。

ストレッチ

今日の開脚幅は開始前155cmで、ストレッチ後161cmだった。開始前の数値が悪いけど、とくに調子が悪いというわけでもなかったので計測の仕方がよくなかったか、たまたま足の開き方が悪かったかといったところだろう。昨日、高級時計と投資の話しを聞いたのでトレーナーさんとお金があったら何に使う話しが盛り上がった。トレーナーさんも庶民的な方でとくにお金があっても贅沢をしたいというものでもないらしい。私も改めてお金があったら何がしたいかを考えてみてもお金を使ってやりたいことはとくにないなというのが率直な思いでもある。私には自分がやったことのないことをやってみたいという思いしかなく、そのためにお金を使ってきた側面も多々あるけれど、お金を直接的に使って何かをやるというよりも、生活できるだけのお金があれば、その時間に自分がやったことのないことに挑戦して人生を楽しむということぐらいしかやることはないんだなと、トレーナーさんと話していて考えたりしていた。

os 雑談

午後から昨日の障害のふりかえりといくつか調査をして、夕方におがわさんに声をかけたら話し相手になってくれると返ってきた。障害のふりかえりをした後に課題管理の雑談もしていて4時間弱ぐらい話してた。私自身、反省しないといけないとは思っていたのでおがわさんはちゃんと指摘をしてくれた。この歳になると私を叱ってくれる人はいない。たまに失敗したときにおがわさんに話して然るべき指摘をしてもらえるのは本当にありがたい。

kubernetes がどうやって動いているのかを理解して運用しているのか？

コンピューターがどうやって動いているのかを理解しているのか？

私が未熟で理解できていなかったからこんな障害を見過ごしていた。システム障害が発生しても人生は終わりじゃない。反省してから次につなげる。おがわさんと話していて、os の仕組みや機能についていくつか教えてもらった。

• 制限対象の違い
  • ulimit はユーザーに対する制限
  • /proc ファイルシステムはシステムに対する制限
• /proc/sys/kernel/pid_max は kernel のデフォルト値として 32768 が設定されているが、systemd を使っていれば値を変更している場合がある
  • 私の ubuntu マシンだと 4194304 が設定されていた
• コンテナ内から /sys/fs/cgroup/memory/memory.usage_in_bytes をみると、コンテナが使っているメモリ量なのか？
  • cgroup の使い方次第で変わる、システムの値かもしれないしコンテナの値かもしれない
• ゾンビプロセスに残っている情報は親プロセスが子プロセスの統計情報を取得するために必要なもの
  • どんな子プロセスも一時的にはゾンビプロセスになる
  • kernel の task_struct 構造体やその他の構造体、リンクしている情報などをすべて足すと1つのゾンビプロセスが10数 KiB 程度ではないか
    • 仮に 15 KiB として 32000 個のゾンビプロセスがあると約 469 MiB のメモリ量になるのでだいたい数字があう
• ユーザー空間とカーネル空間の違いを理解できるようになった方がよい
  • システムコールの fork がエラーになるのはシステムがおかしいとすぐに気付けるはず
    • fork がエラーになる原因として考えられるのはメモリを確保できないか、pid_max に達したか、いずれにしてもエラーコードをみれば推測がつくのではないか
• 環境にログインできるのであれば strace を使えば障害調査に役立つ
  • 私が普段使っていないツールなので障害のときにとっさに扱えるよう練習しておく

夕方から寝ていて何度か起きたものの、そのままずっと寝ていた。あまりないことなんだけど、珍しくたくさん眠れた。

ストレッチ

今日の開脚幅は開始前160cmで、ストレッチ後163cmだった。計測の仕方がややいい加減だった気もしたが、先週より少しよくなったということにしておく。右腰の張りが強いのと肩が前に入りがちなので肩を開いて姿勢を保つように心がけるとよいとアドバイスをいただいた。もう通い始めて1年半ぐらい経つ。トレーナーさんも大半が入れ替わっていて通い始めたときに話しかけてくれた私が知っているトレーナーさんはほとんどいない。1年半も経つと人は変わっていくなというのを実感している。私の最初のトレーナーさんは社内制度で別の店舗の助っ人に行っているのでいなくなった人たちが辞めているわけでもないとは思うけど、1-2年で人が入れ替わってもサービスは継続していかないといけないし、会社ってそういうものだなと実感する機会でもある。

aws インフラの調子が悪い？

1-2週間ぐらい前からテスト環境を含めると複数回発生している eks クラスターの障害 がたまたま土曜日の夜という休日に発生した。いま eks クラスターのインフラの振る舞いを把握しているのは私だけなので、気付いてから指示を出して問題が発生している k8s ノードの削除 (ec2 インスタンスの削除) で復旧させるワークアラウンドで復旧させた。私は本番環境にアクセスできないので詳しい調査はできない。状況を正しく把握できてはいないけれど、k8s ノードが死んだり生き返ったりする不安定な状況に発生しているらしく、k8s ノードを削除して新規に作り直すと復旧することがわかっている。NotReady と Ready を繰り返したりしてアプリケーションの振る舞いが不安定になる。NotReady,SchedulingDisabled になれば、おそらく drain して k8s ノードが入れ替わってくれるのだけど、そうならない不安定な状況があるみたい。これ以上の調査は aws のサポートに問い合わせないとわからない。

ストレッチ

今日の開脚幅は開始前158cmで、ストレッチ後161cmだった。先週よりやや数字が悪くなった。それでも先週はストレッチを受けていても体全体のだるさのようなものを感じていたのが、今回はちゃんと筋を伸ばしている感覚があって先週の体調の悪さはなくなったように思える。右股関節周りの詰まりに加えて、右前ももの張りがいつもより大きかった気がする。毎週ストレッチを受けていると物理的な体調の良し悪しもわかるのがよい。

わざと負ける理由

一昨日からリアルタイム対戦 にはまっている。数をこなしていてわかってきたことがたくさんある。戦略シミュレーションゲームはやればやるほど学びがある。

• パーティーの特性によって相性のよい対戦相手とそうじゃないのがある
  • リアルタイム対戦のマッチングは選択できないのでマッチングしないと相手がわからない
  • 相性の悪い相手だとマッチング時点で辞退する (負けを認める) 相手もいる
• こっちの戦略に呼び込むための布石がいる
  • 3つぐらい戦略を用意して最終的にどの戦略に呼び込むかを相手の動きをみながら考えないといけない
  • キャラを動かす制限時間が15秒なのでわりと忙しい
  • こちらの布石にはめて最終的に勝てると達成感がある
    • 中盤まで負けていて向こうに勝ったと思わせて逆転できるとなお嬉しい
    • ダークドレアム は奇数ターン (1, 3, 5, 7 …) ごとに攻撃力・守備力・すばやさ・かしこさが1段階上がるバフがかかる
      • ダークドレアムはすばやさが低いので徐々にすばやさが上がっていって先制できるようになると最後の1手違いで勝つ状況が出来上がる
      • ダークドレアムで5ターンまで戦闘を継続できれば勝率が高い
• すばやさの高いパーティーには何もできないから勝てない
  • 高すばやさ (且つ、高火力または状態異常) パーティーには絶対に勝てない
    • リアルタイム対戦でダークドレアムがあまり使われていない理由だと思う
  • 初手前にパーティーの半分ぐらいがやられている
  • 相手の攻撃が届かない初期配置がないので絶対に防げない
• 状態異常攻撃の主体パーティーは対戦していておもしろくない
  • 混乱・麻痺・眠り・魅了といった状態異常になると2ターン何もできない
  • 状態異常攻撃 + 高すばやさのキャラの攻撃を防ぐ方法はない
    • 創造神マデサゴーラ が出てきたら高い確率で勝てない
• パーティー編成のウェイト制限がうまく調整されている
  • 高ランク (ステータス高い) のキャラばかりを編成できないようにウェイト制限がある
  • これにより、パーティー編成が4人か5人かにわかれる
  • 低ランク (ステータス低い) のキャラはウェイトも低いので5人目には入れやすい
    • たたかいのベホイム が使える ホイミスライム が活躍したりする

本題のわざと負ける理由だが、わかってきた。リアルタイム対戦のマッチングは同じランク内で行われる。上位のランクになればなるほど、対戦相手も強くなる (強くなければ上位のランクに上がれない) 。一定量のポイントを獲得するとランクアップしていけるが、負けるとポイントが下がるペナルティがつく。一定のランクで勝ち負けを繰り返すとそのランクに留まり続けるということができる。私も自分の限界までランクアップしてみて気付いたのは周りも強いので限界に到達すると勝ったり負けたりを繰り返す。ここで別のルールで勝った回数に応じてコインが支払われるボーナスがある。強い人が低いランクで勝ち数を稼ぐのは限界に近いランクで勝ったり負けたりを繰り返すよりもはるかに効率がよい。それはリアルタイム対戦のマッチングに時間制限があるからなおさらそうなる。実力が均衡した相手と時間をたくさん使って2勝3敗を繰り返すよりも、わざと負けながら弱い相手に勝ち続ける5勝?敗を繰り返す方が絶対数としての勝ち数を稼ぐには効率がよい。おそらく負けたときのペナルティがあるランクからわざと負ける人が現れ始めていると思う。なるほどなぁ。

23時に寝て7時半に起きた。夜中も2回ぐらい起きる。暑さでまいってきた。

ストレッチ

今日の開脚幅は開始前159cmで、ストレッチ後162cmだった。数字は悪くない。いつもはストレッチを受けていると疲労しているところが伸びることで体が軽くなっていく感覚があるのだけど、今日は体全体がだるくてストレッチを受けていてもなんかしんどいなぁとだるさを感じていた。コロナに感染してないと思うけど、夏バテの状態をそのままストレッチにも持ち込んだような感覚があった。腰の張りや肩甲骨の硬さなどが少し気になったかな。トレーナーさんには立ったときの姿勢が少し前よりで重心のバランスがよくないといったアドバイスをされた。とくにどこが悪いというわけでもないのになんかしんどい。

Kubernetes Clients のサンプル実装

Kubernetes Clients の調査 の続き。java クライアントを使って minikube でいくつか動かしてみた。openapi で生成した rest api クライントが提供されている。デフォルト設定でも minikube で普通に動いたのでおそらく裏で $HOME/.kube/config をみたり /var/run/secrets/kubernetes.io/serviceaccount/token を読み込んで認証ヘッダーに設定してくれたりするのだと推測する。

public ApiClient getKubernetesClient() throws IOException {
    var client = Config.defaultClient();
    io.kubernetes.client.openapi.Configuration.setDefaultApiClient(client);
    return client;
}

このクライアントを使って java/kubernetes/docs/ 配下にある api インスタンスを生成する。例えば、cronjob や job を扱うならば BatchV1Api というドキュメントがある。BatchApi だけでも3つのドキュメントがあるのでちょっとやり過ぎな気もする。

• BatchApi.md
• BatchV1Api.md
• BatchV1beta1Api.md

kubectl コマンドで使う cronjob から手動で job を設定するのを実装してみる。

$ kubectl create job --from=cronjob/my-schedule-job my-manual-job

細かい設定はちゃんと調べないといけないけど、一応はこれで動いた。cronjob のオブジェクトを取得して job のオブジェクトを生成して create するだけ。

var api = new BatchV1Api(this.getKubernetesClient());
var cronJob = api.readNamespacedCronJob(cronJobName, NAMESPACE_DEFAULT, null);
var ann = Map.of("cronjob.kubernetes.io/instantiate", "manual");
var metadata = new V1ObjectMeta().name(newJobName).annotations(ann);
var spec = cronJob.getSpec().getJobTemplate().getSpec();
spec.setTtlSecondsAfterFinished(10);
var job = new V1Job()
        .apiVersion(cronJob.getApiVersion())
        .kind("Job")
        .spec(cronJob.getSpec().getJobTemplate().getSpec())
        .metadata(metadata);
var result = api.createNamespacedJob(NAMESPACE_DEFAULT, job, null, null, null, null);

手動で作成した job の pod は終了後にゴミとして残ってしまうので ttl を設定すれば自動的に削除できることに気付いた。

spec.setTtlSecondsAfterFinished(10);

k8s クラスターの内部、つまり pod 内からリクエストするには ServiceAccount permissions を適切に設定しないといけない。ひとまずローカルの minikube で super user 権限にしたらリクエストはできた。実運用では適切なロールを定義して適切に権限設定しないといけない。

kubectl create clusterrolebinding serviceaccounts-cluster-admin \
  --clusterrole=cluster-admin \
  --group=system:serviceaccounts

23時に寝て7時に起きた。今週は不規則な生活をしたのでバテた。

ストレッチ

今日の開脚幅は開始前156cmで、ストレッチ後160cmだった。先週よりちょっと数値が悪くなった。自覚症状はなかったけど、ストレッチをしてみると右腰の張りがそこそこあることに気付いた。自覚症状のない疲労に気付けるのがストレッチのよいところの1つでもある。

スモールオフィスの内覧

たまたま 起業プラザひょうご さんのスモールオフィスに空きがあるのをみつけたので内覧に行ってきた。電話したらとくに予約は取らなくてよいのでいつでも来てくださいと言われたのでアポなしで17時頃に行くことにした。現地のビルに行ってみたが、ビルが工事していて入れる状態ではない。なんかおかしいと思って調べたら地図には全然違う場所が示されていた。後で知ったことだが、2020年8月に移転していた 。前に起業プラザひょうごさんに2-3回行ったことがあったけど、それは移転前だった。その後、移転したことを全く知らなかった。

このコワーキングスペース兼レンタルオフィスが三井住友銀行神戸本部ビルという旧居留地の真ん中に18F建ていう、この付近ではトップレベルの高層ビルと言える。そんなビルの2Fという「ん？」という場所にある。おそらくビルの名前から三井住友銀行の自社ビルだろう。1Fには銀行の窓口があり、窓口の前を横切る形でエスカレーターを上がると起業プラザひょうごさんのコワーキングスペースがあった。入り口には警備員さんが立っていて入ろうとすると「会員証をみせて」と止められた。内覧にきた旨を伝えると通してくれた。銀行のビルなので休日でも警備員さんが控えている。

2Fにエスカレーターで上がり、受付で内覧にきたことを伝えるとそのまま (おそらくアルバイトの) 若いお兄さんがあちこち案内してくれた。興味本位で「素朴な疑問なんだけど、どういう経緯で銀行の自社ビルの2Fの空きスペースみたいな場所を間借りできたんですか？」と聞いみたら、さすがにそれは分かりませんと返ってきたw

普通のオフィス (5.6㎡) と広いオフィス (8.4㎡) の2つに空きがある。

空きスペースをパーティションで区切っただけの簡易的なオフィスではあるけど、家賃は税込でそれぞれ 23,595 円と 33,275 円になる。登記さえできれば、オフィスの体裁は私にとってそこまで重要ではない。物理的なセキュリティの懸念として壁の上によじ登ることができるのはあるけれど、扉には鍵がかかる。床面積から比較するとレンタルオフィスとしては周りの平均よりも半額から1/4ぐらいの破格の価格設定と言える。一通り話しを聞いてみて引越し先として検討できるかどうかを確認していた。私にとっての一番の課題はこのビルに入れる時間帯が制限されていること。私は平日は7時台にはオフィスにいるし、夜も遅かったら3時ぐらいまで作業をするときもある。外的要因で時間の制約を課せられるのが私にとってはストレスとなる。22時をまわることは月に数回程度しかないからまだ譲歩できても朝9時というのは始業が遅過ぎる。

• 平日: 9:00 - 22:00
• 土日祝: 10:00 - 20:00

顧問のはらさんとも相談して懸念がなければ、審査を受けるだけ受けてみてもよいかもしれない。但し、三井住友銀行の拠点ビルとも言えるところにあるコワーキングスペースなのでうちみたいなマイクロ法人は審査が通らない可能性も高いと思われる。過去に三井住友銀行で法人口座開設の申請を出してお断りされた実績もあるのでそれを思い出してた。

外部の人を招いて無償の勉強会を開催してよいかどうかを確認したところ、会議室の予約さえとれれば開催してよいとのこと。さらに会議室の利用料は無料とのこと。会議室は定員6名が2部屋、10名が1部屋、20名は1部屋の合計で4部屋ある。定員20名の会議室と聞くと「はぁ？」って感じでそこもみせてもらった。広い部屋のスペースを贅沢に浪費した構成だった。「こんな広い部屋の会議室って普段使うんですかね？」と質問したら使っているところをみたことないと返ってきて笑ってしまった。定員20名の会議室でどんな会議をやるねん？オフラインの外部勉強会をやるとしたらスペースが広くて快適そうな場所ではあった。あと後ろの方はモニターみえないよね、おそらく。

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

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万点の資料が収められた 国立科学博物館の巨大収蔵庫潜入 完全版！

0時に寝て8時に起きた。起きたら豪雨だった。梅雨明けが早かったから水不足の土地には恵みの雨だなとか思った。

「緊急対応」という種別

先週のリリースに際して発生した問題に「リリース時緊急対応」という種別が設けられた。当時、私はその種別を設けることそのものに否定的なコメントを発したのだけど、誰かがすでにその種別を作ってしまっていて、いくつかのチケットに設定されていたので成り行きで使うことになった。そして、もうリリースしてから1週間も経つのに未だに「緊急対応」というチケットがいくつも作られている。1週間も運用しているのに緊急もへったくれもないだろうと指摘して、明日から新しいスプリントが始めるので「緊急対応」という種別を付けるのはやめようと提案した。一般的な課題管理システムは緊急度と重要度の2つをもっているけど、backlog は優先度しかない。それでも優先度があるのだからそれを設定すればいいだけなのに優先度を使った運用をしていないのと、課題一覧をフィルターするのではなく、大半のメンバーがカンバンしか使えないといったスキル不足もあって、なくてもよい無駄な種別をまた増やしてしまった。

カンバンはシンプルな要件に使うならよいけど、一定以上の複雑さをもつ普通の会社の開発プロジェクトに使えるようなキャパシティをもっていない。それなら最初から使わない方がよいのではないかと考えるようになってきた。というのは、非開発者にとってカンバンは簡単に使い始められる分、そこからさらに高度な検索フィルターを使いこなすスキルアップを阻んでしまう。複雑な要件をカンバンで実現しようと考えてしまってバッドノウハウ的なアプローチをしていく。その典型例が「緊急対応」という種別作ればいいやんみたいな考え方。

クレジットカードの有効期限の更新

前に yj カードが paypay カードに置き換わったときに有効期限が更新されてクレジットカードの設定更新が必要になると書いてあった気がする。4月8日に paypay カードが届いたみたい。クレジットカードの引き落としタイミングのせいか、しばらくは有効期限が異なっていても paypay カード側で決済を許可していたのか、いずれにしても最近あちこちでクレジットカードの引き落としに失敗するという通知がくるようになった。気付いたら、クレジットカードによる セカンドハーベスト・ジャパン さんの寄付の引き落としも止まっていた。通常、有効期限前にクレジットカードが更新されることはないからサービス側で有効期限が近づいてきたときに更新依頼通知を送っているのだと推測する。寄付みたいなところは引き落とし失敗になると督促しないのかもしれない。もう1つ 国境なき医師団 さんにも寄付しているが、こっちは銀行口座からの引き落としだった。クレジットカードと銀行口座の違いとして有効期限の有無が違う。どちらもメリット・デメリットがあるからずっと払い続けるつもりなら銀行口座、自分が死んだ後にいずれ停止してほしいならクレジットカードを使った方がよいといった考え方もできると気付いた。