23時に寝て3時と5時に起きつつ7時に起きた。21時半には出張から家に戻ってきて天気がよかったらオフィスへ行ってたんだけど、雨降りだったのでそのまま寝てた。今日もストレッチを終えてから読書会に参加したらその後は眠くなってしまって家に帰って寝ていた。ストレッチと読書会しかやっていないのに一日の体力を使い果たした状態になるぐらいの疲労が蓄積している。

ストレッチ

今日の開脚幅は開始前155cmで、ストレッチ後159cmだった。数字の上では先週と大差ないのだけど、疲労の蓄積で右腰と右股関節周りが大変なことになっている。久しぶりにストレッチを受けていて辛くて耐えきれないところの一歩手前まで到達していた。ふくらはぎとか限界に近かったが、なんとか耐えきった。出張前に懸念していたことでもあったけれど、結果として、出張前のストレッチで復調しつつあった体調は悪化したと言わざるを得ない。たくさん歩いたことや慣れないホテル暮らしで腰と右足に負担がかかってしまった。

オンライン読書会

先月はオフィスの引っ越しで不参加だったため、1ヶ月飛ばしで 第6回『Go言語による分散サービス』オンライン読書会 に参加した。本書の読書会は今日で最後の読書会で次の2章を読んだ。

• 10章 Kubernetes でローカルにアプリケーションをデプロイ
• 11章 アプリケーションを Kubernetes でクラウドにデプロイ

10章では kind というローカル k8s クラスターを構築するツールを使って go アプリケーションをデプロイする。データベースのようなデータを永続化するようなサービスのためのリソース種別に StatefulSets がある。私は使ったことがないリソース種別だったのでキーワードを知ることができてよかった。jsonnet というデータテンプレート言語というツールも出てきて、なんだこれは？と思ってびっくりした。これも初見だし、使っている話しも聞いたことなかった。本書でも k8s については書籍を一冊書いても足りないと説明されていて、アプリケーションのデプロイに必要な k8s マニフェストの説明を10章だけでやって、ほとんどの読者は置いてけぼりだと思う。k8s の運用経験のある私が読んでも yaml の正当性なんて動かしてみないとわからないし、k8s はバージョンアップが速いのですぐに陳腐化する可能性もある。helm のパッケージングなどにも触れていてキーワードを知るという意味ではよかったと思う。この2つの章は k8s へのデプロイはこんな感じですよという雰囲気を味わってもらうお気持ち程度の内容だと思う。

15時頃には読み終えて、それから8人ぐらいで雑談していた。私は書籍の組版を自分でやったことはないのだけど、しばたさんは出版社によっては自分で組版までやって pdf で納品しているらしい。現行は tex で管理しているようにみえる。余白の調整や索引作るのも自分でやっているらしい。ある本は後になってから出版社の規定している余白よりも広過ぎてページ数が増えたことに気付いて、その後の本で余白を調整したりしたとのこと。本来はそういうお仕事は編集者のお仕事ではある。とくに索引は数ページになったりするので大変といった話しをされていた。effective java 第3版だと索引だけで9ページある。

0時に寝て6時半に起きた。2時か3時頃に急に咳込んで飛び起きてコロナ感染したんじゃないかと危惧したけど、5分ほどしたら治ってその後もなんともなくなった。よくあるたまに吐き気がして起きるときの咳き込むバージョンだったのかな。たぶん胃食道逆流症のせいだと思うけど、慢性化しつつあるので余裕のあるときに病院でみてもらった方がよいかもしれない。

rabbitmq の exchange/queue の初期化

docker compose で環境構築をするときに rabbitmq の exchange/queue の設定を初期化したい。調べてみると Schema Definition Export and Import という仕組みを使うのがよさそうにみえた。推奨方法としては rabbitmq クラスターが起動した後、管理ツールで definitions.json をインポートするのがよいとある。別のやり方として設定ファイルに definitions.json へのパスを記述しておくと、rabbitmq プロセスの起動時にインポートしてくれるという。このやり方だとプロセスの再起動時にも毎回インポート処理が実行されるので初期設定の定義が大きくなるほど起動処理のオーバーヘッドが大きくなるというデメリットがある。またクラスター環境だと、それぞれのノードでの起動時に同じインポート処理が実行されることになるのでそのオーバーヘッドの分だけ効率が悪い。いま作っている環境はオンプレ向けの1つの rabbitmq サーバーのみだし、初期設定の定義もシンプルなので起動時のオーバーヘッドはとくに気にしなくてよいだろうと考えている。

definitions.json は、あらかじめ rabbitmq の exchange/queue の設定を手動設定した後、管理 API を呼び出して取得したものをベースに不要な設定を取り除くと生成できる。

$ curl -s -u "guest:guest" -X GET http://localhost:15672/api/definitions | jq .

ビッグテックのマネジメント勉強会

出張前の事前に資料作り しておいた勉強会を開催した。出席者の大半はリモートから参加しており、オフィスの会議室では私と他に1人だけだった。毎月1回、私がオフィスに出社するタイミングで質疑応答しやすいように課題管理勉強会を設けているのだけど、最早私がその場にいる必要性もなくなってきた雰囲気はある。リモートワークが定着している会社であり、私自身フルリモートで働けるよう、自分の働き方をリモートワーク向けに調整しているから当然の帰結とも言える。

勉強会の内容は基本的にブログ記事の内容を紹介するものだったので文字数が多くて口頭で説明するのが大変だった。勉強会の中でもっとも盛り上がった議論は自律性というキーワードを得るのに必要なものはなにか？といったもの。ある人はその人の性格や才能といった先天的なものではないかという。私はそう思いたくなくて、プログラミングは後天的なスキルなので開発者が自律性をもつかどうかも後天的なスキルだとみなしたい。そこに環境や組織やライフステージの変化なども関連して自律性をもつ開発者とそうじゃない開発者に分かれていく。もっと言うと自律性は優秀さとも異なる。頭がよくて理解力の高い人が自律性をもたないことも多くある。これは永遠のテーマだと思う。

もう1つ盛り上がった議論として優秀でも成果を出せない人がいるという話し。私も前職で何人もみてきた。頭もよく話すと正しいことを言っていてやることも理解しているように聞こえるのにほとんど動くモノを出せない人たちもいる。プライドが高くて途中段階の成果物を他人にみせられない結果として成果をあげられないのではないかという意見もあった。そういうのはどちらかという年配の人に多い傾向がある気がするけれど、若い人たちでもそういう病にかかってしまうこともあるのだろうか。

前日は週の中日でバテ気味だったから20時ぐらいから横になって途中起きつつ7時に起きた。体力回復した。

プロジェクトの進捗報告

月例報告の2回目。前回の進捗報告はこちら 。12月でバックエンド開発をすべて完了できたわけではないが、十分な開発の成果は出ていて、私が品質面から issue を作ってやいやい刺激を与えているのも着実に fix してくれているので及第点は余裕で超えている。遅れているのではなく、見積もりが甘くて量を増やした分すべて終えられなかっただけと捉えている。メンバーも自分から issue を作ってリファクタリングするようにもなりつつあり、先月よりも開発のワークフローに馴染んで洗練してきているようにみえる。これは時間とともに一定量はパフォーマンスが上がるので来月ももう少し上がるかもしれない。

私が日常的に行っている課題管理も好評で他部署でも参考になっているという話題もあった。私は issue のタスクをこなしながら、調べたこと・実際に動かして検証したこと・エラーになったこと・思ったこと・わからなかいことなど、何でもコメントとして書いていく。ざっと過去の私が担当した issue を眺めると1つ辺り10-50個ぐらいのコメントをしている (メンバーからのコメントも含む) 。コメントでやっていることをみえるのがよいという意見もあった。プロジェクト内の情報共有や非同期コミュニケーションを活性化する上で課題管理システムの issue にコメントを書いていくのは優れたプラクティスだと私は考えている。課題管理をやったことがない組織やチームのメンバーはだいたいコメントを書いていなくて、私が見本をみせてその価値に気付く。その価値に気付いたメンバーが模倣してやることでさらに情報共有が促進されて課題管理がよくなっていく。自律的にできるメンバーは放っておいてよいが、これから先はそれをうまくできないメンバーに対して指導していく必要がある。一方でこれは相当に難しくて、ここがうちの会社のビジネスや私のマネージャーとしてのキャリアで乗り越えないといけない壁になる。

納期までの期間のうち、いま1/3が過ぎた。私の中ではこのプロジェクトマネジメントはもう見通しが立ってしまった。バックエンドの開発がほぼ完了していることからコア機能の開発をほぼ終えた。これから開発するフロントエンドは未経験だけど、コアではないのでそれほど難易度は高くないと考えている。中核となるメンバーが開発ワークフローに習熟してきて自律的に開発してくれている。油断したりさぼったりしない限りは確実に納期までに満たすべき品質基準は達成できるだろう。納期まで残りの2/3の期間で私がやっていくことは、どれだけ品質を向上できるか、次のロードマップ開発向けに準備できるか、メンバーの成長のために知識やスキルを共有できるかといったことに注力していく。

2時半に寝て7時に起きた。なんか意味なく夜更かししたもののよく眠れた。

svelte 調査

年末から svelte のチュートリアル を始めたものの、葬儀と年末年始休暇で間があいてしまった。年始やもくもく会でも少しずつやっていたものの、今日で終わらせようと最後の方は少し端折りつつチュートリアルを終わらせた。svelete と sveltekit の2つのチュートリアルをやっていて時間がかかった。svelte のシングルファイルコンポーネント (SFC) は vue.js とよく似ている。スクリプトやテンプレートの構文が違う程度の印象。vue.js よりもスクリプトやテンプレートの記述がシンプルな分、やはり簡単に思える。svelte の作者である rich harris 氏が書いたメモに次がある。

• Rich-Harris/what-is-svelte.md

大雑把にまとめると次のようなことが書いてある。

svelte を ui フレームワークとして開発してきて、svelte 3 で svelte は言語だと気づいた。リアクティブな ui を記述するための言語であると。これまでそういった取り組みをしてきたプロジェクトはいくつかあるが、どれもコンパイラ以上の専用ツールが必要になってしまい、すべてを制御する必要があって、ライブラリの段階的な採用などもできないために大掛かりには導入されなかった。

html, css, js という多くの開発者が蓄積された経験をもっていて、小規模に段階的に導入するには、それらの言語をハックして拡張するのがパフォーマンスもよく、もっとも優れた解決策であると考えるに至った。

実際に svelte のチュートリアルをやってみると、その簡潔さから rich harris 氏の言葉も理解できる。開発者によっては svelte コンパイラが拡張している javascript の構文や機能を受け入れられない人もいるだろう。純粋な javascript を書きたい人には向かないライブラリかもしれない。そこがリアクティブな ui をコンパイラレベルで実現するためのトレードオフと言える。だから svelte は javascript のハックも含めての言語なのだという解釈になる。

23時に寝て6時半に起きた。前日飲み歩いてホテル着いたら酔いつぶれてバタンキューで寝てた。コロナ禍で飲み歩くことがなくなってたのでこういう寝方もすごく久しぶり。

ドーミーイン池袋

自費で泊まる宿泊先を選ぶときにふと 大浴場 があるところにしようと思った。昔は大浴場があって部屋のお風呂がないホテルの方が宿泊料金が安い傾向があったからよく泊まっていた。最近はそういうホテルが淘汰されて、カプセルホテルに近いものと大浴場がセットになって、普通のホテルは大浴場があるところが減ってしまった。あってもそれを付加価値として通常よりも料金が高めになっているようにみえる。大浴場があって宿泊料金が高くない候補の1つにドーミーインがある。予約が空いていたのが池袋だった。

せっかく大きいお風呂に入ろうと予約したので朝起きてから入ってきた。早朝なので空いててほぼ貸し切りのように広いお風呂に浸かれて快適だった。お風呂を出た隣には漫画スペースもあって時間があれば漫画でも読みたい気分になった。部屋に戻ってきて荷物を整理して出掛けようとしたときにおもてなしがあることに気付いた。冷蔵庫をあけたらプリンがあって、ちょっと固いプリンだったけれど、おもてなしの配慮が嬉しくてよかったと思う。ドーミーインはコストパフォーマンスに優れていて設備も配慮も行き届いていてよいホテルだなと改めて感心した。

製品カタログのたたき台作り

合間にコードレビューなどをやりながら、製品カタログの資料作りをしていた。作業を進めているうちに、私は顧客のことを知らなさ過ぎるのでどういった内容が顧客に訴求できるのかわからないことに気付いた。そこで作業の目的を変更して、製品カタログの叩き台を作ることにした。この資料から顧客のことをわかっている人が訴求点を改善してさらに洗練させてほしいという意図で作った。叩き台の叩き台の時点で公開して、メンバーにレビューもしてもらいながら指摘事項を直したりしていた。後日、プロジェクトの進捗報告とともに経営者に説明する。

7時に寝て9時半に起きた。昨日は遅くまで起きてたのでこのまま寝たら寝坊する懸念が高かったからそのまま起きてて6時55分の新幹線に乗って移動中寝てた。祝日だったせいか、新幹線は空いてて快適だった。

もくもく会

出張もくもく会 を開催した。品川駅から飯田橋駅へのアクセスが予想外に悪くて30分ほどかかって10分ほど遅刻した。5人ほど部屋の前で待っていて悪いことした。午前中は8人参加していて、みんなそれぞれの課題をもってきて取り組んでいた。午後から1人来られた。参加者は全部で9名だった。参加者の属性も時代の変化を表していてデザイナーやプログラマーにジョブチェンジして勉強していますという参加者が数名おられた。私は svelte のチュートリアルをいくつかやっていた。あまり寝てなかったので15時頃は眠くてほとんど作業にならなかった。16時頃から眠気も覚めて本を読んでいた。17時30分まで借りていたが、17時過ぎには撤収して軽く飲みに行った。9名中7名が参加してくれていろんなお話が聞けて楽しかった。コロナ禍前の勉強会の雰囲気に戻ってきた。

会場は スペースアイエレガンス飯田橋 という貸し会議室を借りた。10時00分から17時30分まで7.5時間借りて税込7,425円。他の貸し会議室に比べると安い方に分類される。ワンルームのマンションの一室を貸し会議室にアレンジしたような部屋で築年数は感覚的に15年以上は経っているのではないか。古い。机に向かって座れる定員が10人。パイプ椅子が4つ置いてあって座れる定員は14名。部屋はやや窮屈で机に10人が向かって座るといっぱいいっぱい。3人掛けの机は間を空けて2人で座るのがよさそうにみえた。快適にもくもく会をするなら8人の定員が望ましい。トイレは普通。wifi の速度は200Mbps程度で十分に速かったし、8人接続していても安定していた。エアコンも普通かな。部屋が狭さに対してエアコンは有効で寒いということはなかった。

フリーランス、４０歳の壁

フリーランス、４０歳の壁 の後半を読んだ。

• 「第8章 都築響一 還暦を迎えても奔放なフリー人生。」
• 「第9章 フリーランスの上がりとしての創業社長。」

都築氏は1956年生まれて私よりも2周り近く上なのでさらに昔に活躍された方のようだ。 現場主義な方で実際に起こっている事実を観察して自分なりの解釈や判断でフリーランスとして活躍された方のようにみえる。本書に出てくるフリーランスの方々は私からみてあまりピンと来なかったのだけど、この方の生き方や考え方がもっとも私に近くて参考になった。

編集者と作家を兼ねるこういう仕事スタイルをとる人を、私は「編集家」と呼んでおり、自分自身の肩書きにも使っています。都築響一さんは、私の定義を完全に満たした「編集家」です。

やりたいことがあれば自分で試してみて試行錯誤しながらやっていく雰囲気を感じる。都築氏は仕事で大変なことはあったが、壁には当たったことはないという。ある歳を境に仕事が減ることもあったそうだけど、ネットが年齢差や対面でのお仕事を不要にしたという。

僕は、過去に仕事が途絶えることもありましたが、壁だとは思いませんでした。仕事がない時期にこそ、はじめて自分にとって大切なもの、必要でないものが見極められるんです。そのときは大変でも、後になってみたら、立ち止まって考える時期を持つことは大切かもしれません。

こういう考え方も私の好み。ピンチはチャンス。

「違いますね。（大手は）給料が良すぎるっていう、それだけが問題なんですよ。その若い社員編集者も、会社に不満があるのなら、辞めて自分の会社を作れば良いんです。でも、高い給料を捨ててまで自分の道を貫こうという気迫がない。僕もいまの出版界に不満はありますよ。だからこそいまの僕は、自分で直販の道を探して、メディアを作っているわけです。」

若い編集者が上司の愚痴を昔とは時代が違うとこぼしているのに対する答え。もともと会社に頼っていない人間だからこそこういう考え方ができる。私も不満があれば区切りのよいところで会社を辞めてきた人間なのでこういう姿勢も似ている。ググるとインタビュー記事をみかけたのでまた後で読んでみようと思う。

• 普遍、あるいは洗練について。

最後の章は著者が会社を作ったときの話し。最初の起業は大失敗したものの、なんやらかんやらでなんとかなってますといった雰囲気。著者は会社員はできなくても社長ならできるという。創業社長には発達障害だと思われる人がたくさんいるとも書いている。これは流石にバイアスが強過ぎると思う。会社を作ることは誰でもできるが、ある程度長く会社を存続できる人は少ないし、その続けられている人の割合に発達障害と思われる人はずっと少ないと思う。たまたまそういう属性の人が活躍すると有名になるだけで多くの創業社長は普通の人だと思う。一方で橘玲氏の本にもよく出てくる話しだが、日本は解雇規制がために中途採用の敷居がとても高いため、経歴がよくない人は年齢とともに転職がとても難しい。そんな経歴のよくない人でも会社は作れて、取引は法人を介して行われるので個人の経歴を隠蔽もしくはリセットできるという側面をもっている。だからフリーランスの上がりが創業社長なのではなく、経歴の悪い人が最後に働く手段が創業社長なのだと私は認識している。

期待した内容ではなかったものの、賛否も含めて示唆に富む本だったと思う。また余裕があれば書評をブログの記事として書こうと思う。

1時に寝て8時に起きた。午前中は洗濯して普通にだらだらしてた。

課題管理勉強会の資料作り

12月から読み始めた Gergely Orosz 氏の記事 をベースに来週の勉強会の資料を作った。もう少し推敲はするが、スライドで全32枚になった。ブログ記事の内容を解説するスライドなので文字が多い。1時間の枠には十分に耐えそう。この資料と前回の勉強会の資料の2つを知人とオンライン飲み会するときの話しのつまみに使う。毎月、課題管理の文脈で勉強会を行う労力はそこそこあるけれど、コンテンツが溜まっていくのは未来への投資になるので困ることは何もない。課題管理の勉強会があるという機会そのものに感謝する。

フリーランス、４０歳の壁

フリーランス、４０歳の壁 の中盤を読んだ。

• 「第5章 田中圭一 サラリーマンとマンガ家を両立させる男。」
• 「第6章 『電脳マヴォ』と私の未来。」
• 「第7章 FROGMAN アニメ界の革命児が直面した「30歳の壁」。」

平日はサラリーマンで営業として働き、休日を利用してマンガを描くという働き方を30年以上している田中圭一さんのインタビューがある。30年以上と聞くとすごいことでその実績は否定しようがないと素直に思う。一方でうちは兼業農家だったので平日はサラリーマン、休日に農業をするのは普通だった。父はその生活を42年間していた。またうつ病になった経緯のエピソードがある。ある会社に転職して最初のうちはうまくいったが、5年目ぐらいで行き詰まってしまった。技術系の会社でプログラミングを学ばないといけないという空気があったらしい。会社の仕事があわないと田中氏は思いつつも転職する自信をもてず、そのまま10年いてうつ病になってしまったとのこと。これが3ヶ月だったら大変だったんだなと思う。しかし、厳しい言い方だけど、行き詰まりは仕方ないとしても5年もなにも対策しなかったの？と私なら思ってしまう。ここだけ読むと未知のことやスキル不足を勉強しない人の典型例だと思えてしまった。本業で成果を出せていないのに転職できないから会社に残り続ける人たちを私も少なからずみてきた。助言や提案をしても、例外なく、そういう人たちはできない理由を熱心に説明し、自ら努力してスキルを習得しようとはしなかった。できる・できない以前にやろうともしなかったのをみてきた。

著者が運営している 電脳マヴォ という web マンガのサイトがある。たまたまリンクをみつけた 良い祖母と孫の話 を読んでみたら衝撃をうけた。こういう才能がたくさん埋もれているというのは理解できる。一方で漫画を描くことが以前よりも一般化したのだとも私は思う。どんな業界も人気が出たり市場規模が大きくなるにつれその創作者人口は増える。電脳マヴォを創刊したのが2012年だったらしく、奇しくもその頃が「ネットマンガ元年」と呼べるらしい。となりのヤングジャンプ や マンガボックス など、私が知っている web マンガのサービスも出てくる。

フリーランスの最大の営業は、仕事そのものです。 版元編集者は、そのフリーが実際に行った仕事を見て、次の仕事を発注するのです。向こうから来る仕事であれば、意に沿わない仕事は、断ることもできます。持ち込みだと、まさかこちらから断るわけにはいきません。

この考え方は私も同意する。取り引きをしている会社とのお仕事を高い品質で行うことがもっとも重要だと私も考えている。

FROGMAN さんという方を私はまったく知らなかったけれど、インターネットの黎明期 (2000年頃) に動画配信サービスをやろうとして FLASH アニメで一山当てた実業家らしい。その経歴も破天荒にみえる。もともと映画業界で働いていて、映画業界の没落とともに半ば強制的にフリーランス (リストラ) となり、業界としての先行きは不透明だった。島根の山奥に移住し、インターネットに動画を配信する仕事なら島根でもできるだろうと考えたとのこと。これを2000年頃に実施しているのだから素晴らしい先見性と言える。その延長でアニメ制作をするにいたったのも、奥さんが妊娠して出産費用が必要となり、1人で仕事を完遂できればコスト削減できるというアイディアでアニメ制作を始めたとのこと。実写は最低でも数人のスタッフを必要とするが、アニメなら1人でできるのではないか。実際に初期のインターネットの FLASH アニメを1人で作って人気を博して事業が軌道になったらしい。スポンサーを募らず、徹底したコスト意識から権利をスポンサーに渡さないことを意識していた。2006年頃に youtube が台頭したときも、他のアニメ会社が映像を勝手にあげられるのを嫌ったのに対して、FROGMAN さんの会社は自分たちが権利をもっているので自分たちの作品を率先して配信し、時流にも乗ったようにみえる。FROGMAN さんは絵もろくに描いたことがなく、アニメマニアでもないにも関わらず、まさにビジネスモデルの勝利と言える。また実写業界での経験があったから普通のアニメ会社が作るようなアニメとは異なる作品を作り、アニメ落語・アニメ漫才というジャンルそのものを作ってしまったという。きっかけは家賃を半年間滞納して出産費用を捻出するためという、ピンチをチャンスに変えた事例の1つとして、また製作委員会方式というアニメ業界のモデルとは異なるビジネスモデルを考案して実現してしまったところもサクセスストーリーとして痛快に読めた。

1時に寝て7時に起きた。夜遅くに晩ご飯を食べて気付いたら寝てた。

ストレッチ

今日の開脚幅は開始前154cmで、ストレッチ後160cmだった。年末の葬儀で不摂生、且つ身体に負担のかかる状態で3日間を過ごし、その影響で腰や右足周りに負荷がかかっていた。それは正月明けからもあまり予後がよくないなと思いながら過ごしていた。年末はストレッチを1回休みで2週間ぶりに行った。懸念しているところはトレーナーさんからみてもあまりよくないということでいつも通りストレッチで伸ばしてもらって少し楽になった。一方で正月明けはあちこちお出かけして平時よりも歩く機会が多かったので運動量は多く健康的な生活を送っていた側面もある。悪いことばかりでもない。来週は東京出張が控えていて体調がよくなるか悪くなるか、まだなんとも言えない見通しではある。

フリーランス、４０歳の壁

フリーランス、４０歳の壁 の前半を読んだ。

• 「第1章 自由業者フリーランス・40歳の壁。」
• 「第2章 とみさわ昭仁 「好き」を貫く代償。」
• 「第3章 杉森昌武 フリーランスとは自分で選択する生き方のこと。」
• 「第4章 50歳の壁はさらに高い。」

1980年代からのそれぞれのフリーランスの半生を紹介している。いまとは時代の違いがあるため、理解が難しい状況や雰囲気などもある。大雑把に言えば、人生の落伍者の半生、そういった人たちがやってくれたのは時代背景とフリーランスという生き方だったからだといった切り口で展開される。普通のサラリーマンとして働きつつ組織に馴染めずに辞めてきた私とはまったく相容れない生き様や考え方があって素直に受け入れ難い内容ではある。まったく生き様が異なるのに、読んでいていくつか共通項を見いだせるのは、ひとえに組織や集団に馴染まないという性格や特性によるものだと思える。彼らも私も、自分自身が納得いかない論理や仕事をずっと続けられないという点で合致している。それが生活の先行きを不透明にしていても。

ここまで読み進めて40歳の壁も50歳の壁も、一般人の感覚からしたら壁でもなんでもない。著者は恵まれた環境が与えられているにも関わらず、自らがその環境を投げ出し辞めていて、それを壁があるからと表現しているに過ぎない。身勝手で努力不足にもみえるが、全力で擁護するとしたら、組織に馴染まない人間はそうせざるを得なくて他の選択肢などない。だから壁に突き当たってしまうという主旨に読める。

参考になる内容や共通項はあるのでいくつか引用してみる。

そこで浦沢さんはまず「戦略的に」受けを狙って『ＹＡＷＡＲＡ！』をヒットさせ、圧倒的な実績を築き上げることで、「描きたい作品が描ける」作家に自分を鍛え上げたと言えます。これは誰もが考えますが、実現は至難の技です。私はあそこまで商業作家としての戦略を立て、実行し、成功した作家を見たことがありません。作家はつい「自分の描きたいものを描くんだ！」と思いがちですが、 プロ作家として成功するためには、自分の苦手なものでも描かなければならないことがあるのです。芸術家肌の作家と、プロ作家は違います。浦沢さんは、ほんもののプロ作家だと私は思います。

浦沢直樹 さんの凄さを説明している。浦沢さんはもともとデビューして「MONSTAR」のような作品を描きたかったが、新人が描くには編集者の反応は芳しくなかったという。そこで苦手だったが、当時流行りの美少女ものを選び、「YAWARA!」「HAPPY!」とヒットさせることで人気を盤石にした上で本当に描きたかった「MONSTAR」に取り組めたという。it 業界で例えたら、受託開発でお金を稼いでいつか自社プロダクトまたは自社サービスを提供したいと考える会社はたくさんあれど、それで成功している会社は本当に少ない。まさに誰でも考えるが実現は至難と言える。

フリーにとっての40代は、自分の「マンネリズム」との戦いだと言えるかもしれません。 作家を含めたフリーランスは、ふたつのタイプに分けられると思います。 ひとつのパターンの仕事をえんえんと続けることができる「職人タイプ」と、つねに新しいテーマや手法を開拓しようとする「芸術家タイプ」です。 もちろんどちらのタイプにも勉強・研鑽が必要になります。

フリーランスに限らずサラリーマンも同じだと思う。40代は出世競争の結果が出てから敗れた人たちがどう生きていくのかに近いものがある。私はわりと両方の特性がある方な気がするけど、どちらかを選べば「芸術家タイプ」なんだろうと思う。

少なくとも 私は、ブログを書き続けたことで、40歳以降におちいっていたスランプから脱出することができました。

この一文に関心を示す人とそうではない人に分かれると思う。まだ論理的に説明できないが、私は書くことをずっと続けることに大きな意義と実利があると考えている。書くことをやめた人たちが悲惨な状況に陥っているのをみかけることもたまにある。私も日記を書き続けて人生が安定したように考えている。日記を書くことに時間を取られる分、個々の業務のパフォーマンスは下がっているけれど、人間としてのパフォーマンスが安定するようになった。まだ感覚的にしか表現できない。

私にとっては、お金より、やりたいことがやりたいようにできるかが大事で、それができなかったら、仕事をなげうってしまうのです。その後、どうなるかなんておかまいなし。後悔もしません。

この一文も共感できる人とそうではない人に分かれると思う。私はまったく共感できる。

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 の結論にあるように、互換性を考慮すると既存の仕組みを置き換えられないという話しのようにみえる。

• Provide a way to easily retry transient errors #142

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

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

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

オンライン飲み会の準備

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

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年なのでどちらでもよいのだけど、利益に余裕があるならなるべく減価償却した方がいいかと考えて定率法を採用した。

• 自動車の耐用年数や計算方法など、自動車の減価償却の仕組みとは【税理士に聞く】