はじめに コミューンではこれまでCI/CDのツールにCircleCIを使っていましたが、最近Cloud Buildへ切り替えました。 結論から言うと、切り替えにあたってパイプラインの中身とプロセスを今一度見直したところ、以下のように改善しました。 ビルド回数：2回 -> 1回 本番環境のリリース完了時間：約13分~24分 -> 約3分 今回の記事では切り替えるきっかけとなった出来事やCloud Buildの設定、注意点について書きます。 はじめに タフな仕事始め その場限りの対応ではなくあるべきを考える あるべきを設計する パイプラインのステップ ステップ1 ステップ2 Cloud Buildの設定 構成ファイルの作成 サービスアカウントの設定 トリガーの設定 開発環境用のプロジェクト 本番環境用のプロジェクト 注意点 cloudbuild.yamlの多段構成は避ける 自前のタグをつけたリ

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

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

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

こんにちは。鈴木です。 ここにシステムを安定させる4000万円の魔法の壺があるとします。 あなたなら買いますか。 はじめに SREやればいいのに 4000万円の魔法の壺 なぜモノタロウはSREに取り組むのか 10分落ちると数百万円、数千万円の影響が出る 不安定なシステムを札束でしばいたことがある 大規模化・複雑化が旧来の運用方法を無効化する SREの導入による効果 会話の中に「SLO」が登場するようになった システムの状態を深く理解できるようになった オンコールの初動対応が早く精緻になった SREの難しさ 組織横断的な活動の難しさ 安定的に時間を使うことの難しさ 利用するツールやサービスの難しさ どのようにSREを導入したのか Googleの最新SREを学んだ CUJを定義した SLIとSLOを定義した Cloud Monitoringでダッシュボードを作成した 役に立つかもしれない話 可

はじめに 自己紹介 はじめまして、コミューンでソフトウェアエンジニアをしています、ひおきと申します。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 Cloud インフラストラクチャの

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

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

君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、

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

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

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

hooks が発表されてから趣味でも現場でもずっと hooks を使っています。おかげでだいぶこなれてきて、だいたいなんのライフサイクルでも表現できるようになってきました。 最初は単に useState が state を、 useEffect が componentDidMount/componentDidUpdate を置き換えるもの、と説明を済ますつもりでしたが、 useEffect についてはライフサイクルのモデルがぜんぜん違うので、別の説明をする必要があるように感じていました。 で、その結果 React Hooks を理解するには、関数のメモ化を理解するのが最も簡単だと思ったので、その説明をしつつ、イディオムを解説していこうと思います。 最初に: React Hooks は何であり、何ではないか 関数コンポーネントが状態を持てるようにするもので、関数のメモ化のテクニックを多用しま

Ruby/Rails でサーバ書いてたエンジニアが、転職後数ヶ月で TypeScript/React/Redux なチームで書けるようになるまでに参考にしたことJavaScriptTypeScriptReactredux 夏に転職して、それまではrubyしか書いてこなかったのですが、 転職後はそれまで全く触ってこなかった TypeScript/React/Redux/Firebase なチームに入って開発できるようになるまでに参考になったものです。 もちろん、実際にはもっと他にも色んなものを参考にしています。 また、ここに書いたものも隅々まで読んだりしたわけではないのですが、振り返ってみて役に立ったなって思い出せるのを書いてみました。 本 りあクト！ りあクト！ TypeScriptで始めるつらくないReact開発 第2版 りあクト！ Firebaseで始めるサーバーレスReact開発 E

新年あけましておめでとうございます。早いものでこの記事を書くのも3回目になります。毎年年頭に更新している「私の情報収集法」について、今年も更新UPします。 ※私の方法はpiyokangoさんが2013年に書かれた「私のセキュリティ情報共有術を整理してみた。」、およびその記事の元となった根岸さんの2011年の「私のセキュリティ情報収集術」の影響を強く受けて、自分なりに試行錯誤しているものです。必ずしも多くのセキュリティ担当の方に向いている情報収集のやり方ではないかも知れません。 ■インプットに使っている情報ツール 情報収集に使っているツールはそんなに変わってません。忙しいセキュリティ担当の方は、いかにRSSをうまく使いこなすかがカギになるのかと思います。 ツール キタきつね寸評 備考（リンク） RSS Reader 去年から海外ニュースを拾うのに使い勝手が良かったので、このソフトを使っていま