紹介文 :
本研究は、品質保証メンバーが客観的役割を基本としつつ、品質保証活動より得られた知見を活かして、開発プロジェクトに積極的に寄り添ってQCD 問題解決を促進する活動の提案である。 調査分析から、開発プロジェクトが品質保証メンバーに期待する支援範囲を抽出し実践した、大変有用性の高い研究である。

紹介文 :
メカトロニクスの分野では、新規開発の比率が高まりつつあり、不確実性が高いことが問題になっています。 本発表では、反復開発プロセスを適用する際の課題を整理したうえで、スクラムやTDDといったプラクティスの導入、CIの適用など、具体的な解決策を整理しています。ソフトウェアとハードウェアでチームが分かれているという特性から、スクラムを修正して適用しており、導入しやすい形にしているのが特徴です。

紹介文 :
派生開発では新規開発時の作りの悪さや、その後の派生開発での変更作業によってソースコードの劣化が進んでいることが多く、変更ミスを引き起こす要因になっている。ソースコードの劣化を改善する方法としてリファクタリングがあるが、仕様の変更作業の中で、”良かれ“と思って、担当者の判断で安易に構造を変えてしまったり、無造作にリファクタリングにとりかかったりすることでかえって事態を悪化させることが多い。 XDDPでは、仕様変更の中でソースコードの劣化を和らげるために、当該関数に限定した「小さなリファクタリング」を許しているが、これだけでは足りない。 そこで、XDDPを応用してリファクタリングに特化した派生開発プロセスとして「R-XDDP」という方法を提案し、リファクタリング・パターンを限定しながら、混乱することなくリファクタリングに取り掛かる方法を勧めている。

紹介文 :
品質の向上とは、究極的には顧客満足度の向上であり、そのためには、組織全体を、顧客に対する新しい価値を創造し、積極的に提案する顧客価値経営に到達させることが必要である。本論文は、「日本経営品質賞」のフレームワークをベースに、顧客価値経営到達への道筋を、具体的改善項目の実施度合により示しており、アセスメントと改善の繰り返しにより組織レベルを向上させることができる点が、有益かつ実践的である。

紹介文 :
製品知識や開発情報・技術のノウハウは特定の担当者によって異なるが、偏りが進み過ぎると、伝達すべき情報や技術が継承されず，製品を改造・流用する際に製品仕様や設計、実装時の検討漏れや誤りなどの原因となって問題を引き起こす場合が多い。 　本テーマは、この“いわゆる属人化状態”の分析に焦点を当て、プロジェクトチーム内の担当者同士による技術面での個人依存度の主観的な相互評価の値と、レビュー実施時の各担当者別の発言時間という客観的な測定値とを組み合わせ、担当者を「職人領域」，「属人領域」，「教育領域」，「点検領域」，「適正領域」の五つに分類し、チーム内の担当者の相対的な属人化の進行の不均衡さ（チームバランス）を可視化することによって、 管理者が各領域のバランス状態を確認し、必要な育成リソースに対する過不足を把握して、 問題発生前の事前対応計画作成に役立てられるよう、属人化状態の測定・可視化を通して改善する仕組みを構築しようとする研究である。

紹介文 :
１つの変更要求が及ぼす影響というのは時として他システムに跨ることもあります。この影響範囲を特定する方法として派生開発で使用されるXDDPを採用しました。 変更依頼を要求と仕様の階層構造で表現し、要求レベルで他システムへの影響を検討することで影響範囲を特定しようとした試みです。

紹介文 :
ソフトウェア技術者個人のプロセス改善である、パーソナルソフトウェアプロセス（PSP）を職場で試行的に実践した報告です。 筆者自身ではなく同僚への施行のため、導入障壁となりうう負担感や個人の意識が表れており、参考にできます。

紹介文 :
CMMからCMMIへのスムーズな移行を目的として、両モデルの比較考察を行い、両モデルのゴールとプラクティスの対応関係と見解をまとめたマッピング表を作成しています。 また、CMMからCMMIへの移行の際に優れていると思われる点5つ（要件管理、リスク管理、計測と分析、エンジニアリング、決定分析と解決）につて整理されています。

紹介文 :
ISO9001（2000年版）の認証を取得してる企業がCMMを参考にしてさらに改善をしていくためのガイド ISO9001未取得の企業の場合はIOS9001/CMMの要求から自社の状況で施策のベースを検討するのにも有効である。

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

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

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

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

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

紹介文 :
モチベーションやモラールを扱った著書や研究は多い。この問題は、古くは、ホーソンの実験から始まると考える人も多いだろうが、人類の誕生以来ずっとあるのでは無いだろうか。 　本論文を書き終わった時、研究員の全員が異口同音に「自分はプロジェクトリーダだと思っていたが、この１年研究していかに未熟かを実感した」と言っている。本論文には、現代のプロジェクリーダが見えていない世界が描かれている。 本論文は、そのエッセンスが書かれているので、1年かけた研究者と同じ実感はもてないかもしれないが、プロジェクト管理の世界の広さをかいま見ることが出来るだろう。

紹介文 :
本論文では，多くのソフトウェア開発現場で作成・運用されている「チェックリ スト(チェックシート)」の改善を目指した，「Smile - Process for Checklist Design (S-PCD)」法を提案している。 　チェックリストが，チェックを実施する使用者にとっては分かりにくく，チェッ ク作業の効率が良くないものであることが多い。チェックする目的や内容が曖昧で あったり，項目数が必要以上に多いためである。こうした原因がチェックリストを 作成する手法と体系化にあると分析し，チェックリストを改善するために，チェッ クリストの要件定義・設計プロセスをS-PCD法として定義し提案している。 　S-PCD法により、使用者がチェック作業を効率良く行え，ソフトウェア品質向上 に効果があることを実感し，「Smile」を浮かべて作業できるようになり，開発現 場のモチベーションアップに貢献することが期待される。

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

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

紹介文 :
本論文では、ソフトウェア開発において，プロジェクトマネージャ(PM)が様々な 進捗会議用の報告資料準備に多大な時間がかかっている問題を解決するために， CSMA(Connect Similar Materials Automatically)法を提案している。 　特筆すべき点は，現在も進捗報告で多くの人が利用しているExcelツールを活用 して，進捗報告資料準備を効率化するところにある。このため特別なPC環境を用意 することなくCSMA法を導入して利用できる。 　初期設定しておくことで，PMが行っている進捗報告資料準備作業(複数の進捗報 告資料のマージ，データの修正)をExcelツールが代行するので，関係部門が多く 長期間で進捗報告の回数の多いプロジェクトほど削減効果を高められる。 　本論文にExcelツールを添付しているので是非活用いただきたい。

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