Posts for: #Founding

余裕がなさ過ぎる

1時に寝て7時に起きた。タスクが溜まり過ぎてそろそろ辛くなってきているところ。この余裕の無さはよくないことなので、自分のダメさ加減というか、大いに反省しないといけない。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。いつもは打ち合わせの議題を2-3日前には共有するようにしている。だいたい水曜日前後に議題のリファレンスをはらさんに共有して金曜日の朝に話している。しかし、今週はリファクタリングに集中し過ぎていて前日の寝る前になって議題を共有していないことに気付いた。そして朝起きてから急ぎで議題を考えて共有していた。これはとてもよくない。準備ができていないので今日の議題は主に近況の話しをしていた。

ハドルの雑談

先日から 午前中はハドルに滞在 するようにしている。今週は木曜日にチーム外から勉強会についての相談が、今日はメンバーから気分転換に雑談にやってきてくれた。おそらく私がハドルにいなかったらゼロだったコミュニケーションの機会が、1週間に1-2回でもあることに私は嬉しく思ってしまう。フルリモートワークにおける、オフラインのような気軽な雑談の機会を提供する施策の1つとして意味なくハドルに入るのは悪くない気がしている。そのときにコミュニケーションを強制させるような押し付けが発生しないよう、運用ルールを徹底することが大事に思える。いまは相手がハドルに入ってくると 1on1 のような雰囲気になってしまうのでその次の挑戦としてはハドルに入っていても話さなくてよいといった運用ルールを設ければよいのではないかと思う。例えば、午前中はとりあえずハドルに入って気分が向いたときだけ話しかけるみたいな、ゆるいコミュニケーションの場になればいいなと思う。

ハドル雑談の運用ルールのアイディア

  • ハドルに入らなくても業務上の支障は一切おきない
  • ハドルにいる人には、用事があってもなくても、話しかけてよい
  • ハドルに入っていても話さず聞いているだけでもよい
  • 業務に集中していて忙しいときは話しかけられても後回しにしてもよい (ハドルから退出した方がわかりやすいかもしれない)

go の generics 勉強会

ちょうど先週からあちこち直したり、mongodb のクライアント周りをリファクタリングしたりしている。その過程で generics を使ってコードの共通化もしたりしている。私自身 generics で意図した通りにコンパイルできなくてはまってしまった事例もあるのでそういった失敗コードも共有した。go の generics はコードに対して静的な領域しか適用されず、コード中における動的な値の型は generics とは直行した概念だというところに初学者ははまるのではないかと思う。私がはまった。参加者におそらく1度はまるからはまったときに私が話していたことを思い出してとコードの解説をしていた。

余裕があったらスライドにまとめて後で資料として再利用できるようにしたかったものの、私の作業に余裕がなさ過ぎて次のリファレンスから引用しながら解説するといった勉強会になった。ただ私が読んでよいと思った他者のスライドやブログの記事のみを紹介している。それはそれで参考にはなるので勉強会の意図としては問題なかったんじゃないかとは思う。

雑談の多い日

0時に寝て4時に起きて6時に起きた。本当はもっと早く起きて勉強会の資料作りやろうと思っていたけど、疲れと寒さでうまく起きれない。高速バスよりはずっと楽だけど、それでも土日に実家帰ってくると疲れが溜まる。次の週の週末になると蓄積度が違う。

隔週の雑談

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

年末にはらさん主催の忘年会に参加した。参加者は10人前後いたと思う。そのときにはらさんが「会社でオンライン飲み会やっても盛り上がらない?」といった話題があった。その意見には私も同意でおそらく参加者が5人以上いるとオンライン飲み会は盛り上がらない。オンライン飲み会の難しさは1つの部屋だとせいぜい3-4人ぐらいでないと話せない。1つの部屋に10人とかいると、実質話しているのは3人ぐらいで残りのメンバーは聞いているだけになる。それが盛り上がらない要因だと思う。オフラインの飲み会なら、例えば4人テーブルに3グループに分かれて、それぞれのグループが3つの会話が成立するから盛り上がる。そして、隣の会話が薄く聞こえたり、ちょっと休むときに隣のグループの会話に混じったりもできる。これと同じことをオンラインでもチャンネルを分けてやればよいというのは理屈の上で正しい。しかし、オンラインで能動的に別のチャンネルに入り直すのは複数の意味で障壁が高い。まずツールの操作が分かりにくいし、幹事が仕切るわけでもないので運用ルールも曖昧。仮に幹事がいても仕切れるのは1つのチャンネルだけで、他のチャンネルが意図した運用をしているかどうか、チャンネルを出たり入ったりしないと監視するのが難しい。オフラインの飲み会に近い状態にするのは、オンラインミーティングツール側で自動的にうまいこと配慮しないといけないのではないかといった話を、はらさんとしていた。

はんなりPodcast

はんなりプログラミング のコミュニティが はんなりPodcast(仮) を始めたらしい。私もちょくちょくはんなりさんのイベントに参加するので運営の方々とも懇意にさせていただいている。たまたまゲストで呼んでいただいた。感謝。内容はまた公開されてから書くので今日は収録の雰囲気だけ書いておく。かいせんさんとおがわさんとは、オンライン上でもよくやり取りしているので気軽に話すことができた。逆に私が調子に乗り過ぎて内容とは逸脱したことや自分の話したいことをわーっと話し過ぎてしまったのではないかという反省もあとになって思う。いま1人で働いているからこうやって自分の話しを聞いてくれる機会というのは貴重でそれはそれで楽しかった。ついつい自分の話しばかりし過ぎないように注意しないといけない。

起業相談が再び

1時に寝て8時に起きた。寝坊して朝起きれないものの、わりかしよく眠れるようになってきた。

sveltekit の ui からのリクエスト

+page.svelte のスクリプトで onMount() を定義すると bff へ http リクエストを fetch できる。

<script lang="ts">
	import type { User } from '$lib/types/users';
	import { onMount } from 'svelte';

	let data: User[] = [];

	onMount(async () => {
		const r = await fetch('/api/users');
		if (r.ok) {
			data = await r.json();
		}
	});
</script>

bff 側では web api を提供する必要がある。それは +server.ts を定義することで実装できる。内部的にはバックエンドの web api を呼び出して、それを返すだけの実装になる。こういった連携も sveltekit だと簡単に実装できる。前のお仕事は bff も java で作っていたけど、bff なら node.js でいいんじゃないかと思うぐらいにはフロントエンドの技術に慣れてきた自分がいる。

起業相談

少し前にも起業相談 に乗ったが、まったく別の人で12月に起業された方が三ノ宮.dev のコミュニティに入られて起業相談にのってほしいというので行ってきた。個人でもわりと有名な方らしく、ある2つのキーワードでググるとトップに出てくる。スタートアップを目指している方で、できるだけ多くのお金を資金調達して作りたいものを開発したいという話し。いまは金融緩和から緊縮に向かう状況なのでベンチャー資金も渋い状況ではないかと推測する。そんな中で cto をどうやって探せばよいかという質問が大きな話題だった。資金調達する上でもちゃんとした cto がいる方が融資する側からみても印象が違うという。それはそうかなとも思う。

一方で cto を探すのは相当に難しいという話しを私からした。基本的には過去に一緒に働いた人でスキルのある人や同じ意思をもっている知人や友だちに依頼するのがよいだろうと。それも難しい話しだけど、cto 募集なんかでよい人がみつかる確率は低いし、ましては ceo が技術に明るくないのであれば応募してくる求職者のスキルや知識を評価するのも難しい。他のコミュニティメンバーも同意見で、最初は cto を雇わず、普通にテックリードになれる開発者を雇って、プロダクトを開発して実績を作って資金調達した後に再度 cto を探してはどうか?と提案した。

あと資金調達は実績がないと難しいから、最初はすぐにお金を稼げるプロダクト開発をして、それで十分な収益をあげ、その実績から資金調達するのはどうかといった計画の話しをしていて、それはもっと難しそうだと私からは感じた。お金のためだけにやりたくもないプロダクト開発を1-2年やって、その後に本当にやりたいプロダクト開発を資金調達してからやる。それぞれのプロダクトはまったく関係がなく、組織も2つになるという。そんなやり方で成功したスタートアップを私は聞いたことがない。組織の難しさをあまりにも軽視していて無謀だとアドバイスした。

私も起業して早3年が経った。マイクロ法人だから簡単でしょと言われたらそれまでなんだけど、起業相談を依頼されるケースも増えてきた。これはこれで顧問やコンサル業ができるのではないかと少し皮算用していたりする。

納車と慣らし運転

1時に寝て7時に起きた。なんか微妙な疲れがある。

ストレッチ

今日の開脚幅は開始前155cmで、ストレッチ後159cmだった。先週と同じか。腰に張りは残っているものの、先週のような疲労が蓄積して大変な状況からは脱した。先週に引き続き、ふくらはぎの後ろ筋肉のストレッチを受けているとかなり辛い。プロのトレーナーさんなのでこれ以上は耐えられないという一歩手前のところでコントロールしている。もうちょっと続けられたらもう無理の少し手前で終わるのでなんとか耐えられている。経験上、ストレッチが痛いときほど状態が悪いという警告だと理解しているのでそれはそれで自分の体調がわかってよい。

納車

先日 購入した社用車 が納車された。年明けの出張前に駐車場の手続きをうまくやったので車庫証明も車検も段取りがうまく進み2週間で納車となった。午後から引き取りに行ってきた。いくつかの書類に署名をして印鑑を押して車の操作の説明を受けた。初めてレンタカーを借りるときにも戸惑ったが、いまは車の鍵ではなく、電子キーになっていて勝手にロックが空いたり、エンジンをかけるのも鍵をまわすのではなくボタンを押すといった仕様になっている。他にもハンドル周りにボタンがあったり、ナビゲーターのモニターにもボタンがあったりで使い方を教えてもらった。運転中は不可だが、ワンセグも入るのでテレビもみれるという。あとスマートフォンと bluetooth 接続できる。iphone なら apple music で音楽を聞いたりできる。まだ試したことはないけど、電話もできるらしい。2015年モデルの中古車でもそのぐらいの設備が付いている。ドライブレコーダーも付いていて標準のものではないので前の所有者が取り付けたものを外さずに下取りに出したと推測されるとのこと。私はまったくこだわりはないので付いているならそのまま使えばいいやって感じでラッキーに思えた。

車両状態証明書 によると総合評価点は2と高くはない。機能、内装、走行は問題ない。これは外装にいくつか擦り傷やへこみがあるためにそういった評価になっている。ただ普通にパッと見てわかる擦り傷は1箇所だけで十分にきれいにみえる。外装に擦り傷が多いために総合評価点が低く、年式が新しく走行距離も少ないにも関わらず車両価格が割安であった。そこに私のような、初めて購入して乗る車はきっとぶつけたり擦ったりする確率が高いだろうと想定しているためにまったく気にしない人間とウマがあった。

せっかくなので慣らし運転に行こうと思ってディーラーの営業さんと話していたら 西宮神社 へ行くお客さんが多いという。えべっさんと言えば商売繁盛で有名な神様だけど、交通安全祈願のお祓いもやってくれるみたい。お祓いまではお願いしなかったけど、三ノ宮から10kmぐらいの距離で20-30分もあれば行けるのでちょうどよい距離だった。お参りして交通安全のお守りを買ってきた。

今日は打ち合わせの多い日だった

1時に寝て2時、3時、6時と起きて7時に起きた。久しぶりに胃酸が逆流して気分悪かった。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。sveltekit アプリで使う ui フレームワークの相談をして、昨日の課題管理の雑談内容 からさらに考察を深めた。私の中では知っていたことだったはずなのに、いつの間にか、そのことを軽視してしまっていることを再認識したような発見だった。

コミュ障の私にとってはペアワークという概念がすっぽり抜けていたことは昨日書いた通りだが、それでもいまマネージャーとしてそれなりにコードレビューやインフラタスクに時間を割いている。プロジェクトマネジメントだけをやっているわけではない。それは自分が遊撃として開発者のメンバーを手伝っていることに相当するなと気付いて、そう言えば、過去に五月雨式にだらだらと遅れるようなプロジェクトでは、他のメンバーのタスクが遅れることを横からみているだけしかやってなかったような気がした。もし私が自分のタスクを投げ出して遅れている課題に介入したらどうなっただろうか?と思考実験するだけの余地はあった。

もう1つ。盛り上がった話しにおっさんはエモい話しをしにくいと私が考えていると伝えた。なぜなら、私の経験則ではエモい話しをするおっさんは総じてスキルをもっていなかった。具体的な知識やプラクティスを話すときはエモい話にならないからだ。その発言に対して、はらさんからはこんなコメントが返ってきた。おっさんもスキルはあるのだけど、そのスキルが時代にあわなくなって古くなってしまった。現場の技術とあわないスキルは、現場の人間からみるとスキルがない人と同じである。少し前に40歳の壁という本を読んだが、そのノリで言うと、40歳になるとスキルが現場に通じなくなる。

sveltekit アプリのデプロイ

昨日の続き。Building your app によると、sveltekit のビルドは vite と adapter の2段階で行われる。gitlab ci/cd で node.js 向けにビルドして、それを docker イメージに同梱して、コンテナレジストリに登録する。あとはテスト環境で構築している docker compose に組み込むだけ。今日中にできたらいいなと思って、ぎりぎりだったけど、テスト環境で node.js 上にデプロイしたアプリと疎通できるところまでできた。ssr を介して web api サーバーと疎通できるところまで整備した。ここから先はメンバーに管理画面を作っていってもらう。メンバーの開発着手前にデプロイが一通りできているという気持ちよさ。

起業相談

過去に働いていた会社の、私と同い年の元同僚が起業するというので相談にのることに。私が会社を作ってなんとかやっているのをみて関心が出てきたという。いきなり会社を辞めると不安だから副業から始めて、本業の収入を上回るようになったから個人事業主から法人化しようと考えているらしい。実際に会社を辞めるかどうかはまだこれから検討するのかな?本業をやりながら最大4つか5つの副業をまわしてたというから驚き。そんなこと物理的に可能なの?と思ったら開発は人を雇ってマネジメントだけやったりしていたらしい。おそらく4人ぐらい開発者を雇っているという雰囲気だったけど、それでも本業をやりながら4つもマネジメントをするのは相当に大変だと思う。十分にその同僚の能力を認めているつもりだったけれど、それ以上の忍耐や集中力をもっていて、もしかしたら過小評価していたのかもしれない。1つの会社内でも3つ以上プロジェクトを兼任して成果を出しているマネージャーなんか私は見たことない。それを本業と副業と寄せ集めの開発者で実現しているのは類稀な能力だと思う。本人も睡眠時間削って働いてやり過ぎたとは言っていたが。法人登記、税金、節税、働き方とか、ざっくばらんに私が起業してやってきた3年間のお話しをした。なにかしら役に立って活躍されるといいな。

コーポレートタスクの完遂

22時に寝て2時に起きてネットみたり漫画読んだりして6時になって7時に起きた。その睡眠不足から夕方に眠くなって17時から3時間ほど寝てた。ほぼ1日コーポレートタスクをやっていて過ぎた。この数日コーポレートタスクを集中的にやっていて効率がよかった。今後もお正月明けの最初の週はコーポレートタスクを行い、対外的なお仕事はお休みするような予定を立てられるとよさそうと思った。

保管場所使用承諾証明書の取得

昨日の続き 。便宜を図ってもらって急ぎで手配してもらった証明書を管理会社のオフィスまで取りに行く。郵送してもらうと私が来週受け取れないため、もっとも早くて確実な手段として私が大阪まで直接取りに行くことにした。便宜を図ってもらったのでそれぐらいの労力は惜しまない。9時半頃、約1年ぶりに梅田の地下を歩いてみて、まだお正月休みなのか、梅田の地下にしてはまったく人がいなかった。あまりにまばらな人影にゴーストタウンになったのかと錯覚するぐらい。管理会社に着いて証明書をいただいてすぐ U ターンしてディーラーさんへ赴き、担当者さんに納車の手続きに必要な印鑑証明と保管場所使用承諾証明書を手渡す。保管場所使用承諾証明書から警察署で車庫証明を取っていただく。これはディーラーの担当者さんが代行してくれる (要手数料) 。納車日は1月21日になった。父の35日法要で28日に実家へ帰るのでそれまでに納車ができるように調整していた。購入相談へ行ってから2日で納車手続きまで進み、想定通り、ものごとが進捗して幸せ感が高い。計画がうまく進むと幸せなんだということに気付いた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。いつもは9時から行っているが、今日はお出かけしていたので11時半から。お正月を挟んで葬儀というライフイベントもあったのでその話題を中心にしながら ビッグテックはスクラムやってない記事 の共有などを行った。はらさんの知人に コパイロツト さんという会社で働いている人がいてプロジェクトマネジメントやナレッジマネジメントをビジネス展開している会社らしい。うちの課題管理と密接な分野でもあるのでまた機会があれば一緒にお話ししたいといったことを確認した。会社ブログ でもプロジェクトマネジメントについて発信しているらしい。また読んでみて理解を深めようと思う。

償却資産 (固定資産税) の申告

社用車の納車日も決まったので 償却資産(固定資産税)の申告 を行う。eltax で電子申告 する。昨年の申告時の日記 にも書いたが、国税である法人税の節税手段としての「少額減価償却資産の取得価額の損金算入」と地方税である固定資産税の申告とはまったく関係がない。償却資産の申告書類のフォーマットはレガシーでわかりにくい。そのレガシーをそのままシステム化した eltax の画面操作も同じぐらいわかりにくかった。いくつかスクリーンショットを撮ったり画面操作のコツを課題管理システムにコメントしつつ、今期に追加した増加資産を登録した。社用車を購入したのですべての固定資産の取得価額が免税点である150万円を超えてしまった。おそらく春に固定資産税を納税しないといけないと思う。

駐車場探し

3時に寝て8時に起きた。生活リズムが乱れてきた。

コードレビュー

年末にマージリクエストが届いていたのをレビューした。http リクエストが失敗したときのリトライ処理を google-api-go-client の sdk 側に委譲できないかを調べてみた。いくつか issue も上がっているが、おそらく次の issue の結論にあるように、互換性を考慮すると既存の仕組みを置き換えられないという話しのようにみえる。

sdk としては gensupport#RetryConfig のように、ヘルパー関数は用意されていて、例えば storage サービスでは Retry strategy として組み込まれている。しかし、これが sdk の http クライアントレベルで実装されているのではなく、それぞれのサービスごとに実装されているため、サービスによってリトライの仕組みがあったりなかったり、もっと言うとサービスごとに異なるリトライ実装になっていたりする。うちらは admin サービスを使いたいのだけど、そのリトライ処理は自前で実装するしかないというのをコードを読みつつ issue を読みつつ理解した。

駐車場の契約と保管場所使用承諾証明書の手配

社用車を購入する にあたって駐車場が必要になる。駐車場は本拠地 (会社のオフィス) から2km以内に借りないといけない。候補の駐車場の管理会社とやり取りして法人名義で駐車場を借りるのは問題ないとのこと。来週は私が出張で留守なので並行して納車の手続きを進めるため、この証明書を急ぎでほしいとお願いしたら今日・明日で作ってくれるということになった。朝から何度か電話して便宜を図ってくれた担当者に感謝。

オンライン飲み会の準備

毎年のことになっていて悪い運用なんだけど、交際費の予算を30万円と見積もっている。現時点で78,913円しか使っていない。交際費の予算消化も兼ねてこれからオンライン飲み会の機会を増やしていく。過去に働いていた職場の後輩と今度オンライン飲み会をすることにした。初めてのお酒を飲めない相手ということでソフトドリンクを手配した。アップルタイザー などがよいんじゃないかと思って混ぜてみた。これが新しいオフィスから ゆうパックスマホ割 で荷物を送付する初めての事例にもなった。オフィスから郵便局が徒歩2分ぐらいの立地なので郵便を出すのも便利。ほんとうによい立地のオフィスを借りられて満足している。

会社の事務手続きで1日が終わった

0時に寝て何度か起きて8時に起きた。まぁまぁ眠れたと思う。

源泉所得税の納付

6ヶ月に1回の源泉所得税をまとめて納付する。前回から web 版をやめて e-Taxソフト という、windows マシンにインストールして使うアプリケーションを使うようにしている。20年前の visual basic で作ったような年代ものの saas アプリケーションになる。前回送付したデータが残っていたのでそれを開いて別名保存することで前回の送付データを再利用できた。役員報酬は毎月定額で社員も私1人なので6ヶ月分の源泉所得税は年末調整の金額分がずれるだけ。ほとんど同じ書類を申請するので対象月と金額の違いだけ更新すればすぐに作成できる。過去の作業手順を確認しながらやっても10分で完了した。

給与支払報告書の申告

eltax の windows アプリケーションになる PCdesk (DL版) を使って申告する。当初は紙の書類で申告していたのを 昨年から eltax で給与支払報告書を申告する ように運用を変えた。昨年は先に e-tax で税務署向けに源泉徴収票を申告していたため、e-tax と eltax で別々に作業した。今年は 給与支払報告書と源泉徴収票の同時提出 をやってみることにした。この作業を eltax では「一元化」と呼んでいる。ユーザーにとっては申告作業そのものが半分になるので大きな効率化になる。うちは社員が私1人だけなので源泉徴収票の内容をアプリケーション上で手入力している。過去の作業手順とユーザーマニュアルを見返しながら、途中のスクリーンショットも撮りつつ、それでも1時間弱で申告できた。e-tax への送付データの受付確認は e-tax にログインしてメッセージボックスを確認してとあったので、eltax のソフトから e-tax の api (インターフェース) にあわせて申請データを送付しているのだろうと推測する。とくに問題なく一元化できた。2回目でさらに理解度が増したので来年は30分ぐらいでできるんじゃないかと思う。eltax のアプリケーション e-tax と比べて、相対的にアプリケーションがモダンなので作業していてユーザー体験がよい。eltax で作業するのは苦にならない。

経営セーフティ共済の前納

昨年も3月に前納 (一括納付) している ので、今年度も同様に 掛金の前納 を行う。銀行の窓口へ行って書面で手続きを行う。これがすんなり進まず骨が折れた。窓口の担当者も経営セーフティ共済の手続きをよく知らなかったようで前納の申請書の用紙がないとバタバタしていた。この時点で小一時間ほどかかった。用紙は入手できたものの、オフィスの住所変更をしたので一括納付の前に住所変更しなければ受け付けできないということになった。やはり窓口の担当者がよく分かってなくて、中小機構に確認して住所変更してください。住所変更は銀行ではできませんと言われたものの、中小機構の 事業所の住所変更 を確認すると「金融機関の窓口に書類を提出してください」と書いてある。それを説明したらやっぱりできますという話しになって、住所変更のための書類を集めてきて、住所変更と前納の2つの申請を同時に行うことで受付してくれた。私が懸念に思ったことを質問すると、確認しますと裏へ回って中小機構に電話してたんだと思う。銀行も中小機構の仲介を本当はやりたくないんやろなと伺えるほど運用の段取りが悪かった。待ち時間や書類集めでオフィスと銀行を3往復してこの手続きに3時間ほどかかった。

社用車の購入相談

近所のカーディーラーへ行って中古車を購入したいと相談してきた。あらかじめ車種は決めていたし、ネットで相場や予算の目安も決めていた。中古車を店員さんと一緒に眺めながら、店員さんからみた中古車を購入する上でのアドバイスをいくつかもらってエイヤで決めた。色はブルーがよかったんだけど、選択の余地がなくてシルバーになった。いつか新車を購入できる余裕が出来たときにとっておこう。その後、契約の手続きもすぐに行ってくれて小一時間ほどで商談が成立。オフィスに帰ってきてすぐ法務局へ行って印鑑証明を取得した。あとは駐車場を借りたら納車の手続きを進めてもらうための書類がすべて揃う。

購入費用を振り込みして契約書を眺めながら固定資産台帳に登録する。中古車を購入したときの減価償却はちょっとややこしい。普通車の耐用年数は6年になる。中古車で6年以上経っているものを購入した場合、次の計算式で2年として扱われる。

6年(法定耐用年数) x 20% = 1.2年 => 2年

耐用年数を2年として減価償却するときに定額法と定率法がある。後者の方がより多くの経費を早く減価償却できる。たった2年なのでどちらでもよいのだけど、利益に余裕があるならなるべく減価償却した方がいいかと考えて定率法を採用した。

仕事始め

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 のチュートリアルで学ぶ

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>

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

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

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 でできた方がマニュアルを作る上でも簡単だし作業ログも管理しやすい。