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

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

Mac から Windows へ乗り換えました!

Mac から Windows へ乗り換えました!

皆さんこんにちは。Joeです。 この度 3年ぶりに開発端末を Mac から Windows に乗り換える事にしましたので その時の感想を記載したいと思います。

この投稿はチームスピリット Advent Calendar 2023 - Adventar の3日目の投稿になります。

なぜ Windows か?

これまでの約3年間、自分は開発端末としてMacを利用していました。 当時は WSL がまだ未検証で 開発では Mac の方が Bash が使える事や HomeBrew で簡単に依存ライブラリをインストールできるなどのメリットがあったため、「開発には Mac」という感覚がありました。

しかし実際のお客様の環境はほとんどが Windows 環境であり、 Windows を利用していた方がお客様の環境に近い状態で確認する事ができるメリットがあります。

これまで公式のWindows上で Bash を利用できる環境はありませんでしたが、 WSL(Windows上でLinuxを動かす仕組みの事です) が安定して稼働していることをきっかけに端末の更新時に思い切って Windows 端末に変更をお願いする事にしました。

Windows への移行

Mac端末から Windows 端末への開発環境の移行はスムーズに行う事が出来ました。 wsl を有効化すれば、後は Ubuntu 上で環境構築を行う事ができるので後はUbuntuの apt-get コマンドを利用して必要なライブラリをインストールできました。 最後に開発で利用している vscode の設定ファイルを移行してサクッと完成させる事ができます。

Mac 時代に作成したシェルスクリプトも難なく動作し、 今では Mac と遜色なく動作するようになりました。 キーボード・マウスも以前利用していた私物の物をそのまま利用できるので開発環境の移行はそれほど困難ではありませんでした。

乗り換えた結果

良かった事

最大のメリットはなんと言っても Windows 環境でプロダクトの確認を行う事ができる点です。 特にスクロールバーや選択ボックスといったOSのデザインに依存する要素は Mac で確認するのは困難を極めました。 Windowsではスクロールバーが常に表示されるので、 Macで開発してWindows 環境で動作させると、 「あれ?デザインが崩れている」と言った事がしばしばありました。 Windows 環境なら最初からWindowsで確認できるので、 デザインがどうなっているかを開発段階の初期から確認する事ができます。

次点として、 Mac と比較すると 性能が高い物を利用する事ができる事です。 この部分については詳細はお話できないのですが、以前よりも快適に開発ができるようになりました。 (もちろんMacでも問題はありませんよ!)

良くなかった事

一つは vscode について、一部の拡張機能は利用できないものがあります。(特にアトラシアンの拡張機能など) これについては WSL が Windows 内部の仮想環境で動いている事に起因するものでvscodeでアカウントにログインできない等の問題が発生する事があります。

二つ目は npm のビルドがまれに OOM killer によってキャンセルされてしまう問題が発生しました。 恐らくなのですが、 ubuntu だと npm でフルコンパイルを行うライブラリがあるのかもしれません。 npm の OS 差異によるライブラリは注意した方が良いと思います。

まとめ

まとめとして チームスピリットでは Win / Mac 両方で開発する事ができ、 私のように Mac -> Win に移行した場合でも同じように開発を行う事が可能です!

Salesforce組織がたくさんあってブラウザのタブが迷子になる

タイトル:Salesforce組織がたくさんあってブラウザのタブが迷子になる


こんにちは、この9月から新規事業推進室に異動になった倉谷 (id:a-kura) です。

今年も技術系アドベントカレンダーの季節ですね。最近アウトプットできていないので、年に1度でもこういった機会があるのは良いですね。

はじめに

さて、皆さんは複数のスクラッチ組織や本番組織で並行して作業することはありませんか?

ソースコードをデプロイして開発しているスクラッチ組織
パッケージをインストールしてパッケージのテストをしているスクラッチ組織
QAエンジニアやプロダクトマネージャーに渡すためのスクラッチ組織
そして、普段使っている本番組織など開発するためには多くのスクラッチ組織に接続しながら作業することがあります。

その際に、どのブラウザのウィンドウやタブがどのSalesforce組織に接続されたものなのか分からなくなってしまいます。

そこで、どのSalesforceに接続されたブラウザのタブなのか整理しやすくするためのTipsを紹介します。

目次

  • はじめに
  • 目次
  • 物理的にディスプレイを分ける
  • 仮想デスクトップを分ける
  • ブラウザのウィンドウに名前をつける
  • Google Chrome拡張:ORGanizer for Salesforceを利用する
  • ブラウザを切り替える
    • 通常利用しているブラウザ以外のブラウザでスクラッチ組織を開く
    • スクラッチ組織を開くためのURLを発行する
  • おわりに
続きを読む

新方式となった基本情報技術者試験を受験しました

自己紹介

こんにちは!開発チームエンジニアの水越です。

IT業界へキャリアチェンジして、今年でエンジニア歴3年目となりますが

2023年6月に基本情報技術者試験(FE)※を受験し、合格しました!

今回は2023年4月から新方式となった試験の傾向や学習方法について紹介したいと思います。

 

※ 情報処理技術者試験(FE)

「情報処理の促進に関する法律」に基づき経済産業省が、情報処理技術者としての「知識・技能」が一定以上の水準であることを認定している国家試験です。

cbt-s.com

 

新方式の変更点

2023年4月より新方式が採用されました。変更点は主に以下の4つです。

  1. 通年試験化
  2. IRT方式による採点
  3. 出題形式
  4. 出題範囲

 

1.通年試験化

これまで上期・下期の年2回決められた期間に実施されていた試験が、年間を通じてCBT方式※で受験できるようになりました。

※CBT方式

試験会場となるテストセンターに設置されたコンピュータを使用して実施する試験です。

cbt-s.com

 

2. IRT方式

IRT方式について調べると色々と難しく説明されていますが、簡単に言うと問題ごとの配点がなくなり、難易度に応じた評価点を算出する方式です。試験回ごとの難易度格差をなくす目的で採用されます。

また、評価点は科目A, B試験それぞれ1000点満点中、600点以上で合格となります。

 

3. 出題形式

試験名および問題数、試験時間に変更がありました。

【変更前】             【変更後】 

午前試験(80問,150分)     → 科目A(60問, 90分)

午後試験(11問中5問選択, 150分)  → 科目B(20問, 100分)

 

4. 出題範囲

  • 科目A:変更なし
  • 科目B:
    • 選択問題が廃止され、旧午後試験にも出題されていた「情報セキュリティ」と「データ構造及びアルゴリズム(擬似言語)」の二つの分野を中心にした構成に変更
    • 個別プログラム言語(C、Java、表計算ソフトなど)から擬似言語による出題に変更
    • 出題割合は「アルゴリズムとプログラミング」が8割、「情報セキュリティ」が2割

www.ipa.go.jp

 

1のIRT方式については評価方法の変更のため、特に受験者が気にする必要は無いと思います。(実際、私も何も気にしていませんでした。)

しかし、2,3の出題形式や範囲については新方式を想定して対策することで、合格に近づくことができたと感じたので、以下で詳しく説明したいと思います。

 

試験対策の進め方

学習の流れ

大まかですが、以下の流れで学習しました。

  1. 全体像の把握
    • 参考書の読了&例題を解く(完璧でなくても良いので、一通り終える)
    • 出題範囲が広いので、参考書を一通り実施することで全体像を把握しました
  2. 科目A対策
    • 過去問道場で旧午前試験の過去問を解く
  3. 復習
    • 間違えたところを参考書で確認
  4. 科目B対策
    • サンプル問題を眺め、なんとなくでいいので傾向を確認する。このタイミングでは解かないこと!
    • 科目Aの演習で5-6割程度取れるくらいになったら科目Aと並行して科目B対策開始
    • 私の場合、平日に科目Aを学習し、まとまった時間が取れる土日に科目Bの演習をしました
  5. 補強
    • 分野や試験回を指定して出題する機能を活用して、苦手分野を集中的に演習する(下記図参照)
    • 予想問題集を解く
  6. 実際の試験と同じ時間で科目A,Bのサンプル問題を解く

 

分野と試験回を指定する方法

 

科目A対策

科目Aに関しては出題範囲の変更は無いため、過去問とサンプル問題を中心に演習しました。

  • 過去問道場
    • 平成27年秋期〜令和元年秋期くらいまでの約5年分を実施しました。
  • 予想問題(A科目)
    • 過去問と異なり、本番同様の問題数で出題されるため、60分で解き切ることを意識して演習を行いました。
  •  サンプル問題
    • 試験直前に、本番と同じ時間配分で問題を解きました。
    • 本番形式に対応した貴重な問題のため、試験前に解くのが良いと思います。

 

科目B対策

科目Bに関しては、形式が大きく変わりましたが、問題を解くための基礎的なスキルは過去問で身につけることができます。

  • 過去問
    • 「情報セキュリティ」、「データ構造及びアルゴリズム」の2分野に絞り過去8回分を実施。
    • 最初は試験時間を意識せずに、じっくり時間をかけて解きました。
  • 予想問題
    • 過去問ベースではあるものの難易度が高く自信を失いかけましたが、本番よりも難しく作られていた問題集みたいです。
    • 予想問題で直前に演習した内容と似た問題が本番でも出題されたので結果的にやって良かったと思っています。
  • サンプル問題
    • 対策前はぼんやり眺めて、傾向を把握しました。
    • 試験直前に本番と同じ時間で演習することで、本番の出題形式の雰囲気や難易度を掴むことができました。

 

【ポイント】

科目A,Bの演習で間違えたところだけでなく、間違えた問題と同じ分野の重要そうな内容についても同時に理解・整理するよう心掛けました。

例えば、TCP/IPプロトコルの問題で間違えたら、TCP/IPだけでなくOSI基本参照モデルと紐づけて表にまとめたりすることで関連する分野の理解を深めることができました。

 

学習に使用した教材

実際に活用した教材などを紹介します。

 

1.  参考書

令和04年 イメージ&クレバー方式でよくわかる 栢木先生の基本情報技術者教室

現在は令和5年版が出ているみたいです。

令和05年 イメージ&クレバー方式でよくわかる 栢木先生の基本情報技術者教室

 

2. 過去問道場

参考書の学習が終わった後、本格的に取り組みました。

無料で利用でき、解説もしっかりしています。さらに、試験回や分野でフィルターなどの便利な機能付きです。

www.fe-siken.com

 

3. サンプル問題

新方式に対応した貴重なサンプル問題です。

特に、私の受験した5月ごろはB科目の情報は少なかったので、サンプル問題で出題形式や問題の傾向を確認しました。

www.fe-siken.com

 

4. Youtube

参考書でいまいち頭に入ってこない内容や苦手な分野の補助として利用しました。

また、通勤時などのスキマ時間にも活用していました。

注意点としては、古い情報の動画でないか?情報が誤っていないのか?精査は必要かと思います。

 

5. 予想問題集

主に科目Bの対策として購入しました。

難易度高めでしたがアルゴリズム問題の良い練習になりました。

令和05年【上期】基本情報技術者 パーフェクトラーニング予想問題集

※こちらも最新版が出ています。

令和05年【下期】基本情報技術者 パーフェクトラーニング過去問題集

 

受験後の感想

科目Aは、やや傾向が変わっている問題も出題されていた印象でしたが、基本的に過去問を中心とした対策で問題なく合格点に達することができました。

やはり、時間配分を意識して対策したこと、間違えた問題だけでなく関連する重要な内容についても整理していたのが良かったと感じています。

 

科目Bは苦手意識もあった分、入念に対策したおかげで満点をとることができました!

試験形式はサンプル問題と同じで、旧来の午後試験と比べて、各問題が短くなったことから、個人的には解きやすく感じました。学習を始めたときは新方式に合わせた過去問がなく、どう対策すべきか悩んでいましたが、科目Aと同様に、過去問や予想問題を活用してアルゴリズム処理のトレースを練習したことで新方式にも対応できるようになったと実感しています。

 

今回の資格取得に向けた学習により、ITに関する基本的な知識を幅広く習得することができました。これからの業務にも活かして行きたいと思います。

エントリーブログ:入社から3ヶ月の流れと学び

自己紹介

初めまして、2022年9月に株式会社チームスピリットに入社しました、QAエンジニアの船場です。Teamspirit EXのQA業務を行なっております。

入社前は、主にECサイトのQA業務を行なっており、Salesforceやスクラム開発は未経験でした。 今回は、入社から3ヶ月であったことや学んだことを書きたいと思います。

入社後の流れ

入社〜3ヶ月では、入社オリエンテーションと部門に応じた新入社員用のオンボーディングが用意されています。 このプロセスで業務に必要な知識やスキルを身につけつつ、業務に参画していくという流れになります。

■入社オリエンテーション

入社当日は、オフィス内の講談スペースで同期入社の仲間と入社オリエンテーションを受けました。 具体的には、会社端末の設定、入社説明、写真撮影、オフィス案内などがありました。 不明点に対しても丁寧に教えていただきとてもスムーズに業務の準備を進めることができました。

■会社・製品・業務知識説明

会社概要については、荻島代表から直接説明があり、会社として目標や共通マインドの理解を深めることで今後チームスピリットで働いていくビジョンをより明確に出来ました。

また、入社1週間程の中で、各Division Leader、プロダクトマネージャ等の方から製品知識や業務知識についての説明があります。 プロダクトの特徴や顧客に対してどういう部分で付加価値を産み出していくかを把握することは、品質保証の観点からも大事だと思っているので、こういった部分の理解に時間を取らせていただけるのはとても有り難いと感じました。 製品の特性上、法令要件や業界知識も必要になってくるので、質問の時間で不明点を解消しながら理解を進めることができました。

■Salesforce学習

Trailheadを利用してSalesforceについての学習を行いました。 必要な知識が学べるよう、QA用のカスタムカリキュラムが組まれています。 私はSalesforce未経験だったのですが、基礎的な部分から学習できとても活用的でした。

■テスト環境構築・スルーテスト

テスト環境を構築し、システム全体の挙動をシナリオ化しているスルーテストを行いました。 実際にプロダクトの個々の機能を網羅的に触れるので、研修で学んだ知識を活かしながら理解を深めることができます。

■デモ

研修内容のアウトプットとして、チームメンバーに対してTeamspirit EXの製品説明デモを行いました。 デモ内容はある程度自由度があり、製品理解という目的のもと行えるので、とても効率的にこれまでインプットした知識を定着させることができたと思います。

実務の開始

研修カリキュラムがひと段落つくと、スクラムチームに参画し少しずつ業務を行っていきます。 私はQAチームのメンバーとして、まずオフショアのスクラム開発の品質保証やメジャーリリースの総合テストに携わりました。 オンボーディング中も定例MTGに参加させていただいたり、実務についての情報共有をしてくださっていたため、スムーズに取り掛かることができました。

今後もスクラム開発や定期的なテストに加え、自動テスト、性能テスト、テストプロセス改善、CI環境の整備等様々な品質保証業務に携わらせていただける予定なのでとても楽しみです。

感想・まとめ

チームメンバーの支援もあり、とても有意義な3カ月間でした。 機能テスト、自動テスト、性能テスト、テストプロセス改善、CI環境管理等様々なジャンルで品質保証に携われるため、QAエンジニアとしてのキャリアアップに最高の環境だと思いました。また、新たにやりたいことがあれば業務に取り入れることができる、というところもとても魅力的に感じています。 今後もスキルアップを継続しながら、より魅力的な製品が提供できるよう尽力していきたいと思います。

※こちらはチームスピリット Advent Calendar 2022 - Adventarの2022年12月22日目の記事になります。

テスコンU-30で準優勝した話

※この投稿はチームスピリット Advent Calendar 2022の16日目の投稿です。

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

2022年9月17日(土)に開催されたテスコンU-30クラス決勝戦において、弊社チームスピリットのQAチームメンバーで構成されたチーム「つよつよなりたいはんぺん」が4チーム中2位の準優勝を受賞いたしました。

テスコン(テスト設計コンテスト)とは何かという話や、予選成果物提出までの内容についてはこちらの記事を参照: teamspirit.hatenablog.com

今回は予選通過後から決勝戦までのあらましと、決勝戦の様子、およびテスコンを終えての感想を書いてみたいと思います。

予選通過後から決勝戦まで

予選成果物提出後、無事予選を通過したとの発表がありました。

喜びも束の間、決勝戦に向けての準備開始になります。

テスコンU-30では予選結果発表から約2ヶ月後に決勝戦となっていましたが、予選通過後から1ヶ月ほどの間に決勝戦で使用するプレゼン資料を作成して提出する必要がありました。

また、予選成果物に対して審査員から多くのフィードバックをいただいたのですが、それを元に成果物を修正して再提出すると再度点数付けがされることとなっていました。

そのためプレゼン資料の作成の傍ら、予選成果物の修正を行いました。

予選成果物へのフィードバックとしては、全体的に個々の成果物や成果物の間の関連性についての説明が不足しているというようなものでした。そのため、最初に成果物を作成した時点では明示的に書いていなかったことや考慮不足だった点を修正成果物に盛り込みました。

また、フィードバック内容について審査員と直接会話できるフィードバック会が開かれました。自分達が考えていなかったことや、成果物をより良くするにはどうすればいいかといったお話を聞くことができ、とても勉強になりました。

修正成果物を提出してから本番までの間にも、プレゼンの持ち時間15分を測りながら発表練習をしたり、当日は質疑応答の時間もあるので想定質問を用意したりと決勝戦に向けて準備をしていました。

決勝戦の様子

決勝戦では、15分の持ち時間で成果物の内容をプレゼンし、その後5分間の質疑応答を行います。

このプレゼンの巧拙によって加点がなされ、再提出した成果物の評点と合わせて最終的な点数が決定します。

当日は予定していた内容を15分以内で話し切ることができ、また質疑応答もなんとかこなせたと思います。練習しておいてよかったです。

以下にプレゼン資料の一部を引用します。

テスト設計のアピールポイント

各テストプロセスでの強みを強調しました

テストの実行範囲・実行時間を示す

プレゼン資料の全体はテスコン公式サイトでご覧いただけます。

発表と並行してJamboardで審査員や視聴者が質問やコメントをできるようになっていました。好意的なコメントもいくつかいただけて嬉しかったです。

結果発表と講評

全4チームの発表の後審査結果が発表され、我々のチームは準優勝となりました。

その後の講評や、コンテスト終了後にチーム別にいただいた審査コメントをいくつか挙げたいと思います。

  • (成果物1: テスト要求分析の成果物で示している)テスト観点が具体的でテストケースになっているため見落としが出てしまう。抽象度を上げて、全体像を把握することを意識してほしい。
  • (テスト実行において)優先度が低いものを除外して本当にいいのか。除外することのリスクを下げることを考えてほしい。
  • テストアーキテクチャーを多面的な視点で表現しているのは良いが、テストアーキテクチャー全体で伝えたい事が何なのか分かりにくくなっていた。
  • いくつかのテストケースが期待結果不明となっており、現状のままでは第三者にテスト実行を依頼出来ない状態になっている。

いただいた講評については、今後の業務に活かしていけたらと思います。

テスコンを終えての感想

決勝戦終了後にチーム内で振り返りを行い、メンバー同士で感想を出し合いました。以下感想の一部です。

  • テストプロセス全体を実践的に学ぶには良い機会だった。特に第三者から意見・評価を頂ける貴重な機会だった。
  • 最初想像した以上に、長くてタフなコンテストだった。(※半年以上活動していた)
  • (チーム外の)先輩方からのアドバイスはもっと貰ってもよかった。
  • 去年までのテストベースは組み込みソフトウェアの仕様書であったが、今年はスマホアプリの仕様書であった。テストベースの種類によってテストの考え方が変わることが分かった。
  • テスコンU-30クラスは、自ら動けるチーム(時間に余裕がある等)であればコストパフォーマンスの良い研修になると思うので、若手QAの研修としてオススメできる。

予選成果物作成から決勝戦まで長い時間でしたが、準優勝という結果を残せてよかったです。初めの頃は成果物作成の難しさに尻込みし、やり切れるかどうか不安もありましたが、最終的に決勝戦のプレゼンまで終えることができてホッとしています。

テスコンを通して、QAやソフトウェアテストの世界の広さや奥深さを知ることができました。また他のチームの発表を聞いていて、いろんな考え方や手法があることが分かって興味深かったです。

まだまだ勉強すべきことはありますが、予選の記事でも書いたいようなテストプロセスの理解についてはそれなりに達成できたのかなと思っています。あとはテスコンで得た知識を実際の業務に活かしていければと思います。

Japan Dreamin' 2023 に協賛します!

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

来たる2023年1月28日(土)に Salesforceコミュニティ主催の Japan Dreamin' が開催されます。 弊社、株式会社チームスピリット は今回も引き続き協賛させていただきます。

Japan Dreamin' | Home

Japan Dreamin' とは

まずは Japan Dreamin' についてご紹介します。 Japan Dreamin' は国内最大規模のSalesforceコミュニティイベントです。2019年から開催されて今回で5回目の開催となります。
ビジネスユーザ・システム管理者・開発者・アーキテクト・マーケター・Salesforce 社員・Salesforce に関わる全ての人が組織や役割を超えて繋がることのできるイベントであり、 「つながる」をテーマにしていてロゴにもその想いが込められているそうです。

そのため、Japan Dreamin'では有識者の役立つノウハウを共有・学習するだけではなく、全国で孤軍奮闘しているTrailblazerが「つながる」ことで、お互いを引っ張り上げながら、支え合いながら成長していく目的もあり、Trailblazer同士の交流もいろいろとイベントの中に仕掛けがあります。

ここ2回はコロナ禍のためオンライン開催となっていましたが、
今年はハイブリッド開催(会場+オンライン)になります!

抽選50名なので、参加したい人は忘れず申し込みましょう!

つまり、今すぐ申し込みましょう!!

どうしても現地参加したい方はボランティアも狙い目です(期限:12月9日(金))

japandreamin.connpass.com

少し脱線しますが、2022年11月29〜30日に開催されたSalesforce World Tour Tokyo 2022で久しぶりにTrailblazerたちが集まることができました。そこでは久々の人たちに再会でき、懐かしくもあり、現地ならではの臨場感、そして興奮を感じることができました。 改めて、リアルイベントはいいなぁ、と感じました。

どんな発表がされているか?

Japan Dreamin'でどんな発表がされているか知りたい場合は、前回(2022年1月)の発表の一部がYouTubeチャンネルに公開されています。 そちらの動画を見ると雰囲気を掴めるかと思います。

www.youtube.com

ついでに、私も過去3回ほど発表していますのでご紹介です。昨年、一昨年については動画とそのフォローアップ動画も公開しています。

a-kura.hatenablog.jp

a-kura.hatenablog.jp

a-kura.hatenablog.jp

さいごに

毎年アドベントカレンダーに参加しています。 この投稿はチームスピリット Advent Calendar 2022 第4日目の投稿となります。

adventar.org

勤怠計算ロジックのリファクタリング、はじめました

こんにちは。QAエンジニアの石原です。
この記事では、私が現在所属しているTSFエンジニアリングチームのサブチームである勤怠計算リファクタリングチームの活動ついてご紹介したいと思います。

勤怠計算リファクタリングチームのミッション

出社時刻や退社時刻などをもとに労働時間の算出をする機能が勤怠計算です。
多くのお客様にご利用いただいているTeamSpiritの勤怠管理機能の中で特に重要な機能の1つです。

先日投稿した下記の記事でも触れましたが、ドメイン知識習得などが容易でないことから勤怠計算機能は限られたメンバしか開発やテストができないという課題を抱えており、特に開発に関する部分では、長きにわたり勤怠計算機能の開発に携わっているメンバしかソースコードの内容を把握できていないという課題があります。

teamspirit.hatenablog.com

そこで、他のメンバとも分担して勤怠計算機能の開発をできるようにするため、勤怠計算ロジックのリファクタリング(プログラミングの挙動を変えずに内部のコードを読みやすくする)を行うことになりました。
勤怠計算リファクタリングチームでは、この勤怠計算ロジックのリファクタリングを行い、最終的に製品パッケージに組み込んでリリースすることを目標としています。

どうリファクアリングを進めるか?

現在のソースコードは、

  • 構造的な課題により、テストのカバレッジを増やそうとするとSalesforceのガバナ制限に抵触してしまうためテスト数が増やせない
  • 勤怠管理機能の肝とも言えるロジックであるため、いきなり現行ソースコードを修正することのリスクが高い

ということから、現行のソースコードの外側で新しく作り直すという方針をとりました。

大まかには、

  1. 今までより詳細な勤怠計算ロジックの仕様書と、より網羅的な勤怠計算テストの仕様書を作成する
  2. 1.にもとづき、新しい勤怠計算ロジックとそのテストコードを作成する
  3. バックエンド(コントローラー)から、新しい勤怠計算ロジックと旧(=現行)ロジックの両方に接続するよう改修し、並行稼動させる
  4. 新旧それぞれの計算結果の差分を検出し、新しい勤怠計算ロジックの品質を向上させる
  5. 差分がなくなったタイミングで新しい計算ロジックに切り替える

というステップで進めていきます。

新旧ロジック差分検出のイメージ図

チーム内の役割分担

現在、勤怠計算リファクタリングチームはリーダ1名、開発者3名、QA2名の計6名の構成となっています。
開発者は主に勤怠計算ロジックの仕様書整備やリファクタリング、テストを自動化するための基盤構築や実行環境の整備などを行い、QAは主にテスト仕様書作成およびテストコードの実装を行いました。
勤怠計算のテストケースは、TeamSpiritの設定や入力パターンの多さからかなりの件数となったため(勤怠計算は勤怠管理機能の中でも特に重要な機能であり、法要件への適合やTeamSpiritをご利用のお客様の給与計算にも影響しますので、テストをしっかり行う必要があります)、テストコード実装のピーク時には開発者と外部メンバにも参画してもらいました。

現在の状況は?

新しい勤怠計算ロジックの実装とテストケースの実装が完了し、アルファテストとして開発環境に新しい勤怠計算ロジックをデプロイして、過去に実装済みのテストコードと今回実装したテストコードをそれぞれ実行しています。
アルファテスト開始直後は現行ロジックとの差分が何件も検出されましたが、改修とテスト実行を重ね、検出される差分もかなり少なくなってきました。
また、テストを自動で実行できるようにクラウド環境(AWS)や自動化ツール(Jenkins)を利用した環境整備も進めており、現在では大部分のテストを自動で動かせるようになってきました。

最後に

まだまだテストは続きますが、新しい勤怠計算ロジックをリリースできるようチーム一丸となって頑張っていきます!