- 会員限定
- 2016/03/01 掲載
イエス、ノーだけでは共通理解は得られない リーダーシップと権限委譲の仕方
強いチームのつくり方（中編）
記事をお気に入りリストに登録することができます。
業務で行われるソフトウェア開発プロジェクトのほとんどすべては、何らかのチームによって行われています。そしてそのプロジェクトが成功するか失敗するかを左右する大きな要因が、技術力よりも人間系にあることはよく指摘されることです。では、その人間系に注目して強いチームを作るにはどうすればよいのか、そのヒントを多数紹介したセッション「強いチームのつくり方」が、2月19日に行われたイベントDeveloper Summit 2016（通称デブサミ）で行われました。この記事では、そのセッションの内容を前編、中編、後編の3本の記事で紹介します。いまお読みの記事は中編です。
ITジャーナリスト／Publickeyブロガー。大学でUNIXを学び、株式会社アスキーに入社。データベースのテクニカルサポート、月刊アスキーNT編集部 副編集長などを経て1998年退社、フリーランスライターに。2000年、株式会社アットマーク・アイティ設立に参画、オンラインメディア部門の役員として2007年にIPOを実現、2008年に退社。再びフリーランスとして独立し、2009年にブログメディアPublickeyを開始。現在に至る。
リーダーシップの原則
チームの初期にやらなければならないのは、合意とアコモデーション。
まずは「ゴール」、最終的に何を実現するかをみんなで合意しようと。
次は「目標」ですね。短期的にはどこに到達したいか。それから「価値観」。こういうところに価値をおいて、ここは譲れません、という価値観。
ただ、最初に人が集まった段階で、いきなりこんな合意はできないと思うんですね。なのでまず最初に何をするか。相手のことをよく知ろう、ということには合意します。
現時点ではやり方に合意できないし、相手の意見にも合意していないけど、合意していないことには合意しようと。
とはいえ、一緒に考え続けよう、ということにも合意する。
ここからスタートですね。初期であるほどこういうのが必要になってくる。
でもいきなり集められて、こういうリーダーシップをとるのは難しいですよね。「僕はただの社員だから、リーダーシップをとるのはマネージャがやればいいじゃないか」と。
でも、例えばAmazon.comだと「リーダーシップの原則」というのがあって、平社員も管理職も関係なく、社員全員がリーダーですという言い方になっているんですね。
リーダーはまず違うと思ったらちゃんと言えと。大変だけど言えと。で、リーダーは信念を持って容易に妥協しません。
でもいざ決定がなされたら全面的にコミットしますと。あとから「あのとき決まっちゃったけど、オレは最初から反対だったんだ」と言って、やらないのはナシだと。
【次ページ】 フィードバックをしないと共通理解は得られない
関連タグ
あなたの投稿
PR
PR
PR
