こんにちは！　テストエンジニアのマツキョーです！ 「トレーサビリティ」という言葉をご存知でしょうか？　トレーサビリティは英語の「trace」と「ability」を繋げた造語で、日本語では「追跡可能性」のように翻訳されます。元々は製造業の品質管理の概念として生まれたもので、部品から製品までの各製造工程で品質を管理するための手法です。近年では、IT業界においてもトレーサビリティの重要性に注目が集まっています。 もちろん品質保証（QA）においても、トレーサビリティを確保することは重要です。なぜならトレーサビリティを確保していないと、私たちが行ったテスト活動が、ソフトウェアやシステムの要件・仕様に対してどのくらいの品質を担保できているかが追跡できなくなるからです。 では、QAだけがトレーサビリティを意識していればいいかというとそうではありません。QAの責務は品質を保証することであり、品質を作り込んでいくのは、QAや開発を含めソフトウェアやシステムに関わるすべての人間だからです。組織やチーム全体でトレーサビリティを確保するための取り組みを行っていくことで品質の追跡可能性や明確性などの確立を促進することができます。 しかしながら、トレーサビリティを確保して活用していくためには、相応にコストが掛かります。私自身、業務を通して多くのプロジェクトに携わる中で、トレーサビリティの活用に取り組みながらも苦戦するチームを数多く見てきました。トレーサビリティを導入してもすぐに期待通りの効果を得ることは難しいでしょう。それでもトレーサビリティを組織やプロジェクトに導入することは、大変価値のある作業なのです。 この記事では、これからトレーサビリティを導入・運用していくにあたり、トレーサビリティとは何か、そのメリットおよび運用方法と注意点、そしてQAとしてどう関わっていくかについてご紹介していきます。トレーサビリティについて知識を深め、組織やプロジェクトの品質改善にお役立ていただければ幸いです。 トレーサビリティとは？ トレーサビリティという言葉は、元は製造業で使用されていた品質管理の概念です。ソフトウェア開発でも品質管理のための手法として一般的に利用されています。ソフトウェアの品質保証においても重要な概念であることは言うまでもありません。 ISTQB glossary では、トレーサビリティに関する用語として以下のように掲載されています。 関連する作業成果物、または作業成果物内のアイテムを明示的に関連付ける能力。 ISTQB glossary「トレーサビリティ」 たとえばシステム開発であれば、最初に「要求」を定義し、「要求」をもとに様々な「要件」を洗い出し、「要件」を満たすための「仕様」を設計し、「仕様」をもとに「コード」を作成して実装したり、QAが「テスト」を設計したりします。トレーサビリティはこれらの繋がりを明示的に管理することで、「要求」を満たせているか、つまり意図した価値・品質を作り込めているかを測定できるようにしてくれます。トレーサビリティに関するQAの役割としては、様々な種類のテストを通してトレーサビリティの破綻や抜け漏れがないか、その繋がりに妥当性があるかを検証して保証していくことが挙げられます。 トレーサビリティのイメージ トレーサビリティを確保するメリット トレーサビリティのイメージが少し掴めたところで、次に具体的なメリットをご紹介します。 製品の品質について追跡可能性・透明性・明確性を提供してくれる 製品が要求を満たしていることを担保するためには、まず要求をどのようにブレイクダウンして仕様やデザインに落とし込んだか、その仕様がどのコードにより実装されたかが追跡できる必要があります。そしてQAが、仕様をもとにテスト条件を抽出してテストケースを作成し検証することで、要求からテストまでの一貫したトレーサビリティが確保されます。これらを可視化して管理することで「追跡可能性」や「透明性」が生まれ、品質という目に見えない指標を計測できるようになります。また、情報を一意化することにより「明確性」も生まれ、欠陥の混入や不具合の作り込みを防ぐことができるようになります。 他にも、トレーサビリティが適切に確保されていれば、不具合が偏在している機能や、他の機能・システムとの依存関係が集中している部分が明確になります。不具合が集中している部分をリファクタリングしたり、他の機能・システムとの依存関係を緩和したりするなど、プロダクトをより管理しやすく品質を保ちやすい構造に改善していくための判断材料にすることもできます。 変更要求が発生した際に迅速な対処が可能になる あるプロジェクトに途中から参画した時の話です。既存機能の機能変更が計画されておりテスト設計をすることになりました。その際、「以前に実施したテストケースが流用できるので使って欲しい」という指示を受けたのですが、テストケースを確認したところどのテストベースや仕様記述を基に設計されたのかがわからず、流用可能な部分と機能変更により新たに設計しなければいけない部分の調査に時間が掛かったことがありました。何とか期日までに仕上げましたが、人の入れ替わりが激しいIT業界においてトレーサビリティの重要性を再認識した出来事でした。 機能の変更発生時やインシデント発生時など、その機能変更や不具合が現在のシステムのどこに影響するのかを正しく理解していないと、予期せぬ別の不具合に繋がってしまう可能性があります。この時、トレーサビリティが適切に確保・管理されていれば、影響範囲の理解を助けて素早い対応が可能になります。たとえば既存システムに新たな要件にもとづく機能を追加することになった場合、QA視点では以下の活動が容易になります。 既存のテストケースでカバーできる範囲がわかり工数を節約できる 新たに作成する必要があるテストケースが特定でき、素早くテスト設計を行える 新たな要件／機能の追加により既存機能のどこに影響するかを特定でき、優先度をつけて適切なリソース投入ができる トレーサビリティを確保して適切に活用できれば、機能変更やインシデント発生時に影響範囲の調査などにかかる工数を削減することができます。浮いた工数をより品質を高める活動に使用できるため、高品質なプロダクトの継続的な提供が可能になります。またユーザーからの問い合わせに対する調査も迅速に行えるため、お客様の要望に素早く応えることができ、顧客満足度の向上も期待できます。そして影響範囲が明確であれば、不測の事態に遭遇するリスクを大きく減少できます。開発工程では影響範囲を考慮した実装により潜在的な欠陥を減少でき、テスト工程では影響範囲が明確なため効率的なテストが可能となります。結果として不具合の減少や各種リスクの軽減が期待できます。 トレーサビリティには、プロダクト開発の生産性を高め、お客様により高品質なプロダクトを提供するためのメリットがあります。では、実際にトレーサビリティを確保して適切に管理・運用していくには、どのような方法があるでしょうか。 トレーサビリティを確保して運用していくには トレーサビリティを管理する方法には様々ありますが、その中から一般的な方法を３つ紹介します。 ツールを導入して管理する 要件管理ツールは、要求・要件／仕様をチケットとして管理し、依存関係や関連付けをシステム上で簡単に設定できます。適切に導入・運用することで要求から仕様設計までのトレーサビリティの確保を支援してくれます。また構成管理ツールと連動させることで仕様とコードを関連付けることができるので、開発サイド全体のトレーサビリティを確保できます。さらに仕様とテスト条件・テストケース、及び、テスト結果を関連付けできるテスト管理ツールを併用することで、仕様からテスト結果までのQAサイドのトレーサビリティを確保できます。 これらのツールを連携して使用することで開発からQAまでの一貫したトレーサビリティを確保できます。 ドキュメンテーションで管理する トレーサビリティの管理には、ツールを導入することが最も効果的でしょう。しかし組織にツールを導入するには手続きやツールの習熟にかかるコストなどが相応に必要になります。大規模な開発でなければ、Excel等でトレーサビリティマトリクス ※1 を作成することでもトレーサビリティを管理できます。手作業による管理になるため、プロセスをしっかり定めて実施する必要がありますが、手軽に導入できる方法としては最も効果的な方法の１つです。 ※1 トレーサビリティマトリクスとは、要件（行）に対して、仕様・設計・テスト（列）がどのように対応しているかをマトリクスで表現したものです。以下にトレーサビリティマトリクスの例を示します。 トレーサビリティマトリクスの例 レビュープロセスで担保する ツール導入もドキュメンテーションもハードルが高いという人は、まずレビュープロセスにトレーサビリティチェックの項目を追加してみてはいかがでしょうか。 各工程のレビューにおいて、要求と要件／仕様、要件／仕様とテストといった双方向のトレーサビリティが確保されているかをチェックし、議事録やチェックシートに記録してトレーサビリティを担保する方法となります。ただし、この方法では製品全体の情報としてまとめられていないため、トレーサビリティを十分に管理できているとは言えず、効果を十分に得られません。トレーサビリティの効果を実感できたら、ツールやドキュメンテーションによるトレーサビリティ管理を導入することをオススメします。すでにツールやドキュメンテーションを導入している場合は、適切な運用を実現するためのプロセスの1つとして利用すると効果的でしょう。 以上がトレーサビリティを確保・管理する方法の一例ですが、これらの方法を導入すればトレーサビリティの恩恵を受けられるわけではありません。 たとえば、ツールを導入した場合を考えてみてみましょう。まずツールの使い方がわからなければ利用できないので、ツールを習熟するための教育方法を考える必要がありますね。次にプロセスやフォーマットが定まっていなければ活用できる情報として蓄積できないので、運用プロセスやフォーマットを策定する必要があります。プロセスやフォーマットが定まっていても利用者が認知していなければ利用されないため、組織に浸透するまで継続的に周知していくことが求められるでしょう。ただし、これらをすべてクリアしても利用時のプロセスやルールが複雑だったり冗長だったりすると、利用者に負担が掛かり継続が困難になる場合もあるため注意が必要です。 いずれの方法を採用するにしても、導入するだけでなく適切に運用できなくては効果は得られません。トレーサビリティを適切に運用して十分な効果を得るためには、学習・運用・改善のプロセスやルールを設定したり、定期的なチームミーティングの開催などでコミュニケーションを活発にするなど、チーム全員で様々な取り組みに挑戦する必要があることが分かりますね。 QAがトレーサビリティを推進する トレーサビリティを導入して活用していくためには、プロジェクトに関わるすべての人が継続して適切に運用していかなければいけません。その中でも品質に責務を持つQAが主導権を握ってトレーサビリティを推進していくべきかと思います。なぜならQAはテスト活動を通してソフトウェアやシステム全体の仕様に精通していくため、その過程でトレーサビリティが適切に確保され管理されているかを確認できるからです。その際、不適切な運用があった場合はチームへフィードバックしたり運用を改善したりできます。 とはいえ、QAはあくまでトレーサビリティを推進する旗持ちでしかありません。最も重要なのは、全員が 「品質向上のためにトレーサビリティを管理する」 という共通の目標を持つということです。トレーサビリティを確保して品質向上のために活用していくためには、チーム全員がトレーサビリティの重要性を理解し、継続してトレーサビリティの確保・管理・運用に取り組んでいくことが大切ですね。 さいごに トレーサビリティを組織やチームに適用してメリットを享受するには、チームメンバー1人1人が自分事として行動することが重要になります。トレーサビリティを適切に導入・運用して、プロダクトの品質向上に役立てていただければ幸いです！ The post トレーサビリティを制する者は品質を制する！～IT業界におけるトレーサビリティを解説～ first appeared on Sqripts .

こんにちは。RSです 私はAI技術に不可欠なアノテーション業務を行っています。 ここ数年で、AI技術は「開発途上の最先端技術」というよりは「実際に日常に活用されている最先端技術」になってきたと感じています。車の自動運転技術・自動で障害物を避けるお掃除ロボットなど、AI（人工知能）を使った様々な製品・サービスがあることを見聞きしたり仕事やプライベートでChatGPTを使っている方もいらっしゃることでしょう。 また、AI技術が発展してきていることでアノテーション業務を行う様々な業者が増えてきたり、アノテーションを行う求人を見かけるようになったりと、アノテーション業務自体も増えてきている事を感じています。 今回はAI技術に不可欠な「アノテーション」とはどんな事をする作業なのか、無料アノテーションツールを紹介しながらアノテーションの世界を紹介したいと思います。最後に複数のアノテーションツールを実際に使用して、アノテーション作業のタイムアタックを行いました。タイムアタックを通して分かった事もシェアします。 アノテーションってなんだろう？ ここまで、散々じらしてしまいましたが… そもそも、アノテーションってなんでしょう？アノテーションとは　 annotation＝注釈 　という意味です。AIの機械学習には様々な手法がありますが、その中の一つに「教師あり学習」という方法があります。テキストや音声・画像といったさまざまな種類のデータにタグやメタデータを付けたデータを使ってAIに学習させます。その学習用データを作る事をアノテーションと言います。もっとカンタンに言うと「教師あり学習」で機械学習をする際の正解データを作る作業がアノテーションです。 例えばAIに「花」を学習させたい場合、様々な花の画像を用意します。その画像全てに「花」というタグを付けてあげて正解を認識させます。このように認識させたいものと解答を用意して認識させます。 ただ、「鼻」とか間違えたタグをつけてしまうと、花の画像を「鼻」と認識してしまいます。なので正確な「正解データ」がたくさん必要になります。アノテーション業務では基準に沿って正確に作業し、たくさんのデータを完成させることが求められます。 アノテーションの種類 アノテーションの種類を説明する前に、対象データについて少しお話しさせていただきます。機械学習では教えたい内容に応じてアノテーション対象となるデータに様々な種類あります。代表的なものは以下の通りです。 画像・動画データ 音声データ テキストデータ 今回は画像データに対するアノテーションの種類を説明したいと思います。 A．画像分類 1枚の画像に写っているものがなにかタグをつける作業。 B．物体検出 画像・動画の中に映っている物体等を四角で囲み、タグを付ける作業。 画像内のどの位置にその物体があるのか情報を得ることができます。 C：領域検出 画像・動画の中に映っている物体等の領域を囲みタグをつける作業。 四角ではなく、対象物をその形のままに囲み、被写体を識別することができます。 D：座標検出 主に人体に対して使われることが多く、顔や身体等の部位に印をつける作業。 顔認識や姿勢推定などに使われます。 アノテーション作業の課題 色々なアノテーションの種類を見てきましたが、教師ありの機械学習では大量の「正解データ」が必要になります。そのため作業の効率化はとても大事になってきます。私が行ってきたアノテーション作業では、ほとんどのケースで専用のアノテーションツールを使って作業していました。ただ、専用のツールだとしても使い方が煩雑であれば、作業効率はそれほど上がらない可能性もあります。また、アノテーションツールは探してみると色々とリリースされています。各ツールそれぞれに特徴があり、作業工程・操作のしやすさ・使用感はどうなのか？気になるところです。 使用感の指標の1つに…タイムアタックをやってみた！ アノテーション作業では大量のデータを効率よく作業する必要があります。精度も重要ですが、それと同じくらいスピードが求められます。そこで実際の作業の流れを紹介しつつ同一条件でアノテーション作業のタイムアタックを行って、ツールの違いがどれくらい作業スピードに影響するか検証します！ さてさて、どんな結果が出てくるか…計っていくぅ～！ 使用するツール 今回はネットで調べて「無料で使う事ができる」「様々なデータにアノテーションできる」「進捗管理ができる」「ウェブ上で動作するので気軽に試せる」等の特徴が類似している3つのツールを使います。 Labelbox ANNOFAB CVAT アノテーション対象 通常の業務では、お客様の意図した「正解データ」を作るために、お客様からいただく基準書や質問を通してお客様とコミュニケーションを取りながら基準を明確にして作業を行います。今回は花の画像を用意して「物体検出」で「花」や「つぼみ」が写っている以下の画像10枚に対して、アノテーション作業のタイムアタックを行います。 アノテーションの作業内容とタイム計測方法 通常の業務ではアノテーション作業前に事前準備、作業後に見直し作業を行っています。事前準備では実施時に困らないように基準の確認・データ内容の確認等を行います。見直し作業では作業したデータが基準と相違がない事を確認します。「正確性が命」のアノテーションには無くてはならない作業です。自身（もしくは他者）が見直しを行う事で、基準と異なるデータが混入してしまうのを防止することができます。今回のタイムアタックも通常の業務と同じ手順で行いました。 タイム計測方法は、それぞれのツールで作業手順・設定項目等が異なる事から、どの作業にどれくらいの時間がかかるか分かりやすくするために下記3つに分けてタイムを計りました。 ＜作業準備＞ 画像アップロード〜アノテーション作業準備完了までを計りました。 作業画像のアップロード・ラベル名の作成・担当者の指定等ツールごとに最低限必要な設定を行い、アノテーション作業できる状態にしました。 ＜作業実施＞ アノテーション作業実施のタイムを計りました。今回は「物体検出」を行いました。 ＜データ見直し＞ アノテーション作業実施終了後の見直し開始〜終了までタイムを計りました。アノテーション作業が終わったら必ずミスをしていないか確認をします。実際の作業でも重要な工程です。 結果発表とツールの操作感 一番合計タイムが早かったのはCVATでした。 ＜作業準備＞ では他の2ツールと比べると設定項目が多いANNOFABが一番時間がかかりました。 ＜作業実施＞ ではCVATが一番早く終わりました。操作がシンプルで分かりやすい事が要因だと感じました。ANNOFABでは手順1つ多くて且つそれ抜かすとアノテーション出来ない仕様になっていました。そこを抜かすミスを多くしてしまったため時間がかかってしまいまいた。 ＜データ見直し＞ ではANNOFABで上記ミスにより焦りが生じたためか他のツールに比べて作業ミスが多く発生してしまいました。その結果、見直しに時間がかかってしまいました。同じデータをアノテーション作業するとはいえ、人の作業なのでタイミングによって精度にブレが出てしまいました。。。 では、ここからは各ツールごとに操作感をお伝えしたいと思います。 Labelbox 画像アップロード時に一部の縦画像が横で表示されてしまいました。ツール上で修正ができるか調べてみましたが、私の調べた限りでは見つけることができませんでした。そのため修正は行いませんでしたが、使用するデータや状況によっては縦横の修正が必要になるかもしれません。そのような場合どう対応すればよいのか悩ましいところではあります。 それ以外は直観的に作業ができて、ショートカットがある機能はメニュー操作時に表示されていました。はじめて作業を開始してから操作手順を覚えるまでは作業ペースが上がりづらいので、何度も目に入って覚えられるのは良いと思います。 ANNOFAB 進捗管理の機能・アノテーション作業の機能共に色々な機能が付いています。作業時間を細かくモニタリングして統計を取ることもできます。一見便利そうに見えましたが、便利機能があるがために設定項目が多くなったり、必要としている機能がどこにあるのか分かりづらく感じました。使いこなせればとても便利だとは思います。ただ、私は悲しいことにシンプル脳なので笑、私には使いこなすのは難しいなぁ…と感じました。 CVAT 他の2つのツールに比べるとアノテーション作業準備やアノテーション作業の手順がシンプルに感じました。それもあってかタイムアタックでも一番作業が早かったです。 3つのツールの印象 3つのツールの印象を私が一言で表すならば下記のようになります。 詳細な進捗管理をしたい、作業者をモニタリングして作業スピードを向上させるヒントを得たい →ANNOFAB シンプルな操作方法・管理方法でアノテーション作業したい →CVAT ANNOFABとCVATの間 →LabelBox どのツールも作業効率を上げるために色々な工夫をしていたのが印象的でした。 例えば 矩形を作る際には縦横の補助線を表示して1回の作業で矩形の中に対象物が入るような点を打つ手助けする（3ツール全て） 矩形をコピー＆ペーストしたら少しずれた位置にコピーした矩形が表示される事で1つの対象物に複数個の矩形が重なって付く事を防ぐ（Labelbox・CVAT） ショートカットをメニューに表示する（3ツール全て） 等です。 そんな小さなことで〜？！と思われる方も多いでしょう。ただ、アノテーション作業は基本的に単調な作業です。例えば今回の「物体検出」も、「画像から対象物を探す→矩形を作る（コピーする）→対象物にサイズを合わせる」　という、慣れれば数秒で完了するこの工程を1日中繰り返すのです。処理数が多くなるので、ちょっとしたツールの使い勝手の良し悪しが数秒のロスと微細なストレスを生み、積み重なって進捗に影響を与えます。なので、このような小さな工夫が役に立つのです。 更なる効率アップ～自動アノテーション ここからさらに効率を上げていくには人がイチからアノテーション作業を行うのではなくツールの「自動でアノテーションする機能」を使う方法があります。これはツールが自動でアノテーションした結果を作業者が確認、修正が必要であれば修正する方法です。自動アノテーションの精度が上がれば上がるほど、作業者が修正する時間が減っていき、その分作業者が1日で処理できる作業量も増えていきます。 今回上げた3ツールに自動でアノテーションする機能が付いていましたが、有償版の機能だったものもあったため検証は行いませんでした。ご興味がありましたら、ぜひお試しいただければと思います。 各ツールでの無料版・有料版で使える機能をまとめました。よろしければ参考になさってください。 （参考： Labelbox 、 ANNOFAB 、 CVAT ） 終わりに アノテーション作業について説明しましたが、少しはイメージできましたでしょうか？これまで見てきたように、アノテーションとはAIに覚えさせたいデータにタグやメタデータを付ける作業です。必要なデータに合わせて色々な種類に対してアノテーション作業を行い、画像の場合は4種類のアノテーション作業がある事をお伝えしました。少しでもアノテーションに興味を持っていただけたら嬉しいです。 また、アノテーション作業を行う際のツールが色々あり、使用感などを参考にしてもらうためタイムアタックを行いました。今回の検証では3ツールで物体検出を行うための必要最低限の操作方法・ショートカットキーを覚えてタイムアタックに挑みました。なので、今回はこのようなタイムアタックの結果になりましたが、各ツールの習熟度によってはタイムも変わってくるとは思います。 ただ、ツールによって作業時間に差が出ることは新たな発見でした。やる事は同じでもちょっとした工程が変わるだけで作業効率に差が出る事が分かりました。また、ツールの使い勝手も進捗に影響を与えるのだと改めて感じました。この検証を参考にしていただき、ご自分に合ったアノテーションツールを選択していただければと思います！ 最後まで読んでいただき、ありがとうございました The post AIの先生?! アノテーションってなにするの？を解説します first appeared on Sqripts .

はじめまして、QAエンジニアのT.Tです。 今回は流行りのAIを使って問題発生のログ情報とソースコードを基にデバッグを実施してみました。 その結果についてお伝えします。 AIについて まず初めに、AIについてご説明します。AIとは、Artificial Intelligence（人工知能）の略で、人間の知能を模倣するコンピュータープログラムを指します。これにより、機械が推論、認識、判断などの人間と同じ知的な処理機能を実行することが可能になります。特に、近年のChatGPTなどでお馴染みの大規模言語モデルは驚異的な進化を遂げており、本日ご紹介するAIによるデバッグもその力を活用しています。 AIによるデバッグの可能性と課題 AIでデバッグをする理由 デバッグは、コード内のバグを特定・除去し、ソフトウェアの品質を向上させ、ユーザーの信頼性や満足度を高める重要なプロセスです。しかし、デバッグ作業は時間やリソースを多く必要とし、開発者にとってストレスの原因となることがあります。 そこで、AIによる効率的かつ品質向上につながるデバッグの可能性を探ることにしました。 AIを利用したデバッグの方法 まずは、デバッグの実施環境について説明します。今回は、OpenAI社が提供する「OpenAI API」を用いてデバッグを行いました。また、「Langchain ※1 」のAgents機能を使用しました。「Langchain」のAgentsは、目的を遂行するために言語モデルと渡されたツールを適宜呼び出し、その結果をまた言語モデルやツールにインプットします。これを目的を達するまで自律的に行います。今回はこの機能を利用し、問題が発生した際のログ情報、関連ソースコード、そして問題事象の情報を入力できるツールを用意し、AIがこれらを利用してデバッグが可能かどうかを実際に検証しました。 AIを利用したデバッグの課題と解決策 課題：問題発生時の情報の収集 AIを用いたデバッグを実施した際に、AIにインプットするログの収集に課題があることが分かりました。テストを実施し、問題が見つかった場合、その状況を取得するためにログを収集する必要があります。当初、テストケースを実施して問題が発生した際、実施日時を基に必要なログを収集し、AIへインプットしていました。しかし、複数名が同一環境でテストケースを実施する場合、実施日時によるログ抽出だけでは、情報が混在してしまいます。その結果、問題が発生したテストケースとは無関係なログ情報が紛れ込み、正常にデバッグが行えないことが判明しました。 解決策：APMと専用ツール そこで、問題発生時のテストケースのログ情報の的確に収集できるように、下記の工夫を行いました。 APMを活用したトレース情報・ログの取得 トレースとは任意の処理単位（APIへのリクエストや関数呼び出し）の処理時間や呼び出し順序などを記録するものです。マイクロサービスなどでAPI間の複雑な呼び出し階層を持つものでも、トレースを記録することで「どこからどこにどの順序で呼び出されているのか」を処理時間とともに可視化できます。下図のようなイメージです。 参照元 (JAEGER公式サイトより) 今回はテスト時のトレース情報やログ情報を収集するために、APM ※2 を使用しました。その中でもトレースの共通規格であり、OSSで利用できるOpentelemetryを使用しました。Opentelemetryではトレースに合わせて関連するログ情報も取得でき、取得されたトレース情報を参照すると、特定テストケースに関連するログ情報のみ、収集できていました。Opentelemetryでは、トレースID毎にトレース情報・ログ情報を管理しており、テストケースとトレースIDを紐づけることができれば、個別のテストケースのトレース情報・ログ情報を取得できそうです。 関連記事： 分散トレーシングの活用による次世代のテストを考える テスト開始／終了とトレース開始／終了の連携 次に、テストケースとトレース情報・ログを紐づけるために、テストの開始と終了のタイミングでAPMのトレースを開始・終了する必要があります。そのため、私たちは手軽にトレースを開始・終了できるツールを開発しました。このツールでは、テストを開始する際に、任意のトレースIDが発行され、そのテストで行われた操作・処理のトレースが発行されたIDで記録されるようにします。これによりテストケースとトレースIDを紐づけることが可能となり、テストケースに紐づくトレース情報・ログを確実に取得することができるようになりました。 最終的に、今回AIでデバッグを行う際に用意したデバッグ環境は以下のようになります。 AIによるデバッグ それでは実際にAIを用いてデバッグを実施してみましょう。 今回デバッグの対象としたのは、Webアプリです。ユーザー登録機能やログイン機能などがあります。 今回調査する問題は、「ユーザー情報の更新失敗」という事象で、AIにこの事象を調査してもらうことにしました。 指示と入力データ 今回は、AIに対して以下のような指示を与えました。実際のプロンプトには利用するツールや調査手順などが含まれますが、わかりにくくなるためここでは省略しています。 エラーが発生したトレースのIDと、調査したい内容が与えられます。この内容を基に、問題が発生しているコードを確認し、原因を調査してください。 トレースID:{trace_id} 調査内容:更新ボタンを押下したところ「更新に失敗しました」と表示されました。理由を調査してください。 また、Agentsに与えるツールとしてPythonで下記の関数を作成しています。Agentsはこのツールを利用してデバッグを進めていきます。 get_trace_list 対象のトレースIDを与えられると、トレース情報を保持しているDBから該当するトレース情報を取得する。テスト実施時のトレース情報を取得するためのツール。 read_file 指定されたファイルを読み込む。調査対象のソースコードを読み込むためのツール。 今回インプットとなる問題発生時のトレース情報には調査対象のテスト開始から終了までのエンドポイントや関数呼び出しの順序情報、関数のパラメータ・戻り値、各所で出力されるログなどが含まれます。事象発生時には例外も発生しており、そのスタックトレースも含まれています。 結果 AIにデバッグを依頼した結果、以下のような回答が返ってきました。具体的なクラス名や関数名、ソースコード等についてはセキュリティ観点から変更しています。 エラーの内容を確認したところ、`SampleController` の `sample` メソッドで例外が発生していることがわかりました。具体的には、メールを送信する際に「An email must have a "To", "Cc", or "Bcc" header.」というエラーが発生しています。これは、メールを送信する際に宛先（To, Cc, Bcc）が指定されていないことを意味します。 エラーが発生しているコードは以下の部分です： if ($status === 'sample_status') { Mail::to($sample->email)->send(new SampleMail($sample->login_id, $sample->name, $sample->email)); // ... } このコードは、対象のステータスが「sample_status」に変更された場合に、変更されたことを通知するメールを送信しようとしています。しかし、`$sample->email` が空であるか、正しいメールアドレス形式でない場合、上記のエラーが発生します。 解決策としては、メールを送信する前に `$sample->email` が有効なメールアドレスであることを確認する必要があります。以下のようにコードを修正することを提案します： if ($status === 'sample_status') { if (filter_var($sample->email, FILTER_VALIDATE_EMAIL)) { Mail::to($sample->email)->send(new SampleMail($sample->login_id, $sample->name, $sample->email)); } else { Log::error("Invalid email address: " . $sample->email); // ここで適切なエラーハンドリングを行う } // ... } この修正により、メールアドレスが無効な場合はエラーログに記録され、メールの送信はスキップされます。また、適切なエラーハンドリングを追加して、ユーザーにエラーを通知することも考慮する必要があります。 この結果を出力するためにAgentsはおおまかに下記のような動作をしているイメージです。 プロンプトをllmに渡し必要なアクションを決定⇒トレース情報の取得（get_trace_listの呼び出し） get_trace_list(指定されたトレースID)の結果をllmに渡し、次のアクションを決定⇒エラーと関連するソースファイルの読み込み（read_fileの呼び出し） a. 読み込んだソースコードとトレース情報をllmに渡し、llmが調査完了と判断（原因が判明）するまでアクションを繰り返す 最終回答を出力 目的を達するまで利用可能なツールを用いて自律的に調査を進めてくれる有能なアシスタントという感じですね。 さて、そんなAIの出力結果をまとめると下記のようなことがわかります。 エラーの発生箇所 SampleControllerのsampleメソッドのメール送信部分 エラーの発生理由（直接原因） $sample->emailの値が空かメールアドレスの形式として正しくない エラーの回避策 メール送信前にアドレスチェックを行う 考慮点 エラー発生時にユーザーにエラーを通知する この結果から$sample->emailの値がおかしいということになり、その取得元であるDBのテーブルを確認したところ、正しくメールアドレスが格納されていないということが判明し、そのデータを修正することでエラーが解消しました。今回はテスト環境での事象だったのですが、その環境を構築する際に正しくデータが作成されていなかったようです。 このように、AIがトレース情報とソースコードを読み取り、トレース情報中のエラーログやパラメータ情報などから、例外発生の要因を解析し、ソースコードの問題発生箇所まで特定してくれました。従来のデバッグであればローカル開発環境で事象を再現しながらステップ実行したり、大量に出ているログから問題のログを見つけ出したりするなどの手間がかかっていたところですが、AIとAPMを利用することでその手間を削減することができました。 まとめ 時間やリソースを多く必要とするデバッグ作業について、AIが例外発生の要因を的確に解析し、ソースコードの問題発生箇所まで特定してくれることが分かりました。また、テストケースごとのトレース情報やログの収集は、APMやツールを活用することで比較的容易になり、テストケースが実行されて問題が発生した際には、迅速に情報を収集し、AIにデバッグを依頼する環境を整備することができました。 正直なところ、AIデバッグがどこまで問題を詳細に分析できるのか不安でしたが、私が想定していた以上に、細部まで分析し、問題点を指摘してくれました。AIに対する命令は比較的シンプルで汎用性があり、他のプログラムのデバッグにも流用可能だと思います。 近年、AIを利用した革新的なサービスが急速に増えています。その中で、AIによるデバッグは開発者たちを支援し、品質の向上に寄与すると感じています。適切な場面でAIを利用することが、より良いデバッグにつながると考えています。 株式会社AGESTでは、ソフトウェアテストのオプションとして「AIデバッグ」というデバッグのサービスを提供しています。本サービスは、AGESTの次世代QAエンジニアがAIを活用したデバッグを実施しており、次世代QAエンジニアとAIの力と、APMによるデータ収集を活用し、結合テスト・総合テストにおける開発者の不具合対応の負荷を大幅に削減します。お困りごとがありましたら、当社にお気軽にご相談ください。 ※1 Langchain：大規模言語モデル（LLM）を効率的に実装するためのフレームワーク。開発者がLLMを使用したアプリケーションを簡単に作成できるように設計されており、特にGoogle CloudのLLMであるPaLM 2を操作する基本的な方法を提供している。 ※2 APM：「Application Performance Management」の略で、アプリケーション性能管理を意味します。これは、アプリケーションやシステムの性能を監視し、管理するプロセスです。APMツールは、アプリケーションの応答時間や、構成要素のパフォーマンスを調査し、アプリケーション全体の稼働状況を把握するために使用されます。 The post AIの目で見るバグの世界：デバッグの未来形 first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。 「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。 この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ 推論の形 を見ていきます。 ＜テストエンジニアのための論理スキル[実践編]　連載一覧＞ ※クリックで開きます ・ 論理のかたち。推論とは 【連載初回、全文公開中】 今回のテーマは「基本的な推論形式」です。 「推論」と言われると難しそうに感じるかも知れませんが、“入門編”で見た「論理の言葉」が基本になります。 「論理の言葉」を復習してから、推論を支えてくれる基本的な形を見ていきましょう。 前回のクイズ解答 前回、「 論理のかたち。推論とは 」で出題したクイズの解答です。 （問1, 2とも、今回の内容でおさらいしています） 問1 Aさんの性格を考えると、①Aさんはギャンブルに手を出すと破産する。 しかし、②Aさんはギャンブルには手を出さない。 従って、③Aさんは破産しない。 ①は「PならばQ」という 条件法 の形をしています。 ②③は①に対し「PでないならばQではない」という、“裏”の形をしていますが、これはよい形ではありません。 問2 その時代、①家柄がよくて、裕福ならば、誰でも結婚できた。 ②彼の家柄はよかった。 しかし、③結婚できなかった。 従って、④彼は裕福ではなかった。 ①は「(PかつQ)ならば、R」という形をしています。③の「Rではない」から、「Rでないならば、(PかつQ)ではない」という 対偶 の形が考えられます。「(PかつQ)ではない」ということは、「Pでないか、またはQでない」ということです（ ド・モルガンの法則 ）。 ②でPであることが言われているので、「Pでない」可能性は消え、残る「Qでない」が結論として④で述べられています。この主張はよい形をしています。 推論を形づくる“道具” 推論で大切なのは、前提から結論まで筋道を立ててつなげていくことでした。その筋道は、「論理の言葉」をいわば“道具”として作ります。 この“道具”の使い方をよく理解しましょう。 文と文を繋げる道具　――論理の言葉おさらい 基本の論理演算：AND/OR/NOT 論理の言葉の基本のうち、論理演算、AND(論理積)、OR(論理和)、NOT(論理否定)の真理値表を図2-1に示します。（ “入門編”第3回 基本の論理演算 ） 図2-1 基本の論理演算・真理値表 “ならば”と、等値(同値)の“ならば” 条件・場合を表す言葉“ならば”(条件法)と、等値の“ならば”(双条件法)も、論理の言葉の基本でした。（ “入門編”第6回 条件・場合を表す言葉 ） これらにも真偽があり、真理値表で表すことができます。 「“ならば”という言葉の働きが成り立つ場合(真)と成り立たない場合(偽)がある」と考えてください(図2-2)。 図2-2 条件法と双条件法 条件法の真理値表(図2-2 左)で「おや？」と思うところがありませんか？ 2行目・4行目。 Pが偽の時、Qが真でも偽でも“ならば”は真 となっています。 これは条件法の 「Pが真でない時」のことは何も言っていない という性質に由来します。何も言っていないのだから、Qが真でも偽でも“ならば”自体は成り立つ、「あり」とする、という 約束、取り決め と考えてください。（なお、この性質を悪用すると、とんでもないことも「妥当な推論」として言えてしまいます） 3行目。「PならばQ」は、「Pが真なのにQが偽であることはない」という意味です。そこで、 Pが真でQが偽の場合は、条件法は偽(成り立たない) と考えます。 “実践編”での呼び方：選言、連言、仮言、定言 論理積/論理和といった用語に代えて、“実践編”では、堅い響きですが短い呼び方を用います。 論理積(“かつ”)を 連言 とも呼びます。ふたつの主張/判断が連なっているイメージですね。 論理和(“または”)を 選言 とも呼びます。ふたつの主張/判断のいずれかを選び取るイメージですね。 条件法(“ならば”)は 仮言 とも呼びます。“ならば”を用いた主張/判断を 仮言文(仮言判断) と呼びます。 仮言文に対し、「ネコは哺乳類である」「ネコは鳥類ではない」といった断言形式の主張を、 定言文(定言判断) とか 断言文(断言判断) と呼びます。 基本的な推論形式 (1) “入門編”で見たことのあるもの 論理の言葉はそのまま使える 前章でおさらいした基本的な論理の言葉の性質や働きと、次に挙げる論理の言葉の働きは、そのまま推論に用いることができます。 図2-3で、 ⇔の左辺の形は右辺の形に、右辺の形は左辺の形に言い換えることができます ( 前回のクイズ 参照)。 図2-3 基本的な推論形式 (1) 二重否定は “入門編”第3回 基本の論理演算 参照 ド・モルガンの法則は “入門編”第4回 論理演算の組合せ 参照 3・条件法と対偶に関して、逆（QならばP）と裏（PでないならばQでない）は一般には正しくないことも思い出しましょう。 4・条件法の言い換えについて。Pの否定・NOT(P)とQとのORをとると（ NOT(P) OR Q ）、“ならば”と同じ真理値の表が得られます(図2-4)。 この関係から、「PならばQ」は「Pでないか、またはQである」と言い換えて考えることもあります（このように同じ真理値を持つ論理演算どうしの関係も“同値”と呼びます）。 図2-4 “ならば”と「Pでないか、またはQ」 基本的な推論形式 (2) ちょっと複雑な形 推論を形づくる論理の言葉 論理の言葉を組み合わせて、複雑な推論の形を組み立てることができます。その中でも基本的な形とされているものをいくつか図2-5に示します。 図2-5 基本的な推論形式 (2) 6は“または”の意味/働きを使った推論で、 選言三段論法 と呼ばれます。 7, 8, 9は、“ならば”の意味/働きからこのような推論ができます。 7は 前件肯定 、8は 後件否定 というもので、9は“ならば”を重ねています。 併せて 仮言三段論法 と呼ばれます。 10, 11は複雑さが増して感じられますが、「AかBかどちらか」ということを言い表すのに使います。これらは 両刀論法(ディレンマ, ジレンマ) と呼ばれる形です。 次回以降、これらの推論形式を詳しく見ていく予定です。 「当たり前」には裏づけがある 図2-5、（10, 11は別としても）どれも「当たり前では？」と思う人も多いでしょう。実際、これらは私たちの日ごろの思考に通じているものがあります（というか、「私たちの思考」を吟味して論理の言葉や推論の形式ができているのですが）。 この「当たり前」は論理の言葉が保証してくれている、裏づけがある、と知っておくのは大切なこと です。 「よい形」であるのは、当たり前だからなのではなくて、「論理の言葉の使い方として正しいからよい形（妥当）」ということです。 三段論法 2,000年以上の歴史を持つ推論の形 前章で三段論法という言葉が出てきました。 前提2個に結論1個で構成されるから「三段論法(syllogism)」と呼ばれます（前提の数は3個以上でもよい）。 「大前提、小前提、結論」という用語の組を聞いたことのある人も多いでしょう。 ふたつの前提に論理の言葉の働きを作用させたり、主張している事柄の関係性を考慮したりして、結論を引き出すようになっています。 図2-6 三段論法 “定番”の三段論法 「三段論法」と言われたら、多くの人は次の形のものを思い浮かべるのではないでしょうか（“または”も、“ならば”も、使われていません）。 人間は誰しも死ぬ。 ソクラテスは人間である。 ゆえに、ソクラテスは死ぬ。 これを見て「当たり前のことを言っているなあ」と思う人も多いと思いますが（筆者もそうです）、この形はこの形で私たちのものの考え方に根ざしており、知っておく意義はあります。 この形の三段論法は連載後半で取り上げる予定です。 クイズ （解答は次回に） 次回予告 先の「基本的な推論形式 (2)」で出てきた「“または”を使う推論の形（選言三段論法）」を詳しく見ていきます。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 John Nolt, Dennis Rohatyn(著), 加地大介(訳) 『現代論理学 (Ⅰ)』 オーム社 1995 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 レイモンド・スマリヤン(著), 高橋昌一郎(監訳), 川辺治之(訳) 『記号論理学　一般化と記号化』 丸善出版 2013 図版に使用した画像の出典　 TopeconHeroesダーヤマ, 『分かりやすいプレゼン資料 1秒で伝わるビジネスイラスト集』 インプレス 2016 クイズの画像に使用しています。 テストエンジニアのための論理スキル[実践編] 連載一覧 論理のかたち。推論とは 【連載初回、全文公開中】 The post 基本的な推論形式｜テストエンジニアのための論理スキル［実践編］ first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第9回となる今回のテーマは「プロジェクトの品質マネジメント」です。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 品質をマネジメントする、とは プロジェクトマネジメントにおける品質のマネジメントとは、ステークホルダーの目的に合致させるためにプロジェクトとプロダクトの品質要求事項を計画し、組織の品質方針等を取り入れた形でマネジメントしていく活動です。マネジメントの対象は「プロジェクトの品質」と「成果物の品質」の主に2つです。 品質のマネジメントと聞くと、不具合やバグが出ないようにするといったイメージになるかも知れませんが、たしかにそれは品質の1つではありますが全てではありません。成果物だけではなく、プロジェクト、つまり進め方自体の品質管理にフォーカスしていることが重要です。例えば、プロジェクトのスケジュールが計画に対して維持されているか、予算内で実行できているか、これらのスケジュールマネジメントやコストマネジメントにかかる部分もプロジェクトの品質マネジメントにおける品質対象です。 品質マネジメントは以下3つのステップ（プロセス）で行います。 品質のマネジメントを計画する ステークホルダーの真のニーズを確認して「品質要求事項」を特定することから計画ははじまります。またCOQ（Cost Of Quality）、つまり品質を担保するために必要なコストを考慮し獲得しておくことが大切です。 1) 病気もプロジェクトも予防が大切 品質にかかるコストは以下の4種類に分類されます。 大切なのは適合コストと不適合コストのバランスです。適切に適合コストを使わないと不適合コストの発生確率を高めることになりますが、適合コストばかりかけすぎると利益を圧迫してしまうことになります。コスト効果としては一般的に適合コスト＞不適合コストをかけた方がよいです。 2) 「よい品質」にはばらつきがある 一言で「よい品質」「品質が保たれている」といっても、多くの場合同じ品質が指されていることはありません。Aさんは「 XX まで担保されればよい品質だといえる」と思っていても、Bさんは「それでは不十分で XXX でなければ担保されているとは到底言えない」といった感じです。また顧客とのやりとりで「高いクオリティで」という曖昧な要求を受け取る経験も少なくないはずです。 近代的品質マネジメントの提唱者は以下のように言っています。 「品質とは要求条件の一致である」 「無欠陥（Zero Defect）、検査より予防」 フィリップ B.クロスビー 「品質は誰かにとっての価値である」 G.M.ワインバーグ つまり、「品質がよい状態」とは、ステークホルダーの要求を満たし、ステークホルダーにとって価値あるものを提供することと言えますが、見ての通り「よい品質」という定義の曖昧さや捉え方によるばらつきがある（起こる）ことも同じように示していますね。 だからこそ、プロジェクトが考え目指す品質や組織で定義されている品質方針を踏まえて「どうすれば実現できるか」を品質マネジメント計画書などのドキュメントで明らかにし、みんなで品質視座をあわせて目指していけるように準備しましょう。 ＜品質マネジメント計画書に記載される基本的事項＞ プロジェクトの品質基準 品質に関する役割と責任 品質レビュー対象やレビュープロセス 品質マネジメント活動や方法 品質ツール 不適合や是正措置プロセスなどの手続き規定 3) 品質を測定する尺度を決めておく 品質尺度とは、品質の適合を「どのように検証するか」を具体的に規定したものです。クオリティメトリクス（QM）と呼ばれることもあります。例えば、時間通りに完了したタスクの割合、突き当たりの合計ダウンタイム、コード行あたりのエラー、顧客満足度、テスト網羅率の基準としてテスト計画がカバーする要求事項の割合などがあります。品質そのものへの考え方やばらつきがある、とお伝えしたように、品質を何かしら測定する尺度を持っておくことで「こんなはずじゃなかった、これは違う」というトラブルや認識齟齬を予防しましょう。 4) 品質指標 上記の品質尺度に対して、品質指標は「品質を満たしているということはどういう状態か」を定義しておきます。品質指標が顧客の要求を満たした状態か、できる限り具体的な状態を定義しておくことが品質尺度と同様に大切です。 品質のマネジメント 品質のマネジメントでは、組織の品質方針をプロジェクトに組み入れて、品質マネジメント計画を実行します。品質のマネジメントは場合によって「品質保証」とも呼ばれます。プロジェクトマネジメントの観点では、品質保証の焦点はプロジェクトの「プロセス」にあるとともに「検査より予防」の考え方と密接に関連しています。その為、計画した品質を担保する仕掛けや仕組み（規約・ガイド）が正しく機能しているかを＜確認＞することがが重要です。 1) どうやって品質確認する？QC７つ道具を押さえておこう！ 品質標準と運用基準を満たすために、プロジェクトでは常に品質改善活動を行っていかなければなりません。継続した活動の中で、無駄なくプロセスを実行できるようパフォーマンスの測定結果を確認し、問題点を改善していきましょう。改善点を洗い出すためには、まず品質コントロール測定結果を分析します。分析には「QC7つ道具（7つの手法）」や「品質監査」を用いて問題点や改善につながるヒントを抽出し、必要なプロセスの改善点をまとめて必要に応じ変更（変更要求）を行いましょう。 また「QC7つ道具」を使った数値分析は主に製造現場で活用されてきましたが、「新QC7つ道具（N7）」は実測や数値化が難しい場合や言語データも併せて分析することで設計や営業など幅広い改善活動に活用される手法です。QC7つ道具と新QC7つ道具がどのようなもので、どのように活用することができるのかを簡単にでもいいので把握し、ぜひ品質マネジメントに取り入れてみてください。 ＜QC7つ道具：データ整理や関係性分析手法＞ パレート図 特性要因図（フィッシュボーン図・フィッシュボーン分析） グラフ ヒストグラム 散布図 管理図 チェックシート ・QC7つ道具は「Q7」と略称されます。 ・QC7つ道具及び新QC7つ道具の作成手順は「JIS Q 9024:2003 マネジメントシステムのパフォーマンス改善－継続的改善の手順及び技法の指針」でJIS化。 ・新QC7つ道具は「New seven tools for QC」あるいは「New 7 QC Tools」と呼ばれ、「N7」と略称されることもあります。 3) プロジェクトの品質保証活動に組織の品質保証活動を活かす 組織内に品質保証部門などを有する場合、プロジェクト活動でそれらの部門との連携やプロジェクトチームに組み入れるなどして、故障解析や実験計画、品質改善などのマネジメント活動を実行しましょう。豊富な品質ツールと技法を持った専門部門はプロジェクトにとって優れた資源です。 4) 製品は80％が設計で決まる、デザイン・フォー・エックス（DfX）という考え方 1990年代に米国で提唱、実践されたデザイン・フォー・エックス（DfX：Design for X）は、設計（デザイン）における個々の側面を最適化するためにプロダクト設計に取り入れる技術的なガイドラインのことを言います。DfXのXは信頼性、展開、組み立て、製造、コスト、サービス、使い勝手、安全性、および品質といったプロダクトの開発におけるさまざまな側面を指します。こうして多面的な設計思想を持つことで、コスト削減や品質改善、パフォーマンス向上や顧客満足の達成を目指しましょう。 品質のコントロール 成果物（アウトプット）が品質要求事項を満たしているかを検査し、その結果適合・不適合とを判定します。適合とされた上で、ステークホルダに受け入れられてはじめて「受け入れ済み成果物」と呼ぶことができます。 1) 品質マネジメント７原則 「品質マネジメント7原則」とは、品質マネジメントシステムの規格のISO9001で、適合性と有効性を維持した品質マネジメントシステムを構築する為の大枠を7つの原則として示したものです。 原則1：顧客重視 原則2：リーダーシップ 原則3：人々の積極的参加 原則4：プロセスアプローチ 原則5：改善 原則6：客観的事実に基づく意思決定 原則7：関係性管理 ISO9000:2015 品質マネジメントシステム－基本及び用語 さいごに プロジェクトマネジメントにおける「品質のマネジメント」はテストやプロダクト、サービスだけでなく、それらを生み出すまでのプロセスが重要になっていきます。開発中に多くの品質問題がでる、それらの対応などで計画していた開発期間を大幅に超過する、プロダクトは完成したけれども不具合が多発してしまう。もしそんなことが起こっていれば、これは品質のマネジメント自体に課題がないか目を向けてみてください。 次回のテーマは「リスクマネジメント」です。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 The post 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 first appeared on Sqripts .

こんにちは。QAエンジニアをしているポポラスです。私はコールセンター等でサービス受付をするシステムの受入テストを担当しております。 私の現場では、ユーザーの実際のオペレーションの情報が少なく、テストベースは要件定義書のみでテスト設計を行っております。そのような状況において、ユーザー観点を出し、実際のオペレーションに沿ったシナリオを設計するために私が工夫した3つのことを、経験事例を交えてご紹介させていただければと思います。参考になりましたら幸いです。 前提 私が経験していた現場は、システムの操作方法に関する情報が乏しく、また実際の利用者からのヒアリングが出来ない状態でした。そのような中で第三者検証として受入テストを担当させて頂いた際の経験です。 工夫したこと 以下の内容は、実際に私が現場で工夫したことになります。もし実際のオペレーションの情報が無く、設計にお困りの場合、観点出しのお役に立てることがあるかもしれません。ぜひご覧ください。 その１：機能の目的を考える 機能の目的を考えることで、実際のオペレーションに近いシナリオを導き出せることがあります。 以下は実際に私がテスト設計を担当した機能での経験事例になります。 <経験事例> ■機能 サービス対象端末の特殊在庫の表示 ■機能の目的を考えなかった場合のシナリオ まず、機能の目的を考えなかった場合のシナリオは以下になります。 前提条件： なし シナリオの流れ： ①端末Aの画面に遷移し、特殊在庫を表示する ②特殊在庫を選択し、オーダーを完了させる ■機能の目的を考えた場合のシナリオ 特殊在庫機能の目的は、通常在庫が切れた場合かつサービス利用者がどうしてもその端末を希望する場合に、予備の在庫を臨時的にサービス利用者に提示すること、と考えられます。 上記の目的から、以下のシナリオが導き出せます。 前提条件： 端末Aの通常在庫なし シナリオの流れ： ①端末Aの画面に遷移し、通常在庫切れ表示となることを確認 ②特殊在庫を表示する ③特殊在庫を選択し、オーダーを完了させる 機能の目的を考えたことで、「前提条件」と「シナリオの流れ①」がより実際のオペレーションに近い条件として導き出すことができました。 その２：3w1h 機能の目的を考えることで実際のオペレーションに近いシナリオを導き出せましたが、この「3w1h」では、そのシナリオに対して観点のバリエーションを持たせることができます。 今回ご紹介する「3w1h」は以下の要素となります。 Who（だれが） When（いつ） Where（どこで） How（どのように） 実際に私の現場で実践した3w1hは以下になります。 <経験事例> ■機能 サービス対象端末の特殊在庫の表示 ■「Who（だれが）」の考察 これは「システムを使用するユーザー」という理解で考察します。実際にサービス受付システムを使用するユーザーは以下3つのタイプが存在しますので、観点のバリエーションに加えることができます。 コールセンターのオペレーター 店舗の担当者 サービス利用者 ■「When（いつ）」の考察 これは機能が使われる「状況」という理解で考察します。状況として以下4つのパターンが考えられます。 通常在庫が切れた時 通常在庫が補充された時 特殊在庫が切れた時 特殊在庫が補充された時 ■「Where（どこで）」の考察 これは場所ではなく、私の現場の場合は機能を使用するプラットフォームという理解で考察します。プラットフォームは以下3つのパターンが考えられます。 コールセンターのオペレーターが使う受付システム 店舗の担当者が使う受付システム サービス利用者が直接Webサイトからオーダーする受付システム ■「How（どのように）」の考察 これは「どのように機能を実行するか」という理解で考察します。以下4つのパターンが考えられます。 デスクトップPCから特殊在庫を確認する ノートPCから特殊在庫を確認する スマートフォンから特殊在庫を確認する タブレットから特殊在庫を確認する その３：UMLを使ったアプローチ 工夫その１と２は、ユースケース図やアクティビティ図といったUMLを、テスト視点で活用することで導き出すアプローチもあります。UMLを使うことで、機能の目的や3w1hの観点を整理することができ、整理した観点を俯瞰的に見ることで、観点の抜け漏れや新しい観点の気付きにも繋がります。 ユースケース図 アクティビティ図 その４：顧客から情報を引き出す 顧客から市場での実際のオペレーションの情報を引き出すことで、シナリオの設計に活用できます。これは最もシンプルな方法ですが、最も実際のオペレーションに近い情報となりえます。 その５：観点のフォーマット化 工夫その１～４で導き出した観点をフォーマット化することで、他要件の観点出しにも流用が可能となります。更にフォーマットをチーム内で共有し、ユーザー観点を蓄積していければ、フォーマットのブラッシュアップを行っていけます。 結果 上記の工夫を行うことで、受入テストのユーザー観点不足を緩和することができ、より実際のオペレーションに近いシナリオを充実させた受入テストを行うことができます。 まとめ 実際のオペレーションの情報がほとんど無い現場でも、機能の目的や3w1hを考え、UMLを活用することで、ユーザー観点を導き出していけます。更に、導き出した観点をフォーマット化してチーム内で資産化することで、今後の他要件への流用やユーザー観点のブラッシュアップなどの付加価値を生むことができると思います。 本記事の内容は、受入テストのテスト設計としては当たり前の内容かもしれませんが、私の経験事例が皆様の参考になれば幸いです。 最後まで読んでいただき、ありがとうございました。 The post ユーザー観点を追加したい！そんな時に。受入テストにおけるユーザー観点の考え方 first appeared on Sqripts .

第1回目の記事【 パスワードの基礎と主な管理手法について 】で、パスワード管理手法のうち、業務効率化の観点及び安全性向上の観点からパスワードマネージャーによる管理が有効な手段であることをご紹介しましたが、今回は具体的な選定のポイントについてご紹介をしていきたいと思います。 【第1回】パスワードの基礎と主な管理手法について パスワードマネージャーの選定ポイント 無償ツールと有償ツール パスワードマネージャーは主に無償・有償の観点でツールを大別することができます。 無償ツール：主にブラウザベンダーがブラウザに標準搭載しているパスワードマネージャー機能のこと 有償ツール：専門のサイバーセキュリティベンダーから提供されているもの ※無償ツールの中には有償ツールを提供するベンダーが提供する無償版も存在しますが、今回はスコープ外とします。 無償ツールの特徴（メリット、デメリット） 以下に、無償ツールの特徴をご紹介します。 [代表的な提供ベンダー] Apple（Safari）、Google（Chrome）、Mozilla（Firefox）、Microsoft（Edge,IE） [メリット] ランニングコストがかからない ： 文字通りですが、無償であることが最大の魅力です。 利用・導入の容易さ ： ブラウザの機能となるため、導入作業無しに即時利用が可能です。 [デメリット] 安全面の不安 ： ブラウザはパスワード管理をするための物ではないため、安全面よりも利便性を追求しています。その上で、追加的に付与された機能であるブラウザパスワードマネージャーには安全面で以下の危険があることを認識しておく必要があります。 パスワードの保存/利用と暗号化 一部のブラウザでは一貫した暗号化がなされない（若しくは、なされていなかった）ことが専門家により指摘されております。具体的には、本来、機微情報であるパスワードを暗号化して保管し、復号して利用する場合、そのパスワードを復号できる人は唯一、利用者本人であり、利用者本人がパスワードを利用しないときは完全に暗号化されている必要があります。（＝ゼロナレッジアーキテクチャ ※1 ） しかし、一部のブラウザにおいて、部分的に暗号化がなされておらず平文で保管される瞬間や場所がある（若しくは、あった）ことが指摘されております。 アクセス制御 皆様は普段どれくらいの頻度でブラウザにログインを行っているでしょうか。多くの方は、ほぼ常時ブラウザにログインした状態で作業をし、頻繁にブラウザからログアウト→ログインをするというのは稀なのではないでしょうか。これ自体が悪いわけではありませんが、パスワード管理の観点では危険と隣り合わせの行為と言えます。 ブラウザでパスワードを保管している場合、ブラウザにログインしている間、パスワードは平文で確認することができる状態となっているため、上記のようなブラウザの使い方をされている方は、ほぼ常時パスワードが暗号化されていない状態に晒されていることになります。この状態で端末を紛失したり、他人が端末を操作できてしまえば保管されているパスワードが全て漏洩する危険があると言えます。 マルチデバイス対応とアタックサーフェイス ブラウザでパスワードを保管する場合、その情報は他のブラウザとは共有されません。つまり、複数のブラウザを利用する場合、それぞれのブラウザでパスワードを保管する必要があります。利用方法にもよりますが、一般的に複数回パスワード生成や保管の作業をする必要があるという利便性の低さと、機微情報であるパスワードを多くの箇所に置くことにより、アタックサーフェイス（＝サイバー攻撃を受ける可能性があるポイント）が増えるという安全面での懸念があると言えます。 有償ツールの特徴（メリット、デメリット） 以下に、有償ツールの特徴をご紹介します。 [代表的な提供ベンダー] Dashlane、Keeper Security、LastPass、1Password [メリット] 高い安全性 ： 有償ツールはパスワード管理専用ツールであり、安全面を最重視した設計となっているため、無償ツールがかかえる「安全面の不安」を以下のように解消することができます。 パスワードの保存/利用と暗号化 有償ツールの中でも採用している暗号化アルゴリズム、暗号化の単位は異なりますが、基本的に ゼロナレッジアーキテクチャ ※1 に基づいた暗号化メカニズムが採用されており、パスワードが平文で晒されるようなことがない設計となっています。 アクセス制御 有償ツールのほとんどがログインタイマー等の設定がデフォルトで有効化されており、パスワード利用後は自動的にログアウトする設計となっています。 利便性が下がるように思われるかもしれませんが、有償ツールのログインに指紋認証や顔認証を用いることで、利便性が大幅に下がることを防ぐこと可能です。 痒い所に手が届く ： 一部後述する「パスワード利用状況の可視化」、「適切なパスワード共有管理」等のパスワード管理専用ツールとしての機能を利用することができ、包括的なパスワード管理が可能です。 [デメリット] ランニングコストがかかる： 当たり前ですがコスト発生はデメリットであり、メリットとの比較が必要になります。 ※1 ゼロナレッジアーキテクチャ（ゼロ知識アーキテクチャ） ゼロ知識アーキテクチャとは、顧客データの平文（暗号化されていないデータ）をベンダーのクラウドに送信することなく、ユーザーのデバイス上でのみ暗号化と復号を行う仕組みです。 アプリケーションが平文を保管することはありませんし、ベンダーのクラウドが平文でデータを受信することもありません。 データが他のデバイスに同期される場合には、他のデバイスで復号（デコード／暗号化データの解読）されるまで、データは暗号化されたままとなります。 無償ツールと有償ツール、選定のポイントは？ GoogleChromeのパスワードマネージャー では、無償ツールと有償ツール、どちらのパスワードマネージャーを利用すべきなのか。 ここからは、選定時のポイントについて解説をしていきます。 無償ツール　→　有償ツールの順序で考える 最初にお勧めしたい大切な考え方は「無償ツールで運用できないか？」からスタートすることです。この考え方でスタートし、どうしても有償ツールが必要な場合には有償ツールを検討する、という順序が重要となります。 その上で、無償・有償の判断が分かれるポイントして以下の要素が参考になります。 個人利用か法人利用か？ この観点でいうと、個人利用＝「無償ツール」、法人利用＝「有償ツール」と考えるのが一般的です。 個人利用の場合、パスワードの管理責任は各個人にありますが、法人利用の場合、その管理責任は法人に帰属する点がポイントです。一般的に有償ツールには、組織全体のパスワード管理状況を可視化し、管理者は各従業員の「 パスワード使い回しの有無 」や「 弱いパスワードの利用 」をチェックする仕組みが搭載されています。しかし、無償ツールにはそのような仕組みは存在しません。（もちろん、スプレッドシートやメモにも存在しません） そのため、法人利用に無償ツールを選定してしまうと、適切なパスワード管理が組織的になされているか分からず、サイバー攻撃後のインシデント調査ではじめて管理体制の不備を指摘されるという結末になりかねません。こういったことから、基本的には法人利用＝ 有償ツールが適している という結論になります。 ※但し、小規模な組織等で、何らかの手段で適切なパスワード管理を組織として担保できる場合には、法人利用でも無償ツールは有効な手段となり得ます。 例：セキュリティ知識のある数名で設立したベンチャー企業など。 共有アカウント（＝ID/PW）はあるか？ そもそも、「パスワード共有」自体、行わないことがベストなのは言うまでもありませんが、業務上、やむを得ないケースも存在致します。 よくあるのが、SNSアカウントの運用を複数人で行うケースや、外部から付与・貸与されているアカウントを複数人で行うケースです。 このようなケースでは、必然的に1つのアカウントを複数人で共有しながら運用していくことになるため、ID・パスワードの管理を安全かつ効率的に行うことが業務上でとても重要となります。 そして、ほとんどの有償ツールにはこのような課題を解決するためのパスワード共有機能が搭載されています。詳細な機能説明は各ツールごとに異なるため省きますが、この機能を用いることで、メールやスプレッドシートで平文もしくはそれに近い低強度な保護でID・パスワードを共有するのではなく、有償ツール上で、必要な時に、必要な人にだけ（＝Need to KnowやLeast Privilegeの原則に沿った）、高強度の保護と共にID・パスワードを簡単に共有することが可能となります。 まとめ パスワードマネージャーは無償ツールと有償ツールで大別されます。 無償ツールは安全性よりも利便性を重視しており、有償ツールはその逆と言えます。 無償/有償をどちらかにするか考える時は「無償ツールでいけないか？」から考え、ダメなら有償ツールを考えるのがオススメです。 個人利用＝「無償ツール」、法人利用＝「有償ツール」が基本的な考え方となります。 法人利用の場合、従業員の「パスワード使い回しの有無」や「弱いパスワードの利用」をチェックする仕組みが必要となります。 次回はMITREフレームワークに見るパスワード管理について解説します。 シリーズ「組織におけるパスワード管理」記事一覧 【第1回】パスワードの基礎と主な管理手法について The post 【第2回】パスワードマネージャーの選定時のポイント first appeared on Sqripts .

みなさんは、知的生産や知的生活ということばを聞いたことはありますか？ 初めて聞いた、という方はもしかしたら「堅そう」とか「えらそう」といった印象を持つかもしれません。 ところが、私はこの知的生産・知的生活は「ITエンジニア皆に知っておいてほしい」と考えています。もちろん、好き・嫌い、合う・合わないはあるでしょう。 そのため「全員に身につけておいてほしい」ではなく「そういった考え方があると知ってほしい」と、一段階トーンを下げた言い方をしています。 この連載では、ITエンジニアにとって親和性が高く「スキルアップしたい」と思う方にとっては役に立つであろう知的生活について、いろいろなアクティビティやツール、仕事での活用方法などについてご紹介します。知的生産・知的生活の考え方や、「そもそも知的生活とはどうあるべきか」等の話ではなく、できるだけエンジニアの普段の生活や仕事に役立てられるテクニックよりの話をするつもりです。 知的生産・知的生活とは テクニックの話をします、とは言ったものの、知的生産・知的生活について事前情報なしに話を進めてもわかりづらくなってしまいます。 まずは知的生産・生活をこの連載においてどのような意味で扱うかや、それがエンジニアにとってどう関係するのかからスタートしましょう。 知的生産界隈における有名な書籍のひとつに、『知的生産の技術』があります。 この本によると、知的生産は 知的生産というのは、頭をはたらかせて、なにかあたらしいことがら――情報――を、ひとにわかるかたちで提出すること 「知的生産の技術」（岩波新書） くらいに考えておけばよい、とされています。 これを元に、私は知的生産というものを、 インプット 処理 アウトプット の3要素で考えています。 つまり、アウトプットである「なにかあたらしい情報や価値」を出すために、いろいろなインプット＝情報をあつめて、自分の頭やいろいろな道具を使って処理＝思考をする。これが知的生産です。 そして、知的生産を日常生活の中に組み込み、ひとつの楽しみとして行うことが「知的生活」であると考えています。 ちなみにこの『知的生産の技術』は1969年に初版が発行されたもので、知的生産という概念はこれだけ昔から存在していました。 ITエンジニアと知的生活 前述の知的生産の要素に照らすと、多くのITエンジニアが行っているような 技術書を読む 技術的な情報を集める、調べる 勉強する テックブログを書く 勉強会などで発表する 技術書や技術系同人誌を書く なども、ひろく知的生活の一部と言っていいでしょう。 一部、というのは、たとえば技術書について「読みっぱなし」では知的生産とは言えません。そこからアウトプットまで行って初めて知的生産といえます。もちろんこれは感想ブログを書く等に限らず、本で得た知識を普段の仕事に活かすことも立派なアウトプットでしょう。 我々ITエンジニアは知識労働者（ナレッジワーカー）と表現されることがあります。知識や経験を使って価値を生み出すことが求められます。これは、まさに知的生産といえます。 ITエンジニアの周辺では、たびたび「自己研鑽」が話題になります。気合いを入れて毎日勉強するのも良いですが、そうではなく日々の知的生活を楽しんでいたらいつのまにかスキルアップしていた、そういった形もアリだと考えています。皆さんの周りにもそのようなタイプのエンジニアが居るのではないでしょうか。もしくは、あなた自身がそうかもしれません。 楽しみながらスキルアップしたいという方にとって、知的生活をより楽しく実りあるものにするためのテクニックや考え方を学ぶことは、エンジニアとしての成長に直結するのです。 知的生活をよりよくするためのツールや考え方 先に、ITエンジニアにとっての知的生活の要素として インプット 処理 アウトプット の3つが考えられる、と述べました。 それぞれの要素について、よりやりやすくしたり、効果的に行うためのツールや考え方があります。 本連載では次回以降これらのツールや考え方、実際の活用方法などをご紹介します。本記事でも、それぞれ簡単に触れておきましょう。 インプット 知的生活では日常的なインプットが大切です。我々ITエンジニアは日ごろからさまざまな情報が勝手に流れてくる環境にあるため、あえて「大切です」という必要はないかもしれません。 SNSではソフトウェア開発にまつわるプラクティスや言語・フレームワークなどの情報も日々流れてきます。もちろん、読書や日々の業務中の調べ物もインプットにあたります。 「どうやって情報を集めるか」に苦労する方も居るかもしれませんし、一部には「大量に流れてくる情報をどう拾いあげ、自分のものにするか」で困っている方もいるかもしれません。 個人のナレッジを蓄積・管理する概念として「PKM：Personal Knowledge Management」があります。主にデジタルなツールを用いて、インプットした情報を管理しその後の処理→アウトプットにつなげる方法論で、蓄積した複数のメモやノートの類似性やつながりから新たに着想を得たりします。 こうしたデジタルツールを用いた情報蓄積は、ふだんからPCやデジタルデバイスに向かって仕事をしているITエンジニアにとって好相性です。皆さんの中にも、言葉自体は初めて聞いたけれども前からやっていたことに近いな、と感じる方がいらっしゃるでしょう。 処理 前段のインプットにて得た情報を蓄積することで、先のアウトプットに至るためのさまざまな処理を行います。処理といっても、ここでは機械的にできることだけではありません。 会社のテックブログの執筆当番が回ってきて、「何を書こうかな・・・」と過去のメモを見返してうんうんとうなるようなことも、この処理に該当しています。 ここでは主に、蓄積した情報をもとにどう発想するかや、発想を得るための道具について扱います。 ソフトウェアテストを仕事にしている方は、「マインドマップでソフトウェアテスト」という手法を聞いたことがあるかもしれません。この例ではマインドマップはまさに発想を得るための道具ですし、テストのためにマインドマップを使う際の考え方・使い方が発想法に該当します。 アウトプット アウトプットに関しては、ツールというよりも習慣化・仕組み化や、どのような場にアウトプットするかが重要になるでしょう。 現在はSNSやブログサービスなど無料でアウトプットを公開できる場がいくつもあります。また、エンジニアのアウトプットという点では、勉強会で登壇したり同人誌や一般書籍としてまとめることもできます。 ただ、いきなり「アウトプットしましょう」と言われても難しいという方も多いと思います。今後の連載の中では、小さいアウトプットから大きなアウトプットにつなげていく流れについても解説します。 効率だけでなく、楽しく知的生活を送ろう 本記事では知的生産や知的生活について、そしてそれらがエンジニアにとってどう関係するのか、またエンジニアの知的生活の要素についても簡単に触れました。 エンジニアにとっての知的生活は、もちろん成長につながることを目指して行う面もあります。ただ、成長速度や効率ばかりを追い求めてしまうと、苦しくなってしまいます。 この連載では効率もですが、より「楽しく継続できる」ことを大事にしたいと考えています。 仕事のためにとプログラミング言語を習得するよりも、便利ツールや作りたいアプリケーションのために身につけるほうがいい、という考え方と似ています。 知的生活やその要素自体を楽しんでいった先で、気がついたらエンジニアとして成長・スキルアップしていた、という状態を目指していきましょう。 The post 知的生活とはなにか？エンジニアにどう関係するのか first appeared on Sqripts .

こんにちは。クオリティマネージャーのおすぎです。 「段取り八分、仕事二分」という言葉があります。 仕事の事前準備の大切さを表すもので、仕事に取り掛かる前にきちんと段取りを済ましておくことで仕事の8割は完了している、という格言です。 段取りはプロジェクトマネジメントにおいても非常に重要になります。 蛇足ですが「段取り」の語源をネットで調べると 作業の順序や方法を定めたり必要に応じて手配をしたりすることで、歌舞伎の楽屋用語からきているとされています。「段」とは一区切りや一幕のことで、芝居の筋や構成の運びを段取りと言う。  だそうです。 プロジェクトの成功率 一般的に「プロジェクトの成功率は30％」と言われています。 成功の基準は一旦脇に置きますが、例えばJUASが発行している ※1 「 企業IT動向調査報告書 2023 」を見てみると、予定工期を守れたプロジェクトは、100人月未満のプロジェクトの場合で全体の3割程度になっています。 プロジェクトの規模が大きくなればその割合はさらに減る傾向にあるようです。 一昔前のプロ野球なら3割打てれば一流打者と言われたものですが、プロジェクトマネジメントも3割の確率で成功させれば一流の証になるのでしょうか？？？ どうせやるなら3割と言わず10割を目指したいですが、自分の担当するプロジェクトがその3割の成功プロジェクトに仲間入りできるのかどうかは、この「段取り」にかかっていると言っても過言ではありません。 今回はプロジェクトを進める上で「段取り」がもたらすメリットと、私が「段取り八分」を実現するために実際に意識していることをご紹介します。 「段取り」に期待するメリット プロジェクトを段取り良く進めることで様々なメリットがあると思いますが、私は主に２つのメリットがあると考えています。 生産性の向上 業務の効率化 働き方改革が叫ばれる中、生産性を落とさずに就業時間内で作業を完了できるかを求められることが多くなってきました。 働き方改革を実現するためにも生産性の向上や業務の効率化は避けて通れない道だと思いますが、段取りを上手く進めることは、その実現に大きく寄与します。 生産性の向上 何をするのかはっきりしない状態で作業を開始しても、何から手を付けて良いかわからなければ、作業はすぐに停滞してしまいます。 作業のスコープや優先度を明確にすることで、作業を停滞させることなくスムーズに進めることができます。また、スコープがはっきりしていることで作業の手戻りを減らすことにも繋がるため、リソースを無駄なく最大限に活用することができます。 プロジェクトを進める中で発生するであろうリスクを事前に洗い出しておくことで、実際に問題が発生した場合でも速やかに対応することができ、作業の停滞を最小限に留めることができます。 業務の効率化 作業を進めていると様々なことが起こりますが、何かあるたびに手を止めて確認していては、作業も思うように進みません。 大きなプロジェクトになればなるほど対応する人数も増えますが、それぞれが何かあるたびに手を止めていては、結果として膨大な工数を無駄に消費することになります。 作業の手順やフローを明確にしておくことや、プロジェクトの中で使用する定義を明確にしておけば、何か事が起こっても速やかに対応することができるため、作業を効率的に進めることができます。 段取りする上で意識していること 私はクオリティマネージャーとしてテスト工程をマネジメントしており、プロジェクト計画書やテスト計画書を作成しています。 その活動こそが「段取り」に当たりますが、私がプロジェクトの「段取り八分」を目指すために意識している観点がありますのでご紹介します。 ステークホルダーとスコープを整合する プロジェクト計画書やテスト計画書を作成している方は必ず意識していますが、私は特にテストのスコープについてステークホルダーと整合するようにしています。 ソフトウェアテストの７原則に「全数テストは不可能」という原則があります。 その原則通り全てをテストするのではなく、影響範囲やスケジュールなどを考慮してテストのスコープを決めるのですが、「すること」よりも「しないこと」を整合できるように努めています。 何をどのようなテストをするのか決めることは、テストをスムーズに進める上で重要なのは間違いないです。 しかし我々がテストのスコープではないと考えていることを、ステークホルダーがテストのスコープだと考えているケースは少なくありません。 ステークホルダーとの認識齟齬は、追加のテストや作業の手戻りが発生するなど、納期遅れの原因になることがあります。 そのため「テストしないこと」を事前にステークホルダーと整合しておくことが重要だと考えます。 プロジェクトメンバーと手順を共有する プロジェクト計画書やテスト計画書でWBSを作成し、メンバーが何をすべきなのか明確になっていたとしても、その1つ1つを具体的にどう進めれば良いのか決めていなければメンバーの手が止まります。 メンバーの手が止まるだけでなく、プロジェクトマネージャーやプロジェクトリーダーも、その都度メンバーに指示したり、メンバーからの質問に対応しないといけなくなり、思うように進捗が上がらなくなります。 そのためメンバーが作業の手を止めることがないように、WBSで細分化したアクティビティやタスク単位で、作業方針や作業フロー、ルールを定義するようにしています。 その際に注意しているのが、それぞれの目的や意図を合わせて明示しておくことです。 プロジェクトが進むと想定していない様々なことが起こりますが、目的や意図を明確にすることで、メンバー１人１人が応用を利かせた対応がとれるようになります。 プロジェクトマネージャーやプロジェクトリーダーの指示がなくても、メンバーだけで自走してプロジェクトを進めることができるようになっていきます。 腹八分で割り切る プロジェクトは生き物に例えられるように、動き出すと何が起こるかわかりません。 「段取り」が重要なのは間違いありません。 しかし事前に完璧な「段取り」を済ますことは困難ですし、あまりに色々なことを決めすぎても、実際の想定と違う状況になり労力が無駄になることがあります。 そのため「仕事二分」を実現するために「段取り」に拘るものの、その「段取り」も目一杯やるのではなく「腹八分」に抑えるようにしています。 具体的には成果物についてと、目に見える範囲や直前のアクティビティやタスクに対して目一杯段取りを進め、以降のタスクについてはザックリした方針だけ決めておき深追いしません。 それらはプロジェクトが動き出してから段階的に詳細化することで、段取りにかかる労力を分散できるようにしています。 さいごに 昨今はウォーターフォールだけでなくアジャイルの開発プロセスを採用するプロジェクトも多くなっており、状況の変化に対するスピード感が必要になります。 プロジェクトが動き出すと何が起こるかわからないため、想定外の事態が発生したときに、あれもこれも手を出していると、その変化に対応しきれません。 想定外の事態に「仕事二分」の労力の全てを注げることができれば、プロジェクトを成功に導くことができるのではないでしょうか。 私もクオリティマネージャーとして「段取り八分」を徹底し、３割の成功を手にできるようにこれからも邁進したいと思います。 ※1 一般社団法人　日本情報システム・ユーザー協会（JUAS） 企業IT動向調査報告書 2023 https://juas.or.jp/cms/media/2023/04/JUAS_IT2023.pdf The post 段取り八分／仕事二分のマネジメント first appeared on Sqripts .

こんにちは。Sqripts編集部です。 この記事では脆弱性の基本や「脆弱性をなくすことはできないのか」に焦点を当てて解説します。 脆弱性の本質、その存在理由、そしてリスクを最小化するアプローチを解き明かしますので、ぜひセキュリティ対策の参考にしてください。 脆弱性とは？ 用語の定義を理解する 脆弱性とは、システム全体のセキュリティを損なう可能性をもつ「弱点」です。一般的にはソフトウェアのバグ、設計ミスによる欠陥、不適切なセキュリティポリシーや管理体制（による防御の穴）などが含まれます。 総務省の定義によれば、 コンピュータのOSやソフトウェアにおいて、プログラムの不具合や設計上のミスが原因となって発生したサイバーセキュリティ上の欠陥 出典： 総務省『国民のためのサイバーセキュリティサイト』 とされています。 セキュリティ上のリスクを理解する 上記の「弱点」を通じて、攻撃者は不正アクセスを試み、データを盗む、サービスを妨害する、その他の悪意ある攻撃をしかけます。脆弱性に脅威が迫ったときに、システム損害のリスクあるいは、事業継続のリスクなどが生じます。 詳しくは「脆弱性のリスク」の章にて後述します。 なぜ脆弱性が生まれるのかを理解する 攻撃の対象となってしまう脆弱性は、私たちエンジニアが生み出しているという観点を持つことは重要です。脆弱性はシステムを設計する者、システムを利用する者が生み出しており、生み出された脆弱性に脅威が迫ったときに初めてセキュリティリスクが生まれます。 エンジニアから脆弱性が生まれる要因としては、スキル不足、ミスコミュニケーション、要件の急な変更、不十分な品質テストなどさまざまなことが考えられます。人間が関与する限り、完璧なシステムを構築することは現実的には不可能であり、「脆弱性は存在するもの」と認識しておくことが大切です。 利用者から脆弱性が生まれる要因としては、セキュリティアップデートやパッチを適用しないことが挙げられます。アップデートやパッチを適用しない環境下では、既知の脆弱性が存在し続けることになります。 また、パスワードの強度が弱い、パスワードの管理が不適切である（例えば、同じパスワードを複数のアカウントで使用するなど）といった環境も一種の脆弱性と考えられます。 【用語】 脆弱性とセキュリティホールの違いと関係性 脆弱性はシステムの弱点を広く指しますが、セキュリティホールは特定の脆弱性を指します。 セキュリティホールとはつまり、攻撃者がシステムに侵入するための具体的な「窓口」です。 セキュリティホールは脆弱性に内包されており、広義的な弱点を指す「脆弱性」という言葉と、狭義的な弱点を指す「セキュリティホール」という言葉が存在します。 脆弱性のリスク マルウェアへの感染リスク システムの弱点を許容し続けることは、さまざまなリスクを許容するのと同じです。 まず挙げられるのが、マルウェアへの感染リスクです。マルウェアに感染すると、データ漏えいや改ざん・削除といった被害が生じます。 特に近年では、マルウェアの一種であるランサムウェアの被害が世界的に注目されており、データを人質に身代金を要求するといった犯罪行為が後を絶ちません。ランサムウェアによる攻撃も高度化しており、組織化した犯罪集団が「ビジネス」としてランサムウェアを仕掛けてくるケースも目立ちます。 マルウェア感染は、直接的なデータ損失被害だけの話ではありません。顧客の信頼喪失に始まり、金銭賠償、法的責任による事業継続の危機にまで影響を及ぼします。一度評判が損なわれると即座の回復は困難であり、ダメージコントロールには莫大なコストを要します。 ひとたびマルウェアに感染すれば、自分たちが感染源となり、取引先企業への不正アクセスの踏み台になってしまう可能性もあります。あるいは、たとえば某大手動画共有サイトでは、コメント投稿に関するシステムの脆弱性から攻撃を受け、デマコメントが乱立するなど「社会的混乱」を招いた事例もあります。 マルウェアへの感染の要因 マルウェアへの感染の主な要因は、「ソフトウェアのバグ」や「設計ミスによる欠陥」と考えられます。マルウェアやランサムウェアがシステムに感染する際には、システムのバグや設計上の欠陥を突かれる事例が多くなっています。これらの欠陥（脆弱性）を悪用し、不正なアクセスを行ったり、データを盗んだり、システムを遮断したりします。 重要なのは、脆弱性を放置するリスクは派生的に広がっていくことを理解することです。適切にリスク管理と脆弱性対策を実施しないと、放置した分だけ危険度は増していきます。 脆弱性を完全になくすことはできるのか？ 「脆弱性をなくすことはできますか？」 答えはNoです。よく「開発・構築段階で十分なテストをすれば脆弱性はなくなる」と考えてしまうことがありますが、それは誤りです。 技術の進歩、攻撃手法の進化、意図しない操作などとともに新たな脆弱性は常に発見されるため、脆弱性を完全になくすことはできません。 ただし、リスクを管理し、影響を最小限に抑えることはできます。 脆弱性への対策 脆弱性対策の基本：情報収集と適切な管理 ひとことで情報収集といっても、脆弱性の情報は膨大であり、常に新たな脆弱性が発見されるため、すべてを完全に把握することはできません。 IPA（情報処理推進機構）によれば、脆弱性対策情報データベース「JVN iPedia」に登録された累計脆弱性情報は2024年3月時点で206,571件に上り、毎年右肩上がりで件数を伸ばしています。各メーカーや開発元からひとつひとつ脆弱性情報を集めるのは実質的に不可能であり、急速に脆弱性の数が増加する昨今においては、効率的ではありません。 網羅的に情報収集をしつつ、迅速な脆弱性の対策を実現するためには、データベースの活用が有効です。代表的なデータベースとしては以下の3つが挙げられます。 JVN（Japan Vulnerability Notes） 日本国内で使用されているソフトウェアの脆弱性情報を入手するのに適しているデータベースです。 NVD（National Vulnerability Database） 世界全域の脆弱性情報を入手するなら、米国国立標準技術研究所（通称NIST）が運営するNVDを活用するとよいでしょう。（英語表記サイトです） JVN iPedia JVNやNVDなどを一次ソースとして集約するデータベースです。 具体的にどんな情報を得るべきかは、対策に必要な項目から逆算しましょう。脆弱性対策には、具体的な対策手法だけでなく、対策の必要性の有無、対策の優先度を把握しなければなりません。対策の必要性の有無を把握するには、脆弱性が検出されたソフトウェアやバージョン情報を確認します。対策の優先度を判断するには、脆弱性の影響範囲を抑える必要があります。 上記を把握したうえで、定期的なセキュリティチェック、脆弱性スキャニング、ソフトウェアの更新、従業員教育といった具体的な対策に移ります。 脆弱性診断：定期的なセキュリティチェックの重要性 技術の進歩とともに、残念ながらサイバー攻撃も進化しています。一度脆弱性対策を実施したからといって、安全だとはいえなくなってしまったのが現状です。定期的なセキュリティチェックを施すことで、新たな脆弱性にも迅速に対応し、被害を最小限に抑えることができます。 セキュリティチェックには、大きく2つの種類があります。ひとつはプラットフォーム診断、もうひとつはアプリケーション診断です。プラットフォーム診断はネットワーク内のサーバやネットワーク機器、また昨今ではIoT機器なども含む環境の脆弱性有無を調査します。アプリケーション診断では、WebアプリケーションおよびWebサイト、スマホアプリなどを対象に脆弱性を診断します。 どちらの診断も、インターネット経由のリモート診断と内部ネットワークからのオンサイト診断の2つに細分化されます。 2つの脆弱性診断において、自社に必要なリソースがあればその範囲で診断活動を実施するのが最適でしょう。しかし、脆弱性に適切に対応するためには、豊富な知見や経験による「判断力」が必要です。今自分たちが対策していることが、自社にとって正解か否かを判断できなければ、それが企業にとって致命傷となってしまう可能性もあるからです。 自社に十分なリソースがない場合は、脆弱性診断ツールや専門のセキュリティチームを活用することも検討しましょう。 まとめ 脆弱性は常に新たなものが発見されるため、完全になくすことはできません。しかし、放置すればその分セキュリティリスクは高まり、事業継続の危機はもちろん、社会的混乱やパートナー企業へも影響を及ぼす可能性があります。 脆弱性の本質を理解しながら適切な情報収集と対策を施していくことが大切です。そうすれば、万が一脆弱性からの脅威が迫ってきても、被害を最小限に食い止めることができます。 Sqriptsを通じて、読者の皆さんが「自社はどのように脆弱性と向き合っていくべきか」の最適解を見つけられることを願っています。 【参考】 総務省： 国民のためのサイバーセキュリティサイト IPA： 脆弱性対策情報データベースJVN iPediaの登録状況 AGESTのセキュリティ関連ソリューション ● サイバーセキュリティ診断 脆弱性診断サービス ● ULTRA RED セキュリティフレームワークCTEMに則ったSaaS型ソリューション ● クラウドソースセキュリティテストプラットフォーム（Synack） 世界最高峰のエシカルハッカーチームと独自のAIスキャナーを活用したセキュリティテストプラットフォーム など、さまざまなソリューションを展開しています。「必要かどうかがそもそもわからない」段階でもご相談を受けていますので、お気軽にご活用ください。 The post 脆弱性とは？脆弱性をなくすことはできないのか first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 今回のテーマは「ファシリテーション」です。いよいよ具体的な方法の解説に入っていきます。 前回のおさらい 前回は「スクラムマスターが絶対に言わないこと」から、コミュニケーションのポイントをざっくり解説しました。今回からは、より具体的な方法を解説していきます。まずは、場を整えてゴールへと導くために利用できる「ファシリテーション」を解説していきます。 優れたスクラムマスターが絶対に言わないこと ファシリテーションとはなにか？ ファシリテーションとは、チームの能力を高める技術です。最近だと予想できない世界情勢の中で、多様な人達が集まり活動するのが当たり前になってきました。こういったさまざまな「違い」や「変化」がある中で、適切に対立し、オープンかつ建設的に話し合い、物事を進めるためのファシリテーションスキルの重要性は高まっています。 ファシリテーションを行う人をファシリテーターと呼びます。ファシリテーターを理解するために、その特徴を以下にまとめてみましょう。 ファシリテーターは、中立である ファシリテーターは、チームをゴールに導く支援を行う ファシリテーターは、成果を高めるためによりよいコミュニケーションの場を作る これらを眺めてみると、スクラムチームで行うスクラムイベント（計画づくりやふりかえりなどのMTG）で求められる司会進行に通ずるものがあります。スクラムはコミュニケーション主体のフレームワークなので、ここで紹介するファシリテーションといったコミュニケーションスキルとの親和性が高いはずです。 ファシリテーションが機能していない現場例 ファシリテーションを活かした場を考える前に、「活かされていない場」について考えてみましょう。成功する方法を見つけるのは難しいですが、失敗する事例からは多くのことを学べます。 ファシリテーションが機能していない現場を以下のようにまとめてみます。 誰か特定の人が一方的に場をコントロールしようとしている 私は正しく、意見の違う相手は間違っている。よって、MTGでの会話が勝ち負けになりがち 他の人の意見より自分の意見に関心がある。関心を持ってほしい 面子（メンツ）が重要 誤解、対立、防御反応、不信感を感じる こうやって書くと「ひどい現場」に思うかもしれませんが、いろんな現場を見てきた私からすると「よくあるケース」です。ここまでひどいところはなかなかないかもしれませんが、いくつか当てはまる現場はたくさんあります。 たとえば、声の大きい人が上司やリーダー、先輩としているケースを考えてみましょう。こういった方は、すべてを自分でコントロールしようとするコミュニケーション方法を自然に使うことが多いです。その結果、意見を聞くと言いながら、最後は自分の話をしてしまったり、みんなで解決案を議論したいのに、自身の経験やアイデアをとうとうと語り「これやればいいんじゃない？」と考えを押し付けてしまったり。あながち「ない」とは言えない状況だと思います。 ほとんどの提案は相手に響かないという現実 前述の上司や先輩のように、相手からの提案やアドバイスは日常多く発生します。しかし、ほとんどの提案は相手に響かず、アクションに繋がることはありません。 たとえば、アジャイル開発で行われる朝礼やふりかえり（レトロスペクティブ）において、こんなやりとりがあったとしましょう。 「この前のふりかえりでアクションに選んだタスクですが、目の前の仕事が多くて手がつけられなくて困っています」 「みんな忙しいからなかなか難しいよね。ひとまず目の前の仕事を優先したら？」 「僕の場合、カレンダーにやることを全部登録して、その日にできることはその日にやっているよ。君も試してみたら？」 「そもそもやることが多すぎだから、本当にやるべきか考えたほうがいいんじゃない？」 みなさん、メンバーが困っていることの対策を一生懸命考えてくれているようです。もし、あなただったら、これらの提案を全部やってみたいと思うでしょうか？ この状況は、居酒屋でくだを巻くおじさんと似たような構図です。居酒屋でくだを巻くおじさんは、自分の過去の体験を語りながら「もっとこうすれば（私のように）うまくいく」と親切に教えてくれます。とても親切で優しい人なのでしょうが、「相手のためを思って」というより「自分が話したいから」話しているように見えます。  とびっきりのアイデアであれば、飛びついてくる人はいるかも知れません。また、相手との信頼性が高ければ高いほど、やってみようと思うかもしれません。しかし、そこまでの状況でなければ、「うーん。たしかにそうだけど」で思考が止まってしまいます。 他人の言葉や経験は、自分ごとになりにくいからです。 また、何かをやれていない人に対しての「これやれば？」は、相手の否定につながる言葉として受け止められかねません。 ファシリテーションが機能している現場例 それではいよいよファシリテーションが機能する現場を見てみましょう。そこには以下のような特徴があります。 確かな情報を集め、自由に選択を行っている 参加者は決定に貢献したいと内面から思っている 違いがあることを受け入れ、そこから学ぼうとする 相互理解を深め信頼を強める（心理的安全性が高くなる） 学びが多く、刺激的である チームの能力や仕事の質が高まっていると感じる ファシリテーションとは、チームの能力を高める技術です。チームが個人に与える影響や、個人がチームに与える影響が相互に効果を高め合い、チーム能力を向上させるチームダイナミクスを生み出します。 ファシリテーションは、このような場を作るためのスキルです。 提案が自分ごとになるために ファシリテーションが有効活用されている現場であれば、提案やアドバイスは学びとして受け入れられます。やるやらの選択もチームとして最適な選択肢を選ぼうとするはずです。 たとえば、決定事項に合意ができなくても、オープンな議論の上で決まったのであれば、チーム全員でアクションに貢献しようとします。たとえアクションに失敗したとしても、誰かを責めるのではなく、それを学びの機会として受け止め、次に力強く進んでいきます。 自分たちで考え、自分たちで選んだことなので、選択肢が自分ごとになります。 このように、ファシリテーターは、最高のコミュニケーションができる場を作り、建設的なディスカッションを支援し、アクションが自分ごとになるようにファシリテーションしていきます。 ＊ 今回は、ファシリテーションが機能する現場をイメージしてみました。提案が自分ごとになりにくい理由や、あるべき姿の解説も行いました。 次回は、こういった「理想の場」になるために役立つテクニックを解説します。このテクニックは全部で9つあり、それぞれにロジカルな理由や背景があります。 想定や推察を確認する 曖昧な言葉を確認する タブーを話し合う すべての情報を共有する 理由と意図を説明する 自分の「関心」を伝える 提案と質問を組み合わせる 次のステップを一緒に作る アクションを自分ごとにする この9つのテクニックを具体的に事例を交えながら学び、ファシリテーションスキルをどんどん高めていきましょう。 The post あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術 -1- first appeared on Sqripts .

こんにちは。ノウンです。 以前の記事で、「Webサイトのテスト」をスマートフォン（以下スマホ）を使って行う方法を紹介しました。その際は、PCとスマホをケーブルで接続して、PCのブラウザの標準機能であるデベロッパーツール（開発者ツール）を使う方法でしたが、今回はWi-Fi（無線）でPCとスマホを接続して同じテストを実施する方法をメリット・デメリットを交えて紹介します。 Webサイトテスト時の便利技・PCブラウザのデベロッパーツールをスマホで使おう Wi-FiでPCとスマホを接続してデベロッパーツールを使用するには条件があります。条件を満たしていない場合、Wi-FiでPCとスマホを接続をすることは出来ませんが、ケーブルで接続することは可能なので以前の記事を参照していただければと思います。 条件 ①PCとスマホを、同じWi-Fi（無線ネットワーク）に接続する ②「Android」は、「Android Studio」が必要かつ「OSver.11」以上である ※OSver.11で対応された、端末の「開発者向けオプション：ワイヤレスデバッグ」が使えることが前提となるため 「iPhone」は、初回の設定時のみスマホとPCをケーブルで接続する必要がある。OSver.は問わない 次に、「Android & WindowsPC」と「iPhone & MacPC」を使用した具体的な手順や設定について紹介していきます。スマホとPCの組み合わせは、この組み合わせでないと設定できませんのでご注意ください。 Android & WindowsPC（Chromeを使用） 以下の端末を使用した場合で説明します。 Android端末（OSver.11以上）＆Windows10 Pro 1. PCにAndroid Studioをインストールする 以下のURLにアクセスして、Android Studioをダウンロード→インストールします。 Android Developers インストールは、表示される画面に沿って進行すれば大丈夫です。迷う要素は特に無いと思いますが、公式のヘルプがありますので必要に応じてご参照ください。 Android Studio をインストールする 2. Android SDKの設定を行う スマホでPCのデベロッパーツールを使用する場合に必要となるドライバが適用される様にします。 3. 「Tools」メニュー＞「SDK Manager」を選択 4. 「SDK Platforms」タブで、使用するAndroidのOSにチェックを入れる 5. 「SDK Tools」タブで、「Android SDK Platform-Tools」が「Installed」になっていることを確認（「Not Installed」になっていたらチェックを入れる） 6. 「OK」または「Apply」を押下してインストールを実行する これで、スマホでPCのデベロッパーツールを使用する場合に必要となるドライバが適用されます。 7. ADBコマンドを有効にする ADBとは、Android Debugging Bridge のことで、コマンドを有効にするとAndroid Studioを使ってPCでスマホの開発をしたり、コマンドプロンプトからスマホを操作したりと、スマホのみでは行えない操作をPCから行うことが可能となります。 今回はスマホでデベロッパーツールを使用する際、スマホのワイヤレスデバッグが正常に動作するように設定を行います。 設定する際、あらかじめ手順「5」の画像上部「Android SDK Location：」に表示されているフォルダパスを控えておくとスムーズに設定できます。 8. WindowsPCのタスクバーにある「スタート」ボタンを右クリック＞「システム」を選択 9. 「システムの詳細設定」を選択 10. 「詳細設定」タブ＞「環境変数」を選択 11. システム環境変数 の「Path」を選択＞「編集」ボタンを選択 12. 「新規」ボタンを選択＞Android Studioをインストールした時に一緒にインストールされた、フォルダ「platform-tools」のフォルダパスを入力 13. 開いている各ウィンドウを「OK」ボタンを押下して閉じる 【注意】手順13.で「キャンセル」ボタンを押下すると、ここまでの設定が反映されないため、必ず「OK」ボタンを押下して各ウィンドウを閉じてください。 14. PCを再起動する PCを再起動します。 15. ADBコマンドが有効になっているか確認する ここまでの設定が反映されているか、確認を行います。 WindowsPCの「コマンドプロンプト」を起動します。 （「スタート」アイコンをクリック＞「 cmd 」で検索＞コマンドプロンプトを選択。または、タスクバーの検索アイコン・検索ボックスから「 cmd 」で検索＞コマンドプロンプトを選択） 16. 「 adb 」と入力してEnterキーを押下する 画像のようにコマンドの引数（内部デバック[internal debugging：]）、USBの接続[usb：]などの情報）が一覧になって出てくれば、ADBコマンドが有効になっている。 ※ADBコマンドが有効になっていない場合、下記エラーメッセージが表示されます。ここまでの設定や入力した文字列に誤りが無いか確認してみてください。 17. Androidの「開発者向けオプション」を表示する Androidの「設定」＞「デバイス情報」＞「ビルド番号」の部分を連続で7回タップします。 ※Androidによって「ビルド番号」の表示箇所が異なる場合があります。 18. 「開発者向けオプション」を有効にする 「設定」＞「システム」＞「開発者向けオプション」を選択して「開発者向けオプションの使用」のトグルボタンを有効にします。 19. 「ワイヤレスデバッグ」を有効にする 「ワイヤレスデバッグ」のトグルボタンを有効にして表示されたウィンドウで「許可」を選択します。 ※「このネットワークで常に許可する」にチェックを入れてから「許可」を選択すると、2回目以降の接続時にこの手順が不要となります。 20. AndroidとWindowsPCを同じWi-Fiに接続する AndroidとWindowsPCを同じWi-Fiに接続します。 21. AndroidとWindowsPCのペア設定を行う WindowsPCのAndroid Studioを起動＞デバイス表示部分のプルダウン＞「Pair Devices Useing Wi-Fi」を選択して「QRコード」を表示します。 22. AndroidでQRコードを読み込む Androidで「設定」＞「システム」＞「開発者向けオプション」＞「ワイヤレスデバッグ」＞「QRコードによるデバイスのペア設定」＞「QRコードのスキャン」から、WindowsPCのQRコードを読み込みます。 読み込みに成功すれば、ペア設定は完了です。 23. AndroidのChromeでテスト対象ページを開く AndroidのChromeでテストの対象ページを開きます。 24. WindowsPCのChromeを開き、アドレスバーに「 chrome://inspect/devices 」と入力してアクセスする 25. 接続しているAndroidの端末名とブラウザ、テスト対象ページのURLがWindowsPCのChromeに表示されるので、URLの下にある「 inspect 」を選択する 26. デベロッパーツールが開く WindowsPCのChromeの左側にAndroidの画面、右側にデベロッパーツールが表示されます。 27. デベロッパーツール内の通信情報を確認 スマホでアクセスしたwebサイトを操作して、デベロッパーツールでwebサイトの通信情報を確認する。画像は「Network」タブに情報が表示されている状態。 以上で、AndroidとWindowsPCの設定は完了です。 iPhone & MacPC（Safariを使用） 以下の端末を使用した場合で説明します。 iPhone端末＆iMac 1. iPhoneでWebインスペクタを有効にする MacPCでiPhoneのデベロッパーツール（Webインスペクタ）を表示させるには、iPhoneの設定を行う必要があります。 iPhoneの「設定」＞「Safari」＞「詳細」＞「Webインスペクタ」のトグルボタンを有効にします。 2. MacPCのSafariで開発メニューを表示する MacPCのSafariは、デフォルトの設定ではiPhoneのWebインスペクタを開くためのメニューが表示されていないため、設定を行う必要があります。 Safariを起動＞「Safari」メニュー＞「環境設定」＞「詳細」の「メニューバーに開発メニューを表示」にチェックを入れます。 3. iPhoneとMacPCをライトニングケーブルで接続する iPhoneとMacPCをライトニングケーブルで接続します。 4. iPhoneとMacPCを同期する MacPCの「Finder」から接続したiPhoneを選択＞「一般」＞「このiPhoneが接続されているときに自動的に同期」のチェックを外す＞「同期」ボタンを選択します。 同期が完了したら、ケーブルを抜いてください。 5. iPhoneとMacPCを同じWi-Fiに接続する 6. MacPCのSafariで「開発」メニュー＞同期したiPhoneを選択＞「ネットワーク経由で接続」にチェックを入れる 7. iPhoneのSafariでテスト対象ページを開く iPhoneのSafariでテスト対象ページを開きます。 8. MacPCのSafariで「開発」メニュー＞同期したiPhoneを選択＞iPhoneで開いたテスト対象ページのURLを選択する MacPCのSafariで「開発」メニュー＞同期したiPhoneを選択＞iPhoneで開いたテスト対象ページのURLを選択します。 9. Webインスペクタが開く Webインスペクタが開きます。 10. Webインスペクタ内の通信情報を確認 iPhoneでアクセスしたWebサイトを操作して、WebインスペクタでWebサイトの通信情報を確認する。画像は「ネットワーク」タブに情報が表示されている状態。 以上で、iPhoneとMacPCの設定は完了です。 設定時の失敗例 設定が上手くいかない例として以下があります。 スマホとPCが異なるWi-Fiに接続されている 接続するWi-Fiは同じである必要があります。普段使用するWi-Fiが1つの場合は特に問題ありませんが、複数のWi-Fiを使い分けている場合は注意してください。 今回紹介した手順は、各手順毎に設定が行えていることを確認しながら進めれば上記以外の要因で失敗することは無い手順となっています。 注意点 PCとスマホを接続した状態のままにしておくと、スマホとPCが勝手に接続されてしまい第三者に見られたくない情報を盗み見される可能性があります。（例：PCを複数人で使いまわして作業をしている場合） 作業をしない時は、PCとスマホの接続を解除しておくことをお勧めします。 接続を解除する方法としては、「PCとスマホを同じWi-Fiに接続しない様にする」が簡単です。 先の手順で記載した様に、「PCとスマホが同じWi-Fiに接続されている」状態だとペアリングが行われるためです。 また、Androidであれば「開発者オプションを無効にする」、iPhoneであれば「Webインスペクタを無効にする」ことでも接続が解除されます。 なお、以前紹介したケーブルでPCとスマホを接続する手順では、ケーブルを抜けば接続が解除されるためその様なことは発生しません。 おわりに 今回はPCのブラウザ機能であるデベロッパーツールを、Wi-FiでPCとスマートフォンを接続して使用する方法を紹介させていただきました。 ケーブルで接続していないため、ケーブル長に左右されずに作業が行えること、スマホやPCの接続端子を自由に使用できる利点があります。 今回の方法を実際に試してみると、スマホとPCがケーブルで接続されていない状態だと想像以上に端末の取り回しがし易く、快適に作業を行うことができました。スマホ＋デベロッパーツールでテストを行う場合にぜひ使用してみてください。 The post Webサイトテスト時の便利技・PCブラウザのデベロッパーツールをスマホで使おう(第二弾) first appeared on Sqripts .

こんにちは。インフラエンジニアのTYです。普段はAWS,GCPなどのクラウドを扱ったサービスの検証・開発を行っています。 実は以前「 Asterisk入門~SIPフォンで通話してみる~ 」というブログを書かせていただきました。今回はAsteriskの別の機能についてお話ししたいと思います。 Asterisk入門　～SIPフォンで通話してみる～ 1. 概要 AsteriskはオープンソースのPBXです。PBXとは”Private Branch Exchange”の略で日本では”電話交換機”と訳すのが一般的です。1つの親番号に着信した通話をコールセンターやオフィス内線の様に適切な端末に振り分けます。 そんなPBXであるAsteriskですが、PSTNやSIPでの通話もちろんWebRTCでの通話も可能です。 Asteriskの情報は思っているよりも少なく、自分で構築した際にはWebRTCで通話できるようにするだけでも少し苦労しました。本記事では、私自身の備忘録もかねてAsteriskでWebRTC通話ができるようにしてみたいと思います。 2. 構築 AWS EC2インスタンスにUbuntuをセットアップし、そこにAsterisk,WebRTC通話で利用するブラウザアプリをインストールして構築していきます。 2.1 EC2 EC2インスタンスにUbuntuをセットアップし起動します。インスタンスタイプは小さいもので問題ないです。 2.1.1 セキュリティグループ セキュリティグループは以下のようにします。 セキュリティグループ ※アクセスするIPが制限できる場合は制限しましょう。 2.2 Asterisk導入 2.2.1 Asteriskインストール EC2にsshでログインし、Asteriskを導入します。 まずはシステムが更新されているか確認してください。 shell-session $ sudo apt-get update Asteriskをインストールします。 shell-session $ cd ~ $ wget <http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-18-current.tar.gz> $ tar -xvf asterisk-18[tab] $ cd asterisk-18.[tab] $ sudo su # contrib/scripts/install_prereq install # ./configure --with-pjproject-bundled # make menuselect # make && make install && make config # exit $ cd ~ 次にAsteriskの設定ファイルをインストールします。 shell-session $ git clone <https://github.com/InnovateAsterisk/S2E2.git> $ sudo cp ~/S2E2/config/* /etc/asterisk 2.2.2 Asterisk設定( http.conf ) AsteriskでWebRTC通話を行うにはAsteriskのhttpサーバー機能を有効化します。 /etc/asterisk/http.conf を以下の様に変更します。 shell-session $ sudo vim /etc/asterisk/http.conf [general] enabled=yes ; HTTP bindaddr=127.0.0.1 bindport=8080 tlsenable=no ; HTTPS enablestatic=no Asteriskを再起動します。 shell-session $ sudo service asterisk restart 2.3 apacheインストールと構成 WebRTC通話で利用するブラウザアプリを用意します。今回はブラウザアプリもAsteriskと同じサーバーに配置します。 まずはapacheをインストールし設定します。 shell-session $ cd ~ $ sudo su - # apt-get install apache2 # a2enmod ssl # a2enmod proxy # a2enmod proxy_http # a2enmod proxy_wstunnel 必要なポートを開放します。 shell-session # vim /etc/apache2/ports.conf Listen 0.0.0.0:80 Listen 0.0.0.0:443 Listen 0.0.0.0:4443 Webアプリで利用する設定を行います。この時にDNSサーバーにAsteriskサーバーのIPアドレス指すエントリファイルを作成する必要があります。DNSサーバーは何でもいいですが、AWSだとroute53を利用できます。 shell-session # vim /etc/apache2/sites-enabled/000-default.conf <VirtualHost 0.0.0.0:80> ServerName <Asteriskサーバーのドメイン> DocumentRoot /var/www/html </VirtualHost> apacheを再起動します。 shell-session # service apache2 restart snapとcertbotをインストールし、証明書を発行します。 shell-session # snap install --classic certbot # ln -s /snap/bin/certbot /usr/bin/certbot # certbot --apache certbotが完了すると、新しい設定ファイルが作成されるので、それを開いて ws/ ホストを追加します。 shell-session # vim /etc/apache2/sites-enabled/000-default-le-ssl.conf <VirtualHost 0.0.0.0:4443> ServerName __copy_from_above__ DocumentRoot /var/www/html SSLCertificateFile __copy_from_above__ SSLCertificateKeyFile __copy_from_above__ Include /etc/letsencrypt/options-ssl-apache.conf ProxyRequests off ProxyPreserveHost On ProxyPass /ws ws://127.0.0.1:8080/ws ProxyPassReverse /ws ws://127.0.0.1:8080/ws </VirtualHost> apacheの設定はこれでOKなのでapacheを再起動し、設定を反映します。 shell-session # service apache2 restart # exit $ cd ~ 2.4 ブラウザアプリインストール WebRTC通話で利用するブラウザアプリをインストールし、ドキュメントルートに配置します。 shell-session $ git clone <https://github.com/InnovateAsterisk/Browser-Phone.git> $ sudo cp -r Browser-Phone/Phone/* /var/www/html/ 2.5 Asteriskユーザー設定( pjsip.conf/extensions.conf ) ここまでで利用するWebRTCアプリの設定が完了しました。最後にAsteriskサーバーの設定を行います。 まずは pjsip.conf でWebRTCで利用するユーザーを作成します。 /etc/asterisk/pjsip.conf を編集します。githubから設定ファイルをインストールしているためそこに以下を追記します。 このconfファイルでAsteriskで使用するユーザーを定義します。 ※パスワードはお好きな文字列に変更してください。 shell-session $ sudo vim /etc/asterisk/pjsip.conf ; == Users [User1](basic_endpoint,webrtc_endpoint) type=endpoint callerid="One Hundred" <100> auth=User1 aors=User1 [User1](single_aor) type=aor mailboxes=User1@default [User1](userpass_auth) type=auth username=User1 password=1234 [User2](basic_endpoint,webrtc_endpoint) type=endpoint callerid="Two Hundred" <200> auth=User2 aors=User2 [User2](single_aor) type=aor [User2](userpass_auth) type=auth username=User2 password=1234 [User3](basic_endpoint,webrtc_endpoint) type=endpoint callerid="Three Hundred" <300> auth=User3 aors=User3 [User3](single_aor) type=aor [User3](userpass_auth) type=auth username=User3 password=1234 次に /etc/asterisk/extensions.conf を編集します。こちらもgithubからインストールしているため以下を追記してください。 このconfファイルでダイヤル番号とユーザー紐づけます。 shell-session $ sudo vim /etc/asterisk/extensions.conf [subscriptions] exten => 100,hint,PJSIP/User1 exten => 200,hint,PJSIP/User2 exten => 300,hint,PJSIP/User3 [from-extensions] exten => 100,1,Dial(PJSIP/User1,30) exten => 200,1,Dial(PJSIP/User2,30) exten => 300,1,Dial(PJSIP/User3,30) exten => _[*0-9].,1,NoOp(Music On Hold) exten => _[*0-9].,n,Ringing() exten => _[*0-9].,n,Wait(2) exten => _[*0-9].,n,Answer() exten => _[*0-9].,n,Wait(1) exten => _[*0-9].,n,MusicOnHold() exten => e,1,Hangup() ここまでで設定出来たらAsteriskを再起動します。 shell-session $ sudo service asterisk restart ここまででAsteriskサーバーおよびWebRTCアプリの構築は完了です。実際に動作を確認してみましょう。 3.動作確認 動作確認のためWebRTCアプリに接続します。Chromeで以下のURLにアクセスします。 shell-session https://<Asteriskサーバーのドメイン> アクセスすると以下のようなサイトが表示されます。 WebRTCアプリ アカウントをクリックし、Asteriskサーバーに登録します。赤枠内にはAsteriskサーバーのドメインを入力します。パスワードには pjsip.conf で設定した値を入力します。 Asterisk登録 Asterisk登録2 そのほかはデフォルトのままで保存します。 シークレットウィンドウや別ブラウザなどでもう一つWebRTCアプリを表示し、そちらは別のアカウントで登録します。本記事の内容だとUser2 or User3があるはずです。 アカウントが2つ登録出来たらどちらかのアカウントから発信してみましょう。右上の電話マークをクリックし発信先にダイヤルします。ダイヤル番号はUser1なら100、User2なら200といったようになっています。このダイヤル先の設定は extensions.conf で行っています。 WebRTCダイヤル うまく設定できていればブラウザ同士で通話ができるはずです！ 4.さいごに 今回はオープンソースのPBXであるAsteriskをWebRTCの通話ができるように構築しました。音声のみの通話だけでなくビデオ通話も可能になっています。また、AsteriskはPBXであるため、通話の転送や着信をキューに入れて待機させておくことも可能です。 本記事でインストールしたWebRTCアプリには”SIPJS”というライブラリが使用されています。これはjavascriptでAsteriskを利用できるようにするためのライブラリでこのライブラリを利用すれば自作のWebRTアプリでAsteriskを利用することも可能です。私はまだそこまでチャレンジできていませんがそのあたりにもチャレンジしていきたいと思います。 ありがとうございました。 The post Asterisk入門～WebRTC通話編～ first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第8回となる今回のテーマは「コストマネジメント」です。 限られた財源を意識してプロジェクト内で追加コストが発生しないように管理し、プロジェクトの目的・目標を達成することはとても重要です。 しっかりとしたコスト計画方法を知り、コストをマネジメントを適用することで、プロジェクトにとってコストは「管理するだけではない、変化に対応する武器」になるはずです。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ コストマネジメントとは コストマネジメントとは、プロジェクト予算内で遂行するための必要コストの見積もりや予算策定、それらをコントロールする活動を指します。 プロジェクトを行うには、当然ですが人件費や開発費用といったコストが発生します。プロジェクトにおける「鉄の三角形」である QCD ※1 に「C：COST」があるように、コストをしっかりと管理していないと、プロジェクトを終えられたとしても赤字になるなどして、プロジェクトが失敗したという評価になる可能性があります。また、予算超過が原因でプロジェクトが停止してしまうこともあります。まれに小さなプロジェクトでは詳細なコスト管理まで求められないこともありますが、プロジェクト予算が設定されている場合にはしっかりとコスト計画とマネジメントを行っていきましょう。 コストマネジメントは以下4つのステップ（プロセス）で行います。 ※1 QCD 「QCD」とは、Quality（品質）、Cost（費用）、Delivery（納期）の頭文字を重要度の高いものから順に並べたものです。 コストマネジメントのはじめかた 1) WBSやGANTTチャートから「コスト管理表」を作成し見積もってみる アクティビティタスクのコスト合計＝要素成果物のコスト 要素成果物のコストの合計＝成果物のコスト 成果物のコストの合計＝プロジェクト全体のコスト 各活動のコストを見積もる際は、タスク実施に必要な期間やそのタスクで利用する人件費や原材料費など必要な経費も追加します。また成果物の作成や伴う活動を外注する場合には、別途見積書を入手してコストに付加していきます。 2) コスト計画や管理表記載時の注意点 コスト計画や管理表に記載する際は、管理する資源ごとの単位を規定しましょう（例：時間を測定する場合は、労働時間や日数、通貨など）。記載の精密さのレベルや正確さのレベル設定も併せて必要です（例：見積りの正確さの許容範囲を±10％とする、といったレベルを設定するなど）。 また計画したコストの値からどれぐらい変動があったら手当をしなければならない、といった「閾値」を設けておかないと、Aさんは「これくらいのコスト変動（予実差）は許容できるだろう」と思っていても、Bさんは「すぐに処置が必要だ」と感じるかもしれません。そのような感覚に左右されないコスト監視やコントロールができるよう事前に計画、準備記載しておきましょう。 コストの見積もり 1) 見積もり精度のブレは結構大きい（最初から正確を求めない） プロジェクトの見積もり精度はプロジェクト活動が進むにつれて向上します、つまりプロジェクト初期（立ち上げフェーズ）はどうしてもその精度は十分ではありません。 ※PMBOKによる指標 また「超概算」と呼ばれる見積もりは-50～＋100%、予算化するタイミングでの概算は-10%～＋25%とされています。 2) 見積もり方法 コストの見積もりは、人件費（単価）、材料費、インフレーション、リスク要因など数多くの変数の影響を受けます。専門家や社内外にある経験や知識を集積して見積もるようにしましょう。 過去の類似プロジェクトの見積もり 業界、領域、専門分野の情報　 成果物の内製化や外製化の検討 （代替案分析） など 3) マネジメント予備、コンティンジェンシー予備 マネジメント予備（予備費）、コンティンジェンシー予備（予備費）という言葉を聞いたことがあるでしょうか？どちらもプロジェクトのコストとして予備的に計画/準備されるコストです。 コンティンジェンシー予備とは、主にリスク発生を鑑みて適応されるコストです。 例えば「成果物のどこかに手直しの発生が想定されるがどこであるか（手直しが発生するかも）わからない、もし発生した場合にかかるコストを予め用意しておこう」というものがこのコンティンジェンシー予備の使い先になります。一般的にはPMの裁量で使用することができます。 マネジメント予備は上記に対して「予期せぬ作業や事象に備えて用意」しておくコストです。例えば「プロジェクトの途中でクライアントから突発の追加要求が上がってきた」という「いざ」という事態に使うかもしれません。使用にあたってはプロジェクトスポンサー（PO）の承認が必要です。組織やプロジェクトによって「（見積予算 + コンティンジェンシー予備）× ○%」と一律規定、準備する場合もあります。 4) 品質コストを盛り込もう 品質コスト（COQ：Cost Of Quality）の前提条件を盛り込む必要があります。品質コストとはその通り品質を確保するためのコストであり、予防コスト、評価コスト、不良コストなどが含まれます。 コストをマネジメントするために コストコントロールの大部分は、コストの消費と当該支出の作業結果の関係を把握し分析することです。その時に単に「支出だけ」を追跡するのではコストコントロールの意味はぼやけます。必要なのは、達成した作業の本当の「価値」であり、それらを数値的に捉え「コントロール」することです。 「遅れています」「進んでいます」「月末までには完了すると思います」 こういった主観的な報告（説明）に対して、マネジメント者として客観的に「ほんとうに？」という疑問や、「そうだよね」という納得を返せる助けになるのが、複数の指標をコストに換算して管理できるアーンド・バリュー・マネジメント(EVM：Earned Value Management)という手法です。 まずはEVMを解し、プロジェクトの進捗状況や将来の問題をコストコントロールをしながら察知できるようにしましょう。 1) EVMで実績と進捗を定量的に可視化 EVMを使用する最大のメリットは コスト目線でのプロジェクト状態を「客観的に」測定することができる 精度の高い将来予測（見積もり）ができるようになる ことにあります。実際に、1960年代の米国でその膨大な国家赤字を見直すために、国防省でプロジェクトのパフォーマンス測定方法が見直されたことにEVMの起源があります。その後は米国産業界のガイドラインとして、政府調達のプロジェクトの前提条件となっています。 2) EVMで使う指標 EVMとは現在の進捗状況や将来の問題を察知するプロジェクト管理の手法のひとつです。難しくはありません、4つの指標を覚えましょう。 これらのPV、AC、EVの指標を使い、コストを縦軸、経過期間を横軸とするグラフを作成します。このグラフを基にこれまでのプロジェクトに費やされた作業量から推定し、プロジェクト完了にはどうなるか、という見積もりができるというわけです。EVMやそれら使った実績推移グラフからスケジュールの遅延やコストの超過が読み取れるなど、計画と実績の乖離が起きていたら即座に手を打つなど、問題が改善できるうちに対処するなどの予防を行いましょう。 3) EVMを使わないプロジェクト規模 EVMの他にも複数のコスト分析方法がありますが、まずはEVMをコストマネジメントに取り入れられれば十分です。むしろ、誤解を恐れずに言えば多くのプロジェクトで十分にEVMが使われていません。小規模プロジェクトではコスト管理のためのコストをかけることで、プロジェクト自体がショートすることになりかねないからです。筆者の感覚では最低5000万円以下のプロジェクト規模であれば、EVM以外のコスト管理をおすすめします。 コストが溢れそうだ！その時は。 プロジェクトは段取り（準備）が肝であり、コストもいかに計画、計算、想定しておけるか（計画の上で実行できるか）が、その後のプロジェクト成功の鍵です。残念ながら、どれだけ計画しても「まったく計画通り」に進むことは少ないですが、少なくともそれらの「事態」に予備費を準備したりするなど備えをしてきましたね？ みなさんがコストに対して、最も注力して対処するタイミングは「計画時」です。 コスト計画時に プロジェクトオーナーから指示された予算よりオーバーしてしまいそうだ 明らかにプロジェクト憲章に記載した予算と乖離があるぞ とわかったらしめたものです。計画時には2つの方法で予算とコストをポジティブに調整していきましょう！ 1) 基本的なコスト修正対応（1） 成果物の機能を簡易的な内容に調整したり、予定していた活動やタスクを見直す＝（今回は）やめる/スコープから切り離すなどしてコスト調整する「ECRS（イクルス）」を試しましょう。 ECRS（イクルス）とはEliminate（排除：取り除く）、Combine（結合：つなげる）、Rearrange（交換：組み替える）、Simplify（簡素化：単純にする）の頭文字で、元々は製造現場における的確な課題抽出と効果的な業務改善の手法として考えられたものですが、現在ではさまざまな業務改善に用いられています。 排除（Eliminate）：その業務をなくすことができないか？ 結合（Combine）：その業務を他の業務などと一緒にまとめられないか？ 交換（Rearrange）：その業務の順序や場所などを入れ替えることで、効率化できないか？ 簡素化（Simplify）：その業務のやりかたをより簡単にできないか？ 一般的にE→C→R→Sの順に改善効果が大きいと言われています。 2) 基本的なコスト修正対応（2） 予算自体を変更する（してもらう）交渉を恐れずに行いましょう。プロジェクトオーナーやクライアントなど、決裁者との会議や検討を設定し、予算自体適切に変更するための承認活動を行います。つまりプロジェクト憲章自体の予算を変更する、ということになります。いわずもがなですが、安易に予算変更（予算オーバー）承認を得るという考え方ではありませんので注意してくださいね。 多くの場合は、修正対応 （1）と（2）を組み合わせた検討と交渉/承認がスタンダードです。無理な計画、無理のあるコストでプロジェクトを実行しても、後々苦しくなります。プロジェクトの目的/目標の達成に必要な修正対応は早めに行いましょう。 おわりに PMは「限りある予算と限りない要求という圧力」と常に共にあり、コストマネジメントは大変困難な仕事です。そしていかに計画・準備とマネジメント施しても、どうしてもオーバーランするものだと意識してください。ITプロジェクトでは規模が大きくなる程予算超過率も高く、超過しないプロジェクトの方が少ないでしょう。コストの適正さや課題を日頃からプロジェクトオーナーと共通認識をもっておくこと。最も情報が少ないプロジェクト初期がコストマネジメントの重要タイミングであることを忘れず、コストマネジメントを困難にする様々な要因に立ち向かっていきましょう！ 次回のテーマは「プロジェクトの品質マネジメント」です。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ The post 【第8回】コストをプロジェクトの武器にする！ first appeared on Sqripts .

はじめまして。テストエンジニアのサバコ、りんご、ぴょんです。 私たち2名は、昨年よりQA事業に携わる部署の所属となり、現在はテスト実施業務に従事しています。まずはテスト実施で経験を積みつつ、将来的にはテスト設計者へステップアップしたい・・・！という目標を掲げ、日々業務に取り組んでいます。 そんな私たちは昨年、社内で1ヵ月間の「テスト設計者研修」を受講する機会がありました。今回のブログでは、テスト設計未経験の私たちが1ヵ月間の設計研修で何を学び、どんなことを感じたかをお話ししたいと思います。 テスト設計者研修の概要 1．座学（約１週間） はじめに、約1週間の座学を行いました。座学ではテストに関する基礎的な内容を中心に学習しました。 ソフトウェアテストの基礎とテスト工程の概要を学ぶ ブラックボックステスト技法の学習および演習 理解度テスト（1日）：主に各テスト技法の習得度を確認するテスト 2．テスト設計演習×2回（各1週間） 座学の次は、テスト設計演習を２回にわけてそれぞれ１週間ずつ行い、より実践的な学習を行いました。 演習用のシステム仕様書を基に「テスト設計仕様書」を一通り作成し、適切なテスト技法を用いてテストケースを作成するまでの演習 2回目の演習では、顧客への説明を想定したプレゼンテーションも行う テスト設計者研修で学んだこと、感じたこと 1．テストに関する知識・考え方の変化 座学の研修は基礎知識に関する講義が中心でしたが、その中でも重要なポイントについては実例を交えた丁寧な解説があり、テスト業務の全体像が理解しやすい講義でした。特に、テスト設計の一連の流れを学ぶことができたのはとても有意義でした。 受講前は、テスト実施業務で使用している「テスト項目書」は、開発仕様書などから直接起こすもので、イメージとしては「Verification（検証）」の視点に基づくものと考えていました。 しかし、実際には機能の洗い出し、テスト観点の抽出、洗い出した機能へのテスト観点の割り当て・・・など、様々な分析を行いながら「テスト設計仕様書」を作成し、開発仕様書には記載のない部分、ユーザーの要求・ユーザーの使い勝手なども意識した「Validation（妥当性確認）」の視点も含めて、ひとつひとつのテストケースが作られていることを学びました。 普段目にしている「テスト項目書」がどのようなプロセスを経て作成されているかを学び、また設計演習でそのプロセスを実際に順を追って体験できたことで、現在のテスト実施業務においても、 なぜこの観点が用いられているのか この項目にかかる工数は適切なのか などを考えながらテストに取り組むようになりました。 また、 挙動は仕様通りだが、システムの応答時間が若干遅いのでは （とあるシステムで）メッセージの送信時間に、時間だけでなく「日付」も付与した方がユーザーにはわかりやすいのでは など、ユーザビリティの観点を考慮して報告・要望も挙げられるようになってきたり、テストを行う際の「意識」にも少しずつですが変化が出てきたように思います。項目書の文字を追うだけのテストではなく、設計者の意図やテストを行う意味をしっかり理解した上で実施することで様々な気付きが生まれ、より質の高いテスト実施が可能となることをあらためて実感しています。 他にも、テスト設計演習の際、「ローレベルなテスト項目書の作成」を心掛けるよう指導がありましたので、実業務で触れるテストケースについても、 経験の浅いテスターでも、正しいテストが実行できる前提条件・実施手順となっているか 明確な期待値の記載がされているか など、ローレベルな項目書になっているかを常に考えながら見るようになりました。 「テスト設計には正解がなく、テスト設計者によってテスト項目にも違いが出る」とのことでしたので、この先もテスト実施を数多く経験していく中で様々なテスト項目書・テストケースに触れながら、実施しやすいテスト項目書のノウハウを身につけていきたいです。 2．難しかったこと、苦労したこと ブラックボックステスト技法の理解・習得 「同値分割法」「境界値分析」は比較的理解しやすく、実業務でも「テスト項目に具体的な入力値の記載がされていなくても、同値クラスや境界値を入力してテストする」など、ある程度自分で考えて活用できるようになりました。 が、「デシジョンテーブル」「組み合わせテスト」は、どういったケースに用いると有効なのかの見極めと、正しい条件が設定できているのか・・・などの判断がしづらく、演習でもうまく活用することが難しかったです。 とはいえ、膨大・複雑な仕様、入力条件を整理するためにはテスト技法の活用は必要不可欠とのことなので、それぞれの技法に慣れるために「テスト技法の問題集」などを活用し、自学に励みたいと考えています。 顧客への説明を想定したプレゼンテーション 緊張感が高まる中、「テスト設計仕様書」と「テストケース」をどのように作成したかの説明に終始する・・・という反省点の多いプレゼンとなってしまい、少々ハードルの高い演習でした。後に過去の研修の模範的なプレゼンテーションの動画が共有され、プレゼンのあるべき姿が把握できました。 正しいテストを行うためには、ステークホルダとの綿密なやり取り・テストに関する意識の擦り合わせが特に重要であることを学びました。 3．全体的な感想 ・主に「Meet」を利用したオンライン研修でしたが、並行してコミュニケーションツール「Metalife」も活用しました。「Metalife」は、研修メンバー全員での会議はもちろんのこと、受講者同士個別でも気軽にやり取りができるツールで、アバターを作成できるゲームのような機能が搭載されていたこともあり、気軽に利用できました。対面でないと一方通行になりがちですが、こうしたツールを上手に活用したコミュニケーションの取りやすい研修だったと思います。 ・テスト設計の知識が乏しかったため、理解のスピードや演習の進みが遅く、講師の方には苦労をお掛けしたことと思います。そんな中でも、都度Slack・ハドルミーティング等で最大限のアドバイス・フォローをいただくことができたので、設計演習・プレゼンテーションとも反省点は多々あるものの、ある程度の形に仕上げることができました。 ・研修全体を通して、学ぶべき情報量が多く、1ヵ月ではとても頭に入りきらない・・・と焦る気持ちが大きかったですが、研修で使用した資料や演習教材は研修終了後も参照できるよう共有されているため、今後も折に触れ参考にし、引き続き設計に関する知識を深める努力をしたいと考えています。 まとめ 1ヵ月という短い期間で、理論だけでなくテスト設計演習・プレゼン演習なども含めた実践的なスキル研修まで学ぶことはなかなか大変でしたが、得られたものは大きかったと思います。 社内で充実した研修を受講できたことで、テストに関する学びを深められ、日々のテスト実施にも自信を持って取り組むことができるようになりました。 今後も日々の業務を行う中で、研修の内容を反芻しながら知識を増やし、直近の目標として、まずはJSTQB FLの合格を目指したいと思います。 そして将来的には、テスト設計業務にも挑戦しスキルを更に高めていけるよう、前向きに進んでいきたいです。 おわりに 講師の方による研修ブログに、さらに詳しい研修内容の解説があります。ご興味のある方は是非ご覧ください！ テスト未経験者向けに研修を行って、気付かされたこと(前編) テスト未経験者向けに研修を行って、気付かされたこと(後編) The post テスト設計未経験者がテスト設計研修を受けて感じたこと first appeared on Sqripts .

こんにちは、エンジニアのしているタカです。 普段はスクラムマスターや開発者としてプロダクトの開発に関わっています。 今回は、自分たちのプロダクト開発チームで行なっているNotionとGitHubを使ったリリースバージョンの管理について紹介したいと思います。 リリースバージョンとは プロダクトの開発において、開発の区切りや本番リリースを行う段階で、プロダクトに バージョン という一意の番号を付与することがあります。 これはプロダクト（ソフトウェア、インフラ等）のとある段階を指し示すための番号であり、この番号とリリース日などを併せて管理することで、プロダクトの実装済み機能や改修の状態が、チーム内外から分かりやすく判別できるようになります。 例. A機能はバージョン1.0.0で実装した。Bの改修はバージョン1.1.2で行っており、このタイミングでデグレードが起きたなど このうち、本番環境にリリースしたものをリリースバージョンと呼びます。 リリースバージョンを定義することで 「◯月◯日」にリリースした機能 ではなく、 バージョン1.0.0でリリースした機能 といった呼称にでき、機能やリリース時期の関係が分かりやすくなります。 リリースバージョンと管理内容 自分たちのプロダクト開発チームでは4つのリリースバージョンを定義しています。赤字の数字が対象のバージョンに対応する部分です。 これらのリリースバージョンは、リリース日と後述の情報を併せてNotionのDBで管理しています。 リリースバージョンのDB. リリース日はグレーアウトしています ページの内容 リリースバージョンと紐づけて管理している内容は以下の4つになります。 Product Back Log（PBI） リリースノートのページURL コンテナのリビジョン リポジトリのmainブランチのタグ 1.のPBIは、Notionで別管理しているPBIのDBとの関連付けを行っています。また、2. のリリースノートのページURLは、公開したリリース情報に関するページなどのURLを載せています。 3.と4.については以降で個別に解説します。 コンテナのリビジョンを取得する 自分たちのプロダクトの環境は、Google CloudのCloud Run（コンテナ）を使用しています。 デプロイをするかサービスの構成を変更すると、コンテナごとにリビジョンと呼ばれる設定やコードバージョンのキャプチャ情報が生成されます。 このリビジョンにはコンテナのURLや環境変数などの設定に加えてデプロイしたソースコードも含まれ、GUI上から選択することでコンテナ単位で過去のリビジョンに戻すことも可能です。 Cloud runのリビジョンは、事前にインストールした gcloud CLIにプロダクト環境のプロジェクトを設定したうえで、以下のコマンドで取得できます。 $ gcloud run revisions list | grep yes このコマンドを実行するとリージョン選択を促されます。 リージョンを選択すると存在するコンテナの現リビジョンが表示されるので、先ほどのNotionのページにコピー & ペーストしています。 リポジトリのmainブランチのタグ管理 次はGitリポジトリでmainブランチのタグ管理を行います。 通常、タグはリポジトリをcloneしてきたうえで、ローカルリポジトリのmainブランチに切り替えて打つ方法が一般的です。 $ git checkout main $ git tag -a 1.0.2 -m '1.0.2リリース' $ git push origin 1.0.2 （又は git push origin --tags） ただし、ソース管理をGitHubで行なっている場合、 GitHubのRelease機能 を使うことでより簡単に管理が可能です。 機能で管理するメリットはいくつかありますが、タグ打ちとRelease関連情報の記録を同時に行うことが最大のメリットかと思います。 リリース機能の特徴 * GUIでタグを打てる * リリース情報を（commit情報を引っ張ることで）半自動生成で書けてファイル添付も出来る * リポジトリの利用者がRelease機能のページからソースや配布ファイルを簡単にダウンロードできる Release機能の使い方 1. リポジトリトップページの Tags をクリックします。 2. Releasesタブで、 Draft a new Release ボタン をクリックします。 3. Releaseの画面で、 Choose a tag プルダウン からタグを新規作成し、Targetブランチを指定します。今回は本番リリースのバージョンを管理するのでmainを指定します。 入力欄 4. タイトルと説明を入力していきます。本文はGenerate Release Notesボタンでcommit内容が自動で入力されますので、これを使用します。 5. 併せて、Notionのリリースバージョンページへのリンクも掲載して関連付けを行います。 6. 作成ボタン を押して画面が作成されたらOKです。 作成後のページ。内部情報が含まれているのでグレーアウトしています おわりに 今回の内容は以上となります。 現状、本日紹介した内容はリリース作業の一部として組み込んでおり、担当者が手動で実施しています。 現時点ではまだ発展途上であり、今後管理すべき情報がもっと増えた場合はそれに応じて追加していく予定です。 なお、コンテナリビジョン取得やNotion APIを用いてのページ作成等は比較的簡単に自動化できる思うので、リリース時の負荷はまだまだ減らせると思います。 リリース内容の管理に困っている方はぜひ一度試してみてください。 The post GitHubとNotionで実現するアジャイル開発のリリースバージョン管理 first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。 「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。 この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ 推論の形 を見ていきます。 はじめに どちらが「論理的」だと感じますか？ 図1-1、PさんとQさん、どちらが「より論理的」だと感じますか？　その理由は何ですか。 図1-1 食堂で注文を話し合うPさんとQさん 「論理の言葉」を覚えたら “実践編”のテーマ 論理スキル”実践編”では、”入門編”で出てきた「基本的な論理の言葉」を基にして、文や文章の論理構造を読み取ったり、筋道立った文を作ったりするための 「推論」の形 を見ていきます。 不具合/故障のチケットやテストサマリレポートを書きあぐねた経験はありますか。テストベース（要件定義書、機能仕様書、ユーザーストーリー、etc.）や返ってきたチケットを読んで、「どんな場合にどうなるのかわからないな？」「何故この対応でよいと言えるんだろう？」などと感じたことはありますか。 ソフトウェアの世界でも、(長めの)文/文章を読み書きする機会は多くあります。こうした困りごとをなくすためにも、 論理の言葉の使い方、使われ方 の感度を研ぎ澄ませましょう。 ●入門編：テストエンジニアのための論理スキル[再]入門 記事一覧はこちら ｜Sqripts 推論：　話の筋道をつくる、読み取る 推論とは 何か言いたいことがある時、最終的に言いたいこと(結論)と、その結論の前提があります。結論も前提も何かしらの主張や判断ですが、ここではざっくり「文」と呼びます（本連載では、文脈によって「主張」「判断」「文」を使い分けます）。 前提となる文(主張/判断)をつなげて組み立て、結論となる文(主張/判断)を導くことを 推論(inference) と言います。(図1-2) 1-2 “推論”とは 推論では、前提(根拠)から結論までのつながり、話の筋道が重要です。(図1-3) 前提が、結論(言いたいこと)の根拠になっている 前提から結論までのつながりに無理や飛躍がない 図1-3 推論で大事なこと その話の筋道を組み立てたり、話の筋道をチェックしたりするのが、 推論の形 。 そこで活躍するのが、“入門編”で見てきた 論理の言葉 です。 形が整っていれば自動的に「正しい筋道、正しい推論」となるわけではありませんが、形がよくない立論は言っていることが正しくてもよい主張とは言えません。（「「真」と「妥当」」の節参照） 推論の種類と、”実践編”で扱う推論 推論には種類がいくつかあります。(図1-4) 図1-4 演繹と帰納とアブダクション 演繹 （えんえき） 演繹（deduction） とは、ひとつ以上の前提から結論を導き出す推論の形です（図1-4は「前提から結論」をいくつか組み合わせた複合的な形になっています）。 何かを根拠とともに主張する時、正しいと広く受け入れられた事柄に基づいて個別の事例を論じる時、などに使われます。 前提がすべて正しいなら、結論が正しいかどうかは形から判定できます。 帰納 （きのう） 帰納（induction） とは、個別の事例から一般的/普遍的な前提(各事例に共通する規則・法則、性質・特徴など)を導き出す推論の形です。 ソフトウェアのテストで、「画面AでPという操作をしたら故障Xが起こった」「画面Bで操作Pをしたら故障Xが起こった」……「どの画面でも、操作Pをしたら故障Xが起こる（のでは？）」と仮説を立ててテストを広げていくのは帰納的な推論の働きです。 有限個の事例に基づいているため、この推論から導かれる「事例に共通すること」は必ずしも正しいとは限りません（“当てはまらない例外”があり得る）。 アブダクション、レトロダクション アブダクション(abduction)、またはレトロダクション(retroduction) とは、個別の事例から、その事例(結論)に至る前提や理由を導き出す推論の形です。 アブダクション的な推論として、 デバッグ があります（故障から、その故障を引き起こす原因である欠陥を推定する）。また、欠陥の 原因分析 でもこの種の推論が働きます。 この推論から導かれる「前提と当てはまる推論」も、必ずしも正しいとは限りません（デバッグでも、原因を特定したと思ったら違っていた、やり直し。ということは多々ありますね）。 “実践編”で取り扱う推論の種類 “実践編”では、前述のうち演繹的な推論/思考を形成する推論の形を取り扱います。 帰納やアブダクションでも必要になる、思考の基盤です。 演繹的な推論にもいくつか種類がありますが、本連載では「ふたつ以上の前提(主張/判断)から、結論となる主張/判断を導く」形式を主に取り扱います。 「真」と「妥当」　～正しさの留意点 正しい推論であるためには、ふたつのことに留意する必要があります。(図1-5) 図1-5 真と妥当 「真」であること　……内容の正しさ(真偽) 前提が間違っていたり、結論が間違っていたりしていては、正しい主張とは言えません（当然ですね）。正しい前提に基づいて、正しい結論を導出するものである必要があります（図1-5の上の文が真です）。 「妥当」であること　……話の筋道の正しさ(妥当性) 前提や結論が真でも、適当に(自分に都合よく)理屈をつけるのでなく、 話の筋道が「よい形」をしている 必要があります （図1-5の上の文が妥当です） 。 「よい形」とは： 論理の言葉を適切に（意味と働きに即して）使っていること 文(主張)と文(主張)とのつながりの中で矛盾や飛躍を生じていないこと 真偽も大事だが、話の筋道も大事 前提や結論が正しくても、非妥当な(よい形でない)推論は間違った推論です。 次のa, bどちらも、①②③それぞれは正しいとしても、①②から③を主張することは妥当ではありません。 (a) ①イヌはイヌ科の動物である。②イヌは哺乳類である。∴③イヌ科の動物は哺乳類である。 (b) ①ネコにはしっぽがあるか、またはにゃあと鳴く。②うちのネコはにゃあと鳴く。∴③うちのネコにはしっぽがない。 一方、前提や結論は間違っていても、妥当な(よい形をしている)推論は作れてしまいます。 (c) ①哺乳類は空を飛ぶ。②イヌは哺乳類である。∴③イヌは空を飛ぶ。 (d) ①ネコには縞模様があるか、または単色である。②うちのネコには縞模様がない。∴③うちのネコは単色である。 両方揃って、初めて正しい推論と言えることになります。 内容の真偽はその内容を吟味しないと判断できませんが、筋道の正しさは形から判断できます。本連載で取り上げる「推論の形」はその筋道の正しさを確保する役に立ちます。 なお、「よい形」を作れていない推論や、内容に誤りがある推論の特徴を「誤謬(ごびゅう)」と言います。これらについてはシリーズ後半の記事「気をつけたい落とし穴」で取り上げる予定です。 冒頭の“問題” 「食堂で注文を話し合うPさんQさん」は「「論理的」ってどういう感じのこと？」を感じてもらいたくて考えたもので、考え方の正誤や優劣を論じるものではありません。 Pさんの主張を整理・補足すると、①初めての店では外れのなさを優先して注文する。②唐揚げは大体どの店でもおいしい（から、外れがない/少ない）。③唐揚げ定食を注文する。 となっていて、①と②から③が無理なく出てきます。 Qさんの方はどうでしょうか。 ①初めての店では（その店の「推し」として）「本日のおすすめ」を頼む。②さらに煮魚定食はこの店で一番安い（から、懐に優しい）。③煮魚定食を注文する。 Qさんの主張には、 それが嫌いな食べ物でも頼むの？ とか、 「本日のおすすめ」がメニューの中で一番高かったらどうするの？ という疑問が生じます。前提①②と結論③の間に飛躍がある感じがします。 （本“問題”は、『論理的思考の技法Ⅰ』を参考にしました） （注：「食事の注文は論理的に考えてなされなければならない」と言っているわけではありません！） （注：どちらの「注文の論理」も、ありだと思います） （注：何にせよ心地よく選んで心地よく食事を楽しみましょう！） クイズ 次の主張は「よい形」をしていると思いますか。 （『例解・論理学入門』を参考にしました） （解答は次回に） 問1 Aさんの性格を考えると、①Aさんはギャンブルに手を出すと破産する。 しかし、②Aさんはギャンブルには手を出さない。 従って、③Aさんは破産しない。 問2 その時代、①家柄がよくて、裕福ならば、誰でも結婚できた。 ②彼の家柄はよかった。 しかし、③結婚できなかった。 従って、④彼は裕福ではなかった。 参考文献 鈴木美佐子 『論理的思考の技法Ⅰ〔第2版〕』法学書院 2013 弓削隆一, 佐々木昭則 『例解・論理学入門』 ミネルヴァ書房 2009 図版に使用した画像の出典 TopeconHeroesダーヤマ, 『分かりやすいプレゼン資料 1秒で伝わるビジネスイラスト集』 インプレス 2016 人物画(シルエット)をお借りしています。 Loose Drawing  人物画をお借りしています。 The post 論理のかたち。推論とは｜テストエンジニアのための論理スキル［実践編］ first appeared on Sqripts .

こんにちは、エンジニアのタカです。 普段はスクラムマスターや開発者としてプロダクトの開発に関わっています。 今回は、自身が所属する開発チームで起きたコミュニケーションの課題を解決した バーチャルオフィスツール Gatherについて、導入前後でどのようにチームに変化があったのかを紹介したいと思います。 チームのコミュニケーションの課題 開発チームが2023年夏頃に行った振り返りで、特に新しくチームに入ったチームメンバーからコミュニケーションの敷居が高いという意見が上がりました。 チームメンバーはオフィスや遠隔地の自宅などそれぞれ異なる場所で働いており、会話を伴うコミュニケーションツールはSlack（ハドル） とGoogle Meetを使用していました。 これらのツールでは、話す前に「通話いいですか？」などを一度Slackチャンネルに投稿してから行なっており、会話へのアクションが段階を踏むことで気軽に行えないという意見が上がりました。 そこで、解決策の一つとして上がったのがバーチャルオフィスツール ※1 でした。 もちろん、出社時にコミュニケーションを取ることで解決する部分はありますが、遠隔地で勤務しているチームメンバーも含めて常に全員が揃う機会は少なく、今回試すことにしました。 ※1：仮想のオフィス空間 = ワークスペースにチームメンバーがアバターとして表示され会話やチャットを行う。まるでオフィスに居るように人（アバター）の動きが可視化されるのが特徴 Gatherとは バーチャルオフィスツールは数多くありますが、無料プラン ※2 をチームで使って比較検討を行い、最終的に以下のような理由から Gather を使うことに決めました。 操作性 アバター移動の操作性とレスポンスがよく、使っていてストレスが無かった 親しみやすさ ワークスペースが上から見下ろすタイプのドット絵で描かれた2Dで、キャラクターもドット絵で馴染みやすい 筆者を含む2Dゲーム世代(?)のメンバーのウケがとても良かった ※2：この記事を書いている段階ではGatherは最大10名まで無料 Gatherを触ってみての感想 以下、Gatherの導入にあたり設けたチームルールと、主な機能を使ってみての感想になります。 導入したチームルール 定例MTGを含む、全てのチームコミュニケーションはGather内で行う 機密に関わる話、チーム外のメンバーを交えたMTGなどは除く ステータス状態を逐次変更する ステータスはコマンドで変更でき、誰が不在かが分かりやすいため 主な機能の使用感 1. アバターでのコミュニケーション Gatherを選んだ理由の一つでしたが、アバターの操作性、レスポンスがよいです。 またチームメンバーの今の状態が一覧で見れることで「あの人は今誰かと話している」「話しかけて大丈夫そう」など現実のオフィスに近い感覚で状況把握ができるようになりました。 誰かと話して別の人を呼びたい時も、手を振るという機能を使ってすぐに通知が飛ぶので、ストレスなくコミュニケーションを行うことができました。 2. ビデオ通話（多人数、少人数） ビデオ通話の品質は、meetと比較しても特に遜色はありませんでした。MTGルームや各自席周辺などのフォーカスが当たる部分に入ることで、その部分に居るメンバーはシームレスに通話に移行するので使いやすいです。 ただし、人数が増えると、PCスペックや回線によっては、ビデオをONにしたときにややPCが重くなるケースがあったため、その場合はビデオを切ってMTGしてもらうなど対策を行なうことでこの問題は解消されました。 なお、フォーカスの無い場所ではアバター同士を近づけると話せますが、基本的に各自の席周辺や大きなフォーカスエリア（MTGルーム）で話すことが多くなったため、立ち話のように何も無い場所で会話することは少なくなりました。 3. デスクトップアプリ 個人的に、Gatehrはデスクトップアプリがとても使いやすいと感じました。 アプリはミニモードという表示が行え、Gatherからフォーカスを外した時はデスクトップ上に自分のステータスが最小表示されます。このときに誰かが自分の居るフォーカス部分に来ると、ミニモードのままで通話ができます。 常に画面を出しっぱなしにしても良いのですが、集中したいときは気になるので、このモードのおかげでリモートワークのメリットと、オフィスワークのメリットの両方が満たされると思いました。 なお、この状態でキャラクターを動かすことはできないので、MTGルームに行くなどの際は、Gatherアプリを選択してキャラクターを動かします。 4. その他機能 GoogleカレンダーやSlackとの連携、Gatherへの外部アクセス制限、ゲスト招待機能、オフィステンプレートの編集機能などを使用しています。 この中のGoogleカレンダー連携は、予定の数分前にデスクトップに通知を出せるようになるので、MTG参加忘れに役立ちます。 コミュニケーションに起きた変化 Gahterを使い始めてすぐにコミュニケーションの変化を実感しました。そのうち、特に実感したことをいくつかピックアップします。 良い方向に変わったこと 1. コミュニケーションコストの低下 振り返りで課題として上がっていたコミュニケーションの敷居の高さは無事解消されました。 Slackで一言投稿するよりも、話しかけてOKのステータスの人に近寄って呼び出すことは心理的ハードルが低いという意見がありました。 また、アバターだからか誰と誰が話しているかも分かりやすくなり「朝会で報告した問題点について有識者と話していそう」など状況が掴めるようになりました。 2. MTGへのシームレスな移行 MTGをGatherで行うことにより、MeetなどのMTG用ツールの起動が不要になりました。 全員でMTGを行う際は、オフィスのように全員が集まれるエリアに移動するだけでMTGが行えるので、特にストレスなく開始できます。 議事録やチャットもGather上のホワイトボードに記録でき、全体向けに共有が必要な場合はその場ですぐに共有ができるので、プロジェクトで必要なコミュニケーションは、基本的にGather上で動作が完結できます。 気になった点 1. コミュニケーションコスト低下により、作業時間が減るメンバーが出てきた メリットと表裏一体ではありますが、気軽に会話をしやすい環境になったため、特にコアメンバーへは相談や質問でのコミュニケーションコストが生じ、作業時間が減少するという問題が起きました。 設計やレビューなどの必要なコミュニケーションが増えることは良いことですが、本来は自分で解決できるような簡単な質問も増えてしまう傾向が見られました。 リモート、オフィス関係なく基本的なことではありますが、質問する場合のルールを決めたり、優先作業に集中したい場合は応答不可にして貰うルールを設けることを検討しています。 2. リモートメンバーとオフィスメンバーが混在する場合の取り決め オフィスに出社しているメンバー同士ですと、わざわざGather上で話すよりも直接話すことが多いため、リモートメンバーからは状況がつかめなくなります。 弊社はフリーアドレス席のため、固まって仕事をすることはほぼ無いのですが、出社中の場合はステータスを記入してもらうことで状況をリモートメンバーにも明示することを検討しています。 おわりに 今回の内容は以上となります。 バーチャルオフィスツールは初めて使いましたが、結果的にコミュニケーションに対する敷居が格段に下がり、リモートワークにおけるメンバーの満足度が向上しました。 主にリモートワークでコミュニケーションに課題があるチームは一度使ってみる価値はあると感じたので、気になった方はぜひ一度試してみてください。 The post リモートワークのコミュニケーションコストがバーチャルオフィスGatherでグッと下がった話 first appeared on Sqripts .

はじめまして。テストエンジニアのchikaです。 最近はリモートワークも増えチャットツールを導入した企業が多いと思いますが、 チャットツールを使っていて情報を取りこぼしたこと 仕事はこなせているけどもうちょっと効率良く作業できないかな～と思ったこと はありませんか？ そんな２つの課題を解決に導いたTeamsの便利機能を実体験を元にご紹介したいと思います。 Microsoft Teamsとは？ マイクロソフト社が提供するコミュニケーションツールで、チャットや通話、ビデオ会議といった複数の機能が実装されています。また、Officeアプリと連携してファイルを共有したり編集ができるとても便利なツールです。 便利機能の紹介 チャットの見落とし防止 Teamsを使い始めた当初、いつの間にか色んなグループにメンバー追加されどんどんチャットがきて必要な情報を見落としてしまう始末…とても困っていました。そんな中で見つけたTeams初心者にオススメの機能です。 メッセージの保存機能 重要なチャットや後から読み返したいチャットなど、どのグループチャットからも自分専用の場所に保存することができる機能です。 保存したいメッセージの右上［‥］＞「このメッセージを保存する」をクリックすればOKです。 保存したメッセージは、右上の自分アイコンの「保存済み」をクリックすると保存済み一覧が表示され、必要なメッセージのチェック時間を削減することができます。 【補足】チェックし終わったメッセージは「保存」を外しておくと、必要な情報が整理できて 未読の確認機能 検索欄に”/unread”と入力すると、左側のフィードに未読メッセージの一覧が表示されます。　　休み明けやリアルタイムにチャットを確認できなかった場合に重宝します。 ※［アクティビティ］＞未読のみ のトグルをONにしても同様です。 自分専用チャットによる 作業効率アップ 今まで必要な情報はメモ帳やExcelにまとめていましたが「自分専用のチャット」があることに　気付き、使ってみたらファイルを開いて知りたい情報に行きつくまでのちょっとした手間が省け、　以前より情報収集のスピードがアップしていました。 日常的に使えば使うほど「タイパ （Time Performance）」を実感できる機能です。 自分しか閲覧できないチャットで、自分宛てにメッセージを送信して使用します。 画面左にある「①チャット」をクリックし、固定表示の「②自分の名前（あなた）」をクリック 又は、画面上の検索欄①に自分の名前を入力し「②自分の名前（あなた）」をクリック あとは、通常のチャットと同じようにメッセージを書いて送信すればOKです。 今回はほんの一例をご紹介しますが使い方次第で時短の可能性は広がりますので、是非ご自身で　活用法を探してみて下さい。 リンク先やフォルダの場所一覧 リンク先のURLやフォルダの場所を記載しておくと、探す手間だけでなくチャット毎に整理ができ編集もラクなので便利です。 ※但し、デスクトップのショートカットやブラウザのお気に入りの方が便利な場合もあります 操作/手順の簡易マニュアル化 テストツールの操作やテスト手順は、頻繁に使うものは覚えているものの時々使うものは忘れがちです。そんな手順の一部を抜粋したりポイントを記載（簡易マニュアル化）しておくと、テスト実施時や依頼を受けた際の対応スピードがアップします。また、ExcelやWordの手順書は機能毎にファイルが分かれているケースが多いですが、必要な手順だけチャットに送信しておけばTeamsの検索機能でピンポイントで手順を見つけることもできます。 ※但し、複雑な手順は不向き（ExcelやWordの方が見やすい） メッセージの下書き 誰かにメッセージを送る前に内容を整理したり後で送信したい時など、下書き代わりに使用すると便利です。ファイルとは違い記載するだけで内容が維持されるのも良い点です。 端末間の情報共有 Microsoftアカウントは５つのデバイスまで登録可能なので、自分のアカウントでログインした　テスト用端末／事務用端末 のチャットを使って結果（スクリーンショット）を共有できます。今までは不具合チケット起票用のスクリーンショットをテスト用端末から社内メールを使って事務用端末に送付していたので、工程も時間も短縮されました。 注意事項 業務で使用する場合は、セキュリティ上の問題がないかご確認のうえ行って下さい。 上記で紹介したTeamsの便利機能は、他のコミュニケーションツールにも同等の機能があります。 　　例えば「Slack」でいうと以下になります。 - メッセージの保存機能 ⇒　メッセージのブックマーク機能 - 未読の確認機能 ⇒　［アクティビティ］＞未読メッセージ のトグルをON - 自分専用のチャット機能 ⇒　［ダイレクトメッセージ］＞自分の名前 (自分) チャット おわりに 今回紹介した機能は簡単に情報の見落とし防止や時短による効率アップが図れると思うので、 皆さんに活用してもらえたら嬉しいです。 以上、最後まで読んでいただきありがとうございました。 The post Teamsで業務効率UP！便利機能の紹介 first appeared on Sqripts .

本連載では、ここまで主に「1人目のQAがやるべきこと」について、経験ベースでお伝えしてきました。 今回は少し視点を変えて、1人目のQAがやるべきではないこと、アンチパターンについてご紹介したいと思います。 やるべきことは組織の状況などによって変化することもありますが、アンチパターンは状況によらずある程度共通する部分がある、と考えているためです。 本記事では、代表的なアンチパターンを4つ説明します。 ＜1人目QAとしての立ち回り　連載一覧＞ ※クリックで開きます 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 【第2回】組織に品質保証を浸透させるアプローチ 【第3回】品質保証やQAエンジニアを知ってもらうための取り組み 【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。 目の前のタスクに集中しすぎる 一つは、目の前のタスク、「すぐに実施できて達成感が得られそうなタスク」に集中しすぎてしまうことです。 とくに組織にJoinした直後のQAは、できる仕事がたくさんある状態だと思います。 そこで 【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。 | Sqripts でご紹介したように組織の現状把握をしつつタスクの取捨選択を行うわけですが、このときに個々のタスク、とくに達成感・「仕事をした感」が得やすいタスクを選び取りがちです。 たとえばリリース後に見つかる不具合が多い開発チームに入っていき、テスト設計・実行やリリース前の探索的テストに注力したとします。もちろんこれ自体は良いことです。しかし、そこでバグを見つけたり開発チームに感謝されたりしながら、1か月2か月と過ごしていったとして、それは1人目QAとしてのミッションに沿っているのでしょうか？ 会社として、問題のあるチームに入って立て直してほしいという狙いがあれば、動き方としては良さそうです。しかし、広く会社全体の品質保証のやり方を考えてほしい、といった狙いがある場合はどうでしょうか。 目の前のタスクを行って一定の成果が出ることは良いのですが、ついそこにハマってしまう危険もあります。1人目QAとして期待される動きや成果を考慮したうえで、場合によっては広く組織全体にアプローチするようなやり方が必要かもしれません。 得意なやり方、実績あるやり方に頼りすぎる なんらかの課題に対して、自分の得意なやり方や実績あるやり方を当てはめてしまうというのもよく目にするアンチパターンです。 テスト技術に自信がある、テストプロセスの整備の経験が豊富など、QAエンジニアそれぞれにはなんらかの得意なジャンルや手法があるかと思います。 そして、とくに入社直後のQAの場合は目に見える成果が欲しくなるため、つい自分の得意技で攻めようとしてしまいがちです。しかし、たとえばシステムテストの自動化が得意だからといって、なんでもかんでも自動化によって解決できるわけではありません。 必ずしも得意ではなかったとしても、今自分のいる組織にとって何が必要なのかを見定めるところからスタートするのが良いでしょう。結果として、やるべきことに対して自分のスキルが不足している場合には、社外の有識者を頼ることも一つの選択肢ですし、エンジニア部門のマネージャー等と協力しながら「経験はないけれどもチャレンジしてみる」こともできるかもしれません。 周囲のスムーズな理解を期待してしまう 1人目のQAと周囲の開発者やマネージャーとの間には、物事の見方・捉え方や知識の幅などに多くの違いがあります。とくに1人目として入社した直後のQAと、長く勤めているメンバーとではこの違いが顕著になるでしょう。 QAに限らず、そのロールの1人目として働く場合は「自分がどのような役割なのか」を周囲に理解してもらう必要があります。たとえば、1人目QAの方から「QA＝テストしてくれる人、という認識を持たれがち」といった話も伺います。これが誤解である場合、組織におけるQAの位置づけをもっと違ったものとして考えている場合は、適切に伝えていかなければなりません。 ところが、周囲の理解は簡単に得られるものではありません。QAとしての活動をわざわざ邪魔してくる人はいないかもしれませんが、誤解や無知（にQA側からは見える状態）などは必ず発生します。 そのため、開発者やマネージャーはQAのことを知っているはず、一度説明すれば理解してもらえるはず、といった「周囲のスムーズな理解」を期待するのは危険です。 QAの役割や関わり方など、なんらかの情報を組織の中に広めていくということは、思った以上に時間がかかることです。「簡単にはわかってもらえない」「伝わったと思っても伝わっていないことが多い」という前提を持ちつつ、しつこいくらいに伝え続ける動き方が1人目QAには求められます。 独力でなんとかしようとしてしまう QAかどうか、1人目かどうかに関わらず仕事全般に通じるアンチパターンですが、とくに1人目QAの方はハマりがちな傾向にあるように思います。 組織1人目のロールの場合、相談できる相手が居ないか、限られることが多いです。 かつ、1人目QA自身も「プロとして呼ばれてきたわけだから、相談しづらいな・・・」と感じてしまうのかもしれません。 いろいろな組織課題を独力で解決しようと考えても、多くの場合解決できないか、時間がかかりすぎてしまいます。それでは組織にとってもメリットがありません。 私自身1人目QAとして働いて感じたことは、品質への興味を持った方は少なくない、という点です。開発者の中にもテストをうまく・効率的に行いたいと考えている方はいますし、マネージャーの中にも品質向上のために試行錯誤した経験のある方が必ずいます。 そうした方々の取り組みや課題を拾い上げて一緒に解決していくことも、1人目のQAとしての価値です。「自分がなんとかする」という責任感もすばらしいですが、いったん脇に置いて「積極的に周りを巻き込んで一緒になんとかする」という考え方に変えてみるのもよいでしょう。 また、社内に相談相手がいない場合は社外を頼るという方法もあります。 昨今は（私も含めて）カジュアル面談プラットフォームなどを用いて「他社QAと情報交換しましょう！」という場を設けている方もたくさんいます。もちろん社内の情報の扱いには注意が必要ですが、純粋な技術課題・組織運営課題として抽象化したうえで社外の方と話をしてみる、経験談を聞いてみるのも有効です。 1対1の会話でなくとも、社外の勉強会やイベント等に参加して他社事例を聞くことも有効です。勉強会などで「今の自分が抱えている問題にピッタリはまるヒントは得られなかった」という方もいますが、私はそのような都合のよい機会はほぼないと考えています。 そうではなく、普段から勉強会やイベント等に参加をして情報を集めておき、いざ自分がなんらかの課題に直面したときに過去見聞きした情報からヒントを得るものです。 書籍や、Web上に公開されている資料なども含めた意味での「他人の知恵を借りる」ことは常に意識しておきたいですね。 1人だからとタスクや情報を抱え込まないのがポイント 今回は代表的な4つのアンチパターンをご紹介しました。 共通する点としては、1人だからといってタスクや情報を抱え込まないようにすべき、という点です。 1人目のQAは周囲から謎の存在になったり、あるいは「テストしてくれる人」のような固定イメージで見られたりすることがあります。そうならないためにも、自分がどのような役割を担いたいのかや何ができるのか、いま何をしているのかなどを常に発信していきましょう。 連載一覧 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 【第2回】組織に品質保証を浸透させるアプローチ 【第3回】品質保証やQAエンジニアを知ってもらうための取り組み 【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。 The post 【第5回】1人目QAアンチパターン first appeared on Sqripts .