2015年3月25日に、株式会社ロフトワークさま主催の『ビジネスを躍進させる創造的チームの作り方』にて、千葉県の柏にある柏の葉オープンイノベーションラボ（KOIL）にて、「小さなままで世界を相手に冒険できる自己組織化したチーム」というタイトルでお話をさせていただきました。また、最近ではないですが、2012年9月には、Movida School にて「スタートアップは自己組織型であるべき」といったタイトルでスタートアップの起業家に向けてお話させていただきました。
いづれも、「チームの作り方」に触れるような内容でした。
また、同様の内容で、台湾のお客様の社内セミナーや、その他多くの場所でお話させて頂いてます。
自分自身もまだまだ勉強中だということもありますが、このような題材は、「こうすることが正解」というケースは無いと思います。なので、いずれも「会社の文化や、背景、業務内容などにあわせて、良さそうだったら参考にして欲しい」といった思いで話しています。ですから、強いメッセージをあえて避けるように心がけています。
2013年には、特定非営利活動法人AIPさまで行われている「プロジェクト管理・運営講座」でも、様々なプロジェクト管理手法についてのお話をさせていただいたのですが、歴史的な背景（製造・開発等に関わる人口の推移など）と、それの影響を受けて変わっていくプロジェクト管理手法の説明と、チーム内の各個人のモチベーションはどこからやってくるのかという話をし、「プロジェクト管理」や「チームの作り方」は、必ずしも一つのやり方が正しいわけではないことを説明したりしています。
結局は「当事者の心のなかに哲学があればそれが一番だ」といった感覚です。
そのように、決定的な正解をみいだせていない「チームの作り方」ですが、今回は、どのような話をしているかざっくりと共有させて頂きます。
「ホラクラシー」という組織の形
ここ最近、「ホラクラシー」という組織マネジメントの形式が話題になりつつあり、例としてはAirbnb、Zapposなどが取り上げられています。ざっくり説明すると、上記の図のようにトップダウンで命令が行われるヒエラルキー型の組織ではなく、小さなチームに幾つかに分かれて、各チームが自主的に関わりあって大きな組織を形成するような組織になります（と思っています）。
Airbnbは、トップダウン経営と自由な自律組織の妥協点を見つけ出したようだ。同社はエンジニアリング・マネージャーを雇っている。だが彼らの役割は、一般的に想像されるものとはかけ離れている。
「伝統的な組織では、目標や目的、さらにタスクまでもが上から個々の担当者に流れていくものだ」とカーティスは私に語った。「我々のやり方では、マネージャーというのは基本的に世話役に過ぎない。マネージャーは、作業担当者の障害を取り除くために存在しているんだ」。
障害とは、例えば知識や情報に関するものだ。従業員をサポートすることで、彼が取り組んでいるタスクの全体像が見えるようになり、より良いやり方で問題を解決できるようになるだろう。あるいは、キャリアに関する障害というのもある。その場合は従業員を別のチームに配属することで、プロとして成長する機会を与えることができる。
このホラクラシー、元はと言えばソフトウェア会社で開発のために考えられた、昔ながらの上から下に命令を下す形態を、「自律したサークル」のようなものに置き換えた形です。理論的には、このシステムを導入することにより、社員は会社の経営に関してより発言権を持つようになります。根本的には、ホラクラシーは、「人」中心ではなく、「やらなければならない仕事」を中心に、会社を組織するのが目的です。その結果、社員には肩書きが必要なくなったのです。社員は、明確な目的を持っていくつかの職務を担当します。1つのチームや部署で働くのではなく、大抵は複数のチームの一員として、それぞれの場所で特定の役割を果たします。
ホラクラシーを実現するための支援をする組織「HolacracyOne」という企業もあり、その企業が制作した動画が、ホラクラシーを非常にわかりやすく簡潔に説明しています（英語ですが、わかると思います）。
僕も、プロジェクト管理の話をするときに、「自己組織型プロジェクト管理」など、回りくどい表現を使っていたのですが、「ホラクラシー」という言葉が発明されて以降、とてもスムーズに表現できるようになりました。自社の組織形態について話す機会もあり、そこでも「ホラクラシー」という言葉を使用して説明することも増えてきました。
しかしながら、冒頭に説明したとおり、各企業によって歴史や背景が違うので、弊社ヌーラボが「ホラクラシー」な感じで組織構造をとっているかというと、よくわからないのですが、基本的には上から下に命令を下す形態をとっておらず、現在のところ、チーム主体で各サービスの開発を行っています。機能追加のアイデアもチームが主体となり、また、ユーザーサポートに関しても、自律的で親切なサポートを取るようになっており、『Cacooで図がうまく書けないオンラインツールが苦手なユーザーと複数回やりとりした後、結果的に図を書いてあげた』という事例があったりします。現在では、マーケティングやサポートなど、ユーザーと直接対面する場面ではリアルタイムで機転の効いた対応が求められているので、ホラクラシー型の組織はそのような状況にマッチしているようです。
『大企業というのは人の数ではなく、承認フローの複雑さ（承認者の数）のことだ』と、どこかで聞いたのですが、ホラクラシーはもしかしたら、人が多くなっても、まるで動きの早いスモールチームを保つことが出来る組織形態かもしれません。
ソフトウェア開発手法「スクラム」
ソフトウェア開発に従事している方の多くはご存知だと思いますが、ソフトウェア開発手法「スクラム」についても、知っている知識を国内外で懸命に説明させて頂いています。
ご存じない方は、以下の吉羽龍太郎氏が公開されている「Scrumと組織」という資料を御覧ください。
スクラムを採用しているような開発プロジェクトでは、開発チームに権限を移譲してチームの文化を作ってもらうことが一つのポイントになっています。「やらなければならない仕事」を中心にして働く自主的なチームに、沢山の権限を委ねることが重要で、その仕組として、既に説明したホラクラシー型の組織づくりのようなものが、機能しやすいのでは？と想定して、話しています。
スクラムやホラクラシーのお話をさせてもらったときに、「チームの輪を乱す人がいたりしますが、どうしたら良いですか？」というような質問をされます。一瞬「知らんがな」と言いそうになるのを我慢しながら、上下関係の組織構造を引っ張り出して「どうしても、その人がわかってくれないときは、上長に訴えてやめてもらえばいいと思います。」と返答しています。このように「上から下に命令を下す形態」は決して不要なものではなく、緊急時には役に立ちますので、普段は影を潜めさせておきながら、緊急時には活用したほうが良さそうです。このことを「独善的に処理する」と話したりもします。
さてさて、スクラムに関しても、弊社ヌーラボがスクラムを採用しているか？といえば、そうではなく、ヌーラボの中で今まで育ってきた開発プロジェクトのやり方、サービスの育て方を大事にして、ときには振り返って、自分たちなりに改善や工夫を行って、チームで開発を進めています。チーム文化を育むことが大事なので、スクラムの方法論は参照程度にしておくこともいいかもしれません。
モチベーション3.0
ホラクラシー型の組織もスクラムも、チームメンバーが自主的に開発プロジェクトに関わることを前提としています。おおよそ、僕の話を聞いてくれる人は自主性のある人が多いので、あまり話しませんが、企業研修のように強制参加を強いられている人がいるようなセミナーなどでは、そのような自主的なマインドを各々のチームメンバーにどうやって持ってもらうかという話をすることがあります。
そのときに持ち出すのが、ダニエル・ピンク氏の名著『モチベーション3.0 持続する「やる気!」をいかに引き出すか（原題：Drive、以下、モチベーション3.0）』です。モチベーション3.0では、モチベーションを「内的モチベーション（内的動機付け）」と「外的モチベーション（外的動機付け）」とに大きく分けており、ホラクラシー型の組織を作るためには、「内的モチベーション」を考慮してチームを育む必要がありそうです。
以下は、その著書を要約して作った2つのモチベーションを簡単に説明したスライドです。
そして、その内的モチベーションですが、モチベーション3.0では、「自立性」「熟達」「目的」と3つに分解されて説明されており、以下がその内容を僕なりにまとめた簡単な説明です。
自立性
「自己決定」を優先し、自由に好きなように仕事をしたいという欲求のこと。チームメンバー各自は、責任を果たすことを望んでいるので、自主的なマインドを各々のチームメンバーに持ってもらうためには、コントロールせずに課題や時間、方法などを、チーム（やチームメンバー）に確実に任せると良い。
熟達
何か価値のあることを上達させたいという欲求のこと。チームメンバー各自は、自分にとって意味のあることにそれまでよりも熟達するようになることを望んでいるので、作業に没頭できるフロー状態になれる時間を作ると良い。
目的
自分の思い通りに目的を追求したいという欲求のこと。チームメンバー各自は、自分たちの欲求を、自分以外の「より大きな目的（例えば、愛、正義、美など）」に結び付けたいと思っている。なので、単純に利益の最大化を目指すのではなく、利益によってその目的を達成するようにしたほうが良い。
・・・というわけで、綺麗にまとめきれてなさそうですか、つまりは「そもそも、チームメンバーは自主的なマインドを持っている」ようです。なので、「自主的なマインドを各々のチームメンバーにどうやって持ってもらうか」という点に関しては、プロジェクトマネージャーが各自の自主性を邪魔しないように、そして、各自の自主性を邪魔する要素があればそれを取り除くようにしていくと良さそうです。
このような話をしているときに、「橋本さんは、チームを作る権限がある人ですが、わたしにはありません。自主的ではない人がプロジェクトに参加したとき、どうするといいのでしょうか？」という質問を頂いたりします。一瞬「知らんがな」と言いそうになるのを我慢しながら、「それでも、その人の自主性を信じるべきだと思います。」と、とにかく信じることを訴えています。
さらに、プロジェクトマネージャーに対しての教育をするようなセミナーでは、チームメンバーにはそのような内的モチベーションがあるので、マネージメントするときの心構えとして、以下のように、「チームを観察分析して、命令ではなく役立つ情報を伝える」ことを提案させてもらっています。
最後に
・・・というように、様々な要素を関連して考えて、短いときは15分、長いときは6時間くらい（約1時間の自己紹介を含む）を使ってお話させて頂いています。この辺のお話をするときはいつも伝わるかどうか自信がなく、さらに、自分自身も多くの失敗をしてきているので、とても話せる立場ではないと思いながら、なんだかつらい気持ちです。もし、このエントリーで伝わった方がいたら幸いです。
最後の最後に、ときおり、セミナーの締めで「チームを作ろうとする人が折れるのが一番のリスクだし、一番折れやすいので、自身の内的モチベーションも重要です」と言わせて頂いています。