質問や議論をする際につけるPrefix
確認
相談
報告
意図
仮定
推測
解釈
事実
提案
意見
注意
懸念
認識
以前、現在、今後(過去や未来について)
前提の共有
この会の目的は
背景・経緯
具体例
補足
メリット
デメリット
転用
途中経過の共有・進捗の共有
この会では3つの議題があります。
よく使います。
メリットは以下の通り。
- 相手の頭の中に「これからどんな話をするか、会話の方向性」を伝えられるので、相手の思考リソースを割かせない。
- Prefixで絞ることで、相手に発言の意図を伝えられるため、議論の際にこちらの提案に悪意がないことを伝えられる。これは、不要な反発を防ぐことができる上に、長期的に良好な人間関係を構築することができて便利。
文章・口語の中で日本語を扱う
前提を共有する
- 主語を明確にする
- こそあど言葉を使わない(「これ・それ・あれ・どれ」など)
- 相手の理解度を都度確認する(ここまで大丈夫ですか？など)
- 先述の「質問や議論をする際につけるPrefix」で記載したメタ概念を都度使う
基本的に自分の常識と相手の常識は違うので、そこの認識合わせを行うつもりで。
レビュー
MUST,IMO,NITS
MUST
- 日本語訳で「〜しなければならない」
- これコード動かないんじゃね？系を記載(こっちが多め)
- レビューコメントを残すにあたり、相手のコードのA案より、自分の修正案がB案の方が技術的に適切である明確な理由を説明できる場合に使うことが多いです。(ただ、大体の場合宗派があるので、この文の動機で使用する場合は新入社員や未経験エンジニアなどに限られるかも？よって、あまり出番はない。)
- 設計ミスってる時もMUSTになりますが、その場合そもそもMUSTの次元ではなく、手戻りなので、大きいタスクを行う際は小さく相談フェーズを挟むといいかもです。
IMO
- in my opinionで、日本語訳で「私の意見では」
- 個人的にはよく使います
- 「正直どっちでも動くけど、多分こっちのがいいんじゃね？」みたいな、私の主観的目線で、80点のコードを85点に、50点のコードを55点に変更する依頼をする場合に重宝してます。
- IMOをなくすと、「こう変更すべきだ。お前は間違ってる」という人格否定のニュアンスで相手がレビューを受け取る恐れがあります。
- レビューを受ける側のメンタルモデルとして「成果物と個人の人格を分離する」ことが重要ですが、できる人はそう多くありません。特に日本人は幼少期にディベートの経験が少ないことから、議論での結果を人格の評価と結びつけがちです。
- 自分がレビューを受ける時は成果物と個人の人格を分離するよう努めていますが、「他人がそうとは限らない。よって相手のメンタルモデル次第では長期的な人間関係に影響する」ので、なるべくIMOはつけてレビューするようにしています。
NITS
- nitpickで「些細な指摘（重箱の隅をつつくの意味）」
- 相手の不意のミスや当たり前のことについて提案の意味を込めて使うことが多いです。NITSに限らずですが、基本的に下から謙遜ムーブでレビューコメントをすることが多いです。
- NITS的な指摘をする場合、prefixなしで指摘をすると「こんな当たり前なことできてないの？」というニュアンスを含んでしまいます。これは知性への脅しになります。エンジニアはやりがちですが、これは長期的な人間関係に影響するかと思います。
WANT
- 「私は〜したい」なので、要望を表す
- 提案ベース、僭越ながら相手に依頼をお願いしてもいいですか？のような文脈で使用
- 相手の成果物は100%であることを前提に、面倒なことを追加で実装いただく際に使用
- こちらが下から謙りつつ相手に提案ができるため便利。相手のプライドを毀損しない。