※アジャイル組織とは、進化的な発達を伴いながら、秩序（3つの原則）を保つことによって、予測できない混沌とした環境においても、組織が自己設計され、結果として適応的である組織を意味する。
（写真右）株式会社ゆめみ 代表取締役 片岡 俊行さん
1976年生まれ。京都大学大学院情報学研究科在学中の2000年1月、株式会社ゆめみ設立・代表取締役就任。在学中、チャットポータルサイト「ゆめみ亭」の企画・運営、100万人規模の会員サービスとしてNo.1メディアに育てる。デジタルマーケティングの領域において高い技術力をもとに法人向けに大規模CRMシステム、ECサイト、先端的なスマートフォン向けアプリ開発を実現。また、BtoCの自社プロダクト、自社サービスにも積極的に取り組み、ゆめみから2014年4月に株式会社Sprocket、株式会社スピカの2社を分社化、取締役に就任。
（写真左）株式会社ブレスカンパニー 代表取締役 坂東孝浩
早稲田大学卒業。2011年株式会社ブレスカンパニー設立。これまで規模の大小を問わず多種多様な組織の課題解決に携わってきた。しかし、環境の変化が激しさを増してくるとともに、社員教育や人材採用などの各論では根本的な課題解決ができないと感じ始め、2018年手放す経営ラボラトリーを設立。「“人が集まる組織“への進化」をテーマに、最先端の組織や経営スタイルを研究。自社でも“手放す経営“を実践している。
マネジメントの役割分散は、事業内容が生み出した必然。
坂東：突然の『アジャイル組織宣言』にはみんなびっくりされたと思うのですが、そこにたどり着くまでの経緯を教えていただいてもいいですか？
片岡さん（以下敬称略）：2000年創業なんですが、最初10年くらいは従来型の経営管理システムを採用していたんですよ。階層があって部長やマネージャーがいて、という。ただ、2010年ごろ、社員が50人を超えてきたあたりからこのままじゃヤバいなと感じるようになりました。
坂東：何かトラブルでもあったんですか？
片岡：事業内容に関連するのですが、うちはクライアント企業とともにWEBサービスを開発していて、ゆめみ自体は表には出ませんが、実は日本マクドナルドや最大手アパレルショップで日々多くの人が使うサービスを展開している。月間アクティブユーザーベースで5000万ユーザーを超えます。
坂東：この規模でそれほどのスケールでビジネスをされているのはすごいですね！
片岡：本当に大変です。頻繁なアップデートや緊急で運用の要求変更は日常茶飯事ですし。その辺はいわゆるWEBサービス的なんですが、お客様にとってそのサービスは業務系の『基幹システム』扱いなんです。システムが止まると全店で業務停止扱いになっちゃいますから。
坂東：うわぁ……。プレッシャーがすごそう。
片岡：現場のメンバー達は感じていると思います。安定した運用が要求されるのは当然ですが、開発にはスピード感が求められる。安定とスピード、その2つを両立させるにはどんな組織が最適なのか、ずっと頭を悩ませてきました。
坂東：管理職の負担がすごそうですよね。それだけクリティカルなシステムのプロジェクトマネジメントをしつつ、予算やプロセス管理、ピープルマネジメントもしなければいけない。
片岡：負担が一か所に集中しちゃいますからね。その当時、部長が3人連続で（会社は退職せず、部長職を）辞めたこともありました。
坂東：えっ！！
片岡：それで僕が代表と部長を兼務した時期もあったんですが「部長って本当に大変だな。部長という名のもとにあまりにも多くの責務を背負わせすぎていたんだな。」と反省しました。
坂東：マネジメントの役割分散というのはそこからスタートしたんですか。
片岡：そんな状況もあり、最終的なトリガーになったのは大規模なサービス障害でしたね。
坂東：サービス障害？
片岡：お客様のシステムが1日止まってしまいました。
坂東：えぇぇ！
片岡：忘れもしない2011年11月25日の金曜日です。店舗を構えているお客様のシステム開発だったのですが、非常に多くのユーザーが利用するサービスだったため、店頭が大混乱になってしまった。最重要案件ということで最終決済が先方のCEOまで行って「ベンダー選定の疑義が生じた」と聞いたときは、会社が死ぬかもと覚悟しました。
坂東：それだけ重要なシステムだったということですね。
片岡：本当に、責任の重さを痛感しました。その後、全社員に「危険予知研修」をやらせましたからね。「右よし、左よし」みたいな。恐らくIT業界で初だと思います(笑) でもさすがにそれだけでは根本的な解決にはならないので、組織設計を変えなければいけないと思いました。部長というポジションに集中しすぎている役割を分散させていこう、と。
坂東：部長のポジション自体を無くした？
片岡：ポジションを無くしたのではなく、部長が担ってきた役割を整理して、分担できるようにしたんです。具体的には、『プロフィットマネジメント』『プロジェクトマネジメント』『ピープルマネジメント』『プロセスマネジメント』の4つに分類して、「私はピープルマネジメントが苦手なので別の方にお願いします」という風に手分けできるようにした。
坂東：その4つの分類は片岡さんが考えられたんですか？
片岡：そうですね。色んな概念を参考にしながら自分で生み出しました。
坂東：結果的に、部長や管理職の負担は軽減されたんですか？
片岡：ある程度はうまくいきました。社員数も100名を超えて、管理職がどんどん辞めていくということもなくなりました。ただ、役割は分散したものの、権限は分散していなかったんですよ。責任を取れる人が権限を持つという方式でやっていたので、結局どんどんエスカレーション（上位者の指示を仰ぐこと）が繰り返されて、管理職マネージャーが判断を迫られる場面として、重大な判断ほど、あまり減らなかった。これじゃあ、将来的に1000人規模になったとき、また崩壊するなと感じたんです。2011年の受難の時期と同じことになってしまう。それで、役割だけじゃなく権限を分散するにはどうすればいいかを考え始めました。
第二変革期スタート。いざ、1000人規模の組織へ。
坂東：1000人規模の会社をめざすと掲げたのは、どうしてでしょう？
片岡：元々は、100人くらいの規模で全員がフルスタックエンジニア(別名：マルチスタックエンジニア、すべての開発を自分一人で手がけられる人材)として動き回れる集団をめざしていたんですよ。「（水滸伝に登場する）梁山泊の108傑」みたいな。でもこの業界では技術の細分化がどんどん進んでいって。今、ドットエンドエンジニアとかそんな職種も出てきた。
坂東：昔よりもずっと細分化されてるんですね。
片岡：今は1つのプロジェクトに10~15の職種の専門家が入らないとワークしない状況になっている。しかも、それぞれの領域が狭いうえにかなり深い。その上、技術はどんどん陳腐化していくので、最新技術に追いつくには、みんなで調査を手分けして、持ち寄った情報をシェアするという組織的な学習が求められるんです。例えば、iOSエンジニアだけでも30人は必要だと考えています。
坂東：そんなにですか！
片岡：それを15職種なので、450人はそもそも必要だろうという計算です。一方で、一人がマネジメントできる人数はせいぜい6人が限界。そう考えると6人のメンバーを見るリーダー、6人のリーダーを見るマネージャー、6人のマネージャーを見る統括、というかたちで階層をつくらざるを得ないんですよね。仮にマネージャー含めて7人のチームを3階層つくったとすると6人の3乗で216人。4階層つくらないと、450人は超えてこない。6の4乗は1296人なので、逆に言えば4階層つくれば450人も1000人も一緒なんです。
坂東：なるほど～！そういう計算をしてたんですね。
片岡：ただ、4つも階層をつくると相当エスカレーションするので、判断のスピードがどうしても落ちる。うちのサービスは、その場その場で各自が判断してスピード感を持って動かしていかないと成立しないんです。
坂東：ということは単純な階層化では無理ってことですね。
片岡：理論的にも直感的にも無理だと思いました。マネジメントの役割範囲を細かく設定したとしても、誰にも割り当てられない役割はどうしても残るし、相談や決済のエスカレーションが繰り返されて、最終的に一部の人に負担が集中してしまう。どうにか権限を分散できないかと考えていたとき、ティール組織の『助言プロセス』に出会ったんです。盲点でしたね。
※助言プロセスとは
誰もがどのような意思決定をも行うことができる。但し、意思決定の前に以下から助言を求めることがマストとされる。
１） 深く影響があるすべての関係者
２） その分野の専門家
坂東：盲点、だったんですね。
片岡：気づかなかったですね。こんなやり方があるんだと。
坂東：これで権限も分散できて任せられるじゃん！と。
片岡：責任と権限って相互関係にあるので、結局責任を持つ役職者に権限が集中してしまいがち。助言プロセスでは、権限は全員に分散付与した上で、人によって何をどこまで任せるという責任範囲を問題ない形で細かく定めればいいという、権限と責任をセットにしない発想に衝撃を受けました。
坂東：なるほど。
ゆめみの組織構造を大公開
片岡：うちでは階層的に責務を分解し、その責務を遂行するための単位を『チーム』、その責任範囲を『スコープ』と呼んでいます。チームはコミッターとコントリビューターで構成されていて、コミッターはスコープに対しての遂行責任を負い、スコープの範囲におけるコミット権限があります（助言プロセスを経て意思決定することができる）。コントリビューターはコミッターの自律を支援する存在であり、コミット権限はありません。また、親チーム（例えば事業部）のコミッターは子チーム（例えば課）のコミッターになれないという制約を設けることで、部長が課長の決定を覆すようなことが起きないようになっています。
坂東：なるほどなあ。助言プロセスの導入はスムーズに行きましたか？
片岡：助言プロセスって、実は運用がメチャクチャ大変なんですよね。専門家と全関係者からアドバイスを得ようとすると膨大な時間がかかる。大きな意思決定をするときはなおさら。そうなると、スピード感を持った事業運営ができない。どうしたらうまく運用できるのか試行錯誤した末に生み出した仕組みが『プロリク（Proposal Review Request）』です。
坂東：プロリクとは？
片岡：エンジニアにはなじみ深いプルリク（プルリクエスト）をメタファーとした仕組みです。うちでは一つひとつのチームにSlack（社内コミュニケーションツール）のオープンチャンネルが紐づいていて、コミッターが何か意思決定する際は、そのチャンネルと親チームのチャンネルに起案を投稿するんです。投稿を受けた人は、その起案のリスクや回避方法についてレビューのかたちで伝えることはできますが、否決はできない。
原則レビューは48時間以内に行うというルールになっているので、意思決定スピードはものすごく上がりました。このプロリクを経て、大阪本社オフィス移転やリベラルアーツラボの新設といった大きな意思決定もされています。
柔軟なジョブチェンジを可能にする仕組みが、採用競争力を高める。
坂東：組織改革を進めるにあたって、参考にした企業はあったんですか？
片岡：千数百人の従業員を抱えながらアジャイル開発を実現しているSpotifyの事例は参考にしていました。もともと2014年ごろからそれに近いかたちで組織をつくっていたのですが、一方でSpotifyの従来型のマトリックス型組織に課題も感じていた。プロダクトに人が紐づくこのモデルだと、いくらエンジニアリングマネージャーがピープルマネジメントをしていたとしても、けっこう縦割りになってしまうんですよね。
坂東：ゆめみもそうなっていた？
片岡：一つ象徴的な事象があったんですが、あるメンバーから「帰属意識をどこに持てばいいかわからない」という悩みを吐露されたんです。その子はけっこうプロジェクトを転々としていて、もともと一緒にやっていたプロジェクトの仲間が好きなのに、会社都合で他のプロジェクトに行かされたと感じていたようで。これはまずいなと思いました。特にうちは、あるサービスが急に縮小化したり無くなったりするということはあり得るんですよね。いきなり自分が帰属していたプロジェクトが無くなってしまうと、居場所を無くしたような感覚になっちゃうんです。
坂東：事業の特性上、そうなっちゃいますよね。
片岡：そこで、プロジェクトごとにチームを編成するのではなく、iOSチーム、Androidチームというかたちで職能ごとにチームを組んで、そこにプロジェクトを複数振り分けるようにしたんです。もし今やっているプロジェクトに飽きてきたら、チームが持っている別のプロジェクトに柔軟に異動することができる。特定のプロジェクトにロックインされることもないですし、このチームは永続性を保っているので、帰属意識も生まれました。
坂東：チームをまたいでの異動も可能なんですか？
片岡：例えば、Androidエンジニアがフロントエンドエンジニアチームに入りたいと思えば、チームのSlackチャネルをクリックして参加し、そのチームのコントリビューターになれる。極端なことを言えば、1クリックで部署異動が可能です。
坂東：マジっすか！
片岡：自分の関心やめざすキャリアに沿って所属するチームを選べるんです。「iOSの次はAndroidのスキルを上げるためにそっちに異動して、iOSへのコミットの割合を減らす」「組織づくりに興味が出てきたので、人事に異動して会社の福利厚生をつくる」とか。そんな風に自分のキャリアを自分で開発することができます。IT業界にはおいてはエンジニアの採用競争力を高めることがめちゃくちゃ重要で、そのためには柔軟にローテーションしながらスキルを上げていける環境づくりがカギになると思っています。
坂東：なるほどなあ。確かに、優秀なエンジニアほどさらなる成長を求めて転職する傾向にありますよね。
片岡：たとえばうちにはテックリードという、高い技術力を生かして後方支援的に現場のエンジニアにアドバイスを送る役割があります。一人10個ほどのプロジェクトを見ているのですが、仮にその中の一つが最先端技術を導入していたら「一緒に作業させてよ」と実際の現場に入って学ぶこともできる。現場のエンジニアにアドバイスを送りつつ、自分自身も管轄しているすべてのプロジェクトの良いとこどりができるんですよ。こういう働き方は、けっこう昆虫とか参考にしましたね。
坂東：昆虫って、虫の昆虫ですか？！
片岡：スズメバチをモデルにしたんですが、スズメバチってバッタとかを捕食する強い顎を持っていても、それを消化する機能がないんですよね。かみ砕いて団子にしたものを餌として幼虫に渡し、幼虫はそれをガシガシ食べる。すると幼虫はお尻から栄養分のある液体を出すので、成虫はそれを吸って栄養を取るんです。成虫と幼虫はお互いに依存関係にあり、エンジニアの働き方もまさにそれだな、と。
坂東：ハッハッハ（笑）
片岡：テックリードが最先端の技術情報を見つけたら「こんなのあるよ」とプロジェクトに振り分ける。プロジェクトチーム内で作業してある程度吸収できたら、「あとはリリースしといて」と任せることもできる。「根源的なリーダーシップとは何か？」と考える中で昆虫のことも調べたんですが、そこで得たヒントをもとにうちのリーダーシップモデルは作られています。
坂東：テックリードって、採用難易度はやっぱり高いんですか？
片岡：メチャクチャ大変です。すごい競争率です。ただうちの場合は10個くらいのプロジェクトの中から興味のある技術の美味しいとこどりができる。でも一般的なテックリードって、マネジメントも求められたりするんですよね。
坂東：はいはい、エンジニアリングマネージャーをさせられるんですね。
片岡：そうです。会社によってはエンジニアリングマネージャーの役割の中に、ピープルマネジメントもテックリードも要求していたりする。でも、テックリードの中にはピープルマネジメントしたくない人ってけっこういるんですよね。だから、うちではそれはやらなくていいよ、と。むしろ技術的な部分でメチャクチャ美味しい想いができるよ、と。それによって高い採用競争力を維持しています。
坂東：なるほどなあ。
片岡：そうやって色々調べて試行錯誤して組織づくりをしてきたんで、せっかくなら人に使ってもらえるように汎用的なフレームワークにしたいと思っています。僕も本当に苦労したので、これからの人には同じ苦労をしてほしくないな、と。
坂東：リアルで具体的な話がポンポン出てくるので、非常に参考になると思います。次のインタビューも楽しみにしています！
