組織の拡大に伴うアジャイルなプロダクト組織構築
Drivemodeというスタートアップにジョインしてから4年が経ちました。ジョインした（入社すると決めた）当時はまだシードラウンド以前であり、ファウンダー4人+エンジニア2人という状態でした。ですが今となっては組織も数十人規模まで大きくなってきています。
組織が大きくなるにつれ、様々な組織やマネジメントの問題に遭遇するようになり、今後もこれらと真剣に向き合わないといけません。
本記事では、これまでの経験を踏まえて、組織の成長に伴ってどのようなアプローチで組織や文化を構築すれば良いか、考えをまとめて書きます。
常に管理されたプロダクトバックログの重要性
いきなりですが、まずプロダクトバックログの話をします。
常に管理されているプロダクトバックログというものは非常に大切です。プロダクトバックログとは目的地に向かうための道筋であり、そこが空になっていたり、でたらめな状態だと、車（プロダクト）は暴走（それぞれ好き勝手開発され）したり、停止（まったく開発されない）したりします。エンジニアリソースを有効活用できないということは言うまでもありません。
これはすべての組織、方法論に言えることだと思います。「何をやるのか」はエンジニアの開発スピードよりも、プロダクトの技術的品質よりも、何よりも大切なことです。
プロジェクト組織とプロダクト組織
上記でいきなりプロダクトバックログの話をしましたが、この扱いがプロジェクトとプロダクトで大きく違います。
プロジェクトとは、一般的には始まりと終わりが明確に決まっているものです。「何かをやろう」と思ったときに何かをやるプロジェクトが発足し、そのためのチームが編成され、プロジェクトが終わると同時にチームが解散します。つまりその後「なにをやるのか」がなくなるということです。
そのため、プロジェクトが行われ、プロジェクトが解散すると、それによって生み出された成果物はしばしばオーナー不明でメンテナンスしづらいものになってしまいます。まさに作って終わり状態です。
一方でプロダクトとは、製品そのものであり、プロダクト組織とはその製品の寿命と同じくずっと存在します。「なにをやるのか」は常にプロダクトバックログで管理されています。
toCサービスのようなプロダクトにおいて、プロダクトチームというものが存在する場合は、プロジェクトからの引き継ぎによってなんかすることも可能ではありますが、そもそもプロジェクトをやらずに、プロダクトチームがプロジェクトの要件をそのまま受け入れて、プロダクトチームがさばくほうが、引き継ぎの必要はなく、オーナーシップも生まれ、メンテナンスもやりやすいですし、プロダクトオーナーによってその施策を生かしていけます。
プロダクトチームそのものが存在しない場合は、作って終わりという状態になり、プロダクトにいい影響が与えるとは考えづらいです。
プロジェクトという考え方があまりにも一般的なので、いきなりプロジェクトをやめるということも難しいことでしょう。しかし、少なくともプロダクト組織を最低限定義することは重要です。
component team(職能組織)とfeature team（機能組織）
一般的なtoCプロダクトを開発するにあたり、component teamとfeature teamのどちらがいいのかについて考えます。
プロダクトバックログアイテムはどのcomponentにどれくらい工数がかかるのかなどは全く関係がないため、component teamが開発する場合、どこかのチームがボトルネックになったり、それによってオーナーシップが不明瞭になったりします。しかしfeature teamはクロスファンクショナルであり、どのように開発するかもチーム内で決めることができ、開発したものに対するオーナーシップも生まれるため、長生きするプロダクトに所属するチームとして相性が良くなります。
バイモーダル戦略: プロダクト組織かつfeature team
以上をふまえ、SoE(System of Engagement)のような一般的なtoCサービス、リーンスタートアップやアジャイル開発が適したプロダクトの場合、プロダクト組織でかつfeature teamのほうが相性が良いと考えられます。
そしてこれらを理解し、早めに組織構造を固めておくことが、組織問題を未然に防ぐためにはかなり重要です。
組織と文化とプロダクトの関係「文化は組織構造に従う」
上記で述べたように、プロダクトのタイプによって、それに適した組織構造が違います。
コンウェイの法則を利用した逆コンウェイ戦略、SoEやSoRのようなシステムのタイプに合わせたバイモーダル戦略は、組織構造を語る上でしばしば出てきます*1。
また、まだあまり一般的ではないですが、ラーマンの法則(Larman's Law)*2というのもあり、このひとつに"Culture follows Structure"、文化は組織構造に従うというものがあります。
これを考えるとSystemに限る話ではなく、適切な組織構造を作ることは組織の文化にもかなり影響が出るだろうということがわかります。
他にもラーマンの法則を紹介すると、
1. 組織構造は暗黙的に現行のマネージャーと専門家の役職や権限が変わらないように最適化されています。
2. 1の影響により、変化を起こす提案は、元の状態が再定義される、もしくは新しい用語が乱用されることになり、結果的に元々の状態と変わらない状態になります。
3. 1の影響により、変化を起こす提案は「理想主義だ」、「机上の空論だ」、「革命だ」、「宗教だ」、「我々の環境に合うようにカスタマイズすべきだ」といった批判や嘲笑の対象になります。 ーこれは、自分たちの弱点から目をそらすためであり、マネージャーや専門家が現状を維持するためのものです。
4. 1の影響により、変化を起こす提案を間違えた方向にさらに変化させた後、仕事にありつけなかったマネージャーや専門家がまだ残っていた場合、彼らは(2)や(3)を推し進めながら変化を遂行するためのコーチやトレーナーになってしまいます。*3*4
つまり、プロダクトやシステムのタイプに合わせて組織構造を考慮することは極めて重要であり、それを怠った場合、将来的に苦労するだろうというのが予測できます。
適切な組織構築が遅れてしまった場合
組織の規模が大きくなると、組織問題が増え、対処する必要が増えてくるということは、簡単に想像ができるかと思います。
組織問題についての根本的な対策をなされないまま規模が数十人、数百人と大きくなってくると、改善がどんどん難しくなってくることでしょう。
ありがちなパターンとしては、何か問題Xが起こったときに、Xを対処する役割を定義、そしてXマネージャーが誕生し、そのXマネージャーがXの問題を対処する。組織の問題に対しても当てはまります。組織AにYの問題があると発覚する。Yを対処するには組織Aにマネージャーが必要だ、組織Aにマネージャー設置、組織Aマネージャーに仕事Yが追加される。
古くからある大企業でいろんな肩書の人がいるのは、こういった事象も一つの要因になっていることでしょう。もちろん、古くからの大企業でその現場を長年見てきたわけではないので、確信を持っては言えません。また、これ自体が決して悪いことではないということも言っておきます（実際そういった企業も力強く生き残っているわけですし）。
ではそうなった後に、組織全体を大規模なアジャイル組織にしたいとなった場合、どうなるでしょうか。例えば、LeSS(Large-Scale Scrum)やLeSS Hugeを導入しようとなった場合、何が起こるでしょうか。
まず、スクラムにおけるプロダクトオーナーやスクラムマスターがいません。中には経験者や有識者がいるかもしれませんが、人を採用するときにスクラムプロダクトオーナーやスクラムマスターの経験は、歓迎条件としてはあっても、requirementとして定義されていないことでしょう。つまり大規模にスクラムをやろうと思っても、急にうまくやるのは難易度が高いです。今までスクラムに注力しなかった分、うまくスクラムを行うというところにエネルギーを注ぎづらいのです。その難易度故に、スクラムの失敗体験が増える結果となり、悪循環が始まってしまいます。
そして次に、従来のXマネージャーや組織Aマネージャーの扱いです。特にスクラムやLeSSにおいてはマネージャーのroleは定義されておらず、あくまでも任意の存在です。すると、Xマネージャーはクロスファンクショナルなチームの一員とならざるを得ないでしょうし、組織Aマネージャーはこれまでとは違った「別の」責任と権限を持った完全なるサポート役になります。この認識をしっかり定義して、組織全体で認識をすり合わせないといけないのでこちらも難易度が高いかと思います。
よって、先に紹介したラーマンの法則も踏まえ、組織が大きくなってから組織や文化を変えるのは難易度が高く、早めに手を打たなければならないなと感じています。
組織規模によって変わる方法論
組織の大きさや状態によって、組織構築のためのアプローチ方法や難易度は変わってきます。
極めて少人数の時代（〜数名）
私の場合、会社のプロダクトはtoCサービスでありSoEのタイプです。リーンスタートアップやアジャイルは少人数チームだった時代に自ずと文化として生まれていました。
ラーマンの法則で「文化は組織構造に従う」と紹介しましたが、実はスタートアップの場合、むしろ「組織構造は文化に従う」のであると言われています。私はまさにこれを経験しました。スタートアップの初期メンバーだけの頃なんて、特に組織やプロセスなんて意識しなくても組織問題には遭遇せず、プロダクトをどうするかに常にフォーカスがあたっていますし、全員が全力疾走できている状態です。ただ、詳細な業務プロセスはちゃんとしてないこともあるので、そこだけ整えるようにはしていました。
そのプロセスは、ほぼスクラムのパクリなのですが、こんな感じです。
- プロダクトバックログにあたる一元管理された「やること」リストがある
- それは毎日プロダクトオーナーによってアップデートされる
- それはリファインメントミーティング（必要になれば都度やる）によってリファインされる
- エンジニアはプロダクトバックログの上からどんどん拾って開発する
- 開発ができたらプロダクトオーナーが要件を満たしているかを確認する
- そして一定のラインまで来たらリリース
- 週1でレトロスペクティブ
- スプリントという概念はない
- 見積もりもほとんどしない
これだけでうまくいっていました。少人数で皆がオーナーシップとやる気に溢れ、皆がクロスファンクショナルで、そして一つのプロダクトを作っていたからだと思います。
スプリントを定義しなかったのは、スプリントを定義しないほうが柔軟で速かったからです。頑張ってスクラムをやる必要がなかったのです。*5
このようにスタートアップで少人数の場合は、組織論そのものが不要ではありました。
十数名〜数十名の時代
しかし、このやり方もだんだんとうまくいかなくなっていきます。
それは新しく人を採用したり、事業領域が広がってきた場合です。
このときにどんな事が起こったのか、経験からお話します。
シリーズAの資金調達が終わり、人数は一気に2倍以上になりました。8人→20人程度。
また、プロダクトに関連したプロジェクトも増えていき、ふと気づいたらcomponent teamが定義され、component teamのマネージャーも定義され、プロジェクト思考な仕事の進め方が定着していきました。個人的にはプロダクト思考のfeature teamを作りたかったのですが、当時の私はなぜそれがいいのかということについて、まだうまく説明ができず、それとは全く逆の方向に進んでいったのでちょっとまずいなと思っていました。component teamはあまりにも突然決定され、説得の余地があまりなかったのですが、それでも断片的にfeature teamにしようと提案してもなかなかうまく伝えることが難しかった記憶があります。当時の私には、プロダクト思考のfeature teamにおける成功体験はあっても、プロジェクト思考のcomponent teamにおける明確な失敗体験が乏しかったのです。また個人的にもこの体制でやってみたらどうなるのか？というのは非常に興味がありました。よってこの経験は私にとっても貴重なものになりました。
この頃はプロダクトの一部の機能追加もプロジェクトとして扱われるようになり、従来のプロダクトバックログは常時メンテナンスされなくなりました。
このとき、改めて上記の「常に管理されているプロダクトバックログ」の重要性を認識しました。
一方でプロジェクトが頻繁に立ち上がるようになりました。そのため、プロダクトバックログとは別に「次何をやるか」はプロジェクトのタスクとして管理されるようになりました。それぞれのcomponent teamから必要人数をアサインし、デザイン、開発、テストのスケジュールを引き、プロジェクトマネジメントをよしなに行うという感じです。プロジェクトが終わればそのフォロータスクなどはプロジェクトに関わってた人がやるし、そうでない人もやります。
改めて考えてみると、ウォーターフォール的なプロセスだったと思うわけですが、文化としては、依然アジャイルな感じだったので、アジャイルのスタンスではいるけど、ウォーターフォールでやっているという不思議な状態でありました。なので責任権限も偏ることはなく、teamにも比較的オーナーシップがあり、タスクマネジメントもなんとか自分たちでやるし、どのように実装するのかというのは完全にチームの裁量で決めていました。ただし、明確に定義されていない分どうしても組織構造やプロジェクト思考に引きづられ、アジャイル感は薄れていくことが実感できました。ですので問題なかったのかと言われるとそういうわけではありません。
とある一つの大きなプロジェクトが終了したあと、何人もの人が「あのプロジェクトは失敗だった。あの失敗から学ぼう」という意識を持ったことがありました。
何が起こったかというと、これがまたウォーターフォールの典型的なパターンでした。加えて複雑なシステムを作った、アサインされていたエンジニアが退職し、有識者がいなくなり、かつプロジェクトは完了してチームは解散されたので・・・（以下略）という状態です。
幸い、優秀なメンバーに恵まれているため、実際こんな状態でも力技でやっていけてる状態ですが、プロジェクトを振り返ると上記のような認識になってしまいます。
もちろん振り返りは行い、改善を試みようとするものの、改善しようがないものが出てきたりもします。代表的なものとしては、コミュニケーション不足だったのでコミュニケーションをもっととろう！とかですね。
組織の文化を変えようとするのは愚かなことで、常に失敗します。人々の行動（文化）というのはシステムの産物です。ですので、システムを変更すると、人々の行動は変化します。*6
とあるように、文化だけ変えるのは難しい、やはり根本的に組織構造を見直す必要があると改めて実感します。
「組織構造」を見直す必要があるので、もう少しスコープは広く、「プロダクト開発組織」について考え、説明し、組織を作り変えていく必要があります。
もしこの人数規模でも組織が適切な構造になっている場合、例えば最初の熟練したスクラムチームをスケールさせていって、LeSSを導入したり、プロダクト数に応じてスクラムチームを増やしていくというアプローチになっていきます。
数百名の事例
この規模までなると、先程述べたようにかなり難易度が上がりますが、不可能ではありません。
これは私が実践したわけではなく、私は単なるチームの一員だった時の話ですが、私はミクシィに在籍していたことの話になります。
ミクシィでは2012年に全社的に大規模な組織改編がされました。従来のcomponent team-マネージャー構造のプロジェクト思考組織から、feature teamでプロダクト思考な組織になったのです。当時のミクシィ社員だった現株式会社レクターの松岡さんや広木さん*7の施策でした。それと同時に全feature teamにスクラムが導入されました。
社内にはほとんどスクラムに関する知見はなかったので、現場は結構大変ではありましたが、大胆で勇気のある素晴らしい施策だったと思います。
これにより、従来の社内受託開発的な構造が一掃され、マネージャーというポジションはほとんどなくなりました。そして一気にプロダクト開発のスピード感が増し、オーナーシップが形成されていきました。特に上層部からスクラム導入におけるサポートはありませんでしたが、ほとんどの現場で自主的に学習し、より良いスクラムをやろうと模索していったのです。まさにこれは文化が組織構造に従った例だったと思います。
しかしここで注意することは、ほとんど知見がない状態での強引なスクラム導入は、スクラムの失敗体験に繋がる可能性あるということです。スクラムの失敗体験をすると、「スクラムはうまくいかない」というかなり危険度の高い認識が生まれます。私も当時はそのスクラムチームにおけるスクラムマスターの一人でしたが、スクラムガイドを読みながらがんばるものの、「これでいいんだっけ？」という事象が多々ありました。
スクラムはシンプルで理解は容易ですが、習得が困難なため、こういった迷いは生じるかと思います。幸い私は新しく入ってきた当時唯一のCSP(Certified Scrum Professional)保持者及びCSM(Certified Scrum Master)保持者にアジャイルコーチとしてついてもらい、たくさんのことを学びました。個人的には現場に経験豊富なアジャイルコーチを呼ぶことは、かなり効果があると思っています。
また、このような大きな組織で改変を行うには、単にリーダーシップだけではなく、権力が必要になります。例えば私は当時新卒2年目の極めて平凡な社員でしたが、仮に私が当時組織をごそっと変えようとしても、それはとても困難だったでしょう。一体何人の権力者に納得の行く説明をし、合意を取らなければならないか、想像すらできません。この点が数十名規模の組織との違いかなと思います。それでもやらないといけないと強いリーダーシップを持った人は地道にやり遂げるかもしれませんが。
終わりに
ここ２年ほど、組織問題を解決しようとするものの、なかなか適切な言葉や表現が思い浮かばず、苦悩してきた日々でしたが、そんな中で出会ったLarge-Scale Scrumという本が、私が言いたかったことをうまく言葉にしてくれていて本当に助かりました。”Culture follows Structure”という言葉は、感じていたとしても言葉に具現化することが出来ませんでした。できていたとしても単に私が言ったところでそんな名言っぽくならなかったでしょう。
本記事で紹介しているラーマンの法則のラーマンは、まさにこのLarge-Scale Scrumの著者の一人です。
Large-Scale Scrumは単にLeSSについて書いてあるわけではなく、開発組織そのものの考え方をしっかり説明しており、スクラム実践者だけではなく、組織を変えようとしてる人にもおすすめです。最近Odd-eの榎本さんが監修して日本語版が発売されました。
私が現在取り組んでいる組織改編については、現在進行系なので、また後日アップデートしようと思います。
*2:Larman's Laws of Organizational Behavior - Craig Larman
*3:Larman's Laws of Organizational Behavior - Craig Larman
*5:細かいことを言うともうちょっとあります。PMがエンジニアをタスクにアサインしないように、とか。
*6:ジョン・セドン from Large-Scale Scrum
*7:エンジニアリング組織論への招待 の著者です。
