2時半に寝て4時半に起きて6時半に起きて7時半に起きた。

今日の筋トレは腹筋:15x1,腕立て:10x1,スクワット10x1をした。

災害義援金の寄付

週末に災害の寄付をしようと思ったときに、ふと寄付を法人でやればいいんじゃないかと思い付いた。どちらも私のお金であることには変わりないのだけど、会社のお金は個人のお金という気がしないので個人よりも大きいお金を寄付できる。これは法人という人格を分けていることのメリットの1つかもしれない。

• 令和6年（2024年）能登半島地震に係る災害義援金の受付について

今朝から税理士さんに損金算入についての懸念がないかを確認して問題ないということだったので10万円を寄付した。領収書は電子フォームから申請したが、毎日それなりの数の人が寄付しているだろうから領収書が発送されるまで1ヶ月ぐらいはかかるのかもしれない。気長に待って領収書が届いたら軽く記事を書こうと思う。現時点での義援金の残高は 968,223,243 円とのこと。せいぜい集まるお金は数十億程度なのかな。

現時点での暫定推計で被害総額は約8,000億円

能登半島地震による経済損失について考える

はてなブックマーク数の表示

hugo ではてなブックマークの数を表示するためのカスタマイズを追加した。はてな社がそのための機能を提供しているのですぐできる。

• 自分のブログに「○○users」を表示する

{{ $url := .Permalink }}
{{ if hugo.IsDevelopment }}
  {{/* ローカル環境でブックマーク数の表示確認用途 */}}
  {{ $url = "https://kazamori.jp/" }}
{{ end }}

<span class="m-1">
    <a href="{{ print "https://b.hatena.ne.jp/entry/" $url }}">
        <img src="{{ print "https://b.hatena.ne.jp/entry/image/" $url }}" alt="はてなブックマーク - {{ .Title }}" title="はてなブックマーク - {{ .Title }}" />
    </a>
</span>

呼び出し側はこんな風に使う。

{{ partial "hatebu.html" . }}

結果は 記事一覧 で確認できる。

23時に寝て2時に起きて6時に起きて7時過ぎに起きた。なんか微妙な寝方をした。

先日の mongodb のレプリカセットの調査 の整理をしてマージリクエストを作成した。共通鍵の keyFile をどう扱えばいいのか、わからなくて、一旦コンテナ内の tmp 領域にコピーして、それを entrypoint スクリプトでコピーしてから owner/permission を変更するというやり方で、リポジトリ管理で共有しやすいようにしてみた。entrypoint スクリプトは root 権限で実行されることも理解した。

volumes:
  - ./mongo/keyfile:/var/tmp/keyfile.orig
command:
  - mongod
  - --keyFile
  - /data/keyfile
  - --replSet
  - "myrs"
entrypoint:
  - bash
  - -c
  - |
    if [[ ! -f /data/keyfile ]]; then
      cp /var/tmp/keyfile.orig /data/keyfile
      chmod 400 /data/keyfile
      chown mongodb:mongodb /data/keyfile

    fi
    exec docker-entrypoint.sh $$@    

テックブログを読む会

昨日、西原さんに教えてもらった テックブログを読むイベント を探したら毎週月曜日に行われているようだった。早速 テックブログ一気読み選手権20231211杯 に参加した。HackMD で読んだメモを管理している。記事を選択して、読んで、所感をまとめて、他の人たちと共有する。ただそれだけのイベント。ちょうど30分で終わって、自分の勉強にもなったし、他の人の話しも聞いて参考になった。たった30分でも、なにもやらないよりずっとよい。1ヶ月ほど参加してやり方を学んだらチームにも展開してみようかと考えている。

23時に寝て2時に起きて4時半に起きて6時までゲームやって8時に起きた。朝からオフィスで発表資料を作ってた。

2023年ふりかえり

今年を振り返ろう！LT大会 に参加した。

昨日の夜に LT 資料を作ろうと思っていたものの、晩ご飯食べたら面倒になってそのまま家で休んでいた。朝からオフィスで作り始めたら徐々に興が乗ってきて想定した以上にちゃんと作ってしまった。やぎさんにレビューしてもらっていくつか気付きを得た。ちょうど レビューサービス あったら依頼したいなと思ったところだったのでレビューしてくれる人の存在に感謝した。この資料はまたなにか他の機会のイベントでも再利用しようと思う。カフーツさんの忘年会で発表してもよいかもしれない。

• 2023年ふりかえり

北海道から 西原さん という方が参加されていた。全国あちこちのコミュニティに参加して、そこに集う人たちの支援や盛り上げ、ひいては日本の IT コミュニティを活性化させて、世の中をよくしようといった取り組みをされている。これは私も共感するところで大半の人はコミュニティ活動に関心がない。それ自体は個人の好みで構わないのだけど、プログラミングを学びたいと考えているのに行動できない人たちというのが一定数いて、そういう人たちの受け皿として IT コミュニティで始めるのはよいことだと思う。西原さんはまさにそういう活動をされている。とても尊いことだと思う。

短時間にも関わらず、いろいろな話しをして私自身収穫もあったし、西原さんから学ぶことも多かった。企業のテックブログを読む会を毎週30分、社内外でやっていると話されていた。これは素晴らしいなと思ってすぐに反応した。歳のせいか、私は自分で勉強しなくなっていて、本も仕事も課題も積みまくりで、毎日どうしよう？と途方に暮れながら帰っておいしい晩ご飯を食べてゲームしている。そんな自分で勉強しない人向けにこういったコストなく、無理なく、続けられるイベントはありがたい。やり方を学ぶためにオンラインで参加してみようと思う。

• ブログを見つけて読んで感想書いてそれを肴に交流する会を30分でやりきっています

コミュニティ活動の価値というのは、多くの企業もコミュニティを盛り上げようとやっていることから明らかに大きな価値があるにも関わらず、その価値を十分に明文化できていない。私自身、コミュニティからたくさんのモノや影響を受けているにも関わらず、うまく明文化できていないところがある。課題管理の研究の延長上でコミュニティの価値にも追究していきたいと考えている。

23時に寝て2時に起きて6時に起きた。晩ご飯食べてから作業するつもりが、疲れて寝てしまった。今日は権限管理のバグ修正したり、昨日の mongodb の調査を継続していた。

テックブログ公開

先日 テックブログレビュー を終えていた記事を公開した。

• SvelteKit アプリケーションの組み込みへの考察

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。

• テックブログ (↑) のふりかえり
• 日本ナレッジ・マネジメント学会の年次大会の所感
• 税理士さんと契約 して3ヶ月間やり取りした所感

1ヶ月に1-2件ほど折りにふれて税務相談をする機会があったりする。税理士さんとは chatwork でやり取りしている。これがストレスになってきたのではらさんに相談にのってもらった。はらさん曰く、税理士さんの普通と it 業界のうちらとは業務の取り組み方への姿勢がまったく異なるため、最初の1年はストレスや不満がたまるのはあるという。士業という資格によって独占的に保護された業務のせいか、顧客に寄り添った対応をしてくれるわけではなく、質問の背景や意図を汲んでくれなくて質問に回答を返して終わりといった、チャットなのにメールのような一問一答のようなやり取りになっている。さらに回答が意図した内容ではなくて、追加で質問や背景の説明をしても、すぐにレスポンスが返ってくることはなく、数時間たってから回答が1つ届き、それも期待したものじゃないとさらに質問して、さらに数時間といったやり取りで5-6往復するのに数日かかるのがざらにある。はらさんがいうには税理士さんの回答を得るのに1週間ぐらいかかったり、問い合わせを数日放置されるのも普通とのことらしい。

先方も複数の顧客を相手にサポートしていて、やり取りに時間がかかることそのものは理解できるが、チャットのやり取りがコンテキストを理解しているようにみえなくてコミュニケーションが成立していない。例えば、当社への税理士報酬の支払いの対応について問い合わせたら次のような回答が戻ってくるだけ。

報酬の額と消費税等の額が明確に区分されている場合には、その報酬の額のみを源泉徴収の対象とします。

こんなことはググればすぐに分かるし、私も顧問報酬は原則として源泉徴収することを知っている。その上で税理士さん事務所の、当社への顧問報酬の明細について尋ねているのにこういった回答が返ってくるだけ。

• インボイス制度開始後の報酬・料金等に対する源泉徴収

インボイス対応もあるため、請求書に明細を書いて pdf で送ってくださいと依頼して2日間返信なく放置されている。税理士さん事務所の顧問報酬の明細や請求書について尋ねても即日に返信がこないような状況になる。はらさんが言うには税理士さんの対応とはそんなもんらしい。チャットでやり取りしている意味がないし、こんなググればわかるレベルのやり取りしかできないなら解約も検討している。もう1つ懸念に思っているのは本人がチャットで回答していないのではないか？と考えている。チャットなのに1問1答でしか返信がこないし、コンテキストが伝わっていないと感じることも多々ある。とてもベテランの税理士さんが答えているとは思えないコミュニケーションの齟齬がある。

ちょっと調べてみると、税理士は日本税理士会連合会に登録する必要があり、税理士試験に合格しても登録していない場合は税理士としての独占業務を行うことができないらしい。また税理士事務所で働いている人の中には無資格職員もいて税務補助をしている可能性もあるという。必ずしも税理士資格がなければダメだというわけでもない。無資格職員でも経験を積んで税務に詳しい人もいると思う。一方でチャットでベテランの税理士のふりをして職員が回答しているのであれば、それはそれで信頼関係や偽証などの問題がある。そこら辺も聞いてみようと思う。次の記事では無資格職員が税務相談をしている事務所もあると書いてある。

• 税理士へ依頼したつもりが税理士でなかった

2時に寝て6時に起きて9時前に起きた。寝るのがどんどん遅くなってきて生活のリズムが乱れてきた。

sveltekit に関するテックブログ執筆

先日の続き の続き。

調査は一区切りついたのでテックブログを執筆することにした。今日はほぼ丸一日記事を書いていた。本当はマネージャーの私が1-2週間も技術調査して、テックブログを一生懸命書くみたいなことをやるよりも、他に大事なプロジェクトの遊撃やマネジメントに時間を割くべきではある。一方でメンバーに課題に取り組むにあたり、設計をどうするのか？設計をするためには調査が必要であること、調査した内容をアウトプットする重要性などの模範を示したいという意図で書いた。そして、メンバーにも開発の隙間にテックブログを書くことを業務として指示しようと考えている。

なんのためにテックブログを書くか？という目的は、業務においては明確で採用のために書く。プログラマーが採用において協力できることは限られる。その中でもテックブログというのは費用対効果が高く、会社のブランディングにもつながり、よい開発文化を醸成することにもつながる。プログラマーの採用がとても難しくなった昨今「全員採用」というキーワードもよく聞くようになった。一見プログラマーは採用において無関係だし、実際にそういった業務をやらなくても咎められることはない。しかし、自分のできることで採用に協力したいと考えたとき、できることの1つにテックブログを書くというのは悪くない選択肢だと私は考えている。少なくともテックブログを書けない (書かない) 人たちにとやかく言われたくない。

1時に寝て4時に起きてもう1度どこかで起きて7時半に起きた。

テックブログ公開

テックブログレビュー を終えて公開した。この機会に 個々の記事に目次 も追加した。はらさんレビューから修正をして2時間後に公開しますよと宣言して勝手に公開した。

• SvelteKit はどのようにコンパイルしているのか？

家族信託の打ち合わせ

15時にお仕事を早退して、親と一緒に明石市にある弁護士さんの事務所へ訪問した。三ノ宮から車で向かって、ナビゲーションに従っていたら京橋から高速道路に入って若宮でおろされて、なんでこんな早く高速道路おりるんやろ？と不思議に思ったけど、須磨からの海岸線はそれほど渋滞せず信号も多くないから下道で行ってもそんなに時間はかからないという判断だったようにみえる。だいたい40-50分ほどで明石市の中心地に着いた。3分ほど遅刻して打ち合わせが始まった。

遺産を相続するとさまざまなリスクがある。大きなお金をもつというだけで詐欺のターゲットにされる。家族信託 (民事信託) という制度を使って、そのとき必要なお金のみを受け取るように運用する。構成要素は次の通り。

• 委託者: 母
• 受託者: 私と姉
• 信託財産: 預金

受託者は最低2人必要で、うちは姉もいるのでよいのではないかと弁護士さんが話されていた。たしかに1人っ子なら誰かにお願いしないといけない。大雑把に言えば、母の貯金を子どもに管理してもらうような制度になる。但し、最初の契約書に記載された内容の範囲内でしか、受託者はお金を引き出せないのでその契約書をしっかり作ることが重要になる。契約書に記載していれば、資産運用もできるらしい。契約書の叩き台として、どういった内容を書いておくかを相談した。弁護士さん曰く、契約書に書いておかないとその用途に使えなくなるため、1%でも可能性があれば、書くだけ書いておいた方がよいとのこと。書いておいて、実際に使わないというのはなんの問題もない。

3人でブレストするような感じで項目を洗い出した。

• 生活費
  • 冠婚葬祭で払うお金
    • 10万円以内なら生活費として引き出してもよい
    • 例えば30万円いるとして、建替え可能なら10万円/月を3ヶ月かけて引き出すでもよい
  • (お金に困った親戚がいたと仮定して) 親戚への資金援助
    • 生活費の範囲内でやればよいはず
• 看護、療養といった通院も含めた医療費
• 老人ホームの入居費用
• 納税 (一時所得)
  • 太陽光発電で得た収益のうち、所得税をこの口座から引き出して支払うといったこともできる
• 家の改築、修繕、取り壊しの費用
• 農業のための費用
  • 農機具の購入や修理など
  • トラクターが一番高い、100万円〜1,000万円ぐらいとピンからキリまである
• 土地 (田んぼ、宅地) の購入
• 太陽光発電設備の撤去費用
• 自家用車の購入費用
• 生命保険の支払い
  • 死亡保険金は500万円 x 法定相続人数まで非課税なので相続税の節税になるらしい
    • 例) 母の死亡時に姉と私が500万円受け取るような生命保険に入る
  • 相続税の基礎控除が3,000万円 + 600万円 * 法定相続人数
    • 例) うちは私と姉で 3000 + 600 * 2 = 4,200万円が基礎控除となる
      • この金額を超える遺産があれば相続税の課税対象となる
      • 生命保険へ付け替えることで 4200 + 500 * 2 = 5,200万円まで非課税にできる？
• 資産運用
  • 投資信託
    • 積み立て系の投資信託がもっとも望ましいのではないか
      • リスクヘッジとして大きなお金を1度に動かすのはなるべく避けたい
      • NISA 口座を開設できるかどうかは調べないとわからない
    • 信託口座とは別に証券口座も開設しないといけない
      • 受託者が預金口座からお金を引き出して証券口座へ振り込むような運用になる？
    • 具体的にどういった運用にするかは信託銀行と応相談になるかもしれない
      • なんらかの制約が課されるのではないかと推測される
  • 株式投資
    • 可能ではあるが、条件を指定しないといけないため、中長期での実運用は難しいのではないか

私が信託口座からお金を引き出すときに、一定金額以下の生活費 (例えば10万円) ならノーチェックだが、100万円とか大きなお金を引き出すときには銀行員からチェックがかかり、正当な使途なのかどうかを確認されるという。場合によっては見積もり書の提出なども必要かもしれないとのこと。それはとくに問題ない。契約書の作り直し自体は委託者が元気であればできる。しかし、手数料や手間暇もかかるため、実運用としては最初に作った契約書を変更するといったことはそうそう行われない。最初が大事。弁護士さんが契約書を作成するのに2-3週間かかる。その後に三井住友銀行さんで赤ペン先生のチェックが入る。契約内容の修正などのやり取りをしてその後手続きに進む。

思考実験として、詐欺にあって借金してしまった、または連帯保証人となって借金してしまった。その場合はどうなるか？というのも考えてみた。信託銀行に確認してみるとのことだったが、弁護士さんが言うには、家族信託の目的は財産を守ることにあるため、本来の使途ではないものへ支払いは抵抗があるかもしれないとのこと。その状況によって銀行員の判断次第かもしれないとのこと。

受託者は年に1回報告書 (帳簿) を作り、どのように運用したかを委託者へ報告する義務がある。これは家族間だけの話ではある。この手の情報処理 (データ処理) は私が得意とするのでそんなのすぐやりますと回答できた。弁護士さんによると、こういう事務作業を嫌がる受託者もいるという。スプレッドシートでちゃちゃっと作ればよいはず。

契約書を作成したら、それをもって委託者、受託者、弁護士の3人で 神戸公証役場 へ一緒に行く。その公正証書をもって三井住友信託銀行へ行って、母が口座を開設して、そこに弁護士さんが遺産を振り込むといった段取りになる。将来、委託者の健康を害して成年後見人がつく状況になったとしても家族信託の口座はそのまま受託者が管理できる。成年後見人に信託口座が移管されるようなことはない。

最後に契約書の条項をチェックしていて次の内容を教えてもらった。

弁護士業務の適正の確保

甲は、本件事件等の処理の依頼目的が犯罪収益移転に関わるものではないことを、表明し保証する。

「半社チェックのようなもの？」と聞いたらちょっと違っていて、弁護士は大きなお金を動かしても監査を受けないという特権 (信頼) があって、その特権はマネーロンダリングできてしまうという諸刃の剣でもあるらしい。今回のお金は遺産なので半社会的なものに該当しないが、契約書では弁護士が扱う業務がマネーロンダリングではないことをチェックする必要があるみたい。

帰りに 明石焼き ゴ というお店で明石焼きを買った。駐車場の近くにあったお店に立ち寄ってテイクアウトしたのだけど、とてもおいしかった。それで 食べログ の評価もみたら 3.49 とかなり高い。たまたま買ったところがよいお店だった。18時半頃に店内もほぼ満席だったと思う。また明石へ行く機会があれば寄ってみようと思う。

2時に寝て6時に起きてだらだらしてたらいつの間にか2度寝して9時に起きた。8月は開発の佳境なので基本的には土日を働く予定。

晩ご飯を外食して、夕方から NieR:Automata Ver1.1a というアニメが2期決定というニュースをたまたまみて、1期のコンテンツを見始めた。品質の高い作品だとは思うけれど、世界観 (設定) が私の頭の中のなにかとあわない。世界観の違和感や矛盾を受け入れ難いものがあって引っかかりを覚えるような作品だった。もともとゲームが原作らしい。人によって評価が分かれそうに思えた。

事例紹介のたたき台

先日のプレスリリース の続き。こういった会社の正式な文章を書くのは、その労力以上に面倒臭さが上回って後回しにしてしまう。簡潔な文章なので、過去の体裁やフォーマットなどをみながらやればすぐにできた。今回は私はマネージャーとしてプロダクト開発しているので、うちが作ったんよ的なノリでちょっと前のめりにプロダクト紹介をしてみた。私がもっている課題管理のノウハウを駆使して開発プロジェクトをうまくまわした工夫も書きたいところだけど、そうすると事例紹介と課題管理のプラクティスの話しがごっちゃになって訳の分からん記事になってしまう。事例紹介とは別に、今回の事例をベースに課題管理のプラクティスの記事を別途ブログに書こうと思った。他にもお客さん先のテックブログにも書かないといけない記事が2つ溜まっている。私は文章を書くのが遅いからなかなか捌けない。日記を書いて練習しているうちに早く書けるようにならないかな？と期待しているが、まだまだそんな予兆はみえない。

syncrepl を使ったエージェントアプリケーション開発

昨日のレビュー対応したものがマージされた 。それをもって自分たちのアプリケーションのコードを書かないといけない。以前に ldap の dirsync というプロトコル をメンバーが実装して、それを使ったアプリケーションのコードがある。その実装といくつか共通部分を再利用しつつ、プロトコルの違うところだけを追加できるようにしたい。既存のエージェントアプリケーションのソースを読みながら、どういう風に設計していくかのイメージを膨らませておいた。今日のところはコードを読んで頭の中に入れて考えるだけ。この状態で一晩寝かすと、寝ている間に脳が無意識に考えてくれて効率がよいはず。これは休日の時間のよい使い方だと思う。

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

煩雑な検証

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

会社のテックブログ談義

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

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

…

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

…

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

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

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

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

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

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

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

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

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

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

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

ストレッチ

今日の開脚幅は開始前162cmで、ストレッチ後163cmだった。先週より少し数値がよくなった。相変わらず背中や腰の張りは強くてストレッチしてもらっていてなかなか辛かった。昨日は祝日だから早めに切り上げてゆっくりしてたし、ワクチン接種後というのもあるけど、最近は睡眠時間を多く取るようにして安静な生活を送ってたりする。それでもどこかしら張りがあったりする。ストレッチを受けると毎日座ってお仕事をすることの負荷を実感できる。

今日で1年以上ストレッチをしていただいた トレーナーさんが転勤 で最後。おかげで私は健康に過ごせているので感謝しかない。新しい環境でも活躍してほしい。来週から新しいトレーナーさんになる。それはそれで相対比較ができるのでトレーナーさんの違いもわかると思うから楽しみ。

コミット連携機能の紹介

少し前に対応したんだけど、backlog-github-integration-action でコミット連携ができるようになった。

• Add Push subcommand to integrate commits with backlog #2
• Add a feature to change the issue status with commit messages (fix, close) #3

そのことをブログの記事にも書くことにした。1時間もあれば書いてしまえる内容なのに英語で書くというだけで後回しにしてしまう。私は英語を書くときは Grammarly と DeepL を使って書いている。自分の言いたいことを Grammarly で構文チェックしながら書いて、それを DeepL で日本語訳して意味がとれるかどうかで内容があっているかの確認をするといった感じ。

• Commits integrate with Backlog issue

3時に寝て7時半に起きた。前日の深夜にオフィスの掃除をしてた。シェアオフィスなので掃除機をかけると音がうるさくて周りに迷惑なので誰もいない時間帯を見計らって行う必要がある。

逆イールド

会社を経営する上で経済の状況は大きな影響を受けるので機をみて経済の勉強もしている。直近40年近くの統計では、米国債金利において、2年債の金利が10年債の金利を追い越してしまう現象が発生した場合、その1年後ぐらいに景気後退期がやってくる。この現象を 逆イールド と呼ぶ。

なぜ逆イールドが発生すると景気後退となるのか。国債とは政府の借金。金融機関、年金、個人、海外などが貸している。金利は複雑で様々な要因で決まるので一概に言えないが、大雑把にまとめると経済の力や金融政策、世のおカネの量で決まる。政策金利によって3ヶ月債や2年債は大きく影響を受ける。利上げを急ぎでやろうとしている理由は高いインフレがある。米国は約40年ぶりの高インフレとなっている。FRB は約2%のインフレを目標としているが、現状は遥かに高い水準になるので金利を上げてインフレを抑制しようとしている。FRB は次の2つの使命を負っている。

• 物価の安定
• 雇用の最大化

いま物価が急上昇しているため、このまま金融緩和を続けるとさらに物価が上昇して悪い影響を及ぼしてしまう。いまは金融緩和を縮小して利上げをしていく必要がある。しかし、利上げは景気に対して悪影響となる可能性がある。どのぐらい利上げすればよいのかは実際には誰もわからない。最悪の状況として次がある。

• スタグフレーション: 高インフレのまま景気が減速する現象

スタグフレーションが発生すると経済対策や金融政策で対応しづらい非常にまずい状況となる。経済学者によっても意見が分かれるので、まだスタグフレーションが起こるとは限らない。しかし、起こる可能性があるという見方も出てきているらしい。

英語のテックブログ開設

先日作った backlog-github-integration-action の記事を書くことにした。会社のプロダクトとして作ったツールで汎用的なものや業務として保守していくものは積極的にアピールしていきたい。基本的に私は日本市場をあてにしていないのと、せっかく会社を作ったのだし、海外の会社と取り引きできるようになりたいという野望もある。プロダクトの情報発信は英語が基本で、余裕があったら日本語も書くといった優先度でやっていく。

少し前にたまたま hashnode がイケてるというのをタイムラインでみかけたのを思い出した。せっかくなので調べてみたら、どうも Custom Domain を無償、且つお手軽に設定できるのが訴求点になっているらしい。カスタムドメインを使うと、url に統合性があってカッコいいという以外にも信頼できるドメインに対して SEO が行われるため、優良な記事を書いていると自社ドメインの信頼があがっていくといったメリットがある。コストがかからないならカスタムドメインを使わない理由は何もない。そして設定したものが次になる。

• https://blog.kazamori.jp/

ネームサーバーにカスタムドメインの設定をしていて間違って少しはまった。

間違った設定

cname blog hashnode.network

正しい設定

cname blog hashnode.network.

最後にドット . が必要になる。これで blog.kazamori.jp の名前解決が hashnode.network として解決される。

$ dig blog.kazamori.jp
...
;; ANSWER SECTION:
blog.kazamori.jp.	198	IN	CNAME	hashnode.network.
hashnode.network.	46	IN	A	76.76.21.21

CNAME レコードを滅多に設定しないのでドットで終わらないといけない規則を忘れてた。設定後、dns の propagation に最大24時間ほどかかる。世界のどこからでもアクセスできるようになるには24時間ぐらいかかるかもしれないけど、ローカルで動作検証するなら数分で反映されてた。