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に参加してきました。 先日行われていた発表が以下になります。 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は最初に思った以上にありがたかったです。分からないことを言語化できないときに、一緒に言語化していただいたこともありました。

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

【やっと】データモデリング基礎研修を受けました【書いた】

こんにちは、TeamSpirit EX バックエンドエンジニアの尾上です！

ここ最近、スキルの向上を目的に研修を受ける機会が多くなっていますが、
オンラインで受けられる研修も多くてインドアの自分は助かっています……！

---

今回は以前受講した「データモデリング基礎研修」で学んだ内容について自分が気になったことを復習がてらざっくり振り返りたいと思います！

データモデリングとは

以下のような要件を満たせるようにデータの形式（モデル）を設計すること

• データを一定のルールで定めた形式で保管し、情報をわかり易くかつ共有しやすくする
• データの追加・更新・削除を行った場合に関連データ間で不整合を発生させない
• データに効率よくアクセスできる

データモデリングの難しいところ

• ここが決まらないと機能の設計が進まないため、先行して設計作業を行う必要がある
• 一度決めると途中での変更が難しい
  （データモデルを前提に設計された他機能に影響が出る）

つまり素早く正確に設計する必要がある（！！！）

データモデリング設計でやること

1. 概念設計
   データのエンティティ間の関係、エンティティの属性を決める

2. 論理設計
   属性のデータ型やデータ長、制約を決める

3. 物理設計
   "実装可能な状態"に必要なことを決める、DDL（Data Definition Language） を作成する

以降、それぞれのフェーズについてかいつまんでみます！

概念設計でやること

データのエンティティ間の関係や属性を決定するため、
トップダウンアプローチ、ボトムアップアプローチの 2 方向から設計を進めます。
成果物：「概念 ER 図」

• トップダウンアプローチ → どういうシステムを作りたいかの理想を考える
• ボトムアップアプローチ → 現在の旧システムがどうなっているか

ボトムアプローチの「旧システムが〜」はシステム刷新の場面を想定されていそうですが、
「現状どうなっていて何があるのか」から設計をすすめるようなので
普段開発しているプロダクトの新機能に置き換えると……

• 現在顧客はどんな運用をしている？
• プロダクトの他機能はどうなっている？

といったことを考慮して設計するのがよさそうですね！

また、概念設計ではネーミングルールも制定します。
お客さんを指す言葉は「顧客」？「取引先」？
"商品" とは具体的に何を指す？
コンテキストによって「名称」と「〜名」が混在していない？
など、様々な言葉の定義や、命名の規則などを決めていきます。

これによってコミュニーケーションロスの防止や
ドキュメントの可読性向上につながります！

論理設計でやること

エンティティ属性の詳細化と分類
インデックス設計、エンティティのライフサイクル分析
成果物：「論理 ER 図」、「テーブル定義書（論理設計分）」

• エンティティ属性の詳細化 → データの型や取り得る値を体系化、制約の決定
• エンティティのライフサイクル分析 → どの業務がどのエンティティにアクセスするか、アクセスのタイミング

業務要件に沿ってエンティティを詳細化していくフェーズですが
概念設計で業務要件の整理がしっかり出来ていれば、論理設計はひたすら情報を整理していく作業！

物理設計でやること

テーブル定義、インデックス設計、サイズ見積もり
ビュー設計、セキュリティ設計 など 成果物：「テーブル定義書」、「DDL」

• テーブル定義 → 物理名称の決定や管理用列の追加、DDL の作成
• サイズ見積もり → 初期データ件数、増加率増加件数を推定して検査する
• セキュリティ設計 → アクセス権限の設定や暗号化など

テーブルを実装可能な状態にするために必要な細かい情報を詰めていきます！
また、運用に耐えうる件数に収まるか、増加数からみて何年の寿命が見込めるかを試算しておく

アクセス権限の設定では DB ユーザーのアクセス範囲や権限を設定していく。
主に開発者や利用者などで分けたロールを設計し、ロールごとに権限を設定します。

暗号化については、どのデータを暗号化するのか？
暗号化した結果、データサイズへどれほど影響があるか？
暗号方式や、暗号化/復号はどこで行うか？（DB サーバー or AP サーバー）
を決定します。

まとめ

• 概念設計では業務要件を整理してエンティティの関係や属性を決める
• 論理設計では業務要件を元にエンティティのデータ型や制約を決める
• 物理設計では実装可能な状態になるために必要な細かい情報を決める

最後に

研修を受けた時のノートを見ると 2021/07/12 となっていました。
（記事公開：2021/09/01）
タイトルに「やっと書いた」と付けているのはこのためです

早めにブログを書こうと思ってはいたのですが、
なんだかんだずるずると引きずってしまい……。
（細かなタスクは後回しにしがちですが早めに終わらせましょう、、）

-

現在自分はとある新機能のため、Salesforce オブジェクト
（DB テーブルと同じようなもの）の設計を行っていて、 "データモデリングの難しいところ" である

• ここが決まらないと機能の設計が進まないため、先行して設計作業を行う必要がある
• 一度決めると途中での変更が難しい

のプレッシャーに苦しめられています！

• 何から考えればよいのか……？
• 他に考慮すべきことはないか……？
• 自分の判断は正しいか……？
• 他の実現方法はないか……？

新たな挑戦にワクワクする反面、不安になったりもしますが
研修で学んだことを活かしつつ、困ったら頼れるチームに相談して
よりよい機能が実現できるように頑張りたいと思います！

あ、XXXさん！この後ちょっと相談いいですか！！

Salesforce認定試験をオンライン受験するときのトラブルシューティング

こんにちは！開発チームの里石です。
去年に引き続き、Salesforceの「認定 Platform デベロッパー試験」をオンラインで受験しました。

今回はオンライン試験2回目ということで、気の緩みもあったのか色々なトラブルに遭遇したので、シェアしてみたいと思います。

（2021/09/13追記）
より詳しい事前準備案内が、Salesforce公式ページにて公開されました！
オンライン受験のご紹介 - セールスフォース・ドットコム
私の遭遇した指摘事項に加えて、様々な注意事項が動画で開設されています。是非、ご参考ください。

メガネチェックの指摘

試験中、メガネをしていると、1問目の途中で画面が切り替わり、「メガネのすべての面をカメラに写してくれ」と試験官から要求されます。メガネを使った撮影やカンニング防止ですね。

私の場合はメガネをカメラに写すのが不十分だったのか、さらに画面が切り替わって試験が一時中断し、試験官とチャットをして対応することになりました。5分ぐらい待つと、試験官とチャットができるようになり、メガネを映してOKをもらいました。このとき、Kryterionでは日本語の入力ができないため、英語でのやり取りになります！

メガネ指摘時に表示される画像を再現しました。このような画像に画面が切り替わり、試験が中断されます。

マイク不備の指摘

試験アプリケーションである「Kryterion Sentinel」は、起動時にカメラとマイクを設定する必要があります。起動画面で、PC上のカメラとマイクのリストが表示されますので、選択して試験を開始しましょう。

このとき、なぜか選択せずに試験開始することもできてしまうのですが、その場合、試験中にマイクを選択するよう指摘されます。（指摘されました。）

Kryterion Sentinelを途中で終了したときの対処法（超重要）

Kryterion Sentinel起動時に、私の環境では、なぜか起動画面のリストにマイクが表示されておらず、そのまま試験を開始することができてしまいました。しかし前述の通り、メガネチェック指摘中に、試験官からマイクも選択するように指摘されました。起動時にマイクがリストに無かった旨を伝えると、

「Kryterion Sentinelをいったん終了して、PCの確認し、その後Kryterion Sentinelを起動して再開してください」

と指示されました。指示通りKryterion Sentinelを終了し、Windowsのマイク設定を調整し、再びKryterion Sentinelの起動を試みました。

このようにPC不調などで、Kryterion Sentinelを再起動しなければならないときがあります。Kryterion Sentinelは、WebAssessorサイト上の「試験開始」ボタンから起動するのですが、一度起動するとサイト上の「試験開始」ボタンは非表示になり、特別な手続きをしないとKryterion Sentinelを再び起動することはできなくなります。*1

Kryterion Sentinelを再び起動して、試験を再開するには、Kryterionのサポートサイトへ行き、チャットからサポート担当者へ連絡を取る必要があります。こちらにも案内があります。（試験会場について - セールスフォース・ドットコム）

Kryterionのサポート画面。チャットは右下から開始できます。

サポートチャットでは、表示は日本語ですが、担当者は英語話者です。日本語でお願いすると、（たぶん）機械翻訳の日本語で応対してくれるようになります。こちらからのメッセージも（たぶん）機械翻訳されて英語になっているので、機械翻訳の気持ちに寄り添い、担当者にうまく伝わるような日本語を入力しましょう。

「マイク不調で試験中断したため、再開したい」旨を伝えると、「試験時間をリスケし、ちょうど今の時間から再受験できるようにしました」と返事をもらいました。WebAssessorをみると、無事「試験開始」ボタンが再び表示されており、受験できるようになっていたので、お礼を伝えてチャットを終了しました。

「試験開始」ボタンからKryterion Sentinelを起動し、無事、PC本体のマイクを利用して試験を再開することができました。（なお、まだ1問目の途中での終了だったため、試験再開によってこれまでの回答内容がクリアされてしまうかどうかは、分かりません。）

（参考）サポートチャットの内容

ちなみに、サポート担当者の方とのやり取りはこんな感じでした。（サポート担当者の方の日本語は手直ししています。）

サポート（以下、サ）「Thank you, how may I assist you? 」
私「日本語はOKですか？」
サ「大丈夫です」
私「試験中に、Audio device一覧にマイクが表示されなかったため、試験が中断されました。マイクの接続を変更したので、試験の再開をしたいです。 」
サ「承知しました。少しお待ちください。」
サ「21:15に試験のスケジュールを変更しました。起動ボタンは、予定時刻の10分前までから20分後に使用できるようになっているはずです。しばらくお待ち下さい。」
私「ありがとうございます！起動ボタンが表示されました。」
サ「どういたしまして。他に何かお手伝いできることはありますか？」
私「もうありません。すべてOKです」
サ「Kryterionテクニカルサポートにお問い合わせいただきありがとうございます。良い一日を！安全で健康を保ちましょう！」

(※受験は20:30から始めていて、このサポートと連絡を取った時は、ちょうど21:15ぐらいでした。)

ヘッドセット不可の指摘

前回は意識していなかったのですが、今回はマイク不備を指摘されたのもあって、「マイク必要なのか！？」とヘッドセットを装着して受験したところ、「ヘッドセットは外してください」と指摘されました。

答えを聞いてる可能性があるので、そりゃあそうです。色々トラブルが起こっていて、テンパっていました。

試験中、マイクは必要なのですが、ヘッドセットは不可です。

問題文読み上げ指摘

独り言でも、何かしゃべっていると注意されます。

試験が一時停止し、画面が切り替わり「問題文を読み上げないでください」と表示されます。

また逆に誰かが、答えを口頭で教えている可能性も考えられますね。このために、マイクがきちんと機能している必要があるんですね。

最後に

いろいろとトラブルも多かったのですが、そのおかげで前回の受験記より多くのナレッジを得ることができました。これらのトラブルシューティングが、これからオンライン受験する皆さまの手助けになれば幸いです。

*1:なお、WebAssessorサイト上の「試験開始」ボタンのあった場所には、代わりに「試験は進行中です。サポートに連絡してください(xxx-xxx-xxxx)」とKryterionサポートの米国電話番号が表示されています。が、この電話番号にかけても、米国外からの電話サポートは受け付けていないようで、自動応答音声がKryterionサポートサイトのURLを繰り返し読み上げてきます。ディストピアSF映画の雰囲気が、とても味わえます。

また、Kryterion Sentinel本体は、Windowsだと「Program Files(x86)」フォルダにあるのですが、直接起動してもエラーになり起動できません。

リモートでモブプロに挑戦してみました！

初めまして！エンジニアの落合です。1年ほど前に入社し、現在はTSF新機能開発チームで開発者兼スクラムマスターを担当しています。

今回、私が所属しているチームで初めてモブプロに挑戦してみましたので、ご紹介させていただきます。

モブプロとは？

モブプロ（モブプログラミング）とは、複数人で一緒に協力しながらプログラミングすることです。
参加者はドライバー(タイピングする人)とナビゲーター(指示する人)という2つの役割に分かれて、定期的にドライバーを交代しながら行うのが一般的です。

以下の動画がとても参考になります。 www.youtube.com

モブプロを実施したねらい

一番の目的は「属人化の排除」です。

私たちのチームは、新機能を開発するにあたって知識や作業が属人化しないことを目標にしています。
そのために、今までは「コードレビューを皆で行う」という取り組みをしてきましたが、モブプロを取り入れる事でもっと効率的に知識を共有できるのではないかという狙いがありました。

その他には、以下のような狙いもあります。

• ナレッジを共有しあうことで、お互いにエンジニアとして成長する
• 協力してプログラミングすることで、フロー効率を高める
• バグの発生リスクを減らす

どのように実施したか？

準備したもの

オフィスに集まっていれば１台のモニタを囲んでお手軽にモブプロできますが、我々はフルリモートで仕事をしていますので、それは難しいです。
なので、今回はVSCodeのLiveShareという拡張機能を利用することにしました。

visualstudio.microsoft.com

LiveShareを使うと、同じエディタ上で複数人で同時編集する事が可能です。
GithubアカウントかMicrosoftアカウントがあれば利用できます。

実際の流れ

1. ホストの人がLiveShareを開始して皆にURLを教える。
2. 開発する機能の概要や実装方針を皆で確認する。
3. ドライバーとナビゲーターに分かれてコーディング開始！(ナビゲーターが指示して、ドライバーがタイピングする)
4. キリが良いところでドライバーを交代。

全員モブプロ初心者ということもあり、あまり厳密にルールを決めず「とりあえずやってみようか」くらいの気持ちで始めました。(ドライバー交代の時間や役割を厳守しませんでした。)

実際のモブプロの様子

やってみて気づいたこと

Good👍

• 全員で合意しながら実装を行うので、コードレビューの時間が短縮できました。
• 実装中に疑問や考慮すべき点が出てきたとき、その場で議論、合意、情報共有が同時に行えました。
• 熟知者からナレッジ共有してもらって早期に解決策が見つかりました。
  • 「自分ひとりでやってたら分からなかったな〜」という場面が何度かありました。

Bad👎

• 集中しすぎて休憩をこまめに挟まなかったので、かなり疲れました。定期的な休憩は必要ですね。
• 内容が簡単すぎて、ドライバーが一巡する前に終わってしまう時がありました。小さすぎるタスクは学びも少ないので、モブプロに向いてないかも・・・？

気づき💡

• リモートでもLiveShareがあれば割と支障なくモブプロできました。
• 最初は少人数で始めるのが良さそうだと思いました。(今回は3人でやりました)
  • 気軽に発言・質問できるため。
  • 少人数のほうがちゃんと全員がドライバーを試せるため。

まとめ

今回はきちんとルールを決めずに始めたため、あまりテンポよくモブプロが出来なかった時がありました。
なので、次にモブプロをする際は、

• ルールをもう少しちゃんと決めて、しっかり守る。
  • ドライバーの10分交代
  • 役割の厳守
  • 定期的な休憩
• 毎回最後にふりかえりを行ってやり方を改善していく。

といった取り組みで、学びを最大化していきたいです。

ただ、今回「とりあえずやってみる」の精神でモブプロを実践できたのはとても良かったと思っています。

最後に宣伝

そんな我々開発チームで一緒に働いてくれる方を絶賛募集中です！
ご興味のある方は、以下のURLをご覧ください！ recruit.teamspirit.com

Salesforce Saturday 京橋 始動！

こんにちは。エンジニアの田中です。

今年から チームスピリット のエンジニア有志で Salesforce Saturday 京橋 を始めました 🎉🎉🎉 sfsaturday-tokyo-kyobashi.connpass.com

Salesforce Saturday とは

Salesforce Saturday とは、Salesforce を土曜日に勉強する ムーブメントのことです。（世界中で行われています！）
我々は、Salesforce Saturday Tokyo のグループに入っているのですが、
下記のイベントページを見ると 毎週末都内のどこかで Salesforce の勉強会が実施されています。

www.trailblazers.jp

Salesforce Saturday 京橋 について

この取組みに賛同しているメンバーで、Salesforce をもくもくと勉強する会 をはじめました。
京橋にあるチームスピリットのオフィスを活用して勉強会を行うつもりだったのですが、
COVID-19の影響で集まるのが難しくなり、現在はオンラインで開催しています。

私達の勉強会では、 Salesforce が提供する「Trailhead」というeラーニングシステムを利用して自習する形式をとっています。
勉強会の間は Zoom と Quip を利用して、質問などのやりとりを行っています。 学習中の不明点は、参加者同士でディスカッションするなどして解決を目指します。

Salesforce Saturday 京橋 は 5月に一回目、7月に二回目を開催しました。 二回の勉強会では、参加する方々が自分の持っている知識を積極的に共有してくださるおかげで、
問題の解決に結びついたり、お互いに学びを得ることができています。本当に感謝です！！

#1 参加者のみなさん

#2 参加者のみなさん

今後の予定 について

Salesforce Saturday 京橋 は 8月14日に三回目の開催を予定しています。
Salesforce 関連のことを勉強したい方であれば、誰でも参加できます。
平日にスキルアップの時間が取れない方、一人ではTrailheadが続かない方、ぜひ一緒に勉強しましょう！

こちらから↓三回目の勉強会への参加登録をお待ちしております！
sfsaturday-tokyo-kyobashi.connpass.com

TeamSpirit開発チーム新体制（2021年1月～）の紹介

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

はじめに

2019年9月に入社し、エンタープライズ向けのTeamSpirit EXのQAを担当し、2020年7月からミッドマーケットをターゲットとしたTeamSpiritの開発チームに異動しました。

Service Develop Division（SD Division）について

まず、プロダクト開発がミッションである開発部門の構成について簡単に説明します。（自分が所属している開発チームの位置づけを知ってほしいので） TeamSpiritの開発部門（SD Division）は、TeamSpirit EX 製品開発チーム（通称EXチーム）とTeamSpirit Family 製品開発チーム（通称TSFチーム）に分かれています。今回のブログは、赤枠で囲んでいるTSFチームについて取上げます。 TSFチームでは、1スプリント2週間のスクラム開発を採用しており、さらなる価値創造にドライブするために、2021年1月から以下の施策を行いました。

・TSFチームの分割（1チームから2チームに）

・テストプロセスの見直し

・ユーザストーリの細分化

今回はTSFチーム体制の変更について紹介します。

チーム分割について

新機能開発チームと品質改善チームはプロダクトオーナ、開発リーダー、スクラムマスター、開発エンジニア、QAエンジニアで構成され、チームメンバ数は8名です。

新機能開発チームは、経費精算機能やシフト管理機能の強化を担当し、

品質改善チームは、勤怠管理・勤怠計算の機能改善に取り組んでいます。

テクニカルサポートチームは、ユーザからの技術的な問合せを担当するチームです。現在1名だけですが、テクニカルサポートだけでなく、開発チーム全体の改善を促進する仕組みを提案しています。

チーム分割後

各チームがスムーズに立ち上がるように「チームリードお悩み相談会」というミーティングが設けられました。参加者は各チームのリーダ、スクラムマスター、そしてエンジニアリングマネージャです。

「チームリードお悩み相談会」では、チームで上手くいっている点を他チームに共有したり、チームで抱えている課題解決のために、もう一方のチームで同じ課題を抱えていないか確認したりしています。

「チームリードお悩み相談会」は現在も継続しており、チームリーダやスクラムマスターでは解決できない問題をエンジニアリングマネージャにエスカレーションする場になっています。いわゆる「スクラム オブ スクラム」 です。

これから

2チームになり、まもなく半年になりますが、スプリント毎に振返りを行い、チームの成熟度を上げる取組みを行っています。現在、属人化解消・ナレッジ共有のために、以下の取組みを行っている最中です。

・モブテスト

・マニュアルの読み合わせミーティング

上記の取組みは開発エンジニアの積極的な協力があって出来ることなので、非常に感謝しています。 ありがとうございます。

最後に

このような開発チームに入ってみたいというエンジニアの方を募集中です。 よろしくお願いします。

recruit.teamspirit.com