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

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

エントリーブログ:入社から3ヶ月の流れと学び

自己紹介

初めまして、2022年9月に株式会社チームスピリットに入社しました、QAエンジニアの船場です。Teamspirit EXのQA業務を行なっております。

入社前は、主にECサイトのQA業務を行なっており、Salesforceやスクラム開発は未経験でした。 今回は、入社から3ヶ月であったことや学んだことを書きたいと思います。

入社後の流れ

入社〜3ヶ月では、入社オリエンテーションと部門に応じた新入社員用のオンボーディングが用意されています。 このプロセスで業務に必要な知識やスキルを身につけつつ、業務に参画していくという流れになります。

■入社オリエンテーション

入社当日は、オフィス内の講談スペースで同期入社の仲間と入社オリエンテーションを受けました。 具体的には、会社端末の設定、入社説明、写真撮影、オフィス案内などがありました。 不明点に対しても丁寧に教えていただきとてもスムーズに業務の準備を進めることができました。

■会社・製品・業務知識説明

会社概要については、荻島代表から直接説明があり、会社として目標や共通マインドの理解を深めることで今後チームスピリットで働いていくビジョンをより明確に出来ました。

また、入社1週間程の中で、各Division Leader、プロダクトマネージャ等の方から製品知識や業務知識についての説明があります。 プロダクトの特徴や顧客に対してどういう部分で付加価値を産み出していくかを把握することは、品質保証の観点からも大事だと思っているので、こういった部分の理解に時間を取らせていただけるのはとても有り難いと感じました。 製品の特性上、法令要件や業界知識も必要になってくるので、質問の時間で不明点を解消しながら理解を進めることができました。

■Salesforce学習

Trailheadを利用してSalesforceについての学習を行いました。 必要な知識が学べるよう、QA用のカスタムカリキュラムが組まれています。 私はSalesforce未経験だったのですが、基礎的な部分から学習できとても活用的でした。

■テスト環境構築・スルーテスト

テスト環境を構築し、システム全体の挙動をシナリオ化しているスルーテストを行いました。 実際にプロダクトの個々の機能を網羅的に触れるので、研修で学んだ知識を活かしながら理解を深めることができます。

■デモ

研修内容のアウトプットとして、チームメンバーに対してTeamspirit EXの製品説明デモを行いました。 デモ内容はある程度自由度があり、製品理解という目的のもと行えるので、とても効率的にこれまでインプットした知識を定着させることができたと思います。

実務の開始

研修カリキュラムがひと段落つくと、スクラムチームに参画し少しずつ業務を行っていきます。 私はQAチームのメンバーとして、まずオフショアのスクラム開発の品質保証やメジャーリリースの総合テストに携わりました。 オンボーディング中も定例MTGに参加させていただいたり、実務についての情報共有をしてくださっていたため、スムーズに取り掛かることができました。

今後もスクラム開発や定期的なテストに加え、自動テスト、性能テスト、テストプロセス改善、CI環境の整備等様々な品質保証業務に携わらせていただける予定なのでとても楽しみです。

感想・まとめ

チームメンバーの支援もあり、とても有意義な3カ月間でした。 機能テスト、自動テスト、性能テスト、テストプロセス改善、CI環境管理等様々なジャンルで品質保証に携われるため、QAエンジニアとしてのキャリアアップに最高の環境だと思いました。また、新たにやりたいことがあれば業務に取り入れることができる、というところもとても魅力的に感じています。 今後もスキルアップを継続しながら、より魅力的な製品が提供できるよう尽力していきたいと思います。

※こちらはチームスピリット Advent Calendar 2022 - Adventarの2022年12月22日目の記事になります。

テスコンU-30で準優勝した話

※この投稿はチームスピリット Advent Calendar 2022の16日目の投稿です。

こんにちは。QAエンジニアの橘です。

2022年9月17日(土)に開催されたテスコンU-30クラス決勝戦において、弊社チームスピリットのQAチームメンバーで構成されたチーム「つよつよなりたいはんぺん」が4チーム中2位の準優勝を受賞いたしました。

テスコン(テスト設計コンテスト)とは何かという話や、予選成果物提出までの内容についてはこちらの記事を参照: teamspirit.hatenablog.com

今回は予選通過後から決勝戦までのあらましと、決勝戦の様子、およびテスコンを終えての感想を書いてみたいと思います。

予選通過後から決勝戦まで

予選成果物提出後、無事予選を通過したとの発表がありました。

喜びも束の間、決勝戦に向けての準備開始になります。

テスコンU-30では予選結果発表から約2ヶ月後に決勝戦となっていましたが、予選通過後から1ヶ月ほどの間に決勝戦で使用するプレゼン資料を作成して提出する必要がありました。

また、予選成果物に対して審査員から多くのフィードバックをいただいたのですが、それを元に成果物を修正して再提出すると再度点数付けがされることとなっていました。

そのためプレゼン資料の作成の傍ら、予選成果物の修正を行いました。

予選成果物へのフィードバックとしては、全体的に個々の成果物や成果物の間の関連性についての説明が不足しているというようなものでした。そのため、最初に成果物を作成した時点では明示的に書いていなかったことや考慮不足だった点を修正成果物に盛り込みました。

また、フィードバック内容について審査員と直接会話できるフィードバック会が開かれました。自分達が考えていなかったことや、成果物をより良くするにはどうすればいいかといったお話を聞くことができ、とても勉強になりました。

修正成果物を提出してから本番までの間にも、プレゼンの持ち時間15分を測りながら発表練習をしたり、当日は質疑応答の時間もあるので想定質問を用意したりと決勝戦に向けて準備をしていました。

決勝戦の様子

決勝戦では、15分の持ち時間で成果物の内容をプレゼンし、その後5分間の質疑応答を行います。

このプレゼンの巧拙によって加点がなされ、再提出した成果物の評点と合わせて最終的な点数が決定します。

当日は予定していた内容を15分以内で話し切ることができ、また質疑応答もなんとかこなせたと思います。練習しておいてよかったです。

以下にプレゼン資料の一部を引用します。

テスト設計のアピールポイント

各テストプロセスでの強みを強調しました

テストの実行範囲・実行時間を示す

プレゼン資料の全体はテスコン公式サイトでご覧いただけます。

発表と並行してJamboardで審査員や視聴者が質問やコメントをできるようになっていました。好意的なコメントもいくつかいただけて嬉しかったです。

結果発表と講評

全4チームの発表の後審査結果が発表され、我々のチームは準優勝となりました。

その後の講評や、コンテスト終了後にチーム別にいただいた審査コメントをいくつか挙げたいと思います。

  • (成果物1: テスト要求分析の成果物で示している)テスト観点が具体的でテストケースになっているため見落としが出てしまう。抽象度を上げて、全体像を把握することを意識してほしい。
  • (テスト実行において)優先度が低いものを除外して本当にいいのか。除外することのリスクを下げることを考えてほしい。
  • テストアーキテクチャーを多面的な視点で表現しているのは良いが、テストアーキテクチャー全体で伝えたい事が何なのか分かりにくくなっていた。
  • いくつかのテストケースが期待結果不明となっており、現状のままでは第三者にテスト実行を依頼出来ない状態になっている。

いただいた講評については、今後の業務に活かしていけたらと思います。

テスコンを終えての感想

決勝戦終了後にチーム内で振り返りを行い、メンバー同士で感想を出し合いました。以下感想の一部です。

  • テストプロセス全体を実践的に学ぶには良い機会だった。特に第三者から意見・評価を頂ける貴重な機会だった。
  • 最初想像した以上に、長くてタフなコンテストだった。(※半年以上活動していた)
  • (チーム外の)先輩方からのアドバイスはもっと貰ってもよかった。
  • 去年までのテストベースは組み込みソフトウェアの仕様書であったが、今年はスマホアプリの仕様書であった。テストベースの種類によってテストの考え方が変わることが分かった。
  • テスコンU-30クラスは、自ら動けるチーム(時間に余裕がある等)であればコストパフォーマンスの良い研修になると思うので、若手QAの研修としてオススメできる。

予選成果物作成から決勝戦まで長い時間でしたが、準優勝という結果を残せてよかったです。初めの頃は成果物作成の難しさに尻込みし、やり切れるかどうか不安もありましたが、最終的に決勝戦のプレゼンまで終えることができてホッとしています。

テスコンを通して、QAやソフトウェアテストの世界の広さや奥深さを知ることができました。また他のチームの発表を聞いていて、いろんな考え方や手法があることが分かって興味深かったです。

まだまだ勉強すべきことはありますが、予選の記事でも書いたいようなテストプロセスの理解についてはそれなりに達成できたのかなと思っています。あとはテスコンで得た知識を実際の業務に活かしていければと思います。

Japan Dreamin' 2023 に協賛します!

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

来たる2023年1月28日(土)に Salesforceコミュニティ主催の Japan Dreamin' が開催されます。 弊社、株式会社チームスピリット は今回も引き続き協賛させていただきます。

Japan Dreamin' | Home

Japan Dreamin' とは

まずは Japan Dreamin' についてご紹介します。 Japan Dreamin' は国内最大規模のSalesforceコミュニティイベントです。2019年から開催されて今回で5回目の開催となります。
ビジネスユーザ・システム管理者・開発者・アーキテクト・マーケター・Salesforce 社員・Salesforce に関わる全ての人が組織や役割を超えて繋がることのできるイベントであり、 「つながる」をテーマにしていてロゴにもその想いが込められているそうです。

そのため、Japan Dreamin'では有識者の役立つノウハウを共有・学習するだけではなく、全国で孤軍奮闘しているTrailblazerが「つながる」ことで、お互いを引っ張り上げながら、支え合いながら成長していく目的もあり、Trailblazer同士の交流もいろいろとイベントの中に仕掛けがあります。

ここ2回はコロナ禍のためオンライン開催となっていましたが、
今年はハイブリッド開催(会場+オンライン)になります!

抽選50名なので、参加したい人は忘れず申し込みましょう!

つまり、今すぐ申し込みましょう!!

どうしても現地参加したい方はボランティアも狙い目です(期限:12月9日(金))

japandreamin.connpass.com

少し脱線しますが、2022年11月29〜30日に開催されたSalesforce World Tour Tokyo 2022で久しぶりにTrailblazerたちが集まることができました。そこでは久々の人たちに再会でき、懐かしくもあり、現地ならではの臨場感、そして興奮を感じることができました。 改めて、リアルイベントはいいなぁ、と感じました。

どんな発表がされているか?

Japan Dreamin'でどんな発表がされているか知りたい場合は、前回(2022年1月)の発表の一部がYouTubeチャンネルに公開されています。 そちらの動画を見ると雰囲気を掴めるかと思います。

www.youtube.com

ついでに、私も過去3回ほど発表していますのでご紹介です。昨年、一昨年については動画とそのフォローアップ動画も公開しています。

a-kura.hatenablog.jp

a-kura.hatenablog.jp

a-kura.hatenablog.jp

さいごに

毎年アドベントカレンダーに参加しています。 この投稿はチームスピリット Advent Calendar 2022 第4日目の投稿となります。

adventar.org

勤怠計算ロジックのリファクタリング、はじめました

こんにちは。QAエンジニアの石原です。
この記事では、私が現在所属しているTSFエンジニアリングチームのサブチームである勤怠計算リファクタリングチームの活動ついてご紹介したいと思います。

勤怠計算リファクタリングチームのミッション

出社時刻や退社時刻などをもとに労働時間の算出をする機能が勤怠計算です。
多くのお客様にご利用いただいているTeamSpiritの勤怠管理機能の中で特に重要な機能の1つです。

先日投稿した下記の記事でも触れましたが、ドメイン知識習得などが容易でないことから勤怠計算機能は限られたメンバしか開発やテストができないという課題を抱えており、特に開発に関する部分では、長きにわたり勤怠計算機能の開発に携わっているメンバしかソースコードの内容を把握できていないという課題があります。

teamspirit.hatenablog.com

そこで、他のメンバとも分担して勤怠計算機能の開発をできるようにするため、勤怠計算ロジックのリファクタリング(プログラミングの挙動を変えずに内部のコードを読みやすくする)を行うことになりました。
勤怠計算リファクタリングチームでは、この勤怠計算ロジックのリファクタリングを行い、最終的に製品パッケージに組み込んでリリースすることを目標としています。

どうリファクアリングを進めるか?

現在のソースコードは、

  • 構造的な課題により、テストのカバレッジを増やそうとするとSalesforceのガバナ制限に抵触してしまうためテスト数が増やせない
  • 勤怠管理機能の肝とも言えるロジックであるため、いきなり現行ソースコードを修正することのリスクが高い

ということから、現行のソースコードの外側で新しく作り直すという方針をとりました。

大まかには、

  1. 今までより詳細な勤怠計算ロジックの仕様書と、より網羅的な勤怠計算テストの仕様書を作成する
  2. 1.にもとづき、新しい勤怠計算ロジックとそのテストコードを作成する
  3. バックエンド(コントローラー)から、新しい勤怠計算ロジックと旧(=現行)ロジックの両方に接続するよう改修し、並行稼動させる
  4. 新旧それぞれの計算結果の差分を検出し、新しい勤怠計算ロジックの品質を向上させる
  5. 差分がなくなったタイミングで新しい計算ロジックに切り替える

というステップで進めていきます。

新旧ロジック差分検出のイメージ図

チーム内の役割分担

現在、勤怠計算リファクタリングチームはリーダ1名、開発者3名、QA2名の計6名の構成となっています。
開発者は主に勤怠計算ロジックの仕様書整備やリファクタリング、テストを自動化するための基盤構築や実行環境の整備などを行い、QAは主にテスト仕様書作成およびテストコードの実装を行いました。
勤怠計算のテストケースは、TeamSpiritの設定や入力パターンの多さからかなりの件数となったため(勤怠計算は勤怠管理機能の中でも特に重要な機能であり、法要件への適合やTeamSpiritをご利用のお客様の給与計算にも影響しますので、テストをしっかり行う必要があります)、テストコード実装のピーク時には開発者と外部メンバにも参画してもらいました。

現在の状況は?

新しい勤怠計算ロジックの実装とテストケースの実装が完了し、アルファテストとして開発環境に新しい勤怠計算ロジックをデプロイして、過去に実装済みのテストコードと今回実装したテストコードをそれぞれ実行しています。
アルファテスト開始直後は現行ロジックとの差分が何件も検出されましたが、改修とテスト実行を重ね、検出される差分もかなり少なくなってきました。
また、テストを自動で実行できるようにクラウド環境(AWS)や自動化ツール(Jenkins)を利用した環境整備も進めており、現在では大部分のテストを自動で動かせるようになってきました。

最後に

まだまだテストは続きますが、新しい勤怠計算ロジックをリリースできるようチーム一丸となって頑張っていきます!

JMeterでSalesforceアプリへの負荷テストを実施しました

こんにちは。TeamSprit EXのQAエンジニアの河西です。

この記事は、APIテストの取り組みに関する記事の3本目です(全3本)。

  1. JMeterによるAPIテストの実装について
  2. JenkinsによるAPIテストの定期実行について
  3. JMeterを使ったSalesforceアプリへの負荷テストの実施について ◀︎ 今回はこちら

前回までは、APIテストの実装と定期実行の取り組みについてご紹介しました。 今回は、APIテストの実装で習得した知識を活用してSalesforceアプリへの負荷テストを実施した際の、取り組みについて書いていきます。


なぜ負荷テストを実施するのか?

機能テストと、性能を測る性能テストは、全く異なる観点のソフトウェアテストで、どちらも製品を提供するにあたって重要なテストです。

  • 機能テスト
    仕様書や設計書に基づいた正しい動きをしているかどうか。
  • 性能テスト
    ユーザーが快適に利用できるかどうか。
    実際の利用想定に基づいて、システムのデータ処理や応答速度のボトルネックとなる箇所を検出することを目指す。

性能テストには、通常の状態での処理速度や同時処理数を検証するものに加えて、システムが高負荷の状態にあるときの性能を検証するテストがあります。 これを負荷テストと呼び、その目的に応じていくつかのテストアプローチがあります。

TeamSprit EX は大企業向けのサービスです。 大企業、つまり多くのユーザーにご利用頂ける製品になっているか、検証する必要がありました。
まずは、私たちが想定している最大ユーザー数でご利用頂ける状態か検証するために、ロードテストを実施することにしました。 そこで問題がなかった場合に、想定以上の負荷をかけるストレステストも実施することにしました。

どうやって実施するのか?

まずはテスト計画を立てました。計画を立てる上で、下記の3点を関係者にヒアリングし決定しました。

  • テストの目的
    TeamSprit EX はSalesforce Platform上にアプリケーションを開発しています。 そのため、今回の負荷テストでは「サーバーの性能を測ること」ではなく、「高負荷時のアプリとしての問題点を洗い出すこと」を目的としました。

  • テスト対象
    想定しているユーザー数と、どの機能に対して負荷テストを実施するかをヒアリングし、決定しました。 今回は画面操作ではなく、APIリクエストでのテスト実施のため、ターゲットとなるAPIもここで決定しました。 そして、最大でどの程度の負荷をかけるか、RPS(1秒あたりの要求数)を決定しました。

  • スケジュール
    いつまでに結果報告が必要かヒアリングし、決定したテスト対象からおおよそのテスト実施期間を決定しました。 初めて負荷テストを実施するということもあり、準備期間は多めに取りました。

ツールの選定については、今回はAPIリクエストによる負荷テストのため、APIテストで使用した JMeter を選びました。

続いて、決定したRPS(1秒あたりの要求数)から負荷を試算し、テストスクリプトの設計をして、JMeterの設定項目「スレッド数」「Ramp-Up期間(s)」「ループ回数」を決定しました。 参考サイト

そうして、下記3ケースのテストスクリプトを作成しました。

  • 想定しているユーザー数規模(1つのAPIを実行)
    RPSは固定のまま、スレッド数を調整して負荷のかけ方を変えた、8パターンを用意しました。
  • 想定しているユーザー数の2倍規模(1つのAPIを実行)
    RPSは固定のまま、スレッド数を調整して負荷のかけ方を変えた、8パターンを用意しました。
  • 5つのAPIを実行
    とある画面を表示する際に実行されるAPI5つを実行するテスト。RPS・スレッド数を調整した10パターンを用意しました。

画面を表示する際に実行される5つのAPIを実行するテストケースの方が、より実際の負荷に近いものとなります。 しかし、テスト結果を分析することが少し難しいため、5つの中で1番レスポンスに時間がかかる1つのAPIに重点を置きました。

続いて、テストスクリプトを作成したら、Salesforceアプリへの負荷テスト実施で必要な、Salesforceへのパフォーマンステストの承認申請を行いました。 こちら を確認し、ケースにて申請を行い、承認を得ました。

最後に、テスト環境にテストデータを入れて、準備は完了です。
準備したテストスクリプトを順番に実行しました。
(JMeterのGUIではなく、CLIで実行します。スムーズに実行するために、実行するコマンドを一覧化しておくことをオススメします。 その際、出力するログファイル名は、実行するテストスクリプトのファイル名と同じにしておくと、結果の確認がしやすいです。)

テストの結果

結果が出力されているファイル(result.jtlなど)から、結果を確認します。 (ファイルを、JMeterの「統計レポート」というリスナーで参照すると確認しやすいです。)
結果をExcelでまとめ、有用なデータをグラフ化したものがこちらです。
高い負荷をかけましたがあまり性能劣化は起きておらず、Salesforce Platformの性能の良さを改めて知ることができました。

しかし、一部のリクエストでエラーが発生しました。赤線の箇所)
発生したエラーは「403 Forbidden」です。 こちらについてSalesforceに確認したところ、 Apexガバナ制限 によるもの、と回答を頂きました。

10個の長時間(5000ms以上)のトランザクションが実行されている間に追加のトランザクションが開始されると、追加のトランザクションは拒否されます

この制限に引っ掛かりました。この制限は組織内だけであり、他組織に影響はありません。同時実行される可能性が高いAPIで、5000ms以上かかるものがあると、この制限が起きる頻度は上がります。

「高負荷時のアプリとしての問題点を洗い出すこと」を目的とした今回の負荷テストでは、上記の結果を得ることができました。

レポートの共有

結果をまとめて、開発メンバーに共有するレポートを作成しました。レポートには、下記の内容を記載しました。

  • 結果総評
  • テスト結果詳細
    • 処理遅延について
      • データからの読み取り
      • まとめ
    • エラー発生について
      • データからの読み取り
      • エラーの内容
      • APIテストとの照合
      • まとめ
  • 今後の課題について

今回の負荷テストの結果と、定期実行しているAPIテストの結果を踏まえて、今後の課題まで共有することができました。

テスト実行環境について

今回の負荷テストは、PC1台(MacBook Pro2020(Apple M1, 16GB))で実施しました。 計画段階で、PC1台で実施できるのか不安がありましたが、今後の負荷テストの課題を洗い出すためにも、とりあえず今準備できるもので実施してみようと思いました。
負荷テスト実施時は、不要なアプリケーションを全て閉じて、コンソールとアクティビティモニタのみ起動している状態で実施しました。

考えうる課題として、CPU負荷メモリについてモニタリングしました。

  • CPU負荷について
    テストスクリプトのコマンドを叩いた時、つまりJMeterが立ち上がる時に、一時的にCPU使用率が上がりましたが、それ以外はあまり上がりませんでした。 なるべく余裕のある状態での実施が望ましいですが、今回ほど厳密に全てのアプリケーションを閉じて実施しなくても良い、と思われます。

  • メモリについて
    本来、JMeterで負荷テストを実施する際は、先にJVMのチューニングをしておくことが推奨されていますが、今回はあえてチューニングせずに実施してみました。 すると、1500スレッドのテストは問題なく実行できましたが、1920スレッドのテストではメモリ不足によるフリーズにより、テストが止まりました。
    そこで、下記のようにJVMのチューニングをしてみました。
    すると、1920スレッドのテストも問題なく実行できました。
    最大6Gの設定にしましたが、モニタリングしたところ1.5Gまでしか使用されなかったため、まだ余裕があると思われます。

上記の結果から、今回以上の負荷(例えば5000スレッド以上)のテストは、PC1台で実施することは難しそうです。 AWSなどでJMeterサーバーを立てて実施するのが望ましいと考えます。

こうして、テスト実行環境についても課題を洗い出すことができました。

最後に

負荷テストについては、わからないことがとても多く、なかなか計画を立てられず、準備段階でも不安が多くありました。 「わからないことを明確にする」という目的で、とりあえず実施してみると、予想以上に多くの結果を得ることができました。

見つかった課題は Apexガバナ制限 だったため、 負荷テストを実施しないとわからない課題、ではありませんでした。 しかし、普段のテストとは違うアプローチをすることで、潜在的な課題が顕在化し、具体的な影響も見えたことで課題の優先度を判断することができた、と思っています。

APIテスト・負荷テストを任せていただけたことで、とても多くの学びがあり、スキルアップできたと感じています。
新しいアプローチのテストを導入することは大変ではありますが、個人としてもチームとしても、これからもチャレンジし続けたいと思います!

勤怠計算についてチーム内勉強会を開催しています

こんにちは。QAエンジニアの石原です。
現在TSFエンジニアリングチームでは、勤怠計算の勉強会を毎月開催しています。
本記事では、この勤怠計算勉強会についてご紹介します。

なぜ勉強会を開催するのか?

多くのお客様にご利用いただいているTeamSpiritの勤怠管理機能の中で、特に重要なサブ機能の1つが労働時間などを算出する勤怠計算の機能です。
勤怠計算は労働基準法などの法要件に基づいて行われ、固定労働制、フレックスタイム制、変形労働制などの勤務体系によって計算方法が異なります。
また、TeamSpiritの勤怠管理機能には、お客様の運用に合わせて柔軟に設定できるように勤怠計算に関連する様々な設定項目が用意されています。勤怠の入力パターンも、残業、遅刻、早退、休暇、休日出勤など様々なケースがあります。

勤怠計算機能の開発やテストを担当するメンバには、上で述べた法要件、TeamSpirit自体の機能、入力パターン等のいわゆるドメイン知識が欠かせませんが、習得するのは容易ではありません。
このため、現状では勤怠計算の開発やテストができるメンバが限られてしまっており、TSFエンジニアリングチームの課題となっています。この課題を解消するための取り組みの1つとして、勉強会を開催することにしました。

勉強会の内容

勉強会は、TSFエンジニアリングチームのQAである私(石原)ともう1人のQAメンバの計2人で交代で開催しています。
私が担当する勉強会では、勤怠計算初心者〜中級者の方を対象に、計算方法を理解し、基本的なパターンについて労働時間等の各項目の値を自力で計算できるようになることを主な目的としました。
参加者の方には事前に勤怠計算の仕様書を読んできていただき、勉強会の時間では私が作成した練習問題を解いていく構成としました。

練習問題の内容を少しご紹介すると、例えば残業に関する問題はこんな感じです。

固定労働制で以下の勤務をした場合、各項目の値はどのようになりますか?
・出社 9:00
・退社 19:30
・休憩 12:00-13:00
・残業申請(17:30-19:00)を申請済み

※勤務体系の設定(始業終業時刻や所定労働時間など)も問題内で提示していますが、ここでは省略します。

当初はQAメンバ向けに開催する予定でしたが、TSFエンジニアリングチーム全体向けにした方がよいのではと提案をもらったので、チームの方ならばどなたでも参加できるようにしました。

勉強会の様子

コロナ禍でチームメンバの多くは自宅からのリモートワークなので、勉強会は毎回オンラインで開催しています。
練習問題を1問ずつ時間を決めて実際に解いてもらい、その後に答え合わせと解説をするという形式で進めます。単なる座学にならないよう、参加者の方には、計算結果とどのように考えて計算したかを答え合わせの前に発表してもらうようにしています。

先月開催した勉強会では、QAメンバ、開発メンバ合わせて7名が参加してくれました!

勤怠計算勉強会に参加してくださった皆さん

最後に

勤怠計算の勉強会を開催することによって、自分自身の知識の棚卸しにもなりました。
勉強会で使用している練習問題は勤怠計算の一部の範囲しかまだカバーできていないので、練習問題の拡充と勉強会開催を継続しつつ、今後も引き続きチームの課題解消に取り組んでいく予定です。

Salesforce認定資格の話

こんにちは、開発チームの畑本です。約3年近く在籍していますが、実はこちらのブログに書くのは初となります・・・

先日、Salesforce 認定アプリケーションアーキテクト資格を取得できました!これで9個目の資格となります。

これを機に、Salesforceの認定資格について色々ご紹介させて頂ければと思います。

Salesforce認定資格とは?

文字通り、Salesforceプラットフォームに関連するいわゆるベンダー資格です。

Salesforce上での様々な業務に関連した資格があり、試験に合格することで業務上必要な能力があることを証明できます。こちらから資格の一覧や受験ガイドを参照できます。 資格一覧 - Salesforce

Trailheadにも解説記事があります。自分のジョブに対応した受験すべき資格を見つけることができます。 https://trailhead.salesforce.com/ja/credentials/administratoroverview/

どの資格を取るか

まず最初に認定アドミニストレータか認定Platformアプリケーションビルダーを取るのがおすすめです!以下の流れで基本資格から上位資格にステップアップできます。

・管理者・コンサルタントコース

まず基本資格となる「認定アドミニストレータ」に挑戦しましょう!Salesforceに関わるひと通りの機能を学ぶことができます。
その後は以下の上位資格に挑戦できます。

  • 認定上級アドミニストレータ:組織管理の実践的な業務知識を学ぶ
  • 認定Sales Cloudコンサルタント:Sales Cloud機能(商談、売上予測、キャンペーンetc)に特化した業務知識を学ぶ
  • 認定Service Cloudコンサルタント:Service Cloud機能(ケース、ナレッジetc)に特化した業務知識を学ぶ
・開発者コース

基本資格として「認定Platformアプリケーションビルダー」と「認定Platformデベロッパー」があります。アプリケーションビルダーが宣言型(ノンコーディング)開発、デベロッパーがコーディング開発と覚えてください。
アプリケーションビルダーはカスタマイズの幅が広がるので管理者にもお勧めの資格です。
それ以降の上位資格はまた様々です。更にSFの技術を極めるには「認定上級Platformデベロッパー」、画面開発に必須な技術に関わる「認定JavaScriptデベロッパー」 資格、 より上流の観点から包括的にシステムを理解する「アーキテクト」関連資格もあります。

どうやって資格を取るか

基本的にオンデマンド試験に合格すれば認定されます。Webassessorというシステムで受験申込を行いますので、まずはこちらのサイトにユーザ登録しましょう。 https://www.webassessor.com/wa.do?page=publicHome&branding=SALESFORCEJP ※初期登録したメールアドレスはユーザIDとして今後ずっと使いますので、なるべく使いやすいアドレスを登録してください。

受験方法には2種類あります。「オンサイト監督」は 国内各地にあるテストセンターの端末で受験します。本人確認書類(2種類)をお忘れなく! 一方、「オンライン監督」は自分のPCで受験します。テストセンターに行かなくて済むのが利点ですがPCセットアップの手間が難点です。。こちらのサイトで注意点を確認しましょう。 オンライン受験のご紹介 - Salesforce

受験費用の決済方法も2種類あります。通常はクレジットカード決済ですが、代わりにバウチャーコードを使うこともできます。 バウチャーは主に企業が一括購入して従業員に配布するためのものですが、Salesforceのイベントで配布されることも・・・!?

試験に合格するには

基本はTrailheadを使います。Salesforceに関する知識はすべてTrailheadに集約されていますので、これを使わない手はないです。

基礎学習

資格対策に特化したTrailmix(複数の学習コンテンツを一纏めにしたリスト)が公式/非公式問わずありますので、まずこれに沿って学んでいきましょう。

trailhead.salesforce.com

trailhead.salesforce.com

Trailheadのモジュールやプロジェクトは実際にSalesforce組織を操作して再現できる手順が掲載されていることが多いです。ただテキストを読むだけでなく、自分で設定手順を再現することでより理解が深まります。
また、モジュールの中には参考資料としてヘルプページへのリンクがあります。詳細な仕様はこちらに記述されているので、こちらもできる限りチェックしましょう。

直前対策

試験直前になったら、「認定試験に向けた学習」トレイルを履修しましょう。試験本番の多肢選択形式で出題されたサンプル問題を参照できます。

trailhead.salesforce.com

trailhead.salesforce.com

また、Salesforce主催の有償/無償トレーニングも随時開催されています。特に無償トレーニング「Certification Days」ではWebAssessorで使える割引クーポンも貰えるのでおトクですよ。 www.salesforce.com

認定資格の出題内容は受験ガイド記載のトピック別出題比率に沿って出題されるので、出題率の高いトピックを重点的に復習しましょう。もし不合格になってしまったら、Webassessorからトピック別正答率が確認できるので苦手分野を復習しましょう。

合格したら

合格おめでとうございます!初めて資格を取った場合は、まずWebassessorとTrailheadをリンクしましょう。操作はTrailheadから行います。 quip.com

リンクが完了したら、こんな感じにTrailheadのプロフィールに資格情報が表示されます。これでみんなに自慢できますね! https://trailblazer.me/id/hatamoto-t

Trailhead画面

またTrailheadとのリンクにはもう一つ重要な理由がありまして・・・ Salesforce資格は、Trailheadの資格更新バッジを取らないと失効します。 資格更新バッジは「認定資格の維持」トレイルにまとまっているので、定期的に確認しましょう。(だいたい年1回ペース)対応するモジュールのバッジを取ることで資格の有効期限が延長されます。

なぜ資格を取るか

業務でSalesforceに携わる方の中でも、認定資格に興味のない方は案外いらっしゃいます。「資格取る暇があれば業務に関わる作業した方がいいよ」と思っている方も多いです。確かに業務独占資格と違って必須の資格ではないかもしれません。でも取る理由は色々ありますよ。

①Salesforceパートナー企業にとって重要

Salesforceとパートナー契約を結ぶ際に資格者要件があるため、起業する場合に有資格者を集める必要があります。また社内の有資格者の人数はパートナー企業のスコアリングに反映されます。

②Salesforce関連企業で優遇される
そんなわけで、パートナー企業では社員の資格取得を促すために様々な奨励策を取っている事が多いです。受験費用の補助があり、合格時に報奨金が支給されることもあります。
なお弊社には資格手当制度があり、資格保持者には保有資格に応じて毎月支給されます!

③業務経験から得られない技術を学べる

Salesforceの資格試験では多数のトピックから出題されますが、その中には業務で使ったことがない機能が含まれている事があります。試験を通じて、自分がまだ学び足りていない技術が浮き彫りになります。

④足りない知識を補うことでより良い活用ができる

「業務で使わない知識は、要らない知識なんじゃないか?」と思われるかも知れません。けどその技術を知っていれば、過去の業務でより良いシステム構築ができていたということはないでしょうか?新しい技術を学ぶことでそんな可能性に気付くことができます。

これからも様々な認定資格を取れるように学び続けていきたいと思っています。 同じ思いを持っている方、一緒に勉強しませんか?社内外問わず一緒に勉強できるもくもく会を定期開催しておりますので、ぜひ来てくださいね! (最後に宣伝です😅) sfsaturday-tokyo-kyobashi.connpass.com