輪読会の参加ハードルを低くする工夫とアウトプットを出すまでの道のり
この記事は、Magic Moment Advent Calendar 2023 12日目の記事です。 こんにちは！ Magic Moment で Tech Lead をやっている Miyake です。 アドベントカレンダー12日目の今回は、社内で輪読会を開催する際にあたって意識したことと、どのような成果に繋がったかを話したいと思います。 輪読会を開催した背景 以前から漠然とチームで勉強会の文化を作りたいなと思っていた矢先、チームの関心とそれにマッチしそうな良書の発売のタイミングが重なったのがきっかけです。 ちょうど昨年末から今年にかけて、チーム全体で監視やプロダクト品質といった組織で取り組む必要があるテーマに関心が高まったタイミングで以下の本が発売されました（実際に輪読会を行ったのもこの2冊）。 今後の組織の事も考えると、一人で読むよりなるべく多くのメンバーと一緒に呼んだほうが良いと思い、
GoエンジニアがReactにチャレンジして驚いた5つのこと
はじめに こんにちは。Magic Momentでエンジニアをしている伊藤です。 いつもはMagic MomentのプロダクトであるMagic Moment Playbookの開発に携わっています。 元々はGo言語エンジニアとしてMagic Moment Playbookのバックエンド開発に参加し始めました。 ですが、今回フロントエンドエンジニアとしてフロント側の開発に参加することとなりました。 Go言語を使っていたエンジニアがReactを使い始めて驚いたこと、理解しづらかった部分などを書いていこうと思います。 これからフロントをやってみたいと思うバックエンドエンジニアの方の参考になれば幸いです。 そもそもReact.jsとは Magic Moment PlaybookのフロントエンドはReact.jsを使って構築されていますが、そもそもReactとはなんなのでしょうか。 ReactはFac
年間退職率が 37.0% → 3.5% に！
この記事は、Magic Moment Advent Calendar 2023 25 日目の記事です。 はじめに Merry Christmas!! こんにちは。株式会社 Magic Moment で VPoE をしている 清家 (@wakazooo )です。 いよいよ、Advent Calendar も最後となりました。これまで、24回にわたって、技術・組織・開発プロセスなど様々な角度から Magic Moment Tech チームの 2023年の取り組みを紹介してきました。 2022 年に比べ、技術力・組織力・発信力とあらゆる面で大きく成長したのですが、その前提となったのが退職率の劇的な改善だったと感じています。 今回は、退職率がどのように改善し、なぜその変化を起こせたのか、という点についてご紹介したいと思います。 年間退職率が 37.0% → 3.5% に！ 年間退職率を以下で計算し
コア機能のリファクタリングで取り組んだこと
この記事は、Magic Moment Advent Calendar 2013 7日目の記事です。 Magic Moment の @scent-y です。 今年、コア機能での障害に起因した中核データの不整合解消や顧客案内のため、エンジニアやCSのリソースが大きく割かれてしまうという課題に直面しました。根本対応のためタスクフォースに参画しコア機能のリファクタリングを行ったので、どのように取り組んだか紹介したいと思います。 Magic Moment Playbook のコア機能とは 顧客との合意項目を中心に営業オペレーションを定義し、営業活動の中でうまれた顧客との合意内容を記録する機能です。記録内容に応じてレポート機能の数値を更新したり、Salesforce や HubSpot に連携したり、 シーケンスのトリガーとして利用されたりします。 サービスの中核データにあたる顧客との合意内容の永続化
SRE を立ち上げた4ヶ月後の世界
この記事は、Magic Moment Advent Calendar 2023 4 日目の記事です。 こんにちは! Magic Moment で Senior Engineering Manager 兼 SRE Engineering Manager をやっている 木村 (@ryurock) です。 Magic Moment アドベントカレンダー 4 日目では、2023年9月に SRE チーム を立ち上げた 4 ヶ月後の世界。 というテーマでアドカレやっていきたいと思っています。( ｰ`дｰ´)ｷﾘｯ SRE チームの立ち上げの経緯 遡る事、2023年7月頃に弊社が提供しているサービス Magic Moment Playbook のコアデータが立て続けに更新できない障害が相次ぎました。 Sales Operation を行う上で、大切なデータが頻繁に反映されないこの由々しき事態はユーザー様
一人目QA、半年間何してたんだ？
Magic Moment（MM）で自称 QAE (Quality & Agility Engineering) をやっている yano です。 本記事では MM に一人目 QAE として入社した半年間のふりかえりを兼ねて、Magic Moment Playbook (MMP) の開発の雰囲気と一人目 QAE が半年間何をしていたのかという事例をご紹介をできればと思います。 どうして入社したんだ？ そもそも何故 MM に一人目 QAE としての入社を決めたのかというところですが理由は非常にシンプルで、面談を通して話をしたエンジニアの方々が全員プロダクト開発に真摯に向き合っており、サービスを通してユーザに価値を届けたいという熱意がとても伝わってきた点です。 自分の入社エントリ記事 にも記載しているように、実際の業務フローでプロダクトを利用する dogfooding の習慣や Demo Day
GitHub Copilotをエンジニア全員に導入して開発生産性を継続的に上げていく
こんにちは。Magic Momentの髙橋です。 ここのところ世間では生成系AIが注目されていますが、エンジニアが一番注目しているのはその中でもコードを自動生成してくれるAIではないでしょうか？ その中でもよく名前が上がるのが、GitHub Copilotだと思います。 Magic Momentではエンジニアの生産性をあげるべく様々な施策を実行してきましたが、今回GitHub Copilotを会社として公式に導入していくことになりました！ 導入してまだ１ヶ月程度ではありますが、どのように運用しているのか？開発にどのように役立っているのか？をご紹介したいと思います。 導入した理由は、エンジニアの開発生産性を上げるため GitHub Copilotは、エンジニアの書こうとしているコードを補完してくれる生成系AIツールです。 詳しい説明は他記事や公式ドキュメントに譲りますが、これを活用することで
設計を議論する会を作ったらプロダクトの設計品質は上がりチーム全体の設計力が上がりました
こんにちは。Magic Momentの髙橋です。 現在Magic Momentではチーム全体でプロダクト品質の向上と設計力の向上に積極的に取り組んでいます。 もちろんMagic Momentのエンジニアは技術力向上に貪欲で、自分たちで勉強会をしたり新しい技術の使い所について議論をすることが本当に大好きだと思います。しかし個人の日々の勉強ではなかなか得られない経験というのが「顧客向けに作るサービスの設計」だと思います。 いくら自社サービスを作っているMagic Momentであっても、すべてのエンジニアが等しくすべての設計の経験ができるとは限りません。そこで少しでも設計の経験を積んでもらい、それがプロダクトの品質向上にも貢献するような取組をはじめました。 それが「Product Development会」という設計を議論する会議体を作ったことです！ ここからは「Product Develop
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
