0時に寝て何度か起きて気分が悪くて吐きそうになりながら7時過ぎに起きた。昨日は飲み過ぎた。やはり年末でだらけているのでオフィスへ出勤したのが9時44分だった。

slack コネクト

昨日の 税理士さんとの打ち合わせ内容 の1つに chatwork のフリープランの メッセージの閲覧制限 への対応がある。以前は制限がなかったらしいが、どこかのタイミングで40日制限に変更されたという。slack もフリープランは3ヶ月に制限しているので世の中の流れとしては仕方ないのかもしれない。それはともかく、chatwork に (先方の負担で) 課金するか、slack コネクト へ移行するかの相談をしたら slack でも構わないという。先方も slack を有料プランで事務所内では使っているという話しだった。問題提起してヒアリングしてみたらなんのコストもなく移行できることがわかった。

早速、今日、調べて税理士さんを招待した。その際に社外の個人アカウントを使って slack コネクトの振る舞いも検証した。slack コネクトのよいところは次になる。

• 通常のメンバー同様、slack コネクトで招待したメンバーはチャンネル、プライベートチャンネル、ダイレクトメッセージを使える
• 自分のワークスペースに他組織のワークスペースのチャンネルを追加できる (参加するワークスペースが増えない)
• チャンネル名、トピック、説明はそれぞれのワークスペース管理となる
  • とくにチャンネル名を自組織のワークスペースの都合で名前を付けられるのがよいと思う

無料ワークスペースに設定されている使用制限 によると、フリープランは slack コネクトを利用できない。invitation を送るとフリープランでも接続できるが、それは pro のトライアルになるため、3ヶ月だけ使えるみたい。

開発合宿の打ち合わせ

先日 作成した旅のしおり を使って開発合宿の打ち合わせをした。打ち合わせをする前に見直していると、いくつも不備や誤りに気付いて1時間前ぐらいから修正したりしていた。私の作る資料は手直ししないと小さい誤りがいくつもある。参加者は現時点で7名で、いまのところ、これ以上増える見込みはない。昨年は4名だったのでおよそ2倍に増える。きのいえは9名まで宿泊できるようにみえる。神戸組4人に対して関東組は3人参加してもらえる。関東からわざわざ来てもらえるのは本当にありがたい。このぐらいの規模で数年継続できるような仕組みや体制を作るのが当初の目標でよい気がする。昨年は初めてだったので手探りだったが、今年は2回目なのでもう少し段取りやノウハウを使ってうまく運営できればと思う。

みんな時間通りに打ち合わせに集まってくれて、自己紹介して、主旨を説明して、大雑把なタイムスケジュールを紹介して、質疑応答をした。私の知人に声をかけているので神戸組と新規参加の関東組とはまったく面識がない。そういった人たちを少しでも話しやすいよう話題を設けたり、きっかけを作ったりすることがコミュニティマネージャーとしては求められる。別に私がコミュニティマネージャーを目指しているわけでもないが、コワーキングやコミュニティの価値の実践的なものを理解していく上で避けられないと考えている。私自身コミュ障で他人と話したくない人間なので、役割としてやらないといけないというポジションに追い込むことでその機会を得ていると言える。あと2ヶ月、詳細の詰めをしていく段階に入ってきた。

マネーの虎たちのその後

たまたまみたらおもしろかった。昔リアルタイムでみていた。いまの感覚でみればハラスメントやら人格否定しまくりの時代背景の史料の1つも思える。そのときボロクソに言っていた社長たちもその後破産している社長は多いみたい。そして、すごいのが数十億といった負債を抱えて破産してもまたやり直して復活している社長もいるということ。その再起のきっかけにセミナーや講演をしてマネーの虎を宣伝文句として使っているところが本当にダサいとは思うけど、そういったなりふり構わず売上を上げるためなら何でもやるといった姿勢が復活するためのバイタリティになっているのかもしれない。昭和世代のハングリー精神のようなものを感じる。

その中でも南原竜樹さんがすごい。年商100億の会社が取引会社の突然の倒産から資金繰りが悪化して破産して、2年かけてすべての負債 (20億円) を返済して、ホームレスになってからまた再起してまた年商100億まで復活したらしい。経営能力がある人はゼロから成功できるというのがよく分かるモデルケースにみえる。失敗して門前払いする人がいる一方、助けてくれる人もいたみたい。

• 元『￥マネーの虎』南原竜樹さん 年商100億円社長が45歳でホームレスに転落、どん底からの復活劇

一方で、手を差し伸べてくれる人もいた。中でもありがたかったのは、旧知の社長が会社の空きスペースの提供を申し出てくれたことだ。すべてを失った南原さんは、間借りしたオフィスで「過去の成功にとらわれず、心を入れ替えて再出発する」ことを心に誓った。

「僕は、“老害化”した経営者をたくさん見てきました。高齢になった経営者がいきなり頓珍漢なことを言い出して、周囲を困惑させるケースも少なくない。だからちょっと早めに準備して、いろんな方に事業を引き継いでもらいました。(…中略…) 頭も体もしっかりしているうちに、自ら退くのが一番なんです」

手持ちの資金はゼロだったので昼夜を問わず働いた。
「資金を得るためにオートバックスで8時間、吉野家で8時間、モービル石油で8時間バイトして、吉野家ではお客さんがいない時に立ったまま寝ていました（笑）。

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

プロジェクトの進捗報告

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

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

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

23時に寝て1時に起きて4時過ぎに起きた。昨日、打ち合わせに来た親がうちに泊まっている。親がいると4時起きになる。

しくじり先生

たまたま元プロ野球選手の 森本稀哲 選手のしくじり先生をみた。日ハムで新庄選手が活躍していたときにブレークした選手としてしか私は知らなくて、その後、どうなったのかも知らなかったが、キャリアハイを迎えた後は期待された成績を残せず、苦労しながらも野球を続けて引退試合をしてもらえるぐらいには活躍された選手だったようだ。無名のまま引退するプロ野球選手もたくさんいる中で、本人も話していた通り、一時期レギュラーとして活躍して、16年3球団もプロ野球選手で入れたことは間違いなく幸せな選手の側だと思う。

病気のため、小さい頃からコンプレックスを抱えてきた人生の中、それが改善したり悪化したりもしながら、いまふりかえっているのは、人は共通してそういうところに陥ると思えて親近感もわく。いろいろなしくじりもあった中での私にとって気になったのは次の言葉だった。

うまくいっていないときに頑固で他人の言うことを聞かないから自分で悪い状態に気付けなかった。

マイクロ法人やフリーランスの一番の難しさはここにあると私も思う。1人だとキャリアに与える影響に自身の状態がかなり大きい。「無知の無知」への 3ステップ を常に私は意識していて、自分の誤りに自分で気付けていない状態が一番怖い。私にもいくつか成功体験があるから、自信過剰になるとこのやり方ならうまくいくはずと誤った方向に進んでしまう懸念は避けられない。周りにいる人たちに「それ、おかしいよ」とか「何をやっているのか理解できない」とか言ってもらう機会や制度設計に気を配っている。私も他人の言うことをあまり聞かない傾向があるので稀哲さんの頑固で失敗したという体験談は親身に思えた。

スタンディングデスク受け取り

ジモティーで引っ越しで処分していた「DEVAISE スタンディングデスク」を2000円で購入した。メーカーのサイトがどこかわからにので amazon のリンクを張っておく。これは実家の離れではなく、うちのマンションでホットクックを置く台として使う。お昼に東灘区まで引き取りに行ってきた。メッセージを送ると相手のレスポンスの早い方で20分以内には返信が届いていた。メッセージのやり取りだけでシステムに慣れた相手だというのがわかる。本当は引き取りも13時の予定だったのだけど、こっちの都合が変わったので11時頃に早くできない？と訪ねたら20分後には11時45分にいけるよと返ってきて早く引き取りした。

実家との往復

親を送るのと、実家コワーキングスペース化のための椅子を運ぶのと、親戚と打ち合わせの3つを兼ねて実家へ車で帰る。道中、姉の職場へ立ち寄り相続関連の書類を渡して、親戚の家にお邪魔して少し打ち合わせして、16時過ぎには実家へ着いた。カフーツのいとうさんから引き取った椅子4脚 をようやく実家の離れまで運んだ。2脚ずつで2回かかった。あとは机を1-2つ探してくればコワーキングスペースとして形は成り立ちそう。

それからまた神戸へ戻る。1日で神戸と実家を往復したのは初めてかもしれない。帰りは途中で眠くなって淡路 SA で休憩した。

昨日は夜にいろいろ作業して、1時に寝て4時に起きて7時に起きた。

テックブログ執筆

先週から調査している内容 についてテックブログを書き始めた。マネジメントや実装をしていると筆が進まなくて書き始めるのが随分と遅くなってしまった。学校の試験前に、試験勉強やらずに部屋の掃除をやってしまったりするような感覚。午前中は昨日 go-ldap に送った pr がまとめてマージされた。その修正を取り込んだライブラリのバージョンで関連するところのコードをリファクタリングしていた。それでもようやく書き始めた。書き始めたら一気に 2/3 は書けた。本当は晩ご飯を食べた後にレビューできるところまで書いてしまおうと思っていたが、そこまで体力 (集中力) が続かなかった。なんとなく張り合いがなくて適当なところで妥協してしまう。

試行錯誤から学ぶ開発スタイル

たまたまみかけた記事でひどい内容の記事をみた。一読しただけでもやもやしていたのを知人と議論していて言語化できるようになったので書いてみる。

• エンジニアが仕様案を手戻りさせるアンチパターンはもう終わりにしよう

もっと前段にエンジニアが議論に参加する、なんなら議論をリードするくらいのことをしていく必要があるでしょう。

こういうこと言い出すマネージャー (PO) 多いし、意見そのものは一理あるんだけど、これをエンジニアがイニシアティブとってやっていたらマネージャーいらないでしょ？ということを自覚していない。もっと言うと、PO という責任のある立場の人が大変という理由で責任放棄しているようにみえてしまう。(翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 という記事では実際にテックリードまたはエンジニアがプロジェクトのイニシアティブを取っていると書かれている。もしそうするなら、まず自身のスキル不足や未熟さを受け入れないといけない。

マネージャー (PO) にとって大きな役割は意思決定であって、仕様案や計画において技術的なところがわからないのであれば、エンジニアに委譲したり相談して事前にいくらでも調整できるはずだし、その調整作業そのものはマネージャーの仕事の1つと言える。そういった調整をマネージャーがやるからエンジニアは実開発の設計や実装に集中できる。結果的に生産性も上がる。この文章から伺えることはリファインメントや計画に臨んだときにダメ出しされてやり直すことを手戻り、大変、効率が悪いとネガティブに捉えている。逆に言えば、最初から完璧に仕様案を作れるはずだと思い込んでいるふしがある。

そして、誰もが知っていることだが、最初から完璧な仕様案や計画など作れるはずがなく、不確実性を許容しながらスクラムやアジャイル開発といった開発方法論の取り組みで調整していくというのが、モダンな開発のやり方である。その試行錯誤や手戻りは無駄なことではなく、チームやプロジェクトが学ぶべきことの1つだという考えがこの文章からは読み取れない。そして、自分が仕様案を適切に作れなかったのを自分のスキル不足だと認めず、チームのエンジニアが議論に参加していないからだと責任転嫁している。それはマネージャーが技術的に大事なことを理解できていなかったとふりかえり、計画を修正したり、次に計画するときは同じようなことが起こらないよう、努めていくというのがスクラム的なプロジェクトの進め方になるはずだ。手戻りはアンチパターンではなく、学びの過程や必要な試行錯誤であると認めて受け入れるところから始めるべき。

2時に寝て7時半に起きた。昨日からよく寝た。また心機一転。

ldap エントリーの crud api

先週から ldap クライアントや そのプール を実装して結合テストも一通り書いていた。今日はそれらを使った crud な web api を一通り実装した。クライアント実装もテストもしっかり出来ているので後は時間の問題で1つずつ確認しながらコードを書いていくだけだった。こういう作業になると、まとまった時間があればすぐに終わる。他のメンバーのコードレビューをみたり、設計の話しをしたり、他に意識を取られてあまり自分の作業に集中できなかった。

言葉が通じないもどかしさ

先週「参考にして」と指示したものが「全コピー」で驚いてしまった。私がいくつか指摘したらすぐに削除し始めてさらに落胆した。自分の頭で考えて作業していないようにみえる。

開発というお仕事は自分で考えて、コードの1つ1つに明確な意図や根拠をもって書くものだ。もちろん、情報不足や設計に自信がもてなくて一時的に曖昧な実装にするときもあるけれど、それは懸念事項として把握しておくことで将来対応すればよい。基本的に追加するコードにはすべて意味がある。

他人が分からなくても自分が理解できているのなら、自分の考えを説明し、それが論理的であったり筋が通っていれば、私は自分の考えと違っていても構わない。説明できないコードを追加して、ツッコミを受けてなにも説明できない状況をみているのは本当に悲しい。

山田ズーニーさんの著書に書いてあった「考えないという傷」を思い出した。

• 「働きたくない」というあなたへ ７

23時に寝て何度か起きて8時に起きた。ホテルの部屋が暗いと朝になった気がしなくて2度寝したら寝坊した。

組織の対応と sns の議論

先日の sns 騒ぎ の続き。公式からの声明も出たので軽くまとめておく。

• PyCon APAC 2023におけるNOCコンテンツに関するご指摘について

簡潔な文章に事実の記述、責任の所在、関係者への配慮が含まれていて十分な内容にみえる。法律なども関係するため、弁護士チェックが必要なことを考慮すると、こんな短期間で組織の見解を出せたことは運営側の体制を鑑みることができる。それが適正かどうかは人によって判断は異なるかもしれないが、私はコミュニティ運営というボランティア主体の組織であれば十分なものだと思えた。その後のネット上の議論も、ちゃんと追えてはいないが、様々な見解で議論は進んでいるようにみえる。

今回みていて感じたことの1つに、コミュニケーションが成り立たない人が世の中にはたくさんいるということ。議論の前提や論理の出発点が異なる人たちは、一定の論理を含む全体や大局を理解できず、細部や詳細のところだけを拠り所に自身の論理を組み立てる。意見の差異があることはなんら問題はないが、論理が通じないのは議論の余地すらないようにみえた。そういう人たちを会話するときは前提条件を同じにしたり、思想の背景を共有したり、もっと時間をかけて丁寧にすり合わせていく作業が必要になる。そして sns のような、流れが速い不特定多数の議論はそういった丁寧な作業にまったく向いていない。だから sns で議論することは時間の無駄である。

コネクションを共有しないプール

go の非同期処理であまり使われることはないが、semaphore が準公式ライブラリとして提供されている。私はセマフォを気に入っていてたまに使う。

ldap プロトコルではコネクションの確立とログインに相当する bind の操作が分かれている。コネクションを確立したまま、ログアウトに相当する処理ができればプールを設けることでコネクションの再利用ができる。

• The LDAP Unbind Operation

しかし、このドキュメントの説明によると、unbind という操作は用意されているものの、ログアウトに相当する機能ではなく、クローズする前に通知するといった用途だと書いてある。unbind のリクエストをした後にはクローズするしかないといったものになる。それを踏まえて、プールはセマフォで同時接続数のみを制御するのでよいのではないかと思う。そんなワーカープールを実装してみた。

type ClientPool struct {
	config *config.LDAP
	sem    *semaphore.Weighted
}

func (p *ClientPool) Get(
	ctx context.Context,
) (*LDAPClient, error) {
	if !p.sem.TryAcquire(1) {
		return nil, fmt.Errorf("failed to acquire, wait and get later")
	}
	client := NewLDAPClient(p.config)
	if err := client.Connect(ctx); err != nil {
		p.sem.Release(1)
		return nil, fmt.Errorf("failed to connect: %w", err)
	}
	return client, nil
}

func (p *ClientPool) GetAuthenticated(
	ctx context.Context,
) (*LDAPClient, error) {
	client, err := p.Get(ctx)
	if err != nil {
		return nil, fmt.Errorf("failed to get: %w", err)
	}
	dn := p.config.BindDN
	passwd := p.config.BindPasswd.String()
	if err := client.Bind(ctx, dn, passwd); err != nil {
		p.sem.Release(1)
		return nil, fmt.Errorf("failed to bind: %w", err)
	}
	return client, nil
}

func (p *ClientPool) Close(client *LDAPClient) error {
	err := client.Close()
	p.sem.Release(1)
	return err
}

func NewClientPool(cfg *config.LDAP) *ClientPool {
	return &ClientPool{
		config: cfg,
		sem:    semaphore.NewWeighted(cfg.ClientPoolSize),
	}
}

1時過ぎに寝て4時に起きて7時に起きて8時に起きた。夜更ししてネットをみてて寝坊した。先週に引き続き、いくつかリファクタリングしつつ、午後からはコードレビューして、それが終わったからまたコードを書いてた。

正義の追及

もう何年も前から twitter はやめようと考えながら、なんかだらだら続けてきていた。イーロンマスクが買収して、課金しないと機能がなくなったり、利用者も減ったりしていて、私もよいタイミングだと twitter をやめることにした。本当はアカウントをアーカイブモードのように凍結できればよいが、それは故人向けにしか提供していないみたいなのでアカウントを削除するといったことはしていない。というのは、削除すると一定期間を経て他人が同じ id でアカウントを作れるそうなので、なんとなくそれは嫌だなと思ってアカウントだけは残している。

たまたまあるイベントで、運営側の不手際で参加者のプライバシー侵害になるかもしれないといったトラブルが起きたらしい。起きてしまったものは仕方ないが、その不手際に気付いた人が sns (x) で大げさに拡散して、衆知の知るところになって、実被害や問題の大小とは関係なく、そういった不手際があったことがことさら悪いことかのように、また運営の対応も悪かったかのように、(おそらく) 実被害もないのに大きな問題であるかのように喧伝されてしまった。少なくとも運営が対応して以降は被害が出ないことから、それ以上の言及については本人の承認欲求でやっているようにしかみえなかった。醜かった。

SNSで晒すのはトラブル解決の手段としては最悪で全面戦争宣言に等しいという認識 https://t.co/Xrp7zu1ocJ

— 大平 之人(Yukito Ohira) | フリーランスエンジニア完全攻略バイブルの人 (@yohira_dev) October 30, 2023

昔からインターネット上でのトラブルというのはあったけれど、sns は数の暴力が強過ぎるように数年間から感じるようになった。とくに正義の力が強過ぎる。一見それはよいことのように思えるが、正義が現実や事実ではない場面もあるかもしれない。今回もなんらかの実被害や迷惑を被ったという話しはいまのところ1つも見聞きしていない。それに対して、自分たちの主張が正しいからと言って、運営を強く非難するような多くの人からの言動というのはやり過ぎにみえた。sns 上での流布の速度が速過ぎるせいで組織の対応は追いつかない。私は組織の人たちをよく知っているので、待っていれば然るべき謝罪や声明が出ることを信頼できる。この信頼がない人たちにとって、いま起こっている炎上に対して組織が即時で対応しないと、組織の怠慢や隠蔽を疑う声がちらほら上がっていた。sns の速さに人間が慣れてしまったのだろう。信頼がない人にとっては悪意のある組織かもしれないと疑って予防的に慎重にコメントするのも仕方ないのかもしれない。しかし、それが問題をより分かりにくく複雑にしてしまう遠因にもなっているように思えた。

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

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

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

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

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

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

0時に寝て3時、5時ぐらいに起きて7時に起きた。

ストレッチ

先週に比べれば、出張を終えてのんびり過ごしていたのもあってかなりよくなっている気はした。足の張りはどこも目立つほどではなく、左の太もも後ろの筋肉の張りが強かったぐらいで復調している感じはした。腰もそれほど自覚症状はなかったものの、トレーナーさんからみると硬めだったという話しもあり、たしかに部位によってはきついところもちらほらあって、腰はまだまだ復調していないことがわかった。今日の開脚幅は開始前155cmで、ストレッチ後158cmだった。暑さも和らいで時間も出来てきたので少し運動してもよいかもしれない。

コワーキングとコミュニティ

2014年11月に発刊された Coworking Magazine の創刊号がある。昨年ぐらいまでは amazon に在庫があって購入できたが、いまみたら在庫がなくなったようだ。2014年に出版して2022年まで在庫が残っていたという雑誌ではあるが、内容はとてもよいものだと私は思う。2014年頃、コワーキングという新しい働き方のスタイルが日本に輸入され、広まっていったときのそのときの雰囲気や価値観を本書から読み取ることができる。多くのコワーカーたちがコメントしていたり、インタビュー記事もあったりして、コワーキングの価値やコミュニティの良さを語っている。こうやって出版という形で残しておくことで、その歴史の過程を学ぶ機会にもなることが本書から伺える。

私はコワーキングのような価値観や働き方を2016年頃から知ることになり、私もコワーキングスペースで作業したりするようになった。しかし、当時はワークスペースとして利用しているだけでそれはコワーキングと呼べるものではなかった。本書を読んでいて、ある人はコワーカーとはコミュニケーションを取る人たち、またはコミュニティに参加する人たちを指すのだと話していた。コミュニティ参加しなければ、コミュニティの恩恵を受けることが難しく、その状態をコワーキングとは呼べないようだ。2022年6月に カフーツさんを訪問 して、いとうさんとコミュニティについて話してみて、私の知っている IT 業界のコミュニティの在り方とコワーキングにおけるコミュニティには通じるところがあって、それ以来、コミュニティを学ぶことや課題管理のヒントになると考えて、いとうさんの主催しているオフライン／オンラインイベントにも参加するようになった。

コワーキングの価値はコミュニティやコラボレーションにある。作業場としてのワークスペースではない。コラボレーションと言うと、企業間の業務提携だったり、新商品企画を共同でやるとか、そういう大きなものをイメージしてしまうが、コワーキングにおけるコラボレーションとはそんな大きな話しではない。ただ一緒に作業しながら、軽く雑談したり、なにかのテーマで話し合ったり、その場に一緒にいることで生まれるコミュニケーション全般を指す。共通の話題や課題に対して一緒に考えたりする行為で構わない。もっと小さいものだと気付けるようになった。

それは私がマイクロ法人を経営して1人で黙々とずっと仕事をしていても、この延長上に新しい価値を築けるような気がしないというのを実感した後だった。リモートワークと相談相手 にも書いたが、会社に勤めていると自然と同僚とコラボレーションしている。マイクロ法人には同僚がいないのでコラボレーションによる気付きや刺激を受けることができない。コワーキングは1人会社やフルリモートワークのような、同僚が身近にいない人たちへコラボレーションの価値を提供しているということを、身に染みてわかるようになった。

IT 業界では Open Source Software の歴史をみると、古くは1950/1960年代の Unix に端を発し、1990年代の Linux の公開、1998年の Netscape 社の Mozilla Firefox のソースコード公開などの大きなエポックメイキングを経て、社会運動としての OSS 文化や OSS コミュニティが発展してきた。その歴史の過程で日本では2010年前後から IT 勉強会という、主に Web 業界の様々なバックボーンをもつプログラマーが技術情報を共有するようになった。OSS の技術はみんなで共有するものという価値観があるが、それはこういった IT 勉強会によって草の根的に広まっていったと思われる。私もそんな IT 勉強会に参加して技術を研鑽してきたプログラマーの1人なのでまさに生き証人でもある。それはまさにコワーキングの人たちが言う、コミュニティのそれとまったく同じである。IT 技術という共通の話題で困っていることを共有したり、不具合を改善したり、新しいプロダクトを開発したりしていた。製造業の人たちには驚かれたが、web 業界はコンテンツを公開して広告費で儲けるビジネスモデルであることから、自社の技術情報やノウハウをすべて公開してしまう。ビジネス上では競合他社であっても、別会社の開発者とも仲良くなって技術情報を共有している。それが業界全体のレベルの底上げをしてきた。いまもその文化は変わっていない。

次にくる流れとして、IT 業界のプログラマーはどんどん独立していくと私は考えている。いまもフリーランスになる人は増えつつあると思う。スキルも経験もない若い人が安易にフリーランスになることはお奨めしないが、20年も働いてきたベテランはどんどんフリーランスになって、組織の枠に収まらない活躍をしていけばよいと思う。マイクロ法人を経営することのハードルも歴史上、もっとも低くなっていると私は思う。私が経営できているのだから普通のプログラマーでも経営できる。しかし、1人で働いていると、私が陥ったような「行き詰まり」を覚えるようになるかもしれない。コワーキングやコミュニティはそれを防ぐきっかけになるのではないか？と思うようになってきた。この「行き詰まり」に名前を付けたい。私が感じたのは次のようなことになる。

• 自身が成長しているように思えない
• 日々の生活で気付きや刺激がなくなる
• 新しいことに挑戦する気概がなくなる
• 自分の状態が自分で判断できない
• 誰に何を相談していいか分からない

もしかしたら会社に勤めているときも同じような状況になっているときもあったかもしれないが、会社に所属していると、仕事はいくらでも上から降ってくるし、仮にぼーっと何もしなくても給料は毎月もらえる。この先どうやって生きていくのか？という、生命としての根源的な問いから目を背けてしまうような錯覚がある。なんの後ろ盾もないマイクロ法人やフリーランスになることでこういった根源的な問いから目を背けられなくなる。私の場合、そのことに2年目で気付けるようになった。今後のビジネスにおいても、直接的ではなく間接的にコミュニティというのはキーワードだと考えている。コミュニティへの理解を深めるためにもコワーキングには今後も注目していきたい。

23時に寝て何度か起きて7時に起きた。

開発方法論／開発ガイドの更新

前回の改訂 から約4ヶ月ぶりに開発方法論と開発ガイドを改訂した。

• 開発方法論: プロダクトで採用している開発方法論の概念をまとめる
• 開発ガイド: 開発方法論を具体的に実践する方法についてまとめる

近いうち、チームに新規メンバーが入る。今回の開発を経て新たにわかったことや変わったところなどを更新するつもりで全体を読み直してみたが、大きく変わったところはなく小さいアップデートに留まった。開発方法論に 情報共有とコミュニケーションのレベル というタイトルで5段階のレベルについての考え方を追記した。この内容は私もまだ完全に言語化できているわけではない。「聞かなくてもわかる」という価値観の存在をまったく疑っていないが、その背景にあるコミュニケーションの在り方や人間関係や組織での運用についてまだ曖昧なところが多い。それも含めて考えるよい機会だと思ってうちのチームに向けた内容に整理し直してまとめてみた。もう2-3回ぐらいこのテーマで話しをしたりすると、より言語化できてもっとよいものができそうな気配は感じている。

fun/done/learn のカスタマイズ

昨年からふりかえりの手法として fun/done/learn という手法を採用している。2週間のイテレーションが終わったときに毎回このフレームワークを使って、やったことをメンバーに共有するといった用途のために使っている。大きな開発のふりかえりを行ったときにマイルストーンごとの fun/done/learn の個数の変化などもふりかえってはいるが、そこの統計値がなにかに役に立つようには、いまのところ、うちのチームでは思えない。

今回のふりかえりをしているときにメンバーから done はいらないのではないか？という意見が出た。この手法の発明者のオリジナルの記事 ファン・ダン・ラーン(FDL)ふりかえりボード と読むと、done = deliver だし、done しなかったことも含めてのふりかえりを実践していたことが伺える。うちらはやったことをふりかえるためのフレームワークとして活用しているため、done がデフォルトでプラス fun/learn が付くといった運用になっていた。その通りだなと納得して done に置き換わる、うちらの開発の運用にあうカテゴリを考えてみて give を採用した。ゴロがよいように fun/give/learn と呼ぶ。

give とは、このマイルストーンでやったことを形式知として、他のメンバーに共有可能な状態にしたという意図を表す。wiki を書いたりするのもよいし、テックブログを書くのもよい。暗黙知を形式知に変えるには少し手間暇がかかるのでちょうどよいカテゴリに思える。3つのカテゴリに属するときにもっとも価値が高いような運用にも向いている。そのためのボードも作って、これを jamboard の背景に設定してふりかえりをしている。何ヶ月か運用してみて、うまくいきそうだったら fun/done/learn の亜種としてどうだろう？といった提案のテックブログを書いてみたい。

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人以上の社員全員の名前を覚え、日々の業務で社員の行動などに気を配ってすべての社員に声をかけたりするようになったという。このエピソードもなかなか私には効く話しで、私は他人にかなりのレベルで関心がない。もし自分の会社で社員を雇うことになったら待遇がどうとか以前に、その人そのものに関心をもつという姿勢を覚えておこうと思う。