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

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

Salesforce認定Platformデベロッパー試験に合格しました!

はじめに

こんにちは!開発チームの古厩(ふるまや)です。

2024年4月に新卒で入社し、気づけば2年以上が経ちました。日々の業務を通してSalesforceの画面フローやApex、Lightning Web Componentsなどに触れる機会が増え、「Salesforce開発について、もっと深く理解したい!」という思いから、このたび Salesforce認定Platformデベロッパー試験 に挑戦し、無事に合格することができました!

以前取得したSalesforce認定アドミニストレーター資格では、Salesforceの標準機能や設定について幅広く学びましたが、今回のSalesforce認定Platformデベロッパー試験では、ApexやSOQL、Lightning Web Componentsなど、開発者として押さえておきたい知識をより深く学ぶことができました。

今回は、この試験に関する概要や出題内容、私が実際に行った学習方法、そして試験中にどのように問題を解いたかについて、実体験を交えてご紹介します。

Salesforce開発を学んでいる方や、Salesforce認定Platformデベロッパー試験の受験を考えている方にとって、少しでも参考になれば嬉しいです!

Salesforce認定Platformデベロッパー試験とは?

Salesforce認定Platformデベロッパー試験は、Lightning Platform上でカスタムビジネスロジックやユーザーインターフェースを開発するための知識やスキルを問う、Salesforce公式の認定資格試験です。

ApexやSOQL、Lightning Web Componentsなどのプログラミングに関する知識だけでなく、Salesforceの標準機能や宣言的な開発との使い分け、ガバナ制限、セキュリティ、テスト、リリースなど、Salesforce開発に関する幅広い内容が出題されます。

単純にコードの書き方を覚えるだけではなく、要件に対してどの機能を選択するのが適切かを判断する力が問われる試験です。

Certification - Salesforce 認定 Platform デベロッパー

試験内容

Salesforce認定Platformデベロッパー試験は、以下のような形式で実施されます。

項目 内容
試験時間 105分
出題数 60問と採点対象外の最大5問
出題形式 多肢選択/複数選択方式
合格基準 正答率68%以上
試験方式 オンラインまたは試験会場にて受験可能
使用言語 英語または日本語

試験内容や合格基準は変更される可能性があるため、受験前には公式サイトで最新の情報を確認することをおすすめします。

出題範囲は、主に以下のような分野から構成されています。

開発者の基礎(27%)
  • Salesforceのマルチテナントアーキテクチャやガバナ制限は、最初に押さえておきたいポイントです。
  • 標準オブジェクトとカスタムオブジェクト、主従関係と参照関係など、データモデルに関する知識も整理しておきましょう。
  • 数式項目や積み上げ集計項目など、標準機能で実現できる内容を把握しておくと、機能選択の問題にも対応しやすくなります。
  • フローなどの宣言的な機能と、Apexによるプログラム開発の適切な使い分けもよく問われるポイントです。

Salesforceでは、すべての処理をApexで実装すればよいわけではありません。

標準機能やフローで実現できる場合は、保守性や拡張性を考慮して、宣言的な機能を選択することも大切です。

試験でも、「この要件にはフローとApexのどちらを使用するべきか」といった判断を求められる問題が出題されます。

プロセスの自動化とロジック(28%)
  • Apexの基本構文やクラス、メソッド、変数、コレクションなどは、基礎からしっかり押さえておきたい内容です。
  • Apexトリガーの実行タイミングや、トリガーコンテキスト変数の使い方も重要なポイントになります。
  • SOQL、SOSL、DMLの違いと、それぞれの使いどころを整理しておくと安心です。
  • 複数のレコードが一度に処理されることを想定し、一括処理に対応した実装を考えられるようにしておきましょう。
  • Queueable ApexやFutureメソッドなど、非同期処理の特徴についても合わせて確認しました。

特に重要なのが、ガバナ制限を考慮した実装です。

例えば、ループの中でSOQLやDMLを実行すると、処理するレコード数が増えたときにガバナ制限を超える可能性があります。

そのため、リストやセット、マップなどのコレクションを活用し、複数のレコードをまとめて処理する考え方を身につけておくことが大切です。

試験では、コードの実行結果を答えるだけでなく、「このコードにはどのような問題があるか」「ガバナ制限を回避するにはどのように修正するべきか」といった問題も出題されます。

ユーザーインターフェース(25%)
  • Lightning Web Componentsの基本構造や、HTML、JavaScript、メタデータファイルの役割を整理しておきましょう
  • コンポーネントからApexを呼び出す方法や、Lightning Data Serviceを使用する方法もよく確認しました
  • 親コンポーネントと子コンポーネント間のデータ連携や、イベントを使用した処理も押さえておきたいポイントです
  • Visualforceの標準コントローラー、カスタムコントローラー、コントローラー拡張についても、それぞれの違いを整理しました
  • 入力値の検証やエラーメッセージの表示など、ユーザーの操作に関する部分も合わせて確認しておくと安心です

業務ではLightning Web Componentsを使用する機会があったため、実際に経験した実装と結び付けながら学習することができました。

一方で、普段あまり使用していないVisualforceについては知識が不足していたため、それぞれのコントローラーの違いや、どのような場面で使用するのかを整理しました。

テスト、デバッグ、リリース(20%)
  • Apexのテストクラスやテストメソッドの作成方法についても、確実にマスターしておきたいところです。
  • Test.startTest()Test.stopTest()については、役割と使いどころをセットで確認しました。
  • 正常系だけでなく、異常系や複数レコードを処理する場合のテストについても考えられるようにしておくと安心です。
  • コードカバレッジや、System.assertEquals()などを使用した処理結果の検証も、よく問われるポイントです。
  • デバッグログや開発者コンソールを使用して、エラーの原因を調査する流れも確認しておきましょう。
  • Sandboxや変更セットなど、開発した機能を本番環境へリリースする方法についても出題範囲に含まれます。

テストコードでは、コードカバレッジの数値を満たすことだけでなく、処理結果が想定どおりになっているかを検証することが大切です。

例えば、対象のメソッドを実行するだけでテストを終了するのではなく、System.assertEquals()などを使用して、登録・更新された値が期待した結果になっているかを確認します。

また、1件のレコードでは正常に動作していても、大量のレコードを処理したときにガバナ制限へ到達する可能性があります。そのため、複数レコードの一括処理を想定したテストも重要なポイントです。


勉強方法:Trailheadと練習問題を活用!

私は、Salesforceの学習プラットフォームである Trailhead を中心に学習を進めました。

Trailheadには、Salesforce認定Platformデベロッパー試験の出題範囲に沿って整理された学習コンテンツが用意されています。

まずは試験対策用のTrailmixを進め、出題範囲の全体像を把握しました。

【Salesforce公式】Salesforce 認定 Platform デベロッパー 資格 対策 Trailmix |

Trailheadの活用法

ApexやSOQLについては、説明を読むだけでなく、実際にDeveloper Edition環境でコードを動かしながら学習しました。

特に、次のような処理は実際にコードを書いて確認しました。

  • SOQLを使用してレコードを取得する
  • Apexからレコードを登録・更新する
  • Apexトリガーを作成する
  • リストやマップを使用して一括処理を行う
  • テストクラスを作成する
  • Lightning Web ComponentsからApexを呼び出す

実際にコードを動かすことで、文法だけでなく、処理が実行される順番や、どのような場合にエラーが発生するのかを理解しやすくなりました。

また、Trailheadのハンズオンでは、実際のSalesforce環境を操作しながら課題を進めるため、知識の定着にも役立ちました。

業務で使用した機能を振り返る

Trailheadで学習した内容を、これまで業務で実装した機能と結び付けて振り返りました。

例えば、画面フローやLightning Web Componentsについて学習するときは、過去の実装を思い出しながら、次のような点を確認しました。

  • なぜフローを使用したのか
  • なぜApexが必要だったのか
  • Salesforceの標準機能だけで実現できなかったか
  • 複数のレコードを処理しても問題がないか
  • ユーザーの権限や共有設定を考慮できているか
  • テストコードでは何を検証するべきか

業務では、まず機能を正常に動作させることに集中しがちです。

しかし、試験勉強を通して過去の実装を振り返ることで、「Salesforceのベストプラクティスに沿った実装になっているか」という視点でも考えられるようになりました。

練習問題で実践演習

Salesforce認定Platformデベロッパー試験の対策では、Trailheadに用意されている試験対策コンテンツや練習問題も活用しました。

練習問題を解くときは、正解したかどうかだけでなく、すべての選択肢について理由を確認するようにしました。

特に意識したのは、以下の3点です。

  1. なぜ正解の選択肢が適切なのか
  2. なぜほかの選択肢では要件を満たせないのか
  3. どのような条件であれば、ほかの選択肢が正解になるのか

Salesforce認定Platformデベロッパー試験では、一見すると複数の方法で実現できそうな問題が多くあります。

その中から、ガバナ制限、保守性、セキュリティ、標準機能の活用などを考慮し、最も適切な方法を選ぶことになります。

単純に答えを暗記するのではなく、それぞれの選択肢の違いまで理解することで、問題の内容が変わっても対応しやすくなりました。

問題の解き方:要件とSalesforceの制約を整理する

試験では、やはり「この処理は見たことがないな……」と感じる問題や、複数の選択肢が正解に見える問題がいくつか出題されました。

そのようなときに私が心がけたのは、すぐにコードの細かい部分を見るのではなく、まず問題文の要件を整理することでした。

特に、次のようなポイントを確認しました。

  • 1件ではなく、複数件のレコードを処理する必要があるか
  • リアルタイムで処理する必要があるか
  • ユーザーの操作を伴う処理か
  • Salesforceの標準機能やフローで実現できるか
  • Apexを使用する必要があるか
  • 外部システムとの通信があるか
  • ユーザーの権限や共有設定を考慮する必要があるか
  • 同期処理と非同期処理のどちらが適切か

問題文に「大量のレコード」「外部サービス」「ユーザーの権限」「一括更新」などの言葉がある場合は、使用する機能を判断するための重要なヒントになります。

また、答えがすぐに分からない場合は、Salesforceの基本的なルールに反している選択肢から除外しました。

例えば、以下のような実装は不適切である可能性が高いです。

  • ループ内でSOQLを実行している
  • ループ内でDMLを実行している
  • 1件のレコードだけを前提にトリガーを実装している
  • テストコードが既存の組織データに依存している
  • 標準機能で実現できる処理を必要以上にApexで実装している
  • ユーザーのアクセス権限を考慮していない
  • 非同期処理が適している場面で同期処理を使用している

正解が分からない問題でも、「Salesforceで避けるべき実装」を理解していれば、選択肢をある程度絞り込むことができました。

もう一つ意識したのは、問題文に書かれていない条件まで考え過ぎないことです。

実際の業務では、既存システムの制約や例外的な要件など、さまざまな条件を考慮することになります。

しかし試験では、問題文に書かれている条件の中で、Salesforceの標準的な設計として最も適切な回答を選びます。

「実際の案件であれば別の方法を選ぶかもしれない」と感じた場合でも、まずは問題文に書かれている要件だけを基準に判断するようにしました。

Salesforce認定アドミニストレーター試験との違い

Salesforce認定アドミニストレーター試験では、Salesforceの標準機能や設定方法について幅広く問われました。

一方、Salesforce認定Platformデベロッパー試験では、同じ要件に対しても、より技術的な視点が求められます。

自動化に関する問題でも、単にフローの設定方法を覚えるだけではなく、「実務でどう設計するか」という視点で以下のような判断を重ねていくことになります。

  • フローとApexのどちらを使用するか
  • トリガーをどのタイミングで実行するか
  • 大量のレコードを処理できる設計になっているか
  • トランザクション内で処理がどのような順番で実行されるか
  • エラーが発生した場合にどのように処理するか
  • テストコードで何を検証するか

Salesforce認定アドミニストレーター試験で学んだ標準機能の知識が土台となり、その上にApexやLightning Web Componentsなどの開発知識を積み重ねていくようなイメージでした。

先にSalesforce認定アドミニストレーター試験を勉強していたことで、オブジェクトや権限、フローなどの基本的な知識を理解した状態で、開発分野の学習を進めることができました。

まとめ

Salesforce認定Platformデベロッパー試験は、Apexの文法を覚えるだけではなく、Salesforce Platform全体の仕組みを理解することが重要な試験でした。

特に、以下の内容は重点的に学習しておくと良いと感じました。

  • 宣言的な機能とApexの使い分け
  • ガバナ制限
  • 一括処理に対応したApexトリガー
  • SOQL、SOSL、DML
  • Lightning Web Components
  • Apexのテストコード
  • セキュリティと共有設定
  • デバッグとリリース

Trailheadで体系的に知識を学び、実際にコードを書きながら動作を確認することで、少しずつ理解を深めることができました。

また、業務で経験した実装について、「なぜこの方法を選んだのか」「Salesforceのベストプラクティスに沿っているか」という視点で振り返ることも、非常に効果的でした。

これからSalesforce認定Platformデベロッパー試験の受験を考えている方は、コードや問題の答えだけを暗記するのではなく、Salesforce特有の制約や設計思想まで理解することをおすすめします。

資格取得のために学んだ内容は、試験だけでなく、日々の開発や設計にも役立つはずです!

若手エンジニアから見た「QAエンジニアとは何か」

こんにちは!
チームスピリット開発チームで働いているホン・ヨンテクです。
今年の6月27日に大阪の住まい情報センターで開催されたJaSST'25 Kansaiに参加いたしまして、その場で経験した事を共有したいと思います。


参加のきっかけ

参加のきっかけは単純でした。 社内のSlackチャンネルでJaSST関西参加者募集の案内を見かけ、「JaSST」とは何か気になりました。 案内ページを確認すると、JaSSTとは「ソフトウェアテストシンポジアム」であり、今回のテーマは「QA expo 2025」であることが分かりました。

自分のチームにもQAエンジニアの方がいますので、普段協力して働いてますが、実際のところ「QA」という職務については全く分かっていませんでした。 今回のイベント参加で「QAエンジニアとは何か」「QAエンジニアが開発者に何を求めているのか」の問いにヒントが見つかると思い参加を決めました。

↓イベント情報はこちらをご参照ください jasst.jp

会場まで移動・会場の雰囲気

当日は新横浜駅から新大阪駅まで新幹線で移動し、午前9時開始の基調講演に間に合うよう、やや早めに会場へ向かいました。 朝食は駅で弁当を購入し、車内で簡単に済ませました。

会場に到着すると、すでに多くの参加者が集まり、資料を確認する姿やブース準備を進める様子が見られ、想像していた以上に本格的で活気のあるイベントだと感じました。

イベントは9時から17時まで複数のセッションで構成されており、各セッションの間には休憩時間が設けられていました(2セッションごとに1回)。 開始前の会場全体は重苦しさはなく、比較的カジュアルで、参加者同士が自由に雑談できる雰囲気でした。

休憩時間には周囲のブースを巡ろうと考えつつ、先に到着していた弊社メンバーと合流し、席に着きました。

記憶に残るセッション

全15件の講演・セッションの中から、特に印象に残った1つのセッションをご紹介したいと思います。

実践!実例マッピング!うまく実施するためのチーム作り

本セッションでは、新機能開発において仕様が曖昧なまま進んでしまうことによる課題と、その解決手法として「実例マッピング」が紹介されました。

実例マッピングは、以下の4つの要素で構成されます。
  • ユーザーストーリー
  • 実例(具体的な使用ケース)
  • ルール
  • 質問
実施の仕方は以下の3段階で行われます。
  1. 機能の理想的な形をユーザーストーリーとして定義し、その後、具体的な利用例を列挙します。
  2. プロジェクトオーナー(PM)はその実例を確認しながら、妥当性を判断し、認識のずれがある部分を明確にしていきます。
  3. 議論の中で「こうした方がよい」と合意した内容は【ルール】として整理し、その時点では結論が出ないが確認が必要な事項は【質問】として残します。

上記の過程を関係者と共に進めることで、製品仕様が漸進的に具体化され、共通認識が形成され、結果的に作業の手戻りを減らすことができるという点が強調されました。

また、実例マッピングを効果的に実践するためのポイントとして、

  • 関係者を積極的に巻き込み、チームとして議論すること
  • 企画の初期段階で実施するほど効果が高いこと

が挙げられました。

実際、私自身も「もっと早い段階でPMと実例ベースで話しておけばよかった…」と思わされた経験が何度もあります。 開発者同士だけで設計を進めてしまい、後になって「ここは考慮できていなかった」「このケースは想定していなかった」と気づくことが少なくありませんでした。

だからこそ、実例マッピングを初期段階から取り入れることで、こうした認識ずれを早めに発見し、結果的に手戻りを減らせるのではないかと強く感じました。


ワークショップ体験

今回のJaSST'25 Kansaiでは、講演セッションに加えてワークショップにも参加しました。

ワークショップでは複数名の参加者でグループを構成し、与えられた課題に対して意見交換やディスカッションを行う形式で進められました。 特に印象的だったのは、「QAアクティビティカード」と呼ばれるカードを用いた進行方法です。 参加者それぞれが、課題解決に有効だと思われるQA手法が記載されたカードを選び、それをもとに議論を展開していくというものでした。

私自身はテストに関する知識は足りないと思っていましたが、 カードに書かれた内容を一つひとつ確認しながら考えることで、自分なりに「これは有効ではないか」と思える意見を形にすることができました。 グループ全員が自分の意見を積極的に話し合う雰囲気であったため、すごく楽しかったです。 イベントはテスト関連の知識が足りない人も参加しやすい設計になっていた点も非常に良いと感じました。

可愛いデザインが特徴のQAアクティビティカード

まとめ・総括

参加前は多少の緊張もありましたが、実際に足を運んでみると、会場は想像以上にカジュアルで開かれた雰囲気でした。自然な形で参加者同士が挨拶を交わし、名刺交換を行いながら交流できたことも印象的であり、特にワークショップでは終始リラックスしつつ、心から楽しめる時間を過ごすことができました。

今回の参加を通じて、「QAエンジニアとは何か」という当初の疑問に対して、 QAエンジニアはプロダクトとして世に出せる品質へと導く、欠かせない役割を担っているという結論に至りました。

とりわけ、生成AIを活用した開発が当たり前になり、バイブコーディングによってコード量も速度も飛躍的に増えている現在では、 “AIが生成したコードをそのまま製品として提供して問題ないのか” を見極める視点と基準が、これまで以上に求められているためです。

一方で、「QAエンジニアが開発者に何を求めているのか」という点については、明確な答えを出せず、今後の自分自身の課題として引き続き考えていきたいテーマとして残りました。

今回のJaSST'25 Kansaiへの参加は、自身の視野を広げるとともに、QAおよび開発に対する考え方を見直す貴重な経験となりました。 次回はテスト分野に限らず、技術全般を扱う展示会やカンファレンスにも積極的に参加してみたいです。

今回の記事が、少しでも皆さまの気づきや学びの一助になれば幸いです。 ここまでお読みいただき、ありがとうございました。

AWS ISV / SaaS Community Day Vol.2 に登壇しました ~AIエージェントで開発生産性を高める取り組み~

こんにちは。開発チームの橘です。

2025年10月9日、AWS Startup Loft Tokyoで開催されたAWS主催のイベント「ISV / SaaS Community Day Vol.2」に登壇しましたので、イベントレポートを書きたいと思います。

イベント概要

本イベントでは、「SaaSビジネスを加速させる生成AIとデータ活用」というテーマでAWSの最新サービスや各社の取り組みが紹介されました。

チームスピリット開発チームではAmazon BedrockのLLMを利用した開発生産性向上に取り組んでおり、ご縁がありまして登壇させていただきました。

発表内容

登壇テーマは「AIエージェントを活用した開発生産性の向上事例」です。

背景

生成AIの進化により、開発現場でもAI活用の可能性が急速に広がっています。チームスピリットでは、Microsoft CopilotやClaudeなどの対話型AIを社内で試験導入しており、その効果を実感していました。

今回、AWS様からAmazon Bedrockの割引クレジットをご提供いただき、既にAWSを製品基盤・開発支援基盤として利用していたこともあってBedrockのLLMを利用したAIエージェントの検証を本格的に開始しました。

Bedrock選定の狙いとしては、企業利用にあたって不可欠な「セキュリティ」(LLM利用による情報漏洩の防止など)、「ガバナンス」(利用状況の監視や利用者・料金などのコントロール)を担保しながら多様なLLMやエージェント製品を比較検討しつつAI活用を推進することにあります。 

検証したツール

  • Cline+Bedrock(Claude)
  • Claude Code+Bedrock(Claude)
  • Cursor
  • GitHub Copilot
  • Perplexity
    ※今後はKiro、Atlassian Rovo Dev、Figma Makeなども検証予定。

活用事例

開発エンジニア

  • 勤怠計算問題集アプリを数時間で開発
  • デプロイ可能なコードの生成・デバッグがほぼAIで完結

PM(プロダクトマネージャー)

  • ユーザーストーリーマップやUIモックをAIで生成し、企画段階の仮説検証を加速

QA(品質保証)

  • テストデータ作成や観点抽出、ケース作成で最大90%の工数削減
    例:テストデータ作成は「2~3日 → 2~3時間」に短縮

社内アンケート結果

  • 約60%が「50%以上の生産性向上が見込める」と回答

課題

  • Bedrockの従量課金によるコスト予測の難しさ
  • LLMリクエストエラーやコンテキスト制限
  • AI活用に合わせた開発プロセスの再設計

今後の展望

Bedrock+AIエージェントの検証は上記の通り一定の成果を挙げているものの課題もあります。今後の展望としては以下の通りです。

  • 利用ログの分析やユースケースに応じたLLMの効率的な利用を通してコスト最適化を推進
  • AI活用の解像度をさらに高め、属人化対策に活用
  • 設計・テスト・ドキュメント生成など、開発全体でのAI活用を推進
  • AI活用事例の蓄積

まとめ

僕自身も普段の開発でAIに実装アイデアを出してもらったりコードレビューをしてもらったりしていて、生産性の圧倒的な向上を実感しています。

他社の発表やイベント後の懇親会での会話から感じたこととしては、既に生成AIで業務効率化や新サービスの提供を実現しているというケースがある一方で、活用のイメージが湧いておらず生成AIを利用していないというケースもまだまだありそうで、生成AIの伸び代は大きそうです。

今後もチームスピリットは、開発者体験を向上させる取り組みを続けていきます。

JaSST初参加と登壇で思ったこととその後の変化

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


今回、6月末に開催されたJaSST'25 Kansai(以降JaSSTと記載)に参加した際の感想について、述べてみたいと思います。
実は、JaSSTの参加は今回が初めてでした。
JaSST登壇までの取り組みや、JaSST当日の様子、登壇を終えての心情の変化などについて述べてみたいと思います。

「目次」

 

JaSST Kansai公式サイトは以下となります。
https://jasst.jp/kansai/


JaSST登壇までの準備

JaSST参加・登壇は、開催の2ヶ月前ぐらいに参加を申し出ました。
申し込んだ理由としては、以下が挙げられます。

  • 元々参加してみたかった
  • 関西のQAやテスト関連の方と交流をしてみたい
  • 関西へは行ったことがないため、いってみたい

参加・登壇はスムーズに決定し、早速JaSST登壇のプレゼン資料の作成に取り組みました。

プレゼン資料の候補ピックアップ

まずは、プレゼン資料の候補をピックアップしました。
私は、TeamSpirit の経費機能や新機能を開発するチームに所属しており、開発関連の内容にしたいと思いました。
過去携わった開発として、以下があります。

  • オフショア開発
  • 保守開発
  • 新規プロダクト開発

以上からどれにしようか迷いましたが、いずれも共通した内容がありました。
それは、「勤怠設定ナビ」というプロダクト開発です。

「勤怠設定ナビの概要」
https://www.teamspirit.com/news/product/001213.html

勤怠設定ナビは、オフショア開発、新規プロダクト開発、保守開発にも関する内容でした。
私にとってとても感慨深い開発でした。

オフショア開発チームとの新規プロダクト開発で、検知した課題と課題に対して改善したことを述べようと思い至りました。

プレゼン資料作成、完了まで

プレゼン資料の作成の流れとして、以下のように取り組みました。

  1. ストーリー立て
    まずは、箇条書きでストーリー立てて書きました。
    その後は、文字数をあまり気にせず、伝えたいことを書き出してみました。

  2. レビューの繰り返し
    レビューは、QAメンバーやリーダーに確認頂きました。
    レビューで指摘があった箇所の修正や、スライドの文字数やレイアウトを調整して、プレゼン資料のみやすさ・読みやすさを工夫しました。
    レビュー回数は複数回要しましたが、回数を重ねることで、プレゼン資料のクオリティは上がったと思います。

  3. 資料作成以外の取り組み
    資料作成以外で、プレゼン登壇に向けての取り組みも行いました。
    私は、過去にイベント等で登壇してプレゼンする経験がなく、登壇当日は特に緊張すると思い、短期間ではありましたが、プレゼン時のポイントを書籍等で学びました。
    プレゼンで取り入れたものとしては、以下となります。
    1. 特に伝えたいキーワードや内容をリピートして伝える
    2. 赤裸々な感情(ドキドキ、ワクワクなど)を用いて話す
    3. 話すだけではなく、身振り手振りも用いる

  4. プレゼンのブラッシュアップ
    レビューやリハーサルを繰り返し実施し、プレゼン資料やプレゼンのブラッシュアップを登壇当日まで行いました。
    各スライドの「ノート」部分に、話す際の補足を入れたり、力を入れて話すスライドでは、感情を込めたり工夫しました。

 

JaSST当日

当日は、会場に早めに着くことができ、登壇までの準備等進めました。

登壇した際に感じたこと/思ったこと

登壇の直前までは、正直ずっと緊張していました。
私は午前のセッションで、順番としては4番目でした。

登壇前までは緊張が続いていましたが、登壇の順番となり、名前が呼ばれて登壇しプレゼンし始めたら、吹っ切れて自然体で話す事ができました。
アドリブも取り入れたりして、会場の反響も良かったのではないかと思います。
自己紹介時に、趣味の筋トレについて話したところ、注目を得る事ができました。
プレゼンは時間内に収まり、概ね成功したと思いました。


嬉しかったのが、登壇直後に質問や声を掛けてくださった方がいました。
オフショア開発に関する悩みや課題についてなど、共感頂いた部分もあった旨を話したりしました。


登壇後は、リラックスして他登壇者のプレゼンを聞くことができた。
テストやQAに関する悩みや課題に対して、どのように対応したかなど、各登壇者の方のプレゼン内容はもちろん、プレゼンでの立ち振舞いや話し方など、色々と参考になりました。

情報交換会参加で思ったこと/感じたこと

プログラムの最後に、「情報交換会」があり、登壇された方やJaSSTに参加された方と積極的に話に行きました。
この場でも、オフショア開発で困ってること、意思疎通の難しさなど話題に上がりました。
また、普段のQAや開発の取り組みについて、気をつけていることや、AIの活用など、様々なことについて意見交換しました。


今回のJaSSTは、自社以外の方とのやり取りで、新たな気づきや刺激を受けることができました。

参加前までは、堅苦しいイメージという印象が強かったですが、いざ参加してみると、QAやテスト等の様々な情熱をもった方が参加されるため、予想よりカジュアルでとても有意義な一日でした。

 

JaSST参加後の変化

JaSST参加後は、プラス思考となり、業務やプライベートでの自己学習等のモチベーションアップに繋がりました。
さらに、登壇セッションや意見交換会で話題に上がった「AI」に関する取り組みを意識するようになりました。
「AI」を用いて業務効率を図り、更により良いQAやテスト活動に活かしたいと思いました。

初めての参加・登壇だったので、色々と大変でしたが、参加できて本当に良かったと思います。

 

最後に

チームスピリットでは、一緒に働く仲間を探しています。
興味を持っていただけましたら、ぜひお話しできたらと思います。
是非よろしくお願い致します!


最後まで読んで頂き、ありがとうございました!

 

Salesforce Administrator試験受験してみた

はじめに

こんにちは!開発チームの古厩(ふるまや)です。

昨年の4月に新卒で入社し、早いもので1年が過ぎました。日々の業務を通してSalesforceに触れる機会が増え、「もっと深く理解したい!」という思いから、このたび Salesforce Administrator試験 に挑戦し、無事に合格することができました!

今回は、この試験に関する概要や出題内容、私が実際に行った学習方法、そして試験中にどのように問題を解いたかについて、実体験を交えてご紹介します。Salesforceの基礎知識を体系的に身につけたい方にとって、少しでも参考になれば嬉しいです!

Salesforce Administrator(アドミニストレーター)試験とは?

Salesforce Administrator(アドミニストレーター)試験は、Salesforceの基本的な管理・運用を担う人材としての知識やスキルを問う、公式認定の資格試験です。

Salesforceを日常的に使うだけでなく、ユーザーやプロファイル、レポートの管理、オブジェクトの設計など、幅広い管理業務が出題範囲となっています。特に、システムの導入・運用を行う立場として、Salesforceの設定やカスタマイズの知識が求められます。

試験内容

Salesforce Administrator試験は、以下のような形式で実施されます。

項目 内容
試験時間 105分
出題数 60 問と採点対象外の 5 問
出題形式 多肢選択/複数選択方式
合格基準 正答率65%以上
試験方式 オンラインまたは試験会場にて受験可能
使用言語 英語または日本語

出題範囲は広く、主に以下のような分野から構成されています:

設定とセットアップ(20%)
  • 会社情報、営業時間、通貨、ログイン制限などの基本的な組織設定について理解が必要です。
  • ユーザインターフェースの設定(リストビュー、Lightning アプリビルダーなど)の違いと使い方を把握しておきましょう。
  • ユーザの作成・権限管理、共有ルールやロール階層など、セキュリティコントロールの設定も重要なポイントです。
オブジェクトマネージャとLightningアプリケーションビルダー(20%)
  • 標準オブジェクトとカスタムオブジェクトのリレーションシップ構造(主従関係・参照関係など)を理解しておくことが求められます。
  • 項目やページレイアウトの作成・編集・削除の影響も確認しておきましょう。
  • ビジネスプロセスやレコードタイプの設計と割り当てに関する知識も問われます。
セールス&マーケティングアプリケーション(12%)
  • 営業プロセス(リード→商談)に関連する機能(パス、予測、Einsteinスコアリングなど)の活用法が出題されます。
  • キャンペーン管理やリード割り当てルールなど、マーケティング機能の基礎もおさえておくと良いです。
サービス&サポートアプリケーション(11%)
  • ケース管理(割り当てルール、キュー、エスカレーションなど)の自動化とナレッジの活用方法について問われます。
  • サポート業務の流れをシナリオベースで理解しておくと効果的です。
生産性向上とコラボレーション(7%)
  • 活動管理、Chatterの使い方、モバイルアプリの機能など、日常業務の効率化に関わる機能を理解しておきましょう。
  • AppExchangeの活用事例にも触れておくと◎。

業界やカテゴリーで条件を絞って探せる!アプリ活用事例集

データ管理&分析(14%)
  • インポート/エクスポートや大量削除などのデータ操作に関する基本的な注意点を把握しておきましょう。
  • レポート作成・ダッシュボード設定時に必要な知識(共有設定、データソース、グラフの種類など)もよく出題されます。
ワークフロー/プロセスの自動化(16%)
  • フロー(Flow Builder)を中心に、自動化の設計・選択に関する問題が多く出ます。
  • ワークフロールール、プロセスビルダー、承認プロセスの違いや適切なユースケースの判断が求められます。

勉強方法:Trailheadと公式の過去問を活用!

私は、Salesforceの学習プラットフォームである Trailhead を中心に学習を進めました。Trailheadでは、「Salesforce Administrator(アドミニストレーター)試験」向けに整理されたトレイルが用意されており、ポイントを貯めながら楽しく学べます。

Trailheadの活用法

まずはAdministrator試験用の基本的なトピックを含んだトレイルミックスを完了させ、全体像を把握しました。実際に手を動かして設定を試せるハンズオン形式が多く、知識の定着に非常に役立ちました。

【パートナー向け】認定アドミニストレーター資格 対策 Trailmix | Salesforce Trailhead

公式の過去問で実践演習

Salesforce公式が提供している 練習問題(Practice Test) も活用しました。本番に近い形式で出題され、各問題の解説もついているため、苦手分野の把握や試験対策としてとても有効でした。解説を読み込みながら理解を深めることで、単なる暗記ではなく「仕組みの理解」に繋がります。

Platform Administrator Practice Test

問題の解き方:知らない問題にも立ち向かうコツ

試験では、やはり「これは知らないな…」という問題がいくつか出題されました。

そのようなときに私が心がけたのは、「問題に登場する用語から、自分ならこの機能にどんなことができるようにするか?」を考えることでした。

たとえば、「エンタイトルメント管理」「ケース割り当てルール」など聞き慣れない言葉が出ても、それがSalesforceの中でどのように動作するのか、自分の経験や文脈から推測して解答するようにしました。

機能の名前は直感的に意味が込められているものが多いので、完全に知らない問題でもある程度は予測で正解に近づくことができました。

まとめ

Salesforce Administrator試験は、範囲がとても広く、一見ハードルが高く感じられますが、Trailheadでの体系的な学習と、公式の練習問題を活用することで着実に力をつけることができます。

また、知らない問題に対しても、単語の意味や機能の直感的な理解をもとに冷静に解答することが、合格のカギになります。

これから受験を考えている方は、ぜひTrailheadを活用しながら、Salesforceの基礎から一歩一歩学んでみてください。
「管理者」としての視点を身につけることで、日々の業務にも大きな自信が生まれるはずです!

JaSST'25 Kansaiに参加しました:登壇者を支え、生成AIに学ぶ

https://cdn-ak.f.st-hatena.com/images/fotolife/t/toro_spirit_QA/20250731/20250731184703.jpg ※この画像は、JaSST'25 Kansaiの雰囲気をイメージして生成AIで作成したものです。

はじめに

こんにちは、QAエンジニアの岡内です。

今回は、2025年6月に大阪で開催されたJaSST'25 Kansaiに参加してきました。
その体験を通じて感じたことや学び、ちょっとした裏話などをお届けします。

JaSSTとは

JaSSTというキーワードを初めて耳にした方もいらっしゃるのではないでしょうか?
JaSST(Japan Symposium on Software Testing)は、ソフトウェアテストに関する知見を深めるためのシンポジウムで、業界の第一線で活躍する方々の講演や、実践的なワークショップが行われます。
北は北海道から南は九州まで、全国各地で開催されています。

今回参加したJaSST'25 Kansaiは、大阪で開催されました。

JaSST'25 Kansaiへの参加を決めたきっかけ

過去に何度かJaSSTに参加したことがありますが、今回参加を決めたきっかけは2つあります。

登壇者および初参加者のサポート

今回、弊社からは2名が参加の意思表明がありました。
1名はQAメンバー、もう1名は開発メンバーです。
QAメンバーは参加も登壇も初挑戦であり、2023年に登壇した身として本番まで助力せねばと意気込みました。
また、開発メンバーの参加は個人的にとても嬉しく、これを機にソフトウェアテストやそのイベントに今以上に興味を持ってもらうチャンスだと考えました。

招待講演が気になった

生成AIで効率化を、と言われている昨今。
品質保証のみならずプロセスをどう変えていけばよいのか、そもそもどのように自身が学んでいけばよいのか悩んでいます。
水野 昇幸さんの『変化する開発、進化する体系:時代に適応するエンジニアの知識と考え方 ~変わり続ける現場で生き抜くために~』が、この悩みから一歩抜け出すヒントになるのではないかと考えました。

当日までの舞台裏

先に書いた通り、登壇者および初参加者のサポートをすることが、今回の私の参加意義の1つです。

登壇リハーサル

業務で使う資料とは違う角度で気を付けることが有りました。
弊社内の業務では弊社のことを知っているのが当たり前の相手が聴衆ですが、そうではありません。
また、登壇という場で本人のキャラクターも生かして話していただく必要があります。

情報交換会を見越したTシャツや名刺準備

HR Tech系のイベントと比べると、弊社をご存じの方は少ないと予想されます。
その場合、情報交換会で他社の皆様と接する際に、初見で弊社のメンバーと認知いただく必要があります。
その際に初見で認識いただくのにシャツ、後で思い出していただくのに名刺が必要ですが、普段使うことがなかったがためにこれらの準備に手間取りました。

当日の様子

期待と不安に胸躍らせながら、いよいよ当日を迎えました。

登壇の様子

弊社からは、テクノロジーセッションで「オフショアで挑む新規プロダクト開発」というタイトルでQAエンジニアの須崎が発表しました。
内容は後日お届けしますが、ここではその様子を。

リハーサルのときよりも堂々として、制限時間内に最後まで伝えきることができました。

弊社製品をご存じの方がいらっしゃるか会場の皆さんへ質問したときの1枚です。
弊社のお客様がいらっしゃって、私もとても嬉しいです。

興味深かった講演

招待講演も含め、私が特に興味深いと思ったセッションを2つご紹介します。

『変化する開発、進化する体系:時代に適応するエンジニアの知識と考え方 ~変わり続ける現場で生き抜くために~』

speakerdeck.com

生成AIを使うことによってスピードアップする部分があるのは確かですが、何もかもが一変するわけではありません。
しかし、既存の手法をプロンプトにすることで机上検証のスピードが速くなる可能性はあります。
特に印象に残ったのは、変化を楽しむ姿勢です。
日々変わる技術に対して、恐れるのではなく柔軟に取り入れていく姿勢が大切だと再認識しました。

『テスト設計コンテストで新たな挑戦者求む!生成AIと創るテストの未来』

drive.google.com www.youtube.com

生成AIと協業し、テストプロセスの構築や自動化の、具体的な事例を紹介いただいています。
明確な指示を与えないとトークンが大量になってしまったり抜け漏れがある可能性はあります。
ですが、ロジカルに明文化できることは生成AIと協業できるため、生成AIを使うプロセス構築のヒントが得られました。

情報交換会にて

今回の参加のきっかけの1つ、「登壇者および初参加者のサポート」の〆です。
登壇は無事に終わったものの、果たして開発者にソフトウェアテストやそのイベントに今以上に興味を持ってもらえたのか?
幸いにして、参加したワークショップの講師の方とお話いただいたり他社の方とお話いただいたり、率直に「楽しかった!」と感想をもらえました。 ここでやっと、肩の荷が下りました。

おわりに

生成AIとともに歩む未来のイメージがつき、悩みから一歩抜け出すことができそうです。 また、今回の経験を通じて、技術だけでなく「人とのつながり」や「学び続ける姿勢」の大切さを改めて感じました。

弊社では仲間も継続して募集しています。
まずは気軽に、カジュアル面談からお声がけください。 herp.careers

QAエンジニアが認定スクラムマスター研修を受けてみました

はじめに


こんにちは、QAエンジニアの岡内です。
今回は、私が認定スクラムマスター研修を受講した感想をお話します。

受講した認定スクラムマスター研修


2024年07月24日から26日の3日間、株式会社アトラクタが主催する認定スクラムマスター研修を受講しました。 www.attractor.co.jp

座学とワークショップにより、スクラムについて体系的に学びました。

受講したかった理由


「スクラムおよびスクラムマスターを体系的に理解し、スクラムチームと関わることができるようになりたい」

この研修を受講する2024年07月までの、私の業務についてお話します。
私はミッドマーケット向け製品のQAをしています。
ただし私が所属するのは特定の機能開発をするチームではなく、QAエンジニアのみで構成されるリグレッションテストチームというサブチームです。
ミッドマーケット向け製品の開発体制は、こちらをご覧ください。 teamspirit.hatenablog.com

リグレッションテストチームは、他チームのサポートを行うことがあります。
より適切なサポートを行うために、今よりも他チームのことを理解したいと考えるようになりました。

他チームのうち、サポートを行う頻度の高いチームはスクラム開発を行っています。
スクラム開発について理解することができれば、今よりも他チームのことを理解することができるのではないかと考えました。

書籍や動画を使用して学習していましたが、独学ではスクラムマスターについて体系的に理解することに限界を感じるようになりました。

受講した感想


受講したかった理由である「スクラムおよびスクラムマスターを体系的に理解し、スクラムチームと関わることができるようになりたい」には、近づけたと思います。
この研修によってスクラムについて座学を受けたことも要因の1つですが、ワークショップの中で次の2つの気づきがあったからです。

1. 「ユーザー」は、誰のこと?

業務に誰かと話す中で「ユーザーにとってこの機能は(以下省略)」のように、ユーザーという言葉を使うことはありませんか?
私はユーザーと使ってしまうことがありますが、話す相手とユーザーの指す姿が一致しているのでしょうか?
研修中、何だか話が嚙み合っていないと感じたときに、ユーザーの指す姿を質問してみると、話し相手と一致していないということがありました。
ついつい使ってしまう「ユーザー」、この指す姿が話し相手と一致しているかどうかは業務でも役立ちそうです。

2. その機能は、どんな価値を届けるため?

機能開発をしていると、ついつい色々な機能やオプションを付けたいと思うことはありませんか?
しかしそれは、本当に価値を届けるための行動でしょうか?
研修中、機能を増やすことに注力しそうになってしまったとき、どんな価値を届けたいのかをチームに問いかけることによって立ち止まることが出来ました。
QAである私にとって価値に着目するのは自然なことではあるものの、その価値が指すものがチームと同じなのか気を付ける必要がありそうです。

受講後に工夫したこと


他チームのサポートが無い時期であっても、受講したことの中で活用できたことがあります。
それは、リグレッションテストチームで行うふりかえり手法を変えることです。

リグレッションテストチームが使ったことのある手法として、それまではKPTを高頻度で使っていました。
チーム内で意見を言いにくいという雰囲気こそ無いものの、私たちリグレッションテストチームのメンバー同士で考えや思いを伝えやすくする手法があるのではないかと考えました。
そして、KPTではない2つの手法を使い分けるようになりました。

温度計

温度計とは、感謝・気づき・興味・提案・希望の問いに答えていく手法です。
こちらのふりかえりカタログを参考にしました。
speakerdeck.com

リグレッションテストチームとして経験の浅いテストを実施した後のふりかえりで、この手法を使用しました。
こちらは、実際にリグレッションテストチームのふりかえりに使用した温度計です。
イラストは、フリー素材集のいらすとやから探しました。
①にあるように、興味から改善アイデアが出ることがありました。
温度計_イメージ

3匹の子豚

3匹の子豚とは、童話「3匹の子豚」に出てくる藁の家・木の家・レンガの家に見立てて意見を集める手法です。
藁の家は今にも崩れてしまいそうなこと、木の家は凡そ問題は無いが改善できそうなこと、レンガの家は盤石なことを指しています。
こちらのブログを参考にしました。
qiita.com

リグレッションテストチームとして何度か経験のあるテストを実施した後のふりかえりで、この手法を使用しました。
チームメンバー全員が童話「3匹の子豚」を知っており、藁の家・木の家・レンガの家のイメージが一致しやすかったです。
こちらは、実際にリグレッションテストチームのふりかえりに使用した「3匹の子豚」です。
イラストは、温度計と同様にフリー素材集のいらすとやから探しました。

①は、藁の家から木の家になるためのアイデアを考えた様子です。
②は、木の家からレンガの家になるためのアイデアを考えた様子です。

3匹の子豚_イメージ

おわりに


研修に含まれるワークショップで、業種や職種の違う皆さんと関わる中で話し合うことの大切さを改めて実感しました。
研修の時には言葉を尽くしているものの、普段の業務のときはついつい説明を省いてしまっていることがあるかもしれないと思います。

スクラムについて学ぶ研修でしたが、相手と同じゴールに向かっているが言葉を尽くす大切さを実感できた機会でもありました。