docker compose に期待しない

0時に寝て5時に起きて7時に起きた。起きたら冷やしたのかお腹痛かったが、まぁまぁ眠れたと思う。

テスト環境の構築

GitLab CI/CD にだいぶ慣れてきてジョブを追加したり改善したりしながらようやくアプリケーションの docker image もコンテナレジストリに push されるようになった。それを pull してきて、テスト環境を docker compose で構築する。Use Compose in production とドキュメントでは威勢がよいが、これが全然イケてない。複数の compose.yml で項目によっては変更したいところを置き換えるといった振る舞いになっていない。例えば、ポート番号などを dev と prod で置き換えたいといった運用の要件を考える。

  • dev.yml
services:
  myapp:
    ports:
      - 18080:8080
  • prod.yml
services:
  myapp:
    ports:
      - 8080:8080

これを次のように指定すると、

$ docker compose -f dev.yml -f prod.yml up -d

実際のサービスは次のように振る舞う。全然あかん。

services:
  myapp:
    ports:
      - 18080:8080
      - 8080:8080

他にもそれぞれの yml ファイルで読み込む environment file のマージなどもよくわからない振る舞いをしていて複数の compose.yml で制御するのは断念した。dry の原則に反して設定は重複するけど、それぞれの環境を個別に compose.yml として管理した方が保守コストは小さくなると私は判断した。複数の compose.yml の使い分けのデバッグを1-2日やった後に諦めてテスト環境の構築は完了した。

年金事務所の住所変更手続き

先週 法務局で法人登記の変更申請 をしていて、そのときに問題がなければ今日から登記事項証明書を取得できると案内をもらっていた。決定書が漏れていて再提出というトラブルはあったものの、最小限の損失で留めたせいか、問題なく登記事項証明書を発行できた。住所の変更だけわかればよいので履歴事項証明書ではなく現在事項証明書を発行してみた。この書類もおもしろくて1つ前の住所といまの住所の2つを確認できる。法務局へ行った帰りに年金事務所へ立ち寄って社会保険の住所変更の手続きを行った。次の3つの書類をもって窓口へ。

  • 登記事項証明書: 番地まで記載されている
  • オフィスの一時使用契約書: ビル名はあるがこのビル名は来月に改名
  • ビル名変更の証明書類: ビル名の変更のみが記載されている

この3つの書類で完全に指定された住所 (Fully Qualified Address: 造語) を丁寧に説明したところ担当者に納得してもらえて事なきを得た。

休日のオンライン学習

0時に寝て夜中に吐き気がして2回ほど起きて3時と5時に起きて8時に起きた。なかなか苦しい寝方をした。

ヤフートラベルと一休.comのシステム統合

アーカイブ公開されたらみようと思いつつ忘れてたので見返した。

雑なめも。また機をみて見返すこともあるかも。

  • バックエンドは完全に一休側に寄せるという大きな意志決定を2016年に行った
    • この意志決定はフロントエンド統合にも大きな影響を与えた
    • ふじもんさんの意志決定がよかった?
  • 今日の話しはマルチブランドデザインシステム統合がメイン
    • 開発者が50-60人程度で半年ぐらいで launch できた
    • nuxt/vuejs で開発している
    • スタイルは tailwindcss を使っている
    • 実は launch した後にこのシステムが必要だとわかった
      • 開発者とデザイナー間の細かい意思疎通が困難
      • 外部からデザインシステムに詳しい人にも来てもらっていろんな議論をした
      • ガイドラインを言語化するところから始め、最終的にソースコードの共有ができるようになった
    • 終わってからデザインシステムそのものは重要ではないと気付いた
      • この過程で開発者とデザイナー間のどのように共通化するか、あるいはしないかと議論を繰り返し行ったことが重要だったと当事者がインタビューで語っていた
      • デザインシステムの開発を通じてデザインの共通認識をもてたことがよかった
  • 波及効果
    • 同じソースコードから少し異なる体験の開発のノウハウができた
    • ふるさと納税に特化した宿泊予約サイトを作った
  • 統合は終わりではない、lauch したところが始まり
    • 統合後にいろいろな施策をすることで課題がみえてくることがある
  • 全国旅行支援は1つの開発で2つの体験をつくることができた
  • Q. デザイナーと開発者はわりと仲が悪いのでは?価値観や考え方が異なるのですり合わせるのは難しいのでは?
    • 過去の一休でも起きていた
    • 一休のチームはデザイナーと PM と開発者で構成されている
      • このチームが一緒に働いていてチームでなるべく意志決定している
      • 普段から一緒に働いていると仲が悪いということはなかった
      • とはいえ、仕事のプロセスが異なるので課題はあった
        • 地道に丁寧にすり合わせを行った
        • 外部から講師を読んで中立的な立場でワークショップを何度も行った
    • デザイナーと開発者を別の組織にしているとコミュニケーションの壁ができてしまうかもしれない

go の学び直し

テストの学び直し に引き続き、Gopher塾 #2 - Goらしいコードの書き方 - DAY 1 に参加した。

テストの次のプログラミングの話しだったので内容そのものは難しくはなかったけど、改めて重要な項目を選抜しているのだと考えると学びはあったと思う。参考になったことをいくつか覚えている範囲でまとめる。名前の付け方について感覚的に理解していたし、実際に私はそうしているけど、コードレビューしていて自然になっていないコードを指摘する機会も多いので一定の習熟を要するのかもしれない。いま毎週勉強会をやっていて私が講師として話している。ネタがなくなってきたり大変になったきたら準備の少ないコードリーディング会もやってみたいと思った。

  • google Go Style
  • derrors.Wrap
  • 名前に文脈を与えるという概念
    • 相対的な名前をつける
  • 準備の少ないコードリーディング会
    • お題(読むパッケージ)を決める
    • 選んだお題に期待することを当日話す
    • 時間を決めてみんなでそれぞれ読む(20分とか)
    • 読みながらSlackのスレッドにメモをしていく
    • 残りの時間で気になったところを議論する
    • 自分が気づけなかった点を知ることができる

openapi-ext-tools をまた使う日がきた

0時に寝て4時に起きて7時に起きた。わりとよく眠れた。

ストレッチ

トレーナーさんと月曜日の日本対クロアチア戦の感想を話したりしていた。今日の開脚幅は開始前153cmで、ストレッチ後156cmだった。先週は疲弊と疲労で散々な数値になっていたものが復調してきつつある。今週も毎日8-22時はオフィスで缶詰め状態だった。たくさん座っている (同じ体勢でいる) 時間が増えると筋肉にはよくない。まだまだ右腰と右太もも周りの張りは強く復調にはもう少し時間がかかるようにみえる。一方で忙しさのピークを越したと思うので今週以降は少しペースダウンしながら体作りをしていく。いまお手伝いしている開発は12月にすべての集中力を費やしてもよいと考えている。残りは期間はメンバーに委譲するような体制になるとベストかもしれない。そのための体力づくりは重要。

openapi-ext-tools 再び

github pages ならぬ gitlab pages がある。ふと web api のドキュメントを作るために openapi のスキーマを定義したら gitlab の ci/cd と連携できていいんじゃないかと思い付いた。スキーマがあればフロントエンドのクライアント生成や e2e テストコードの自動生成などに使えるかもしれないし。過去に作った openapi-ext-tools を oss にしておいたからいまも使える。oss 万歳。先のことはわからない。redoc を使ってちゃっちゃと実装した。

pages:
  only:
    changes:
      - schema/*
  stage: deploy
  image: alpine:latest
  before_script:
    - apk --no-cache add python3 nodejs npm
    - python --version
    - python -m ensurepip
    - pip3 --version
    - node --version
    - npm --version
    - npm install --global redoc-cli
    - redoc-cli --version
    - pip3 install openapi-ext-tools
    - pip3 freeze openapi-ext-tools | grep openapi
  script:
    - openapi-spec-cli --spec-path schema/openapi.yml
    - |+
      redoc-cli bundle bundled_openapi.yaml \
        --output index.html \
        --options.expandResponses=all \
        --options.requiredPropsFirst=true \
        --options.jsonSampleExpandLevel=10 \
        --options.hideLoading=true \
        --options.pathInMiddlePanel=true      
    - mkdir -p public
    - mv index.html public/
  artifacts:
    paths:
      - public

久しぶりに触ったら openapi-ext-tools が依存ライブラリの変更で動かなくなっていたので直した。

3年目の創立記念日

0時に寝て何度か起きて7時に起きた。金曜日は普通の週でも疲れているが、今週はハードだったからさらにバテバテ。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。オフィス移転に伴う諸々を雑談したり、おもには夕方から講師をしてもらうフロントエンド勉強会の最終確認のようなことをしていた。

フロントエンド勉強会

私がマネージャーとなって今月決めないといけない大きな意志決定の1つにフロントエンドの技術選定がある。とはいえ、私はフロントエンドに関して素人なのでなにかしら取っ掛かりがほしい。その参考の1つとして、はらさんにお願いして技術選定というテーマでフロントエンド勉強会を開催してもらった。感謝。いまお手伝い先では私が毎週チーム勉強会を行っている。これも1ヶ月以上続けている。そろそろ定着しつつあってチーム外からも毎週数人が参加してくれるようになってきた。勉強会という開発文化の取り組みとしてもちょうどよいように思ったのでお手伝い先も巻き込んで講師だけ社外の人が務める勉強会となった。結果は15人以上参加してくれて質疑応答も盛り上がってよかったと思う。

State of JS アンケート (ここは翻訳されたサイト) という、主にはフロントエンドの開発者の調査結果がある。これはフロントエンドの開発者のみのアンケートなので偏りはあるだろうというのも考慮しつつ、最近のトレンドを理解する上でよさそうに思えた。React をデファクトスタンダードとして、対抗する候補に Svelte のみを私は考えていたが、もう1つ Solid を加えてもよいのではないかとアンケート調査をみていて思うようになった。

私にとってもっとも参考になった技術選定の考え方としてリニューアルを前提にフロントエンドを作るというもの。技術選定で難しいことの1つは、いま流行っている技術が未来もそうかどうか誰にもわからない。未来に人気がなくなって保守されなくなって開発中止となり、フロントエンドの作り直しを強いられることを避けたいという心理や懸念は一般的だと思われる。その懸念を逆転の発想をもって、例えば、作ってから3年経ったら既存のフロントエンドはすべて捨てて作り直すと決めておけば多くの悩みは解消される。こういう言い方をすると多くのフロントエンド開発者は怒るかもしれない。私にとってはプロダクトのコアはバックエンドであってフロントエンドはそうではない。だからフロントエンドはそのときの流行りの技術で動けば何でもよいという考え方は納得感が高い。

創立記念日

今日が会社の創立記念日。無事に3周年を迎えた。いつか創立記念日をお休みにしたいが、未だそのときではない。

2年目は大きな失敗も経験して経営やキャリアの両方で反省する機会にもなった。その過程でうちの会社はなにをやるのかという基本方針とプロダクトの種のようなものができた。3年目はプロダクト開発の前段階としての実証実験のようなことを実際のお客さんの業務を通じて行っている。しかもそれがいま2社目。会社を作ったときに最初の10年間のステージを3つに分けた。そしてそのステージにおけるフェーズ1の終わりが近づいていて、目標としていたことも達成の見込みがたっている。うまくいけば来年の中旬以降から実証実験の結果を踏まえたプロダクト開発に移っていけるかもしれない。そうなればフェーズ2に移行する。起業してから3年経ってもありがたいことにお仕事はあるし応援してくれる人たちもいる。周りの人たちに恵まれていて感謝することも多い。過去の自分がやってきたことに自信をもっているからその人脈も継続できているし、少しずつ新しい関係性を作っていくことにも注意を払っている。あと何年働けるだろうかと考えることもしばしばある。もうそんなに長くないこともわかっているので悔いのないよう挑戦していきたい。

rabbitmq 再び

0時に寝て3時に起きて6時半に起きた。前日あまり寝てなかったから普段よりよく眠れた。

rabbitmq の認証

たまたまなのだけど、前のお仕事でも rabbitmq を使っていて、いまのお仕事でも rabbitmq を使っている。私の中では kafka のエコシステムに感銘を受けたので私が技術選定してよいなら kafka を使っていきたいところだけど、rabbitmq も人気があってすごいなと思う。インフラを触っていて rabbitmq の認証をしていないことに気付いた。rabbitmq の docker image を使うとデフォルトで guest/guest のユーザーが作られる。

If you wish to change the default username and password of guest / guest, you can do so with the RABBITMQ_DEFAULT_USER and RABBITMQ_DEFAULT_PASS environmental variables. These variables were available previously in the docker-specific entrypoint shell script but are now available in RabbitMQ directly.

おそらくメッセージのやり取りを通信するときも何も指定しなかったら guest ユーザーとして扱っているのかな?通信するときの RabbitMQ URI Specification によると、amqp://user:pass@host:10000/vhost のような、昔ながらの uri にユーザー/パスワードを埋め込むような認証になる。このやり方だと uri 自体が credentials になってしまって運用の使い勝手が悪くなってしまうものの、アプリケーションの変更は必要ないというメリットもある。おそらく歴史的に認証は後付けで追加されたのかな?ともかく実際の運用だとユーザー/パスワードでアクセス制御を行うだろうと想定されるので気付いたタイミングで開発環境の docker image の設定と uri の変更を行った。

時事ネタの気軽な雑談会

【おはなし会】CEXだって安全にできるもん に参加した。ちょうさんは fin-py のイベントで何度か発表を聞いたことがある。データサイエンス系のお仕事をされているのかな?ftx 事件 をうけて ethereum の創始者である vitalik buterin 氏がブログに投稿したアルゴリズムの解説をされていた。

取引所の不正を防ぐための仕組みとして、それぞれの口座の残高を公開しなくても merkle tree とハッシュ関数をうまく使って、取引所が実際に管理している残高とユーザーの残高が一致しているかをチェックできるような、そんなアルゴリズムだったと思う。ちゃんとブログの記事を読んでないけど、ちょうさんの解説を聞く分にはアルゴリズムはそう難しくないように思えた。そんなすごい仕組みじゃなくて、簡易的に大きな計算コストもなく全体の残高があっていることのおおよそのチェックはできますよといったもの。

イベントが始まる前にちょうさんが大学の研究室にいた頃、研究室へ行くと同僚がいて気軽に新しい技術の話しができたけど、社会人になるとそういう機会が減ってしまったという。時事ネタを気軽に雑談できるイベントがあればという話しをされていて私も共感できた。

gitlab の ci/cd 入門

0時に寝て3時に起きてそのまま眠れずにいたら6時になって7時過ぎから準備してオフィス行ってお仕事を始めた。

gitlab の ci/cd の調査

初めて GitLab CI/CD を触っている。まだ触り始めたばかりだが、感覚的には github actions 相当の機能はあるようにみえる。ソースコードリポジトリやパッケージリポジトリ/コンテナレジストリと ci/cd がセットになっているととても便利だ。これはすごいことだと最近思うようになってきた。もはやソースコードリポジトリのみのホスティングビジネスは成り立たない。なぜなら github や gitlab のような ci/cd が当たり前になってしまうと、その機能がない場合、デメリットを上回るメリットがないとそんなソースコードリポジトリを選択しない。

docker image をビルドして push する仕組みは既にメンバーが作ってくれていたのでその後始末の処理を作った。Container Registry API を使うと、不要な docker image を削除できる。

削除向けに便利な api 設計になっている。こういう細かい配慮は嬉しい。keep_n で最低限残すイメージ数を指定して older_than で過去何日より古いイメージを削除対象とするといったよくある運用の設定ができる。

curl -s -H "PRIVATE-TOKEN: $PROJECT_ACCESS_TOKEN" -X DELETE "${endpoint}" \
  --data "name_regex_delete=.*" \
  --data "keep_n=${KEEP_N}" \
  --data "older_than=${OLDER_THAN}"

あとは認証のトークンを指定する方法として私が調べた限りだと2通りある。

  • (ci_job_token_scope の feature flag を有効にして) $CI_JOB_TOKEN を使う
    • こっちの方が一時トークンなのでよりセキュアなはず
    • この場合はヘッダーに JOB-TOKEN を指定する
  • プロジェクトレベルのアクセストークン を発行して ci/cd の variables に登録する
    • トークンが漏洩したときにプロジェクトレベルで被害が発生する
    • この場合はヘッダーに PRIVATE-TOKEN を指定する

使うトークンによってヘッダーが変わるというのがちょっと変な認証の設計にもみえるけど、まぁそれぐらいしか気にはならない。

echo のよさの1つはテストがやりやすい

にわかサッカーファンになって、20時頃に1-2時間寝て24時からワールドカップのクロアチア戦をみて3時に寝て8時に起きた。睡眠のリズムが完全に狂ってしまった。

echo のテストのやりやすさ

うちのチームでは http フレームワークに echo を採用 している。その後、開発を継続していていくつか http ハンドラーも実装されてきた。そろそろ http ハンドラーのテストを書いていこうと参照実装を私が書いてみた。メンバーが知らないことは、マネージャーの私が参照実装して教えるといったやり方をしている。echo.HandlerFunc に echo.Context を渡すシンプルなインターフェースはテストを書くときに http ハンドラー以外の依存関係 (例えば db とのコネクションなど) を context を介することでモックと差し替えるのが容易になる。

tests := []struct {
	name    string
	ctx     echo.Context
	err     *echo.HTTPError
} {
    ...
	func() echo.Context {
		data := `{...}`
		c := newEchoContext(http.MethodPost, "/endpoint", data)
		c.Set("db", &myMockDB{})
		return c
	}(),
    ...
}

if err := myHTTPHandler(ctx); err != nil {
    ...
}

こんな感じで context にモックを入れてしまえば http ハンドラーそのものの単体テストを簡単に書ける。そんなことをツィートした。

そしたら podhmo からレスをもらったので go のリクエストコンテキストの扱いについても議論した。

  • リクエストスコープのものを context に入れるのは同意
  • それ以外のスコープのものを context に入れるのは懸念がある
    • http ハンドラーのレイヤーとアプリケーションのレイヤーが明確に分かれているならまだ理解できる
    • アプリケーションのレイヤーで context を自由に使うと依存関係や統制が取れなくなる
      • これは私も同意するところでアプリケーションのレイヤーにリクエストコンテキストを渡す必要はない

オフィス住所の更新

引き続き、住所変更の手続きを時間をみつけてやっている。同じ銀行の住所変更の手続きでも PayPay 銀行と三菱 UFJ 銀行ではまったく異なる。前者はオンラインでアカウント情報を変更するだけで済んだ。簡単。一方で後者はオンラインではできず、来店予約をとって対面で行う。当日に登記事項証明書の原本をもってこいと。なんという面倒臭さ。よくよく考えたら法人の登記事項証明書は誰でも取得できる。行政のシステムがどうなっているか知らないが、銀行が法人の住所変更を自分たちで調べることもやろうと思えばできるはず。登記事項証明書をオンラインで取得する手数料は500円になる。来店予約すると応対する人の人件費を考えたらシステムの手数料を支払った方が安いのではないか。

国税庁の管轄ではあるが、国税庁法人番号公表サイト から法人の住所変更そのものは確認できる。これは e-tax で次の2つの書類を申請した。登記事項証明書がなくても申請はできた。なにも言ってこなければ問題ないのかな?

  • 異動届
  • 給与支払事務所等の開設・移転・廃止の届出

有償にはなるが 登記情報提供サービス というのがあって登記情報をオンラインで確認できる。このサービスを会社で契約していればいつでも確認できるはず?

法人登記変更申請にもの思い

4時に寝て8時に起きた。3時過ぎまでオフィスの片付けなどをやっていた。貧乏暇なし。

年金事務所でヒアリング

8時半から住所変更のために年金事務所に立ち寄る。会社の住所変更をすると行政機関にその申請をしないといけないが、年金事務所がもっとも短くて移転後5日以内となっている。行ってみたら登記事項証明書のコピーがないと手続きをできないという。すべてに先立って法人登記の変更申請が必要なことがわかった。法人登記の変更申請に1週間かかるのでその時点でこの手続きは無理だとわかった。行政のバグの1つかもしれない。

法務局で法人登記の変更申請

以前、電子公告の変更で法人登記の変更申請をやったことがあったので手続きの雰囲気を理解していた。お昼休みを兼ねて法務局へ住所変更の申請に行く。合同会社の法人登記の変更申請は次のリンクにある。

しかし、このリンクを辿ると、3つの記載例がある。

3-4 合同会社変更登記申請書(商号の変更及び目的の変更)【R4.11.11更新】

3-5 合同会社本店移転登記申請書(管轄内移転)【R4.9.20更新】

3-6 合同会社本店移転登記申請書(管轄外移転)【R4.9.20更新】

ここで私が慌てていて 3-4 の「商号の変更及び目的の変更」の記載例しか目に入ってなくてその内容を確認して申請書類を作って提出してきた。後日、担当者から決定書が必要ですと電話がかかってきた。私が参考にしないといけない記載例は 3-5 の「管轄内移転」の方だった。たしかにその書類には決定書が含まれていた。3-4 にはそれが不要だったので申請書類から漏れた。後日、決定書を再作成して法務局へ再申請に行ってきた。申請自体は15分もあれば終わる作業だけど、1度で終わらせる手続きを済ませられなかったという自分の不甲斐なさにショックを受けた。余裕をもって周りの観察が大事という話し。

初めての会社のオフィス移転で学ぶことも多かった。申請には「原因年月日」を記述できるので予め前もって登記変更の申請を行うことはできないのだろうか?移転後2週間以内に申請する必要があると書かれた記事を読んでいたので私は引っ越し後にしか申請できないと思い込んでいた。

また定款の記載内容によってはオフィス移転で定款変更も必要になる可能性がある。定款の変更には同意書が必要なため、さらに申請書類が増える。うちの会社の定款の条項は次になる。

(本店所在地) 第3条 当会社は、本店を神戸市に置く。

定款の本店所在地は市町村まで構わない。神戸市内で引っ越しする分にはうちの会社は定款変更を必要としない。おそらく会社を設立するときにオフィスがまだ決まっていなかったからそうしたのかもしれない。私が意図して定款の本店所在地を決めたわけではない気もする。freee 経由で定款作成代理人がよしなに作ってくれたようだ。感謝。

さらにたまたま申請する直前にオフィスの掲示板で来月からビル名が変わりますという掲示をみつけた。登記変更の申請を知らない人向けにこの手続きはどんな内容であろうが申請に手数料が3万円かかる。ビル名が変わったらその都度3万円支払う必要がある。少し調べてみると、新しいオフィスのビル名が変わるのは3度目でどうもそういう傾向のあるビルにみえる。これは4度目もありそうだ。登記の住所についてさらに調べてみると、法律上は番地まで記載すればよくてビル名を登記に含める義務はないという。今回の登記変更の申請にはビル名を含めず番地までとした。これで未来に4度目のビル名の変更があっても登記変更を申請しなくて済む。たまたま申請前にオフィスの掲示板を眺めて気付いたことで登記の住所の仕様を学ぶことができた。周りの観察は大事という話し。

掃除は respect を表現している

掃除は respect を表現している

22時に寝て1時に起きて吐き気がして苦しんでた。その後、寝て1度起きて7時半に起きた。寒くなってきたせいか、疲労のせいか、なんとなく体調が悪い。今日も掃除したり荷解きの片付けやったりしていた。

退去するオフィスの掃除

ワールドカップが盛り上がっているので関連するニュースを読んでいるうちにサポーターだけじゃなく、選手もロッカールームをきれいに掃除して退出しているニュースをみかけた。

日本では小学校の頃から自分たちの活動の場を自分たちで掃除するという習慣が当たり前のように教育されている。その延長で自分たちが使った場所は掃除して帰るといった価値観が一般的に定着しているように思う。掃除するお仕事を奪っているという批判も、掃除はボランティアがやっている、ボランティアと言っても有償ではある、有償といっても歩合制でお金をもらっているわけではないでしょうとか。さまざまな意見がある。批判を認めないわけではないが、私も掃除をすることは正義の1つだと最近思うようになってきた。12月3日に引っ越しするのに12月4日 (予備日) まで借りていた理由はとくになかったのだけど、オフィスを掃除するためだったんだなと後付けの理由ができた。朝から掃除機をオフィスへ運んで掃除してきた。

This isn’t just a clean dressing room, it’s a clear demonstration of values.

It’s a statement about respect, gratitude and attention to detail.

The small things are the biggest indicator of the big things - your values.

https://www.linkedin.com/posts/stevenbartlett-123_this-is-how-the-japanese-mens-team-left-activity-7001499750009044992-qpeU/

たまたまねとらぼの記事を読んだ後に linkedin の投稿もみかけた。日本人は掃除に respect なんか感じたことはないかもしれないけど、外からみるとそういった振る舞いの1つにみえるんだという気付きにはなった。やっぱり掃除は正義やね。

オフィスの引っ越し

3時に寝て8時に起きた。疲労困憊だけど、今日を乗り切ればよい。9時から荷造りの続き。昨日の深夜に大半の荷造りを終えていたので2時間ほどで終えて軽く掃除したりしていた。

引っ越し

14時から レントラ便 さんにお願いしていた。13時25分にレントラ便の担当者から電話がかかってきてオフィスに到着したとのこと。私もすでに準備出来ていたのですぐやりましょうということで搬出作業が始まった。作業員として1名しかお願いしてなかったが、先方の担当者は2名いたので荷物の搬出がその分楽になった。だいたい30分ぐらいで搬出作業が終わった。新しいオフィスに移動して14時から搬入作業を開始した。搬入作業はだいたい20分ぐらいで終わった。出すよりも入れる方が速かったのは、バンに荷物を積み込むときにスペース効率を考えながら配置する必要がないからだろう。時間に余裕があったので追加で新しいオフィスにある椅子を保管するために家まで運んでもらった。オフィスの椅子はアーロンチェアを使っているので備え付けの椅子はいらない。それが終わったのが14時25分だった。そこで事務手続きして完了とした。荷物の移動も含めて約1時間で引っ越し作業を終えた。本当は14-16時で依頼していたが、早く始めて想定したよりも早く完了していいこと尽くめだった。また次回があればレントラ便さんにしようと思う。その後、荷解きしながらぼちぼち片付けをしていた。

ストレッチ

19時半からストレッチ。先週の田んぼ作業 でスクワットに近い運動をたくさんやったので月曜日や火曜日はひどい筋肉痛になっていた。水曜日以降はましになったが、若干の違和感も残っていた。今日の開脚幅は開始前144cmで、ストレッチ後150cmだった。疲労と筋肉痛でまったくいつも通りにはいかなかった。お腹つったり足裏つったりしてた。トレーナーさんが言うには筋肉痛のときは普段のストレッチをあまりやるよりも筋肉をほぐすようなストレッチをした方が早く回復するみたいな話しをされていた気がする。あとはワールドカップの話などをしていた。

クリーンアーキテクチャを勉強し直したい

0時に寝て5時前に起きたらサッカーやってて最後の10分ほどみた。まさかスペインに勝つと思ってなかったから驚いた。

アーキテクチャと設計

退職したメンバー がドメイン駆動開発 (DDD) とクリーンアーキテクチャから既存のアーキテクチャを構成したというドキュメントを残してくれた。そのドキュメントを読みながら、説明の粗いところや足りないところを私が補って加筆し、既存のコードを読みながら誤っているところなどをリファクタリングしたりしていた。あとアーキテクチャや設計のドキュメントを書く上で図がないのはよくない。現代の開発は分割統治の概念で設計されていて、そこで扱う本質的複雑さは依存関係になる。誤解を恐れずに言えば、現代の開発のアーキテクチャは依存関係をどう管理するかの基本的な考え方に過ぎない。依存関係の向きが分かるので図があった方が圧倒的にわかりやすい。一方で私自身もクリーンアーキテクチャにそう明るくない。もう少し勉強し直す必要があることは感じた。クリーンアーキテクチャ勉強会もやっていいようにも思う。

課題管理 + イテレーション開発とスクラム開発の勉強会

今週ずっと朝起きたら2-3時間かけて資料を作り続けてきた。前回は時間が余ったので今回は余らないよう、最終的には43枚のスライドになった。

  • スクラム事前知識
  • スクラムガイド
  • 課題管理+イテレーション開発とスクラム開発との比較
  • スクラムマスター
  • 会議体とツール
  • 分析・計測
  • スクラムの是非
  • まとめ

話してみたら1時間を10分ほどオーバーした。勉強会で1時間話すネタを調整をするのは難しい。毎月出張でオフィスへ行くときは課題管理に関する勉強会を行う。課題管理や開発方法論の話しを聞いてくれる人たちがいるというだけでありがたい。5日前から準備を始めて資料作りの時間が少なかったので細部の調査はあまりできていないし、構成も荒くて練れていない。もう2-3ヶ月かけて細部の調査や理論武装をしたらよいコンテンツになるかもしれない。イテレーション開発とスクラム開発を比較するときの叩き台として寝かしておく。

オフィスの引越しの荷造り

神戸に戻ってきて一旦家に帰って晩ご飯を食べて一息ついて、23時過ぎから引越しのための荷造りを始めた。大きい家電や電子機器は購入時の箱を置いておくと引越しのときの荷造りが楽になる。言うても一部屋の荷物なんで本気出せばすぐ終わる程度の量。3時間ほど荷造りやって8割ぐらいできたところで今日の作業は終えた。出張と移動で疲労は積み重なってきた。