会社のLT会でgit-jumpを紹介した

会社のLT会で発表させてもらった。楽しかった。

git-jump は git の contrib 以下に入っているスクリプトで、興味のある要素

• diff: diff hunks
• merge: merge conflicts
• grep: grep hits
• ws: whitespace errors

をエディタ(Vim)で開いてくれるというもの。例えば git grep のヒットした周辺を見たい場合、 -C で前後数行を出すこともできるけど、エディタで開いてくれたらもっと柔軟に周辺を見れる：

docs.google.com

あるいはマージしてコンフリクトが発生した時に、コンフリクトした箇所を順に編集していける。

私が git-jump を初めて知ったのは昨年の11月に視聴した「AWS Developer Live Show: Git の最新アップデートから考える開発手法の潮流」で紹介されていたのを見て。

aws-dev-live-show.connpass.com

どんなツールなんだろうと触ってみて、これ他のエディタでも使えたらいいなって思って、標準出力に出せるようにして Emacs の M-x grep から使えるようにして、そらに Emacs を起動できるようにしました。Emacsで使った場合のデモ：

docs.google.com

LT会で出た質問で git Mailing List の話があり、昔はメールでパッチ送る必要があったけど、今は GitGitGadget - contributing git.git patches via GitHub PRs があるのでだいぶ楽になりました。

発表に使った資料です：

speakerdeck.com

「私たちはどう学んでいるのか」を読んで思ったこと

私たちはどう学んでいるのか　――創発から見る認知の変化 (ちくまプリマー新書)

知識は伝わらない。教育とは知っていることを整理して伝えることではない。

文脈や環境から切り離して完全な再現性なんてないってことか。振り切ってるな / 能力という仮説は無効であり、能力は虚構 #私たちはどう学んでいるのか

— Yoichi Nakayama (@yoichi22) 2022年10月29日

学習というと、問題が既にそこにあって、正解があって、その正解を知っている人がいる、という状況で、問題の解き方を学ぶということを想像するかもしれない。しかし、僕らが普段立ち向かっているのは文脈や環境から切り離された答えのある問題ばかりではなく、正解がない、あるいは問題自体が明確でない状況が多くある。

認知科学における問題とは、望ましい状態と現状が一致していないことを指し、問題を解決するとはそれらが一致した状態にするということである。解決のために現状に何らかの操作を加えていくのだが、複数の操作をうまく順序立ててやらないといけなくて、試行錯誤して解決方法を探っていく必要がある。つまり、問題を変形しつつ、解ける問題を探索することで、解決を目指していく。

この本を読んで、文脈や環境に依存した無限のパターンの問題に対して、教育により解き方を教えられるなんて考えはおこがましいと思った。ただ、教育という相互作用の場を通して、両者が学び合い、それぞれの中での認知的変化を起こしていく。そういった協力をしながら一緒に歩んでいけると素敵だなと思った。

近接項は「伝える」だけど、遠隔項は「向かわせる」なのは学習者自身が知識を構築するものであり、人から教えられるものではないからかな #私たちはどう学んでいるのか

— Yoichi Nakayama (@yoichi22) 2022年11月8日

2022年のふりかえり

昨日で無事に仕事も収まりましたので一年のふりかえり。

今年の仕事、無事に収まりました。冬休み！

— Yoichi Nakayama (@yoichi22) 2022年12月28日

健康面

既往症の尿路結石、2月に再び来襲していた。とても痛かったのでお医者さんで座薬入れてもらって、あとは薬飲みつつ様子見してたら治まりました。4月にお医者さんで見てもらったら、膀胱の手前の石と、右腎臓に残っていた石も無くなっていてスッキリ。左腎臓には石があるけどそちらは様子見。

あと、健康診断では初めて便潜血ひっかかってしまい、大腸内視鏡検査を受けた。

お医者さんにて、初めての大腸内視鏡検査、初めてのポリープ切除に加えて、初めてのウォシュレットを体験した。初めてづくしだ

— Yoichi Nakayama (@yoichi22) 2022年12月21日

検査が終わった後「お尻洗ってくださいねー」と処置室の脇のトイレに案内されて、生まれて初めてのウォシュレットにチャレンジしたのがとても緊張した。切除したポリープの細胞診の結果は年明けなのでまだ安心はできないけど、ひとまず初めての検査は乗り越えた。頑張ったね自分。

お仕事（前半）

とあるプロジェクトを開始して、拠点跨ぎ（大阪と東京の2拠点）、組織跨ぎのメンバー構成で進めていたが、満足行く結果には到達できなかった。拠点が分かれていることでフェイストゥフェイスで話せる頻度が低いことよりは、組織の向こうのメンバーが別のプロジェクトとの兼務で、組織上のチームが違うのでその兼務の間でのきめ細かな優先度コントロールに踏み込めなかったのが敗因だったと思う。

その後同じメンバーで後述の組織上のチームを再構成することになったので、人的な面でも業務知識習得の面でも準備になっていたと、後からの解釈はできるが、当時はうまく進められずにかなりもどかしい思いをしていた気がする。

プロジェクト業務に集中するため、その他の業務の自分以外のメンバーへの委譲を推し進めていて、こちらも組織変更でのチームリーダー（私）の離脱をスムーズに進められたことに繋がった。属人性の解消は以前より継続的に取り組んできていたので、こちらは狙い通りかな。

お仕事（後半）

8月に会社のテックブログにチームビルディングに関する記事を出したけど、そちらは前のチームの話で、7月から新しいチームに移っていた（チームリーダーとして受け入れてもらった）ので、裏では新しいチームのチームビルディングが絶賛進行中でした。

tech-blog.monotaro.com

これまで組織変更によるチーム名の変更やメンバーの出入りはあったものの、ずっと同じシステムをメインで見てきたのに対し、今回の異動で慣れ親しんだシステムから離れて、１番の下手くそになる機会*1を与えていただきました。

新しく見ることになったシステムについては全然わかってなかったのでオンボーディングして欲しいとお願いして、前から担当されている方々から優しくいろいろ教えてもらいました（とっても感謝）。

システムリプレースを進めている箇所の移行元システム担当から移行先システム担当に移った形で、業務領域は共通部分があり自分もそこそこ詳しいことが多々あるので、双方向の知識継承や、違った視点からの意見を出し合っての対話や議論が継続的に発生していて、受け入れてもらった私達も、受け入れた側の方々も、いい学びが得られてるんじゃないかと思います（自画自賛）。

新たに担当することになったシステムについては同僚がブログに書いた記事があるので興味ある方はご参照下さい：

tech-blog.monotaro.com

tech-blog.monotaro.com

SQLFluff コミュニティ

会社の新しいチームで SQL のフォーマットを揃えるのに sqlfluff を導入しようとしていた（その後導入した）のですが、メンバーの一人が Issue を出したりしていたのに刺激を受けて、私もいくつかプルリクエストを出して貢献することができました。10月の Hacktoberfest 2022 でカウントされたのも4つともsqlfluffへの貢献でした。

主に貢献したのは対応してなかった形式のクエリへの対応ですが、sqlfluff ではパース結果を期待値と比較するテストの仕組みがとても良く出来ていて、改修の際にリグレッションが発生しないことの担保を低コストで行えるようになっているのが素敵です。

あと、コミュニティの雰囲気がとても良い感じで、プルリクエストのレビュー時のフィードバックが的を得たものが多く、こちらの言い分もしっかり受け止めてくれる感じがします。また、変更箇所のうちこちらが説明不足だったところも遠慮なく率直に「これは何で？」と問いかけてくれて、次は前もって出せる情報は出しておこうと前向きな思考に繋がったり、気持ちよくやりとりできている印象です。自分がコードレビューする側に立った時のあり方について考えるきっかけをもらいました。

git-jump の Emacs 対応

Git の勉強会 (Git の最新アップデートから考える開発手法の潮流 - Speaker Deck) で git-jump という git サブコマンドの存在を知り、使ってみたところ、vim 専用のコマンドであること、ファイル名:行番号: のフォーマットを quickfix*2 という機能で解釈していることがわかりました。

github.com

私は vim も使いますが、コード編集で主に使ってる Emacs でも使えるといいなと思って、対応してみました。

github.com

メーリングリスト上のレビューで鋭い指摘をいくつかいただいて、いい刺激になりました。

次のリリース 2.40 に入る予定です(リポジトリの最新からとってこれば今でも使えます)。

まとめ

一年って思ったより長くて、後半の記憶は鮮明だけど、前半何やってたかを思い出すのに結構苦労しました。それくらい日々色々なことがあって、刺激を受け、学びながら過ごせているということなので、良い一年だったと思う。健康には気を付けつつ、来年もいろいろ学んで行けるといいな。

*1:参考：情熱プログラマー 第1章 4 一番の下手くそでいよう

*2:https://vim-jp.org/vimdoc-ja/quickfix.html

「聞く技術 聞いてもらう技術」を読んだ

東畑開人さんの「聞く技術 聞いてもらう技術」を読んだ。

聞く技術　聞いてもらう技術 (ちくま新書)

「キク」に当てる漢字として「聞く」と「聴く」があるが、この本は「聞く」についての本である。語られていることを言葉通りに受け止める。話し手と聞き手の関係性構築の基礎となるアクションが「聞く」だが、それが意外と難しい。

実際自分が人から何か言われている時にも、裏があるんじゃないかとかそういった思いが頭の中を駆け巡り、言葉通りに聞けてないことがある。耳では聞こえてるし、言葉通り素直に聞いて受け止めればいいのに、受け止められない。後になって考えると、何で素直に聞けてなかったんだろ？って不思議ですらあるのだけど、その不思議さがポイントだということがこの本を読んでわかった。

上で「聞く」が関係性構築の基礎だと書いたけど、逆に関係性に問題が生じていると聞けないということもあり、関係性構築のために「聞く」のか、「聞く」ために関係性構築するのか、「鶏が先か、卵が先かの問題」がそこにはある。最初どっちから入るかは大変難しいけど、一旦できてしまえばあとは自然と連鎖していく。上で書いた不思議さは、関係性が構築されてしまった後ではそんなの当たり前と思えてしまうということ。

「聞く」に入るための対処方法として書かれているのは、

• 誰か他の人に話を「聞いてもらう」ことで、自分が「聞く」余裕を作る
• 「聞く技術 小手先編」の手法を使う

で、前者の「聞いてもらう」については、続く「聞いてもらう技術 小手先編」にとっかかりとなる具体的な手法が紹介されている。

題名には「技術」と入っていて、対処方法を伝えることが主題かと思ったけど、そうではない。誰かに話を聞いてもらい、今度は誰かの話を聞く、そうして話を聞いてもらった人が、別の誰かの話を聞く、という「聞いてもらう」「聞く」の連鎖が人と人の間で繋がっていき、関係性の構築、コミュニティの形成ができるというのが著者が目指しているところで、そのための手法は何でもいいんだよ、とにかく「聞く」「聞いてもらう」をぐるぐる回していきましょう、「聞く」「聞いてもらう」によってもたらされる価値を享受していきましょうというのがこの本で伝えようとしていることと思った。

小手先編に書かれている方法で実践で使えそうなものがいくつかあったので試してみる。特に「傷つけない言葉を考えよう」に書かれていた「ゆっくり考えてから言葉にする」は早速やっていく。

ヨシタケシンスケ展に行ってきた

愛知会場が始まったので行ってきました。6穴ノートに描かれたスケッチが足元から天井までずらーっと展示されているところで一時間以上見入っていたと思います。上の方は流石に見れなかったですが、下の方はしゃがみ込んで見ました。とても楽しかった。

yoshitake-ten.exhibit.jp

記念品の「あなたのみらいはこれかもしれない！でもぜんぜんちがうかもしれない！」カードは「めいかんとく」でした！なれるかな？

ローコンテクストなコミュニケーションは共につくる

リモートワーク環境におけるコミュニケーションの促進のため、あるいはメンバーの多様性への対応のため、コミュニケーションのローコンテクスト化が重要というのをよく耳にするようになりました。

ローコンテクストなコミュニケーション、ハイコンテクストなコミュニケーションについては、書籍「異文化理解力」において、国毎のグラデーションの視点から紹介されています。

異文化理解力 ― 相手と自分の真意がわかる ビジネスパーソン必須の教養

ローコンテクストなコミュニケーションでは、話し手は明確で曖昧さがないように意図を伝えます。それにより、聞き手は行間を読んだり、想像したりといったことなしに話し手の意図を理解できると期待します。つまり、ローコンテクストなコミュニケーションでは話し手が言語化の責務を負うことで、聞き手が曖昧さに対処する負担を減らします。

ローコンテクストなコミュニケーションにおける言語化について、話し手の責務が大きいのは確かです。ただその一方で聞き手は全くの受け身で良いかというと、私はそうではないと思います。聞き手もまた能動的にコミュニケーションに参加し、言語化を一緒になって進めないと、話し手の意図を正確に理解できない場合があります。

それは何故でしょうか。

一つは、ローコンテクストといってもグラデーションがあることによります。ある聞き手は十分明確で曖昧さがないと受け取っていても、別の聞き手はまだまだハイコンテクスト過ぎて理解が及ばなかったり、あるいは誤った理解をしてしまい、伝える側が意図してない内容を受け取ってしまうことがあります。

そういったことを完全に避けることはできないので、受け取ったことを聞き手が自分の言葉にして、元の話の話し手や、他の聞き手と対話をしてみること、そこで曖昧さに気付いて問いを発することが、解決の糸口になります。

また、「明確に伝わるように最初からしっかり言語化しておいて欲しい」と聞き手は思うかもしれませんが、話し手が一方的に聞き手のことを想像して、曖昧さがないように伝えようとしても、完璧なコミュニケーションなんて存在しないので無理だし、無理なのを頑張ってその方向性を目指すことで、「ライト、ついてますか」の長くて読みきれないし逆に伝わらない標識のようになってしまうこともあります。

ライト、ついてますか　問題発見の人間学

もし今が昼間でライトがついているなら

ライトを消せ

もし今暗くてライトが消えているなら

ライトをつけよ

もし今が昼間でライトが消えているなら…

ローコンテクストなコミュニケーションではシンプルさも求められるのですが、それを忘れて誤解がないようにという点に固執すると、逆に明確さが失われてしまうという例です。

この問題は、話し手だけにコミュニケーションの責任を負わせていることに起因していると思います。

話し手の方はある程度は聞き手のことを想像しつつ、明確に伝えるよう意識する。その一方で聞き手は、明確なコミュニケーションを話し手だけの責任にせず、わからないポイントを言語化して質問する。すると、わからないポイントに即した説明がもらえて、相互の共通コンテクストが構築されていく。そして共通のコンテクストの上で曖昧さのない明確なコミュニケーションが成立します。

ノーコンテクストではなく、ローコンテクストと言っているのは、グラデーションのことを双方が理解し、対話を通してコンテクストを共につくるということを含めてのことと思いました。話し手と聞き手の双方が敬意を持って対話することで、一緒に共通理解を増やしていけると素敵ですね。

「LISTEN ー 知性豊かで創造力がある人になれる」を読んだ

LISTEN――知性豊かで創造力がある人になれる

本が手元に届いた時の第一印象は「分厚い」でした。目次を見ていくと確かに盛りだくさんの内容で、全部読み切れるのかといきなり自信喪失しかかり、まずは目次を眺めて気になったところをつまみ食い的に読んでみたところぐっと引き込まれ、だいぶ時間はかかりましたが最後まで読み切りました。

解決をしたいなら、相手の意見を聞くしかない(p180)

反対意見を聞くことは「相手の言うことを聞かねばならない」ことではない、という表題のChapter 7には、対話による課題の解決、合意形成のために聞くことについて書かれていました。自分とは異なる意見を相手が言ってきたときに、最後まで聞かずに反論したり、しっかり相手の言っていることを理解しようと聞けていないことはありがちだけど、良く聞くと実はたくさん共通点があったり、自分の意見と組み合わせることでより良い結論になることもある。このことは自分の経験上も確かにと思うんだけど、つい反射的に反応しちゃうんですよね。 「反対意見を聞くことは、人間にとって生理的に脅威を感じること」と書かれているように、怖いという思いが出るのは避けられないので、そうなった時に気を落ち着かせて、ちょっと聞いてみるかと思い直せるかどうか。

自分が話さなかったからこそ、価値のあることが聞ける(p399)

会話の中で沈黙が訪れた時に、それを埋めようと口を開いてしまい、相手の発話を妨げてしまったかも思うこと、これもよくある。やってしまってからしまったなーと思うことばかり。ここでは作曲家のグスタフ・マーラーの言葉「音楽の最高な部分は、音符の中には見つけられない」を引き合いに出して、いちばんいいところは沈黙から現れるので、間や沈黙を早く埋めてしまわずに、沈黙に注意を払うことが大事と書かれていた。沈黙してるのは、相手が言葉にならない何かを伝えようとしているかもしれないという考えに立って、焦らず観察する、とにかく待ってみる。

うわの空になるのは、「思考」が話よりも速いから(p162)

話を聞こう、沈黙を埋めずに待ってみよう、と思ってもなかなかできないことの理由の説明。いちばん会話を邪魔するのは「自分を次に何を話そうか」という心配、というのはまさにそれだなと思った。しっかり相手の話を聞きたいと思っていたのに、いつの間にか何を話そうかと考えてしまっていること、聞いたことを理解しようと考える中で、聞くことから意識が外れるのを抗えない時はある。そうなってしまったらできることは、「あ、うわの空になってるわ」と気付いたら素早く「聞く」ことに戻るくらいかな。

まとめ

他人の話を聞くことでどのような価値が得られるのか、聞くことができないのはどういう理由があるのかなど、「聞く」についての知見がぎゅっと詰まった本でした。人の話を聞くとき自分がどういう風にしていたかを思い出し、この先どういう風に聞いていくかを考えさせられました。学んだこと実践していこう。