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

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

プロダクトマネージャーチュートリアル~FigmaでToDoリストを作ってみよう~

今年シンガポールから帰国したけど、引き続き日本のチームスピリットでプロダクトマネージャーとしてお世話になっている二宮です。

私にとって今年は、PMとしてFigmaをよく触った年になりました。
そこで今回は、その培ったFigma力をチュートリアルとして還元していきたいと思います。

プロダクトマネージャーがどのようにして、プロダクトや機能を構想していくかも合わせてご紹介していきます!

お題

お題はエンジニアの方だったら一度はやったことのある、定番のToDoリストにしたいと思います。(こんなの)

下記のような行程で進めていきたいと思います。

  1. 要件定義
  2. ワイヤーフレーム作成
  3. UI設計 (Figma)
  4. プロトタイプ作成 (Figma)

それでは、作っていく!

要件定義

普通はユーザーの課題から機能を考えてくのが正しいのですが、今回はある程度作るものありきなので、形式的にやっていきます。

普段自分は下記の項目を整理して書くことが多いです。なので、今回もそれに則ります。

  • 想定ユーザー
  • ユーザーの抱える課題
  • 課題を解決する機能

想定ユーザー
日々色々なタスクをこなしている人

ユーザーの抱える課題
自分が今どんなToDoを抱えているか、またそれらの期日、ステータスを管理できていない

課題を解決する機能
必要そうな機能を書き出していきます。

  • ToDoリスト
    • ユーザーがやるべきToDoを管理できる
      • ToDoが登録、編集、削除できる
      • ToDoが一覧として確認できる
    • ToDoのステータスが管理できる
      • ToDoのステータスを完了にできる
      • 完了したToDoはリストから消える

今回はこの辺で止めておきます。 本来は、考えられるだけ書き出して、取捨選択、優先順位づけ、リリースの単位を整理していくのがいいでしょう。ユーザーストーリーマッピングなどのフレームワークを使うと整理しやすいです。

ワイヤーフレーム作成

書き出した機能を元に、画面の構成を考えてきます。 紙に描く、作図ツール、パワポなんでもいいです。ここからFigmaを使っても問題ないです。

今回はiPadで手で描きます。

自分でも驚くほど字が綺麗ですが、大体こんな感じです。

UI設計

ここからが今回の本題、Figmaの出番です。
まずはUIを作っていくフレームを作成します。
今回はモバイルアプリという想定で作っていきます。

フレーム配置

Frameを配置して、iPhone13の画面サイズに設定します。

コンポーネンの作成

今回はチュートリアルなので、各部をちゃんとコンポーネントとして作っていきます。
メインのUIを作るページとは別のページに、コンポーネント群を整備していきます。

タイトル用のText Style
手始めに、画面上部に配置するタイトル部分を作っていきます。
FigmaのText Stylesを使えば、いわゆるhタグに相当する様なテキストのスタイルを保存して、使い回すことができます。

次に必要なコンポーネントを作っていきます。
コンポーネントも作成しておけば、使い回すことができます。

入力コンポーネント
それっぽい見た目になる様に、オブジェクトと文字を配置して、それらをまとめて選択して画面上部のダイヤのボタンでコンポーネント化することができます。 幅が変わった時にも、意図した通りに拡大/縮小するか確認しておくと良いでしょう。
同様に日付の入力コンポーネントも作りました。

ボタンコンポーネント
基本的な作り方は、上記と同様です。
加えて、ボタンコンポーネントにはVariantを設定してみましょう。
Variantによって、コンポーネントの状態(Selected, Disabledなど)を表現することができます。
作成したコンポーネントを選択してVariantを設定すると、コンポーネントが自動で複製されます。

今回はボタンのDisabledを設定したいので、DisabledというPropertyを設定して、FalseとTrueのUIを作成します。

実際にコンポーネントを置いてみると、こんな感じで簡単に状態を切り替えられるようになりました。

チェックボックスコンポーネント
ボタンと同様に、チェックがついていない状態、ついている状態を作成しました。

リストコンポーネント
リストをコンポーネント化するときは、リストのヘッダーや行だけコンポーネント化しておきます。リスト行は選択状態のVariantを設定しました。

これでコンポーネントが揃いました!!

画面の作成

最初に作ったフレームに、作成したコンポーエントを配置して画面を作成していきます。

タイトル
好きなタイトルをテキストで配置し、作成しておいたText Styleを設定します。

フォーム部分
作成したコンポーネントはAssetsタブから呼び出して、使うことができます。 ボタンと入力項目を配置してこんな感じにしました。

リスト部分
リスト用のフレームをおいて、その上に作成したヘッダーと行のコンポーネントを配置していきます。

配置した後は、プレビューしながら全体のバランスを整えて完成です!

これだけでも十分なのですが、今回はこれをデモっぽく動くようにしていきます。

プロトタイプ作成

FigmaにはPrototypeという機能があります。 いわゆる"紙芝居"(デモ)を作る機能で、作成したUIを動いているかのように見せることができます。 より正確に画面の動作や遷移を伝えることができます。

シナリオ
それでは、まずどのようなデモにするかシナリオを考えます。 Figmaのプロトタイプの機能ではあくまで、あらかじめ設定しておいたフローでしか動かせないので、複数機能がある場合は複数フローを作成してもいいでしょう。

1. タスクの新規登録
 初期画面 → タスク入力 → 保存してリストに追加 → タスクが一覧で見れる
2. タスクのステータス更新
 タスク一覧 → タスク選択 → Doneに変更 → 一覧から消える
3. タスクの削除
 タスク一覧 → タスク選択 → 削除 → 一覧から消える
4. タスクの更新
 タスク一覧 → タスク選択 → 更新 → 一覧に反映

今回はこれらをデモに入れていきます。
最初に"紙芝居"と表現したように、一つの画面を動作させるのではなく、各状態の画面を用意しておいてクリックで遷移させていくような作り方をします。(作りながら機能の微調整もしていきます。)

実装
「初期画面 → タスク入力」 にあたる2画面を作りました。

これを繋げて動いている様に見せます。

入力欄をクリックすると入力したかの様に動く様に、入力欄から繋げていきます。

実際にプレビューするとこんな感じ。

同じようにして、ガシガシ作ってきます。 今回は書き出したすべてのシナリオを一つのフローに入れることができました。

そして、最終的に完成したデモがこちら
ToDoリストのアプリの機能が、実際に動いている形で見えるのではないでしょうか。

さいごに

Figmaのプロトタイプ機能は、プロダクトのアイデアを最短で動く形にできる非常に強力なツールです。このチュートリアルを真似して、あなたもプロダクトマネージャーとしてデビューしてみてはいかかでしょうか!

この投稿はチームスピリット Advent Calendar 2021 第9日目の投稿となります。

adventar.org

学び方を学びなおす

こんにちは、TeamSpirit QAエンジニアの岡内です。
2021年6月1日に入社し、半年が過ぎました。

はじめに

前職でもソフトウェアテストやQAに従事していました。
しかしながら、上手くいかないこともありました。
タイトルにあるように、「学び方を学びなおす」必要があったので、これについて書きます。

弊社のアドベントカレンダーの12月8日に掲載いたします。
adventar.org

新機能開発チームから品質改善チームへの異動

入社してから先日まで、私はTSFチームのうち新機能開発チームに参画していました。
開発チームの体制については、下記をご覧いただければ幸いです。
teamspirit.hatenablog.com チームメンバーの支えのおかげで、業務に支障を来すことなく日々を送っていました。
そして、11月になってから品質改善チームに参画することになったのです。

「早く製品全体の知識を身に着けたい」と思っていた私にとって、新機能開発チームだけでなく、品質改善チームでの経験を積むことはチャンスです。
しかし、早々に躓くことになりました。

「これまでの自分のやり方」では通じなくなる瞬間がきた

品質改善チームに参画し、途端に右も左も分からなくなりました。
「チームが違うといえど同じ製品なのに、そんなに違うものなのか?」と感じる方もいらっしゃるかと思います。
チーム異動前の私が、まさにそう感じていました。
今まさに、「これまでの自分のやり方」では通じなくなったのです。

では、私にとって 新機能開発チームと品質改善チームの大きな違いは何なのでしょう?
最も大きな違いは、対象としている機能を理解するための業務知識です。
新機能開発チームでは経費精算機能やシフト管理機能を担当しています。
私は前職までで金融系のプロジェクトに参画していたことがあり、そのときの学び方を無意識に行っていたようです。
一方で、品質改善チームでは勤怠管理・勤怠計算を担当しています。
これまで勤怠に関わるプロジェクトに参画したことがなく、勤怠についての学び方で右往左往しているのです。

学び方を学びなおす

しかしながら、この右往左往している状況は、自身にとってはチャンスに出来る可能性があります。
これから先、いくらでも今まで学んでこなかった領域の学習をする必要が出てくるからです。

私の場合は、2つの原因がありました。
 1. 勤怠管理の全体像が見えない
 2. 1つ1つの用語の意味が分からない
1つ目については、弊社の場合は下記に挙げるような資料があります。
私はこちらを読みながら、勤怠管理の全体像を理解している最中です。

www.teamspirit.com

www.teamspirit.co.jp

2つ目については、諸先輩方の協力を仰ぎ、学習している最中です。

おわりに

今回は、チーム異動をきっかけに学び方を学びなおす機会に恵まれました。
果たしてこの学び方の学びなおしはうまくいくのでしょうか?
折を見てご報告できればと思います。

Entrance Book for engineer (2024年4月更新)

チームスピリット

はじめに

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

弊社は働き方改革プラットフォーム「TeamSpirit」というSaaSプロダクトを開発・運用しています。 2016年からエンジニアの採用活動をスタートし、2021年12月時点で弊社の開発組織は約60名、2024年2月時点では73名の規模になりました。

「Entrance Book for engineer」では、チームスピリット / TeamSpirit に興味をお持ちいただいた方に、私たちのことをより知っていただくために「入り口」となる公開情報を集めています!

こんな方に読んでいただけるとうれしいです。

  • チームスピリットのエンジニアになってみたい方
  • チームスピリットの開発組織に興味のある方
続きを読む

リリースのリードタイムの70%削減に挑戦する話

みなさん、こんにちは。
TeamSpirit EXのエンジニアリング・ マネージャをしている杉山です。
普段はマネージメント業務もしつつ、BEエンジニアとして勤怠機能の開発もしています。

こちらは チームスピリット Advent Calendar 2021 - Adventar の6日目の記事です。
今日は、リリースのリードタイムの70%削減に挑戦する話をします。

TeamSpirit EXのリリース

TeamSpirit EXは1年間に4回のメジャーリリースをしています。
マイナーリリースを含めると1年間に30回以上、月に2~3回のペースでリリースしていることになります。

LeanとDevOpsの科学 などで紹介されている、デプロイ頻度やデリバリーのリードタイムと照らし合わせると、私達はミディアムパフォーマーという括りに入るでしょうか。

※ こちらのDevOpsチェックでも診断できます www.devops-research.com

リリースプロセス

TeamSpirit EXは AppExchange に公開してるアプリケーションですが リリースするために、パッケージ作成と呼ばれる作業をSalesforce上で行います。
下図はマイナーリリース作業を表したものです。

ご覧のように、パッケージの作成に多く時間がかかっています。
パッケージの作成時間に幅がありますが、作成に失敗することがあり、その場合は再作成が必要になるためです。

これだけ時間がかかると、緊急リリース時など修正は1日で終るのに、リリースできるのは3~4日後という事態になってしまいます。

ボトルネックはどこか

パッケージの作成時にはすべてのテストクラスが実行されます。
TeamSprit EXには5000弱のテストケースがあり、それらがパッケージ作成時に実行されますが、 ここに4時間弱 かかってしまいます。
この問題を解決する方法を考えていきましょう。

解決策1. テストを並列実行する

Salesforceではテストクラスのアノテーションにプロパティを指定することでテストを並列実行できます。 しかし、この方法だけでは問題を解決できません。
なぜなら、多くのテストがDBアクセスしているため、並列実行するとレコードのロックエラーが発生するためです。

解決策2. Mockを利用して、DBアクセスするテストを減らす

DBアクセスするテストが多いのであれば、テストを修正しましょう。
ApexのMockを利用すればDBアクセスを減らすことができ、実行時間の短縮も見込めます。
しかし、、この方法でも問題は解決できません。
なぜなら、、修正対象があまりにも多すぎて時間がかかってしまうためです。
(本当は少しずつでも対応するのが望ましいですが)

では、どうするか・・

開発用とパッケージ作成用のテストクラスをわける

パッケージ作成に必須ではないテストをパッケージから除外しましょう。
私達のチームでは、CIで定期的に全てのテストを実行しているため、パッケージ作成のタイミングに必要になるテストは極めて少ないです。
名前空間にまつわる不具合はパッケージ作成のテスト時に発見されることもありますが、これもCIのテスト組織で名前空間を利用すれば早期に発見が可能です。

パッケージを作成するためには最低限75%のカバレッジが必要ですが、そのテストだけであれば大幅に実行時間の短縮を見込めます。

さいごに

まだ発案段階ではありますが、プロダクト開発に注力できる環境を作ることがお客様にの価値につながると信じて、粘り強く挑戦していきたい次第です。

チームスピリットでは一緒にはたらく仲間を探しています。
興味を持ってくれた方は是非お声がけをお願いします!!

recruit.teamspirit.com

recruit.teamspirit.com

リスクベースド・アプローチを導入して、JaSST nanoで発表しました

こんにちは。TeamSpirit QAエンジニアの中西です。

私たちのチームでは2021年1月からリスクベースド・アプローチ※を採用したテストを始めました。当記事では、その取組み内容をJaSST nanoというイベントで発表してきましたので、その報告とともに苦労したポイントについてお伝えします。
※ リスクを特定し、リスクに応じて対応する方法

はじめに

取組みの経緯を説明する前に、当社のプロダクト開発手法と開発チームにおける
QAエンジニアの役割を説明します。
プロダクト開発体制についての詳細は下記ブログを参照ください。 teamspirit.hatenablog.com

プロダクト開発手法

私たちのプロダクト開発では、スクラムを採用しています。 1スプリント2週間の開発サイクルを8回程度繰り返して、プロダクトをリリース※しています。
私たちの開発チームはスプリント最終日のスプリントレビューでデモできるように、小さな単位で機能開発しています。
また、スプリントレビューでデモを実施した結果、クリティカルな指摘がある場合、次のスプリントの開発に組み込みます。
※ エンドユーザ向けにリリースするのは年3回(3月、7月、11月)です。

QAエンジニアの役割

TeamSpirit family製品開発チームにおけるQAエンジニアの役割は以下の通りです。

  1. プロダクト品質目標の作成・更新
  2. テスト戦略・テストアーキテクチャの策定・運用
  3. リリースサイクルごとにテスト計画、品質評価レポートを作成
  4. 詳細設計のレビュー
  5. 開発が完了したユーザストーリー、不具合のテスト設計/テスト実施
  6. 開発期間中に発生した不具合の分析、分析結果を開発チームにフィードバック
  7. リグレッションテストケースの整備
  8. 非機能要件のテスト計画~テスト実施のリード
  9. 継続的なテストプロセスの改善
  10. テスト自動化の推進
  11. テストナレッジの共有
  12. 採用支援

リスクベースド・アプローチを導入するまで8~11に記載していることが
十分に実施できていませんでした。

リスクベースド・アプローチの導入

従来はQAエンジニアが全てのリリース対象に対して、機能テストを行っていました。
さらに、開発者テストとQAエンジニアのテスト内容が重複している場合もあり、
テストに必要なコスト・時間が多い状況でした。
そのため、QAエンジニアのテストがボトルネックとなり、
リリースできない機能改修が発生していました。

このような問題に対応すべく、リスクベースド・アプローチを用いて、
機能テストにおけるQAエンジニアの関わり方を整理しました。
どのように整理したかはJaSST nanoで発表した資料を見ていただければと思います。

speakerdeck.com

苦労した点

次にリスクベースド・アプローチ導入時に苦労した点を共有します。
(JaSST nanoでは説明していない内容になります。)

苦労した点は不具合が混入するリスクが低い機能改修に対して、
QAエンジニアがどのようなテストをするか決めることでした。

テスト手法を検討するにあたり、不具合混入リスクが低い機能改修で混入した
不具合の発生傾向を分析しました。

その結果、ラベル名の変更、エラーメッセージ、エラー発生条件の変更のような
機能改修では、クリティカルな不具合が頻繁に発生していないことが分かりました。

分析結果をふまえて、不具合が混入するリスクが低い機能改修に対して、 下記2点を行うことに決めました。

  • QAエンジニアは開発エンジニアが作成したテストケースをレビューする。
  • QAエンジニアは1~3時間のタイムボックスでアドホックテストを実施する。

今後について

リスクベースド・アプローチ導入後、モブテストを通じて、 テスト実施の勘所を開発エンジニアに少しずつ伝えているところです。
また、定期的にJSTQB Foundationレベルのテストの目的やテスト設計技法を伝えて、 開発エンジニアもQAエンジニアと同等のテストができるように支援していくことを考えているところです。

JaSST nanoでの発表

リスクベースド・アプローチの取り組みが定着した頃、
JaSST nanoでの発表を決めました。

JaSST nanoについて

JaSST nanoはテストやQA、品質に関連するテーマで誰でも、
気軽に社外に対して、発信できる場です。

1ヶ月に1度、19:00から1~2時間、オンラインで開催します。現時点では第3火曜日です。テーマはソフトウェアのテストやQA、品質に関することなら何でも構いません。レベルとか質とか関係ありません。話したい人が話したいだけ話す、という趣旨です。 JaSSTnano - PukiWiki から引用

JaSST nano参加のきっかけ

2021年の個人目標として、以下の2点を挙げていました。

  • リスクベースド・アプローチを開発プロセスに組込み後、その成果を社外に発信する
  • 社外のテストエンジニア・QAエンジニアの方との接点を持つ

特に「社外のテストエンジニア・QAエンジニアの方との接点を持つ」ことに関しては、
並々ならぬ意欲をもっていました。

そんな中、JaSST nanoのイベントを定期開催するというtwitterを見て、
2021年度中に発表するということを決意しました。

JaSST nanoに参加してみて

運営の方によるイベントの雰囲気づくりにより、
発表者にとって非常に発表しやすい雰囲気でした。
「テスト、品質に関わることならなんでも」という主旨のため、
発表内容もバリエーションが豊富で、 テストの目的をカジュアルに分かりやすく例える発表もありました。

家事・育児に学ぶテストと品質管理の心構え - Speaker Deck speakerdeck.com

他社の取り組みや発表者が持っているテストや品質の考え方を
気軽にインプットすることができる場でした。

また、社外の方と接点を持つきっかけとなるイベントでした。
自社の取り組みではなく、ソフトウェアテスト、品質に対して、
自分の考えをアウトプットする場として、また参加しようと思っています。
積極的にアウトプットして、ソフトウェアテストを盛り上げていけるように頑張ります。

最後に

このようなQAエンジニアが所属しているチームです。
一緒に働きたいというエンジニアの方を絶賛募集中です。
よろしくお願いします。

recruit.teamspirit.com

recruit.teamspirit.com

Autify LTに参加してきました

こんにちは!チームスピリットのQAエンジニアの仲です。

以前ブログを書いてから一年ほどたちました。この一年も新しいことを始めたりと濃密な一年を過ごしておりました。
今回はTeamSpiritがAutify LTに登壇しましたのでそちらの振り返りを兼ねて記事を書きます。

Autify LTって?

そもそもAutify LTとは何?という方もいると思いますのでAutify LTについて軽く説明しておきます。
Autify LTとはAutify(ソフトウェアテスト自動化プラットフォーム)ユーザーが集まりお題に沿ってプレゼンテーションを行うイベントです。
今回は「Autifyの管理にどんなツール使ってる?」というお題でした。
Autify autify.com Autify LTautifyjapan.connpass.com

登壇内容

TeamSpiritが発表した内容についてですが。 「スクラムチームでのAutify活用例」という内容で発表させてもらいました。
ざっくりとした内容ですが、 スクラムチームで開発を行うにあたりどのような方法で自動テストを運用しているのか?という内容です。
一年前に私が書いた内容と重なりますが自動テストの問題点として以下の二点がよく挙げられ、その結果自動テストが廃れてしまうという問題をよく聞きます。
teamspirit.hatenablog.com180度変わった業務環境で開始した業務の話 - チームスピリットデベロッパーブログ

  • 属人化: 自動テストに携わる人口が減ってしまい、一部の人間しか自動テストに関心が無くなってしまう。その結果自動テストの運用が廃れていく
  • メンテナンス工数の増加: 速度のあるスクラム開発で細かな機能追加が頻繁に行われているため、作成したすべての自動テストを定期実行してゆくとそれにより発生するメンテナンスの工数が増加し続ける

こちらの問題を解決するために以下の施策を行っています

  • 属人化の解消: 自動テストの作成有無をチーム内で決め、作成タスクを開発者にも割り当てることにより自動テストに携わるメンバーを増やしている。属人化が解消されると同時にチーム内で自動テストについての話題が出てくる環境が作成される。
  • メンテナンス工数の削減: 定期実行のほかにシーズン中に作成したテストシナリオも定期実行を行う。リリース直前に行うスルーテストのテスト項目の更新に合わせてシーズン中に作成したテストシナリオで定期実行が必要なテストシナリオの選定を行う。これによりメンテナンス工数の削減を行う。

上記のことを発表しました。

気になったツール

Autify LTで興味があった内容ですがNotionを使用して複数の機能テストを管理しているという発表がありました。
機能に対して複数のテスト(コードテスト/E2Eテスト/手動テストなど)を行っていると、何の方法で何の機能のテストを行っているのわかりづらくなってしまう。その問題を解決するためにNotionを使用して機能に対して各テストの紐づけを行うことにより各テストの管理を行っているという内容でした。
Notion www.notion.so
開発により機能が複雑になって行く中すべてのテストを一括で管理管理できるようにするためのツールというのは非常に大切になってくるだろうと感じました。

まとめ

Autify LTに参加してきました。 f:id:te_naka:20211006151010p:plain 先日行われていた発表が以下になります。 www.youtube.com 普段通りAutifyを使用していると追加された機能を見落としてしまうことがあり、APIから自動テストが実行できる機能をAutify LTで知ることになりました…
運用次第ではプルリクエスト作成時に自動テストを自動的に回すような世界も可能になるのではと思っております。
自動テストに携わっている方はもちろんのこと、それ以外の方も今後Autify LTに参加してみてはいかがでしょうか?

転職してフルリモートワークになった話

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

はじめに

2021年6月1日にチームスピリットに入社しました。
そこから3ヵ月の試用期間を振り返り、印象的だったことを書きます。

オフィスに出社したのは初日のみ

入社前は、新型コロナウイルスの感染者が増加し緊急事態宣言が解除されない中で、都内への通勤により自身の感染リスクが高くなるのではないかと不安でした。
実際は、オフィスに出社したのは初日だけでした。パソコンの受け渡しや設定、書類の確認や上長との顔合わせを行うのみで、次の日からはリモートワークでした。

オンボーディングが手厚い

勤怠管理システムは未経験だったものの、QAエンジニアとしては経験者での中途採用でした。 入社前にオンボーディングがあることは知っていましたが、中途採用ということもあり、1週間程度だと思っていたのです。
が、実際のオンボーディングは3ヵ月もありました。

1か月目~2か月目は、全社的な教育、および部署としての教育をしていただき、チームへ参加するための知識をつける期間でした。私の場合は、TeamSpiritだけでなくSalesforceも入社するまで使ったことがありませんでした。SalesforceはTrailheadを使用して学習し、TeamSpiritは製品を動かしながら学習しました。学習しながら分からないことがあったら相談することで、「どなたに質問すればいいか?」「どこを調べればよいか?」といった、チームに参加した後に困りそうなことを解消することが出来ました。トレーナーだけでなく、チームの皆さんが助けてくれました。
3か月目からは、チームに参加してOJTの開始です。少しずつ作業をいただき、トレーナーのサポートを受けながら自分の出来る作業を増やしていきます。1か月目~2か月目では分からないということにすら気づいていなかったこともあり、TeamSpiritへの理解をより深くしていきます。

また、オンボーディングでは学習する内容だけでなく、1か月目・2か月目・3か月目とそれぞれ目標設定があります。目標と現在の状況を比較して、自分の達成度を確認しながら進むことが出来ました。トレーナーや上長からフィードバックがあるので、客観的な判断と自分の主観的な判断のギャップに気づくことも出来ました。

相談できる相手や機会が多い

先ほど、トレーナーと書きましたが、3ヵ月のオンボーディングの間はトレーナーが付きます。ただし、3ヵ月が過ぎたら完全に相談できないわけではなく、今度はチーム内で週に1度は1on1の時間をいただくことができます。さらに、上長とも月に1度は1on1があり、望めば他の方にもその機会をいただくことができます。
また、これら1on1はチーム内だけに限ったことではありません。他の部署・チームの方にメンターとなっていただいています。チーム内での「縦の関係」ではなく、部署・チームを跨いだ「斜めの関係」ですので、自身のこれからの業務が会社の中でどのように関わっているのかも意識できます。

おわりに

初めてのシステム、初めてのプロジェクト、初めてのチーム…と初めてのことばかりで戸惑っていた一方で、不安や孤独はありませんでした。
大きな要因は3つあります。1つ目は、通勤による感染リスクが極めて低い環境だったことです。通勤による不安がなくなったことで、業務時間中は集中して過ごすことが出来ました。
2つ目は、オンボーディングカリキュラムが充実していたことです。学習すべきことや目標が定義されていて前進あるのみだったので、迷うことなく進むことが出来ました。最初は自覚していなかったものの、経験者での中途採用だったことで、一刻も早く製品知識を身につけなければならないという焦りもあったのだと思います。
最後に、チームの内外に支えてくださる方々がいたことです。分からないことや困っていることがあっても、一人で悩み続けずに相談できたので、孤独を感じることがありませんでした。特に、1on1は最初に思った以上にありがたかったです。分からないことを言語化できないときに、一緒に言語化していただいたこともありました。

転職前は「本当に、コロナ禍の今、転職していいものか?」と何度も自問自答したのですが、杞憂に終わりました。
「コロナ禍だから」「フルリモートワークだから」ではなく、最終的には関わる方々との関係性が大切なのであろうと、しみじみと感じました。