チームスピリットデベロッパーブログ

チームスピリット開発者のブログ

エントリーブログ:入社から3ヶ月間のできごと

自己紹介

2022年2月1日にチームスピリットに入社しました、 開発エンジニアの小松原です。

それまでは、SIerにてJavaとSpring FWでWebシステム開発に5年ほど携わっていました。スクラムもSalesforceも全くの未経験です。

入社〜3ヶ月の間のできごと

入社日当日

入社日は会社に出社し、社用端末の設定と就業規則などの説明を受けました。

オリエンテーション

入社後1週間は、荻島代表や各Division Leaderとの個別のミーティングで、時間を掛けて会社の概要について勉強しました。 また荻島代表や各Division Leaderに直接質問できるため、各組織がどのような目的で動いているのかを理解を深める事ができました。

オンボーディング

チームスピリットでは入社から2ヶ月間はオンボーディングを実施しています。 開発エンジニアとしてチームに参画できるようになることがゴールです。

内容としては、

  • プロダクトマネージャーやスクラムマスターより製品(TeamSpirit)に関するプロダクトの紹介
  • 開発プロセスやスクラム運営に関する情報共有
  • 製品のテスト環境を構築
  • システム全体の挙動をシナリオ化しているスルーテストを実施
  • 製品の各機能概要をロールプレイングでメンバーに説明

を行いました。

オンボーディングの感想

入社後のフォローが手厚く、製品の理解から開発チームに参画するまで順調に過ごすことができました。 今回、入社からほぼ100%リモートで作業でしたが

  • Slackを用いたコミュニケーション
  • 各チーム単位でのデイリーミーティング
  • ナビゲーターとのデイリー1on1
  • 他部署のメンバーとのマンスリー1on1

を通じて常に質問を投げやすい環境が整っていたと感じています。 そのため、Salesforce開発に未経験の私でも、無事に開発チームに参画できました。 積極的に周りのメンバーから支援いただけたので、精神的にも助かりました。

ただ、スクラムは説明だけでは理解するのが難しいと感じました。 やはり、実際にチームに加わって体感して理解できてきたという感じです。

スクラムチームへの参画〜実務の開始

入社から約2ヶ月程度経つと、開発プロジェクトのスクラムチームに参加し始めます。 私は開発エンジニアとして、TeamSpiritの新規機能開発チームに入ることになりました。 スクラムチームとしてはこのチームに参画しながら、設計、開発、試験を担当していきます。 このチームの特徴としては、モブプロを積極的に取り入れていることです。 モブプロをすることで、一人でタスクを抱え込むリスクが減り、チームとしての一体感が出ていると感じています。 世の中に自分が携わった機能が出ていき、フィードバックを得られるのでとてもやりがいがあります。

まとめ

研修期間の手厚いフォロー、メンバーの支援があり、とてもスムーズに開発チームに参画できたことに感謝しています。 今後はCI/CD周りにも興味があるので、魅力的な機能を素早く提供できるよう微力ながら尽力していきます。

Webページ性能計測自動化の改善

はじめに

こんにちは。TeamSpritEX開発チームQAエンジニアの長尾です。
Webページ性能計測の自動化のアップデートを行いました。
今回はその内容についてまとめました。

Webページ性能計測について

そもそもWebページ性能計測とはどのようなもの?
→実際にユーザが利用する際のWebページの表示速度を計測する。
というのが一般的かと思います

測定の方法は様々な方法がありますが、今回私が対応したものは、ブラウザにて手動で確認することも可能な以下の時間(Finishのタイム)を想定したもの。

Chromeブラウザのデベロッパーツール

データ計測のメリット

顧客満足度に直結する大事な指標となることは当然のこと、計測データを利用することによって、他の製品との性能比較、ロード時間の長さに関する課題の顕在化など、アプリケーションを開発する上で様々な目的や課題の解決のための指標として利用することが可能と考えています。

Webページ性能計測(自動化)の仕組み

私のチームでは、前述したデータの計測を自動化し、蓄積したデータをグラフ化し開発メンバーに共有しています。ここではその方法について記載します。
今回はgas-webpagetestというGoogle Apps Scriptで動作するパフォーマンス計測ツール使用しました。
また、計測対象となるテスト環境についてはJenkinsを利用し毎日Masterブランチのデプロイを実行し、各チームの修正が取り込まれる状態にしています。

公開されているリポジトリgithub.com

図解すると以下の通り

WebPageTest自動化

改善の背景

実装の仕組みについては前述したとおりですが、
実は、私がチームスピリットに入社するより以前から、既に自動化は運用され計測結果も収集している状態でした。
問題なく動いてはいましたが、運用していく中で改善課題も上がっていたため、今回私の方でその課題に対応するために改修することとなりました。
課題としては主に2点

  • Salesforceの上のパッケージ開発における開発可能な範囲に絞った性能速度の計測ができていない。
  • ユーザーの利用頻度の高いユースケースに対応したテストシナリオになっていない。(初回実行時のキャッシュ無しを想定した計測となっていた)

そのため、まずは現在の自動化の実装フローがどのようになっているのかを理解。その後対応方法を検討していきました。

どんな改修を実施したのか

結果として以下のような対応を実施。

  1. Salesforceのロード時間を除いた計測に変更
     →Visualforceページのみ計測対象とすることで自社内で対応できる機能に絞り込んで計測することができた
  2. ページリロード時の計測に変更(キャッシュ有りの利用を想定)
     →WebPageTestの実行スクリプトを修正し、より利用頻度の高いシチュエーションにおけるロード完了時刻の測定に絞り込むことができた

性能テスト自動化のメンテナンス作業を通して

前述した通り、私が対応し始めた段階ではある程度自動化の仕組みは構築され既に定期実行で計測する運用はされていました。
そのため、途中から運用を引き継ぐ形で対応することとなったのですが、
今まで利用したことのなかったGoogle Apps Scriptを利用した運用方法であったこともあり、
内容を理解するのはなかなか大変でした。

社内の有識者に質問攻めの状態でなんとかやりとげることができましたが、 今回一番やってよかったと思ったのは、トライアンドエラーで何度も実装したことです。
仕組みの全貌を理解できたのは、1つずつ自分で試してみて1通りの実装が終わった段階でした。
引き継ぎの段階で一通りの説明をもらい、その後少し期間が空いてからメンテを始めようと思うも時既に遅し。何をすればよいか全く分からなくなりました。
初回説明の段階で全く理解してなかったからだと思います・・・。
実際にやってもいないのに理解したつもりでいることの怖さを改めて感じるのと同時に、理解したことを実行して身につけることの重要性に気づきました。

苦労した点も多かったですが、結果的に品質基準として定めていたページ読み込み時の速度目標を改定することとなり、
弊社のパッケージ開発の目標としてより妥当な品質基準を設定できたと感じています。

解決できていない課題について

現時点の課題として具体的には以下のようなものが存在しています。

  • 複数バージョンのパッケージ製品の計測に対応していない
     →弊社では同一製品でも複数のバージョンを提供しているため、それぞれに対応した性能テストの自動化を目指したい(現在1バージョンのみ実装)

  • 一定のタイミングで計測が停止、計測ツール(WebPageTest)の計測サーバの混雑度合いなどを考慮できていない
     →定期実行スクリプトが稀に停止しその後計測が止まってしまうことがある

顕在化していない問題も含めるとまだまだ改善の余地があるものかと思うので、今後もこういった課題を1つずつ解決していきたいと思っています。

最後に

性能テストの目的は”ユーザがストレス無く快適に利用できる製品を作りだすこと”だと思っています。
私はQAエンジニアなので、現時点ではこの情報の抽出の部分に注力していますが、当然ながら計測しただけでは意味がないと思っています。

  • 開発エンジニアに性能評価を意識した開発を進めてもらうにはどうすればよいか
  • マーケティングの指標としてどのように活用していけるか
  • 更に効率的な性能テストの自動化の仕組みを検討(利用するツールの統一化など)

などなど、やるべきことはたくさんあると思っています。

テストを実施することが目的になりがちなQAエンジニアですが、
今回のような非機能要件の検証に関わることも、大きなやりがいの一つです。
チームスピリットでは、これ以外にも様々な技術検証を行っているので、
今後もいろいろなことに挑戦していきたいと思います。

Autifyのテストシナリオにラベルを付けて自動テストの管理を始めました

こんにちは。TSEX開発チームの仲です。
2021年もあっという間に終わり2022年になりました。今年もよろしくお願いします。
今回は年末にリリースされたAutifyの機能であるラベル機能を利用してテストシナリオをラベル分けを行って自動テストの管理を開始しました。 autify.com

ラベル機能とは?

2021年12月22日のリリースにてテストシナリオごとに任意のラベルを追加できるようになりました。 https://autify.zendesk.com/hc/ja/articles/4411895830681-2021%E5%B9%B412%E6%9C%8822%E6%97%A5%E3%81%AE%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9

現状の背景として私たちがAutifyの導入を開始して作成したテストシナリオの総数が500シナリオ前後(不要なテストシナリオなども含まれています)あり定期実行を行っているテストシナリオや新機能のテストシナリオを確認することが難しくなっておりました。
この問題を解決するためにテストシナリオにラベル付けを行い管理・運用できるようラベル作成・運用ルールを定義しました。

どのように管理したいのか?

膨大なテストシナリオの中から何をどのように管理したいのかを考えます。

  • 何を: 定期実行や特定のタイミングで実行したいテストシナリオ
  • どのように: いつ作成されたのか・何の機能なのか・外部開発により実装された機能なのか

上記の内容から3つの観点として管理しようと考えました。

  1. リグレッションテストとして定期実行しているテストシナリオ
  2. 現在のシーズン中に開発・不具合修正された機能のテストシナリオ
  3. その他(事前準備を実行するテストなどの円滑に行うためのテストシナリオなど)テストシナリオ

運用の観点で1,3については一意のフラグを付けておけば問題ありませんが、シーズンごとに項目が増えていく2の観点については一つのラベルで運用するのは難しいと感じたため以下の3つの内容のラベルの有無で管理するように考えました。

ラベル機能のルール決めとフラグ付け

上記の観点をもとに参考用のラベル名を準備し、ラベル名の定義とラベル付けのミーティングを行いました。 その中でシーズン内に作成したテストシナリオのラベルのルールとして以下の3種類をラベルとして追加するというルール決めを行いました

  • どのシーズンで作成されたテストシナリオなのか?
  • このテストシナリオのドメインは何か?
  • ベンダー開発により実装された機能なのか?

ルール決めが完了後に、テストシナリオごとにラベル付けを開始しました。 上記のルールでテストシナリオを分類したところ8種類に分類ができたため、各分類ごとにラベル付けのメンバーを割り振り分担してラベル付けを行いました。

ラベル付け結果

ラベル付けの分担を行うことにより500件のテストシナリオの中から260件のテストシナリオにラベル付けを行いました。 また複数人でラベル付けを行うことにより、ルール決めのミーティング含め一時間以内に完了することができました。 抽出前

抽出後

注意点

注意点としてはテストシナリオに追加するラベルを大量に追加しないことを心がけております。
ラベルのルールを大量に作成すると運用時のルール確認に時間がかかってしまうことや。ラベルの存在価値が薄れてしまうことを懸念したため、テストシナリオ内に最大でも4つよりも多くラベルを設定しないように運用を行っています。
画像のようにラベル付けを行いました。

運用結果

現在ラベルの追加を行いテストシナリオの運用を開始しております。運用開始直後でもラベルを検索すれば大量のテストシナリオから指定したテストシナリオのみを抽出できるため、Autifyに新規で携わることになったユーザでも必要なテストシナリオを表示できるようになったと思います。
また他のメンバーが作成したテストシナリオのフラグからどのようなテストシナリオを追加したのかを詳細を確認せずに把握できるようになりました。その中でフラグ管理が正しく行われていないテストシナリオについても一目で確認できているため、修正依頼などを出すことも容易にできるようになっております。 将来的にはテストシナリオから過去のシーズンでどのような機能が追加され、自動テストが作成されたのかさかのぼり、過去に作成したテストシナリオを参考できるようになるのではないかと思っております。

終わりに

前回はテストシナリオの運用ルールを定義して実行して運用を開始したため、その運用ルールを参考にラベルを作成しました。
teamspirit.hatenablog.com
また各ドメインを横断して開発を行うプロジェクトも新たに追加され、テストシナリオを作成するメンバーも増えました。そのためリスト上で何のテストシナリオなのかが明確にできるように運用を行おうと考えました。 今後の課題としては現状は導入開始直後なので今後に課題や運用時に求めていたものが抽出できないという課題が出てくるとは思いますが、現状の運用方法をブラッシュアップしてゆきたいと思っております。

ISTQB Agile Testerを受験してみた

こんにちは。2021年12月からチームスピリットにQAエンジニアとして入社しました橘です。

ISTQBのAgile Testerに今月合格したので、受験までの流れや勉強方法について書いてみたいと思います。

ISTQB Agile Testerとは

まずそもそもISTQB Agile Testerとは何かについて。

ISTQB Foundation Level Agile Tester(以下Agile Tester)とは、ソフトウェアテストの国際的な資格認定団体ISTQB(International Software Testing Qualifications Board)による認定資格で、試験ではアジャイル開発の中でのテスト担当者の役割やアジャイル開発の知識について問われます。

受験には下位資格であるISTQB Foundation Level(以下FL)の合格が必要になります。

Agile Testerの受験方法

Agile Tester試験は2022年1月現在日本語での試験が提供されておらず英語での受験になりますが、日本のテストセンターで随時受験することができます。 以下受験方法になります。受験料は190ユーロ(約2万5000円)です。

※2022年1月時点での手順なので、今後変更がある可能性もあります。

  1. ISTQB試験の提供団体であるBrightestのSign inページでアカウントを作成します。
  2. 試験カタログからCTFL-AT: ISTQB® - Certified Tester Foundation Level - Agile Testerを検索して選択します。
  3. 試験の受験場所を聞かれるので、「At a test center」を選択します。
  4. 受験の際の言語を聞かれるので、「English」を選択します。
  5. training providerを選択し、re-sit(再試験)であるかどうかを回答します。training providerについては僕の場合は自習での受験だったので「No Training Provider (Self-Study)」を選択しました。
  6. Consecutive Appointments(連続して試験予約)をするかどうか聞かれるので、そのまま「Next」で次の画面に行きます。
  7. Admission PolicyやReschedule Policyなど諸々のポリシーが表示されるので、読んでから「Agree」で次の画面に行きます。
  8. 当日の受験場所であるテストセンターを選択します。東京の場合は新宿、池袋、秋葉原など各地のテストセンターを選択できます。
  9. 試験日と開始時間を選択します。カレンダー上で選択可能な日付と時間が表示されるので都合のいい日時を選択します。
  10. 申し込み内容を確認し、「Proceed to Checkout」で支払い画面に行きます。
  11. クレジットカードを選択し、各種情報を入力して支払いを行います。

Agile Testerの試験内容

https://www.istqb.org/certification-path-root/agile-tester.htmlのシラバスに沿って

  1. アジャイルソフトウェア開発
  2. アジャイルテストの基本的な原則、プラクティスおよびプロセス
  3. アジャイルテストの方法、技法、およびツール

の3分野から選択式の問題が40問出題され、65%(つまり26問)以上の正解で合格となります。

試験時間は60分です。なので1問あたり1分〜1分30秒で解答する必要があります。英語なのもあってあまり時間に余裕がありません。

※公式サイトによると英語が非母国語である場合は試験時間が15分追加されて75分に延長されますが、僕の受験の際はこの追加の15分が試験チュートリアルやアンケートに充てられていたようで、結局解答時間は60分でした。

なお試験終了後に紙でスコアレポートを受け取れるので試験結果はすぐに分かります。

Agile Testerの勉強方法

ここからはAgile Testerに受かるために自分がどのように勉強したかを書いていきたいと思います。

Agile Testerの試験勉強にあたって、以下のものを参考にしました。

勉強の方針としては、

  • 解説動画シリーズを見てシラバスを全体的に頭に入れる。
  • 動画視聴と並行して日本語版シラバスを読んだり、サンプル問題を解いたりする。
  • How to prepare and pass ISTQB® Agile Tester Extension Certification Examに書かれているExam Tipsを参考に特定の分野を重点的に学習したり、ネット上で用語を調べたりする。

という感じでした。

シラバスの内容は割と抽象的だったりするので、動画視聴中・シラバス読み込み中でも早い段階からサンプル問題を解き、さらにサンプル問題の解説も公開されているので解説もよく読んで理解を深めるようにしました。

試験勉強のTips

How to prepare and pass ISTQB® Agile Tester Extension Certification ExamのExam Tipsから今回の僕の受験で特に助けになったものをいくつか簡単に紹介します。

  • シラバスは3・4回は読んで理解する。試験ではシラバスにある用語や概念についてよく覚えて理解していないと解けない問題が出るため。
  • シラバスのアジャイルマニフェストは暗記する。
  • アジャイル開発のアプローチのうちスクラム・カンバン・XP(エクストリームプログラミング)について、たとえば選択肢のうちXPのプラクティスに含まれないものを選べといった形で出題される。そのためこれらのアプローチについて理解しておく必要がある。
  • 「早期かつ頻繁なフィードバック」および「ふりかえり」のメリットを理解する。
  • アジャイルテストの四象限について出題される。
  • テストピラミッドについて出題される。
  • シナリオが与えられ、適切なテストケースやテストアプローチ、テスト技法を選択する問題が出題される。
  • アジャイルチームにおけるテスト担当者の役割について出題される。

これらに加えて僕が気づいたことや必要だと思ったことを挙げると、

  • 試験勉強について
    • シラバスにある用語や概念については、シラバスだけでなくネット上の記事を読んだり、余裕があれば本を読んだりした方がいい。
    • 下位資格であるFLの内容を前提にした出題がよく見られる。
    • サンプル問題と全く同じ問題は出題されない。
    • アジャイルにおいてチーム全体アプローチ(whole-team approach)が重視されることを根拠に解答する問題が出題される。
    • プランニングポーカーのやり方や考え方について出題される。
  • 問題・試験形式について
    • 解答は1つ選ぶ場合だけでなく複数選ぶ場合もある。
    • 見直しをする時間があまり取れないので、なるべく1問に時間をかけすぎずテンポ良く次々と解答するようにする。
    • 選択肢の選ばせ方について表現が多彩なので、どのように指定されているのかに注意する。例:
      • TRUEなものを選ぶ
      • TRUEでないものを選ぶ
      • 最も期待されるもの(MOST expected)を選ぶ
      • 最も期待されないもの(LEAST expected)を選ぶ
    • onlyやdon't need toなどがある限定的だったり否定的・消極的だったりする選択肢は少し疑った方がいい。

といった感じです。

英語ではありますが、問題のほとんどはあまり長くなく解答もシンプルなものが多いため、勉強すれば受かりやすい試験なのではないかと思います。

参考にした記事・書籍

最後に、試験内容の個々のトピックを学習する上で参考にしたWeb記事や本を紹介したいと思います。

スクラム

SCRUM BOOT CAMP THE BOOK【増補改訂版】 www.amazon.co.jp

ユーザーストーリー

アジャイル開発におけるユーザーストーリーとは?その目的や作成方法を紹介 https://crowd.itpropartners.com/pieceblog/4134

INVEST技法

ユーザーストーリーの”INVEST”とどう付き合うか https://guildworksblog.wordpress.com/2015/06/03/how_to_deal_with_invest_of_userstory/

アジャイルテストの四象限

アジャイルテストの4象限とテスト自動化のピラミッド https://notta55.hatenablog.com/entry/2015/05/03/161631

テストピラミッド

テストのピラミッドを開発者と一緒に眺めてみよう! https://dev.classmethod.jp/articles/testing_pyramid/

プランニングポーカー

みんなで見積もれ!アジャイルな見積もり手法「プランニングポーカー」のやり方 https://www.mof-mof.co.jp/blog/column/agile-estimation-planning-poker

以上、参考になれば幸いです。

【2021年版】プロダクトディベロップメントチーム解体新書!(技術・開発環境編)

はじめに

皆さんこんにちは!エンジニアリングマネージャの生井( id:riririusei99 )です。
今回は、2017年に行ったプロダクトディベロップメントチーム解体新書!(技術・開発環境編)のリバイバル企画ということで2021年版を作りました。

teamspirit.hatenablog.com


今回はサービスデベロップメントディビジョン(以下、SDディビジョン)メンバーに向けて、Microsoft Formsを使いアンケートを行い、結果をまとめています

 

アンケート結果

Q1.あなたの役割を教えて!

SDディビジョンでは、働き方改革プラットフォームとして"TeamSpirit"とエンタープライズ向けの"TeamSpirit EX"の二つの製品を主軸とした製品開発を行っており、日本とシンガポールの二つの開発拠点で協力して開発しています。

また、ディビジョンの中には開発エンジニアだけでなく、プロダクト開発に関わる様々な役割のメンバーがいますので、それぞれがどんな役割をしているのか聞いてみました!

2021年

f:id:riririusei99:20211221115707p:plain

2017年

f:id:riririusei99:20211221100110p:plain

 

こうしてみると人数規模は2017年の21人から現在60人に増えていますがメンバーの構成比は大きく変わらない感じですね。

QAエンジニアが多い組織だったりしますので、QAエンジニアの業務範囲が広かったりするのも他の組織に比べると特徴の一つなのかと思います。

また、サーバサイドエンジニア&フロントエンドエンジニアを積極採用中ですので、興味がある方はぜひ採用サイトに目を通していただければと思います!

 

エンジニア採用情報 | チームスピリット キャリア採用サイト

 

 

Q2.仕事で使っているキーボードを教えて!

続いて、みんなどんな環境で仕事をしているのでしょうか?
2020年から在宅がメインで仕事をする様になりましたが、その影響が質問であるどんなキーボードを使っているのかに反映されるのか確認していきましょう!

2021年

f:id:riririusei99:20211221115450p:plain

2017年

f:id:riririusei99:20211221103215p:plain

 

在宅勤務を通してキーボードを使ってるメンバーが半数以上に増えているのがわかります。

また、前回の調査ではキーボードを使う派Rralforce, Happy  Hacking Keyboard, Magic Keyboardに分かれていましたが、2021年現在では沢山の選択肢があることが分かりますね。

 

メンバーがどんな机で働いているか一例を紹介します!

f:id:riririusei99:20211221122311j:plain

メンバーそれぞれのこだわりが作業机に見られます

 

 

Q3.仕事で主に使っているエディタを教えて!

2017年にはエディタに関する話は鉄板ネタだったと思っていて、Slack上で最強エディタをめぐる覇権争いをしていたこだわりのエディタ議論。2021年の勢力図はどうなっているのでしょうか?

 

2021年

f:id:riririusei99:20211221135827p:plain

2017年

f:id:riririusei99:20211221125836p:plain

この4年間でエディタの勢力図がガラッと変わっており、Salesforce開発のエディタといえばVisual Studio Code(以下 VSCode)という状況になっています。

というのも2019年の10月をもって、最大派閥だったEclipse用プラグインのサポートが終了し、その移行先として推奨されたのが VSCodeでした。

 

参考: Salesforce ヘルプ:2019 年 10 月に廃止される Force.com IDE

 

また、Salesforce開発者向けトレーニングプログラム(Trailhead)では推奨されているエディタとしてVSCodeのコンテンツが用意されているため、新たにSalesforce開発を始める人・特に強いこだわりがない人はVSCodeを使っているため、上記のような結果になっていると考えられます。

 

trailhead.salesforce.com

 

また、この質問では「使わない」という人の割合が増えたのもポイントです。

以前は開発エンジニアが中心の組織だったためエディタの質問をしていますが、現在ではテクニカルサポートやグローバルコミュニケータなど様々な職種の人が在籍し、全員が全員エディタを使って仕事をする人だけではなくなったので、チームの多様性が反映された結果になりました。

 

あなたの好きな言語を教えて!

2021年

f:id:riririusei99:20211221152706p:plain

 

2017年

f:id:teamspiritinc:20171219151606p:plain

前回のアンケートと同様JavaScriptとJavaが上位にいますね。
私たちが使っている言語はApexと言ってJavaに似たプログラミング言語を使っています。(前回のアンケートでApexが上がってこないのが気になりますが…。)

 

最近興味のある技術分野を教えて!

2017年の記事ではこの質問に対してこんなことが書かれていました。

「最近興味のある技術分野」のところで、無理にまとめてはいけない(まとめられない)ことに気づきました。

過去の失敗を踏まえ、メンバーの気になる分野をまとめることは非常に難しい挑戦だということを知り、まとめることを早々に切り上げ、ここではツールの力に頼ってそれっぽい物にしようと思います。

ということで、アンケートの自由回答欄を元にワードクラウドを作成しました。

f:id:riririusei99:20211221155625p:plain

ワードクラウド

改善するためのツールだったり、Saleforceの最新のサービスだったり、AWSのサービスだったり…色々入ってますね、この辺は見る人の感性によって着眼点が違いそうなので、ぜひぜひにらめっこしてみて下さい。
自分が見ると、テスト系のツールが目に着いたので嬉しい限りです。

 

 

まとめ

いかがでしたでしょうか。時間の流れに伴って、変わっている物と変わっていないものをアンケートを取ることで確認することができました。私たちチームスピリットの開発チームの雰囲気を掴む参考になれば幸いです。

また、前回実施時はQAエンジニアとして参加したこの企画を、今回は運営側に回って集計することになったので…何というか、時間の流れみたいな物を感じました。

この記事を書くにあたり、当時のマネージャの苦労だったり心境を垣間見ることができたので、当時の記事を執筆した松田さんには感謝の気持ちを遅ればせながら表したいと思います。本当に感謝です。

 

最後に

この投稿はチームスピリット Advent Calendar 2021 - Adventar 第23日目の投稿になります。毎日面白い投稿が行われていますので、ぜひ最後までチェックしてください!

 

adventar.org

 

 

最後までお読みいただきありがとうございました!

おわり

 

 

 

2021年のSalesforce Saturday 京橋 をふりかえり

こんにちは。TSFエンジニアリングチームの田中(美)です。

2021年最後の Salesforce Saturday 京橋 を 12月18日に行いました。 sfsaturday-tokyo-kyobashi.connpass.com

おかげさまで、今年は計6回のもくもく会を行うことができました! ひとえに、参加してくださった皆様のおかげです。ありがとうございます!

この記事は チームスピリット Advent Calendar 2021 の20日目 の記事です。 adventar.org


ふりかえりのきっかけ

Salesforce Saturday 京橋 は今年から、弊社エンジニアの畑本さんと二人で始めました。 (始めた時の感想はこちらに書きました。) 畑本さんは以前から様々なSalesforceコミュニティで活躍しており、Salesforce Saturday 京橋の運営においても手腕を発揮しています。 私自身は今回初めて運営業をやってみて、不慣れな点もあり反省することもありました。 そこで、来年もより良い運営を行いたい、反省点を次につなげたいと考え、 Salesforce Saturday 京橋 のふりかえり を企画して実施しました。

ふりかえりの手法と実施

今回のふりかえりは、「Good, Bad, Ideas, Action」 という手法で実施しました。 次に繋げるという点を重視して、ふりかえりカタログ / Retrospective Catalog - Speaker Deck から合いそうなものを選びました。 詳しい内容は以下を参考にしてください。 www.goretro.ai

参加者は私と畑本さんの運営二人です。 オンラインで Cacoo を使いながら、意見を出し合っていきました。

ふりかえりの結果

私達のふりかえりの結果は以下のようになりました。

f:id:mh-tanaka:20211218191620p:plain
ふりかえりの結果

Good

様々な人が参加してくれたことが、一番最初に出たトピックでした。 本当に参加してくれた方々には感謝です。 また、運営として継続して取り組めたことも良かった点にあげられました。

Bad

Badというよりも気になることがいくつかあげられました。 例えば、参加者の方に負担がかかりすぎていないか などです。 もくもく会として実施しているので、参加者のみなさんが適度に集中して自習ができているかなどは今後も継続してウォッチしていきます。

Ideas

実行できるできないは考えないで、アイディアを出し合いました。 オンサイト開催の場合のアイディアや、オンラインでどうやってコミュニケーションを増やすかという観点のアイディアが出ました。

Action

来年はオフィスで Salesforce Saturday 京橋 を開催する!! というのが運営二人ともが合意したアクションです。 オンサイトのコミュニティ活動にお世話になってきた身としては、やはりオンサイトでも実施してみたいですね。 オンサイトの方が、偶発的なコミュニケーションが生まれやすいと感じています。 参加者にとって良いフィードバックが得られる機会を増やしていきたいです。


来年の活動について

次回は2022年2月に活動を予定しています。 今回のふりかえりの結果を元に、少しずつカイゼンしていきます!

f:id:mh-tanaka:20211218190808p:plain
Salesforce Saturday 京橋 #6 参加のみなさん
再度になりますが、Salesforce Saturday 京橋 に参加してくださった方、応援してくださった方、本当にありがとうございました!! 来年もどうぞよろしくお願いいたします!

Dreamforce2021 Global Gathering Tokyoで 第二世代パッケージを導入した話を発表しました。

こんにちは!EX開発部の佐藤(諒)です。 11/26にSalesforce Developer Groupの「Dreamforce2021 Global Gathering Tokyo」が行われ、 そこで TeamSpirit EX を最新技術 2GP(第二世代パッケージ)化した話を発表してきました。

こちらは チームスピリット Advent Calendar 2021 - Adventar の18日目の記事です。 adventar.org

発表の様子

昨今の情勢もあり、ほとんどの方はリモートで参加されておりましたが、 ちょうどコロナが落ち着いてきた関係もあり、社内で発表をすることができました。 その時ちょうど社内で懇親会を開いていた関係もあり、会社の部署問わずに話を聞いていただけました。

発表の様子

発表内容について:第二世代パッケージの導入・効果・運用

発表の内容はTeamSpirit EXに第二世代パッケージを導入した際の導入方法・導入の効果・導入後の運用方法を包括的に発表しました。 導入の方法や導入の運用法はスライドを見ていただくとして、 ここでは特に印象に残っている導入後にどのような効果があったのか、 またこれからどうするのかを実際のエピソード・開発段階の会議を交えながら紹介したいと思います。

speakerdeck.com

導入の効果

シンプルにパッケージングをCIで自動化し、パッケージングの作業時間を短縮した以外にもメリットがありました。 特に第一世代パッケージの「運」要素が無くなったことは大きなメリットでした。

パッケージングには「運」が必要?

第一世代パッケージでは、ベータパッケージを作成するにはパッケージ組織に資産をデプロイして作成する必要がありました。 開発中の資産でもパッケージ組織に資産をデプロイすれば、パッケージングを行えるかをテストすることは出来るのですが、 それを行うと本番パッケージを作成する前に開発中の資産がデプロイされていないことを目視で確認する必要があります。 特に開発中に不要になった資産があると、その資産をパッケージ組織から依存関係に注意しながら手動で削除する必要がありました。 そのためパッケージ作成のテストを開発中に行うことはできませんでした。

そのためパッケージングは全てのQAレビューが完了した後に初めて行う、 言わばぶっつけ本番の状態になっておりました。

もちろんパッケージングで行われるユニットテストなどはCIで毎日行っておりますが、 パッケージングの段階で名前空間に関する違いなどでユニットテストが失敗して3~4時間かかるテストを最初からやり直しといった問題もあり、 パッケージングには「運」が必要とまで言われることもありました。

運要素不要な第二世代パッケージ

第二世代パッケージでは、パッケージ作成にパッケージ組織にデプロイを行うことは不要になり、 単にコマンドを打つだけで既存のソースを元にパッケージを作成することが出来るようになりました。

そのためリリース前に限りますが、 第一世代のようにパッケージ作成組織を目視確認や手動で削除といったことは必要なく、 開発中に不要になった資産についてはリポジトリから削除すれば 次回のパッケージではその資産が削除された状態でパッケージが作成されるようになります。

これによりパッケージ作成を何回でもやり直すことができるようになり、 第一世代の時のようにぶっつけ本番では無くなりました。

チームスピリットではCIでパッケージ作成を毎日行うことで、 パッケージが作成できるのかどうかを毎日テストしております。

これにより、「運」要素を無くすことができるようになりました。

第二世代パッケージのこれから

現在のパッケージを第二世代パッケージにすることだけでもメリットはありますが、 第一世代パッケージになかった新しい機能を利用することでさらに開発を進めていきたいと考えております。

モノリスからの脱却

第二世代パッケージは @namespaceAccessible という同一名前空間のパッケージ間で Apex コードを共有できる機能があります。 この機能を利用してパッケージを複数のパッケージに分割して行くことが可能になりました。

将来的にはこの機能を活用することで現在モノリスになっているパッケージを分割し、 パッケージの作成範囲を絞ってリリースすることができるようにしたり、機能開発のスピードを上げていきたいと思います。