紹介文 :
近年、システムの構成要素としてOSSの活用が増えている。OSSはソースコードが公開されているが、OSSのソースコードを解読しているとシステム構築に時間がかかるため、OSSの導入メリットがなくなってしまう。そのため、OSSはブラックボックスの状態で活用する場合が多い。
従来、システムの全体的な品質確保の目的で品質特性の利用や、重大障害防止のためにFTA(Fault Tree Analysis)やFMEA(Failure Mode and Effect Analysis)などのリスク分析手法を用いたテスト観点の導出を行っていた。
しかし、FTAやFMEAを適用するには、内部処理を詳細に知っておかないと効果的なテスト観点を導出することが難しく、OSS活用が増えてきた近年ではこれらのリスク分析手法の適用が難しくなってきている。
本発表では、機能間インタフェースに着目して安全性(ハザード)を解析する手法であるSTAMP/STPA(Systems-Theoretic Accident Model and Process/STAMP based Process Analysis)を、テスト観点導出に適用した事例について紹介する。
具体的には、OSSを活用したオンプレミスのシステムにおける、STAMP/STPAを適用した品質保証部のテスト観点の導出、およびそのテスト観点を用いたテスト結果について紹介する。

紹介文 :
当社では、本番障害の多くが上流工程の問題に起因しており、40％弱が外部設計工程での埋め込みとなっている。

主な埋め込み要因
・開発メンバー間で同じことをイメージできる状態まで設計内容を記載していない。
・検証可能性の観点からテストケースを導出できない。
・システム間で認識齟齬が発生し、誤った思い込みのまま開発を進めている。

そこで上流工程の問題に対する打ち手が、効率的・効果的な品質向上につながると考え、上流工程からの品質の作りこみを実現するために今年から工程完了判定を導入した。

当社では年間300弱の開発案件が立ち上がるが、レビューアとして参画できる品質マネジャーは2名というリソースの制約があった。
そのため、開発案件に対して、どのようにメリハリをつけて過不足のない品質保証活動を行うのかが最も重要なポイントとなり、そこで開発案件毎にリスクレベルを設定し、レベルに応じてレビュー度合いをテーラリングする仕組みを検討した。
また過去3年間の本番障害の内容を分析することで、外部設計書における欠陥の埋め込みを予防する観点を抽出し、過去の障害の再発予防を徹底した。
さらに今後はWモデルを適用することにより、外部設計書の欠陥を早期に検出できるよう品質の作りこみを強化していく。

同様の課題を抱えている参加者に対して、工程完了判定の導入で工夫した具体的内容とその導入効果を紹介する。

紹介文 :
ソフトウェア開発の定量的な品質管理では、プログラムコード行数あたりのバグ摘出数・テスト数といった指標を使うことが多い。昨今は業務パッケージソフトウェアの利用などでプログラムコードを直接書かないプロジェクトが増え、プログラムコード行数を用いた指標を利用することが難しくなってきている。また上限・下限値といった水準値を定めて指標値を評価するが、
統計的に意味のある類似したプロジェクトの情報の入手が前提となっている。昨今は技術の多様化が進んでいるため類似したプロジェクトを見つけるのが厳しくなっており、この点からもプログラムコード行数を用いた指標を利用することが難しい。そこで本論文ではテストプロセスを対象とした、プログラムコード行数を用いない品質分析技術を提案する。
また現代のビジネスにとってソフトウェアの重要性は増しており、 その開発を高速に行うことが市場に求められている 。迅速に提供できたとしても ソフトウェアの品質が悪ければ提供価値が下がるため品質管理の重要性は変わらない 。品質を保ちつつ品質管理にかかる作業は高速であることも求められている。プロジェクトでは次のフェーズに進んで良いか判断するために、各フェーズの終了時に品質を 確認するクオリティゲートを設定することがよくあるそのための品質報告 情報のとりまとめや、次のフェーズに進んで良いか判定している期間がソフトウェア開発を停滞させてしまうことがある 。この点に品質管理を高速にするための改善余地があると考え、解決するための手法を提案する。
定量的な品質管理は開発中に日々行うことが理想ではあるが、実現できているプロジェクトは多くはない。そこで日々の品質管理のために何を確認しているのかヒアリングを行った。 その結果、テスト観点に対してテストを網羅的に実施できているかと、すり抜けバグの 発生状況の確認を行っていることが多かった。この 2 つを定量的に確認できるような品質分析技術として整理し、無理なく品質管理を日々行うことで開発速度を落とさない品質管理 手法を策定した。
本論文では2 章で解決したい課題を明確にし、3章で改善策の提案を行い、4章で提案手法の適用結果を紹介し、 5 章で今後の展開を述べる

紹介文 :
ソフトウェア開発を成功に導くために、技術者の能力の均質化や底上げ、開発プロジェクト内での共通認識の醸成を目的として、開発標準などのドキュメントを作成している企業は非常に多い。しかし、ソフトウェア開発プロジェクトは複雑であるため、開発標準に記すべきノウハウは多岐にわたる。そのため開発標準が重厚長大なドキュメント群となってしまうことが多い。多くの技術者は多忙な開発の中で重厚長大な開発標準を読むこととなり、大変な苦労を感じている。結果として開発標準は技術者から「役に立たない」・「読みたくない」といった評価を受けることがある。また、ソフトウェア開発に関する技術やテクニックは、常に進化しており、開発標準も進化に追従していかなければない。しかし、重厚長大なドキュメントを修正するには、執筆やレビューの工数が負担となり、迅速な改善が難しい。その結果、開発標準に記されているノウハウが、時代遅れとなってしまうことも珍しくなく、技術者からの評価がより悪化してしまう。開発標準が、ユーザである技術者から見て魅力のないドキュメントとなってしまうと、目的であった技術者の能力向上や、共通認識の醸成がうまく進まず、ソフトウェア開発プロジェクトが失敗に終わってしまうことがある。そこで我々は、オープンソースソフトウェアの開発技術・文化を、組織などの閉じたコミュニティで実践するインナーソース開発のノウハウを、開発標準の作成に適用し、このような問題を解決した。本発表では、これらの経験に基づくノウハウや、考え方を紹介する。

紹介文 :
従来型のウォーターフォール開発では、工程ごとに次工程に移行するための品質チェック
の基準が設けられ、後戻りのないように上流工程から品質を 作り込んでいく。一方、アジ
ャイル開発などのイテレーティブな開発手法 では、ウォーターフォール開発において工程
ごとに実施されていた品質チェック が暗黙的となりやすく、欠陥の発見が遅れることがある。我々は、従来型 の工程ごとの品質チェックとは異なる観点で、アジャイル開発に適した構造化 された品質チェック項目を作成する方法を検討してきた。本発表では、その方法を実際のアジャイル開発プロジェクトに適用し、効果を確かめた結果を 報告する。アジャイル開発のプラクティスのインプット・アウトプット・ステークホルダー を整理し、マトリクス形式で品質チェック項目が構造化できることを確かめた。 その上で、品質チェック項目の効果を検証するため、過去に検出された欠陥の うち、品質チェック項目により早期検出可能な欠陥がどの程度あるか分析した。 分析の結果、実際に検出された時点よりも早期に検出できた可能性がある 欠陥があることが示され、当初の狙いを達成できていることが分かった。 さらに、早期に検出できた可能性のある 欠陥の多くが従来の要件定義のレビュー やテストケースのレビューに該当するチェック項目で検出できた可能性があることが分かり、対象としたアジャイル開発プロジェクトの改善点を見出すことができた。

紹介文 :
弊社において、大規模なサービスを過去10年以上にわたりウォーターフォールでプロダクト開発を進めていた中で、生産性の向上を目的として開発体制の一部でアジャイル開発を採用し、リーンアプローチを続けていた。しかし、その中でも小さいウォーターフォールのような体系は残ることが多く、各メンバー同士の役割も大きく変化することはなかった。結果、プロダクト開発に対する意識や理解のズレが発生し、QAメンバーのモチベーションや開発効率の低下に影響していた。そこで、QAが固定化された役割の中で動くのではなく、コミュニケーションをとりつつ全体の進捗に応じて緩やかな連携を行うことで、「生産性の向上」を図った。
　今回、新たなチーム作りにおいては、QAメンバーの役割の再定義(越境)と開発プロセスにおけるQAメンバーの立ち位置を変化させることに焦点を当てた。QAメンバーの役割を考え抜く中でプロジェクトにおける業務内容も変化し、モチベーションの向上やチーム全体の開発効率の最大化に繋げることに成功した。
　弊社のように長い間ウォーターフォールで取り組んできた大規模な開発現場では、アジャイルなどに取り組む際に、QAの役割は以前のやり方を踏襲することも多い。本発表では、その中でどのようにQAの役割を再定義したのか、新たな取り組みに対してデメリットやリスクを会話する中で最適な解を出せるように取り組んだ事例をご紹介します。

紹介文 :
　UI/UXが訴求ポイントの一つとなってから久しいが、業務システム開発の分野では、未だに単調で大量の画面と、大量のマニュアルを作り続けていることが多い。これは「業務システムの価値観」において「主要」はバックエンド処理であり、UI/UXは「コストオン」として、重要と認識しつつも優先度を下げて取り扱われてきたからである。「変化に柔軟に対応して価値向上を目指し続ける価値観」への転換が求められている昨今、「業務システムでもUI/UXの向上を」との意識は強まっているものの、十分な対応ができる技術者が少ないとの問題も出てきた。
　そこで、とある金融系業務システムにおいて「デザインシステム」を構築・運用することを始めた。「デザインシステム」とは、プロダクトやサービスのデザインに関する様々な情報を「言語化」「可視化」し、関係者間で共有できるようにしたものである。これまでも似たようなものに「UI標準」があったが、それと違うのは、プロダクトやサービスと乖離せずに一緒に成長していく仕組みまで含まれている点である。これによって、部品やレイアウトなどの一貫性・統一感といった「デザインメリット」が得られただけでなく、部品の再利用・柔軟性による「開発効率化メリット」、部品名で会話して素早く認識を合わせることができる「コミュニケーションメリット」が得られた。
　本発表では、構築した「デザインシステム」の概要とそこから得られた効果を紹介する。

紹介文 :
　レガシーシステムで培ってきた品質を確保するための開発ノウハウは、デジタル化の潮流など新しい技術が注目される現在も重要と考え、品質管理部門は、障害報告書を活用した開発ノウハウ可視化に取り組んでいる。この取組みは「経験不足を補う良い活動」といった声がある一方で、開発ノウハウ可視化作業は経験のあるベテラン社員が相応の工数を要して作成することから、開発ノウハウ数がなかなか伸びないという問題がある。また、開発ノウハウへのアクセスが少なく活用度が低いという問題もある（テキストで公開しているため検索できないという背景もあり）。
　これら問題に対して、AI（機械学習）を利用した文書検索エンジンで解決できないか、試作品を開発し効果検証した。問題解決のアプローチは、可視化数がなかなか伸びない問題に対しては、開発ノウハウで紹介している障害事例と、同水準の件数とバリエーションの障害報告書を文書検索エンジンで検索できれば、障害の注意喚起機能を代替できると考えた。ノウハウへのアクセスが少ない問題に対しては、ネット検索のような利便性の高い検索エンジンを作ることができれば開発ノウハウへのアクセス数が伸びると考えた。本プログラムでは、効果検証の結果、文書検索エンジンの開発で苦労／工夫したことを紹介する。

紹介文 :
ソフトウェア開発時に、以前の類似システムのときと同じ原因の不具合を混入させないようにする、再発防止は十分に実施できているでしょうか？ 開発現場で再発防止策を定着させることは実際にはなかなか容易ではなく、以前の類似システムと同じような問題が繰り返し発生してしまうケースが少なからずあります。
この論文では、再発防止策の定着に有効な要素が何であるかを特定するため、ソフトウェア開発者が再発防止策を実施するときのモチベーションやヒューマンファクターに着目して調査・分析しています。また、分析結果から、再発防止策の定着に結び付ける展開・伝達手法として、どのようなアプローチを用いるとより有効となるのか(「あつ森法」)を提案しています。

紹介文 :
ドメイン知識の共有は多くのチームで重要な課題となっている。我々のプロジェクトでも 以下の状況が
見受けられ ドメイン知識が共有できている状態にする必要があった。
・情報を見つけるのに時間がかかった
・見ていた情報が誤っていた
・知らない情報があり失敗した
・同じような質問を何度もされ回答が面倒
分析の結果、ドメイン知識を共有する活動を継続的に行うためには 以下の 問題を解決する必要があると考えた。
・知識提供者には、知識利用者から必要とされるドメイン知識がわからない
・知識提供者には、ナレッジ DB へのドメイン知識の登録を妨げる 時間 的 制約 と 心理的障壁がある
本研究では知識共有を妨げる問題を解決するために 先行研究を参考に、知識共有を妨げる要因を解消できる「ナレッジスタッフを中心としたニーズ駆動知識共有アプローチ」を考案した ま た 考案したアプローチをもとに、ドメイン知識共有システム を 構築 し た
構築したシステムを 1 年間運用し Wiki が継続的に更新・参照され 知識利用者から必要とされるドメイン知識が Wiki に登録され続ける状態が維持できることを確認した。
考案したアプローチとシステムにより ドメイン知識を共有する活動が継続し ソフトウェア開発の効率
向上と品質安定化に繋がる効果が期待できる

紹介文 :
ソフトウェアの設計レビューで指摘できた不具合の発生原因を集め、うまく傾向を分類・分析し、原因の傾向に合わせて適切な対策を実施できているでしょうか？ 実際には傾向分析の入力である、分類した原因区分に誤りが割と多く、傾向分析の結果が不正確で、適切な対策になっていないことが起こりがちです。このため、下流工程のテストでも設計時と類似した原因による不具合が残っていることも少なくありません。
そこで、この論文では、品質管理責任者が原因区分の誤りの程度を判断して傾向分析の“確からしさ”を判断でき、そしてレビュー指摘を受けたレビューイも原因区分の誤りを是正できるような、設計レビューでの不具合の原因区分を明確にする仕組みを研究し、「ARCメソッド(Ascertain the Roots Cause method)」手法を提案しています。

紹介文 :
ている。このことは、開発から納品までの工期が短い「短納期型開発プロジェクト」でも同様であり、短い工期中に発生するテストの手戻りは大きな負担になる問題がある。我々はこの問題の解決策として、FaRSeT（Flexible and Rapid Software Test）というテスト手法を提案し、SQiPシンポジウム2018にて発表した。
FaRSeTを用いた探索的テストにより、事前にテストケースを準備する必要がなくなり、仕様変更が多い部分の手戻りを解消することができた。また、重要な探索箇所についてステークホルダの合意を得ながら優先して探索的テストを実施できるようになり、テストの効率化を図ることもできた。
しかしながら、以下2点の問題点が浮き彫りとなった。
? 未実施のテストは不具合が発生していないため、重要な探索箇所として判断できない。
? 不具合数だけでは、残存不具合を想定することができない。
これらの問題点により、重要な探索箇所を判断するための根拠が欠けるため、ステークホルダに探索箇所の合意を得る際の障害になっている。
そこで本研究では、これらの問題点を解決するために、重要な探索箇所を推測し、それを提示する手法「FaRSeT-#（ファルセットシャープ）」を提案する。重要な探索箇所を判断するための手法として、機械学習の1つである自己組織化マップ（Self-Organizing Maps）を利用し、セッションを二次元マップ上に可視化し提示する。

紹介文 :
リモートワーク環境下での開発における品質／生産性向上を目的として、「リモート開発におけるレビュー改善方法」を提案しています。
「リモート開発におけるレビュー改善の手順」がわかりやすく、具体的に示されており、「レビュー成功要因関連図」や「レビュー改善Tips」も具体的で実践的な内容が紹介されています。

紹介文 :
　既存の欠陥分析方法には信頼度成長モデルと根本原因分析がある。信頼度成長モデルは欠陥数の積算をグラフ化し収束状況を観察する。欠陥はすべて平等にカウントされるが、開発者は重要な欠陥とそうでない欠陥があることを知っている。一方、根本原因分析は一件々々、欠陥の原因の原因を突き止めるので分析に膨大な手間がかかる。また、同様の欠陥が他にないことを示すことは非常に困難である。
そこで、Ram Chillarege氏は欠陥の開発プロセスに対する意味合いを分析できるODCをIBM社において1992年発表した。彼が示した方法論は、ソフトウェア開発に適用できる方法論である。日本の電機メーカーの製品多くは、ハードウェアとソフトウェアから成っている。ソフトウェア開発において、開発終盤ハードウェア開発チームからの設計変更依頼は、ソフトウェア開発に多大な影響を与えるが、ソフトウェア開発チームは、依頼を受けざるを得ない状況が多々ある。ソフトウェア開発で活用しているODC分析をハードウェア開発に水平展開し、開発終盤の設計変更を少しでも減らせないか、というアイデアがこの論文のテーマである。

紹介文 :
東芝グループでは、SEPG（Software Engineering Process Group）とSQAG（Software Quality
Assurance Group）の両輪にて開発部隊を支える体制で、長期戦略のもとSPI（Software Process
Improvement）活動を推進している。報告者はコーポレートSEPG に所属し、部門のSEPG やSQAG
と連携しながら活動している。本報告では、”組織の成熟度”と”SQAG の成長”の2 軸からなる
「SQAG 進化チャート」と呼ばれる活動の参照モデルを用いて、SQAG の活動を段階的に取り組む際
の問題点とその解決方法を、事例を交えて紹介する。

紹介文 :
自動運転は社会的期待が大きい技術だが、安全性において多くの課題を抱えている。その解決のために実際に起きた事故から学ぶことは重要である。
本研究は2018年3月に米国アリゾナ州で発生したUberの自動運転システムの人身事故報告書をSTAMPモデルを用いた事故分析手法CAST(Casual Analysis using System Theory)とハザード分析手法STPA（System-Theoretic Process Analysis)とレジリエンスエンジニアの機能共鳴手法FRAM の3つの分析手法を用いて改めて分析したものである。さらに新たに社会、組織、人を含んだシステム全体を捉えるために5階層モデルの考え方を適応することを試みた。いずれも大変新規性の高い取り組みである。
論文とともに具体的な分析の一連の証跡、分析手順、結果など、利用価値の高い付録も収録しているので、ぜひ活用してほしい。

紹介文 :
日本情報システム・ユーザー協会（JUAS）の年次レポート「企業IT 動向調査」によると、日
本企業のIT 予算は8 割が現行ビジネスの維持に使われている。ここ数年「現行ビジネス維持8 割：
新規2 割」の状況が続いており、システム維持管理費の高止まりが経営課題解決に向けたIT 投資
の阻害要因のひとつとなっている。
このような課題を解決すべく当社では『システムカルテ診断支援サービス』を実施している。
本サービスは、稼働中の全システムを対象に保守作業の生産性を検証しシステム保守費の適正化
による投資余力の創出を支援するものである。同サービス導入により得た知見を発表したい。
本論文が日本におけるIT コスト構造変革の一助になれば幸いである。

紹介文 :
FMEA（故障モードと影響解析）は、システムにおいて発生する故障を識別し、その影響の致命度に基づく相対的な評価等を通して、故障に対する対策を検討する手法である。JAXAでは、FMEAを行うことでミッションの達成に影響がある故障モードを識別している。故障モードを識別するためには、システムやソフトウェア（以下、SWという）の故障発想の支援が必要である。その方法には、失敗経験等の過去知見の活用、ガイドワードの活用、分析アイテムの具体化の3つと言われている。特に失敗経験として過去の不具合情報は、事象や原因、その発生メカニズムが適切に記録されている場合、システムの特性を捉えた固有の故障モードを作成することに有効である。
一方、JAXAでは、SWやシステムの論理に関するFMEAとして、上記の3つの支援をもとに導出した故障モードとその導出経緯をGoal Structuring Notation（以下、GSNという）形式で蓄積しているが、蓄積されたGSN形式の成果物を知見として十分に活用されていないという問題がある。製品固有の故障モードを抽出するためには、分析者が過去の情報を解釈し、自身の製品の問題に落とし込むことが必要となるが、過去の情報は、類似製品開発を経験した分析者の経験や知見を有する者が参照することが前提となった情報であることが多く、過去知見の参照は極めて属人的となるためである。
そこでJAXAでは、過去FMEA活動を通して蓄積された過去の知見（故障モードとその故障モード導出時に着目した仕様情報）の検索を通して、故障発想を支援する方法を検討した。本稿では、情報検索を使った故障発想への支援を目的とした、情報検索方法や学習データ作成方法、検索結果の反映方法を提案する。

紹介文 :
ソフトウェアテストチームがテスト活動に取り組む上で、リーダーから指示を受けるメンバーに受動的な行動が多い場合は、リーダーの管理工数が増加する傾向がある。管理工数を抑えるには、能動的な行動が求められるため、受動的なメンバーに対して能動的になるように育成する必要がある。

育成のポイントを明確にするため、リーダーの行動に着目した。リーダーは能動的な活動ができていると仮定し、メンバーの行動との差を抽出した。
理想的な行動はコンピテンシーモデルを参考に、そこから抽出した特性を基にアンケートを実施し、165名から回答を得た。その結果、受動的なメンバーを効率よく育成するためには、「課題分析能力」と「当事者意識」が重要なポイントであることが分かった。

これらを向上させるため、「CLDAT Method：'Causal Loop Diagram for Active Test engineers' Method」手法を考案した。
はじめに「課題分析能力」と「当事者意識」を阻害している要因に着目した因果関係を示した図を準備した。それを元に阻害している要因を特定、取り除くことで、メンバーの行動を変え、潜在的に持っているソフトスキルを引き出し成長させることを狙った。
実際にCLDAT Methodを活用し、短期間で効果を得ることができたので、その活用方法を紹介する。

紹介文 :
ウォーターフォール型ソフトウェア開発は前工程を終えたのちに後工程を開始し、後戻りすることなく逐次的に進めるものとして一般に 認識されている。しかしウォーターフォールモデルにおいて隣り合う2工程の間には双方向の関係がありこの関係のためそれらの工程は部分的に並行して実施され得る。筆者らの経験においてもウォーターフォール型ソフトウェア開発の日程計画において工程間に重なりを持たせることはしばしば行われている 。ウォーターフォール型ソフトウェア開発は工程が逐次的に進められることが基本ではあるものの、工程間に重なりを持たせた日程計画を立てることは一般的なことであるといえる 。工程間に重なりを持たせることにはメリットとデメリットの両面がある。工程を重ねることで作業を並行して実施することができ、開発期間を短縮できたり次工程の作業者の手持ち時間を減らせたりできるなどのメリットが 得られ る。これにより、プロジェクトの利益率向上が期待される。一方で過度に工程を重ねてしまうと前工程で生じた変更が次工程またはそれ以降の工程での後戻り作業を増やすことになり計画時に比べて品質やコストに悪影響を及ぼしてしまう。これにより、プロジェクトの利益率が悪化するリスクが高くなってしまう 。工程間の重なりに関する検討は、これまでシミュレーション研究として扱われたり、並行ソフトウェア開発などのプロセスモデルとして論じられたりしてきた 。しかし、ウォーターフォール型ソフトウェア開発における工程の重なりがプロジェクトの利益率にどのような影響を与えるのかについての実証的な取り組みは筆者らが知る限り十分に示されていない 。アジャイル開発が広がりを見せている一方で、 ウォーターフォール型ソフトウェア開発は依然として広く利用されておりそれを適用することが望ましい場合や顧客都合などの理由によりそれを適用せざるを得ない場合もある。ウォーターフォール型ソフトウェア開発における工程間の重なりと利益率の関係に関する知見を実証的に導き出し、開発現場へと適用することは意義ある取り組みであると筆者らは考えている 。
本論文ではウォーターフォール型ソフトウェア開発プロジェクトを対象に収集したデータを基に工程の重なりと利益率との関係について分析を行う。 工程の重なりにはメリットとデメリットの両面があり重なりの度合いは利益率に何らかの関係がある可能性がある 。また、工程を個別に見たときにどの工程とどの工程の重なりが利益率と関わりがあるのかについて掘り下げて検討する必要がある。 さらに、品質メトリクスを含めて総合的に捉えたときに、利益率に関わる要因同士の構造が明らかになれば、プロジェクトの日程計画を立案する上で有益な知見が得られるものと期待できる 。そのため本研究では次のResearch Questionsを設定する。
RQ1プロジェクト全体で見た工程の重なりと利益率との間には、どのような関係があるのか。
RQ2：工程の重なりを個別に見たときに、利益率と関わりのある工程はどれか 。
RQ3 工程の重なりと品質メトリクスを用いて、利益率を説明することはできるか。
2章では分析対象について述べたのちに 、分析に用いた変数である工程の重なり、利益率予実差、および品質メトリクスについて、それぞれの概要とデータの概要を示す。 3章ではRQ1からRQ3についての分析結果を示す。 4章で考察を述べ、最後に5章でまとめを述べる。