紹介文 :
本発表では、欠陥密度の管理限界を適切に定めるにはどの程度のデータ蓄積が必要なのかの判定方法について議論する。

ソフトウェアの品質管理において欠陥密度は、上下の管理限界を定めその範囲に収まれば懸念なしとし、範囲外になった場合は品質に懸念ありとするように用いられることが多い。このため実務上妥当な管理を行うには管理限界を適切に定めることが重要になる。

管理限界を定める際に過去蓄積されたデータを用いる場合、適切な管理限界を得るためにどれだけのサンプルを集めなければならないかの判断基準が必要になる。

本発表では、欠陥密度は発見された欠陥数をＬＯＣ数で割ったものとする。また欠陥数はＬＯＣ数に対し離散的に発生するのでポアソン分布に従うとする。ポアソン分布においては上下の管理限界は、それまでに蓄積したサンプルの累積欠陥数を累積ＬＯＣ数で割った欠陥密度があれば定めることができる。本発表では、ある時点において集まったデータを元に算出された平均値が、その後、継続的にデータを蓄積していくにつれどのように推移していくかを予測し、その予測の変動幅がデータ蓄積規模の増加対比小さい範囲に収まっているといえる状態に至れば妥当な管理が可能な程度にサンプルが集まったと判断できると考え、その方法を提案するとともに実施例を提示する。

紹介文 :
組込みソフトウェア医療機器（e.g.血圧計や血糖計）の設計検証においては、FDAの定めるGeneral Principles of Software Validation（以下、GPSVと記す）を遵守することを念頭におき活動している。GPSVでは、「ソフトウェアの仕様がユーザのニーズや意図する用途に一致しており、ソフトウェアに実装された特定の要件が一貫して満たされていることを、検査および客観的な証拠の提出により確認すること」と定義されているが、具体的にどうやってそれを実現するかは、製造業者に任されている。
従来はソフトウェア要求仕様書をテストベースとして、明示的な仕様のテストプロトコルを作成してきた。また、暗黙的な仕様を押さえるために、過去事例からテスト観点を抽出し、エラー推測しながらテストを実施してきた。しかし、この方法ではソフトウェア要求仕様書のヌケモレを検証できないため、十分なシステムテストができていることを保証できなかった。
そこで、ソフトウェア要求仕様書を試験性の観点でテスト分析する手法を研究し、検証設計ガイドラインとして手順化した。今回、そのテスト分析手法について発表する。

紹介文 :
ソフトウェアプロセス改善を行う場合，CMMI(Capability Maturity Model Integration)などに代表される「モデルベース型のプロセス改善」と，SaPID(Systems analysis／Systems approach based Process Improvement methoD)などに代表される「問題解決型のプロセス改善」がある．モデルベース型プロセス改善は，実績のある効果的な手法が体系的にプロセスモデルとして纏まっているが，開発現場などの当事者自身が問題の存在に合意できないと，モデル適合を目的化しがちなり，「やらされ感」が出てしまうという課題がある．また，問題解決型プロセス改善は，当事者自身が問題分析を行うため「やらされ感」は出づらいが，適切な分析結果とそれによる十分な改善効果を得るためには，問題分析のスキルや時間が必要となるという課題がある．
本報告では，改善推進者が当事者に既存手法を導入することでプロセス改善を推進する場合，第三のアプローチとして「マフィアオファー型プロセス改善」を提案する．マフィアオファーは，導入したい手法の特徴から，それが解決できる問題の構造を導き，「質問」という形にする．つまり，直接，当事者の問題分析するのではなく，手法が解決可能な問題の存在を質問し，当事者自身に問題構造について考えさせることで「やらされ感」を払拭する．問題構造を推進者側から提示するため，当事者側には問題分析のスキルや多く時間を必要としない．
本報告では，派生開発手法であるXDDP(eXtreme Derivative Development Process)の導入について，マフィアオファーを試行した結果について述べる．

紹介文 :
当社の情報システムエンジニアリング部門における品質管理ノウハウは、従来から各職場での開発経験をもとにOJTとして先輩から若手に継承してきた。しかし近年は、プロジェクトが大規模化する一方で開発案件に対する要求納期が短納期化の傾向にあり、開発要員の役割分担の細分化、開発業務の委託外注化が進んだことから、プロジェクトの計画段階から終了まで当社の社員(SE)自身による一貫した品質管理業務の機会が失われてきている。
そこで、当社では開発業務での品質マネジメント経験を形式知化したテキストに、現場のプラクティスを元にした演習を加えた教育コンテンツを整備し、広くSEに教育を実施することとした。
また、教育・育成への効果的な動機付けとして、品質管理のプロフェッショナルである「品質管理エキスパート」の認定制度も立上げ、講座受講と業務経験を要件に段階的に認定する制度も開始した。
本発表では、職場のOJTだけに頼らない、品質管理業務を実践できる人材の育成に関する全社的な取り組みの内容、および現時点の成果と今後の方向性について紹介する。

紹介文 :
アドバンテストではソフト開発の工期と品質を両立するため、トヨタ開発方式*1をカスタマイズ*2しソフト開発現場で利用している。
*1) 次の文献にて著者が名付けた開発方式であり、「欠陥」だけでなく開発工程で生じる「待ち」や「遅れ」の状態もムダとし、改善対象とする特徴を持つ。
”トヨタ製品開発システム”James M.Morgan、Jeffrey K.Liker著
*2) カスタマイズし利用している内容は、次の３点である（SQiP2013にて発表）。
・開発を切り出して部署間の活動を同期化し、かつ平準化を図る。
・切り出した開発目標(マイルストン内容)を詳細計画が網羅する。
・課題ばらしの実施を計画に組み込み、事前に十分な検討を行う。
今回の発表はカスタマイズ内容*2の３点目を深掘りしたものである。工期の遅延が日常化している複数のプロジェクトについて、遅れの原因を確認したところ、課題ばらしの質が確保されていない点が共通していることが分かった。そこで、課題ばらしの質の改善に重点を置いた活動を行った。この活動に際し、LAMDAサイクル(トヨタ開発方式)*3 と ＰＱ指標*4を新たに導入した。
*3) LAMDAサイクル（Look/Ask/Model/Discus/Act）
*4) ＰＱ指標（Pは課題抽出力、Qは課題解決力）
上記の手法と指標を導入し活動した結果、課題ばらしの質を向上する効果が出た事を確認できたので紹介する。

紹介文 :
　ソフトウエア開発において、障害（ソフトウエアバグ）対応コストは、後工程になるほど高額になっていくため、出来るだけ前工程で障害を検出することが、品質向上、生産性向上につながると言われている。
　しかし、ソフトウエア開発工程の障害対応コストの見える化は、ほとんど行われていない。
　そこで、ソフトウエア開発工程ごとに１件あたりの障害対応にかかるコストを定義し、過去の複数案件について、設計から稼働後までの障害件数を金額に換算することを試みた。
　この試行の結果、上流工程での品質確保の必要性や、コスト増となる「バグ曲線」の存在が明らかになった。
　さらに、「障害分類や障害検出基準」と「コスト定義」を組み合わせることで、“無駄なコスト”や、“本来コストをかけるべき工程”が見えることもわかり、これらの試行結果を整理し、「コストモデル」の作成に至った。
　今後は、「コストモデル」という“ものさし”を使い、品質管理とコスト管理を共存させながら、開発中にギャップを是正するプロジェクトマネジメントを追求していく。

紹介文 :
フェリカネットワークスでは，人と技術の両側面からチームのパフォーマンスを高める活動に取り組んでいる．どのようなことを行えばチームのパフォーマンスを高めることができるのだろうか．著者の所属するソフトウェア開発プロジェクトでは，複数の関係する会社と共に，製品の円滑な開発と，品質の確保，チーム力の強化を目指し， 9 年間に渡って試行錯誤を重ね，さまざまな取り組みを行ってきた．
働きやすい職場とはどのようなものか，個々人が切磋琢磨しながらチームとして何かを生み出していくためのコミュニケーションはどうあるべきなのか，チームでディスカッションを重ね，さらにチームワークの練習を繰り返し行ってきた．この活動を継続することにより，お互いを受け入れ，共通のゴールに向かって知恵を絞り，協力することができるチームの文化を築くことができた．品質を高めていくための技術の導入に，その技術を支える人という面からのアプローチを加えることにより，チームは成長を続け，開発の成功につながり，さらに自分たちのコミュニケーション力の向上という面でも成果を出した．
この活動を振り返り，「チームの立ち上げ期」，「チーム学習の発展期」，「チーム文化の定着期」の 3 段階に分けて，各段階において行ってきた活動の内容と，その効果について報告，考察することにより，チームビルディングの有効性について論じる．

紹介文 :
近年、成果物の品質の良し悪しに関わらず、多くのプロジェクトで進捗遅れが頻発していた。日々遅れのリカバリに追われ、進捗管理がうまく回っていないように見受けられた。
進捗管理では、計画・成果量・成果物の品質・工数・要求の変化・管理の状況など、様々な要素をもとに進捗を監視・コントロールする（問題に手を打つ）必要がある。しかし、忙しく混乱した現場ではこれらすべての要素に目を向けることは難しく、うまく進捗管理ができていないことが分かった。
そこで、工数以外の要素も重要だが、まずは我々の組織で風土として根付いており忙しい状況でも計測できている工数を活かして進捗管理ができる姿を目指し、進捗遅れの減少に取り組んだ。
工数からできる限り多くの情報を掴み進捗管理に利用するために、進捗遅れが発生しないための進捗管理のあるべき姿を考えた。それをもとに、工数から直接分かる作業時間や生産性だけでなく、遅れの度合いや品質確保状況の概観を掴む指標、仕事ぶりの見方などを定義し、工数を進捗管理で活用する方法を明らかにした。そして、それらが現場で実行され定着するための仕組みとして、「進捗管理トレーニング」「PM層に対するコンサル」「改善推進者による密着支援」を構築し、実施してきた。
本発表では、工数に重点を置いた進捗管理の定着の取り組みと、現場で進捗管理を実践した結果について紹介する。

紹介文 :
　筆者は2008年にパナソニックエレクトリックデバイス（PED)のコーポレートSQAに着任、社内事業場のSQAの仕組み強化と役立ち度アップのため、SQAのスキル要件を定義し、必要スキルを満たすSQAがソフトウェアの監査を実施する仕組みとした。また、SQAスキル要件と連動したトレーニングマップを作成し、活用、改善を行ってきた。
　このPEDのSQAスキル要件を、パナソニック全社の車載関連部門のSQAに展開し、さらに広範囲のSQAのレベルアップを図ることになった。そこで、スキル要件の更なる体系化の検討を行った結果、SQuBOKを活用することとした。SQAに関する知識体系であるSQuBOKを活用することで、求めるSQA像を、より分かりやすく表現することができ、スキル要件の客観性、網羅性、使用性が向上することを期待したためである。
　本取組みと、SQuBOKを用いて得られたメリット、更に、今回改定したSQAスキル要件とひも付いたトレーニングの体系、スキルレベルの認定制度など、パナソニック車載関連部門におけるSQA育成の取組みを共有し、SQAの育成について、共に考える機会としたい。

紹介文 :
企業が使用する業務用ソフトウェアシステムの多くは、複数のIT統制、監査、
認証に対応しなければならない。経営管理者はシステム開発・運用に係る管理
記録を整備し、システムの管理品質と製品品質を長く維持しなければならない。
その一方で、開発・運用現場には多種多様な記録・管理方法の混用があり、記
憶に頼る属人的な習慣も根強い。従来の方法では、管理要求を達成するために
多くのコストが必要となり、また、対象システムの増加や規模拡大により、手
順の実現と定着は容易でない。

IT統制、監査、認証の要求実現の急所は「管理記録の網羅性・完全性・追跡可
能性の同時成立」にある。一方で、現場の要求は作業利便性と効率性の追求に
ある。２つの要求に通底する共通課題に着目し、統合情報基盤の構築による、
強制力のみに依らない要求の実現と、有効な定着を目指した。

本論文では、島津製作所グループの基幹業務を支える業務用システムの開発・
運用現場（100種、200名）において、IT統制水準とシステム品質の向上を目
的としたIssue Tracking System（ITS - Redmine）の全面導入事例を紹介する。
5年間のITS運用結果（12万チケット）の定量・定性分析に基づいて「効率・
品質・統制」の観点で導入効果を検証した。その結果、各種要求の実現、管理
手順の有効な定着、低負荷の工数管理、多重管理の無駄をなくす、という効果
が確認できた。

紹介文 :
同じ開発母体による類似製品の並行派生開発において，複数製品で同じ機能に対する仕様（これを共通仕様という）の漏れや誤った解釈は，その影響が複数製品に及ぶ可能性が高いため品質リスクが大きい．
この問題に対し，専門組織を設置し共通仕様を取りまとめて管理する解決方法があるが，小規模な派生開発では開発コストに厳しい制限があり，適用が困難であった．
そこで筆者らは，過去の方法論であまり対象としていない，小規模な並行開発にも対応可能な専門組織に代わる方法により，共通仕様の検出とこれを並行開発する製品の関係者で共有する仕組みを考案した．本発表では、この仕組みについて紹介する．

紹介文 :
ソフトウェアの欠陥はリポジトリシステムによって管理されることが多くなっており，リポジトリシステムとCI(continuous integration)ツールを連動させ，開発からテストといったソフトウェア開発の全工程を管理することも往々にして行われている．そこで，我々はCIツールへのプラグインとして，リポジトリシステムで管理されている欠陥データから，それぞれの欠陥に対して発見した時間を取得，ソフトウェア信頼度成長曲線に適応，今後発生すると予測される欠陥数についてグラフ化を行い，CIツールにて確認できる環境の構築を行った．
我々が開発したプラグインを用いることで，予測される欠陥数を定量的に把握することができ，開発者やマネージャが悩んでいた欠陥数を見積もることができ，開発の進捗状況を日々確認することができる．加えて，残りの欠陥について後どれだけの欠陥を発見すればよいか定量的な目標ができ開発者のモチベーションの向上や維持につながることが期待される．本研究は共同研究企業とともに有効性を検証している．

紹介文 :
センサで車両周囲の環境を検知し、その結果を用いて車両制御する超音波センサシステムの新規開発を担当している。このシステムは、ユーザの実使用環境の影響を受け易いため、仕様開発と量産開発の２つのフェーズに分けて開発している。
しかしながら、近年、自動車メーカからの車載システム機能の高度化、複雑化、短納期かつ高品質要求に応えるためには、従来の２フェーズ開発方式を保つことが難しくなった。
そこで、前後二つのフェーズの一部を重ね合わせたコンカレント開発方式に切り替えることで、品質を落とさずに製品開発期間を短縮する効果を得た。本発表では、具体的な施策と、その結果について紹介する。

紹介文 :
ソフトウェア開発におけるレビューは、ソフトウェアの欠陥を早期に検出可能な手段として、品質向上・コスト削減・納期遵守に有効である。しかしながら、レビューにおいて影響度の高い欠陥を検出できるかや、検出に掛かる時間の長さはレビューアに依存しているのが現状である。これらの課題について、個々人が持っている欠陥に関する知識(以下、欠陥知識)を組織として有効活用することで解決できないかと考えた。
そこで、本研究チームでは、影響度の高い欠陥を容易に見つけることが可能な思考法であるHDR法（SQiPシンポジウム2013、HDR法：仮説駆動型レビュー手法の提案）から着想を得て、「欠陥連鎖チャート（Defect Chain Chart：以下DCC）」を考案した。
DCCは欠陥知識を可視化し、欠陥知識同士の関連を表現した図であり、欠陥知識を共有・蓄積・活用するためのものである。
このDCCにより課題の解決が可能かを確認するために実験を行った。DCCを用いてレビューを実施すると、従来のレビューよりも単位時間あたりの重大欠陥の指摘数が上がるという結果を得た。また、実験被験者からは「経験が少ないメンバーに対して有効である」との評価が得られた。これはDCCを用いたレビューが課題解決に有効であることを示唆する。
本論文では、新しい欠陥モデルである欠陥連鎖チャートの利用方法と効果、ならびに今後の展望について報告する。

紹介文 :
技術者が「学び・育つ」ためには、「自ら考え自ら行動する」ことが重要である。そのためには考える拠り所となる材料が必要であり、その基礎的な材料の１つとして我々は工数データに着目した。工数は技術者一人ひとりの日々の“仕事ぶり”を捉えることが可能なため、集めたデータを活用することで主体的な自己改善につながるデータである。この考えのもと、我々は工数を計測してきたが、計測した工数を実際に活用する段階になると“事実に合わない”データとなっていることが多々あり、自己改善にうまく使えなかった。その状況を解決するためには、集めたデータが実際に使えるデータになっているかの目安となる指標が必要であり、指標を利用することで工数入力を真に定着させ、工数データの質を引き上げ、自己改善につなげたいと考えた。本研究では、使えるデータとなる工数入力スタイルを「都度入力」と定め、都度入力となっている状態を真の定着とした「工数入力定着モデル」を考案・開発現場に適用した。
発表では、考案した「工数入力定着モデル」とモデルを構成する二つの指標「工数入力スタイル指標」「工数入力データの粒度指標」を紹介する。また、合わせて五か月間の実験結果およびモデル・指標の有効性についても報告する。

紹介文 :
弊社ではシステム品質向上を目的として、２００９年以来開発プロセスの改善活動を進めてきている。この活動は、①開発に必要なプロセスが分かりにくい、②プロセスの強み・弱みや陳腐化を客観的に把握できていない、③プロセスに対し「やらされ感」を持つ社員が少なくないといった全社的な問題意識が背景であった。
改善活動は、ＣＭＭＩモデルを参考としたギャップ分析から開始した。この分析結果から明らかとなった課題を解決する分かりやすい開発プロセスを構築し、それを「やらされ感」を持たれないよう、定着させていった。「やらされ感」を感じながらのプロセス実施は「形骸化」につながり、プロセスの意図や狙いを達成できず、非効率な結果となる可能性が高い。そのため、時間がかかっても一人一人の腹に落ちるよう、工夫を重ねた。
これら活動の結果、内製部門においてＣＭＭＩのレベル３を達成、またプロセスの定着率も着実に向上しつつある。
本発表では、弊社のプロセス改善活動の内容や工夫した点についてご紹介する。同様の課題に取組んでいらっしゃる方の参考となれば幸いである。

紹介文 :
テストを自動化しデイリービルドに組み込み継続的に実行する事で、品質を保ちながら開発のアジリティを加速する、継続的インテグレーションや継続的デリバリーなどの手法が一般的に使われるようになってきた。近年では単体テストやコンポーネントテストだけでなくシステムテストも自動化、継続的に実行されるようになってきている。
自動化される以前は、システムテストは開発工程終了後に成果物であるソースコードを対象として行われていた。自動化後はシステムテストを実装と平行したリグレッションテストとして継続的に実行する。それにより、早期にバグを発見したりバグ修正日数を削減したりする事が可能になる。
しかし、一方で継続的システムテストの実態やその性格は従来の品質保証プロセスからは説明出来ない部分もまだ多い。例えばバグ曲線は従来のソフトウェア信頼度成長モデルでは緩やかに収束していたが、継続的システムテスト環境下では急激に収束してしまう。
継続的なシステムテスト環境下での開発と品質保証プロセスについての理解を深めるため、我々のソフトウェア開発プロジェクトから得られた開発、ソースコードとバグのメトリクスについて分析を行った。

紹介文 :
本発表の目的は、メソッドのインターフェースの複雑度に着目しメトリクスを利用にすることでレガシーコードからリファクタリング対象を自動抽出することである。
市場で不具合が発生した時、修正箇所は正常に動作するようにするが、将来のことを考えるとメンテナンス性を向上させたいと思うことが現場では多々ある。その結果リファクタリングしようという考えに至るのだが、修正対象のコードがレガシーコードであるため、どこから手をつけて良いものかわからないという壁にぶつかる。現場においては人的リソースや時間が限定される。そのような状況下では効果的なリファクタリング対象を素早く検出する必要がある。そこでメトリクスを使ってリファクタリング対象を自動抽出する仕組みを考案した。
本発表ではその方法と実施結果を紹介する。

紹介文 :
本発表は、D-Caseをソフトウェア開発に導入した事例の紹介である。
ソフトウェアの妥当性をテストで評価するためには、期待結果が明確でなければならない。しかし、一部のソフトウェアには、期待結果を一意に決
めにくいものがある（乱数を用いたシミュレーションなど）。そのようなソフトウェアに対しては、単体テストや画面系テストなど「決めやすい」
テストは一生懸命行うが、ソフトウェアの重要な「決めにくい」部分の確認方法は明確化されず、関係者間での合意も行われないまま放置されがち
である。そして、開発後期の大きい手戻り、責任の押し付け合い、出荷後不具合を引き起こすことがある。
DEOSプロジェクトで提唱されているD-Caseは、システムのディペンダビリティについての説明責任を果たし、ステークホルダ間で合意を形成するた
めの手法である。我々はD-Caseを用いて、ソフトウェアの「決めにくい」期待結果を明確化し、関係者間の合意を行うことに成功した。本発表で
は、その経緯と成果について紹介する。

紹介文 :
改善とプロジェクトマネジメントを別物扱いしている組織やチームが多いと感じています。
それぞれを別手法でばらばらにアプローチする例は多 く、改善を一過性のものにしたり、大きな問題が発生しないと着手しない、改善が定着しない、効果が得
られないなどの元凶になっている場合もあると思われます。
そこで、プロセス改善手法：SaPID（*1）の構成要素 （例：ふりかえり、問題構造分析など）をプロジェクトのモニタリング＆コントロール（問題／リスク発見・解決など）に活用しながらプロセ ス改善を実践した事例を提供し、以下の内容を共有したいと思います。
(1)プロジェクトのモニタリング＆コントロールと改善実践を可能な限り自然な流れで一体化する方法とポイント
(2)プロジェクトで発生した問題事項の再発防止だけでなく、発生する可能性がある問題（リスク）を先読みして手を打つ予防処置実践につなげる方法
(3)プロジェクトにこの手法を適用する際の工夫と注意事項
(4)プロジェクトマネジメントにおける問題発見・解決実践力の向上に必要なこと
*1：SaPID?（Systems analysis／Systems approach based Process Improvement methoD）
問題対象をシステムと捉えて解決するシステムズアプローチに基づき、実務を行う管理者・技術者自らが持つ問題意識や事実情報を問題構造図に表して現状を分析し、解決すべき問題を特定、現状の制約条件などを考慮した現実的かつ効果的な対策を実践するプロセス改善手法。