Posts for: #Information Exchange

10年に1度の失敗

21時頃から布団に入って0時ぐらいまで 精霊の守り人 をみていたらそのまま寝てしまった。

今日の運動は腹筋ローラー,スクワット,縄跳び(両足跳)をした。統計を 運動の記録 にまとめる。

公正証書の正本を紛失する

12時から信託銀行の担当者と口座開設の打ち合わせをする予定だった。事前に準備しようと 公正証書の正本 を探してみたが、みつからない。月曜日のリリースパーティ のときは机の上に放置していた。机の上に粗雑に放置しておくと失くすからあえて移動させた記憶がある。本来は予めかばんに入れて打ち合わせまで保管しておくところが、リリースパーティへ出掛けるから、道中の行き帰りや現地でかばんを紛失するリスクがあると正本をかばんに含めず、一旦オフィスに置いておこうと書架にしまったつもりだった。しかし、机の上にも書類を置いてある書架にも一通り調べてみたが、どこにも正本が見当たらない。みつからないので誤って他のゴミと一緒に捨ててしまったのだろうと推測している。保管場所を忘れてしまった可能性もなきにしもあらずだけど、数時間探して見当たらないのでそんな保管場所を無意識に選択するとは思えない。

公正証書の正本を取得して1週間で紛失するという失態を私がやってしまったことにショックを受けた。私は書類管理をきっちりする方なので重要な書類をなくしたりはしない、いや、過去にはしなかった。どこに閉まったか、忘れてしまうことはたまにあるけれど、あちこちひっくり返して調べれば必ず出てくるぐらいには書類を必ず残しておく方だった。過去にこんな失敗をした記憶はない。にも関わらず、そんな私が重要な書類を紛失してしまうという状況に遭遇して、この機会にふりかえることにした。非常に稀な事件が起こったので戒めに書いておく。

3月は例年になく、とんでもなく忙しい月になっているせいか、日々の生活に対する私の集中力や注意力が散漫になっているように思われる。

よくも悪くも複数の未知のイベントや人間関係に脳のリソースを多く割いた結果、集中力を欠いて本来やらないような失敗をしてしまったのだと推測する。そして、そのいろいろにかまけて書類管理を怠っている状態を長い期間に渡って許容してしまった。もっと早くオフィスの書類管理を見直すべきだった。

  • オフィスに会社と個人の書類が混在している
  • 書架には会社の書類を整理する棚は作られているが、個人の書類の置き場所がない
  • 会社の書類はほぼ整理されているが、机の上に未整理の書類を散乱させる運用になっている
    • そこに未整理の会社と個人の書類が混在していた
  • 書類を乱雑に積み上げているから、大事な書類を紛失するという事件が起きた

10時半に信託銀行へ電話するも、担当者はすでに出発していて捕まらなくて11時半に折り返しがかかってきて、事情を説明して確認したところ、やはり公正証書の正本なしでは信託口座を開設手続きを進められないとのころ。申し訳ないところだが、今日の打ち合わせをキャンセルしてもらった。午後から公証人へ連絡して再発行の手続きをしてもらう。幸いにも来週すぐに再発行してくれるらしい。手数料に3,500円ほど必要になる。図らずして公正証書の安全性を確認できた。原本は公証役場に保管されているため、原本と同じ効力をもつ正本は (手数料さえ支払えば) いつでも再発行できる。

同時にこの失敗は他人の失敗に対して私を寛容にするだろう。私ですら、公正証書の正本を1週間で紛失するという、ありえない失敗をする。人間は必ず失敗する。どんなありえない状況でもそれが起こってしまったのであれば、その事実を受け入れる必要がある。失敗してしまったことそのものを言及するのではなく、なぜ失敗したのか?その失敗をふりかえることで次の気付きへとつなげる。同じ失敗を繰り返さない仕組みを構築する。他人が失敗しているのをみかけたとき、この記事を読み返して自己を省みるようにしようと思う。

後日、再発行したときの領収書。これをとっておいて見返すことでありえない失敗をした自己を省みる。

スマート縄跳びの試用

先日 スマート縄跳びを購入 した。水曜日に届いていたものの、雨降りだったり、寒波だったりして、ようやく試用できた。跳んだ数を数えるアプリは普通に使う分にはよさそうにみえる。跳んだ回数と消費したカロリーを算出できる。私は使わないけれど、ソーシャル機能も備わっている。LED による回数表示そのものはカッコいいし、アイディアも斬新でよいと思う。どんな使い勝手かは実際に使ってみないとわからないのでこの仕組み自体は一見の価値がある。一方で実際に使ってみて実用性を考えたらいまひとつかなと思えた。

  • 回数ディスプレイの表示位置を調整するのがやや難しい
    • 調整はグリップを握る位置を変えないといけない
    • 縄跳びの回転の速度によっても表示位置がブレる
  • LED はロープの長さを調整できない
    • 3つのサイズを提供していて小さめの M を買ったものの、これでも私の感覚としてはロープが長過ぎる
    • 自分の跳びやすい長さの調整できないと跳んでいてストレスになる

近いうちに時間のインターバルによるワークアウトに移行しようと考えている。回数が重要でなければ跳んでいるときに回数を確認する必要もない。ロープの長さを調整できないことは知っていたのでそれ自体は仕方ないものの、LLED だと自動でカウントできても跳ぶときにストレスがたまる (ストレスは代謝を下げる) と思えた。そこでロープの長さを調節できる SmartRope PURE も購入してみた。3-4日もあれば届くはず。

確定申告の新しい合わせ技

2時に寝て6時半に起きた。いつも通りのサイクル。寝る前と起きた後に体重を測っていると寝た後に体重が少し減ることがわかった。寝ている間の減量 でも、寝ているときに筋肉増強と脂肪燃焼の代謝が起こっているらしくて睡眠時間を確保することは重要にみえる。

今日の運動は腕立て,スクワット,散歩をした。統計を 運動の記録 にまとめる。

2023年度の個人の確定申告2

先日の書類作成の続き 。さとふるで「寄付金控除に関する証明書」の電子データを申請していた。サイトには2日かかるとあったけど、おそらく翌日には作成完了していたと思う。この xml データを freee で取り込んで確定申告書類を作成する。あとは国境なき医師団への寄付だけ。認定 NPO 団体は 神戸市の条例指定寄附金 として申請すればいいのかなと思う。これで金額を確定してそのまま電子申告を行った。

電子申告したら、電子申告に漏れた書類を別途提出するためのシートがあって、そこには電子申告に関する情報が記載されているので、そのシートと一緒に紙の書類を提出する。午後から近所の確定申告特別会場へ行って提出してきた。提出したものは次の書類になる。

  • 電子申告に関する情報が記載されたシート
  • 認定 NPO 団体への寄付の紙の領収書

初めてだったので受付の担当者にあれやこれやを質問しながら、とくに問題なくそのまま提出できた。念のため、小規模企業共済の掛金控除証明書ももっていたので、この書類も提出した方がよいか質問してみた。これは不要だという。小規模企業共済もマイナポータルで紐付いているので私のマイナンバーから支払履歴を確認できるはず。デジタル庁がよいお仕事をしているのか、確定申告がどんどん電子化されていって楽になっていく。これはこれで毎年楽しみになってきた。

今回の確定申告で電子申告 + 紙の領収書の合わせ技パターンを学習した。

知の創造研究部会

第64回知の創造研究部会 に参加した。冒頭に主催から挨拶があって、このイベントはもう17年やっているらしい。ナレッジマネジメント、知の創造、共創といったものがテーマ、積極的に事例なども紹介している。

18:00~19:30 第一部: やさしいビジネススクール 中川功一 学長の講演

中川先生のやさしいビジネス研究 で youtuber もやっているらしい。話しもプレゼンテーションも上手くてわかりやすかった。ディスラプト (disrupt) とは非連続的な変化、まったく別の視点から創造的破壊を行うことを指す。体制側からはネガティブな言葉のように聞こえるが、必ずしもそうではない。ロン・アドナー著のエコシステムディスラプションの紹介されていた。中川氏が監修しているらしい。

いまのビジネスは単体の製品で行っているわけではない。複数の製品群でイノベーションを起こしている。それをエコシステムと呼んでいる。価値軸の転換をもたらすものが云々。こういった製品の組み合わせが社会的に何を意味しているのか、背景にある潮流を見抜く必要がある。グレタさんのような人をスポンサーしたり投資したりするのはなぜか?どんな方法であれ、ゲームのルールを変更すれば、競争の優位劣位はひっくり返る。世界の企業はいまゲームチェンジを争っている。エコシステムによるビジネスを一般化すると、ゲームチェンジさえ成し遂げればよい。しかし、日本の企業はゲームチェンジが苦手ではないか?

19:35~20:35 第二部: 細野一雄氏の研究書出版講演

sier で定年退職した著者がシニア層 (年配の人たち) が it 業界でどうやって活躍していくか、もしくはシニア層は残りの時間をどのように働いていくかといったことがテーマのお話だった。細野氏の博士論文を一般人向け?に読みやすく書籍にして出版もしている。自費出版ではないそうだが、初版500部と話されていたのでよく出版できたなと思ってしまった。

私の関心事に近いテーマではあるが、私の関心は第一線を離れたシニアの人たちが若い人にどう技術継承していくかといったことがテーマではない。技術的にも若い人より高いレベルにあるシニア層から若い人たちがどう技術継承していくかに関心がある。会社から厄介者扱いされるような元気のないシニア層に関心はない。シニアは最新の技術に付いていけないといった姿勢で話していて、私の周りにいる同年代や年配の人たちは、一般の若い人よりもずっと高いレベルで働いているのになと思って内容に違和感が多かった。sier で普通に働く人たちの業務と oss の世界で活躍している開発者と比較するのは酷なのかもしれない。

巨大クリアブックとクラウドストレージ

5時前に寝て8時過ぎに起きた。夜に部屋のレイアウト変更して掃除し始めたら集中力が出てきてやりきってしまった。

今日の筋トレは腹筋:10x2,腕立て:15x1をした。夜に1時間で3-4kmぐらいは歩いたかな。

クリアブックと書類整理

近くの文房具屋さんで クリヤーブックウェーブカット固定式A4縦 100枚青 品番:ラ-T590B を購入した。税込で4,697円になる。年度をまたいで有効な契約などの書類を一元管理しようと思う。うちが4年強で溜め込んだ年度をまたぐ書類として21ファイル使った。1つのファイルの表裏に書類を入れているので40書類ほどになる。クリアブックを机に置いても自立する。キャパシティの1/5程度しか使っていないのでまだまだ余裕がある。年度をまたがない書類は、基本的に法人決算の書類をまとめるための別クリアブックに保管している。その年に締結した契約書 (業務委託契約とか) なども年度決算のクリアブックに収めている。

年度をまたぐ契約というのは、例えば 経営セーフティ共済 の契約書などがある。こういった組織との契約だと、厚手の紙の立派な証明書が送られてくる。それを保管する義務があるのかどうかよく知らないが、これをシュレッダーにかける気にはなれない。立派なのでとりあえず保管しておこうとなる。

他にも初期の手続きの書類には契約条件や制約事項などが書いてあったりする。なにもトラブルがなければ不要だが、後になって調べたいときがある。例えば、2023年10月分からシェアオフィスの賃料の自動引き落としの手数料が200円請求されるようになった。請求額が増えていることに気付いて「おいおい。引き落としの手数料なんか聞いてないぞ。文句言ってやろう。」と思いつつ、念のため、契約書を掘り返してきて自動引き落としの手数料について記載があるかどうかを調べた。すると、自動引き落としの手数料は借り主が負担するとちゃんと書いてあった。つまり、2023年10月分から請求するようになったのは、これまで4年近く運営会社が自動引き落としの手数料を請求すべきところをなにかの手違いで見落としていて請求していなかったのだと推測する。その見落としに10月頃に気付いて請求するようになったと推測される。引っ越し前の契約書も 2022年12月に引っ越しした ときの契約書のどちらにも自動引き落としの手数料は借り主負担と書いてあった。ちゃんと契約書を保管していたので、運営会社に勇ましくクレームして、後になって自分が間違っていたと恥をかくこともなかった。

これまで種別やカテゴリ、取引先組織といった、なんらかのグルーピングをして書類をクリアファイルに収めていた。そうして4年経ったらやや膨らんだクリアファイルが数十できてしまった。そして、なにかを調べたいときに目当ての書類がどのクリアファイルの、どこにあるのかを探すのが煩雑になってきた。さらにクリアファイルを棚のあちこちに置くと、どこに置いたかも忘れてしまって、結局すべてのクリアファイルを机の上に並べて線型探索するみたいな作業になってしまう。この運用にうんざりしてきた。

そこで100枚入りの巨大クリアブックの出番だ。個々のクリアファイルに保管していたものを1つに収める。なにかあったらその1つのクリアブックを線形探索するだけで済む。クラウドに例えると、100枚入りの巨大クリアブックは s3 の1つの bucket で、書類はそこに格納されるオブジェクトになる。その bucket を ListObjects api で列挙すればどこかに入っているとわかる。その bucket は無限に拡張するのであふれることはない (巨大クリアブックは100枚が上限だが) 。運用ログを1つの bucket に溜め込む感覚と似ている。なにもトラブルがなければただのアーカイブだ。なにか起きたときだけ調査して見返す。これまでは、書類ファイルがローカルのファイルシステムにあったり、google drive にあったり、dropbox にあったりしていたようなイメージだ。

神戸ルミナリエ散策

4年ぶりの開催 ということなので散策してきた。5年ほど神戸に住んでいるけど、ちゃんとルミナリエに参加するのは初めて。今回のメイン会場はメリケンパークにあり、有料チケットを購入することでイルミネーションの真下を歩ける。1時間ごとに5000人の人数制限をしている。チケット料金は前売り500円、当日券1,000円になる。屋台の出店も10件以上は並んでいてそこに100人ぐらいの行列ができて繁盛していた。19:30の開始時間の入場でちょうどそのぐらいの時間に行ったら入場ゲートで20分待ちの行列になっていた。入場ゲートが4テントほどあって、1つのテントに2つの入口があってチケットをもぎりしてカードを渡すといった運用になっていた。もう2倍ぐらいあったらスムーズに入場できんたんじゃないかと思えた。入場ゲートさえ通過してしまえばちょっと混み合っている程度の過密度だったので人数制限は適切だったと思う。入場ハックするなら1時間の区切りの終了時間の15分前ぐらいに行って行列を待たずにすぐ入場させてもらうのがいいんじゃないか?と思えた。

初めてちゃんと参加したルミナリエはこれだけの参加者を集客する荘厳さがあったように思う。鎮魂イベントやしね。普段みないような巨大イルミネーションを鑑賞して非日常の気分を味わえたと思う。今回は初めての1月開催、交通規制をせずに3会場分散配置、人数調整のための有料エリアなど、ルミナリエのイベント自体も新しい取り組みをしていたようにみえる。私は過去イベントに参加していないので比較しようもないが、混雑を制御できているという視点からはうまくイベント運営されているようにみえた。新しい企画をした運営スタッフはしてやったりじゃないかな?コミュニティのイベントスタッフをしていた影響でイベント運営の勘所みたいなところをついついみてしまう。

日本ナレッジ・マネジメント学会にオンライン参加した

0時に寝て5時に起きてゲームして9時に起きてまたゲームしていた。午前中は家でだらだらしていてお昼からオフィスで作業していた。

ナレッジ・マネジメントの年次学会

夏ごろに 日本ナレッジ・マネジメント学会へ加入 していた。学会誌を読んだりする程度しか活動できていなかったものの、年次大会をオンラインで視聴していた。

お昼からみたのでパネルディスカッションの後半と研究発表をいくつか視聴した。パネルディスカッションは ai についての議論をしていたが、私からみてとくに目新しい議論はなかったように思える。研究発表はいくつか関心のあるものがあって、自分たちの研究について話す前に先行研究としてこれやあれがあって、それらを踏まえて、自分たちはこういう研究をしていると聞ける。それまでの歴史や先行研究でわかっていることなども知ることができて、自分で一から調べるよりも調査時間を短縮できる。聞いていていくつかおもしろそうな論文もあった。また時間ができたときに調査するための issue として作っておいた。すでにそういった issue はたくさんあるのだけど。

おもしろかった発表内容の1つにリーダーシップ論は 野中郁次郎 先生ともう1人 (名前を聞き取れなかった) を除いたら、すべて米国からきたものだという。日本の地域性の高い問題においては米国由来のリーダーシップ論ではうまくいかないケースがあるといった話しをされていた。他にも実践知と叡智の違いとか、賢慮がどうこう、気付きの定義、技術と技能の定義といった用語の定義を明確にして議論をするといったところが学術研究とビジネスの大きな違いのように思えた。そして、学術研究においてもそれが定説としての認知度または実績がなければ、さまざまな仮説や研究があることから、自分たちはこの単語をこのように解釈して使っているとか、それぞれの派閥によって同じ言葉を別の意味で解釈していたりする。知識に関する用語が乱立して、結果的になにについて話しているのか、わかりにくくなってしまうといった雰囲気も感じることができた。野中先生の提唱する「フロネティック・リーダーシップ」には、実践知の起源として、アリストテレスが分類した3つの知識の一つ、フロネシスにあり「賢慮」とも訳されるらしい。実践知の要素には倫理が含まれていて正しいことを行うための判断も指摘されていた。来年ぐらいからうちの会社もこういった研究に時間を割いていきたい。また資料が公開されたふりかえりをしてみようと思う。

気付きというスキル

2時に寝てあまり眠れなくて6時半に起きた。スマホで ゴブリンスレイヤーⅡをみてから寝た。

プロジェクトの進捗報告

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

開発の中盤を過ぎて、これから追い込みへ入っていく。予定していたバックエンドの機能開発は完了した。私の頭の中ではもう完了までの見通しができていて、あとはフロントエンドの新規画面を構築したり、品質や堅牢性のための小さい改善をしていくといったことを残りの1ヶ月で行う。若いメンバーに経験を積んでもらうことも考慮しているため、サポートを最小限にしながらメンバーの成長を期待したいところ。見た目上の開発スケジュールは順調なのでマネージャーとしスケジュールの懸念はほとんどない。kit/vite アプリケーションの調査 を私が自らやっていて、これを一区切りつけないと次の作業に進めないところが、私の課題でもある。インターネットを検索してもみつからないことを、どのように考え、仮説を立て、調査して、意思決定していくかをメンバーに示したい。マネージャーが一連のワークフローについて業務の参考になるようものをみせることができればいいなと考えている。

以前 コミュニケーションのレベルについて考えたこと をベースにした方法論を社内の wiki にも書いてある。5段階のコミュニケーションのレベルがあり、多くの人たちはレベル4までしか到達しないのだけど、課題管理のスキルを身につけるとレベル5の「聞かなくてもわかる」というエスパーのような状態に達する。メンバーのうちの1人はこのレベルに片足を踏み入れていて、十分にうまく課題管理できているという話題も共有した。一方でレベル5に至るためのプラクティスや施策を、課題管理という文脈でもっとうまくできないか?というのはうちの会社のビジネスの中核でもある。とても難しい。いわば「気付き」を習得するための短期修行コースのようなものを作りたい、業務の中で。この話題を話し始めると、気付きの有無はその人の性格や動機づけにも関連するせいか、賛否両論の多様な議論に発散しやすい。私の立場としては、一定レベルまでは誰でも身につけられるスキルとして扱いたいが「気付き」が本当にスキルなのかどうか、実は確信がない。しかし、諦めることなく継続的に考えていきたい。

ふりかえり + チーム勉強会

22時から寝始めて何度か起きて7時に起きた。久しぶりにどっしりくるような夢をみたけれど、もう内容を覚えていない。

ふりかえりを兼ねたチーム勉強会

新しい開発に着手して初めてのチーム勉強会を行った。前の開発とチーム勉強会の運用を大きく変更した。ざっくり次が要項になる。

  • 前開発の postmortem 運用がうまくいかなかったので代替としてやってみる
  • 開発システム全体の機能が増えてきて、メンバーそれぞれがやっていることもバラバラになりつつある
    • 普段やっていることを他メンバーへ情報共有する機会とする
    • そのときのマイルストーンでやっていることをふりかえりする機会とする
  • 開発システムについて知りたいところや設計の議論などをしてもよい
    • メンバーが全員揃っていれば、どんな質問をしても誰かが知っているはず
  • そのマイルストーンでやったことを基本として他メンバーへ共有する
    • 内容は基本的になんでもよい、あまり準備せずに話せる内容でよい
      • 特定の issue の内容でも、マージリクエストの解説でも、機能や振る舞いの考察など
    • 知識やノウハウを他メンバーに共用する上で wiki やブログの記事などにしてもよい
      • 書くところがなかったらテックブログに書けばよい
  • 勉強会のために調査する時間が必要であれば、その調査時間も仕事の一環とする
    • 勉強会の準備も考慮して開発のスケジュールを各自で調整する
    • 業務で実装したことや調査したことを共有する機会にもなる

まだ合流前だけど、メンバーが新規に1人増える。2週間に1回の定例のみだと、新しいメンバーが既存のメンバーに追いつくための情報が足りないだろうと思って質問しやすい機会を設けようと考えていた。雑談時間とか、設計会議とか、そういう呼び方をしてもよいのだけど、私にとって違和感なく一番しっくりきて柔軟性も高いのが「チーム勉強会」になる。ふりかえりと情報共有と学びの場の3つを兼ね、チームビルディングにも応用しようという、まさに天才の所業ではないかw まだ始めたばかりだから言うだけ言っておく。また開発が終わったときに良し悪しのふりかえりはする。

今日のところは最初だったので前マイルストーンでやった issue をメンバーそれぞれ1つずつ内容を説明して共有した。私も mongodb の初期化ツールのマージリクエストが出来たばかりだったのでその背景や意図、工夫したところなどを紹介した。他のメンバーも背景やソースコードを紹介しながらみんなでわいわいできた。第1回目にしては活気があって情報共有という目的も果たせたし、よい感じの取り組みにみえた。このままうまく運用にのせていく。

次開発の要件決めは既定路線

1時に寝て何度か起きて7時に起きた。エアコンを入れていると夜は寒くなってきた。

feedly pro+ にアップグレード

前からやろうやろうと思っていながら忘れて放置していた feedly のサービスに課金した。基本的に sns をやめていく方針でいるため、情報収集のソースを rss リーダーに戻そうと考えている。これまでも sns と並行で feedly を使ってはいたんだけど、もうちょっと feedly の機能も使ってインプットの効率を上げられないかと考え始めた。Pricing をみると、pro, pro+, enterprise の3つのプランがある。真ん中のプランが推しのようだったのであまり調べもせず Pro+ プランを選択した。いまのところ、検索の機能を使うぐらいでしかないが、そのうち ai 機能的なものも触ってみようと思う。

次開発の優先順位付けと担当者の割り当て

先週の要件発散会議 の続き。発散させた要件を整理して優先順位を決めて、担当者まで割り当ててしまった。課題管理がうまくできている必然なのか、なにも迷わずに自然にこのモジュールは○○さんでといった棲み分けもできて、それぞれが役割を果たせば開発の要件が満たせる体制になっている。全体像としての要件一覧は概ね用意した通りではあったものの、要件や設計の詳細の話しをしていると、私の要件の誤解もいくつかあって、それらは訂正しながら設計していくことにはなる。それでもメンバーも成長してきて、私がお膳立てしなくても、メンバーが自ら考えてうまくいくように設計してくれそうな雰囲気もみえてきたりしていて、それによって、私は面倒で厄介なインフラの再整備に注力できたりもしている。前開発がうまくいったので、なんとなく次開発もうまくいきそうな、始まる前から気を抜き過ぎにも思えるが、もう始まる前から開発が終わっている (うまくいくことが分かっている) ような感覚をもっている。できることは分かっていて、あとはどれだけの量を次開発で実装できるかといった、私が区切りの線をどこに引くかだけ決めればいいんじゃないかと考えている。よいチームになってきたなとちょっと誇らしい。

組織やプロジェクト横断的なメトリクスの視覚化

0時に寝て4時に起きてもう1回ぐらい起きて6時半に起きた。

もうすぐ期限がやってくる。私が担当している issue 対応はあらかた終わってメンバーに「大きいもので見落としある?」って尋ねて「ない」って返ってきたのでもうクローズに向けて調整していく感じ。今週末から月曜日と3日間お休みする (土日も含めて休むというのも変ではあるが) ので一安心。

dirsync 周りのリファクタリング

ずっとレビューが放置されていた。おそらくいま go-ldap のプロジェクトで最も活発なメンテナーが夏休みだったのではないかと推測する。昨日帰ってきたようで怒涛のレビューをされていて、私が3週間前に送っていた pr もレビューしてくれた。

概ね同意してくれて public な関数名をより適切な関数名に変えたところを、1度公開したものは互換性を維持するために deprecated のコメントをして残しておいてと言われたところだけ修正した。修正後、数時間ですぐにマージしてくれた。感謝。

go-ldap にいくつかコントリビュートした機能はうちのプロダクトのシステムに使われていて、それなりの qa テストをやった上で動いているので一定の品質は担保していると思う。直近1年間のコントリビューター を参照すると、私は2番目に貢献しているようにみえる。こういう見える化が自分のモチベーションになるならそれはそれでよいと思う。

組み込みの課題管理のプロダクトを作る上で、個人がみたいメトリクスを簡単に集計できるような機能を提供しようと考えている。それは自分が伸ばしたいスキルやプラクティスに対して、会社やプロダクトを横断的に計測できる仕組みがあるといいと私は考えている。とくにいまどきはプログラマーが転職するのは当たり前だが、転職したら前の会社でやっていたメトリクスがみれないとか、別の会社でのメトリクスと相対比較したいとか、そういうニーズはあるなと私自身が感じているからでもある。

go イベントのパネルディスカッション

mercari.go #23 Go1.21 パネルディスカッション オンライン開催 に参加した。視聴者が少なかったのか、youtube のコメント欄でちょくちょくツッコミもいれたら現場で拾ってくれておもしろかった。私が関心のあった話題を3つあげてみる。

gonew の提供

For a long time now, we have heard from Go developers that getting started is often the hardest part.

Experimenting with project templates

go で新規プロジェクトを始めるときにテンプレートからプロジェクトのレイアウトを作ってくれるユーティリティとして gonew というツールが公式から提供されたらしい。知らんかった。私も新しいリポジトリ作るときに標準的なものはファイルを基本コピペしているのでこういうのできれいに作れると嬉しいかもしれない。 

derrors の是非

pkgsite という pkg.go.dev というサイトのリポジトリの internal として実装されている derrors というパッケージがある。defer を使って必ず関数がエラーを返すときに wrap するという、ユニークな発想で実装されたツール。明示的なコードを書くという go の文化とはあわない気はするけど、ユニークな使い方ではあるのでおもしろい。

この延長でエラーが発生したときにレポートを生成する derrors のユーティリティもあったりする。google がやっていることだから、わりと開発者間でもこれと同じものを自前で実装する開発者が増えているといった話しも聞く。

go 2 はもうリリースされない

The answer is never. Go 2, in the sense of breaking with the past and no longer compiling old programs, is never going to happen. Go 2 in the sense of being the major revision of Go 1 we started toward in 2017 has already happened.

Backward Compatibility, Go 1.21, and Go 2

これまでの go の言語処理系の開発の中で非互換な変更について「go 2 で」とプロポーザルだったり、issue の議論で先送りされてきた。最近コア開発者の Russ Cox 氏が (現時点で) go 2 はもう出ないと宣言した。go は既存のプログラムをコンパイルできない状態で新しいバージョンを出すことはしない。この背景の1つとして、誰もがジェネリクスの導入で go の互換性は崩れると思っていたものが互換性を維持して導入できたことが大きいと思う。(現時点で) go 2 はもうリリースされないらしい。

台風の暴風雨にびびった

台風が来るということだったので昨日は18時には家に戻ってきてゆっくりしていた。とくに何をしていたわけでもないけれど、なぜか眠れなくて3時ぐらいまでは起きていた気がする。あまりちゃんと眠れない中、7時に起きた。朝から外の暴風雨がすごくて人が飛ばされそうな勢いだった。さすがにオフィス行けないなと諦めて家でリモートワークしていた。お昼過ぎぐらいまで暴風雨が続いていたと思う。夕方になってから外に出たら普通の雨になっていてそれからオフィスに来た。

課題管理とプロジェクトマネージメントの話を熱く語る

理由があって先日 チェックした音声データ とは違う音声データを使って昨日の夜に公開された。週末働いてバテていたせいか、昨日は余裕なくて聞けなかったものの、深夜に聞き始めた。よいこと言っているなーと自画自賛しつついくつか間違ったことも話してしまっているけれど、私の話しにそこまで注意して聞く人はいないでしょう。

課題管理の話題になると、ついつい熱中して話してしまう。「熱く語る」と書かれてしまうのはこの分野に熱意をもっている人が稀だからかな。私はこの1-2年この分野をずっと調べているから、ここで話した10倍ぐらいのコンテンツをもっている。勉強会の資料も数個はあるし、スライドは200枚ぐらいある。そして、調べれば調べるほど私が分かっていないことも分かってきて、もっともっと調べたいことがある。しかし、いまいまはもう体力と気力がない。

エージェントアプリケーション開発

昨日の続き 。昨日レビューをしっかりしてもらってマージした。windows ad サーバーとの dirsync の通信のところを、一切動かさず、既存のコードをインターフェースにあうように作り直したものの、実際に動かしてみると非同期の制御が意図したデータフローでなかったり、windows ad サーバーの知らない仕様があったり、細かいバグもあったりで半日ほどかけてデバッグしながらバグ修正してた。単体レベルのテストでこのバグ数だと、qa レベルだとさらにバグありそうだなという感触だけ確かめた。その後 dirsync の検索も非同期になった方が嬉しいなと思ってちょっとリファクタリングして検証がてら提案してみた。特別なことをしなくても go-ldap の非同期検索を使ってそのまま動くことも確認できたのでこれはこれで役に立つと思う。

定例会議とそのプラクティス

22時に寝て1時半に起きて3時半に起きた。それからお風呂入って準備して始発の新幹線に乗った。いつもは夜通し起きているけど、今日は夜に雑談会があるので寝ておくことにした。

新しいやり方で1ヶ月が経過した定例会議

一ヶ月前の定例会議 は変更したばかりで手探りな状況ではあったが、今回は3つのマイルストーンをこなし、チームメンバーも新しいやり方に慣れてきたと言える。いまのところ、開発の情報共有でメンバーが困っているようにはみえない。しかし、タイムボックスの始めと終わりが生産性が上がるといったマイルストーンを短くした成果もあまりみえない。可もなく不可もなくといったところかな。悪いわけではない。

一方で6月末に私が休暇をとったり社員旅行があったりしてその分の業務時間が3日ほど少なかったことが最も大きく影響したと言うべきかもしれない。私は終わってみれば2週間で1つの issue しか fix していなくて、これまでは10以上 fix しているので、今回のマイルストーンの成果がいまいちにみえるのは私が最も働いていないといった方が正しい。いろいろ手掛けてはいるのだけど、調整のタイミングが悪くて fix しなかったという状況がある。それも含めて次の1ヶ月をピークにもっていく開発のメリハリではある。これまでの1ヶ月の進捗をみてメンバーにも3ヶ月でいま想定している機能開発を終わらせるよと共有した。

私が作業するなら余裕でこなせる作業量だけど、実際に作業するのは私じゃなくてメンバーが担当する。今後もメンバーの進捗を注視しながらサポートしていくことになる。他人の進捗をコミットするのはなかなか難しいという思いを抱きながらサポートしていく。

コパイロツトさんと雑談

準備を経て 19時半から南青山のオフィスで雑談してきた。いろいろ準備していったが、モニターが大き過ぎて画面共有しても文字がよくみえなかったり macbook の操作がやりにくかったりして資料はほとんど使わずに雑談してきた。コパイロツトさんはプロジェクトマネジメントそのものをやっているわけではなく、プロジェクトリーダーの意思決定を支援するための取り組みをしているというユニークな業務を提供している。スクラムで例えると、スクラムマスターよりも代理プロダクトオーナー (Proxy Product Owner) に近いという。

定例会議をうまくやればプロジェクトがうまくいくという信念のもと SuperGoodMeetings を提供している。ツールを正しく使ってもらえると意図した通りにうまくいくのだが、問題はツールをそもそも使ってくれないユーザーやチームをどう導くかというところで苦労されているように思えた。これは課題管理システムを使ってくれないという私の問題意識とも通じる。ツールを使いこなすには文章を書くことが重要で、文章を書けない人たちが一定数いるという事実を受け入れて、どのような取り組みをしていくか?これも課題管理と共通の問題であるように思える。課題管理の話しをして背景や意図が通じる人は少ないだけに、その価値観を共有できるというのは稀な機会であった。また 日本ナレッジ・マネジメント学会 という学会があることを教えていただいた。後日加入してみようと思う。

19時半から21時ぐらいまでオフィスで雑談して、その後23時半ぐらいまで飲みに行ってきた。楽しかった。

情報共有とメンバー課金の過ち

1時に寝て4時に起きて5時に起きて7時に起きた。明け方からうまく眠れなくなった。

clang の互換性

openldap 2.5 向けに ldap の overlay モジュールのビルド環境を作っていた。これまでは 2.4 向けのモジュールのみを提供していた。2.5 もそろそろやろうということで先週末からビルド環境の構築に着手していた。rpm のパッケージングの作業をしていて、openldap 2.5 のサーバーのビルドをしていると次のエラーが発生した。

configure:21011: checking for pthread_detach with <pthread.h>
configure:21033: clang -o conftest -O2 -g3 -fstack-protector -fPIE -D_REENTRANT -D_THREAD_SAFE -DOPENLDAP_FD_SETSIZE=16384 -DLDAP_CONNECTIONLESS -DSLAPD_META_CLIENT_PR -D_GNU_SOURCE -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  conftest.c    >&5
clang-15: warning: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-hardened-ld' [-Wunused-command-line-argument]
clang-15: warning: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1' [-Wunused-command-line-argument]
conftest.c:118:16: error: incompatible pointer to integer conversion passing 'void *' to parameter of type 'pthread_t' (aka 'unsigned long') [-Wint-conversion]
pthread_detach(NULL);
               ^~~~
/usr/lib64/clang/15.0.7/include/stddef.h:89:16: note: expanded from macro 'NULL'
#  define NULL ((void*)0)
               ^~~~~~~~~~
/usr/include/pthread.h:269:38: note: passing argument to parameter '__th' here
extern int pthread_detach (pthread_t __th) __THROW;
                                     ^
1 error generated.

エラーメッセージを調べていると、どうやら clang 15 に pthread_detach がないといったものらしい。clang 14 のときはビルドできたという。他の oss でも clang のバージョン違いでビルドできないといったことは発生しているらしい。有識者によると、次の修正が clang15 対応らしい。

それ以外はとくに問題なく、ビルドできてモジュールそのものの動作も確認した。あとは rpm のパッケージングと gitlab ci/cd でビルドしたモジュールで動くかどうかの検証だけ。

メンバー課金による過ち

昨日 SuperGoodMeetings をさわってみた ときにチーム管理の機能があって、任意のユーザーを招待するのは無制限で課金されないと書いてあった。「なるほどね。」とピンと来てコパイロツトの中の人に次のような所感を共有してみた。

招待可能ユーザー数を無制限にしているのはよい視点だと私は思います。メンバー課金にすると、経費を削減するために共有アカウントを利用したり、あまり使わない人にはアカウントを作らないようになって情報共有の側面から望ましくない状態になる。一昔前のオンプレ時代は業務に使うシステムのアカウントは全社員がもっていて当たり前だったのが、クラウドサービスを使うようになってメンバー課金の経費削減から全社員がもたないようになりつつある (とくに中小企業) のは、情報共有の視点から過去よりも悪化しているという問題意識を私はもっています。

コパイロツトさんもまったく同じ課題意識をもっていてメンバー課金しない料金体系にしているとのこと。鶏と卵みたいな話しだけど、組織には情報共有のためにアカウントのお金をケチんなと言いたいし、クラウドサービスの会社も料金体系を1人ずつじゃなくて、30人、100人、1000人といったある程度の階段でいいんじゃない?とか思ったりする。メンバー課金じゃないクラウドサービスとして basecamp や backlog などがある。