Posts for: #2022/09

台風待ち

#document 

0時に寝て7時に起きた。台風がやってきそうでなかなか来ない。2日前から警戒して備えているのに今朝時点ではまったく平気。朝起きて雨だったら休もうと思っていたものの、雨がやんでたからオフィスきて一仕事してきた。

ドキュメントを書き終えた

5日以上に及んだ 非開発者向けのインフラドキュメント を書き終えた。他にもいくつかインフラのドキュメントの加筆や推敲もしていた。叩き台としてそれなりに伝えたいことは書けた。あとは勉強会をしながら出てきた話題や質問などを参考にしながら推敲していくだけ。

一日中議論してた

#founding  #finance  #tax  #scrum 

1時に寝て7時に起きた。

会計監査と数字の着眼点

note で300円で販売している記事をみかけた。監査法人に勤めていた公認会計士が勝手にレビューしてみた的な記事になる。

タイムラインでみかけたことをきっかけに私も過去3年分の会計報告を眺めたり、社内コミュニティで時事問題として取り上げていたので関心があった。経営者として他社の財務諸表をみる機会は私もあるので、会計士さんがどういった数字の見方をするのかの視点はとても勉強になった。現時点で不正をしているという話ではなく、会計報告からみえる数字だけを追いかけても経費の数字のいくつかに不可思議なところがあるという会計士からの指摘だった。ヒアリングすれば解決するかもしれないしそうじゃないかもしれない。一方で国や都からの少なくない金額の助成金 (税金) を受け取っているので会計報告に不明瞭なところがあるのであれば、精査して説明責任を果たす必要はあるだろうというのは一般的な共通認識ではないかと思う。

スクラム雑談

【三宮.dev オンライン】語り合おう！スクラム開発雑談会！ に参加した。常連のメンバー3人で話し始め、途中から主催者の先輩が加わって、sier のマネジメントのしんどい話しみたいものになって、最後はフロント／バックエンドの技術談義とかハックバーどうよみたいな話しになって、まさに雑談イベントみたいなものになった。ニフティのスクラム という本があるよと教えてもらって無料なので読んでみた所感をつぶやいたりもしてみた。あるイベントでも スクラム雑談 をしていて気付いたことの1つに、スクラムうまくいかない話しの大半は、スクラムというガイドライン上に洗い出された組織の課題を議論するようになるのではないかと思う。組織の課題の洗い出しにスクラムは使えるが、スクラムをやれば組織の課題を改善できるわけではないとわかってきた。

ドキュメントを書いてマンガを読んで

#life  #document 

0時に寝て7時に起きた。

ストレッチ

今日の開脚幅は開始前160cmで、ストレッチ後163cmだった。今週も調子がよい。やはり涼しくなって日々の生活の快適度があがって体調もよくなっている気がする。ストレッチを受けていてもあちこち調子よくていい感じにストレッチできているように思う。これで少しジョギングや運動をするといいんだろなという気持ちになってくる。これまでも暑い夏はあったと思うが、今年ほど夏の暑さにまいって集中力を欠いた年はなかったと思う。というのは、日記を1年近くも毎日書いたことがなかったからその変化に気付けたことも過去になかった。日記を書く過程で環境や状況の変化に敏感に気付けるようになったという背景もある。他の要因としては歳をとって体力が落ちているのだろうと推測する。落ちた体力をカバーするだけの取り組み (運動するとか摂生するとか) が必要なのだろうけれど、私は昔と比べて生活の姿勢をとくに変えていない。もうそろそろ不摂生がダメなんだろうなという自覚は出てきた。昨年からストレッチを始めたのは本当に僥倖で健康度はいくらか上がっていると思う。

まだドキュメントを書いている

非開発者向けのインフラドキュメント がなかなか完成に至らない。厳密に書くわけでもなく、嘘を書くわけでもなく、重要なことのみを専門用語を使わずに技術知識がない人たち向けに書くドキュメントは相当に難しい。どういう構成にするかも何度も試行錯誤しているし、説明のための文章量も増えてしまうところがある。インフラを知らない開発者向けに引き継ぎのドキュメントを書くよりもずっと大変だと3日も書いているのに書き終わらない (自分で納得がいかない) 事実から認識できた。書いて読まれるのかどうかもわからないけど、それは読み手の自由であって書き手は自分が伝えたいことを自分の言葉で書くことに意味があるだろうと考えて、いまの自分ができる精一杯のドキュメントを書こうと思う。

葬送のフリーレン

夕方から 葬送のフリーレン を7巻ぐらいまで読んだ。これまで1巻を無料キャンペーンで読んだことはあったし、人気があることも知ってはいたけどいつか読もうぐらいの感覚だった。毎日 LINE マンガで 神之塔 を読んでいて、たまたま2巻も無料化されたのを見かけて読んでみたらおもしろかったので、いつかはいまだと認識して電子版を購入して読み進めた。

葬送 という言葉も私は知らなかった。「死者と最後の別れをし、火葬場、墓地に送り出すこと。」を指す言葉らしい。マンガのタイトルから「葬送のフリーレン」という物語だよというのは、内容から妥当だと思うものの、これは物語の世界の中でもフリーレンの異名として魔族が呼んでいる。私はてっきり勇者ヒンメルとの思い出を辿る旅全体を葬送に見立てているのだと思って読み進めていたのに、途中で魔族からそう呼ばれていて、魔族を殺しまくる忌み名的なものだったの？！というところで、それまで読み進めていた自分の中の世界観とバグが生じた。もしかしたら今後の物語の展開によってまた違った意味になってくるのかもしれないけど。

歴史上で最も多くの魔族を葬り去った魔法使いとして「葬送のフリーレン」の異名を持ち、魔族から忌み恐れられている。

ja.wikipedia.org/wiki/葬送のフリーレン

あと思い出を辿るという物語は、ほのぼのしている話しもあれば、魔族との戦いを話しもあり、資格を取るための競技会の話しもある。話しの展開を何とでも創生できる想像力の源になっている。このマンガは旅の終わりが来なくてもよいし、強い敵を倒さなくてもよいし、思い出さえあれば物語を展開できるのでその幅の広さに感心した。内容はまったく違うけれど、蟲師 を読んだときと同じような感銘を受けた。葬送のフリーレンもアニメ化が決定しているらしい。

これから面談が増えていく

#founding  #career 

23時に寝て5時過ぎに起きた。7時にはオフィスに着いて9時までプロダクトオーナーのためのインフラ入門のドキュメントの続きを書いてた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。前隔週を1回飛ばしたので話題はたくさんあった。エージェント経由のお仕事探しはまったくうまくいってないという状況を相談していたら、私のような開発者が匿名の職務経歴書で選別されるのは難しいのではないかとのこと。まさにその通りだと私も思う。逆に個人のパブリックなリソース (github, qiita, blog, slide など) からスコア算出するサービスは相手から面談のオファーがくる。長く生きている分だけパブリックなリソースがあってスコアがよくなるという理屈だが、そういったお仕事探しをしないと私の実績や経験では職務経歴書の見栄えが足りないということを学んだ。はらさんからのアドバイスとして、勉強会やイベントに登壇して発表者だけのレセプションパーティーに参加するのがよいと教えてもらった。懇親会とは異なる。懇親会はどちらかという参加している開発者のためのパーティーだが、レセプションパーティーは関係者のためのパーティーなのでスポンサーや著名人と話しやすい。そこでコネができるとカジュアルによいポジションのお仕事の紹介/斡旋が起きるとのこと。

お仕事探し

知人の働く会社で面談してもらった。たまたまやり取りするきっかけがあったので開発者を探していれば声をかけてくださいと言ったらまさにそういう状況だったみたい。経営者の方々とも、私からは面識があって10年以上前に1度だけご挨拶したことがあった。先方が覚えてくれていたかどうかはわからない。「いま何歳？」と聞かれて、あのとき20代だった人間がもう40代か、歳とったなとみんなで笑っていた。そりゃ16年も経っているのだからそうだよねって感じでおもしろかった。業界内ではトップレベルのパッケージベンダーだし、私自身も大先輩の方々だと認識しているし、技術的にも私などがお手伝いできるのだろうか？という懸念はあったものの、先方がやってほしいと考えている業務内容だけをみたらマッチングは問題なさそうに思えた。うちの会社のビジネスにしたい課題管理のノウハウを実践したり体系化したりする現実の職場としてもよさそうに思う。詳細な契約の条件や先方の要件などをこれから摺り合わせていく。うまくいくといいな。

インフラと非開発者

#infrastructure  #document 

0時に寝て5時に起きて7時に起きた。

インフラのドキュメント作成の続き

昨日はインフラ構成図を主に書いていたが、今日は引き継ぎのために wiki に概要を書いて補足事項なども肉付けしながら、私がやったことや今後運用していく上で知っておくべきことなどをまとめていた。それと同時に backlog の wiki の階層構造なども見直していた。backlog の wiki はタイトルに / を含めることで階層構造を表す。実際の url はエイリアスリンクが使われていて、タイトルとは無関係なので wiki のタイトルを変更することで階層構造が変わる。これはこれでお手軽とも言えるけれど、この階層以下のドキュメントをすべて移動したいといったときは1つずつタイトルを変えないといけないので面倒になる。デイリースクラムのときに来週のインフラ勉強会の時間もスケジュールを抑えてもらった。おそらく1回では終わらないのではないかと推測するが、説明してみて開発者の反応もみながら2回目の有無を決める。

さらに「プロダクトオーナーのためのインフラ入門」というタイトルで別のドキュメントも書き始めた。他の重要な業務がなくて暇だと言ってしまえばそうなのだけど、非開発者向けにクラウドのインフラや自分たちの web システムをどう理解してもらうのがよいか、私自身、試行錯誤で答えをもっているわけではないが、難しいからプロダクトオーナーはインフラを理解しなくてよいというつもりもない。以前からプロダクトオーナーが「自分たちもインフラがどうなっているのかを理解したい」というコメントを何度か聞いていたので筆を取った次第だ。技術的な詳細は理解できないだろうが、いまどきのインフラにおいてどういった概念や考え方が重要なのか、なぜこのような複雑なインフラになってしまっているのか、そうした背景を理解してもらおうと考えている。初めての試みなので、後日やってみて反応をみてふりかえりしようと思う。

インフラと引き継ぎ

#infrastructure  #document 

0時に寝て6時に起きた。

インフラのドキュメント作成

契約終了まであと1ヶ月半。私が唯一引き継ぎしないといけないものにインフラがある。

引き継ぐ前のインフラは本当にひどい状態だった。手抜き工事のまま放置されたような状態だった。cdk のコードから実際のインフラを構築することはできなくて、コード化されていないところを aws のマネジメントコンソールから手作業で設定していた上、どこを手作業で設定していたかの情報は一切残されていなかった。新しいインフラが追加されるときに cdk のコードと乖離があるからデプロイできなくて、それを前任者は直せなくて私が引き継いだという経緯がある。私が1ヶ月ほどかけて30以上の pr を作ってコードと実際のインフラをほぼ完全に同期させた。その過程で3回ほど (テスト環境ではあるが) 障害も発生させている。デプロイしたら手動設定が消えて壊れてしまう。何が手動設定で何がコード管理なのかの情報が何もないのだからデプロイしてみないと動くかどうかわからないという状況だった。そのため、現在のインフラは私が作り直したと言っても過言ではない。cdk のバージョンも v1 から v2 にアップグレードした。半分以上の cdk のコードは私が書いたと思う。その引き継ぎならびにドキュメント化の作業にようやく着手した。これまで書いてなかったのはインフラを管理しているのは私だけだったのでドキュメントなくても運用上の問題はなく、ドキュメントタスクの優先順位が低かったから。今日は draw.io で aws のシステム構成図を書き上げて、wiki のインフラドキュメントの再構築に着手したところ。

今週中に引き継ぎのドキュメントを書いて、来週ぐらいからインフラ勉強会やって引き継ぎを完了させる予定。

コワーキングから学ぶコミュニティ

#github  #coworking  #community  #event 

0時に寝て2時に起きて5時前ぐらいまで本を読んでまた寝て8時に起きた。昨日の続きでちょっとした画面の改修をやって、小さいタスクを2つほど片付けて、それでもやることなくて暇だなぁ。

backlog-github-integration-action のアップデート

backlog のライブラリのバージョンが上がっていたのを少し前にみかけていたので更新してリリースした。

コワーキングのオンラインイベント

先日のカフーツさんのトークイベント 同様、9月のイベントに参加した。前回は急遽スケジュール調整をしたせいか私1人だったけど、今日は6人の参加者がいた。私以外はコワーキングスペースを運営している人みたい。コワーキングと街づくりといった内容が今日のテーマだったみたい。その事例の1つとして オトナリ［島根県雲南市］ を教えてもらった。成功事例の話しを聞いていると共通点の1つとして主催者が地元の人ではなくても、その地域に移住して運営しているという。オトナリも東京のコンサル会社が受注してコワーキングのビジネスを始めたものの、その会社の社員が東京から移住してまでその地域の街づくりに参画しているという。その熱意の違いが正否をわける要因の1つであろうと私は感じた。以前、神戸市さんとコミュニティについて雑談した ときも、あえて言わなかったけど、職員自らではなく業者に委託して運営しているようなコミュニティではまったく運営の取り組みは異なるだろうと思う。他にも コミュニティ財団 という財団法人を作って運営している 愛媛県 西条市 の事例なども教えていただいた。

その後、参加者個々のコワーキングスペースの運営者のお悩み相談みたいなやり取りをしていた。私だけ運営者じゃないのでちょっと浮いてた。お前何ものやねん的なw あと箇条書きで書いたものをマインドマップに変換する Transno というエディターがあるらしい。私は手書きでマインドマップを描くのでこういったツールは使わないけれど、ツールでマインドマップを書くのが好きな人には向くのかもしれない。

蓋然性という言葉がよくわからなかった

#verbal aptitude  #medium 

0時に寝て7時に起きた。朝からタスクの詳細をヒアリングして web api と画面を作るだけの簡単な作業。しばらく (1-2週間ぐらい？) は暇な日々が続きそう。

蓋然性 (probability) と可能性 (possibility) の違い

わかりやすかった。

夏目漱石が授業で言った例では、「教壇で喋る講師が逆立ちする可能性はあるが、蓋然性はない。」というものがあります。

「判例の用いる確率の用語」～元公務員講師のコラム～

なんとなく稼ぐ

次の4つの手法による収入を passive income (受動的な収入) と定義している。

  1. ソフトウェアとデジタル資産を売る
  2. ブログを始める
  3. 自分の youtube チャンネルを始める
  4. フリーランスオンライン

それぞれみていくと、ソフトウェアを売るというのはアプリストアに代表されるようなマーケットプレイスで販売すること。デジタル資産とは電子書籍など。ブログは medium のようなサブスクリプションを使う。youtube はコンテンツを作って広告収入を得るかな。オンラインでフリーランスとして副収入を稼ぐという方法。どれもよく知られた当たり前の手法だけど、簡潔にまとまっていてわかりやすかった。

スキルの定量化とお仕事探し

#founding  #career  #medium  #management 

0時に寝て7時に起きた。直近は日曜日はだらだらしてたんだけど、すんなり起きれた。

お仕事探し

offers さんのカジュアル面談 の雰囲気から企業に直接応募するプラットフォームの方が、私の経歴や実績の詳細を確認しやすいので面談に進みやすいのではないかとみている。そこで findy と lapras のプロフィールを作成してみた。これまで oss 活動やブログなどでアウトプットしていた資産がたくさんあるのでレベルはしょぼいにも関わらず、これらのプラットフォーム上ではそこそこよい数値がアルゴリズム的には算出される。プラットフォーム側としては転職やエンゲージメントを高めたいという意図があるから、ゴーストアカウントのようなものも含めて算出すると普通の人は高めの数字が算出されるのではないかと推測する。

findy さんのスキル偏差値によると、想定年収予測は1060-1160万円らしい。この数値は起業する前のサラリーマン時代の年収に近いのでそんなにずれてはいない。lapras さんの公開プロフィール によると、技術力が4.01で約170万人中668位だというのは上位 0.04% に属することになってしまう。んな、あほなという思いはある。とはいえ、自己申告の経歴をいくらでも盛れる職務経歴書よりも、客観的なアルゴリズムで評価できる指標の方が絶対値が適切かは置いておいても、相対評価において他の候補者と比較できるのを好む採用担当者もいるだろう。匿名の一般的な職務経歴書を用いる remogu さんの選考 は書類選考でばんばん落ちまくる。それに比べたら、アルゴリズムで相対的によい数値が出ているプラットフォームの方が面談に進みやすいのではないかという話し。本当にそうかどうかの仮説はこれから検証する。

google の従業員が働いていないという発言の真意

昨日たまたま medium のダイジェストでみかけた記事を読んだらおもしろかったので、なるべく余裕のある日は medium の記事を1つ読むようにしてみようかと思う。言うても deepl を使って斜め読みして大意を掴む程度なので日本語の記事を読むのとそんなに時間が取られるわけではないと思う。今日は次の記事を読んだ。

プログラミングにおける生産性とはどういうものかを説明しつつ、google の ceo がいう生産性が十分ではないという発言の真意は、従業員が業務時間にさぼっているとか怠慢だとかいう意味ではなく、google のビジネス全体がこれまで達成してきたのと同じ業務時間では期待した成果を達成できなくなってきているのではないかと考察している。

At some point, productivity measurement becomes Schrödinger’s cat.

また著者の引用？では生産性の計測とはシュレディンガーの猫のようなものだという話題もおもしろい。どんな会社もある時点での生産性の測定はシュレディンガーの猫のようなものになる。セグメントを分割し過ぎると返ってストレスとなり、余計な混乱を招き、計測そのものが生産性を低下させる。生産性の測定はマクロレベルでやるのが理に適っていて、工場時代のマネジメントをもつ amazon は大量の人員削減をしつつも成し遂げた。google のようなワークカルチャーをもつ会社ならその気になればスマートにできるだろう。一方で google という会社はすでにリベラルな極みにある企業文化をもっているため、生産性を測るような試みは組織全体に大きな感情的ダメージを与えるだろう。その結果として amazon と同じような道を歩むのではないかと。

シュレディンガーの猫がどういう意味かもわからなくてそれも読んでた。

キャリアは知識と経験の差分でわかる

#life  #medium  #programming  #information exchange 

23時に寝て2時に起きてその後どうしていたかあまり覚えていないが気付いたら8時だった。

ストレッチ

今日の開脚幅は開始前160cmで、ストレッチ後163cmだった。今週も全然ストレッチできなかったのになぜか数値はよくなっていた。ストレッチを受けていて調子の悪さも感じなかったので気候が過ごしやすくなってきて体調がよくなった結果として普段の生活における活動量や新陳代謝などにも影響を与えているのかもしれない。トレーナーさんからは涼しくなったのだから運動をしてくださいと言われた。ほんとその通り。

知識と経験

たまたま目を通した medium のおすすめ記事に出ていて、タイトルにひかれて斜め読みしたらおもしろかったので後で deepl を使って精読した。最近は英語の記事を deepl で訳して読んでいる。まず deepl で全訳した後に文脈から訳文の意味をとれなかったり、明らかにおかしいところだけを手直しする。著作権的に機械翻訳を公開はできないため、その翻訳内容は課題管理システムのイシューで管理している。この記事だと手直し数回ぐらいで大意を読める。普段、英語の記事を日本語アカウントで紹介することはないんだけど、これは素晴らしい内容だったのでそのまま共有することにした。軽く所感も書いてあるが、課題管理システムのイシューにはさらに詳細な分析やコメントも残している。

多くの若いチームでは課題管理の重要性を理解していない。その無理解の原因の1つとして、ものごとを検討したり判断したりした時点では正しかったことが未来のある時点で誤りになってしまう可能性を想像できないからだと私は考えている。記憶と忘却の仕組みから前日のことですら半分以上忘れてしまうので数ヶ月前の詳細など、ほとんどの人は覚えていない。にも関わらず、日々の小さい判断の積み重ねや意思決定の履歴を記録として残さないのはなぜだろうか？それはその詳細があとで重要になるかどうか、多くのケースでその発生時点ではわからないからだ。例えば、システムのアーキテクチャに関して言えば Architectural Decision Records (ADRs) というドキュメントが提唱されている。アーキテクチャのような大きなものでさえ、明示的に残さないと経緯がわからなくなるのに、もっと小さい粒度である日々の開発や運用の誤りを、一般の (普通の) 開発者がその発生時点から数ヶ月や数年経ってふりかえって見直すことができるだろうか？いやできないというのが、多くのチームやメンバーをみてきた私の所感だ。多くのメンバーは過去のある時点の見逃しや判断ミスをなかったことにしようとする。それは無意識にしろ意識的にしろ起きやすい。客観的に詳細を確認できればなかったことになってしまうのは仕方のないことでもある。

私は課題管理システムのコメントに、こういう状況からこう判断したとか、誰それと相談してこういう事情でそうしたとか、自身の感覚からとくに意味もなく決めたとか、常々なぜに相当する内容を残している。そして、あるとき過去の経緯を見返して、そのときの判断は適切だったか、過去のある時点で気付けたはずのことを見逃してなかったか、見逃していたとすればどうすればその時に気付きを得られたか、というふりかえりを日常的なチケット整理の一環として実践している。件の medium の記事にはなぜそれが重要なのかの概念を書いてあるように私には受け取れた。課題管理 + 情報共有の需要な概念の1つだと認識して寝かせておこうと思う。

若い会社とのエンゲージメントを図る

#founding  #career 

23時に寝て5時だと思って3時に起きてそのまま家事をやって5時から働いてた。早起きすると暇つぶしのように溜まっているタスクをこなし始めるので早起きは三文の得というのは本当だ。非稼働日だけど、午前中に次のタスクの要件のヒアリングだけやっといて、月曜日の朝一から作業できるように調整しておこうと考えたが、今日は開発リーダーが休みだったので何もしなかった。

カジュアル面談

Offers というサービス でみつけた会社にカジュアル面談を申し込んでいた。エンジニアリングマネージャーを業務委託で募集しているのは珍しかったのでその背景などを聞いてた。面談してくれた方はテックリードと言っていたが、この人も副業で手伝っているらしい。雰囲気的に若い会社のようで正社員はほとんどいなくてチームのメンバーが10人ぐらいのうち正社員が1-2名だという。基本的に外部の寄せ集めメンバーがそれぞれ副業や業務委託で空き時間を使って開発しているといった話らしい。8時間/週といった契約のメンバーもいるとのこと。どんな人を採用するにしてもまず業務委託から始めるというのがその会社の方針らしい。信頼関係という視点からみると、このような経営者にとって都合がよい労使関係を嫌う人もいるのではないかと思う。一方で私は雇う側も働く側もお互いにマッチングしないときの不幸を防ぐには1-3ヶ月ぐらい働いてからお互いに望むときに採用するといったやり方の方がよいと考えている。実際にマッチングしない人の場合は1週間で見切りをつけるとかあるらしい。私自身、初めてお手伝いする会社は最初の3ヶ月とかは1ヶ月契約でも構わないと伝えることがよくある。その後、お互いにマッチングするなら3-6ヶ月の契約期間に延長したいと交渉する。20年働いてきて、過去に試用期間で解雇されたことや1ヶ月で即解約になったことはないので一定の自信もある。

テックリードが若かったので組織もチームもメンバーも若いのだろうという印象を受けた。業務的にはお互いにマッチングしているように私からは思えた。あとは単純にテックリードが話してみた感覚や相性で私のようなベテランを求めているかどうかで次の選考の有無が決まるのではないかと推測する。次があったら正社員の人とも話してみたい。