はてなブックマーク

はじめに こんにちは。コミューンでスクラムマスターをしているまつむらと申します。 今回はコミューンで私が取り組んだ技術課題のなかから「メール送信システムのリプレース」について記載させていただこうと思います。 はじめに 背景 IPウォームアップとは？ 移行計画のための準備 メールの開封率 ドメイン乖離度合 メール送信数 実装 要件 ソースコード データベース 工夫ポイント その1: データ全件取得 その2: 乱数生成器を外部から注入 その3: キャッシュ有効期限のコントロール 結果 やらかし まとめ 背景 コミューンは、BtoBおよびBtoC向けにコミュニティを作成できるプロダクト「commmune」を提供しています。 commmune ではメール送信のために SendGrid という SaaS を利用しているのですが、 2022年5月頃、事情により SendGrid のアカウントを変更する

はじめに こんにちは。コミューンでソフトウェアエンジニアをしているU2です。 今回は commmune の開発でも使用している typescript-sequelize のモデル定義ファイルからER図を作成していきます。 はじめに 背景 やりたいこと 実装 環境 前準備 実験 ER図の生成 CI化 今後の課題 参考サイト まとめ 背景 commmune は豊富な機能を持ちそれに合わせいくつものデータを保持しているので、永続化のためのテーブルが多く存在します。 また、テーブル定義としてはリレーションを持つが、Sequelizeのロジック上使用しないことが理由でモデルファイルにそのリレーションが記述されていないこともあります。 そのため、新規参入者がテーブル全容を把握するのに苦労しています。（そもそも長く開発に関わっている人でも知らないテーブルがあったりする。） そんな問題を解決するために、S

QAの須賀(@kawabeaver)です。 先日QA Test Talk Vol.2で「自分たちのテスト設計プロセスを作ろう」というタイトルで、テスト設計プロセスを作る思考過程について発表させていただきました。（発表資料はこちら） 外部イベントで発表するのは初だったので緊張して「出社推奨日」がうまく言えませんでしたが、楽しい時間を過ごせました。 さて、本記事では、上記発表で少し紹介したテスト設計プロセスについて説明したいと思います。 テスト設計のやり方に悩んでいる方、他の人のテスト設計を教える立場の方などのお役になれば幸いです。 テスト設計とは何か テスト設計はなぜ必要か テスト設計プロセスをなぜ作ったか テスト設計プロセス作成のゴール テスト設計プロセスの内容 テスト対象を洗い出す テスト対象について、テスト条件に関する情報を洗い出す テストすべきテスト観点を洗い出す 各テスト観点に対し

初めに こんにちは。コミューンプロダクトサポートチームにおいてプロダクトスペシャリストとして活動している栗山と申します。 元々EMとしてコミューン開発に携わっていましたが、紆余曲折を経て現在のポジションに転向しまして、既に半年ほど経ちました（ここら辺の経緯は機会があればどこかで）。 そこで本エントリでは過去のプロダクトスペシャリストとしての活動を振り返りつつ、「そもそもコミューンのプロダクトスペシャリストって何をやってる人なの？」という皆さんの疑問を解消できればと思います。 初めに What is プロダクトスペシャリスト？ プロダクトスペシャリストが必要になった背景 どんなことをしているか 問い合わせ対応 SSO導入におけるサポート アプリケーションレイヤ以外の機能に関するフィジビリティ調査 プロダクトへのFB ぶっちゃけプロダクトスペシャリスト楽しい？ どういう人にオススメ？ まとめ

はじめに こんにちは。2022 年 7 月に入社したエンジニアの浅見(@astatsuya1)です。 今回は 20%ルールで実施した問題の早期発見をして開発体験を上げるために行ったことを紹介します。 はじめに コミューンの 20%ルールとは 何をやるか考えた commmune の開発における問題と課題 問題:問題の発覚が遅くなると多くの人を巻き込んでしまう 課題:出来るだけローカル環境で問題を検知したい 施策 ①:検知する項目を増やす リントでチェックする項目を増やす ローカル開発のみでしか使用しないconsole.logに警告を出す ローカル開発でのみしか使用しないtest.only, test.skipに警告を出す 英語のスペルチェックをする 施策 ②:ローカルでも出来るだけ早く検知出来るようにする コードを書く時のチェック Visual Studio Code の拡張を共有 書いたコ

初めに こんにちは。ソフトウェアエンジニアの近藤です！ 2022 年 8 月からコミューンに入社し、当社サービスの commmune の開発チームで、フロントエンドおよびバックエンドの開発に携わっております。 今回は具体的な技術の話ではなく、コミューンの開発チームの取り組みである 20%ルールについてご紹介します。 初めに 20%ルールについて なぜ緊急度の低い課題を解決することが大事なのか 具体的な運用方法 私が実際に 20％ルールを行い感じたメリットと課題 具体的に実施された事例の紹介 私が今後 20%ルールを使って取り組みたいこと まとめ 20%ルールについて Google などのイノベーティブな企業でも導入している 20％ルールですが、当社では下記のような運用ポリシーで行っています。 各自の業務時間の 20%を技術課題の改善に充てる。自分のマネージャーと相談しながら時間の調整などを

初めに(自己紹介) 2022年7月1日に入社したQAの金丸です。前職ではITメーカー系の企業でQAとして勤務していました。 今回は前職の経験を活かした5W（なぜなぜ分析）による障害分析の取り組みと効果について紹介したいと思います。 初めに(自己紹介) 障害分析 再発防止策の基準 未来の障害を防止する 従来の手法 ポストモーテム概要 コミューンにおけるポストモーテムの改良点 5Wの導入 5W導入の背景 5W概要 5Wの例 5Wの注意点(1つ目) 5Wの注意点(2つ目) 5W実施ケースと効果 5Wの改善点と今後の展望 現状の5Wの改良点 後書き 障害分析 QAチームとしてテスト品質の向上を継続していくことはもちろんなのでが、私は障害分析について特に注力しました。 理由は私の前職での経験があります。前職では障害が生じた際に障害分析を必ず実施するルールとなっており、大企業のQAだったこともあって障

はじめに SREチームの磯村です。 去年入社してからフロントエンドエンジニアとして働いていましたが今年6月からはSREチームに転属しました。 SRE見習いとして奮闘中です。 コミューンはアプリケーションの基盤としてGoogle CloudのCloud Runを利用しています。 そしてCloud Runで実行するコンテナイメージをCloud Build上でビルドしています。 この記事ではCloud Build上でのコンテナイメージのビルド速度を改善した事例を紹介します。 今回やったこと コミューンでは動作確認用の環境(develop環境と呼ばれています）や本番環境へのデプロイに20分以上かかってしまうことが頻繁に発生していました。 場合によっては29分もの時間がかかってしまう場合もありました。 このような長いデプロイ時間はメインブランチにマージできるPRの数を減少させ、変更のリードタイムを悪

はじめに こんにちは。コミューン株式会社でソフトウェアエンジニアをしている板倉です。2022 年 5 月にコミューンに入社してから、モバイルアプリチームに所属しており、Flutter を用いたモバイルアプリ開発を担当しております。 Flutter はプライベートでも使用しており、個人でモバイルアプリを開発・リリースしております。 業務開発と個人開発で同じ技術（今回は Dynamic Links）を使うことにより相乗効果が出て、良い手応えを感じられることがあったため、この記事で紹介させていただければと思います。 はじめに 業務開発での Dynamic Links の利用 Dynamic Links 経由の遷移処理の実装 個人開発での Dynamic Links の利用 ショートリンク生成の実装例（REST API 使用） 動作確認を通じて得られた気づき 社内での知見共有 まとめ おわりに 業

はじめに はじめましてこんにちは。2021 年 11 月にコミューンに入社した中野です。現在は SuccessHub というコミューンの新たなプロダクトを開発しています。 この記事では新規プロダクトの開発を通して、筆者が「どうしたら業務をコードに落とし込めるのか」実践したことをお話しします。 はじめに 背景 まずは書いてみた 業務知識をヒアリングする 核となるモデルを作る モデル同士の関係や階層を確認する コードで表現する なぜ業務知識を理解することが必要なのか 終わりに 背景 SuccessHub の開発を始めて数ヶ月経った頃、カスタムフィールドという機能を作ることになりました。 カスタムフィールドとは簡単に言うと、クライアントが保持している顧客データを自由なフォーマットやカラム名にカスタマイズしてテーブルUIに表現できる機能です。 [カスタムフィールド] 日付をYYYY年MM月 や Y

はじめに はじめまして、2022年3月中旬にコミューン株式会社に入社した西山です。 普段はフロントエンドのエンジニアとして開発業務に携わっています。 この記事では、私がERモデルを使ったDBのデータモデリング（以下、データ設計）を行う際、特に意識していることを3つ紹介します。 尚、具体的にユースケースからエンティティを抽出する方法や、チューニングなどの物理設計については触れません。 前提 まずは私がデータ設計とどのように関わってきたかについて紹介します。 前職までのキャリアでは、フルスクラッチの受託開発案件をごく少人数で開発しており、利用者に業務を伺ってデータ設計をする、ということも度々行なっていました。 システムの用途としては一般公開されない、所謂「業務アプリ」「業務システム」といった企業内での利用を想定したものや、限定された一部の利用者に向けたものです。 また規模としては大きくなく、多

はじめに 自己紹介 はじめまして、コミューンでソフトウェアエンジニアをしています、ひおきと申します。2022 年の 5 月にコミューンに入社し、今月で 4 ヶ月経過しました。 前職では 4 年間ソフトウェアエンジニアを経験し、特にフロントエンドエンジニアとして、自社プロダクトの新規開発などをしてきました。 なぜコミューンを選んだか コミューンを選んだ理由は、『超本質主義』と『チームコミューン』というバリューに共感したためです。 超本質主義 なぜやるのか、特にエンジニアの方は考える人が多いのではないでしょうか。メンバー一人ひとりが意識しコトに向き合い、本質的なことに時間を割こう、本当に良いものを作ろうというバリューに共感しました。 チームコミューン 考えるからこそ衝突やディスカッションが発生するかと思います。それを健全なものにするために、心理的安全性や信頼関係、向き合うことを大切にするバリュ

はじめに はじめまして。コミューンでマネージャー見習いをしているまつむらと申します。 2022 年 4 月にエンジニアとしてコミューンに転職しました。 現在スクラムマスターを通じてマネージャー見習いをさせていただくことになっています。 マネージャーを目指すことになったきっかけと、コミューンに入社した理由についてお話させていただければと思います。 はじめに マネージャーを目指すきっかけ キャリアについて考えてみた 一人でのシステム作りの限界 自分がプレイヤーとして取り残される懸念 リーダー経験を得られていない現状 このまま現場でエンジニアを続けていいのか？ なぜコミューンなのか マネージャーを目指すにあたり会社の規模感がちょうどよかった 社員のキャリア育成に対する考え方 事業やバリューへの共感 実際にコミューンに入社してみて キャリアの視点から 事業やバリューの視点から これからコミューンで

自己紹介 はじめまして、2020年の1月から業務委託、2020年の11月から正社員でコミューンのエンジニアとして働いているよしもと(@yoyo_yo123)です。 2022年の頭にスクラムチームが誕生し約８ヶ月間スクラム開発をしてきました。 正直スクラムを始めた当初はスクラムイベントの意義を感じられず多くのイベントに懐疑的でした。 しかしチームでの改善活動や取り組みを繰り返す中で、「スクラムイベントは意義があるものだ」と感じるようになりました。 今日は私が元々どう感じていて、今はどう感じているか、それは何故か、についてお伝えできればと思います。 スクラムイベントのどこに意義を感じてなかったのか？ 短いミーティングの中だけで実施されるリファインメント 要件の理解や実現方法の検討もできずで、「ただPOから話を聞くだけ」のあまり意味のない時間になっていた 時間内にストーリーの詳細化が進まず、結果

はじめに こんにちは！コミューン株式会社でサーバーサイドエンジニアをしている安藤(@andnandna)と申します。 今回、私が所属しているチームでモブプロを実践してみたのでその方法や感想を紹介したいと思います。 モブプロが気になっている人や他の人がどうやっているかが気になるような方へ参考になれば幸いです。 モブプロ導入 導入まで 私が今所属しているチームではスクラムを実践しているのですが、その中での取り組みの一つとして"WIP制限"というものをしていました。 簡単に言うと「チーム全体で進行中にするストーリーの数を絞る」というものです。 (詳しい内容や背景などはこちらの記事をご参照ください) チーム全員が同じストーリーに取り掛かるので、うまい具合にタスクがバラけていれば一人ずつ作業を進められますが、実装を切り分けづらかったりする場合もあります。 そういった場合にメンバー全員が一つのタスク(

はじめに コミューンのインフラにおける課題 使ってみた 既存のGCPのリソースをTerraform形式でエクスポートする main.tfを作成する 既存のGCPリソースをインポートする terraform planで実行計画を見る 1. google_compute_route 2. google_compute_ssl_certificate 3. google_storage_bucket 4. google_logging_log_sink 検証結果 感想 良い点 GA版に期待すること さいごに エンジニア募集中！ カジュアル面談はこちら！ 注釈 注1 注2 はじめに SREチームの川岡です。 もうそろそろコミューンのインフラをコード化しなきゃと考えていたときに、Google Cloudのブログで『Terraform と gcloud CLI を使用した完璧な Google Clou

はじめに 自己紹介 こんにちは、コミューンのUS事業でエンジニアをしています”さわだ”と申します。 今年4月からコミューンにジョインしました。 前職は大手IT企業のソフトウェア開発子会社で20年以上受託案件に携わってきました。 親会社からの大規模案件よりも、数人から多くて10名程度の直顧客案件や研究所関連の仕事が多く、入社後はJava Appletから始まって、OpenGLを使っった3Dアプリ、Webページ、Androidアプリ、はたまた機械の制御アプリなど様々なジャンルの開発をしてきました。 2014年にはアメリカのスタートアップと一緒に開発をしたり、直近では技術調査部門に所属しシリコンバレーに３年間駐在するといったグローバルな経験もしてきました。 アメリカ駐在の頃からスタートアップに興味を持ちはじめ、たまたま日本発の世界に向けたサービスを目指すコミューンがUS事業のエンジニアを募集して

こんにちは。昨年の11月にエンジニアとしてコミューンに入社したざびえる（仮名）です。 コミューンは、CEOのブログ「進出して分かった日本とアメリカのSaaSプロダクトニーズの違い｜高田優哉/commmune｜note」にもある通り、アメリカ進出をしており、私はその開発担当をしています。 この記事では、海外展開に関わるようになった経緯や、プロダクトのグローバル化をどのように進めているか、そして今後のグローバル化の課題などをお話しようと思います。 GlobalPJ参加の経緯 新卒でWebエンジニアとして働き始めてから常々「日本初のソフトウェアプロダクトで世界的に使われるものってないな。いつかそういうプロダクトが出て来れば日本のソフトウェア業界ももっと盛り上がって、優秀な人がソフトウェアエンジニアとして集まってくるだろうに」と思っていました。 一つ思い当たるのはプログラミング言語のRubyですが

はじめに コミューン株式会社でQAマネージャーをしている須賀（@kawabeaver）です。 今回は1人目のQAエンジニア視点でコミューンの魅力についてお話します。 1人目のQAエンジニアとして転職を考えている方、1人目のQAエンジニアの採用を検討している方に1人目のQAエンジニアにとってどのような環境が望ましいかを考える参考になれば幸いです*1。 もちろん、この記事をきっかけにコミューンに興味を持っていただける方が増えると嬉しいです！ コミューンを転職先に選んだきっかけ 私は前職に約7年半お世話になりましたが、働く環境は良かったので前職に不満があったわけではありません。ただ、前職は私が入社した時点でQAチームの体制が整っていたため、今回はQAチームの体制が整っていない環境でチャレンジすることに決めました。 新たなことにチャレンジする場合、私は業務内容がチャレンジングであるだけではなく、チ

はじめに 良いコンポーネントとは 良いコンポーネントを作るためのポイント 1. コンポーネントを要素ごとに過不足なく分割する 2. コンポーネントの抽象度を揃える 3. 利用する側を意識せずにコンポーネントを作る 最後に はじめに こんにちは、コミューンでフロントエンドエンジニアをしている根岸です。 この記事では自分がフロントエンドのコンポーネントを作るときに気をつけていることを紹介します。 良いコンポーネントとは そもそも良いコンポーネント、良いコードとは何でしょうか？ 私は プログラマが知るべき97のこと の 美はシンプルさに宿る という記事の下の一文に大きな影響を受けています。 特に重要なのが「シンプルである」ということです。アプリケーションやシステムが全体としてどれほど複雑であっても、個々の部分を取り出してみると、全てシンプルになっています。 重要なのはどんな複雑なアプリケーション

こんにちは、コミューン株式会社でスクラムマスターを担っているヤマシタ（@yama_sitter）です。 前回「スプリントの属人性を減らしたらベロシティが安定した話」という記事を書きました。 この記事で紹介した取り組みに至るまでの過程に興味がある、という声を頂いたので、その過程、及び過程を振り返って得られた気付きを紹介させて頂きます。 ちなみに少し長いです。 ご了承下さい。 まずは結論から 取り組みの出会いから定着に至るまで 「WIP制限の導入」に至るまで 出会い 導入 定着 「タスクサイズの制限の導入」に至るまで 出会い 導入 定着 「死亡前死因分析（プレモーテム）の導入」に至るまで 出会い 提案 定着 改めて振り返ってみて まとめ 取り組みに出会えたのも上手くハマったのも正直偶然 「気付いてもらう」ことが大事。最後に決めるのはメンバー 「とりあえずやってみよう」くらいの気持ちで改善に取り

はじめに このブログで伝えたいこと 僕が入社する前にあった組織の課題感 マネージャーたちが感じていた課題のリスト 課題感を要約 本当の課題 見えてきた本当の課題とどう向き合うのか マネージャー陣を統括して計画立案から実行をリードできる人が物理的に存在しない 複数チーム全体を俯瞰したマネジメント経験がないのでどうしていいかわからない よし、組織のテーマをいっしょに考えてみよう！ 組織が今年取り組むべきテーマを考えるワークショップ ワークショップの進め方 まずは道しるべとしての大目標 2022年のテーマ of コミューン開発 もともとあった課題をポジティブに言い換えると目標っぽくない？ これからのチャレンジ 自分たちで決めたテーマなら自分たちでアレンジもできる 組織がいきいきしだしたから起きているうれしいこと まとめ 最後に エンジニア職種全方面募集中です！！ 宮本とのカジュアル面談はこちら

はじめに そもそもcommmune って何？ サービスの紹介 特性について 旧アーキテクチャとその問題点 問題１：増減するトラフィックに対してコスト最適なマシンスペックを設定するのが運用上難しかった 問題２：トラフィックのスパイクでサービスが過度に不安定になっていた 問題３：動作環境としてのVMの管理が煩雑になってしまっていた 打ち手としての新アーキテクチャ 新アーキテクチャ サービス選定の内訳 成果 新たな課題 最後に はじめに こんにちは。 前原夏樹と申します。 コミューン株式会社のSREチームでアクティングマネージャーをしています。 今日は当社のプロダクトであるcommmuneのアーキテクチャについてざっくり紹介していきたいと思います。 今回公開に至った動機としては知見の共有が最も大きいです。 運用負荷が比較的低いマルチテナントSaaSのアーキテクチャの具体的な一例として、どのような

【2022/07/04追記】 この記事の結果に至るまでを示した補足記事を書きましたので、良ければ見て頂けると嬉しいです。 tech.commmune.jp はじめに これは何？ 誰向けの記事？ 自己紹介 前提：「ベロシティの安定」とは 取り組み導入の背景 属人性を減らす取り組みの一覧 ① WIP制限 どうやったか 得られた成果 補足 ② タスクサイズの制限 どうやったか 得られた成果 ③ 死亡前死因分析（プレモーテム） 死亡前死因分析とは？ どうやったか 得られた成果 全ての取り組みの結果 得られた成果 何故この成果を得られたか？ 注意点 まとめ 最後に はじめに これは何？ スプリントの属人性を回避しようと取り組んだらベロシティが安定したので、実際に行った以下の取り組みを紹介する記事 WIP制限 タスクサイズの制限 死亡前死因分析 誰向けの記事？ スクラム最初の壁であるベロシティの安定化

自己紹介/経歴 コミューン株式会社でcommmuneチームのEM(Engineering Manager)見習いをやっている いちろー と言います。 今迄20年間位、ほとんどのキャリアを開発につぎ込んで決ましたが、2022/02のコミューンへの転職を機にEM的な仕事を行なうようになりました。 27歳位まで、とあるSIerの下請け会社の技術サイドのトップをやっており、技術的なマネージャ、アーキテクト、技術チームの評価、メンタリングなどをやっていました。 でも、その会社を辞めた後は、一環してアーキテクト、プログラマーとして物作りを行なっており、それがプライドでありアイデンティティでありました。 というわけで、現在のWeb系でモダンなマネージメント手法に関しては情報をあまり持っておらず、素人の気持ちで職務に当ってます。 このentryで伝えたい事 EMの仕事って意外とフワフワしている部分があるか

こんにちは。2022年1月に入社した1人目の社員QAエンジニアの須賀(@kawabeaver)です。なぜか息子に「かわちーばー（ビーバーのこと）」や「アマビエ様」と呼ばれています。 1人目のQAエンジニアとして入社したりQAエンジニアのいない開発チームに配属されたりすると、最初は何をやって良いか悩む方が多いのではないかと思います。私もその一人でした。そこで、私が1人目のQAエンジニアとして入社してから最初に行う品質向上施策を決めるまでのプロセスを紹介したいと思います。 現状の分析 既存メンバーへのヒアリング 現状のプロセスの把握 本番障害（市場バグ）の分析 施策の決定 パレート図 短期的に成果を出す 開発スピードを落とさない 成果と今後の展望 We are Hiring! 現状の分析 まずは課題の把握や施策の優先順位を決めるために現状を分析します。 既存メンバーへのヒアリング 何も仮説を持