Slack などのチャットツールや GitHub の issue や プルリクエストで誰かに対して何らかの指摘をする機会があると思います。
「これどう？」と見せられた成果物に対して満足いかず、何らかの修正をお願いするときなどです。
人に何かを指摘するのは面と向かった対話でも難しいのですが、文字ベースのチャットだと更に難しいです。
- 文字だと感情が正確に伝わらない
- この指摘の大事さ(必ずやってほしいのか、できたらやってほしいのか)など
- 会話と違ってやり取りに時間がかかるのでフラストレーションが溜まる
といった問題があるためです。
面と向かった対話に切り替えることが可能な環境であれば、文字ベースでのやり取りが難しいなと思った時点で切り替えるのが良いと思います。
しかし同じ空間にいない場合など文字ベースでコミュニケーションを取り続けなくてはならない場面もあります。
そのような場合にできるだけコミュニケーションを円滑にするために僕が気をつけていることを書きたいと思います。
駄目な指摘
まず、僕が考える駄目な指摘の仕方を紹介したいと思います。
少なくとも僕が同様の指摘をされたら反応に困ります。
自分が「これどう？」と誰かにレビューをお願いしたとします。
コードレビューでもいいし、どっかに載せるドキュメントでもいいです。
その時に
- なんかこの部分、どうしたら良いのか分からないけどしっくり来ないな〜。直してもらえる？
- 全然駄目だから直しといた (全部書き換わってる)
と言った指摘を貰うと反応に困ります。
まず 1 についてですが、結局何がどのように駄目なのか指摘が貰えていないのではっきり言ってこの指摘には意味が無いです。
恐らくレビュワーの力不足でレビューされるものに何らかの問題はあるのですが、その問題点を正確に見抜けていない or 対処方法が分からない為にふわふわした指摘になっています。
この場合、レビュワーと更に話し合って問題点や修正方法を明確にする必要があります。
その結果、どうでも良い指摘という事が分かればこの指摘は無視してもよいことになります(勝手に無視しちゃ駄目)。
次に 2 についてですが、勝手に全部直されるとやる気が無くなります。直す楽しみは残しておいてください(全部直す必要がある時もありますが、それについては最後の方に)。
可能であれば、何がどのように駄目なのか、またどのように修正すべきなのかをコメントしてもらいたいです。
そうすれば、明らかな問題があったのか、それともレビュワーの好みに反していただけなのかが分かります。
また、指摘を貰って修正を行うことで学習することができます。恐らく直してもらったコードをコピペするだけではまた次も同じ問題を発生させてしまいます。
レビュワーの好みに反していただけなら修正する必要はないと思いますが、その辺は大人の事情だと思うのでよしなにお願いします。
良い指摘
先の悪い指摘を踏まえて、良い指摘なのはどのようなものか書きたいと思います。
ざっくりとですがそれはこのようなものです。
- 元のやつを踏襲しつつ 適切 に直してあるやつ
- XXな理由でYYYの部分がマズいと思ったので直したバージョンを書いてみました
より抽象的に書くと
- 直し過ぎない
- 問題点や修正方法を明確にする
- 例示する
といったことです。
特に 3 の 例示する というのは非常に重要な事で、この例を作る段階で問題点などが自分の中で整理されます。
また問題を分かりやすく説明するために問題点を抽象化したり一般化することで、指摘の内容も分かりやすくなります。
さらに、一般化された問題に対する修正の例を示すことで、 1 の 直し過ぎない という部分も満たすことができ、レビューされた人に対して考える余地を残すことができます。
気をつけること
最後に、指摘する場合に忘れてはいけない大事なことを紹介します。
それは ドレイファスモデル と言われるものです。
ググると沢山の記事が出てきますが、僕はこの概念をオライリーのリファクタリング・ウェットウェアという本で知りました。
素晴らしいことにちょうどその本のドレイファスモデルの章が pdf でサンプルとして公開されているので気になる方はぜひ読んでみてください。
ドレイファスモデルとは人が技能を習得する過程をモデル化したもので初心者から達人のレベルまで以下の5段階をたどると説明したものです。
先のオライリーのリファクタリング・ウェットウェアで説明されている各段階の特性を括弧内に引用させていただきます。
- 初心者 (レシピが必要)
- 中級者 (全体像を見たがらない)
- 上級者 (問題解決ができる)
- 熟練者 (自己補正が可能)
- 達人 (直感で動く)
これ以降、上級者以上の人たちは話題にしません。 なぜならば、大抵の人は中級者で人生が終わるからです。
では初心者と中級者に着目して話を戻しましょう。
この両者にはそれぞれ別のアプローチで指摘をする必要があります。
初心者に対する指摘
まず初心者の場合です。
この場合、先ほど悪い例として説明した 全部直してみた のような指摘方法は適切な方法です。
初心者には問題を一般化して説明しても理解することはできません。
それよりもこの場合は、こうするのが正解というルールを教えてあげましょう。
レシピが必要 と言われるように沢山のレシピを教え込みましょう。
アレンジするのはまだ後からでいいです。
- 変数名・関数名はこうする
- 大きすぎる関数は分割する
など、基本的なことを教えましょう。
プログラム全体の設計に関わる指摘が必要な場合は、そもそもそのような作業を初心者にやらせてはいけません(圧倒的成長の為とか言わない)。
指摘をしてもそもそも理解ができないので無駄です。それよりもグッドパーツを沢山増やすことに集中しましょう。
そうすれば恐らく1年以内に初心者をぬけ出すことができます。
訳の分からないふわふわとした指摘で頭を悩ませて1年を過ごすと何も得られないまま初心者止まりになってしまうので気をつけてください。
中級者に対する指摘
次は中級者に対する場合です。
それなりに経験を積んでいるので一般化した問題も少し考えると理解することができるような段階です。
しかし、初心者から脱したばかりの人の場合、ルールがあることに慣れてしまっているので答えの発見に急ぎがちです。
こういった人に指摘をする場合は先に紹介した 良い指摘 の様な指摘が適しています。
というか実はこの記事は中級者に対して書いたようなものなのですが、初心者の場合には別のアプローチが必要だなと思ったのでこの部分を書いています。
おわり
ちょっと長くなりましたが、こんなことを気をつけながらコミュニケーションしています。
相手の技量を把握したうえで指摘を行うのは非常に重要です。
相手の技量に合わない指摘をすると意味のないものになってしまい、時間の無駄です。
相手のことをよく理解するためにも普段からコミュニケーションを取って親睦を深めるのがプロジェクト成功の鍵だと思います。