2時に寝て7時に起きた。昨日は23時ぐらいまで送別会やっててまた寝るのが遅くなった。

隔週の雑談

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

• オフィス引っ越し計画 の共有
• SECI モデルのワークショップ の共有

昨日の送別会で、システムはいくらでも社員を監視して効率や最適化を要求できるけれど、そんな働き方は嫌だろうし、幸せじゃないだろうと私が話した。それに対して次のような反論がきた。

そんなことはなく誰か (何か) に管理されたいと考える人間の方が多数派だ

私はまったく同意しないのだけど、はらさんにも聞いてみた。リスクの多寡や有無ではないかと。リスクを取りたくない≒管理されたいと考える人が多いのではないかと答えてくれた。上司の言うことさえ聞いていれば自分は何も責任を負わなくてよいと考える人たちが一定数いることは私も理解できるが、そんな卑屈な人たちが多数派になるのかな？とやはり懐疑的に思えた。

プロジェクトの最終日

スプリントレビュー、送別会、今日のデイリースクラムと、今週は「最後なんで」の挨拶を3回ぐらいした。毎回話すことを用意しているわけでもなかったので即興で話すわけだけど、こういうところを私はもう少し準備してちゃんとした方がよいのかもしれないと反省もした。自己肯定感のセミナー でも書いたが、私は他人との比較をやめてから自分の尺度でしか生きていない。このプロジェクトで私が為したことはもちろん私の全力ではあるが、私がもてるスキルや知識のすべてを提供できたわけではない。それは組織の壁、業務の壁、伝えるスキルの稚拙さなど、様々な要因がある。一切の他責はなく、いまの成果物はすべて私の実力を反映しているものだけれども、その成果に自分自身では満足していない。10段階で言えば3ぐらいの成果だろう。自分では低い評価を下しているにも関わらず、他人からの賞賛を受け入れるのは難しい。辞めるときなので社交辞令もある。それも考慮して感謝の言葉をもらうときに、自分はそんな感謝を伝えられることをしていないというギャップに違和感を覚える。これは何を為しても満足できない、私が抱えている心の闇かもしれない。

それはともかくプロジェクトメンバーが オンライン寄せ書き にメッセージを書いて送ってくれた。オンラインの寄せ書きは無料だけど1年経つと削除されてしまう。メンバーが私のためにわざわざ時間をとって書いてくれた寄せ書きが消えてしまうというのはみんなに申し訳ない気持ちになって、プリントしてお届けを購入 (2,948円) することにした。情に訴えるビジネスモデルは抗いがたい。せっかくなので内容を秘匿して会社の宣伝にも使うかなぁ。

葬送のフリーレン で勇者ヒンメルは依頼人とあっさり別れるといったエピソードが出てくる。

旅をしてる以上また会うことだってあるだろう、また会った時恥ずかしいからね。

依頼人から報酬を受け取って貸し借りなし。それでお終い。この感覚は私にもあって、いまの時代、一緒に働いた同僚と離れても転職やなにかの縁でまた一緒に働くことは多々ある。あまり仰々しくしたくないと私も思う。送る側も良かれと思って気遣いしてくれている。それもわかるのでこういう価値観を伝えるのはなかなか難しい。

23時に寝て何度か起きながら7時に起きた。なんか体調が悪い。

ふりかえりとむきなおり

毎週火曜日はふりかえりの日。今週もスプリントゴールは未達に終わったわけだけど、未達が普通で稀に達成できるのが常態化しつつある。悪く言えば ゾンビスクラム 状態と言えるのかもしれない。サービスインのゴタゴタも解消したので PO からもツッコミがあってスプリントゴール達成できない問題が再燃した。私からみたらこんなところか。

• スプリント初期は前スプリントの残タスクをやるのが常態化している
• メンバーにやる気と実力がない
• コミュニケーションコストが高くてオーバーヘッドが大きい (スクラムイベント、確認や待ち時間など)
• フルタイムで働いていないメンバーがいる (ちょくちょくメンバーも休暇をとる)
• スプリントが1週間と短過ぎる

その議論をしている中でスクラムマスターが むきなおり をしようといった結論になった。私は用語を知らなかったので調べてみた。

この3点を満たしながら、事業をふりかえって、行きたい方向へとむきなおることが今回の合宿の狙いでした。ただふりかえるだけではなく、あるべき姿との差から、今後の方向性を決めることを、特に「むきなおり」と名前付けしています。ふりかえり、むきなおる。今回の合宿はギルドワークスの今後の方針と向き合うための機会としました。

事業をふりかえって、行きたい方向へむきなおる

ふりかえりの結果から方向性を変えることを呼ぶらしい。私はまったく理解できていないのだけど、普通のふりかえりをして改善するときは何と呼ぶのだろうか。ただの言葉遊びじゃない？という気もする。また後日、そのためのイベントをするそうなのでそのときに理解を深めてみる。

0時に寝て4時半に起きてだらだらして2度寝して8時に起きた。

jjug のセッションの紹介

jjug の公式アカウントがランダムにセッションのページを紹介している。私のセッションのリンクが今日ツィートされた。この日記を書いている時点で3つの「いいね」が付いている (1つは私なので除く) 。大して人気の出るような内容ではないし、なにかを期待しているわけでもないけど、誰からも関心を持たれなかったらそれはそれで発表者として寂しいなという気持ちもあって、ついつい見てしまった。ほんの2-3人でもいいから当日は発表を聴いてくれると嬉しい。そして、その流れで質問をしてくれればと考えている。もし当日、誰も聴いてくれなかったらスタッフの人が質問してくれるんやろか？

JJUG CCC 2022 Spring 6月19日開催
[Track C] 10:25- #jjug_ccc_c#jjug_ccc
Java で作るカスタム GitHub Actionshttps://t.co/cwpuR7dPmJ

— JJUG (@JJUG) June 15, 2022

ブログ記事のレビュー

朝一で昨日書いた記事を読み返しながら推敲した。やっぱり一晩寝ると、文章の粗が目立ってみえて細かい表現をあちこち直していた。その後に身近な人たちに記事のレビューをお願いして、概ね問題なさそうなので会社ブログの担当者にもレビュー依頼した。その返事はまだ返ってきていない。

設計ミーティング

先週から始めた 設計ミーティング の2回目。時間は2時間も抑えられていて話題がなければ解散するといったやり方。今日もなんだかんだで2時間丸々話していた。うちらの開発チームは開発者で共有すべき開発情報や設計の考え方などの情報共有が不足しているんだなと、多くの時間を割いても話題が尽きないことからも実感した。私は設計を練るのが好きなのでそれ自体も楽しい。スクラムイベントで会議の時間が多い上にこのミーティングは追加で実務の時間を奪うという懸念が大いにある。しかし、2-3ヶ月やったらアプリケーションの設計や品質に何かしらよい影響を与えそうな雰囲気はしている。代わりに他のスクラムイベントを削ることはできないだろうか。

0時に寝て4時半に起きた。6時から金朝ツメトギを聞きながら途中で寝てしまって7時過ぎに起きた。

コミュニケーションについての記事を書く

以前 コミュニケーションコストに考えたこと をベースに、3ヶ月フィードバック の一節としてお手伝い先の社内 wiki に書いた。コミュニケーション一般の話なので私の考えを伝えられるよう、社外秘の部分を削除してブログにまとめておくことにした。ちょっと書き始めたところ、また週末にでも時間があるときに少しずつ推敲したり、洗練させて自身の考えを整理していく。現状でも悪い内容ではないけれど、まだしっくり来ていないところもあって、そのもやもやも見直していきたい。

課題管理の特性

課題管理システムにチケットを作成すると fix しない限り、そのチケットは永遠に残り続ける。未着手の状態でずっと放置することもできるが、それは対応を先送りしているだけで完了するわけでもない。チケットの対応方法として wontfix という選択肢が非常に重要になる。問題があることはわかっていたとしても様々な理由で対応しないという判断はありえる。誰がどういう理由でその判断を下したかという背景や意図さえわかれば、仮に将来的にその問題が看過できない状態になったとしても、過去の判断から新たな対応方法を検討したり、その判断の是非をふりかえることができる。これはチケットを作らずに見てみぬふりをして将来同じことが起きるのとは全く異なる知見が積み重なるので非常に重要な意思決定であると私は考えている。

閑話休題。話しがズレた。ここで fix せずにずっと放置するメンバーもいたりする。様々な理由で課題管理に非協力的な姿勢をとるメンバーがいる。少なからずいる。そういう人を放置すると、真面目に課題管理をやっている人たちが腐ってしまうので、課題管理の専門家を自称する私としては看過できない状況と言える。最初のうちは非協力的なメンバーにお願いしてやってもらうわけだけど、やってくれない人はずっとやってくれない。それを言い続けるのも嫌になるので別の対応方法が求められる。私の経験則では若い人に非協力的なメンバーはほぼいない。いまの若い人は優秀なので上司や先輩のやり方をみて勝手にやる人もいるし、ちゃんと教えれば教えた通りにやってくれる。非協力的なメンバーは往々にしてそれなりの経験をもっている中堅以上の社会人に多い。実はお仕事をさぼっていてあまり作業していないとか、課題管理に馴染みがなければ、それまでの自分の仕事のやり方をアンラーニングできないという人もいるかもしれない。理由はともかく、お願いしてもやってくれない人のチケットが課題管理プロセスの中で浮いてみえてくる。他のメンバーが腐る前に対応しないといけない。私の経験則ではこれはすごく難しい問題であるし、非協力的なメンバーそれぞれの理由にあわせて対応する必要があるので工数もかかる。

課題管理をしたくないというメンバーの中には何らかの理由で自律的に働きたくないという人もいる。課題管理というプロセスにおいては、そういった人たちをあぶり出してしまうため、状況によってはとても難しい人間関係の問題へと発展してしまう。

1時に寝て6時半に起きた。昨日は夕方に一旦帰ってきて仮眠したらまた作業しようと思っていたけど、なんかバテてそのままだらだらしてた。

カレンダー共有と祝日

お手伝い先の社員さんと開発メンバーとのお休みがあわない問題が気になるようになってきた。というのは、お手伝い先は基本的に祝日は営業日として扱われている。おそらくは祝日に働いたら手当がつくのか、代休を別の日にとっているようにみえる。祝日に働かずに休む社員もいる。祝日に休むという表現もおかしいが。業務委託の開発メンバーは原則として祝日は休んで普通の日に働く。ここで社員さんが祝日に働いて普通の日に代休をとると、休みが異なるのでコミュニケーションコストが高くなる。お互いが働いている時間が減ることでその時間に対する価値が高くなってしまうという話し。国が違わない限り、あまりそういう状況は発生しないので、休日をあわせることの重要性を再認識した。

さらに働き始めた頃から気になっている カレンダー共有の問題 がある。休みが異なる可能性が高いのにメンバーのカレンダーはばらばらなので、お休みするという報告をもらっていても日が経つと忘れてしまっていて、slack でメンションをしてしまう場合がある。金曜日に月曜日はお休みすると聞いていたけど、月曜日になったら忘れてたみたいな。お休みしている社員さんに普通にメンションして、普通にやり取りしていて、あとでお休みだったと気付いて申し訳なく思った。カレンダーを確認してお休みだとわかっていれば slack でメンションはしなかった。

4時に寝て7時半に起きた。休日にだらだら過ごしてたので生活のリズムが狂ってしまった。

開発者同士の雑談

リリース作業前の検証のときにそれぞれの開発者が対応した課題の検証をやりながらハドルで雑談するのが定例になってきた。オンラインミーティングをするときに打ち合わせのリソースを作成する必要がないので、ハドルぐらい手軽にオンラインで繋げられれば雑談もしやすいということが少し理解できてきた。slack アプリは常に開いているので打ち合わせのために特定のアプリ(ブラウザで特定のページ)を開くという作業がないだけで心理的な障壁が下がる気がする。チャットツールに音声通話の機能がつくのは大きなメリットがあるなと、zoom や google meet と比較して思うようになってきた。定例会議やイベントなどは zoom や google meet でかまわない。だけど、「いまからリリースやるからみんな集まって」みたいなノリはハドルの方が集めやすいし、参加しやすい。フルリモートワークはオフィスと同じような雑談がやりにくいという課題の、技術的な課題はハドルが少しずつ解決していきそうな未来があるのかもしれない。

いままでのほほんと雑談していただけだったが、こういう機会にどんな会話をしているか、その会話からどういった情報共有が行われているか、会話することで人間関係や心理的安全性に影響を与えるかなど、雑談の意義や効果に注意を向けながらやってみるとなにかしら発見があるような気もしてきた。

0時に寝て3時に起きた。4時までドラクエタクトしたりもしてたけど、夕方に PoC のデモ打ち合わせがあるのになにも準備できてなくて不安で起きて5時からお仕事してた。久しぶりに早起きしたせいか、打ち合わせ終えたら眠いからすぐに帰って、夜はオンライン飲み会しつつくつろいでいた。

情報共有とコミュニケーションコスト

課題管理システムのことを考えていてふと思いついたことを書き出す。私からみると、多くの人たちは「聞かなくてもわかる」という価値を過小評価しがちである。というのは、その価値を定量化するのは難しいので評価されにくい。そうすると、評価されないことはやらないといった合理的な働き方をすればそうなるのは理解できる。しかし、私はその価値を理解しているので軽く考察してみる。

1. 聞けない
2. 聞けばわかる
3. 聞いてもわからない
4. 聞かないとわからない
5. 聞かなくてもわかる

情報共有の過程でパッと思いつくことを段階ごとに書いてみた。1に近い方が容易で5に近い方が難しいという難易度を表しているとも言えるし、組織の情報共有のレベルを表しているとも言える。少し言葉を補うと次のように解釈してもよいだろう。

1. (メンターが気難しくて/メンターに無能だと思われたくなくて) 聞けない
2. (メンターに余裕があって) 聞けばわかる
3. (メンターのスキル不足で/担当者が退職してて) 聞いてもわからない
4. (背景が文書化されていなくて) 聞かないとわからない
5. (課題管理システムを検索すれば) 聞かなくてもわかる

昔は1のような状況を発生させる人もちょくちょく職場にいた気がするけど、いまは淘汰されてあまりみかけない。多くの組織は3か4ぐらいのレベルだろう。5まで達している組織は少ない。課題管理システムについて議論していると、たまに「知っている人に聞けばいいじゃない？」という意見があがる。この質問をしている時点で目指している働き方のレベルや生産性が大きく異なっていることがわかる。というのは、他人に聞くというのはコミュニケーションコストが非常に高い。これは他人に聞くなと言っているわけではない。他人に聞かないといけないことを減らすことで生産性を上げるという話しをしているだけだ。他者へ同じ情報を伝えるのに1時間の打ち合わせが済むのか、3時間の打ち合わせを要するのかという比較をしている。当然、打ち合わせ時間を減らしても伝えられる情報量が同じであれば打ち合わせ時間は少ない方が望ましい。そういう話しをしている。

5のレベルに達していれば、例えば、いまのシステムの仕様はなぜこのようになっているのか？変更するとしたら影響範囲はどのぐらいか？どういったモジュールに注意して改修すればいいか。もちろん前任者やリーダーに聞けばわかるだろう。聞くために打ち合わせの予定を調整するかもしれない。するとリーダーは忙しくて時間を調整できるのは来週になるという。もし課題管理システムにそういった情報が残っていれば、来週まで待つ必要がなくなる。理想的にはリーダーとの打ち合わせも必要なくなる。リーダーは他に重要な業務に時間を割ける。これが「聞かなくてもわかる」という価値である。

昔はなんらかの理由で1の状態にあった組織において、職場の風通しがよくなると、コミュニケーションコストを軽視しがちになる。職場の風通しがよいことは重要だが、打ち合わせや会議ばかりするようになると、キーパーソンの時間を湯水のように使う。キーパーソンはすぐに会議だらけになって物理的に実務ができなくなって、結果的に生産性や品質が下がる。ここで重要なのは権限委譲だが、この話しは長くなるのでここで筆をおく。