Konifar's ZATSU

私はのび太の味方じゃないわ、悪の敵よ

40%キーボードを買ってもらった

嫁氏が就職して初任給が入り、欲しいものを買ってやるというので、前から気になっていた40%キーボードを買ってもらった。

色々検討した結果 Corne Cherry V3 にした。2日ほど実務でも使っているが結構慣れてきたので雑に記録を残しておく。

選定基準

  • せっかくなので分割キーボードにしたい
  • キースイッチが家にいくつかあるのでホットスワップ
  • はんだ付けからしたいわけではないので精密ドライバーがあれば作れる
  • 親指あたりの数が3つくらい。それ以上はたぶん使いこなせないので
  • 3万円以内くらい
  • 熱が高まっているので数日以内に手元に届く
  • できれば無線

Amazon でキーソケットつきではんだいらずの Corne Cherry V3 があったので購入した。 V4 の方がよかったが、在庫がなくすぐに手に入らなそうだったので諦めた。注文してから3日くらいで届いたのでよかった。

完成品

  • キーキャップ
    • Keecipal Violet
    • ZOMO PLUS プラスチック版 肉球キーキャップ
    • 梅雨なので紫陽花みたいな色いいなと思って買った。右下のキーを Esc にして、持て余していた肉球キーキャップをつけることで感触で判断できるようにした。実用性も高く、下で紹介するノラネコぐんだんのマスキングテープ装飾ともマッチしててよい
  • キースイッチ
    • アルファベットキー部分 : PFU キーボード HHKB Studio リニアスイッチ
    • 親指キー・サイド1列 : GATERON Mini i Switch
    • 静音で軽いのが好みで、もともと使っていた HHKB Studio のスイッチがあったのでそれをメインにした。Kailh MX Nighttime PRO Switch もよかったが、自宅にあるのが20個くらいで足りなかったのでやめた。CtrlやCmd、レイヤ切替のためのキーは少しコトコト音が鳴るほうが勢いがついてよいのでスイッチを分けてる
  • ケーブル
  • Pro microカバー

キーマップ

次の指針でキーマップを決めていった。

  • レイヤーは3つまで
  • よく使うキーは人差指、中指に寄せる
  • 英数かなの切替はワンタップで
  • QMK Configurator で設定できないことはやらない

40%キーボードを使って気づいたが、マジでキーマップの探求は沼。沼すぎる。色々変えながら実務でも使ってみて、2日くらいでだいたい次のように固まってきた。

  • レイヤー0 : 文字入力
  • レイヤー1 : 数字と移動
  • レイヤー2 : 記号
  • レイヤー3 : Fnとデバイスとマウス

親指にShiftとEnterを割り当てたのは意外とよかった。マウス移動もすべてキーボードでできるのも非常によい。たいていはショートカットキーで対応できるけれど、ちょっとマウス欲しい時もあるしね。

2日くらい実務をやって、Typing Practice for Programmers | typing.io でも記号キーに慣れていったら70%くらいのスピードになった。まだ記号と数字が入り混じる文字を書く時には頭で考えて打ってる。慣れないマニュアル車を運転しているような感覚があるが、あと1週間くらい触ってれば指で打てるようになると思う。

カバーもいいものがあれば購入する予定。

総じて、非常によいプレゼントとなった。嫁氏に感謝ァ。

相手への気遣いの考え方は人によって違う

今日も今日とてインターネッツは騒がしい。

このツイットが内容、引用ツイ含めて興味深かった。

「初めまして。〇〇です。………一度打ち合わせをして頂けないでしょうか?」
「良いですよ。」
「ここから選んで下さい。」
TimeRex
これいつも「は?」と思うの僕だけですか?

正直自分は本文のやりとりをされたとしても何も問題には感じなかった。むしろ、日程調整の手間がかからずありがたいとポジティブに感じるくらいである。つまり、自分もこの「は?」と思われるやりとりをする可能性が大いにあるということである。自分の視野を広げるために、少しキャッチアップしておきたい。

このやりとりのまずいところは2つあると思う。そもそも自分の感覚がズレているので間違っているかもしれない。間違ってたら教えてほしい。

  1. 自分の予定に合わせた日程調整を依頼していること
    • 相手に一方的にお願いをして時間を取ってもらう立場にもかかわらず、自分にとって都合のよい時間をベースに調整を依頼していること自体が意味がわからないという意見
    • 要は、本当に打ち合わせを依頼するならまずは先方の予定に合わせられるかを前提にコミュニケーションを取れよという話
  2. 必要な説明や前置きなく事務的に日程調整を依頼していること
    • どんな打ち合わせで何分必要なのか、日程調整ツールの選択肢の中で、できればどのくらいまでにお願いしたいといった話がされていないとしたら改善した方がよさそう
    • また、「不躾ではありますが、まずはこちらの日程の中でご都合のつく日はありますでしょうか?なければ候補をいくつかいただき調整させていただければ幸いです」みたいな表現が合ったほうが、余計な摩擦も減るとは思う

「出席が前提となっているのが謎」という意見も見られたが、「いいですよ」で承諾してもらっているということからこれは問題ないはずだと感じてる。正直この感覚も違うかもしれなくて自信がないのだけれど。

「選択肢が長期になるし多すぎて大変」という意見については、日程調整ツールの設定次第なので、今回は考慮していない。

「いきなりツールで調整を依頼するのは失礼」という意見については悩ましい。やりとりの手間も減るし、むしろ相手の負担を減らす配慮だと思うので、あとは文面次第なのではないかと思う。

1 の 自分の予定に合わせた日程調整を依頼していること については、まあそうだなと思う一方で、自分は打ち合わせを承諾した以上相手の予定と自分の予定を上下なくフラットに最短で調整するという頭になってるので問題ないと判断してしまっていた。「なんで依頼してきた人の予定に合わせないかんの?」という感覚がそもそもなかったのでここは認識を更新しておきたい。

2 の 必要な説明や前置きなく事務的に日程調整を依頼していること については、このツイットだと正直実際どうだったかわからないけれど、配慮して丁寧めにコミュニケーションを取るに越したことはないと思う。

ただ、相手への配慮・気遣いの考え方というのは人によって結構違うというのを認識しておく必要がある。「なるべく相手の負担が少なく調整できるように最小限の文面とTimeRexを相手に渡す」という合理的なやりとりもある種の気遣いと言えるし、「相手がどう感じるかわからないから前置きの説明を丁寧めにして、日程調整もどうするのがやりやすいか意向を伺ってからにする」というのも想像力のある気遣いと言える。

これはどちらが正しいというわけではなく、育ってきた環境によって違う考え方になることがあるというだけ。実はどちらも相手に配慮しようとしているというところはズレていない。なので、「合理的な考えができない」「細やかな相手への配慮ができない」といった感じでお互いをけなし合わずに理解するところから始めなければならない。その上で、初対面のやりとりに対してはどういう配慮が適切かを考えることが大事。チャットコミュニケーションで絵文字使うかどうかとかも同じような話だと思う。

めんどくさいと感じる人もいるかもしれないけれど、何かを前に進めたいのならそんなにコストかかるものでもないしちゃんと考えた方がいい。今回のツイットは、自分があまり考えられていない領域だったのでとても参考になった。

頑張ってみるよ、やれるだけ。頑張ってみてよ、少しだけ。

レビュワーを"憑依"させて Pull Request をセルフレビューする

メンバーと1on1をしていると、「うっかりミスが多くて Pull Request で毎回コメントをもらってから気づくのを何とかしたい」という相談を受けることがある。

まず、そういう認識を持てていることが素晴らしい。課題意識があるのであれば、どう補正していくかを一緒に考えることができる。

自分がオススメしているやり方は、レビューを依頼する前に徹底的にセルフレビューすることである。巷でよくやられている方法ではあるが、どういうやり方かを雑に書いておく。

レビューを依頼する前に レビュワーになりきって 自分の Pull Request を自分でレビューしてみる

  • 頭にレビュワーが思い浮かぶのであれば、その人を "憑依" させるイメージ
  • 「この人はここでこういうコメントしそうだな」と思ったら、 先回りして PR上にコメントしておくか、突っ込まれないようにコードやコードコメントを改善する

タイトルや説明が、レビュワーにとって過不足ない内容になっているかを確認する

  • PRテンプレートをの内容埋められてなかったり、必要な背景が記載されていなかったりしないか
  • Pull Request は自分の作品 というつもりで仕上げることを意識するのが大事
  • 特に不安なポイントなどを書いておくのもオススメ

余計な修正が入っていないか、全体的に確認する

  • デバッグログが残っていたり、試行錯誤中の不要なコードが残っていたりしないか、自分で1~2周よく見てチェックするのが大事
  • Pull Request は自分の作品 なので美しい状態になるよう仕上げきる

コードの意図が分かりづらいところにはセルフコメントを残す

  • レビュワーの立場に立ってみて、なぜそうしているのか引っかかりそうなところには 先回りして コメントを残していく
  • 例えば、共通化しなかった理由、命名で悩んで捨てた選択肢など
  • 仕様がこれでいいのか分かりづらいところには、仕様の該当箇所のリンクを貼って説明しておくとかも
  • 「この実装/テストはこのPRではなく次のPRで対応します」とかも。とにかく 先回り をすることが大事
  • コメントを書いているうちに コードコメントに書いた方がいいな と気づくこともある
  • このセルフコメントは、つけすぎるくらいの方がいい。レビュワーの負担を減らすことは、巡り巡って自分の負担を減らすことになる

意見をほしいところにはセルフコメントを残す

  • 実は不安なところや、もっといい書き方があれば教えてほしいところなどにはその悩みをコメントしておく
  • レビュワーからすると、どういう粒度でどういうコメントをすべきか悩ましいこともあるので、 先回りして 書いてくれていると非常にやりやすい

「自分のコードを確認するのって当たり前じゃない?」と思う人もいるかもしれない。それはそう。大事だよね。

あるいは、「それができれば苦労はしねえ」と思う人もいるかもしれない。それもそう。難しいよね。

それでも自分はセルフレビューをすることをオススメしたい。続けていくと、だんだんとレビュワーを"憑依"できるようになってきて、「ここでツッコミ受けそうだな」とか「これは説明しといた方がよさそうだな」とか先回りして考えられるようになってくる。

最初から全部できなくていい。少しずつ想像力を身につけていくことが大事なのだ。

このセルフレビューは、Pull Request だけではなく資料作成やデータ抽出などあらゆることに応用が効く。うっかりミスをなくせることはもちろん、他者の立場にたって物事を考える訓練にもなるので自分は好きなのだと思う。シャーマン・エンジニアリングしていきましょう。

社内に詳しい人がいない領域のコードを触る時

自分も含めて社内に詳しい人がいない領域のコードをいじることってあるよね。特に歴史の長いサービスだと当時触っていた人が誰もいないとか。仮にいたとしても1年くらい触ってないとほとんど忘れてしまって知らないのと同じような状態になっていたりする。

自分もそういうことが何度もあって、雑にスタンスややってることをまとめておこうと思う。

前提のスタンス

  • 「これを倒したら俺がこの領域で一番詳しい最強になるんや」という気持ちを持ってる
  • 詳しい人がいない状態で属人化とか気にしても仕方ない。まずは自分が詳しくなってから考えるでよい

自分用メモを作る

  • キャッチアップしたことを書き残していく。ドキュメントじゃなくてSlackに垂れ流すでもいい

過去のドキュメント・やりとりを探す

  • 全体像を把握できるドキュメントがないかを探すのを最初にやってる
    • ここは近道はない。とにかく全部集めて全部読む気持ちで臨む
  • Google Drive、ドキュメントサービスを漁りながら、登場人物やキーワードを見つけていく
    • 社内でちょっと知ってそうな人、外部の問い合わせ先などの情報もここで集める
  • Slack を検索するのもめちゃくちゃやる
    • ドキュメントのURLやキーワードで検索する
    • 登場人物で from: @hogehoge のように検索することもある
  • 世に公開されている参考記事やスライドも読み漁る

GitHub のコードを読む

  • キーワードで検索して PR、Issue、コードをとにかく読んでいく
  • 関連するリポジトリをすべてcloneしておくと検索しやすくてよい
  • ドキュメントはあくまで全体像を素早く確認するもので、細かいところはコードを読むしかないしその方が早い
  • コードコメントが少ない場合は、理解したことをコメントに書いてcommitしていくこともある

READMEを書く

  • ここまでくるとだいたい自分が一番詳しくなったという自負が持てるくらいになってる
    • 規模にもよるけれど、これだけに集中できるなら1週間以内を目処としている
    • 実際にちゃんと理解できるにはもっとかかることが多いんだけれど、とりあえずの区切りみたいな感じ
  • 過去の自分が欲しかった内容を GitHub の README やドキュメントにまとめる
    • 自分の理解も深まり、ここで実は認識が間違っていたと気づけることも多い

ざっと書き出すとこんなところだろうか。

もちろん組織的な課題として解決すべきこともあるんだけれど、自分の場合はこういうところを触るときはちょっと美味しいと感じるというかワクワクする。

他の人のやり方も聞いてみたい。

個人コミュニケーションKPI

嫁氏はナチュラルコミュニケーションお化けである。

自分から見れば初対面の相手や複数人の集団とあんなスピードで打ち解け関係を作れるのは才能だとしか思えない。相手について気になったことを深堀って話していくとよいというアドバイスを受けたが、"できる人"のアドバイスで自分にはあまり参考にならなかった。

色々話した結果、才能がなければコミュニケーションを分解して単純なKPIにしてそれを達成しに行くというのがよいという結論にたどり着いた。個人でコミュニケーションを取る際のKPIである。

たとえば、「この懇親会ではこの人に話してこの過去の資料の感想を伝える」とか。そこまでブレイクダウンできていれば自分でもできそうに思えた。できた / できなかったの基準も明確である。

あるいは、「この会議の最初にこの人の以前のこの件についてお礼を言う」とか。これも練習できるレベルまでブレイクダウンできている。「ランチ中にこの人の名前を3回声掛けする」「終わり際に感想とお礼を伝える」とかもそう。ファシリテーションであれば「xxさんに必ず1回話を振ってみる」「最後に2人に感想をはなしてもらう」とか。「Slackで毎日必ず10回emojiリアクションをする」とか「テキストにひとつemojiを入れてみる」みたいなテキストコミュニケーションにも設定できる。

すごく稚拙なようだが、こういうコミュニケーションKPIを決めて準備してから臨むとうまくできなかったとしてもなんだか気分はそこまで落ち込まない。

理想を言えば何も考えなくても自然とコミュニケーションを取れるようになりたいけれど、今は仕組みで型を作って練習して身体に染み込ませていくしかない。それに、こういうのは仕組みで矯正されているうちに自然とできるようになったりするのだ。

これができる時点でコミュニケーションが取れてると言う人もいるかもしれないが、近くに圧倒的に人と話すのがうまい人がいるとそれに憧れてしまうもので、あの域を目指したいなと思ってしまうのである。

マネジメント半年くらいの自分へ

あの頃の俺に伝えたい内容を雑に書く。

本を読め

お前が困ってることはたいてい先人の知恵によって体系化されている。経験から学ぶことも大事だが、歴史から学ぶことを常に継続しろ。

他社のマネージャーと話せ

社内のことで手一杯なのはわかるが、思った以上に視野が狭くなっているぞ。社外の人間と話すとそれに気づくはずだ。緊張を乗り越えて直接声をかけたりイベントに出向いたりしてみるといい。思考が整理され、きっと解決の種が育つ。

引き出しを増やせ

マネジメントは成長がわかりづらい。不安になったらマネジメントの引き出しを増やすことに集中しろ。メンバーへの物事の伝え方、意思決定の前の整理の仕方、やり方は無数にある。何個違うやり方にチャレンジできたかを数えてみるといい。

どこで成果を出すかを決めろ

自分の期待は自分で合わせろ。やること、やらないこと、頼りたいことを明文化しないと全てが自分の責任のようにすれば感じて辛くなるぞ。ただし完璧を目指すな。まずは拙くとも言語化して人に見せろ。

最初が重要

とにかく最初のスタートダッシュが重要。気負う必要はないが、最初はボーナスタイムだと思え。時間が経てば経つほど自分へのプレッシャーはデカくなる。

遅すぎることはない

打ち手が遅くなっても今更なんて思うな。よくあることだ。いつからでも巻き返せる。明日からではない。今から始めろ。もう遅いなんて思うな。

ボールを持つな

自分にWIP制限をかけろ。自分でなくてもいいものは速攻でパスしろ。まわりに遠慮するな。遅くなって後でパスするよりマシだ。どうしてもボールを持ってしまうなら一度立ち止まってまわりと期待合わせをしろ。

いつの成果を出すかを意識しろ

わかりやすい短期の成果を追いすぎるな。個人や短期で成果を出せることはお前もまわりもわかってるから焦るな。結果として短期の成果をとるのはいい。1年半くらいを意識しつついつの成果を取るかを選択しろ。

変化を待つな

専門家はいない。俺たちしかいないんだ。何かがいつの間にかよくなることを心の底で期待していないか。そんなことは起きない。直接的でも間接的でも自分が動くべきだ。そのほうが気持ちも楽になる。

伝えてない期待をするな

相手を信じて期待するのはいい。ただし、伝えてない期待が満たせなかったときに憤るな。マネジメントは期待合わせが肝だ。


以上だ。幸運を祈る。エル・プサイ・コングルゥ。

言い回しの引き出しを増やす

先日他社の方複数人でオフラインで話していた時に、自分が何かを発言しようとしたタイミングで他の人が話をしてまあいっかとやめたことがあった。

その時 「私今konifarさんがちょっと言いかけていたことがすごく気になってるんですけど」と拾ってくれて、これはすごいと思ったので雑に書いておく。

自分だったら「今何か言いかけましたか?」みたいな感じで促していたと思う。それをあくまで「私が気になる」というスタンスで聞くことで、相手も気をつかわなくてもよい表現になっていたのだった。こういう言い回しは、普段からまわりを見て気遣いをしていないとなかなかパッと出てくるものではない。

こういうよいと思った言い回しは、気づくごとにストックしておいて引き出しを増やしておくとよい。たとえば申しわけなさそうに「今ちょっといいですか」と聞かれた時に一言目を「もちろんです」と返したり、「自分がよくわかっていないので教えてほしいんですけど」のような枕詞を使ったり、物事を前に進めたり誰かの意見を引き出したりするのに便利な言い回しはいっぱいある。

あまり白々しいと気持ち悪く感じるかもしれない。しかし何かをリードした経験のある人はなんとなくわかると思うが、こういうのは何回も使っていくうちに振る舞いとして定着してきて様になってくる。自分がよいと思ったら真似していくほうがいい。もちろん相手にもシチュエーションにもよる。だからこそ大事なのは引き出しを増やすことなのだ。

コミュニケーションスキルの熟達度合いのひとつは、こういう細かい引き出しをいくつ持てるかということなのかもしれない。