Posts for: #Life

放置していたバグを直した

1時に寝て7時に起きた。寝ていて夜中に吐き気して眠れなくて上体を起こすしかなかった。たまにある 胃食道逆流症 のひどいやつ。

参議院選挙

普段は期日前投票で済ませるのだけど、今週は他のことに注意を取られていたせいか、当日行ってきた。場所が期日前と違ったので勝手がわからなかったけど、とくに混雑もしてなかったのですぐに完了できた。タイムラインを眺めると、私のタイムライン上では投票したと発言する人が増えてきたように思う。投票率が50%程度で半分ぐらいの人が投票していない状況に懸念をもつ人たちの可視化がされている。

ふと父の選挙はどうなるんだろう?と思って検索してみた。意思表示できない状態だと選挙はできないみたい。

選挙人本人が投票所に行き自らの意思で投票することが原則であることから、意思表示が困難である場合には投票することはできません。これは投票所の係員が選挙人の投票を補助する代理投票においても同様です。したがって、家族の方が本人に代わって投票することはできません。

神戸市 FAQ > 市政情報 > 選挙

70歳以上は傷病で選挙権を行使できない人たちもいるだろうから減るのかな?と、総務省の 年代別投票率 のグラフを確認してみた。直近だと、70歳以上が61.96, 60歳代が71.43、50歳代が62.96だった。60歳代と比べて減ってはいるけど、50歳代とそう変わらないのをみると、元気な人たちに選挙へ行こうと呼びかけるのは正しい気がした。

backlog-github-integration-action のバグ修正

運用してすぐにコミットメッセージ中にシングルクォートやダブルクォートが含まれると引数を正しくパースできなくてエラーになることがわかっていた。いま運用している環境の用途だと、それほど重要ではないので後回しにしているうちに面倒になって放置していた。晩ご飯を食べてからデバッグしていたら7時間ぐらいやってた。

bash 上の文字列の扱いと action.yml の inputs の args に引数渡しするときの振る舞いの勘違いもあって、issue の見た目以上に複雑な振る舞いをしていることがわかった。github actions 上のコンテキストに依存したくなかったため、github.event.commits の json をそのまま cli パラメーターとして渡している。bash 上の json 文字列と cli パラメーターとしての扱いが煩雑になるのでこのやり方は失敗だったかもしれない。ローカルでのテストもやりにくい。私はそのことをよく理解していたはずなのに github actoins 上のアンチパターンにはまってしまった。カスタムアクションのユーザーが簡単に使えるように cli パラメーターの設定を簡単にする意図で json 渡しにしたんだけど、エスケープの振る舞いが想像以上にややこしくなって、エスケープしたいユーザーには簡単ではなくなってしまった。それでもデバッグをがんばったおかげでシングルクォートは完全に使えるように実装できた。ダブルクォートは制限付きでエラーにならなくできるが、事実上は使わないでくださいといった仕様制限にしてしまおうと思う。引用するときはダブルクォートじゃなくてシングルクォートを使ってくださいと啓蒙することに決めた。

github actions の push イベントワークフロー改善

23時に寝て6時に起きた。今週はサービスインで凸凹していて疲れた。

ストレッチ

今日の開脚幅は開始前161cmで、ストレッチ後164cmだった。ちょっと数値がよくなった。一昨日の日本酒イベントで4時間ほど立ち呑みをしていた疲労で腰に張りが少しあった。それ以外はとくに問題はなくて調子がよかった。右股関節の詰まりも2-3週間前よりもよくなっている気がする。これはトレーナーさんも注意を払って詰まりを取り除くようにストレッチのメニューを組んでくれているのでその成果が徐々に出始めている気がする。以前よりも可動領域が広がってきている気がして安心感を得た。

github actions の push イベントワークフロー改善

午後からビルド・デプロイの最適化のために github actions のワークフローを改善作業をしていた。

今週はサービスインにより、本番環境への緊急リリースを何回もやっているのを傍からみていて、ビルド・デプロイが速くなればなるほど、その回数を増やせるし、修正後の検証に時間を多く割ける。あるリポジトリが7つのモジュールをまとめてビルド・デプロイしている。これはあるモジュールの微修正の反映には向かないので改善することにした。結果として最大で50%ぐらいのビルド時間の削減、モジュールに依っては、具体的には10分かかっていたものを4分台でビルドできるようにした。

ワークフロー改善のためのデバッグしている間はビルド・デプロイが出来なくなることから開発者が使っていない時間帯が望ましい。必然的にサービス休日出勤して github actions のワークフローを改善していた。デバッグと動作の検証も兼ねて午後から半日以上やっていたので休日にやったのは正解だと言えるだろう。

push イベントの github コンテキストの github.event.commits にコミット情報が入っていて、そこにコミットのリビジョンがある。例えば、次のようなオブジェクトで id がコミットのリビジョンに相当する。

[
  {
    "author": {
      "email": "...",
      "name": "...",
      "username": "t2y"
    },
    "committer": {
      "email": "...",
      "name": "...",
      "username": "t2y"
    },
    "distinct": true,
    "id": "f8df1f77ffec9ef234e7321b2e237b663256b01c",
    "message": "コミットログのメッセージ",
    "timestamp": "2022-07-08T12:32:33+09:00",
    "tree_id": "37b066734e58779c5d2c687d40b4cc43af177cb2",
    "url": "https://github.com/OWNER/REPO/commit/f8df1f77ffec9ef234e7321b2e237b663256b01c"
  },
  ...
]

このリビジョンを使って github rest api からファイル情報を取得できる。

$ gh api -H "Accept: application/vnd.github+json" /repos/OWNER/REPO/commits/f8df1f77ffec9ef234e7321b2e237b663256b01c

いろんなデータが返ってくるけど、ここでは変更したファイルのパスを知りたい。

{
  "sha": "...",
  "node_id": "...",
  "commit": {
    ...
  },
  ...
  "files": [
    {
      "sha": "...",
      "filename": "module1/path/to/src",
      ...
    },
    {
      "sha": "...",
      "filename": "module2/path/to/src",
      ...
    }
  ]
}

この filename のトップディレクトリがモジュール名と同じなのでここだけ取り出して、管理対象のモジュールかどうかを比較する。bash でも =~ をサブ文字列のマッチングができる。

$ targets=(mymodule1 mymodule2)
$ echo " ${targets[@]} "
 mymodule1 mymodule2 
$ [[ " ${targets[@]} " =~ " mymodule1 " ]] && echo "match"
match
$ [[ " ${targets[@]} " =~ " mymodule2 " ]] && echo "match"
match

さらにマッチしたモジュールを github actions の expressions で制御しやすいように json の array に変換する。

$ jq --compact-output --null-input '$ARGS.positional' --args -- ${targets[@]}
["mymodule1","mymodule2"]

これを step の outputs として格納する。

echo "::set-output name=modules::${json_array}"

例えば、後続の job で実行条件としてモジュールの有無を調べたいときは expressions を使って次のように記述できる。if 文は ${{ ... }} のブラケットを省略できるようだけど、ここだけ省略すると返って混乱するかなと思って私は記述するようにしている。その方が統合性があってコードが読みやすいように私は考えている。

  mymodule1-job:
    if: ${{ contains(fromJSON(needs.build.outputs.mymodule_target.modules), 'mymodule1') }}
    needs:
      - build

ちなみに workflow レベルの env は job の if 文には使えない。outputs を使って動的な値を扱うようにしている。どうも workflow レベルの env はいろいろ問題があるみたいでなかなか issue がクローズされないのをみると取り扱い注意なのかもしれない。

最終的なモジュールを判別するための step は次のようなものになった。

  build:
    outputs:
      mymodule_target: ${{ steps.mymodule-target.outputs.modules }}
    steps:
    - name: コミットログからビルド対象のモジュールを設定
      id: mymodule-target
      run: |
        declare -A modules
        target_modules=${{ env.TARGET_MODULES }}
        revisions=$(jq --raw-output '.[].id' <<< '${{ env.COMMITS }}')
        for revision in ${revisions}
        do
          names=$(gh api -H "${{ env.ACCEPT_HEADER }}" ${{ env.COMMITS_PATH }}/${revision} | jq --raw-output '.files[].filename' | cut -d"/" -f1 | sort -u)
          for name in $names
          do
            if [[ " ${target_modules[@]} " =~ " ${name} " ]]; then
              modules[${name}]=true
            fi
          done
        done
        targets=$(jq --compact-output --null-input '$ARGS.positional' --args -- "${!modules[@]}")
        echo "::set-output name=modules::${targets}"        
      env:
        TARGET_MODULES: |
          (
            'mymodule1'
            'mymodule2'
          )          
        ACCEPT_HEADER: "Accept: application/vnd.github+json"
        COMMITS_PATH: /repos/${{ github.repository }}/commits
        COMMITS: ${{ toJSON(github.event.commits) }}

処理も理屈も簡単なんだけど、実際の運用コードはもう少しだけ複雑なものの、デバッグは github actions を実行しないといけない。ちょっとした typo のために実は2時間ほどはまっていたのは内緒。シェルの配列や連想配列を使うと、記号が多くてわかりにくい。配列の閉じブラケットを忘れていたがために EOF のエラーが発生していた。閉じブラケットのミスだけにエラーが発生しているところと実際のコードがズレていて、それに気付くのに少しずつコードを足したり消したりしてデバッグするみたいな原始的なやり方で些細な typo を気付くのに時間がかかった。

xxx.sh: line 47: unexpected EOF while looking for matching `"'

夏休み

0時に寝て7時に起きたけど、昨日から体調よくなくてしんどくて寝てた。

開発やら決算の事務手続きやらのタスクが一段落して余裕時間ができたことでぼーっとしてた。まぁたまにはそういう日もあるか。何も作業せず休んだ日は day off というタグを付ける。あとで何日ぐらい休んだか、どのぐらいの期間で休んだかの確認にもなるかもしれない。

夏バテ

0時に寝て7時に起きた。途中で吐き気がして何度も起きた。夜うまく眠れない。

ストレッチ

今日の開脚幅は開始前160cmで、ストレッチ後163cmだった。先週とほぼ同じでよい状態を維持できている。外が暑くなってその比較から dr.stretch さんの事務所はエアコンがよくきいていて涼しい。うちのオフィスはエアコンの設定温度を上げる人がいて気付くと26.5℃とかに設定されていて私にとっては暑い。とくにどこか張りの強い部位や痛いところはなかった。夜にあまり眠れないわりには身体的には負荷がかかっているところはなさそう。

ストレッチを終えてからオフィスに戻って軽く調べものして、眠くなって仮眠して、そのまま家に帰って寝てた。とくに急ぎでやるタスクがなかったせいか、なんか一気にバテた。

k8s のアップグレードをやってみた

0時に寝て6時半に起きた。起きてから1時間ほどだらだらしてた。

ストレッチ

今日の開脚幅は開始前161cmで、ストレッチ後163cmだった。先週と同じなので現状維持とも言えるし、よい状態を維持しているとも言えるかもしれない。もう1年以上通っているせいか、なにかポイントが溜まっていて使わないといけないという話しで今日は20分延長でやってくれた。とは言っても、基本的なストレッチ項目が変わるわけではなく、いつもより伸ばす時間や手順が少し増えているぐらいだった気がする。今週はとくに腰の負荷もあまり感じなかったせいか、いつもの右腰の張りもなかったように思う。トレーナーさんに聞くと、暑くなると筋肉は伸びやすくなるので季節要因でストレッチをしたときの伸び具合が変わるのは普通とのこと。調子がよくなってきたのでこのまま好調を維持したい。

eks (k8s) のアップグレード

お手伝い先のお仕事がもうすぐサービスインなのでそれまでにリスクのある作業をやっとこうみたいな状況にある。たまたま eks (k8s) のバージョンを 1.21 から 1.22 にあげようと思い立って、木曜日に提案したら、どんな障害が起きるかわからないので他メンバーがテスト環境を使っていない時間帯で作業した方がよいだろうという話になって土日にやることにした。

何が起きるか分からなくても、土曜日から始めて致命的なトラブルに見舞われても1日もあれば解決できるだろうという見通しで作業を始めた。その見通しも「私がやれば」という前提に成り立っている。良くも悪くも私がやろうと言ったことに反対されることはほとんどないが、それは私が言ったことは一定時間に私がすべてやり切るという信頼に基づいている。本当の意味でできるかどうか分からないことを必要以上に抱え込んでしまうときもあるのでバランス感覚は必要かもしれない。言わばサービス休日出勤だし、なぜ私がやっているかと言うと、システムの運用や保守の展望を考えたら、サービスインの前にインフラのバージョンを上げておく方が将来の保守コストを下げることに繋がるという1点のみに重要性を見い出していて、それをもっとも強く主張しているのが私だからという理由。

結論から言って2時間でアップグレード作業を完了した。1つ手順漏れがあって、アプリケーションの pod がすべてエラーになるというトラブルに見舞われたものの、すぐ手順漏れに気付いて難なく復旧できた。今日はテスト環境のアップグレードをしたわけだけど、また後日、本番向けの作業手順書を作れば、ほぼタウンタイムなしで1時間もあればアップグレード作業を完了できそうな見通しではある。

実際はミスもあったので次の順番でやったわけではないが、おそらくこの手順でやれば正しいはず。

  1. aws cli と eksctl コマンドのインストール
  2. aws のアップグレードドキュメンを読む
  3. cert-manager のアップグレード (1.1.1 から 1.5.4)
  4. aws-load-balancer-controller のアップグレード (2.2.0 から 2.4.2)
  5. k8s control plane のアップグレード (1.21 から 1.22)
  6. (オプション: 不要) autoscaler のアップグレード
  7. (オプション: 不要) gpu サポートノードのアップグレード
  8. vpc cni プラグインのアップグレード (1.7.5 から 1.11.2)
  9. coredns プラグインのアップグレード (1.8.4 から 1.8.7)
  10. kube-proxy のアップグレード (1.21.2 から 1.22.6)
  11. k8s nodegroup のアップグレード (1.21 から 1.22)
    • k8s ノードが存在する nodegroup をアップグレードするとそのインスタンスが再作成されて pod が再デプロイされる

細かい手順は aws のドキュメントの指示に従いながらやったらできた。add-on と self-managed add-on の種別の違いがあったり、helm と k8s manifest の手順が別々だったり、どのバージョンからのアップグレードかで作業手順が異なったりと、ドキュメントをちゃんと読まないと正しい作業手順がわからない。基本的にはドキュメント通りの作業で完了できた。

もくもく会

アップグレード作業を終えてから1時間ほど残っていたので16時から 【三宮.dev & KELab 共催】もくもく会 に参加した。今回は Kobe Engineers Lab さんと共催ということで 120 WORKPLACE KOBE で開催された。Kobe Engineers Lab の主催者の会社が 120 workplace でオフィスを借りているため、会議室を5時間/月まで無料で借りられるという。私も過去に何度か 120 workplace のコワーキングスペースで作業したこともあった。久しぶりに行ってよい場所だとは思う。会議室は初めて入ったけど、10人ぐらいは余裕で作業できる大きなテーブルがあって広くてよかった。終わってからわたなべさんと3時間ほど立ち呑みしてた。

はんなりビジネス

21時から はんなりビジネス #0 に参加した。おがわさんがまた新しいことやるんだなと思って興味本位で参加してみた。現実の課題に対してコミュニティの有志を募ってチームで取り組んでみたら、問題解決能力も身についてプログラミングの知識を活かしてより実践的なスキルが身に着いてよいのではないかといったところから始まった企画らしい。今日は初回だったので参加者でどういう取り組みがよいのかを雑談してた。まだまだこの先どうなるかわからないけど、私はあまりこの手の取り組みには懐疑的かなぁ。自分たちにとってちょうどよい課題レベルの対象をみつけるのは難しいし、誰でも参加できるオープンなビジネスコンテストやアイディアソンが本当に大事な問題を扱っているかも怪しい。現実の課題はお仕事でいくらでもあるので、それをコミュニティでやろうと思うとニッチな何かになるか、価値があるかどうかよりも本人がやりたいかどうかの目的になってしまうような気もする。とはいえ、私自身、ビジネス力はまったくないのでなにかしらやっているうちに価値に気付くこともあるかもしれない。もうしばらく様子をみてみる。

余白談義

0時に寝て6時に起きた。だいぶ復調してきて朝起きれるようになってきた。

歯科検診

3ヶ月ごとの定期検診。前回 は2年ぶりにレントゲンをとったので新しい歯のレントゲン写真をみせていただいた。とくに変わりなく、親知らずにゴミが溜まるスポットがあるから、親知らずを抜いた方がいいのはいいけど、下側の親知らずを抜くのは大変だから痛くなってからでもよいかも?みたいな話しをした。いま3ヶ月ごとに定期検診して親知らずのゴミスポットの掃除をしてもらっているからそれでもしかしたら大丈夫なのかもしれない。あと1箇所だけ銀の詰めものと歯が精密に一致していないところがあって、その隙間にゴミが溜まりやすいとのこと。急がなくてもよいけど、いずれ付け直した方がよいらしい。

隔週の雑談

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

  • お手伝い先の契約更新についての話題
  • カフーツさんとワーケーションの話題
  • jjug ccc 2022 spring ふりかえり

先日の記事 でも「余白」という概念が個人的にはまったのであちこちで余白談義をしている。デザインで言うところの余白とは何かをはらさんに聞いてみたところ、次のようなものだという。

  • 空白というコンテンツである
  • 他に使ってはいけない領域である

開発における余裕とかゆとりのことを余白と言ってしまうと、デザインの文脈とは一致しないという話しになった。ワーケーションの文脈では予定調和じゃない時間を指すといとうさんは仰っていた。何かをやるための計画を立てた時間ではない。何もしなくてもよいし、思いつきで何かをしてもよい。先日の記事で、課題管理の文脈でメタ課題の抽出や他人のチケットにコメントしたりするのも余白の1つではないかと私が書いたのはその行動が必須というわけではない。誰かから指示されてやっているわけでもないという行動が、ワーケーションにおける予定調和じゃない行動と共通点があるのではないかと考えたから。

私が開発における余白を余裕やゆとりのように解釈して発言したので余っているものというニュアンスになってしまったけど、その時間は余っているものではなく、明示的に明けておくべき時間のように捉えたらデザインの文脈で言う余白にも近い概念になるかもしれない。開発だと想定外の追加作業や要件漏れなどのために確保しておく時間をバッファと呼んだりもする。例えば、開発の作業時間を1日8時間、1週間(5日間)で40時間と見積もるから余白がなくなってしまうであって、仮に1週間の余白を3時間と先に確保してしまって、37時間を開発の作業時間としてしまえば余白がなくなるということない。その余白時間に業務に関係ない勉強会をやってもいいし、自分の調べたいことに費やしてもいいかもしれない。私が金曜日を非稼働日として業務委託の作業をやらずに雑談していることにも通じる。

その後、余白談義からスクラムの課題や展望の話しなどにも発散して盛り上がった。スクラムには余白がないから。まだまだ私自身、余白の言語化に曖昧なところがあるので今後も意識しながら概念や価値を言語化していくように努めたい。

ワーケーションの定義を教えてもらった

0時に寝て7時に起きた。前日は移動による運動量が多かったせいか、なぜかよく眠れた。

ストレッチ

今日は朝から調子よいなと思っていた通り、開脚幅は開始前161cmで、ストレッチ後163cmだった。ここ数週間は162cmが上限になっていたので久しぶりに163cmにになった。先週末に休息の時間を多めに取ったせいか、腰の張りもいつもよりは小さかったように思う。

カフーツさん訪問

ストレッチを終えてから神戸駅の近くのカフーツさんに行ってきた。コワーキングスペースのあるイベント でみかけた縁で ブログJelly Vol.120 に参加した。イベントの趣旨としてはブログを書いて、参加者に共有して、ブログの内容について参加者同士でコメントしあうといったもの。参加者は3人だったので必然的に濃いコミュニケーションになった。

私は、明日の jjug ccc 2022 の参加報告ブログの下書きを書いたものの、まだ公開はできないのでリポジトリにコミットした markdown を共有しつつ、既に公開済みのワーケーションの記事をイベントの参加者に共有してみた。いとうさんはワーケーションにも詳しい方なのでワーケーションの定義を間違えているよと教えてくれた。その間違いは私だけでなく、一般的 (日本?) にもよく誤解されているという。まず2泊3日のような短期の滞在をワーケーションとは呼ばない。

日本の「ワーケーション」という言葉の使い方は間違ってて、冒頭、お書きのように、海外で言うところのワーケーションは1ヶ月〜3ヶ月、そこに滞在して地元に溶け込んで観光ではなくて「余白」を作って楽しむ、というものなんですよね。バケーションなので。会社員はムリですが(はっきり言いますけど)、デジタルノマドなリモートワーカーは自分の時間と仕事をコントロールできるので全然OKなわけで、なのでみんな会社員やめたらいいのにと思ってます。

ぼくらの解釈は「余白」はあらかじめなにも予定しない時間、ということです。行った先の成り行きでやることを決める、そのための余剰の時間ですね。だから普段やらないことをやってもいいし、本読んで内省してもいいし、ボ〜っと一日過ごしてもいいし。でも、行った先の地元の人たちとつながる、そこに余白を使うことが望ましいと思います。でもそれも出会い頭が面白いですね。

ワーケーションについてなんやらかんやら雑談しているうちに、いとうさんもテンション上がってきて有料記事をプレゼントするからこれ読めってノリで記事を紹介していただいた。

いとうさんと 「余白」 という概念について議論していて、ずっと自分の中にあった言語化できていなかった概念とも紐付いた。本当によいキーワードを知ることができた。ワーケーション中にはらさんと話していたときに 時間をかければできるものじゃないことをやった方がいい と感じことに言葉を割り当ててくれた。昔の開発と比べて、いまの開発は余裕やゆとりが全然ないと私は思っていて、開発者が自由に調査したり開発したりできなくなっているように感じている。それは「リーン」という概念が幅をきかせていて無駄を減らし、効率を上げることばかりを邁進した結果として「余白」もなくしてしまっているように思う。開発に限らず課題管理の文脈でも、メタ課題の抽出や分類・整理も、他人のチケットにコメントをすることも「余白」の1つと言えるかもしれない。

13時に訪問して、ブログを書き終わったのが15時過ぎで、それから17時過ぎまで適当に作業をやって、その後ビールを飲みながら3人で雑談していて、気付いたら23時20分になっていた。基本的に私は人見知りなので初対面の人たちとそんな長く話すこととかないんだけど、なぜか意気投合していろんな雑談をしていた。コワーキングやワーケーションという分野と課題管理の分野は交錯する点や共通点がいくつかあって、私が課題管理の文脈からこうじゃないか?と言うと、異なる視点からいとうさんが答えるみたいなやり取りになって盛り上がっていた。別分野の経験豊富な方と話すことで多くの気付きを得られるのも「余白」がもたらす価値と言えるのかもしれない。

ワーケーションの精算

1時に寝て7時に起きた。ふとんなしで寝ても寒くない季節になった。天気も悪かったので15時ぐらいから帰って、ドラクエタクトしたり、読み溜めてた LINE マンガ読んだり、疲れたら寝たりして普通に休んでた。

ストレッチ

今週はバテバテになっていて、先週から引き続き、右股関節や右腰に張りが強い。右側が少し前に出たような形状になっているらしく、姿勢か癖かで右側に負荷が偏るなにかになっているみたい。今日の開脚幅は開始前159cmで、ストレッチ後161cmだった。現状維持といったところ。今週末は休もうと思っている。参考がてらトレーナーさんに休むときにどうするかを聞いてみた。ジムへ行って運動した後、それから考えるらしい。私の場合、起きたらひとまずオフィスへ行ってなんか調べものして過ごすことが多い。サードプレイスへ出掛けるのはわりと多くの人に共通する行動なのかなとか思えた。

ワーケーションの精算

今週はバタバタしていてまったく余裕がなかった。ワーケーションのお金の精算をした。同行者からも料金の一部を徴収しているのでこの金額すべてが経費ではない。食費や入浴料金、お土産を除くと次になる。

  • 宿泊費 (県民割引を適用後)
    • 1泊目: 26,000 (3人)
    • 2泊目: 27,000 (4人)
  • 交通費
    • レンタカー: 23,760
    • ガソリン代: 2,424
    • 高速道路代: 5,230
    • 駐車場代: 800
  • 接待
    • 居酒屋: 9,200
  • 合計: 94,414

入浴料金を会社の経費にできるかどうかは福利厚生費ならできるらしい。但し、うちは社員がいないので福利厚生費を計上できない。原則として役員には福利厚生費を適用できない。福利厚生とは社員の生活や仕事の充実や向上を目的とするため、役員はそれを提供する側になる。とはいえ、役員と社員が一緒に利用する妥当な金額の福利厚生費なら認められるらしい。

高速道路の料金を etc の利用履歴から取得できないかな?と考えてググると、ETC利用照会サービス というのをみつけた。初期登録するにはカード番号と直近の利用履歴、車両番号と車載器管理番号が必要になる。レンタカーの領収書には車載器管理番号までは記載されていなかったので店舗に電話して尋ねると快く教えてくれた。これでETC利用照会サービスに登録できたものの、登録後に利用明細が表示されるまで4時間かかるという。バッチ処理のタイミングなのか、なにかわからないけど、4時間は長過ぎでしょとか思いながら待った。待った甲斐があって明細は csv と pdf 出力できた。記録としてデータを残す上でダウンロード機能はありがたい。

ワーケーション 3日目

3時に寝て6時前に起きた。起きて作業しようと思って階下に降りた (寝室は2階) ものの、なんかバテてて、畳の部屋で寝転がっていた。涼しくて気持ちよかった。2度寝もしてたかもしれない。起きてからは帰りの高速道路のサービスエリアを調べたり、丹波篠山市か、六甲山天覧台に寄り道するならどういうルートになるかシミュレーションしたりした。

朝風呂とモーニング

昨日と同じように7時を過ぎてから朝風呂に出掛けていく。今日は「地蔵湯」に入った。子ども向けの浅いお風呂と大きなお風呂があった。座椅子でやや腰に負担がかかっていたのでジャグジーで腰の療養をした。昨日3時まで雑談して疲れていたせいか、2泊を終えてバーンアウトしてしまったのか、3日目の旅程の考えがうまくまとまらなくて、お風呂に入りながらぼーっとしていた。喫茶店の 萠阿 (のあ) さんでモーニングを食べた。

事前に作成しておいた旅のしおりでは、チェックアウトは11時にして、13時に城崎温泉を出発する旅程になっていた。意図としては観光したい人向けに余裕をもったスケジュールにしていたつもりだった。しかし、周りも疲れているようにみえて、11時に城崎温泉を出てもいいかなという空気にはなっていた。とはいえ、11時から帰り始めると2時間半で神戸に着いてしまう。はらさんの帰りの飛行機の時間が19時だったのであまり早くても持て余してしまう。車で行ける付近の場所を観光してもいいかなと思いつつも具体的なアイディアが出てこない。疲れると想定外の状況に対していくつかの仮説を並行してシミュレーションできなくなっていた感じ。お昼ご飯どうする?という話題に、城崎温泉で食べるか、よそで食べるかもまとまらない。誰かが出石そばを食べに行こうと言い始めて「あっ、よさそう」と思えた。近くのパーキングエリアで出石そばを食べたらいいんじゃない?という案もあったが、出石の城下街へ行こうと押し切った。はまらないパズルのピースがはまった。学生の頃にツーリングで出石に行ったことがあったので私はどんな場所かを知っていて、お昼ご飯も食べられて少し観光もできてちょうどいいと思えた。

チェックアウト

11時に管理人さんが来られ、チェックアウトの手続きはすぐに済み、みんなで記念写真を撮って帰り始める。管理人さんは城崎温泉のことを質問すると、あれやこれやと教えてくれていた。すみよしさんが「出石そばのお薦めのお店知っています?」と管理人さんに尋ねた。私がそれは流石に知らんやろと横で聞いていたら「ちょっと待ってください」と即答で2店舗を教えてくれた。この管理人さんは何でも知っているんやなと感心して笑ってしまった。管理人さんは本当に親切でよい人だった。

このときの集合写真はきのいえのインスタグラムで公開されている。

出石そばと城下町散策

11時に城崎温泉を出て出石の城下町へ向かう。40分ほどで着く。きのいえの管理人さんに教えてもらった 官兵衛 さんに訪問。お昼前で少し早かったせいか、ちょうど待たずに入れた。うちらがお店を出たときは2組ほど並んでいた。出石そばのシステムがわからなくて、注文するときに店員さんに尋ねると、大人男性ならだいたい10-15皿だという。ひとまず10皿を頼んで足りなかったらまた注文すればいいとのこと。まずはそばだけ食べて、その後に薬味を使って、卵は後半の方がよいと教えてくれた。私は、最初の2皿をそばだけを食べて、次にわさび、その後に葱や大根おろしを試し、とろろも入れ、8皿目ぐらいに卵をつかってみた。ちょっとした味のバリエーションにもなっていておもしろかった。私は10皿で満足した。

余談だが、まったく値段を知らずに入ったので、お会計のときにこれはいくらなんだろう?思いながら勘定をした。1人あたり薬味150円と皿そばが170円 * 10皿で合計すると1,850円 (税込) だった。おいしかったし、皿そばという名物を食べるという雰囲気も味わえてよかったのでまったく不満はない。純粋にそばだけだからそんなに高くないのかな?という先入観から想像以上だったので少し驚いた感じ。はらさんが「外国人を連れてきたらすごく喜ぶと思いますよ。」と2回ぐらい言ってた気がするので、これは大事なことなんだと思って、外国人を連れてきたらいいと私の記憶に残った。

その後、せっかく出石に来たから城跡も行ってみることにした。城跡には行ったことがなかった。城跡だから原っぱみたいな場所をみるだけかな?と考えていたら、石垣がしっかり残っていて3段目ぐらいまで登って街並みを展望できた。さらにもっと山を登っていけるようで、頂上までいくとそれなりの山登りハイキングができる場所になっているみたい。

私はまったく出石城のことを知らなくて、もともとのお殿様ではないが、なんやらかんやらで 仙石秀久 が城主になったらしい。センゴク の漫画の主人公。城跡に上る鳥居の裏に作者の宮下英樹さんの名前もあった。仙石秀久:鈴鳴り武者、またの名を蕎麦の伝道師…、あんたはいったい何者だ!? の記事によると、出石そばも仙石秀久が信州から出石へ転封したときに一緒に付いてきた信濃のそば職人が発祥になっているらしい。はーん。

西紀サービスエリア

ワーケーション1日目の反省点 にも書いたが、車の移動で行きはどこで休憩するかを決めていなかった。そうすると、どのタイミングでどこのサービスエリアに入っていいかがわからなくなってしまった。帰りは下調べして、休憩によさそうな設備があって中間の適切な位置として、舞鶴若狭自動車道の西紀サービスエリアがよさそうと調べていた。そして最初からナビの目的地をサービスエリアにしてしまうことで走り過ぎや休憩までのペースなども走りながら考える必要がない。当たり前のことなんだけど、自分で運転してみて初日はうまく段取りできなかったのでこれも大事な事前準備だと気付いた。

小さなふりかえりと神戸空港

神戸に戻ってきてから雨がぱらぱらし始めた。天候も何とかもってちょうどよかった。1時間ほどドトールさんで休憩しながら軽いふりかえりみたいになった。

  • 朝と夜に温泉入るのは疲れる
    • 7つの外湯があり、パスポートを購入していても連続でお風呂に入る人はいなかった
  • 開発合宿は2泊3日が限界
    • 非日常の慣れない生活は楽しさととも緊張もあるので疲労も大きい
  • 実際にやってみることから得られる経験や体験はとても大きい
    • 城崎温泉がどういう場所か、その文化や歴史の一端を垣間見えた
    • 主催としてやらなければならない段取りや準備の経験を大きく積めた
      • 今回の経験をベースにして今後も課題管理システムに積み重なっていく
  • 今後の開発合宿イベントの展望
    • オープン版は三ノ宮.devでやりそうなのでそこに便乗する
    • うちの会社の関係者や知人に声をかけてクローズドなイベントを1回/年でやる
      • (当面は) bizpy ではやらないかなぁ

その後、解散してはらさんを神戸空港まで送っていった。空港の場所は知っていたけど、実際に行ったことなかったので車で空港への行き方がわかってよかった。これで飛行機で神戸に来る人がいても送迎ができる。18時半にレンタカーを返却した。今回は日産 NOTE e-Power というハイブリッド車を初めて運転した。今回の旅程で約350km走って消費したガソリンは約15リットルだった。燃費は23.3/リットルだった。レンタカーを返して家に着いたらやり終えたなって感じで気分がよかった。

ストレッチ

いつもは土曜日の10時に通っているストレッチを、ワーケーションがあったので日曜日の19時半に変更してもらっていた。温泉に入った後に多少はストレッチをしたものの、運転疲れで体が硬くなってしまっていた。今日の開脚幅は開始前155cmで、ストレッチ後160cmだった。ワーケーションへ行ってきて疲れた後にストレッチを受けられるのは、疲弊した箇所がわかってとてもよかった。外湯に入るために普段より歩いたのものあって腰とふくらはぎの張りが強かった。その上で座椅子や車の運転なども相乗効果があって疲れが溜まっていた感じ。トレーナーさんと旅のふりかえりを雑談しながらストレッチを受けていて、週末どこかへ行ってきた後にストレッチを受けるのはすごくいいと思ってしまった。この場合、私の中ではストレッチがマッサージに置き換わってしまっている。

法人決算をほぼ完了

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

ストレッチ

今日の開脚幅は開始前160cmで、ストレッチ後162cmだった。先週とほぼ変わらないので現状維持といったところ。右腰に張りがあって今週は椅子に座って後ろに寄りかかっていてもやや右腰が張るなぁと自覚症状もあった。ストレッチを受けていても効くなぁって感じだった。新しいトレーナーさんに代わってから1ヶ月のストレッチを受けてだいぶ打ち解けた感はある。

法人決算をほぼ完了

法人決算の e-tax 申請 の続き。前に消費税の申告をしたときに別表五以外はすべて作成していた。別表五はどこに何の数字を入力するのかが難しくて、過去の書類と数字を見返しながらやらないと詳細を覚えていなかったりする。その作業をするのが面倒でずっと先送りしていた。本気出してやれば1-2時間もあれば完了した。なんやらかんやらで eltax も e-tax の電子申告も自分でできるようになった。できることが増えていくことそのものが楽しい。

今回の法人決算で申告・申請したのは次の3つ。

e-tax の画面は基本的に帳票そのものなので数値を入力した後で紙に印刷することで帳票を保管することもできる。例えば、法人税・地方法人税の申告に必要な帳票がこれらになる。過去2年は手書きで作成していたけど、ほぼ同じの内容を画面で作成してデータで送付するだけの違いしかない。紙なら2時間で終えられる作業を、(使いにくい) アプリケーションの画面で入力すると余分に数時間かかってしまうものの、システムだと差し引きや合計値の計算は自動でやってくれるので記入ミスは起こりにくい。とはいえ、システムの自動計算が間違っていることもあるので強制入力が必要になるときもある。

税務署へ電話で問い合わせたときに財務諸表を pdf 添付でよいと話していたけど、いざやろうとしたら財務諸表は xml または xbrl 形式でないとダメだと説明が出てきた。仕方ないので月曜日に税務署へ行って紙で提出してくる。電子申告と紙を組み合わせて法人決算やることは構わないとのこと。

はっくばーに行ってきた

4時に寝て8時に起きた。昨日は遅くまで資料作りをしていてやや眠い。

ストレッチ

トレーナーさんが代わってから3週目。だいぶ新しいトレーナーさんのストレッチにも慣れてきた。7割ぐらいは同じストレッチだけど、3割ぐらいは似て非なるもので指圧の掛け方や伸ばしている部位が微妙に違う。あとやり方も違う。トレーナーさんが代わったばかりのときはその微妙の違いに耐性がなくて調子が出なかったけど、少しずつ慣れてきたみたい。今日の開脚幅は開始前160cmで、ストレッチ後163cmだった。腰も右股関節もそれほど悪い状態でもなかった。トレーナーさんが言うには肩甲骨と骨盤周りがあまりよくないといった話だった。3月ぐらいから怠惰な日々が続いているのでそろそろ運動やストレッチも再開したい。

jjug のビデオ録画

昨日の続き。資料はできたのでその発表ビデオを撮らないといけない。イベントで発表するのにビデオを提出するのは私にとって初めての試み。まずビデオを撮ったことがないのでツールの使い方から分からない。リハーサルをやぎさんに手伝ってもらって Windows マシンで試しにやってみた。感謝。Windows の標準機能だとゲームバーという録画ツールが使える。ショートカットは Windows キー + G で起動する。ゲームのプレイ動画などを録画して sns にアップロードするようなツールみたい。撮ってみたら録画時間は21分だった。発表時間は15分なのでここから6分削ればよい。

はっくばー

近所にはっくばーが出来たのでそのプレオープンイベントに行ってきた。内装は普通のバーで4人席が4卓、カウンター席が5席ぐらいかな。こじんまりとした可もなく不可もなくな装いだった。2時間弱ほどいてビールとレモンサワーを飲んで支払いは2,000円だったので料金は普通と言えるだろう。プレオープンだからなんかイベント的なことやるのかな?と期待して行ったんだけど、とくに何もなくて、参加者同士がお酒を飲みながらわいわい話すだけのイベントだった。オーナーが挨拶するといったこともなかったし、どういった展望をもってはっくばーをやっているのかもわからなかった。参加者の中にはオーナーやその所属組織の関係者のコネで来ましたという人もちらほらいたので、どこかしらの技術コミュニティで盛り上がっているのかもしれない。

私は7人の参加者と話した。相対的に若い人が多かったようにみえた。youtuberのサロンでプログラミング勉強してますというフリーターの人とか、ベンチャー企業やってますみたいな人とか、普通の会社員の人とか、マイクロソフト社にお勤めの人とか、大学生でプログラミングの勉強してますとか、いろんな人がいて、話しを聞いてみて、私が普段関わっている業界の内容ではなかったのでそれはそれで楽しかった。若い人たちは twitter をフォローしてくださいと qr コードで相互フォローをお願いしていた。twitter に qr コードを表示する機能があったんだと初めて知った。しかし、私だけ鉄の意志でやらなかった。スマホに twitter アプリ入れてないし。私が普段参加している 三宮.dev というコミュニティがある。少し前にそこに参加された方がたまたまその場にいて、少し話してみて、その人は技術の話しをしたいのではなく、インフルエンサーになりたい人なんだなと感じた。twitter のフォロワーを集めるためにイベントやコミュニティに参加しているようにみえた。別にそれも悪いことではないけれど。

あと、たまたま私が話した人がそうだっただけかもしれないが、あるベンチャー企業の社長が2つの目的、仕事をもらうのと採用のためにここに来てますと話していて、それ自体は悪くないと思うのだけど、そういう人が来るところに私は行かないなと率直に感じた。プレオープンイベントに参加した雰囲気だと、異業種交流会のような性格が強かった。オーナーの関係者で〇〇の会社をやっていて協業できれば嬉しいですみたいな紹介があったりしたし、卓を囲む人同士で名刺交換しているのもみかけた。バーというのはそういう特性もあわせもっているのかもしれないけど、コミュニティではないなという印象を受けた。

神戸に IT 系の有名な会社やコミュニティはないよねというのは、私も感じている共通認識で、はっくばーがそういったコミュニティの役割になればいいんじゃないかと話す人もいた。一方で私はそうはならないだろうと思っている。相互協力のコミュニティというのはもちろん存在するけど、それはどちらかというとそうせざるを得ない事情があって成り立つ。神戸はまだまだ余裕のある都市なのでそんな様相にはならない。じゃあ、コミュニティはなにをもって形成されるかというとコンテンツ (そして、その先にある文化) だと私は考えている。コンテンツのないコミュニティに人は集まらない。

はっくばーが今後どういった活動をしていくのかはわからないけど、単なるビジネス出会い系の場だとしたら三ノ宮みたいな地方都市ではなく、東京や大阪のような大都市でやった方がうまくいく可能性は高いだろうと思う。東京の Hackers Bar がうまくいっているかどうかは知らないけど、東京ですらうまくいくかどうかわからないものを三ノ宮で成功させるのは難しいだろうという印象を私はもっている。