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

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

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

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

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

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

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

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

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

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