リーダーシップと権限委譲の仕方～強いチームのつくり方（中編）。Developers Summit 2016

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

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

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

リーダーシップの原則

チームの初期にやらなければならないのは、合意とアコモデーション。

まずは「ゴール」、最終的に何を実現するかをみんなで合意しようと。

次は「目標」ですね。短期的にはどこに到達したいか。それから「価値観」。こういうところに価値をおいて、ここは譲れません、という価値観。

ただ、最初に人が集まった段階で、いきなりこんな合意はできないと思うんですね。なのでまず最初に何をするか。相手のことをよく知ろう、ということには合意します。

現時点ではやり方に合意できないし、相手の意見にも合意していないけど、合意していないことには合意しようと。

とはいえ、一緒に考え続けよう、ということにも合意する。

ここからスタートですね。初期であるほどこういうのが必要になってくる。

でもいきなり集められて、こういうリーダーシップをとるのは難しいですよね。「僕はただの社員だから、リーダーシップをとるのはマネージャがやればいいじゃないか」と。

でも、例えばAmazon.comだと「リーダーシップの原則」というのがあって、平社員も管理職も関係なく、社員全員がリーダーですという言い方になっているんですね。

りーだーはまず違うと思ったらちゃんと言えと。大変だけど言えと。で、リーダーは信念を持って容易に妥協しません。

でもいざ決定がなされたら全面的にコミットしますと。あとから「あのとき決まっちゃったけど、オレは最初から反対だったんだ」と言って、やらないのはナシだと。

フィードバックをしないと共通理解は得られない

初期の段階で多数決でなにかを決めると、いつも少数派に回る人は反感を持つことがあるので、これはみんなにとってリスキーです。マネージャーがこうやれというのもリスクですが。

じゃあどうするか。コミュニケーションのツールっぽいものを使うとうまく行きやすいです。ここでは5本指を使って意見を聞くんです。

ぐーの人は「0」。この時点で決定を行うこと自体に反対。

指を1本挙げたら、重大な問題があるのでこのまま決定したらオレがぶっつぶすと。

2本はもっと話し合おう。3本は、まあいいよと。

4本あげるといいね、協力します。5本あげると、素晴らしいので自分がリーダーになりますと。

コミュニケーションの中でこういう意見を聞いて意思決定するとトラブルが起きにくい。 これはアジャイル開発で使う「プランニングポーカー」もそうで、まずそれぞれの見積もりを「せーの」で出して、そのあと意見を聞いてと、意見のフィードバックをして、もういちどあらためてカードを出す。

フィードバックをしないと共通理解は得られません。イエス、ノーだけでは共通理解は得られません。

チームの責任は「説明責任」と「改善責任」

チームの大事な責任はいろいろあると思います。

「説明責任」は、聞かれたときに合理的な説明をする。

「改善責任」は、つねにチームをよくする。ということです。完成責任というのもありそうですが、全力を出すことは責任を持てても無理なときは無理なので、全力を尽くす責任は持てても、完成させる責任を持つのはかなり難しいです。

チームのスキルを見える化する

チームにはスキルが必要です。チームにどんなスキルがあるのか、オススメはスキルを見える化することです。

見える化すると、チームにとって得意なスキルやリスクが見えてきます。

これを2週間とか1カ月に1回更新して、メンバー同士で「これができるようになりました」とか「次はこれを学びます」という会話をしてマップを埋めていくと。

ただし、こういうのを作るとマネージャが「人事評価に使おう」と言い出します。そう言った瞬間に、みんなが自分のスキルに二重丸を付けだしてマップが使えなくなってしまうので、これは人事評価には使わないで、チームのために使う。

それから、メンバーの中には「自分は勉強したくないし、ワンショットで参加しているだけなのでこのスキルだけあればいいでしょ」という人がいるかもしれません。

そういう人をやる気にするのは個人の価値観なので難しいのですが、僕がよく言うのは「変化に対応しないことを選ぶなら、自分が生きるか死ぬかは他人がコントロールしますよ、それでもいいんですか。会社は守ってくれませんよ」って。

自分を守るために、学ぶことで自分にスキルを与えると。

で、スキルマップの続きですが、マップを見ると、チームの仕事の中でこの人にしかできない仕事というのがあるかもしれません。そのとき、その人がいなかったらどういう問題が起きるか考えましょう。

その問題が許容できるんだったらほっとけばいい。それが許容できないんだったら、すでになにかがおかしい。「プロジェクトリーダーが倒れたら、このプロジェクトは終了です」というのは、なにかが間違っているわけですね。

それを避けるためには、基本的にはその人しか知らない情報をなくしておく。そのためにチームの中で情報を見える化しましょうと。

でも人には自分の仕事を守りたいという欲求があって、多くの人が自分の仕事を囲いたくなります。でも外で役にたたないものは抱え込んで守る意味はないので、そういうのはなくしていった方がいいです。

メンバーの成熟度によってリーダーシップの形態が変わる

組織の成長過程には段階があります。「SL理論」というのがあって、メンバーの成熟度によってリーダーシップの形態が変わる。

「S1」は、リーダーが意思決定して、これをやってくださいと指示します。

「S2」は説得型で、リーダーが考えを説明し、疑問に答える。

「S3」はメンバーの意見を聞き、意思決定を支援してもらう。

「S4」は委任型。メンバーに任せようというもの。

もちろん全部を任せるわけではなく、委譲にも段階があります。これは「マネジメント3.0」の本にあるのですが、7段階あります。

決めなくてはいけないことを一覧にしてみて、どこまで委譲できるかと考えて委譲していく。いきなり任せるのは委譲ではなく丸投げですね。

≫後編に続きます。後編のテーマは「チームのコミュニケーションについて」です。

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