12月に受験していたドイツ語技能検定の4級に合格してました。やったね。ドイツ旅行に行っても帰ってこられそう。
Duolingoも260日くらい続いているので今年も勉強を続けて、今度の冬は3級を受けようと思う。
『段ボール読み』集合知山手線ゲームをふりかえる
この記事は ゆる言語学ラジオ非公式 Advent Calendar 2022 - Adventar の7日目の記事です。
アドベントカレンダーの発起人ではあるものの他の参加者みたいなコンテンツは持ち合わせてないので、ゆサD（ゆる言語学ラジオサポーターDiscordサーバー）の中で今年楽しかった集合知山手線ゲーム（あるルールに合致するワードを集めたい人が山手線ゲーム形式で集合知を募る遊び）のひとつ、『段ボール読み』スレッドについて振り返りながら、こういう遊びをサポーターコミュニティでは楽しくやってるよ、という雰囲気を紹介したい。こんな遊びが好きならあなたもぜひゆサDへ！
専門用語が多くて語釈がめんどくさいなこれ。
『段ボール読み』の誕生
ことの発端は2022年2月4日、ゆサDのゆるい雑談チャンネルでのひとこと。
訓+外来語はあれど音+外来語の例ってあんま無い気がする。探したい
なさそうな感じがしたけどみんなでも考え始めるといっぱい出てきたので、集合知山手線ゲームとして立て直すことに。 このときに「音読み+外来語」というルールの呼称が『段ボール読み』になった。「音読み+外来語」に合致する代表的な例をそのカテゴリーの呼称にするということで、いわゆるシネクドキ（ゆる言語学ラジオ好きはすぐシネクドキって言いたがる）である。重箱読み、湯桶読み、そこに連なる新たなパターンが『段ボール読み』である。天才の命名。
レギュレーションの制定
集合知山手線ゲームといえばまずレギュレーションの制定・確認をするものである（そうなんです）。今回も「音読み+外来語」だけでは曖昧だったレギュレーションを詰めるところからスタートした。
集合知山手線ゲームの難しいところは、言葉はだいたい無限に創作可能で、特に漢字の熟語はかなり自由度が高いということ。段ボール読みのレギュレーションでは音読みする漢字部分は1文字に限定し、なおかつその漢字が用言ではないことがスタートラインとなった。
レギュレーションがゲーム参加者の中で共有されて回答が集まり始めたが、どうやら段ボール読みの言葉の中でも芸術性のような観点があることがわかってきた。そこからはより芸術点の高い段ボール読みを集めるゲームへとシフトしていった。
段ボール読みの四象限
そんなこんなで楽しくなってきた僕は、段ボール読みの芸術性が大きく2つの軸で評価できると踏んで、それを可視化してみようということで段ボール読みの四象限を作った。
作ってみたもののしっくりこないため、その後も集まり続ける段ボール読みをプロットする軸を試行錯誤していた
次々に集合知が集まりながらも、最終的に「漢字部分の造語力」と「外来語部分の造語力」の2軸による四象限が出来上がった。造語力とは、別の単語とくっついて合成語を作りやすいかどうかの度合いである。「高○○」や「反○○」などは造語力の高い漢字部分の典型例である。
この四象限で左上に近づくほど芸術性の高い段ボール読みだということがひと目でわかるようになった。ここから先の僕はスレッドに流れてくる集合知をひたすらプロットしていくことで段ボール読みに向き合っていた。
こんな感じで2月4日が終わり、このゲームも流れていくかと思いきや、翌日以降も新たな参加者による新ネタでさらに充実していく。
『塩ビ管読み』という新たな可能性
そんな感じでゆるやかに段ボール読みの収集が続けられていたが、偶然登場した「塩ビ」から『塩ビ管読み』という新しいカテゴリが発見されたが、まだあまり研究は進んでいない。
もし塩ビ管読みに強く惹かれた人がいたらぜひ集合知山手線ゲームを立ち上げてみるといいと思う。
そして人々は飽きていく
次から次に新しい集合知山手線ゲームは生まれているので、段ボール読みもだんだんと忘れられてスレッドはアーカイブされていく。1ヶ月近く収集が続いたので、集合知山手線ゲームの中ではだいぶ長いこと続いた方だと思う。 最終的に段ボール読みの体系はこんな感じになった。
案外探せば見つかるが、いいのが見つかったと思ったら訓読みだった〜ということも多く、そのバランスがいい具合に面白かったテーマだと思う。難しすぎると考えるのをやめちゃうし、簡単すぎると面白くない。「おお〜〜」という芸術性の高い段ボール読みを出せたときの快感がクセになる。
そして一度この遊びを知ってしまうと日常的にあらゆる場面で段ボール読みを探してしまうし、見つけたときに「段ボール読みだ」と思ってしまう呪いにかかる。この中毒性は ゴママヨサラダ に通じるものがある。ゆサDにはゴママヨを集める「ゴママヨサラダ」スレッドもあるのでゴママヨの呪いにかかった諸氏はぜひ参加してほしい。
以上、個人的に今年一番ハマったゆる言語学ラジオサポーターコミュニティでの遊びを思い出してふりかえってみました。サポーターコミュニティ開設初日から参加してますが1年過ぎてもいまだに盛り上がりつづけており、最近はあまり顔を出せてないですがいつ覗いてもにぎやかなのでいつでも帰ってこれそうだと思える不思議なコミュニティです。来年も楽しませてもらおうと思います。
ついでですが、ゆサDがきっかけで始めたドイツ語の勉強の成果としてドイツ語検定の4級を受けてきました。自己採点では多分合格できてると思います。何かを新しく学びたいと思わされる刺激的な人たちがいっぱいです。
明日はyasuさんの投稿です。
ビジネスとエンジニアリングの3wayハンドシェイク
ビジネスとエンジニアリングが足並みをそろえて共に顧客に価値を届けるためには、欠かすことのできないステップがあることに気づいた。それは 「要求」「検査」「合意」 の3ステップで、あらためて考えると当たり前のことしか言ってないが、これを欠いたプロジェクトは簡単に炎上する。この3ステップの様子がTCPのコネクション確立時のプロトコルと似ていたので、ビジネスとエンジニアリングの3wayハンドシェイク と呼ぶことにした。
1.「要求」: ビジネス要求をすべてテーブルに載せる
最初のステップは、ビジネスがプロダクトへの要求をすべてテーブルに載せる。 「テーブルに載せる」 というのは、人々が囲む円卓の上に情報や考えを公開し、それぞれの人が吟味して議論できるようにするイメージだ。ここではプロダクトというテーブルをビジネスとエンジニアリングが囲んでいるということになる。
「要求」に求められるのは、忖度も遠慮もなく、100%の理想をまずテーブルに載せること。2番目の「検査」では、最初にテーブルに載せられたものしか扱えない。ここで隠した目論見や期待が後出しされ、すでに動き出したプロジェクトが吸収できる衝撃の許容限界を超えてしまえば、プロジェクトは炎上する。
とはいえ最初からすべての要求を具体的にすることは難しい。それでもわかってないことはわかっていないということを全部載せる。何がわかってることで何がわかっていないことかという認識を、テーブルを囲む全員で共有する。わかってないからといって隠さずに「このへんは後から変わる可能性が高いから変わっても耐えられるようにしてくれ」という要求ができないと、「そんなことは聞いてない」という悲しい炎上が待っている。
2. 「検査」: ビジネス要求の実現可能性を見積もる
次のステップは、テーブルに載せられたビジネスからプロダクトへの要求を、エンジニアリングの視点で開発要件に翻訳した上で実現可能性を見積もる。検査の最初の段階では、100%の理想を実現するために必要な仕事を見積もり、チームや組織にその仕事を実行できる力があるかどうかを吟味する。
力が足りないのなら、この要求すべてを満たすことは難しいということとその根拠をテーブルに上乗せする。もし余裕があるのなら、余力があること、もっと顧客に価値を届けるために厳しい要求に答えられることも上乗せする。ここで余力があることを隠すと、それに感づかれてしまった後には信頼を失い、「どうせ余力があるんだから後から追加の要求をしても大丈夫だろう」と「要求」の質が下がることになる。
3.「合意」: 実現可能かつ価値ある明確なプロジェクトのゴールに合意する
エンジニアリングサイドから最初の「検査」結果が出たら、あとはテーブルを囲む人々で協力してビジネス要求を調整する余地を探る。実現可能性があり、顧客にもっとも大きな価値を届けられる落とし所を探る。
全員が納得の行く「合意」に至るには、それぞれの判断基準がすべてテーブルに載っていて、テーブル上の材料から考えれば誰もが同じ結論に辿り着くだろうという信頼が必要である。
実現可能性と顧客価値の両方が最大化される点を見つけ、その実現に明確なコミットメントを置かなければ、プロジェクトは炎上する。厳しすぎるゴールはそもそも実現できないし、参加メンバーも消耗する。甘すぎるゴールもコミットメントがあいまいになり、計画性や生産性を高めるための創意工夫がおろそかになる。そしてプロジェクトの期間が長くなれば長くなるほど後からビジネス要求が追加される可能性も高まる。（パーキンソンの法則）
ビジネスにとっても顧客にとってもエンジニアリングにとっても、甘すぎるゴールは望ましくない。実現可能性と顧客価値の両方が最大化される絶妙なラインを見定めるのが、ビジネスとエンジニアリングでテーブルを囲んでやらなければならないことである。
3way ハンドシェイク
3way ハンドシェイクとは一般的に、TCPにおいてクライアントとサーバーの間の通信を確立するための所定の手続きのことで、次の3ステップを最初に行う。
- クライアント -> サーバー:
SYNを送信 - サーバー -> クライアント:
SYN-ACKを送信 - クライアント -> サーバー:
ACKを送信
「要求」「検査」「合意」 は同じ3ステップのプロトコルということだけでなく、クライアントとサーバーが接続して機能するためにかならず最初に行わなければならない手続きという点で似ている。ビジネスとエンジニアリングの協働をはじめるためのプロトコルとして、3wayハンドシェイクという比喩はそこそこ的を射ているのではないかと思う。
また、これはあくまでも信頼できるコネクションを確立するまでのプロトコルにすぎず、確立したコネクション上でどのようにコミュニケーションしてデリバリーにつなげるかはチームのプロトコル次第だというのも、TCPとHTTPの関係に似ているようにも思う。
3way ハンドシェイクができないチーム
そのチームが自分たちで3way ハンドシェイクができなければ、できる人に「要件定義」をしてもらわないといけない。つまり上流工程と下流工程の分離であり、バリューストリームの源泉をチームの外に依存した状態だということになる。
自分たちで一貫して顧客に価値を届けたければ、チームが自分たちで3wayハンドシェイクができるようにならないといけないし、それが自律したプロダクトチームが担うプロダクトマネジメントの最初の一歩ではないか。
社内ブログに書いた内容から加筆修正して公開。
独検2022冬の4級に出願した
ゆる言語学ラジオのサポーターコミュニティDiscordがきっかけで始めたDuolingoでのドイツ語学習が180日くらい続いており、せっかくなので何かしら試験を受けてみようと思って独検ことドイツ語技能検定試験に出願してみた。
試験日は12/4。 Duolingo基準だとこれまでに1500単語くらいに触れているらしいが、ReadingはともかくWritingはぜんぜんやってないので、あまり冒険せず1000語相当らしい4級からはじめてみることにした。
文法規則はけっこうわかってきているのであとは語彙と場数という感じな気がしている。というわけで試験までの戦略は
- 過去問を解く
- 単語学習用のアプリで毎日語彙を増やす
単語学習用のアプリはなんとなくよさそうな ReWordというのを使ってみる。Duolingoと同じく英語話者向けの教材だが多分これで困らない。
というわけでしばらく合格に向けて勉強していきます。
読後メモ『エンジニアリングマネージャーのしごと』
O'Reilly Japan - エンジニアリングマネージャーのしごと
今年オライリーから発売された『エンジニアリングマネージャーのしごと』を読み終わったので、あとでまた思い出したいエッセンスをいくつか書き残しておく。
3章 人間と関わる
3.3 上司との連携
毎週時間を取って状況をまとめるというシンプルな活動は、強力な治療効果があります。 取り組んでいる問題からちょっと離れて、紙の上で扱えるようになります。そうすると、問題もそれほど 重大でないとか、難しくないことがわかります。 自分の生活を記録することは、気分や健康の改善に良い影響があるという研究もあります。 仕事を毎週記録することで、 仕事でも同じような効果があるのです。
うまく書けないなら、4つのPというアプローチを試しましょう。
- 進捗 (Progress): 前回の記録から何が起こったか?
- 問題 Problems) どんな問題が起こったか、対処が必要なものは何か?
- 計画 (Plans):問題に対してどのように取り組む予定か?
- 人 (People) : チームの人はどうか。 全員良い状態か? 辛い状態の人はいないか? 何を改善できるか? (p56)
自分のマネージャーとしてのパフォーマンスや健康状態について上司と話をするために、ふりかえりと計画を端的に、定期的に記録する。
サマリーの書き方としておすすめされている「4つのP」も、この文脈に限らず汎用性のありそうなので覚えておきたい。
4章 1on1
4.3 コントラクティング：最初の1on1
コントラクティングとは最初の1on1で扱う単純な質問一式で、あなたと部下が期待することについての会話を誘発するものです。 両者から期待することを出します。 このエクササイズにより、 お互いのニーズを構造化された安全な方法で話せるようになり、率直で透明性の高い会話ができるようになります。(p65)
部下との最初の1on1で、コントラクティング（contracting, 契約）というエクササイズを行うことで、その後両者が互いに何を期待し、どのように関わるかについて合意をつくることができる。
似たようなことは今までにメンターとして1on1をするときにやっていたが、この節のガイドのおかげで今後はもっといいコントラクティングができそうだと思った。
10章 人間って難しい
10.3 ムチとニンジン
処理能力を向上させる本当のリーダーシップは、チームのなかで目的と情熱を育むことで生まれ ます。 エンジニアが組織内での自分の目的と会社のために形勢を変える方法がわかれば、本来のパ フォーマンスを発揮できるようになります。 仕事に情熱が持てれば、もっと良い仕事ができるようになります。 本質的に楽しめる人たちだからです。
（中略）パフォーマンスの問題ではないと仮定してですが、もしチームの仕事に対するモチベーションが低いとか、あなたの思うような動きをしてくれないといった場合は、チームがよく機能する一団となっていける状況を作り出す必要があります。
これに役立つモデルがあります。 自律性、熟達、目的です。 (p186)
チームにとってニンジン（それによってやる気が湧いて一生懸命働くようになるもの）となるのは、それが自律性・熟達・目的の3つの条件を満たすようなものであるという考え方のモデル。
チームの成果に課題を感じるとき、まずこのモデルで考えてみようと思う。そのチームの前にニンジンはぶら下がっているか？ムチで叩いてしまっていないか？
12章 情報の証券取引所
12.3 社内政治
あなたが情報をうまく扱っているとしても、仕事はそこで終わりではありません。 マネージャーとして、人に情報を把握しておいてもらう義務があります。誰も置いていかないようにしましょう。
共有する情報の一貫性を継続的に示すべきです。（中略）プライベートなインタラクションと全体への周知の両方を使って、誰も置いていかないようにしましょう。 (p223)
チームやメンバーが情報の流れから置いていかれないように、必要な情報を確実に把握しておいてもらうことはマネージャーとしての義務である。
「チームを適切な情報のループに入れておく」という考え方はなるほどと思った。点での情報共有ではなく、確実なループを作ることを意識してみようと思う。
14章 良いハウスキーピング
14.4 問題を学習の機会に変える
先ほどは、ソフトウェアに問題があったときに何をするかを見てきました。 では、プロ セスに問題がある場合はどうすべきなのでしょうか？チームが、ブラットフォームのアーキテクチャーに関するドキュメントや新しいサービスを作るときのベストプラクティスを記したガイダンスを見つけるのが難しいような場合です。 これは単にチームにとどまらない問題であり、答えを見つけるのは難しいかもしれません。 また、このような問題は、士気の低下にもつながります。手に負えない状況の場合、 人はどうやって変化をもたらせるのでしょうか?
このようなときに、マネジメントバグに取り組んではどうでしょうか? eBay が急成長していたときリーダーシップチームは現場からどんどん離れていってしまいました。 小さくて機敏な文化は、急激に大企業的になりました。 CEOはこの問題を正したいと考えて、オフィスの人通りの多い場所に意見箱を置きました。 誰でもメモを箱に入れることができ、全社ミーティングのときに箱を空にしました。すべての意見や提案が、従業員全員の前で読み上げられ、 回答されたのです。 (p266)
マネジメントバグという方法ははじめて知ったが、つまりプロセスやマネジメントの課題についての目安箱だということだろう。特徴的なのは、それがすべて全員の前で読み上げられ、マネージャーがすべてに回答するという徹底的な透明性へのコミットメントだと思う。投げ込んだチケットが無視されず回答されると信頼できるからこそ、真剣に意見を上げてくれるのだろう。会社全体の課題じゃなくとも、小さい規模でやってみたいと思った。
16章 現代の職場環境
16.2 リモートワークへの移行
非公式なやりとりが減ってくると、スタッフのために価値と目標をきちんと設定することはより重要になります。
- 価値はチームの働き方を定義するため、メンバーは統一された方法で非同期に進捗を出せます。（中略）
- 目標はチームの狙いを定義するため、みんなの足並みがそろいます。 分散チームではスタッ フが自律的に働けるため、目標の重要性が増します。
チームの価値と目標についてそれぞれ別の効果のために設定する。価値は何を大事にするかという、チームの働き方を規定するための土台になるもので、具体的な行動指針として記述されればそれがワーキングアグリーメントということになるだろう。 一方で、目標はチームがなんのために働くのか、何がそのチームの勝利・成功なのかということの基準になるものであって、イテレーションの中で追跡していくものになる。この2つを混同せず、どちらも欠けていないようにチームを保たなければならないだろう。
感想
エンジニアからマネージャーになったことで、個人としての自分のアウトプット、パフォーマンスの見えにくさによって自己効力感や自己肯定感を失い始めている人に、本書をおすすめしたいと思う。繰り返し出てくるフレーズがあるのだが、これがこの本で一番伝えたいこと、覚えて帰ってもらいたいことなのだろうと思う。
マネージャーのアウトプット = あなたのチームのアウトプット + あなたが影響を与えた他のチームのアウトプット
とはいえ、このことを頭で理解していても、実際に心で納得できるほどになるには精神的な成熟が必要だと思うし、このことに悩んでいる人は実際に周りでもたくさん見ている。
僕個人はこのことには悩んでいないが、それはそもそもマネージャーじゃなかったとしても、そんじょそこらのエンジニアでは個人で生み出せる価値なんて大したものじゃないと思っているし、結局チームとして価値を出せるかどうかだけが拠り所だと割り切っているからかもしれない。なので、マネージャーをやり始めて日は浅いがこの方程式はしっくり来ている。それがうまく言語化されていて腑に落ちた本だった。