こんにちは、MagicMoment 採用担当です。
Magic Momentは、組織設計において可用性を大事にしています。可用性とは、システムを障害などで停止させることなく、稼働し続けること。サービスをグロースさせるためには欠かせない概念になります。
今回は開発責任者である清家に、可用性を大事にする背景や実際の取り組みについて伺いました。
＊清家のプロフィールはこちら
誰か1人がいないと回らない組織では、成長しない
――テックチームでは、組織設計において「可用性」を大事にしていると聞きました。可用性を大事にするようになった背景を教えてください。
2020年末にβ版として数社に提供し始め、2021年3月に大きな障害が起こりました。そのとき障害対応ができるのは私しかいなかったんです。誰か1人がいないと回らない。このような可用性のない組織体制ではサービス提供を安定的に続けられないと分かりました。CEOの村尾にも、「清家がいなければだめだったら、組織は成長しないよ」と言われて。確かにその通りだと感じ、属人的な組織体制を変えていくことを決意しました。
私自身、以前の会社でも同じような危機に直面していました。組織が成長しているのにも関わらず、最初からいる人間が同じ役割を持ち続けてしまうのです。組織とプロダクトが成長していくためには、早めに属人性を排除できる文化や仕組みを作るべきだと考えていました。Magic Momentでは、同じ課題感を抱くチームメンバーがいたこともあり、可用性を高める仕組み作りを急速に進めることができました。早いうちから手を打てたのはラッキーだったと感じますね。
――具体的にはどのような仕組みを作っていったのでしょうか？
もともと、チケット制は導入していました。ストーリーポイントをスプリントごとに見積もり、開発していく形です。私自身、前職でストーリーポイントの妥当性を実感しており、チームに私一人の段階から作っていたものでした。可用性というよりは、チームの生産性を数値化して把握しておくための施策です。
ペアタスクについては、チームのメンバーが4～5人に増えた2020年8月頃に導入しました。これも以前の会社でいい取り組みだと感じていたものの一つです。1人でタスクをしているとどうしても属人性が高くなりますが、ペアタスクをすることで2人の中で情報を確実に共有することができます。可用性ももちろん、チームで協力して難しい問題に取り組んでいくカルチャーにもつながると、導入を決めました。
障害対策のために、数値化も取り組んでいます。障害が起きるときは何かしら前触れのようなものがあります。しかしきちんとウォッチしていなければ気づきません。そこで2021年3月、品質の可視化を始めました。他社の場合、お客様から求められてSLA（サービスレベルアグリーメント）を設定するケースがほとんど。自社の課題感からSLAを制定できたのは非常に良かったと感じます。具体的に数字で示すことで、優先度を決める基準となっています。
2021年7月にはテックブログをスタートしました。メンバーが「チームの良さを自覚する」ためにスタートしたものです。1人で書くのは大変なので、ペアタスクで進めています。背景としては、6月くらいにチーム全体が疲弊した時期があったんです。目の前の開発をいかにこなすかと考えるばかりで、リリース後にプロダクトがどのように使われるか、「そもそもこのチームの魅力って何だっけ」という問いにメンバーが答えられなくなっていました。そこで始めたのが、コアバリューのワークショップとテックブログでした。テクニカルの発信で自分たちの魅力を伝えることで、再確認することにもつながっています。
ボトムアップの組織作りを
――これから組織設計のために取り組んでいきたいことはありますか？
入社3～6か月単位のスキルマップやキャッチアップの仕組みを作っていきたいです。今チームにあるスタックはどのようなもので、新しくジョインした方がどんな順番でスタックを積み上げていくべきなのかが分からないと、新しいメンバーは迷子になってしまいます。これまで入社してきてくれたメンバーは、彼らの頑張りに依存する形となっていましたが、今後採用が加速していくフェーズに入ってくると、属人的な仕組みでは回りません。新しく入社した方がしっかり目標をもって方向性を定められるようにしたいですね。
また、ボトムアップで組織を作っていくことも大事だと考えています。採用という難しい課題に取り組んでいく中で、採用がうまくいっているように見える他の会社を見て気づいたことなのですが、自分たちがどんなチームになりたくて、そのためにはどんな人が必要で、どんなカルチャーをつくっていきたいのかを自分たちで語れるチームは採用でも強いんですよね。自分たちもボトムアップの組織へと成長していきたいです。
「ボトムアップの組織」を言い換えると、自分たちで理想を描き、実現できる組織ではないかと考えています。その状態に向けて、最近取り組んでいることとして、各自で「テーマ」を持とうとしています。目標管理の仕組みとして、全社でクオーターごとにOKRを立てて取り組んでいますが、個々に意思がないとどうしてもトップダウンの目標になってしまいます。そうならないよう、各自がどういったテーマをもっているのかを言語化し、その中からクオーターを通してどういったことに取り組みたいのかを個人のOKRとし、会社、チームのOKRと接続することができれば、みんなワクワクして仕事ができるのではと思っています。
――ここまでのお話を聞いてみて、システム関連のものはボトムアップでの改善も多いものの、組織設計においては村尾さんと清家さんで考えたものも多いと感じます。現状はうまくいっているように思うのですが、ボトムアップにしていかねばならないという危機感はどこから来ているのでしょうか。
組織が大きくなっていけば、私と村尾のコミュニケーションはどんどん抽象的になってしまいます。今後、2人だけの視点では具体的なアクションに落とせなくなるかもしれません。この問題を回避するためには、トップダウンではなく、ボトムアップで自律していく仕組みも必要だと考えています。
――今後エンジニアチームをどのようなチームにしていきたいか、目標を教えてください。
これまでのキャリアの中で、組織がバラバラになってしまう経験を何度かしました。エンジニアが、自分のプロダクトについて自信を持って語れる組織であるべきだと痛感しています。世の中や顧客にどのような価値を作っていくのかを、エンジニア一人ひとりが語れるチームをつくりたいです。
――最後にここまで読んでくださった方にメッセージをお願いします。
「言われたことだけをやる」「テクニカルなチャレンジだけができたらいい」という方は、Magic Momentには合わないと思います。仮にスキルが追いついていなくても、プロダクトや顧客に向き合える人たちと一緒に仕事がしたいと考えています。自分たちがいいものを作っているとモチベートされる組織になれば、組織も成長しますし、個人もどんどん成長していくはずです。
世の中や顧客のためにプロダクトづくりをしたい、志を同じくする方、ぜひ一度お話ししましょう！
