こんにちは、Magic Moment 採用担当です。
本日は、Magic Moment の主力プロダクトである営業支援 SaaS「Magic Moment Playbook」の開発を担うテックチームへ、働く環境づくりにどのような工夫をされているのか聞いてみました！
＜目次＞
テックチームの取り組み
Tech ラジオ
- 目的：各スクラムチームを横断したメンバーコミュニケーションの醸成
- 概要：隔週に1度、お昼の1時間で Gather を活用して開催。ラジオパーソナリティは固定メンバー2名が担当しゲストは入社歴の浅いメンバーを招待。リスナーとなる他メンバーには Google フォームからお便りを募り、ゲストの様々な情報を発信している。（お便りの質問は常識の範囲内であれば何でもOK） 2022年4月より開始した取り組み。
飯田：2022年は徐々にテックチームの人数が増え、同じチームなのによく知らない人もいるという状況に課題を感じていました。そんな時に清家さんから「双方向コミュニケーションではなくてもいいのではないか」と提案いただいたことがきっかけで、ラジオをやってみたら面白いのではないかと考え始めました。実際にラジオを開始したことでゲストで呼ばれるメンバーの意外な一面が見え、それをきっかけにコミュニケーションが発生したり、あだ名が定着したりチームメンバー同士のコミュニケーションの増加に効果があったと感じます。
中嶋：そうですね。特に2022年9月からはスクラム体制となり、その後に入社した新メンバーは各チームの配属となったので、チームが異なる場合は新メンバーとの接点が少ない状況でした。その様な状況でもラジオから新メンバーの様々な事が共有されることで、まだ話をしていなくても人と成りが伝わってくるのは新しいなと思いました。その後出社した時は「ラジオの⚪︎ ⚪︎さんですよね」みたいな（笑）僕、ある新メンバーとの最初の話は、その人がラジオで話してたラーメン二郎についてでしたからね！
石田：僕が9月に入社して初めて視聴したラジオのゲストは、実は第一印象がクールそうだなと思っていたメンバーだったんです。実際にラジオを聴いてみたら「めっちゃこの人柔らかい」と印象が変わりました。入社したばかりで緊張もあったからだと思いますが、第一印象につられてコミュニケーションをしなくて良かったと思います。ラーメン屋が好きと言っていたので「噂のラーメン屋に行ってきました！」みたいに話すきっかけになりました。
清家：ラジオパーソナリティを担当している飯田さんがある種芸能人的な立ち位置になっているほど、凄くラジオパーソナリティ力が高いんですよね。
大塚：分かります！あとは Google フォームで寄せられる質問がすごくラジオっぽいですよね。「飯田さんこんにちは」とか、ラジオネームがすごく変だったり（笑）
飯田：そうそう。センスを感じますよね！
輪読会
- 目的：学習したい本の理解の促進・積読の解消
- 概要：参加者は事前に定められた章を読み、分かったこと・分からなかったことを持ち寄り、理解を深める。共通して学びたいコンテンツがあった場合に開催
大塚：ある時、共通の読みたい本を持ってるメンバーが複数人いて「それなら一緒に読もう、じゃあ輪読会にしちゃおう！」とカジュアルに始めました。現在行なっている輪読会のコンテンツは「単体テストの考え方/使い方」です。Magic Moment としても単体テストに課題を感じていたので、読みたい本を見つけた際に口裏を合わせていなくても数名のメンバーがすでに買って読んでいたので、輪読会で勉強しながら実際に単体テストの改善をしています。
山下：輪読会では毎回決められた章を事前に読み、当日は分からなかったことをメインに議論することができるので、より記憶に定着しやすいと感じます。また実際の業務にて単体テストで悩んでる部分は、その疑問も一緒に解決できるので学びが業務で活かされていると実感しています。個人的に技術者の積読はある種エンジニアのあるあるかなと思うので、消化できる機会になってます。
清家：学習のために本を読んでいても、途中から理解が追いつかなくなって諦める事はありがちだと思います。輪読会があることによって、分からなかったことをピックアップして持ち寄り、分からないことに向き合っていくと理解の定着はしやすいですね。
フロントエンドアーキテクチャ会（通称：茶会）
- 目的：各スクラムチームを横断したフロントエンド領域の課題の棚卸し・挑戦したいことの議論
- 概要：毎週金曜日に1時間の開催。フロントエンド全体の進捗共有やその週で困ったことの相談を実施。新しい技術についての議論も行なっている
石田：現状の技術に対しての相談は勿論、今後やりたいことや挑戦したいことも話しています。例えば、Storybook を入れた方が開発効率が上がるのではないかなど、やってみたいことの話が挙げられた際は、1つのチームが Storybook を導入しその実証をもとに横展開をしてフロントエンド全体で活用するようになったという事例もあります。
中嶋：通常、業務時間内に行われるミーティングは業務の課題について話す割合が多いですが、茶会はフロントエンドエンジニア同士の情報交換といった側面も多いと感じています。業務的な会話だけに留まらず「あの言語のこの仕様が分らないな、ライブラリに新しいバージョン出ましたよ」など、開発と少し離れてエンジニア同士がお互いに情報を交換することでスキルアップに繋げられているのは、通常のミーティングとは異なった独特で良い部分です。それが個々の成長に繋がる機会になっていると思っています。
飯田：各スクラムチームで行なっている実装に対しチームは異なりますが同じフロントエンドの領域として様々なメンバーにアドバイスをもらえる場にもなっているのでありがたいですね。
石田：また茶会では今までに出来ていなかったことを解消するために OKR を持つようにしています。目標を持つことでフロントエンドが前に進むための土台作りができ、挑戦したいことも話せるのでなかなか良い発散の場になっていると実感しています。
LT 会
- 目的：各スクラムチームを横断して業務で習得した新たな学びを共有する
- 概要：発表者は立候補形式。事前に発表したいコンテンツを集め、最低2-3名の発表者が集まった際に開催。Magic Moment Playbook の開発において各スクラムチームがどのような設計・実装を行なっているのかナレッジをシェアするために開始
山下：スクラムチームに分かれていることで他チームの技術的なチャレンジや、どのような工夫をして開発をしているのか知ることができる機会が少なく、横断して共有できる場が欲しいと思っていました。そんな時にカルチャーの推進をしているメンバーへ LT 会の運用方法について相談し様々なアドバイスをいただいたことで開催に至ることが出来ました。実は前職でも LT 会を行なっていたのですが、発表準備が大変だったことで継続開催が難しいという課題がありました。そのためなるべくハードルを低くし、カジュアルに開催することができるように工夫をしています。
中嶋：僕も何度か立候補しているのですが、一つのテーマについてプレゼンをすることで自分にとっても記憶の整理や定着が見込めると思っているので、なるべくこのような機会を活用したいと思っています。
山下：発表するだけではなく、分からないことがある場合は発表者が疑問を投げかけてその場にいる参加者で解決するという取り組みも行なっています。初回の LT 会の発表者は飯田さんで、疑問を参加者へも投げかけその場の議論は盛り上がりましたよね！
飯田：そうです。分からないことをバカにすることは禁止というのが暗黙のルールになっているので、初歩的なことでも自分が理解している意味が間違っていたら、メンバーから優しいツッコミが入り改めて理解することができるのはとても有難いです。
山下：ちょっとだけインターネット老人会みたいな感じで盛り上がりましたよね。
一同：（笑）
清家：皆んな教えたがりなんです（笑）
Demo Day
- 目的：新機能を全社へお披露目し、使い方の共有やフィードバックなどを行う
- 概要：隔週金曜日に開催。全社員が参加する場でデモンストレーションを交えて発表。現在はお休み中。
清家：Magic Moment では、2021年1月に正式ローンチする前から、機能のアップデートについて、開発に携わったエンジニアが社内に対してデモをして、お披露目をする Demo Day というイベントがあります。単なる機能の説明にならないように、どういった課題があり、ユーザにとってどのような価値があるのか。そこに対してどういった技術的工夫をしたのか、といったことをエンジニアの言葉で語ることで、プロダクトの進化を全社で喜び楽しむイベントとなっています。エンジニアにとっても、営業という肌感覚を持ちにくいドメインの開発をしている中で、ダイレクトな反応を得て、次のモチベーションへもつながる貴重な機会となっています。一方、プロダクトがシンプルかつ会社規模がコンパクトだった時期に比べ、伝え方・伝わり方が難しくなってきたため、今はプロダクトチームと議論しながら目的とやり方の見直しをしています。
コミュニケーション
Gather の活用
- 目的：コミュニケーションの醸成と円滑性の向上
- 概要：在宅の業務時間内に活用。実際にオフィスで仕事をしている時のように気軽に会議室に入室し通話がすることができる
清家：他のコミュニケーションツールも活用していたのですが、チームが増えていくと同時にコミュニケーションの取りにくさを感じていました。例えば、声をかけるには「話したいことがあるので別の Room に移動しましょう」といった会話から始めなくてはならず、カジュアルに声をかけたり、雑談ができる状態ではなかったです。コミュニケーションを醸成するために真剣に話し合ったところ、Gather というツールを知り試しに活用したことがきっかけです。
Gather は同じエリアの人と話すことができる仕組みが良かったです。実際のオフィスにいる時のように近くにいるメンバーの声が聞こえるので、チームごとにグループを作り自由に会話の単位を区切れるようになりました。
飯田：声だけではなくアバターがあることと、エモートというリアクション機能があることで、コミュニケーションの気軽さや楽しさを感じますね。
中嶋：そうですね。リアクションができるのでミーティングでメンバーが良いことを言ったときに拍手を送り合ったりしてます。
清家：同様にコミュニケーション醸成の目的で始めた Tech ラジオの取り組みは Gather だからこそ成り立っています。同じエリアにいなくてもその空間にいる全員に声を届けることも出来るので、まさにラジオや町内放送のように活用できます。
成長支援
PERF
- 目的：社員個人の成長・評価のオペレーション
- 概要：セルレビュー、マネージャーレビューで構成され、強みや改善点などについて多角的かつ客観的に知ることができ、成長に必要な要素を知ることができる。全社員が対象。
清家：PERF は自分自身を定期的に振り返り、マネージャーや会社からどう見られているか、課題や成長といった変化についてのフィードバックを得る機会です。各 Job Level（※） で求められる内容を支える6つの特性を表した Attributes を参考にしながら行うのですが、職種ごとに異なるのではなく全社共通です。分かりやすさを選ぶのであれば、エンジニア特有の言葉や振る舞いで定められたものをベースとしたほうが良いのでしょうが、それだと全社共通で大事にしたいカルチャーや、成長に対する捉え方が薄まってしまう気がしています。エンジニアも、特殊な職種ではなく” Magic Moment のいちビジネスマンとして ”という観点に立ってみる良い機会になっていると感じています。
中嶋：PERF は四半期ごとに行うのですが、このサイクルが絶妙だと感じています。Magic Moment の開発チームではおおよそ3ヶ月でひとつの開発プロジェクトに取り組むことが多いため、振り返りのタイミングがちょうどプロジェクトの区切りと重なります。
過去に PERF を通じて振り返りを行なった内容やいただいたフィードバックもいつでも参照することができるので、3ヶ月前の自分と比べて、つまりひとつのプロジェクトを通して成長があるのかないのかがすぐ判別できます。もちろん、たった3ヶ月で目覚ましく成長できることは少ないので、同じようなことで何度もつまづいていることもあります。しかし、同じ課題が繰り返し現れることは、それが本当に自分の苦手としている弱みなのだと自覚できますし、同じ課題であっても3ヶ月前の行動よりも進歩できているかどうかを検証できます。Attributes も抽象的な言葉で書かれているので、初めはピンとこないまま自分の行動に当てはめてみることも多かったのですが、PERF を重ねるうちにスッと腑に落ちる瞬間があります。経験や知識を積み重ねてきた実感を持てる制度デザインになっていることが PERF の良い点だと思っています。
大塚：そうですね。Magic Moment Playbook というプロダクトを通じ世の中に価値を届ける Magic Moment の社員としての振る舞いを振り返り、フィードバックを得られることが良いなと考えています。お二人も言っているように Attribtes が基準になっているため軸がブレずに振り返ることができています。
担当しているプロジェクトや個人 OKR の結果がどうであれ、その結果に至ったプロセスを振り返りフィードバックを得ることができるため、課題であれば改善手段、強みであればそれをもっと伸ばすための手段を明確にすることができ、次のQで行動に移すことができます。
（※）Job Level：メンバーがよりMMのミッションに対してインパクトを与えるアウトプットを創出するための力を効果的に高めるためのフィードバックの基準。その基準は6つの特性に分解された Attribtes で支えられている
Magi Tech Fund
- 目的：エンジニアの技術支援を目的とした支援制度。
- 概要：毎月定められた金額がエンジニア手当として支給され、学習やスキルアップを目的に自由に活用ができる
石田：まだ制度として始まったばかりですが、Magi Tech Fund で書籍を購入し、さらに輪読会に出ているメンバーは多いです。
飯田：活用の仕方は自由なので電子書籍で購入できる点も良いですよね。
中嶋：スキルアップ的な面ですと、私たちは Google Cloud を活用していて個人用のサンドボックス環境を持つことができるので、人によっては Magi Tech Fund を活用して新しい機能を自発的に試しているメンバーもいます。また、少し話は逸れますが Google Cloud や、クラウドエースといったクラウドベンダーから学習用のプログラムへお誘いいただくことがあり、参加するには業務を抜けなくてはならないのですが、申請すれば快く送り出してもらえる周囲のサポートも成長支援となっています。
レトロスペクティブ
- 目的：各スクラムチームの課題に対するアクションを定める
- 概要：スクラムチーム単位で1スプリント（現在は2週間）の終わりに開催。
石田：レトロスペクティブは個人にフォーカスすることはあまりないですが、個人が失敗したことや問題を提起した際はチームメンバー同士でフィードバックし合っています。そこはスクラム体制だからこそできている文化であり、成長にも繋がっていると思っています。
働き方
出社スタイル
・スタイル：オフィス出社と在宅勤務のハイブリッド制。現状出社は水曜・金曜の2回。開発状況により出社からリモートへの切り替えは相談可能。
・目的：コミュニケーションの醸成・集中できる開発環境の構築
中嶋：オフィス出社と在宅勤務のそれぞれのメリットを考え、バランスを取ったのがハイブリッド制だと捉えています。やはり情報共有やコミュニケーションを取らなくてはいけない場面があるので出社のメリットを感じますし、そうは言っても手を動かして開発を進めなければならないので、出社にかかる時間的コストを考えた際は在宅勤務のメリットを感じます。
大塚：僕は気分転換も含めて出社したいと思っているタイプなのですが、それぞれのスタイルを叶えられるのは良いですね。また、在宅勤務のみだと会話が各チームに閉じてしまう傾向がありますが、出社すると他チームや外へのコミュニケーションが盛んになるのは良いなと思っています。業務外でも、僕と中嶋さんのチームは別ですがこの前は一緒にランチに行きましたよね！そのようなチームを超えて関係を築くことができるのはとても大事だと思っています。あと、夜に飲みに行くこともあります（笑）
中嶋：大事ですよね。全員がハイブリッド制を続けられているのはテックチーム全体でのコミュニケーションに価値を感じているからだと思います。また、出社か在宅かというのはあまり本質ではないと思っています。チームとして成果やアウトプットを出すことが大事だと理解しているので必要に応じてコミュニケーションを密に取りたい時は出社しますし、集中して開発を進めなければならない時は在宅にするなど、時々に合わせて柔軟に手段を変えられるような体制をとっています。
大切にしていること
ー働く環境づくりにおいて様々な取り組みや工夫をされているテックチームですが、最後に大切にしている軸を教えてください
清家：一人目のエンジニアとして入社してから、3年以上かけて20名を超えるチームとなってきました。チームが拡大する中で、様々な失敗をし、見切りをつけて辞めていったメンバーもいます。そういった経験の中から、働く環境という点で重要なのは、分断をしないことなのではないかと考えています。
アーキテクチャとしてマイクロサービスを選択している我々にとって、疎結合は重要なテーマですし、チームとしてもユーザの体験ごとに責務を負ったスクラムチームを作り、自律分散して開発していくことを目指しています。一方、完全に分断してしまうと孤立を生み、仕事をつまらなくしてしまいます。エンジニアの仕事はプログラムを書くこと（だけ）ではありません。今回このインタビューで取り上げた様々な取り組みは、個と個、個とチーム、個と会社といった繋がりを大切にし、そこから生まれる仕事の楽しさやインパクトを感じ、成果を最大化していくことに繋がっていると思います。
加えて大事なのは、これらの取り組みの多くがテックチームの自発的な活動から生まれていることです。変化の激しい環境において、自分たちで課題を見つけ、変わっていくことが出来るチームは強いですし、経営もそういったチームの動きに対して惜しみないサポートをしてくれます。
これからもこのような軸を大切にして、成果にこだわるチームとその環境を作っていきたいと思います。
ーありがとうございました！
インタビューをしたメンバー
