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

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

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

2021年9月1日にチームスピリットに入社しました。 QAエンジニアの長尾です。

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

入社日当日

入社した9月1日は、緊急事態宣言発令中であったこともあり、会社には出社せず事前に郵送していただいた社用端末を使い自宅から社内のミーティングに参加、オリエンテーションを受けました。
こういった状況下で、入社の手続きまで全てリモートで対応できる体制が整っていることは素晴らしい!
と、個人的には思っています。

オリエンテーション

入社後1週間は、荻島代表や各Division Leaderとの個別のミーティングで、時間を掛けて会社の概要について勉強する機会がありました。
自身が会社におけるどのような立ち位置でどういったことが期待されているのかがより明確になったので、モチベーションアップに繋がりました。

オンボーディング

チームスピリットでは入社から1〜3ヶ月の期間で社員教育のためのオンボーディングを実施しております。
その後、開発チームでの研修からOJTと進んでいきます。
では、そこでは何をやっていたのかというと、
まず最初に、プロダクトマネージャーやスクラムマスターより製品(TeamSpirit)に関するプロダクトの紹介や、
開発プロセスやスクラム運営に関する情報を共有していただくと共に、実際にテスト環境を構築しプロダクトに関する知識を深めていきました。
その後、システム全体の挙動をシナリオ化しているスルーテストを実施し、個別の機能に関する理解度を深めていきました。

オンボーディングを通して感じたことですが、率直に入社後のフォローが手厚いと感じました。
今回私の場合は、入社からほぼ100%リモートで作業するという形ではありましたが、
・Slackを用いたコミュニケーション
・各チーム単位でのデイリーミーティング
を通じて状況をヒアリングして頂いていたこともあり、常にリアルタイムで質問を投げやすい環境が整っていたと感じています。
そのため、Salesforce開発に関する知識も経験も無かった私でも、”分からなくて進められずどうすれば良いか分からない”といったことは全くありませんでした。
環境が整っていることも当然ありますが、
積極的にフォローしようとしてくれる周りのメンバーの姿勢が一番大きかったのかなと感じています。

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

入社から約2ヶ月程度経ち、開発プロジェクトのスクラムチームに参加し始め少しづつ実務に入っていきました。
私はQAエンジニアとして、主にオフショア開発案件の品質保証を担当する予定となっていたので、スクラムチームとしてはこのチームに参画しながら、開発担当の作成したテスト仕様書のレビュー、受け入れテストの計画&実施を担当しています。
一部開発のオフショア化については、チームスピリットとしてまだプロジェクト発足後間もない状態で、これから作り上げていくことになります。
他メンバーにフォローしていただきながらではありますが、こういった仕事を任せてもらえることについてはとてもありがたいですし、今後もやりがいを持って仕事ができるなと感じています。

また、オフショア開発とは別に、プロダクト毎のスクラムチームに依存しないチームスピリットのQAエンジニアとしての業務にも今後は積極的に挑戦していく予定です。
APIテストの構築、テスト自動化、QA全体のテストプロセスの改善など。
やりたいこと、挑戦できることが多すぎて、1つ1つ進めて行くことになりそうですが、
QAエンジニアとしてのキャリア形成には十分すぎるほどの課題と挑戦できる環境が整っていると思いました。

まとめ

まずは、研修期間の手厚いフォローには感動しました。
(ここまでやってくれる会社はあまりないのでは?と思いました。)
じっくりと学ぶ時間がもらえたので、実務にスムーズに入ることできました。

またQAエンジニアとしては最高の環境でキャリアを積める場所だと思いました。
開発担当が作ったものをテストすることが目的となることが多いQAエンジニアですが、
実際に求められているのはそういったスキルばかりではありません。
マネジメント、テストプロセス改善、テスト自動化、非機能要件テスト計画、など。
今のチームスピリットでは、おそらく全部できます。
そもそも、プロダクトの開発に直接関わることの少ないQA担当として、
開発エンジニアと密接に関わりながら、自分でテスト環境を構築したり、
APIテストや自動テストを設計、実装する必要がある環境はあまり多くないと思います。

自分で手を上げればどんなことにも挑戦できる、そんな企業だと改めて思った3ヶ月間でした。

エンジニアで開発していた私が、プロダクトマネージャーで無双できるか?

こんにちは。

株式会社チームスピリットの古川(id:furukawa-hisakatsu)です。

今回は技術的な話ではなく、実体験をベースにプロダクトマネージャー(以下PM)になった際に、どういった心構えを持ったほうが良いかについての内容になります。
ちなみに手法やHow toに関してはあまり触れないのでご注意ください。
ちなみに魔法を使う異世界にいったり、神様からチートを貰う話でもございません。

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

え!来月からPMですか!?

PMという職に関してはトントン拍子で上がっていくものではなく、
自らPMになりたいと学び、ポストが空いたところを狙ったり転職をしたりするケースや、
元々製品を初期から開発したことでPMに近しい事をしていたケースが多いかと思います。(※ 個人的な感想です)

ただ、これとは別に突如「来月からPMね」と言われることも社会人生活をする場合はまあまああったりします。
理由も千差万別で、新しいプロダクトを立ち上げたいから抜擢されたり、
前任の人が退職することにより採用が決まるまでの穴埋め要因であったり(大抵の場合はずっとそのまま)、
元々PMというポジションがないところを追加したり、
トラックに追突されたり、謎の魔法陣に召喚されたり、
といろいろあったりします。

ただ、色々あるにせよPMという立場になる以上は、プロダクトの今後を決める人になるため、
プレッシャーはあるかもしれませんが、後述する心構えを持ってプロダクトの一生に関わりましょう。

え!結論からですか!?

だらだらと内容を書いていると「👺結論が遅い」と言われそうなので、まず結論から。

  1. 本当にやるべきことに絞るため、それ以外のことは勇気を持ってやめる/やらない。
  2. 苦渋の選択があるかもしれないが、やると決めたことをは覚悟を持ってやる/決める。
  3. その情報はプロダクトにも影響があるかも?情報とプロダクトの関連性は意識する。
  4. そのリリースは誰のため?ビルドトラップには注意しよう。

今回はこの4本となります。他にあるかもしれませんが私が思いつく内容としてはこれが精一杯。

1. え!このタスク/不具合をやるかどうかを決めるんですか!?

まず、PMになって初っ端に来る可能性が高い作業として、降り掛かってくるタスク/不具合の優先順位を決める仕事があります。
特にエンジニアを熟練している場合になりますと、このあたりの作業はマネージャから依頼され、やるかやらないかではなく、やれと依頼されるケースが多いかと思います。
ただ、PMとなったからには全てのタスク/不具合をこなすことは現実的に無理とわかってしまい、どうするかが求められることとなります。
「うぅ~...判断なんて難しいよ...責任者に渡したいよ...」と言いたいところですが、責任者は自分でしたね。
というわけでプロダクトやエンジニアのためにも旗振りしてやるべき事を決めていきましょう。

また、場合によっては対応しないことや、面倒な機能を削除するも重要になります。
むしろプロダクトマネージャーとして持つべき必要がある重要な考えたど私自身が思っております。

2. え!これでよろしいですかの判断をするんですか!?

実際に作業を進めるとなるとエンジニアからこれでよいかの判断が来ます。
プロダクトの方向やロードマップを決める事となったとしても不安点は残ったままかもしれません。 また、前述にてやらないことを決めましたが、やらないと決めた事に関しても引きずることがあるかもしれません。

ただ覚えておいて欲しいのは、そこで判断したということは貴重であり、プロダクトの意思でもあります。 そのため、その意志を常に貫けるように、やることを決めた場合は、覚悟を持ってリリースしましょう。
(まぁ間違った場合はごめんねと謝って次に活かしましょう)

3. え!この問題うちにも影響あるんですか!?

世の中のどんな情報がプロダクトに影響があるかも意識する心構えを持つと、色々なことに先手を打つことが可能となります。

TeamSpirit では 勤怠や経費 のプロダクトがございますが、関連する情報としては法改正が一番考えられます。
それ以外としてはテレワーク等のトレンド、他社製品のリリース情報等にも目を配らせる必要があります。 それだけではございません。何らかの他社製品の障害や変更情報があった場合でも、何らかの影響があるかもしれません。

常にアンテナを貼っておくのは難しいかもしれませんが、確認できた情報から「うちの製品になにか影響が無いかな」と思う心構えは持ったほうがよいですね。

4. え!プロダクトの方向性を無視してリリースを!?

PM界隈でよく言われる用語の中に「ビルドトラップ」という用語がございます。

特に他部署から言われることが多いのですが、お客様からこんな機能がほしい、こんな画面にしてほしいといった内容や、
最近これが流行っているからこの機能がほしい、数!とりあえずリリース機能数をいっぱいにしろ!等、様々な事を言われることがあります。
それをそのままリリースしてしまうことにより、前述の要望は満たされるのですが、本当にやりたかったことがやれずに、大抵が個別要望に近い形であるため、大多数のお客様は満足しないといった結果になることもあります。

これ以上は会社での力関係にも関わる部分になるかもしれませんが、忘れてはいけないのがプロダクトの責任者はPMです。
とはいえ、すべてをはねつけるのもあれでしたら、大本の問題点を精査して他の会社にとっても良い機能を提案したりするのも良いかもしれないですね。

え!もう終わりですか!?

簡単な内容にはなりましたが、エンジニアからPMになった場合、エンジニアでのマインドセットを変更しないといけないことが多々あるかと思います。 ただ、プロダクトの一生を見ていくことは色々な意味で良い経験となりますため、各々が心構えを持って挑んでいければと思います。

あと、最後に TeamSpirit では プロダクトマネージャーの採用も行っております。 また、シンガポール法人も採用はしておりますが、異世界での採用は行っておりません。

recruit.teamspirit.com

Partner Intelligence Starter Packのはじめかた

こんにちは。TeamSpirit開発チームの畠山です。
今回は今年の9月に開催されたDreamforce 2021にて発表されたPartner Intelligence Starter Packについてご紹介いたします。 当セッションは以下のSalesforce+のURLより見ることができます。弊社テクニカルサポートの手島も登壇しておりますので是非ご覧ください。

www.salesforce.com

Partner Intelligence Starter Packとは

2021年9月3日にリリースされたAppExchangeで提供されているLabAppの1つで、同じくAppExchangeで公開したSalesforceアプリケーションの利用ログをAWSと組み合わせて簡単に取得できるようになるアプリケーションです。 TeamSpiritではリリース以前よりパイロットとして本アプリケーションの利用を開始し、ログ取得の仕組みを大幅に改善することができました。本記事では導入に至った経緯、具体的な仕組み、従来方法と比べて改善された点、実際のセットアップについてご紹介します。

Salesforceアプリケーションのログ取得の問題点

まず、Salesforceでは通常どのようにログを取得するのかご説明します。 ログ取得までのデータフローは以下のとおりです。

出典 : ISVforce ガイドよりAppExchangeのApp Analytics のデータフロー

ここで問題はAppAnalyticsQueryRequestの部分です。ログの取得には都度ログ取得リスクエストをSalesforceに行う必要があり、リクエストにはクエリが15分以内に完了しなければならない且つ24時間に取得するログの容量20GBまで、さらに取得できるのは過去1ヶ月までという制限があります。

リクエストはAppExchangeで提供されているApp AnalyticsアプリケーションにてAppAnalyticsQueryRequetsオブジェクトにレコードを追加するか、APIを直接呼び出して行います。そうすると数分後にログのダウンロードリンクが取得できるためそこからログを取得する形になります。

このリクエストとダウンロード手動で毎日行うのは手間がかかります。さらに、ログを取得しようとしているアプリケーションに大規模な登録者基盤がある場合1日のログ容量は20GB(※)を超えます。実際にTeamSpiritでは1回のリクエストが15分以内に完了するためには1日のうち30分程度のレンジに絞る必要があり、必要なリクエスト数は非常に多くなっていました。そこで以下のような仕組みを作成してログの取得を行っていました。

Partner Intelligence Starter Pack導入前に構築していたログ取得自動化方法

具体的にはログ取得状況を管理するカスタムオブジェクトを作り、これに従ってEC2に作成したバッチが日次で動作して必要なデータを抽出した上で自組織のカスタムオブジェクトへ書き戻してレポートで閲覧する仕組みがありました。

ここで蓄積されたデータは弊社のカスタマーサクセスで活用され十分に有効性が確認されていました。そこで開発チームでも利用をはじめようとしたところで新たにいくつかの問題が上がりました。 それは大容量のため取得時間も長いことや、取得の失敗が起こるたびにリトライが追いつかなくなる事態があること、また当初はカスタマサービス向けの情報が目的であったため完全なログが残らず後から別の情報を取り出すことが出来ませんでした。

これらの改善に乗り出したのが今年の7月頃で、ちょうどその頃TeamSpiritではSalesforceと協同でAnalyticsの有効活用に向けて話し合いが行われていました。そこで上記の問題を相談したところ、Salesforceのエンジニアの方を紹介していただき提案されたのがPartner Intelligence Starter Packのパイロット版であり、先行で利用させていただく事になりました。

Partner Intelligence Starter Packを導入

実際に導入してみるとPartner Intelligence Starter Pack(以下、PI App)はTeamSpiritが構築したようなログ取得の仕組みを簡単にセットアップでき、且つ効率化された方法で上記の問題点を解決してくれるものでした。具体的な構成は以下のとおりです。

Partner Intelligence Starter Packのアーキテクチャ

このうち、QuickSightを除くAWSの部分は提供されるCloudFormation設定によって全自動で構築されます。組織にインストールしたPartner Intelligence Starter Pack本体と合わせて動作し、毎日のログ取得からマニュアルでの期間を指定したリクエスト、リトライまでSalesforce側で制御することができるようになります。取得したログはS3に蓄積され、Athena、QuickSight、TablaueCRM等のデータソースに利用できます。

改善ポイントその1 : バッチ処理のサーバーレス化

まずEC2で行っていたバッチ処理はEventBredgeから起動されるStepFunctionsで処理されます。サーバーレス化されたことによりコストが大幅に低下した上、実行ごとにコンソールからビジュアルで動作ログを追うことができるようになりメンテナンス性も向上しました。

AWSコンソールで見たStep Functionsの実行画面

改善ポイントその2 : ログの容量低下

App Analyticsのログ形式はSummer'21までcsv形式しかありませんでした。しかしSummer'21からはParquet形式に対応し、大幅に容量が削減された状態でダウンロードできるようになり、TeamSpiritの場合csv形式で30GBほどあったサイズがParquet形式では2GB 弱ほどまで抑えられています。もちろんPI Appはこれに対応しており低コストでログを保存できるようなり、取得にかかる時間も非常に短くなりました。しかしParquet形式のファイルはそのままでは読み込むことが出来ないため、後述するAthenaを利用して解析を行います。

改善ポイントその3 : データ分析の基盤ができる

S3に蓄積されたParquet形式のログファイルは列指向データのためそのままの状態では分析が難しいですが、AthenaというAWSのクエリサービスを用いて馴染みあるテーブルデータとして扱うことが出来ます。これはQuickSightやTablaue等の分析基盤のデータソースにすることができます。

QuickSightダッシュボードの例
Tablaueダッシュボードの例

Partner Intelligence Starter Packのセットアップ手順

ここからは実際にPI Appを導入する手順を解説していきます。 所要時間は1時間弱程で完了することが出来ます。尚、本記事のセットアップ手順は2021/12時点のものとなっております。オリジナルの記事はこちらです。

medium.com

まず、Salesforce側の設定です。

  1. まずSaleforce LabsよりPI Appをインストールします。 Partner Intelligence Starter Pack [Old Version] - Salesforce Labs - AppExchange インストールするとPI LabAppアプリケーションにてLogPullConfig、Log Pull Activityオブジェクトを確認できます。

  2. PBO組織にてユーザ(PILabappにアクセスするユーザとAWSからAppAnalyticsRequest APIを呼び出すAPIユーザ。同一でもOK)を用意し、権限セット「PILabappConfigPSL」を割り当てます。このとき、APIユーザでセキュリティトークンを発行しておきます。

  3. PI LabAppアプリケーションに移動し、LogPullConfigタブを開き、以下のようにレコードを作成します。

    新規LogPullConfig画面

    ・AppName - 任意のアプリ名
    ・AppPackageId - AppExchangeリストに関連付けられているパッケージIDの15文字。18文字のパッケージIDから最後の3文字を削除します。
    ・Packages - AppPackageIdと同じ。複数パッケージのログを取得する場合はコンマ(,)区切りで入力します。
    ・ExpectedVolume - 予想されるログの量に応じて選択。HIGHのほうがリクエストが細かく分割されるようになります。

ここからはAWS側の設定です。

  1. CloudFormationスタックをインストールします。「新しいリソースを使用(標準)」を選択し、「前提条件 - テンプレートの準備」は「テンプレートの準備完了」、「テンプレートの指定」はS3URLにリージョンによって以下を指定します。
  2. us-east-1 : https://pi-public-template-bucket.s3.amazonaws.com/PiappjscdkStack.template.json
  3. ap-northeast-1 : https://pi-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/PiappjscdkStack.template.json スタックに任意の名前を付け、残りはすべてデフォルトで作成します。

  4. PBOログイン情報をSecretManagerに登録します。TemplatedSecret..ではじまるシークレットを見つけてPBO組織のAPIユーザ名とパスワードを更新します。

    Secrets Manager更新画面
    ・ sfdcclientid - PBOのAPIユーザ名
    ・ password - 上記ユーザのパスワード(セキュリティトークン付き)

以上で設定は完了です。

最後に

今回はPartner Intelligence Starter Packを使用したTeamSpiritログ取得の改善活動の内容をお届けしました。TeamSpiritでは本アプリを利用することでカスタマーサクセスにおけるDXや、機能開発の意思決定の迅速化を実現しました。是非利用してみてはいかがでしょうか?

プロダクトマネージャーチュートリアル~FigmaでToDoリストを作ってみよう~

今年シンガポールから帰国したけど、引き続き日本のチームスピリットでプロダクトマネージャーとしてお世話になっている二宮です。

私にとって今年は、PMとしてFigmaをよく触った年になりました。
そこで今回は、その培ったFigma力をチュートリアルとして還元していきたいと思います。

プロダクトマネージャーがどのようにして、プロダクトや機能を構想していくかも合わせてご紹介していきます!

お題

お題はエンジニアの方だったら一度はやったことのある、定番のToDoリストにしたいと思います。(こんなの)

下記のような行程で進めていきたいと思います。

  1. 要件定義
  2. ワイヤーフレーム作成
  3. UI設計 (Figma)
  4. プロトタイプ作成 (Figma)

それでは、作っていく!

要件定義

普通はユーザーの課題から機能を考えてくのが正しいのですが、今回はある程度作るものありきなので、形式的にやっていきます。

普段自分は下記の項目を整理して書くことが多いです。なので、今回もそれに則ります。

  • 想定ユーザー
  • ユーザーの抱える課題
  • 課題を解決する機能

想定ユーザー
日々色々なタスクをこなしている人

ユーザーの抱える課題
自分が今どんなToDoを抱えているか、またそれらの期日、ステータスを管理できていない

課題を解決する機能
必要そうな機能を書き出していきます。

  • ToDoリスト
    • ユーザーがやるべきToDoを管理できる
      • ToDoが登録、編集、削除できる
      • ToDoが一覧として確認できる
    • ToDoのステータスが管理できる
      • ToDoのステータスを完了にできる
      • 完了したToDoはリストから消える

今回はこの辺で止めておきます。 本来は、考えられるだけ書き出して、取捨選択、優先順位づけ、リリースの単位を整理していくのがいいでしょう。ユーザーストーリーマッピングなどのフレームワークを使うと整理しやすいです。

ワイヤーフレーム作成

書き出した機能を元に、画面の構成を考えてきます。 紙に描く、作図ツール、パワポなんでもいいです。ここからFigmaを使っても問題ないです。

今回はiPadで手で描きます。

自分でも驚くほど字が綺麗ですが、大体こんな感じです。

UI設計

ここからが今回の本題、Figmaの出番です。
まずはUIを作っていくフレームを作成します。
今回はモバイルアプリという想定で作っていきます。

フレーム配置

Frameを配置して、iPhone13の画面サイズに設定します。

コンポーネンの作成

今回はチュートリアルなので、各部をちゃんとコンポーネントとして作っていきます。
メインのUIを作るページとは別のページに、コンポーネント群を整備していきます。

タイトル用のText Style
手始めに、画面上部に配置するタイトル部分を作っていきます。
FigmaのText Stylesを使えば、いわゆるhタグに相当する様なテキストのスタイルを保存して、使い回すことができます。

次に必要なコンポーネントを作っていきます。
コンポーネントも作成しておけば、使い回すことができます。

入力コンポーネント
それっぽい見た目になる様に、オブジェクトと文字を配置して、それらをまとめて選択して画面上部のダイヤのボタンでコンポーネント化することができます。 幅が変わった時にも、意図した通りに拡大/縮小するか確認しておくと良いでしょう。
同様に日付の入力コンポーネントも作りました。

ボタンコンポーネント
基本的な作り方は、上記と同様です。
加えて、ボタンコンポーネントにはVariantを設定してみましょう。
Variantによって、コンポーネントの状態(Selected, Disabledなど)を表現することができます。
作成したコンポーネントを選択してVariantを設定すると、コンポーネントが自動で複製されます。

今回はボタンのDisabledを設定したいので、DisabledというPropertyを設定して、FalseとTrueのUIを作成します。

実際にコンポーネントを置いてみると、こんな感じで簡単に状態を切り替えられるようになりました。

チェックボックスコンポーネント
ボタンと同様に、チェックがついていない状態、ついている状態を作成しました。

リストコンポーネント
リストをコンポーネント化するときは、リストのヘッダーや行だけコンポーネント化しておきます。リスト行は選択状態のVariantを設定しました。

これでコンポーネントが揃いました!!

画面の作成

最初に作ったフレームに、作成したコンポーエントを配置して画面を作成していきます。

タイトル
好きなタイトルをテキストで配置し、作成しておいたText Styleを設定します。

フォーム部分
作成したコンポーネントはAssetsタブから呼び出して、使うことができます。 ボタンと入力項目を配置してこんな感じにしました。

リスト部分
リスト用のフレームをおいて、その上に作成したヘッダーと行のコンポーネントを配置していきます。

配置した後は、プレビューしながら全体のバランスを整えて完成です!

これだけでも十分なのですが、今回はこれをデモっぽく動くようにしていきます。

プロトタイプ作成

FigmaにはPrototypeという機能があります。 いわゆる"紙芝居"(デモ)を作る機能で、作成したUIを動いているかのように見せることができます。 より正確に画面の動作や遷移を伝えることができます。

シナリオ
それでは、まずどのようなデモにするかシナリオを考えます。 Figmaのプロトタイプの機能ではあくまで、あらかじめ設定しておいたフローでしか動かせないので、複数機能がある場合は複数フローを作成してもいいでしょう。

1. タスクの新規登録
 初期画面 → タスク入力 → 保存してリストに追加 → タスクが一覧で見れる
2. タスクのステータス更新
 タスク一覧 → タスク選択 → Doneに変更 → 一覧から消える
3. タスクの削除
 タスク一覧 → タスク選択 → 削除 → 一覧から消える
4. タスクの更新
 タスク一覧 → タスク選択 → 更新 → 一覧に反映

今回はこれらをデモに入れていきます。
最初に"紙芝居"と表現したように、一つの画面を動作させるのではなく、各状態の画面を用意しておいてクリックで遷移させていくような作り方をします。(作りながら機能の微調整もしていきます。)

実装
「初期画面 → タスク入力」 にあたる2画面を作りました。

これを繋げて動いている様に見せます。

入力欄をクリックすると入力したかの様に動く様に、入力欄から繋げていきます。

実際にプレビューするとこんな感じ。

同じようにして、ガシガシ作ってきます。 今回は書き出したすべてのシナリオを一つのフローに入れることができました。

そして、最終的に完成したデモがこちら
ToDoリストのアプリの機能が、実際に動いている形で見えるのではないでしょうか。

さいごに

Figmaのプロトタイプ機能は、プロダクトのアイデアを最短で動く形にできる非常に強力なツールです。このチュートリアルを真似して、あなたもプロダクトマネージャーとしてデビューしてみてはいかかでしょうか!

この投稿はチームスピリット Advent Calendar 2021 第9日目の投稿となります。

adventar.org

学び方を学びなおす

こんにちは、TeamSpirit QAエンジニアの岡内です。
2021年6月1日に入社し、半年が過ぎました。

はじめに

前職でもソフトウェアテストやQAに従事していました。
しかしながら、上手くいかないこともありました。
タイトルにあるように、「学び方を学びなおす」必要があったので、これについて書きます。

弊社のアドベントカレンダーの12月8日に掲載いたします。
adventar.org

新機能開発チームから品質改善チームへの異動

入社してから先日まで、私はTSFチームのうち新機能開発チームに参画していました。
開発チームの体制については、下記をご覧いただければ幸いです。
teamspirit.hatenablog.com チームメンバーの支えのおかげで、業務に支障を来すことなく日々を送っていました。
そして、11月になってから品質改善チームに参画することになったのです。

「早く製品全体の知識を身に着けたい」と思っていた私にとって、新機能開発チームだけでなく、品質改善チームでの経験を積むことはチャンスです。
しかし、早々に躓くことになりました。

「これまでの自分のやり方」では通じなくなる瞬間がきた

品質改善チームに参画し、途端に右も左も分からなくなりました。
「チームが違うといえど同じ製品なのに、そんなに違うものなのか?」と感じる方もいらっしゃるかと思います。
チーム異動前の私が、まさにそう感じていました。
今まさに、「これまでの自分のやり方」では通じなくなったのです。

では、私にとって 新機能開発チームと品質改善チームの大きな違いは何なのでしょう?
最も大きな違いは、対象としている機能を理解するための業務知識です。
新機能開発チームでは経費精算機能やシフト管理機能を担当しています。
私は前職までで金融系のプロジェクトに参画していたことがあり、そのときの学び方を無意識に行っていたようです。
一方で、品質改善チームでは勤怠管理・勤怠計算を担当しています。
これまで勤怠に関わるプロジェクトに参画したことがなく、勤怠についての学び方で右往左往しているのです。

学び方を学びなおす

しかしながら、この右往左往している状況は、自身にとってはチャンスに出来る可能性があります。
これから先、いくらでも今まで学んでこなかった領域の学習をする必要が出てくるからです。

私の場合は、2つの原因がありました。
 1. 勤怠管理の全体像が見えない
 2. 1つ1つの用語の意味が分からない
1つ目については、弊社の場合は下記に挙げるような資料があります。
私はこちらを読みながら、勤怠管理の全体像を理解している最中です。

www.teamspirit.com

www.teamspirit.co.jp

2つ目については、諸先輩方の協力を仰ぎ、学習している最中です。

おわりに

今回は、チーム異動をきっかけに学び方を学びなおす機会に恵まれました。
果たしてこの学び方の学びなおしはうまくいくのでしょうか?
折を見てご報告できればと思います。

Entrance Book for engineer (2024年4月更新)

チームスピリット

はじめに

こんにちは、TSFエンジニアリングチームのチームリーダーをしている倉谷 (id:a-kura) です。

弊社は働き方改革プラットフォーム「TeamSpirit」というSaaSプロダクトを開発・運用しています。 2016年からエンジニアの採用活動をスタートし、2021年12月時点で弊社の開発組織は約60名、2024年2月時点では73名の規模になりました。

「Entrance Book for engineer」では、チームスピリット / TeamSpirit に興味をお持ちいただいた方に、私たちのことをより知っていただくために「入り口」となる公開情報を集めています!

こんな方に読んでいただけるとうれしいです。

  • チームスピリットのエンジニアになってみたい方
  • チームスピリットの開発組織に興味のある方
続きを読む

リリースのリードタイムの70%削減に挑戦する話

みなさん、こんにちは。
TeamSpirit EXのエンジニアリング・ マネージャをしている杉山です。
普段はマネージメント業務もしつつ、BEエンジニアとして勤怠機能の開発もしています。

こちらは チームスピリット Advent Calendar 2021 - Adventar の6日目の記事です。
今日は、リリースのリードタイムの70%削減に挑戦する話をします。

TeamSpirit EXのリリース

TeamSpirit EXは1年間に4回のメジャーリリースをしています。
マイナーリリースを含めると1年間に30回以上、月に2~3回のペースでリリースしていることになります。

LeanとDevOpsの科学 などで紹介されている、デプロイ頻度やデリバリーのリードタイムと照らし合わせると、私達はミディアムパフォーマーという括りに入るでしょうか。

※ こちらのDevOpsチェックでも診断できます www.devops-research.com

リリースプロセス

TeamSpirit EXは AppExchange に公開してるアプリケーションですが リリースするために、パッケージ作成と呼ばれる作業をSalesforce上で行います。
下図はマイナーリリース作業を表したものです。

ご覧のように、パッケージの作成に多く時間がかかっています。
パッケージの作成時間に幅がありますが、作成に失敗することがあり、その場合は再作成が必要になるためです。

これだけ時間がかかると、緊急リリース時など修正は1日で終るのに、リリースできるのは3~4日後という事態になってしまいます。

ボトルネックはどこか

パッケージの作成時にはすべてのテストクラスが実行されます。
TeamSprit EXには5000弱のテストケースがあり、それらがパッケージ作成時に実行されますが、 ここに4時間弱 かかってしまいます。
この問題を解決する方法を考えていきましょう。

解決策1. テストを並列実行する

Salesforceではテストクラスのアノテーションにプロパティを指定することでテストを並列実行できます。 しかし、この方法だけでは問題を解決できません。
なぜなら、多くのテストがDBアクセスしているため、並列実行するとレコードのロックエラーが発生するためです。

解決策2. Mockを利用して、DBアクセスするテストを減らす

DBアクセスするテストが多いのであれば、テストを修正しましょう。
ApexのMockを利用すればDBアクセスを減らすことができ、実行時間の短縮も見込めます。
しかし、、この方法でも問題は解決できません。
なぜなら、、修正対象があまりにも多すぎて時間がかかってしまうためです。
(本当は少しずつでも対応するのが望ましいですが)

では、どうするか・・

開発用とパッケージ作成用のテストクラスをわける

パッケージ作成に必須ではないテストをパッケージから除外しましょう。
私達のチームでは、CIで定期的に全てのテストを実行しているため、パッケージ作成のタイミングに必要になるテストは極めて少ないです。
名前空間にまつわる不具合はパッケージ作成のテスト時に発見されることもありますが、これもCIのテスト組織で名前空間を利用すれば早期に発見が可能です。

パッケージを作成するためには最低限75%のカバレッジが必要ですが、そのテストだけであれば大幅に実行時間の短縮を見込めます。

さいごに

まだ発案段階ではありますが、プロダクト開発に注力できる環境を作ることがお客様にの価値につながると信じて、粘り強く挑戦していきたい次第です。

チームスピリットでは一緒にはたらく仲間を探しています。
興味を持ってくれた方は是非お声がけをお願いします!!

recruit.teamspirit.com

recruit.teamspirit.com