みてねの開発スタイルを大きく変えた話
とても久しぶりに個人ブログの方に記事を書きます。
冒頭ちょっとだけ在職エントリ的な内容を。
今も元気にミクシィでエンジニアとして在職中です。2011年11月に入社したので、もうすぐ丸10年。
みてねを新規事業で立ち上げ、開発を始めてからももう7年ほど経っている。この10年で技術スタックも役割も自らいろいろ変えてきたので、全く飽きてはいないし、それどころか仕事をすればするほど新しく仕事が生まれるので飽きる暇もなく毎日を忙しく過ごしている。
最近の状況はざっくり書くとこんな感じ。
- 引き続き、みてねのエンジニアリングマネージャーとSRE
- モバイルアプリとインフラの間での改善とかコスト削減とか
- 外部リソースを使いながら開発している案件のディレクションとか
- あとは、開発の足回りでみんながちょっと嬉しいと思ってくれそうな改善とか、ライブラリの導入・バージョンアップとかを勝手に拾ってやってる
さて、ここからは本題。長いので時間ある時に読んでもらえると嬉しいです。
組織の規模感
「みてねの開発スタイルを大きく変えた」というタイトルだが、それがどのくらいの規模感の話なのかというところは前提として書いておきたい。もし、参考にしてもらえるようなことがあったとしても、規模感が全然違うと通用しない話になるかもしれないので。
- エンジニア(モバイルアプリ/サーバーサイド)が10名未満
- UI/UXデザイナーが10名未満
- そのほか、マーケティングやCS・BizDevなど合わせて15~20名ほど
つまり、この「開発スタイルを変えた」ということで影響を受けた人間の数としては、30名程度だと考えるとよさそうである。ただ、移行した後の開発スタイルはスケールのことも考えているので、それ以上でも通用する話ではあるはず。あと、SREや機械学習の開発チームは少し違うスタイルで開発しているのでここではちょっとスコープ外(無関係という程ではないが)。
これまでの開発スタイル = LeSS
これまでは、ざっくり言うと、「スクラム開発」でやってきた。
スクラムチーム1チームの体制が開発当初から数年続き、メンバー増などの影響で、さまざまな面で複雑性や面倒臭さが増したことにより、ラージスケールスクラム(LeSS)へと移行していた。LeSSに移行してからは2年ほど経っていた。
LeSS 自体はとても良かった。
まず、プロダクトバックログがひとつであるために、その管理コストが非常に低い。プロダクトオーナーは基本的に直列にプロダクトバックログの優先度を管理すれば良かったので、シングルチームからマルチチームへの移行コストがプロダクトオーナー視点ではほぼ無かったはずである。
また、LeSS の開発チームには、明確にミッションがあるわけではない(施策による得意領域というのは自然と出来てくるが) ので、柔軟に対応しながらユーザーのために必要な価値に集中して開発ができるし、今後チームを 2→3→4…と増やして組織をスケールしていくことを考えても「増やしたチームにどんなミッションを与えるのか？」などと考える必要もなくポコポコとチームを増やしていくことも気軽に出来たはずである。
さらに、自分が LeSS の良い点と感じていたのは、「チームメンバーはできる限り変えず、長期間一緒に仕事をすること」というもの。たとえ、4~5人のチームであったとしても、呼吸を合わせてパフォーマンスを維持しながら仕事ができるようになるために、少なくとも年単位で一緒に働かく必要があると思っていたからだ。
LeSS をやめた理由
ここまで書いたように、色々良いことがある LeSS を捨ててまで、何故、開発スタイルを変える必要があったのか？
一番大きな理由は、求められるビジネスのスピード感が非常に高いことに加えて複雑性も急激に増していたこと。つまり、プロダクトバックログの優先度を直列に考える難易度が高まっていた。
端的に言語化するのは難しいが、 LeSS の観点から言うと「ひとつのバックログ・ひとつのプロダクト」という前提が、事業のスケール状況と対比すると、揺らぎ始めていた感覚があった。
また、プロダクト自体がリリース後、6年目に突入していく中で、エンジニアからいわゆる技術的負債の解消欲求や業務改善の要望などもばんばん上がってきており、バックログが短期間でどんどん肥大化・複雑化し、グルーミングも仕切れないほどになっていた。
こうった状況は薄々察知していたので、いずれは変えなきゃなぁ、でも影響が大きいしミスったらちょっと怖いなぁ、と提案資料は手元に作っていたのに、心理的に乗り切らずのらりくらりしていたのだが、とある開発メンバーが問題提起し、積極的に開発スタイルを変えていくことを提案してくれたことにより、自分も背中を押され一気に状況が変わっていった。そこは、本当にありがたかった。
今回の開発スタイルの変更は、そのメンバーともじっくり意見交換しながら、最終的には自分がハンドリングして、ステークホルダーや各組織のマネージャーとコミュニケーションをとり、2~3週間ほどで一気に行った。
プロジェクト型組織への移行
では、どのような開発スタイルに変えていったのか。
と言いつつ、特徴的なものではなく、いわゆるプロジェクト型の組織に変えていった。色々参照してはいたが、最終的には自分の中では、かなりBASE株式会社の開発スタイルに影響を受け、参考にするようにしていた。以下の資料の24ページ目あたりから。
コンセプト
まず、自分は新しい開発スタイルのコンセプトとして以下のようなもの掲げた。
- 一定期間メンバーがプロジェクトに集中できる環境を提供する
- メンバーがオーナーシップを持てるように積極的に権限委譲を行う
- プロジェクトチームは明確なゴールが存在し、それを達成するための期間が設定されている
- プロジェクトごとにチームのメンバーを変えることで気分をリフレッシュすることができる
- 「改善」を行うためのプロジェクトを常に組成する
4は LeSS で「良かったこと」としていた内容の真逆をいくが、これはコミュニケーションの活性化の狙いもあり、昨今のリモートワークという環境下に合っているのかもしれない、とも考え、あえて自分の考えも変えて、ここを強く押し出してみた。
5に関しては、常になんらかの「改善」に目を向けて対処していくことで、一定のエンジニアリングリソースは確保してしまうが、長期的にスピード感を高めていくために重要であることを説明した。
運用方針
このようなコンセプトのもとで、具体的には以下のような運用を行っている。
- 各プロジェクトにはプロジェクトリーダーを置き、プロジェクト内の具体的な施策や優先度の決定などの権限を委譲する
- プロジェクトリーダーはプロジェクトの目標とそれを達成するために必要な期間を設定する
- プロジェクトの最大期間は3ヶ月とする
- 期間を延長することも可能だが、その場合は目標を再設定し、マネジメントと合意する必要がある
- 各プロジェクトにはリードエンジニアが配置され、プロジェクトリーダーの決断のための判断材料（時間・難易度など）をエンジニアリングの観点から提供する
- 各プロジェクトにはエンジニア・デザイナーだけでなく、CSやBizDev、マーケティングなどの別組織からも横断的に参画してもらうことで、より多角的な視点でプロジェクトの企画を練り上げていく
- プロダクトオーナーは、プロジェクトリーダーを窓口にして頻繁にチームとコミュニケーションを取る
- プロジェクトへのメンバーのアサインは、各エンジニア・デザイナー等との1on1やチームでのミーティングを通して意見交換し、最終的にマネージャー間で調整して確定する
- チーム内での開発スタイルは自由で、チームにお任せする（引き続きスクラム開発で進めても良いし、全く別のスタイルでやっても良い）
- リファクタリングやエンジニア発案によるコードベースやアーキテクチャの改善、業務改善を担当するプロジェクトが常に存在している
プロジェクトにメンバーをアサインする時には以下のようなことに気を付けている。
- 技術スタックが偏らないように、いわゆるフィーチャーチームとして必ず成立させる
- 得意分野や興味、色々な意味でその人に任せたい領域をできる限り任せられるように考慮する
- リードエンジニアは固定しすぎず、多くのメンバーに任せられるようにする
- 次にどのプロジェクトにアサインしてもらいたいかをうっすら予見しておき、次のプロジェクトにスムーズに移行できるようにする
開発スタイルの移行による効果とデメリット
LeSS をやめて、このようなプロジェクト型の開発スタイルに移行したことによって、どのような効果があったか？
基本的にはメンバーや各組織のマネージャーたちから、ポジティブな声があがっており、効果が出ていると感じている。
まず、とにかく「集中できるようになった」ということはみんなが口を揃えていっている。そういう組織に半ば強制的に変更したので、当然と言えば当然だが、一番狙っていたことでもあったの、そういう声が多くてほっと一安心した。
また、これは客観的にプロジェクト型組織の全体を管理している自分の視点から感じたことだが、行動や思考がプロジェクトチームごとに完全に切り分けられたことにより、コミュニケーションが分散され、それぞれのプロジェクトチームの中で職種を超えて自然と濃密で活発な会話が発生しているように感じる。また、各メンバーが一定期間、ひとつの物事に集中することで、脳内に整理しておくべき情報量も少なくなり、最適化されたはずである。
最後に嬉しい効果として特筆したいのは、さまざまな決定や進捗管理が各チームに分散するようになったことで、LeSS イベントにかけていた全体での定例的なミーティングの時間が圧倒的に減り、移行前から計算上は62%分も削減できた。
一方で、マネジメントコストは高まっているのを感じる。まず、アサインを考えるのは結構大変で、今取り組んでいるプロジェクトの次のプロジェクトを予見したり、本人の希望ややってもらいたいことなどを総合的に考慮しながら、少ないエンジニアリングリソースの中でも長期的な視点で判断することは相当慎重にならざるをえない。例えば退職者が発生したときなどはどう対処すべきか、などは一旦棚上げにしている課題だ。
また、各プロジェクトに閉じて、詳細な議論や決断をおまかせしているわけなので、コミュニケーション量が効率化して良い反面、詳細な情報が欲しいときに入手する難易度は逆に高まっていきそうだ。ふとした時に詳しい情報を欲するプロダクトオーナーやマネジメントレイヤーが困らないように、長期的にはプロダクトチームが情報をアウトプットするプロトコルを適切に定義して必要な時に必要な情報がスッと取り出せるようなオープンな状況をもう少し作っていく必要がありそうだ。
まとめ
今年の3~4月は、こんなことを仕事として取り組んでいたため、なかなか大きなプレッシャーがあった。脳をフル回転させながら細かいところまで気を配ったり直接対話したりしていて、とても疲れが溜まった。
「スプリントゼロ」から、みてねをスクラム開発で運用してきていたので、正直そのスタイルを一回捨てることに関しては、ものすごく腰が重く、いざ取り組むときにはとても緊張したし不安だった。
ただ、今となってはそれなりにスムーズに開発がまた進むようになってきたこともあり、今後何年か先までの手法をが手に入れたかも、という安堵感とそういう環境をチームに提供できたことの喜びもある。
みてねは今後こんな開発スタイルでやっていくぞ！という表明と、組織設計の知見共有の意味をこめてこの記事を書いた。
みてねに興味ある人は、ぜひ一緒に働きましょう。
採用に関しての詳細はこちらから。
自分は、ミクシィに入社してもうすぐ丸10年になるが、エンジニアリングからマネジメントまで、いろんな意味で自由気ままに勝手にやらせてもらっているし、一緒に働くメンバーやプロダクトにも恵まれている環境なのと、やれることもいっぱいあるのでまだ頑張っていこうかな、と思っています。
