関連リンク
はじめに
こんにちは、マネーフォワード ERP開発本部 福岡第一開発部 Guardianグループの@sekkyと申します。
昨年の4月にマネーフォワードに入社し、もうすぐ一年が経とうとしております。今月は8th長崎QDGというイベントに参加したのでレポートを書こうと思います。
長崎QDGとは
nagasaki-it-engineers.connpass.com
NaITEというコミュニティが主催している、長崎の技術者向けのイベントです。
詳しくは弊チームのリーダーである@tositeさんが登壇された件での記事にも記載されているので、そちらも合わせて確認いただけると幸いです。
マネーフォワードからの参加者
- レポート Part1 担当者
- @gof
- @cho.kori
- @sekky
- @arai.toshihiro
- レポート Part2 担当者
- @irie.shou
- @yukky
- @imaizumi.taiki
スペシャルセッション「事業継続を支える自動テストの考え方」 末村 拓也 氏（オーティファイ株式会社）
こんにちは、マネーフォワード クラウド経費・マネーフォワード クラウド債務支払でQAを担当している@gofです。 このセッションの感想は私が担当させていただきます！
要約
このセッションは「事業が長くなればなるほどソフトウェアが大きく複雑化するが、自動テストに具体的な使い方・使われ方を記述することで、事業継続を支える」という内容でした。
1. 事業とソフトウェア
ソフトウェアはビジネスの変化に柔軟に対応できるが、長期間の運用で複雑化し、管理が難しくなる。
良いソフトウェアは、使用方法が明確で、複雑でも安全に扱えるものである。
自動テストは、ソフトウェアの信頼性を保つための実践的なエンジニアの知恵である。
2. ソフトウェアを使う人とソフトウェアの使われ方
ソフトウェアは使用されて初めて価値を持つ。
ソフトウェアは「使われる側（プロバイダー）」と「使う側（コンシューマー）」がある。
例えば、ECサイトは「使われる側（プロバイダー）」、ECサイトを利用するユーザーは「使う側（コンシューマー）」である。
開発中は「使われる側（プロバイダー）」に注目しがちだが、「使う側（コンシューマー）」の視点も重要であり、それをテストする必要がある。
3. ふるまい、契約、自動テスト
プロバイダーとコンシューマーのふるまいを「契約」とし、自動テストはその契約を守るための技術である。
自動テストは生きたドキュメントとして機能し、ソフトウェアの動作を正確に記述する。
4. 事業とともに成長する自動テスト
事業、アプリ、テストは一体として考えるべきで、自動テストは手動テストよりも信頼性が高い。
ビジネスルールと具体例を発見し、テスト計画を立てることが重要である。
5. 複雑さを征服する
リファクタリングや分割統治を用いて、システムの複雑さを管理する。
自動テストには限界があり、すべての問題を解決する「銀の弾丸」ではない。
感想
事業の成長に合わせてコードも複雑になるのは、私自身も感じたことがあるので、深く共感しました。
自動テストが「生きたドキュメント」としての役割を果たすという考え方の意味を改めて理解できました。
通常のドキュメントであれば、ふるまい（使い方・使われ方）を変えたときに、ドキュメントをアップデートする必要があります。しかし、ドキュメントを変えるタイミングが自動で通知されないため、アップデートのタイミングを逃し、どれが最新のふるまいかわからなくなることがあります。
自動テストであれば、ふるまいが変わったらテストが失敗します。アップデートすべきタイミングを自動で通知してくれます。
そもそもテストとは具体的なふるまいの集まりです。自動テストを修正することで、常に具体的なふるまいがアップデートされ続ける、生きたドキュメントになるのだと理解しました。
契約（プロバイダーとコンシューマーのふるまい）の種類に応じてテストレベルを適切に使い分けるという話についても、「なるほど」と考えさせられました。以下が具体例です。
- ユーザージャーニー（ユーザーのUI操作が記載された資料）が契約ならば、E2Eテスト
- API仕様書が契約ならば、APIテスト
- 関数の仕様が契約ならば、Unitテスト
また、このセッションを聞きながら、私は「単体テストの考え方/使い方」という技術書を思い出しました。「出力値ベース・テスト、状態ベース・テスト、コミュニケーション・ベース・テストという3つの方法の内、出力値ベース・テストが一番優れている」といった内容です。
このセッションを通して「状態ベース・テストやコミュニケーション・ベース・テストは内部の状態に注目しがちで、プロバイダーの視点に偏ってしまう」のだと思いました。だからこそ「『出力値ベースでふるまいを記述することで、一番優れている方法となる』のようにつながるのでは」と思い、理解が進みました。
さらに、実例マッピングを使ってビジネスルールと具体例の発見方法についても新たな視点を得ることができ、具体的な活用方法を学べました。
このセッションを通じて得た知識を活かし、今後のソフトウェア開発とQA活動に役立てていきます！
技術・事例・研究セッション 「テストアーキテクチャ設計で実現する高品質で高スピードな開発の実践」苅田 蓮 氏（freee株式会社）
担当： @cho.kori
要約
先日参加したセッションで、SaaSプロダクト開発において高品質と高速なリリースサイクルを両立させるための手法として、実践的なテストアーキテクチャ設計が紹介されていました。
テストアーキテクチャ設計とは、リグレッションテストスイートの最適化と適切な自動テスト戦略によるアプローチとのことでした。
キーコンセプトは以下の2点です。
- 重篤度分類: 重篤度に基づいてテストケースを分類することで、ユーザーの手元で起こしてはいけない重大な事象の検知に集中したテストスイートを導出します。
- テストサイズ分類: テストサイズを用いてテストケースと自動テストの対応関係を整理することで、実行コストを最適化した自動テストスイートを導出します。
テストアーキテクチャ設計のステップは以下の3つです。
- 論理的機能構造を用いた機能リストの作成: PRD（Product Requirement Document）やコードをもとに、システムをドメインごとに分割し、ユーザー視点での振る舞いをフィーチャーとして特定。 各フィーチャーを論理的機能構造で分析します。
- 重篤度に基づいたテストケースの選定: 重篤度（Critical、Major、Normal、Minor）でテストケースを分類し、重大な事象を検知するケースを選定します。
- テストサイズ分類による最適な自動テストスイートの作成: テストサイズ（Small、Medium、Large）でテストケースを整理し、実行コストを最適化。 コンポーネントの責務や外部サービスとの連携状況から適切なテストサイズを特定し、論理的機能構造との対応関係を整理します。
これらの取り組みによって、テスト実行時間を90%削減し、開発速度が向上したことでリリース頻度を2週間から2〜3日に短縮できたと報告されていました。 さらに、導入後6ヶ月間、既存機能のデグレーションに起因する障害は発生していなかったそうです。
感想
同じくSaaSプロダクト開発のQAエンジニアとして、リグレッションテストの最適化は常に課題であり、今回のセッションは非常に興味深い内容でした。 特に、重篤度とテストサイズという2つの軸でテストケースを分類し、テストスイートを最適化するという考え方は、非常に理にかなっていると感じました。具体的な判断基準と手順を示しており、参考にできたらと考えています。 また、論理的機能構造とソフトウェアアーキテクチャの対応関係を整理することで、テストサイズを効率的に特定できるという点も、実務に役立つ知見でした。
また、実際に組織で導入した結果、テスト実行時間やリリース頻度が大幅に改善されたというお話も、大変刺激になりました。 私の所属するチームでも、同様の課題を抱えているため、今回の内容を参考に、テストアーキテクチャ設計に取り組んでいけたらと思います。
スペシャルセッション「ビジネスと現場活動をつなぐソフトウェアエンジニアリング ～とあるスタートアッププロダクトの成長記録より～」水野 昇幸 氏（システムエンジニアリング）
担当： @sekky
要約
本講演では、スタートアッププロダクトの開発における課題に対してどのようなアプローチを取ったのか、さらにそれを抽象化し、どのようなスキルや思考が重要であるかについて学びました。この内容はスタートアッププロダクトに限らず、あらゆるフェーズのプロダクト開発においても重要な視点であると感じています。
水野さんの講演では、大きく2つの課題に直面したとお話しされていました。
- 課題1: 顧客獲得前後で、開発の運用プロセスが「ビジネスができるソフトウェア開発運用」と大きく乖離していた
- アプローチ：手動テストや監視の仕組みを導入し、プロセスを改善
- 課題2: 顧客へのインテグレーション時に、開発チームの受け入れ工数が大きくなってしまっていた
- アプローチ：テストの継続的な改善と自動化、監視のシステムのさらなる強化
まず、課題1についてです。スタートアップの開発現場では、スピードが重要視されることが多く、様々なアイデアを試しては作り直すという高速なPDCAを回す環境です。そのため、詳細なテストが実施されることは少なく、自動テストのコードの実装も省かれがちです。このような状況では、仕様の変更が正しく反映されず、デグレーションが多発することがあります。 これに対するアプローチとして、テストと監視システムの導入が行われました。ステージング環境を整備し、テスト仕様書管理ツールを用いて顧客が使用する部分に絞ったテストケースを作成しました。 また、監視の仕組みとして不具合の収集を行い、エラー発生箇所の傾向を予測し、将来のスケーリングに向けた性能の考慮を始めました。 これにより、少なくとも顧客提供前の段階で仕様変更の管理が可能となり、変更失敗率も改善されました。
次に、課題2についてです。顧客への導入が安定し、ターゲット顧客に対して個別のカスタマイズが可能になったタイミングで発生した課題です。この状況では、売上が開発チームの導入支援能力に依存するようになります。 これに対するアプローチとして、CI環境を構築しAPIテストの自動化を実現しました。また、課題1で導入された監視システムを強化し、利用者の操作状況のログやwarning/errorの状況を取得し、問題発生時に影響範囲を判断できる体制を整えました。 これにより、受け入れ工数を抑えるだけでなく、アクティブな不具合対応・改善が可能になりました。
このような課題に対するアプローチの前に、重要なことは自身の持つスキル（道具箱）に多様性と専門性を持たせ、問題を適切に見極める能力を養うことです。
感想
私がマネーフォワードにジョインする前は、スタートアップの開発現場にいることが多かったため、これらの課題については「あるあるだなあ」と思いながら楽しく聞かせていただきました。過去に所属していた開発チームでも、スピードを重視した0→1開発が行われ、適切なテストケース管理が行われておらず、自動テストのコードもない状況がありました。また、システムのユーザーが社内の方だったため、ユーザーをテスターにする状況にもなっていました。 この状況が続くと、デグレが発生するたびに社内のオペレーションが滞り、社内の方からの不満が高まってしまいます。当時の私のチームは、ヒューマンパワーでなんとかするという解決策をとっていましたが、このような場面では適切なスキルを用いて問題解決を図るべきだと感じました。
私が所属する開発チームが担当しているクラウド経費のプロダクトは、2016年にリリースされて以来、約9年間運用されています。昨年ジョインしてからは、目の前の課題に取り組むばかりでしたが、プロダクトのフェーズやビジネスサイドの観点からも課題を見つけ直したいと考えるようになりました。 例えば、現在導入支援を行っているCR（Customer Relation）チームがどのような規模の会社とやりとりをしているのか、それに対して開発チームはどのように振る舞うべきかを考える必要があります。また、CS（カスタマーサポート）チームやCRチームから開発チームに起票されるお問い合わせを迅速に解決するための仕組み改善など、意識すべき点が多くあることを考えさせられました。
スポンサーセッション
こんにちは、クラウド経費・クラウド債務支払でQAを担当している@arai.toshihiroです！ 初長崎・初QDG参加でしたが、とてもいい経験となりました！このセッションの感想は私が担当させていただきます！
スポンサーセッションは3社によって行われました。 そのどれもが素晴らしい発表でしたが、今回は特に印象に残った株式会社NDKCOMの発表について紹介します！
要約
セッション概要
- 発表者: 水田 真之介 氏（株式会社NDKCOM）
- タイトル: ITの力で長崎から元気に NDKCOMのこれまでとこれから
株式会社NDKCOMは、社内だけでなく長崎県のIT業界を盛り上げることを目的として、社内全体でJSTQB（Japan Software Testing Qualifications Board）の資格取得に鋭意取り組まれているとのことでした。
jstqb.jp
社内の改善活動 - JSTQB推奨資格取得
株式会社NDKCOMはJSTQBの資格取得を推奨し、社員のスキル向上に取り組んでいるとのことでした。
2023年から2024年にかけて、JSTQB AL（Advanced Level）合格者は前年の1名から全社員の31%と、大きく増加したとのことでした。（原文まま）
このように大きく資格取得者が増えたという変化の背景には以下の要因があったそうです。
- 社内勉強会の実施
- 受験レポートの作成によるナレッジ共有
- 合格者が次の受験者の講師となる好循環！
私もこの取り組みに刺激を受け、イベント後に自チーム内で呼びかけを行い、定期的にもくもく会を開催することにしました！
希望者を募って週2回、1時間程度もくもくするだけの会ですが、現時点ですでに3回実施しており、ありがたいことに毎回参加者がきてくれています。
今後も継続していき、社内の技術力向上に貢献していきたいと考えています。
感想
株式会社NDKCOMの取り組みは、社員主体の学習と成長に重点を置いた非常に良いモデルだと感じました。特に、資格取得の促進と社内勉強会の継続が、技術力向上に寄与していることが印象的でした。
実は私はすでにJSTQBの資格を持っていますが、昔のことなので細かい部分を忘れてしまいました。そのため、社内メンバーにJSTQBのことを詳しく伝えるのは難しいかもしれません。
その代わりに、今後受けてみたい資格がいくつかあるので、社内の品質向上に取り組む立場から「受験レポートの共有」「資格取得者が次の指導者になる仕組み」などを取り入れていきたいと思いました！
終わりに
前半のパートはこれにて終了となります。
ここまででようやく半分に達しましたが、それだけに非常に内容の濃い、充実したイベントであったことを実感していただけるかと思います。私たちは遠く長崎の地まで足を運び、多くの学びや他社の方々との貴重な出会いを通じて、有意義な時間を過ごすことができたと感じております。
このブログを通して、当日に参加したメンバーの熱い思いを少しでも感じていただけたのなら幸いです。
後編もありますので、そちらも合わせてお読みください！
マネーフォワード 福岡開発拠点ではエンジニアを募集しています！
hrmos.co
福岡開発拠点のサイトもあるので、ぜひご覧ください。
fukuoka.moneyforward.com
