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) に近いという。

• How to Succeed as a Proxy Product Owner

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

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

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

persistent search あれこれ

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

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

• Persistent Search: A Simple LDAP Change Notification Mechanism

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. メンバーが自由に雑談

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

22時に寝て何度か起きて7時に起きた。たまには早く寝てみた。

チャンネルを用いた ldap 検索の api

うちらの要件に足りない機能が go-ldap にある。私が機能拡張についての issue を作ったときにある開発者が先にこの機能が必要だとコメントしてくれた。もともと draft pr で実装されたコードがあったのでそれをベースに検証したら普通に動いた。あとは go のエンジニアリングとして開発者が使いやすいように、私の経験からのアレンジを加えて pr とした。テストも実装した。なにか問題があればレビューで指摘さえしてくれれば私がすぐ修正してマージできるはずと考えている。はてさて、どうなることやら。

• Add search with channels with context #440

能―650年続いた仕掛けとは―

能―650年続いた仕掛けとは― を読んでいる続き。世阿弥の紹介をしている第五章に感化された。

第四章 能にはこんな仕掛けが隠されていた

能はシテ (主役) の役柄や内容で5種類にわけられる。

1. 初番目物 神: 神様が登場して颯爽 (さっそう) と舞う
2. 二番目物 男: 修羅物とも呼ばれ、武将が修羅道に落ちた苦しみを描く
3. 三番目物 女: 鬘物 (かずらもの) とも呼ばれ、優雅な美しいものが多い
4. 四番目物 狂: 雑能とも呼ばれ、他の4つに分類されないもの
5. 五番目物 鬼: 切能 (きりのう) とも呼ばれ、鬼や妖怪、精霊、霊獣などがシテになる

さらにこの5つの分類に入らない翁という演目もある。翁を最初に置き、この順番に上演しながら、能と能の間に狂言を演じ、最後に祝言の短い能を演じるのがかつての正式な上演だったらしい。これだけ演じると朝から晩までかかってしまうので忙しい現代ではなかなかみれなくなってしまっているという。

ひと昔前は結婚式で仲人さんや親戚が謡を謡っていたという。たしかに古風な結婚式ではそうだったような、、、と私もうっすらとそういう記憶があるような気もする。

能の身体的な特徴の1つに摺り足がある。摺り足には重い二本の刀を腰に差して腰痛にならないという効能があるらしい。ほんとかな？

世阿弥が能の構造は序破急にせよと書いている。序はワキの登場、破はシテが登場して話をして去る、急は再びシテが姿を変えて登場するといった構造になる。水戸黄門や暴れん坊将軍のような時代劇の最後の展開が急に相当する。水戸黄門で例えると次になる。

• 序: 現状把握と善人の窮状
• 破: 善人が騙される／襲われる
• 急: 印籠を出す

そして、この後に書いてあることが個人的におもしろかった。水戸黄門は番組開始時点では印籠を出すようなシーンはなくて、当初は助さん角さんが敵をたたき斬っていただけだったという。そもそも印籠を出したぐらいで本物の水戸黄門かどうか分かるわけもなく悪人がひれ伏すはずがないw あるときから印籠を出すという急を作って、序破急が安定したことで人気が出て長寿番組となったと書いてある。ほんとかな？

第五章 世阿弥はこんなにすごかった

能の大成に大きな影響を及ぼした世阿弥についていろいろ書いてある。

夢幻能 という能のジャンルを完成させた。念が残る、思いが残っているといった残念を昇華させる物語の構造になっている。世阿弥は特に敗者の無念をみせる舞台構造を作ることに成功したという。もともと日本人は死者を尊ぶ習慣があったことも要因としてあげている。

世阿弥は世襲で継いでいくという家元制度を作った。これは後世に必ず継ぐシステムを作ったと言える。現代まで能が継続されている背景の1つに家元制度はたしかにあげられると私も思う。しかし、現代では基本的人権 (職業選択の自由) に反することから家元制度の批判もあるようだ。著者はこの仕組みを称賛しているが、私は現代の感覚からすると個人の自由を制限して成り立っている古い制度のように感じてあまり著者の意見に同意できなかった。

陰陽の和するところの境を成就とは知るべし

昼や晴れた日には観客の気分が盛り上がり過ぎているので控え目に演じなさい。曇りや雨の日には逆に観客の気持ちが萎えているので派手目に演じなさいといったことを言っている。要は客の状態を見て演じ方を変えなさいと言っている。これは言うは易し、行うは難しだという。能ではこれを楽器の構造から音の力で解決していると説明がある。

時に用ゆるをもて花と知るべし

ともすれば絶対的な善し悪しがあるように思い込み、そのようなものを追求しがちであるが、実際はそのようなものはない。あるのは時との関係性だけだという。易経の時中も引用している。いまがどのような「時」であるかを知り、それがもっとも適合した時期であるか、行動できるか、それこそが「花」であるという。

花と面白きと珍しきと、これ三つは同じ心なり

現代の言葉とはちょっと意味が異なる。

• 面白き: 目の前がパッと明るくなること
• 珍しき (愛ず): 愛らしいこと、まったく普通のことに感嘆を抱かせる工夫など
• 花: 秘すれば花、秘密にすることで偉大な働きをすること

能では、演者はあまり観客に働きかけない。よくわからないことで、逆に観る人が能動的になり、見えないものが見え、聞こえない音が聞こえるようになる。これも秘することによって咲く花だという。師匠が弟子に教えないというのも、簡単なことでも秘することで、弟子が散々苦しみ抜いた上でその助言の価値に気付くこともあるという。

「老後の初心」という考え方。どの歳になっても初心はあるが、歳をとって体力が劣っていくからこそやることも変えていく。第一章にも出てきた能における「初心」という言葉の概念は本当におもしろい。能では体が動かなくなっていくのだから「しないというやり方も方法としてありえる」と考える。演じないことで演じる、歳を取ったときの表現方法がある。高齢な能楽師でしか演じられない境地があるから能楽師は歳を取ることを楽しみにする。この考え方はいまの時代にとてもあうように私は思えた。

2時に寝て何度か起きて7時に起きた。能の本を読みながら寝落ちした。

落ち穂拾いの終了

4月末にリリースしてその後 GW に入って、5月は「落ち穂拾い」として 開発全体のふりかえり をやったり、次の開発の要件を整理 したりしていた。ドッグフードテスト の導入もまだ作業中ではあるが、社内のシステム管理者にも協力していただいて進めている。私の作業でも十分な余裕をもって次の準備につなげることができたので開発の区切りで1ヶ月ぐらい準備期間があることはよいように思える。経営者はもっと働かせたがるかもしれないが。

これまでの開発は定例会議も 1on1 も毎週行ってきたが、次の開発ではこれらの会議を隔週にしてみる。口頭による同期コミュニケーションのコストを減らし、より開発そのものに時間を割いて注力できるようにする。もしかしたら、これによって私も開発に参加する時間を作りやすくなるかもしれない。もう1つ 必要なときに必要な人とすぐに話す (会議の日まで待たない) という狙いがある。毎週会議があると、すぐ聞けばよいことを次の会議まで待ってしまうということがある。私もある。私ですら待つときがあるのだからおそらくメンバーにもそうしてしまうことがあると推測する。会議の頻度を下げることでこの待ち時間を削減して即時問い合わせ、即時解決するといったコミュニケーションに移行していきたいという狙いがある。開発者の自律性を高めるためにはこういった取り組みも必要だと思える。もっと言えば、毎週会議しないと情報共有できないというのは開発者を子ども扱いして堕落させるのではないかと考える。実際に意図したようにうまくいくかどうかはやってみてから考える。

うちの開発メンバーは半年前より見違えて課題管理に習熟したので次の開発がどうなるかが本当に楽しみだ。

0時に寝て何度か起きて6時半に起きた。余裕のある生活を送っていると朝もすんなり起きれる。たぶん普段働き過ぎなんやな。今日は朝もお昼もご飯食べてないが、とくに気にならなくて余裕があるとお腹も空かないことに気付いた。

ジモティーで椅子の受け取り

以前コワーキングのオンラインイベントで ジモティーが熱い と聞いてから ジモティー にアカウント登録して、たまに眺めたりしていた。実家のオフィスで使う椅子をジモティーで探そうと思って検索していた。いくつか候補をみつけて最も近所で受け渡しが簡単そうだったのがバランスチェアだった。実家で使おうと思って購入を決めた。ジモティーで売買をやり取りするのは初めてだったので勝手がわからないものの、出品者とメッセージをやり取りして翌日には受け取りの待ち合わせをすることで話しが付いた。振り込みとか発送とかそういう概念がなくて、直接会って現物交換するときに現金で支払うという、なんというか、昔ながらの個人間取り引きになる。一周まわって新しい。

出品者が10年以上前に購入してブランドロゴがいまとは違うため、類似品と正規品との判断がつかないということで明言はしていないものの、おそらく VARIER MULTI ではないかと思われる。椅子じゃなくても10年以上使うとなにかしら劣化や変色などがみられると思う。もちろんこの椅子も新品と比較すればいくらかはそうだろうけど、10年以上使ってきたという歴史に対して色褪せない質感を醸しているのでおそらくはもともとの素材や構造が優れているのだと思う。

出品者の人もよい人で待ち合わせして受け取り／支払いの体験もよかった。一周まわって新しいと書いたのは、人と人のコミュニケーションの原点のようなものがある。ヤフオクやメルカリだとシステムとのやり取りだけで完結するので相対的にそういったものを思い出した。戻ってきて早速使ってみる。見た目の質感の良さの通り、座った感じの、フィットするのにまったくブレない剛性感もしっくりきて気に入った。当初は実家で使おうと思っていたものの、すごく気に入ったので現オフィスでセカンドチェアとして使うことに方針変更した。

姿勢もよくなりそうだし、背もたれがないので作業に集中したいときのルーチンにもよさそうに思う。

しくじり先生

前回の青春編 をみておもしろかったので続編の 竹原慎二先生「５０歳過ぎてもケンカを売られ続けてバリしんどい先生」完結編 をみた。ガチンコ時代の裏話などもあって懐かしくておもしろかった。またガチンコ時代の教え子でプロボクサーからは引退したものの、いまも仲良くしているメンバーもいて、そういうのもいろんな人の縁で社会がまわっているなにかを感じられてよい演出だったと思う。竹原氏は見た目怖いし、実際に強いし、無礼に対する態度も威圧的なものの、意外？と精神的には普通の人とあまり変わらない雰囲気だった。格闘技が強いかどうかよりも、精神を鍛えることの難しさや大事さが伺えた。見た目の強さよりも内面の強さというか、若い頃はあまりそういうことがわからない気がする。多くの人がある程度社会で揉まれていくうちになんとなく理解していくのではないかと思う。

0時に寝て何度か起きて6時過ぎに起きた。休日は朝だらだらしてオフィスへ行くのが9-10時ぐらいになることが多いのだけど、今日は普通に8時過ぎに行けた。

法人決算

朝から法人決算の続き。昨日たまたま消費税の計算をして、祝日やのに e-tax 稼働しているんやと思いながら申告した。これまで休日や祝日は稼働していなかった気がするので時代の変化にあわせてシステムはなるべく24時間稼働するように少しずつ変わってきている。今日も法人決算の続きをやっていて、課税所得を確認して、カテゴリ的には3つに分類される法人3税と呼ばれる税金を算出した。具体的には6つの税金を算出しないといけない。

• 法人税 (=> 国税 => e-tax)
  • 法人税
  • 地方法人税
• 法人住民税 (=> 地方税 => eltax)
  • 法人県民税
  • 法人市民税
• 法人事業税 (=> 地方税 => eltax)
  • 法人事業税
  • 特別法人事業税

過去の法人決算の経験からまず法人住民税と法人事業税を確定させてから法人決算の申告をすべきだというプラクティスがある。というのは、法人住民税と法人事業税の数値になんらかの誤りがあると法人決算で提出する別表の数字も修正しないといけないため、先に地方税を確定させた方が手戻りを少なくできる可能性が高い。電子申請するとそれぞれの書類の数値のバリデーションが機能するので手計算や手入力で誤りがあったときに発見できる可能性がある。これは電子申請をするメリットの1つでもある。

地方税を管轄するのが eltax で国税を管轄するのが e-tax で別システムになる。いまとなっては、事前にチェックしておけばよかったなと思うところだが、あとの祭り。e-tax は5月3-4日が稼働していて5-7日が休止している。eltax は5月3-5日が休止していて6-7日が稼働しているというスケジュールになっていた。双方のシステムが稼働していれば今日中に終えられたものが、なんともちぐはぐなスケジュールで申告を完了させるのは来週以降に持ち越すことになる。また来年やるときはこのそれぞれのシステムの稼働スケジュールを事前にチェックして法人決算の作業日程を決めるように法人決算の issue に書き込んでおいた。来年はもっとうまくやる。

• e-tax e-Taxの利用可能時間
• eltax 令和5年度の休日運用日

今日のところは法人3税の税金を算出し終えて、それらと関係ない別表の大半を作成した。基本的には決算の試算表から数値を転記したり、特例措置の申請のための書類を作ったりでなにも難しくない。

iijmio と iphone で作るモバイル wifi ルーター

今年に入ってから 実家のオフィス化 の準備を着々と進めている。晩年は足が不自由だった祖父が生活できるよう、倉庫の一部を改築して車椅子でも生活できるような部屋になっていて、ある種の離れのようなスペースになっている。祖父が他界してからは誰も使っていない。トイレもお風呂もキッチンもついていて広さで言えば14畳ぐらいある。これまで使いにくかった理由は2つあってエアコンとインターネットがなかった。この前、母にお願いしてエアコンを購入してもらい、つい先日、設置が完了したらしい。

インターネットの回線をひくことも検討していたが、どうやら5000円/月ぐらいかかることがわかってきた。母はインターネットを必要としていないので月1回ぐらいしか使わないのに5000円も支払うのはもったいないなと一旦ストップしていた。スマートフォンのテザリングでお仕事できないわけではないから当初はそれでもいいかと考えていた。私の個人のスマホとインターネット回線は iijmio を使っていて iij さん好きなので同じように pocket wifi 的なものはないのかな？と調べたら正にそういう記事をみつけた。

• 格安！IIJmioでポケットWiFiを作る！料金・手順・注意点まとめ

よくよく考えたらデータ専用の sim を購入したらあとはモバイル wifi ルーターだけあればよいことに気付いて、それって iphone でできるやんということに気付いて、過去に使っていた古い iphone 11 を再利用できることに気付いた。さらにいまは esim という物理 sim を必要としないソフトウェアベースの sim もあるようで月額の料金も esim の方が安い。 音声通話なしのデータ専用プランで税込で次の金額になる。さらに使わなかったらデータ量は翌月以降に繰越できる。プランによって繰越できる期間が異なる。例えば2GiBなら翌月末まで繰越できる。繰越という概念はたまにしか使わない私の用途にぴったりでひとまず2GiBプランを選択してお試し運用してみることにした。

• 1GiB: 165円/月
• 2GiB: 440円/月
• 5GiB: 660円/月
• 10GiB: 1,100円/月
• 20GiB: 1,650円/月

esim というソフトウェアベースのものだと、申し込みして5分後に設定できましたというメールが届き、すぐにアクティベートして iphone 11 に esim の設定をしたら10分後にはインターネットに接続できるようになった。その後 apn の設定を行ってテザリングもできるようになって、30分後には iphone 11 をモバイル wifi ルーターとして macbook からインターネットにアクセスできるかの疎通確認を終えた。

つまりソフトウェアベースで業務を行うことのワークフローの効率が半端なく高い。これが物理 sim なら数人の人手と待ち時間がかかることは容易に想像できる。物理的にしかできなかったことをソフトウェアベースにしてワークフローを洗練化させることの強力さを実感した。常々、私が課題管理の文脈でコミュニケーションコストを減らせれば生産性が上がると開発者に啓蒙していることと同じで自分がやろうとしていることの概念を追体験するような経験となった。ワークフローの効率を極端に落とすのは人間である。

22時頃から寝て何度か起きて7時に起きた。久しぶりに夢をみた気がする。オフィスに着いた頃にはもう覚えていないけど。

リリース前日

プロダクトの開発、テスト、パッケージングとすべて完了していてドキュメントや社外に提供するためのインフラの仕組みの作業を行っている。これはリリースまでに出来ていなくてもプロダクトが動かないわけではないのでリリース後もしばらくは継続する。今日は運用ツールのちょっとしたリファクタリングをしたり、コードレビューをしたり、windows インストーラーの調査をしたりと、なんやらかんやらで忙しかった。

示唆を与えなければならない

ここ1ヶ月ほど私がクリティカルパスの作業を担ってきたのでメンバーの作業を落ち着いてみる余裕がなかった。たまたまというか、私がクリティカルパスから脱したことでメンバーのレビューやアドバイスを行うときの余裕も戻ってきた。CSK の新人研修で習うことに社是と経営理念とサービス精神という言葉がある。

サービス精神

• お得意様にあくまでも満足していただく技術を提供しなければならない
• 技術は高度で専門的でなければならない
• 仕事は正確に、かつ迅速・効率的に行なわなければならない
• 常に、お得意様の利益を考え、示唆を与えなければならない

新人研修ではこれらを暗唱して暗記させられる。20年以上経ったいまでも覚えている。もともと私の考え方にあっていたのか、それとも新人の頃に刷り込まれたのか、その両方なのか。いま見返すと私の課題管理の考え方とこのサービス精神には共通しているところもある。その上で最後の 「示唆を与えなければならない」 という言葉を、今日メンバーとやり取りしているときにふと思い出した。

アドバイスをしていると、なぜこの懸念を考えずに作業を継続してしまったのだろうか？と思う機会がちょくちょくある。そのときに質問してその背景を尋ねたり、効率や保守のための考え方を教えたりする。ふと私が指摘しなかったらそういった効率や品質の低い結果のまま進んだのだろうと推測される。当たり前の話しだが、意識的にしろ無意識にしろ、個人では気付けなかったフィードバックや示唆を与えてくれる人がいなかったら個人の能力では限界がある。気付きがないところに学びも改善もないから成長もしない。いまお手伝いしている会社はこれまで個人でやってきた働き方を、チームで協調して働くように変えていきたいという話しから始まった。私自身、どちらかと言えば個人主義の働き方をしてきた方でチームでの働き方をちゃんと教えられるか、当初はあまり自信がなかった。半年やってきて、チームで働く上で必要なことはメンバーのアウトプットに対して質問するだけでよかったんやと理解できるようになってきた。個人の視点しかない働き方と他者の視点から常にツッコミが入る働き方はまったく異なる。うちのメンバーをみていて、まだまだ道半ばではあるが、それまでの状況と私が啓蒙している課題管理は、おそらく根本的に働き方を変えてしまっていることにようやく私の理解が追いついてきた。

0時に寝て7時半に起きた。そろそろ出張バテしてきた。

プロジェクトの進捗報告

出張したときの月例報告の5回目。前回の進捗報告はこちら 。私のマネジメントの不手際で1ヶ月延期 (元の計画通り) して、未だに開発は完了していないものの、今月末にリリースできる見通しでプロジェクトを進めている。おそらくあと1-2回は私が休出するのだろう。これからメンバーにはできる限りの QA テストを3週間に渡って行ってもらう。

チームが fix した3月の issue 数は47、そのうちの34を、enhance ラベルが付いたものは12でそのうちの9を私が担当した。クリティカルパスになりそうなものは、一旦はメンバーにアサインするものの、進捗をみて遅れていれば私が issue を引き取って対応している。先月から引き続き、やばそうな芽が出てきたら私が本気出して対応する。見た目上のスケジュールには影響を与えないようにしている。先月の反省で早めに引き取ることにしたのでずるずる後ろへ延びることはない。このやり方をすると、私がボトルネックになりかねないが、私の工数は調整次第でメンバーよりも大きくできるのでいまのところ問題ない。リリースまで1ヶ月を切った中で取り得る手段は限られてくる。

2月から ハドルと雑談 の試験運用をしていた。ほぼ毎日午前中は私が slack のハドルに在籍 (オフィスアワーに近い取り組み) するようにして、メンバーから雑談する機会は増えるかどうかを試していた。約2ヶ月やって結果は次の通りとなった。

• 対象日数: 34日
• 雑談人数: 10人
• 雑談時間: 5.75時間

3日に1日ぐらい軽く雑談するといった結果になった。おそらく私がハドルにいなかったら話す機会はなかったのでこの価値をどう見積もるかは人によって分かれると思う。うちのチームはリモートワークが中心なので雑談する機会があるほど望ましい。それほど強く提案するわけではないが、slack のハドル活用をもっと展開してもよいのではないかと経営者に推奨した。

聞いた話では着任前にこのプロダクト開発は2年近く迷走していたらしい。それによって要件は整理されていたと言える。私がこの半年でリリース (予定) できる状態にしたのを評価してもらえているようにはみえる。余談だが、自分のスキルを社会の役に立てられるのがいまは嬉しい。前職では、誰でもできる簡単なお仕事しかできず、開発もあまりつまらなかった。いまは自分がよいと思うものを一定の裁量で判断し、さらにマネージャー経験も積めて、今回のお仕事は私の中でも達成感は高い方でもある。

あとは今後の開発の話し、販売戦略の話しなどもしていた。4月末で初期開発の区切りもつく。今後は毎月1週間も出張しなくてよいのではないかという話しもして、5月は会議を2-3日に集中してやったらいいんじゃないかということになった。出張はそろそろ疲れてきたのと、私がオフィスにいてもメンバーは半分以上リモートワークなのでオフィスに来る意義があまりない。うちのチームはリモートワークで開発に支障が出ない仕組みを構築できているとは思う。