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

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

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

こんにちは。

株式会社チームスピリットの古川(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

チームスピリット

はじめに

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

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

「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

リスクベースド・アプローチを導入して、JaSST nanoで発表しました

こんにちは。TeamSpirit QAエンジニアの中西です。

私たちのチームでは2021年1月からリスクベースド・アプローチ※を採用したテストを始めました。当記事では、その取組み内容をJaSST nanoというイベントで発表してきましたので、その報告とともに苦労したポイントについてお伝えします。
※ リスクを特定し、リスクに応じて対応する方法

はじめに

取組みの経緯を説明する前に、当社のプロダクト開発手法と開発チームにおける
QAエンジニアの役割を説明します。
プロダクト開発体制についての詳細は下記ブログを参照ください。 teamspirit.hatenablog.com

プロダクト開発手法

私たちのプロダクト開発では、スクラムを採用しています。 1スプリント2週間の開発サイクルを8回程度繰り返して、プロダクトをリリース※しています。
私たちの開発チームはスプリント最終日のスプリントレビューでデモできるように、小さな単位で機能開発しています。
また、スプリントレビューでデモを実施した結果、クリティカルな指摘がある場合、次のスプリントの開発に組み込みます。
※ エンドユーザ向けにリリースするのは年3回(3月、7月、11月)です。

QAエンジニアの役割

TeamSpirit family製品開発チームにおけるQAエンジニアの役割は以下の通りです。

  1. プロダクト品質目標の作成・更新
  2. テスト戦略・テストアーキテクチャの策定・運用
  3. リリースサイクルごとにテスト計画、品質評価レポートを作成
  4. 詳細設計のレビュー
  5. 開発が完了したユーザストーリー、不具合のテスト設計/テスト実施
  6. 開発期間中に発生した不具合の分析、分析結果を開発チームにフィードバック
  7. リグレッションテストケースの整備
  8. 非機能要件のテスト計画~テスト実施のリード
  9. 継続的なテストプロセスの改善
  10. テスト自動化の推進
  11. テストナレッジの共有
  12. 採用支援

リスクベースド・アプローチを導入するまで8~11に記載していることが
十分に実施できていませんでした。

リスクベースド・アプローチの導入

従来はQAエンジニアが全てのリリース対象に対して、機能テストを行っていました。
さらに、開発者テストとQAエンジニアのテスト内容が重複している場合もあり、
テストに必要なコスト・時間が多い状況でした。
そのため、QAエンジニアのテストがボトルネックとなり、
リリースできない機能改修が発生していました。

このような問題に対応すべく、リスクベースド・アプローチを用いて、
機能テストにおけるQAエンジニアの関わり方を整理しました。
どのように整理したかはJaSST nanoで発表した資料を見ていただければと思います。

speakerdeck.com

苦労した点

次にリスクベースド・アプローチ導入時に苦労した点を共有します。
(JaSST nanoでは説明していない内容になります。)

苦労した点は不具合が混入するリスクが低い機能改修に対して、
QAエンジニアがどのようなテストをするか決めることでした。

テスト手法を検討するにあたり、不具合混入リスクが低い機能改修で混入した
不具合の発生傾向を分析しました。

その結果、ラベル名の変更、エラーメッセージ、エラー発生条件の変更のような
機能改修では、クリティカルな不具合が頻繁に発生していないことが分かりました。

分析結果をふまえて、不具合が混入するリスクが低い機能改修に対して、 下記2点を行うことに決めました。

  • QAエンジニアは開発エンジニアが作成したテストケースをレビューする。
  • QAエンジニアは1~3時間のタイムボックスでアドホックテストを実施する。

今後について

リスクベースド・アプローチ導入後、モブテストを通じて、 テスト実施の勘所を開発エンジニアに少しずつ伝えているところです。
また、定期的にJSTQB Foundationレベルのテストの目的やテスト設計技法を伝えて、 開発エンジニアもQAエンジニアと同等のテストができるように支援していくことを考えているところです。

JaSST nanoでの発表

リスクベースド・アプローチの取り組みが定着した頃、
JaSST nanoでの発表を決めました。

JaSST nanoについて

JaSST nanoはテストやQA、品質に関連するテーマで誰でも、
気軽に社外に対して、発信できる場です。

1ヶ月に1度、19:00から1~2時間、オンラインで開催します。現時点では第3火曜日です。テーマはソフトウェアのテストやQA、品質に関することなら何でも構いません。レベルとか質とか関係ありません。話したい人が話したいだけ話す、という趣旨です。 JaSSTnano - PukiWiki から引用

JaSST nano参加のきっかけ

2021年の個人目標として、以下の2点を挙げていました。

  • リスクベースド・アプローチを開発プロセスに組込み後、その成果を社外に発信する
  • 社外のテストエンジニア・QAエンジニアの方との接点を持つ

特に「社外のテストエンジニア・QAエンジニアの方との接点を持つ」ことに関しては、
並々ならぬ意欲をもっていました。

そんな中、JaSST nanoのイベントを定期開催するというtwitterを見て、
2021年度中に発表するということを決意しました。

JaSST nanoに参加してみて

運営の方によるイベントの雰囲気づくりにより、
発表者にとって非常に発表しやすい雰囲気でした。
「テスト、品質に関わることならなんでも」という主旨のため、
発表内容もバリエーションが豊富で、 テストの目的をカジュアルに分かりやすく例える発表もありました。

家事・育児に学ぶテストと品質管理の心構え - Speaker Deck speakerdeck.com

他社の取り組みや発表者が持っているテストや品質の考え方を
気軽にインプットすることができる場でした。

また、社外の方と接点を持つきっかけとなるイベントでした。
自社の取り組みではなく、ソフトウェアテスト、品質に対して、
自分の考えをアウトプットする場として、また参加しようと思っています。
積極的にアウトプットして、ソフトウェアテストを盛り上げていけるように頑張ります。

最後に

このようなQAエンジニアが所属しているチームです。
一緒に働きたいというエンジニアの方を絶賛募集中です。
よろしくお願いします。

recruit.teamspirit.com

recruit.teamspirit.com