Posts for: #Communication

論理の通じない人たち

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

組織の対応と sns の議論

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

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

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

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

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

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

しかし、このドキュメントの説明によると、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),
	}
}

sns の百害

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

正義の追及

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

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

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

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

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

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

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

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

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

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

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

雑談について雑談した

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

ストレッチ

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

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

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

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

雑談の雑談

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

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

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

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

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

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

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

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

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

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

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

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時半ぐらいまで飲みに行ってきた。楽しかった。

ldap プロトコルの persistent search

0時に寝て5時に起きて6時半に起きた。朝から大鼓方を調べたりしていた。

persistent search あれこれ

ldap プロトコルの文脈でクライアントがサーバーに接続して、エントリーの更新を検出して更新があったエントリーのみを取得することを persistent search (永続検索) と呼ぶ。メッセージキューで言うところの pubsub の consumer に相当する機能。フィルター条件に合致したエントリーのみを取得するという側面では検索と言える。

ietf のワーキンググループに次のような仕様がある。

go-ldap で過去に Add Persistent search control + PersistentSearch() #80 で実装を追加しようとしたのもあったので調べてみた。しかし、この機能に openldap は対応していないようだ。

以前から調べている openldap の syncrepl も persistent search を実現する機能の1つと言える。ldap に詳しくないと用語と機能と実装の切り分けができなくて困惑する。syncrepl はもともとレプリケーションのための仕組みではあるが、pubsub の consumer としても使える。そういうときに syncrepl を使って “persistent search” を行うと言ったりする。このときに先の ietf に提案されている persistent search とはまったく関係ない。だから混乱する。

lopenldap サーバー同士で syncrepl の provider の機能は次の overlay モジュールによって提供される。逆に syncrepl の consumer の機能は openldap の組み込みの機能で提供される。なんらかの歴史的経緯があるのだろう。

overlay syncprov

ldapsearch コマンドで persistent search (syncrepl consumer) を実行するには次のようにする。

$ ldapsearch -x -H "ldap://localhost:389" -b "dc=example,dc=com" -D "cn=Manager,dc=example,dc=com" -w "secret" -E '!sync=rp'

ldap プロトコルの文脈で persistent search を行うといった場合、クライアントから pubsub で言うところの consumer を用意するといった意味だけで、その実装や通信方法はいくつか実現方法があるということを学んだ。

サイトデザイン最終レビュー

19時からデザイナーさんとはらさんと打ち合わせ。少し前に用意してくれた サイトデザインのサンプルページ の最終レビューを行った。全体としては気に入っているので概ね ok なのだけど、詳細の気になったところやデザインの機微のようなところをはらさんと一緒にデザイナーさんとやり取りして共有した。

デザインだけをみてこちらで想定していたことも、デザイナーさんの意見や視点を伺ってみると発見があっておもしろかった。逆に言えば、デザインだけでデザイナーさんの意図を伝えるのはとても難しいということもわかった。背景の説明を受けると論理的だったり合理性があったりするものの、なにも情報がない状態でそのことに気付くのは難しい。これはコードリーディングにおいても同じで、作者に意図の説明を受けながらソースコードを読むと簡単に理解できたりする。そして、デザイナーさんもうちらの意見から考え方を見直すこともあった。ウェブデザインのようなものを1人で完全に気付きを得るのは難しそうだ。

はらさんにレビューに入ってもらっていてとても助かる。私は ui/ux については素人なので、要件やレビューする視点の重要なところにツッコミを入れてくれるので気付くことも多い。私がコードレビューで設計やプログラミングについて指摘しているのも、別の人の視点からみるとこういうみえ方をするんだろうなと思いながら聞いていた。「餅は餅屋」とはよく言った言葉だ。自分がよくわからない分野のお仕事を依頼もしくは話すときは、自分たちの立場でそういった外部の専門家を雇うことの重要性も同時に理解できた。私は課題管理の専門家としてそういうポジションを作っていきたい。

トイレにうんこ

0時に寝て4時に起きてドラクエタクトやりながらだらだらしているうちに少し寝て7時に起きた。

トイレにうんこを詰まらせた

いや。正確にはトイレが詰まってうんこを浮かべた。朝トイレへ行ったら洋式トイレにトイレットペーパーが漂っていた。前に使った人が流していないのかな?と考えて気持ち悪いのですぐ流した。これまでも過去にそういうことがたまにあった。あとから考えると、誰かのいたずらでなにかしらトイレに詰まるものがトイレットペーパーの下に隠されていた可能性もある。この時点で次に水が流れるかどうかのチェックをするべきと洞察できていなかった。

それから、うんこして流したらトイレが詰まったようで流れない。微妙に便器から水が溢れてきた。ぎりぎり溢れ返ることにはならなかったのでトイレの床にうんこが散乱する最悪の状況にはならなかった。しかし、トイレにうんこがぷかぷか浮かんでいる状態になった。べつに私が悪いわけではないと思うのだけど、トイレにうんこが浮かんでいる状態にしてしまったことにとても罪悪感を感じた。

幸い朝8時からシェアオフィスにいるのは私ぐらいで、多くの利用者は10時前後にならないと出社してこない。いまトイレに誰かが入ってきて犯人扱いされることはなさそう。なんか行き当たりで人を殺めてしまった殺人犯みたいな心境になった。運営会社のサポートは9時から。1階へ降りていって掃除のおばちゃんに尋ねてみたけど、うんこが浮かんだトイレの階は自分たちの管轄じゃないと断られてしまった。(´・ω・`) 仕方なく、時間を待って9時ぴったりにサポートに電話して聞いてみる。サポートにも断られたらどうしよう?不安と緊張が走る。サポートのお姉さんは (当然ではあると思うけれども) 全然平気ですよーと快く応じてくれて安心した。まぁ、電話しているお姉さんが対応するわけじゃないしね。

電話で一報を終えて、その後、トイレ業者さんが来るまで自分のうんこを浮かべておいていいのかどうか、すごく悩んだ。かといってうんこを取り出す勇気もなく結果的にそのまま放置した。人間がしょぼい。40年以上も生きてきて自分のうんこの処理もできないのかと思うと本当に情けなくなった。「入るな、危険」ぐらいの張り紙しといてもよかった。本当の犯人だったらここでとんでもないトリックを思いついて実行するところだけど、一報したことでそこまでの切羽詰まった状況でもなくなっていた。もし警察がやってきてもサポートのお姉さんが犯人じゃないと証言してくれるだろう。

9時から打ち合わせがあって、1時間半後、恐る恐るトイレを見に行ったらすでに詰まりは解消していてうんこもなくなっていた。平和な日常が戻ってきてよかった。

平安時代とか、都はうんこまみれだったという記事を昔読んだのを思い出した。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。

最初の30分でサイトデザインをみながら、はらさんのレビューの視点や背景を教えてもらっていくつか気付きを得た。後半は来月の雑談会へ向けて、課題管理の資料のレビューを始めて、いつもは1時間で打ち合わせを終えるのだけれど、つい課題管理の話しでテンションあがって話し過ぎてしまって30分オーバーした。打ち合わせのような時間を決めている会議で議論に熱くなるのはよくない。失敗したなーと反省した。

パスワードの表現

go でパスワードを扱うときに平文をハッシュ化して保持するためのユーザー定義の構造体を作りたい。構造体にハッシュ化した値をもつとしても、プログラマーが誤って任意の値を設定できないように制御したい。ここで go はオブジェクト指向言語ではないのでコンストラクタという概念がない。私が知っているもっともシンプルな方法は interface と private な構造体を組み合わせてコンストラクタに近いものを実装する。コードレビューしていてメンバーにパスワードがハッシュ化されていることを保証する仕組みをお題として指摘してみた。

今日のところは解決できなくて月曜日に持ち越しになった。私の想定する模範解答は次のようなものだけど、ちゃんと自分で考えて実装できるかなぁ。

type Password interface {
	Authenticate(s string) error
	Get() []byte
	String() string
}

type passwd struct {
	hashed []byte
}

func (p *passwd) Authenticate(s string) error {
	return bcrypt.CompareHashAndPassword(p.hashed, []byte(s))
}

func (p *passwd) Get() []byte {
	return p.hashed
}

func (p *passwd) String() string {
	return string(p.hashed)
}

func NewPassword(s string) (Password, error) {
	h, err := bcrypt.GenerateFromPassword([]byte(s), bcrypt.DefaultCost)
	if err != nil {
		return nil, err
	}
	return &passwd{hashed: h}, nil
}

ぼくのかんがえたさいきょうの定例会議

1時に寝て何度か起きて8時に起きた。昨日ブログを書き終えてほっとしたのか、珍しく寝坊した。

課題管理の定例会議の進め方

5月31日から 新しい開発がスタート していてイテレーションを2週間に、そして定例会議も同様に隔週とした。その狙いは先日の日記に書いてあるが、これまで毎週やっていた定例会議の進め方はあわないので新規に会議の進め方を刷新した。これまでふりかえりと定例会議を別にやっていたのを1つにした。またふりかえりの会議のときに、ふりかえり作業そのものもやっていたのを、定例までに事前にメンバーがそれぞれやってきて、結果を定例のときに共有しようというやり方に改めた。ネガティブなふりかえりは発生時点で課題管理システムに登録してフィルター可能というのがアピールポイント。いまチームのメンバーが3人なのでこれでも会議は1時間でおさまる見積もり。メンバーが増えたらふりかえりと定例は別の時間にわけてやるかな?会議時間が長くなるとダレるので1つの会議は1時間以内で締めるというのは徹底したい。

  1. 現マイルストーンのふりかえり (目安時間: 25分)
    1. fun/done/learn を使ったポジティブなふりかえり で共有
    2. ネガティブなふりかえりは課題管理システムに Postmortem ラベルを付与して issue 登録したものを共有
  2. 次マイルストーンでやることの確認 (目安時間: 25分)
    1. 課題管理システムにある次マイルストーンでフィルターした issue を共有
  3. issue になっていないもので聞きたいことや分からないことを聞く (目安時間: 10分)
    1. メンバーが自由に意見を表明
  4. 雑談 (余り時間)
    1. メンバーが自由に雑談

事前準備を済ましてから、スクラムでいうところの、レトロスペクティブとプランニングを同時にやるといったもの。実践としてうまくいくかどうか、今回の開発で試してみる。