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年が経過していた。保険金は父の財産であり、成年後見人の弁護士さんが管理するもの。保険金支払いは父も含めて家族の生活に変化をもたらすものではない。私が弁護士さんとやり取りする必要がなくなるので自由時間が増えるというぐらいの変化。

23時に寝て2時に起きて6時に起きた。

シェルスクリプト再考

久しぶりにシュルスクリプトを書いていて、ユーティリティ関数をうまいこと実装できないかを調べていたら nameref という仕組みが bash 4.3 以降で使えるらしい。私の bash 環境は 5.0.17 なので、bash 5 以上という制約にしてしまってもよいだろうと思う。例えば、こんなことができる。シェルスクリプトで split を実装するの面倒よね。

function split() {
    local -n arr="$1"
    local values="$2"
    local sep="${3:-,}"
    IFS="${sep}"
    read -a arr <<< $(echo "$values" | tr -d '[:space:]')
}

function test() {
    split mylist "a, b, c"
    echo "'${mylist[0]}'"
    echo "'${mylist[1]}'"
    echo "'${mylist[2]}'"
}

実行結果。ちょっと感動した。

$ test
'a'
'b'
'c'

• How to return an array in bash without using globals?
• 3.4 Shell Parameters

bizpy 勉強会

Python で機械学習の前処理をやってみる勉強会 を開催した。今回も講師をわたなべさんにお願いした。私が余裕なくて全くなにもできていない。運営が2人いるとすごく助かる。今回は機械学習の前処理に着目して pandas や scikit-learn を使って実際にどういったプログラミングをするかを解説してもらった。Colab を使ってデモするのがいまどきのやり方なのかな？私は全く触ったことがないけど、そういうやり方の違いも含めて関心をもてた。Colab 上で普通に git コマンドも使えるのでリポジトリのクローンなんかもできる。次回は私もなにかしら発表をしたいなとは思う。いまのお仕事が一段落ついたら。

23時に寝て5時半に起きた。何度か夜中にも起きた。起きてからドラクエタクトやってた。

oauth apps と github apps

いまお仕事で ci/cd の改善をやっていて、その一環としてリポジトリをまたがったパイプライン処理を検討している。 ci/cd で使うような認可の仕組みとして github には oauth apps と github apps の2種類がある。

• Building OAuth Apps
• Building GitHub Apps

私はどちらも全く関わったことがなかったので、仕組みがイメージできる oauth apps を使えばよいのだろうと調べ始めた。しかし、一通り調べてみて会社の開発における ci/cd に使うなら github apps の方が適していることがわかった。両者がどう違うのかもドキュメントに記載されている。最初にこのドキュメントを読めば oauth apps を調査する必要はなかった。

• Differences between GitHub Apps and OAuth Apps

具体的には、oauth apps は user の権限を認可する仕組みで、github apps は organization の権限を認可する仕組みと言える。github apps も oauth によるユーザー認証もできる上にアプリ自身の認証もできる。さらにアクセスできるリポジトリも制限できることから github actions などで、特定のリポジトリに対してのみアクセス可能なトークンを取得するには github apps の方が向くというわけだ。oauth でユーザーが認可するときに scope を指定するが、その scope を organization が設定できるといったところが github apps と oauth との違いにみえる。取得できる token の有効期限にもその考え方の違いが出ている。

• oauth apps
  • ユーザー/デバイス認証
    • 認可コード: 15分
    • アクセストークン: 無期限
• github apps
  • installation 認証
    • 認可jwt: 10分
    • installation トークン: 1時間
  • ユーザー/デバイス認証
    • 認可コード: 15分
    • アクセストークン: 8時間