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

2016年2月22日

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

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

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

fig

リーダーシップの原則

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

fig

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

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

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

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

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

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

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

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

fig

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

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

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

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

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

fig

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

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

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

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

fig

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

fig

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

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

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

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

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

fig

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

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

fig

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

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

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

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

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

fig

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

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

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

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

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

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

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

fig

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

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

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

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

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

fig

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

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

Developers Summit 2016

このエントリーをはてなブックマークに追加
follow us in feedly

タグ : 働き方



≫次の記事
チームのコミュニケーションについて~強いチームを作るには(後編)。Developers Summit 2016
≪前の記事
強いチームを作るには時間がかかる~強いチームのつくり方(前編)。Developers Summit 2016

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed



Publickey 最新記事 10本

Publickey Topics 最新記事 10本


PR - Books


fig

fig

fig

fig



blog comments powered by Disqus