物流業界で利用されるシステムの一つが倉庫管理システム（Warehouse Management System、以下WMS）です。WMSは、倉庫内の物品の入出庫や在庫管理、ピッキングなど、さまざまな物流業務を統合的に管理します。物流業務の効率化と精度向上を目的としており、正確な在庫管理や出荷プロセスの最適化を支援します。 e-Statによると 日本国内における2023年度の営業用トラックによる輸送量 は約2,000億トンキロを超えており、さらに増加する予想となっています。そのため、物流業界はさらなる効率化が求められており、その中でWMSの重要性はますます高まっています。本記事では、品質の高いWMSを実現するのに欠かせない、テスト自動化の導入ポイントについて解説いたします。  [出典]: 自動車輸送統計調査 自動車輸送統計年報 年度次 2023年度 \| ファイル \| 統計データを探す \| 政府統計の総合窓口 WMSシステムの概要 WMSの主な機能は以下が挙げられます。 在庫管理 入出庫管理 ピッキング管理 棚卸管理 発送管理 こうした機能は、倉庫の大小に関わらず必要な機能になります。日々の入出庫データを入力し、データに合わせて在庫管理を行うことで、在庫の適正化を図ります。ピッキングは手作業で行われるケースも多いですが、ピッキングリストはWMSから出力されます。同時に送り状も印刷され、ピッキングされた物品に対して貼り付けられます。 入荷時には検品を行い、不具合なく物品が入庫したことを確認します。この時、バーコードやRFIDを利用して在庫データを更新します。逆に出荷時にはピッキングリストに合わせて製品をピックアップし、出荷情報をバーコードやRFIDと紐付けて管理します。 入出庫データは基幹システムである販売管理や、生産管理システムと連携しています。そのため、WMSは基幹システムとの連携が重要であり、データの整合性を常に保ちづけなければなりません。 在庫は常に正しいのが基本ですが、さまざまな事情で数が合わなくなります。たとえば雨漏りなどによる商品の破損、盗難、商品の不良などが考えられます。そのため、定期的な棚卸しを行い、在庫数と実数の差異を確認します。 この際、WMSは在庫数の更新を行い、データの正確性を保ちます。なお、在庫数の増減に際しては常に日付や作業者とともに記録する必要があり、履歴としてデータを管理します。これにより、過去の在庫数の変動を追跡し、問題が発生した際に原因を特定できます。 WMSはビジネスの成長とともに拡張、または縮小が発生します。たとえば倉庫の追加や拡大、物流業者の追加、国内だけでなく海外の倉庫が追加されるケースもあります。そのため、WMSには高い柔軟性と拡張性が求められます。柔軟性に欠けるWMSを構築してしまうと、ビジネスの拡大に対応できず、ボトルネックにつながりかねません。 さらに、WMSはユーザーフレンドリーなインタフェースが求められます。倉庫スタッフはITシステムの専門家ではなく、かつ実製品を扱うのが主な業務になります。実際の入力は社員ではなく、アルバイトやパートスタッフが行うケースも良くあります。システムに不慣れな人員でも理解しやすく、入力ミスが発生しづらいインタフェースが求められます。  2024年物流問題 最近の物流業界で度々話題に挙がるのが「2024年物流問題」です。これは、 物流ドライバーの働き方改革に伴うもので、労働時間に上限が課されることになりました。時間外労働時間が、年間960時間に制限されます。 これにより、物流業界は大きな変革を迫られています。 問題視されているのは、労働力不足に伴う輸送能力の低下です。ソフト的、ハード的な解決策がさまざまに行われていますが、WMSへの影響も少なくはありません。これまでトラックに頼っていた物流を、鉄道や船舶、航空機を利用するケースも増えます。そのため、WMSは新しい輸送手段への対応が求められます。 また、環境問題も大きな課題です。トラックでの輸送はCO2排出量が多く、環境負荷が大きいとされています。そのため、輸送ルートや在庫管理の最適化を実現するWMSが求められます。 物流業界全体での人材不足も深刻です。在庫管理やピッキングでの自動化、ロボティクス導入も進められています。少ない人員でも効率的に業務を遂行し、生産性の維持が求められるでしょう。自動化が進めば、より高いレベルでのWMSとの連携が必要になるでしょう。  物流システムにおけるテスト自動化 WMSでは、帳票や入出庫など実際の物品が伴う業務が多数あります。そうしたシステムのテストでは、完全な自動化を実現するのは難しいでしょう。しかし、システム間のデータフォーマットや入出力タイミングなど、自動化できる部分も多数あります。 こうした部分についてテストを自動化すれば、手動テストの領域を少なくできるでしょう。 WMSは他の基幹システムとの連携が多く、システムが複雑になります。また、入出庫は企業のビジネスに直結しているため、万一の不具合がビジネスに与える影響が小さくありません。在庫管理、ピッキング、発送管理などミスが許されない重要な業務を扱うため、手動テストでは膨大な時間と労力がかかります。テストを自動化することでテスト工数を大幅に軽減し、さらにシステム修正に伴うデグレをいち早く発見できます。 テスト自動化のメリットとしては、高速なテスト実行はもちろん、さまざまな条件を利用したテストの実行、一貫性の確保、そして工数の削減が挙げられます。一度テストスクリプトを作成すれば、何度も繰り返し実行できるのがメリットであり、24時間いつでもテストを実行できます。デメリットとしては、初期導入コストの高さやテストスクリプトのメンテナンスが挙げられます。なるべく学習コストの小さい、メンテナンス工数の低いツールを選定しましょう。 WMSではバーコードリーダーやプリンターとの連携も求められます。そのため、Windowsのようにサポートされるハードウェアデバイスが多いOSをクライアントアプリケーションとして選ばれるケースが多いです。こうしたWMS特有の要件に応じた自動化テストツールの導入も重要です。 バルテスの提供するT-DASHは「誰でもカンタンにテスト自動化ができる時代へ」をコンセプトに、低学習コストで利用できるテスト自動化ツールを提供しています。 Windowsアプリケーションにも対応しているので、WMSのクライアントアプリケーションの自動化テストにもご利用いただけます。 まとめ 物流業界は2024年問題を皮切りに、さらなる進化と効率化が求められています。WMSはその根幹を支えるシステムとして、ますます重要性を増していくことでしょう。 より品質と信頼性の高いWMSを構築するために、テスト自動化を積極的に導入してください。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post WMSにおけるテスト自動化の導入ポイント 物流2024年問題も解説 first appeared on VALTES サービスサイト .

QA（Quality Assurance）とは、品質保証を意味します。ソフトウェア開発の現場においては、最終成果物であるプロダクトの品質を保証するチームがQAチームと呼ばれます。主にテストフェーズを担当しますが、最近ではプロジェクトの開発プロセス全体に関わって品質向上を担っているケースもあります。 一方で、QAがうまく行われていないという声もよく聞かれます。テストが不十分、テスト工数に時間がかかる、テストの品質が低い…などといった課題があるようです。これらの課題は、テストプロセスが適切に構築されていないことが原因であることが多いです。 顧客はプロダクトが問題なく利用できることを信じて導入し、利用します。それが思った通りに動かないという状態は、顧客との信頼喪失につながり、ビジネス的に大きな損失を招く可能性があります。そのため、QAを強化することはビジネスにとっても重要な課題です。 本記事では、QAを強化するための手法として、テストプロセス改善について解説いたします。 テストプロセス改善によって、QAチームの生産性向上や品質向上を実現できるでしょう。 QAとは？品質保証の基本 QAとはQuality Assuranceの略語であり、品質保証を意味します。 QAチームは、プロダクトの品質を保証するために、テストを行い、品質を向上させるための活動を行います。実際にテストを手がけるケースもありますが、QAチームは複数のプロジェクトに対してテストプロセスの設計やツール開発、品質向上のためのプロセス改善など後方支援に回ることもあります。 QAチームは、プロジェクトの品質を保証するために、以下のような活動を行います。 QAチームの活動 – テスト計画の策定 – テストケースの設計 – テストの実施・管理 – 不具合の報告 – テスト結果の分析・レポート – テストプロセスの改善 – テストツールの開発・導入 QAチームはテストフェーズに関わるので、プロジェクトにおいては最終盤から関わることが多くなります。しかし、その状態から効果的なテスト設計を任されても、なかなか良いテストを作成することはできません。そのため、最近ではQAチームがプロジェクトの序盤である設計フェーズから関わり、プロジェクト全体を通してQA活動に関わるケースが増えています。 品質向上とテストプロセス改善の関係 QAチームがあり、テストを実施している中でも思ったほど品質向上が望めない場合、それはテストプロセスに課題があるのかも知れません。 テストプロセスを改善することで、テスト効率が向上し、最終的に品質向上が期待できます。 テストプロセスとは、主に以下の5つのプロセスになります。 – テスト計画 – 分析と設計 – テストの実施 – 評価と次回の改善 – テスト終了 このプロセスは、開発プロジェクトがウォータフォールであってもアジャイルであっても変わりません。規模の大小はありますが、適切なテスト設計とテスト実行、そしてそのフィードバックを次回に活かす評価が必要です。 テストプロセスにおいて、よくある課題を以下に挙げます。 テストプロセスの課題 – テストケースの設計が不十分 – テストのスコープが広すぎる・狭すぎる – テストの自動化が不十分 – テスト結果の分析・評価が不十分 これらの課題は、テストプロセスが適切に構築されていないことに要因があります。テストプロセスを改善することで、これらの課題を解決し、品質向上を実現できるでしょう。 最適なテストプロセスは組織やプロジェクト、チーム体制によって異なります。そのため、最初からベストなテストプロセスを構築できる訳ではありません。トライアンドエラーを繰り返し、フィードバックを次回に活かすといったPDCAサイクルを回す必要があります。 テストプロセス改善がQAに与える影響 テストプロセスが改善されると、後工程を含めて開発プロセス全体におけるテスト・品質に対する意識が高められ、最終的なプロダクトの不具合が減ります。結果として、プロダクトの品質向上と手戻りによる開発工数逼迫が起きづらくなります。また、テスト工数自体が削減され、開発チームの負担が減り、生産性が向上します。 QAチームに求められる役割として、開発プロセス全体に渡ってテストに対する意識を高めるという点があります。 テストしやすいコードを書く、不具合が分かりやすいログの出力、ユニットテストの網羅率を高めるなど、開発チームと協力することで、プロダクト全体の品質を向上させられます。 開発プロセスの中でテストを作り込めると、結果としてテスト工数の大幅な軽減につながります。ユニットテストレベルで不具合を検出できると、手戻りの工数が減って開発スピードが向上します。テスト工程での不具合検出数を可視化すると、テストプロセスの改善と不具合検出数の相関関係が見えてきます。こうしたレポートは開発チームのモチベーションにもつながるのでお勧めです。 QAを強化するための具体的な改善手法 もちろん、QAチームとしてもテストプロセスの改善に務めなければなりません。 ひとつの改善手法として、テスト自動化の導入が挙げられます。 人手によるテストを自動化し、継続的に実行できるようにすれば、不具合の早期発見につながります。また、テスト自動化によってテスト工数を削減し、開発チームの負担を減らす効果も期待できます。 ただし、テストの自動化についてはテストスクリプトを作成する関係上、そのメンテナンスが課題になりやすいです。テストスクリプトのメンテナンスが追いつかないと、テスト自動化の効果が薄れてしまいます。そのため、どの部分について自動化するか、どうテストスクリプトを書けばメンテナンスしやすいかといったポイントをQAチームとして検討する必要があります。 テスト自動化が導入できれば、それをCI/CDプロセスの中に組み込みます。 テストの自動実行と、その結果の最終成果物生成とデリバリーまでを自動化できれば、開発チームはよりスピーディにプロダクトをリリースできるようになります。このCI/CDプロセスにおいても、QAチームの果たすべき役割は大きいです。 そして、QAチームは開発チームに対してテストの重要性を啓蒙しなければなりません。必要に応じてテストケースのレビューやリファクタリングを行い、より効率的なテストができるようにサポートが求められます。開発とテストの役割をチームごとに分けてしまうと、コミュニケーションが取りづらくなり、品質向上につながりにくくなります。品質はテストはもちろん、開発プロセス全体の中で作り込まなければなりません。 また、テストのアウトソーシングを検討するのも一つの案です。 完全独立型のテストアウトソーシングもあれば、社内にQAチームを立ち上げるのをサポートするサービスもあります。ウォータフォール型で、テスト工程の規模が大きい場合には独立型のテストアウトソースが適しており、継続的に品質向上に取り組みたい場合にはQAチーム立ち上げのサポートを依頼すると良いでしょう。 バルテスはテストの専門会社として、顧客にとって最適なテストソリューションを提供しています。テストのアウトソーシングはもちろん、 品質向上サービス としてテスト支援・QAチーム立ち上げ・品質コンサルティング・自動化支援などを提供しています。テストプロセスに課題があるならば、ぜひバルテスにご相談ください。 まとめ 「テストプロセス改善でQA（品質保証）を強化する方法を紹介」と題して、ご紹介してまいりました。今回はQA（品質保証）改善について、テストプロセスに視点を当てて解説しました。 QAチームに求められる役割は増加傾向にあり、テストプロセスだけでなく、開発プロセスにおいても関与が求められています。 また、テストに関連したテクノロジーは広がっており、CI/CDはもちろん、AIなども利用されています。そうした技術のキャッチアップを怠らず、プロダクト品質の向上に取り組みましょう。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post テストプロセス改善でQA（品質保証）を強化する方法を紹介 first appeared on VALTES サービスサイト .

車やパソコン、家電などさまざまな製品の品質を保証するには、テストが欠かせません。ネジ一つとってもテストを行い、その精度が品質基準に適合しているかテストを行います。つまり、テストは品質管理において欠かせない要素です。 ソフトウェアについても同様です。ソフトウェアが仕様にあった動作であるか保証するためには、テストが欠かせません。テストを行い、品質が保証されればユーザーは安心して利用できます。 ソフトウェアの世界は日々進化、複雑化しており、テストの仕組みもまた変化しています。 本記事では、ソフトウェアテストの歴史と現代における役割、今後の展開について解説いたします。 ソフトウェアテストの歴史と初期のアプローチ Wikipedia によると、1979年にGlenford J. Myers氏によってデバッグとテストの分離が導入されました。テストはまだ発見されていないエラーを発見する検証活動であり、デバッグは開発活動の一部であると定義しています。 1980年には ソフトウェア・テストの技法 (1980年) という書籍が出版されています。著者は前述のGlenford J.Myers氏です。当時はマシンスペックが低かったため、あらゆる入力パターンでテストを行うと時間がかかるという問題がありました。そこで、同値分割という考えを導入し、条件をグループ化することでテストの効率化を図りました。境界値分析は、その境界値に関する分析手法になります。 初期の頃はテスト手法が確立されておらず、各組織や部署で試行錯誤が行われていました。 テストは開発技法とともに進化しており、たとえばインタフェースと実装の分離によってユニットテストが生まれています。テストは繰り返し実行できること、再現性があることが重要であり、徐々に自動化へのニーズが生まれていきました。 ソフトウェアテストの進化と現在の技術 ソフトウェアテストの転換期につながったのはCI/CDの登場でしょう。 CI/CDとは継続的インテグレーションと継続的デリバリーの略称で、開発者がコードをリポジトリにプッシュすると、自動的にビルド、テスト、デプロイが行われる仕組みです。CIはデザインパターンの提唱者として知られる Grady Booch 氏が提唱し、CDは2010年に発行されたJez Humble氏とDavid Farley氏の共著である「Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation（和訳： 継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化 ）」にて登場しています。 CI/CDによって、開発者はリリース作業に手間取ることなく、ユーザーは常に新しい機能を利用できるようになりました。 CI/CDを利用したプロジェクトでは、コードをプッシュする度にテストを実行します。そのため、テストの回数は膨大であり、人の手を挟むのは困難です。そこで、テストの仕組みを自動化する必要があります。テスト自動化にはテストの自動実行、テスト結果の自動判定などが含まれます。テストが正常に完了すれば、自動的にリリースまで行われます。 最近ではAPIを利用して外部サービスと連携する機会が増えています。そうした外部サービスとの連結部分をテストする上で、モックサーバーの存在が重要になっています。モックサーバーが外部サービスのインタフェースを模倣することで、実際には外部サービスへ接続せずにテストを行えます。 コンピュータのUIといえば、かつてはCUIであり、現在はGUIが当たり前になっています。また、デスクトップのみならずモバイルデバイスやHMD、カーナビなどデバイスは多種多様に広がっています。そうしたUI周りにおけるテストだけでなく、テスト自動化も日々進化しています。海外にあるデバイスをエミュレートする、位置情報やカメラなどにアクセスするなどテストに求められる機能は拡大していると言えるでしょう。 ソフトウェアテストとAI　今後の展開と未来の課題 最新のトレンドとしては、やはりAIが見逃せません 。UIは日々の運用によって徐々に変化するものであり、その変化によってテストに失敗する可能性が高まります。AIによる自動修正機能によって、そうした差分を柔軟に吸収し、メンテナンス工数が削減されています。また、テスト結果の判定と修正提案という分野においてもAIが活用されています。 また、テストケースの作成もAIによって自動化されています。開発者の作成したコードに対して、ユニットテストが自動で生成されます。さまざまなパターンを網羅したテストケースが生成されることで、より品質の高いプロダクトを開発できるようになります。 こうした時流の中で、テストエンジニアに求められる役割も変化しています。従来はテスト工程の管理が主な職務でしたが、現在では最新のテクノロジーを使いこなし、テストを自動化するアーキテクチャ設計まで求められることも増えてきました。その場合、ツールが出力するエラーメッセージを正しく読み取り、開発チームへフィードバックする役割も重要になっています。 バルテス社のソフトウェアテストサービスは、未来へのアプローチ これまでに書いてきた通り、テストに関わるテクノロジーは日々進化、複雑化しています。最新テクノロジーと従来の信頼あるテスト手法を組み合わせ、品質の高いプロダクトをより早く、繰り返しリリースしなければなりません。それがビジネスの価値に直結し、競争力の源泉となります。 こうした変化を、すべて社内のテストエンジニアが追いかけ続けるのは非常に困難です。そこで私たちバルテスではソフトウェアテストサービスを提供しています。 テスト専門家として、テスト計画や設計の支援、テスト自動化支援、QAチーム立ち上げ支援などを行っています。最新のテスト技術を取り入れることで、品質の高いプロダクト開発をお手伝いします。 テストはプロジェクトの進捗によって、工数が増減しやすい傾向があります。アウトソースすることで工数を適切に確保し、開発チームは製品開発に専念できます。 まとめ  「ソフトウェアテストの歴史と今後の展開　AIを活用しよう」と題して、ご紹介してまいりました。 今回はソフトウェアテストの歴史と現在、そしてテストエンジニアに求められる役割を中心に解説しました。テスト技術は日々進化しています。最新の技術を取り入れて、プロダクトの品質向上に役立ててください。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post ソフトウェアテストの歴史と今後の展開　AIを活用しよう first appeared on VALTES サービスサイト .

ソフトウェアを開発する中で、テストがどれだけ重要なのかはあえて言う必要もないでしょう。テストされていないコードをリリースすることは、致命的な不具合を生み出す可能性があります。ソフトウェアだけでなく、工業製品などは常にテストを行い、品質を保証します。ソフトウェアについても同様に、品質や機能を保証するためにテストは必ず必要です。 本記事では、社内テストと第三者検証という観点からテストについて考えてみます。第三者検証と社内テストの違いやメリット、使い分ける方法を解説いたします。 社内テストとは？役割とメリット・デメリット 社内テストとは、ソフトウェアの開発者をはじめとして、社内の人員が行うテストになります。 自社でテストを行うことで、自分たちのプロダクトに対する品質保証を行います。 社内テストのメリットは以下のようになります。 社内テストのメリット ・開発に関わった人たちがテストを行うため、意図を理解しやすい ・社内でテストを行うため、修正がしやすい ・テストの実施が容易で、コストが低い 逆に社内テストにはデメリットもいくつかあります。 社内テストのデメリット ・開発者がテストを行うため、視点が偏りがち ・テストの範囲が狭くなりやすい ・プロジェクトの進捗によってテストに割ける工数が増減する この中で、特に問題になりやすいのはテスト工数の時間です。専門のチームを設けている場合においても、社内ではどうしても融通が利きやすい傾向があります。そのため、後工程になりやすいテスト工程は短縮されやすく、その中で何とかして品質を担保する流れになります。 また、開発者自身の前提知識によるテスト漏れも発生しやすいのが課題です。開発者は前提知識として、入力が想定される内容を把握しているため、異常な入力データに対するテストが抜けやすい傾向があります。しかし、不正な利用を行う人たちはそうした異常な入力を利用することが多く、セキュリティリスクの増加につながります。 第三者検証と社内テストの違い   一方で、第三者検証は社内テストとは異なり、外部の専門家が行うテストです。第三者検証のメリットは以下のようになります。 第三者検証のメリット ・社内の視点とは異なる視点からのテストが可能 ・ソフトウェアの品質を客観的に評価できる ・テスト工数を確保しやすい ・ベンダーによっては業界や製品特性に応じたテスト観点を保有している ・前提知識のない、網羅的なテスト設計が行いやすい 第三者検証では、前提知識や社内での暗黙知がないため、より一般化したテストによる検証が可能です。そのため、社内テストでは見落としがちな不具合を発見できるでしょう。もちろん、常に第三者検証が良い訳でありません。たとえば以下のようなデメリットも存在します。 第三者検証のデメリット ・社内テストと比べてコストが高い ・複雑なワークフローに対するテストが難しい ・ピンポイントでのテストが難しい システムを開発する中で、適切で網羅的なワークフローやデータフローが作られていないと、第三者によるテスト検証は難しいでしょう。そのため、システム開発の後工程で第三者検証に入ってもらうと、必要な情報を揃えるのに時間がかかってしまいます。 また、特定の機能だけをテストするのは難しいです。システムはモジュールが複雑に絡み合って構成されており、一部のモジュールだけを理解しても、品質は保証できません。そのため、第三者検証は全体を対象とした知識とテストが求められるでしょう。 社内テストと第三者検証を 使い分けるためのポイント 社内テストと第三者検証の使い分けるためには、以下のようなポイントが挙げられます。 使い分けのポイント ・機能テストや結合テストや社内テストで行う ・セキュリティテストやパフォーマンステスト、受け入れテストの前段階でのテストは第三者検証で行う システム開発であらかじめ仕様書やRFPを作成している場合、それらのドキュメントに合わせた第三者検証は可能です。第三者検証を通すことで、ユーザー企業の受け入れテスト前に不具合を発見し、修正できます。 機能テストなどで第三者検証を入れる場合には、テストコードについて十分な内容であるか、テストケースが網羅的であるかといった検証はできるでしょう。また、社内テストで見落としがちな不具合を発見するために第三者検証を入れるケースもあります。 前述の通り、第三者検証は社内テストと比べて工数やコストが大きくなります。そのため、CI/CDなどで日常的なテスト工程に組み込むのは難しいでしょう。システムテストや受け入れテストなど、プロジェクトにおけるテストレベルが変わる段階での第三者検証実施がお勧めです。 第三者検証の重要性とメリット   ユーザー企業への納品やSaaSでの提供にしても、外部の視点は重要です。自社の人員だけでは思い込みや暗黙知が入り込みやすく、思わぬ抜け漏れが発生します。 第三者検証は、そのような抜け漏れを発見し、品質を向上させるための手段として有効です。 また、テストの専門家としての視点は、単にシステムが動けば良いというものではなく、ユーザーが求める品質を担保するための視点が加わります。さらに昨今のセキュリティインシデントにつながりやすい仕組みをあらかじめ防げ、不具合につながりやすい箇所を発見するのにも役立ちます。 第三者検証と社内テストの連携による効果 第三者検証と社内テストは、どちらかだけ行えば良いものではありません。 両方を組み合わせてこそ、より良い結果を得られます。 第三者検証で得られた知見を日々のテストに反映することで、プロダクトの品質向上につなげられます。より工数を減らしたテストを実現し、品質を担保する効率的なテストを実現できます。 また、第三者検証をより効率的に、品質高くするためには、日頃の社内テストが重要です。社内テストがまったく行われていない状態で第三者検証を行っても、不具合が多く見つかってしまって効率的とは言えません。社内テストが十分に行われている中で実施される第三者検証こそ、最も効果的なテスト戦略と言えるでしょう。 まとめ 「第三者検証と社内テストを使い分けるとメリットがあるよ」と題して、ご紹介してまいりました。今回は、社内テストと第三者検証の違い、メリット・デメリット、使い分ける方法にスポットを当てて解説しました。 社内テストは社内の人員（主に開発者）が行うテストであり、第三者検証は外部の専門家が行うテストです。それぞれのメリットやデメリットを理解し、使い分けることで、より効果的なテストを実現できるでしょう。 バルテスはテスト専門企業として、ソフトウェアテスト支援やテスト自動化などを提供しています。ぜひバルテスの品質向上サービスを皆さんのプロダクト開発に活用し、品質向上に役立ててください。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post 第三者検証と社内テストを使い分けるとメリットがあるよ first appeared on VALTES サービスサイト .

2024物流問題が話題に上がる中、物流・倉庫業界における効率化・自動化が強く求められています。その一助になるのが、IoT（Internet of Things）です。IoTは小さなセンサーなどを活用してリアルタイムにデータを収集し、データドリブンな物流・倉庫業務を可能にします。これにより、物流プロセスの効率化や在庫管理の最適化が実現します。 本記事では、物流・倉庫業界におけるIoT導入の事例とその効果について解説いたします。 物流業界におけるIoT導入事例 佐川急便では、RFIDを用いた効率的な資材管理を提案しています。RFID（Radio Frequency Identification）は、電波を用いて小さなRFタグの情報を読み取る技術です。RFIDを活用することで、資材の在庫管理やトラッキングが効率化され、作業時間の短縮やヒューマンエラーの削減が実現します。 【佐川急便】工場内物流｜TMS｜ソリューション一覧｜ロジスティクスソリューション ヤマト運輸では、ドライブレコーダーとデジタルタコグラフを一体化した専用車載デバイスを利用して、集配車の運行データを収集しています。収集されたデータは配車の効率化はもちろんのこと、ドライバーの運転状況の改善や事故防止にも利用されています。 ヤマト運輸、IoT活用ですべての集配車に車載端末を導入 | IoT NEWS 三菱ふそうトラック・バスは、IoTと機械学習を組み合わせて、構内搬送車両の稼働最適化を進めると発表しています。部品搬送に用いる200台の構内搬送車両に対してIoTデバイスを搭載し、日々の業務における稼働状況を分析するとしています。 IoTや機械学習を用いた構内搬送車両の稼働最適化に着手：物流のスマート化 – MONOist 倉庫管理のIoT事例とその効果 ロジスティードでは、2021年9月から2024年3月まで経済産業省資源エネルギー庁公募事業「AI・IoTなどを活用した更なる輸送効率化推進事業」を実施していました。この事業では自動運転フォークリフトなどの効率化機器を導入し、トラックの荷待ち時間短縮を実現しています。 IoT活用で荷待ち時間半減､ロジスティードなど実証 NTTコミュニケーションズは、倉庫環境監視IoTソリューションという取り組みを大和ハウスとともに行っています。これは施設内の温度や湿度をリアルタイムで測定し、庫内の作業員の熱中症防止・インフルエンザ罹患リスクを低減します。 NTT Com、倉庫の労働環境をIoTで監視–大和ハウスが物流施設で活用 – ZDNET Japan 住友倉庫では、タブレットなどで出入庫や在庫状況を一元的に把握できるシステムi-Warehouse（アイウエアハウス）を開発しています。倉庫作業員がスキャナーで情報を読み取ると、Bluetoothでスマートフォンなどとデータが共有されます。従来の紙媒体での管理に比べ、全体の作業時間を約20%短縮されています。 ECサイトにおけるIoT活用事例 IoTを活用した物流・配送の最たる例がECサイトです。Amazonでは、商品の在庫管理や配送状況をリアルタイムで把握するために、IoTデバイスを活用しています。また、ピッキングや倉庫オートメーションを支える技術としてIoTが徹底的に活用されています。 Amazonが展開する最新の倉庫オートメーション、新世代の倉庫ロボットたち | 株式会社フォーバル 日本ではサービスは終了してしまいましたが、ZOZO SUITはサイズ計測のためのウェアです。正しいサイズを計測して、そのサイズに合ったアパレルを選択できる仕組みです。現在はアメリカにて、ZOZOFITとしてサービスを継続しています。 3D body measurement & tracker by ZOZOFIT | Body fat percentage, BMI ECサイズにおけるIoT活用は、物流のボトルネックを解消し、顧客体験の向上にもつながっています。なお、バルテスでは衣料品・雑貨等の企画・製造・販売を行うアダストリア社向けのテスト品質支援も行っています。事例は以下よりご覧いたします。 株式会社アダストリア様 – VALTES テストサービス IoT導入の課題と成功へのポイント IoT導入を成功に導くためのポイントとして、IoTは以下の3つのパーツに分割できます。 センサーデバイス ネットワーク クラウド（サーバー） センサーデバイスはごく小さく、大量に配備できるものでなければなりません。プロトタイピングはRaspberry PiやArduinoを使えますが、実運用時には専用デバイスを開発することが多いでしょう。それにより、低消費電力で安定した運用が可能になります。 次にネットワークは、センサーデバイスからクラウドまでの通信を担当します。センサーデバイスはバッテリー駆動であることが多いため、通信の頻度やデータ量を最小限に抑えることが求められます。また、通信の安定性も重要です。スマートフォンやコンピュータのように常時接続環境は実現が難しく、かつネットワーク速度が遅いケースも多いです。 最後にクラウド（サーバー）です。センサーから収集したデータを分析し、そこから何らかの価値を生み出します。さらに、分析結果によってはデバイスの動作を変更するといった、カスタマイズも必要になります。そうしたサーバーとデバイス間の双方向通信の仕組みも必要でしょう。 成功事例から学ぶ導入のポイントと今後の展望 これらの課題を踏まえて、成功事例から学べるIoT導入のポイントです。 – ビジネス課題を明確にする – プロトタイピングを繰り返す – セキュリティを考慮する IoTを導入してどういったビジネス課題を解決したいのか、それを明確にしましょう。まずデータ収集からはじめてもうまくいかないことが多いです。課題が明確になれば、どういった方法やデバイスが必要なのかも分かってきます。 そして、一度の導入で完了すると考えない方が良いでしょう。プロトタイピングを開発してテストし、改善を繰り返す必要があります。特にセンサーを多数配備してからの変更は容易ではないので、事前に十分な仮説検証を行いましょう。 また、IoTプロジェクトではセキュリティも重要です。IoTデバイスはネットワークに接続されるため、セキュリティ対策を怠らないようにしましょう。不正な侵入を許してしまうと、センサーのデータを読み取られる、または逆に送られる可能性があります。IoTデバイスにはスマートフォンやコンピュータのようなセキュリティが施されている訳ではなく、自分で実現する必要があります。 まとめ 今回は物流・倉庫業界におけるIoT導入事例と課題について紹介しました。EC市場が拡大する中、物流・倉庫業界にはさらなる進化が求められています。その一端を担うのがIoTになります。 IoT導入は十分なテスト、仮説検証、セキュリティ対策が欠かせません。ぜひ今回紹介した事例を参考に、自社のビジネスへのIoT活用を検討してください。 当サイトでは、テスト技法を学びたい方、アジャイル開発やマイグレーションのテスト手法について知りたい方、テストアウトソーシングサービスに興味のある方へ、ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post 物流・倉庫業界におけるIoT導入の実例とその効果 first appeared on VALTES サービスサイト .

システムのマイグレーションにおいて、データベース（以下DB）に関する変更を行う場合があります。DBはシステムの根幹を担う存在であり、この際にはさまざまな懸念点があります。たとえばスキーマ変更やデータ移行に伴うダウンタイムのリスクがあり、その解決手段としてDBテストが欠かせません。 本記事ではDBテストにおける課題と解決策について解説いたします。 マイグレーションにおけるDBテストとは マイグレーション時におけるDBに関する変更としては、以下が挙げられます。 – DBの変更 – DBのバージョンアップ – スキーマ変更 – データ移行 いずれの場合においても、移行した後にテストを実施してDBの正常性を確認しなければなりません。主なテストとしては、以下が挙げられます。 スキーマの整合性テスト スキーマはDBの設計図であり、根幹です。これがマイグレーション前後で正しい状態であることを確認します。開発環境と本番環境でカラムの並び順が異なってエラーになる、張られているべき外部キーやインデックスがないといった問題を発見できます。 データの整合性テスト カラムの種類を変えたり、DBを変更したりすると、データの整合性が損なわれる場合があります。開発環境のDBは個人情報などがマスクされているため、移行前後の本番環境のデータを利用してテストを行います。 パフォーマンス・負荷テスト DBをバージョンアップ、または別なDBに載せ替えた場合には、パフォーマンステストや負荷テストが必須です。クエリの実行速度やDBの応答時間を測定し、必要に応じて最適化を行います。 バックアップ・リストアテスト 本番環境のデータが正しくバックアップされており、かつリストアも問題ないことを確認するテストです。バックアップされているはず、と思い込んだ結果、万一の際にデータが消失するケースは少なくありません。バックアップのタイミング含め、正しく動作していることをテストします。 マイグレーションにおける課題 DBはシステムのボトルネックになりやすいと言われます。理由は、アプリケーションサーバーは増やせても、DBをスケールさせるのは難しいためです。 そのため、DBテストを適切に行い、常に最良のパフォーマンスを出せるように準備が必要です。 複雑性 DBはアプリケーションから利用するのが基本です。DB自体の複雑さに加えて、そうした利用する外部システムとの互換性も考慮しなければなりません。クライアントのドライバーがDBと適合していないと、レスポンスが文字化けしてしまう、対応していない文字コードを送信してDBに障害が発生することもあります。 また、DBには固有の方言、固有の機能があります。SQL以外のトリガー周りはDB依存性が高く、マイグレーション時の足かせになることが多々あります。扱えるデータ型についても、DB毎に異なるので注意が必要です。 ダウンタイム マイグレーション時には一定のダウンタイムが発生するのは致し方ないでしょう。ビジネスへの影響を最小限にする必要があります。Amazon Aurora PostgreSQLやGoogle Cloud SQL for PostgreSQLなどのマネージメントサービスではダウンタイムが（ほぼ）ゼロでのパッチ処理などをサポートしています。こうしたサービスを利用するのも一つの解決策です。 テスト DBのテストを適切に設計するのは困難です。DBはアプリケーションと密接に関連していたり、トリガーなどの独自処理も追加できます。そのため、単体テストでデータベースに関連する処理をカバーするのは難しいでしょう。結合テストなどで、ワークフローを通じてDB周りもカバーする形になります。ただしアプリケーションからすべてのデータに触れるよう設計するのも大変・スクリプトが膨大になってしまうので、テストの範囲をどこまで広げるかが難しい判断になります。 テスト環境を用意する際にも、本番環境と同等の環境を作るのは多大なリソースが必要です。また、大量のデータを用いた負荷テストを行う場合、テストデータの作成やテストの実行に時間がかかるため、効率的なテストの実施が難しい点も挙げられます。 マイグレーションDBテストの解決策 では、このようなマイグレーションDBテストの課題をどのように解決すればよいのでしょうか？以下にいくつかの解決策を紹介します。 計画立案 マイグレーションを円滑に成功させるためには、まず詳細な計画立案が不可欠です。DBの停止はビジネスへの影響が確実にありますので、利用者への告知も十分に行わなければなりません。そして、最小限の時間で済むように設計します。 マイグレーション時に何らかの問題が発生した場合に備えて、バックアップや社内での通知体制を整えましょう。移行が完了した後もモニタリングを続け、問題が発生した際に素早く対応できるようにしておきます。 テスト環境の構築 実運用環境と同じDB環境を構築し、テストを十分に行います。ただし、クラウド環境などではOSがすでにバージョンアップしているなど、ライブラリまで含めてまったく同じ環境を作るのは難しいかも知れません。 テスト環境ではスキーマ変更やデータ移行をシミュレーションし、なるべく手作業なしで行えるように準備を整えます。テスト環境で潜在的な問題を発見し、移行後のトラブルを防ぎましょう。 テスト自動化ツールの活用 DBのテストは複数のステップを経て行われるので、自動化ツールの活用も検討したいところです。自動化ツールを利用することで、同じ手順を繰り返し検証できます。また、自動化ツールを利用すれば作業漏れ、検証漏れを防げます。 適切な計画立案を行い、それに沿ってテストスクリプトを作成しましょう。 マイグレーション品質向上支援サービスのご紹介 バルテスでは長期・大規模・高難度のマイグレーションプロジェクトを支援する「マイグレーション品質向上支援」を提供しています。 当サービスでは、マイグレーション経験者を中心とした品質管理支援担当（QMO）が御社プロジェクトに参画し、品質活動を推進します。 マイグレーションプロジェクトで起こりがちな「現行システムの仕様がわからない」という課題に対して、システムマイニングのツールを活用して現行システムフローを可視化します。 また、マイグレーションで発生するリグレッションテストについては、当社のテスト自動化ツール「T-DASH」を利用して省力化を図ります。さらに、テスト管理ツール「QualityTracker」を活用して、ボリュームの高いテストを一元管理します。 まとめ DBはシステムの根幹を担う存在であり、マイグレーションの失敗はビジネスの致命的な問題になりかねません。それを防ぐためには、綿密な計画、テスト環境そしてテスト自動化ツールの活用が肝要です。 バルテスでは、マイグレーション品質向上支援サービスを提供しています。マイグレーションプロジェクトにおける品質活動を支援し、成功を後押しします。マイグレーションプロジェクトにおいて課題を感じていましたら、ぜひバルテスにお問い合わせください。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post マイグレーションにおけるDBテストの課題と解決策 first appeared on VALTES サービスサイト .

ソフトウェア開発手法は、プロジェクトの規模や目的に応じて最適なものを選択することが成功の鍵になります。アジャイル開発やウォーターフォール開発など、さまざまな手法が提案されていますが、その中でもV字モデルは、品質向上や効率的な開発を実現するための手法として改めて注目されています。 本記事では、V字モデルの基本概念や構造、メリットと課題について解説いたします。 また、V字モデルをさらに発展させたW字モデルとの比較や、実務におけるV字モデルの活用についても取り上げます。ぜひ、本記事を参考にして、V字モデルの重要性を学びましょう。 V字モデルとは何か？ V字モデルとは、ウォータフォールモデルの一種で、開発プロセスをV字型に表現したモデルです。 左半分は要件定義や設計などの開発工程を示し、右半分はテスト工程を示しています。V字モデルでは、開発工程とテスト工程が対応している点がポイントです。 ウォータフォールモデルの場合、設計フェーズとテストフェーズが独立しています。従って、テストで見つかった不具合がどの設計段階に起因しているのか分かりづらいことが課題でした。 それに対して、V字モデルでは、開発工程とテスト工程が対応しているため、不具合の原因を特定しやすくなります。問題点に起因している箇所が明確になることで、次のプロジェクトの改善につながったり、品質向上につながったりするといったメリットがあります。 V字モデルのメリットと課題 V字モデルのメリットとして、以下のような点が挙げられます。 品質向上や効率的な開発への貢献 テスト工程を中心にした開発が可能 一方、V字モデルには以下のような課題もあります。 設計変更が発生した場合の対応が難しい テスト工程の遅延が全体の進捗に影響する ではV字モデルについて解説します。 V字モデルのメリット ・品質向上や効率的な開発への貢献 V字モデルでは、開発工程とテスト工程が対応しているため、不具合の原因を特定しやすくなります。そのため、品質向上につながるだけでなく、開発プロセス全体の効率化にもつながります。たとえば結合テストでの不具合発覚が多い場合、基本設計のやり方を見直すことで、将来的な不具合発生数を減らせる効果が期待できます。 ・テスト工程を中心にした開発が可能 V字モデルでは、テスト工程が開発工程と対応しているため、テスト工程を重視した開発モデルと言えるでしょう。テスト工程を軸にすることで品質管理体制を整えることができ、最終成果物の品質向上が見込めます。 V字モデルの課題 ・設計変更が発生した場合の対応が難しい V字モデルは、開発工程とテスト工程が対応しているため、設計変更が発生した場合の柔軟な対応が難しい傾向があります。設計変更が発生した場合、テスト工程にも変更が必要になるため、全体の進捗に影響が出やすくなります。 ・テスト工程の遅延が全体の進捗に影響する V字モデルではテスト工程を重視しているため、テスト工程に遅延が生じると、全体の進捗に影響が出ます。もちろん、開発工程に遅延が発生した場合には問題が発生します。しかし、V字モデルの場合には一定のテスト工数を確保しておくことが重要です。 W字モデルとV字モデルの違いとは？　2つのモデルを比較してみよう V字モデルをさらに発展させたW字モデルという開発手法があります。 W字モデルの特徴は、開発工程とそれに対するテスト工程を同時に行う点が特徴です。 つまり、前述したV字モデルにおける課題の一つである「テスト工程の遅延」を極力なくせるのがW字モデルの特徴です。また、テスト工程の作業を同時に行うので、手戻りのリスクを軽減できるというメリットもあります。 W字モデルの場合、テストエンジニアはプロジェクトの初期段階からアサインし、テスト計画やテストケースの作成、検証を行います。通常、テスト工程は後工程に回されがちですが、W字モデルの場合はその点が異なります。 V字モデルの場合、設計フェーズが終わった段階でテストエンジニアはテスト設計、テストケースの作成に入ることができます。そのため、開発工程が行われている間にテスト工程の準備を進められます。 一方、W字モデルの場合、開発工程とテスト工程が同時に進行するため、テストエンジニアは設計工程にも参加し、テストの観点から開発への関わりが求められます。 テスト工程自体は、V字モデルとW字モデルで大きくは異なりません。ドキュメントに対する仕様漏れ、コンフリクトが発生していないかと言ったテストは追加されますが、開発工程後のテストはV字モデルと同じです。単体テスト、結合テスト、そしてシステムテストといった工程が行われて出荷されます。 実務におけるV字モデルの活用例 V字モデルを成功させるためには、以下のようなポイントに注意する必要があります。 テスト工程を重視した開発体制を整える テスト工程の進捗管理を徹底する テスト工程における自動化を推進する それではVモデル成功のためのポイントや活用例を、詳しくご紹介していきます。 テスト工程を重視した開発体制を整える V字モデルでは、テスト工程を重視した開発体制を整える必要があります。テスト工程を中心に据えて品質管理体制を整え、最終成果物の品質向上にプロジェクト全体として取り組まなければなりません。また、テスト結果を対比する工程にフィードバックし、同じ不具合が発生しないよう改善を繰り返します。 テスト工程の進捗管理を徹底する V字モデルでは、テスト工程の進捗管理が重要です。テスト工程が遅れると全体の進捗に影響が出るため、進捗管理を徹底しましょう。また、テスト工程についてもあらかじめ見積もり、完了した際には振り返りを実施します。何か問題があって遅延した場合には、次回には繰り返さないようにするか、テスト工程の見積もりを見直すなどの対策を講じます。  まとめ 「V字モデルの全体像と重要性　W字モデルとの違いも解説」と題して、ご紹介してまいりました。V字モデルは、開発工程とテスト工程をリンクさせることで、テストを中心に据えた開発工程を実現できるため、製品の品質向上や開発の効率化が期待できます。 本記事を読まれた方の中には、V字モデルを古いと思われる方もいるかもしれません。しかし、日本の開発現場においては、V字モデルを用いているプロジェクトは今も数多いです。ぜひV字モデルを理解し、品質の高い製品を提供できるよう開発側とテスト側で協力し合い、プロジェクトを進めていきましょう。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post V字モデルの全体像と重要性　W字モデルとの違いも解説 first appeared on VALTES サービスサイト .

QA組織と聞いて、どのようなイメージが浮かぶでしょうか。多くの方はテストや品質チェックのプロセスを思い浮かべるかもしれませんが、実はそれ以上の役割を持ちます。QA組織は、製品を市場の期待を超える品質で提供することを保証します。それは継続的な品質管理と改善の中心であり、企業の競争力の源泉なのです。 本記事ではQA組織の紹介と、あなたの企業に対して果たす大きな役割について紹介いたします。 QA（品質保証）とは？ QA（品質保証）とは、ソフトウェア開発における重要なプロセスです。 製品の設計段階からリリースに至るまでの各フェーズにおいて、品質基準を満たしていることを保証する活動を言います。開発ライフサイクル全体を通じて、バグの発見と修正、さらに機能の正確性の確認やユーザビリティの向上など、製品がエンドユーザーにとって価値あるものになるよう担保します。 エンドユーザーにとって意味のある製品と体験を提供するのは、顧客満足と企業の信頼性を高めるために必要不可欠です。品質管理プロセスを組織化し、体系的に実施すれば、コストの効率化と市場投入までの時間短縮を実現し、競争優位性につながります。  QA組織とは何か？ QA組織とは、製品の品質と整合性を維持・向上させるための専門チームや部門を指します。この組織は、ソフトウェア開発プロセス内で品質基準が設計から実装、さらにリリース後のサポートに至るまで適切に適用されるよう活動します。QA組織の役割は多岐にわたり、開発初期段階での要件定義のレビューからはじまり、コーディングやテスト、デプロイメントに至るまでの全開発プロセスに対する品質チェックを統括します。 テストフェーズにおける役割 QA組織は、テスト計画の策定やテストケースの設計を行い、継続的な品質改善につながるデータを収集します。例えば、テスト自動化の採用を支援し、回帰テストの速度と正確性を向上させ、マニュアルテストでは捉えにくいエラーを検出するために複雑なテストシナリオを設計するなど、さまざまなアプローチで品質向上を目指していきます。 また、不具合が発見された際には原因の特定や、是正措置が迅速かつ適切に実施されるよう開発チームと協力します。 チーム間のコミュニケーションと協調 効果的なQA組織は品質保証のプロセスを文書化・自動化し、開発ライフサイクルに組み込みます。これは、開発チームとのコミュニケーションを明確にし、かつ責任の所在を確かなものにします。 こうした透明性はチーム間の協調を促し、予期せぬ問題への素早い対応を可能にします。さらに、リリース後に発生する可能性があるリスクを事前に評価し、その影響を最小限に抑えるための戦略を立案、実行します。 継続的な品質向上 最終的に、QA組織はひとつの手段として、CI/CD（継続的インテグレーションおよび継続的デリバリー）を導入し、品質の監視するための指標とフィードバックのループを導入を行ったりします。 これは、製品の品質を継続的に追跡・向上させるのに役立ちます。また、顧客からのフィードバックを積極的に取り入れ、顧客満足を最大化するための製品改善に関する責任の一端を担います。このようなQA組織の総合的なアプローチによって、品質の高い製品を市場に提供できるのです。 QA組織が企業にもたらす価値 QA組織が企業にもたらす最大の貢献は、製品の信頼性を高めることにあります。 信頼性の高い製品は顧客の期待を単に満たすだけでなく、期待をも上回る可能性があります。信頼できるQAプロセスを構築できれば、エラーは早期に特定され、リリース前にほぼ解決することができます。 つまり、製品が顧客の目に触れる際にはすでに問題がなく、顧客が経験する問題の数はほとんどありません。その結果、製品は顧客の期待通りに動作し、安定性と性能の面で顧客の信頼を勝ち取れるのです。 つまり、QA組織は顧客満足度を向上させるために欠かせない役割を担っています。品質保証プロセスによって、顧客のニーズと期待に合った製品が作り出されることが保証されるのです。エンドユーザーが直面する可能性があるシナリオやユースケースは事前に考慮され、それに基づいてテストが行われるでしょう。その結果、高い顧客体験と実際の利用に合わせた使いやすさが提供されます。 QA組織が品質問題に対して素早く対応し続ければ、顧客からの信頼は確固たるものになるでしょう。市場投入後のフィードバックや不具合報告に対して迅速に対応すれば、顧客は自らの声が開発チームに届いていると実感します。ソフトウェアの不具合をゼロにするのは非常に困難です。 しかし、不具合を迅速に修正する能力を示せば、それは企業が製品に対して持つ責任感と献身を反映していると見えるでしょう。こうした素早い不具合解消は、長期的な顧客との信頼関係を構築する上で必要不可欠です。 QA組織がない組織におけるリスク QA組織がないと、ソフトウェア開発プロセスは多くのリスクに晒されてしまいます。 品質保証の手順が確立されていない場合、コードのバグやパフォーマンス問題が開発の早い段階で検出されず、製品の信頼性に直接影響します。 こうした問題がリリース後に顕在化すると、顧客の信頼を損なってしまうでしょう。さらに、システムのダウンタイムやデータ損失など、直接的なビジネス上の不利益につながる可能性が高まります。これらのインシデントは、ブランドの評判に長期的な悪影響を及ぼす結果にもなりかねません。 リリース後に発覚した問題に対処するコストは、開発中にそれらを解決するよりもはるかに大きくなります。製品が実稼働している中で問題が見つかると、急遽パッチを作成・配布しなければならず、場合によってはリコールにつながります。 これには、開発チームが本来の開発スケジュールを中断して対応する必要があり、他の機能開発に影響します。また、問題を解決するために人員を追加投入する場合もあります。こうした問題は、開発段階で品質保証を行えていれば回避できる余分なコストです。 さらに、低品質な製品は顧客からの問い合わせの増加につながります。これはサポートチームの負担を増やし、顧客サービスの品質を悪化させます。不満足な顧客がネット上で不平を書いたりすると、新規・既存の顧客に影響を与えてしまい、ビジネス上のネガティブインパクトにつながります。もちろん、低品質な製品は顧客の離反・競合他社の移行へもつながります。それは失われたビジネス機会として計算され、企業の市場シェアの低下につながるでしょう。 つまり、品質組織や品質保証プロセスの欠如は、開発の後工程における経済的リスクを増大させるだけでなく、事業継続性と成功にも大きな影響を及ぼすのです。 自社にQA組織を設立するステップ では、ここから自社にQA組織を設立するステップについて解説します。 目的と目標の定義 組織の構造と人員の計画 QAプロセスとメトリクスの定義と実装 1. 目的と目標の定義 自社にQA組織を設立するために、まずQA組織の目的と目標を明確に定義しましょう。企業のビジョンと整合性を保ちつつ、品質基準やプロセス、および責任範囲を決めます。意思決定を素早く行うために、経営層を巻き込んでトップダウンでの推進が望ましいです。そして、全社として品質がビジネスの成功に直結することを理解してもらいましょう。 目標は極力具体的・測定可能・達成可能・高い関連性なものを設定し、それらに基づいて何をすべきかを検討・実施します。 2. 組織の構造と人員の計画 次に、QA組織の構造と人員を計画します。成功するためには、適切なスキルセットと経験を持つ人材を集めなければなりません。理想的な人材像としては、様々なテスト手法に精通し、開発者と効率的に協力できるコミュニケーション能力を持つ人でしょう。 また、チームにはテスト自動化やパフォーマンステスト、セキュリティテストなど、特定の専門知識を持つメンバーが含まれるべきです。そうしたメンバーの役割と責任を明確にした上で、十分なトレーニングとリソースを提供して組織の土台を築きます。 3. QAプロセスとメトリクスの定義と実装 3つ目の工程として、QAプロセスとメトリクスの定義および実装を行います。品質保証活動が一貫性と透明性を持つよう、標準化された手順とドキュメンテーションが必要です。また、進捗と品質を測定するためのKPI（重要業績評価指標）を定義し、これらのデータを用いて、プロセスの改善と効果的な意思決定につながる基盤を作ります。 QAは一時的なものではなく、継続的な活動です。継続的な改善の文化を構築するためには、定期的なレビューとフィードバック、成果と課題のチーム全体での共有が必須です。品質に対するチーム文化の構築こそが、効果的なQA組織を運用する上で軸になるでしょう。 まとめ 今回はQA組織とは何か、そしてなぜあなたの企業にQA組織が必要なのかについて解説しました。QA組織については、多くの企業や開発チームで必要性が高まっていると感じます。しかし、なかなか取り組めていない組織も多いのも実情です。それだけ、QA組織の設立や運用には多くの課題やハードルがあるということを意味します。 バルテスでは、QA組織の設立や運用を支援する「QAチーム立上げ支援サービス」を提供しています。 QA組織に関する課題感がある方は、ぜひ一度ご相談ください。バルテスの専門家がお手伝いいたします。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post QA組織とは何か、なぜあなたの企業に必要なのか first appeared on VALTES サービスサイト .

自動化は、今やソフトウェア・システム開発の不可欠な要素です。 本記事ではシステム開発やソフトウェア開発を軸に、プロセスごとの自動化トレンドを詳しく解説いたします。 効率的な開発プロセスを実現するためのキーアプローチを紹介し、そのメリットを深掘りします。ここでは、システム開発における自動化、ソフトウェア開発における自動化を合わせて「開発自動化」と呼んでいます。 また、開発自動化において役立つサービスやソフトウェアについても紹介します。最新の技術を活用して開発プロセスを効率化し、品質を向上させるための一助としてください。 開発自動化とは 開発自動化とは、ソフトウェアやシステムの開発プロセスにおいて、繰り返し発生するタスクを自動化する技術や手法を指します。 このアプローチにはコード生成やテスト、デプロイメントといった各段階での自動化が含まれており、手動での作業を最小限に抑えるのがゴールです。 例えば、CI（Continuous Integration。継続的インテグレーション）や CD（Continuous Deployment。継続的デリバリー）は開発自動化の一例であり、コードの変更があるたびに自動的にテストとデプロイが行われるように設定されています。 開発自動化の主な目的の一つとして、開発の効率を向上させる点とプロダクト品質を一定に保つ点が挙げられます。自動化されたプロセスを導入して人的ミスを減らし、さらに反復的なタスクにかかる時間を削減できます。 また、デプロイメントの速度が向上するため、より迅速に市場にプロダクトを投入できます。これらは競争上の優位性につながり、顧客満足度向上にもつながるでしょう。 開発自動化が特に注目される背景には、技術の急速な進化と市場の変動があります。世の中のデジタル変革が進む中で、企業はより素早く効率的に、高品質なソフトウェアを市場へ提供する必要に迫られています。 自動化はこの市場ニーズに応えるための鍵となり、さまざまな技術を利用して開発プロセスを最適化する動きが加速しています。 クラウド技術、人工知能（AI）、機械学習といった技術が開発自動化をさらに推進し、複雑なタスクも効率的に処理できる時代に移り変わっています。 システム開発の自動化トレンド 現代のシステム開発における自動化トレンドは、インフラストラクチャの管理、データベース管理、ネットワーク設定の自動化など多様な文化で進んでいます。 これらの領域ではIaC（Infrastructure as Code。コードによるインフラ管理）や自動化されたデータベースマイグレーションツール、ネットワークの自動構成ツールが広く利用されています。 IaCでは、サーバーの構成やネットワークの設定などのインフラ要素がコードとして管理され、これによってインフラのセットアップ、スケーリング、管理が自動化されています。また、データベース管理においては、スキーマの変更やデータの同期を自動化することで、データ整合性を保ちつつ効率的な運用が可能となります。 これらの自動化技術は、開発プロセス全体の速度と効率を飛躍的に向上させています。インフラ管理を自動化することで、システムのデプロイメントが数時間から数分に短縮されるケースも珍しくありません。自動化されたデータベース管理システムによって、データベースの変更やスキーマ管理が迅速かつ確実に行われています。 その結果として、開発チームはより創造的な作業に集中できるようになります。さらに、ネットワーク設定の自動化はシステムの安定性を高め、セキュリティリスクを最小限に抑える助けとなります。 自動化のメリットは、単に効率化だけではありません。組織全体のリスク管理や品質保証にも寄与しています。 自動化によってヒューマンエラーの可能性がなくなり、一貫性ある環境が保証されます。その結果、より安全で信頼性の高いソフトウェア提供が実現します。システム開発の自動化は、技術面だけでなく、ビジネス戦略でも重要な役割を果たしています。 ソフトウェア開発の自動化トレンド ソフトウェア開発における自動化のトレンドは、コード生成やコードレビュー、テストの自動化に重点を置いています。 これらの技術は、ソフトウェアの品質を向上させるとともに、開発速度を大幅に改善します。コード生成ツールは、GitHub Copilotに代表されるサービスで提供され、エディタと連携して煩雑なプログラミング作業を自動化します。 開発者は、より高度な設計やアーキテクチャに集中できるようになります。一方、コードレビューの自動化では、静的コード解析ツールが利用され、コーディング標準の遵守や潜在的なエラーの特定が行われます。忙殺されがちなリードエンジニアの負担を軽減し、コード品質を維持するための重要なツールとなっています。 テスト自動化は特に注目される領域で、手動テストの限界を超えた効率と精度を提供します。自動テストフレームワークやツールを使用することで、コードが変更されるたびにテストが自動的に実行され、問題が即座に検出できます。その結果、リリース前のバグの発見と修正が迅速に行われます。テスト自動化はCI/CD領域で特に有効であり、開発のサイクルタイムを短縮し、プロダクト品質を継続的に向上・維持できます。 これらの自動化技術の導入によるメリットは多数あります。 まず、開発プロセスの効率化によってプロジェクトの時間とコストが削減され、より多くのリソースをイノベーションに割り当てられるでしょう。 また、エラーの早期発見と修正により、最終的なプロダクトの品質が大幅に向上します。さらに、自動化はチームメンバーを繰り返しの単調な作業から解放し、よりクリエイティブで価値の高い活動に集中できることで、モチベーションに貢献します。 これらの要素が組み合わさり、組織全体の競争力が強化されます。 役立つサービス・ソフトウェアについて では、ここでは各プロセスにおける代表的なサービスやソフトウェアを紹介します。 インフラストラクチャ自動化 インフラストラクチャ自動化においては、IaC（Infrastructure as Code）が主流です。IaCは、インフラストラクチャの設定や管理をコードで行うことで、環境の自動化とスケーラビリティを実現します。代表的なツールとしては、以下のものがあります。Terraformは元々オープンソース・ソフトウェアであったこともあり、多くのユーザーに利用されています。 各パブリッククラウドでは、自社のクラウドサービスに対応したIaCツールが提供されています。 – [Terraform]( https://www.terraform.io/ ) – [AWS CloudFormation]( https://aws.amazon.com/jp/cloudformation/ ) – [Azure Resource Manager]( https://azure.microsoft.com/ja-jp/features/resource-manager/ ) – [Google Cloud Deployment Manager]( https://cloud.google.com/deployment-manager ) データベース管理 データベース管理においては、データベースマイグレーションツールが利用されています。これらのツールは、データベースのスキーマ変更やデータの同期を自動化することで、データ整合性を保ちつつ効率的な運用を実現します。 パブリッククラウドでは、データベースの移行や同期を自動化するサービスが提供されています。 – [Flyway]( https://flywaydb.org/ ) – [Liquibase]( https://www.liquibase.org/ ) – [AWS Database Migration Service]( https://aws.amazon.com/jp/dms/ ) – [Azure Database Migration Service]( https://azure.microsoft.com/ja-jp/services/database-migration/ ) – [Google Cloud Database Migration Service]( https://cloud.google.com/database-migration ) ネットワーク自動化 ネットワーク自動化（NetOpsと呼ばれます）においては、Ansibleのネットワークモジュールが有名です。ネットワーク機器では各機器メーカーでOSが異なるという課題があり、なかなか自動化が進んでいません。その中にあって、Ansibleはさまざまなベンダーの機器に対応しており、自動化が進めやすい環境を提供しています。 – [Ansible Network モジュール]( https://docs.ansible.com/ansible/2.9_ja/network/user_guide/network_resource_modules.html ) – [NEEDLEWORK]( https://www.ap-com.co.jp/ja/needlework/ ) – [NetBrain]( https://www.netbraintech.com/ ) CI/CD CI/CD（継続的インテグレーション/継続的デリバリー）は、ソフトウェア開発プロセスにおいて、コードの変更を自動的にビルド、テスト、デプロイするプラクティスです。CI/CDを実現するためのツールとして、以下のものがあります。 – [Jenkins]( https://www.jenkins.io/ ) – [CircleCI]( https://circleci.com/ ) – [GitLab CI/CD]( https://docs.gitlab.com/ee/ci/ ) – [GitHub Actions]( https://github.co.jp/features/actions ) – [Travis CI]( https://www.travis-ci.com/ ) コード生成 コード生成は、開発者がコードを書く際に、自動的にコードを生成するツールです。コード生成ツールは、開発者の生産性を向上させるだけでなく、コードの品質を向上させる効果もあります。代表的なコード生成ツールとしては、以下のものがあります。 – [GitHub Copilot]( https://copilot.github.com/ ) – [Tabnine]( https://www.tabnine.com/ ) – [Resharper]( https://www.jetbrains.com/resharper/ ) コードレビュー コードレビューは、開発者が書いたコードを他の開発者がチェックし、品質を確保するプロセスです。コードレビューを自動化することで、コーディング標準の遵守や潜在的なエラーの特定が行われます。代表的なコードレビューツールとしては、以下のものがあります。 – [SonarQube]( https://www.sonarqube.org/ ) – [CodeClimate]( https://codeclimate.com/ ) – [Codacy]( https://www.codacy.com/ ) – [DeepSource]( https://deepsource.io/ ) – [Codebeat]( https://codebeat.co/ ) テスト自動化 テスト自動化は、あらかじめ作成したシナリオに沿ってWebブラウザやGUIアプリケーションを自動操作してテストを行う手法です。テスト自動化を実現するためのツールとして、以下のものがあります。 – [T-DASH]( https://service.valtes.co.jp/t-dash/ ) – [mabl]( https://www.mabl.com/ja/ ) – [MagicPod]( https://magicpod.com/ ) – [Testim]( https://www.testim.io/ ) – [Cypress]( https://www.cypress.io/ ) まとめ 開発自動化はインフラ、データベース管理、ソフトウェアテストといった各プロセスで進化し続けています。自動化はエラーの減少、効率の向上、そして最終的なプロダクト品質の向上につながります。 自動化導入によって、開発チームはより創造的な作業に集中でき、組織の競争力を高められるでしょう。 ぜひ、本記事で紹介したサービスやソフトウェアを活用してシステム開発、ソフトウェア開発の自動化に取り組んでください。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post 開発自動化の最新トレンド：プロセス毎にまとめて紹介 first appeared on VALTES サービスサイト .

組み込みソフトウェアとは、特定のハードウェアに組み込まれて、そのハードウェアの機能を制御するために設計された専用のソフトウェアを指します。日常生活で使用される多くのデバイス、例えば家電製品や自動車の制御システム、ネットワーク機器などに利用されます。組み込みソフトウェアは、特定のタスクを効率的に遂行するのに特化しており、多くはリアルタイムで動作します。そのため、組み込みソフトウェアには高い信頼性と安定性が求められます。 本記事では、組み込みソフトウェアに焦点を当てて、そのテストに関する考え方を解説します。 組み込みソフトウェアのテストの特徴 組み込みソフトウェア特有のテストとして、ソフトウェアとハードウェアが正しく連携して動作することを確認する点が挙げられます。組み込みソフトウェアは特定のハードウェアで利用されるため、そのハードウェアとのインターフェースや相互作用をテストする必要があります。そのため、単にソフトウェア単体での動作確認では終わりません。 また、組み込みソフトウェアの多くは、リアルタイムでの動作が求められます。そのため、タイミングやパフォーマンスの検証も大事な要素になります。さらに、組み込みソフトウェアが外部からアップデートされる場合、アップデートと再起動が正しく行われるか、セキュリティ面を含めた確認が必要です。 ソフトウェア開発全般で言えることでもありますが、組み込みソフトウェアでは、ホワイトボックステストとブラックボックステストが大事になります。ホワイトボックステストは、ソフトウェアの内部構造やコード全体を検証するもので、コードレベルでの不具合を発見・解消するために行われます。ブラックボックステストは、ソフトウェアの機能や出力を検証するもので、ユーザー視点での動作確認を行います。この二つを組み合わせて、ソフトウェアの品質を保証します。 組み込みソフトウェアはユーザー環境（家庭やオフィスなど）で利用されることが多く、セキュリティに関するテストを十分に行わなければなりません。特にインターネットに接続する機器は、不正な利用をされないように検証する必要があります。一方で、インターネットを介することでOTA（Over The Air update）が容易になります。正しい更新は受け入れる一方、不正な利用は防げるような仕組みが必要です。 テストの際に、シミュレータやエミュレータを活用するのも組み込みソフトウェアの特徴です。これらは実際のハードウェアを利用せず、その動作が検証できます。これにより、ネットワーク状態の変更や異常な状態を再現でき、効率的なテストが実現できます。もちろん、それですべて行える訳ではなく、実機でのテストは欠かせません。 組み込みソフトウェアのテストプロセス テストのプロセスとして、ホワイトボックステストは通常のシステム開発と大きくは変わりません。ユニットテスト、結合テスト、システムテストに分けて段階的にテストを行うなかで、主にユニットテストと結合テストの前半まではホワイトボックステストとして行われています。これらのプロセスは自動化が容易で、さまざまなツールが利用できます。 特徴的なのはハードウェアとソフトウェアの相互作用テストでしょう。これは組み込みシステム特有のテストプロセスです。ここではタイミングや消費電力、入出力インターフェースの動作確認などが行われます。先述の通り、シミュレータやエミュレータを利用することで、ある程度自動化も可能です。ただし、最終的にはハードウェアに組み込んだ上での実機テストが必要です。 テスト自動化の導入と利点 組み込みソフトウェアにおけるテスト自動化は、IoT（Internet of Things）市場の拡大とともにますます重要になっています。IoTで利用されるデバイスは、多様な環境で利用されるため、多くのテストケースを網羅する必要があります。また、IoTデバイスはセンサーやアクチュエーターを多く搭載しているため、その動作を確認するためのテストが必要です。これらのテストを手動で行うのはテストケース数の多さなどから困難であり、自動化が不可欠です。 また、ファームウェアのアップデートや機能追加が頻繁に行われる環境では、自動化が不可欠です。これにより、人的エラーのリスクを減少させ、一貫性のあるテスト結果を得ることができます。 ArduinoやRaspberry Pi、Mbedなどの有名なIoTボードでは開発環境が充実しています。標準的なプログラミング言語が利用できたり、ライブラリが多数用意されていたりするため、テスト自動化を行いやすい環境が整っています。また、エミュレータやシミュレータがあり、実機を用意しなくてもテストを行うことができます。しかし、すべてを自社で開発している場合、そうしたハードウェアのエミュレーション環境を用意が必要であり、自動テストは難しいでしょう。 自動化ツールの選定と導入方法については、プロジェクトの特性やチームのスキルセットに応じて適切なツールを選びましょう。組み込みシステムの場合、多くはC/C++を使用しているため、C/C++に適した自動化ツールを選ぶことになるでしょう。ツールを選定する際には、サポートするプラットフォーム、拡張性、学習のしやすさなども考慮する必要があります。 テスト自動化を導入する利点として、一番大きいのはテスト工数の削減が挙げられます。テストスクリプトの構築、自動化テスト環境構築という初期投資は必要ですが、その後はテスト工数を大幅に削減できます。また、自動化されたテストスクリプトは再利用可能であり、ソフトウェアの変更があった際にも迅速に対応できます。これにより、リリースサイクルが短縮され、品質向上にもつながります。 さらに、自動化ツールの適切な運用によって、テストプロセス全体の透明性が向上し、不具合のトラッキングやレポート作成が容易になります。自動化テストの結果は一貫しており、客観的なデータに基づいた意思決定が可能となります。 まとめ 組み込みソフトウェアは、ソフトウェア面だけでなくハードウェア面も考慮したテスト環境構築が必要です。また、バージョンアップなどの運用面も考慮し、セキュリティ面でのテストも重要になります。 テスト自動化は、開発からリリースまでのサイクルを高速化する上で欠かせません。プロジェクトの要件に合わせて、最適なツールを選定・導入してください。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post 組み込みソフトウェアにおけるテストの考え方 first appeared on VALTES サービスサイト .

IT化という言葉が一般的に使われるようになってから、すでに20年以上が経過しています。その中で多くのシステムが開発され、現在も運用されているでしょう。そうしたシステム（一般的にレガシーと呼ばれます）の中には、時代の変化に取り残され、時代遅れのアーキテクチャになっている場合があります。 レガシーなシステムを刷新するモダナイゼーションと、もう一つのキーワードであるマイグレーションの違いについて、基礎とその課題について解説いたします。 モダナイゼーションとは？ モダナイゼーションとは、既存のシステムを刷新して最新のテクノロジーやアーキテクチャに変更するプロセスを言います。主な目的としては、システムの効率化やセキュリティ向上、ライセンスコストの低減などが挙げられます。レガシーシステムをリファクタリングする、プラットフォームを移行する、新しいテクノロジーによる刷新など、さまざまな方法があります。 対してマイグレーションとは、既存システムやデータを新しい環境へ移行するプロセスになります。良くあるところでは、既存のオンプレミスシステムをクラウドアーキテクチャへ移行するケースが挙げられます。 この場合、現状のソフトウェアをそのまま利用し、新しい環境で動作させることもありますし、システム更改を含む場合もあり、マイグレーションと同時にモダナイゼーションを行うことも多くあります。。 モダナイゼーションが必要になるケース モダナイゼーションが必要とされる理由はさまざまです。まず良くあるの理由は、技術が進化して既存システムが時代遅れになり、システム修正が複雑化・難解になってしまうケースです。また、ソフトウェアやハードウェアのライセンスが切れることで、サポートが終了するタイミングで取り組むケースもあります。 システム修正に時間を要するのは、企業の競争力低下につながります。市場にマッチしたサービスを素早く提供できなければ、あっという間にライバル企業に遅れを取ることでしょう。また、サポートが切れたソフトウェア・ハードウェアを利用するのは、セキュリティリスクにつながります。  マイグレーションの目的  マイグレーションはシステム移行が主なプロセスであり、その目的としてコスト削減や柔軟性の向上が挙げられます。特にクラウドへの移行は、スケーラビリティや可用性の向上につながり、サービスの状況に応じた柔軟なリソース増減を可能にします。また、多くの場合オンプレミスに比べて、初期コストを低減できます。 モダナイゼーションの課題  実際にモダナイゼーションプロジェクトを推進する際に課題となるポイントを3つ紹介します。  複雑性  長期に渡るシステム運用の中で、さまざまなカスタマイズが行われているでしょう。そうしたカスタマイズにより、システムは複雑になっています。それらを新しいアーキテクチャに対応させる、新技術で置き換えるのは容易ではありません。よく挙げられるのはCOBOLからJavaへの移行プロジェクトです。レガシーな技術を理解するエンジニア不足や、移行ツールの欠如が課題になります。 ビジネス上のリスク  一般的に、モダナイゼーションプロジェクトは大規模な開発になります。時間とコストがかかり、スケジュール上の問題発生も少なくありません。そして、プロジェクトが完了するまでは新しいビジネス要件に対応するのは困難でしょう。新規システムへの移行に失敗し、ビジネスが停止したという話題にも事欠きません。モダナイゼーションが必要なケースは多いですが、それに伴うビジネスリスクは正しく認識しなければいけません。 過去の資産への理解度 ドキュメントが残されていたとしても、すべての仕様を理解するのは容易ではありません。緊急で行われたパッチについては、ドキュメントが存在しないこともあります。また、運用の工夫で解決している要件があるケースも少なくありません。そうした人に依存した知識は、人事異動や退職などによって失われます。システム全体の理解が進んでいない中でのプロジェクト実施は、大きなリスクになります。  モダナイゼーションとマイグレーションのテストの役割 モダナイゼーション・マイグレーションプロジェクトにおいて、テストは極めて重要な役割を果たします。ここではテストのカテゴリー毎に解説します。  結合テスト 結合テストはシステムを個々のモジュールに分割して開発し、それらを正しく連携できるか確認するテストです。大規模なシステムであれば、実際の開発は個別のモジュール・コンポーネントに分割して行われます。また、マルチベンダーでの開発も良く行われます。そうした場合、徹底した結合テストが必要です。 システムテスト システムテストは、システム全体が仕様通りに動作するかを検証するテストです。一般的に、結合テストの後で実施されます。システムテストでは、エンドツーエンドで機能が正しく実行されることを確認し、全体的な動作検証を行います。  パフォーマンス・負荷テスト パフォーマンス・負荷テストは、実際の運用環境において、システムが期待通りの性能を発揮するか検証します。モダナイゼーションやマイグレーションでは、アーキテクチャの変更やインフラ周りの変更が行われます。そのため、ネットワークのレイテンシーや新しいデータベースなどによって、予定通りのパフォーマンスが出ない（旧システムより劣化する）ケースがあります。  ユーザー受け入れテスト（UAT） 実際のエンドユーザーがシステムを試用し、要件が満たされていることを確認するテストです。この時点ではシステムが完成している前提になりますので、ユーザー視点からのUI/UXを確認するのが一般的です。そして、ユーザーフィードバックを基に、最終的な調整や改善を行います。  マイグレーション品質向上支援について ここまでで挙げた課題に対応すべく、バルテスではマイグレーション品質向上支援サービスを提供しています。これは、レガシーシステムからのマイグレーションプロジェクトにおいて、「仕組み化」を重視したテストサービスになります。古い資産の仕様を明らかにし、マンパワーに頼らないテスト支援を行います。 主な特長は3つあります。  現行システムフローの可視化 システムマイニングツールを活用し、「現行システムの仕様が分からない」という課題に対応します。システムフローが明らかになることで、マイグレーション対象となる資産の特定やテスト範囲の見極めが可能になります。  勘所を押さえた品質活動を推進 当社の品質管理支援担当（QMO）がプロジェクトに参画し、品質活動を推進します。マイグレーション経験者を中心としており、マイグレーションプロジェクトにおける品質活動の勘所を押さえています。  ツールを有効活用したテストの省力化と資産化  当社の提供するテスト自動化ツール「T-DASH」や、テスト管理ツール「Quality Tracker」を活用し、テストの省力化と資産化を実現します。  まとめ 本記事ではモダナイゼーションとマイグレーションの違いと必要性、課題、そしてテストの重要性について解説しました。どちらも一定のリスクが内在しており、適切な戦略とテストプロセスの導入が成功の鍵となります。 バルテスでは、マイグレーション品質向上支援サービスを通じて、マイグレーションプロジェクトの成功を支援しています。ぜひ、お気軽にお問い合わせください。 The post モダナイゼーションとマイグレーションの違い 基礎から課題まで解説 first appeared on VALTES サービスサイト .

　バルテスが主催するカンファレンスイベント「VALTES QUALITY DAY ～DX/AI時代における品質向上の価値～」が、2024年5月29日に開催された。 　同イベントでは、「アパレル企業のDXにおける品質戦略」をテーマにバルテスの逆井賢と小宮理恵子がアダストリアの櫻井裕也氏と対談を実施。グローバル進出とDXによる変革を迎えているファッション業界において、店舗／ECの融合・独自物流網・業務支援AIなどのさまざまなシステムの品質をどう担保しているのか、その戦略を聞いた。 登壇者紹介 株式会社アダストリア 執行役員 デジタルソリューション本部長 兼 DX本部長 櫻井 裕也氏 バルテス株式会社 品質マネジメントサービス事業部 流通品質サービス部 リーダー 小宮 理恵子 バルテス株式会社 品質マネジメントサービス事業部 流通品質サービス部 副部長 逆井 賢 アダストリアのDXをバルテスが2018年からサポート 　アダストリアは、ショッピングセンターを中心に展開するカジュアルファッション専門店チェーンである。2023年に創業70周年を迎え、30を超えるブランドを国内外に約1400店舗展開。さらに、公式Webストア『.st（ドットエスティ）』は1750万人の会員を有する。また、マルチカテゴリー戦略による多様な商品を展開しており、アパレルはもちろん服飾雑貨やライフスタイルにまで幅広く対応することで、「顧客がより楽しんでもらえるようなサービスを展開しています」と櫻井氏は語る。 　アダストリアは、約4年前に示した中期経営計画で4つの大きな柱を設定。1つ目は収益改善と成長を両立させる「マルチブランド、カテゴリー」、2つ目はECやデジタルを活用して顧客体験を向上させる「デジタルの顧客接点、サービス」、3つ目はグローバルとローカルを掛け合わせた造語でワクワクを海外に届ける「グローカル」、4つ目は飲食を代表とする新たな事業にチャレンジする「新規事業」である。そして、将来的には2026年2月期3100億円、営業利益率7.2％を目指している。 アダストリアの成長戦略の概要 　成長を見据え、システムに関しても強化を図るべくここ数年で大規模な投資を実施している。2024年2月期の実績で「36億円」、2025年2月期は「38億円」を計画。「成長のためにはシステムへの投資が重要であり、会社のど真ん中で取り組んでいます」と櫻井氏は力強く語る。 　同様に力を入れているのがDXの推進だ。「社員、スタッフが“ワクワク”して働ける環境を作る」「世の中を“ワクワク”させるサービスを提供し続ける」というDXの2本柱を設定。具体的な取り組みとして、自社ECの『.st』ではECを「Electronic Commerce」から「Entertainment Community」に進化させるべく、「スタッフボード」と呼ばれるコンテンツを展開。「4000名以上のスタッフが『.st』内で自身のスタイリングなどの個性を発信することができ、さまざまなお客様に楽しんでもらえるようなコミュニティ作りをしています」と櫻井氏は語る。 アダストリアのDXの2本柱 　加えて、購入商品の幅を広げるために『.st』の「オープン化」も推進しており、これまでにピーチ・ジョンやヤーマンなどが『.st』に参画。アダストリアがこれまでに取り扱ってこなかった商材を取り扱うことで顧客がより楽しんで買い物ができるようなサービス提供を目指している。 　そのほか、ECの世界をリアルでも体験できるOMO（Online Merges with Offline）ストア『ドットエスティストア』を全国に10店舗以上展開。新たなサービスとして、スタッフの愛用品を購入できるフリマサイト『ドットシィ』や、メタバースでのデジタルスキンを取り扱うバーチャルファッションモール『StyMore（スタイモア―）』なども展開。海外版の『.st』を立ち上げたほか、中国が取り扱うアパレルブランドを海外展開する越境EC『Wardro（ワードロ）』を2024年2月にオープンさせるなど加速度的なチャレンジを遂げている。 OMOストア『ドットエスティストア」のイメージ 　さまざまなチャレンジに取り組むアダストリアだが、DX部門を取り巻く環境も「大きく変化しています」と櫻井氏は説明する。「例えば、新たなサービスや事業が続々と開始するためDX部門としてもかなりのスピード感が求められます。また、自社の業務システムやECが他社でも利用可能なプラットフォームになりつつあることで、求められる品質はより高くなっているのが実情です」と櫻井氏は語る。 　スピードを上げる策の1つとして、国内パートナー中心の開発体制から「海外パートナー（Offshore Development Center：ODC）＆内製化」を推進。品質面では、独自の品質管理体制からバルテスとの協業による強化を図っている。 　バルテスがアダストリアの品質支援をスタートしたのは2018年。当初は2名体制の小規模なチームで、EC領域のテスト支援を行った。そこから業務システムへのテスト支援などにも領域を拡大し、在庫管理や会計の全システムに関わる2022年の大規模改修に際しては、その全般的なテスト実施をバルテスが担当。これにより、アダストリアのシステム全般に関するノウハウがチーム内に蓄積され、支援対象領域が飛躍的に広がったという。そしてここから現在に至るまで、基幹システムも含めたシステム全般のテスト支援をバルテスが担っている。 バルテスの品質支援の流れ 　また、最近ではEC化の加速にともなう「倉庫自動化プロジェクトへのテスト支援」や、グローバル展開に対する「海外ECへのテスト支援」なども担当。現場担当であるバルテス 小宮は「加速度的に進化を続けるアダストリアの最新ビジネスに並走する動きを続けています」と胸を張った。 品質や生産性の向上をバルテスとともに取り組んでいく 　後半は、パネルディスカッションを実施。バルテスの逆井がまず「バルテスの導入前・導入後で品質はどう変わりましたか？」と問うと、櫻井氏は、「バルテスの参画前はアダストリアの社員がテストを実施していたため、品質の観点では障害がほぼ毎日起きていたうえに、障害対応が繰り返し発生する状態でした。一方でバルテスの参画後は、業務に影響が出るようなトラブルが格段に減少し、ECやユーザーに対するサービスレベルが飛躍的に上がりました。社員の働き方も新サービスの検討や既存サービスの改善などに集中できるようになった点はとても大きかったです」と振り返る。 　この話を受けて逆井は、専門的な業務を専門家に外注することで自分たちが本来やるべき作業に集中できるようになるという副次的な効果に注目。バルテスとしてもそれが、我々が存在する第一の理由だと考えると訴えた。 　櫻井氏はこれに同意しつつ、「事業の成長やDXの推進において、コア事業とそれ以外の領域をきちんと分けることが重要です。それ以外の領域についてはその道のプロに任せるなど、取り組みにメリハリをつけることも大事だと考えてバルテスに参画してもらいました」と付け加えた。 　次に逆井から、「流通・小売関連システムに特有の品質課題について」の質問が投げかけられた。ここでまず、櫻井氏がポイントの1つに挙げたのは「ビジネスモデル」。そもそも、流通・小売業界は1つのサービスを提供するうえでさまざまなステークホルダーが関わっており、そのステークホルダーを結ぶラインがどこか1つでも途切れてしまうとビジネスは回らない。つまり、ビジネスモデル自体が「“さまざまなバリューチェーンをつないで顧客にサービスを届けている”という点が大きな特徴です」と櫻井氏は説明する。 　「これは流通・小売を支えるシステムでも同様です。さまざまなバリューチェーンをつなぎ、上流からきちんと下流へデータが流れてこないと最後の店舗販売まで至りません。バリューチェーンのつなぎがとても重要になるのです」と櫻井氏は続ける。実際、サービス提供までにはいろいろなシステムでデータの受け渡しが発生しているため、例えば品質課題だけを見ても上流から下流まで、どこか1つがダメになってもバリューチェーンは切れてしまうため注意してシステムを構築する必要があるのだ。 　流通や小売に関するサプライチェーンマネジメントに関するシステムには「（サブシステムも含む）システムの総数が多い」ことや「メインとなるシステムが定義しにくい」といった特徴がある。だからこそ、横断的に品質を考える必要があり「そこに難しさを感じている」と逆井は実感を述べた。これを受けて櫻井氏は「バルテスはその点、バリューチェーン自体のプロセスを非常に理解し、アダストリアのシステムの背景や現状などもきちんと把握してくれました。これこそが、品質管理の面で大きな意味を持っていると思います」と評価した。 パネルディスカッションの様子。左から逆井氏、櫻井氏、小宮氏 　次のテーマは、「外注化の品質的メリット・デメリット」について。体制として「社員」の下に「開発ベンダー」と「テストベンダー」が連なる場合、櫻井氏はメリットとして「お互いの役割分担がはっきりする」という点を挙げたが、逆に「それがデメリットになることもある」とも付け加える。境界がある程度はっきりしてしまうと、情報やインプットなどの受け渡しにそれなりのマンパワーが必要になってくるためだ。 　また、社員に関することとして、例えばテストベンダーがさまざまなテストを行うなかで「そのノウハウをどうやって社員に蓄積していくか。それがとても重要です」と櫻井氏は続ける。テストベンダーに任せることが通常ルーチンになってくると「社員の役割が薄まり、育成がなかなか進まないという現状があります」という認識を示した。逆井も「それぞれが持つノウハウをどう標準化し、どう共有するかというテーマはある」と同意した。 　最後に、櫻井氏は「アダストリアとバルテスの今後の展望」について次のように述べた。 「バルテスとのこれまでの関係性の継続を踏まえつつ、今後はサービスの品質向上外部のプロ目線で一緒にもう一段上げてほしいと考えています。業務効率の改善などにもチャレンジし、開発全体の生産性を上げるような取り組みを一緒に進めていきたいです。また、バルテスに蓄積されたアダストリアのノウハウをオープンにしてもらうことで、当社の社員を育成するような存在にもなってもらいたいと考えます」（櫻井氏） 　これに対して逆井は、バルテスが既存のテスト支援からさらに一歩踏み出すような取り組みとして、マネジメントのノウハウなどを「いかにして社員にフィードバックできるかを考えていくこと」を提案。最終的には、組織の成熟として内製化が進むような状態を作ることが、バルテスのミッションの「プラスワンだと考えている」と櫻井氏の要望に応えた。 >>レポート資料のダウンロードはこちら VALTES QUALITY DAYでは品質向上に力を入れる各社をゲストに迎え、その取り組みを伺った。各セッションのレポートは 特設サイト に掲載している。 （所属・役職は2024年5月時点のものです） The post 【VALTES QUALITY Dayセッションレポート】アパレル企業のDXにおける品質戦略 first appeared on VALTES テストサービス .

2024年5月29日、「VALTES QUALITY DAY」が開催された。JR東日本情報システム（以下、JEIS）とバルテス社員による対談セッションは「交通インフラの未来への道　サービス拡大と品質向上に向けた取り組み」がテーマ。JR東日本のシステム品質を守るJEISの挑戦に迫った。 JEISからは吉川眞之氏、石井耕司氏が登壇。バルテスからは角田誠、林和生が登壇した。司会進行は石原一宏が務めた。 登壇者紹介 右から株式会社JR東日本情報システム取締役 Suica・駅サービスソリューション本部長 駅サービスシステム部長 吉川 眞之氏 株式会社JR東日本情報システム Suica・駅サービスソリューション本部 駅サービスシステム部 インターネット開発PJ マネージャー 石井 耕司氏 バルテス株式会社 取締役 角田 誠 バルテス株式会社 エンタープライズ品質サービス事業部 クロスソリューション部 副部長 林 和生 バルテス・ホールディングス株式会社 品質ビジネスイノベーション部 部長 石原 一宏 （所属・役職は2024年5月時点のものです） 「シームレスな移動の実現」で鍵を握るえきねっと 　その名の通り、JEISはJR東日本の情報システム子会社であり、Suica・駅サービスソリューション本部を含む5つの事業本部で構成されている。Suica・駅サービスソリューション本部は主にJR東日本の旧販売系システム、そして最近ではMaaSなどを手がける部署と密接に連携した事業やシステム構築を行なう。 　現在、JR東日本グループではグループ経営ビジョン「変革2027」を掲げ、大きな変革のの1つとして「シームレスな移動の実現」に力を入れている。吉川氏はその狙いを次のように語る。 　「コロナ禍を経て非接触サービスが主流になり、“いかにお客様に快適かつシームレスに移動していただくか”がサービス戦略の核になりました。ここではSuicaのような媒体を中心に、鉄道利用に限らず、駅構内での物品やサービス購入、タクシーなどの二次交通、ホテルの宿泊などをすべてシームレスにつなげていきたいと考えています」（吉川氏） 　シームレスな移動の鍵を握るのは、2001年から開始したWebサービスの「えきねっと」である。吉川氏が「窓口に並んで切符を購入することが不便だとの声に応えて誕生しました」と語るえきねっとは、時代のニーズとともにサービスを拡大してきた。（ 参考：JR東日本グループ経営ビジョン 変革2027 ） 　「最近ではえきねっとでもチケットレスが普及し、切符を持たずにICカードで改札を通過できるようになりました。将来的には新幹線や在来線の特別列車だけではなく、ローカル線も含めてJR管内の各鉄道をチケットレスでシームレスに移動できるようにしたい。さらにさまざまな乗車サービスや利用シーンとの連携を視野に入れ、ますます進化を遂げていく必要があります。そのためのシステム開発、品質の維持が我々にとって最大のテーマになっています」（吉川氏） 　続いて石井氏が、えきねっとシステムの状況と課題を説明した。石井氏によれば、現在のえきねっとはシステムの重要性、複雑性が増しているという。 　「まず重要性についてですが、旧来のみどりの窓口からWebやアプリへと購入手段が移行し、利用率が非常に高まっています。お客様にとっても当たり前のサービスになったことでシステムの重要性が増し、求められる品質レベルが上がってきています。 　複雑性については、パターンが無数に存在することが要因に挙げられます。サイト、予約種別、予約形態、乗り継ぎ、列車種別、券種、席種、申し込み人数、決済方法、各種割引などが複雑に交差し、ここに乗車変更や払い戻しなどが加わるなどしてすべての要素が掛け算になるのです」（石井氏） えきねっとシステムの課題となっているシステムの複雑性 効果的なテストで網羅性を高めながら品質向上に成功 　複雑な購入パターンを網羅し、高い品質を保つためには専門的なテストが不可欠となる。しかしJEISでは重要化、複雑化するテスト工程を自社人材だけでは補うことができず、ソフトウェアテスト専門会社であるバルテスに依頼。プロジェクトリーダーを窓口としてJEIS側の管理工数を最小限にしつつ、品質を高めながら工程を進捗する体制を構築した。 　専門家を入れたことで、テストの結果はポジティブなものになった。JEISからはえきねっとに関する業務知識を、バルテスからはテストメソッドを持ち寄り、綿密な打ち合わせを重ねながら網羅的なテストパターンを作成した。 　「バルテスとの継続的なパートナーシップにより、1.案件ごとにえきねっとシステムのテストノウハウを積み上げることによる効果的なテストの実施、2.テストノウハウを資産とし、新規参画者のハードルを下げることによる業務の波動への対応で効果を上げることができました。今後もノウハウを蓄積し、過去案件のテストデータも取り込んでいくことで、より効果的・効率的なテストを行なっていく予定です」（石井氏） バルテスとの協業であげた効果 　バルテスは2018年度からJEISの支援を開始。総合テスト支援に始まり、段階的にサポート範囲を拡大してきた。バルテスの林は「これまでの5年間でポイントは3つ。1つ目はテスト構造設計の導入、2つ目は品質管理支援（QMO支援）、3つ目はテスト管理ツールの導入です」と語った。 　1つ目のテスト構造設計の導入では、段階的にテスト設計を進めることでテスト全体を見える化。これによりテスト観点の抜け漏れや重複を防止した。また、因子水準表や組み合わせテスト技法を用いて漏れなく最小限にしたことで、網羅性を高めながら品質向上に貢献できたという。 　2つ目の品質管理支援は2022年度と2023年度で対応。品質をモニタリングして報告することで継続的な改善を推進した。3つ目のテスト管理ツールの導入はテスト実施管理の効率化やテストケースの資産化が目的であり、大量のテストケースの管理とテスト状況の見える化に役立った。そのうえで林は「今後はテスト自動化や上流工程からの支援など、えきねっとシステムに関する支援範囲を拡大していきたい」と語った。 2018年度から始まった支援と今後の予定 コミュニケーションを取り、一体感を持って進めることを意識 　セッションの後半は、石原が質問形式で進めるディスカッションを実施。最初の質問は「業務知識とテストメソッドを現場のテストに落とし込む際に何が重要だったか」というものだ。 業務知識とテストメソッドの落とし込み 　石井氏は「今回はお互いの知恵を持ち寄ることから始まったので、密接にコミュニケーションを取って一体感を持って進めることを意識しました。具体的には早めに成果物を作り、何段階にも分けて打ち合わせを重ねました」と振り返った。 　林は「我々にはテスト技法の技術的なベースがありますが、業務知識が皆無ではコミュニケーションが取れません。ですからテストパターンに落とし込む際は機械的な組み合わせではなく、システムや業務への影響度などを踏まえ、どんなテストが重要なのかを考えながら進めました」と語った。 　次は「5年間を振り返っての感想」を聞いた。これに関しては、マネージメントの立場から吉川氏、角田がそれぞれ次のように答えた。 　「この取り組みでは、網羅性と効率性の二律背反をどのように実現するかがポイントになります。網羅性の観点では、我々や各種ベンダーは経験が長いため、自分たちの目線で優先順位を決めてしまう傾向があります。それゆえに偏りがあったり、無駄なパターンが重複したりすることがあるのも事実です。 　一方でバルテスは業務知識がないところから入ってきているので、ニュートラルな視点で“効率的にどこをつぶせばいいのか”を判断できました。逆に大事な部分が抜け落ちていることもありましたが、そこに関してはお互いのコミュニケーションを通じて優先順位をつけたり、重要度を入れ替えたりしてきました。そのアプローチが上手く行ったのだと思います」（吉川氏） 　「お互いが違うところを見ていたり、解像度が違ったりするとどうしてもズレが生じてしまいます。だからこそ弊社ではISO29119（ソフトウェアテストの標準規格）に基づいた体験にきちんと落とし込んでドキュメント化をしています。わかりやすく、ズームイン、ズームアウトができる状態のドキュメントをお互いに参考にしながらコミュニケーションを取るようにしているのです。今回のようなプロジェクトでは、きちんとしたドキュメントを作ることが共通理解には必要だと思います」（角田） 　ここまでのやり取りを見ればわかるように、肝は“コミュニケーション”に代表される人間力にある。事実、JEISに刺さったのは技術面だけではない。印象的なエピソードを問われると「テスト現場の活発な意見のやり取りを見て“試験愛”“システム愛”を感じることができました」（吉川氏）、「ベンダーやクライアントとの打ち合わせにも入ってもらうなど、最初から懐に入り込んでくれました」（石井氏）と、それぞれがバルテス社員のマインドセットを高く評価した。 　最後の質問は「お互いのビジネスの方向性や思いについて」。 　吉川氏は「将来的には、リアルの窓口で取り扱う業務をすべてシステムに置き換えたい。高い利便性を担保しながら効率的に商品を販売するシステムは極めて難しいものですが、チャレンジしていかないと価値を生み出せません。今後もより新しいことに取り組んでいきます」と展望を述べた。 　角田は「世の中のシステムはどんどん複雑化していますが、我々はいかにそれらをわかりやすく要約するかを考えていきたい。ツールやAIなどのテクノロジーを利用して、全体の底上げを図ることも視野に入れています」と結んだ。 >>レポート資料のダウンロードはこちら VALTES QUALITY DAYでは品質向上に力を入れる各社をゲストに迎え、その取り組みを伺った。各セッションのレポートは 特設サイト に掲載している。 （所属・役職は2024年5月時点のものです） The post 【VALTES QUALITY Dayセッションレポート】交通インフラの未来への道　サービス拡大と品質向上に向けた取り組み first appeared on VALTES テストサービス .

　2024年5月29日、「VALTES QUALITY DAY」が開催された。以下、GOとバルテス社員による対談セッションの様子を紹介する。 本セッションは「品質とスピードを両立し、ビジネスをドライブさせる！ GO株式会社のQA組織とは」がテーマ。ゲストにGO株式会社 澤田雄一氏、同社 丸靖和氏を迎え、バルテス 貝本康次が司会進行を務めながらGO社のQA組織が取り組む「効率化のためのプロセス見直し・改善」を掘り下げた。 登壇者紹介 右からGO株式会社 プロダクトマネジメント本部 クオリティマネジメント部 部長 澤田 雄一 氏 GO株式会社 プロダクトマネジメント本部 クオリティマネジメント部 クオリティマネジメント2グループ グループマネージャー 丸 靖和 氏 バルテス株式会社 Web・IoT品質サービス事業部　Webサービスソリューション部 副部長 貝本 康次 その都度課題を洗い出し、効率化のための改善ネタを集約 GOではさまざまな交通課題に対し、ITを駆使して多様なサービスを展開している。主なプロダクトにはタクシーアプリ『GO』、モビリティ領域における脱炭素化を推進する『GX（グリーントランスフォーメーション）』、交通事故削減支援サービスの次世代AIドラレコ『DRIVE CHART』の3つがある。澤田氏は「タクシー産業の課題解決を起点に、交通・社会課題の解決を目指すことが最大のミッション」と話す。 澤田氏、丸氏が所属するクオリティマネジメント部では、「プロダクト品質の信頼性評価」「欠陥の作り込み防止」「意思決定・成長／改善のための分析・情報提供」を3本柱とする。全プロダクト開発における品質を管理・評価する専門家集団であり、開発部門から独立することでより良いサービスの提供に集中できるのが特徴だ。 2020年4月にJapanTaxiとDeNAの『MOV』、『DRIVE CHART』事業が統合して以降、QA（品質保証）組織は導入期、成長期、強化期のステップを踏んできたが、わずか2年で強化期に到達した。 QA組織の成長過程 貝本が「統合の混乱もあったはずなのに、2年で強化期に入っているのは驚異的なのでは？」と問いかけると、丸氏は「文化や仕事の進め方の違いはありましたが、1つのゴールに向かって皆が協力したことが短期間で成長した要因だと思います」と語った。ちなみにバルテスでは導入期から成長期に至る時期にテストの支援に加え、ナレッジベースの作成とブラッシュアップを繰り返し行なってきた。現在もこのナレッジベースはクオリティマネジメント部以外の部署も含めて新メンバーのオンボーディング資料などに活用されている。 QA組織では効率化のためのプロセス見直し・改善を推進している。今回は継続的なプロセス改善スキーム、リグレッションテストの見直し、データドリブンの3つを紹介した。 最初の継続的なプロセス改善スキームに関しては、そのつど課題を洗い出して集約し、効率アップにつなげる各種施策の検討、アクションを実施する。改善ネタはテスト設計・実施の生産性向上や工数削減、管理業務の効率向上、コミュニケーションコスト削減、スイッチングコスト削減など多岐にわたり、「単純に前に進むだけではなく、取り組んだ中で廃止したほうがいい、見直したほうがいいことも含めて考えながら日々対応しています」と丸氏は説明する。 一般的に改善ネタを社内から収集しようとしても出てこないことが多い。しかし、「めんどくさいリスト」と言い方を変えるだけで業務に対する困りごとが出てくるようになったという。この取り組みはQAに限らず、プロダクトマネージャー、デザイナー、開発エンジニアなど多方面から意見を求めている。 継続的なプロセス改善スキームの概要 丸氏は「間違ったことをやっていなくても、どうしても従来の手法に固執してしまうことがあります。なので新メンバーの意見も踏まえながら、いろんな視点を採り入れるようにしています」と語る。また澤田氏は「仮に実現できなくてもいいから言ってほしいと投げかけると、たくさんの意見が出てくるようになります。ヒアリングする側にも工夫が必要です」と秘訣を語った。 次のリグレッションテストの見直しについては、機材構成や機能の増加に伴いテスト項目が肥大化したことが契機となった。当初は時間に追われ、機能テストから単純に抜粋して作ることを繰り返していたためだ。「そこでバルテスのメンバーが中心となって機能ごとに分類していただきました。それにより、選定作業の負荷軽減、網羅性の確認のしやすさにつながり、リグレッションテストを見直すことができました」と丸氏は振り返る。 このときに行なった分類方法は、バルテスの体系的なテストドキュメント「Quintee（クインティー）」の考え方を応用して適用することで、実現させることができた。 3つ目のデータドリブンの取り組みでは、すべての業務工数、テスト活動の情報をGoogleスプレッドシートに記入し、GoogleのBigQuery（ビッグクエリ）に蓄積。分析活動を通じて業務改善につなげたいとする。データの集約はできつつあるが、分析はまだ十分にできていないとのことで、GO社では引き続きチャレンジしていく予定だ。 独自開発したツールで工数やコストを大幅に削減 　そこからさらにブレイクダウンし、独自開発した代表的な業務効率ツールについて触れた。その内容は、不具合管理ツール、テスト項目書自動作成ツール、案件管理表、工数管理文脈（作業時間記録）、開発制限事項自動管理ツール、テスト自動化のテスト結果自動管理ツールの6ツールである。 セッションで紹介した6つの業務効率ツール 不具合管理ツールは、Jiraによる管理の煩雑さを解消するために開発した。不具合チケット管理に使用しているJiraの情報をGoogleスプレッドシートに自動出力することで不具合状況をリアルタイムで分析。さらに担当チケット／進捗状況などの各種情報をSlackへ通知してチケットの確認漏れを防止し、業務負荷を軽減している。 テスト項目書自動作成ツールは因子水準表からテスト項目書を自動出力。テストツールのPictMasterなどでは対応できない付随情報の反映にも自動で対応し、テスト項目書を毎回作る手間を削減した。 案件管理表は資料格納先となるGoogleドライブ内でのフォルダ作成、各種テンプレートファイルのコピーを実施するツールであり、テスト準備工数の大幅な削減を実現した。 工数管理文脈（作業時間記録）は先に触れたデータドリブンの取り組みの一環だ。メンバー全員がテスト業務だけでなく、各種ミーティングへの参加工数など日々の作業時間をすべて入力することで、業務効率化の分析へとつなげる。 開発制限事項自動管理は、あるメンバーからの提案が起点となった。テスト開始時は機能がまだ実装できておらず、バグがあるなどの理由で開発制限事項が発生する。それを試験表や項目書に反映してブロックをかける作業は非常に工数がかかるうえに、反映漏れや解除漏れなどが発生してしまうことが悩みのタネとなっていた。 そこでGoogleスプレッドシート、Google Apps Script、Asana、Slackを連携して開発制限事項の管理を自動化。開発制限事項の転記作業工数、制限事項に関わるテスト関係者のコミュニケーションコストなどを大きく削減することに成功した。 さまざまな工数・コスト削減に寄与した開発制限事項自動管理 最後のテスト自動化のテスト結果自動管理は、テスト結果を横断的に分析できない状態を打破するために開発した。テスト自動化ツールベンダーが提供しているAPIを活用し、Googleスプレッドシートに自動でテスト結果を取り込む仕組みを構築。テスト実行後のリザルト一覧の自動集計、リザルト一覧からの詳細なテスト結果レポートの自動生成を可能にした。 講演の様子。左から貝本、丸氏、澤田氏 組織に縛られず関係者を巻き込んで、“品質とスピードの両立”に挑戦していく 　QA組織は上流工程の取り組みにも積極的だ。その思いを澤田氏はこのように語る。 「QAはテストだけが仕事ではありません。上流工程にどれだけ貢献できるかもポイントです。PRD（プロダクト要求仕様書）、デザイン作成段階でのインスペクションレビューをはじめ、ビジネス領域における要件の議論段階までQAエンジニアが入り込み、上流工程からの品質向上に向けた活動を実施中です」（澤田氏） ただし、これらの活動はそれぞれのステークホルダーに対する地道な信頼の積み重ねにより実現できたものだ。インスペクションレビューに関しても開始までには1年半ほどかかっているそうで、澤田氏は「QAエンジニアがビジネス領域で関わっていくのは難しい面が多々ある」と感想を漏らす。その反面、確かな手応えも感じている。 「ヒアリングしたことによって、テスト設計をするときに『ビジネス側はこういう機能を求めているからこういうテストをしよう』という発想が出てきます。その結果、テストの質が向上する。やはり上流からQAが入ってくることは品質向上につながると考えています。また、定量的な分析によってQAエンジニアが上流工程に関わる効果を各ステークホルダーに共有することも重要です。分析結果から上流工程でのプロセス改善にも役立てることができるからです。これもデータドリブン活動の1つと言えるでしょう」（澤田氏） 最後に丸氏は、今後の展望について次のように述べた。 「GOのQAエンジニアは開発からQA工程での出力向上のためにワーキンググループを定期的に開催し、めんどくさいリストを導入して関係者を巻き込みながら常に改善のきっかけを探っています。各部署とフラットに会話できる環境が整っているのが我々の強み。関係者と協力して、これからも『品質とスピードの両立』にチャレンジしていきます」（丸氏） 品質とスピードの両立に向けてQAがハブとなって関係者を巻き込んでいく >>レポート資料のダウンロードはこちら VALTES QUALITY DAYでは品質向上に力を入れる各社をゲストに迎え、その取り組みを伺った。各セッションのレポートは 特設サイト に掲載している。 （所属・役職は2024年5月時点のものです） The post 【VALTES QUALITY Dayセッションレポート】品質とスピードを両立し、ビジネスをドライブさせる！GO株式会社のQA組織とは first appeared on VALTES テストサービス .

2024年5月29日、「VALTES QUALITY DAY」が開催された。 オムロンとバルテス社員による対談セッションは「オムロンの目指す企画・営業まで巻き込む、アジャイル開発の品質保証」がテーマ。ゲストにオムロン松本光博氏を迎え、バルテス田中慶之とディスカッションを行なった。 登壇者紹介 オムロン株式会社 データソリューション事業本部 自立支援事業部 商品・技術開発グループリーダー 松本 光博氏 バルテス株式会社 品質マネジメントサービス事業部 エンタープライズ品質マネジメント部 リーダー 田中 慶之 五月雨の要求を受け止めるために高速アジャイル開発を採用 オムロンでは介護領域における自立支援ソリューション事業を展開している。本ソリューションの中心は、介護現場で働く専門職による分析やノウハウをシステム化したものである。具体的には、専門職が高齢者にヒアリングとアセスメントを実施して高齢者の生活行為を工程分析。これをもとに生活課題や阻害要因を抽出し、その人に適した介護支援、目標設定を行なう。また、文章作成支援機能によって専門職の負担軽減にも貢献する。バルテスはテストチームとして参画した。 オムロンが開発した自立支援ソリューションのICTシステム 本プロジェクトでは介護の専門職のみならず、オムロンの営業や企画の意見をその都度、採用しながら反映させてきたという。まずはこの特異な点について松本氏が解説した。 「自立支援ソリューションは新規事業開発モデル事業の一環で、介護現場に営業や企画の人間が張りついて一緒に解決法を探ったり、施策を重ねたりしながら進めてきました。こうした背景からやりたいことが変わることがたびたびあり、五月雨でやってくる要求に答え続けないとゴールにたどり着けない状態でした。そのため、一般的なアジャイル開発のスプリントによるアプローチでは開発を進められないという課題がありました」（松本氏） そこで採用したのが高速アジャイル開発だ。要件定義、設計、設計レビュー、実装、実装レビュー、デバッグ、テストがひと塊になって進行するイメージとなる。 「今回のプロジェクトの特徴は営業、企画、開発、テストチームが並走して取り組まないとプロダクトが作れなかったことです。一般的なアジャイル開発では1週間、1カ月などの単位でスプリントが進行し、テストとデバッグは工程が分けられています。通常であればバルテスはその段階で参画するわけですが、開発メンバーを集めたタイミングでテストチームを招集しました。なぜなら、我々自身がドメイン知識を学びながら、試作を作って確認するステップを何度も繰り返してきたからです」（松本氏） 本プロジェクトで採用した高速アジャイル開発の概念図 招集当初からテストチームのメンバーに介護業界の教科書的な書籍を渡して読み込んでもらうなど、本プロジェクトならではの方法も適用した。チームが一丸となり、一気通貫でドメイン知識を深めることが重要だったためだ。 「立ち返ったのは『アジャイルソフトウェア開発宣言』（2001年）です。アジャイル開発はフレームワークが注目されがちですが、アジャイルソフトウェア開発宣言にまとめられているのはスローガンそのものです。骨子は対話と協調、変化への対応、動くソフトウェアといったシンプルなもの。ですから営業、企画、開発のメンバーはテストチームの意見を真摯に受け止め、テストチームも営業、企画、開発の意見を尊重するといったように、お互いが対話と協調をもとに一緒にプロダクトを作る環境を基本としました」（松本氏） テストチームが上流工程から伴走、次々とアイデアを出す この言葉通り、バルテスのテストチームは開発の上流工程から伴走。「アジャイルソフトウェア開発宣言の骨子を愚直に実現し、要求仕様、UI資料、実機を高速かつ多角的に検証しました」と田中は振り返る。 先に述べたように、介護現場で直接やり取りする営業や企画からは五月雨で新規のアイデアや改善案が舞い込み、機能実装のリクエストが絶えない状況だったが、度重なる要件変更にも柔軟に対応した。 「仕様検討の段階でテストチームが仕様を一旦読み込んだり、実機で試す際にUIの部分で詳細に確認したりしてフィードバックを返してもらいました。常に情報を共有しているので『ここはどう動くのか』『このボタンはこういう動きでいいのか』といった意見がテストチームからも出てきて、それが上流の要件定義に反映されるのが開発プロセスの日常でした。商用で正しく高品質なプロダクトを作るには、バルテスのノウハウが不可欠。それを活用して高速アジャイル開発を成功させました」（松本氏） こうした伴走型の検証を「探索的テスト・仕様整理」と名づけ、テストチームはユーザーの立場に立った使い方やシステム構築などについて積極的に案を出した。田中は「毎週金曜日に定例会議を開き、しっかりとコミュニケーションを取る場合は週に2回ミーティングを開催。必要に応じて臨時の打ち合わせも実施しました。定例会議では松本様と対話を重ねながらいろんなチャレンジをさせていただきました」と語る。 全チームが共同で要件定義を行なうのが特徴 例えばFigmaで作成された図案をもとにUI／UX仕様書をテストチームで作成。それによりさらなる仕様理解の浸透に努めた。「我々が画面設計書を作りますと立候補して、それが結果的にインプットや早期のフィードバックにつながったと考えています」と田中は語る。松本氏も、これらスピード感のある手法が上手くハマったと評価する。 オープンな場を作れたことが最も大きな成功要因 田中は本活動におけるメリット、デメリットを開発チーム、テストチーム双方の視点からまとめた。開発チームのメリットとしては「仕様バグ・漏れの早期発見（品質の向上）」「UI／UXの妥当性が評価できる（品質の向上）」「仕様書作成分の工数を開発に注力できる（コスト削減）」の3つ、テストチームのメリットには、「仕様の早期把握による時間コスト削減」「仕様整理のアウトプットがテスト設計のインプットとなる（精度の高いテスト設計が可能）」の2つを挙げた。 一方のデメリットについては、開発チームが「開発人員が古い思想だと指示待ちになってしまう」「『変化への対応』によって優先度が低いタスクを諦める必要がある」「スケジュールを次々と組み替えるため、チーム間のコミュニケーションに多くの時間を取る必要がある」の3つ、テストチームが「カバー範囲が拡がったことにより、ドメイン知識の習得が必須になってしまう」の2つを挙げた。そのうえで田中は、今回の学びについてこのように触れた。 「テストチームの観点で言えば、前段階で仕様やUIを煮詰めたものに対してテスト設計を行なうので、非常に精度が高いものができあがるのが大きなメリットです。ただし、単純にテストの知識があればいいというわけではありません。介護業界に限らず、厚生労働省の仕組みなどもしっかり頭に入れて設計する必要があったため、人員のアサインも含めて、そこが一番難しいと感じました」（田中） 松本氏は「デメリットよりも遥かにメリットのほうが大きい。デメリットは課題と認識してリスクヘッジすることでカバーできるのに対し、メリットは失われるわけではないからです。表面化したデメリットに関してはおおよそリスクヘッジできたこともあり、今回のプロジェクトは成功したのだと思います」と手応えを見せた。 最後に田中は、「今回のケースをすべてのプロジェクトに当てはめることは難しいですが、開発チームとテストチームのあり方の成功例の1つとして紹介したい」と前置きして成功させる4つのポイントを披露した。 チーム全体が融合して成功させるための4つのポイント これを受け松本氏は、次のように結びの言葉を述べた。 「この4つのポイントは確かに必須ですが、結局は発注側、受注側という立場を超えて、“1つの目標に向かう一緒のチーム”との意識を持つことが最も重要だと考えます。私自身、それぞれの立場を超えて協力し合い、コミュニケーションを重視した環境を作ることが大事だと改めて感じました。 このポイントで言えば4番目はよくあるケースです。おかしいと思っていても言えないことは多々ありますから。でも疑問をすぐに相談できたり、議論できたりすれば、失敗する確率を減らすことができます。その空気を醸成できなければ、どれだけ緻密なプロセスを計画しても検知されたリスクが判断されず、放置されて瓦解することが起こり得ます。しかし今回はそうした問題をクリアしつつ、なおかつ次々と出てくる要求に対して対処することができました。やはり、オープンな場を作れたことが最も大きな成功要因だと捉えています」（松本氏） >>レポート資料のダウンロードはこちら VALTES QUALITY DAYでは品質向上に力を入れる各社をゲストに迎え、その取り組みを伺った。各セッションのレポートは 特設サイト に掲載している。 （所属・役職は2024年5月時点のものです） The post 【VALTES QUALITY Dayセッションレポート】オムロンの目指す企画・営業まで巻き込む、アジャイル開発の品質保証 first appeared on VALTES テストサービス .

　バルテスが主催するカンファレンスイベント「VALTES QUALITY DAY ～DX/AI時代における品質向上の価値～」が、2024年5月29日に開催された。 　本セッションでは、「テスト自動化による品質保証の高次化」と題してTISの胡居悦朗氏と、バルテスの畠山塁が対談を実施。TISのクレジットカード部門における品質確保、特にテストの自動化に焦点を当て、その取り組みや品質向上について語り合った。 登壇者紹介 右から、TIS株式会社 デジタルイノベーション事業本部 ペイメントサービス事業部  ペイメントサービス第2部 エキスパート 胡居 悦朗氏 バルテス株式会社 エンタープライズ品質サービス事業部 金融ソリューション部 副部長 畠山 塁 T-DASHの特長がテスト自動化導入・定着における課題を解決 　国内大手のシステムインテグレーターであるTISにおいて、ペイメントサービス事業部はキャッシュレスに代表されるような「市場の生活に寄与するサービス」などを展開する部署となる。 　胡居氏が所属するペイメントサービス第2部では金融／信販系やクレジットカード業務を取り扱う企業が顧客の中心となっており、エンドユーザーや顧客企業が利用するWebサイトの開発から保守までを幅広く行っている。また、通常開発と並行して組織変革の施策なども担っており、その一環として「テストの自動化」にも取り組んできた。テストの自動化を推進するに至った背景について胡居氏は「ペイメントサービス第2部のお客様は、その多くがクレジットカードなどのサービスを提供しており“品質に対する要求が高い”ことが特徴です。そのため、我々は入念なテストや点検を行うことで、安心して利用してもらえるサービスの提供に日々励んでいます」と語った。 　しかし、テストのための人手は案件の規模が大きくなるほど増加する傾向にあり、人手が増えればミスや漏れが生じるリスクも増大するというジレンマがあった。胡居氏自身も、人的ミスによりテストをやり直す場面を「何度も経験してきた」と吐露する。加えて、昨今は業界全体でエンジニアが不足しているため、人手に頼る現在のやり方では近い将来限界が訪れる。このような背景から、胡居氏は「機械でテストを行っても、きちんと品質を確保できるような新しい取り組み」の模索を行っていた。 　テストの自動化のメリットとして、胡居氏は代表的な3つを挙げた。1つ目は、人間が別の作業に時間を使えるようになる「人的時間削減」である。2つ目は、機械実行ならではの特徴である“正確性”や“定型化”にともない、人が見るべき（あるいは判断すべき）ポイントを限定化・明確化できることで得られる「検証効率の向上」。そして3つ目は、何度実行してもミスなく同じ操作を期待できる「再現性の高さ」である。 「テスト工程では、テストデータの入れ直しやアプリの修正などによって何度もテストをやり直す場面がありますが、人の手で作業を行う場合はどうしてもその回数分だけ、ミスや漏れが発生するリスクを抱えることになります。しかしながら、機械実行であればそのリスクを削減することができます」と胡居氏は補足する。 　一方で、テスト自動化には使い続けるという点で課題が起きやすく「従来から進めていたテスト自動化の取り組みでは、なかなか定着までに至らないという悩みがありました」と胡居氏は語る。 　例えば、ブラウザベースで動くWebアプリケーションの自動テストでは、Seleniumと呼ばれるライブラリ言語を用いて自動スクリプトを生成してテストを自動化するという取り組みがあった。しかしこのケースでは、2つの大きな問題が生じた。1つは、“テストの実施者”と“自動化のエンジニア”という目的の異なる2者がいたために認識の齟齬や勘違いが発生してテストが上手くできなかったという問題。そしてもう1つは、労力の観点でテストケース本体側の見直しが発生する度に、自動化スクリプト側も見直し実装修正を行わなければならないという問題である。 　この2つの問題により、一度は仕組みを作ったものの「形骸化につながってしまった」ばかりか、本来の目的である「品質確保のためのテストをきちんと実行できない」という結果になってしまったという。「自動化を試みたものの、定着には至りませんでした」と胡居氏は振り返る。 このような状況に頭を悩ませていたときに出会ったのが、 バルテスのテスト自動化ツール「T-DASH」 であった。 従来のテスト自動化における課題の概要 　T-DASHについて胡居氏がまず注目したのは、日本語でテストケースが記述でき、同時に自動化スクリプトが自動生成されること、またスクリプト部分が自動生成されるため、テスト実施側でのメンテナンスが不要という特徴だ。この2点については「まさに画期的」と高く評し、先ほど触れた定着化の妨げとなっている課題が「これで一気に解消される」と付け足した。さらに、その他の特徴として「主要ブラウザの動作保証」「操作結果確認のためのエビデンスキャプチャが自動取得される機能」も挙げた。 「（ペイメントサービス第2部が）解決したい課題」と「T-DASHの特長」との相関図 　これらの特長に魅力を感じ、ペイメントサービス第2部におけるT-DASH導入の検討を開始。あるプロジェクトで試験導入した際に“手動テスト”と“T-DASH”を比較したところ、「テスト実行＋エビデンス作成」の工程では手動テストが「33人日（1ケース：15分）」だったのに対してT-DASHは「4人日（1ケース：2分）」という結果に。さらに、最終的には「テストにかかる体力の40%削減が見込める」という成果を得ることができた。手動テストでの、ミスや漏れによるやり直しも含めて平均的に時間が増えている課題も、T-DASHの導入で改善され、「より高い生産性の効果につながっている」と胡居氏は補足する。 手動テストとT-DASHを比較した結果の概要 　バルテスは、2022年12月からテスト自動化導入支援をスタート。導入に当たっては実現可能性の調査を含んだソリューションとして提供しており、まずはSTEP1の「調査・検討」として「フィージビリティ・スタディ」（自動化の実現可能性調査）を実施。バルテスの畠山によれば、ペイメントサービス第2部の総合結果はA～Eの5段階評価で上から2番目の「B」で、「対象システム（Web）の自動化適合性は高い」「採算性を高めるためには、多くの実行が必要」という評価だったという。 　これを踏まえて、バルテスはSTEP2の「導入」でT-DASHによる自動化の実装を、STEP3の「運用」で分析・メンテナンスを支援した。胡居氏の重視していた「時間・工数の制約の中、人に頼らないやり方へ」「ヒューマンエラーを極力少なくし、品質を向上させる」といった点で成果が出ており、畠山は「その効果がTIS内でも注目され、自動化の広がりを見せている」との印象を語った。 バルテスが実施したフィージビリティ・スタディの結果の概要 　T-DASHの特長や実際に使ってみた感想を踏まえると、ブラウザベースのWebアプリを新規開発しているシステム開発会社はもちろんだが、「（開発のない）事業会社でも活用できる可能性はある」と胡居氏は提案する。例えば、ブラウザを使った業務処理に機械作業を導入したり、委託した開発会社からの納品物の確認（UAT等）に自動テストを導入したりすれば負荷を軽減できることから、T-DASHは「幅広く有効活用できるツールである」と評価した。 　最後に、胡居氏はペイメントサービス第2部の今後の取り組みとして2つのテーマを紹介した。1つは「テストの自動化スコープの拡張」で、ここまでに紹介したブラウザを用いるアプリケーションのテスト自動化は引き続き継続する一方で、今後はモバイルアプリケーション領域でのテスト自動化にも挑戦していく。もう1つは「テスト専門部隊による横断的なテスト推進」で、こちらではプロジェクト横断でテストを担える専門部隊を組成し、すべての顧客に均一かつ高水準な品質確保の実現を目指していく考えだ。そして胡居氏は、これらについても「バルテスの知見やアドバイスを取り入れながら具体化していきたい」との姿勢を示した。 小さく始まった取り組みが全社的な広がりに発展 　セッションの後半は、胡居氏と畠山がパネルディスカッションを実施。始めに畠山から「新しい取り組みの導入に、ハードルや障壁はありましたか？」と問うと、胡居氏は苦笑しながら「ありましたね」と回答。新しい取り組みの場合、得てして「実績はあるのか？」「根拠はあるのか？」と聞かれることが多いため、それらが何もない状況でも興味を持って話を聞いてもらうことが「最初にクリアしなければならないハードルだった」と続けた。 　そして、その解決策の1つとなったのが、偶然にも胡居氏自身が直接マネジメントするプロジェクトがあったことである。さらに胡居氏は、そのプロジェクトがまさにテストを始めようとしていたときにT-DASHの存在を知ったという「タイミングの良さ」や、バルテスのフィージビリティ・スタディによる実績作りを「上長が後押ししてくれた」ことにも触れ、それらが「取り組みを進める大きな一歩につながった」と説明した。 　これに対して畠山が「小さなプロジェクトから始めたテスト自動化を、さらに大きく推進していくにあたりどのようにして社内を巻き込んでいったのか？」を問うと、胡居氏は、すでに紹介した手動テストとT-DASHの比較を改めて引き合いに出し、「まずは比較分析と根拠づくりに全力投球することが重要」とした。 　さらに、それらを踏まえて次に考えたのが、T-DASHを「どうしたら社内に広めることができるか」だったという。これに対して胡居氏は、数ある要素のなかから「導入のしやすさ」にフォーカスし、導入までのプロセスやT-DASHの使い方に関する「社内向けのガイドライン」を策定。このガイドラインとこれまでの実績を携えて社内プレゼンを行ったところ、同じような課題に悩んでいた多くの部門が採用するに至ったほか、現在は社外のグループ会社にも話が広がっているという。これに加えて、社内の開発基盤を担当する部門からも声がかかったそうで、最終的に「活動内容を全社的に発信できるところまで発展している」と胸を張った。 　最後に畠山は、胡居氏が今後の取り組みとして挙げた「横断的なテスト推進」について、その取り組みの背景や今後の展望などを聞いた。 　ペイメントサービス第2部では開発とテストがそれぞれのプロジェクトごとに分かれている現状にあるが、胡居氏の狙いは「試験・点検をまとめて行うような部隊を組成することで、社内ナレッジのさらなる集約化・効率化をはかれる」ことや、「設定する品質基準を均一化するとともに、その基準をさらに押し上げることで全体の底上げにつなげる」ことにあるという。そこで、今後はそれらを目指すために「ガイドラインの策定」「テストの計画書のフォーマット定義」「テストの基本設計のやり方」などのナレッジの共有化を進め、「一本の“品質の柱”を構築できるような活動にしていきたい」と抱負を述べた。 >>レポート資料のダウンロードはこちら VALTES QUALITY DAYでは品質向上に力を入れる各社をゲストに迎え、その取り組みを伺った。各セッションのレポートは 特設サイト に掲載している。 （所属・役職は2024年5月時点のものです） The post 【VALTES QUALITY Dayセッションレポート】テスト自動化による品質保証の高次化 first appeared on VALTES テストサービス .

2024年3月19日に「事例で学ぶQA組織立ち上げの成功ポイント」というセミナーを、バルテス株式会社の主催で開催しました。今回はその講演内容のポイントについてご紹介します。 QA組織立ち上げ成功における3つのポイント 「複数プロジェクトに対して、横断的に品質を見られるようにしたい」 「開発負荷の軽減したい」 「不具合の市場流出を低減したい」 このような課題感を持って QA組織 を立ち上げたが、うまく機能しないといったお悩みを聞くことも増えてきました。ここからは、セミナー内容をもとにQAを立ち上げ、効果を出すうえでどのようなポイントがあるのか当社の支援事例からQA組織の立ち上げにおけるポイントを分析します。 1. QA組織の活動目的を明確にする QA組織を立ち上げる際、まずは活動目的を明確にしましょう。 品質確保にはコストがかかります。かけられるコストは有限なので、改善を続けるためにも費用対効果の高いパフォーマンスを出す必要があります。 しかし、品質保証の活動は、不具合を未然に防いでいる性質上効果が見えにくいのが課題となります。「QAチームの活動はどれだけ効果があるのだろう」という問いに答えるために、まず今直面している課題を明確にし、その課題解決ができているのかを計測できるようにしておくことが重要になります。 2. 顧客・利用者の理解のためのアプローチを行う 品質保証で重要となるのは、顧客理解の深化に向けたアプローチです。ソフトウェアの品質が良いというのは、バグがないことだけではありません。最終的にはシステムのユーザーがしたいこと（要求）が、システムにマッチしている状態です。 QAの効果を最大限に引き出すためには、製品がどのようにユーザーの問題を解決し、利便性を提供するかを意識する必要があります。最終的には仕様書に書かれた内容を超え、ユーザーの利用体験や、ビジネスの収益モデルの理解をするなどパースペクティブな視点を持つことでより良いQA活動が可能となります。 3. QA組織体制を強化する QA活動自体の強化活動も重要です。オンボーディングの仕組みを作り、組織として強くすること、要件定義などの上流からの参画や、ユーザーインタビューなど利用者やビジネスを理解するチャンスを増やすこと、QA活動を受ける一連のプロセスを整備することなどが挙げられます。 QAをリスタートした事例 ここからは、Webアプリケーションのアジャイル開発現場におけるQAチームの立て直し事例を見ながら、実際のQA現場でどのように組織を立ち上げ、効果を出していくのかを見てみましょう。 本事例では既存QAチームの活動に大きく3つの課題が発生していました。 これらの課題について、前述のQA組織立ち上げのポイントを元に当社が活動の改善を行ったポイントを解説します。 課題1 潜在問題を抽出できないままリリース 状況 リリースされる製品に潜在的な問題が残っており、ユーザー体験に悪影響を及ぼしていました。このため、リリース後のHotFix対応が頻繁に必要な状況となっていました。 行ったこと 不具合の市場流出を防ぐため、リリース前の各スプリント直前に、回帰テストを実施しました。そして、リリース前に不具合を事前に検出できる体制を整えました。 さらに不具合が検出されたテスト工程を記録し、どのテスト段階で問題が発生したか、その原因が要件定義、詳細設計、またはコーディングのどの部分にあるのかを詳細に分析しました。これにより、プロダクトの弱点を特定し、その部分に対する強化テストも行っています。 指標としてリリース前にデグレードを検出できた数と、リリース後のHotFixの件数を取ったところ、リリース後のデグレート不具合の件数が顕著に低下しており、QA活動の成果を分かりやすくステークホルダに説明できるものとなりました。 課題2 QAがあることで開発対応コストが増加 状況 QAが不具合を検出することで開発対応コストの増加を招いていると評価されている不健全な状態に陥っていました。原因を分析したところ、不具合レポートが改修目的を明確に示せていないことで、開発とQA間のコミュニケーションコストが増大していたことが分かりました。 行ったこと 対策として、不具合レポートのフォーマットを改善し不具合の現象と手順だけでなく、エンドユーザーが求める期待値と不具合が発生した場合の与える影響についても明記するように変更を行いました。 改善された不具合レポートにより、開発に改修の方向性が明確に伝わるため、差戻しが軽減され、コミュニケーションコストが抑えられました。また、エンドユーザーにとっての影響度という観点も含めたレポートにより、不具合修正の優先度も立てやすくなっています。 また、QAチームはシステムの構造を理解するための勉強会を実施し、API連携の仕組みなどを共有しました。 これにより不具合の原因特定までQAチームで行えるようになり、開発側の調査工数が短縮されました。 課題3　オンボーディングに時間がかかる 状況 関連資料が散在しており、仕様書が存在していない状態でした。これは新メンバーがプロジェクトに参加する際の課題となっていました。 行ったこと 開発チームが保有する仕様の不明点をQAチームが確認し、整理することでドキュメントの整理と共有化を行いました。整理された情報はConfluenceやNotion、GitHubのWikiなどのプラットフォームに集約し、プロダクトチーム全員がアクセス可能な形で共有しました。 集約された資料によってQA組織としてのプロセスや教育体制が整備されたほか、開発も含め新規メンバーのオンボーディングにかかる時間が短縮され、プロジェクト全体の効率が向上しました。 まとめ 本ウェビナーでは、QAを立ち上げたがうまく機能しないという現場でリスタートを成功させた事例をもとに、立ち上げのポイントや、実践例を見てきました。その他、QA立ち上げに際して考慮しておきたいチェックリストを作成しましたので是非併せて参考にしてください。 >>チェックリストのダウンロードはこちら バルテスでは、テスト専門会社としてのナレッジを元に QA立ち上げやリスタートのご支援 を行っています。もしQA組織の立ち上げや ソフトウェアテストのアウトソーシング にご関心があればぜひご相談ください。 The post QA組織を立ち上げる前に考えておきたいポイントとは？QAのリブートを担当した技術者が解説 first appeared on VALTES テストサービス .

2024年2月29日に、『「仕様書無し」「前任者不在」でドキュメントがないシステム開発現場の悩み リバースエンジニアリングを外注する前になすべきこと」』というセミナーを、バルテスグループでWeb/モバイル/XR開発を手掛けるバルテス・モバイルテクノロジー株式会社（VMT）の主催で開催しました。今回はその講演内容のポイントについてご紹介します。 本当にやるべきはリバースエンジニアリングなのか 本セミナーで取り上げた リバースエンジニアリング は、動くソフトウェアのコードや振る舞いから仕様書などのドキュメントを作ることを指しています。 「仕様書無し」「前任者不在」というシステム開発現場では動くソフトウェアしか頼れるものがなく「そこからドキュメントに落とし込めるならば」というご相談いただくことが多くなっています。 しかし、リバースエンジニアリングは上記のようなお悩みの現場で最適解と言えるのでしょうか。 多くの開発現場で直面する問題は、単にドキュメントの欠如だけではなく、その根底にあるシステムの設計や運用方法の課題に起因しています。例えば、システムの使い勝手が悪いからといってドキュメントを整備するだけでは、根本的な問題解決には至らない場合が往々にしてあります。 弊社では、ドキュメントを作成するためにリバースエンジニアリングを行うといった依頼を受けた際には、その背後にある本当の問題を明らかにし、解決策を模索して当たっています。 本講演では、リバースエンジニアリングによって業務が大幅に改善した例と、実はリバースエンジニアリング以外の方法が最適であった例を取り上げ、どのような場合に適しているのかを考察します。 さらに、弊社のリバースエンジニアリングの標準的な進め方もご紹介します。 解決の糸口は仕様書作成の他にある。ドキュメントでは解決しなかった事例 システム開発は、思い通りに進むとは限りません。たとえば、開発の途中で方向性が変わったり、思っていた以上に複雑なカスタマイズが必要になったりすることがあります。そんなとき、プロジェクトの進行を再検討しなければならないこともあります。今回ご紹介するのは、まさにそのような事例です。 ある企業様が開発中に悩みを抱えて、弊社にご相談を頂きました。 パッケージシステムのカスタマイズを行って作りかけているものの、現状で使い勝手が悪くどうにか改善したいというご相談です。 当初、ご担当者の念頭にあったのは、すでに半分作りかけているシステムがあるのだから、リバースエンジニアリングによって仕様の整理を行い、機能の整理や使い勝手の改善をしていこうというものでした。 このような状況でリバースエンジニアリングというご相談を受けたのですが、弊社はまず、お客様の要件を徹底的にヒアリングしました。その結果、リバースエンジニアリングでドキュメントを整備するよりも、新しい視点からシステムを見直すことが重要であることが分かりました。 具体的には、現行の使い勝手の悪いシステムに基づく設計書を起こして、そこからまた新しい設計を考えた場合、大変非効率であることが予想されたため、改めて必要な機能を持つシステムをゼロから設計するアプローチのほうが、コストやスケジュールを試算すると効率的であると考えられたのです。 結果、企業様は新しいシステムの設計と開発に着手し、以前よりも使い勝手の良いシステムを構築することができました。この事例は、ドキュメント整備だけに頼るのではなく、根本的な問題解決のためにシステム全体を見直すことの重要性を示しています。 このようなアプローチにより、弊社は企業様の本来の問題を解決し、最終的に満足のいく結果を提供することができました。システム開発においては、常に柔軟な対応と深い理解が求められることを改めて実感させられた事例です。 リバースエンジニアリングが適しているのはどんな時かを考える 次に、ドキュメント整備が必要だった事例を取り上げ、リバースエンジニアリングが適しているのはどんな時かを考えてみたいと思います。 リバースエンジニアリングは、特定の状況下で非常に効果的です。特に、ドキュメントが整備されていないシステムのメンテナンスや改修において、その真価を発揮します。例えば、ある企業の情報システム部門でシステムが長期間にわたって運用されている場合、属人化が進行しがちです。つまり、システムの知識が特定の担当者に依存し、その担当者が異動や退職した場合、システムの運用が困難になることがあります。 ある企業では、長年にわたり一人の担当者がシステムを管理していたため、新しいメンバーがその担当者の知識を引き継ぐのが難しくなっていました。担当者の異動に伴い、システムの全体像や各画面の連携が不明確となり、新しい担当者がシステムを迅速に理解するのが困難でした。このような場合にリバースエンジニアリングを実施し、システムの画面遷移図や機能一覧、画面設計図、テーブル設計書を作成することで、システムの全体像が明確になり、属人化の問題が解消されました。 また、システムの保守性向上にもリバースエンジニアリングは有効です。不具合が発生した場合、その影響範囲を迅速に特定するのは難しいことがあります。しかし、適切なドキュメントが整備されていれば、不具合の影響範囲を迅速に切り分けることができ、問題解決がスムーズになります。例えば、あるWebアプリケーションシステムでは、保守運用フェーズにおいてデータの不整合による障害が頻発していました。データの不整合は、システムの使用中に発生する予期しないエラーや不具合の一因となります。この問題に対処するために、リバースエンジニアリングを用いてテーブル設計書やER図、画面遷移図を作成し、データの状態やシステム全体の構造を明確にしました。その結果、不具合の原因を迅速に特定し、問題解決までの時間を大幅に短縮することができました。 このように、リバースエンジニアリングを活用することで、システムの運用におけるさまざまな問題を解決することができます。ただし、すべてのドキュメントを網羅的に作成することはコストや時間の面で現実的ではありません。そのため、必要なドキュメントを厳選し、最も効果的なものだけを作成することが重要です。例えば、ある企業ではドキュメント整備の一環として、画面遷移図、機能一覧、テーブル設計書などの基本的なドキュメントを作成しました。これにより、システムの全体像を把握しやすくなり、不具合発生時の影響範囲の特定が迅速に行えるようになりました。 実際にリバースエンジニアリングを導入した企業の事例では、ドキュメントの整備によりシステム運用が大幅に改善されました。例えば、特定のWebアプリケーションシステムでは、リバースエンジニアリングを通じて作成されたドキュメントにより、データ不整合問題の発生頻度が減少し、システムの安定性が向上しました。また、属人化の問題も解消され、新しい担当者が迅速にシステムを理解し、運用に参加できるようになりました。このように、リバースエンジニアリングを適切に活用することで、システムの運用効率が向上し、企業全体のIT戦略に貢献することができます。 一方で、リバースエンジニアリングには一定のコストが伴います。ドキュメント作成に必要なリソースや時間を考慮し、全てのドキュメントを網羅的に作成するのではなく、目的に応じて必要なものだけを作成することが重要です。例えば、ある企業では、データ不整合の問題を解決するためにテーブル設計書とER図を作成し、システムの全体像を把握しやすくしました。また、画面遷移図や状態遷移図を作成することで、各機能の関係性やシステムの動作状況を明確にしました。このように、必要なドキュメントを厳選し、最も効果的なものだけを作成することで、リバースエンジニアリングの効果を最大限に引き出すことができます。 リバースエンジニアリングが適しているのは、システムの属人化が進行している場合や、不具合発生時の影響範囲を迅速に特定する必要がある場合です。また、システムの保守性を向上させるためにも有効です。適切なドキュメントを整備することで、システムの運用効率が向上し、企業全体のIT戦略に貢献することができます。企業の情報システム部門においては、リバースエンジニアリングを活用することで、システムの属人化を防止し、保守性を向上させるための有効な手段として検討する価値があります。 以上のように、リバースエンジニアリングは特定の状況下で非常に効果的な手法です。ドキュメント整備を通じてシステムの全体像を明確にし、属人化の問題や保守性の向上を図ることで、システムの運用効率を大幅に向上させることができます。企業の情報システム部門においては、リバースエンジニアリングを積極的に活用し、システムの安定運用と効率的な保守を実現することが求められます。 リバースエンジニアリングの成功を導く8つの手順 最後に、弊社VMTが考えるリバースエンジニアリングを成功させるための8つの手順を     紹介します。詳細は下記画像をご覧ください。 リバースエンジニアリングのプロセスは、単なるドキュメント作成ではなく、システム全体の理解と効果的なリソース管理を伴う複雑な作業です。最初に戻って考えることは、ドキュメント作成が本当に必要かどうか、他の解決策がないかを検討することです。その上で必要なドキュメントを絞り込み、体制を整えて効率的に進めることが、成功の鍵となります。8つの手順は、リバースエンジニアリングを成功させるための重要なガイドラインです。 8つの手順を解説したウェビナーを公開中 バルテスグループでは、リバースエンジニアリングを通じて、ソフトウェアの品質向上を図る様々な手法を提供しています。今回のセミナーで紹介した内容を参考にしていただき、具体的なご相談がある場合はお気軽にお問い合わせください。また、関連するセミナーのダイジェスト版も公開しておりますので、そちらもぜひご覧ください。リバースエンジニアリングを通じて、より良いシステムの構築に役立てていただければ幸いです。 The post リバースエンジニアリングは仕様書のない開発現場の特効薬となりえるのか？システム再構築の事例から見る”あるべき”手順とは first appeared on VALTES テストサービス .

ソフトウェアテストはソフトウェアの品質保証を行う重要な仕事です。しかし、それを行うテストエンジニアのスキルを証明するのは難しく、仕事を依頼する側にとって、本当に任せて大丈夫なのか？という判断は難しいといえます。テストエンジニアとして雇用して欲しい！と思っても、その人に本当にテストエンジニアとしてのスキルがあるか分からないと採用する会社としては躊躇します。また、ソフトウェア開発会社がテストはしっかりと行います！と顧客にアピールしても、顧客はそれを真に受けて良いかどうかを考えるでしょう。 そのため、公に認められているテストエンジニアの資格が必要です。資格を持っていれば、必要なスキルを持っている証明になります。資格を持っていない人と資格を持っている人であれば、当然、資格を持っている方を選ぶでしょう。とはいうものの、では実際にどんな資格を取得すればいいのか、資格取得のための学習はどうすれば良いのかと悩むでしょう。 本記事ではそんなお悩みをお持ちの方のために、テストエンジニアの資格の紹介と、その学習方法について紹介します。 テストエンジニアの３つ資格 代表的なテストエンジニアの資格として、以下の３つが挙げれられます。 ・ JSTQB認定テスト技術者資格 ・ JCSQEソフトウェア品質技術者認定資格 ・ IT検証技術者認定試験(IVEC) JSTQB認定テスト技術者資格は、国際的なソフトウェアテスト技術者認定組織であるISTQB（International Software Testing Qualifications Board）に加盟しているJSTQBが運営しています。 そのため、日本だけでなく世界で通用する資格といえます。選択解答式の試験で2006年から実施されており、比較的知名度の高い試験です。2023年現在では、CBT（コンピュータ・ベースド・テスティング）形式となっており、好きな時に受験できるのもメリットの一つです。 JCSQEソフトウェア品質技術者認定資格は、日本科学技術連盟が認定するソフトウェア品質向上のための資格制度です。 そのため、ソフトウェアテストのみではなく、ソフトウェア品質全体に関する内容となっています。こちらも選択解答式の試験になっていますが、実施時期は初級試験が年２回、中級試験が年１回となっており、決められた会場で実施されます。 IT検証技術者認定試験(IVEC)は、IT検証産業協会(IVIA)が認定するテストエンジニアの資格試験です。 上記２つの試験との大きな違いは、テストの現場における実務を重視しており、試験方式も選択解答式ではなく、PCによる記述形式となっています。年２回、決められた会場で実施されます。 【テストエンジニアの資格の比較】 資格名称 認定組織 内容 実施時期 受験料 JSTQB認定テスト技術者資格 JSTQB ソフトウェアテスト 随時 Foundation Level、Advanced Level 各22,000円   JCSQEソフトウェア品質技術者認定資格 日本科学技術連盟 ソフトウェア品質 年２回 初級 15,400円 中級 20,900円 IT検証技術者認定試験(IVEC) IT検証産業協会(IVIA) ソフトウェアテスト 年２回 19,800円～25,300円 ※レベル毎に異なる ※2023年8月現在※受験料はいずれも税込 「何かしらのテストエンジニアの資格を取得したい！」「広く知られている資格を取得して、スキルを証明したい」といった理由であればJSTQB認定テスト技術者資格が良いでしょう。「ソフトウェアテストだけでなくソフトウェア品質全体の知識を習得・証明したい」のであればJCSQEソフトウェア品質技術者認定資格が合っています。「ソフトウェアテストの実務に沿ったスキルを習得したい」のであればIT検証技術者認定資格(IVEC)を目指すと良いでしょう。 JSTQB®AL(TM)資格に準拠したテストのマネジメントスキルを学ぶ テストマネージャ編 JSTQB認定テスト技術者資格をもっと詳しく！ 本記事では、広く知られている資格であるJSTQB認定技術者資格（以下JSTQB）についてもう少し詳しくご紹介します。JSTQBには、 汎用的なソフトウェアテスト知識に関する基礎レベルとなる（Core）Foundation Levelと、上級レベルとなる（Core）Advanced Levelが存在します。 （Core）Advanced Levelは、さらに「テストマネージャ」と「テストアナリスト」の2つの試験に分かれています（もう一つ「テクニカルテストアナリスト」がありますが、2023年8月時点では未実施）。 また、2021年3月には、 専門分野の資格であるFoundation Level「自動車ソフトウェアテスト担当者」も実施されています。 今後もJSTQB公式サイトでシラバスが配布されている「AIテスト」「モバイルアプリケーションテスト」「性能テスト」「テスト自動化」「アジャイルテスト」など、様々な分野・内容におけるテストスキルを認定する資格の追加が予想されます。 そのため、実際に関わる専門分野の資格を取得すれば、汎用的な知識だけでない、専門分野に特化したテストエンジニアであるという証明を行えるようになるでしょう。（Core）Foundation Levelには受験資格はありませんが、Advanced Levelを受験するにはFoundation Levelの取得と実務経験3年が必要です。最初は（Core）Foundation Levelにチャレンジすることになります。 最短で資格を取得するための学習方法とは？ （Core）Foundation Level試験の合格率は、 JSTQB公式サイト によると約40％～75％となっています。大分バラつきはあるものの、しっかりと試験対策を行えば誰でも合格できるレベルです。 公式サイトのページ にはシラバスが公開されており、試験範囲の内容に関して一通り記載がされています。しかし、シラバスに記載されている内容を丸暗記すれば合格出来るというような簡単なものではありません。 試験には、K1記憶レベル、K2理解レベル、K3適用レベルの3つのレベルの問題が用意されているので、記載された内容を覚えるだけではなく、実際の状況に当てはめて選択できる力が求められます。実施した試験問題は持ち帰りが出来ないため、合格するまで何回も試験を受けるという対策はあまり効果的ではありません。 また、複数回受験するのは受験料がもったいないため、以下の中から自分にあった学習方法を選択し、最短で合格するのが良いでしょう。 テストの専門家が体系化した3つのメニューから構成された ソフトウェアテストの教育サービス ソフトウェア品質教育サービス「バルカレ」のご紹介 【試験に合格する為の効率の良い学習方法】 公認書籍を読む 試験対策講座を受講する 試験対策のeラーニングを受講する 試験対策アプリで学習する Advanced Levelに関しては、K4分析レベルも追加され、合格率もテストマネージャが約6％～34％、テストアナリストが約6％～42％と大分低くなります。さらに公認書籍が存在せず、個人での学習がしづらい試験となるため、よりしっかりとした対策が必要です。バルテスが提供しているeラーニングサービスにおいて、Advanced Level テストマネージャのみとはなりますが、動画コンテンツが日本で初めてJSTQBより公認を受けております。Foundation Level、Advanced Level テストアナリスト、Foundation Level スペシャリスト 自動車ソフトウェアテスト担当者も対策講座を取り揃えておりますので、ぜひこちらも参考下さい。 eラーニングサービス： https://www.qbook.jp/e-learning/ まとめ 「テストエンジニアの資格を取得し、スキルを証明しよう！」と題しまして、ご説明してまいりました。資格取得は、テストエンジニアとしてのスキルを証明するためのもっとも手っ取り早い手段です。 本記事で紹介した資格は、更新制の免許とは異なるため、一度取得すれば継続して自身のスキルの証明に使用できます。より多く資格の恩恵を受けるためにも、出来るだけ早い資格の取得をおススメします。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post テストエンジニアの資格を取得し、スキルを証明しよう！  first appeared on VALTES テストサービス .

「友達が怒りっぽくてさ、いつ話しかけても機嫌が悪いんだよ。飴ちゃんあげてもダメ、ジュースおごってもダメ、すごく優しくてもダメ。ただ唯一、ネコの動画見ている時だけ喜んでいるんだよなぁ」 この文章を一目でわかるようにして！と言われたらどうしますか？そんな時は”状態遷移図”を使えば、すぐに解決します！(記事の内容を参考に、上記の話を状態遷移図に落とし込んでみてください。) 今回は状態遷移図を具体的な例を用いて紹介し、図式化するメリットも解説します。うまく活用できれば仕事の資料作りにも活躍します！ 状態遷移図ってなに？ 状態遷移図とは「システムの状態が、あるイベントによって別の状態に変わることを可視化できる図」です。 まずは身近な例を使って説明していきます。 上の図では、「おやつを待っている状態」から「喜んでいる状態」に遷移しています。この状態の変化を引き起こすのは、「おやつをあげる」という動作になります。この動作が「イベント」となります。 「状態」に関してはいろいろな種類があります。 ・外部的な物の状態(例：電源のスイッチがONである) ・内部の処理の状態(例：あたため処理中である)　など・・・ これ以外にも定義できる状態はありますが、その時々に合う種類をピックアップし、どの遷移先のなるのかを状態遷移図で表していきます。一般的な状態遷移図を理解していただくために、以下のような仕様を例として図を作ってみましょう。 「電子レンジの待機中にあたため時間をボタンで指定して、startボタンを押すと中にあるものを温める。また、あたため中に停止ボタンを押すと待機中に戻る。指定した時間が終了すると、あたためが終了し冷却を行う。」 図中の表記について少し説明します。 □(しかく)の中には状態が、遷移先は矢印で表記されています。イベントは矢印の近くに書かれており、何がきっかけで遷移するのかが表記されています(あくまで一例です)。ここで注意していただきたい点は、「イベント」は使用者が操作するものだけではなくシステム対象が自動的におこなうものも含みます。図式化する内容は他にもバリエーションがありますが、今回は割愛します。 状態の遷移だけではなく、画面遷移においてもこの図を用いることが多くあります。画面であっても、考え方は変わりません。 ここまで状態遷移図について説明してきましたが、「状態」を考慮するのはなぜでしょうか？理由は「イベント発生前の状態によって同じ操作でも遷移先が違うため」です。PCを例にして考えてみましょう。 例) 表中にもある通り、電源OFF時には音量変更ボタンを押下しても変化はありませんが、ON時には音量変更中の状態になります。電源ボタンに関しては、同じ動作でも真逆の状態に遷移します。したがって、「イベント発生前の状態」を考慮してテストを実施しないと期待結果の判断間違いも発生します。さらにテストの考慮漏れが起こる可能性も高くなり、バグを見過ごしてしまうのです。 ソフトウェアテストの技法を習得できる ソフトウェアテスト設計技法編 図で書くことのメリット 先ほどの電子レンジの状態遷移を見て、すでに1つ目のメリットに気づいた方も多いのではないでしょうか。 そのメリットとは「図にすると、全体の関係性が視覚的によりわかりやすくなる」という点です。 状態とは違いますが、家系図を思い浮かべるとより理解が深まります。 例)①ある家系を文章にすると 「私は夫と結婚し、2人の子供がいます。どちらも結婚していますが、娘には男の子1人と女の子2人の子どもがいます。息子には女の子・男の子1人ずついます。」 ②ある家系を図にすると(家系図) 上の例でもわかるように、文章だけで説明するよりも図を合わせて示した方がよりわかりやすくなります。したがってソフトウェアを対象にする場合には、今まで示した電子レンジの仕様よりもはるかに多くのシステムや状態がかかわってきます。従って、状態遷移図にするメリットがより一層大きくなります。 開発者に仕様の確認をする場合は、文章だけではなくこのようにして図を併用すると理解しやすいです。また、図にすることでお互いの認識・解釈の齟齬がより見つけやすくなります。 状態遷移図は仕様を元に作成していきます。仕様とは「あるシステムのありよう」ですが、内容としては「このシステム(機能)ではこんなことができます」が多くなっています。 つまり状態遷移図においては、基本的には「何ができるか」や「状態の変化」の整理になります。「何ができるか」のテストを漏れなく計画・実施することも大事ですから、状態遷移図における内容の確認は重要になります。 テストの専門家が体系化した3つのメニューから構成された ソフトウェアテストの教育サービス ソフトウェア品質教育サービス「バルカレ」のご紹介 ”見えない”遷移 状態遷移図では仕様書からはわからない遷移も可視化できます。以下の架空の仕様を状態遷移図にすると、どうなるでしょうか。 例)照明器具の仕様で、明るさの調節については以下の仕様がある ・明かりの強さは3段階あり、明るさボタンを押すことにより強さが大きくなる 矢印とイベントは明るさ1からより明るい方にしかありませんが、明るさ3から2または1への変化は起こりえないのでしょうか？日常生活のことを考えると、明るさを弱くすることは大いにありえます。しかし、仕様に無いのでどのようにすれば弱い明るさに調整できるのか、はたまた元からシステムとして存在しないのかがわかりません。 状態遷移図を書き、矢印の方向に注目する(＝流れに注目する)ことによって仕様の不明点・不備などを発見しやすくなります。ソフトウェアテストにおいては、仕様上の内容だけでなく”書かれていない”仕様も確認する必要があるので、この点で図が役に立ちます。この際、矢印を追って流れを把握するだけではなく、ユーザーであればどのような使い方をするのか想定することも”見えない”遷移を見つけるために役立ちます。 しかし、状態遷移図で確認できることは「全体の流れ」と「仕様における何ができるか」です。 言い換えると、「ある状態のみを考慮したさまざまな操作」や「(仕様内外において)何ができないか」は漏れる可能性があります。従って、そのようなリスクがあることを念頭に置いて状態遷移図をテストの材料として作成する必要があります。 まとめ 「状態遷移図ってなに？」をテーマにして、ご説明してまいりました。 仕様書の内容や状態遷移を図で表すことで不明点や不備を発見でき、情報共有の場でもわかりやすく相手に示すことができます。 全体の流れを把握することにも役立ちますので、状態の移り変わりを考慮しながら「何ができるか」と「見えない遷移」を図から読み取ることもできます。 状態遷移図を書くには慣れが必要な部分もありますが、「状態」も考慮した適切なテストをおこなうことで品質の高い製品づくりを目指してみてはいかがでしょうか？ 最後に冒頭の文章を状態遷移図にしたものをお見せします。この書き方が唯一の正解ではありませんが、参考にしてみてください。 当サイトでは、テスト技法を学びたい方、 アジャイル 開発や マイグレーション のテスト手法について知りたい方、 テストアウトソーシング サービスに興味のある方へ、 ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。 The post 状態遷移図をわかりやすく！具体的な例と図式化するメリットをご紹介 first appeared on VALTES テストサービス .