紹介文 :
自社内での改善を進めていくと、開発現場での最終的な改善の目標は、いかに顧客の要求を早い段階で適切に引出して共有できるか、即ち“要求仕様の早期明確化”となる。然しながら、プロジェクトが進み仕様が詳細化されるに連れて、仕様齟齬が発生するケースが数多くみられる。アジャイル手法による反復開発の導入は解決策の一つだが、ウォーターフォール開発で経験を積んできたプロジェクトチーム全体がすぐに導入するのは難しい。そこで開発中に、仕様齟齬が大きくなり始めた開発対象機能の発生を把握して抽出し、そのような機能に限定して、テストシナリオの先行作成、プロトタイプ開発や先行開発など、部分的な反復開発を導入して対処する手段を提案している。 このため本研究では、仕様齟齬の予兆を、顧客と開発チームの特徴に関する「開発の特性」と仕様変更に関する「メトリクス」をモニタリングして察知し、「対処パターンと判断基準」を活用してプロジェクト進行中に部分的に開発プロセスを変更させていく、仕様齟齬の早期解決手段を提案し体系化した。 顧客との仕様整合の完成度は、その後のプロジェクト進捗に大きな影響を与えるが、本テーマは、“要求仕様の早期明確化”を支援する有用な一方策を提供する。

紹介文 :
アジャイル開発の品質保証における製品品質を評価プロセスの改善提案である。開発途中にプロセスゲートという評価マイルストンをおいて品質をみえる化し、それを積み上げていくことで、製品品質の品質保証のための評価法を提案している。

紹介文 :
工程毎に分業化された複数のグループで同時並行で行われる小規模な派生開発における進捗管理の課題に対して「機能-作業マトリクス」という簡潔な進捗管理方法を提案している。「機能-作業マトリクス」では、進捗管理時に課題となりやすい計画立案、進捗情報入力、対策立案に対して属人的な計画にならず進捗管理負荷が軽減されるように工夫されているのが特徴で、ガントチャートのように専用ソフトウェアがなくても管理可能な点が負荷軽減の一助になっていると思われます。

紹介文 :
XDDPとSCRUMを組み合わせることにより、①後戻りに関する課題(終盤でのH/W変更リスク)、②人とチームが成長するチームビルディング、③ソフトウェアのリリースタイミングといった課題を解決した事例です。プロジェクトメンバへのアンケート結果もあり、現場からの声も一部紹介されています。

紹介文 :
派生開発では機能の変更が中心であり、変更後のテストでも機能のデグレードに目が行きがちで、操作性や使い勝手が変化していることに気づくことは少なく、リリース後に「使いづらくなった」といったクレームが入ることがある。 また、操作に関連した変更の場合も、求められている操作性については確認するが、まったく意識していないところで影響がでることがある。 変更時に参照する機能仕様書や操作仕様書には、ユーザビリティについて詳しく書かれていないが、テストケースには、いろいろなケースが扱われている。 そこで、変更で影響を受けやすいユーザビリティの観点と関連するテストケースを組み合わせて「振る舞いbefore/afterシート」を作ることで、変更に伴うユーザビリティの影響に気づく方法を提供している。 この方法は、普段からテストケースを充実させておくことで対応しやすくなる。

紹介文 :
本論文では、派生開発において高リスクな不具合を早期に検出しやすくするため、従来のリスクベースドテストよりも軽量なテスト手法を提案している。 具体的には、新旧ソフトウェア間における機能群単位でのテストケース数の変化割合および不具合の検出数からテスト実施の優先度を付ける手法（LightTest-Prioritization Method，LTP-Method）である。これらの情報はプロジェクト情報として揃う情報であるため、テスト実施のために新規で揃える必要がない。これらの情報を説明変数として重回帰分析を行い、高リスク不具合の潜在期待値を機能群ごとに導き出すことで、テスト実施の優先度をつける。 本手法は従来のリスクベースドテストよりも導入しやすくなるため、高リスクな不具合を早期に検出できることが見込まれる。

紹介文 :
開発チームがアジャイル開発のフレームワークを取り入れようとしたとき、従来、QAを行っていたチームはそれにどのように対応していけばよいだろうか。従来のやり方、考え方では、現場レベルでうまくかみ合わないことが多い。本論文は、現場レベルでどのようにやり方、考え方を変えていけばよいか、その対応のガイドラインを提案している。

紹介文 :
一般に、派生開発では機能の追加と変更が中心になる。その結果、応答時間などに変化が生じることがある。設計の担当者は応答時間の変化に気づかなかったり、気づいていた時でも、これくらいなら問題ないだろうと勝手に決め込んだりしていることが多く、納品後に「時間効率性」の劣化としてクレームとなる場合がある。時間効率性に関するクレームは、必ずしも遅くなったから問題になるとは限らない。派生開発の場合、使い慣れている状況に対して変化が許容範囲を超えると操作に影響を与えるからである。 設計者が応答時間等の劣化に気づかない理由として、ソースコードの該当箇所を探す際も、機能の変更に気を取られ、その機能が操作と絡んでいることに気がついていないことがある。そこで、変更要求を捉える段階で、メモリー処理や通信処理などの時間効率性に影響を与えそうな機能を変更するときには、時間の変化を予測して、「EMOT(Estimation Method Of Time behavior degradation)」の確認表を使って変化時間の目安を確認する。そこで事前に想定している許容範囲を超える時は、早めに依頼者と変更方法などを協議する。また他に変更方法がない時は、操作側で事前にトレーニングして備えてもらうことになる。こうした対応によって、後からのクレームになることを回避する。

紹介文 :
本論文では、派生開発での回帰テストにおいて、デグレード不具合を効率よく検知するため、テストケースにソフトウェア変更の影響範囲を基にしたスコア付けを行い、テスト実施するテストケースの選定手法を提案している。 具体的には、データフロー図(Data Flow Diagram, DFD)を用いてデータフローを介して繋がる機能数を機能ごとに計測し、その数を基にスコア付けを行い、スコアの高い順から優先的にテストケースを選定する手法である。 この手法により、変更後の機能からの影響を受けやすい機能をスコアとして表すことができる。そして、スコアが高い機能を優先的かつ重点的にテストを行うようにテストケースを選定することで、デグレード不具合を検知しやすくなることが見込まれる。

紹介文 :
派生開発において、変更要求を実現した結果、当初の”設計制約”が変わることがあります。このような、本来の変更に付随して発生する”前提条件の変更”は見つけにくいものです。本研究では、これを”欠陥混入メカニズムの知識”を活用して把握しようというものです。

紹介文 :
アジャイルは、顧客に価値を提供していく成果物を開発することを目標としているが、顧客が本当に求めている要求をとらえられず、価値の低い製品をデリバリーすることがしばしばある。それは、アジャイル開発における要求を表しているバックログ自身に問題があることも多い。本論文は、その課題に焦点を当てて、顧客の価値を考えたバックログを作るプロセスを提案している。

紹介文 :
セキュリティ対策など、優先度の高い対応をスピーディに行う場面では、使用性への配慮が不足しがちです。その結果、業務効率を悪化させることが開発終盤や納品後に判明し、手戻りの要因となっています。このような問題を、顧客のビジネスリソース(作業分担，システム連携，作業自動化の程度など）の違いに着目し、解決しようとしています。チェックリストで注意を促す古典的なやり方との違いは、顧客と自社のビジネスが両立する仕様決定を促す点です。

紹介文 :
ソフトウェア開発チームは、その開発活動において、いろいろなストレスを受ける。例えば、ある知見を持ったチームメンバーが突然移動になるなどは、チームの活動にに大きなインパクトがある。いったんそのインパクトを受け止めて、そのダメージから回復していく力をレジリエンスと呼ぶ。アジャイル開発では、その@プラクティスにおいて、数々のストレスを認識し、それに対するレジリエンスを持つ気づきを与えてくれる。この論文は、アジャイル開発のプラクティスとレジリエンスに関係性があることを仮説して、実際のチームを調査し、アジャイルプラクティスをうまく行うチームは、レジリエンスが高い傾向にあることを示した。

紹介文 :
コロナ禍によって研究活動自体がオンライン実施となったことを逆手にとって、完全オンライン環境でUXデザイン手法の実践に取り組んだ経験論文です。 UXデザインだけでなく、オンライン環境でのコミュニケーション実施例としても、とても参考になります。