チームのコミュニケーションについて～強いチームを作るには（後編）。Developers Summit 2016

業務で行われるソフトウェア開発プロジェクトのほとんどすべては、何らかのチームによって行われています。そしてそのプロジェクトが成功するか失敗するかを左右する大きな要因が、技術力よりも人間系にあることはよく指摘されることです。

では、その人間系に注目して強いチームを作るにはどうすればよいのか、そのヒントを多数紹介したセッション「強いチームのつくり方」が、2月19日に行われたイベントDeveloper Summit 2016（通称デブサミ）で行われました。この記事では、そのセッションの内容を前編、中編、後編の3本の記事で紹介します。

いまお読みの記事は後編です。

メンバーの採用

メンバーを採用するときには、一緒に働くことになる人が採用の判断をするほうがいいです。ただ、本質的にはたった数回のインタビューではお互いのことはわからないので、外資系では5回とか10回インタビューすることもあります。

採用する人に対する期待値、仕事の内容を明確にしたほうがいいですね。

文化の適合性も大事です。チームが壊れない人を採用しないといけないので、カラーに合う、文化に合う人を採用する。

人が足りないときにすぐ採用したくなりますが、我慢してチームの平均以上の人を採用し続けると、ゆるやかにチームの能力が上がっていく、ということもあります。

そして良い人を落とすよりも悪い人を入れてしまう方がチームのダメージが大きいので、よい人を落としたらあきらめると。

退職について。

自分のチームから誰かが辞めるときには、理由をできるだけ生々しく聞いた方がいい。それが改善できることなら、同じ理由で辞める人を次からは防げます。

ちなみに、「アメリカ海軍に学ぶ『最強チーム』の作り方」によると、自分たちがやりたいやり方でやらせてもらえない、尊重されていないと感じるのが、辞めてしまう理由の多くで、給与は5番目なんですね。

組織の構造はアーキテクチャに影響を与える

なんでテクノロジーのイベントで組織の話をしているのかというと、組織構造はアーキテクチャに影響を与えるからです。

昨今はマイクロサービスが注目されていますが、マイクロサービスを実現するには組織構造がマイクロサービスに適合していないとできないんです。

自分のチームで開発してデプロイして運用して、というのができないと、分業が増えてオーバーヘッドが増えるだけです。

新しい技術や考え方を使うときには、自分のチームに合うかどうかを考えないといけないですと。

チームのコミュニケーションの話

コミュニケーションは手段であって目的じゃないんですね。目的はミッションやビジョン、ゴール、期待をチームで共有すること。進捗や課題の把握です。

このあたりをはき違えてコミュニケーションをよくしても意味がなくて、なんのために改善するかを共有することが必要です。

コミュニケーションには「同期型コミュニケーション」と「非同期型コミュニケーション」の2種類があります。

同期型は時間を共有して行います。多くの人が関係することを集中してやるのに向いています。計画作りとか障害対策会議とかはこちらがいい。

ただ、みんなの時間を等しく消費する、みんながやっていることを止めるという問題がある。

一方で非同期型は異なるタイミングでコミュニケーションができるので、仕事の割り込みになりにくい。

ただし、コミュニケーションのパスが人数が増えるごとに加速度的に増える。Slackの会話が延々終わらない、なてことが起きます。

それから意図したことが伝わったかどうか、相手の顔色が分からない、といったこともあります。

同期型と非同期型は、無駄がないように使い分ける必要があります。

チームの外部とのコミュニケーション

チームの外部とコミュニケーションをするときには、コンテキストややり方が共有できていない前提でコミュニケーションしなければいけません。

運用チームの仕事が遅いとか、インフラをなかなか用意してくれないとか、そういうときには組織構造が問題です。それからチームのやり方を見える化する。こういうやり方をしているので乗ってください、という風にするとうまく行きがちです。

ちなみにAmazon.comでは、コミュニケーションをAPIにしました。

Amazon.comでもクリスマスの時にはサーバを増やさなくちゃ行けないので、昔はインフラ部門にメールでお願いをしていました。そこにすごくコミュニケーションのオーバーヘッドがあったので、それをAPIに置き換えたんですね。

コミュニケーションをそのままにしておく必要はなくて、APIやツールに置き換えるという手もあります。

評価とフィードバック

最後にお話しするのは評価とフィードバックです。

評価の基本原則は、価値観、優先度、期待値、求める成果を先に合意し、後出しじゃんけんを避けるということ。

そして定量評価、定性評価を組み合わせるのがベストです。

定量評価だけでやると、いかさまをします。例えばコミット数で評価すると言われたら、僕なら1行ごとにコミットする、もしくはボットを作ります。

定量評価だけで評価すると倫理観が崩壊するんですね。

かといって定性評価に寄せすぎると好き嫌いが出過ぎるので、組み合わせるのがよいです。

ゴールを設定するのは仕事を上手くすることが目的であって、評価だけにあるのではないので、1年に1回とかじゃなくてもっと頻繁にやる。1カ月に1回とか3カ月に1回とか、ゴールに対してどういう状態で、いまどんな問題を抱えているのか確認する。

そのときによく使うのが1対1のピアレビューです。

フィードバックでは、いいことだけではなく、時にはネガティブなことも必要。ただ、個人攻撃と取られないようなものの言い方にする。相手からフィードバックをもらったときも、自分のやり方についてアドバイスをもらったと考える。

そのためにはやり方も重要です。密室で正面を向いてやると攻めている感じになります。

あなたvsわたしではなく、私たちvs問題という形にする。「お前の書いた仕様書は腐ってる」という言い方は個人攻撃になるので「私はあなたの仕様書が分からないので、説明してくれ」というと受け取り方も変わる、私を主人公にする（I message）のがいいと思います。

というわけで僕の話はここまでです。

（公開されたスライド）

Developers Summit 2016

• 5カ月でAngularJSとTypeScriptでSPAを開発。その技術の選択理由と開発過程は？（前編） Developers Summit 2016
• 強いチームを作るには時間がかかる～強いチームのつくり方（前編）。Developers Summit 2016
• レイテンシに負けないプロトコルとして登場したHTTP/2～奥一穂氏による「HTTPとサーバ技術の最新動向」（前編）。Developers Summit 2016
• Yahoo! Japanがアジャイル開発の採用と改善で現場から変えた“サービスの作り方”（前編）。Developers Summit 2016
• エンジニアを成長させるためのマネジメントと組織づくりとは～アドテクを中心とする組織の取り組みの例。Developers Summit 2016