紹介文 :
近年、システムの構成要素として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 章で今後の展開を述べる

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

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

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

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

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

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

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

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

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

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

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

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

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

紹介文 :
　現代社会は、従来のモノの提供を通じて価値を実現するビジネスから、コトとしてサービスを提供するビジネスモデルへ大きく変化を遂げており、IoTやAIなどの先進技術を組み合わせたシステムが本格的に活用され始めている。システムの重要性が増す一方で、システム障害や事故が発生した場合、原因は個々の構成要素の故障に留まらず、構成要素間や、システムと人間との間の複雑な相互作用、さらには悪意を持ったサイバー攻撃に起因することがあり、原因究明が困難になりつつある。本稿では、セーフティとは、偶発的なミス、故障などの悪意のない危険に対する安全を示し、セキュリティとは、悪意をもって行われる脅威に対しての安全を示すものとする。
従来の事故モデルを前提とした事故分析手法では、先入観や偏見による影響や偏りがあり、人への非難が発生し、建設的な議論とならないことに陥りやすい。事故モデルは、セーフティ分野の考え方なのでそのままセキュリティ分野に適用することが難しい。
　複雑なシステムのセーフティを扱う新しい理論として、システム理論に基づく事故モデルSTAMP（System-Theoretic Accident Model and Processes）や、レジリエンス・エンジニアリングに基づく安全分析手法FRAM（Functional Resonance Analysis Method 機能共鳴分析手法 ）が提唱されている。しかし、国内では分析事例の少なさもあいまって、事故分析への適用は普及していない。また、システム開発段階のリスク分析においてセーフティとセキュリティを統合的に扱う手法が提案されているが、事故分析においては両分野を別々に実施しているのが現状である。以上のことより我々
は 、IoTやAI、人間といった構成要素を含む複雑なシステムに対し、セーフティとセキュリティを垣根なく分析できる、新たな事故分析手法が必要となると考えた。
本稿では、報告書として公開されているセキュリティ事故事例を対象に、STAMPに基づく事故分析手法CAST（Casual Analysis using System Theory）および、FRAMによる事故分析を行った。CASTおよびFRAMはセーフティ分野の分析手法であるが、人間を含むシステムや機能間の相互作用に着目して事故要因／成功要因を分析するという特徴に着目し、セキュリティ事故の分析に適用できることを示す。また、分析結果をもとに、各分析手法のメリットとデメリットを整理し、各分析手法の有効性を示す。

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

紹介文 :
昨今のデジタルトランスフォーメーションへの期待からプロダクトを用いて新しい価値を市場やユーザーに提供する活動が 急増 している 。 その一方で 、 プロダクト開発での Agile 開発に適した 人材確保に多くの企業が苦戦をしており 、 Agile 人材育成に対するニーズが高まっている 本内容 ではデジタルトランスフォーメーションを加速させる Agile 人材育成について高い学習効果を出すための方法や知見について報告する 。

紹介文 :
1 背景
ソフトウェアの品質向上のためにレビューは有効な手段として認められており、必須の活動として取り組まれている。また、同じく品質向上の取り組みとして、多くの企業で各工程やスプリント、プロジェクト終了時などに開発全般に関しての振り返りが行われる。
しかし、振り返りは一般的に、システム開発プロセスやプロジェクト管理の観点に注目が集まることが多く、レビューの実施方法に踏み込んだ振り返りが行われることは比較的少ない。
筆者らは、開発現場で成果物品質が上がらないのは、振り返り活動がレビュー品質の改善に繋がっていないことに一因があると考えた。そこで、個々の現場におけるレビューの質を向上させるために、レビューの振り返り手法を検討することにした。
2 解決すべき課題
振り返り手法には、KPT やYWT などのいくつかのフレームワークがある。しかし、これらは、活動内容を思い出しながら振り返ることが一般的である。多くは、参加者の主観的な記憶を頼りに行われることになるため、振り返りの観点に漏れや偏りが発生しやすい。
これは、改善の機会を逸しやすい状況にあることを示唆している。
次に、会議で自由に発言するような振り返り手法を用いた場合、声が大きい人の意見にその場の議論が引きずられるため、他の参加者が本音を言えないことがしばしば起こる。
特に作成者とレビューアでは上下関係がある場合が多いため、作成者が意見を言いにくいことも多い。ここにも、改善の機会を逸しやすい状況が存在している。
上記の課題に対して、筆者らは以下の2 点を満たす振り返り手法を考案することができれば、レビュー品質の改善に効果の高い振り返りが実施可能になるのではないかと考えた。
・ 事実に基づく客観的な振り返りを実施するための具体的な手順・ 役割・立場が異なる参加者全員から意見を引き出すための具体的な手順これらを踏まえて、本研究では以下を解決すべき課題として設定する。
RQ1：事実に基づく客観的な振り返りによって、重要な振り返り項目が導出できるか？
RQ2：役割・立場が異なる参加者全員から意見を引き出せれば、改善の観点が広がるか？
RQ3：提案手法を用いて、レビュー品質や成果物品質が向上するか？
以降、2 章では先行研究の調査結果を示し、3 章では筆者らが提案する振り返り手法を示す。4 章で提案手法に対する実験と評価考察を行い、5 章でまとめを示す。

紹介文 :
IT開発にかかわる組織では、組織や製品の特徴、顧客との関係性などから定めた「レビュー実施方法」、あるいは過去の経緯などから独自の工夫 を行った「組織で定着しているレビュー実施方法」に基づき、レビューを行っている。しかし場面によっては、レビューの長時間化、論点の拡散、欲しい効果の未獲得、作成者の疲弊などの問題が生じている。そして組織で定めたレビュー実施方法に従うことを重要視する あるいは慣れ親しんだレビュー実施方法を変更することへの障壁から、場面に応じてレビューの実施方法を変えることができないという問題がある。 この問題を解決するために我々は、レビューにて得たい効果に応じた「 レビューの実施方法 」、つまりは「レビューの活動要素」を最適化する「オプティマイズ・ レビュー ・ マップ法 」を考案した。 簡易実験とアンケート調査により、本手法の有効性を確認することができた。