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

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

ISTQB Agile Testerを受験してみた

QA

こんにちは。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 京橋 をふりかえり

Salesforce アドベントカレンダー イベント

こんにちは。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で 第二世代パッケージを導入した話を発表しました。

Dreamforce Salesforce バックエンド

こんにちは！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 コードを共有できる機能があります。 この機能を利用してパッケージを複数のパッケージに分割して行くことが可能になりました。

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

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

入社ブログ QA

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

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

入社日当日

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

オリエンテーション

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

オンボーディング

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

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

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

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

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

まとめ

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

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

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

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

アドベントカレンダー プロダクトマネジメント

こんにちは。

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

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

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

え！来月からPMですか！？

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

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

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

え！結論からですか！？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

え！もう終わりですか！？

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

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

recruit.teamspirit.com

Partner Intelligence Starter Packのはじめかた

Salesforce Dreamforce エンジニアリング 改善

こんにちは。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)はTeaｍSpiritが構築したようなログ取得の仕組みを簡単にセットアップでき、且つ効率化された方法で上記の問題点を解決してくれるものでした。具体的な構成は以下のとおりです。

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や、機能開発の意思決定の迅速化を実現しました。是非利用してみてはいかがでしょうか？