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

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

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

こんにちは、れいしきです。 初心者の方にとって、WoTのMAPの多さはかなり凶悪ですよね。グランドバトルMAPを除いでも約40MAPもあり、その上陣地も2つあるわけですから、80ものパターンがあるわけです。更に更に、乗る車種によって初動ポジも全く異なるので、もう手のつけようがありません…。 そこで、ランダム戦通常戦における各車種の初動ポジションをご紹介したいと思います！目次から飛んでいってもらえればすぐ見れると思います＾＾ 紹介する初動ポジションは僕がランダム戦を22,000戦以上やって見てきたポジションです。ですが、必ずしもこうなるとは限りませんのであくまで目安として受け取ってください。 また、僕が知らないだけで超強いポジションもあると思いますので、そういう時は是非Twitterで教えてくれると非常にありがたいです。 構成が異なれば当然形が変わりますが、大体は同じ感じになると思います。あ

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

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

はじめにこれは何？ 数カ月間マーケット調査、商談をして見えてきた日本とグローバルでSaaSプロダクトに求められることの違いを紹介する 誰向けの記事？ グローバルで利用されるプロダクト開発に興味のあるPdM, エンジニアの方 まとめると？ 競合がエグい。日本はプロ野球で、グローバルはメジャーリーグみたいなイメージ。プロダクトは広く浅く→狭く深くに要件が変わる。 エコシステム、SaaS市場の成熟度の違いから、インテグレーションファーストになる 時差や人件費の違いがプロダクトに影響を与え、セルフサービス前提の設計になる 伝えたいこと グローバルで使われるSaaSプロダクトづくり（＝メジャーで野球する）、そしてそこで勝つためのプロダクト・開発組織づくりに経営者として本気で取り組みます。 メジャーで勝利するために、優秀なメンバーが集まり、切磋琢磨し、成長できる環境。勝ち筋も見えています。他ではできな

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

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

【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! 現状の分析 まずは課題の把握や施策の優先順位を決めるために現状を分析します。 既存メンバーへのヒアリング 何も仮説を持

ヤフーという大手企業を退職し、なぜ次にコミューンを選んだのか、そして、すでに動き出しているコミューンの海外展開へ向けての開発の現状をお伝えします。 東京工業大学大学院博士課程を単位取得退学し、新卒でヤフー株式会社にWebエンジニアとして入社。複数のサービスの開発に従事した後、広告部門で社外API連携や広告閲覧履歴DBの移行やSRE導入、新人教育などを経験。2021年11月にコミューンへ入社し、グローバル化プロジェクトの開発を担当している。 ※記事の内容は執筆時点の内容です。前職ではエンジニアとして幅広い経験をした後、新人の教育担当として試行錯誤していました。ヤフーの広告部門はGoogleやMetaといったグローバル企業が競合なので、淘汰されないためには世界レベルの開発の速度と品質が必要です。一方で、巨大で安定した組織が持つ長所や限界についても考えるようになりました。そんな意識の変化が社外に

この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性

こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 これまでは、中村の記事で宣言した 「医師版Stack Overflow」(12/16に正式名称Docpediaとしてリリースされました) の技術的チャレンジの 記事を続けて書いていたのですが、今回はここで宣言しなかったClean Architectureについて書きます。 浪江駅（なみええき）は、福島県双葉郡浪江町にある、東日本旅客鉄道（JR東日本）常磐線の駅。本文には特に関係ありません。 Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,高木 正弘出版社/メーカー: ドワンゴ発売日: 2018/08/01メディア: Kindle版 なぜ書くのか 参考にできる実例を増やしたい Tech Blogはそのままドキュメ