Posts for: #Founding

標準ライブラリに XOAUTH2 の実装がない

0時に寝て3時に起きて5時ぐらいまでネットで遊んでて6時半に起きた。昨日の夜に洗濯しようと思って忘れていたので朝から洗濯した。

隔週の雑談

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

  • 税理士さんとの打ち合わせのふりかえり
  • 昔お手伝いした会社の開発体制の話
  • 新しいチーム勉強会 の導入

3人の税理士さんと打ち合わせしてみて最終的に顧問契約をお願いする方を決めた。話してみてやり取りした雰囲気だと、その税理士さんもスキルやこちらの要件対応については全く問題なさそうに思えた。あとは報酬とうちの会社の規模などを考慮して選択した。

昔お手伝いした会社で2年経ってちょっと相談にのってほしいという打ち合わせをした。私がいた2年前と開発体制はまったく変わってなくて、未だにテックリードがほぼ1人で開発している状況らしい。私が辞めてから以降も何人かは開発者が入っては辞めを繰り返しているのだと推測する。私も2度とその開発者と一緒に働きたくないと思うぐらいには信頼してなくて、開発者が引く手あまたな世の中の状況において、人間として信頼されないリーダーって致命的なんだなということを改めて実感した。おそらくテックリードを追放しない限り、あの開発体制 (と言ってもほぼ独り開発) は何も変わらないのだろうと思う。

oauth 2.0 で認証して google の smtp サーバーを使う

昨日の続き

リフレッシュトークンを使って取得したアクセストークンで smtp の AUTH コマンドで XOAUTH2 で認証すればよい。仕様は次のドキュメントに書いてある。

なぜか go の標準ライブラリの net/smtp には Plain と CRAM-MD5 の2つしか実装されていない。AUTH コマンドの実装は smtp.Auth インターフェースで定義されている。

type Auth interface {
	Start(server *ServerInfo) (proto string, toServer []byte, err error)
	Next(fromServer []byte, more bool) (toServer []byte, err error)
}

正常系の雑な実装だとこんな感じ。

type oauth2 struct {
	user        string
	tokenType   string
	accessToken string
}

func (o *oauth2) Start(server *smtp.ServerInfo) (string, []byte, error) {
	if !server.TLS {
		return "", nil, fmt.Errorf("need tls")
	}
	resp := []byte("user=" + o.user "\001auth=" + o.tokenType  + " " + o.accessToken + "\001\001")
	return "XOAUTH2", resp, nil
}

func (o *oauth2) Next(fromServer []byte, more bool) ([]byte, error) {
	if more {
		return nil, errors.New("unexpected server challenge")
	}
	return nil, nil
}

ググるとサンプルコードを実装している人たちがちらほらいるので、そのうち標準ライブラリに誰か実装してくれると思う。

go 本体に pr を送るチャンスでもあるけど、Contribution Guide を少し眺めて大変そうと思って、いまそこまでのモチベーションないなって感じ。

珍しく余裕のなかった一日

0時に寝て何度か起きて7時過ぎに起きた。眠れたような、そうじゃないようなよく分からない起き方をした。お昼ご飯を食べる間もなく、打ち合わせとコードレビューで1日を終えた。連休明けでよい慣らしになった。

税理士さんとの打ち合わせ2

税理士さん探し の続き。今回話した方は公認会計士だった。監査ができるのが公認会計士で、税務の申告ができるのが税理士という役割の違いになる。会計監査も含めてチェックしてほしかったら公認会計士さんにお願いするといった役割分担になるかもしれない。話してみて、若くて理路整然として悪い印象はなにもなかったのだけど、逆にこの人がうちの会社の会計/税務を親身にやってくれそうにもみえなかったし、ホームページの事業内容をみても公認会計士だから税務のビジネスだけではなく、もっと大きな会計のお仕事の方がを目指しているようにもみえた。同じ質問をして、前回の税理士さんの回答の違いなども考慮しながら選定の判断材料にはなるなと思いながらやり取りしていた。選択する側の打ち合わせはおもしろい。

アーキテクチャの再考

お手伝いしているシステム開発で、私の中ではもうアーキテクチャは固まったかな?と考えていたのが、お客さんと話していて、さらなる要件や展望を聞いているとそうじゃなかったことに気付いた。どうやら最初の実装としてはいまのアーキテクチャを堅牢に作って、その次の要件として待っていてくれたようにみえる。

私の認識を正す意味も含めて、さらにお客さんの要件や世の中の競合製品に対して競争力をもつにはどうするかといった視点をざっくばらんに雑談した。もう1段階アーキテクチャを見直す必要があるなと思えた。開発に着手して今月末でちょうど1年が経つ。これまで大きなアーキテクチャの変更もなく、順調に開発は進んできたものの、ここらで見直しやズレの補正が必要になってきてもなんらおかしくはない。いまの開発フェーズでは対応しないが、次の開発フェーズに向けてのアイディアの1つとしてアーキテクチャの再考が必要なことを認識した。

税理士さんの選定

1時に寝て3時頃に吐き気で起きて1時間ぐらい苦しんでた。久しぶりにやばかった。その後なんとか寝て7時半に起きた。

税理士さんとの打ち合わせ1

うちの会社のイベントとして毎年ワーケーション (開発合宿) をやろうかと考えている。コワーキングやコミュニティの延長上でワーケーションを行うわけだが、いくらかうちの会社の持ち出しで費用負担してよいと考えている。しかし、そのときの支出はどういった建付けで経費として扱えるのかどうか、私は税理士ではないのでよくわかっていない。そういったことを相談するために税理士さんに顧問になってもらおうと考えている。うちから税理士さんへの要件としては freee のデータを正として扱ってくれればそれでいいかな。

また2021年度は赤字決算になったので2022年度に 法人税の欠損金の繰り戻し還付 を行った。このお金を2022年度に計上していないため、その分の金額が資産のマイナスとして2023年度の決算に残ってしまっている。法人税の支払いは正しいのだが、還付金を2023年度に雑収入として登録するか、2022年度に遡って未計上の金額を登録するかのどちらかで訂正しないといけない。過去の法人決算の訂正自体も行う仕組みはあるので手続きするだけだが、それも手間暇がかかるのでついでに税理士さんにやってもらうと考えている。

会計システムに freee を使っているので freee さんの税理士紹介サービスを使って選定する。3事務所ピックアップしてくれたので順番に打ち合わせしていく。今日はその最初の税理事務所の方と打ち合わせした。話した感覚でうちの会社の考え方や規模にあった税理士さんだったのでこの方でいいんじゃないかとも思っているけれど、せっかく他の事務所もピックアップしてくれたので他の税理士さんの話も来週また聞いてみる。

コードレビュー

まる一日コードレビューをしていた。私もマージリクエストを投げていてレビューしてもらいつつ、メンバーのコードレビューも順番にやっていった。その中で smtp の仕様を把握しておく必要があっていくつかシニアエンジニアの方からもアドバイスをもらって、私もそうだったんだと勉強していた。メールヘッダーのエンコーディング、昔は覚えていたけど、ずっとメールを送るコードを書いてなかったので私も忘れてしまっていた。こういうことをさらっと指摘できるのがシニアエンジニアのすごいところ。

go だと標準ライブラリに mime パッケージがある。mime パッケージを使って件名を utf-8 でエンコーディングされた文字列で指定すると次のようになる。q エンコーディングと b エンコーディングの2種類がある。b エンコーディングの方がデータ量が減ってよさそう。

fmt.Println("Subject: " + mime.QEncoding.Encode("utf-8", "テスト"))
fmt.Println("Subject: " + mime.BEncoding.Encode("utf-8", "テスト"))
Subject: =?utf-8?q?=E3=83=86=E3=82=B9=E3=83=88?=
Subject: =?UTF-8?b?44OG44K544OI?=

コワーキングとコミュニティ

0時に寝て3時、5時ぐらいに起きて7時に起きた。

ストレッチ

先週に比べれば、出張を終えてのんびり過ごしていたのもあってかなりよくなっている気はした。足の張りはどこも目立つほどではなく、左の太もも後ろの筋肉の張りが強かったぐらいで復調している感じはした。腰もそれほど自覚症状はなかったものの、トレーナーさんからみると硬めだったという話しもあり、たしかに部位によってはきついところもちらほらあって、腰はまだまだ復調していないことがわかった。今日の開脚幅は開始前155cmで、ストレッチ後158cmだった。暑さも和らいで時間も出来てきたので少し運動してもよいかもしれない。

コワーキングとコミュニティ

2014年11月に発刊された Coworking Magazine の創刊号がある。昨年ぐらいまでは amazon に在庫があって購入できたが、いまみたら在庫がなくなったようだ。2014年に出版して2022年まで在庫が残っていたという雑誌ではあるが、内容はとてもよいものだと私は思う。2014年頃、コワーキングという新しい働き方のスタイルが日本に輸入され、広まっていったときのそのときの雰囲気や価値観を本書から読み取ることができる。多くのコワーカーたちがコメントしていたり、インタビュー記事もあったりして、コワーキングの価値やコミュニティの良さを語っている。こうやって出版という形で残しておくことで、その歴史の過程を学ぶ機会にもなることが本書から伺える。

私はコワーキングのような価値観や働き方を2016年頃から知ることになり、私もコワーキングスペースで作業したりするようになった。しかし、当時はワークスペースとして利用しているだけでそれはコワーキングと呼べるものではなかった。本書を読んでいて、ある人はコワーカーとはコミュニケーションを取る人たち、またはコミュニティに参加する人たちを指すのだと話していた。コミュニティ参加しなければ、コミュニティの恩恵を受けることが難しく、その状態をコワーキングとは呼べないようだ。2022年6月に カフーツさんを訪問 して、いとうさんとコミュニティについて話してみて、私の知っている IT 業界のコミュニティの在り方とコワーキングにおけるコミュニティには通じるところがあって、それ以来、コミュニティを学ぶことや課題管理のヒントになると考えて、いとうさんの主催しているオフライン/オンラインイベントにも参加するようになった。

コワーキングの価値はコミュニティやコラボレーションにある。作業場としてのワークスペースではない。コラボレーションと言うと、企業間の業務提携だったり、新商品企画を共同でやるとか、そういう大きなものをイメージしてしまうが、コワーキングにおけるコラボレーションとはそんな大きな話しではない。ただ一緒に作業しながら、軽く雑談したり、なにかのテーマで話し合ったり、その場に一緒にいることで生まれるコミュニケーション全般を指す。共通の話題や課題に対して一緒に考えたりする行為で構わない。もっと小さいものだと気付けるようになった。

それは私がマイクロ法人を経営して1人で黙々とずっと仕事をしていても、この延長上に新しい価値を築けるような気がしないというのを実感した後だった。リモートワークと相談相手 にも書いたが、会社に勤めていると自然と同僚とコラボレーションしている。マイクロ法人には同僚がいないのでコラボレーションによる気付きや刺激を受けることができない。コワーキングは1人会社やフルリモートワークのような、同僚が身近にいない人たちへコラボレーションの価値を提供しているということを、身に染みてわかるようになった。

IT 業界では Open Source Software の歴史をみると、古くは1950/1960年代の Unix に端を発し、1990年代の Linux の公開、1998年の Netscape 社の Mozilla Firefox のソースコード公開などの大きなエポックメイキングを経て、社会運動としての OSS 文化や OSS コミュニティが発展してきた。その歴史の過程で日本では2010年前後から IT 勉強会という、主に Web 業界の様々なバックボーンをもつプログラマーが技術情報を共有するようになった。OSS の技術はみんなで共有するものという価値観があるが、それはこういった IT 勉強会によって草の根的に広まっていったと思われる。私もそんな IT 勉強会に参加して技術を研鑽してきたプログラマーの1人なのでまさに生き証人でもある。それはまさにコワーキングの人たちが言う、コミュニティのそれとまったく同じである。IT 技術という共通の話題で困っていることを共有したり、不具合を改善したり、新しいプロダクトを開発したりしていた。製造業の人たちには驚かれたが、web 業界はコンテンツを公開して広告費で儲けるビジネスモデルであることから、自社の技術情報やノウハウをすべて公開してしまう。ビジネス上では競合他社であっても、別会社の開発者とも仲良くなって技術情報を共有している。それが業界全体のレベルの底上げをしてきた。いまもその文化は変わっていない。

次にくる流れとして、IT 業界のプログラマーはどんどん独立していくと私は考えている。いまもフリーランスになる人は増えつつあると思う。スキルも経験もない若い人が安易にフリーランスになることはお奨めしないが、20年も働いてきたベテランはどんどんフリーランスになって、組織の枠に収まらない活躍をしていけばよいと思う。マイクロ法人を経営することのハードルも歴史上、もっとも低くなっていると私は思う。私が経営できているのだから普通のプログラマーでも経営できる。しかし、1人で働いていると、私が陥ったような「行き詰まり」を覚えるようになるかもしれない。コワーキングやコミュニティはそれを防ぐきっかけになるのではないか?と思うようになってきた。この「行き詰まり」に名前を付けたい。私が感じたのは次のようなことになる。

  • 自身が成長しているように思えない
  • 日々の生活で気付きや刺激がなくなる
  • 新しいことに挑戦する気概がなくなる
  • 自分の状態が自分で判断できない
  • 誰に何を相談していいか分からない

もしかしたら会社に勤めているときも同じような状況になっているときもあったかもしれないが、会社に所属していると、仕事はいくらでも上から降ってくるし、仮にぼーっと何もしなくても給料は毎月もらえる。この先どうやって生きていくのか?という、生命としての根源的な問いから目を背けてしまうような錯覚がある。なんの後ろ盾もないマイクロ法人やフリーランスになることでこういった根源的な問いから目を背けられなくなる。私の場合、そのことに2年目で気付けるようになった。今後のビジネスにおいても、直接的ではなく間接的にコミュニティというのはキーワードだと考えている。コミュニティへの理解を深めるためにもコワーキングには今後も注目していきたい。

初めて lvm を操作してみた

0時に寝て何度か起きて7時に起きた。最近は寝る前にはてブのアプリで適当に記事を読みながら寝ることが多い。

隔週の雑談

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

ここ1-2週間ぼーっとしていて、忙しくもなく、なにかやっているわけでもないけど、のんびり過ごしている。軽いバーンアウトだと思う。先週末は休みも取った。「hugo のテンプレート作り」のような新規開発を、どこかのもくもく会やイベントに行って、その場で集中してやったらいいんじゃないか?というアドバイスをいただいて、確かにそういうやり方もよいように思えた。今週末は課題管理のコンテンツを考えて、できればブログに書いてみようと思う。

lvm の論理ボリュームの結合

新規に almalinux 8 で仮想マシンを作った。デフォルト設定でインストールしたら //home でパーティション分割されていて、これは使い勝手が悪いなと思ってパーティションを結合することにした。

$ df -h
ファイルシス               サイズ  使用  残り 使用% マウント位置
devtmpfs                     1.9G     0  1.9G    0% /dev
tmpfs                        2.0G     0  2.0G    0% /dev/shm
tmpfs                        2.0G  8.6M  2.0G    1% /run
tmpfs                        2.0G     0  2.0G    0% /sys/fs/cgroup
/dev/mapper/almalinux-root    70G  6.5G   64G   10% /
/dev/mapper/almalinux-home   437G  5.0G  432G    2% /home
/dev/vda1                   1014M  221M  794M   22% /boot
tmpfs                        393M   12K  393M    1% /run/user/1000

基本的には次の記事をみてやったらうまくいった。

/home をバックアップする

# mkdir /home-bkup
# cp -a /home/ /home-bkup/

emergency モードに入る?

# systemctl emergency

結合したい領域を unmount して、home の論理ボリュームを削除する。

# umount /dev/mapper/almalinux-home
# lvremove /dev/mapper/almalinux-home
Do you really want to remove active logical volume almalinux/home? [y/n]: y
  Logical volume "home" successfully removed.

バックアップからデータを戻す。

# cp -a /home-bkup/ /home/

/etc/fstab から不要なパーティション設定を削除する。

# vi /etc/fstab
...
/dev/mapper/almalinux-home  /home  xfs  defaults  0  0  # <- この行を削除
...

root の論理ボリュームに余っている領域を拡張する。

# lvextend -l +100%FREE -r /dev/mapper/almalinux-root
  Size of logical volume almalinux/root changed from 70.00 GiB (17920 extents) to <507.04 GiB (129802 extents).
  Logical volume almalinux/root successfully resized.
meta-data=/dev/mapper/almalinux-root isize=512    agcount=4, agsize=4587520 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=0 inobtcount=0
data     =                       bsize=4096   blocks=18350080, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=8960, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 18350080 to 132917248

この時点で1つの領域に結合されたことがわかる。

# df -h
ファイルシス               サイズ  使用  残り 使用% マウント位置
devtmpfs                     1.9G     0  1.9G    0% /dev
tmpfs                        2.0G     0  2.0G    0% /dev/shm
tmpfs                        2.0G   78M  1.9G    4% /run
tmpfs                        2.0G     0  2.0G    0% /sys/fs/cgroup
/dev/mapper/almalinux-root   508G   14G  494G    3% /
/dev/vda1                   1014M  221M  794M   22% /boot

バックアップを削除する。

# rm -rf /home-bkup/

マシンを再起動する。

# reboot

これで問題なければ完了。

稀な出張飲み歩き

0時に寝てあまり眠れなくて7時に起きた、いつもと違うホテルのせいか、あまりうまく寝付けなかった。部屋も広くてよかったのになぜか落ち着けなかった。

プロジェクトの進捗報告

出張したときの月例報告の10回目。前回の進捗報告はこちら

概ね 事前に準備してあった資料 のまま次の3次開発へ進むことに決定した。いくつか経営者に確認することも用意していた。「よしなにはからえ」な方向で取り組めそうだ。1年近く開発を継続してきて、次の3次開発を終えれば品質面でも私からみて自信をもてるようにはなると思う。

そろそろ私の契約を終えてもいいんじゃないかと考えていたが、もう少し追加の開発に付き合ってほしいとのこと。それを受けて「もうちょっとだけ続くんじゃ」と自身のモチベーションコントロールをしていく。早ければ今月いっぱいで契約終了する可能性もあった。継続しても、あと3-4ヶ月程度で終えて、その後に私も3ヶ月ほど休もうとか考えていた。まだまだプロダクトの機能や品質に満足していない、私が長期休暇を取れる状態ではないぞという激励でもあったのかなと思う。

セルフ居酒屋

晩ご飯に 大崎一番家 さんへ行ってみた。

店主が1人でやっていて、お客さんはセルフで飲みものを手配する。冷蔵庫からお酒 (ハイビール、酎ハイ、瓶ビール) を取ってきて、氷も冷凍庫から勝手に容器に入れてもってくればいいと言う。あとで卓上に置かれた缶や瓶を数えて精算する。ボトルを入れているお客さんなんかはやってきて勝手に飲み始めたりもすると店主が話していた。食べものだけオーダーシートに書いて厨房にいる店主に声をかけて提出する。厨房の入口に置いていたら、都合のよいタイミングで受けとって料理を作ってもってきてくれる。こういうスタイルのお店を嫌う人もいるだろうけど、私は自分のできることが多いスタイルのお店は気楽で気に入ってしまった。店主も関西の人らしくて陽気な性格だった。料理が大皿なので1人だと2-3皿食べるとお腹いっぱいになってしまう。野菜サラダなんかは私は大皿でもりもり食べたいのでちょうどよかった。口コミでデミグラスカツがよいとあったので注文してみておいしかった。但し、1人で食べるには多過ぎで2-3人向けの分量だが。

こういう1人で全部やるという働き方そのものを私は好む。誰かと一緒に働くの、他の人間と一緒に働くのはどう繕っても気を遣う。居酒屋のような、本来は1人でできないことをお客さんの力も借りながら1人で成り立たせる工夫をあっぱれだと言いたい。以前 マイクロ法人のススメ に書いたが、1人で意思決定して楽しく働く、1人の会社が他の会社と協調して大きなお仕事や難しい課題を解決するという、新しい働き方に私も挑戦していきたい。

飲み歩き

大学の友だちに声をかけてみたら、そのとき浅草で働いていて、その後、ちょうどよい場所として新橋へ移動した。20時過ぎから新橋の居酒屋さんで飲んでいた。2-3年ぶりぐらいに会ったかな。社員が20人の頃に入社した会社がいまや社員が400人になっていて上場も視野に入れてお仕事しているとのこと。当然、その友だちも幹部社員になっていてすごいなぁと近況を聞いていた。マンションを3つ買ったとか話していた。

プロジェクトマネジメントやメンバーの育成など、私も最近はマネージャーをやっているからあーだこーだと話しをしていた。その友だちはもともとマネージャー職を目指していたので私よりもマネージャーとしての経験や知見が多い。その友だちも私に負けず劣らずのハードワーカーなので考え方は私と近いと思う。若い人に適正がなさそうでもどう教えるか、どこで見切るかといった話しが一番盛り上がった。その友だちは3年ぐらい面倒はみるが、それでダメなら適正がないと本人に告げて他の仕事に移ってもらうようにするという。適正がないと本人に告げることも優しさだという。たしかに大企業だと、まったくできない人が開発者として中堅社員になってたりすることもあり、それがプロジェクトの弊害になることを私は経験したことがある。あとお互いに年寄りでスキルもやる気もないのは無条件でダメみたいなところは一致した。以前、参加した オープンセミナーの懇親会 でも、成長しない社員に対してどう接するかの話しをしたことがある。そこでもこのままそのレベルで仕事を継続してもよいが、待遇はそれ以上あがらないことを伝えるとある管理職の方は話していた。

成長の度合いも個人差があり、どの程度をよしとして、どこで線を引くかは難しい。私はプログラミングが好きなら多少のスキルの個人差はあってもよいと考えている。しかし、会社になると組織に貢献しているかというのは大きな基準になるので必ずしも私の考え方は正しくはない。人間が人間を評価するのは本当に難しい。このまま小さい組織で評価とは無縁で働きたい。

昼に寝て夜に考える

0時に寝て何度か起きて7時に起きた。昨日は晩ご飯食べてからだらだらしているうちにいつの間にか寝ていた。今日はオフィス暑くて14時から帰ってきてお昼寝して19時過ぎにまた戻った。

ストレッチ

先週末は実家や四国へ出掛けていたため、ストレッチをお休みしていた。2週間ぶりのストレッチとなる。右足がパンパンでひどいことになっていた。休んだことと出掛けていたことの疲労が重なったのか、右足のどこの部位も調子が悪くて歩くのもやや辛いと言える。相対的に左足が大丈夫なように聞こえるが、普通の感覚ではそれなりに張りがあるので左足も疲労している。あと腰も左右ともに負荷がかかっているように思えた。今日の開脚幅は開始前155cmで、ストレッチ後157cmだった。週末はちょっと休もうかと思ったぐらいの疲労度と体調の悪さを実感した。

工事業者の訪問

先日の 暑さ対策委員会 の続き。

ストレッチを終えてオフィスに向かうと、ちょうど同じエレベーターで工事業者さんと鉢合わせになった。いまから作業するところだったらしく、作業前にオフィスに入ってもらって通気口の状況を確認してもらった。いまの室温は30℃を少し上回ったところ。通気口からエアコンの風は出ているが、室内がまったく冷えないことを伝えた。そのときになにかの機器にガスを注入したという話しをしていた。これでダメなら (エアコンの?) メーカーの担当者と別の調査か対策を行うといった話しをされていた。何であれ、調査して原因の切り分けをして、次の作業へ進展している話しを聞いて安心した。但し、今日のところは、夜になっても室温の変化はみられなかった。まだ改善するかどうかはわからない。

遺産分割協議書の契印・割印の要否

弁護士さんから以前、作成した遺産分割協議書に割印をしていないことに気付き、税務署の手続きを進められない可能性があるから、もう一度、相続人全員の割印を取得してほしいと書類が届いた。すでに銀行・法務局の手続きは滞りなく終えている。こんな面倒なことを可能性があるという不確かな情報でやってられないと思って、本当に必要な手続きかどうかを税務署に確認してほしいと返信した。それと同時にググってみると、あるほうが改ざん防止になるので望ましいが、必須ではないという記事が多くみつかる。書類を作成するときに依頼されていれば応じるが、書類作成後になって大半の手続きも終えていて、相続税を払うためだけにそんなことやってられるかと思ってこのまま進めてほしいと押印せず書類も返送した。

もちろん税理士さんや税務署に裏付けをとる必要はあるが、ちょっと調べれば分かることをベテランの弁護士さんが調べずに顧客へ工数を転嫁することにがっかりした。

ストーリーポイント再考

少し前にみかけたポストで「ストーリーポイントは機能しない」というものがあった。

私もストーリーポイント否定派の1人だが、その投稿に発明者ですら謝罪していると書かれていた。それでずっと気になっていたので発明者の元記事を読んでみた。翻訳に近いが、日本語でも要約された記事もある。

これを読んでみて、発明者も言っていることは真っ当だと思う。ストーリーポイントがいかに誤用されているか、それによって意味のない時間を費やしているか。そもそも見積もりは現実のプロジェクトマネジメントにおいて必要とされるが、実際の開発においてまったく無意味であるといったことなどが書かれていて、ソフトウェア開発を見積もろうとする行為そのものがそもそも間違っていて、それをさらに相対化 (抽象化) させたストーリーポイントが役に立つわけがないとすら思えた。誤用されるなら、スプリントプランニングのためにストーリーポイントを使うのはまったくの無駄とまで言い切っている。

この記事を読んで不思議なことの1つに、実際にスクラムでストーリーポイントを使ってみれば意味のない指標であることに気付く開発者は多いと思う。スクラムガイドにおいても、見積もりより経験主義の重要性を説いているにも関わらず、なぜこんな誤ったメトリクスがスクラムとセットで導入されているのか、私には理解できない。プロジェクトマネジメントては別の、政治力学においてストーリーポイントが使われているのではないか?という気すらしてくる。

課題管理の文脈だと、見積もりは勘と経験でよいというのが私の解になる (ストーリーポイントを使ったところで出鱈目なんだから) 。課題管理と見積もりというテーマもなにかしらコンテツになりそうな気がした。

涼しくなる前に暑さ対策を

0時に寝て何度か起きて7時過ぎに起きた。6時に起きようと思ったけど、気付いたら7時になってた。

ドキュメント書き

8月前半にやっていた非機能要件である差分比較の仕組みについてドキュメントを追加した。但し、この機能はまだ品質を保証できないところがあるため experimental という機能にした。そのためのドキュメントとサポートポリシーについても明記した。利用者からのフィードバックを得られることを目的にした開発途中の機能をプロダクトに追加する仕組み化した。あまりエンタープライズ向けの業務システムでそういった機能を多用するようなことはないと思うけど、QA を十分にできなくてまだ品質に自信がないといったときにも使えるかもしれない。

実務スタッフの訪問

先日の 暑さ対策委員会 の続き。

そろそろ電話しようかと考えていたところ、スタッフが訪問してくれた。7月の中旬からクレームを上げていて、初めてオフィスに来てくれて室温が高いことを確認してくれた。いまだと昼間は30℃ぐらい。その人は過去の経緯をわかっていないようで、フィルター交換と冷媒交換をしたが、まったく効果がないことを丁寧に説明し、エアコンのコントロールパネルの温度・風量設定もまったく機能しないことを伝えた。明日の午前中に工事の業者と一緒に調査してくれるという。ようやく人が来てちゃんと確認してくれた。明日の作業に期待。

クレジットカードの明細のリアルタイム連携

先週末の小旅行にかかった経費の領収書を会計システムに登録した。30分もあればできるのにずっと後回しにしていた。

唐突だが、freeeカード Unlimited がすごくよい。起業時に作った法人向けのクレジットカードは所持しているが、クレジットカードの盗難・紛失時の冗長化の目的で4月に携帯用のカードとして導入した。これが後発のせいか、freee のシステムとの親和性を考慮しているのか、まだ使っているユーザーが少ないからなのか、ほぼリアルタイムで決済情報が会計システムに連携される。

もともと使っていた旧来のクレジットカードと比較できるため、会計システムと決済情報のデータが迅速 (ほぼリアルタイム) に連携すると、実際に運用してみて事務手続き工数を削減できることに気付いた。旧来のクレジットカードは決済情報を取得するのに2週間ほどかかり、さらに先方のシステムの都合で月の負荷が高くなりそうな期間 (10-14日とか) は連携不可といった運用になっている。2週間経ってから決済情報をみても何にお金を使ったのか思い出すのに少し時間がかかったり、請求書などを調べて確認したりする作業が発生する。クレジットカードで支払った直後に会計システムに取引登録するのがもっとも事務手続き工数を削減できることに気付いた。

半年間ほど新旧のクレジットカードで運用してみて、旧来のクレジットカードによる決済を置き換えていくことに決めた。今後は Unlimited なクレジットカードを2つ使って冗長化した運用にしようと思う。

速さは正義。

家に帰るまでが旅行

実家へ帰って疲れていたせいか、21時過ぎから寝てしまって2-3時間ごとに起きて5時半に起きた。親はもっと早くから起きているからその時間から朝ご飯が出てくる。

ドキュメント書き

持ち帰ったばかりの机とバランスチェア を使って初めてのリモートワーク。とくに問題なく作業できたのでよさそうに思う。今日は早くお仕事を切り上げるために7時からお仕事を始めた。issue の対応を見守りながらドキュメントをまとめて書いていた。新規追加した機能やまったく違う仕組みに置き換えたものがあるため、ドキュメントの変更量が多い。

お昼にメンバーからも qa テストの完了報告が届いて、私も自分がもっている issue ではバグ修正もすべて終えていて、あとはドキュメントと最後の GA 向けのパッケージングぐらい。いつもそう思うけれど、終わってみれば順調に予定通り開発のイテレーションを完了できた。今回は機能開発に約3ヶ月、QA に1ヶ月の約4ヶ月のイテレーションとなった。開発の状況をみながらマイルストーン (2週間) を増やしたりもした。その程度の調整もした上で予定通りと言える。3ヶ月のイテレーションに対して、私がマネジメントをしていれば前後2週間程度のズレしか出ない。こんなの当たり前だと思うが、以前お手伝いしたスクラム開発でのストーリポイントでは2ヶ月の見積もりに対して4ヶ月を要した。見積もりがめちゃくちゃだったと言える。

帰路に着く

てらださんが鳴門から淡路島南 IC に15時30分に着くという予定を教えてもらっていた。そのため、15時にお仕事を切り上げて、迎えに行って、それから神戸に一緒に帰ってきた。

たこせんべいの種類

帰路の途中で たこせんべいの里 へ立ち寄った。津名一宮 IC のすぐ近くにある。おそらく私は行ったことなかったと思う。長居するような観光施設ではないが、立ち寄ってみたらそれなりにおもしろかった。てらださんの奥さんがたこせんべい好きらしくて、いろいろ教えてくれた。50種類ぐらいある。たこせんべいっていろいろ入っていることは知っていたけど、こんなに多くの種類があるとは知らなかった。たこせんべいの個別試食ができて、コーヒーも飲めて、工場見学して、お土産にせんべい買って帰った。16時半には出発した。

新神戸駅

快調に高速道路を走って、3号神戸線を迂回して7号北神戸線から神戸へ戻る。道中で若宮-芦屋間で渋滞18kmとか出ていた。いつものこと。てらださんに 3号神戸線のうんちく をたくさん語って満足。この日のためのネタだ。17時には新神戸駅に到着して送り届けられた。無事に旅程をこなせてよかったと私がほっとした。

小旅行の所感

てらださんがオープンセミナー参加のために香川県へ来られるという話しを聞いて、車も買ったばかりだし地元だから案内しようと考えた。その延長で LT 発表しようと思いつき、ある記事を翻訳したらちょっとバズって世の中の役に立ったのかもしれない。

私はなにも用事がなければ出掛けないことが多い。いまは基本的にずっと会社のお仕事をしているし、そんな毎日でも不満もない。だからこそ、なおさらこういった縁の機会が大事だとわかるようになってきた。てらださんが来られなければ、この3泊4日の小旅行はあり得なかった。そして 車中泊の経験 も得られなかった。新しいことを学ぶ機会そのものが尊い。旅程を通して関わってくれた周りの人たちに感謝したい。

これは昔はらさんからも助言をいただいたことを覚えている。私が交際費を年間で2-3万円しか使っていなかったときのこと。

放っておいて会社にお仕事が舞い込んだりしない。
いまのお仕事がずっと続くことはあり得ない。
将来のために新しい縁を自分から探しに行かない限り、会社を継続できない。

クレームへの階段

0時に寝て何度か起きて6時に起きた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。先週は多忙でお休みした。今日の議題はこれら。

たまたま X (twitter) でスクラム批判しているツィートを教えてもらってリンクにあるように Scrum is a cancer. というインパクトのある書き出しで聴衆を一気に掴んで盛り上がっていた。多少の誇張はあるものの、内容も真っ当で私が読んでみてもそんなに違和感がなかった。スクラムの懸念をうまく言語化したポストになっていたと思う。その延長で他にも、見積もり、フィードバック、ストーリーポイントにも言及していて、これらの話題についてはらさんと雑談してみた。はらさんとは1-2年前からスクラムの話題で何時間も話しているので、もうお互いに食傷気味ではある。ただ時事ネタなのと1年ぐらい経ったらアップデートもあるかな?という期待もあって話題に選択してみた。次のような意見が出た。

  • スクラムの開発プロジェクトをそんなに経験している開発者は少ないから主語が大きくなりがち
  • マネージャー入門としての、スクラムという開発方法論を評価してもよいのでないか?
  • 「スクラムにはマネージャーいない」と骨髄反射で返答をよくもらうがそれは理想論ではないか?
  • スクラムの失敗と事業/業務の失敗は違う
  • スクラムは毎日見積もり、デイリースクラムで確認できるというメリットがある
  • スクラムはチームの限定合理性を重視するため、個人の限定合理性を重視するメンバーを排除できる
  • スクラムの懸念の1つに全然できていないのに「できている」というメッセージを出し過ぎるのではないか?
  • ソフトウェア開発は前提として見積もりできないという認識をもつべき

お腹いっぱいなので詳細はあまり書かない。

オフィスの担当者との電話

先日の 暑さ対策委員会 の続き。

昨日、運営会社にその後の進捗を確認するために電話したらお休みだったので再度電話した。昨日もコールバックすると言いながら15時過ぎてもコールバックがなくて、もういい加減エスカレーションして偉い人に正式なクレームをあげようと考え始めていた。ようやく電話つながったと思ったら通話の音質が悪くて話しているうちに切断して、その後もつながらない。本当にイライラがつのる。2回目のコールバックで話していると、エアコンの工事によって隣のオフィスの人たちは問題ないと言っていたといったコメントが出てきた。

私のイライラが最高潮に達したのはこのとき。私はこれまでもずっと隣のオフィスの社員さんと暑さどうですか?という会話を何度かして先方も室内は暑いという話しを聞いていた。隣のオフィスの社員さんが問題ないなんて言うわけがないと思って、そのまま隣のオフィスへ言ってそこの社員さんにも電話に出てもらった。もちろん隣のオフィスの社員さんはこの件について一切やり取りしていない。社員さんも「(暑さについて) すぐ分かるから現場に来いっ!」って怒っていた。

ほんとその通りで7月の中旬からずっと伝えている。何もしていないわけではないのは理解するが、現地で確認したらこれまでの施策の効果がないことは一目瞭然である。一切確認せずに作業したから問題ないと判断して放置していたようにみえる。一連の対応が終わったときに正式なクレームとして運営会社にあげようと考えている。

  • 1ヶ月半の間に5回電話して一度もコールバックも進捗報告もなかった
  • 効果が出ていないことは報告しているにも関わらず、なんら施策を検討していない
  • 現地で確認すれば、ひどい暑さであることがすぐわかるのに1度も調べようとしなかった

気分転換に開発はお休み

0時に寝て3時5時7時と起きて8時に起きた。起きてからネットの記事を読みながらしばらくだらだらしていた。11時ぐらいにはオフィスへ行って今月分の請求書を発行して、9月のイベントで発表するネタの調査、三ノ宮.dev の slack で 課題管理について話した podcast を紹介してもらったお礼を述べたりとか、いろいろ自社のお仕事をしていた。

マイクロ法人のススメ

たまたまだが、私がよく行くお店でマスターが1人でやり繰りしている飲食店が増えてきた。またコワーキングスペースなどへ行くと、マイクロ法人でがんばっている人たちと交流する機会も増えてきた。私自身マイクロ法人として1人で会社や事業を経営している立場なのでそういった似たもの同士な人たちとよく気があう。同じような人たちをみていて、マイクロ法人のなにが楽しいのかを、いずれちゃんとしたブログの記事にしたいと思う。外から観察していても働き方に共通点がある。

よいところを述べる前に、わるいところも言うべきだと思う。

  • (サラリーマンと比較して) 会計や税制といった財務知識が必要になる
  • (サラリーマンと比較して) 書類などの事務手続き作業は増える
  • (サラリーマンと比較して) 短期的な安定や信頼を得にくい
  • 自分で営業しないといけない
  • 自分で事業を設計しないといけない
  • 同僚と雑談できない、困ったときに助けてもらえない
  • 複数人で対応するような規模の大きな仕事はできない

たくさんわるいところもある。これらのわるいところを受け入れた上でよいところもある。

  • お仕事はすべて自分で決められる
  • 目標設定をしなくて済む (他者評価もされなくて済む)
  • (サラリーマンと比較して) 事業がうまくいけばより大きな対価を得られやすい

デメリットよりもメリットが上回るのならマイクロ法人がいいと私は思う。もちろん若い人には勧めない。経験のある人が評価されずにつまらない組織の仕事で残りの余生を過ごすぐらいなら、自分で思うよう好き勝手働いた方が人生としては楽しいのではないかと思ったりする。もちろんそれで失敗する人もいるだろうし、私も今後失敗するかもしれない。失敗したときに会社を辞めずにサラリーマンをしておけばよかったと後悔する日が来るかもしれない。仮に失敗したとしても、その瞬間までのマイクロ法人で働いてきた日々に価値を見出せればそれだけでよかったと思えるかどうか、と言い換えられるかもしれない。

楽しく働く

うちの会社の価値観の1つにしようと考えている。歳をとってシニア社員になるほど、楽しく働いている人は少なくなっていくように傍からはみえる。会社から評価されず、おもしろい仕事も任されず、ただ生活のために働いている人は多いのだろう。状況が許せば、そんな人がマイクロ法人になると、働く楽しさを取り戻せるかもしれない。