2時半に寝て寝たのかどうかよく分からないながら5時頃に寝落ちして7時半に起きた。

差分比較のための機能

id 連携で運用のための非機能要件の1つとして更新された内容を確認できるようにしたい。非機能要件だから私が作るかと思ってあたためておいた issue に着手した。wikipedia によると差分という言葉には次の2つの用語があるのをみつけた。

• Delta update
• Data differencing

数学やコンピューターの用語的には delta (ギリシャ語で変化を表す) という言葉を使う。os のパッケージングシステムで一部のパッケージをアップデートするようなことをデルタアップデートと呼ぶ。一方でコンピューターサイエンスにおいて2つのデータセット間の差分については diff という用語を使う。データの差分においては diff でよいのではないかと思う。そういった用語の定義から始めた。mongodb のコレクションのデータ定義をしたり、結合テストを書いて動かしてみたり、インフラのレイヤーから開発に着手した。

上司道 企業家として生き様と、人として求められること

第92回上司道 企業家として生き様と、人として求められること に参加した。なんとなくタイトルに惹かれた。上司道 に参加するのは3回目。

講師の牛島さんは昨日が誕生日だったらしく90歳だという。90歳になって zoom でオンライン勉強会の講師を務めるというのを、私はまったく想像できないけど、コンサルタントの第一線で活躍されてきた方の貫禄があった。もともとどういう主旨の勉強会だったのかよく分かっていないけれど、内容はビジネスの自己啓発セミナーに近いものになった。牛島さんが90年も生きてきて大事だと思える内容には普遍性や汎用性があるのだと思う。いくつか共感できる考え方もあった。

• これからは頭の良い人 (IQ が高い) よりも心が豊かな人 (EQ が高い) の方が大事で組織に貢献する
• 一番大切なのは幸せであること
• 楽しく生きる (働く)

過去に働いた会社でも頭がよくて何でもよく理解しているのにプロジェクトにあまり貢献しない人がいることに気付いた。さぼっているわけでもない。その違いを「心が豊かな人 (EQ が高い) 人」という言葉でいくつか説明できるのではないかと思えた。新規プロジェクトのような、常に変化して、正解もわからないまま進める業務において、論理や頭のよさだけでうまくいくことはなくなってきつつあるのではないか。なんのためにそのプロジェクトをやるのか、自分はなぜここで働いているのか、といった問いに答えをもっている人は普通の社員とは行動が異なる。自身の価値観や展望と比較して、現状の課題や改善に気付くのでプロジェクトを前向きに進めていける。頭のよい人は「あれが問題」「これが問題」と問題を指摘してエスカレーションするだけで自らが課題をどう解決するかの答えをもっていない。そんなことを考えながらこの話しを聞いていた。

次の2つは最近の私の人生観や働き方と重なるところがある。私はもう無理してがんばったりしないし、自分が嫌なお仕事も一切しないように決めている。一般的にいう「働きたくない」という生き方を目指している。もちろん実際には働いているわけだけど、それはなるべく働く時間を、遊んでいる時間に置き換えられないかと模索している。その過程で辛いことやしんどいことも避けようと考えている。

なぜそれができるかというのも、20代30代と約20年働いてきて自身の価値観を育ててきたからだと捉えている。私はなにが楽しくて、なにが辛くて、なにをやりたくないか。これは人それぞれに違う。私には私にしかない価値観をもっている。それがわかってきたから、いま自分の会社を経営していて、毎日がとても楽しいし、自分の価値観にあわないことはすべて断るという判断基準も明確になっている。そんな勝手気ままでやっていけるの？という懸念を抱く人も多いと思う。ダメかもしれない。仮にやっていけなかったとしても、いまの自分は幸せで楽しいのだからそれでいいんじゃないかと思う。無理をしていまがしんどくても将来がよくなる保証なんてどこにもない。

牛島さんはマザーテレサとインドで実際に会って10日間ほど一緒に過ごしてその体験がその後の人生を大きく変えたように話されていた。マザーテレサに「社員を大事にしていますか？」と聞かれたときに「しています。」と答え、その後に「社員全員の名前を覚えていますか？」と聞かれたという。当時の牛島さんの会社の社員は300人以上いて全員は覚えていなかった。それで「愛情の反対は無関心なのですよ。」とマザーテレサに指摘されて大きな衝撃を受けたという。その後、帰国してから300人以上の社員全員の名前を覚え、日々の業務で社員の行動などに気を配ってすべての社員に声をかけたりするようになったという。このエピソードもなかなか私には効く話しで、私は他人にかなりのレベルで関心がない。もし自分の会社で社員を雇うことになったら待遇がどうとか以前に、その人そのものに関心をもつという姿勢を覚えておこうと思う。

2時に寝て2回ぐらい起きて6時半に起きた。お休みとったからいろいろ余裕がないけれど、体力だけはある。

syncrepl 機能の実装

go-ldap の非同期検索 の続き。persistent search という用語 も理解して、満を持して openldap の syncrepl 対応に臨んでいた。syncrepl を用いた persistent search というのは、簡単に言えばメッセージキューで言うところの pubsub のコンシューマーに相当する。その通信のテストやデバッグをしているときに非同期検索のバグもみつけた。余計なことをして返って複雑なバグを混入したなと反省しながら修正の pr を送った。

• Fix a deadlock issue using search asynchronously #446

go-ldap の ldap 通信の処理や設計を理解するのに2日、rfc-4533 を読みながら Control に関するプロトコル実装に1日、テストやデバッグ、その他の調査や設計に2日ぐらい、次の pr を作るのに1週間 (平日5日) ほどは工数を割いた。

• Add syncrepl (rfc-4533) consumer (persistent search) #447

ローカル環境で単体レベルの動作は問題ないと思う。あとは私が知らない ldap プロトコルの振る舞いや単体レベルで検証できていない通信、実際の運用レベルの syncrepl の状態やエラーなどに耐えられるかどうかといったところだと思う。おそらく rfc を読みながらプロトコルの一部を私が実装したのは初めてかもしれない。もうサーバーサイドやバックエンドの領域で (スキルの多寡はあれども) 私が作れないものはそうないだろうという自信をもっている。実際に rfc で提案されたプロトコルを実装して、テストして、ちゃんと動いて、そういう日々がすごく楽しくて嬉しかった。根拠のなかった自信を確認できた。またレビューに時間かかるかな？マージのためのやり取りや修正に2週間から1ヶ月ぐらいを見込む。

0時に寝て何度か起きて6時半に起きた。朝から外はめっちゃ暑い。冷房をつけっぱなしのオフィスも朝からやっぱり暑い。根本的な空調の問題。

agent アプリケーションのメモリリーク正体

先週のメモリリーク調査 の続き。本当は週末にやればよかったんだけど、遊んでたりさぼってたりして放置してた。先週時点でリークしているのは go-zeromq/zmq4 側だというのはわかっていたが、何が原因でリークしているのかは分からなかった。一通りソースも読んでみたけど、いまひとつよく分からない。仕方ないから動的デバッグでソースコードに手を入れながら調査していて、すぐにみつけた。socket 構造体が保持しているコネクションの map がどんどん肥大化していく。なにも使っていない map にコネクションの値を保持して解放する処理がないことに気付いた。

sck.ids[uuid] = c

修正するかと思ってリポジトリの最新ブランチをみてもそのコードが見当たらない。すると次の pr で4月に修正されていた。まだリリースされていないからうちらのアプリケーションで使っているリビジョンにはその修正が含まれていなかった。

• Deal with empty Identity for ROUTER socket #140

Additionally, remove sck.ids, which is unused and leaks *Conn.

メモリリークの調査を始めたときに github issues/pr を leak で検索して一通りチェックしているので、先週もこの pr をみかけているはずだが見逃してしまった。タイトルが全然違うし、ほんの1行の typo に近いミスなので修正内容をみて気付かなかったのだと思う。自分の観察力の無さに気付いた。leak で検索ヒットしているのだから、それが自分たちのアプリケーションで使っているコードに入っているのかどうか、その内容をもっと注意して調べるべきだった。そうすればこの調査時間を数時間は短縮できた。これは私のミスだと認めて Postmortem のラベルを付けた。次回の定例会議でふりかえりに使う。

23時に寝て8時に起きた。オフィス行こうか迷ったけど、たまには休むかと思ってドラクエタクトしながら1日ゆっくり過ごしていた。

23時に寝て何度か起きて7時に起きてから11時ぐらいまでだらだらしてた。近所の靴屋さんに紐なしスニーカーを探しに行ったが適当なものがみつからなくて結局オンラインで検索して購入した。

オフィスの部屋が暑い

普通に作業ができないぐらいには暑くてしんどい。明らかにビルの内側と窓側で温度差がある気がする。サーキュレーターは昔から使っているものの、扇風機は汗を蒸発させて気化熱で涼しいという仕組み上、暖かい空気を冷やせないので温度が高いと効果が半減する。他に冷房機器を増設できないかを調べてみた。エアコン以外で増設する方法が次の2種類がある。

• スポットクーラー
• 冷風扇

しかし、どちらも私の要件や状況を改善するものにはならない気がする。

スポットクーラーはエアコンと同じ仕組みのミニエアコンのようなもの。エアコンの室内機と室外機が1つになったものと言える。これは冷風を送れるが、冷却した熱を外に排出しないといけないため、排気ダクトから外へ暖かい空気を排出できないと意味をなさない。うちのオフィスは窓を開けられない仕様なので排気ができない。ちなみにスポットクーラーを密室で使うと、冷却する機器の放熱と排気の暖かい空気の分だけ温度が上がってしまうらしい。あとエアコンの室外機とは異なり、熱をもつ機器が一体化している分だけ冷やす効率も悪化する。名前の通り、冷風を送るところだけ涼しければいいといった用途に使うものらしい。

冷風扇は水の気化熱を利用して冷やすという仕組みで排気を必要としない。原理的には打ち水したところに風を送ればちょっと涼しいといったもの。タンクに水と氷を入れたり、保冷剤を入れたりすることで涼しい効果を強化できるものの、最大のデメリットは水を蒸発させて涼しくするため、湿度をあげてしまうことになるらしい。湿度が高くなって不快指数があがれば元の木阿弥になってしまう。またフィルターで水を蒸発させる仕組み上、水を扱うところはカビや菌が繁殖しやすく、さらにそれを扇風機でばら撒いてしまうのでちゃんと掃除しないと衛生面でもよくないらしい。氷や保冷剤を準備するところまでは我慢できるが、掃除は面倒だなと思えて導入を諦めた。

エアコンってよく出来た仕組みなんだということが理解できた。レンタルオフィスのサポートに問い合わせたら夏場はエアコンを切らなくてよいのでつけっ放しにしておくと少し改善するのではないかというので今日から試してみることにした。これまで毎日朝エアコンを ON にして夜帰るときに OFF にしていた。基本的に私が一番早くオフィスに来て一番遅くに帰る。

対策はまだわからないけれど、この不快さを計測しておいて改善のための施策に役立てるために温度計と湿度計がセットになった計測器を購入した。エンペックス気象計 という会社の製品がよいとみかけたので次の2つを購入してみた。

• EX-2841
• TM-2464

近所のダイソーで同じような目安品というのも購入してみた。100円だと誤差があるそうでこれを厳密な値として信用するなと書いてある。パッケージに入ったものをいくつか比べても針の指す値にはブレがあるようにみえた。エンペックスの計測器が届いたらそれも比較してみようと思う。

能楽の勉強

能: 敦盛 を観に行ったときに解説を朝原さんが行っていて、その内容がとてもよかったので朝原さん主催の読書会 (？) のようなイベントに参加してきた。

• 一途な恋心を、扇にからめて描き出す《班女》 第35回能のことばを読んでみる会

芦屋能舞台 という、外からみたら普通の家のようにみえて入ったら能舞台が現れるといった構造になっていた。能舞台って家の中にあるからびっくりする。初めて行ったからピンポンするのに躊躇する感じ。地図をみたらこの家になっているけど、本当にここなの？って感じで、他の参加者も集まってきて、そのうち常連さんがやってきてここであっていますよと案内してくれて中に入れた。中に入ったら立派な舞台があった。

結論から行ってこの読書会はめちゃくちゃよかった。覚えていることをずらっと書き出してみる。

• 班女は世阿弥作の能とみなされている
• 世阿弥が謡を書いたものに「五音」がある

  • 班女、ゲニヤ祈リツ、

  • そこにはこれだけしか記述されていない (失われてしまった？)
  • 世阿弥の息子が世阿弥の芸談をまとめた「申楽談儀」に班女の謡い方についての記述があることからも世阿弥作だと考えてよいらしい
• 謡は シテ方五流 によっても異同がある
  • 観世流 (かんぜりゅう)
  • 宝生流 (ほうしょうりゅう)
  • 今春流 (こんぱるりゅう)
  • 金剛流 (こんごうりゅう)
  • 喜多流 (きたりゅう)
• 能を完璧に理解しようとするのはすごく大変
  • 演劇を完全に理解しようといった見方はしないように、能も演劇の一種とみてそのぐらいの感覚の方が楽しめる
  • シテ方各流の謡本の異同を比べたり、併合したりしながらより正しい解釈に努める
  • 大昔の能の謡の意味に正解などない、シテ方各流のそれぞれの解釈はある
• シテやワキの台詞や謡には歴史、和歌、漢詩、韻を踏むといった、さまざまな意図が含められている
  • 教養がないとその意図に気付くことができない
  • 漢詩は 和漢朗詠集 から引用されている

20人ぐらい参加していた。朝原さんによると、いつもは10人に満たないと話されていた。私のように敦盛の解説を聞いて行ってみようと思った参加者がたくさんいたのかもしれない。

読む会のやり方はいたってシンプルで、詞章のプリントが配られててそれを参加者が数行ずつ順番に音読していく。歴史的仮名遣いだから音読するのもちょっと難しいんやけど。参加者の音読を聞いていると、慣れた人から素人までいるようなので拙くてもそれほど迷惑をかけている感じはしないのでまぁいいんじゃないかと思う。音読した後に朝原さんがその数行の意味や背景や歴史やなんやらかんやらをわーっと解説する。その解説の精度がすごい。

例えば、次のような一節がある。

花巾上 (はなきんしょう) に散りぬれば、

昔の謡の本はカナで書かれていて「ハナキンショウ二 …」と書いてあった。それを豊臣秀次も能が好きで謡抄に書き換えるときに漢字を当てようとしたが、キンという漢字が分からなかったか、なんらかの要因で一時的に「巾」という文字を割り当てた。豊臣秀次はいろいろあって切腹してしまうわけだけど、謡抄の編纂はその後も続いていてそのまま「巾」という文字で残ってしまった。他のシテ方の謡では「花琴上」とあり、意味的にも「琴」で正しいと思われる。音は「キン」で同じなので謡う上では何も違いはない。

秀吉をまねて秀次も能楽を自ら演じるようになったが、彼は公家・禅僧らに命じて最初の謡曲の注釈書である『謡抄』を編纂させ、後世の文芸に大きな影響を与えた。
豊臣秀次

ここには私は覚えていることをざっくり書いているが、もう少し詳細に説明されていた。謡の上でなんら重要でもないこんな歴史の話しを知っている人いるの？と思ってしまった。すごい。

もう1つ紹介すると、地謡の歌に次のような節が出てくる。

夏はつる。扇と秋の白露と。いずれか 先に 起臥 (おきふし) の床 (とこ) 。

この一節は新古今集和歌集の次の和歌を引用している。

夏はつる 扇と秋の白露と いづれかまづは 置かむとすらん 壬生忠岑

• http://jiuxia.web.fc2.com/Nohpage/NohWakan/Wakan03.html#P169

前に敦盛の詞章と一緒に観ていてなぜ単語の区切りがこのような感じになっているのか、まったく理解できなかった。それは私が和歌をまったく知らなかったからだと言える。謡や台詞の冒頭の一節は和歌を引用していることも多い。そのために和歌を知っていると謡をすんなりと聞き分けられるのだと思う。

このようにほんの数行の詞章にもたくさんの意図や背景があることを知った。朝原さんは能楽の研究者なので、詞章を読みながらそれぞれの文節の背景や意図を調べていることが伺えた。プロってこのぐらいやらないといけないなと。私は課題管理の文脈なら何気ないワークフローや作業にいろんな意図や背景を見出だせないといけないという気付きや示唆を受けた。

3ヶ月に1回のペースで開催している。次回は蝉丸という能を取り上げる。

• 『百人一首』で知られる蝉丸と、その姉・逆髪が出会い、別れる能《蝉丸》 第36回能のことばを読んでみる会

その後に蝉丸の能を演じるイベントも開催されるらしい。次回は読む会で詞章を予習した上で能をみるようにしてみる。するとまた違った趣になるのではないかと思う。

1時に寝て何度か起きて7時に起きた。昨日は遅くまで調べものをしていたわりには達成感がなくていまいちな金曜日になった。

ストレッチ

東京出張から戻ってきたときはあまり体調がよくないことが多い。今日は右足全般の張りが強かった。すねの外側、太ももの後ろ、股関節の関節部位、あちこち硬いなと思えた。今日の開脚幅は開始前154cmで、ストレッチ後158cmだった。数値もよくはなかった。なんとなくだけど、あと何年かしたら右足が動かなくなるんじゃないかとすら思えるようになってきた。いまストレッチしているのはその寿命を伸ばす行為だと考えている。なにもしていないのに体調が悪くなるというのがこれからどんどん増えてくるのだと推測する。悪いことばかりでもなく、先週まで辛かった首の痛みは気付いたら治っていた。

日本ナレッジ・マネジメント学会に加入申請を出した

先日の課題管理の雑談 のときに 日本ナレッジ・マネジメント学会 という学会があることを教えていただいた。学術的なところでナレッジマネジメント (知識経営) についてどのようなことが研究されていて (あるいはされていなくて)、どういう知見が溜まっているのかを知りたかったのでちょうどうちの会社にとってよい機会だと思える。

さっそく web のフォームから加入申請を送って、法人会員になるのは申請書を郵送する必要があるとのことでその事務手続きも終えた。法人会員は10万円/年の費用がかかる。学会などの年会費は「諸会費」という勘定科目使い、不課税となる。まぁこのぐらいの金額ならよいだろうと即断即決で決めた。

雑談の雑談

毎月お手伝い先の会社に出張して経営陣とサポート部門トップを含めたトップ3に プロジェクトの進捗報告 をしている。

プロジェクトの初期の頃は情報共有を密にしたり親睦を深める意図から (言うても月1回だけれども) 毎月行くことには意味はあった。しかし、うちのチームはフルリモートで開発が進む体制になっており、私が物理的にオフィスに出向かなくてもプロジェクトの開発にはほとんど影響を与えない。ではなぜ出張しているのかの意義はプロジェクトの進捗報告をオフライン会議でやっていることの方が大きいのではないかと思うようになってきた。早いときは20分ほどで報告は終わるし、普通にやっても30分もあったら報告内容は終わる。そこから参加者でその時々の雑談が始まる。会議のうち報告と雑談の時間が半々ぐらいといったときもある。

この雑談の機会を作る大義名分として、私が出張して進捗報告の会議があるから「出しになっている」のではないか？という仮説を思いついた。その場では「プロジェクトには直接関係ないのだけど、、、」という話題もちょくちょく出る。会社の業務には誰の責任でも担当でもない宙ぶらりんになる業務も発生する。チームならそれはマネージャーがすべて巻き取るわけだが、部署単位になると浮いたままになることもある。そういう話題がこの会議の中ではちょくちょくあがってくる。

建前上の会議を「出しにして」話す機会のない人たちが雑談するという、別の価値を提供している会議もあるんじゃないかと、顧問のはらさんと雑談していたところ、次の記事を紹介された。

• なぜ雑談が重要か

私も前日にざっと読んでこれはひどい記事だなと思ってスルーしていた。意外とこの記事の是非について盛り上がった。私がこの記事をひどいと思うのは次の点になる。

• 目的と手段をベン図 (集合を扱う表現) で表すという奇妙さ
• 会議では重要な情報を得られず雑談でこそ得られるという極端な物言い
  • そういうケースがあることは同意するが、大半は会議で重要な情報を得られているはずだ
• 会議と雑談を別の空間や時間で行う対立軸のように書いているところ
  • 会議の中で雑談して、会議内の雑談で発見があったのならそれは会議で得られたのと同じこと (上述した事例が正にそう)
  • 雑談は会議を補うものであって会議を置き換えるものではない
    • 会議で重要な情報を得られないなんてことは一般の業務においてあり得ない

試しにこの記事の著者が書いた本のファンである友だちにも意見を聞いてみたところ、次のようなコメントが返ってきた。

• 目的と手段を同じ座標の集合にするのは無理がある
• 手段を「目的の役に立つもの」と独自定義を置き換えることへの懸念と分かりにくさ
• 本とブログとのギャップに驚いている。どちらかが本人でどちらかがゴーストライターなのか、とさえ思ってしまう

前半の大事な前提が受け入れられないからその続きの内容も入ってこないといったコメントをその友だちからもらった。そんな話しをしていると、はらさんが javascript と java を混同して話す人はなにを話しても聞く気にならないと解釈すれば理解できると共感していた。それぐらい冒頭の目的と手段について書かれた内容はわかりにくいと言える。

著者が言いたいことは、本質的な課題は最初からわかりにくいもので顧客自身も気付いていないことが多い。いくつか調査したりヒアリングしたり、その結果を分析したりしながら徐々にわかってきたりすることがある。イシューからはじめよ ではそのことを「解くべき問題 = 課題を見極める」と表現している。私はそれを課題管理で解決しようとしているが、著者は雑談で解決しようというアプローチの違いについて書いてあるものだと意図は理解できる。しかし、記事の内容は分かりにくいので支持しないというのが私の立場である。

23時に寝て何度か起きて5時に起きてからだらだらネットしながら記事を読んだりしていて7時に起き上がった。

agent アプリケーションのメモリリーク調査

qa テストの一環として先月からテスト環境で毎分 agent アプリケーションにリクエストを投げる長時間稼働テストを実行している。なんとなく気になるところがあったからやったわけではあるけれど、長時間稼働テストによってメモリリークを検出できてしまった。自分を過信せずちゃんと検証しないといけないなと思えた。top コマンドの実メモリー (RES) を1ヶ月前と比較して増えているからメモリリークだと気付いたところ。これからメモリプロファイリングをしながら原因を追求していく。私が書いた (レビューした) go のコードでメモリリークはないだろうと高をくくっていただけにちょっとショックではあった。

go は標準ライブラリに pprof というプロファイラがあるので簡単にデバッグできる。プロファイラで昨日から調査していたところ、go-zeromq/zmq4 の処理でメモリリークしていることはわかった。それがライブラリの使い方が誤っているのか、潜在的な不具合なのかはまだこれから調査するところ。

ライブラリ側の問題を調査するので厄介ではあるけど、私が書いた (レビューした) go のコードでメモリリークしているわけじゃないことがわかって少しほっとした。

go の generics 勉強会

先日準備した資料 を使って勉強会を開催した。

• https://github.com/t2y/go-generics-study

この勉強会はある意味、うちのチームのメンバーが理解しておくべき内容なので go のプログラミングをやっていないメンバーが聞いてもあまり関心をもてない内容となっている。そういうお断りもした上で最悪2-3人ぐらいの参加者になるかと思ったもののプログラミングに関心がある人たちは参加してくれて5-6人ぐらいの規模にはなった。一方で内容も難しいし、私の説明がどれだけわかりやすかったか、私自身にはわからないのでなんとも言えない。質問も一切なかったので喋りきって疲れたという疲労感と、伝わったのか伝わらなかったのか分からない消化不良感と、金曜日だから今日はもういいや感でどっと疲れたというのが率直な感想になる。

とはいえ、私もずっと generics の仕様をちゃんと追いかけたいと思いながら先送りしていたものではあるので私の中では自分が go の generics の理解度をあげて実際の開発の中で使い分けるだけの判断基準をもてたことが収穫だったと言える。

20時にホテルに戻ってきてのんびりしながら気付いたら22時ぐらいになって、少しテレビをみて0時に寝て4時ぐらいから起きてその後はあまり眠れなかった。それでも7時過ぎまでだらだらしていた。

7月後半に実装予定の新機能の設計

9月までに実装する新機能のうち、唯一、私の頭の中で設計の見通しをもっていなかった機能の設計を行うことにした。

ざっくりした機能概要から私がふわっと想定していたものはずっと複雑なものだったのだけど、プロダクトオーナーに要件をヒアリングしているうちにそんな高度なものは求められていないことに気付いた。逆にその高度な機能の仕組みを提供しても、実際に運用の現場で使うにあたって手間暇だけかかってそんなものを求めていないと言われそうな気がした。そこで私が作りたいなと思っていた設計のアイディアは封印することにした。既存の先行プロダクトがもっている機能とほぼ同様のものを、うちらの開発しているプロダクトで実現するだけでよさそうにみえた。そのシンプルな機能の設計を軽くやっておいた。詳細を詰めるのは次のマイルストーンで私ではないメンバーに実装してもらうことになるけれど、なんとなく当初の想定よりも早くできそうに思えた。

ログ出力のリファクタリング

id 連携の処理で複雑なリソースを map 型で扱うときデバッグ用途でリソースを丸ごと dump したい。しかし、パスワードのような機密情報が含まれる場合はそれらはログに出力したくない。この処理をいまは連携種別ごとに実装していて、本質じゃないところで個別実装の手間があるのと機密情報の出力というセキュリティに関するところを毎回プログラマーが手で実装するのもどうかな？という気がして汎用のログユーティリティとしてロガーのライブラリ側で提供することにした。インフラやプラットフォーム的な機能に私は積極的に開発に介入している。

やり方の1つとしてオリジナルのリソースをコピーして機密情報だけ削除した一時的なリソースコピーを dump してログ出力する。go 1.21 で標準ライブラリに追加される maps パッケージを使うと map の操作が簡単にできる。コピー関数もある。しかし、この機能は shallow copy なので map の値にネストした map が含まれる場合はオリジナルの値を書き換えてしまう。ネストした map を調べてそれらもクローンしていく処理を実装した。excludeKeys に除外したい任意のキーを渡し、map の値を再帰的にチェックして取り除く。最終的には次のようなコピーユーティリティになった。

func copyWithoutExcludeKeys(
	fields map[string]any, excludeKeys []string,
) map[string]any {
	cloned := maps.Clone(fields)
	for k, v := range cloned {
		switch t := v.(type) {
		case map[string]string:
			strMapCloned := maps.Clone(t)
			for _, sk := range maps.Keys(strMapCloned) {
				if slices.Contains(excludeKeys, sk) {
					delete(strMapCloned, sk)
				}
			}
			cloned[k] = strMapCloned
		case map[string]any:
			cloned[k] = copyWithoutExcludeKeys(t, excludeKeys)
		case []map[string]any:
			for i, v := range t {
				t[i] = copyWithoutExcludeKeys(v, excludeKeys)
			}
		default:
			if slices.Contains(excludeKeys, k) {
				delete(cloned, k)
			}
		}
	}
	return cloned
}

前日に飲みに行ってきて1時に寝て何度か起きて7時過ぎに起きた。移動日であまり眠れていなかったのと夜遅くまで飲みに行っていたせいか、朝からどっと疲れた印象があった。

プロジェクトの進捗報告

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

今回はあまり大きな話題がなかったのと、いま機能開発の真っ只中なので報告もシンプルなもので済む。前月に導入した新しい取り組みをおさらいしつつ、それらが1ヶ月を経てどのような状況になっているかを共有することにした。前月は新しい取り組みを始めたからいろいろツッコミが出るかな？と期待したらほとんど出なくてやや消化不良だった。今回は逆に前月と大きな取り組みの違いもなく、淡々とやってますよ、進捗はまぁまぁですよみたいな共有だったのに報告後の雑談は盛り上がった。会議の趨勢は未だに読めない。

いずれにせよ、開発はこれからの1ヶ月が正念場になる。私も積極的に開発に介入するし、私がやらないといけない issue もいくつかある。人に張りついて指導していると自分の作業がまったく進められない。なので、指導していない時間に自分の作業を進める取り組みをそろそろ始めていく必要もある。心技体は悪くないのでまぁ大丈夫だろうとみている。

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

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

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

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

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

コパイロツトさんと雑談

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

• How to Succeed as a 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 対応らしい。

• ITS#10011 build: fix compatibility with stricter C99 compilers

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

メンバー課金による過ち

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

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

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

• https://basecamp.com/pricing
• https://backlog.com/ja/pricing/