今日の運動は腹筋ローラー,腕立て,スクワット,縄跳び(両足跳)をした。統計を 運動の記録 にまとめる。

コレクションデータの再定義

ある mongodb のコレクションのデータ定義で _id に ldap の dn の値を使っていた。dn は一意な値なので主キーとして使ってもよさそうに思えたが、ここで運用上 dn の値が変更されるケースがいくつかあることがわかってきた。例えば、dn に姓名が含まれる場合、結婚して姓名が変わると dn の値が変わることはありえる。他にも dn に含まれる ou の値が現実の組織名を表している場合、組織変更によって ou の値が変わったときに dn の値も連動して変わってしまう。一意な値というだけでデータベースの主キーにするのはよくないということがわかってきた。主キーは一意な値、且つ immutable が望ましい。

たとえば mongodb では _id を主キーとして使う。mongodb は主キーの値を変更することはできなくて実装上は delete & insert になる。

• How to update the _id of one MongoDB Document?

delete & insert の運用上の問題は更新時にトランザクションを使わないといけないため、パフォーマンスが悪い。さらに id 連携という業務に特化して言うと、たとえば、姓名の変更は名前が変わったというだけでその人が退職したわけではない。これをシステム上 delete & insert で扱うと、古いユーザーデータを削除して、新規にユーザーデータを作成するといった振る舞いになってしまう。そうすると、古いユーザーがもっていた権限やデータなどを移行しないといけないわけだが、それらをすべて自動化できるか？という難しい課題も積み重なってしまう。本質的に rename を delete & insert で扱うことそのものが誤っているのだ。

メンバーと相談して _id に uuid を発行して dn はフィールドに unique 制約を課して保持するよう設計を変更することに決めた。コレクションのデータ定義の主キー変更なのであちこち修正してテストコードも修正しないといけない。一意な値、且つ immutable な値のみを主キーとして使うのが今回の学びとなった。私自身、初期の設計に関わったときにこのことに気付かなかったから、これは私のレビューの失敗・見逃しでもある。

2時過ぎに寝て6時に起きた。いつも通りよく眠れた。

今日の運動は腕立て,スクワット,縄跳び(両足跳)をした。統計を 運動の記録 にまとめる。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。1時間を10分ほど超えてしまった。

• fun/give/learn を miro に移行した話し
• 城崎温泉の開発合宿ふりかえり
• 睡眠時無呼吸症候群の重症だった話し

はらさんが城崎温泉の開発合宿ふりかえり記事を書いてくれて嬉しい。参加者がもっとどんどん書いてほしいけれど、なかなか難しいみたい。私自身も書こうと思いながらまだ時間を取れていない。ざっくり次のようなことをふりかえりした。

• 城崎温泉／きのいえはよいところなので今後も継続したい
• 最大13人泊まれるが、うちらは屋内で作業するので8人程度がちょうどよい
  • みんなでご飯を食べに行ったり、外へ出掛けたりする上でもこのぐらいが限界
  • 2つの鍋で晩ご飯を食べるのも8人がちょうどよかった
    • 量も味もよくて成功だったと思われるが、🦀は値が張る、近くの市場まで出掛けたらもう少し安くなる？
• 毎年イベントを開催するとしてメンバーをどうするか
  • 既存枠6人、新規枠2人といった内訳で新しい人も入れていきたい
  • イベントの半年前には予約しないといけないため、既存枠は先着にしてしまう
• 一晩ですべての発表をやるのは時間がかかる
  • 発表の後にいろいろ質問する時間をもっと取りたい
  • 1日目と2日目にわけて4人ずつ二晩かけて発表するのを次回試してみる

あと、なにかの話題から発散したときに余談で次のクソ記事について議論した。

• 「MPがすぐに尽きてしまう人」は、企業では救えない。

私もいまマネージャーとして若いメンバーを指導したりしている。その中で人は個人差があって、画一的には扱えないことを実感している。こんな雑で横柄な論調で書けるわけがない。この記事で言及されている、仕事ができない人たちの背景はみんなバラバラだろうし、職種や業態、その人の得意・不得意によっても成果も変わってくるだろう。それを 「いわゆる MP」 のような、用語の定義もない意味不明なキーワードに括って論じてよいわけがない。著者の主張する重要なメッセージがボケているだから、周りの論理も成り立たない。久しぶりにひどい記事をみた。

ふりかえり

一昨日から jamboard 移行 ならびに隔週のふりかえりの運用変更についてまとめていた。せっかくだからそのノウハウなどをテックブログに書いておこうと雰囲気で思い立って、木曜日の夜から着手して、金曜日の午前中いっぱいかかって書き終えた。うちの会社の顧問さんやお手伝い先でも任意でレビューをお願いして、あちこち推敲して次の記事を公開した。ふりかえりの手法ややり方に言及している記事はあまりみかけないから、にっちに受けたりするかな？と思ったものの、まったく受けなかった。いつもは数日寝かしてから sns に投稿したりしている。それは後になって内容の不備に気付いたときに修正する時間を取れるようにという意図でそうしている。今回は3人もレビューしてくれて、文章のわかりにくいところを推敲できたので公開と同時に sns にも投稿してみた。しかし、ほぼスルーだったのであまり関心をもたれる内容ではなかったようだ。残念。

• チームのふりかえりの改善

家族信託の公正証書の作成

15時30分から弁護士さんと母と公証役場で公正証書の作成を行う。旧居留地のど真ん中に 神戸公証センター がある。きらびやかなビルの雰囲気とは変わって、ビル内の公証役場の事務所は普通の役場のオフィスって感じだった。私は公証役場に入るのは初めて。

弁護士さんに作っていただいた家族信託の契約書の内容を、公証人がすべて読み上げ、母と私が正本を見聞きして、最後のその内容を承諾して署名・捺印するという儀式を行う。だいたい1時間弱で手続きが終わった。とくに大変でもなかった。契約書の原本は公証役場で保管するため、公証人から公正証書の正本 (原本と同じ効力をもつ書類) という書類を、母と私がそれぞれに受け取った。この契約書に関する手続きをするときはこの正本を使う。公正証書の保管期間は20年と規定されている。保管期間を過ぎた後に公証役場で破棄されたら無効になってしまう。もし保管期間を過ぎても実は保管し続けている場合もあるし、(理由があって) 連絡すればさらに延長して保管しておいてもらうこともできるらしい。家族信託の契約書が20年後も必要になるのかどうかはわからない。ひとまず1ヶ月以内に正本を使って信託銀行に信託口座を開設しないといけない。来週、三井住友信託銀行の担当者とやり取りする。

公証人と雑談していて、遺言の公正証書は特別な扱いだと教えてもらっておもしろかった。もともと公証役場における遺言の保管期限は120歳だったものの、遺言の場合は亡くなってからも親族でごだごだする可能性があるため 公正証書遺言の保管期限は遺言者が170歳を迎える日まで になったという。例えば119歳で亡くなったと仮定して、相続で親族が揉めてしまうと1年で決着がつかないかもしれない。そのときに遺言の効力がなくなってしまうと遺言者の意図とは変わってしまうため、遺言者の死後も十分に長い期間として50年足して170歳までとなっているらしい。

バッテリー上がり

公正証書の作成し終えたので母を実家へ送り届ける。駐車場にある車に乗り込もうとしてエンジンが全く反応しない。ディーラーさんに電話して症状を伝えると、おそらくバッテリーが上がっているのだろうとのこと。保険会社のサポートセンター経由でロードサービスの方に来てもらった。17時前に保険会社のサポートセンターに連絡して、ロードサービスの担当者が来られたのが17時37分、それから30分ほどでバッテリーを復旧していただいた。エンジンがかからないことに私がパニクってから1時間半ぐらいでトラブルを解決できた。サポートの関係者さんに感謝。

バッテリー上がりの原因は数日前に私が車に荷物を積み込んだ際にルームランプを点けっぱなしにして消すのを忘れていたせいだった。ルームランプは車のロックをかけても消えないという。ロードサービスの担当者もバッテリーを上げてしまう原因として多い原因だという。こんな失敗をするんやなと自分自身でちょっとショックを受けた。今後はなるべく駐車場でルームランプを点けないようにしよう。夜間荷物の出し入れをやめたり、狭いスペースで出し入れせず、広くて明るいところに車を出すなりして、ルームランプを使わない運用にしようと思う。

fitbit の日々の目標の1万歩と2900カロリーの消費を達成するため、23時過ぎから散歩に言って0時前に達成して戻ってきて、CPAP のセットアップする前に疲れてそのまま寝てしまった。

今日の運動は水中ウォーキング,散歩をした。統計を 運動の記録 にまとめる。

google jamboard の移行先

サービス終了するので移行しないといけない。

• Google Jamboard の提供終了について

前にお手伝いしていた会社でよく使っていた Miro でいいんじゃないかと思って実際に評価して、機能性と使い勝手がとてもよかったので、やっぱり miro でいいんじゃないかと結論付けた。お手伝い先では miro を使っていない。偉い人に miro の管理者になってもらって、私のアカウントを招待してもらって、開発メンバーのチームを作ってもらうことにした。

• 付箋に絵文字を付けられる
• 付箋の作成者を表示、確認できる
• 付箋にコメントを付けられる

この3点だけでも jamboard ではできなかったことを実現できて好感触。今後の fun/give/learn のふりかえり は miro のボードを使う。

プール

前に行ったのが2月16日なので約1ヶ月経ってしまっていた。最近は週の半分ぐらいは夜に予定が入っている。打ち合わせや勉強会が入ったり、ちょっとお仕事を残業していたりすると全然余裕がない。プールに入った後に時計をみたら19時19分だった。1時間は運動しようと思って途中に5分休憩があるので20時25分で引き上げてきた。歩いたり平泳ぎしたりを1時間ずっとやってた。プールは空いていたのでほぼ1コースを貸し切りで自分のペースで歩いたり泳いだりできて快適だった。しかし、プールでは fitbit を外しているのでこの1時間のアクティビティは記録されない。これだけが残念。

隣のコースで外国人がバタフライで泳いでいて、すごいダイナミックで迫力があってカッコよかった。バタフライとかどうやって泳ぐのだろう？と軽く真似してみたけど泳げる気がしない。4泳法の中では一番難しいみたい。

バタフライは、クロールや平泳ぎ、背泳ぎと並んで、水泳の「4泳法」のひとつです。両手を回すように動かしたり、両足を揃えて上下にうねらせたり、非常にダイナミックなフォームで泳ぎます。4泳法の中ではクロールの次に速く泳げる一方で、泳ぎ方にコツが必要なため、最も泳げない人が多い泳法といわれています。

【水泳】バタフライを上手に泳ぐコツは？ 泳ぎ方の基本を押さえよう

プールを終えて晩ご飯を食べて歩数が9000歩を超えてたり、消費カロリーが2700カロリーぐらいだった。プールのアクティビティを含めると実際は軽く超えているけれど、データ上の目標を達成していないのが気に食わないと思えたので夜に散歩に出掛けて、データ上も日々の目標値を達成した。しんどかったけど、余分に運動したのでよしとしておく。

今回は寝台列車であまり寝付けなかったのか、fitbit に睡眠時間が記録されていなかった。おそらく2-3時間は寝たと思う。

今日の運動は合宿明けと移動疲れがあるのでお休みにした。統計を 運動の記録 にまとめる。

会議の準備

この3日間で私が主催の打ち合わせが5つある。主題だからそのすべてに私が資料を作らないといけない。もちろん先週から準備はしていたものの、完全ではなく、週末には城崎温泉でいっぱいいぱいになっていて余裕がない状態のまま出張になってしまった。打ち合わせの成否はそれまでにかけた準備時間に比例する。私の持論だ。最低限このぐらいの資料や段取りを組んでやらないといけないという私なりの基準がある。今回はぎりぎりまで資料を作ったり、打ち合わせ内容を練ったりして自身の基準すら満たすのにとてもしんどかった。

定例会議

いつものマイルストーン単位の定例会議。

特定の path 配下の web api にミドルウェアで認証や認可を適用している。こうしておけば認証しなければいけない web api の認証設定を実装し忘れるということが絶対に起きない。一方で未認証の web api もある。/auth/login や /status/ping といったものだ。これらは未認証で呼び出せるのでトップレベルの path をわけたい。そうすると、既存のトップレベルに設定してある /api/xxx という名前が論理的におかしい。web api は他にもあるのに認証を要するものだけ api というトップレベルの path を付けるのは奇妙に思えてくる。

/api/ping

チームで話し合ったり、私が思いついた最終結論としては1文字の path を設けることにした。ミドルウェアを適用したいという目的なので path さえあればよい。認証を要することを表す単語をつけると path が長くなってそれはそれで違和感を感じるし、開発者はタイプ量が増えることを嫌う。そこで一文字にしようと提案した。

/p/ping

permit, private, protected の意図で p という文字を使う。

3次開発の大きなふりかえり

事前に資料を作っておいた 開発の大きなふりかえり。2時間を使ってふりかえりを行う。前回の大きなふりかえり を経て、今回も若手のメンバーが大きく成長してくれて、その成長度合いが課題管理システムの統計からみてとれた。私がプロダクト開発に参加してチームを組んで1.5年経った。初期からのメンバー2人はどちらも十分に課題管理をうまくできるようになった。その結果、チームがよい開発文化を形成するようになった。

今回は新たに入りかけた若いメンバーはうまく立ち上がらなかったという反省があるだけで、その他のことについては開発全般うまくいっているし、プロダクトの品質も上がっているし、バックログの課題もたくさん自分たちで見つけられるようになってきた。私からみてもこのチームは十分によい開発チームに育ったと思う。マネージャーとしての私にとっての次の課題は途中からチームに参加するメンバーをいかに早く開発に馴染んでもらうか、よい開発文化を形成するようになってもらうかという取り組みになる。

スライドのあちこちに次の文言を埋め込んである。

ふりかえりなくして成長 (改善) なし

初期から課題管理に取り組んでいる2人のメンバーはどちらも成長が著しいし、ふりかえりの効果を実際の業務で体感してもらえていると思う。私自身も初めてのマネージャー経験、初めての課題管理をプロジェクトマネジメントとして導入するという経験、それらの PoC としての答えは出たと思う。間違いなく、課題管理は開発プロジェクトをよりよくするものだし、適切に課題管理すればプロダクトの品質も高くなっていく。今回のふりかえりは課題管理をビジネスにすることへの確信につながった。

1時に寝て6時に起きた。ここ数日2-3時に寝てしんどかったので数日ぶりに早く帰って寝た。最近は5時間眠れるようになってきた。健康大事。

今日の運動はレッグレイズ(椅子),腹筋ローラー,スクワットをした。統計を 運動の記録 にまとめる。

3次開発のふりかえり資料作り

昨日の続き 。一通り資料を作り終えてメンバーに共有した。QA テストのときに指導した ことに加え、3次開発をふりかえると新規メンバーがまた落ち込むかもしれない。しかし、経営者から開発に参加させてほしいと依頼されて、3ヶ月間なにもしなかったという事実を隠すことを私はしないし、あえてその背景を深堀りしないけれど、私のプロジェクトで次からこんなことを認めないという判断基準 (クライテリア) を設けて次の開発へ臨む。具体的にはフルタイムで時間を取れないのであれば開発に参加させないし、1ヶ月間を開発に取り組んで何も実績をあげられないときは開発から外す。今回は隔週で「来週からやります。」という言葉を3回ぐらい聞いて何もしなかったということが起きた。チームの規律を守るためにそんな人もいるとわかったのでその対策を講じる。

ぷち前夜祭

明日からの開発合宿に関東組が4人参加する。そのうち2人が前泊で神戸入りしたので軽く晩ご飯でもいくかと思っていたものの、いろいろ予定があわなくて、よしださんがうちのオフィスで別イベントのオンラインミーティングに参加するといった形になった。言うてもオンラインイベントなので mute にしながら会議室で軽く一緒に晩ご飯を食べた。阪急百貨店のデパ地下でお刺し身とお寿司とサラダ2種を買ってみた。18時前に行ったらお寿司とお刺し身は2割引だった。これで税込4,843円になる。このぐらいあれば2人で十分だった。オフィスの会議室も8人ぐらい入れる。数人規模の飲食イベントならすぐできそう。あとオフィスの冷蔵庫のスペースを奪ったままになっている缶ビールも3本消費できた。私はもう体重落とすことに専念しているので1人ではお酒を飲まないし、外へ出掛けてもなるべく飲み食いしないようにしている。体重を落とすゲームが楽しくなってきて、摂取カロリーよりも消費カロリーの方を大きくしていれば必ず痩せる。完全攻略に取り組んでいるような趣き。

お風呂で fitbit を外してそのまま付けるのを忘れて寝た。たぶん3時前に寝て6時半ぐらいに起きた。

今日の運動は腹筋ローラー,腕立て,スクワット,散歩をした。統計を 運動の記録 にまとめる。

大きなふりかえりの資料作り

今日は丸一日ふりかえりの資料を作っていた。だいたい出来た。過去のスライドがあるのでその内容に沿って統計のグラフを作りながら、今回の開発の特徴や前開発との違いなどを比較していく。ノウハウが溜まっているので比較的簡単に作っていける。しかし、今回は2週間遅れ、新規メンバーの受け入れ失敗と、プロジェクトとして明確も失敗もあったのでその反省として、次の受け入れのときにこういう状況なら受け入れせず、開発からメンバーを外すといったクライテリアを作ることにした。今回の失敗は新規メンバーのために、ぎりぎりまで参加できるよう、待ったために結果的に中盤の機能開発の集中力を乱した。プロジェクトマネジメントの失敗としてしっかりふりかえりをしていく。

バランスボール

ジモティーで IGNIO のバランスボールを0円で譲り受けた。新品を買ってもそんなに高くないのかな？

椅子の代わりにもなるし、トレーニングのなにかにも使えるかもしれない。実家コワーキングスペースに置いておく用に譲ってもらった。県庁駅の近くの持ち主の自宅近くまで意味なく歩いて受け取りに行ってきた。おかげで7000歩、片道40分ほど歩いて今日の運動のノルマを達成した。もう1万歩歩くのは簡単になってきた。普段の生活に1時間ほど散歩の時間を設けると簡単に超える。バランスボールの空気がやや少なかったのでダイソーで空気入れを探してこようと思う。

• バランスボールに使える空気入れの種類や空気の入れ方を解説

創作天ぷらと創作そば

私の知る限り、三ノ宮で一二を争うおいしいお蕎麦屋さんに ISOGAMI FRY BAR がある。以前からお昼にはちょくちょくお蕎麦を食べに行ったりしていた。いまはダイエット中だから外食そのものをほぼ　していない。ふと夜はどんなメニューがあるのかの下見に入ってみた。夜はお酒も出しているので、チャージ300円、ワンドリンク必須だという。料理は刺し身や前菜、サラダ、つまみ系の料理、創作天ぷらがあり、お蕎麦も基本のざる蕎麦から創作系の変わったお蕎麦もある。ちょっとよい居酒屋へ行くぐらいの金額にはなる。ここのお蕎麦はおいしいから割高でも私は気にはならない。

創作そばの彩り野菜の豆乳バジルそば。

創作天ぷらのバジル&トマト。

0時に寝て2時に起きて6時に起きて7時に起きた。まぁまぁ普通に眠れた。

定例会議

いよいよこのマイルストーンを終えると、あと1つで機能開発の終わりとなる。いくつかの要因があって開発の進捗は遅れ気味になっている。メンバーがどうこうというわけではなく、私がうまく段取りを組めていなかったり、自身がマネジメントの業務をちゃんとまわせていないところが開発スケジュールの遅延につながっている。いまの状況は私が失敗したあのときのあれや、このときのこれから全体の進捗へ影響を与えているなとわかるぐらいにはマネジメントの動きが読めるようになってきた気がしている。読めるんだったら対応しろよというのはわかっているものの、モチベーションが足りなくて成り行きに任せていて成るようになっていないなといったところ。私のモチベーションが足らないところも含め、今フェーズの開発にはマネジメントの反省材料がいくつかある。

真面目にやった人を不当に咎める

昔から私はわりとワーカホリックだったので興が乗るとずっとお仕事をしていることが多かった。若い頃はやったらやった分だけ成果が出て評価されて、それはそれで楽しかったものの、30代になるとできて当たり前、成果のレベルがよほど飛び抜けていない限りは評価されることはなくなった。仮に10段階で例えると、若い頃は3しかできないと思っていた人が8ぐらいやると評価されやすいし、30代では8やって当たり前だと思われているから10やっても12やっても大差ないとみなされる。もはやお金のためにお仕事をしているのではないため、評価されなくても気にはならないし、いまは自分で契約の判断ができるので嫌なら契約を終了して別のお仕事を探せばよいだけという割り切りもある。

そんな中、昔からずっと思っていることが1つあって、真面目にやっている人たちを適切に評価しない上司が多い。要はなにも言わなくてもちゃんとやってくれているから放置するといった傾向がある。そして、さぼっている人たちや成果を出せていない人たちをかばう傾向がある。それはパフォーマンスが低い人たちを悪く言うと、さらにモチベーションを下げて、もっと悪くなるから励ますという意図があるのだと思う。しかし、その対応が度を過ぎると、真面目にちゃんとやった人たちのモチベーションを吹き飛ばしてしまう。その典型的な言葉が「みんながんばった」になる。実際は数人のコアメンバーが業務の大半をやっているのに上司は個々人の差異をなくしたがる。チームの一体感とか、空気を悪くしたくないとか、ハレーションを防ぐとか、いろいろあるのだろう。私は一緒に働いている人なら誰でも気付けるレベルの、みんながんばってないのに、そういった問題を指摘することもなく、なぁなぁで済ませるのをいくつもみてきて、これは日本の会社や組織で共通する傾向があると思う。なにを危惧しているのかわからないが、問題の本質に触れようとしないことが度々起こる。気付いたら対応しないといけないから気付いてないことにしたいと言い換えてもよいかもしれない。そういう状況をみると「またか」と思って私のモチベーションが落ちる。誰だって働きたくない。

私はよくやってくれている個人を、何度でも、よくやってくれていると明言して評する。がんばっていない人たちを咎めたりはしないが、がんばっていないのにがんばったとは絶対に言わない。状況によってはもっとがんばってほしいと言う。個人差があることを曖昧にしたりはしない。

0時に寝て4時と5時に起きて6時に起きた。最近は4時から1時間ごとに起きたりする。メールの送信処理のリファクタリングのコードレビューが長く続いていてなかなかややこしい。

mailhog の web api を使って検索する

メール送信の結合テストに mailhog というツールを使っている。smtp サーバーとしてメールを受け付けて web ui でそのメールの内容を確認できる機能をもっている。さらに web api で任意のメール取り出すこともできる。パスワードリセットの一時トークンをメールで送信するため、結合テストで一連のパスワードリセットを検証するにはメールから一時トークンを取り出さないといけない。そこで mailhog の出番だ。

検索 api を使うと任意のメールをフィルターできる。例えば、送り先のメールアドレスで検索するときは次のようにリクエストする。

$ curl -s "http://localhost:8025/api/v2/search?kind=to&query=myuser1@example.com" | jq .

うちらのやり方はメールのメッセージ ID に意図した uuid をセットしている。メールのメッセージから指定した uuid を含んでいるかを検索することで任意のメールをフィルターできる。

$ curl -s "http://localhost:8025/api/v2/search?kind=containing&query=28c9391f-25a5-4a8f-9035-7b8d5ac2d0f4" | jq .

それを結合テストのテストコードから呼び出すようにユーティリティを作ると次のようなコードになる。

import (
	"github.com/mailhog/data"
)

type mmSearchResult struct {
	Total int            `json:"total"`
	Count int            `json:"count"`
	Start int            `json:"start"`
	Items []data.Message `json:"items"`
}

func searchMail(
	host string, kind string, query string,
) (*mmSearchResult, error) {
	q := url.Values{}
	q.Set("kind", kind)
	q.Set("query", query)
	u := &url.URL{
		Scheme:   "http",
		Host:     host,
		Path:     "/api/v2/search",
		RawQuery: q.Encode(),
	}
	url := u.String()
	slog.Debug("mailhog search endpoint", "url", url)

	req, err := http.NewRequest("GET", url, nil)
	if err != nil {
		return nil, fmt.Errorf("http create new request error. err: %s", err)
	}
	res, err := http.DefaultClient.Do(req)
	if err != nil {
		return nil, fmt.Errorf("http request error. err: %s", err)
	}
	if res.StatusCode >= 400 {
		return nil, fmt.Errorf("returned response code is %d", res.StatusCode)
	}
	var r mmSearchResult
	if err := convertBody(res, &r); err != nil {
		return nil, fmt.Errorf("failed to convert: %s", err)
	}
	return &r, nil
}

歯医者

17時から歯科検診へ行ってきた。歯科検診をしてくれた今回のスタッフはおそらく初めてだったと思うが、手際がよくていつもよりもストレスが少なかった気がした。うちのチームのメンバーは朝方なので8時過ぎにはだいたいみんな始業し始める。なので、朝よりも夜にいない方がメンバーにとってよいだろうと考えて、朝一 (9時) に歯医者へ行くよりも最終 (17時) に行くようにしている。

pycamp ふりかえり

先週末の Python Boot Camp のふりかえり。ここまでがスタッフのお仕事なので一般的な kpt でイベントのふりかえりをした。仕事じゃないし、大きなトラブルもなかったし、参加者の評判 (アンケートの内容) もよかったので概ねよい内容だったと思う。テキストの改善点は直接 issue に追加してほしいと言われたので報告した。是非も含めてスタッフに判断してほしいので私が直すつもりはない。

• タプルとリストの違いの説明に辞書のキーになれることも追加する #219
• Windows 環境で普通に pip upgrade をすると環境が壊れる #220
• pip コマンドの説明で実際に存在するモジュールを書いてあると誤ってインストールしてしまう #221

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

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

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

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

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

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

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 の亜種としてどうだろう？といった提案のテックブログを書いてみたい。

深夜に1-2時間仮眠をとったものの、あまりうまく眠れなくて、3時に起きて準備して5時に家を出た。新幹線でも寝ていたが、夕方にはやはり眠くなった。

約4ヶ月間の開発のふりかえり

前回のふりかえりのふりかえりはここ 。2時間をとってこの約4ヶ月間の開発のふりかえりをした。

今回は2次開発というのもあって、メンバーも開発に成熟したし、1次開発でできなかったことのいろいろが改善できそうな見通しが立ってきたし、最高ではないものの最善ではあったんじゃないかと思う。私からみても十分によいものを提供できたと思う。8月の後半に私がテンパっていたのはなんだったのか？と思うぐらい、私が後半に詰め込んでやり過ぎたところもあったりはしたものの、それも終わってみればきれいにすべて回収できたのでよかったと思う。課題管理システムから情報を抜き出して1次開発のときと同じ指標の比較もしてみた。それによってメンバーのパフォーマンスが上がっていることも定量的に確認できた。これはまた会社のブログにもいずれ書きたい。これでメンバーも自信を付けて次の開発もがんばってくれるといいなと思う。今回はよい開発になったなと思う。

今回はいろいろ事情があって、私が東京へ出張してそのオフィスで1人でテレビ会議でふりかえりをするといったやり方になった。本当はこういう区切りになるふりかえりにもっと積極的に参加してほしい、オフラインで会議に参加してほしいと思う気持ちはある。それはそれで私の古い考えかもしれないし、メンバーからしてみたら、マネージャーがふりかえりにやかまして疎ましく思っているのかもしれない。若い人たちの考え方にあわせるという意味では、大きなふりかえりをテレビ会議で行うのも構わないのだが、オフィスで1人会議は私のテンションが上がらないことにも気付いた。先週から準備して資料を作って、わざわざ出張して会議をして、会議の場に誰もいないというのは、どう繕っても、私も出張せずにリモート会議した方が合理的だったと思えてしまう。その自分の中の違和感なのか反感に対して新しい答えを見い出さないとこの体制はうまくいかないと新たに思う一時でもあった。

大崎に泊まる

五反田のいつもホテルに泊まるのも飽きたので気分転換に大崎の ニューオータニイン東京 に泊まってみた。五反田から大崎は一駅の距離で川沿いを歩いていける。この川にかかる橋が夜はライトアップされていて散歩していて気持ちがよい。まだちょっと暑かったけれど、15分もあれば歩ける。宿泊プランを朝食付きプランにすると素泊まりに比べて500-1000円高くなる。それでもいつも泊まっているホテルの料金と比べて大差なかったので試しに朝食付きにしてみた。料理の種類の多い朝食ビッフェでとてもよかった。外食が多いと野菜が不足しがちになる。私はこういうところで基本的に野菜サラダを大盛りにしてたくさん食べるようにしている。その野菜の種類やコンビネーションのやり方が増えるほどアレンジする楽しみも増えて楽しい。これはいいなと思って今後もしばらく大崎に泊まってみようと思う。