業務開発と個人開発で相乗効果を出すことができ、良い手応えを感じた話

はじめに

こんにちは。コミューン株式会社でソフトウェアエンジニアをしている板倉です。2022 年 5 月にコミューンに入社してから、モバイルアプリチームに所属しており、Flutter を用いたモバイルアプリ開発を担当しております。

Flutter はプライベートでも使用しており、個人でモバイルアプリを開発・リリースしております。

業務開発と個人開発で同じ技術(今回は Dynamic Links)を使うことにより相乗効果が出て、良い手応えを感じられることがあったため、この記事で紹介させていただければと思います。

続きを読む

新規プロダクト開発記 〜どうしたら業務知識をコードに落とし込めるのか〜

はじめに

はじめましてこんにちは。2021 年 11 月にコミューンに入社した中野です。現在は SuccessHub というコミューンの新たなプロダクトを開発しています。

この記事では新規プロダクトの開発を通して、筆者が「どうしたら業務をコードに落とし込めるのか」実践したことをお話しします。

続きを読む

コミューンのモバイルアプリを Flutter でリプレイスしている話

はじめに

こんにちは、コミューン株式会社でソフトウェアエンジニアをしている牛嶋です。 2022 年 4 月にコミューンに入社してから、モバイルアプリチームに所属しており、Flutter を用いてコミューンのモバイルアプリ開発に従事しております。

元々コミューンのモバイルアプリは React Native で開発されていましたが、2022 年の 4 月から Flutter を利用したクロスプラットフォーム開発に取り組んでいます。 具体的には、WebView を利用してコンテンツを表示していた部分を Flutter 側で実装し直すことに取り組んでおり、その結果として、ユーザー体験の向上させることを目的としています。

この記事では、Flutter を利用したリプレイスプロジェクトの概要について書いていきたいと思います。

続きを読む

FlutterでMacOSのメニューバーに常駐するアプリを作成

はじめに

こんにちは。コミューンでソフトウェアエンジニアをしているU2です。 少し前ですが、Flutter のバージョンアップデートでデスクトップアプリも stable になったという話を聞いたので、メニューバー(タスクトレイ/システムトレイ)に常駐するデスクトップアプリケーションを作成したのでご紹介します。

続きを読む

ERモデルを使ったデータモデリングを行う際に意識していること

はじめに

はじめまして、2022年3月中旬にコミューン株式会社に入社した西山です。
普段はフロントエンドのエンジニアとして開発業務に携わっています。

この記事では、私がERモデルを使ったDBのデータモデリング(以下、データ設計)を行う際、特に意識していることを3つ紹介します。
尚、具体的にユースケースからエンティティを抽出する方法や、チューニングなどの物理設計については触れません。

続きを読む

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

自己紹介

はじめまして、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のアーキテクチャの具体的な一例として、どのようなアーキテクチャにしようか悩むエンジニアの参考情報になると嬉しいです。

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

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

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

では紹介していきます。

続きを読む