概要

ヒューマンエラーとは、達成しようとした目標から、意図せずに逸脱することとなった期待に反した人間の行動です。このヒューマンエラーは本来人間が持っている多くの特性の何れかが現れただけであり、自らエラーをしようと思っている人間はいません。品質事故の原因の多くは、関係者の確認
不良とコミュニケーションエラーであり、ソフトウェアの品質管理においても、ここに注視する必要があります。
開発者間では、開発中に同じ用語をそれぞれの解釈をしていることに気づかなかったり、特例があることを伝えることを忘れていたりすると大きな手戻りや不具合につながります。ユーザインタフェース
を通じた操作や情報提示は、ユーザと開発者間のノンバーバル（Non Verbal）のコミュニケーション
と捉えることができます。ここでは、アフォーダンス（Affordance）への配慮が少ないとユーザが使いにくいと感じたり勘違いを誘発したりします。
本講演では、ヒューマンファクターの視点から、コミュニケーションエラー誘発の要因、エラー防止のポイントを考えてみます。

概要

通常、ソフトウェアテストにおいては、テスト要因を分析し、その要因を組み合わせてテスト項目を作成し実行する。作業効率化のため、実行と結果確認を自動化しても、テスト項目作成は人手であり、
実施可能な組み合わせ数に限界があった。そこで我々は、要因をランダムに組み合わせ大量のテスト項目を自動生成し、生成されたテストの実行および回答との結果比較まで自動化する手法により組み合わせのバリエーションを拡張したテストを実施し、多くの障害を検出した。
しかし、活用の実績から2つの問題があることが明らかになっている。1つは、テスト項目を、ランダムに要因を組み合わせ生成した順に実行するため、品質リスクに応じた順番でテストできず、早期の品質確保ができないことである。もう1つは、結果比較でNGとなるテスト項目を大量に検出した場合、それらが同一原因によるものかの確認は人手であり、工数がかかることである。
本報告では、これらの問題を解決するため、障害に関係する重要な要因を含むテスト項目を優先的に実施する手法と、検出した障害を、そのテスト項目の要因に着目して同一原因かどうか自動で分類し、原因の究明を効率化する手法を提案し、実際のテスト作業においてこの手法を適用した効果について報告する。

概要

探索的テストは、バグの摘出効率が優れており、品質向上や生産性向上を目指す多くの組織に注目・活用されている。
しかし、システムの受託開発を行う業者における、探索的テストの採用事例は少ない。
探索的テストは、事前にテストケースを作成しないため、テストの総量や実施範囲が不透明であり、テスト管理が難しいことが原因の1つと考えられる。
そこで、受託開発におけるテスト管理に求められる要件を明確にすべく、JSTQB Foundation Levelシラバス「5. テストのマネジメント」に記載の6つのカテゴリに着目し、これらのカテゴリごとに、探索的テスト導入時の問題点を整理し、改善目標を定義した。
本発表では、テストをセッションと呼ばれる時間の枠で管理する「Session-based Test Management」を活用することで、定義した改善目標を満たしながら、探索的テストを実施する方法を検討し、実際の開発現場で適用した結果を紹介する。

概要

製造装置の組み込みソフトウェアの開発は、装置の初期開発から保守にいたるまで開発期間が長く、その間に機能追加、機能改修を随時行う必要がある。特に新規装置では改良が頻繁に行われ、ソフトウェアは定期的にリリースされる。この定期的なリリース毎に、開発チームでは開発から実機組み込みまでフェーズを分けてテストを行っている。
リリース前のテストでは、目的の異なる２つのテストを行っている。作った機能が仕様通りに動くことを確認する仕様ベースのテストと欠陥検出を主眼としたテストの２つである。仕様ベースのテストを主とし、欠陥検出のテストで仕様ベースのテストを補完するようにしている。
これらのテスト活動を行っているが、リリース後(装置組み込み後)に欠陥が検出されることがある。欠陥を検出しきれていない問題にはいくつかあるが、その中でも欠陥検出のテストがアドホックなテストとなっている点に着目し、このアドホックな欠陥検出のテストを探索的テストとするべく取り組んだ内容を報告する。

概要

STAMP/STPA (Systems Theoretic Accident Model and Processes / System-Theoretic Process Analysis)は、数多くのシステムがつながることにより発生する事故の解析に有用とされており、安全性解析の新しい手法として注目されている。
従来の安全性解析手法（FTA、FMEA）では、事故を引き起こす原因はシステムの故障であるとしている。それに対してSTAMP/STPAでは、システムがシステムの状態を誤認識することにより、“安全ではないアクション”を実行することが事故の原因であり、それを特定するためにプロセスモデル（システムが認識するシステムの状態）の抽出が必要であるとしている。しかし、プロセスモデルの具体的な抽出方法については提示されておらず、分析者がアドホックに抽出するしかないという課題がある。
この課題に対し、MITのJohn Thomas氏はExtending STPAというコンテキスト（システムの状態）を分解してプロセスモデルを具体化していく手法を発表している。本提案は、この手法の前に、6W3Hを適用してコンテキストを幅広く捉え、プロセスモデルの漏れを予防しようとするものである。

概要

システムのディペンダビリティを説明しステークホルダ間の合意形成を行うことを目的として、D-Caseという手法が提唱されている。発表者らは2013年度にD-Caseを用いて曖昧な要求仕様を明確化することに成功し、その後も現場への適用拡大に取り組んできた。しかし、D-Caseの使いどころや論証方法が難しいという点から導入が進んでいない。
対策として「D-Case適用ガイドライン」を策定し、プロジェクトへの適用手順を明確にした。その際、いきなりD-Caseを書き始めるのではなく、D-Case作成前のチーム議論によってプロジェクトの目的、リスク、チャレンジしたい内容をチームで共有することに重点を置いた。また、ソフトウェア開発によくある具体的なパターン（D-Case適用パターンと呼ぶ）をガイドライン中に掲載し、初めてD-Caseを作成する人の指針となるようにした。さらにD-Case適用ワークショップを開催し、開発プロジェクトごとに少人数のグループにわかれた議論を行いD-Caseを作り上げた。現在は、作成したD-Caseから導出されたタスクの実行と効果の確認を行っている。
本発表では、D-Case適用ガイドラインの内容と適用の結果を報告する。

概要

業務システムの開発においては、関心事の異なるステークホルダーに対して、業務システムの機能や画面といった、仕様に関する情報をさまざまな視点や抽象度で表現し、議論や妥当性確認を促す必要がある。そのような場面において、例えば、技術者と技術者ではない読み手とのコミュニケーションのために、仕様書が用いられる。仕様書は、通常、技術者が作成・維持し、仕様に関する情報をある形式で表現し集約したものである。しかし、技術者ではない読み手には不適切な形式で仕様が表現されることや、読み手のさまざまな視点に合わせた異なる形式の仕様表現との間に不整合が生じるといった課題がある。そこで本研究では、仕様に関する一通りの情報を集約しつつ、読み手のさまざまな視点に合わせた形式の仕様表現を生成するための、仕様書の作成・維持の支援手法を提案する。具体的には、形式手法のひとつであるVDM (Vienna Development Method)によって厳密な仕様表現(形式仕様記述)を作成し、その記述から、機械処理により状態遷移図やシーケンス図といったさまざまな形式の仕様表現を生成する。本提案手法により作成・維持される仕様書は、異なる形式の仕様表現との間の不整合を防ぎつつ、現場担当者や技術者といったさまざまな読み手に適した形式の仕様表現を含むという特徴を持つ。

概要

派生開発では、変更の影響箇所に潜在する欠陥を、回帰テストで見逃さず検出することが必要である。限られた時間で、影響範囲に対するテスト漏れを防止するためには「確実な影響範囲の特定」に加えて「テストの網羅性の確認」と「影響範囲を小さくする設計」が重要である。本発表では「制御の流れとデータ更新・参照の流れから影響箇所を特定可能」という考えから、影響波及パスという概念を定義し、それを利用した手法「影響波及パス分析法」を提案する。本手法を実開発に適用した結果、影響範囲に対するテスト漏れによる欠陥流出の防止に繋がる効果が確認できた。

概要

近年のソフトウェア開発では流用開発やOSSの活用等、開発者は他者が開発した機能を開発対象に組み込むことが一般化してきている。この開発方法は開発工数の大幅な削減が期待できる。その一方で、他者が開発した機能を取り込むことで、開発対象のソースコードがブラックボックス化・複雑化し、ソースコードの品質劣化による障害の誘発や、障害調査・修正に多くの時間を要する等の問題が発生している。開発者に開発対象のソースコードの品質情報を提供すれば、問題の早期発見や修正時間の短縮化につながると考え、ソースコードの品質状況をメトリクスにより自動測定し、定量的に把握する仕組みの確立、および開発現場への展開を行ってきた。しかし、開発現場からは「メトリクスを見ても対応方法が判らない」等の声があがっており、定量的なメトリクス情報に基づいてソースコードの品質を改善するプロセスが現場に根付かない問題があった。
そこで本稿ではソースコードの品質劣化を表すメトリクスと、その後のソースコードの修正回数や修正日数（品質リスクと呼ぶ）との関係を分析し、これらの間に関連があることを示す。これにより開発者にメトリクスを活用したソースコード品質改善の早期対応への動機づけを行う。あわせて品質リスクへの具体的な対応案を開発現場に提示し、品質劣化を防止することで、追加コストの発生および納期遅延を未然防止することを狙いとする。

概要

既存システムの改修を行う派生開発では、開発側も顧客側も機能要件に意識が集中しがちなために性能要求が要求仕様書に明記されず、応答時間や処理速度の劣化を招くことがある。このような性能劣化は開発終盤や納品後に判明することが多く、そのため修正に大きなコストがかかる。
そこで我々は、機能の追加・変更に伴う性能劣化について顧客と交渉が容易な要件定義フェーズで把握することが重要ととらえ、システムの改修が時間効率性に与える影響を処理時間に換算して検出するための方法「EMOT (Estimation Method Of Time behavior degradation)」を考案した。
本論文では、本手法により時間効率性の劣化を機能の追加・変更要求から検出することができ、要件定義フェーズで性能劣化の対策を講じることで時間効率性の劣化防止に寄与できることを示す。

概要

ソフトウェアパッケージ製品を一定期間契約するサブスクリプションモデルおよび月額ベースで契約するクラウドサービスモデル等のリカーリングビジネスを支えるためには製品およびサービスの品質を高めるだけではなく、顧客からの技術的な問い合わせに関するプロアクティブなフィードバックプロセスの構築が必要不可欠である。
当社では第三者への品質情報の提供を意識し、品質特性を活用した品質保証プロセスの構築と適用を進め、予定品質での製品リリースを進めてきた。しかし、リカーリングビジネスを支えるために必要なサポート部門の顧客からの問い合わせ結果を社内の体制面および問い合わせ分析のタイミングなどの問題から効率よく開発部門にフィードバックすることはそれほど想定できていなかった。顧客問い合わせの定期的分析を製造部門にフィードバックしても次期開発プロジェクト対応では顧客要望の反映に一年以上かかり、リカーリングビジネスにおいては損失につながる可能性がある。
顧客要望や指摘を迅速にパッチリリースや次期メンテナンスリリースに反映させる仕組みを検討し、品質保証プロセスと技術的な問い合わせの発生原因分析との連携が必須であるとため、品質保証プロセスとの連携が可能な問い合わせ分析のフィードバックプロセスの構築を進めた。この既存の品質保証プロセスとの連携および迅速な顧客要望へのフィードバックへの対応方法の紹介およびその効果について解説する。

概要

当社では利用時の品質の評価を実現するため、利用者用文書を活用した取り組みを行っている。SQIPシンポジウム2016で発表した内容であるマニュアルベーステストを行う時期や検証実施条件を考慮し、マニュアルベーステストで修正した内容が効果的かどうか検討した。なお、今回はマニュアルベーステスト技法を用いた評価の実施が可能かどうかの判断基準としてマニュアルユーザーテストを活用し、その結果からマニュアルベーステスト実施時の検証観点の考慮を行うこととする。
また、過去の評価結果に対し、当社サポート部門への問い合わせ分析による技法の効果測定を行った結果、問い合わせ数が減少しこれまでの施策が効果的だと考えられた。そこで、既存のマニュアル制作プロセスにマニュアルの品質保証を目的としたマニュアルベーステストとユーザーテストを組み込んだプロセスを構築し、適用することとした。「マニュアル評価ガイドライン」の評価観点と利用者文書の品質要求の品質特性とを紐付けしマニュアルの評価工程別に担保すべき品質の明確化し、プロセス改善を進めた。
今回は、当社が適用しているマニュアル制作プロセスの流れとマニュアル制作の一部を修正し、マニュアルベーステストとユーザーテストを適用し評価した結果を報告する。また、マニュアル制作プロセスでマニュアルの評価を行うことが、利用時の品質の向上に繋がることを定量的に示し、利用時の品質評価のためのマニュアルベーステスト技法の改良について解説する。

概要

製品の販売数増加に伴って、テクニカルサポートに対する問合せ数に大幅な増加傾向があり、製品に関する何らかの「品質」が低下していると考えられ、対策が急務となっていた。
そこでわれわれは「テクニカルサポート部門」という立場から、ISO/IEC 25010を参照し「品質」のモデル化と定義を行いテクニカルサポートへの問合せを分析して、品質低下の根元要因分析とフィードバック先を特定することとした。結果としては、ユーザは製品自体（ソフトウェア品質）ではなく、製品の「運用などを含む利用状況」（システム品質）に問題を感じていることがわかった。
さらに調査を進めると、根元問題としてシステム移行に関するマニュアルが存在していないことが分かった。ソフトウェア自体に関する文書品質には問題ないと考えていたが、運用部分を考慮した「システムとマニュアルの一貫性」が低いために問合せが多く発生していることが分析できた。

開発部門の考慮の中心は「ソフトウェア品質」に偏ることが多くなり、「利用時品質」や「システム品質」への考慮が不足して品質要求の漏れが生じる。そこで、「テクニカルサポート問合せ分析」を行う事によって利用者側の観点及び製品運用の観点を付与することができ、利用者を考慮した品質要求分析を行うことができると考える。本発表は、テクニカルサポート部門の活用によりシステム品質向上に効果が得られた事例の報告である。

概要

ウォーターフォール開発プロセスは、上流工程における成果物の完成度をできる限り高めることにより、当該工程以降に検出されたバグの修正による後戻り作業を低減するモデルといえる。そこで、品質管理部門では、上流工程の成果物の完成度の程度を測るための各種メトリクスを定義・運用して、品質上のリスクを見極める判断をしている。
筆者の組織では、プロセスメトリクスの一つであるレビュー工数の基準値を定め、レビュープロセスを確実に実行するように、組織的なプロセス標準を規程し品質管理を運用してきた。その結果、レビュー工数の増加と供に、出荷後のバグ数は減少し、一定の成果が得られたと考えられる。しかし、レビュー工数がある程度確保され、レビュープロセスが安定して実行されるようにプロセスが成熟した組織に対して、レビュー工数を軸にした品質管理だけでは品質リスクの見極めが難しくなってきた。
そこで、レビュー記録に着目し、レビュー記録のテキスト情報から得られるメトリクスについて設計品質に影響を与える要因を分析した。レビュー記録のテキスト情報から抽出したメトリクスには、バグの指摘率、レビュー指摘文の長さ、および、レビュー指摘文の述語の種類別の頻出度などである。
本発表では、これらの分析結果をもとにして、レビューにおける多角的な品質管理方法について提案する。

概要

レビュー会議において、時間通りに終わらない、軽微欠陥の検出に終始するなどの問題が発生し、参加者は効率よくレビューが行われていないと感じている。我々はこの問題が解決されない原因は以下の二つにあると考えた。

• レビュー会議の目的が曖昧になっている
• レビュー会議の実態を参加者が正確には把握していない

この二つの原因により、参加者はレビュー会議に不要な活動があり、効率よくレビューが行われていないと感じているのである。
そこで我々は、レビュー会議の目的が曖昧になっており、レビュー会議の実態を参加者が正確には把握していないことに起因する問題を解決する手法として、TMBRI(Time Measure Based Review Improvement)法を考えた。TMBRI法の特徴は下記の三つである。

• (1) レビュー会議の参加者全員で、各々が持つレビュー会議の目的を共有する
• (2) 発言内容毎の時間、発言者を可視化し、参加者全員で振り返る
• (3) 振り返りにより、レビュー会議の主体的な改善を促す

TMBRI法の効果を検証するため、実際のレビュー会議に対して試行したところ、レビュー会議の目的が曖昧になっていることを参加者が認識することができ、レビュー会議の改善策を導出できることがわかった。
本報告では、TMBRI法を用いたレビュー会議の可視化により目的の曖昧さを明確にする手法について詳細を述べる。

概要

ソフトウェア開発において、品質と生産性の向上は永遠の課題である。
弊社では、ソフトウェア開発を行っている組織から毎年プロジェクトデータを収集・蓄積し、組織横断的なデータ分析を行い、品質や生産性への影響要因を分析することにより、全社的な品質・生産性の改善活動に結びつけてきている。
今般、2015年度に終了した527件のプロジェクトデータを使用し、出荷後の品質状況、設計・製造工程のレビューにかけた工数、設計・製造工程の工数、テスト工程の工数、各工程の摘出バグ数等から、品質および生産性の関係を分析したところ、設計・製造工程でレビューに時間をかけて、より多くのバグを摘出するほど、出荷後の品質がよく、生産性もよいことがわかった。
本発表では、これらの分析結果を説明し、品質と生産性はトレードオフの関係ではなく、品質・生産性向上を両立させて改善できることを報告する。

概要

我々は、ウォーターフォールによる組込みシステム開発において「プロジェクト後半での不具合の顕在化による日程遅延とコスト増加」という問題を長らく抱えていた。当初はドキュメント作成やそのレビューの厳格化による解決を試みたが、投資に値する結果が得られることはなかった。その後、アジャイル導入による問題解決を試みたが、プロセスやプラクティスの真の目的を理解しないまま実践した為、その効果を得ることはできず問題解決には至らなかった。今回は、この反省に基づきプロセスの導入方法から根本的に見直した。既成のプロセスをそのまま導入するのではなく、現行プロセスの問題点を明確にした上でその問題を解決するために必要なプラクティスを選別し、さらにそのプラクティスをチームおよび開発対象の特性に合わせ最適化させながらプロセスを再構築した。例えばアジャイルプラクティスの中でもイテレーション開発／テスト自動化は技術面において非常に効果的であるが、ハードウェア開発との整合が必要な組み込みシステム開発においてはそのままでは導入が難しい。しかし、それらを組み込みシステム開発に最適化する工夫を施すことにより、実践が可能となりその効果を得ることができるようになった。
本試みの結果として、ハード結合工数の半減、システムテストのバグ件数の2/3削減および余裕をもった日程維持を実現することができ、長年の問題を解決することができた。

概要

Agile開発におけるチームマネージメント方法についてScrumが知られているが、導入に際して効果的に定着出来ていないプロジェクトが散見される。特に導入段階で躓くプロジェクトの多くに幾つかの共通点がある。形骸化されたロール定義による誤った責任分担。Scrumの原則を順守しないイテレーション開発の実施。その結果、プロダクトの品質が確保できず、Agilityが上がらないチーム開発になり、期待した結果を得られない事が多い。
原因は、Scrum自体が抽象度の高い開発プロセスである事がその一つだと考えている。実案件においては開発プロセスを補完するために従来型の開発方法の知見を利用する事になる。Agile開発の本質は、可能な限り早く顧客に価値を提供する事を優先する事だが、しかしながら適応した知見がAgile開発との相性が悪いと、効果が出るまでの障害となる事がある。この問題については、Agileに適した知見を共有する事で問題解決するのではないかと考えた。
本発表では、これからScrumを導入するプロジェクトに適した幾つかのプラクティスを示す。プラクティスを導入した実案件のプロダクトの品質の分析結果およびプロジェクトの課題を共有する。

概要

ホスティングシステムで実現していた企業顧客向けのプリンティングソリューションをクラウドに移行しました。
アーキテクチャー、プロセス、組織連携などを一から見直し、高いQCDの実現を目指しました。
APIコミュニケーション、CloudNative、自働化（テスト、デプロイ、監視）、DevOps、Microserviceの視点から組織、プロセスのあり方、その推進について紹介します。

概要

様々な分野でIoT（Internet of Things）への取り組みが盛んになっています。本セッションでは、スマートハウス/スマートオフィス/スマートシティ、スマートヘルスケア、エネルギーマネジメントシステム、IoTセンサーネットワークシステム、IoT/組込みセキュリティの各分野で活躍されている技術者の方をパネリストとして迎え、標準化や動向を紹介いただきます。標準化や動向を俯瞰した上で、品質において標準が担う役割をはじめいくつかのトピックで議論します。

概要

ソフトウェア開発において、レビューは品質確保のための重要な技術である。特に日本では、テストだけで品質を確保するのではなく、開発の早期からレビューを実施して品質を確保する取り組みが多くみられる。本論文では、レビュー技術の動向に焦点をあて、海外および日本のレビュー技術動向を調査した結果を解説する。調査対象は、レビューについて論じた日本および海外の論文、加えてWebサイトや書籍等である。
調査の結果、1990年代以降の海外のレビュー技術動向は、日本ではほとんど知られていないことがわかった。その代表例は、レビューの読み方の技術であるリーディング技法および最近注目されているモダンコードレビューである。一方、日本では新しい技法の提案というよりも、現行のレビュー方法の工夫によって効果を得る事例の提案が多いことがわかった。本論文では、これらの技術を具体的に紹介するとともに、海外と日本の技術動向の差異の背景にあるものを考察する。

概要

2015年から開始した当SIGでは、いまIT業界の一部で注目されているソフトウェア品質技術者試験、その学習を通じて、ソフトウェア品質の知識を習得し、かつ試験に必要なノウハウを学ぶことが目的です。本シンポジウムでは、当SIGでの勉強法や試験合格のためのノウハウや裏情報を一部公開し、それを有効活用していただいて、秋の試験に向かって走っていただきたいと思います。また、SQuBOKがVer1.0から2.0に上がり、試験にどのような影響がでたのかについても、（あくまでも私見ですが）少し触れていきます。

概要

毎月1回くらいのペースでソフトウェア品質に関する勉強会を開催しています。業種・業界を問わず誰でも参加できます。一方通行ではなくご自身の抱えている問題と対策を自由に話して、参加者から自由に意見をもらう交流会です。Ustreamでオンライン配信しているので遠隔地のかたも視聴できます。本セッションでは勉強会の最近の内容等についてご紹介させていただきます。自由な雰囲気を味わってください。年会費等のご負担はありません。興味のあるテーマの回にスポットの参加で大丈夫です。但し、一方的に聞くのではなく、一言でも良いので発言して頂くことをお願いしています。

概要

ソフトウェア欠陥混入の再発防止のためには、その原因を分析し、的確な対策を立てる必要がある。欠陥の標本とそれに付帯する情報をノウハウとして蓄積し、分析や対策の立案に役立てることができれば非常に有用である。
SQiP研究会欠陥エンジニアリングの分科会活動では欠陥発生のメカニズムを欠陥モデルとして表現し、原因分析をする研究を行ってきた。
この欠陥モデルについて、分科会参加者以外にもわかるよう手引書を作成している。
本手引書では、実際の社内事例を用いて分析を行い、原因を突き止めることが出来るようブラッシュアップを進めている。
本ポスターセッションでは、これらの取り組みとそこで得られたノウハウについて紹介する。

概要

こんなことはありませんか？
「いつも忙しい」「いくつものプロジェクトを抱え込んでいる」「終わったと思ったのにすぐ次の仕事が待っている」
これを解消するにはマネジメントの支援が不可欠です。
マネジメント層に現状が伝われば良いですが、必ずしもそうとは限りません。
今回、マネジメント層に対して現状をしっかり伝えるために、どこに真因があり、どの順に何をすればよいのかを決めるための手法を、ワークショップを通して体験していただきたいと思います。

対象

どなたでも参加いただけます。
「いつも忙しい！」と感じておられる方であれば、何かしら気づきを持ち帰っていただけると思います。

概要

プロジェクトの活動には何らかの新しい要素が存在するため、確実な進め方は存在しません。その先行き不透明さが不安につながり、不安の回避のため責任の押し付け合いのような状況に繋がってしまうことさえ有ります。
今回は、リスクを捉え、先行き不透明な状況でも改善を続けるための新しい「計画」と「ふりかえり」手法として、「未来予想型改善ワークショップ」を紹介します。
ワークショップでは、疑似プロジェクトとして「見積りが不確実なタスク」を模擬した「折り紙」を完了するミッションで実際に体験します。
将来の不安を取り除きながら改善及び成果に繋げるための方法を体験してみましょう。

対象

チームで活動している方であればどなたでも参加いただけます。

概要

不具合をどんどん見つけるレビューの能力は、一種の「技能」です。
であれば、レビュー能力を向上させるために、他の技能を上達させるための方法論や練習方法等を応用することができるのではないでしょうか？
本SIGでは、レビューに関する個人の能力の向上のためのアイディアを、他のさまざまな技能の上達方法を元にして、ワークショップ形式にて検討します。
ご参加のみなさまにたくさんのアイディアと気づきをお持ち帰り頂ければと思っています。

なお、レビューア特有の思考方法とその能力の鍛え方に関するSQiP研究会での研究、および研究会で考案したトレーニング法にご興味をお持ちの方は、SIG12にどうぞ。

対象

「日本語で書かれた文章についてレビューが出来る」能力をお持ちの方。
なお、何かの「技能」を身に着けていらっしゃる方であれば、なお良いです。

「上達の法則―効率のよい努力を科学する (PHP新書)」（岡本 浩一 著）を参考にしています。

概要

こういうことは、ありませんか？

• お客様から「この機能がたりない、これって当たり前でしょ」と言われた。お客様は当たり前だと思っているので打ち合わせで言う必要があると思ってなかった。
• 開発者が進捗会議で「順調です。問題ありません」でも、土壇場で、「実は、こんなことで困ってます」と言ってくる。困る予兆はあっても伝えてくれない。

いろんな場面で、困っていること、工夫したいこと、工夫していることを共有して、各自の課題の解決の一助になればと思います。

対象

どなたでも参加いただけます。
色々な立場からのご意見をお待ちしております。

概要

テストの説明責任を果たすためには、

1. ① テスト開始前
     テスト戦略を立案する      利害関係者の合意をとる
2. ② テスト実施中
     テスト結果（エビデンス）を記録する      テスト結果生成の進捗をモニタリングする   
3. ③ テスト実施後
     テスト結果を示す      不足があれば対策をとる      品質に対する確信を得る（assure）

の3ステップをとることが大切です。

本SIGでは、SIGリーダーがゴール指向の合意形成のための記法（GSN）の一種であるD-Caseを用いたテスト戦略立案のための5種類のテンプレートを提示し、SIG参加者は自身のテストの実態をリバースする形でテスト戦略を記述するワークを行います。

対象

どなたでも参加いただけます。
もし時間があればD-Caseのホームページ（http://www.dcase.jp/）を読んできてもらえると予習になります。

概要

品質にまつわる課題の中でよく聞くものに「活動が上手く行っているかわからない」「活動が成功したことを可視化できない」と言うような、活動と品質の関連性を上手く表現できないというようなことがあるかと思います。
私たちは外部のエンジニアとして、客観的な視点でそのような課題を見たときに、もしかしたら品質に対しての捉え方を変えることで救える現場があるのではないかと感じました。
これまで多くの品質に対する技法や手法、プロセスなどが議論されてきましたが、ここで今一度「品質とは何か」について議論する勝ちがあるのではないかと思いSIGへ提案させていただきました。

対象

絶対ではありませんが、下記のような方はぜひ。

• これから品質関連の活動に携わる予定
• 今品質に関わる活動をしていて「品質」の定義、計測、可視化のような部分で悩んでいる方

概要

昨年度、経験論文として発表したインタラクションデザイン（IxD）評価手法による定量化の実例を共有したいと考えています。
これを基に感性品質・UXの定量化に向けての悩み/成功や失敗の体験を共有し、皆様の取り組みの気づきに繋がるようにしたいと考えています。

対象

どなたでも参加いただけます。

概要

昨今、アジャイル・プラクティスを取り入れる組織も増えてきました。中でも振り返り手法KPTは特によく使われています。最初は、”いいね”って思って始めましたが、徐々にマンネリになっていませんか？

• 意見が出なくなってきた
• 発言が特定の人に偏っている
• 盛り上がらない、楽しくない
• やることが目的になっている感じがする

KPTは「小さい単位で繰り返し振り返る」が故に、マンネリ化しやすい特性があると思います。
「KPTをマンネリ化させず良さを引き出すには、どんな工夫ができるか」をみなさんと一緒に議論し、アイデアを共有したいと考えています。また、マンネリ化を防ぐ１つの工夫としてメタモデル手法を紹介します。

対象

どなたでも参加いただけます。
アジャイルのKPTに取り入れている方や、プロセスの形骸化・マンネリ化に困っている方は大歓迎です。

概要

プロジェクトの振り返りは、やり方次第で、次の一手を生み出すこともあれば、時間を掛けたわりに次に生かせなかったりします。
本SIGでは、皆さんの行っている振り返りでの工夫や、振り返りの課題やその解決策を話し合いま
しょう。
そして、プロセス改善、品質向上に活かせる振り返りのコツをお持ち帰りいただきたいと考えています。

対象

「効果的な振り返りをしたい方」、「効果的な振り返りをしている方」「プロセス改善に興味がある方」「品質向上に興味がある方」であれば、どなたでも歓迎いたします。

概要

成功体験を過信して、変化に対応できないことへの教訓として、「成功体験は捨てよう」という話を、よく聞きます。変化に対応するためには、成功体験を捨てるのではなく、問題の深掘りと同様に、成功の深掘りを行い、成功の水平展開とリサイクルをすることが、重要ではないでしょうか。人や組織の問題解決においても、問題が起きた時に焦点をあてるのではなく、問題が起きるような状況にもかかわらず、問題が起きなかった時に焦点をあてて問題解決を図る事が、迅速な問題解決に繋がると考えます。失敗の責任追及ではなく、実績を上げている成功の責任追及の方法をご紹介し、チーム力の向上について、みなさんと話し合いたいと思います。

対象

下記のような思いを、お持ちの方の参加をお待ちしています。

• 人や組織の強みにも、深掘りが必要だと思っている人
• 人や組織の問題を、ポジティブに解決したいと思っている人
• チーム力を、向上させたいと思っている人

概要

私たちのコミュニティでは、バグ票がうまく使われない事例やその調査結果、バグ票そのものを上手く活用するための改善等ついて検討やワークショップ等を行なってきました。(※詳細は、コミュニティのWebサイトを参照ください。)
今回のSIGでは、バグ票改善などに関する事例、検討結果やみなさまからいただいたご意見を共有したいと考えています。また、SIG参加者みなさまが直面しているバグ票に関わる「現状の困ったこと」、「既に困りごとが解決されたこと」を共有し、「気持ちの良い」バグ票コミュニケーションとは何かを考える対話ワークショップを行ないたいと思います。

対象

どなたでも参加可能ですが、特に以下のような方の参加をお待ちしております。

• 腹立たしいバグ票を読んだことがある、バグ票の記載で怒られたことがある方
• バグ票を活用できていない、形骸化していると感じる方
• バグ票の改善を検討したい方、今より活用したい方

開発者やテスト担当者だけでなく、マネジャーやプロセス改善担当者などいろいろな立場(ロール)の方々と議論したいと思います。
当日は、参加の皆様とバグ票の課題や悩みについて共有するワークを行なう予定です。自身が直面している問題・課題をいくつか準備ください。(非公開情報や機密事項、固有名詞などは含まないようお願いいたします。)密度の濃い議論ができ、改善のヒントが得られるかもしれません。

概要

2016年度のSQiP研究会で、レビューアが持つべき思考能力について研究し、その能力を鍛える方法を考案しました。
http://www.juse.jp/sqip/library/shousai/?id=248

本SIGでは、そのトレーニング法をご体験いただきます。
斬新な方法であるものの、シンプルで誰でも取り組める内容となっていますので、お気軽にご参加いただけます。
レビューア特有の思考方法とその能力の鍛え方、SQiP研究会で考案したトレーニング法に、ご興味をお持ちの方は、本SIG12にご参加ください。お待ちしております。

なお、レビュー能力の向上に関して、ご自身や他の参加者の体験を元に、何か新しい技能向上方法を考えてみたい人、参加者同士の意見交換を中心にしたい人は、SIG3にどうぞ。

対象

どなたでも参加いただけます。
「レビューをより良くしたい」
「レビューが上手くなりたい」
という気持ちをお持ちの方、ご参加をお待ちしております。

概要

システム開発文書品質研究会（ASDoQ）は、システム開発文書の品質の特性を様々な角度から分析、整理した「システム開発文書品質モデル Ver. 1.0 」（以下、文書品質モデルと略す）を発行しました。
本SIGでは、前半で文書品質モデルを紹介し、後半ではモデルを用いた開発文書の品質測定を実際に体験していただきます。
開発文書の品質を実際に測定することで文書品質を可視化してみませんか？
また、品質特性の傾向やより有効な測定方法などを一緒に討議してみませんか？
皆様のご参加をお待ちしています。

対象

開発文書の品質に対し問題や課題をお持ちの方、興味をお持ちの方であれば、どなたでも参加可能です。