開発チームの信頼や協調がプロダクトに与える影響

このエントリを書こうと思ったのは二つの記事を読んだことがきっかけです。一つはGoogle VenturesのDaniel Burka氏の"Don't let team politics get in the way of shipping great design"（安藤幸央氏の翻訳から知りました）です。この記事は要素技術に長けていても他のチームメンバがプロダクトにそれを活かしてくれるとは限らないという段落からはじまります。Burka氏はWebを通じて提供されるサービスのユーザインタフェースのデザインを手がけているようで、要素技術としてPhotoshopの使い方や色に関する理論やキャッチコピーが挙げられています。Burka氏の記事の残りの部分では、チームの他のメンバの考えを知ろうとすることや他のメンバに信頼されるよう自分の主張の裏付けを持っておくことを勧めています。

この話はデザイナに限定される話ではないと思います。複数メンバで構成されるチームでソフトウェアを開発するとメンバ間の信頼や協調がプロダクト（最終成果物）に与える影響を感じることがあります。

本ブログエントリを書くきっかけとなった記事のもう一つがこのことを説明していると感じました。Simon Sinek氏のTEDプレゼンテーションの翻訳記事です(元のプレゼンテーションは動画"Why good leaders make you feel safe"にあります)。このプレゼンテーションでは人類が持っている社会性の一つである信頼と協調に関して言及されています。ここでは、ある航空会社の乗務員とSinek氏とのやりとりが紹介されています。乗務員はSinek氏に冷たい接客をします。乗務員が自分は何も保証されておらず、乗客(Sinek氏)を規則に従わせなければクビになるかもしれない考えていると話し、乗客に口うるさく指示を出した理由であると説明します。Sinek氏は乗務員と上司の間に信頼関係ができていないことが乗客に十分なサービスを提供できない原因であると分析しています。

ソフトウェア開発でも、不具合の予想がしづらく（ワナが多い）配慮が必要な場合や新しい取組みで不明な点が多い場合にあてはまるでしょう。信頼関係がなければ、自分の範囲を守ることに必死で、他のメンバが担当する細かい部分まで気がまわらなかったり、まわったとしても指摘しないということも多いように思います。「また何か文句言ってきている。偉そうに」「自分のところさえやっておけば大丈夫。他のメンバのところを考える義理はない」「こう言ったら自分の評価が下がるかも。自分の仕事が増えるかもしれないし．．」「自分が困っているときには助けてくれなかったアイツが困っていても助ける必要はない」といった考えも起こる等して、洗練につながる考えを思いついたりそれを伝えたりする機会は減るでしょう。こうした考えにはプロとしての意識が欠けていて、信頼や協調以前の問題ではあるのですが．．普段であれば発揮できるプロ意識もスケジュールが厳しくなる等して普段とは少し違う状況に置かれると無視できなくなってくるのではないかと思います。

コードレビューにそうしたチームの信頼や協調を深める役割も持たせる動きが出てきています。単に欠陥を指摘するだけでなく、チームメンバの活動の透明性をあげたり、よい点を指摘したり、代替案を提示したりすることでメンバ間の信頼を高めたり協調を促します。構成管理ツールやコラボレーションツールに定型的なレビュー管理の一部を任せることを前提に、信頼や協調を培う場とするような特徴を持つコードレビューをモダンコードレビューと呼んで従来の（コード）レビューと区別する動きもあります。

2015年3月2日に東京で開催されるRegional Scrum Gathering Tokyo 2015 Day 3でモダンコードレビューの紹介をする機会をいただきました。コードレビューに限定しない一般的なレビューの課題と対策を紹介し、モダンコードレビューの動向も紹介します。セッションのタイトルは「レビューの課題と対策、モダンコードレビューの動向」です。申込み方法等詳細はこちら。3日間開催されるイベントで様々なセッションが予定されています。