💭

仕事で大切にしている考え

2022/05/06に公開

メモ

work

idea

個人的なメモを兼ねて。まだまだWIP

コミュニケーション

自分と相手の認知を認知する

まず、人はそれぞれ認知フレームが異なり、自分も何かしらの認知フレームに囚われていて、バイアスがかかっているということを認知した上でコミュニケーション（情報伝達/意思疎通）を行なっているという大前提を忘れてはいけない。

有名なこの書籍でも語られている内容
エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング

「コミュニケーション」という言葉を履き違えないこと

あと、大事にしたいのは、「コミュニケーション」というのは、情報伝達や意思疎通の意味であって、「わいわい」みたいな意味ではないということ。
日本の組織だとここの履き違えがよく起こっているように感じる。

心理的安全性がよくバズワードとして使われるが、心理的安全性が高いというのはいわゆる「わいわい」しているという状況ではなく、ちょうど下に貼ったツイートのような、状態を指している。

よく、「コミュニケーションを取って解決して」みたいなことが言われるシチュエーションがあるが、こういう場合は、AさんとBさんの間で情報伝達が正しく行われなかった、ということなので、なぜ正しく行われなかったのか、AさんとBさんの認知にズレがあるのではないか、という思考で、その認知のズレを認知し、正しく情報伝達がされるようにしている。
絶対に感情的になってはならないし、常に冷静に物事を見る力が必要である。

ドキュメンテーション

出処を記す

「ソースは？」
PoCの検証とか調査系は必ず書くし、思考の過程も残しておくことが望ましい。
過程が残っていると、もし方向修正があったときに、「なぜ」を振り返れる。
また、レビューする際も流れが掴みやすくいい議論になりやすい。

正しい語を使うこと

たとえば、
× Github, ElasticSearch, Opensearch
○ GitHub, Elasticsearch, OpenSearch

数字は半角数字を常に使っていること

全角数字を使う人に大事なコードはあまり任せられない・・。怖すぎる
こういうことなんだろうなと思っている

なるべくコミュニケーションコストを減らすべくドキュメンテーションしていく

たとえば、とある技術で社内に詳しい人が私くらいしかいなかった場合、そのままにしておくとあらゆる質問が私宛にメンションされる。
そこでドキュメントに仕事させる。
2回か3回同じことが聞かれたらもうドキュメント化した方がいいでしょう。

ドキュメントをみんなで育てる

ドキュメントのオーナーシップを組織で持つという意識を根付かせる。
明らかに訂正した方がいい内容といちいち Auther に許可を取らない。
また、ドキュメントの編集をレビューできる機能があると、 Auther 以外の編集する際の心理的安全性が引き上がると思う。誰でも編集できる環境だと Auther 以外誰も編集しないという経験をした。
そういう意味で GitHub で管理された README は編集リクエストにレビューを通す仕組みが自動的に備わり好きだが、主流のドキュメンテーションツールでその機能があるものが少なくてなかなか悩みものである。

MTG

カレンダーの予定にアジェンダやMTGのゴールなどがわかる記事のリンクなど貼る。詳細をちゃんと書く

MTGが始まって頭出しするのではなく、事前に資料を読んだ上で各々意見を持った上でMTGに参加している状態を普通にしたい。
説明ではなく議論にみんなの時間を使うべき。リモートになったのもあって、関係者が同期的に集まる時間というのは超貴重。めちゃくちゃ大切にすべき。資料の読み込みなんかに使っていい時間じゃない。同時に、参加者は事前共有された資料を事前に理解して自分の意見を持っておくというのが大切になる。
聞くだけなら録画を後で展開するだけで良くて、同期的なその場に参加する必要はない。

Google Calendarのステータスで出席/欠席を表明する。会議が始まってから「〇〇さん今日不参加？」とかいう不毛な会話をしない

いらないことでMTGの時間を使わないようにしましょう。

開始と終了時間は守る

誰か必須参加者が参加に遅れると他の参加者の時間給分のロスが単純に発生していることになる。
ジェフベゾスを1分待たせたらあなたは約3300万円の利益を生まなければペイできない。

ツール系

GitHub

基本的にこんな感じでSlackと連携している。

Review Requestはリアルタイムで受け取るのと、毎朝レビューアサインされているPRを表示するようにしている。
PRのレビューは他人の作業をブロックしてしまう優先度の高いタスクなので、Review Requestが飛んできたらなるべく早く見るようにしている。
逆に言うと、まだドラフトの状態なのにPRをOpenしてレビュアーを自動アサインさせられると、とってもノイズになるためPRのステータスはちゃんとしてほしい。
ステータスという意味では、PRの再レビューは、Re-request Reviewという機能がGitHubにあるから、それを使ってほしい。でないと再度見ていい状態なのか私はわからない。

また、コードレビューの方針は基本的にこれに同意でほぼ沿った動きを取ることが多い

基本的に集中力を要するタスクをしている時以外はレビュー依頼が飛んだらそれが最優先タスクになっている。

Google Calendar

主にGoogle Calendar上で完結させている。
たとえば、予定を作って、Slackで「予定登録しましたので、かくかくしかじか」みたいなのはあまりやりたくない。
予定の招待などの通知情報はリアルタイムで受け取っているのと毎朝今日の予定を出力させている。

新しい時間の提案などの機能も充実してきたし、Google Calendarで大体済むし、参加の可否の表明もCalendar上でちゃんとしてほしい。
基本的にそのMTGの必須人物でもない限り開始時点でいなくても無視して進行する。時間がもったい無い。

また、予定のdescriptionに資料やアジェンダなどの情報はほぼ必須。これがないMTGは出る気が40％ほど落ちる。