22時に寝て2時前に吐き気で起きて少しだらだらして寝て7時に起きた。

ストレッチ

今日の開脚幅は開始前154cmで、ストレッチ後158cmだった。あまり数値は振るわなかったものの、この1ヶ月ぐらいではもっとも復調しつつある。まだ腰の張りがやや残っていて全快とまではいかないものの先週よりはよくなりつつある気はする。先週から左右への開脚以外に前後の開脚のときの股関節のストレッチを重視するよう、トレーナーさんからも指示はあったものの、今週は全然そんな余裕がなくてあまり取り組めなかった。それを余暇でうまくできなかった分の、数値の悪化かなとも受け取れた。

2-2. 傾聴・可視化・リフレーミング

エンジニアリング組織論への招待 のメンタリングの技術の章を読み直し。前回 からだいぶ間があいた。

メンターはメンティに対して「問題を解決してあげよう」ではなく「モヤモヤしていない問題に変換してあげよう」と考えることが重要。問題を次のように考え、

• 感情的に固執していて解けないので「傾聴」をする
• 客観視できずに解けないので「可視化」をする
• そもそも解けない問題なので前提を変える「リフレーミング」をする

というのが、メンタリングで意識すべき流れになる。

共感と同感の違い

• 共感という言葉の意味は「相手がそのような気持ちになった理由を理解する」こと
• 同感は「自分が相手と同じ気持ちになる」こと

傾聴において示すべきことは、「共感」であって、「同感」ではありません。

認知フレームとリフレーミング

• 人はありのままに物事を見られない
  • 人は認知する枠組みの範囲でしか処理できない
  • この枠組みのことを「認知のフレーム」と呼ぶ
    • この外側にあることは「心理的な盲点」と呼ばれる
• 対話によって認知フレームを変えることを「リフレーミング」と呼ぶ
  • 「解けない問題」を「解ける問題」へと変えていく

確認された前提を「一旦、この前提がなかったらどうなりますか？」というように外して考えるようにすることで、リフレーミングを促すことができます。 また、この中で「一番重要だと思うものは何ですか？」というように前提の優先順位を問うこともリフレーミングを促します。気になって仕方なかったことが、実はあまり重要ではないかもしれないと気がつく契機になります。

「情報の非対称性」を解消するには、

• 自分の情報を相手に伝える
• 相手の情報を自分が聞く

という行動をとればよいのですが、この当たり前のことができなくなってしまうケースがある

これは、メンター役になる人に対しても重要な警句です。メンターは、メンティの問題を「自分の課題」として捉えてはいけません。メンターにとっての課題は「メンティを自立的な問題解決」に導くことであって、「メンティの課題を解決すること」ではないのです。

この節を読み終えて、課題管理とは、メンターを必要とせず、自分で自分をメンタリングするツールとも言い換えられるかもしれないと思えた。課題管理を習熟すると自分で自分の間違いに気付けるというメリットを周りに伝えたりしていたことがメンタリングで大事なことのいくつかの共通することが書いてあった。

車を運転して実家へ

明日は父の35日なので夕方から購入した車で初めて実家に帰った。神戸の高速道路の路面が少し濡れていたり北淡で小雪が降ってきたりして、さっそくタイヤ周りを汚れてしまった。まぁ仕方ないか。door-to-door で1時間15分ぐらいで実家に帰れる。高速バスで帰るとこんな段取りになる。

• マンションからバス停へ移動する (10分)
• バス停でバスが到着するのを待つ (待ち時間10分)
• 高速バスで移動する (1時間20分)
• バス停まで親に車で迎えに来てもらって実家へ移動する (15分)

待ち時間の調整が入ると2時間ほどはかかっていた。これが自分の都合で移動できるので調整時間がない分のストレスが溜まらない。帰ろうと思って1時間強で移動できる気楽さがある。

0時に寝て夜中に吐き気がして2回ほど起きて3時と5時に起きて8時に起きた。なかなか苦しい寝方をした。

ヤフートラベルと一休.comのシステム統合

アーカイブ公開されたらみようと思いつつ忘れてたので見返した。

雑なめも。また機をみて見返すこともあるかも。

• バックエンドは完全に一休側に寄せるという大きな意志決定を2016年に行った
  • この意志決定はフロントエンド統合にも大きな影響を与えた
  • ふじもんさんの意志決定がよかった？
• 今日の話しはマルチブランドデザインシステム統合がメイン
  • 開発者が50-60人程度で半年ぐらいで launch できた
  • nuxt/vuejs で開発している
  • スタイルは tailwindcss を使っている
  • 実は launch した後にこのシステムが必要だとわかった
    • 開発者とデザイナー間の細かい意思疎通が困難
    • 外部からデザインシステムに詳しい人にも来てもらっていろんな議論をした
    • ガイドラインを言語化するところから始め、最終的にソースコードの共有ができるようになった
  • 終わってからデザインシステムそのものは重要ではないと気付いた
    • この過程で開発者とデザイナー間のどのように共通化するか、あるいはしないかと議論を繰り返し行ったことが重要だったと当事者がインタビューで語っていた
    • デザインシステムの開発を通じてデザインの共通認識をもてたことがよかった
• 波及効果
  • 同じソースコードから少し異なる体験の開発のノウハウができた
  • ふるさと納税に特化した宿泊予約サイトを作った
• 統合は終わりではない、lauch したところが始まり
  • 統合後にいろいろな施策をすることで課題がみえてくることがある
• 全国旅行支援は1つの開発で2つの体験をつくることができた
• Q. デザイナーと開発者はわりと仲が悪いのでは？価値観や考え方が異なるのですり合わせるのは難しいのでは？
  • 過去の一休でも起きていた
  • 一休のチームはデザイナーと PM と開発者で構成されている
    • このチームが一緒に働いていてチームでなるべく意志決定している
    • 普段から一緒に働いていると仲が悪いということはなかった
    • とはいえ、仕事のプロセスが異なるので課題はあった
      • 地道に丁寧にすり合わせを行った
      • 外部から講師を読んで中立的な立場でワークショップを何度も行った
  • デザイナーと開発者を別の組織にしているとコミュニケーションの壁ができてしまうかもしれない

go の学び直し

テストの学び直し に引き続き、Gopher塾 #2 - Goらしいコードの書き方 - DAY 1 に参加した。

テストの次のプログラミングの話しだったので内容そのものは難しくはなかったけど、改めて重要な項目を選抜しているのだと考えると学びはあったと思う。参考になったことをいくつか覚えている範囲でまとめる。名前の付け方について感覚的に理解していたし、実際に私はそうしているけど、コードレビューしていて自然になっていないコードを指摘する機会も多いので一定の習熟を要するのかもしれない。いま毎週勉強会をやっていて私が講師として話している。ネタがなくなってきたり大変になったきたら準備の少ないコードリーディング会もやってみたいと思った。

• google Go Style
• derrors.Wrap
• 名前に文脈を与えるという概念
  • 相対的な名前をつける
• 準備の少ないコードリーディング会
  • お題（読むパッケージ）を決める
  • 選んだお題に期待することを当日話す
  • 時間を決めてみんなでそれぞれ読む（20分とか）
  • 読みながらSlackのスレッドにメモをしていく
  • 残りの時間で気になったところを議論する
  • 自分が気づけなかった点を知ることができる

22時に寝て1時に起きて吐き気がして苦しんでた。その後、寝て1度起きて7時半に起きた。寒くなってきたせいか、疲労のせいか、なんとなく体調が悪い。今日も掃除したり荷解きの片付けやったりしていた。

退去するオフィスの掃除

ワールドカップが盛り上がっているので関連するニュースを読んでいるうちにサポーターだけじゃなく、選手もロッカールームをきれいに掃除して退出しているニュースをみかけた。

• FIFA公式が日本代表のマナーを絶賛　ピカピカ更衣室に「ドウモ アリガトウ」

日本では小学校の頃から自分たちの活動の場を自分たちで掃除するという習慣が当たり前のように教育されている。その延長で自分たちが使った場所は掃除して帰るといった価値観が一般的に定着しているように思う。掃除するお仕事を奪っているという批判も、掃除はボランティアがやっている、ボランティアと言っても有償ではある、有償といっても歩合制でお金をもらっているわけではないでしょうとか。さまざまな意見がある。批判を認めないわけではないが、私も掃除をすることは正義の1つだと最近思うようになってきた。12月3日に引っ越しするのに12月4日 (予備日) まで借りていた理由はとくになかったのだけど、オフィスを掃除するためだったんだなと後付けの理由ができた。朝から掃除機をオフィスへ運んで掃除してきた。

This isn’t just a clean dressing room, it’s a clear demonstration of values.

It’s a statement about respect, gratitude and attention to detail.

The small things are the biggest indicator of the big things - your values.

https://www.linkedin.com/posts/stevenbartlett-123_this-is-how-the-japanese-mens-team-left-activity-7001499750009044992-qpeU/

たまたまねとらぼの記事を読んだ後に linkedin の投稿もみかけた。日本人は掃除に respect なんか感じたことはないかもしれないけど、外からみるとそういった振る舞いの1つにみえるんだという気付きにはなった。やっぱり掃除は正義やね。

1時に寝て何度か起きて7時に起きた。起きてからも昨日の夜にやってた勉強会の資料作りをずっとやってた。

1on1 で設計談義

あるマージリクエストで私が nil ガードを実装した方がよいとコメントした。その意図がわからないという話になって nil ガードを実装する背景について、実際のコードをみながらメンバーに説明した。プログラミングの文脈では全然難しくないことではあるけど、あまり経験がない人にとってはその意図や考え方を学ぶのは難しいかもしれない。こういった、詳しい人に聞けばすぐ解決するけど、ググって調べるのは難しいこともある。1on1 のような身近に話す機会があると、定例会議でみんなの時間に話すほどの重要度ではない話題を聞くことができる。そこで聞いた意見をベースに私が issue 化したり、ある話題をチームで話し合う打ち合わせの機会を設けたりしている。

メンバーの送別会

私があるチームのマネージャーをして1ヶ月が経つ。メンバーの1人が退職することになった。実はマネージャーになって1週間後に転職が決まったという話しだった。いきなり開発体制がバタバタしたけれども、私からみたらやることは変わらないのでその影響は最小限に留められたのではないかと思う。いまのところ、当初の開発の計画にも変更をきたしていない。出張でオフィスに来ている機会なので私もそのメンバーの送別会に参加した。他の社員さんも20人ぐらい参加されていた。飲み会の雰囲気をみていて若い人が自由に発言して楽しんでいるのを傍から眺めてた。飲み会の雰囲気ってその組織の性格が出ておもしろいと思う。イヤな人がいないのは組織において重要になる。後日、経営者の方々とそういう会話をしていたら小さい会社はみんな仲良くできるといった話しをされていた。たしかにそれぞれのメンバーの顔とやっていることを見渡せる規模だから親近感を抱きやすいと言えるかもしれない。ここ数年どこへ手伝いに行ってもよい雰囲気をもつ会社は多い。変な言い方だけど、よい世の中になったと思えて嬉しい。

0時に寝て4時に起きた。5時前には家を出た。初日だけは早起きして新幹線乗らないといけないので緊張する。新神戸6時10分発が始発になる。始発に乗った方が混雑もしていない。9時過ぎにはお手伝い先のオフィスについて業務を始められた。移動に約3時間。早起きは三文の徳みたいな話。

フルリモートワーク

朝一でオフィスに着いたものの、チームのメンバーの1人はお休み、2人は在宅勤務、上長は出張だったので私が一人だけオフィスワークしてた。普段は私がフルリモートワークなのでうちのチームはリモートワークの働き方が容易になるように業務を設計している。私がオフィスにいようが、普通にリモートワークするのはある意味で自然な働き方とも言える。周りのチームの人に「あっ、いたんですね」とか声を掛けられながら1人で黙々とお仕事してた。

全国旅行支援 + ただいま東京プラス

今回の出張は全国旅行支援で宿泊費が40%オフになっていて、且つ ただいま東京プラス という取り組みで3000円/日のクーポン券が付いていた。 region PAY というアプリにクーポンを登録して QR コード決済で対応店舗で買いものできる。すべてのお店が対応しているわけではないが、普通に周りの飲食店やコンビニなどでも使えた。ちょっとよい晩ご飯の定食を食べて、帰りにコンビニで飲みものを買って帰るぐらいの贅沢ができる。至れり尽くせり。

競輪選手というキャリア

ホテルでたまたまテレビをつけたらやっていておもしろかった。競輪オタクが競輪選手になったらめっちゃ強くて無双している、どこかのラノベみたいな話し。競輪という競技を私はあまりよく知らなかった。なぜこんなことができるかというと、競輪というスポーツは純粋な体力や身体能力で勝敗が決まらないらしい。試合展開の駆け引きがあって最後に勝敗が決まる。競輪オタクはすべての選手のプレースタイルを記憶していて、個々の選手の戦術を予測して対策できるから勝てるのだという。

• 競技経験ゼロ！28歳の「脱サラ競輪選手」。“オタク知識”をフル活用してまさかの快進撃

5時過ぎに寝て10時に起きた。出張で生活のリズムが狂ったまま。

2-1. メンタリングで相手の思考をリファクタリング

エンジニアリング組織論への招待 のメンタリングの技術の章を読み直すことにした。3年前ぐらいに読んだのであまり覚えてない。私は管理職ではなかったし、若い人に口であれこれ言うのもハラスメントになる懸念から私の働き方をみて役に立つところを盗んでもらえればよいと考えていた。これまでメンタリングには関心がなかった。しかし、いまマネージャーとしての役割で臨む以上は最低限の基礎は抑えた上で取り組む必要があると考え方を改めた。今日は「2-1. メンタリングで相手の思考をリファクタリング」を読んだ。節を簡潔に要約してみる。

メンタリングとは、対話を通じて、思考の幅を広げ、その人の歪んだ認知を補正し、次の行動を促し、成長させる手法である。スキルなので誰でも習得できる。自ら問題を発見し解決することができる 自立型人材 を作るために、信頼関係の上に正のフィードバックループから 自己効力感 (self-efficiency) を与えられるように働きかける。次の条件を満たさないとメンターの言葉でメンティの行動を自ら変えるようにはならない。

• 謙虚: お互いに弱さをみせられる
• 経緯: お互いに敬意をもっている
• 信頼: お互いにメンティ (自身) の成長期待をもっている

自らいままでわからなかったことを理解した状況を 自己説得 と呼ぶ。他人が質問で促し、体験を伴い、行動の変化が発生しやすい。メンティが自己説得できる状態になるようメンターは対話で気付きを与えないといけない。悩むと考えるは違う。悩んでいるときは思考がぐるぐると巡り、もやもやした状態。非常に苦しい上に生産的でもない。一方で考えているときはメモ帳やホワイトボードなどに課題を書き出し、分解したり、抽象化したり、具体化したり、、、何かしら行動をとっている状態。次にとるべき行動がはっきりしていれば悩むことはない。メンティが行動できているかどうかを観察し、悩んでいるようならその背景を聞き出して、気付きを与えて考えている状態へ変えていく必要がある。

ストレッチ

今日の開脚幅は開始前154cmで、ストレッチ後159cmだった。東京出張であちこちガタがきていて全身に張りがあったように思う。生活や睡眠が不規則になったことによる疲労もそのままストレッチの窮屈さにつながっているように感じた。毎週ストレッチの機会があって本当に助かっている。ストレッチをした後は体が軽くなって疲労を軽減できているように思う。これまでたまにマッサージへ行って対応していたのが、毎週チェックして手入れできていることの価値がこういうときによくわかるようになってきた。

1時に寝て7時に起きた。ホテルのビッフェ形式の朝ご飯は2回目のなのでうまくプレートに盛り付けて段取りよく配膳できた。昨日より改善できた。

課題の意思決定と割り当て

プロジェクトの初期なのでとにかく段取りを早め早めに決めてタスクを洗い出し、メンバーが目標に向かって作業しやすい状況をマネージャーとして作り出さないといけない。昨日からプロジェクトのリポジトリ構成を変更しようというイシューを作ってメンバーと議論していた。当初は私がちゃちゃっと作業して移行しようと考えていたが、私の移行イメージを書き出していたらメンバーからいくつか背景や要望が出てきて、メンバー集めて打ち合わせして合意をとって決断することにした。私が入ってからプロジェクトでの初の意思決定かもしれない。

既存のソースを読んだらリポジトリ統合は少し工数がかかるとわかって、私がやるよりもメンバーの方がいいだろうと意思決定だけ私が判断して、実作業はメンバーに割り当てた。初めてのマネージャーっぽいお仕事をできたとちょっと自己満足。その議論の過程で monorepo vs polyrepo という比較記事を読んでみた。monorepo から polyrepo に切り出すのは容易だが、polyrepo から monorepo に統合するのは大変ということが書いてあって、まさにプロジェクトの状況と合致してメンバー間で認識合わせした。いま (過剰な) polyrepo で管理されているのを monorepo に統合しようという決断をした。これをやるのにコミット履歴を維持するのはコストがかかるのでソースファイルをコピーして新規ソースとして移行してよいという判断も下した。こういう意思決定は即断即決でやりたい。

monorepo の対義語として polyrepo という言葉があるのか。勘と経験でリポジトリは複数に分割するので私がやってきたのは polyrepo ではあるのだけど、ちゃんと考えたことはなかったのでアーキテクチャとして議論する余地があるんやろな。 https://t.co/7LQY4cMteF

— Tetsuya Morimoto (@t2y) November 1, 2022

1on1

マネージャーとして1on1を行う。プロジェクト初期は毎週やって、その後はメンバーの要望を聞きながら隔週でもよいと考えている。1on1 の目的ややり方は様々だが、私が提供できるのは次の3つに含まれることかなと思う。

• モチベーションアップ
• 業務・組織課題の改善
• 能力開発／キャリア支援

初日から長時間の会議と懇親会などでチームのメンバーと話す機会が多かったので 1on1 もみんな気さくに話してくれてよかった。私はなるべく話さずに聞くことに専念しないといけない。私は圧倒的に自分の思ったことをがんがん話してしまう方なので他人の話を聞く姿勢を身につけるよい機会になると思う。今回は準備不足で雑談がメインではあったものの、1on1 の本なども読みながら勉強していこうと思う。

0時に寝て6時過ぎに起きた。朝からシャワー浴びてホテルのビッフェ形式の朝ご飯食べてた。初めてのオペレーションだと段取りわからなくて朝ご飯さえうまく配膳できなかった。経験のないことは全然できない。

課題の洗い出し

お手伝い先のワークフローや段取りを学ぶ。毎週火曜日がプロジェクトの定例会議。火曜日の終わりに週報を書く。メールで週報を提出するという、いまどきの会社からみると古い会社の慣習にみえる。郷に入れば郷に従えということで私も同様に行う。課題管理で日々の活動をひたすら書いているので週報はいつでもすぐ書けるので私は全く苦にならない。

プロジェクトのリポジトリ構成の変更や課題の洗い出しなどをやっていた。イテレーションは週1でマイルストーンを4週間(月1)で設定して、その区切りでふりかえりなども実施していきたいと思う。コミュニケーションコストが高いことから、私は開発方法論としてスクラムを採用するつもりはない。あくまで自分がやってきた経験による課題管理 + イテレーション開発で製品開発のワークフローを構築したい。お手伝い先ではチームで課題を共有して開発に取り組むといったことはこれまでやってきていないものの、課題管理システムを使って開発者間でやり取りするのは普通にやっていたそうなのでイシューのコメントへの返信がめちゃくちゃ速い。イシュー上で議論していて私がこうしましょうとコメントを書いたら最も速いメンバーは5秒後にリアクションがつくぐらいの速さ。他のメンバーも数十分以内には返信がつくので課題管理システムを使うところのなにかを教える必要はない。課題管理が身に着くのに半年から1年間かかるというのは、他人のアクティビティを監視するという日々の運用 (行動) の変化に半年ぐらいかかると私は想定しているが、このチームはもっと早く課題管理の考え方に適応しそうな気がする。イシューの他人のコメントに5秒でリアクションできる開発者はそうそういない。

私がまだまだプロジェクトの理解が浅いので1-2週間はそのキャッチアップをして、メンバーが遊ばないように課題をどんどん作って優先度付けしてメンバーが担当できるようにしていきたい。

1時半に寝て3時半に起きて4時半まで仮眠して準備して5時41分に家を出た。出張も3年振りで寝過ごすのが怖くてうまく眠れなかった。

東京出張

3週間以上前に新幹線を予約すると EX早特21ワイド という割引サービスがあって 東京・品川から新神戸だと15,380円が12,630円と2,750円と18%もの割引でお得。6時55分の新幹線の予約をしていた。スマート ex の予約のやり方を忘れてたり、地下鉄のホームを間違えたりしていて朝ちょっと早く出掛けてちょうどよかった。段取りが読めないことは30分以上早く行動するのが安心できてよい。

自己紹介大会

お手伝い先のオフィスに到着し、一息ついてから自己紹介大会になった。1つの会議室に20人ぐらい、リモートからも10人ぐらい参加されていて全社員だったのかな？自己紹介大会をしていただいた。チーム内でのみ行うと考えていたのでたくさん参加者がいて緊張した。30人程度というのはそういうことができるぎりぎりの人数かもしれない。暖かい雰囲気の会社だなと思った。お土産のお菓子 が16個入りで数が足りないことにこのとき気付いた。チームと関係者のみだったら16個もあれば十分と安易な考えだったと気付いた。失敗。

プロジェクトの情報共有

午後から数時間をとってチームメンバーとプロジェクトの情報共有を行った。いまみえてて伺っている内容だけなら私の経験から全体の技術体系ややりたいことも見通すことができて、全部自分1人で開発しても提示された期間内にはできるように思えた。しかし、今回はマネージャーというポジションで若い開発者に実務を担当してもらうことになる。自分が手を動かすのではなく他人にやってもらう新しいキャリアへの挑戦になる。私がビジネスとして取り組みたい課題管理の探求にも力を入れたい。今回のお仕事は千載一遇のチャンスなので集中して取り組んでいきたい。

懇親会

初日は早々に業務を終えて関係者とチームで懇親会を3時間ぐらい行った。昔働いていた会社の同僚・先輩方がいて、やや平均年齢の高いメンバーだったので昔話や同世代の価値観のお話ができて楽しかった。40代以上の人が集まるとすぐ健康の話になって若い人がいると申し訳ない。運動しないと50歳ぐらいになると動けなくなるぞと念を押されたので注意しようと思った。初日は自己紹介、会議、懇親会とたくさんチームのメンバーと話すことができたので初日から随分打ち解けて話せるようになった。感謝。