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

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

Autify運用編:利用者アンケートを元に活用事例を共有します!

はじめに

こんにちは!
今年もアドベントカレンダーの幹事やったり、来年もほろよいてっくの開催幹事も頑張りたいQAチームのマネージャになりました、生井(id:riririusei99)です。

 

今回のテーマは「Autifyを導入したけど、その後どうなったの?」みたいな話を書きたいと思い、そこでAutifyのコミュニティで「コミュニティメンバー実態調査アンケート vol.1」が開催されていましたのでその回答とチームスピリットでの実態を添えて紹介していこうと思います。

 

Autifyとは&これまでの歩み

Autifyとは「AIの力で品質保証の課題を解決し、素早い開発サイクルを実現する」自動テストプラットフォームツールです。autify.com
合わせて、チームスピリットでの導入については下記のブログで書いていますのでぜひそちらもご確認ください。

teamspirit.hatenablog.com

 

teamspirit.hatenablog.com

 

ポットキャストでも話しています。

open.spotify.com

 

 

コミュニティメンバー実態調査アンケート vol.1

Q1 - あなたの職種は何ですか?

A:QAエンジニアです。

チームスピリットのQAエンジニアはスクラムチームの開発チームの一員という立ち位置で、機能テストの他にも非機能系のテストも担当したり、スプリント後のテストレポート作成やプロセス改善など、プロダクト品質だけでなくプロセス品質の向上に責任をもつエンジニアです。

Autifyの導入も健全なE2Eテストの構築・運用のための施策になります。
チームスピリットの品質保証については別の記事を書いていますので、こちらの記事をご確認ください。

teamspirit.hatenablog.com

 

Q2 - Autifyの使用経験はどれくらいですか?


A:トライアルを始めたのが今年の1月なので、Autify歴はもうすぐ1年になります!

Autifyを使用する前は、SeleniumWebDriver(Java)とBrowserStackを使って自動テストを書いていましたが、特定のメンバーしかメンテナンスができず保守の面で問題を抱えていました。

また、一部ではWebDriverIOを使った自動テストも併用して使っており、こちらは今でも使用しています。

 

 Q3 - テスト自動化のご経験はどれくらいですか?

 

A:専任の経験はないですが、テスト自動化の経験はそこそこ…

自動テスト作成は作り始める前にあらかじめ運用面で考えておかないと、メンテナンスの面での諸問題を抱える気がしています。

入社したばかりの頃にCIサーバを立てて自動テストの実行環境を用意するとこから携わることができました。いろいろ経験できたのはよかったのですが、サーバのOSアップデートとか考えないといけない等々、本筋とは違う仕事が増えてしまったのも事実です。

 

Q4 - テスト自動化の対象は何ですか? 

 

A:自社製品である「TeamSpirit WSP」の自動テストを行っています!(英語サイトしかなかった…。)

www.teamspirit.com

 

Q5 - 何を自動化していますか?

 

A: 主要機能のスモークテストの実装を行っています!

リリース前の回帰テストとして使われる他にも、Salesforceプラットフォームで稼働するアプリなので、プラットフォーム側のバージョンアップの際の検証にも使われるので回帰テストの中でも重要な役割をもつ箇所を自動化しています!

 

Q6 - 社内でAutify使用者は何人いますか?

 

A:5人以上で社内でAutifyのユーザはたくさんいます!!

導入時はスクラムチーム1チームに導入していましたが、現在は主に日本の拠点のチームでAutifyの自動テストが作成されています。

メインでAutifyを使うQAエンジニアは4人いて、他にもスポットフロントエンドをはじめとした複数の開発メンバーもAutifyで自動テストを書いています!少しでもAutifyを触ったことがある人は20人います。(投稿時点)

また、複数人が同じシナリオだったりステップグループを触ったりすることがあるのでAutify用のSlackチャンネルを使って情報共有をしたりしています。
ここではステップグループを直した時や、汎用的に使えるJSステップを書いたときなどが話されています。

また、様々なロールのメンバーがこのチャンネルにいるのでならではの知見を得られることができました。

f:id:riririusei99:20201216223124p:plain

チャンネルのやりとりの様子

 

 

f:id:riririusei99:20201216222441p:plain

余談:フロントエンドエンジニアによるお褒めの言葉

 

Q7 - JSステップを使いこなせていますか?

 

A:十分に使いこなせてるが微妙ですが、使ってます!

チームスピリットではAutifyをなるべくシンプルに使うように心掛けています。
なので、なるべくレコード時と変わらないような処理をテストできるように心掛けていますが、プロダクトの性質上時間の経過で画面の情報が変わってしまう部分などにJSステップを使っていたりします。

そういった場合にJSステップを使うことが多いです。
今回はJSステップを使った部分を公開したいと思います。

f:id:riririusei99:20201216233520p:plain

勤務表の月度表示の例

今日の日付を取得して、必要なところだけ加工して使ってる感じです。

 var today = new Date();
var year = today.getFullYear() + "年";
var month = ("00"+ (today.getMonth()+1)).slice(-2) + "月";
console.log(year+month); 
return year + month;

 

 

また、Salesforceならではの事象ですが、ログインユーザ(組織)ごとにドメインが違うため、URL遷移した時にシナリオが組織で使いまわせなかったのですが、JSステップを使って遷移先のURLを共通で作れるように工夫するようにしました。(順次載せ替え中)

f:id:riririusei99:20201216234258p:plain

ログインユーザごとにドメインが違う問題

ステップグループ機能ですでにログインしているのでドメインを取得してから、遷移先URLを作る感じです。

var path = "移動したいURL"; 
var domain = document.domain;
var url = "https://" + domain + path;
return url;

 

Q8 - 1シナリオのステップ数は平均どれくらいにしていますか?

 

A:30ステップ以内にできるように頑張っています。

他のメンバーが見た時にわかりやすくするために、なるべく手順を減らすようにチーム内の約束事としています。
そのために「何をテストするか」はあらかじめ明確にしておきます。自分たちの場合は前述した主要機能のスモークテストです。何をテストするのか手順を明確にしたうえで、機能を細かい単位で分割化したり、簡略化することでシンプルなシナリオにするよう心掛けています。

一方で課題もあります。Autifyだけで自動テストを完結するように作っているため、自動テストの準備とテスト後の後片付けもそのシナリオ内で行っています。
その後片付けのステップを作り込む必要があったり、片付け自体がステップ数を使うことがあります。

今後ステップグループを途中に入れられたり、共通の処理をまとめてステップグループとするみたいな機能があると嬉しいです!

 

f:id:riririusei99:20201217000711p:plain

準備と片付けでも結構なステップ数になる

 

おわりに

いろいろ書きましたが、チームスピリットではAutifyの活用という意味ではまだまだ改善の余地があると思っています。(本当はいろんなテストに当て込みたい!)
なので、引き続きアップデートがあればまた記事を書きたいと思います。

今回の記事は自動テストアドベントカレンダー18日目の記事なります。

ありがとうございました。 

 

qiita.com

 

TeamSpirit Singaporeと日本の開発チームがうまくやってる話 2020

TeamSpirit Singaporeでプロダクトマネージャーをしている二宮です。

今回は2018年に自分で書いたこの記事から2年経った今、日本の会社ではなかなか珍しい日本とシンガポールの2拠点開発体制の状況について書いていきたいと思います!

teamspirit.hatenablog.com

開発体制について

この2年で開発チームの構成が大きく変わりました。

2018年 f:id:n-nino:20201210172422p:plain 2018年当時は、1つのプロダクトに対して内部で2つの開発チームに分かれていて、その内の一つが日本&SG混成チームという形でした。

2020年 f:id:n-nino:20201210172328p:plain こちらが2020年現在の体制になります。
2チーム体制だったのが、人数が増えたこともありモジュールごとに4つのチームに細分化され、日本とSGにそれぞれ2チームあるような体制になりました。
各チームにプロダクトマネージャー、エンジニア、QAがおり、それぞれスクラムで開発を進めています。 人数比も今では日本とSGでほぼ1:1になっています。また最近、チーム横断の課題を解決する分科会の取り組みも始めています。

TeamSpirit Singaporeについて

ここでもう少し、TeamSpirit Singaporeについてご紹介したいと思います。
2018年に自分が社員1号と入社してから、今では20人を超える世帯になってきています。 アジア各国出身のエンジニアやQAが働いています。

エンジニアが普段どんな感じで働いているのか書いてくれていたりするので、よかったら読んでみてください!(※英語だったり、コロナ前の話だったりしますが。) medium.com
あとは最近ありがたいことに、社員サーベイを元に、Great Place To Workという働きがいのある職場として認定してもらうことができました🎉 www.teamspirit.com
また、それを受けてTeamSpirit SingaporeのCulter Handbookというものを作成して公開しました🎉こちらもよかったら見てみてください!


このような感じで、今ではSG側もチームスピリットにはなくてはならない開発拠点になりました。


日本とSGの協働体制

次に、日本とSGでどのように開発を協働しているかお話していきたいと思います。

チーム内のコミュニケーション

前述した通り、2018年とは違い、各開発チームはそれぞれ同じ拠点のメンバーで組成されています。 そのため、混成チームでやっていた時と違いチーム内の言語は統一されたため(日本は日本語、SGは英語)、チーム内のコミュニケーションは効率化されたのかなと感じています。

拠点間のコミュニケーション

では、日本とSG間のコミュニケーションはどうやっているでしょうか。

コミュニケーションの方法

今はコロナの状況もあり、ほぼ全員が在宅勤務をしているため、コミュニケーションは基本オンラインで行われています。
そのため、これまであった物理的な距離の差が平等になり、拠点間のコミュニケーションのハードルが心理的にかなり下がったと感じています。

言語について

当然SGメンバーに日本語習得を強いるのは酷な話なので、全体共有が必要な話やSlack上でのやりとりは、2018年当時から日英併記もしくは英語ですることにしています。
当時は、そうはいっても、まだまだ日本語を使ってしまうことが多かったですが、最近は日本語だけでやり取りされることはほぼ見なくなりました。

個人的にはここがこの2年の大きな変化かなと感じているのですが、今はチーム横断のミーティングはほぼ英語で行われています。
もちろん、必要があれば英語な得意な人が通訳を助けることがありますが、各人が最大限英語でコミュニケーションすることを心がけています。

その結果、以前よりも日本とSGのメンバーが直接やり取りする機会が増え、一つのグローバル開発チームとして形を成してきていると感じています。


何でうまくいってるのか

実は特に何か特別なことはしていないと思っています。また、ここについては一朝一夕で解決できるような銀の弾丸もないと思っています。

SGメンバーの数が増え、次第に意識が変わった部分もあるでしょうし、必要に迫られて始めざるを得ない状況から徐々に慣れていったという部分もあると思います。
大前提として、日本とSG両者が一つのチームになることを目指して、お互い歩みよる努力をしたは間違いありません。
日本メンバーの英語の上達には目をみはるものがあります。

チームスピリットのQAチームがどうやって一つのグローバルチームになっていったのかを、今年のJaSSTで発表していて、ここに具体的なストーリーが登場しています。 teamspirit.hatenablog.com


グローバル開発チームとして次のステージへ

ここ2年の進歩は計り知れません。2拠点でここまでグローバルな開発ができているのは稀有だと思います。

とはいえ、まだまだ発展途上だと思っており、特に今があるのは個々人の努力に依るところも大きいです。 ですので、今後は今うまくいっている要因を分解して、仕組み化していかないといけません。
そのために、12月からグローバルオペレーションというチームを立ち上げました。
チームスピリットの開発チームがより一丸となっていけることを目指しています!

最後に

日本に居ながら、こんなグローバルな環境で働けるというのは貴重だと思います。 ご興味ある方は是非採用サイトもチェックしてみてください!一緒にグローバル開発チームを作りましょう! recruit.teamspirit.com


この記事はチームスピリット Advent Calendar 2020 10日目の記事になります。

アジャイル原則の振り返り

経緯

今年7月にTeamSpiritにジョインしたYINです。日本とシンガポールを跨ぐプロダクト開発組織の責任者をしています。 公式ブログにての初投稿になりますが、アジャイルの話題をテーマにしたいと思います。

実は自分は、入社の時からTeamSpiritのアジャイル開発の高い浸透具合に感心しています。

例えば社内全てのプロダクトに対して、全開発チームがスクラム手法をフルに活用している事にしています。 ディリースクラム、スプリント計画、レトロスペクティブ、スプリントレビュー、リファインメントなどのイベントがほぼ教科書通りに実施されていて、2005年からスクラムプロセスをずっと適用してきた人間としては、本当に嬉しいかぎりです。

なお、社内ツール系も、基本的にJIRAでEPIC/STORY/TASKの進捗を記録し、ConfluenceやFigmaやMiroなどのコラボレーションドツールでドキュメントを管理して、作業効率向上に大変貢献しています。

今回年末のアドベントカレンダーの記事参加との経緯もあって、せっかくなので今のスクラム活動の棚卸しをしてみたいと思います。

例えば、同じような事をずっとやっていると、ルーチンワーク化、マンネリ化してしまう事があるでしょうか? スクラムマスターはチームを守っているにも関わらず、スクラム原理主義者と呼ばれる事があるでしょうか?

この時に、一旦原点のアジャイル12原則に帰って、振り返るといいと思います。

続きを読む

B2B SaaSエンジニアMeetup - Sharing Issues Online #1 に登壇してきた!

2020年11月6日(金)に開催された B2B SaaSエンジニアMeetup - Sharing Issues Online #1 に参加・登壇してきました。 

smartcamp.connpass.com

今回の発表では、SaaS プロダクトでは重要となる管理画面について話しました。こちらから資料と動画を見ることができますので、よろしければご覧ください。

www2.slideshare.net

Q&A

登壇の最後にQ&Aの時間を取りましたが、その時間内で拾いきれなかった質問についても回答していこうと思います。

第1問

(質問)
やりたいことから辿れるようにすることはとても大切だと思うのですが、FAQやマニュアルの管理が大変そうです。どのように漏れがないようにしていますか?

(回答)
登壇時に回答済みですが、改めて。

管理は大変です。愚直に頑張っています。特に真新しいことはありませんが、まとめておきます。

FAQについては漏れなく作ることはいくら事前に考えても無理だと思っています(もちろん最善は尽くします)。そこで、フィードバックループを回すことで必要なコンテンツを揃えるようにしています。

愚直な取り組みに時間をかけられない、という方もいるかもしれません。しかし、FAQを作成することでお客様からの質問の際にFAQのコンテンツのリンクを添えて回答することで回答スピードや回答品質のアップにもつながるので、歯を食いしばって時間を取るようにしています。

第2問

(質問)
愛されると並行して、業務が回る機能を担保しないといけない思うのですが、そのバランスは開発工数の中でどう割り振ってますか?

(回答)
とてもいい質問ですね!

正直なところ、新機能開発に開発の比重が寄ってしまいます。

現時点ではフィードバックループはあまり回せていません。そのため、最初に作るときの完成度を高めるようにしています。完成度を高める方法としてはカスタマーサクセスチームとのレビューが役に立っています。日々お客様とやりとりしているメンバーからのフィードバックはお客様がどういった使い方をするか、どういった点で躓くか、気づきをもらっています。

今後の取り組みについても少しご紹介します。 大きな機能改善についてはプロダクトマネージャーが開発要件を取りまとめ、バックログに積んでいきますが、小さな機能改善の場合はなかなか拾いきれない課題があります。そこで、最近立ち上げたテクニカルサポートチームに愛される開発要件の取りまとめとその開発を組み込んでいこうとしています。

teamspirit.hatenablog.com

第3問

(質問)
項目のTipsに表示する文言を決めていく(関係者で合意を取る)のが、なかなか時間がかかるのですが、どのようにレビューを回すなどされてますか?

(回答)
はい、時間がかかります。

ニッチな機能の設定だとどう書いてもわかりにくくなってしまうので苦労しています。開発者だけだとどのように挙動が変わるかに注力した文言になってしまい、お客様に伝わらない文言になりがちです。3〜4年くらいまではQAエンジニアを中心に文言をレビューして見直していました。ここ最近はテクニカルサポートやカスタマーサクセスのメンバーの意見を聞いたりして決めています。

以下では、弊社内で回しているレビュープロセスについてご紹介します。

レビューとしては機能の複雑度に応じて設計レビュー、リリース前レビューの2回のタイミングがあります。 設計レビューは、ある程度機能や画面の設計が決まったタイミングでカスタマーサクセスチームのメンバーとレビューします。機能が複雑な場合は、画面にどういった、どれくらいの文言を表示するか意見交換しています。特に、バッチ処理を実行するような利用方法を画面に組み込むケースでは密にやりとりしています。

リリース前レビューは、機能開発がほぼ完了したベータ版をレビューしてもらいます。カスタマーサクセスチームへの引き渡しも兼ねており、このベータ版をもとにお客様向けのドキュメントの作成や更新が実施されていきます。カスタマーサクセスチームのメンバーは機能を動かしながら分かりにくい部分があればフィードバックしてくれます。Tipsの文言など細かなところはこのタイミングで見直すことが多いです。

まとめ

今回は、管理画面にフォーカスして発表してきました。

私は、管理画面の使いやすさはエンジニアリングしやすいところと考えています。

管理画面の使いやすさは、操作方法が統一されていること、利用方法が分かりやすいこと(調べやすいこと)、操作ミスしにくいこと、などノウハウを積み上げていくことで解決できるものが多く、ノウハウを開発ガイドラインとしてまとめて少しずつブラッシュアップしていく、というエンジニアリングがしやすいと考えるためです。

以上、管理画面の使いやすさを向上させる一助になれば幸いです。

最後に

少しだけ宣伝です。

今回の登壇には間に合いませんでしたが、採用サイトがリニューアルしました。 想いのつまった採用サイトになっています。

私たちのミッションである「すべての人を創造する人に」に共感してくれる人を絶賛募集中です。 全方位で求人しておりますので、どんな求人があるのか気になった方はぜひ眺めてみてもらえればと思います。

recruit.teamspirit.com

JaSST'20 Kansai テクノロジーセッションに登壇しました!

こんにちは!
夏があっという間に過ぎ去り、秋になったことになかなか気持ちがついていってないQAエンジニアの角です。

9/12(土)に JaSST'20 Kansai がオンラインで開催されました。
チームスピリットは同シンポジウムのスポンサーとして協賛させていただき、テクノロジーセッションでの発表時間をいただきました。
今回はそのイベントで発表させていただいた内容についてのブログを投稿します!

JaSSTとは

NPO法人ソフトウェアテスト技術振興協会(ASTER)が全国各地で開催しているソフトウェアテストシンポジウム(JaSST: Japan Symposium on Software Testing)のことです。毎年各地で開催され、テストや品質の関わる人達が多数参加する活気あふれるイベントです。

今年はCOVID-19の影響でJaSST'20 Tokyoが中止になり、他地域のJaSSTイベントもオンライン開催になっています。

チームスピリットは過去JaSST'19 Hokkaidoにて、弊社QAエンジニアの生井が「アジャイル開発 ✕ 品質保証」をテーマに事例発表をさせていただきました!

teamspirit.hatenablog.com


これまではオフラインだったので東京での参加が基本でしたが、オンライン開催となったこともありその他の地域のシンポジウム自体も積極的に参加させていただいています。
(実行委員のみなさん、いつも開催にむけてのご尽力ありがとうございます!!)

セッション内容について

私が発表させていただいたセッションのタイトルは
「Global QAチームを目指して 〜日本とシンガポールの2拠点QAチームを築く上での気づきと大切にしたこと〜」です。
今回、JaSST'20 Kansaiはオンライン開催ということもあり、講演内容を事前収録し提出するという形がとられました。


弊社のシンガポール開発拠点は2018年6月に立ち上がりました。最初はリファラルを中心としたFE/BEエンジニアの採用から始め、その後2019年初頭からQAエンジニアの採用活動を開始しました。その後いろいろな紆余曲折を経て、現在に至ります。(スライド参照)

QAエンジニアと一口に言っても仕事内容は会社によって違う(SET・テスター・テストマネージャ)ため、どういう人がこの会社には必要なのか、ということの関係者間の認識合わせはとても重要でした。さらに、シンガポール1人目=立ち上げということで、テクニカルスキルに加えコミュニケーションスキルやヒューマンスキルといったソフトスキルも必要だったので、実際採用活動をはじめてから内定に至るまでは約半年かかっています。
また1人目の採用後から2人目のSG-QAがジョインした現在も、拠点の壁や言語の壁など乗り越えないといけない課題も沢山ありますが、それ以上にたくさんの刺激を受け、知識をシェアしあい、日本以外のスタンダードを知ることができています。また、お互いにリスペクトしながら同じプロダクトに向き合い日々仕事をしています

開発拠点が海外にある会社はそれなりにあると思いますが、(オフショアでない)QAチームが日本と海外にある事例はほとんどないのではないでしょうか。実際、JaSSTでの講演時にTwitterで多くの反応をいただくことができました。驚きや称賛などたくさんのポジティブな反応をいただき、改めて発表してよかったなと感じました。聴いていただいた皆さん、本当にありがとうございました!

セッション準備の裏話

私自身、外部イベントでの登壇がそもそも初めてだったことに加え、講演内容を収録(しかもWFHのため自宅で&1人で!)ということで、準備にとても時間がかかりました...
スライドの作成にはマネージャやチームメンバーが力を貸してくれ推敲を重ねることができました。 そしていざ音声収録!となったとき、まず15分一発撮りだとミスが多発。。(そもそも原稿を準備していなかったので…)という話をQAチームの定例MTGでするとSG-QAメンバーが、パーツにわけてこのソフト使って編集したらいいよ、ということを教えてくれたのです。圧倒的感謝…!
そうこうしてなんとか完成し、一息つこうと思った矢先……提出直前にスライドの比率を間違えていたことに気づき、慌てふためいて編集に編集を重ね、なんとか提出物を完成させることができました。
みなさんも事前にスライド比率は念入りに確認しておきましょう…(汗)

QAエンジニア募集中!

私たちと一緒に日本とシンガポールの2拠点でQAエンジニアとして活躍してくれる人を大絶賛募集中です!
いま英語は話せなくても、使う気概と勉強する気持ちがあれば大丈夫!
お待ちしています〜♪

【こういうマインドだとチームスピリットのQAチームに合うかも…】

  • テスト活動だけに留まらず、プロダクト全体をみながら品質向上のための活動やプロセス改善の活動をしたい
  • シンガポールメンバーとも協力しあいながら働きたい

【スキルセット】

  • テストプロセス全体の経験(テスト設計〜完了、できればテスト計画作成も)
  • JSTQB Foundation Level資格保有
  • スクラムチームでのQA経験
  • 自動テストの作成経験(Autify・WebDriverIOなどのJavaScriptを使った自動テストツール)

f:id:naomi-s:20200915123450p:plain
QAチームMTGの様子!

チームスピリット流 スクラム勉強会!

初めまして。チームスピリットの内藤です。WSPの開発でフロントエンドエンジニアを務めてさせていただいております。

チームスピリットでは開発チームメンバーによるスクラム勉強を開催しております。今日はその勉強会の様子をお伝えしようと思います。

まず、なぜスクラム勉強会をしようと思ったか。それは。

アジャイルで働いているはずだけど、私達は自分達のスクラムに自信がない。ただのウォーターフォールの変形になっていないだろうか。

そんなチームメンバーの思いがあって開催が決定しました。僭越ながら私が主催を務めさせていただきました。

勉強会は毎週火曜日、朝の9時開始、10時終了。毎回「忘れてた」とか「今日は欠席」、「耳だけ参加」などありますが、必ずチームの半分以上が参加しております。朝早い時間でも集まれるのはリモートワークの良いところですね。共通理解を得るためにプロダクトオーナーにも参加してもらっております。

使用した本はこちらです。高額ですが、皆さんに本を用意してもらいました。 

「エッセンシャル スクラム」作者: Kenneth S.Rubin

エッセンシャル スクラム

エッセンシャル スクラム

 

全23章、400ページ近くある重厚な本です。これすべてを勉強会で行うと年単位で時間が掛かってしまいますので、勉強会では重要な個所だけ行うことにしました。重要な個所はアンケートで決めました。

第一回目の勉強会では全員に勉強会に参加した目的を書いてもらいました。勉強会が終わった後で、学べたこと、学べなかったことをふりかえり、後の個人学習に役立ててもらおうという思いがありました。

さて、勉強会。

最初にファシリテーターがどこまで読むかを決めます。第〇章の△から第〇章の△までと決めます。「始めてください」の合図で皆が一斉に読み始めます。

読み終わったらハングアウトのチャットに合図をします。○、1、🙆‍♂️、👍など個性があって面白いです。私が先に読み終わった時はドキドキワクワクしながら皆さんの合図を待っています。

f:id:naito-kaoru:20200825110306p:plain

読み終わった後での意見交換


1回で読む内容は5~10分ぐらいでキリよく読める量にします。皆さんそれぞれ読む速度が違うので、量が多いと読み終わりにばらつきがでます。すると3分、5分という時間を待っていただく必要があります。量を調整するのはとても難しいです。慣れてくると自然と「ここまでかな」というのが見えてきます。

待ち時間ができてしまった場合は議事録に重要箇所、疑問点、今のチームでの問題点などを先にまとめてもらっています。

勉強会は食べ物、飲み物の持ち込みが自由ですので、お菓子や朝食を食べながら待つのも良いかもしれません。

全員が読み終わった後はまとめをします。

(以下、まとめ一部)

f:id:naito-kaoru:20200826103933p:plain

書籍に対しての疑問

 

f:id:naito-kaoru:20200826104218p:plain

チームの問題点指摘と解決策の提示

 

 

f:id:naito-kaoru:20200826104534p:plain

PO(原さん)を交えた前向きな議論

 

f:id:naito-kaoru:20200827102043p:plain

チームの問題点と照らし合わせてアクションを決めた

 まとめが終わっても時間がある時は、またファシリテーターがどこまで読むかを決めるところから始めます。1時間あれば2~3回ぐらい循環できます。

勉強会の面白いところは全員が生徒であり、教師であるところです。「分からない」と声を出してみると他の人も疑問に思っていたり、言われて「たしかに理解できてない」と気づいたり、もしくは「こうだと思った」と解釈を教えてくれたり。一人では挫折しそうな文章も他人の共感や意見を得られることで前向きに取り組むことができます。

また参加者はチームメンバーですので、このようなやり取りがチームのコミュニケーション能力向上に繋がっています。

勉強会の後でも交流が続くことがあります。

f:id:naito-kaoru:20200813103419p:plain

「精度と正確性の違いとは?」

この日の勉強会は「精度と正確性は何が違うのか?」が熱く議論されました。

以上、チームスピリットメンバーによるスクラム勉強会の様子でした。

さて、私事ではありますが、先日、スクラムマスター認定資格を取りました。その上で勉強会をすれば、また違った目線で見えてくることでしょう。今後の勉強会がとても楽しみです。

Salesforceの認定アドミニストレータ試験をオンラインで受験してみました

こんにちは!開発チームの里石です。
先日7月に、Salesforceの「認定アドミニストレータ試験」をオンラインで受験しました。
物理会場に赴いての受験とは色々異なるポイントがあったため、受験記のようなものをシェアしてみたいと思います。

受験申込

受験の申し込みは、通常の受験時と同様にWebassessorから行います。
試験一覧の中で、「オンライン専用」となっているものが対象です。
オンライン試験にも関わらず、開催日程が月に1回しかないので、スケジュールに注意してください。

申し込み前に、受験案内PDFがダウンロードできるので、よく読んでおきましょう。
オンライン試験の説明は、ほぼこれぐらいしかありません。

受験前の準備

申し込み後、Webassessorのサイトで試験用ソフトである「Sentinel」をダウンロードし、インストールします。
受験時間前であればいつでも良いのですが、事前登録や動作確認のため、早めにインストールしておきましょう。
インストール後起動すると、まず自分のBiometric(顔情報)登録画面が表示されます。
試験はこのソフトで行うのですが、試験中はwebカメラを介して顔認証され続けることになります。そのため試験の前に顔情報の登録が必要です。

f:id:satoishi_ts:20200817141302p:plain
顔情報登録画面

眼鏡を外すよう注意事項が書かれていますが、外さなくても問題なさそうです。
私のときは、眼鏡外そうとした瞬間に登録完了になってしまい焦りました。
一度登録実行してしまうと、その後再登録はできないので、顔がはっきり映るよう照明に注意して登録してください。また、登録後の映りは確認できません。
(「登録実行」前にwebカメラが写している映像が見れるので、そこで確認しましょう。)

顔情報登録が終わると事前準備はOKです。

Sentinelはいったんアンインストールし、あとで再インストールしてもOKです。(その際の顔認証の再登録は不要です)

なおSentinelを立ち上げると、一部の外付け機器が無効になるようです。
私の場合ですと、USB Type-C接続の外部モニタが使えませんでした。また、USB Type-Cハブ経由のモニタも同様に無効化されて利用できませんでした。
すべての外部機器が無効になるのかどうかわかりませんが、ノートPCだとキーボードの故障などで、外付け機器が必須の状態になってしまっていることもあると思います。
受験前に、一度Sentinelを起動して確認しておき、使用しているPCでの受験が無理そうであれば、受験をキャンセルした方が良いかもしれません。

またSentinel起動中は、デスクトップに戻ることもできないため、各種通知やPCバッテリー残量も確認することができません。

試験中

試験開始時間の5分前にSentinelを立ち上げます。
webカメラが起動するので、なるべく登録したときと同じような照明で顔が映るようにします。

f:id:satoishi_ts:20200817141756p:plain
試験開始画面

試験中は常時顔認証し続ける必要があるようで、例えば正面を向いていなかったり、顔が隠れたり、画面から外れると、画面が切り替わって問題が見えなくなります。
そのため登録時と異なる環境下で受験すると、認証に失敗しやすくなり、試験に支障が出るかもしれません。
webカメラから顔が外れないよう注意しながら、問題を解いていきましょう。
受験後、回答を送信すると即座に結果が表示されます。

あと、これは大事なポイントなのですが、ノートPCを利用する場合は試験前にAC電源をつないでおきましょう。
SentinelはなぜかCPU使用率が非常に高く、起動中はファンがフル回転しバッテリーがどんどん減っていきます。
私はAC電源をつなぐのを忘れて試験開始してしまい、途中でファンのフル回転に気付いたものの、顔をwebカメラから外せないためAC電源をつなぐこともできず、刻一刻とバッテリーが減りゆく中、メチャクチャ焦りながら試験を終えました。
回答送信後、Sentinelを終了してバッテリー残量を確認すると、あと10分しか残っておらず危なかったです。(試験時間90分のうち70分ぐらいで回答を送信したので、最後まで時間かけていたら送信できずに終わっていました…)

自宅で受験しているとは思えない危機的状況に陥ったものの、結果なんとか無事合格することができました。
火事場の馬鹿力ですね。たぶんAC電源つないでいたら不合格になっていたと思います。

出題傾向

私は2回目の受験で合格したのですが、物理会場かオンラインかに関わらず、「認定アドミニストレータ試験」の出題傾向は次のようなものでした。(試験用ソフトのSentinelは物理会場の端末にインストールされているのと同じものです)

  • 標準アプリと標準オブジェクトについての出題が4割を占めます
    標準アプリの標準オブジェクトは、カスタムオブジェクトと同じものに見えますが、使っている言葉が異なります。例えば、ただの選択リストをセールスプロセスやリードプロセスと呼んでいたりします。
    このため、開発者向けTrailheadで覚えたことと出題内容がつながらないので、開発者であっても、実際にSalesCloudを使ってみて感覚を掴んでおくことが重要です。
  • ほとんどの問題は、シチュエーションに対して適切な対応はどれか?といった出題内容です。そのため、「これはあの機能のことを出題されているな」と気付けるかどうかが肝です。
  • 「〇〇の設定で選択できるのはどれですか?」といった暗記すればよいものも、1~2問程度はでます。

最後に

Salesforceに携わるようになったのは、チームスピリットに入社してからにもかかわらず、無事1年ほどで合格することができました。
過去に受験してきた先輩方の勉強資料で、実のある勉強ができたおかげだと思っています。
ありがとうございました。

「認定アドミニストレータ」はまだまだTrailhead(登山口)なので、次は「認定Platformデベロッパー」を目指していきます。