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

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

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

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

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

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

紹介文 :
　プロジェクトマネジャーは忙しいという研究員の言葉を聞いて、それは『プロジェクトマネジャー消防士論』に則ってないからだとこたえたのが始まり。ここで言う消防士とは、火消しではなく『火事が起きないように願い予防処置をする人』が消防士だ。つまり、火消しは消防士 ではなく、消防士は、自分の仕事が無くなるようにと自己否定しながら生きる不思議な人だ。
そのためにはどうすれば良いか。人、組織、システム化対象物、プロジェクト、ソフトウェア、コンピュータの仕組みなど諸々を知り、その特性に合わせて予防処置をすることだ。つまり、プロジェクト・マネジャは、物事の本質をとらえて意思決定をすることである。
さて、本質とは何か。論文を読んでいただこう。

紹介文 :
受託開発では、上流設計の遅れから試験期間が圧迫されることが多い。特に開発期間が１年を超える新規開発においては、システム設計、基本設計に時間をかけることで実装計画がずれ、残された期間で試験を実施しなければならない。試験工程ではシステム試験の期間を確保するため、ソフトウェア間の結合試験が十分実施されずにシステム試験に進む場合があり、現地動作確認前に不具合が潰し切れない可能性がある。
そこで、試験期間の圧迫が品質に影響していると捉え、部門のデータを分析、試験期間が不具合の発生状況に影響しているという結果が得られた。この結果を元に、品質向上に繋がる適正な試験期間の指標を設定できた。
本発表では、試験期間及び不具合に関するメトリクスの分析結果と品質向上に向けた取組みについて紹介する。

紹介文 :
PJに大きな影響を与える要求管理プロセスの作業品質の向上が注目され、さまざまな企業で改善が継続的に取り組まれている。例えば、仕様が曖昧である、要求が決まらないといった課題は頻繁に挙げられ、その対処法も明確には提示されていない。弊社においても要求管理に関する課題は様々あり、PJのスムーズな進行を阻害する一因になっている。特に、コンシューマ製品開発における要求管理は、さまざまな関係者とのやりとりに課題が多く、また、市場動向等の外部要因による変動要素の影響が大きく難易度が高い。そこで、2011年下期より、要求管理を専任として担当する仕様担当者を中心とした関係者とのやりとりの課題改善や仕様担当者自身の作業品質の向上へ主軸を置いて改善活動を推進してきた。本活動では、影響の大きな要求定義の工程に対し、要求に関わる関係者へのヒアリング結果や過去の記録から問題を分析し、要因に応じて課題への施策を実施してきた。その結果、要求・仕様変更の低減や残件の早期解決など仕様合意の早期化や開発の混乱の低減に貢献した。本報告では、これまでの活動のうち、主な課題である、①要求変更が多い・要求・仕様が決まらない、②仕様合意が曖昧である・仕様変更が発生する、③変更発生により開発が混乱する、という3つの課題についてその施策を紹介する。

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

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

紹介文 :
当社では、プロジェクトリーダが、ソフトウェア開発プロジェクトのデータとして、品質や工数、コスト等の他に受注前の審査情報から、出荷後の品質までを１つのシステムで管理している。この蓄積されたデータを元に品質目標の設定やプロセスの実施状況を監視するための項目抽出を行い、実施してきた。このことは、出荷時の品質を確保することに対して、有効である。
では、出荷時の品質が確保出来たこと＝成功プロジェクトと言えるのか？品質を確保するために膨大な工数をかけ、コストがかかれば、プロジェクトは不採算となる。プロジェクト遂行中の様々な状況を把握、判断し、プロジェクトを成功に導くには、熟練者の経験や勘に頼ってきた傾向がある。
ならば、データから、プロジェクト遂行中の状況や変化を的確に捉え、プロジェクトの成功に導くことは出来ないか？データが示す事実から仮設を立て、それがプロジェクトの成功、採算につながる因子なのか、失敗、不採算につながる因子なのか分析を行った。導き出された因子を不採算プロジェクトの早期発見やプロセス改善活動に活かしている。

紹介文 :
　我々は、開発対象となるソフトウェアの特徴から派生開発に特化した開発プロセスXDDPを導入している。しかし、上流工程で変更箇所の抜け・モレを十分に抑えることができず、後工程で不具合が散見されていた。その原因の１つとして、担当者がXDDPのねらいや効果を十分に理解しておらず、XDDP帳票のフォーマットを埋める形で成果物を作成していることが多々あることがわかった。つまり、導入・整備したプロセスに対して、開発を担当する技術者のスキル・理解が不十分であった。このことはXDDPに限った問題ではなく、開発現場でよく見かける典型的な問題である。
　本発表では、表面的な理解・形式的な作業に留まっていた技術者のレベルを引き上げ、成果物の質の向上につながるトレーニング手法の提案と、本手法を適用しXDDPのスキル向上に取り組んだ活動結果を報告する。
　提案する手法のポイントは、社外コンサルからの指導（教えられる）とピアレビューを用いた実践指導（教える）とを組み合わせた「教えられる・教える」立場を同時期に繰り返し経験する点と、第三者視点を導入した点である。若手リーダーに適用した結果および評価と合わせて、本手法の有効性を報告する。

紹介文 :
エキスパートレビューアを育成するためのトレーニング手法として、特に伝え方や教育が難しいドメイン知識に着目し、経験の浅いプロジェクトメンバーに実務において失敗させずにドメイン知識を習得してもらう手法として、EIDeR-Training法（Error Injected Document Review - Training 法）を提案している。短時間での教材作成や、個人学習なのに疑似的失敗体験ができる仕掛けなど工夫がされている。

紹介文 :
IBR法(問診に基づくレビュー方法）は成果物作成者への問診から得た推論からレビューポイントを導出する。成果物作成時の個人・プロジェクトの問題を認知し、短時間で「合理的なレビューポイント」を導出することが出来る。
システム開発において品質を検証する技法であるレビューは、効果的に重大欠陥を検出する重要な手段である。しかしレビューが、成果物の説明会、若手の指導や作成者の吊し上げを行う場など、個人・プロジェクトの前提・課題の共有および対策の検討をする会議と化している事が散見される。これは開発期間短縮等により情報共有や対策検討の時間が確保できない事が原因だと考えられる。
そこで我々は「問診」を通じて成果物の作成状況から個人やプロジェクトが抱えている課題を的確に推論し、レビューポイントを導出するIBR法を考案した。
問診は、成果物作成者に個人やプロジェクトの背景にある問題を推測する質問をする。医療の診断においては誤診を防ぐ工夫がされており、これをソフトウェアレビューに則した改変を行った。これを用いる事で問診の推論の精度を高める。
実験の結果この方法は、重大欠陥の効率的な検出に有効であり、理解しやすく、習得性が高い方法である事がわかった。

紹介文 :
一般的にシステムテストの自動化は、フロントエンドのアプリケーションのGUI入力をエミュレートすることが多い。しかし、GUIは人間用に設計されており、プログラムからの操作に適していない。実際に問題になった点を挙げる。
・不安定なテストになる。(タイミング依存で成否が変わる。)
・技術的にブラックボックス性が高く失敗理由の解析が困難。
・プロダクト変更時のメンテコストが高い。
・テストシナリオの可読性が悪い。
・操作不可能なケースも多々ある。

問題が積み重なると、解消するためのコストが増大する。逆に、これらの問題が発生しないインターフェイスが用意できれば、十分なROIを確保できるといえる。
本発表では、操作用インターフェイスとしてGUIだけでなくAPIも利用する方法と、その際、ユーザー操作とは異なるインターフェイスを使うことに関してのトレードオフを実例を交え紹介する。
また、テストシナリオから使うインターフェイスを洗練させる手法としてアプリケーションドライバ(WebでいうところのPageObject)も合わせて紹介する。

<備考>
実例で紹介する操作対象はWindowsアプリで、操作のために使ったライブラリはFriendly[http://www.codeer.co.jp/AutoTest]である。

紹介文 :
ソフトウェア開発の現場では，短納期，高品質が求められており，技術文書に対するレビューが不可欠となっている．各プロジェクトでは，混入した欠陥をいち早く検出するために，同一文書に対して複数回に渡りレビューを実施したり，開発リーダや有識者がレビューを実施したりする等の工夫がされている．しかし，それでも重大欠陥の検出漏れを防ぐことができず，大きな手戻りが発生し，結果的に時間やコストがかかってしまうケースが多く見られる．そこで，我々はレビュー時の新規役割「ハーベスタ」，及び欠陥分析用ツール「知見分析表」を提案する．
ハーベスタは，レビュー結果を収集し，検出された欠陥の傾向や欠陥混入に至った背景などを分析して，以降のレビューにフィードバックする役割を担う．知見分析表は，影響度と緊急度という２つの指標を軸とした表で，レビュー時に検出された欠陥を,ハーベスタがその表にプロットし，欠陥の検出傾向を捉えるために利用する．ハーベスタは,プロットした結果から傾向や混入原因を考察することで，以降のレビュー観点を導きだす．考察の結果として，検出される可能性があるにも関わらず未検出の欠陥種類があれば，その観点の追加も検討する.
実験では，ハーベスタを配置して知見分析表を用いて欠陥の分析を行い，その結果を次回のレビュー担当者にフィードバックすることで，レビューの質が向上し重大欠陥の検出効率が向上することが確認できた．

紹介文 :
プログラムを自動解析・自動実行するConcolic Testingは、制御パスを通るテストケースを自動生成し、抽出した値を使ってパスを自動実行するテスト技術です。
この技術のツールであるCRESTを、リグレッションテストに適用し、利用方法と検証結果をまとめました。
Concolic Testingに取り組もうとする方や、リグレッションテストの自動化に興味のある方の一助となる論文です。

紹介文 :
ソフトウェア開発の現場で起きている失敗の原因とUX手法が解決できる問題を突き合わせることで、現場や問題の状況に合わせて適切なUX手法を選択することを提案している。単に手法ありきで導入するのではなく、本来の目的を把握・意識したうえで、本当に望まれている結果を導くための重要な考え方を提示している。

紹介文 :
ノベルゲームとは、分岐構造を持つ文芸的に書かれたシナリオに演出を加えたDSLを、ゲームエンジンが解釈・実行するコンピュータゲームである。本発表では、開発効率や品質の向上を念頭に工夫したノベルゲーム開発基盤を試作し、ワークショップを通じて得られたフィードバックに基づき改修を繰り返した事例から、アジャイル開発やソフトウェア工学の知見が、開発効率や品質の向上に、どのような影響を与え得るか評価を試みる。
試作した開発基盤には、コードの共同所有、継続的インテグレーション、高速なイテレーション、状態遷移図による見える化、モデル検査、など、アジャイル開発のプラクティスとソフトウェア工学のツールを導入した。この開発基盤を用いたワークショップでは、チームでの開発効率の改善を観察することができ、体験者の声から、実務にも活かせる先端的体験提供を確認できた。