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

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

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デベロッパー」を目指していきます。

180度変わった業務環境で開始した業務の話

こんにちは! 4月に入社したQAエンジニアの仲です。
リモートワークで悪戦苦闘しながらも業務に慣れてきましたので、エントリーブログを書かせてもらいます。
本記事では入社以降指で数えられる回数(2回)しか物理出社を行わずリモートで業務を行い感じたこと、自動テストを触ったことない人間が初めて自動テストに着手した話を書きます。

入社後すぐに始まったリモートワーク

前職でもQAやテストエンジニアを行っており、大量の機材で評価を行わなければならず、リモートは無縁の人生だと思っていたのですが、COVID-19の影響により入社日とその週末の二回しか物理出社を行わず、すべての業務をリモートで行っています。

リモートの利点
  • 通勤時間などの移動時間がない
  • 業務環境を自由に変えられる
  • 作業に集中できる

長期間のリモートでの業務の利点として感じたことはやはり自分に使える時間が増え、かつ自分のペースで業務が行えることでした。
業務環境の作成に時間はかかりましたが現在は立ち/座りを切り替えながら業務を行っています。
高低差を切り替えられるスタンディングデスクは有能です。

リモートの欠点
  • 社内のメンバーの細かな輪郭がわからない
  • 体内時計の変化
  • 業務環境に変動がありすぎる(部屋が寒かったり暑かったり)

長期間のリモートでの業務の欠点として感じたことしては、1からの人間関係の構築がすごく難しいことです。
いくらビデオ通話などで顔を合わせて会話をしていても表情や声のみでは深く知ることがとても難しく感じています。
また自宅で汗まみれになりながら業務を行っていると会社の空調がいかに素晴らしいか思ったり。

初めてのテスト自動化について

私のチームでは統合時に不具合が発生していないことをAutify(https://autify.com/ja )を用いて自動テストを行い確認しています。
私は前職でも品質に携わる業務を行っていたのですが、自動テストに携わることは一度もなく、初めての取り組みとなりました。
自動テストのイメージとして以下のようなイメージを持っていました

  • 自動テストの作成ができるようになるまでに工数が異常にかかってしまう
  • コーディングスキルがなければ作成が難しい
  • 上記の理由から自動化を導入するハードルが高い

そのため自動化については興味を持っていたのですが、いざ自動テストの作成を依頼されたときは結果が出せるのか心配でした。
実際にAutifyを触り始めて3か月ほどたちますが、私が懸念していた問題を感じることなく運用が行うことができ、現在はテストシナリオの作成・運用を行っています。
3か月という短い時間で運用できているのはAutifyではページ上で操作を行うだけでテストシナリオを作成できるため、作成が容易であるからではないのかと感じています。
作成したテストシナリオにおいて何をやっているのかがわかりやすかったことも挙げられます。

f:id:te_naka:20200818123712p:plain
Autify_Testscenario
またテストシナリオ実行中にJavaScriptを組み込むことができるため、Autify本来の機能 + αで的確なテストシナリオを作成することができます。
現在はJavaScriptの勉強を行っており、わずかですがテストシナリオの中に組み込んでおります。
チームスピリットでは今後も自動テストに力を入れるためにQAチーム全体でJavaScriptの勉強を始めております。

Autifyについてはそのほかにも記事があります

teamspirit.hatenablog.com

teamspirit.hatenablog.com

teamspirit.hatenablog.com

まとめ

リモートでの業務や初めての自動化の着手などには慣れてきましたが、会社の一員になれているのかと考えてしまうことがあります。
しかし現状の環境を変えることは難しいので某漫画風に言うならば配られたカードで現状をプラスの方向に受け入れて行こうと思っております。
…とはいえどこかへ遠出とはかけ離れた生活となってしまっていますので、外出をしたいですね。

テクニカルサポートチーム始動!

自己紹介

こんにちは!
2020年4月にTeamSpiritにジョインした手島です。
ジョインと同時にテクニカルサポートチームが新設され責任者をしています。
責任者といってもチームメンバーは私一人ですが・・・

テクニカルサポートチームが新設された経緯

弊社製品のTeamSpiritはお陰様で20万契約ライセンスを突破。
多くのお客様に利用されているが故に製品に対する問い合わせも一定数は発生しています。
お客様からの問い合わせに関してはカスタマーサクセスチームが対応しますが、技術的な調査に関しては 開発チームへエスカレーションされます。
開発チームではエスカレーションがきたら最優先で対応していますが、
一方で追加機能を予定通りリリースしないといけないので保守と開発の板挟みとなり厳しい状況になっていました。
そこで「エスカレーション対応の専属部門を作ろう」となり、私のジョインと共にテクニカルサポートチームが新設されました。

テクニカルサポートチームって?

カスタマーサクセスチームで対応が難しい専門的な問い合わせを解決します。
現状の問題点を確認し、お客様の設定状況・データ更新日時・データの整合性などから総合的に判断し、問題点を解決します。
バグを発見する事もあり、バグの場合は改修を開発チームに依頼しながらお客様の業務が止まらないようにデータ修正を行ったりもします。

今後のテクニカルサポートチームは

まずはエスカレーションの迅速かつ適切な対応を改善する必要があります。
 ・エスカレーションフローの改善
 ・過去類似案件の効率的な検索ツール構築
 ・エスカレーションの全社への見える化
また、治療だけでなく予防も大切なので
 ・エスカレーション分析からの機能改善
 ・すぐに機能改善が難しい場合はFAQ、マニュアル改善
 ・追加機能のリリース前レビュー体制の強化

最後に

全てが一人では実現が難しい案件ばかりです。
開発チームやカスタマーサクセスチームとのコミニケーションも大切になってきます。
やらないといけない事は盛り沢山!
一緒にテクニカルサポートチームを盛り上げてくれるメンバーを募集しております。

f:id:kenji_teshima:20200813190401p:plain
最近作ったJIRAダッシュボード

TeamSpirit Singapore 出張記 #1

2018年10月に1週間、TeamSpirit Singaporeへエンジニア1名とプロダクトマネージャ1名で出張してきました。 f:id:niseissa:20181026165751j:plain

TeamSpirit Singapore

チームスピリット、初の海外拠点をシンガポールに設立|ニュースリリース|お知らせ|勤怠管理・工数管理・経費精算ならチームスピリットの発表にありますようにシンガポール拠点を2017年に立ち上げ、2018年から開発チームも立ち上げました。 弊社では本社のエンジニアとシンガポールのエンジニアの混成チームで一緒に開発をしています。毎朝のデイリーミーティング、スプリントごとのふり返りなどで、基本的なコミュニケーションはとれているものの、対面でのコミュニケーションに勝るものはありません。今回は新しい取り組みを含んだストーリーがあったためDevリーダーの湊と一緒に2名で訪問してきました。

TeamSpirit Singapore Office

2018年9月1日から、WeWorkを拠点として利用しています。

www.wework.com

f:id:niseissa:20181031115611j:plain 吹き抜けのある開放的な場所でソファで仕事したり、食事をとったりすることができます

f:id:niseissa:20181031121759j:plain お酒の高いシンガポールでもWeWork名物の無限ビールは健在です

Work Together in Singapore

WeWork内は、大小さまざまな打ち合わせスペースがあり(2-3人用から30人程度まで)そこで新しい取り組みや今後のロードマップについて共有をしました。

f:id:niseissa:20181031122504j:plain 新しい取り組みやアーキテクチャについてエンジニアから英語、日本語、身振り手振り入り混じっての説明がありました。

今回出張した彼は現在シンガポールに移籍して、現地のメンバーと一緒に開発をしてもらっています。 シンガポールチームと一緒にプロダクト開発を続けていたお陰で今回のコロナ禍におけるリモート開発は非常にスムーズに移行することができました。 ダイバーシティを高め、さまざまな文化を取り込んで仕事をするということが役に立つことを実感したできごとでもありました。

「変化を抱擁せよ」です。