Posts for: #Founding

仕事始め

#founding  #scrum  #iterative and incremental development 

0時に寝て8時に起きた。夜に吐き気がしてやや苦しんだ。実家だと吐き気はなかったので寝方の問題なんやろか。今日からオフィスに出てお仕事を再開する。

名刺の発注

オフィスの住所を変更したので名刺を作り直さないといけない。オフィスの引っ越し作業の最後のタスクになる。名刺を配る機会そのものがないので優先度はかなり低いのだけど、一連の引っ越しタスクの親タスクを完了できないのも気持ち悪いので年末にやろうと考えていた。それが葬儀でなおざりになっていた。名刺データは Adobe Illustrator で管理されていて、その ai ファイルから編集した svg ファイルがある。この svg ファイルを inkscape というアプリケーションで読み込んでオフィスの住所が書かれたテキスト編集を行う。元データは有償フォントだったけれど、自分で編集できるよう、フォントも身近な M+ FONTS に置き換えている。

M+ FONTS のインストール方法。

$ unxz mplus-TESTFLIGHT-063a.tar.xz
$ tar xvf mplus-TESTFLIGHT-063a.tar
$ sudo mkdir /usr/share/fonts/truetype/mplus
$ sudo mv mplus-TESTFLIGHT-063a/*.ttf /usr/share/fonts/truetype/mplus/
$ fc-cache --verbose

ubuntu だったら inkscape は apt からインストールできる。

$ sudo apt install inkscape

inkspace で元の svg ファイルを読み込み、Ctrl + Shift + T でテキスト部分を編集して保存する。最後に次のバッチコマンドで svg を pdf に変換する。

$ inkscape --file=my-biz-card.svg --export-area-drawing --without-gui --export-pdf=my-biz-card.pdf

この pdf データを使って パプリ というサービスで名刺を発注した。

ビッグテックの技術系プロジェクトのマネジメント方法と興味深いスクラムの不採用

9月からずっと積ん読していて、本当は12月の課題管理勉強会で取り上げようと読み始めたものの、記事の文量が多いのでちゃんと精読してこれだけで1つの勉強会できそうと途中で読むのをやめて、1月の課題管理勉強会へと先送りしていた。

ローカルで deepl で機械翻訳しながらおかしな翻訳のところだけ精読して直したりしている。それでも数時間程度はかかった。すべて翻訳してからざっと読み返してみると、それほど特徴的なことを言っているわけでもなくて、もともと自分が知っていた内容にいくつか補足や背景があるといったものだった。記事の切り口が「ビッグテックはスクラムやってない」というキャッチャーなタイトルから掘り下げていて、もちろんビッグテックと他の企業との違い、そういう傾向がある背景も解説しているし、著者の経験や主観も展開されていておもしろい考察ではある。私もずっとスクラムよりもイテレーション開発の方がコミュニケーションコストが低い分、自由度が高くて開発者がオーナーシップや主導権を取りやすかったり、その結果として生産性を向上させられるといったことを考えていた。その自説を論理武装する内容もいくつか書いてあった。私にとって今後のコンテンツを書くときに役に立つ記事であることは間違いがない。これから勉強会の資料も作る。

全体を通しての要項をツィートにまとめてみた。

svelte のチュートリアルで学ぶ

#founding  #government  #svelte 

22時頃から寝てたものの、また2時頃に吐き気で苦しんで何度か起きて7時過ぎに起きた。なかなか体調が悪い。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今週はてんやわんやで議題を整理する余裕すらなかったので近況を軽く共有した。

課題管理を it 業界や開発プロジェクトだけでなく、もっと様々な分野や業界で応用できるようにしたい。最初は私がノウハウをもっている業界や業務のみに特化したものになるだろうけど、いずれはスコープを拡げていきたい。その先に 地域おこし協力隊 のようなところにいって社会貢献ができればおもしろいのではないかといった話しをした。地域おこし協力隊の内容はおもしろそうだけど、1人あたりの経費の上限が480万円に設定されていて、ググって調べると余裕のない自治体では満額支給されていないケースもあるみたい。行政がやらないといけない業務をアウトソーシングする予算が低過ぎて、適切な実績やスキルをもった人が経済的に参加しにくい状況にある。採用の目利きができないから単価を低くして失敗を許容しやすくなっているようにもみえる。行政の予算が低い問題は専門家が入って採用も含めて改善していく必要がある。

svelte 入門

昨日の続きで svelte のチュートリアル を始めた。このチュートリアルはファイル操作とオンラインエディタもついていて、ソースコードを変更するとすぐビルドされて結果も確認できる。フロントエンドのチュートリアル自体がフロントエンド技術のデモになっている。よく作られているよなと感心しながら取り組んでいる。svelte でスクリプトを書くときの、マジックコード的な変な構文がある。simple is not easy の文脈で言うところの easy であり、私のような simple 派からみるとやや気持ち悪い。わりと分量があるので途中にコードレビューや勉強会の講師をやっていたら1日では終わらなかった。

let count = 0;
$: doubled = count * 2;

<script>
  export let answer;
</script>

ケーブル配線トレー気に入った

#founding  #device  ケーブル配線トレー気に入った

20時に寝て22時に起きて、24時ぐらいまでだらだらやって6時まで寝た。本当は晩ご飯食べてオフィスに戻るつもりが疲れて寝てた。

ケーブル配線トレー

たいちさんの記事 を参考に購入した ケーブルトレー (CB-CT4) が届いたのですぐ机に取り付けてみた。ちょうど机のサイズやオフィスの空間にもマッチしていてケーブルの配線をよい感じに収納できた。新しいオフィスには幅広な棚がついていてその棚もそうなんだけど、縦の空間を分割して使えると効率がよい。普段プログラミングや ci/cd で効率のことばかり考えているから日常生活でも効率のよいことがあると嬉しい気持ちになる。ケーブルトレーはオフィス空間の効率化に寄与する。物理的なメリット以上に、私にとっては精神的に作用した気がする。

rabbitmq の management api

rabbitmq には Management Plugin という拡張があって、これをインストールすると管理画面と HTTP API が付いてくる。docker image だと、たぶん management のタグが付いているものを選べばよいと思う。exchange や queue の初期設定を go のアプリケーションからできるようにしようと思って rabbit-hole というライブラリを使ってすぐに実装できた。最低限の必要な機能をもつサブコマンドな cli からも呼べるようにした。本番環境でもこの cli を使って rabbitmq の初期設定や確認をする運用ツールにしようと思う。管理画面でもできるけど、cli でできた方がマニュアルを作る上でも簡単だし作業ログも管理しやすい。

eltax で異動届を申請してみた

#founding  #eltax 

0時に寝て5時に起きて7時に起きた。変哲のない普通の朝だった気がする。

三菱 UFJ 銀行の住所変更手続き

先週来店予約をとったので登記事項証明書をもって来店した。手続き自体はすんなりと進み10分で完了した。わざわざ対面で行うのは最早これセキュリティ。とりあえずセキュリティと言っておけば多少の不便さなんか吹っ飛ぶ。担当者が次の項目をチェックしていた。

  • 免許証の写真と同じ人物かどうか
  • 住所が書類とあっているかどうか
  • 通帳が正しいかどうか
  • 銀行の届け印が正しいかどうか

eltax の住所変更手続き

オフィスのプリンタを調べたらスキャナの機能もあることがわかった。夜に登記事項証明書をスキャナで取り込み pdf 変換できたのでそれを使って eltax で地方自治体 (県と市) の異動届も提出することにした。どうやら申請・届出は pc 版ではなく web 版を使うらしい。初めて行う申請だったので書類の在り処や段取りがわからなくて2時間ぐらいかかった。ざっくり次の手順でできる。

  1. 県向けに異動届を作成
    1. 登記事項証明書の pdf 添付
  2. 作成した異動届をマイナンバーカードを使った公的個人認証サービスで署名して送信
  3. eltax の利用者情報の変更届けを送信
    1. 住所が旧住所になっているので更新
    2. 県と市のどちらかを選択すると両方に通知される？
  4. 県向けに送付した異動届を複製
    1. 登記事項証明書の pdf 添付も複製される
  5. 同じ異動届を使って市向けに作成
  6. 作成した異動届をマイナンバーカードを使った公的個人認証サービスで署名して送信
  7. メッセージ照会や受付状況照会で内容を確認

翌日には受付状況照会で手続きを完了したというステータスになっていたので問題はなかったみたい。同じ異動届を複製できたのが便利だった。

docker compose に期待しない

#gitlab  #docker  #infrastructure  #founding 

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: 造語) を丁寧に説明したところ担当者に納得してもらえて事なきを得た。

3年目の創立記念日

#founding  #event  #frontend  #tech selection 

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

隔週の雑談

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

フロントエンド勉強会

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

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

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

創立記念日

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

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

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

#go  #founding 

にわかサッカーファンになって、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つの書類を申請した。登記事項証明書がなくても申請はできた。なにも言ってこなければ問題ないのかな？

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

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

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

#founding  #government 

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度目のビル名の変更があっても登記変更を申請しなくて済む。たまたま申請前にオフィスの掲示板を眺めて気付いたことで登記の住所の仕様を学ぶことができた。周りの観察は大事という話し。

オフィスの引っ越し

#founding  #life 

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

引っ越し

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

ストレッチ

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

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

#design  #iterative and incremental development  #scrum  #founding 

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

アーキテクチャと設計

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

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

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

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

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

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

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

寝ることとお仕事の選び方

#life  #founding  #jira  #issue tracking system 

20時過ぎに寝て0時に起きて、何度か寝たり起きたりしながら7時に起きた。神戸マラソン のスタート地点が近所なので朝から神戸マラソンのアナウンスが聞こえてきた。

睡眠時間と仕事始め

後藤達也 note の掲示板 (たぶんメンバーしかみれない) に後藤さんがいつ寝ているのかという質問への回答を書かれていた。

よくある睡眠パターンは21:30ごろ～4:30とかだと思います。これだと7時間寝ているので十分です。

後藤さんも早寝早起き派らしい。私はだいたい0-6時が平均的なパターンだと思うけど、ちゃんと眠れないので6時間も寝ていない。体調の悪いときは横になっているものの1-2時間しか寝ていないときもある。7時半までには家を出てオフィスに向かい8時までにはお仕事を始める。開発が佳境に入ってきて集中力が上がっていれば仕事始めが6時半から7時ぐらいになる。開発のピークにそういう時期をもっていくように調整しながら働くときもある。最近は働き方改革でそういった密度の高い開発を要求されることも少なくはなりつつあるけど。

仕事を受ける判断

後藤さんはすごいなーと読んでいたら睡眠時間の投稿が思いの外盛り上がったらしく、第2段として仕事の選び方について投稿されていた。

そのなかで仕事を受ける判断として大事にしているのが、「発見があるか」「広がりがあるか」です。

これも私にとって共感のある内容でその投稿を読み入ってしまった。これまでも日記のあちこちに断片的には書いてきている。私も2021年1月31日に会社として引き受けないお仕事の基準を設けた。次の項目に該当したら基本的に引き受けない。

  • 自分の目指すキャリアの延長上にない
  • 自分がもっている知識や経験だけでできる
  • すでにあるものを維持していく、手伝うだけ
  • そこそこの開発メンバーがいて人手が足りないのを補うだけ
  • 権限委譲がなくてイニシアティブを取れない

どういうお仕事を受けて、どういう働き方をするかを課題管理し、その後も継続的にずっと考えていてまだ答えは出ていない。もう2-3年かければより明確になりそうな気はしている。やりたいことよりもやりたくないことを定義する方がずっと簡単で具体的と言える。

jira の epic 運用にもの思い

jira に特化した話だけど、チケットの整理をしていて自分の中での結論を言語化できたので書いてみる。前からずっと思っていたことではある。twitter に書いた通りだけど、epic のサブタスクはあまり使わない運用がよいのではないかと思うようになった。そもそも epic という単位が story よりも大きな機能のグルーピングを表す概念なのだから epic チケットはシステム上の制約で存在しているだけでそれを通常のチケットのように扱わなくてもよいのではないかと思う。epic に限らず、チケットを束ねるだけのハブチケットまたは親チケットに通常のチケット機能を設けない方がユーザーにとってわかりやすいようにも考えている。ハブチケットや親チケットに特化した要件や振る舞いはあるはずで、多くの課題管理システムはそれを追求していないようにもみえる。