現代のソフトウェア開発では、競争力を維持し、顧客ニーズに迅速に対応するために、より短いスパンでのリリースが求められるようになりました。従来の開発手法ではこれが難しいとされており、こうした課題に対応するために注目されているのがDevOpsです。 この記事では、初級者エンジニア向けに、DevOpsの基本知識やアジャイル開発との違い、DevOpsのライフサイクルや導入方法まで、詳しく解説していきます。DevOpsに興味を持っている方や、DevOpsを導入するメリットを知りたい方は、ぜひこの記事を読んでみてください。 DevOpsとは？ DevOps（デブオプス）は、ソフトウェア開発における開発者を意味する（Development）と運用者を意味する（Operations）を組み合わせた造語です。DevOpsは、開発チームと運用チームが協力して、一つのチームとして、スピーディにソフトウェアを開発し、品質や生産効率を高めることを目的としています。 従来の開発チームと運用チームは、役割が異なるために対立することがありました。一般的に、プログラムを作成する開発チームと、システムの運用を担当する運用チームに分かれて作業を行います。開発チームの役割は、競合他社との競争力を得るため、システムに新しい機能を追加することであり、運用チームの役割は、安定したサービスを提供し続けることです。しかし、新しい機能を追加したい開発チームに対し、運用担当者はシステムの安定稼働を優先するため、機能追加に慎重になることがありました。 DevOpsはこのような問題を解決するために、開発チームと運用チームが協力して、一つのチームとして開発にのぞむための手段と言えます。開発と運用の間の壁が取り払われることで、効率的かつ効果的なソフトウェア開発と運用が実現されます。 DevOpsの基本 DevOpsは、開発チームと運用チームが協力してソフトウェアを作ることを目指すため、以下のような考え方を基本とします。 ソフトウェア開発ライフサイクルの自動化 共同作業とコミュニケーションの向上 継続的な改善と無駄の最小化 ユーザーニーズの重視とフィードバックループの最短化 これらの基本原則を理解した上で、開発・運用の各プロセスを自動化することで、効率的かつ効果的なソフトウェア開発と運用を実現し、継続的に改善することができます。 DevOpsが重要な理由 DevOpsの重要性は、開発と運用のコラボレーションを促進し、開発から運用までの一貫性を確保することにあります。また、自動化ツールを活用することで、作業の効率化と品質向上を実現できます。さらに、DevOpsは迅速なビジネス対応とイノベーションの促進にも寄与します。これらの理由から、DevOpsは現代のソフトウェア開発において、必要不可欠な要素です。 DevOpsとアジャイル開発の違い DevOpsとアジャイル開発は、ともにソフトウェア開発において重要な手法ですが、それぞれのコンセプトは異なる側面があります。 アジャイル開発の特徴は以下のとおりで、どちらかというと開発に注力した考え方をしています。 要件や仕様の変更を積極的に受け入れるようにしている 設計・開発・リリースのような工程でできるだけわけずに、小さな機能ごとの開発を短い期間内で繰り返し行っていく コミュニケーションを重要視し、自己組織化されたチーム 一方で、DevOpsは、先ほどDevOpsの基本で説明した4点の考え方を特徴としており、運用と開発のつなぎこみに注力する側面が強いです。 つまり、アジャイル開発はソフトウェア開発の具体的な手法であり、DevOpsはソフトウェア開発と運用の手法となります。 DevOpsとCI/CDとの違い DevOpsとCI/CDは、ときどき混同されがちですが、それぞれ異なる概念であり、同時に密接な関係があります。 CI/CDはContinuous Integration（継続的インテグレーション）とContinuous Delivery（継続的デリバリー）の略称で、ソフトウェア開発における自動化の実践です。 CI/CDによる自動化は、DevOpsの考え方と相性が良く、効率的かつ効果的なソフトウェア開発と運用を実現するために、DevOpsアプローチの中でCI/CDが活用されることが多いです。つまり、CI/CDはDevOpsの実践において重要なツールとして機能し、両者は相互に補完しあう関係にあります。 DevOpsのライフサイクル DevOpsはソフトウェア開発と運用に関わる考え方ですが、その具体的なプロセスはどうなっているでしょうか？DevOpsのライフサイクルには、計画・コーディング・ビルド・テスト・リリース・デプロイ・運用・モニタリングの8つのステップがあります。DevOpsのライフサイクルを正しく実施することで、開発チームと運用チームが協力し、より迅速かつ信頼性の高いソフトウェア開発を実現することができます。 以下に各ステップの概要を説明します。 計画（Plan） DevOpsのライフサイクル最初のステップは計画です。このステップでは、開発チームと運用チームが協力して、ソフトウェアの要件定義や開発計画を策定します。計画ステップでは、開発と運用の間でのコミュニケーションが重要であり、双方が協力して開発計画を策定することが大切です。 コード（Code） 計画ステップの次はコーディングステップです。このステップでは開発チームがプログラムのコードを開発し、ソースコード管理システムにコードを格納します。単体テスト、コードレビューなどの手順を経て、コードを完成させます。 ビルド（Build） コーディングステップが完了したら、次のステップはビルドです。ビルドステップでは、開発チームがソースコードをビルドして動作可能なアプリケーションを作成します。自動化ツールやクラウドサービスを活用して、ビルドを迅速かつ安全に行います。 テスト（Test） ビルドしたアプリケーションに不具合がないかを確認するステップです。ここでは、開発チームがアプリケーションをテストし、バグを特定して修正します。テストステップでは、自動テスト、手動テスト、セキュリティテストなどの手順を経て、ソフトウェアの品質を確認します。 リリース（Release） リリースステップでは、ソフトウェアの新しいバージョンが完成し、デプロイの準備が整います。リリース管理ツールを使用して、ソフトウェアの異なるバージョンを管理し、必要に応じてロールバックできるようにします。 デプロイ（Deploy） リリースされたアプリケーションやソフトウェアの新しいバージョンを実際の本番環境に配置します。デプロイの工程では、リリースされたバージョンのアプリケーションが実際のサーバー、クラウド環境、または他のインフラストラクチャに配置され、本番環境での動作が確認されます。 運用（Operate） 運用ステップは、ユーザーサポートやトラブルシューティング、システムメンテナンスを実施し、システムを安定稼働させます。 モニタリング（Monitor） モニタリングステップでは、運用チームがシステムの稼働状況を監視し、問題が発生した場合には、迅速に対応します。 DevOpsのライフサイクルは、開発と運用を連携させ、自動化することを重視したプロセスです。この方法により、ソフトウェア開発と運用のパフォーマンスと品質を向上させることができます。 DevOpsの開発手法 DevOpsの開発手法は、ソフトウェア開発プロセスにおいて、開発チームと運用チームが協力して、アプリケーションの開発・テスト・デプロイ・運用を継続的に改善するための手法です。 DevOpsの開発手法には、以下の項目があります。 継続的インテグレーション 継続的デリバリー 継続的デプロイメント コミュニケーションと共同作業 継続的フィードバック これらの手法を正しく理解し、導入することで、開発チームと運用チームがより密接に連携し、効率的かつスムーズなアプリケーションの開発・テスト・デプロイ・運用が可能になります。 継続的インテグレーション 継続インテグレーションは、コードの変更を共有リポジトリにマージした後、自動化されたビルドとテストを実行することで、問題を早期発見することができ、品質を向上させるための手法です。この手法により、開発者はコードの変更に伴う不具合を迅速に解決し、品質の高いソフトウェアを提供できるようになります。また、テストを自動化することで開発者は時間と手間を省くことができるので、より大規模なプロジェクトでも効率的に作業できます。 継続的デリバリー 続的デリバリーは、ソフトウェアのリリースプロセスを自動化し、常にリリース可能な状態を保つ手法です。この手法は、アプリケーションのリリースに必要な準備を自動化することでリリースの速度と安全性を向上させるだけでなく、品質の向上、コストの削減、チームメンバーのストレス軽減などのメリットもあります。 ただし、リリース自体は人が手動で実行する必要があるため、デプロイプロセスの設計と慎重なテストが必要です。 継続的デプロイメント 継続デプロイメントとは、ソフトウェア開発で変更を行うたびに、リポジトリから本番環境やテスト環境に自動的にリリースする手法です。この手法により、リリースのスピードを向上させることができます。継続的デプロイメントでは、ビルド、テスト、デプロイが自動化されているため、開発チームや運用チームの負担を軽減し、素早いリリースを実現できます。 継続的デプロイメントと継続的デリバリーの違いは、継続的デリバリーは本番環境にリリースする前に、人の承認作業が必要になる点です。一方、継続的デプロイメントでは変更が行われたらすぐに本番環境にリリースされるため、より迅速なリリースが可能です。 このように、継続的デプロイメントは、開発者がより頻繁に変更をリリースできるため、ユーザーのフィードバックをより早く反映することができます。 コミュニケーションと共同作業 DevOpsの成功には、運用チームと開発チームの共同作業が不可欠であり、そのためには組織内でのコミュニケーションが欠かせません。具体的には、チャットアプリやプロジェクト管理ツールなどのDevOpsツールを使用してリアルタイムで情報共有やコミュニケーションを促進することが重要です。例えば、SlackやMicrosoft Teamsなどのチャットアプリは、リアルタイムでチームメンバーと瞬時にコミュニケーションを取ることができ、問題点を素早く共有し、対応することができます。また、プロジェクト管理ツールの例として、Azure DevOpsやJiraなどがあり、タスクの進捗状況の共有やプロジェクト全体の進捗管理を行うことができます。これらのツールを活用することで、タスクの進捗状況や問題点の共有がスムーズになり、組織全体が目標に向かってより密接に連携できるようになります。 継続的フィードバック 継続的にフィードバックを得ることで、顧客のニーズに合わせた製品の改善が可能になります。具体的には、プロトタイプやモックアップのように開発の早期段階からフィードバックを獲得する方法や、A/Bテストやカナリヤリリースのように本番稼働中のシステムからフィードバックを獲得する方法があります。 このように、継続的にフィードバックを得ることで、開発チームは製品を改善し、より高品質な製品を提供できるようになることから、顧客との信頼関係を築くことができるようになります。 DevOpsを導入するメリット DevOpsはソフトウェア開発と運用のパフォーマンスと品質を向上させることができますが、その具体的なメリットは何でしょうか？DevOpsのメリットは以下のようなものがあります。 開発スピードの向上 DevOpsの考え方やプラクティスを取り入れることにより、開発と運用のプロセスを効率化し、自動化を促進することができます。これにより、開発者はより迅速にアプリケーションを開発することが可能になります。また、DevOpsにより、開発者と運用者がより密接に連携できるため、開発者はより早い段階でフィードバックを受け取ることができます。 信頼性の向上 自動化されたテストやデプロイメントプロセスを通じて、システムの品質を向上させることができ、信頼性の高い製品を提供できます。 生産性の向上 DevOpsの導入により、開発者と運用者はより迅速にシステムを開発・デプロイすることができます。またリリースまでのプロセスを迅速化することで、ユーザーのフィードバックを早く反映させることができ、生産性を向上させることができます。 共同作業性の向上 DevOpsツールにより、開発チームと運用チームがより密接に連携することができるので、コミュニケーションの障壁を取り除くことができます。またチーム全体でシステムの状態を把握できるため、共同作業性を向上させることができます。 拡張性の向上 DevOpsの考え方では、インフラストラクチャもアプリケーションコードと同様にコードで管理することが推奨されます。この手法をInfrastructure as Codeと呼び、インフラをコードで定義することで、標準化されたパターンでリリース、更新、複製が可能です。これにより、インフラと開発プロセスを統合し、システム全体をより効率的に管理できます。 セキュリティ面の向上 DevOpsでは、開発と運用のプロセスを効率化し、自動化を促進することが重視されます。この自動化の一環として、セキュリティポリシーに基づいた自動チェックが実装されることが望ましいです。これにより、継続的にビルド・テストされたコードは、セキュリティポリシーに基づいて自動的にチェックされ、安全なソフトウェアを迅速に提供できるようになります。 DevOpsモデルの導入方法 このように、DevOpsはソフトウェア開発と運用に多くのメリットをもたらしますが、導入には、いくつかの障壁があります。 DevOps導入の障壁 DevOps導入の障壁として、以下の2つが挙げられます。 企業文化の変革の必要性 DevOpsは、開発チームと運用チームが協力してソフトウェアの開発から運用までをスムーズに行うことを目指す仕組みです。しかし従来のシステム開発方針では、開発チームと運用チームは別々に働き、それぞれに異なる目標や評価基準が存在していました。そのため、DevOpsを導入する際には、両者の役割や責任を明確にし、コミュニケーションや協調性を高めるための企業文化の変革が必要になります。 ツールの選定 DevOpsを実現するためには、適切なツールを選定することが重要です。しかし、数多くのツールが存在するため、どれを選ぶべきか判断することは容易ではありません。 DevOpsを実現するためのツール DevOpsを実現するためには、AzureやAWSなどのクラウドプラットフォーム、CI/CDツール、コンテナ管理ツールなどが必要です。 クラウドプラットフォーム クラウドプラットフォームを利用すると、インフラの設定や管理を自動化し、環境を柔軟にスケールアップ・スケールダウンできます。AzureやAWSはその代表例です。 Azure Microsoftによる提供で、Windowsとの親和性が高い点が特徴です。AIやIoTなどの先進的な技術にも対応しています。 AWS Amazonによる提供で、最も普及しているクラウドプラットフォームの一つです。サーバーレスアーキテクチャやコンテナ技術、マイクロサービスなど、最新の技術にも対応しています。 CI/CDツール CI/CDツールには、コードをビルド・テストしてリリースまでの自動化を支援する機能があり、Azure DevOpsやAWS CodePipelineが代表的なツールとして知られています。 Azure DevOps Azureクラウド上で提供されます。コードの管理からビルド、テスト、リリースまでの一連のプロセスを一元管理できます。また、GitHubやJenkinsなどの外部ツールとの連携も可能です。 AWS CodePipeline AWSクラウド上で提供されるCI/CDツールです。このサービスもビルド、テスト、リリースなどのプロセスを自動化できます。AWSの各種サービスとの連携が容易です。 コンテナ管理ツール DevOpsにおいては、コンテナ技術を活用することが多いため、コンテナ管理ツールも重要な役割を担っています。コンテナのデプロイや管理、スケーリングなどを支援する機能があります。代表的なツールとして、Azure Kubernetes ServiceやAWS Elastic Kubernetes Serviceが挙げられます。 Azure Kubernetes Service Azure上で提供されるKubernetesベースのコンテナ管理ツールで、Kubernetesクラスタの作成、管理、スケーリングを自動化できます。Azureで稼働するアプリケーションをKubernetes上で実行できるため、高い可用性や拡張性を実現できます。 AWS Elastic Kubernetes Service AWS上で提供されるKubernetesベースのコンテナ管理ツールで、コンテナの管理、スケーリング、自動復旧などを支援します。Amazon EC2上でKubernetesクラスタを構築するため、EC2の自動スケーリングやロードバランシングなど、AWSの各種サービスとの連携が容易になります。 これらのツールは、DevOpsの実践をサポートするものであり、組織やプロジェクトの要件に応じて選択・組み合わせることが可能です。また、これらのツールを効果的に活用することで、開発プロセスの自動化や効率化、コラボレーションの強化が実現できます。ただし、ツール自体がDevOpsを実現するわけではなく、適切な文化やプロセスが整備された上でツールを使うことで、DevOpsの恩恵を最大限に活用できることを理解しておくことが重要です。 Four Keysの 4つの指標 DevOpsの実践においては、プロジェクトの進捗やチームの効率化を評価する為の指標が不可欠です。そのための指標として、GoogleのDevOps Research And Assessmentチームが提唱した「Four Keys」があります。この指標を使用することで、ソフトウェア開発チームは、自分たちのパフォーマンス評価し、改善することができます。 Four Keysは、以下の4つの指標から構成されています。 デプロイ頻度 変更リードタイム 変更障害率 平均修復時間 これらの指標を定期的に測定することで、開発チームは、ソフトウェアの品質を向上させるために必要な改善点を把握できます。自身のパフォーマンスを客観的に評価し、改善することができます。 以下に、4つの指標について解説します。 デプロイ頻度 デプロイ頻度とは、開発チームが新機能や修正をリリースする頻度を示します。デプロイ頻度が高いほど、開発チームが効率的にリリースを行っていることが示されます。 変更リードタイム 変更リードタイムは、コードの変更から、本番環境でリリースされるまでの時間を示します。短い変更リードタイムは、新機能やバグ修正に迅速に対応できることを示します。 変更障害率 変更障害率とは、デプロイが原因で本番環境で障害が発生する割合を指します。変更障害率が低いことは、開発チームが信頼性の高いソフトウェアを提供できていることを示します。 平均修復時間 平均修復時間は、障害が発生してから修復するまでにかかる時間を指します。平均修復時間を短縮することで、障害を早期発見し、迅速に対応できるようになります。 Four Keyの指標は、開発チームのパフォーマンスを測定するものであり、改善に役立ちます。これらの指標を把握することで、開発チームは自身のパフォーマンスを客観的に評価し、継続的に改善を繰り返すことで、より高品質なソフトウェアを提供することができます。 まとめ 本記事では、DevOpsの基本的な概念や導入メリットについて解説しました。DevOpsは、開発チームと運用チームのコラボレーションを促進し、より効率的な開発が可能になる手法であり、今後ますます重要性が高まることが予想されます。 この記事が、エンジニアの皆さんの今後のソフトウェア開発をよりよいものにする助けになれば幸いです。 The post DevOpsとは？基本知識や導入メリットを解説 first appeared on Sqripts .

ISO/IEC/IEEE 29119は、ソフトウェアテストに関する国際標準です。この標準を理解し、適用することで、ソフトウェアの品質を向上させることが期待されます。本記事では、 ISO/IEC/IEEE 29119を学ぶ理由やメリット、デメリットについて説明します。 ISO/IEC/IEEE 29119とは？ ISO/IEC/IEEE 29119は、国際標準化機構（International Organization for Standardization; ISO）によって開発されたソフトウェアテストに関する国際標準です。この標準は、いくつかの既存のテスト標準やベストプラクティスを統合し、現代のソフトウェア開発とテストのニーズに対応するように設計されています。 ISO/IEC/IEEE 29119の歴史は、2007年に始まります。ソフトウェアテストワーキンググループ（WG26）が、SC7（ISO（国際標準化機構）とIEC（国際電気標準会議）が共同で運営するJTC1（統合技術委員会1）の下で活動するサブコミッティー）の一部としてソフトウェアテスト標準を開発・維持するために2007年に設立され、新しいテスト標準の開発を開始しました。これは、以前のソフトウェアテスト標準（ISO/IEC 12207, ISO/IEC 15288, IEEE 829, IEEE 1008, BS 7925-1, BS 7925-2）が、それぞれ異なるアプローチや用語を使用しており、一貫性や適用範囲が限定的であったためです。 この新しい標準の目的は、ソフトウェアテストのプロセス、ドキュメント、技法に関する包括的で一貫性のある指針を提供することでした。その結果、 ISO/IEC/IEEE 29119は、5つのパートから構成される一連の標準として策定されました。 ISO/IEC 29119-1:2013 – ソフトウェアテストのための概念および定義 ISO/IEC 29119-2:2013 – ソフトウェアテストプロセス ISO/IEC 29119-3:2013 – ソフトウェアテストドキュメント ISO/IEC 29119-4:2015 – ソフトウェアテスト技法 ISO/IEC 29119-5:2016 – キーワード駆動型テスト 最初の4つのパートの作業が始まった直後、ISO/IEC 33063のテストプロセス評価（Part 2で定義されたテストプロセスに対する評価）が別の提案によって作成され、これに続いてISO/IEC/IEEE 29119-5のキーワード駆動型テストが開発されました。その後、WG26は、他の標準によってカバーされる動的テストを補完するために、レビューに関する別の標準（ISO/IEC 20246）を開発し、これが2017年に発行されました。 その他にも、以下に示すように、いくつかの分野で作業が進んでいます。 • 2020年発行 – AIベースのシステムのテストに関するガイドライン（ISO/IEC TR 29119-11） • 2021年発行 – アジャイルプロジェクトでのISO/IEC/IEEE 29119（すべてのパート）の使用に関するガイドライン（ISO/IEC TR 29119-6） • 進行中 – 自動車システム向けソフトウェアのテストでのISO/IEC/IEEE 29119の使用に関するガイドライン（ISO/IEC TR 29119-7） • 進行中 – モデルベースのテスト（ISO/IEC TR 29119-8） • 進行中 – ゲームテスト（ISO/IEC TR 29119-9） • 進行中 – 性能テスト（ISO/IEC 29119-10） • 進行中 – インシデント管理（ISO/IEC/IEEE xxxxx） • 進行中 – 生体認証システムのテストでのISO/IEC/IEEE 29119の使用に関するガイドライン（ISO/IEC 29119-13） • 進行中 – データ移行テスト（ISO/IEC TR 29119-14） • 進行中 – 静的解析（ISO/IEC 29119-15） • 進行中 – 大規模で複雑なシステムのテストに関するガイドライン（ISO/IEC TR 29119-16） 上記の標準番号にTRとついているものは技術報告書と呼ばれるもので、情報提供の意味合いが強く、厳密には国際規格(IS)とは異なります。また、インシデント管理の標準は、純粋にソフトウェアテストに関するものではないため、ISO/IEC 29119ソフトウェアテストシリーズの一部とは見なされず、ランダムな番号が割り当てられます。 国際規格は5年間毎に見直しがされ、必要であれば更新されます。実際、最初の4つのパートは2021年と2022年に更新されました。 • 2021年発行 – テストプロセス – 第2版（ISO/IEC/IEEE 29119-2） • 2021年発行 – テスト文書 – 第2版（ISO/IEC/IEEE 29119-3） • 2021年発行 – テスト技法 – 第2版（ISO/IEC/IEEE 29119-4） • 2022年発行 – 一般的な概念 – 第2版（ISO/IEC/IEEE 29119-1） ISO/IEC/IEEE 29119を学ぶ理由 ISO/IEC/IEEE 29119を学ぶ理由には内発的要因と外発的要因の2つあります。まずは、内発的要因ですが、主要な要因に以下の３つがあります。 a) 品質の向上 ソフトウェアテストは、品質を確保するための重要なプロセスです。 ISO/IEC/IEEE 29119は、テストプロセスの標準化を目指しており、学ぶことで品質向上につながります。 b) 信頼性の向上 ISO/IEC/IEEE 29119は、国際的な標準であり、それに従うことで、顧客やビジネスパートナーからの信頼を得ることができます。 c) 効率化 標準化されたテストプロセスは、効率的な作業ができるようになります。これにより、開発サイクルが短縮され、コスト削減にもつながります。 次に外発的要因ですが、ISO/IEC/IEEE 29119は国際規格である性格上、その準拠が求められることが挙げられます。ISO/IEC/IEEE 29119の準拠が求められる場合は、主に以下のような状況です。 a) クライアントの要求 顧客やクライアントが、ソフトウェア開発プロジェクトやテスト活動においてISO/IEC/IEEE 29119に準拠することを要求することがあります。これは、品質保証のための一般的な基準を確立し、プロジェクトのリスクを低減するためです。 b) 法規制や業界標準 特定の業界や分野では、法規制や業界標準によってISO/IEC/IEEE 29119に準拠することが求められることがあります。これは、ソフトウェアの安全性や信頼性を確保し、利害関係者に対する責任を果たすためです。 c) 国際的な取引 多国籍企業や国際的なプロジェクトでは、異なる国や地域の組織間で一貫した品質基準を確立するために、ISO/IEC/IEEE 29119に準拠することが求められることがあります。 ISO/IEC/IEEE 29119のメリット ISO/IEC/IEEE 29119を導入するメリットは多くありますが、主なものは以下の4つになります。 a) 組織全体での共通言語 ISO/IEC/IEEE 29119を導入することで、組織内でのコミュニケーションが円滑になります。共通の言語を持つことで、誤解やミスが減少し、作業効率が向上します。 b) テストプロセスの標準化 テストプロセスが標準化されることで、繰り返し実施するテストの品質が向上します。また、新しいプロジェクトに対しても、テストプロセスを迅速に適用できます。 c) ドキュメントの統一 ISO/IEC/IEEE 29119は、ドキュメントのフォーマットや内容も規定しています。これにより、ドキュメントの品質が向上し、情報の共有や管理が容易になります。 d) トレーサビリティの向上 標準化されたドキュメントやプロセスにより、テストのトレーサビリティが向上します。これにより、問題が発生した際に原因を特定しやすくなり、迅速な対応が可能となります。 ISO/IEC/IEEE 29119のデメリット ISO/IEC/IEEE 29119の導入はメリットだけではなく、考慮しなければいけないデメリットも存在します。主なものは、以下の3つです。 a) コストと時間 ISO/IEC/IEEE 29119を導入するには、初期費用や研修費用が必要です。また、標準に沿ったプロセスやドキュメントを整備するための時間も必要となります。 b) 柔軟性の低下 標準化されたプロセスやドキュメントは、柔軟性が低下する可能性があります。特定のプロジェクトに対して最適な方法が標準と異なる場合、適応が難しくなることがあります。 c) 過剰な成果物 ISO/IEC/IEEE 29119は、ドキュメントやプロセスに関して詳細な規定をしています。これが、場合によっては過剰な成果物を生む可能性があり、作業効率が低下することがあります。 まとめ ISO/IEC/IEEE 29119は、ソフトウェアテストに関する国際標準であり、品質や信頼性の向上、効率化に役立ちます。また、組織全体での共通言語やドキュメントの統一、トレーサビリティの向上などのメリットがあります。一方で、コストや時間、柔軟性の低下、過剰なフォーマリティなどのデメリットも考慮する必要があります。 学ぶ理由やメリット、デメリットを理解した上で、組織のニーズや状況に応じて ISO/IEC/IEEE 29119の導入を検討してください。適切に適用することで、ソフトウェアの品質向上や効率化に大きく貢献することができます。 The post ISO/IEC/IEEE 29119とは? 学ぶ理由、メリット、デメリットを分かりやすく解説 first appeared on Sqripts .

こんにちは！フロントエンドエンジニアのつかじです。 今回はNext.jsアプリケーションに Microsoft Clarity を導入してみたいと思います。Microsoft Clarityは、ユーザーエクスペリエンスを向上させるための無料の分析ツールです。このツールを使って、ユーザーの行動を理解し、アプリケーションのパフォーマンスを最適化しましょう。 なぜMicrosoft Clarityを導入するのか？ Microsoft Clarityは、ウェブサイトのユーザーエクスペリエンスを向上させることを目的とした無料の分析ツールです。Clarityを導入する際の具体的な目的は下記の通りです。 ユーザー行動の理解 ヒートマップやセッション再生機能を利用して、ユーザーがウェブサイトでどんな行動をしているのかを知ることができます。これで、ユーザーのニーズや問題点を見つけ出し、対応策を考えることができます。 ユーザビリティの向上 セッション再生機能を利用して、ユーザーがウェブサイトで困っている場所や、ナビゲーションが難しいところを特定することができます。それらの問題を解決するための改善策を実施することでウェブサイトをもっと使いやすくできます。 コンテンツの最適化 ヒートマップ機能を利用して、ユーザーが最も興味を持っているコンテンツや、なかなかスクロールされないエリアを特定できます。これを参考に、コンテンツの配置やデザインを工夫し、ユーザーの興味を引くサイトに仕上げることができます。 コンバージョン率の向上 インサイトを利用して、コンバージョンまでのユーザーの動きを調べ、コンバージョンの障害となるポイントを見つけ出します。これを解決することで、コンバージョン率を向上させることができます。 デバイスやブラウザの最適化 インサイトダッシュボードで、ユーザーがどんなデバイスやブラウザを使っているのかを調べ、それに合わせて最適化を行います。これにより、すべてのユーザーに適したウェブサイトの提供が可能になります。 Next.jsアプリケーションへMicrosoft Clarityを導入する 1. Microsoft Clarityのアカウント作成 まずはじめに、 Microsoft Clarityのウェブサイト にアクセスし、アカウントを作成します。 アカウント作成が完了したら、プロジェクトを追加して、トラッキングコードを取得します。このトラッキングコードがNext.jsアプリケーションに必要になります。プロジェクトの追加はウェブサイト名とURLのみの入力で簡単に登録可能です。 2. Next.jsアプリケーションにトラッキングコードを追加 さて、Microsoft Clarityのトラッキングコードを手に入れたら、次はNext.jsアプリケーションに導入していきます。以下の手順で導入できます。 １． _document.tsx ファイルを作成する pages フォルダ内に _document.tsx ファイルを作成します。すでに作成済みの場合は、そのファイルを開いてください。 ２．Microsoft Clarityのトラッキングコードを追加する _document.tsx ファイルの <Head> タグ内に、Microsoft Clarityのトラッキングコードを追加し、デプロイを行います。 ※ YOUR_TRACKING_CODE の部分は、実際のトラッキングコードに置き換えてください。 import Document, { Head, Html, Main, NextScript } from "next/document"; class MyDocument extends Document { render() { return ( <Html> <Head> {/* ここにトラッキングコードを追加 */} <script type="text/javascript" dangerouslySetInnerHTML={{ __html: ` (function(c,l,a,r,i,t,y){ c[a]=c[a]||function(){(c[a].q=c[a].q||[]).push(arguments)}; t=l.createElement(r);t.async=1;t.src="https://www.clarity.ms/tag/"+i; y=l.getElementsByTagName(r)[0];y.parentNode.insertBefore(t,y); })(window, document, "clarity", "script", "YOUR_TRACKING_CODE"); `, }} /> </Head> <body> <Main /> <NextScript /> </body> </Html> ); } } export default MyDocument; 以上で導入は完了です。簡単でしたね。 Microsoft Clarityのダッシュボードでユーザー行動のデータが表示されるようになります。ヒートマップやセッション再生などの機能を使って、ユーザーの行動を分析し、アプリケーションの最適化を行いましょう。 終わりに Next.jsアプリケーションへMicrosoft Clarity導入はかなり簡単でしたね。Microsoft Clarityと統合することで、無料で分析データを取得し、ウェブサイトのユーザーエクスペリエンスを向上させることができます。これらの情報を活用して、ウェブサイトを改善し、より多くのユーザーにとって魅力的なコンテンツを提供しましょう。 The post Next.jsアプリケーションにMicrosoft Clarityを導入してユーザーエクスペリエンスを向上させよう！ first appeared on Sqripts .

テスト駆動開発のスタイルを取り入れているもののテストのことはあまりよくわかっていないプログラマーと、テストへの熱い情熱をもちつつプログラマーの事情はわかっていないテスターとが、小さな障害の発見をきっかけとして出会い、役割の壁を崩しながら少しずつ協調するようになっていく、小さなお話です。 登場人物 プロ之 … プログラマー テス緒 … テスター 前回、プロ之さんとテス緒さんは協力して、問題の原因が古いIE対応サービスにあることを突き止めました。しかし、IE対応サービスはすでにサポート外でサービスも停止済みであることがわかりました。プロ之さんは停止済みサービスが今後問題を起こすはずがないと結論し、テス緒さんは原因追及が振り出しに戻ってしまい途方に暮れています。 問題はどこにいった？ プロ之さんはIE対応サービスが1年以上前に終了していると聞き、自分の目でもゲートウェイが存在せずクラスター内にも稼働していないことを確認しました。テス緒さんと調べていた問題がIE対応サービスに存在していたとしても、実行されなければ今後問題になるはずがありません。修正する意味もありません。 「(完全に時間の無駄だっただろうか？)」プロ之さんは考えてみました。「(そんなことはない)」とプロ之さんは自分で答えました。調査を通じて新しく学んだことは多く、テストの考え方や観点も参考になるし、今後テストチームとコミュニケーションするときもスムーズにできそうです。「(一定の満足が得られた、有意義な活動だった)」そう結論しながら、イシュー管理システムにテス緒さんが数週間前に作ったチケットを、開発チームの担当者として「対応なし」でクローズしようとしました。 その寸前に、テス緒さんからチャットのメッセージが届きました。「ちょっと相談できる？」 プロ之さんはメッセージで返信しました。「いまチケットをクローズするところです。どんな相談ですか？」 テス緒(以下、T)「問題の他の原因について」 プロ之(以下、P)「原因は判明しました。発生した現象と完全に一致しています。他の可能性は考えられません。今後実行しないコードなのでこれ以上問題は起きません。これ以上の調査と対応は優先順位を下げるべきです」 T「そうだよね、でもおかしい気がして。話せない」 P「これまでの調査や議論は無駄ではなかったと考えています。テス緒さんにもいろいろ教えていただきましたし、有意義でした。ですが今回の問題はクローズです。いまクローズするところです。そうしないとチームリーダーにも文句を言われます」 突然背後で呼び出し音が鳴り、プロ之さんは飛び上がりました。鳴ったのは社用携帯電話で、開発チームの緊急連絡用なのでめったに使いません。プロ之さんは用心して、通話をスピーカーフォンモードにしました。 携帯電話からはテス緒さんのあわてた声が聞こえてきました。「ああよかった、番号間違えたかと思った。どうしても話をしたくって。あ、すみません、番号間違ってないですよね？ プロ之さんだよね？」 P「そうです」 T「よかった！ もうこれからどうしたらいいかわかんなくなっちゃって、リーダーにも次の作業をせっつかれるし、相談に乗ってもらえないし、プロ之さんもう話してくれないし、調べても無駄とか話しても有意義じゃないとか冷たいし」 P「そんなことは言ってません。ですが現時点ではやるべきことをやりました。これ以上は優先順位を下げるべきです。問題のコードが書かれたのはずいぶん前なので十分な調査ができる気はしません。1年以上動作していませんし…」 「1年前！」テス緒さんの大声で携帯電話が震えました。「ちょっと待ってちょっと見て日付」 プロ之さんからのチャットで大量のログが送られてきました。大量すぎて内容は把握できませんが、日付の部分を眺めると1ヶ月か2ヶ月前のものになっています。 T「見て！ IE対応サービスが1年以上動いてないのに、このログは1ヶ月前なんだよ！ データがおかしくなっているところも、最近1年以内にあったはず。だからきっとほかに原因があるはずで…プロ之さん？ 聞いてる？」 プロ之さんは考え込んでいて、聞こえていませんでした。「(あのコードは1年以上動いていない。このログを出すのはあのコードしかあり得ない。このログは1ヶ月前に、本番環境で出ている。ということは)」 「あのコードがどこかで動いている」プロ之さんは声に出して言いました。 テス緒さんは聞き返します。「でもIE対応のサービスは動いていないんでしょう？」 「動いていないはずです。それが理論的推論です。ですが動いています。これは観測した事実です。推論と事実では、必ず事実が勝ちます。コードは動いています」プロ之さんは断言しました。 2人のヒートアップしたやり取りから、新たな可能性が見えてきました。プロ之さんは調査結果から自分の結論を出しました。テス緒さんは、うまく言葉にできないもやもやを抱えながら、プロ之さんのヒントに新たな糸口を見出しました。 ここでは、プロ之さんが冷静な判断を見せています。調査結果自体は事実ですが、そこから論理的に出した結論は推論です。推論は強力な武器ですが、もしそれに反する証拠や事実が新たに見つかったら、間違っているのは推論のほうです。見つかった事実に合わせて、論理を組み立て直すことになります。 そして2人がヒートアップしながらも、相手を非難したり、萎縮させたりはしていない点にも注目できます。同じことを同じように言っても、相手によっては攻撃を受けたように感じたり、守りに入ったりして、率直な議論ができなくなる場合があります。この2人がこれまで積み重ねてきた関係性とお互いへの信頼があるからこそ、第三者から見たら激しく見えるようなやりとりでも建設的になります。2人それぞれの性格も、関係あるかもしれません。 ポイント: 観測した事実と論理で導かれる可能性を統合して問題を絞り込む 信頼関係を積み重ねているからこそ率直な議論ができる それは人の問題で、チームの問題 ここからは後日談になります。プロ之さんはログを出力しているインスタンスを見つけ、インスタンスの内部を調査して、本来は存在しないはずの該当コードがデプロイされているのを確認しました。さらにインスタンス固有のAPI設定を手で書き換えた形跡があり、そのせいで呼び出されないはずのIE対応サービスのコードが実行されていたことがわかりました。その特定のインスタンスでのみ発生する現象だったため、これまで見落とされてきたのです。 この発見は開発チームと運用チーム両方で重大な問題として調査することになりました。その結果、2年前に大規模なリリースをしたとき、開発者が動作確認をするため一時的にIE対応サービスのコードをデプロイし、APIの設定も書き換えていたのですが、それを元に戻し忘れていたことがわかりました。作業ミスをしたのは、なんと今の開発チームリーダーだったとのことです。 対応としてAPI設定を正しく直したのはもちろんですが、このような作業ミスが起きたこと、それを今まで見逃してきたことも問題視され、対策が検討されました。開発リーダーのような優秀な人でもミスをするのだから、本番環境を直接操作するような運用は危ないと再認識され、リリース作業の自動化が前進しました。また不要なコードのデプロイ防止策として、リリースノートをテストチームと共同で書くという案を検討しています。 テストチームでもテスト観点を見直しました。ソフトウェアを動かして確認するだけでは見落としが発生するという認識から、デプロイプロセスの確認や、設定内容の確認などもテストに含めることにしたのです。こうした確認の一部は開発チームの力を借りて自動化されました。テス緒さんが「同じ内容のテストを手で繰り返すなら自動化すべき」と主張したのが採用されたそうです。 ポイント: ソフトウェアの問題は、誰かが「やらかした」結果なので、人の問題と言える 起きた問題ではなくその原因を直しに行く。問題が起きないように直す 問題を解決した！さてお次は？ いろいろな変化が起きていく中で、プロ之さんとテス緒さんは久しぶりにリアルで顔を合わせました。 T「やー、なんだか大変なことになっちゃったね。手順も変わるしツールも新しくなるし。よく、お前のせいだからな！ ってリーダーに言われるんだよ。笑いながらだけど」 P「私たちのせいではありません。タイミング良く見つけただけです。開発リーダーも少し静かになっていましたが、今は新しいことに取り組むのに忙しそうです」 T「開発リーダーさんは新しいこと好きそうだよね。でもこれが落ち着いたら、いろいろ良くなりそう。テストチームでもテスト自動化を勉強してるんだよ」 P「開発プロセスが現代的になりそうですし、DevOpsの考え方も進んでいます。良くなりそうですね」 テストで見つかった問題をきっかけとして、各チームが対策を取り、チーム間の協力も強化されそうです。失敗から学べる、優秀な組織のようです。人為的ミスを減らす工夫は、品質にも良い影響がありますし、作業の効率化にもつながります。問題への見事な対応だと言えます。 G.M.ワインバーグの著書『コンサルタントの秘密』(1990, 共立出版)に、こんな言葉が紹介されています。 第一番の問題を取り除くと、第二番が昇進する 一番の問題、いま最も重要な問題、まず解決すべき問題を無事に解決できたら、それは素晴らしいことです。しかし同時に、それまで二番手だった問題がトップに躍り出てきます。問題に対処しても問題はなくならない、また次の問題が現れるだけであるという法則です。[ 1 ] T「ところでね、昨日こんな不思議な現象があったんだけど…」 P「テストチームのテスト自動化で、気になることが…」 2人もまた新たな問題を見つけたようです。問題は途切れないかもしれませんがひとつずつ片付ければ、ひとつずつ状況を良くしていけます。小さな問題でも大きな問題でも、根本的な原因をたどって改善のきっかけにできます。こんどの問題は簡単なものでしょうか、チームやプロダクト全体を巻き込むようなものでしょうか、はたまた…？ ポイント: 問題を解決しても問題はなくならない。次の問題が登場する チームの品質とプロダクトの品質を両方とも改善していく 本連載は今回が最終回となります。最後まで読んでいただき、ありがとうございます。 [1] 書籍ではワインバーグが13歳の時、スーパーでアルバイトをした話が紹介されています。そこで、野菜売場でルタバガ(カブに似た野菜)の売れ行きがとても悪いことに気づきました。野菜売場責任者のルウディーが売場スペースを整理しようとして、ワインバーグになにかアイデアがないか聞きました。ルタバガを減らすのはどうかとワインバーグが答え、ルウディーはその案を喜んで採用します。ルウディーはルタバガを片付けてから、こうワインバーグに聞きました。 「で、ルタバガの次は何だね」 問題をひとつ片付ければ、次の問題が登場します。おまけにそれも片付けるよう期待されてしまうかもしれません。これが「ルウディーのルタバガの法則」です。 第4回：立場を越えて問題を追及しよう 第3回：大事(だいじ)なことが本当に大事か確かめよう 第2回：それぞれの得意をつなぎ合わせよう 第1回：引っかかりを感じたら相談しよう The post 【テスターと開発者が上手に協力するには】第5回：テストを通じてチームとプロダクトとに貢献しよう first appeared on Sqripts .

こんにちは！フロントエンドエンジニアのつかじです。 皆さんはREST APIクライアントをどのように開発していますか？私はAPIクライアントを手作業で作成するのは手間がかかるため、普段のプロダクト開発ではOpenAPI Generatorを使って自動生成しています。しかし先日、Microsoftが新しいAPIクライアント生成ツール「Kiota」を 発表 しました。気になった方も多いのではないでしょうか？ 今回は、Microsoftから新しく発表されたAPIクライアント生成ツール「Kiota」を使って、Node.js(TypeScript)のプロジェクトでAPIクライアントを生成し、実際に動かしてみたいと思います。 1. Kiotaのインストール こちら の公式ドキュメントを参照してインストールします。 ※ 私は.NET toolでインストールしました 2. Node.js(Typescript)サンプルプロジェクト作成 npm init npm install -D typescript ts-node npx tsc --init 3. Kiotaの依存パッケージをインストール Kiotaが生成したAPIクライアントのビルド、実行のために抽象化パッケージへの参照が必要です。 npm install @microsoft/kiota-abstractions npm install @microsoft/kiota-http-fetchlibrary npm install @microsoft/kiota-serialization-form npm install @microsoft/kiota-serialization-json npm install @microsoft/kiota-serialization-text 4. KiotaでAPIクライアントを生成 今回は Swagger PetStore からAPIクライアントを生成したいと思います。 Swagger PetStoreは、Swagger（現在のOpenAPI）のサンプルAPIで、ペットストアの基本的な操作を提供しています。Swagger PetStoreは、APIの定義、実装、ドキュメント化のデモンストレーションを目的として設計されており、試すことができます。 Kiota CLIにて下記のコマンドを実行 kiota generate -l typescript -d <https://petstore.swagger.io/v2/swagger.json> -c PetStoreClient -o ./petstore-client すると、 petstore-client ディレクトリ以下に下記のAPIクライアントのコードが無事に生成されました！ . ├── kiota-lock.json ├── models │ ├── apiResponse.ts │ ├── category.ts │ ├── createApiResponseFromDiscriminatorValue.ts │ ├── createCategoryFromDiscriminatorValue.ts │ ├── createOrderFromDiscriminatorValue.ts │ ├── createPetFromDiscriminatorValue.ts │ ├── createTagFromDiscriminatorValue.ts │ ├── createUserFromDiscriminatorValue.ts │ ├── index.ts │ ├── order.ts │ ├── order_status.ts │ ├── pet.ts │ ├── pet_status.ts │ ├── tag.ts │ └── user.ts ├── pet │ ├── findByStatus │ │ ├── findByStatusRequestBuilder.ts │ │ ├── findByStatusRequestBuilderGetQueryParameters.ts │ │ └── findByStatusRequestBuilderGetRequestConfiguration.ts │ ├── findByTags │ │ ├── findByTagsRequestBuilder.ts │ │ ├── findByTagsRequestBuilderGetQueryParameters.ts │ │ └── findByTagsRequestBuilderGetRequestConfiguration.ts │ ├── item │ │ ├── createWithPetPostRequestBodyFromDiscriminatorValue.ts │ │ ├── index.ts │ │ ├── uploadImage │ │ │ ├── uploadImageRequestBuilder.ts │ │ │ └── uploadImageRequestBuilderPostRequestConfiguration.ts │ │ ├── withPetItemRequestBuilder.ts │ │ ├── withPetItemRequestBuilderDeleteRequestConfiguration.ts │ │ ├── withPetItemRequestBuilderGetRequestConfiguration.ts │ │ ├── withPetItemRequestBuilderPostRequestConfiguration.ts │ │ └── withPetPostRequestBody.ts │ ├── petRequestBuilder.ts │ ├── petRequestBuilderPostRequestConfiguration.ts │ └── petRequestBuilderPutRequestConfiguration.ts ├── petStoreClient.ts ├── store │ ├── inventory │ │ ├── createInventoryResponseFromDiscriminatorValue.ts │ │ ├── index.ts │ │ ├── inventoryRequestBuilder.ts │ │ ├── inventoryRequestBuilderGetRequestConfiguration.ts │ │ └── inventoryResponse.ts │ ├── order │ │ ├── item │ │ │ ├── withOrderItemRequestBuilder.ts │ │ │ ├── withOrderItemRequestBuilderDeleteRequestConfiguration.ts │ │ │ └── withOrderItemRequestBuilderGetRequestConfiguration.ts │ │ ├── orderRequestBuilder.ts │ │ └── orderRequestBuilderPostRequestConfiguration.ts │ └── storeRequestBuilder.ts └── user ├── createWithArray │ ├── createWithArrayRequestBuilder.ts │ └── createWithArrayRequestBuilderPostRequestConfiguration.ts ├── createWithList │ ├── createWithListRequestBuilder.ts │ └── createWithListRequestBuilderPostRequestConfiguration.ts ├── item │ ├── withUsernameItemRequestBuilder.ts │ ├── withUsernameItemRequestBuilderDeleteRequestConfiguration.ts │ ├── withUsernameItemRequestBuilderGetRequestConfiguration.ts │ └── withUsernameItemRequestBuilderPutRequestConfiguration.ts ├── login │ ├── loginRequestBuilder.ts │ ├── loginRequestBuilderGetQueryParameters.ts │ └── loginRequestBuilderGetRequestConfiguration.ts ├── logout │ ├── logoutRequestBuilder.ts │ └── logoutRequestBuilderGetRequestConfiguration.ts ├── userRequestBuilder.ts └── userRequestBuilderPostRequestConfiguration.ts 5. Kiotaで生成されたAPIクライアントでAPIを叩く 次に、生成されたAPIクライアントを使って、実際にSwagger PetStore APIにアクセスしてみましょう。 以下のサンプルコードを** index.ts **というファイル名でプロジェクトディレクトリに作成し、 import { AnonymousAuthenticationProvider } from "@microsoft/kiota-abstractions"; import { FetchRequestAdapter } from "@microsoft/kiota-http-fetchlibrary"; import { PetStoreClient } from "./petstore-client/petStoreClient"; (async () => { const authProvider = new AnonymousAuthenticationProvider(); const adapter = new FetchRequestAdapter(authProvider); const client = new PetStoreClient(adapter); const pet = await client.petById("1").get(); console.log(pet); })(); 実行すると、コンソールログにレスポンスの内容が表示されます。これでSwagger PetStore APIとのやりとりができるようになりました！ おわりに 今回は、Microsoftから発表されたばかりのKiotaを使って、TypeScriptのAPIクライアントを簡単に生成することができました。Kiotaは新しいプロジェクトであり、まだ発展途上ですが、今後の機能追加や言語サポートにも期待大ですね！みなさんもぜひ試してみてください！ The post Microsoftの新しいAPIクライアント生成ツールKiotaを試してみた first appeared on Sqripts .

テスト自動化のお仕事をしているきむらです。 Windowsアプリの自動操作に興味があるけど、自動化ツールが色々あってよくわからない。 自動化ツールのセットアップとか難しそう。。 そんな、自動化の世界に飛び込めずにいる方のために、自動化ツールをインストールしないで、Windowsに標準搭載されている「UI オートメーション」機能を使って、アプリを自動操作する方法を紹介したいと思います。 用意したPowerShellのスクリプトをコピペして実行するだけで体験できますので、気楽な感じでお付き合いいただければと思います。 環境 この記事のPowerShellスクリプトは下記の環境で動作確認しています。 Microsoft Windows 10 Pro 22H2 PowerShell 5.1.19041.2673 Microsoft Windows 11 Pro 22H2 PowerShell 5.1.22621.963 Microsoft Edge 112.0.1722.58 UIオートメーションとは 「UIオートメーション」は、ざっくり言うと「ユーザーインターフェイスをプログラムから操作したりすることができる」機能で、Windowsに標準搭載されています。 もっと詳しく知りたい方は「 UI オートメーションの概要 」をご参照ください。 Windows PowerShell ISEを起動する 「Windows PowerShell ISE」はWindowsに標準搭載されているPowerShellの統合開発環境で、PowerShellスクリプトを効率的に作成することができるアプリです。 タスクバーの検索ボックスに「powershell」を入力して、検索結果から「Windows PowerShell ISE」を選択して起動します。起動したら、ツールバーの「スクリプトを新規作成します」ボタンを選択します。（またはメニューバーから [ファイル] > [新規作成] を選択します。） 上半分の背景が白色のウィンドウが「スクリプトウィンドウ」で、こちらにスクリプトをコピペしていきます。 下半分の背景が紺色のウィンドウは「コンソールウィンドウ」で、コマンドを入力・実行したりするウィンドウです。 UIを自動操作するための土台となるスクリプトコピペする まずは、UIを自動操作するための土台となるスクリプトをコピペします。 このスクリプトには、要素をクリックしたり、キーボード操作をする関数（部品のようなもの）が書かれていて、この関数を使って自動操作をおこないます。 下記のスクリプトをコピーします。 # Windows PowerShellでアプリを自動操作するスクリプト # UI オートメーションを使うための準備 Add-Type -AssemblyName "UIAutomationClient" Add-Type -AssemblyName "UIAutomationTypes" $AutomationElement = [System.Windows.Automation.AutomationElement] $TreeScope = [System.Windows.Automation.TreeScope] $Condition = [System.Windows.Automation.Condition] $InvokePattern = [System.Windows.Automation.InvokePattern] $SendKeys = [System.Windows.Forms.SendKeys] $Cursor = [System.Windows.Forms.Cursor] # マウスの左クリック操作をおこなうための準備 $SendInputSource =@" using System; using System.Drawing; using System.Runtime.InteropServices; using System.Windows.Forms; public class MouseClick { [StructLayout(LayoutKind.Sequential)] struct MOUSEINPUT { public int dx; public int dy; public int mouseData; public int dwFlags; public int time; public IntPtr dwExtraInfo; } [StructLayout(LayoutKind.Sequential)] struct INPUT { public int type; public MOUSEINPUT mi; } [System.Runtime.InteropServices.DllImport("user32.dll")] extern static uint SendInput(uint cInputs, INPUT[] pInputs, int cbSize); public static void Click() { INPUT[] input = new INPUT[2]; input[0].mi.dwFlags = 0x0002; input[1].mi.dwFlags = 0x0004; SendInput(2, input, Marshal.SizeOf(input[0])); } } "@ Add-Type -TypeDefinition $SendInputSource -ReferencedAssemblies System.Windows.Forms, System.Drawing $MouseClick = [MouseClick] # 要素を取得する関数 function GetElements { Param($RootWindowName = $null) if ($RootWindowName -eq $null) { try { return $AutomationElement::RootElement.FindAll($TreeScope::Subtree, $Condition::TrueCondition) } catch { return $null } } else { $childrenElements = $AutomationElement::RootElement.FindAll($TreeScope::Children, $Condition::TrueCondition) foreach ($element in $childrenElements) { if ($element.GetCurrentPropertyValue($AutomationElement::NameProperty) -eq $RootWindowName) { return $element.FindAll($TreeScope::Subtree, $Condition::TrueCondition) } } Write-Host "指定された名前 '${RootWindowName}' のウィンドウが見つかりません。" } return $null } # 要素を検索する関数 function FindElement { Param($RootWindowName = $null, $PropertyType, $Identifier, $Timeout) $startTime = (Get-Date).Ticks do { foreach ($element in GetElements -RootWindowName $RootWindowName) { try { if ($element.GetCurrentPropertyValue($AutomationElement::$PropertyType) -eq $Identifier) { return $element } } catch { continue } } } while (((Get-Date).Ticks - $startTime) -le ($Timeout * 10000)) throw "指定された要素 '${Identifier}' が見つかりません。" } # クリック操作をおこなう関数 function ClickElement { Param($RootWindowName = $null, $PropertyType, $Identifier, $Timeout = 5000) $startTime = (Get-Date).Ticks do { $element = FindElement -RootWindowName $RootWindowName -PropertyType $PropertyType -Identifier $Identifier -Timeout $Timeout $isEnabled = $element.GetCurrentPropertyValue($AutomationElement::IsEnabledProperty) if ($isEnabled -eq "True") { break } } while (((Get-Date).Ticks - $startTime) -le ($Timeout * 10000)) if ($isEnabled -ne "True") { throw "指定された要素 '${Identifier}' が有効状態になりません。" } if ($element.GetCurrentPropertyValue($AutomationElement::IsInvokePatternAvailableProperty) -eq "True") { $element.GetCurrentPattern($InvokePattern::Pattern).Invoke() } else { # IsInvokePatternAvailablePropertyがFalseの時はマウスカーソルを要素に移動して左クリックする $clickablePoint = $element.GetClickablePoint() $Cursor::Position = New-Object System.Drawing.Point($clickablePoint.X, $clickablePoint.Y) $MouseClick::Click() } } # キーボード操作をおこなう関数 function SendKeys { Param($RootWindowName = $null, $PropertyType, $Idendifier = $null, $Keys, $Timeout = 5000) if ($Idendifier -ne $null) { $element = FindElement -RootWindowName $RootWindowName -PropertyType $PropertyType -Identifier $Idendifier -Timeout $Timeout $element.SetFocus() } $SendKeys::SendWait($Keys) } # Microsoft EdgeでWebキャプチャの保存操作をおこなう関数 function SaveWebCaptureByMicrosoftEdge { SendKeys -Keys "^(+S)" ClickElement -PropertyType "AutomationIdProperty" -Identifier "view_52561" ClickElement -PropertyType "AutomationIdProperty" -Identifier "save_button_id" Start-Sleep -Seconds 3 SendKeys -Keys "{ESCAPE}" } # ↓↓↓↓↓ この行以降にアプリを自動操作するスクリプトを書く ↓↓↓↓↓ 次に「Windows PowerShell ISE」のスクリプトウィンドウに貼り付けます。 「ここで一度ファイルに保存しておこうかな」となるかもしれませんが、 ここでは保存しないでください。 ファイルに保存すると、PowerShellの実行ポリシーの設定によってはスクリプトが実行できなくなるためです。 PowerShellの実行ポリシーについてはあとで説明します。 電卓を自動操作するスクリプトをコピペして実行する では、Windowsアプリの自動操作の練習台として定番（？）の電卓を自動操作してみましょう。 「電卓を起動して、1から10までを足し算する操作」を自動操作してみます。 下記のスクリプトをコピーします。 ################################################################################ # 電卓を自動操作する ################################################################################ # 足し算する値の範囲を設定する $start = 1 $end = 10 # ボタンをクリックした後の待機ミリ秒を設定する $waitMilliseconds = 300 # 電卓アプリを開始する Start-Process calc -Wait # 電卓アプリを操作する foreach ($count in $start..$end) { # 数値を1桁ずつに分割する $array = $count.ToString().ToCharArray() # 電卓アプリの数値ボタンをクリックする foreach ($number in $array) { ClickElement -RootWindowName "電卓" -PropertyType "AutomationIdProperty" -Identifier "num${number}Button" Start-Sleep -Milliseconds $waitMilliseconds } # 現在のカウントで処理を分岐する if ($count -ne $end) { # 範囲の終わり以外の時は[＋]ボタンをクリックする ClickElement -RootWindowName "電卓" -PropertyType "AutomationIdProperty" -Identifier "plusButton" Start-Sleep -Milliseconds $waitMilliseconds } else { # 範囲の終わりの時は[＝]ボタンをクリックする ClickElement -RootWindowName "電卓" -PropertyType "AutomationIdProperty" -Identifier "equalButton" Start-Sleep -Milliseconds $waitMilliseconds } } 次に、スクリプトウィンドウの「141行目」に貼り付けます。 これで準備ができました。 では、ツールバーの緑色の「 ︎」（スクリプトを実行）ボタンを選択して、スクリプトを実行してみましょう。 電卓が起動して、1から10までを足し算する操作がおこなわれて、計算結果に55が表示されます。 操作間隔を空けずに自動操作する 実行したスクリプトは、自動操作の様子を確認しやすいように操作の間隔を空けています。 自動操作の間隔を空けずに実行するとどうなるか見てみましょう。 「1から10までの足し算」はあっと言う間に終わってしまいますので、ついでに足し算する範囲を「1から100まで」に変更してみましょう。 まず、スクリプトの147行目の「 $end = 10  」を「 $end = 100 」に編集します。 145 # 足し算する値の範囲を設定する 146 $start = 1 147 $end = 100 次に、スクリプトの150行目の「 $waitMilliseconds = 300 」を「 $waitMilliseconds = 0 」に編集します。 149 # ボタンをクリックした後の待機ミリ秒を設定する 150 $waitMilliseconds = 0 ツールバーの緑色の「 ︎」（スクリプトを実行）ボタンを選択して、スクリプトを実行してみましょう。なお、スクリプトの実行を途中で停止したい時は、ツールバーの赤色の「■」（操作の停止）ボタンを選択します。電卓が起動して、1から100までを足し算する操作が爆速でおこなわれて、計算結果に5050が表示されます。筆者の環境では、自動操作の間隔を空けた時の実行所要時間は「およそ1分50秒」で、間隔を開けない時の実行所要時間は「およそ15秒」でした。 Microsoft Edgeを自動操作するスクリプトをコピペして実行する 続いて、ブラウザを自動操作するスクリプトを紹介します。 ブラウザの自動操作は「Selenium」や「Autify」、「mabl」などの自動化ツールを使う方が多いかもしれませんが、ちょっとした操作であれば「UI オートメーション」でも自動操作することができます。 今回は「Microsoft Edgeを起動して、Bingのトップページを開いたあとに、検索とWebキャプチャを保存する操作をおこない、最後にダウンロードフォルダーを開く」操作を自動操作してみます。 「Microsoft Edge」を初めて使う場合は、初回実行時の設定が必要になりますので、一度「Microsoft Edge」を起動して初回実行時の設定を完了させておいてください。 また、アドレスバーに「edge://settings/downloads」を入力しEnterキーを押下して表示されるダウンロードの設定項目「ダウンロード時の動作を毎回確認する」が既定値の「オフ」になっていることを前提として自動操作しますので、設定を「オン」にしている場合は「オフ」に設定してください。 まず、電卓を自動操作するスクリプト（141行目から最後の行まで）を削除します。 次に、下記のスクリプトをコピーします。 ################################################################################ # Microsoft Edgeを自動操作する ################################################################################ # 検索する値を設定する $searchWords = @( 'フェンダー' 'ギブソン' 'ポール・リード・スミス' ) # ページ読み込み完了待ち秒数を設定する $pageLoadWaitSeconds = 3 # Microsoft Edgeを開始する Start-Process msedge -Wait # Microsoft Bingのトップページを開く SendKeys -PropertyType "AutomationIdProperty" -Idendifier "view_1020" -Keys "https://www.bing.com/{ENTER}" Start-Sleep -Seconds $pageLoadWaitSeconds # 「$searchWords」に記載されている値を検索してWebキャプチャを保存する $index = 0 foreach ($word in $searchWords) { # 2回目以降の検索時は検索ボックスの内容をクリアする if ($index -gt 0) { ClickElement -PropertyType "AutomationIdProperty" -Identifier "sb_form_q" ClickElement -PropertyType "AutomationIdProperty" -Identifier "sw_clx" Start-Sleep -Seconds 1 } # 検索ボックスに値を入力して検索する SendKeys -PropertyType "AutomationIdProperty" -Identifier "sb_form_q" -Keys "${word}{ENTER}" Start-Sleep -Seconds $pageLoadWaitSeconds # 1回目の検索時は画像リンクをクリックする if ($index -eq 0) { ClickElement -PropertyType "NameProperty" -Identifier "さらに表示" ClickElement -PropertyType "NameProperty" -Identifier "画像" Start-Sleep -Seconds $pageLoadWaitSeconds } # Webキャプチャを保存する SaveWebCaptureByMicrosoftEdge $index += 1 } # エクスプローラーでダウンロードフォルダーを開く explorer.exe $env:USERPROFILE\Downloads スクリプトウィンドウの「141行目」に貼り付けます。 なお、 145 # 検索する値を設定する 146 $searchWords = @( 147 'フェンダー' 148 'ギブソン' 149 'ポール・リード・スミス' 150 ) の「フェンダー」とかの文字列は、とりあえず適当に書いただけですので、他の文字列に編集してもよいです。 では、ツールバーの緑色の「 ︎」（スクリプトを実行）ボタンを選択して、スクリプトを実行しましょう。 Microsoft Edgeが起動してBingのトップページを開いたあとに、検索とWebキャプチャを保存する操作が繰り返しおこなわれ、最後にダウンロードフォルダーが開きます。 ※ うまく動かない時は、ツールバーの赤色の「■」（操作の停止）ボタンを選択してスクリプトを停止してください。 PowerShellの実行ポリシー 「 UIを自動操作するための土台となるスクリプトコピペする 」で、 ひとまずファイルに保存したくなるかもしれませんが、ここでは保存しないでください。 ファイルに保存すると、PowerShellの実行ポリシーの設定によってはスクリプトが実行できなくなるためです。 PowerShellの実行ポリシーについてはあとで説明します。 と書きましたが、ここでファイル保存した状態でスクリプトを実行してみましょう。 「Windows PowerShell ISE」ウィンドウのツールバーのフロッピーディスクアイコンのボタン（スクリプトを保存します）を選択します。（またはメニューバーから [ファイル] > [名前を付けて保存] を選択します。） 「名前を付けて保存」ダイアログが表示されたら、任意の場所・ファイル名で保存します。 では、ツールバーの緑色の「 ︎」（スクリプトを実行）ボタンを選択して、スクリプトを実行しましょう。 お使いの環境によりますが、PowerShellの実行ポリシーが「スクリプトの実行が許可されていない」ポリシーに設定されている場合は、悪意のあるスクリプトの実行を防止するための安全機能が働き「セキュリティ エラー」が発生して、スクリプトの実行が中断されます。 そこで今回は「今現在使用しているWindows PowerShell ISEのみスクリプトの実行を許可」してみます。 まず、コンソールウィンドウに下記を入力して実行します。 Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process すると、異様に横長なダイアログが表示されるので [すべて続行] を選択します。 これでファイル保存したスクリプトが実行できるようになりましたので、試しにもう一度ツールバーの緑色の「 ︎」（スクリプトを実行）ボタンを選択して、スクリプトを実行してみましょう。 今度は「セキュリティ エラー」が発生せずにスクリプトが実行されます。 今回は「今現在使用しているWindows PowerShell ISEのみスクリプトの実行を許可」しましたが、他に「現在のユーザーにスクリプトの実行を許可（-Scope CurrentUser）」したりすることができます。 もっと詳しく知りたい方は「 about_Execution_Policies 」をご参照ください。 さいごに 今回は自動化ツールをインストールしないで、Windowsに標準搭載されている「UI オートメーション」機能を使ってアプリを自動操作する方法を紹介しました。 ブラウザの自動操作は「 Microsoft Edgeを自動操作するスクリプトをコピペして実行する 」で書いたように各種自動化ツールを使う方が多いかもしれませんが、簡単な内容であれば今回体験したように、自動化ツールをインストールしなくても自動操作することができます。 これを機に、自動化に取り組んでみてはいかがでしょうか。 また「自動化ツールをインストールすることができない環境で自動化したい」という状況の時にも対応することができるようになりますので、頭の片隅に残しておいていただけると、いつか役に立つ時がくるかもしれません。 それではまた機会があれば。 The post UIオートメーション〜コピペで体験Windowsアプリの自動操作 first appeared on Sqripts .

はじめに みなさんは、「ブロックチェーン」という言葉を聞いたことがあるでしょうか？ ブロックチェーンとは、ビットコインやイーサリアムなどの「暗号資産」と呼ばれるデジタルな通貨や資産を実現するために使われている技術です。 暗号資産は、銀行の預金や企業発行の電子マネーなどとは異なり、暗号技術を用いて誰でも自由に通貨を発行できる点に特徴があります。暗号資産技術により、2023年4月現在までに、少なくとも9000種類（※1）を超える暗号資産が発行され、暗号資産取引所などで取引が行われています。 ブロックチェーンの技術的な特徴として、暗号資産などの取引データがすべて公開され、誰でもデータを閲覧したり、取引が正当なものかを検証したりできる点があります。例えば、2009年から稼働しているビットコインのブロックチェーンでは、稼働当時から現在までの「どのアカウントがどれくらいのビットコイン残高を持っているか」「過去どんな取引をしたか」といった情報を誰でも自由に閲覧できます（図1）。 図1. Blockchain.com で閲覧できるビットコインの取引データ例 こうしたブロックチェーン上のデータは【オンチェーンデータ】とも呼ばれ、パブリックなビッグデータとしての活用が検討されています。 ブロックチェーンの応用例は、暗号資産のような通貨や資産の送付や売買だけでなく、土地や建物などの物理的な資産と紐づく【デジタル資産】や、それらを対象とした【金融商品】、データの永続性を利用した【証明書サービス】、ゲーム内アイテムやコインを現実の資産として扱える【ブロックチェーンゲーム】など、さまざな分野やアプリケーションに広がりを見せています。 それとともに、オンチェーンデータとして利用できる情報源や活用の幅も広がってきています。 本連載では、ブロックチェーンの基本的な仕組みを解説しながら、オンチェーンデータを分析するための基本的な手法について、全8回で紹介します。 分析のためのツールとして、データべースやビッグデータのデータ処理のために広く使われている【SQL】と呼ばれるクエリ言語を利用します。これまでSQLを使ったことがない人も対象にして、初歩的な構文から実践的なテクニックまでを幅広く紹介していく予定です。 ブロックチェーンのオンチェーンデータ分析に興味がある人はもちろん、これからブロックチェーンを学びたい人や、SQLのスキルを身につけたい人にとっても役立つ情報を発信していきますので、ぜひご活用いただければ幸いです。 ※1 CoinMarketCap ブロックチェーンとは 本連載の第1回目では、ブロックチェーンの歴史について概観し、代表的なブロックチェーンの違いや関係性について紹介します。 ビットコインの誕生 2008年11月、サトシ・ナカモトを名乗る人物がビットコインと呼ばれる新しい電子通貨に関する論文を発表しました。翌2009年1月にはビットコインのソフトウェアが公開され、運用が開始されます。このビットコインを実現するために発明された中核技術が、のちにブロックチェーンと呼ばれています。 このとき投稿された論文（図2）は、PDFで9ページ程度の短い文章であり、現在 bitcoin.org にて各言語に翻訳されて公開されているため、興味のある方はぜひ読んでみてください。 図2. Bitcoin: A Peer-to-Peer Electronic Cash System ビットコインの技術的な解説は本連載の第2回目以降の記事に譲るとして、今回はその社会的受容の歴史について紹介します。 ビットコイン受容の歴史 ビットコインの論文は、サトシ・ナカモトによって暗号理論に関するメーリングリスト（※2）に投稿されましたが、メーリングリストのメンバーからは懐疑的な反応が寄せられました。ビットコインのアイデアは、単に数学的なアプローチで証明できるものではなく、「ビットコインの運用に関わる実際のユーザーたちがどのように行動するか」といった経済学的な側面や、「世界規模の自律的分散システムが正常に動作し続けられるか」といったコンピュータサイエンス的な側面が複雑に絡み合っており、想像だけで理解することが難しいものだったためです。 そこで、サトシ・ナカモトは、実際に動作するシステムのコードを作成し、アイデアに賛同してくれたメンバー間でそのシステムを動かしてみることにしました。いくつかのバグ修正のあと、そのシステムは動作を開始し、約10分に1回のペースで、新しいビットコインが「採掘」され、メンバーの間で送金しあえる新しい電子通貨が誕生しました。 当初、この新しい電子通貨には全く価値が付いていない単なる電子データでした。そこで、ビットコインのアイデアに賛同する人たちは、ビットコインを通貨として流通させるため、ビットコインを現実のお金で取引できるサービス（※3）を公開しました。新しいビットコインを採掘するためには、ある程度の計算パワーが必要だったため、その計算にかかる電気代をベースとして、1ドルあたり1,000 BTC前後で取引が開始されはじめました。 ビットコインと現実の通貨が交換できるようになると、次第にそのユースケースが登場していきます。特に世間から注目を浴びた例として、2010年11月に起きたWikiLeaksスキャンダルや、2011年頃のシルクロードという取引サイトへの糾弾が挙げられます。 WikiLeaksによってアメリカの外交機密文書が公開された事件が発生した際、WikiLeaksに対する制裁として、PayPalを用いたWikiLeaksに対する送金が停止されたり、WikiLeaks創設者の銀行口座が凍結されたりといったことが行われました。WikiLeaksの是非は別として、特定の民間企業によって資産の移動を凍結されてしまう事態に対して反発が起こり、一方でビットコインを用いたWikiLeaksへの募金は止められなかったため、「送金の自由を誰にも止めることができない」というビットコインの性質に注目が集まりました（※4）。 また、シルクロードというサイトでは、匿名で送金が可能なビットコインを用いて違法な薬物が取引されていたり、マネーロンダリングに悪用されていたりする実態が糾弾されましたが、それらのニュースを通じてビットコインへの関心も高まり、2011年には1 BTCが30ドル以上で取引されるなど、最初のビットコインバブルを迎えました。 ※2: Satoshi’s posts to Cryptography mailing list ※3: New Liberty Standard ※4: Could the Wikileaks Scandal Lead to New Virtual Currency? ※5: Schumer Pushes to Shut Down Online Drug Marketplace アルトコインの誕生 ビットコインへの関心の高まりとともに、ビットコインの仕組みを流用した新たな暗号資産も登場し始めます。ビットコインの採掘や送金は、約10分に1回行われるブロック生成ごとにおこなわれますが、この間隔を短くして高速にトランザクションを実行できるようにした「ライトコイン」（※6）や、ビットコインにDNSの機能を付加した「ネームコイン」（※7）など、さまざな改良や改変をおこなったコインが発行されました。これらを総称して、「アルトコイン」と呼ばれます。 初期のアルトコインは、ビットコインのプログラムをフォーク（コピー）してきて、必要な改変をおこなったあと、賛同者たちでその改変プログラムを実行する形で発行されました。しかしこのやり方は、新しいコインの発行や維持する賛同者たちを多く集める必要があり、ハードルの高いものでした。 そこで、新たにプログラムをフォークして動かすことなく、より簡単に独自のコインを発行できるプラットフォームとして、Mastercoin(Omni)（※8）やCounterparty（※9）なども登場しはじめました。 ※6: Litecoin ※7: Namecoin ※8: Omni Layer ※9: Counterparty イーサリアムの誕生 ビットコインに続いてさまざまなアルトコインが登場する中で、大きな転換点となったのが、2015年のイーサリアム（※10）の登場です。 ビットコインをベースとした派生コインの多くは、あらかじめ決められた送金処理などを実行することはできますが、その表現力は限定的でした。そこでイーサリアムは、ビットコインが発明したブロックチェーンという仕組みを拡張し、ブロックチェーンの上で汎用的なプログラムを実行するためのプラットフォームの実現を目指しました。 イーサリアムを用いることで、ユーザーはわずか数十行のプログラムを記述してデプロイするだけで、独自の暗号資産をブロックチェーン上で実現することができるようになりました。 このように、新たな暗号資産を発行するハードルが劇的に下がる一方で、成功した暗号資産は初期の値段から数百倍～数万倍の価値に跳ね上がることも珍しくなく、一つのプロジェクトで数億円～数百億円の資金調達が実現されるなど、多くの投資資金が暗号資産に流入していきました。 ※10: Ethereum DApps, NFT, DeFiの誕生 イーサリアムを用いると、独自の暗号資産の発行だけでなく、汎用的なプログラムそのものをブロックチェーン上で動かすこともできるようになりました。 例えば、ある既存の暗号資産と、自身で発行した独自の暗号資産を交換するために、どこかの取引所サービスでその暗号資産を取り扱ってもらう必要はなく、イーサリアム上のプログラムで自動的に暗号資産同士の交換をおこなうことができます。そのような、ブロックチェーン上の取引所をDecentralized Exchange（DEX）と呼びます。 また、暗号資産を用いたギャンブルのようなサービスをブロックチェーン上で動かすこともできますし、より複雑なゲームロジックを実装することも可能です。 イーサリアム上のプログラムはスマートコントラクトと呼ばれ、スマートコントラクトを用いたアプリケーションはDecentralized Apps（DApps）とも呼ばれます。 イーサリアム上でさまざまなスマートコントラクトが開発されるようになると、類似の用途のコントラクトは共通規格化して統一的に扱いたくなります。そのような統一規格として、Fungible Token（FT）と呼ばれるトークン規格であるERC20や、Non-Fungible Token（NFT）と呼ばれるトークン規格であるERC721などが策定され、次第にイーサリアム上でDAppsを開発するエコシステムが整っていきました。 さまざまなDAppsの中で、特に影響の大きかったサービスの類型として、Decentralized Finance（DeFi）サービスが挙げられます。DeFiとは、大まかには暗号資産を対象とした金融商品を実装したり取引したりできるDAppsサービスの総称です。DeFiの登場により、将来価格が上がりそうな暗号資産に投資をするだけでなく、保有している暗号資産を誰かに貸し出して金利を得たり、複数の暗号資産のデリバティブ取引を組み合わせてリスクヘッジをしたりといった資産運用を、銀行や証券取引所を介することなくブロックチェーン上で行うことができるようになりました。 DeFiを用いた暗号資産の運用は、年利10%から数百%を上回ることもあり、より多くの投資資金を集めるきっかけとなりました。 ポスト・イーサリアム争い～現在 ビットコインやイーサリアムの歴史は、これまで説明したような成功や進歩の歴史だけでなく、違法取引やマネーロンダリング、消費者被害、環境への悪影響など、さまざまな負の側面も持っています。 短い紙面ですべての課題を解説することはできませんが、ここではイーサリアムの技術的課題と解決へのアプローチの潮流について簡単に紹介します。 さまざまなDAppsサービスがイーサリアム上で開発・運用されるとともに、ブロックチェーンのスケーラビリティ問題が深刻化していきました。 スケーラビリティとは、システムが処理すべきタスクの増大に対して対処可能な特性のことです。一般的な分散システムでは、システムを構成するノードを追加していくことで、タスクを分散処理してシステム全体の処理能力が向上できるようなアプローチを取ります。 しかし、古典的なブロックチェーンのアーキテクチャでは、いくらシステムを構成するノードを追加しても、システム全体として処理できるタスク量は増加しません。初期のイーサリアムの仕組みでは、秒間10-20トランザクションを処理することが限界でした。VISAクレジットカードのネットワークが秒間24,000トランザクションを処理可能（※11）であることと比較すると、イーサリアムのパフォーマンスは世界規模のトランザクションを処理する性能を満たせていません。 このスケーラビリティ問題は、2023年現在でも解決できていない課題の一つですが、大きく分けて２つの潮流があります。 一つは、スケーラビリティを兼ね備えた新しいブロックチェーンプラットフォームサービスを開発し、イーサリアムを超えていこうとする潮流です。代表的なプロジェクトとして、Solana（※12）やPolkadot（※13）などが挙げられます。イーサリアムの直面した課題をゼロベースで解決していこうとする場合が多く、必ずしもイーサリアムと互換性を保っているわけではありません。 もう一つは、既存のイーサリアムをLayer-1として、その下位に位置するLayer-2チェーンを接続し、イーサリアム自体にスケーラビリティ特性を付加しようとする潮流です。代表的なプロジェクトとして、Arbitrum（※14）やOptimism（※15）、zkSync（※16）などが挙げられます。 これらの技術はまだまだ発展途上であり、暗号資産の時価総額から考えても、ビットコイン、イーサリアムに続く第3のブロックチェーンサービスは流動的です。 本連載の中では、数あるブロックチェーンサービスの中でもある程度の地位を固めたと考えられるビットコインとイーサリアムについて、それぞれのオンチェーンデータを深掘りしていく予定です。 ※11: Visa ※12: Solana ※13 Polkadot ※14: Arbitrum ※15: Optimism ※16: zkSync オンチェーンデータ分析のすすめ 最後に、データ分析のスキルを学ぶ上で、オンチェーンデータが題材として適していると筆者が考えているメリットをまとめます。 まず、データ分析するために使えるリアルなデータが、誰でもアクセスできる状態で豊富に蓄積されている点がメリットとして挙げられます。 多くのサービスで蓄積されているデータの権利は、そのサービスを運用している企業や団体に帰属しており、一部の例外を除いて自由に閲覧したり活用したりできる状態にはありません。そうしたサービスのダミーデータを生成して練習することもできますが、人為的に生成されたデータと、実サービスで多くの人々によって蓄積されたデータとでは、得られる情報量に大きな違いがあります。 また、オンチェーン分析のためのツール群が充実している点も、初学者にとっては大きなメリットとなります。 例えば、Google BigQueryでは、ビットコインやイーサリアムなどの主要なブロックチェーンのトランザクションデータが、パブリックデータセットとして簡単にアクセス可能な状態で提供されています（※17）。ブロックチェーンデータ分析のための専門ツールを提供しているDune Analytics（※18）では、イーサリアムのトランザクションデータに対してSQLを用いて集計したり、ダッシュボードとして可視化したりする機能を無料で提供しています。 これらのサービスを用いることで、環境構築やデータの準備にほとんど時間をかけることなく、低コストでデータ分析の演習を始めることができます。 さらに、ブロックチェーンを用いたサービスを提供している企業や団体の多くは、こうしたオンチェーン分析に対する需要も高く、学習からコミュニティへの貢献までの距離感が非常に近いこともメリットとして挙げられます。 一般的な業界では、SQLを数週間から数ヶ月程度学んだ人が、いきなり実践的な成果を出せるケースは多くないでしょう。一方、ブロックチェーン界隈の現状では、プロジェクトの数に対してオンチェーン分析を行えるスキルを持った人材が圧倒的に不足しているため、初学者であっても実践的な成果を出すチャンスが多くあります。 ブロックチェーンサービスのエコシステムでは、オンチェーン分析の成果に対してグラントのような報酬を設定しているプロダクトも多く存在しているため、そういったグラントの獲得を目標に設定して学習するというのも、モチベーションを維持するために有効な手段です。 今回の記事でオンチェーン分析に興味を持っていただいた方は、ぜひ第2回～8回の記事も参考にしていただき、ブロックチェーンに対する理解やSQLのスキルを磨いていただければ幸いです。 ※17: Google Cloud Datasets ※18: Dune Analytics The post 【第1回】ブロックチェーンとは first appeared on Sqripts .

みなさん、こんにちは！　QA事業本部のゆーすけです。 JSTQB CBT試験みなさん受けてますかっ！？（前回と同じ入り方） ついに、テストアナリストのCBT開始の連絡もありましたね、しかもテストアナリストはPBTやテストマネージャーCBTとは異なり、「3年間の業務経験」という条件がなくなっていますので、より現場に近い資格になったんじゃないかな、と思います。 また、年内には ・アジャイルテスト担当者 ・自動車ソフトウェアテストテスト担当者 ・テスト自動化エンジニア も開始予定とのことなので、自分もそろそろアジャイルテストと自動化エンジニアの勉強を再開しようかと思っているところです！（自動車はPBTで取得済み） ということで、JSTQBの学習のススメ連載の6回目となります！ ▼1～4回のおさらいです！ 1回目 JSTQBってなんだろう？→Foundation Levelから始めよう 2回目 Foundation Levelの構成ってどうなっているんだろう？ 3回目 テスト基礎について 4回目 テストのライフサイクルについて 5回目 静的テスト 　 JSTQB Foundation Levelの構成は以下のようになっていて、6回目の今回はみんな大好きテスト技法について触れていきたいと思います。 １：テストの基礎 ２：ソフトウェア開発ライフサイクル全体を通してのテスト ３：静的テスト　 ４：テスト技法　　　←今回はココ ５：テストマネジメント ６：テスト支援ツール テスト技法って？ テストを効率的かつ効果的に進めるための考え方、アプローチ方法ととらえると分かりやすいかもしれません。シラバスにも記載されていますが、テス技法ありきでテストを考えるのではなく様々な要因のもと正しくテスト技法の取捨選択、適用範囲を決めていることが大事になります。 プロダクトの性質上、適用できない/適用しても効果的ではない、というテスト技法もあるので、技法の特性特色はここで適切に把握するようにしていきましょう。 FLシラバスでは、動的テストの「ブラックボックス」「ホワイトボックス」「経験ベース」の3つに分類しています。以前の記事にも使ったテスト図に付け加えると以下のようなかたちになります。 ブラックボックスのテスト技法 上の図とは順番が異なりますが、シラバス記載の順序通りにブラックボックステストの技法から簡単に触れていきましょう。 同値分割 同値はデータの処理からグループ分け（同値クラス化）をする考え方です。 例えば、数字入力のフォームにて、 ・0～50 ・51～100 ・101～ の入力結果において異なる処理が行われる場合、上記の3つカテゴリが有効同値クラスとなります。 テストを行う際は、同値内の中央値を使用くするのが一般的と言われています。 境界値分析 境界値分析はIPAなどでは限界値分析とも呼ばれます。 コーディングにおいて、”＞”（大なり）、”＜”（小なり）と、“≧”（大なりイコール）、”≦”（小なりイコール）を取り間違える、というのはありそうでなさそうだけど、実際はありえる分かりやすいコーディングミスの一つです。想像することのできるコーディングミスで、最も単純でその割に影響度が果てしなく大きいので、出来れば重要な数値周りは境界値の観点でテストを行い、「問題ない」というお墨付きをもらっておきたいところですよね。 ※設計書上で数字の分岐定義、統一がされていない、「以上以下」と「より未満」が入り混じるようなものは要注意です。 先ほどの同値分割と同じ数字でいうと、 ・0～50 ・51～100 ・101～ 0、50、51、100、101が境界値分析として取り扱うべきテスト対象となります。 ※境界値として2値をとる、という方針になった場合。3値の場合は0、49、50、51、99、100、101が対象となります。 同値と境界値の関係を簡単な図にすると以下のようになります。 デシジョンテーブル 決定表とも呼ばれるテスト手法で、デシジョンテーブルのことを取り上げた記事もあります。 いまさらデシジョンテーブルというものを考えてみた | Sqripts 上の記事にも記載していますが、テストケースを省略できるパターン、省略できないパターン、デシジョンテーブルではなく原因結果グラフが適切な場合などいろいろ考えられますが、Foundation Levelではまずは簡単なテスト条件からテーブルを作成できれば問題ないと思います。 デシジョンテーブル記事の再掲となりますが、 　想定： 　　映画館のチケット割引サービス 　 　仕様： 　　通常金額1900円 　 　割引システム： 　　ファーストデイ：毎月1日はだれでも1200円 　　レディースデイ：毎週水曜日は女性なら1200円 という条件があった場合、以下のようなテーブルが作られます。 条件からデシジョンテーブルを作ってみる、という内容はJSTQB ALテストアナリストや、IVEC（IT検証技術者認定試験）でも頻出しているので、自分で条件を考えて実際に数回テーブルを作ってみる、というのがいいと思います。 状態遷移テスト これまた別ブログ記事参照で申し訳ないですが、状態遷移を取り上げた記事がありますので、より深く知りたい方はこちらを参考にしてみるといいかもしれません。 幅広いソフトウェアとテストレベルで適用可能な状態遷移テスト | Sqripts 状態遷移テストは、「状態遷移図」または「状態遷移表」を作って考えます。 それぞれの特色としては、 　状態遷移表：無効値も含めて考えるため、仕様の抜け漏れに気づきやすい 　状態遷移図：フロー図で表すため、遷移が視覚的に分かりやすい ということがあります。 状態遷移テストはJSTQB ALテストアナリストでも引き続き掘り下げられていく手法のため、FLの段階でしっかりと状態遷移図、状態遷移表のどちらも作れるようにしていきましょう。 ※JSTQBテストアナリスト試験では、状態遷移図を作ってNスイッチカバレッジを求めよ、というのが頻出傾向でしたが、最新PBTではなくなった、という嘆きの声もあるようです。 ※嘆きの声が書かれた記事がこちら シラバス改定後初のJSTQB ALTA試験受けてきた #1 | Sqripts ユースケーステスト まずはシラバスから抜粋すると ソフトウェアアイテムとの相互作用の設計方法であり、テストケースは、ユースケースから導出可能である。 ユースケースには、ソフトウェア機能の要件が盛り込まれている。 （省略） 各ユースケースは、1 つのサブジェクトと 1 つ以上のアクターとの相互作用による振る舞いを明確にす る（UML 2.5.1 2017） と記載されています。 つまりユースケースは、ソフトウェア機能要件（要件定義～詳細設計）で定義されたものがテストベースとなります。 ただし、ユースケーステストをISTQB GLOSSARYで調べると ブラックボックステスト技法の一つ。ユースケースの動作を実行するようにテストケースを設計する。 同義語：ユーザシナリオテスト、シナリオテスト と記載されているので、ユースケース図をテストベースとしたテストだけではなく、ユーザーを想定した一連のテストを丸めて呼んでいる、代表的な例としてユースケース図をベースに作成する、とざっくりとした理解でもFLの段階ではいいと思います。 このあたりはSWEBOK-SQuBOKや、ISO/IEC/IEEE 29119など、他の学習を取り入れ、そのうえで自分の中でのユースケース定義、シナリオテスト定義などをしっかりと定め、認識齟齬なくテスト活動を行っていく、ということが重要なところとなります。 ちなみにシラバスにも記載されているユースケースにおける、サブジェクトとアクターはこのように表せます。 なんと次回に続く…… 今回テスト技法を「ブラックボックス」「ホワイトボックス」「経験ベース」の3つを取り上げる予定でしたが、3つ全て取り上げるとかなりのボリュームになりそうなので、今回はブラックボックスだけの内容として、残りの2つは次回にまわしたいと思います。 次回はなるべく早めに掲載できるよう頑張りますので引き続きお付き合いいただけますよう何卒宜しくお願いいたします！！ The post JSTQB学習のススメ #6 〜Foundation〜 first appeared on Sqripts .

はじめまして、AGESTクオリティマネージメント部の坂本です。 今回は弊社が新たに開始するコード解析サービスについてご紹介したいと思います。 QA for Development QA for Developmentとは「開発のための品質保証」を実現するAGESTの新しいソリューションです。「不確実性が高い時代のモノづくり」の品質課題にオールインワンで向き合うため、AGESTは開発×テストの二刀流のノウハウを持った”次世代QAエンジニア”による新しい価値提供を行います。 今回ご紹介するコード解析サービスは、こちらの新ソリューション「QA for Development」のサービスのひとつです。どのようなものか、どのようなメリットがあるのか、また具体的な進め方や成果物についてご紹介します。QA for Developmentについての詳細は下記のページをご覧ください。 QA for Development コード解析サービス サービス概要 コード解析サービスとは、コード品質にお悩みのお客さまのソースコードを様々な観点から解析、品質を計測し、改善点を検出・作成するサービスです。 当サービスにより問題（指摘事項）やコード量の傾向等が可視化され、コードの問題箇所が見えてきます。また、問題箇所への最適な対応もご提案するため、結果として問題が減少し、クリーンなコードになることが期待できます。また継続的なコード品質の維持についても考えますので、一度受けて終わり、ではなく受けたあともコード品質をあげる仕組みができます。 ( ※1 ) コード品質とは 一言にコード品質といっても様々な観点が存在します。 たとえば下記の観点があります。 1.保守性 コードのメンテナンスのしやすさを表します。 　a.可読性 　変数やメソッド、クラス等への適切な命名、シンプルなロジックを作成する等で向上します。 　b.テスト容易性 　クラス、メソッドへの適切な責務の割り当てをする等で向上します。 　c.変更しやすさ 　定数を利用する、コードを重複させない、グローバル変数を使わない等で向上します。 2.再利用性 コード（モジュール、クラス）の再利用のしやすさを表します。適切な責務の割り当て、モジュール分割によって向上します。適当にクラスやメソッドを作成しているといらない機能が入っていたり、変に特化している部分があったりして再利用できないことがよくあります。 3.効率性 CPU利用やメモリ消費の多寡を表します。無駄なファイル入出力、メモリ確保をなくしたり、DBであればインデックスが効くようにクエリを発行する等で向上します。多くの場合プログラム実行速度に直結します。 4.移植性 プログラムを異なる環境に移植した際に動作させる容易さを表します。CPUやOS、ミドルウェア等に依存したコード（改行コードのべた書き、特定のDBにしか存在しない命令等）を減らすことで向上します。 5.信頼性 エラーへの強さを表します。具体的には例外的な入力があってもデータが壊れない、エラーが発生した場合フェイルセーフな動作をする等があります。例外的な場面に備えた処理を実装することで向上します。このようにコード品質には様々な面があり、プロジェクトによって注力するべきところも変わってきます。 低品質コードのリスク 前項で記載したなかでプロジェクトに必要な観点を満たしている割合が低いものを品質の低いコードということができます。それではそもそもコードの品質が低いと、誰がどう困るのでしょうか。 例えば下図のような、作業への影響、その結果として起こりうるリスクがあげられます。 テスタビリティの低下 テストがしにくくなることで、コードカバレッジやテストケースの漏れが発生し、欠陥検出率が低下します。その結果、市場不具合が発生し、顧客に損害が発生する、自社の信頼を失う等の影響が発生します。またプロジェクトもテストがスムーズに実施できないことで進捗遅れが発生します。 メンテナンス性の低下 メンテナンスがしにくくなることで、不具合修正の難易度が上がり、デグレードの発生確率が上がります。また機能追加・変更をする際にも影響範囲の広さや再利用性の低さからコストが増えます。 移植性の低下 移植性が低下すると異なる環境でソフトウェアを利用したいとなった際、修正が必要な箇所が増え、コストが増大します。 可読性の低下 可読性が低下するとコード解析の難易度が上がります。結果として不具合修正や改修時のコストが増えます。また意図を理解できずにロジックを修正した結果、欠陥を埋め込んでしまうリスクもあります。 対策 低品質コードは様々な工程で問題を引き起こします。そのため低品質コードを生み出さないことが大切です。対策も様々ですがたとえば下記のようなものが考えられます。 コードレビューを実施する 有識者によるコードレビューを行うことで、問題のあるコードを検知し、修正することが可能です。ただしすべてを見るにはコストが高く、プロジェクトの状況によっては難しいことも多々あります。またレビューアのスキルに依存するため、効果はその時々で大きく変わってきます。 静的コード解析を実施する Linterといわれる静的コード解析ツールやSonarQubeを利用した解析を行い、コードの問題箇所をリストアップできます。リストアップされた指摘を精査していき、問題箇所を修正することでコードの品質を向上させることが可能です。ただし環境・言語によっては導入が難しいことがあります。また警告の量が多く、些細な指摘に埋もれてクリティカルなものに気づかないことも起きえます。 コードメトリクスを計測する コードメトリクスを計測し、その結果をもとにレビューを実施したり、クオリティゲートを設定したりすることで、効率よくコード品質の低下を防ぐことができます。メトリクスにはステップ数、循環的複雑度（Cyclomatic Complexity）、継承の深さ、クラス結合度等、様々なものが存在します。プロジェクトの特性や言語によって利用するものを選定します。 静的コード解析とは 静的コード解析 (せいてきコードかいせき、static code analysis) または静的プログラム解析 (static program analysis)とは、コンピュータのソフトウェアの解析手法の一種であり、実行ファイルを実行することなく解析を行うこと。   静的コード解析 – Wikipedia コーディング規約違反やリソースの解放忘れ、到達不能コード等数多くの問題を指摘してくれるものです。CIに組み込んで違反コードをマージさせないような仕組みにすることもあります。 コードメトリクスとは コード メトリックスとは、開発者が開発中のコードをより理解できるようにする、ソフトウェアの一連の基準です。   コード メトリックを計算する – Visual Studio (Windows) | Microsoft Learn LOC(コード行数)、循環的複雑度(Cyclomatic Complexity)、CKメトリクス(オブジェクト指向言語用のメトリクス群)等、数多くのメトリクスが存在します。 コード上の複雑な箇所を見つけたり、多くの箇所から利用されているものを見つけたりするようなことが可能です。 コード解析サービスを利用するメリット 低品質コードの対策としては前項であげたものがありますが、それまでやっていなかった場合は実際にやるとなるとどうすればいいのかわからず、とりあえずやってみたけど特に得るものもなく徒労に終わるといったこともあります。 そういった場合にはノウハウを持った専門家に依頼することが有効です。 弊社のコード解析サービスはまさにこの対策を提供するものです。 サービスを利用するメリットとしては下記があげられます。 専門家がコード解析、それを受けた改善点のご提案するため、効果をあげやすい 外部の目が入ることで、新しい観点のレビューが実施される 自社で実施した場合にかかる工数が大幅に削減される 静的解析の結果は些細なものがフィルタリングされるため、重要なものにのみ集中できる メトリクスの閾値に適切なものが設定できる プロジェクトにマッチしたCI/CDへの導入方法がわかる(※1) 一度サービスを受けた後は実施した作業・メトリクス計測・閾値設定を継続、改良するだけでコード品質維持が可能になる。他のプロジェクトにも適用しやすくなる。 特に下記のようなことにお悩みのお客さまにおすすめです。 上流工程で品質を担保していきたい 静的コード解析を導入したいが方針が決まらない、導入したが成果が見えない コードメトリクスによるクオリティゲートを設定したいが何をどんな基準で設定すればいいかわからない 不具合が大量に発生してしまっていて手を打つ必要がある 今後もコード品質を向上させていきたい 下図は改善後イメージです。 コード解析サービスの進め方 それでは実際にコード解析サービスがどのように進められていくのかご紹介します。 おおまかなフローとしては下図のようになります。 1.事前準備 まずは対象プロジェクトの状況、課題のヒアリング、目標ヒアリング・設定をします。その後プロジェクト環境に適用可能な商用ソフトウェア、OSS等の調査、インストールを実施していきます。実はここが一番大変だったりします。OSSも玉石混交で、思うように動作しないものも多くあり、利用するソフトの調査に時間と手間がかかります。またお客さまのビルド環境が特殊だったりすると急激に適用できる商用ソフトウェア、OSSが減り、どうしようもないときはOSSをカスタマイズしたりちょっとした補助ツールを作成したりといったこともあります。 2.ソースコードの受領 git等のリポジトリからcloneしたり、プロジェクトフォルダをコピーいただいたり、基本的にはビルド可能なプロジェクトの全ソースをご連携いただきます。解析の中にはビルドしないと解析できないものも存在するためです。 ここでまずはビルド、テストが通るかの確認をします。 3.各解析の実施 下記を実施します。 　a.コードリーディング 　メトリクス計測の結果や、ヒアリング結果から要注意の箇所を確認していきます。コーディングルールがどうなっているか、重複コードがないか、バッドプラクティスのコードがないか等を確認します。 　b.静的コード解析 　SonarQubeやlinter等を利用し静的コード解析を実施します。独自環境であればそれに組み入れられるよう手順を構築します。 　c.メトリクス計測 　各言語ごとに利用可能なOSSや弊社ツールを利用し、必要なメトリクスを計測します。こちらも環境にあわせて手順を構築します。 4.解析結果の分析 解析結果を分析し、重要な指摘をリストアップ、整理していきます。指摘の傾向からどのようなところに注意が必要かを判断します。メトリクス計測した結果からはコードの状態をレポートします。複雑度等が事前に設定した閾値を超えている場合は何が問題なのかを分析します。また各メトリクスから不具合の発生しやすい要注意スポットを割り出します。ここもナレッジがないと難しいポイントとなります。 5.改善点、対応案の作成 指摘や具体的なコードの問題、メトリクスから改善点、対応案を作成し、レポートします。いま存在する問題点の解消と今後コード品質を維持するための施策を含めてご提案します。 6.CI/CDへの導入提案・支援( ※1 ) CIにツールを導入する必要があると考えられる場合にはそこへの導入提案・支援を実施します。継続的にコード品質を上げていく仕組みづくりを考えます。 レポート例 プロジェクトごとに内容は変わりますが、一例として下図のようなレポートを出します。 対象プロジェクトに合わせて設定したメトリクスと閾値にしたがって閾値を超えている箇所を可視化 プロジェクトのコード品質を可視化、またコード内の具体的な問題箇所についても整理し、改善案作成 まとめ 低品質コードは様々なリスクを発生させます。もしリスクが顕在化した際のダメージは甚大になりうるものです。それを避けるためには低品質コードを生み出さないことが重要です。コードレビューや静的コード解析、メトリクス計測等を実施し、コード品質を向上させていきましょう。上流工程の品質向上は後工程のコスト削減や市場不具合の減少につながっていきます。 もしコード品質が低く困っているがノウハウがなくどうすればよいかわからないというようなことがありましたら、ぜひ弊社へご相談ください。エキスパートがお客さまに最適な改善案をご提案します。 ※1 既存のCI/CDへの組み込み対応のみとなります。新規のCI/CD構築支援につきましては別途サービス開始予定となっております。 参考： コード解析 – 株式会社AGEST（アジェスト） The post コード解析サービスのご紹介 first appeared on Sqripts .

こんにちは、AGESTでエンジニアをしているやまたろうです。 皆さんは、FigmaやAdobeXDといったデザインツールをご存知でしょうか。Webシステム開発に携わっている方であれば、聞いたことがあったり、使っている方が多いと思います。 デザインツールという名前を聞くと「デザイナーのためのツール」という印象を持たれるかもしれません。（私も最初はそう思っていました）しかし、実際にエンジニアとしてデザインツールを使って得られたものは想像以上に大きかったので紹介させていただきます。 本記事は、筆者がメインで利用しているFigmaをベースにお話しします。 超高速なプロトタイピング 私はフロントエンド領域を得意とするエンジニアで、2日もあればTwitterのクローンアプリを作れる程度には自信があります。なので、実務でプロトタイプを作成する際はFirebaseやSPAフレームワークを駆使していました。また、デザインツールを活用したプロトタイプは、インタラクションの表現に乏しい「紙芝居」に近いものしか表現できないと思っていたため、実際にアプリケーションの利用イメージを伝えるためには、アプリケーションを開発してしまうことが確実であると考えていました。しかし、それは大きな誤りでした。 以下は、この記事のために作成したサンプルのログインページのイメージです。非常にシンプルな画面ですが、プログラム開発の場合、画面を作る時間に加えて、開発環境の構築やユーザーに触れてもらうためのホスティングなどの設定を行う必要があるため、短く見積もっても30分はかかります。しかし、Figmaを使用する場合は、それらの工程は必要ないため、5分もあれば作成することができます。 また、Figmaのコンポーネント機能を使用することで、状態や振る舞いを持ったUIパーツを定義することができます。そのため、懸念していた紙芝居のような印象を与えることはありません。むしろ、「もうアプリケーションを開発したの？」と勘違いされることのほうが多いです。 よくあるトグルスイッチ プログラムを書かずにコンテキストメニューを表示まで再現可能 その他、豊富なプラグインや無料で公開されているUI Kitを利用することで更に効率よくプロトタイプ/デザインを作成することができます。こちらはオススメが数多く存在するので実際に見たり触ったりして頂くのがよいと思います。 Figma Community 円滑なコミュニケーションの実現 今まではプロトタイプ修正後、デプロイしてからチャットやメールで変更した旨を共有していたのですが、Figmaであればリアルタイムでデザインやプロトタイプが変更されるのでコミュニケーションコストが大きく削減されました。 また、Figmaのコメント機能で修正すべき箇所に直接フィードバックが貰えるので、メンバー間で認識の齟齬が減ったように思います。 UIに直接フィードバックを受けることができるので、どこかを伝える必要がない ドキュメント作成の選択肢が増える 設計資料の中で言葉だけでは伝わりにくい箇所に図面を活用するのですが、Figmaで作成することが増えています。 以下は、Mermaidで作成した構成図を具体的にイメージを持ってもらうために簡略化やアイコンを追加してFigmaで作り直した例です。 Mermaidで作成したエンジニア向け資料 Biz向けFigma製の資料 一般的に、PowerPointを使って図面を作られている方が多いと思いますが、見た目に特化したツールではありませんし、Illustratorは学習コストや料金面で手が出しにくいため、私はFigmaやAdobeXDなどのツールを活用することをおすすめします。 見た目や資料の品質は別のスキルが必要になりますが、自由にデザイン・レイアウトを作れるのはデザインツールならではの長所だと思います。 さいごに 元々はデザイナーさんとのコミュニケーションのために触り始めたFigmaですが、使えば使うほどこのツールの汎用性の高さと洗練された機能に驚かされます。特に資料を作るのが苦手なエンジニアの方であれば十分な恩恵を得られると思うので、利用していない方は是非試してみてください！ それでは、よいFigmaライフを The post エンジニアでも使える！デザインツールFigmaがもたらす効果とは？ first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第1回目のテーマは、「アジャイル開発の過去、現在、未来を知ろう！」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 アジャイルの現在位置 アジャイル開発の現在・過去・未来～今を知り、源流を訪ね、先を見据える～ 上記の図は、平鍋健児さんという方が2010年に発表した『 アジャイル開発の現在・過去・未来～今を知り、源流を訪ね、先を見据える 』から引用した図です。アジャイル開発が生まれるまで、生まれてからの流れがとても良くわかるすばらしい資料なので、読み解いてみましょう。 アジャイル開発は2001年頃に生まれました。ただ、その前から様々な方法論がありました。たとえば、図の左上にある「EVO」、「FDD」、「Crystal」は、アジャイル開発が登場する前に生まれた開発手法です。 その下には「Patterns」や「TPS」が並んでおり、そこから「XP」につながっています。Patternsは、建築家クリストファー・アレグザンダーが考えたパターンランゲージが元になっています。パターン・ランゲージとは、「こういった場合だと、この方法がいい」といったパターンを解説したものです。この考え方をソフトウェア開発に取り入れたのがXP（エクストリーム・プログラミング）です。TPSはトヨタ生産方式（Toyota production system）です。TPSは日本企業であるトヨタが考えた手法で、もともとは自動車の生産に関係する方法論でしたが、XPだけでなくLean（リーン）やScrum（スクラム）など、様々なソフトウェア開発手法にも影響を与えています。 さまざまな流れは、現在主流になっているスクラムなどを巻き込みながら、「アジャイル開発」へとつながっていきます。 アジャイル開発が誕生した後にもさまざまな方法論や手法が登場しています。たとえばリーンスタートアップがきっかけになってリーンUXなど、リーンの考えをベースとした手法がいろいろ出てきました。また、さすがにXPやスクラムといった有名な手法を超えるものは少ないですが、DevOpsのような考え方も今では当たり前になってきています。 さらに、ソフトウェアの開発方法だけでなく、ソフトウェア開発における組織論、大規模開発などにもアジャイル開発の思想は広がっています。 アジャイルマニフェストの誕生 アジャイル開発は2001年に生まれたと書きましたが、その誕生には面白いストーリーがあります。 2001年、アメリカのソルトレイクシティに、開発手法に詳しい17人が集まり議論を行いました。当時は会議室が見つからず、しかたなく空いていたスキーリゾートを予約して集まったそうです。 その議論の結果、「アジャイルソフトウェア開発宣言（通称：アジャイルマニフェスト」が誕生しました。このアジャイルマニフェストの誕生が、アジャイル開発の誕生となっています。アジャイルマニフェストは、以下のような1枚のWebページで公開されています。 アジャイルソフトウェア開発宣言 この時の様子は、アジャイルマニフェストの背景にも描かれています。背景をみると、ホワイトボードのようなものの前に、幾人かの男性が集まって話し合っている姿があります。ひとりはこちらを向いて、ホワイトボードのどこかを指差しているように見えます。おそらく、こちらを向いている人は、書籍『リファクタリング』などで有名なマーティン・ファウラー氏です。それ以外の背を向けているメンバーも、スノーバードに集まった17人の方法論者です。 また、アジャイルマニフェストの下側には、集まった17人の署名があります。名前を見てみると、世界初のWikiを開発したワード・カニンガム氏や、エクストリーム・プログラミングの生みの親であるケント・ベック氏、スクラムの生みの親であるジェフサザーランド氏なども名を連ねています。 様々な言語に翻訳されたアジャイルマニフェスト アジャイルマニフェストは、わずか10行の文章でしかありません。しかし、このわずか10行のテキストが世界中へと広がり、今では一般的に使われる手法へとなりました。その証拠に、アジャイルマニフェストのページを下にスライドさせていくと、他の言語に翻訳されたページへのリンクが並んでいるのがわかります。この記事を書いている時点では、68の言語に翻訳されているようです。 当時のスノーバードの様子。おそらく世界で一番有名なホワイトボードではないでしょうか？ アジャイル開発の10年、20年 毎年アメリカで開催されるアジャイルカンファレンスは、世界最大のアジャイル開発に関するカンファレンスです。 アジャイルマニフェスト誕生10年を祝うイベント。マイクを持っているのは書籍『アジャイルプロジェクトマネジメント』の著者ジム・ハイスミス氏 2011年は、アジャイルマニフェストが誕生して10年たった記念すべき年でした。その誕生を祝して、アジャイルカンファレンスにおいて、特別なイベントが開催されました。 イベントのテーマは「Back to where it all began. Back to the future」です。日本語に訳すと「すべてのはじまりの場所に帰ろう。そして未来へと進もう」という内容で、ケント・ベック氏を除く16人の署名者が集まり、当時を振り返りました。このときのレポートは、 アジャイルマニフェスト署名者たちが再会する「The Big Park Bench」～Agile 2011 Conference に書いたので、当時の熱気を感じたい方はぜひ一読ください。 現在では、アメリカだけでなく、ヨーロッパでも1000人規模のイベントが行われています。もちろん国内でもたくさんのイベントや勉強会、コミュニティが生まれています。日本語に訳された書籍だけでなく、日本語の書籍もたくさん登場しました。アジャイルマニフェストは、現在も広がり続けているのです。 アジャイルマニフェスト20周年となる2021年にも、誕生を祝うイベントがありました。残念ながら、コロナ禍だったのでオンラインイベントとなりましたが、数人の署名者がスノーバードのホワイトボード前に集まるイベントでした。こちらも 動画が公開されている ので、ご興味があればぜひご確認ください。 アジャイル開発の現在と未来 アジャイル開発の現在から未来を見ていきましょう。この数年のニュースを調べてみると、現在に至るまで、アジャイルの広がりがよくわかります。海外に目を向けてみると、 80％以上の企業がアジャイル開発を取り入れている というデータもあります。 ただ、アジャイル開発はその国の文化にも影響を受けており、日本や香港の場合、ウォーターフォールのような従来型の手法が根強いため、なかなかアジャイル開発の導入が進まないケースもあるようです。 では、なぜ、ここまでアジャイル開発がメインストリームとなったのでしょうか？ その理由はいくつかありますが、まず、変化の激しい時代になったからでしょう。作れば作るほど売れる時代から、消費者ですら何がほしいかわかっていない時代になっているため、消費者のニーズを掘り当てながら進んでいく開発が必要になりました。 また、技術の進化もアジャイル開発に影響を与えています。たとえば、クラウド・仮想化・コンテナといった技術は、開発にスピードや柔軟性といった恩恵を開発者に与えました。手軽に使えるサービスや技術を活用しながら、よりアジャイルに開発ができるようになってきています。 最後に、アジャイル開発が成熟したこともあげられます。アジャイル開発はその名の通り、ソフトウェア開発が中心の理論でしたが、プロダクトマネジメントやビジネス、あらゆる仕事にその考え方が浸透し、広がっています。もうアジャイル開発はソフトウェア開発だけのものではなくなってきています。 これらの状況をふまえて、アジャイル開発の未来をちょっとだけ考えてみると、アジャイル開発はプロダクトマネジメント、テストや品質などを中心に議論が進んできています。この10年でアジャイル開発は当たり前になりました。ニューノーマル（新たな常識）と言えるかもしれません。さらに10年でプロダクトマネジメントやテストや品質分野が成熟していく可能性を秘めています。 さらに、アジャイル開発の拡大を元に、組織やスケールが課題になりつつあります。よって、アジャイル開発に対応するために、企業レベルの変化が求められていく可能性もあります。 The post 第1回 アジャイル開発の過去、現在、未来を知ろう！ first appeared on Sqripts .

はじめまして、QAコンサルタントのヤスゴロウです。今回は私の経験に基づくテストのアプローチ方法をご紹介させていただきます。 テストベースがないシステム テストベース ( ※1 ) 昨今のシステム開発事情 デジタル化が進んだ昨今では新規システム構築は稀で、既存システムのマイグレーションや既存システムの改修・保守開発( ※2 ）が多いと感じております。例えば、システム利用者のフィードバックを受け、改善のための改修・保守開発を繰り返してサービス向上やユーザビリティ向上等をおこなっているようなケースです。 こういった背景の中、弊社へいただくQAコンサルタントやテスト実施のご相談は、既存システムの不具合に悩まされている場合が多い気がしております。 しかもその既存システムに対して改修・保守開発を繰り返しているうちに、サブシステムが増えたり機能間の関係や仕様が複雑になったりする等の理由で、現在の開発担当者が全仕様を把握できていない状況をお見かけすることがあります。 とはいえ、競争の激しい現代においてビジネスを成功するためには、改修・保守開発をスピーディかつ不具合なく実施しなければいけないという使命があるため、大変な世の中だなと改めて思ってしまいます。 私も前職で15年程SE/PGや開発PMに従事しておりましたので、システム開発に携わっている方々の痛みに共感しております。 また、改修・保守開発は長期に渡っている場合があるため、ずっと同じ担当者が開発しているとは限らず、有識者の退職により全仕様を把握している方がいないというようなことはよくあることです。 このような事情から ・改修箇所の影響範囲の特定がうまくできない。 ・隠れ仕様に気づかず、設計、実装、テストの考慮漏れが発生する。 等の原因で本番障害が発生し、既存システムの品質改善や品質向上に悩みを抱えている企業様もいらっしゃいます。現代は避けたくても避けられない道なのかもしれません。 なぜテストベースがない場合があるのか 前述のような昨今のシステム開発事情より、テストベースとなるシステムの最新ドキュメントがない理由は大きく2つあると私は解釈しております。 1.引継ぎ情報不足 長期に渡り改修・保守開発を繰り返していると、開発担当者の入れ替えがあり、引継ぎがうまくできないケースがあると思います。 システムが大きくなればなるほど全仕様を理解することが難しいため、既存ドキュメントを改修する知識が不足し、また正しく更新する自信がないことにより、その時の改修箇所（差分）のみしかドキュメントを書かなくなってしまうのではないかと思います。 2.時間 ビジネスの機会損失を避けるためにシステムリリースのスピードを優先することがあります。動くもの（プログラム）は必須で新しくなっていきますが、そのベースとなる要件定義書や設計書等のドキュメント修正は「時間がないため後回し」にしてしまう場合があります。後で修正しようと思っていても、次のリリースの開発に追われ、ずっと修正できなくなってしまうケースもあると考えます。 また、ちょっとした改修の場合は、簡単なメモ程度で仕様を決めて済ましてしまう場合もあるかもしれません。理想は既存システムのドキュメントを更新して常時最新仕様を理解できるドキュメントを保持することですが、上記のような理由によりドキュメントを最新化できなくなっているのではないでしょうか。 テストベースが無いとどう困るのか 改修・保守開発を繰り返しているシステムにはテストベースとなる最新ドキュメントがない場合があることをお話してきました。では、なぜQA担当者はテストベースが無いと困るのでしょうか。 テストを実行するためには、まずシステムの正しい仕様を理解する必要があります。そして仕様に沿ってテストケースを作成し、「何を以って合格とするか」の基準となる「期待する結果」を定義する必要があるため、そのよりどころとなる情報が無いということになってしまいます。 特に、第三者検証の会社にテストを依頼する場合は、仕様を把握するためのテストベースとなる最新ドキュメントが原則必要となります。 必要なテストベースは実施するテストレベル( ※3 )にもよりますが、例えば利用者目線で業務の流れを一通りテストしてほしいというご依頼であれば、業務フローや業務ルール（処理の分岐条件等）を理解できるドキュメントをご提供いただきたいです。ですが「テストを実施してほしいが、最新仕様を理解できるドキュメントは無いです」と言われてしまった場合、どうすればよいでしょうか？ どういうアプローチがあるか アプローチのアイディア 私が担当したWebサイトのプロジェクトでテストベースがなかった時のアプローチをご紹介します。 私はJSTQBで学んだ「テストオラクル( ※4 )」が使えるのではないかと考え、探してみることにしました。テストオラクルになりそうなものはないか調べた結果、以下3つのものを使用しました。 (1) Webサイト上に公開されている説明やFAQ (2) 運用担当者やシステム管理者向けの業務マニュアル (3) 過去の障害事例 テストオラクルを使ってみる まずは、「利用者に公開している(1)Webサイト上に公開されている説明やFAQの通りに動作しなければ不具合である」とする作戦が良いと考えました。幸いお客様にも良いアイディアだと言っていただけたので、早速テストエンジニアに実践してもらいました。残念ながら(2)は最新なのか分からないものが多かったのですが、Webサイト上に書いていない条件分岐になる業務ルールは正解と見立てて参考にしました。(3)からはテストしたい業務に関係する実際にあった障害をピックアップし、障害が発生した画面操作手順や業務の流れを理解して、テスト条件や期待する結果を検討するための参考にしました。 設計書等のドキュメントに書かれた仕様通りに開発されていることだけが正解ではなく、Webサイト上で利用者向けに告知していることが期待通りにできなければNGにしようと考えたら、あとは意外とスムーズに進みました。 テスト設計の具体例 では、どのようなテスト設計の考え方があるのか一例としてECサイトを例にご紹介させていただきます。皆さんもECサイトで買い物をすることがあるかと思いますが、注意して読んでみると以下のような「業務ルール」と思われることが書かれている場合が多いです。 ・XXXX円以上購入すると送料無料 ・当月XXXXX円以上購入すると翌月顧客ランクアップ ・離島など地域によって特別送料を課金 ・配送方法（種類）を選択 ・決済方法（種類）を選択 ・在庫切れの場合 ・到着前にキャンセルする場合 ・返品する場合 等です。 前述の「(1)Webサイト上に公開されている説明やFAQ」を読み込むと、たくさんの業務ルールがあることに気が付きます。業務ルールを デシジョンテーブル のようなマトリクス表に整理するとテストケースを作成できるようになります。 具体的なイメージをもっていただくために以下に簡単な例を挙げさせていただきます。 例）ECサイトで送料無料になる条件 ・顧客ランクがプラチナの場合 ・顧客ランクがゴールドの場合、かつ１注文あたりの購入金額が5000円以上の場合 ・顧客ランクがシルバーの場合、かつ１注文あたりの購入金額が10000円以上の場合 得られるテスト結果の例（メリット） 私もプロジェクトにおいて、前述のような考え方でテストオラクルから業務ルールを洗い出してテストケースを作成し、テストを実行したら、それなりに不具合を挙げることができました。不具合を一覧にしてシステムの有識者に確認していただいた結果、「サイト上に公開されている説明やFAQ」の方が誤っている場合もあり、サイト上の表記を修正することで、品質向上につながりました。。 その他、長期に渡り立ち止まることなく改修・保守開発を繰り返しているシステムの品質を認識できる良い機会にもなりました。「思っていた以上に潜在不具合があったのだね・・・」というような感想をいただくこともありました。また、最新のテスト設計書ができあがったことにより、システムの有識者以外の方が仕様理解に活用できるようになりました。 まとめ ・長期に渡り改修・保守開発を続けている既存システムのテストはテストベースとなる最新ドキュメントがない場合が多く難易度が高いが、工夫すれば品質向上のための強化テストを実施することができる。 ・テストベースが無い場合は、いかに適切なテストオラクルを見つけ出して妥当な「期待する結果」を導出するかが重要である。 ・場合によっては仕様理解用のドキュメントとしてテスト設計書が利用できることもある。 今回ご紹介したWebサイトのようなフロントシステムの場合はテストオラクルが探しやすいと思いますが、目に見え辛いバックエンドシステムの場合にはどのようなテストオラクルを見つけ出せるのか、今後の課題として取り組んでいこうと考えております。 APPENDIX:用語の説明 ※1 テストベース 「テスト分析と設計のベースとして使用するあらゆる情報」（ ISTQB Glossary より引用）具体的には、以下のようなものである。 ・要件仕様。ビジネス要件、機能要件、システム要件、ユーザーストーリー、エピック、ユースケースの他、コンポーネントやシステムに期待される機能および非機能の動作を指定する類似の作業成果物などがある。 ・設計および実装情報。システムやソフトウェアに関するアーキテクチャー図もしくはドキュメント、設計仕様、コールフローグラフ、モデル図（UMLやER図など）、インターフェース仕様、コンポーネントもしくはシステムの構造を指定する類似の作業成果物などがある。 ・コンポーネントまたはシステム実装そのもの。コード、データベースのメタデータやクエリー、インターフェースなどがある。 ・リスク分析レポート。コンポーネントやシステムの機能、非機能、構造の各側面を考慮する。 出典： ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03 「1.4.2 テストの活動とタスク」 ※2 改修・保守開発 IPAのソフトウェアデータ白書 「表　開発プロジェクトの種別の選択基準」中段「スクラッチ開発」の「b:改修・保守」に該当する開発プロジェクト 出典： 独立行政法人情報処理推進機構 (IPA) 「ソフトウェア開発分析データ集2022」 2022年9月26日 発行 P.197 この表の通り、母体となる既存システムの規模に対して、どの程度「機能仕様の追加・変更があるか」により、開発プロジェクトの種別を判断してステークホルダー間で共通認識を持つことができる。 ※3 テストレベル 「具体的にインスタンス化したテストプロセス」（ ISTQB Glossary より引用）具体例としては、単体テスト、結合テスト、総合テストのようなテストプロセスの段階。 ※4 テストオラクル 「テスト対象のシステムの実行結果と比較する期待結果のソース」（ ISTQB Glossary より引用）　具体例としては、実在するベンチマーク用のシステム、他のソフトウェア、ユーザーマニュアル、個人の専門知識等など。コードであってはならないと言われている。 The post テストベースがないシステムの不具合を見つけるアプローチ first appeared on Sqripts .

はじめに 旅が大好きな、いしだぁぁです！ 私は、現在ソフトウェアテストとはかけ離れたアノテーション（詳細は後述）に関わるプロジェクトに従事しており、ソフトウェアテストの経験は浅いですが、JSTQBのFL取得に向けた学習を行っています。 ソフトウェアテストを勉強していくうちに、アノテーションの作業プロセスは、ソフトウェアテストプロセスと類似していることが分かりました。 アノテーションの作業プロセスに、ソフトウェアテストプロセスを応用すれば、よりよいプロジェクトになれるのでは、とそう考えました。 まずは、ソフトウェアテストプロセスの良いところをどのように取り入れていけばよいのかと考えたとき、最初に頭に浮かんだのは「学ぶことは、模倣から始める」です。 「模倣」は、否定的に見られがちですが、個人的には、ただ真似るだけではなく、その中から工夫も改善も自然と生まれ、重要な要素であると考えています。 このテックブログを通して、アノテーションのようなソフトウェアテスト以外のプロジェクトでも、ソフトウェアテストの様々な仕組みや技法を知ることによって、プロジェクト成功への近道となるヒントがもらえるのではないか、と感じていただければ幸いです。 アノテーションとは！？ 「アノテーション」と聞くと、あまりなじみがなく、遠い存在だと感じる方が多数いらっしゃるかもしれません。 私もその中の一人でした。 アノテーションとは、英語で「注記・注釈」という意味であり、ITの分野では、対象となるデータの一つひとつに、タグやメタデータと呼ばれる情報の付与を行う作業です。 アノテーションの対象となるデータには、以下の３種類があります。 画像＆動画データ 音声データ テキストデータ より詳しく言うと・・・アノテーションとは、AI開発のプロセスにおける必須の通過点であり、機械学習に使われる教師データを作成する工程を指しています。 教師データって！？ 例えば、みかんの画像があったとします。 この画像を「みかん」とAIに認識させるためには、みかんの画像に「これはみかん！！」という情報を付与してAIに学習させる必要があります。学習用の画像それが教師データです！！この教師データをたくさん作り学習させることで、AIがみかんを認識できるようになります。 しかしながら…AIにみかんの画像だけを学習させればいいというわけではなく、同時に例えば「りんご」との違いも認識する必要があります。AIにみかんだけの画像ばかり学習させてしまったら・・・りんごの画像を見せたときに、りんごをみかんと認識してしまう可能性があります。そのため、りんごのデータも学習させる必要があります。そうすることで、AIはみかんとりんごの特徴の違いを認識できるようになります。 このように教師データを使った機械学習によって形作られたAIは・・・実は、ビジネスや日常生活等のあらゆる場面に潜んでいます。 「これは便利だ！」、「すごい・・・技術が進歩している！！」と思っていたそこのあなた。 それらのモノにはアノテーションを使った学習済みAIが組み込まれている可能性があり、ビジネスや日常生活などで直面する問題を解決する手助けとなっているかもしれません！ アノテーション作業自体はとてもシンプルですが、AIの教師データとなり、その品質がAIの動作に大きく影響を与えます。AIが正しく動作するように、一枚一枚丁寧に作業してあげる必要があります。ですので、 日々我々は「重要な役割を担っているんだ！」という使命感を持って 作業しています。 ソフトウェアテストとアノテーションの作業プロセスについて 書籍『ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応』（以下「ソフトウェアテスト教科書」と称する）に出会う前までは、アノテーションの作業プロセスについて深く考える機会がありませんでした。 ソフトウェアテストを勉強していくうちに、アノテーションの作業プロセスは「実行前作業」「実行時の作業」「完了作業」「全体を通して行われる作業」の4つに分類され明確になるのでは・・・と気付きました。さらに、アノテーションの作業プロセスには、ソフトウェアテストプロセスとの類似点があることにも気付きました。 何を隠そう、私はソフトウェアテスト教科書に出会う前までは・・・事前準備や納品等の事後作業もすべて「作業実行」に含まれると思っていました。つまり、アノテーションの作業プロセスは、「作業実行」1つのみであるというのが、私の最初の考えでした。お恥ずかしい限りです・・・ それでは、両方のプロセスの全体像を見ていきましょう。 ご覧の通り、両方とも「実行前作業」「実行時の作業」「完了作業」「全体を通して行われる作業」の4つに分類することが可能です。 私が現在担当しているプロジェクトについて、ソフトウェアテストプロセスと同じように整理することができました。 ソフトウェアテストとアノテーションのプロセスの類似点について つぎに両方の類似点に着目していきましょう。 プロセス/作業内容 ソフトウェアテスト アノテーション 実行前作業 テスト計画（開始基準の設定） ・テスト目的の決定＆共有 ・テスト範囲の決定　等々 作業前準備（開始基準の設定） ・作業目的の決定＆共有 ・作業範囲の決定　等々 実行時の作業 ・実行レポートへの反映 ・欠陥レポート作成、反映　等々 ・実行レポートへの反映 ・欠陥レポート作成、反映　等々 完了作業 ・テスト結果の報告　 　> 実行レポート提出 　> 欠陥レポート提出 ・テストウェアの整理 ・作業結果の報告 　> 実行レポート提出 　> 欠陥レポート提出 ・改善活動 　> 各レポートの整理整頓　等々 全体を通して行われる作業 ・進捗管理 ・終了基準等の達成状況の確認 ・進捗レポート作成＆提出　等々 ・進捗管理 ・各メンバーの目標値の達成状況の確認 ・進捗レポート作成＆提出　等々 ご覧の通り、プロセス内の作業内容にも多くの類似点があることがわかりました。 多くの類似点の存在を知ったことで、今ではプロジェクトでうまくいかないことがあったら、ソフトウェアテストプロセスや作業のやり方・良いところを模倣して参考にすればよいのだ！という安心感を持って進めることができています。 応用事例の紹介 それでは、実際にソフトウェアテストプロセスを、アノテーション作業プロセスに応用してみると、どのような効果が得られたか、いくつか応用事例を紹介します。 応用事例１「開始基準」の応用 ソフトウェアテスト教科書には、このように記載されています。 開始基準 「開始基準が満たされないままにテスト活動を開始すると、難易度が上がり、テスト時間が増え、コストも増え、リスクが高まります。」 アノテーションは、画像が驚くほど大量にあります。画像が何万枚もある中で、どこから作業を始めればよいか、どこまで作業をすればよいか、といったような迷いが出ないように事前に入念な準備が必要となります。 特に初めて作業するデータに着手する時は、開始基準の設定に多くの時間を費やすようにしています。例えば、トレーニングに要する時間や相互チェックの実施方法、頻度を事前にお客様と相談して決めておく必要があります。 トレーニングに要する時間 どれくらいできればよいか どこまでやるか 相互チェックの実施方法 全量チェックか、サンプリングチェックか どのくらいの頻度でやるか これらを考慮せずに作業を進めてしまうと、予想以上に工数がかかったり、手戻りが発生したりしてしまうという大変な思いをしたことがありました。 作業を円滑に進めるためには、開始基準を明確化し、お客様としっかり連携を行いながら、チーム内の情報共有を行うことがとても重要であると、毎回実感しています。 応用事例２「工数に影響する要因（人の特性）」の応用 ソフトウェアテスト教科書には、このように記載されています。 テスト工数に影響する要因（人の特性） テスト工数を見積もるためには、テスト工数の見積りに影響を与える要因を知っておく必要があります。考慮もれによるテスト工数の見積り誤りを防ぐためです。 見積りに影響を与えるものとして、テスト対象であるプロダクトの特性、開発プロセスの特性、人の特性、テスト結果などが挙げられます。 人には得意分野や不得意分野があり、それぞれの能力や実力には個人差があります。そのため、実際の作業に入る前に、各メンバーが十分にトレーニング期間を設けて、各メンバーの能力と実力を正確に把握することが必要となります。 各メンバー同士も作業に必要なスキルや知識を共有できますし、作業管理者も各メンバーの能力と実力に合わせた作業分担やスケジュールを立てられるようになります。 以上のように、工数に影響する要因として人の特性を把握することが、工数見積りの精度向上につながる重要な要素であると、毎回実感しています。 応用事例３「欠陥マネジメント」の応用 ソフトウェアテスト教科書には、このように記載されています。 欠陥マネジメント 欠陥は、検出時点から分類、修正、最終確認まで、きちんと追跡しなければなりません。その対策が終了するまでマネジメントできなければなりません。 欠陥をマネジメントするためには、発生したすべての欠陥を記録しなければなりません。 アノテーションミスを見つけることは重要ですが、それらをきちんと管理していかなければなりません。以前は適切に管理できておらず、記録が見つからない、同じ失敗を繰り返すなんてことがありました。今は記録を取り比較することで、優先順位を付けられますし、ミスの記録を参照することによって、将来的なミスの予防につなげられるようになっています。アノテーションミスの記録を残し活用することがとても重要であると、毎回実感しております。 以上、応用事例を３つ紹介しましたが、ソフトウェアテストプロセスを応用することで、 作業の効率が上がり、他の作業に割ける時間が増えるなど、様々な効果が生まれました！ 同時に、「学ぶことは模倣から始める」ということが大切であるとひしひしと感じました。 おわりに 最後になりましたが・・・ 今のプロジェクトをよりよいものにしていきたいという思いから始まった挑戦 　 ソフトウェアテストプロセスの他分野への応用 「学ぶことは、模倣から始める」 　「物事の上達は、模倣にあり」 うんうん、模倣だっていいさ。 まずは、模倣してみることから始めて改善に役立てたいと考え、ソフトウェアテスト教科書を読み込んで、とことん模倣してやろう！という気持ちで改善活動をスタートしました。 この改善活動によって、ソフトウェアテストプロセスとの類似点があるという新たな気付きや、模倣から始まり改善に役立てたという新発見をもたらしました。そして、応用事例で紹介したように様々な効果が得られ、業務改善に役立てることができました。 今回の学びは、ソフトウェアテストプロセスの中から、模範となるものを見つけて、そこから模倣して、改善に役立てるのが、私にとってプロジェクト成功への近道であるとわかったことでした。 教科書は読んで終わりではもったいないです！！ ソフトウェアテストプロセスの良いところを模倣して、改善活動してみませんか？ ひょっとしたら、ビジネスだけではなく日常生活シーンでも改善に役立って、心豊かな生活のヒントをもらえることがあるかもしれませんよ！？ 今回の活動を通して、「他分野へのソフトウェアテストのプロセスの応用」が利くということがわかりましたので、今後も試行錯誤を繰り返しながら改善活動を継続していきたいと思います。 皆さんもぜひ、模倣から始めて、新しいことに挑戦してみてはいかがでしょうか。 追伸 2月末、JSTQB認定テスト技術者資格 Foundation Level試験を受けてきました～さて、結果はいかに！？ 次回、試験結果・・・それとソフトウェアテスト経験が浅い私の勉強の進め方も紹介するので、お楽しみに♪ The post 模倣だっていいさ　挑戦してみた　ソフトウェアテストプロセスの他分野への応用 first appeared on Sqripts .

デバッグとは デバッグの語源や由来 デバッグという言葉は、不具合を表す「バグ（bug）」という言葉に由来するとされています。 実際にコンピュータに虫がはまり込んで故障を起こし、虫を取り除いたことにちなんで名付けられたと言われています。 デバッグの重要性 デバッグは、ソフトウェア開発の重要なプロセスの１つであり、プログラムが期待通りに動作しない場合に、その原因を特定し修正することです。デバッグが重要な理由は、ソフトウェアにバグがあると、それが原因でソフトウェアが正しく動作しなくなる（バグ）ことがあるためです。 例えば、予期せぬ動作が発生したり、データの損失、セキュリティ上の問題など、様々な問題が発生する可能性があります。そのような問題は、顧客やユーザーから不満やクレームが出ることがあり、企業の信頼性や評判に悪影響を与える可能性があります。そのため、デバッグはソフトウェア開発において欠かせない作業であり、十分な時間とリソースを費やすことが重要です。 デバッグとテストの違い デバッグとテストは関連性がありますが、異なるプロセスです。具体的に言うと、テストはソフトウェアの品質を評価するために、入力値や条件を変えながら繰り返し実行し、正常動作やエラーが発生しないことを確認するプロセスです。 一方、デバッグはテスト中に検出されたエラーを修正するために、エラーの原因を特定して、修正するプロセスです。つまり、テストとデバッグは密接に関連していますが、テストはソフトウェアの品質を確保するためのプロセスであり、デバッグはテスト中に検出されたエラーを修正するためのプロセスであると言えます。 デバッグのプロセス バグの発見 プログラムのバグは、さまざまな方法で発見できます。テスト段階、ユーザーからのフィードバック、エラーメッセージ、クラッシュやフリーズなどの動作異常などがそれに当たります。開発者自身がコードをレビューして問題を見つけることもできます。 さらに、自動テストツールを使ってバグを検出することもできます。自動テストツールは、テストスクリプトを作成して自動的にテストを実行し、ソフトウェアの動作を評価します。 また、静的解析ツールを使って、ソースコードの構文やロジックを解析し、潜在的なバグを検出することもできます。バグを発見するためには、多様な手法を駆使し、徹底的にテストを行うことが重要です。 バグの原因の特定と分析 バグが発見されたら、それを修正するためにバグの原因を特定し原因を分析する必要があります。バグの原因を特定するために、開発者はデバッグ技術を使用して問題を特定します。これには、デバッガーの使用、ログファイルの分析、コードのレビューなどが含まれます。 バグの原因を特定したら、原因を分析し、修正するための対策を検討する必要があります。バグが発生した環境を再現し、修正されたコードが望ましい結果を生成することを確認するために、テストを実行する必要があります。 バグの修正と検証 バグの修正には、バグが含まれるコードの変更が必要です。修正後には、テストを実行して、修正が正しく機能していることを確認する必要があります。テストは、単体テスト、結合テスト、システムテスト、受け入れテストなど、さまざまなレベルで行われます。また、コードの修正が予期せぬ影響を及ぼしていないかをテストするレグレッションテストもあります。 デバッグプロセスの成功には、開発者が良好なデバッグ技術を持っていることが不可欠です。また、デバッグ過程で生成される情報を分析し、問題の特定と解決策の検討を行うことが重要です。最終的に、バグの修正とテストが行われ、問題が解決されたことが確認されるまで、デバッグプロセスは続きます。 デバッグの手法 机上デバッグ 机上デバッグとは、プログラムのコードを読み込み、問題を予測し、推論する手法です。コードを熟知していることが前提となります。机上デバッグでは、コードのシミュレーションや手計算によって、プログラムの実行過程を想定し、問題を特定することができます。具体的には、変数の値の変化や制御フローの動きを手計算で追いながら、どこで問題が発生しているかを推論することができます。 机上デバッグは、デバッグの初期段階でよく使われますが、複雑なプログラムになるほど限界があるため、実際にプログラムを実行しながらデバッグする必要があります。 デバッガを使う デバッガを使うことで、実行中のプログラムの状態を見ることができます。デバッガを使って実行中のプログラムにブレークポイントを設定することで、特定の箇所で実行を止めることができます。ブレークポイントで実行を止めた後は、その時点での変数の値を確認したり、ステップ実行という機能を使って、1行ずつプログラムを実行しながら問題を特定することもできます。デバッガは、複雑なプログラムのデバッグに非常に有効であり、開発者にとって欠かせないツールの1つです。 デバッグを効率的に行う方法 設計書を確認し、仕様を把握する ソフトウェア開発においては、設計書に基づいてプログラムを作成します。プログラムに不備がある場合、設計書に不備がある可能性があります。そのため、設計書を確認し、仕様を把握することが重要です。 設計書は、ソフトウェアの全体像や各機能の詳細な仕様、ユーザーインターフェースの設計などが記載されているため、設計書を確認することで、プログラムがどのように動作するかを把握することができます。プログラムに問題がある場合、設計書を再度確認し、仕様が適切に反映されているかを確認することが重要です。 設計書の内容が不明確であったり、不備がある場合は、開発チーム内で議論を行い、問題を解決する必要があります。 わかりやすいプログラムを書く わかりやすく、コンパクトにまとめられたプログラムを書くことで、デバッグの効率が上がります。変数の名前を適切につけたり、処理をわかりやすく分割することで、デバッグがしやすくなります。 また、コメントを付けることで、プログラムの処理内容や意図が明確になり、デバッグがよりスムーズに進むでしょう。さらに、コーディング規約に従ってコードを書くことで、複数人での開発においてもコードの可読性が向上し、デバッグ作業が効率的に行えます。 ログを出力し確認できるようにしておく プログラムが実行される際に、ログを出力することで、プログラムの動きを確認することができます。ログを出力することで、特定の箇所でプログラムが異常終了したり、想定外の値が返されたりすることがわかります。 また、ログを出力することで、プログラムの動作を再現することができます。バグを再現することができれば、その原因を特定しやすくなります。ログを出力する際には、必要な情報だけを出力するように設定することが大切です。大量のログが出力されると、逆にデバッグの効率を下げてしまいます。 分割統治法 分割統治法は、問題を小さな部分の問題に分割し、それらを再帰的に解決していく手法です。大きな問題を小さな問題に分割することで、それぞれをより単純な問題として解決することができます。 例えば、ある関数において発生しているバグの原因を探したいが、処理が大きく複雑になってしまった場合、問題のある箇所とない箇所を分けることで問題箇所を絞り込んでいきます。 分割統治法は、アルゴリズムやデータ構造の設計にもよく用いられる手法です。 デバッグツール デバッグツールを利用するメリット・デメリット デバッグツールのメリット デバッグツールを利用すると、以下のようなメリットがあります。 プログラムの実行中にデータの値を確認できるため、プログラムの振る舞いをリアルタイムで確認できます。 デバッグツールは、プログラムの構造を理解するのに役立ちます。コードの一部分だけでなく、プログラム全体を俯瞰することができます。 デバッグツールは、コードの実行速度を計測することができます。これにより、プログラムのボトルネックを見つけることができます。 デバッグツールのデメリット デバッグツールを利用すると、以下のようなデメリットがあります。 デバッグツールは、プログラム実行時にリソースを消費するため、プログラムの速度が低下する可能性があります。 デバッグツールの操作方法を理解するまでに時間がかかる場合があります。 デバッグツールは、プログラムが動作している環境に依存するため、特定のプログラミング言語やプログラム実行環境に限定される場合があります。 代表的なデバッグツール 代表的なデバッグツールには、以下のようなものがあります。 Visual Studio Debugger：Microsoft Visual Studioに含まれるデバッグツール。C/C++やC#、Visual Basic.NETなどで書かれたプログラムのデバッグに使用されます。 Xdebug：PHPのデバッグツール。PHPスクリプトのデバッグやプロファイリングに使用されます。 WinDbg：Microsoft Windows上で動作するデバッグツール。Windowsのカーネルやドライバ、アプリケーションのデバッグに使用されます。 gdb（GNU Debugger）：UNIX系OS上で動作するデバッグツール。C言語やC++言語で書かれたプログラムのデバッグに使用されます。 Valgrind：Linux環境で動作するプロファイリングツール。メモリリークやプログラムの最適化に使用されます。 まとめ デバッグは、ソフトウェアの品質を維持するための重要なプロセスです。バグの発見方法には多様な手法があり、自動テストツールや静的解析ツールも使用できます。 デバッグの目的は、テストとは異なるプロセスで、テスト中に発見されたエラーを修正することです。バグを修正するためには、バグの原因を特定し、原因を分析する必要があります。プログラムの問題がある場合、まず設計書に不備があるかどうかを確認することが重要です。また、コードの品質を上げることでデバッグをしやすくすることが大切です。 デバッグをうまく活用してプログラム開発を行いましょう。 The post ソフトウェアプログラミングにおけるデバッグとは？ first appeared on Sqripts .

テスト駆動開発のスタイルを取り入れているもののテストのことはあまりよくわかっていないプログラマーと、テストへの熱い情熱をもちつつプログラマーの事情はわかっていないテスターとが、小さな障害の発見をきっかけとして出会い、役割の壁を崩しながら少しずつ協調するようになっていく、小さなお話です。 登場人物 プロ之 … プログラマー テス緒 … テスター 前回、テス緒さんとプロ之さんはそれぞれのリーダーから指摘を受け、プロダクトにとって大事なこと、チームにとって大事なことが何なのか考え直しました。そしていま調べている問題も大事なことだから、継続して調べようと2人で決意しました。 プログラマーが切り込む話 テス緒さんはテストチームリーダーと、プロ之さんは開発チームリーダーとそれぞれ交渉し、もうしばらくこの問題を追及していいことになりました。2人はそれぞれ自分の時間を使って調査を進め、これからお互いの発見を持ち寄って話し合うところです。 プロ之(以下、P)「total_hoursを更新する可能性がある箇所を、コールグラフを使って探したらAPIと画面合わせて4箇所ありました。APIはその先にUIがあるので、画面的には9箇所になります」 テス緒(以下、T)「えっそんなに？」 P「でも画面によっては他の項目を更新するだけなので、実際にtotal_hoursを変えられるのは4画面です」 T「あ、それならわかる」 P「4画面のどのパスもテストでカバーしているし、とりあえずおかしくは見えませんでした。ところがですね、念のためgrepしたら…」 T「ぐれーぷ？」 P「…リポジトリ横断して全検索したら、まったく別のアプリでtotal_hoursがヒットしました。更新していないバージョンで、どうやらIE対応のもののようです。現状稼働しているのか、よくわかりません」 プロ之さんはツールを駆使して、関係ありそうな箇所を絞り込みました。こうしたツールは開発中や、特にデバッグ時によく使うものです。 T「すごい！ よくそんな詳しく調べられたね」 P「基本的なことですよ」 T「ホームズみたい！」 P「カンバーバッチみたいですか？」プロ之さんの顔がちょっと嬉しそうになりました。 テス緒さんが「あ、ロバート・ダウニー・Jr.だと…」と言いかけるとプロ之さんの顔が曇ったので、あわてて話題を変えました。※1 ポイント: 問題の原因となり得る箇所を特定するために深く掘り下げるアプローチがある 開発者が原因追求に利用するツールはテストや調査でも利用価値がある ※1 著者はジェレミー・ブレット派です。 テスターが見逃さない話 テス緒さんはログを画面共有で表示しながら説明しました。「テストケースを増やすのはやめにして、表示がおかしいあたりのデータが登録されたときのログを500行くらい絞り込んで眺めたのね」 P「ただ眺めるんですか？」 T「他の仕事もあるからずっと眺めてたわけじゃないけど、ときどき引っ張り出してね。何度も見てると、だんだん“引っかかるな”って感じがしてきて、そうしたら！ 気がついたのよ」 P「ただ眺めるだけで？」 T「っていうか、絞り込んだログだけ眺めても何もわからなかったんだけど、別の条件にしたらログの出方が違っているのに気がついて。ほとんど同じなんだけど、あっちは”recorded”なのに、こっちは”record”になってて、スペルが違うでしょ。表示がおかしくなるのは、”record”って出ているときだけみたいで」 P「すごいですね。執念というか」 T「気になったから気にしてただけだけどね。これ、なんでだかわかる？」 ポイント: ログやデータなどを広範に調べ、問題の起きる条件を追求するアプローチもある 意味がわからなくても些細な違いや違和感を拾い上げると、突破口になることもある ついに問題を突き止めた！ プロ之さんは少し考えて答えました。「わかりませんが、調べればわかると思います。その部分はログの固定文言だと思われるので、検索すればすぐ見つかると思います」 プロ之さんはそう言いながらもうキーボードを叩いています。テス緒さんはプロ之さんがどう作業を進めるのか知りたくなって、画面共有してもらうように頼みました。 T「タイピングすごい速いんだね。あ、検索ってコマンドで実行するの？ いつも検索ツールを使ってるけど、そっちの方が早いね」 P「ログを検索するのとコードを検索するのは違いますよ。でも良かったらあとで教えます。それはともかく、ログに”recorded”ではなく”record”と出力する箇所が見つかりました。total_hours更新で絞り込むと…やった、1箇所だけです。それに…先ほどのIE用サービスの中です。これはビンゴですよ」 T「じゃあそのサービスを使っている画面を使えば、現象を再現できるかも！」 プロ之さんはIE用のサービスを手元の開発環境で立ち上げて、テス緒さんは以前に作ったテストケースを実行しました。数件実行したところで、テス緒さんが声を上げました。 「出た！ できた！ こっちの画面で入力して、あっちの画面だと9.9だけど、この画面は10.0になってる。やったよプロ之さん！ 突き止めたよ！」 「やりましたね。古いモジュールが原因だったんですね。おめでとうございます」プロ之さんは表情はあまり変えず、しかしいつもより早口で言いました。 テス緒さんはくちびるを尖らせて言いました。「何言ってるの、おめでとうなんてひとごとみたいに。プロ之さんと私で一緒にやりとげたんだから、もっと喜んで！ ほら、やったーって言って！ やったーって」 「確かにそうですね。私も嬉しいです。でもやったーと言う必要は…言わないといけないんですか？…はい、では、や、や、ヤッター」 こうして、テス緒さんがテスト中に発見した不思議な挙動の原因が判明しました。まだ開発環境で確認しただけなので、本番環境でも同じ結果になるか追加の確認が必要です。また原因がわかったら、修正して正しく動くようにすることになります。問題の性質によっては、修正が難しいことがあったり、影響が軽微なら修正不要と判断する場合もあります。プロ之さんは既に、どう修正を進めるのが良さそうか考え始めています。 2人はここでいったん作業を終えることにしました。1週間後にまた集まることにして、それまでに本番環境での確認を進めたり、IE対応サービスがなぜ最近修正されていないのか調べたりしてくることにしました。テス緒さんもプロ之さんも、大きな壁を乗り越えた充実感と自信に満ちあふれて、明るくセッションを終了しました。 ポイント: 開発者にもテスターにもそれぞれの直感があり、両方を組み合わせて使う おたがいのスキルや経験、人間性を尊重しあうと能力を発揮できる 真の問題とは？(次回に続く) テス緒さんはIE対応サービスを使うために、過去のテスト資料を調べていました。そこで見つけたテストケースには、なんと「IE対応終了のテスト」として、画面がすべて使えないと確認するテストケースが書いてありました。実際に試しても、本番環境ではIE対応サービスにアクセスできません。 テス緒さんは考えました。「(問題がある箇所を見つけたのに、アクセスできないんだったら実際には問題が起きるわけがない！ まったく違うところに問題があるのかなあ？ それじゃあ調べたのが全部ムダになってしまう。どうしよう…)」 同じ頃プロ之さんは先輩の開発メンバーから、IE対応は1年以上前に終了しており、サービスも停止していると教わっていました。それを聞いてプロ之さんも考えます。「(終了しているサービスなら問題は起き得ないし、修正しても意味はない。修正の検討は時間の無駄になった。ここまでの調査も無駄と言える。これ以上、時間を使う意味はない)」 本連載の次回では、2人がついに真の問題に到達し、連載も最終回となります。 The post 【テスターと開発者が上手に協力するには】第4回：立場を越えて問題を追及しよう first appeared on Sqripts .

こんにちは、エンジニアをしているタカです。 今回は 私が受けた アジャイルソフトウェア開発技術者試験の 受験レポートを記したいと思います。 アジャイルソフトウェア開発技術者検定試験とは アジャイルソフトウェア開発技術者検定試験 アジャイルソフトウェア開発技術者検定試験は、アジャイルソフトウェア開発に関する知識やスキルを認定するための検定試験です。 Lv1, Lv2がありますが、Lv1は受験するための条件は無く、アジャイル開発の基礎知識に関する問題が出題される入門的な位置づけです。 なお、検定試験は指定された全国の試験会場と日時での受験が可能です。 受けようと思ったきっかけ 直近のプロジェクトでスクラムマスターの役割で開発に携わっており、体系的な知識の整理に役立ちそうと感じたことや、現時点で会社の推奨資格に上げられていることもあり、受けてみようと考えました。 申込完了まで 受験申し込みは、公式サイトからリンクされているプロメトリックのサイトでプロメトリックIDを取得のうえ、試験日の3営業日前までに会場と時間を指定して申し込みを行います。 Lv1の場合、受験料金は11,000円（税込）でした。 申し込みが完了するとメールで確認証が送られてきますが、念の為、画面に表示された確認証を印刷しておきましょう。 学習 アジャイル検定公式テキスト が販売されており、体系的な知識を整理するためにも、こちらを購入して学習することをおすすめします。 プロジェクトでアジャイル開発に携わっている場合は、このテキスト以外に学習は特別必要ない印象でした。 ただし、本番試験は60問で合格条件が80%のため、単純計算で48問以上の正答が必要となります。 ミスを極力減らす必要があるため、XP、スクラムなどの様々なアジャイルのフレームワークの用語や考え方を知っておくと良いので、必要に応じて、アジャイルサムライなどの関連書籍も一読しておくと安心かと思います。 なお、試験内容については守秘義務があり、過去問題も出回っていませんが、公式テキストに演習問題が付いています。 試験当日の流れ 当日は、試験開始時間より前に集合時間が設けられており、その時間まで会場に向かい、確認証と、確認証記載の本人確認書類を提示して受付を済ませます。 私は会社近くの受験会場に申込み、徒歩で会場に向かったのですが、初めて行く場所だったので入り口を探すのに5分ほど迷い…結果的にギリギリの到着になりました。 どのような試験にも言えることですが、初めて行く場所には早め早めに付くように心がけていきましょう。 なお、集合時間に遅れた場合は受験ができないと明記されているので要注意です。 入室～試験中 時間になったら、指定される最低限の持ち物だけを持って入室します。 なお、ティッシュは持ち込みが許されており、鼻炎持ちの私には大変助かりました。 他の荷物はロッカーが準備されているので、そこにしまっておきます。 試験時間は60分で全て選択式となります。 時間は余る印象なので、問題と回答をよく読み、全て回答したらもう1周最初から読み込んで、ケアレスミスを無くすことを心がけていきましょう。 前述の通り問題内容はここでは掲載できませんが、私の結果は97点で合格でした。 試験が終了するとその場で結果が出るので、事前に指示された通りに退出し、受付の方に報告後に荷物を持って退出となります。 結果レポートはメールで受け取れ、後日合格証明書が送られます。 おわりに 今回の内容は以上となります。 Lv1試験はいつでも受けれる試験かつ難易度はそこまで高くないため、比較的受けやすい試験になります。 興味をお持ちの方の参考になれば幸いです。 The post アジャイルソフトウェア開発技術者検定Lv1 受験レポート first appeared on Sqripts .

こんにちは、見習いフロントエンドエンジニアのぱやぴです。 新卒として2022年4月に入社、9月に配属されもう早一年がたとうとしていることに驚きを隠せません。何より後輩が入ってくるということが最大の驚きです。 そこで今回は入社から執筆現在(4月)までの約1年間に何を行い、何ができるようになったのかを紹介したいと思います。 AGESTの新卒エンジニアはこういう感じなんだなと一つの例として見ていただければ幸いです。 はじめに まずは簡単に自分のプログラミング歴を紹介します。 情報系の大学を出ており、プログラミングはC言語を簡単に一通り学びました。 C言語を学ぶ中で再帰とポインタにトラウマを植え付けられ、在学中は正直プログラミングに苦手意識を持っていました。 新卒研修(4月 ～ 8月) AGESTは4月から8月末まで研修を行います。 インフラから開発、テストまで一通りを時間をかけて教えていただきました。 開発の研修ではHTML、PHP、JavaScriptを学びました。 Progateから始まり、いくつかの課題を通してコードの書き方や、コードを書く楽しさなどを学ぶことができました。 また、同期とお互いに教えあったりすることもあり、同期仲を深めると同時に技術について自信を持ちながら研修を進めることができました。 この研修で大学在学中に抱いていたプログラミングへの苦手意識を払拭することができ、9月の配属を迎えることができました。 配属(9月 ～ ) いざ、配属です。 ここから配属後研修でさらに深く技術について学ぶ機会をいただけました。 学んだ技術 配属後研修では主に以下二つの技術について学びました。 TypeScript 現在書いているコードの9割9分はTypeScriptを用いており、現在の自分の開発業務には欠かせないものです。研修ではJavaScriptは学びましたがTypeScriptは配属後から学び始めました。 型を考える大変さはありますが、そのおかげで得られる恩恵が大きく、日々TypeScriptとは喧嘩をしながら仲良く業務をしています。 React フロントエンジニアとしての第一歩を踏み出しました。 学べば学ぶほど奥の深さを実感し、Notion等今まで何も考えずに使っていたサービス等のコンポーネントに対して「すごいなこのコンポーネント…」となることが増えました。 まだまだ未熟ではありますが、少しずつ作れるものも増えてきており日々学びながら業務に向かっています。 それではそれぞれ詳しく何を行ったのか紹介していきます。 TypeScriptの学習(9月 ～ 11月) 行った内容は以下の3つでした。 APIの呼び出し Playwrightを用いたスクレイピング Slackbotの作成 それぞれ簡単に説明します。 APIの呼び出し TypeScriptとのファーストコンタクトでした。 ここでTypeScriptの基本的な書き方や実行方法、JavaScriptの違いを学びました。 実際にはAxiosを用いてRESAS APIの呼び出しを行うコードを書きました。 ここからAPI呼び出しの際の型との戦いの火ぶたが切られました。 RESAS APIとはRESASという地域経済分析システムのデータを取得することができるAPIです。 詳しくは以下のURLを確認してみてください。 RESAS-API – 地域経済分析システム（RESAS）のAPI提供情報 Playwrightを用いたスクレイピング 弊社はテストの会社ということもありPlaywrightの使い方について学びました。 TypeScriptの書き方に慣れつつ、DOMツリーの学習を踏まえてスクレイピングを行いました。 実際にはO’REILLYの書籍一覧から各書籍のURL、書籍名、表紙の画像URL、発行年月日、ページ数をローカルに保存するコードを書きました。 スクレイピングをする際はrobots.txtや利用規約などを確認し、サーバーに負荷をかけない程度に行いましょう。 Slackbotの作成 一通りTypeScriptを学ぶことができたため、社内用のSlackBot「デジタルコンシェルジュ こころちゃん」の開発を行いました。 以前出した記事 で当時に起きた問題とその解決について紹介をしているので良ければぜひ見てみて下さい。 ここではどちらかというとバックエンド寄りの実装をTypeScriptで行っていました。 GCPやGoogle APIのOAuth認証についても学ぶことができ、非常に勉強になりました。 (GitHubの利用) このSlackBotの開発からGitHubを用いた開発を行っており、同時にGitHubを用いた開発方法についても学ぶことができました。 Gitは取り返しのつかないことをしてしまいそうで怖いと感じていたのですが、今回のような一人のプロダクトで実際に触り動作を理解することで少しずつGitHubの使い方を知ることができ、便利さを改めて実感しました。これからもGitHubとはもっと仲良くしていきたいです。 この三か月の経験でTypeScript、GitHubの知識や開発経験を得ることができ、コードを書くことに自信が持てるようになりました。 Reactの学習(12月 ～ 現在) Reactの学習では主に以下の2つのことを行いました。 O’REILLYの「Reactハンズオンラーニング 第2版」 コンポーネントの作成 O’REILLYの「 Reactハンズオンラーニング 第2版 」 O’REILLYの書籍を一通り学習し、Reactの基礎を学びました。用いた書籍は以下のものです。 Reactハンズオンラーニング 第2版 この書籍はクラスコンポーネントではなく、最近の主流である関数コンポーネントの記述方法で書かれており、関数コンポーネントを用いたReactの書き方の基礎を学ぶことができました。 コンポーネントの作成 書籍で一通りReactを学ぶことができたのでいざ実践です。 他のコンポーネントライブラリも参考にしながらコンポーネントの作成について学び、主業務で開発しているサービスに使用するコンポーネントの作成を行いました。 仕様書をもとに、必要な機能を考え実装を行い、デザインを反映する形でコンポーネント開発を行い、自社のコンポーネントライブラリを充実させていきました。 また、ここでUI/UXやパフォーマンス、セキュリティ等フロントエンジニアとして必要な知識や技術を教えていただきフロントエンジニアとして第一歩を踏み出しました。 現在 現在は引き続きコンポーネント作成を通してReactについて学んでいます。 カレンダーや検索可能なマルチセレクトなど、ある程度複雑なコンポーネントの作成までできるようになりました。作れるものが増えてきていることを実感することで、楽しくフロントエンジニアとして学ぶことができています。 以下作ったコンポーネントの一部になります。 カレンダーコンポーネント マルチセレクトコンポーネント また、コンポーネントの作成の延長で、作成したコンポーネントを用いる機能の開発部分を任されることもあり、徐々にチームの一員として業務に参加することができています！ 終わりに 配属からの約一年間をさらっと振り返ってみました。思い返せばいろいろなことをやらせていただいており、非常に充実した半年間でした。 また、実装にあたって相談させていただけることが多く、先輩、上司の方には感謝の念に堪えません。 少し苦手意識を持っていたプログラミングも入社してからの一年で自信を持つことができ、自分自身の成長を感じました。四月から社会人初の後輩が入社してきますが、負けないようにこれからも成長し続けれればと思います。 これからも、かっこいいエンジニアになれるよう日々努力を続けていきます。 この記事が何かの参考になったら幸いです。 The post 新卒がエンジニアとしての一歩を踏み出すまで first appeared on Sqripts .

テストの自動化、特にE2Eテストの自動化を行ううえで、ツールの選定はとても悩ましい問題ではないでしょうか。 特に有償のツールを用いる場合、会社でお金を払ってライセンスの購入や契約をするわけなので、「なんとなく」や「有名だから」「他社が使っているから」では通りません。 OSS等の無料のツールを用いる場合は一見そうした説明責任からは無縁に見えますが、導入後にトラブルが起こった際には「選定の責任者」としての対応を迫られることになります。 いずれの場合も、ツール選定のプロセスを明示して組織内で合意をとる必要があります。そんなときによく用いられるのが、ツールの比較表です。筆者も過去テスト自動化のコンサルテーションを行っていた際には何度も作成しました。比較表があることで、他にも候補がある中でこんな項目を比較して選びました、という証拠にもなります。 そんなツール比較表ですが、使い方・結果の捉え方次第では、ツール選択に悪い影響を及ぼすこともあるのです。 本記事では、そんな比較表を用いたツール選定で失敗しないよう、活用方法や注意すべきポイントについて見ていきます。少しニッチな内容ですが、参考になれば嬉しいです。 なお、E2Eテストの定義については玉川さんの記事 E2Eテストの自動化を最速で成功させる秘訣 | Sqripts と同じとします。 ツール比較表とはどんなものか 本記事で扱う「ツール比較表」とはどういったものでしょうか？ 細かいフォーマットは作成者によって異なりますが、一般的には以下のようなものを指します。 一方の軸にツールの名称、もう一方の軸に比較したい項目を書き、交差するマスに○△✕や、直接情報を記載して作成します。 この表を埋めて、自分たちのニーズに最も合うツールを選ぶ、という使い方が一般的です。 比較表を用いて選定することの注意点 このツール比較表を作成すれば自分たちにあったツールが選択できると思われがちですが、いくつか気をつけなければいけないポイントがあります。 注意点１：比較表の陳腐化 昨今は「変化が早い時代」「開発サイクルの高速化」などとよく言われますが、これはテスト自動化ツールについても同様です。ツールを開発している各社は、自分たちのツールをよりよいものにすべく、日々機能追加や改善を行っています。 結果、ツール比較表を作成しても１週間後、１ヶ月後には内容が古くなっている可能性があります。しかし、各ツールの更新情報を常にチェックして比較表を最新に保つ、というのは現実的ではありません。そのため、ツール比較表の情報はどうしても古くなってしまいがちです。 まずこの点に注意が必要です。 注意点2：比較表には現れないポイントがある ツールの比較表の項目は、ツールの機能・スペックの比較になりがちです。これらももちろん大事ですが、一方で比較表には現れづらいけれども選定の材料になるポイントがいくつかあります。例えば以下が挙げられます。 使い勝手 サポートの質 開発・ユーザコミュニティの活発さ 使い勝手については主観も多分に含むため、単純な比較は困難です。これは後の項目でも触れますが、実際にトライアルをしてチーム内で意見を募ることで一定の判断ができます。 一方、サポートの質は短期のトライアルでは判断しづらい部分もあるかもしれません。トライアル前後のツール会社とのやりとりの際に、レスポンスの早さなどから間接的に推測することになります。最低限、何営業日以内に返事がくるか、サポートセンターがあれば国内か海外か、日本語でのやりとりがどの程度可能かなどは調べておきましょう。 また、特にOSSの場合は、開発の活発さやコミュニティの盛り上がり具合なども注意すべきです。具体的な線引きは難しいですが、GitHub等でツールのリポジトリを確認し、最終更新が “4 Years Ago”など古いものは注意が必要です。OSやブラウザ、使用している言語のバージョンアップに対応されない可能性が高いです。 注意点3:比較項目を挙げること自体にスキルが要る これが最も見逃されがちな点かもしれません。そもそも、 多種多様なテスト自動化ツールについての比較項目を挙げること自体に、一定のスキルが必要 です。 システムテスト自動化の知識や経験がない状態で比較表を作成すると、例えば「データ駆動テストが可能か」「オブジェクト管理の機能があるか」などを挙げるのは困難でしょう。これらの項目について調べるには、システムテスト自動化においてテストスクリプトのメンテナンス性が大事であること、メンテナンス性を高めるためのデザインパターンや機能があること、を知っていなければなりません。 もちろん、スキルが必要だからといって、すぐに身につくものではありません。大切なのは、テスト自動化についての知見が無い状態で作った比較表の信頼度はそれほど高くない、と理解をすることです。必要であれば、中立的な立場のテストベンダーやコンサルタントなど、テスト自動化の専門家にツール選定のアドバイスをもらうことも検討してみましょう。 ツール選定の基本的な考え方と比較表の活用方法 ここまでに述べた注意点に気をつけながら、実際のツール選定はどのように行なえばよいでしょうか。 大きくは以下の流れで進めましょう。 必須条件を満たすツールをリストアップする 比較表を作成しながら、2, 3のツールに絞る トライアルを行う それぞれ詳しく見ていきます。 1. 必須条件を満たすツールをリストアップする 最初から比較表を作って比べようとすると、手間がかかることがあります。そこで、まずは 選定対象を選定 する、ところからスタートしましょう。 この段階における「必須条件」とは、以下を指します。 テスト対象の操作・確認にツールが対応しているか 例：ツールからDBへのアクセスができるか、Edgeが操作できるか、Flutter製のモバイルアプリが操作できるか、など 社内のルールに対応できるか 例：SaaS使用不可、LDAP連携必須、など 上記の条件は、テスト対象やチームによらず必ずチェックすべきポイントです。ツールの対応については、これが満たされなければそもそもテスト自動化はできないため、機能や使い勝手の比較を行う必要がありません。また社内ルールへの対応についても、初期段階で調べておくべき重要なポイントになります。会社によってセキュリティチェックシートやツール・サービス利用時の導入条件などが設定されている場合があるので、確認をしておきましょう。 2. 比較表を作成しながら、2, 3のツールに絞る ツール候補をリストアップできたら、次は実際に比較表を作成しながら最終的には2つか3つ程度のツールに絞っていきます。 ここでいきなり比較項目を挙げていくのではなく、まずはテスト自動化の目的・ゴールから考えていきましょう。 テスト自動化の目的やゴールはさまざまで、チームによって異なると思います。 E2Eテストの自動化を最速で成功させる秘訣 | Sqripts などを参考に、チームの中で話し合ってみてください。 目的が見えてきたら、次はその目的が達成された際の、開発・テストの流れを想像してみてください。そこではシステムテストの自動化が行われているはずですが、誰がどのタイミングで自動テストを実行しているでしょうか。開発者か、QAエンジニアか。それともCIツールから自動実行しているでしょうか。自動テストの結果は誰が確認をして、テストが失敗（NG/Fail）していた場合は誰が原因の調査をしているでしょうか。 あえて回りくどい言い方をしましたが、大事なポイントは テストを自動化して運用している姿をイメージしてみましょう ということです。 そして、ツール比較表で比較すべきは、 自動テストの運用に必要な要素 です。 自動テストを作って動かすのが開発者なのかテストエンジニアなのかによって、ツールに求める要件は異なります。前者の場合は、プログラムを書いて自動化するタイプのツールが良いかもしれませんし、後者の場合はノーコードで自動化できるツールのほうが良いかもしれません。 自動テストの結果をチームのSlackで確認する運用がしたい、という場合は、Slackとの連携機能やWebhook対応などが比較項目になるでしょう。 このように、単純にツール間の機能有無を比較して「なんでもできそうな（○がいっぱいついている）ほうが良い」といってツールを選ぶのではなく、自分たちがテストを自動化して日々運用するのに必要な機能を持っているツールを選ぶことが大切です。 この点を意識して、意味のある比較項目を出すことができれば、そのツール比較表は有効なものになるでしょう。 3. トライアルを行う 前の段階で、ツールはほぼ絞られると思います。最後に必ず行っていただきたいのが、トライアルです。有償のツールでも、OSSのような無料のツールでも、必ず使い比べたうえで検討を行いましょう。 トライアルで確認するべき点はツールを絞る際と同じで、想定通りに運用ができるかどうか、が主になります。ツールの仕様上「可能」となっていることが、テスト対象との相性などで難しい、ということも稀にあるため、注意しておきましょう。 まとめ：比較表だけで選定するのではなく、あくまでも材料としての活用を心がけよう 本記事では、テスト自動化ツールの選定時によく用いられるツール比較表について、注意すべき点と活用方法についてご説明しました。 一番お伝えしたかったポイントはツール選定の流れにおける2番め、テスト自動化とその運用のイメージをもとに比較項目を考えましょう、という点です。この順番を意識していただければ、テスト自動化ツールの選定で大きく失敗することは無くなります。 今回はテスト自動化ツール全般に関わる選定方法でしたが、次回はここ数年導入事例が増えてきている「AI自動テストツール選定時の考え方」についてご紹介します。 The post テスト自動化ツールの選定【前編】～ツールの比較表をどう活用するか first appeared on Sqripts .

こんにちは。名古屋グループのとりです。 昨年まではリモートワークにする日が多く、静かな環境で集中できるかと思いきや、安物の椅子で座り心地が悪かったり、移動する事が無いので運動不足がストレスになったりと、やっぱり職場の方が仕事に集中できるなと思う今日この頃です。 私はWebやアプリの入力フォームに対して探索的テストを行う時、開発現場に居た時の経験から何か悪さできないかなとプログラム上誤動作を起こしそうな入力を試す事が多いのですが、同様の手段でデータベースを意図的に不正操作する方法をSQLインジェクションと呼びます。 システムの脆弱性診断を行っている現場寄りの内容ですが、仕様の穴になりやすい内容で機能テストを実施する現場でも理解しておいて損はないと思いますので、紹介します。 セキュリティ領域は非機能要件になるため、機能テストではカバーされない事がありますが、探索的テスト等の観点の1つとして取り入れると機能要件側でもリスクヘッジができて良い内容だと思います。 SQLインジェクションとは SQLインジェクションの説明ですが、まず名称に入ってるSQLから軽く説明します。 SQLというのは、データベースに対して命令を投げる際の問い合わせ言語の事です。 アプリケーションやWebシステムのサーバで動くプログラム上からデータベースにアクセスし処理を行う場合、SQL言語で組まれた命令を投げて目的のデータを取り出したり、書き換えを行ないます。 SQL例 SELECT * FROM 顧客マスタ WHERE ID = '01234567';  UPDATE 顧客マスタ SET パスワード = 'abcdefgh' WHERE ID = '01234567'; 上記例は基本的な構文となりますが、1つ目が顧客マスタからIDが「01234567」に該当するデータを返させる内容で、2つ目が顧客マスタ上でIDが「01234567」に該当するデータに対して、パスワードの情報を「abcdefgh」に書き換える内容になります。 Webサービスなどでユーザーが自身情報を画面に表示して参照する時、そしてパスワード変更を行う時を想定すればイメージしやすいと思います。 さて、次にSQLインジェクションの説明です。 WHERE ID = '〇〇〇〇' の「〇〇〇〇」は、処理を行う上で対象となるデータを特定する条件となりますが、この値は入力フォームに入力した値を、プログラム上そのまま当てはめている場合があります。 では、例えばその入力値がこんな値だったらどうなるでしょう。 例１ ■入力値 01234567' OR 'A' = 'A ■SQL SELECT * FROM 顧客マスタ WHERE ID = '01234567' OR 'A' = 'A'; フォームに入力する値としてはとてもおかしな値ですが、入力値に「’」を含めることによって生成されるSQL文では前後にシングルクォーテーション「’」がついてSQLの構文として成り立ってしまいます。SQLの内容としては、IDが「01234567」であるまたは「A」が「A」である条件に該当するデータを全て返せになります。「A」が「A」である事って、当たり前で意味のない指定の様ですが、こうする事により常に条件が真となり顧客マスタ上のすべてのデータが返されてしまいます。 例２ ■入力値 01234567'; UPDATE 顧客マスタ SET パスワード = 'abcdefgh' WHERE ID = ‘01234567 ■SQL SELECT * FROM 顧客マスタ WHERE ID = '01234567'; UPDATE 顧客マスタ SET パスワード = 'abcdefgh' WHERE ID = '01234567'; 上記の例では終了記号「;」を入力値に含ませ、続けてDBを操作する構文を入れることによって自由にDBのデータ書き換えなどが出来てしまう可能性があります。 こういったSQLの命令を悪用して不正動作を発生させる手法をSQLインジェクションと呼びます。 （入力フォームなどでSQLの構文の一部を注入（インジェクション）するという意味です） 実際にこの仕組みが使われて顧客情報が漏洩したなどの過去の事例は多いです。 テスト実施時に考慮すべき点 では、SQLインジェクションを防ぐ為、テストの実施者として考慮する点を2点挙げます。 （開発観点では他にも色々ありますが、テストの実施観点として絞っています） 入力値のバリデーション処理は行なわれているか ここで言うバリデーション処理とは、フォーム上で入力された値が仕様に沿った形式（文字数、文字のタイプ、文字列の形式など）となっているかプログラム側で確認し、外れている場合はエラーとして返す処理の事です。 （バリデーションテスト／妥当性確認試験とは、また言葉として別物なので注意） SQLで使用される「’」といった記号は、SQLインジェクションの様な問題が発生しない様に入力フォーム上にて入力不可の文字として設計される事が多いです。機能テストとして、その設計内容通りに入力がエラーとなる事を確認する事はとても重要です。 特に検索キーとなるIDといった入力は、入力制限は多いと思います。 記号に対してエスケープ処理は行なわれているか 入力値としてSQL構文で特殊な意味を持つ「’」といった記号を許可していても、エスケープ処理を施していれば問題ありません。エスケープ処理とは、エスケープ文字を組み合わせる事によってプログラム構文上で使われる記号であっても、文字データとして扱われる処理の事です。 エスケープ文字は使用されているDBシステムによって違い、例えばMySQLであれば「\」がエスケープ文字になります。 SQL例 UPDATE 顧客マスタ SET 備考 = ' 使用端末 'iPhone 14' ' WHERE ID = '01234567'; という様な「iPhone 14」を「’」で囲んだ情報で更新したい場合、このままでは「iPhone 14」が「’」の囲みから外れてSQL構文の一部と見做され構文エラーとなってしまいますが、 UPDATE 顧客マスタ SET 備考 = ' 使用端末 \'iPhone 14\' ' WHERE ID = '01234567'; 上記の様に「iPhone 14」前後の「’」の前に「\」を付けることによって、「 使用端末 ‘iPhone 14’ 」という文字列データとして扱われ更新されます。 エスケープ処理が施されていれば、「’」の様な記号が悪さしてSQLインジェクションに繋がる事はありません。ただこのあたりの確認はブラックボックステストにおいては入力を試して挙動を確認するしかないので、探索的テストでこういった構文を想像しながら怪しい入力を試してみると良いと思います。 私の経験則では、この辺りの対策がされているシステムは、設計時点からしっかりされてそもそも入力ではじかれます。1画面ピックアップして対策されていないシステムは、どの画面もされていない事が多いので探索的にどこか主要の1画面を確認するだけでも十分効果はあるんじゃないかと思います。 最後に 学生の頃はコミュニティサイト内のチャットでの発言にHTMLタグを組み込んでみたり、相手のCDROMドライブが勝手に開くみたいな悪戯を仕込んだりといった事が流行った記憶がありますが、昔はユーザーの入力に対して本当にどのWebサイトも無警戒だったと思います。 今回の様なSQLインジェクションに関わるような入力を探索的テストで確認していた時も、それでとんでもない挙動を起こさないかと半ば好奇心で試していましたが、情報漏洩やデータ改ざんに繋がるって怖いなと改めて思いました。 ただ、テストを行う上で好奇心を持つことは大事で、普段何気なくテストで確認している入力制限文字の確認なども、システム中のプログラムの仕組みを知るとなぜこういう仕様になっているのか？と理解が進み楽しくなるんじゃないでしょうか。 本記事を読んで頂き、少しでもテスト観点の幅が広がれば幸いです。ではまた。 The post テスト実施で知っておきたいSQLインジェクション first appeared on Sqripts .

PMとPMOの違い PMとPMOは、プロジェクトマネジメントにおいて異なる役割を担います。PMは「プロジェクトマネージャ（Project Manager）」の略で、プロジェクトの計画・管理・運営に関する責任者です。一方、PMOは「プロジェクトマネジメントオフィス（Project Management Office）」の略で、PMによるプロジェクトマネジメントを支援するポジションを担います。PMがプロジェクトの具体的な運営を担当するのに対し、PMOはプロジェクト管理に専念します。 [Tips]PMとPMOとコンサルタントは何が違う？ コンサルタントも、PMやPMOに似ているイメージですが、どこが違うのでしょうか。コンサルタントは、組織や企業に対して、ビジネス戦略やプロセスの改善、コスト削減などのアドバイスや支援を提供します。その中には、PMに関するコンサルティングや、PMOの設計や構築、PMの育成やPMプロセスの改善などが含まれます。 PM、PMO、コンサルタントは、それぞれ異なる役割を担いますが、プロジェクトマネジメントに関する知識やノウハウを共有することで、組織や企業のプロジェクトの成功に貢献できるのです。 PMの役割、業務、必要なスキル PMの役割、業務、必要なスキルについて詳しく解説します。 PMの役割 PMの主な役割には以下のようなものがあります。 プロジェクトの計画と立ち上げ プロジェクトの目的やスコープ、タイムライン、予算などの計画を策定し、スタッフを選定してプロジェクトを開始する。 スケジュール管理 プロジェクトのスケジュールを策定し、進捗を監視して調整し、遅れが生じた場合はスケジュールの変更や再調整を行う。 リスク管理 プロジェクトのリスクを特定し、それらに対処するための計画を策定する。また、リスクの発生に備えて対策を講じる。 コミュニケーション ステークホルダーとのコミュニケーションを円滑に行うことで、プロジェクトを成功に導く。 資源管理 プロジェクトに必要な人員、設備、財源などの資源を適切に割り当てて管理する。 品質管理 プロジェクトの成果物が品質基準を満たしているかどうかを監視し、必要に応じて改善を行う。 問題解決 プロジェクトの進行上の問題を特定し、解決するための方法を提供する。 PMの役割は、プロジェクトの成功に直接影響するため、多くの企業で重要視されています。 PMの業務 PMの主な業務には以下のようなものがあります。 プロジェクト計画 プロジェクト目標、スコープ、タイムライン、予算、リスク管理などを策定します。これには、必要なリソースを特定し、プロジェクトチームを構築することも含まれます。 プロジェクト実行 プロジェクトチームを指導し、計画に基づいてプロジェクトを実行します。これには、タスクの割り当て、進捗の監視、品質管理、コミュニケーションなどが含まれます。 プロジェクト監視 進捗状況を監視し、スケジュールや予算の変更、品質管理の改善などが必要かどうかを判断します。 プロジェクト制御 問題が発生した場合は、適切な対応を講じます。これには、予算、スケジュール、品質、リスク管理などを調整することが含まれます。 ステークホルダー管理 プロジェクトに関係するステークホルダーとのコミュニケーションを円滑に行い、プロジェクトがステークホルダーの期待に応えることができるようにします。 プロジェクト報告書作成 プロジェクトの進捗状況や成果物をステークホルダーに報告するための報告書を作成します。 これらの業務は、プロジェクトの成功に不可欠です。PMは、これらの業務を適切に遂行することで、プロジェクトを成功に導きます。 PMに必要なスキル PMには多くのスキルが必要です。以下に挙げるのは一般的に重要視されるスキルです。 リーダーシップスキル プロジェクトチームを率い、目標に向けて指導できる能力。 コミュニケーションスキル ステークホルダーとのコミュニケーションを円滑に行うことができる能力。 問題解決スキル 問題を特定し、解決するための方法を提供する能力。 プロジェクトマネジメントスキル スケジュールや予算の管理、品質管理、リスク管理などのプロジェクトマネジメント技術を使いこなす能力。 技術スキル プロジェクトに必要な技術を理解し、プロジェクトチームと協力してプロジェクトの成功に導く能力。 ビジネススキル プロジェクトの目的と企業のビジネス目標を理解し、プロジェクトがビジネス上の目標を達成するために必要な計画を策定する能力。 チームビルディングスキル プロジェクトチームを結束させ、チームメンバーのモチベーションを維持するための能力。 プレゼンテーションスキル プロジェクトの成果物や報告書をステークホルダーに説明し、プレゼンテーションスキルを持つことが重要です。 これらのスキルを持ったPMは、プロジェクトの成功に貢献するでしょう。 PMOの役割、業務、必要なスキル 続いて、PMOの役割、業務、必要なスキルについて詳しく解説します。 PMOの役割 PMOの主な役割には以下のようなものがあります。 プロジェクトマネジメントの標準化 PMOは、プロジェクトマネジメントの手法やツール、文書の作成方法などを標準化することにより、プロジェクト管理の品質を向上させます。 プロジェクトポートフォリオの管理 PMOは、企業が抱えるプロジェクトの全体像を把握し、プロジェクトポートフォリオとして管理することにより、プロジェクトの優先順位付けや予算配分などを行います。 プロジェクトの進捗管理 PMOは、プロジェクトの進捗状況を把握し、問題や課題を早期に発見し、解決することにより、プロジェクトのリスク管理を行います。 プロジェクトマネジャーの支援 PMOは、プロジェクトマネジャーに対して、プロジェクトの遂行に必要なツールや情報を提供することにより、プロジェクトマネジャーの業務を支援します。 企業によっては、より多くの役割を担っている場合もあります。 PMOの業務 PMOの主な業務には以下のようなものがあります。 プロジェクト管理のフレームワークやプロセスの策定・改善 PMOは、プロジェクトの進捗管理や品質管理などのフレームワークを策定し、プロセスの改善に取り組んでいます。また、プロジェクトマネジャーの指導や支援も行います。 プロジェクトの進捗管理・報告 PMOは、プロジェクトの進捗状況を管理し、定期的に報告書を作成して上層部やスポンサーに提出します。進捗状況に基づいて、プロジェクトのリスク分析や問題解決に取り組みます。 リソース管理 PMOは、プロジェクトに必要なリソース（人材、予算、設備など）の管理を行います。また、必要なリソースを供給するために、組織内の他部署や外部パートナーとの連携を図ります。 コミュニケーション管理 PMOは、プロジェクトに関わるステークホルダーとのコミュニケーションを担当します。プロジェクトに関する情報の共有や調整、または関連する問題の解決など、コミュニケーションに関するあらゆる業務を行います。 プロジェクトの成功に向けて、多岐に渡る業務を担当しています。 PMOに必要なスキル PMOに必要な主なスキルには以下のようなものがあります。 プロジェクト管理に関する知識と経験 PMOは、プロジェクトの計画、実行、監視、制御、クロージングなどのフェーズで活動するため、プロジェクト管理に関する知識と経験が必要です。例えば、プロジェクト管理のフレームワークやツール、プロジェクト計画や進捗管理、リスク管理などについて理解している必要があります。 コミュニケーションスキル PMOは、プロジェクトに関わるステークホルダーとのコミュニケーションを担当するため、優れたコミュニケーションスキルが必要です。これには、報告書の作成やプレゼンテーション能力、問題解決能力、関係構築能力、交渉力などが含まれます。 リーダーシップスキル PMOは、プロジェクトチームや関係者を統率し、プロジェクト目標の達成を支援するリーダーシップスキルが必要です。これには、チームの指導や指示、モチベーション管理、問題解決能力、優先順位の設定などが含まれます。 データ分析スキル PMOは、プロジェクトの進捗状況やリスクに関するデータを収集・分析し、適切な意思決定をする必要があります。そのため、データ分析スキルやエクセルやプロジェクト管理ツールの利用スキルが必要です。 プロジェクト全体のビジョンを把握する能力 PMOは、プロジェクト全体のビジョンや戦略を把握し、プロジェクトの目標に沿ったサポートをする必要があります。プロジェクトに関する知識を深めることで、プロジェクト全体のビジョンを理解する能力が必要です。 ただし、業務内容によって必要なスキルが異なるため、詳細な業務内容に応じて必要なスキルを身につける必要があります。 PMOを導入するメリットと注意事項 PMOを導入するメリットと注意事項について解説します。 PMOを導入するメリット PMOを導入することによって、以下のようなメリットが得られる可能性があります。 プロジェクト管理の統一化 プロジェクトの進捗管理や品質管理など、プロジェクト管理の方針や手順を統一化できます。 プロジェクト管理の改善 PMOはプロジェクト管理のベストプラクティスを提供することができ、これを各プロジェクトに適用できます。これにより、プロジェクトの効率性や成果品質が向上します。 リスク管理の強化 PMOは組織全体でリスク管理を行うことができ、リスクの早期発見や回避が可能です。 組織の透明性の向上 PMOによってプロジェクトの進捗状況や成果物の可視化ができるため、組織の透明性が向上し、組織全体でのコミュニケーションの改善につながります。 PMO導入のメリットとして、システムの進捗を徹底的に管理できることが挙げられます。小規模プロジェクトではPMが全ての業務を管理できますが、人数が増えると状況把握や書類の質などの問題が出てきます。PMOを導入することで、肥大化したマネジメント業務に対応できるのです。 また、PMOはプロジェクトマネジメントの強化につながり、開発チーム全体の連携を高めることができます。複数のプロジェクトが並行して動いている規模の企業では、PMO部門を社内に持つことで全プロジェクトの状況を把握できます。PMOスキルを持つメンバーがいない場合は、外部のPMOに入ってもらったり、コンサルタントと連携したり、社外の戦力を検討すると良いでしょう。技術の複雑化や働き方の多様化により、協力会社やフリーランスなどの人員管理の手間も増えていますが、PMOの導入によってこれらの課題にも対応できます。 PMOを導入する際の注意事項 併せて、PMOを導入する際には、以下のような事項に注意する必要があります。 コスト PMOの設置や運営には費用がかかります。組織にとってその負担が大きい場合があります。 組織への影響 PMOは組織全体に影響を与えることがあります。組織文化やプロジェクトマネジメントの方針に合わない場合、導入が困難である可能性があります。 プロジェクトマネージャーの負担増 PMOの導入によって、プロジェクトマネージャーの負担が増加することがあります。PMOからのレポーティングやプロセスの遵守、文書の作成などが増えるため、プロジェクトマネージャーの時間やリソースが削られる可能性があります。 PMOを導入する場合には、進捗管理に重きを置きすぎて、コミュニケーション不全や他部署への無関心を引き起こすことがあります。PMOは各部署の中継役として、プロジェクト全体の成功を目指すために機能する必要がありますが、進捗管理に過度に力を注ぎ、現場の粗探しに走ることで各部署が保身に走り、プロジェクトの炎上につながるかもしれません。 PMOは、進捗管理と同様に、各部署との円滑なコミュニケーションを築くことが必要です。機械的にプロジェクトを管理するだけではなく、メンバーと人間関係を構築し、チーム全体の能力を向上させることが重要です。PMOは、各部署の調整役として、高いコミュニケーション能力が必要な部門であることを覚えておきましょう。 PMOの導入を検討 PMOを導入するかどうかは、組織の状況やニーズによって異なります。以下は、PMOを導入する方が適切な場合と、導入しない方が適切な場合の例です。 PMOを導入する方が適切なケース 組織内に複数のプロジェクトがあり、それらの管理が分散している場合。 プロジェクト管理に関するノウハウやベストプラクティスが統一されておらず、プロジェクト成功率が低い場合。 リスク管理や品質管理など、プロジェクト管理における課題がある場合。 組織内に複数の部門があり、それらの間でプロジェクトが進行している場合。 組織が急速に成長しており、プロジェクトマネジメントをより効果的に行いたい場合。 大規模プロジェクトの開発において、PMOの導入は強く推奨されます。プロジェクト規模が大きく、複数の部署が関わる場合、PMOはプロジェクト全体を統括する役割を果たし、進捗管理やプロジェクトマネジメントを行います。PMOによって、プロジェクトの目標を達成するために必要な情報の収集、共有、報告、分析などが行われ、組織全体でのプロジェクトの進捗状況や課題が把握できます。また、PMOはリスクマネジメントや品質管理などにも貢献し、プロジェクトの成功に不可欠な役割を果たします。 PMOを導入しない方が適切なケース 組織が小規模で、プロジェクト数が少なく、プロジェクトマネジメントの管理が容易である場合。 組織内のプロジェクトが単純で、プロジェクト管理の手順が明確である場合。 組織内の文化やプロセスがPMOに適さない場合。 PMOの導入に伴い、組織に対する費用や時間の負担が大きくなる場合。 小規模なプロジェクトや部門の場合、PMOを導入する必要性は低いと言えます。PMOを導入することによって、プロジェクトの進捗状況や課題を共有することが難しくなり、コミュニケーションのコストがかかる可能性があります。また、PMOに必要なリソースや費用がかかるため、コストパフォーマンスが低くなるでしょう。 一方、小規模プロジェクトでは、プロジェクトのリーダーが中心となって進捗管理や課題解決を行うことができ、柔軟な対応が可能です。そのため、PMOを導入することが適切であるかどうかは、プロジェクトの規模や目的に応じて慎重に判断する必要があります。 PM、PMO関連の資格 代表的なPM、PMOの資格には、以下の3つがあります。 PMP プロジェクトマネージャ試験 NPMO認定資格 1. PMP（Project Management Professional） PMPは、米国プロジェクトマネジメント協会（PMI）が認定するプロジェクトマネジメントの資格です。PMP認定者は、PMに関する幅広い知識、スキル、経験を持ち、プロジェクトを成功に導くためのベストプラクティスを熟知しています。 PMP認定には、PMP試験に合格することが必要であり、PMP試験はPMの5つのプロセスグループと10の知識領域に関する問題が出題されます。PMP認定者は、PMだけでなく、プロジェクトチームメンバーやステークホルダーとしても重要な役割を果たします。 PMPは、世界的に認められたPMのスタンダードとなっており、PMP認定者の需要は高く、キャリアアップにもつながることが期待されます。 2. プロジェクトマネージャ試験 プロジェクトマネージャ試験は、一般財団法人日本能率協会が実施するプロジェクトマネジメントの資格です。PMIが提供するPMPに比べて、日本国内での認知度は低いですが、日本企業においては、この試験を求める求人も多くあります。プロジェクトマネージャ試験は、プロジェクトマネジメントの知識やスキル、実践経験を証明するものであり、合格者は、PMとしての資格を取得することができます。 試験は、プロジェクトマネジメントの基本的な知識や技能に加えて、プロジェクト計画、プロジェクト推進、プロジェクトコントロール、リスクマネジメント、チームマネジメント、コミュニケーションマネジメントなどのスキルや知識が問われます。プロジェクトマネージャ試験の合格者は、プロジェクトマネジメントにおいて、日本企業におけるキャリアアップの可能性を高めることができます。 3. NPMO認定資格 PMOに関する資格として、日本PMO協会が認定する「NPMO認定資格」が存在します。NPMO認定資格には、プロジェクトマネジメント・アソシエイト（PJM-A）、PMOスペシャリスト（PMO-S）、PMOスペシャリスト（PMO-S）の3つの総合的な資格があります。 プロジェクトマネジメント・アソシエイト（PJM-A） PJM-Aは、プロジェクトマネジメントに関する基礎的な知識や技能を証明する資格です。NPMO認定資格の最初のステップとして位置づけられています。PJM-Aの取得には、PMOの概要、プロジェクトマネジメントの基本的な知識、プロジェクトの計画や実行、チームマネジメント、コミュニケーションマネジメントなど、幅広い領域の知識が必要です。 PMOスペシャリスト(★)【PMO-S(★)】 PMO-S(★)は、PMO運営に関する知識や技能を証明する資格です。PMOの立ち上げや改善に関するプロジェクトマネジメント、戦略的なプロジェクト選択やプロジェクトポートフォリオマネジメント、PMO運営に必要なマネジメントスキルやコミュニケーションスキルなどが問われます。PMOの運営に必要な基礎的な知識を身につけたPJM-Aの取得が前提となります。 PMOスペシャリスト(★★)【PMO-S(★★)】 PMO-S(★★)は、PMOのプロセス改善や戦略的なPMO運営に関する高度な知識や技能を証明する資格です。PMO-S(★)の取得が前提となり、PMOの戦略的位置づけやビジネス価値、PMOの運営における課題解決や改善、PMO運営における成果や評価、PMOのグローバル展開など、より高度な知識やスキルが問われます。PMOのプロフェッショナルとしての知識とスキルを証明することができます。 まとめ PMOは、プロジェクトを円滑かつ迅速に進めるためのスキルを備えています。業界や組織にかかわらず、その能力を最大限に発揮するでしょう。PMやPMOの資格を取得することで、自分自身が大規模なプロジェクトに適した人材であることがアピールできます。知識の習得だけでなく、資格取得もスキルアップの一つとして検討することが重要です。大規模なプロジェクトでは、リソースを最大限に活用して万全を期したいものです。「プロジェクトの進捗が遅れている」「次のプロジェクトは確実に進めたい」といった場合には、PMOを活用してみることを検討してみましょう。 　 PM PMO 役割 プロジェクトの計画と立ち上げ スケジュール管理 リスク管理コミュニケーション 資源管理 品質管理 問題解決 プロジェクトマネジメントの標準化 プロジェクトポートフォリオの管理 プロジェクトの進捗管理 プロジェクトマネジャーの支援 業務 プロジェクト計画 プロジェクト実行 プロジェクト監視 プロジェクト制御 ステークホルダー管理 プロジェクト報告書作成 プロジェクト管理のフレームワークやプロセスの策定・改善 プロジェクトの進捗管理・報告 リソース管理 コミュニケーション管理 必要なスキル リーダーシップスキル コミュニケーションスキル 問題解決スキル プロジェクトマネジメントスキル 技術スキル ビジネススキル チームビルディングスキル プレゼンテーションスキル プロジェクト管理に関する知識と経験 コミュニケーションスキル リーダーシップスキル データ分析スキル プロジェクト全体のビジョンを把握する能力 ＜PMとPMOの役割、業務、必要なスキル＞ The post PMOとは？PMとの役割や業務の違いについて解説 first appeared on Sqripts .