鯨飲馬食

いろいろつまみ食いで勉強したことのメモ書き

焦らず時間を掛けて、サポートしたい

数学ガールの秘密ノート 図形の証明」を読んだ。

今回の対象は証明問題で、「僕」が「こうすれば絶対に証明が見つかるという方法はないんだ」と言う通り、何にでも通用する一般的な解き方は存在しない。

図形の証明問題に立ち向かうノナとユーリをサポートをする「僕」の振る舞いを見て、自分の仕事の現場で、解き方がわからない課題に立ち向かうメンバーをどうサポートしていくかを想像しながら読んでいった。

ユーリとノナが横道にそれてスイーツの話をしているときの「僕」の心の声

一度にたくさん流し込むのが良いとは限らない。 … 相手に伝えるために、時間を掛ける。 相手が受け止め、消化するのを待つために、時間を掛ける。

これとても大事だな。焦らない。時間を掛けて伝える。相手がそれを咀嚼して自分のものにするのを焦らず見守ること。

伝えたいことがいろいろあると、つい焦って流し込んでしまうことがある。焦っていることは多分相手にも伝わっていて、それが誤解を招く。短い時間で飲み込むことが大事で、理解の質は疎かにしていいという誤ったメッセージとして伝わってしまう。

しっかり受け止めて理解して欲しいのなら、相手のペースに配慮して、ひとつひとつ理解してもらえるよう適した時間を掛けていくのがいい。

ふと「カメの遠足」の歌詞が頭に浮かんだ

のんびり行こう のんびり行こう ゆっくり行けば まだまだ続く

新しいことを取り込み自分のものにしていくのは楽しい。その時間をじっくり味わってもらえるよう、焦らず時間を掛けてサポートしていけるといいな。

「自分ごとと考えないで」と言って驚かせていた

長尾彰さんのSchooの授業で、メンバーのメンタルモデルの変化「依存・他責→自立・自律→共存・共栄」を聞いて、ふと思い出したことがあったので書く。

schoo.jp

チーム内のタスクで周りの人をうまく巻き込むには?という課題について話していた時のこと。

私が「タスクを自分ごととして捉えていないですか?」と聞いたところ、聞き間違えと思ったようで「え?他人事として捉えてないですか?じゃなくて、ですか?」と驚きの表情で聞き返されてしまった。

チームとして重要なタスクを、他人事としてではなく自分ごととしてそれぞれのメンバーが捉えてくれているのは理解していて、その一方で自分の方に強く引き寄せすぎちゃっているように見えていた。それは悪いことじゃないけど、チームとして何とかしたい重要なことだからこそ、自分ごとで止まらずに、チームの周りに頼ってでも解決していけたらもっと良い。「自分事」じゃなくて「チーム事」と捉えて周りを巻き込んでもらえたら嬉しい。というお話をした。

他人事→自分事→チーム事というのはまさに授業で出てきたメンタルモデルの変化だった。一人で抱え込んでいると大変なことも、チームでやれば無理なく楽しく取り組める。授業の最初の方で、変化の先の3つ目の状態を「無理をしないで価値を出せている状態」と言っていたけど、気負わず自然体で、チームとして価値を出せている状態を目指すというのはとても良いなと思った。

(2022/04/23 追記) 沢渡あまねさんの「チームの生産性をあげる。」に、他責思考も忘れず、組織の成長に繋げようという話があった。以前読んでいたそれも「自分ごとと考えないで」の発言のベースになっていたのかもしれない。

46歳になりました

20220202と2が多い日ですね。誕生日を迎えて46歳になりました。46は大好きなライダーのValentino Rossiのゼッケン番号と同じ数字ですね。

大好きな本「情熱プログラマー」を本棚から取り出して最初から最後まで読み直しました。

楽しんでいきます。

「問いかけの作法」を読んだ

「問いかけ」を通したチームづくりの実践のヒントが詰まった本でした。

この本の特徴は、「問い」という結果単独ではなく「問いかけ」という行動に着目して、「見立てる」→「組み立てる」→「投げかける」のステップを順に追い、良いポイントを見つけそれに対して良い質問を投げかけるまでの過程に重きを置いて解説していることだ。

見立てのフェーズでは、相手のこだわり、とらわれを特定する。3つの着眼点

  1. 何かを評価する発言
  2. 未定義の頻出ワード
  3. 姿勢と相槌

に注意してチームを観察し、

  • 場の目的
  • 見たい光景
  • 現在の様子

から成る三角形モデルを使って見立ての精度を上げ、必要な変化の仮説を立て、それを問いかけの目的と定める。組み立てのフェーズでは、その仮説に沿ってこだわりを深ぼる問い、とらわれを揺さぶる問いを組み立てる。そうして組み立てた問いを投げかけ、相手の反応を観察して再び見立て→組み立て→投げかけ、と繰り返しサイクルを回していく。

組み立ての章では具体的な手順が豊富に紹介されていたが、その中で目に止まったのは、「何を主語にして答えてもらいたいか」を考えるということ。この観点を知れたのは良い収穫だった。これまでの私は答えの主語を意識せずに問いを発して、暗黙で期待していたのと違う主語で答えが返ってきて戸惑いそこから先に進めないことがあった。これからは、期待する主語を明示した質問でチームメンバーの思考対象を揃えたり、返ってきた答えに対して主語を変えて再度問いかけることで相手の視座を上げ下げするといった工夫を実践していきたい。

実践してナンボの本だと思うので、学んだことをチームのミーティングや1on1で活用していけるといいな。

2021年のふりかえり

健康面

何はともあれ概ね健康に一年を過ごすことができました。今年は結石が降りてくることもなかったし、風邪で寝込んだのも一回だけだったと思います。

ただ、特に在宅の時に座りっぱなしになりがちで身体を動かさないのが肩凝りと腰痛を悪くしてる気がして、昼休みに散歩したり自転車乗ったりして抗っています。5月にTREKクロスバイクを入手してこないだ半年点検に行ってきたのですが、お店の人に「半年経ってるのに綺麗ですね」と言われて、「もっと乗りなさいよ」って意味だと思うので、来年はもっと出かけたいと思います。もう少し寒さが和らいでから…。

お仕事

1月から所属が梅田に出来た新しいオフィスに移ったのですがその頃はフルリモートだったので行かれず、初出社は3月だったようです。

最近は週2出社、週3在宅勤務です。チーム毎に曜日を決めて出社していて、出社曜日が決まっているので生活のリズムは落ち着いてきた一方で、直接顔を見る人が固定化してしまっているのがちょっと気になっています。特にチーム外の人のところに、用事無いけどふらっと行って雑談する機会が減っていて、いい意味のノイズが不足してる感がある。

Software Design連載

勤務先のMonotaROのメンバーでSoftware Designの2021年8月号から「Pythonモダン化計画」という連載をしています。歴史のあるシステムにモダンな仕組みを取り込むためにやってきた色々な工夫を、これまでは表に出せていなかったことも含めて書かせてもらっています。私は、2021年9月号「「テストがない」からの脱却」のCI導入の部分と2022年1月号「運用監視の解像度アップとサービス横断的なログ基盤の整備」のDatadog APM導入の部分を書きました。雑誌の記事を書くのは初めてでしたが社内のレビュアーやラムダノート鹿野さんのサポートを受けつつ、自分たちがやってきた取り組みを記事にして紹介することができました。

gihyo.jp

gihyo.jp

その他のアウトプット

はてなブログ: 8本(本記事含めて)、2020年は15本だったので少なめでした。

Zenn: 19本、検索可能なところに書いておかないと学んだことすぐ忘れてしまうので、学んだことのメモを書くようにしています。以前はQiitaに書いていましたが、今年からZennに移りました。

zenn.dev

GitHub連携を使っていますが、ローカルで書き溜めておいて、npx zenn preview でブラウザでプレビューできるのを便利に使っています。使い始めた頃は画像は別途アップロードする必要がありましたが、途中からgit管理できるようになり(参考: GitHubリポジトリ連携で画像をアップロードする方法)、より便利に書き溜められるようになりました。

そのうちの一つの記事 git reflogを日時で参照する にまとめた内容、git reflog で日時による参照ができることを知ったのは非常に面白かったです。関連して libgit2 の revparse を git コマンドの動作に近づけたり (Better revparse compatibility for at time notation by yoichi · Pull Request #6095 · libgit2/libgit2 · GitHub)、git log の date オプションの bash/zsh での補完候補を拡充したり (completion: add human and auto: date format by yoichi · Pull Request #1083 · gitgitgadget/git · GitHub) したので、今年もちょこっとOSS貢献できました。後者では GitGitGadget を用いたプルリクエストによるGitへのコントリビュートも体験しました。ピタゴラ装置的で興味深かったです。

zenn.dev

Qiitaの過去に書いた記事にちょっと追記: 2本

  • GitのオブジェクトID衝突時の挙動
  • 親を3つ以上持つコミット

前者は更新のきっかけとなったコメントでgitに衝突検出の仕組みが入っていることを知ることができ、SHA-1衝突検出ライブラリを使ってみたを書くきっかけになりました。

qiita.com

qiita.com

まとめ

今年もいろいろ楽しむことができました。来年も楽しみます。

「良い質問」をする技術、を読んだ

重い質問の仕方

本書では質問を4つに分類している。

  • 良い質問: 答えたくなる×気づきがある
  • 軽い質問: 答えたくなる×気づきがない
  • 重い質問: 答えたくならない×気づきがある
  • 悪い質問: 答えたくならない×気づきがない

このうち、「重い質問」と「悪い質問」の違いは質問の目的が共有されているかどうか。気づきがあるかどうかは質問を受けた側がどれだけ考えるかに依ると思うが、目的を丁寧に伝えることで、当人の背中を押して深堀りを促し、答えにくい質問から気づきを得る確率を上げられそうな気がした。

アドバイスをしない

多くの場合アドバイスには再現性がなく、「良い質問」は、良いアドバイスよりも「一生もの」になりやすいとのこと。これは、アドバイスを受けて行動する場合よりも、問いかけを受けて自身で行動を選択する場合の方が、より主体性を持って取るべき行動を探しに行くことになり、結果だけでなくコンテキストについても深く考えるから、応用可能な抽象化された知識が残るということかなと思った。

アドバイスしたいという気持ちを少し我慢することで、長い目で見て良い方に転ぶということは十分あり得ると感じた。やってみる。

文字列の内部表現

クイズ

Pythonクイズ 文字列中に含まれる a という1文字が消費するメモリサイズは?

  1. 1バイト
  2. 2バイト
  3. 3バイト
  4. 4バイト
  5. わからない

こういう問いかけをSlack上でしたところ、「1. 1バイト」と答えた人が9名、「5. わからない」と答えた人が4名でした。

出題意図としては、「5. わからない」あるいは、「1. 1バイト」&「2. 2バイト」&「4. 4バイト」の3つを選択してくれたなら正解のつもりだったので、4名が正解。

Python: PEP-393

www.python.org

Python 3.3 以降における文字列の内部表現は、latin-1 or UCS-2 or UCS-4 のいずれかが用いられる。どれが用いられるかは文字列中の文字のコードポイントの最大値で決まる。256未満ならlatin-1配列(1文字1バイト)、65536未満ならUCS-2配列(1文字2バイト)、それ以外ならUCS-4配列(1文字4バイト)

CPythonの実装は

cpython/unicodeobject.c at 0d7f61ddb074659d8c18c8f5ac86a6a18e41f9e5 · python/cpython · GitHub

で、NULL終端の分も含めて (size + 1) * char_size 分のメモリを文字列格納用に確保している。

クイズの答えはpython REPL上で以下のように確認できる:

>>> import sys
>>> X = "abc"
>>> sys.getsizeof(X + "a") - sys.getsizeof(X)
1
>>> X = "abcあ"
>>> sys.getsizeof(X + "a") - sys.getsizeof(X)
2
>>> X = "abcあ\U00029e3d"
>>> X
'abcあ𩸽'
>>> sys.getsizeof(X + "a") - sys.getsizeof(X)
4
>>>

他の言語処理系では

ついでにPython以外だとどうなのか調べてみたら、いろいろあることがわかった。

Rubyはバイト列とエンコーディングの組み合わせで文字列を表現しているとのこと。

techracho.bpsinc.jp

.NET は UTF-16

docs.microsoft.com

JavaUTF-16 だけど、Java9以降では1文字1バイトに収まる時はlatin-1で表現しているとのこと。知らなかった。

yujisoftware.hatenablog.com

Goの string は UTF-8

text.baldanders.info