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

k8s のロールバック

Rolling Back to a Previous Revision をみながらすぐできた。ロールバックもこれまでと同様、github actions の workflow dispatch で管理できるようにした。基本的にはこれだけでロールバックできる。

$ kubectl rollout undo deployment/my-app-deploy

ちょっと工夫したこととして、デプロイ時に kubernetes.io/change-cause というアノテーションに git のリビジョンもセットしておくと確認するときにちょっと楽ができる。apply した後の deployment リソースに docker イメージのタグ情報 (= git のリビジョン) を書き込んでおく。

$ kubectl apply -k ${{ env.DEPLOYMENT_ENV }}
$ kubectl annotate deployment my-app-deploy kubernetes.io/change-cause=${{ env.IMAGE_TAG }} --overwrite=true

kubectl から履歴をみたときに k8s のリビジョンがどの git のリビジョンを使っているかがわかりやすい。デフォルトでは何も設定されていないかもしれない。

$ kubectl rollout history deployment/my-app-deploy
deployment.apps/my-app-deploy
REVISION  CHANGE-CAUSE
15       <none>
16       <none>
17       <none>
18       <none>
19       <none>
20       <none>
21       <none>
22       <none>
24       1f17a22a6659ea0714a21fca034645cd191e189b
27       a84e113d8b7c124178b58e2f40f57b00aae65485 
28       dcf3552db0668d416ed880f6e896455d7bab194c

23時に寝て2時に起きて4時ぐらいまでだらだらして寝て6時に起きた。

ストレッチ

これまで11時からストレッチを受けていたが、今週から dr.stretch さんの土日の開店時間が10時になったのにあわせる形で時間変更した。朝に予定が入っているとその時間にあわせて起きて身支度して1日が始まるので家で中途半端にだらだらしなくてよい。いつもは11時にあわせて家を出掛けるのが、10時にあわせて出掛けるようになったのでいつもより1時間早く活動できるようになった。私はなんか予定がないとだらだらしてしまって怠惰に過ごしてしまう。そういう怠ける自分の性格もわかっているので適度に予定を入れて怠けないように注意している。

今日の開脚幅は開始前163cmで、ストレッチ後165cmだった。先週とほぼ同じ。今週もお仕事が忙しくて全くできなかったので現状維持といったところ。

デプロイのパイプライン処理

github deployment から workflow dispatch に移行したおかげでせっかく deployments ベースで作ったパイプライン処理のツールを workflow dispatch 向けに移行する必要があった。言うても基本的に同じパラメーターを処理するだけなので大半は再利用できる。ツールのちょっとしたリファクタリングをやってパイプライン処理が動くかどうかの検証をして、ドキュメントを wiki にまとめた。あとはロールバックを自動化するための仕組みを作るだけ。基本的には k8s の kubectl を実行するワークフローを作るだけという想定。

1時に寝て6時に起きた。朝ちょっとデバッグをやって午後からは来週のオンライン飲み会の手配をしたり、打ち合わせのメモをまとめたりしていた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。直近の2-3週間でやっていた ci/cd の改善や github actions のことについて共有したりした。次の契約更改のタイミングで契約条件の変更を相手と協議しようと考えている。具体的には単価をあげたり事例紹介を許可してもらったりといった類の交渉をする予定。一般論として業務委託は最初の契約条件から条件変更するのが難しいらしく、なかなかタフな交渉になるっぽいというのをはらさんから助言してもらったりしている。私の中では交渉するネタはいくつかあるし、ダメならダメで最悪のケースなら契約終了して、別の会社のお仕事に切り替えてもよいし、いまは開発者は売り手市場なので楽観的に考えていたりする。

近況報告

元同僚と1年ぶりにオンライン飲み会をした。それぞれ近況を話したりしていた。私が見限ったビジネスはその後うまくいったらしくてなにがうまくいくかわからんものだという話しも聞いた。私が在籍していた頃の早期退職制度は50歳以上が対象だったけど、いまは45歳以上に下がっているらしい。また来期から年配の社員を辞めさせるための追い出し部屋ならぬ追い出し会社がグループ企業として設立されるという話しも聞いた。おそらくは戦力外社員をその会社に集めて待遇を下げるみたいな話なんだろうと推測する。日本の労働基準法では、一方的な解雇や減俸はできないが、配置転換は許されていて、別会社に転籍してその会社の待遇が元の会社よりも悪いというのは法律的に問題ないらしい。本体より待遇の悪いグループ企業を作って、そこに転籍することで事実上の減俸や自主退職を促すような慣習となっている。私が起業した理由の1つは早期退職制度ができて自分の未来もそうなると実感したというのがある。少なくとも自分の会社で自分が解雇されることはない。

元同僚の1人も来期は45歳になるので早期退職制度を使って会社を辞めるかもしれないという話されていた。40代からのキャリアってなかなか難しいなとは思えた。私もいまはなんとかなっているけど、このままお仕事がある保証はないし、引き締めていかないといけない。ただあるとき急に追い出し会社に送られるという組織の論理で生きているわけではないという自由だけは謳歌している。

23時に寝てたぶん1回ぐらい起きて6時前に起きた。

GitHub Discussions

やぎさんに GitHub Discussions というのがあると教えてもらった。軽くチュートリアルやドキュメントに目を通してみた。stackoverflow のような q&a ができるようなサービスなのかな？著名な oss のコミュニティでたまに盛り上がるネタとして issue がサポートセンターになってしまうという問題がある。経験が少ない開発者が自分の環境で動かなかったときに issue 登録して開発者にサポートを依頼するみたいなことになってしまうケースがある。もちろん経験が少ない開発者にとっては環境要因のエラーとそうじゃないのを見分けるのは難しいことかもしれない。一方で oss コミュニティのメンテナーのリソースも有限なことから初心者質問を回答するために多くの労力をさけないという現実もある。その issue と q&a のギャップを埋めるようなサービスになるのかな？と推測している。試しにいま作っているデプロイツールで discussions を有効にしたのでいろいろ触ってみる。

近況報告

約1年ぶりにやすだ先生とオンライン飲み会をした。3月にやっているので今期の経営的なふりかえりも少ししつつ大半は雑談をしていた。昨年、経営コンサルティングで交際費が少な過ぎるという指摘を受けてからオンライン飲み会や雑談会を始めたときの、身近な相談相手の1人と言える。今期は10人以上とオンライン飲み会やオフラインの雑談会をやっているし、こんな感じで知人と定期的に近況を話す仕組みを継続できればいいなとは思う。今期は交際費として30万円/年の予算を確保しているものの、現時点では83,747円しか消化していない。もう決算まで1ヶ月もないのに。なぜなのか。。。

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

リーン思考

スクラムのふりかえりをしていて、スクラムマスターがふとスクラムっぽいものとスクラムとの違いの1つとしてリーン思考の有無をあげた。私がリーン思考というのを知らなかったので軽く調べてみた。

• リーン思考とモジュラー化を実現するための3ステップ

リーン思考とは？

リーンという考え方は、ムダを最小限に抑えつつ、顧客価値を最大化することです。そのためには、ムダを削除・削減させるような構造化された「働き方」と、それを継続的に改善し続けることが必要です。つまり、リーンな組織というのは顧客が何に価値を感じているのかを理解しており、継続的な価値向上に繋がるプロセスに注力するものです。繰り返しとなりますが、究極の目標は、ムダゼロな完璧なプロセスを通して、顧客に最大限の価値を提供することです。

引用しておいてなんだが、「リーン思考とは」と節を書いているのに直接な定義を最初に書かない文章は読みにくい。要約すると、リーンという概念を組織として理解していて実践していく考え方や心の動きをリーン思考と呼ぶのだろうか？スクラムマスターがリーン思考が足りないとか言っていたけど、あまりピンとこない。というのは、スクラムマスターは基本的に言うだけで実践はすべて現場に丸投げ。リーン思考が足りないというだけなら誰でも言えるが、日々の具体的な活動や実践にどう落とし込むのかを示さないので現場のメンバーにはあまり響かない。リーダーシップにもいろんなタイプがあると思うが、実践は実践力をみせつけてフォロワーがついてくる。とくに抽象的なよくわからない概念をビジョナリーが提唱するだけではなにも変わらない。

私自身がリーン思考を意識したことはないが、課題管理に関して開発のワークフローを最適化するというのはある種のリーン思考とも言える。チケットのワークフローが洗練すれば洗練するほど効率がよくなってイテレーションのサイクルが多くまわり、結果として価値が速くユーザーに届いたり、試行錯誤の改善が早くなる。キーワードとして一応は覚えておく。

23時に寝て5時過ぎに起きた。何度か途中で起きたけど、久しぶりによく寝た。前日あまり寝てなかったから19時過ぎには帰ってきてだらだらしてた。

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

業界研究を兼ねて もてなしだけではもう食えない -ホテル経営学の本質と実践- を読み始めた。同じ出版社の週刊ホテルレストランという雑誌の連載を書籍化したものらしい。著者は立教大学で社会人向けビジネススクールでホテルマネジメントとホテルインベストメントを教えているらしい。ビジネスの堅い話しを小説調にすれば読みやすいんじゃないかみたいな取り組みなのかな？よくわかてないけど、小説仕立てで業界研究ができるような書籍になっているらしい。第1章プロローグと第2章腐りやすい在庫を読んだ。実際の現場でこんな仕事できない人が改革チームのリーダーなんかになったりしないなと思いながら読んでた。そこは本題じゃない！コンサルティングでありそうな経営の話しが出てくるのでうちの会社の経営の勉強にもなるかもしれない。少しずつ読んでいく。

デプロイ改善の成果

水曜日がすくらむのふりかえりイベントがあるのでそれに間に合わせて簡単にまとめの資料を作った。3スプリント (3週間) もかけて抜本的に開発のワークフローからビルド/デプロイの ci/cd を見直したので開発全般に影響を与えた。

• 本番環境デプロイ: 実行時間を約72%の短縮
• テスト環境デプロイ: 実行時間を約51%の短縮
• hotfix デプロイ: 実行時間を約64%の短縮
  • そもそも従来のやり方では hotfix を出していないので机上の時間ではあるが

単純に github actions の実行時間だけ比較しても速くなっているのだけど、それ以上にブランチ戦略を大きく変えた。従来は3つのブランチで運用していた。

• develop
• test
• main

これを1つのブランチのみで運用できるように開発のワークフローを刷新した。ブランチが1つしかないので ci/cd の戦略もシンプルになって、変則的な運用 (hotfix を出したいとか) をしても、開発全体に影響を与えない。「誰か勝手にブランチを作ってデプロイして」で終わる。従来のやり方は3つのブランチが開発ワークフローと ci/cd に密接であったために本番環境のリリースするときは開発すべてが止まってしまう状態だった。週1回のリリースだったので本番リリース前の1-2日は PR のレビューやマージを止めているという運用になっていた。それは開発速度に大きな影響を与えていた。ブランチ戦略を見直したことでいつでも本番環境にデプロイできるようになって、継続的デリバリーっぽいことがやりたかったらできるよという話しをした。

3時に寝て6時半に起きた。朝起きたら github actions のリソース上限に達しているという連絡が slack に書き込まれていて週末に移行作業して1500分ぐらいは浪費しましたと事後報告した。

ワークフロー移行後の説明

週末に移行した新しい ci/cd の仕組みを開発者に説明した。開発のワークフローも大きく変わる。いくつか要望をもらいつつ、とくに混乱も誤解もなく受け入れられた。github actions の管理画面からボタンでデプロイ実行できるため、本番環境にデプロイできるユーザーは制限したいと言われて次のようなステップを追加した。

- name: デプロイユーザーを確認
  if: ${{ env.DEPLOYMENT_ENV == 'prod' }}
  run: |
    [[ "${{ contains(fromJSON(env.DEPLOYABLE_USERS), github.actor) }}" == "true" ]] && exit 0
    echo "デプロイ権限のあるユーザーではありません"
    exit 1    
  env:
    DEPLOYABLE_USERS: '["user1", "user2", "app-bot"]'

expressions の Functions に組み込みの関数がいくつか紹介されている。それらを組み合わせるとうまくいきそうと思って書いてみた。たしかにちょっと楽に実装はできるけど、github actions の expression とシェルの文字列との境界が、yaml のコード上では曖昧なため、真偽値などはとくにわかりにくい。例えば、次のコード。

[[ "${{ contains(fromJSON(env.DEPLOYABLE_USERS), github.actor) }}" == "true" ]]

${{ ... }} で囲まれたところは github の expression なので boolean として評価できるが、それをシェルにもってくると文字列になってしまうので文字列で比較しないといけない。普通にコードを書いていて気づきにくいので実行して振る舞いを検証しないと間違うみたいな話し。

ぼくのかんがえたもっとさいきょうのでぷろい

昨日 ぼくのかんがえたさいきょうのでぷろい を実装したんだけど、その後、残っていた残課題に対応しているうちにもっと最強のデプロイ方法があることに気付いた。結論から言って GitHub Deployments を使う必要がなかった。GitHub Deployments で過去のリビジョンを指定したときは次のような 409 エラーが発生する。

gh: Conflict merging main into f0cff65c94c4a242efebc79c8fb1e31d58d2f592. (HTTP 409)

これを回避するためにどんな手段があるかなと workflow dispatch event をみていて inputs というパラメーターがあることに気付いた。あれ？workflow dispatch ってパラメーターを受け取ることができたんだっけ？と調べたら2020年7月ぐらいからできるようになってた。

• GitHub Actions: Manual triggers with workflow_dispatch
• GitHub Actions: Input types for manual workflows

github actions の web ui とも連動していて画面からもパラメーターを渡せるようになっていた。jenkins で言うところのパラメーター付きビルドと呼ばれる機能。カスタムアクションの inputs と同じような使い勝手で利用できる。workflow dispatch がパラメーターを受け取れるなら GitHub Deployments を使うメリットって何があるっけ？と思ったら何もなかった。GitHub Deployments を使うことで無駄にリソースを浪費してパイプライン処理を複雑化させるデメリットしかなかった。inputs に渡す型に environment を指定すると、環境の制限や権限、protected branch などにも応用できるらしい。但し、この environment は public リポジトリか、github enterprise でしか高度な設定はできないみたい。GitHub Deployments 経由でリソースの作成自体はできる。

2時に寝て8時頃に起きた。前日に深夜まで開発してたせいか、朝起きたら頭痛かった。

ストレッチ

お仕事に集中していて今週は1回しかストレッチができなかった。今日の開脚幅は開始前164cmで、ストレッチ後165cmだった。先週と同じぐらいかな。それでも毎週予定が入っているので必ず週に1回はちゃんとしたストレッチを受けられる。もう1年以上続けているのだけど、以前より体調のよい状態をずっと継続できている。私はなにかに集中すると他のことをしばらく放置してそればっかりやってしまう傾向があるから毎週の予約があることが継続的な体調管理に大きく役立っている。太ももの後ろの筋肉と腰のストレッチの2つを楽しみにしている。デスクワークをする人は基本的にこの2つに疲労が蓄積するので疲労が溜まるのは自然と言える。その度合いがどのぐらいかでその週の疲労感や調子がよくわかる。今日は先週よりもその2つはましになっていた。

ぼくのかんがえたさいきょうのでぷろい

ここ2週間ほど、ビルドとデプロイの分離のための作業をしている。具体的には GitHub Deployments と GitHub Actions を組み合わせて、新たな開発のワークフローを作るといったもの。main, test, develop と3つのブランチで開発/運用しているのを main ブランチ1つに統合し、ビルドもデプロイも最小限に留めて継続的デリバリーを目指すというもの。移行時は開発を止めてしまうのでこの土日で作業する予定だった。準備は十分にやっていたので問題なく移行を完了させた。今日は単体リポジトリのテスト環境へのデプロイができるところまでできた。あとはデプロイツールや github actions の処理を洗練させていくだけ。テンションが上がっているのでこのまま明日も休出してできるだけ品質をあげていく。

0時に寝て3時40分に起きてそれからの記憶があまりないけど、6時半には起きてた。昼間は久しぶりにシェルスクリプトに熱中してて夜にイベントがあって、それを聞きながらも日付が変わるぐらいまではずっとシェルスクリプトを書いていた。

よくわからないイベント参加

【デブサミ再演】10年後もエンジニアが成長し続けるためにできることを、20年続く組織の中から考える に参加した。なにかの機会でたまたまみかけて中堅社員のキャリア論かなと思って参加したけど、なんかいまいちだった。シェルスクリプトを書きながら聞いてたから大事な話しもしていたかもしれないけど、miro でプレゼン資料が作られていて、参加者が付箋などに書いたコメントをみながら主催者が回答したりもしつつ、スライドで説明したりもしつつ、発表と雑談が混ざった進行で私からはコミュニティの内輪感にみえたし、何が言いたいのかよくわからないイベントだった。コミュニティのメンバー数をみるとそこそこ大きいようにもみえるので、単純に私がコミュニティの対象とする参加者ではなかったんだと思う。パワーポイントなどのスライド資料でプレゼンするのではなく、miro でプレゼンするというスタイルが新鮮で私からはそれがもっとも参考になった点だった。

組織論やキャリアの悩みは私の中では決着がついてしまったのかもしれない。変なことは言っていないし、5年前ぐらいの自分なら関心をもって聞いていたかもしれないけど、自分で会社を作ってみて、組織の論理に振り回されることがなくなって、自分のやりたいことに集中できるようになったからかもしれない。

0時に寝て3時40分に起きて気付いたら6時半だった。

交通事故の裁判

父の交通事故の裁判で保険会社と和解が成立した。交通事故の後、症状固定という、医師の視点からは治療は完了したという診断書をもって加害者の保険会社から任意保険の保険金が支払われる。相手の保険会社の審査のようなものが滞っていて症状固定診断から1年以上経っても支払われないので裁判を起こしていた。弁護士さん曰く、保険会社も多忙なので保険金支払いの裁判を起こすのはよくあることだと当時聞いた。基本的に私は弁護士さんとメールでやり取りしているだけだったが、裁判の傍聴 も1度だけした。10月にもう少しで終わりそうと見積もっていて、実際に結審したのが3月なので5ヶ月ぐらいかかっている。裁判は1-3ヶ月に1回ぐらいの頻度でしか開かれないのでそういう時系列になる。裁判を始めたのが2021年6月頃なので和解という形で結審するまで1年半ぐらいかかったことになる。父が交通事故にあってから約5年が経過していた。保険金は父の財産であり、成年後見人の弁護士さんが管理するもの。保険金支払いは父も含めて家族の生活に変化をもたらすものではない。私が弁護士さんとやり取りする必要がなくなるので自由時間が増えるというぐらいの変化。