スクラムの各種イベントに対して懐疑的だったが、チームでの改善を繰り返すうちに意義を感じるようになった話

自己紹介

はじめまして、2020年の1月から業務委託、2020年の11月から正社員でコミューンのエンジニアとして働いているよしもと(@yoyo_yo123)です。

2022年の頭にスクラムチームが誕生し約8ヶ月間スクラム開発をしてきました。

正直スクラムを始めた当初はスクラムイベントの意義を感じられず多くのイベントに懐疑的でした。
しかしチームでの改善活動や取り組みを繰り返す中で、「スクラムイベントは意義があるものだ」と感じるようになりました。

今日は私が元々どう感じていて、今はどう感じているか、それは何故か、についてお伝えできればと思います。

続きを読む

スクラムチームでモブプロをやってみた

はじめに

こんにちは!コミューン株式会社でサーバーサイドエンジニアをしている安藤(@andnandna)と申します。
今回、私が所属しているチームでモブプロを実践してみたのでその方法や感想を紹介したいと思います。
モブプロが気になっている人や他の人がどうやっているかが気になるような方へ参考になれば幸いです。

続きを読む

『Terraform と gcloud CLI を使用した完璧な Google Cloud インフラストラクチャの構築』は本当に完璧なのかやってみた

  • はじめに
  • コミューンのインフラにおける課題
  • 使ってみた
    • 既存の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 Cloud インフラストラクチャの構築』という記事を見ました。
「完璧」という言葉に惹かれ、上の記事を参考にして自社プロダクトで検証してみたので紹介します。
なお、Terraformの概要や用語は説明しませんのでご了承ください。

続きを読む

日本のSaaSスタートアップが世界で戦うためのプロダクトを開発するということ

こんにちは。昨年の11月にエンジニアとしてコミューンに入社したざびえる(仮名)です。

コミューンは、CEOのブログ「進出して分かった日本とアメリカのSaaSプロダクトニーズの違い|高田優哉/commmune|note」にもある通り、アメリカ進出をしており、私はその開発担当をしています。

この記事では、海外展開に関わるようになった経緯や、プロダクトのグローバル化をどのように進めているか、そして今後のグローバル化の課題などをお話しようと思います。

続きを読む

良いコンポーネントを作るために気をつけている3つのこと

  • はじめに
  • 良いコンポーネントとは
  • 良いコンポーネントを作るためのポイント
    • 1. コンポーネントを要素ごとに過不足なく分割する
    • 2. コンポーネントの抽象度を揃える
    • 3. 利用する側を意識せずにコンポーネントを作る
  • 最後に

はじめに

 こんにちは、コミューンでフロントエンドエンジニアをしている根岸です。

 この記事では自分がフロントエンドのコンポーネントを作るときに気をつけていることを紹介します。

続きを読む

スクラムは「気付いてもらう」とうまくいく、と気付いた話

こんにちは、コミューン株式会社でスクラムマスターを担っているヤマシタ(@yama_sitter)です。

前回「スプリントの属人性を減らしたらベロシティが安定した話」という記事を書きました。
この記事で紹介した取り組みに至るまでの過程に興味がある、という声を頂いたので、その過程、及び過程を振り返って得られた気付きを紹介させて頂きます。

ちなみに少し長いです。
ご了承下さい。

  • まずは結論から
  • 取り組みの出会いから定着に至るまで
    • 「WIP制限の導入」に至るまで
      • 出会い
      • 導入
      • 定着
    • 「タスクサイズの制限の導入」に至るまで
      • 出会い
      • 導入
      • 定着
    • 「死亡前死因分析(プレモーテム)の導入」に至るまで
      • 出会い
      • 提案
      • 定着
  • 改めて振り返ってみて
  • まとめ
    • 取り組みに出会えたのも上手くハマったのも正直偶然
    • 「気付いてもらう」ことが大事。最後に決めるのはメンバー
    • 「とりあえずやってみよう」くらいの気持ちで改善に取り組もう
  • 最後に
続きを読む

コミューンのアーキテクチャ選定

  • はじめに
  • そもそもcommmune って何?
    • サービスの紹介
    • 特性について
  • 旧アーキテクチャとその問題点
    • 問題1:増減するトラフィックに対してコスト最適なマシンスペックを設定するのが運用上難しかった
    • 問題2:トラフィックのスパイクでサービスが過度に不安定になっていた
    • 問題3:動作環境としてのVMの管理が煩雑になってしまっていた
  • 打ち手としての新アーキテクチャ
    • 新アーキテクチャ
    • サービス選定の内訳
    • 成果
  • 新たな課題
  • 最後に

はじめに

こんにちは。

前原夏樹と申します。

コミューン株式会社のSREチームでアクティングマネージャーをしています。

今日は当社のプロダクトであるcommmuneのアーキテクチャについてざっくり紹介していきたいと思います。

今回公開に至った動機としては知見の共有が最も大きいです。

運用負荷が比較的低いマルチテナントSaaSのアーキテクチャの具体的な一例として、どのようなアーキテクチャにしようか悩むエンジニアの参考情報になると嬉しいです。

現在のアーキテクチャについて正直素晴らしいエレガントなアーキテクチャだとは思っていません。改善すべき箇所はまだまだ存在しています。

しかし、改善に改善を重ねつつ必要なところでは負債を返して(あるいは返そうとして)おり現実的に戦っていけるアーキテクチャではあるなと自負しています。

(あわよくば改善提案、今後ぶち当たりそうな問題など諸先輩方のフィードバックをいただけると非常に助かります。または『こんなアーキテクチャぶっ壊して俺が最強のアーキテクチャを作るんだ!』っていう気合の入った方も是非当社の開発チームに応募いただきたいです!)

では紹介していきます。

続きを読む

スプリントの属人性を減らしたらベロシティが安定した話

【2022/07/04追記】
この記事の結果に至るまでを示した補足記事を書きましたので、良ければ見て頂けると嬉しいです。

tech.commmune.jp

  • はじめに
    • これは何?
    • 誰向けの記事?
  • 自己紹介
  • 前提:「ベロシティの安定」とは
  • 取り組み導入の背景
  • 属人性を減らす取り組みの一覧
    • ① WIP制限
      • どうやったか
      • 得られた成果
      • 補足
    • ② タスクサイズの制限
      • どうやったか
      • 得られた成果
    • ③ 死亡前死因分析(プレモーテム)
      • 死亡前死因分析とは?
      • どうやったか
      • 得られた成果
  • 全ての取り組みの結果
    • 得られた成果
    • 何故この成果を得られたか?
  • 注意点
  • まとめ
  • 最後に

はじめに

これは何?

  • スプリントの属人性を回避しようと取り組んだらベロシティが安定したので、実際に行った以下の取り組みを紹介する記事
    • WIP制限
    • タスクサイズの制限
    • 死亡前死因分析

誰向けの記事?

  • スクラム最初の壁であるベロシティの安定化を突破できず苦しんでいるエンジニア・スクラムマスターの方
続きを読む

1人目のQAエンジニアが最初の品質向上施策を決めるまで

こんにちは。2022年1月に入社した1人目の社員QAエンジニアの須賀(@kawabeaver)です。なぜか息子に「かわちーばー(ビーバーのこと)」や「アマビエ様」と呼ばれています。

1人目のQAエンジニアとして入社したりQAエンジニアのいない開発チームに配属されたりすると、最初は何をやって良いか悩む方が多いのではないかと思います。私もその一人でした。そこで、私が1人目のQAエンジニアとして入社してから最初に行う品質向上施策を決めるまでのプロセスを紹介したいと思います。

続きを読む

倒れたときの応急処置をGCPにお願いする

倒れても自力で立ち上がろうとするインフラが好きなSREチームの川岡です。
サービスがダウンした時の応急処置くらいは自動化できないものかと思い、Cloud Pub/SubをトリガーにCloud FunctionsからCompute EngineへSSHでアクセスしてインスタンス上のアプリケーションを起動する検証をしてみました。

続きを読む