チーム開発で暗黙的に行なわれている批評というプロセス

Pull Request を通して行うコミュニケーションに「レビュー」という言葉がつくことに違和感を感じるときがあります。

Wikipediaコードレビューを引くと、「見過ごされた誤りを検出・修正することを目的として体系的な検査(査読)を行う作業 」とあります。もちろん、これを目的として行うやり取りもあるのですが、その手前の「コードや設計について議論し、もっと良い判断を探る」ために行うコミュニケーションもあると思います。むしろ、そちらのコミュニケーションをやりやすいことが、Pull Request というプラットフォームが提供する価値なのではと感じることが多いのが、違和感の元かもしれません。

2015年6月に O'Reilly から出版された「Discussing Design: Improving Communication and Collaboration through Critique」という書籍があります。ぼくは、この書籍に書かれていることが、すなわち Pull Request を通して行っている活動の「レビュー」ではない側面なのだと感じています。

Discussing Design: Improving Communication and Collaboration through Critique」は、デザインを洗練させるための批評(Critique)というプロセスを扱った書籍です。本書における批評とは「チームでデザインを行う際に、目的に照らしてデザインを分析しフィードバックするプロセス」のことで、本書にはこのプロセスを行う際に大切なことが、とてもよく整理されまとまっています。

Discussing Design: Improving Communication and Collaboration through Critique

Discussing Design: Improving Communication and Collaboration through Critique

具体的に挙げると、

  • 良いフィードバック(批評)とは何か
  • フィードバックを与える側が気をつけるべきこと
  • フィードバックを受ける側が気をつけるべきこと
  • より良いフィードバックのためのファシリテーションの仕方

などといった内容が書かれています。

たとえば、だいじだなと思ったことの中には次のようなことがあります。

  • フィードバックとは、感情を押し付けるためのものでも、説明のない指示を与えることでもなく、受け手が成果物をより良くするために必要な情報をきちんと届けること
  • 「今はデザインプロセスのどの段階ですか?」「どうしたらいちばんあなたの役に立てますか?」という情報をもとにフィードバックの内容を調整する
  • フィードバックを与える際は、なぜそんな反応をしたくなったのか、感情をいだいたのかを一旦深く潜ってかんがえることが大事
  • フィードバックに問題解決を含めないこと。議論の分析的な焦点が損なわれ、ずれてしないかねないので、問題解決をしてはいけない
  • フィードバックをうまく与える/受けるには練習が必要

「Discussing Design」( デザインについての議論)、Pull Request を通して行われているやりとりは、まさにこのことだと思います。「批評」という用語自体がぼくらの業界に馴染むかどうかはわかりませんが、本書にあるデザインのプロセス/考え方は、開発者の人にも広く共有されると良いものだと考えます。

気がついたら本書の翻訳書が「みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド」というタイトルでBNNから出版されていて、とても読みやすい訳となっていました。他人のコードや設計にフィードバックする機会のある人、フィードバックを受ける機会のある人は、ぜひ一度読んでおくことをお勧めします。

みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド

みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド