紹介文 :
ソフトウェア開発において、工数は関心が高い事項の一つである。工数と規模の関係においては、相関があることがわかっている。また、弊社では工数を開発工数、管理工数、顧客対応工数と工数の用途に応じて、分離して収集を行っている。これらの工数はすべて規模と相関があるのであろうか。

弊社の先行事例では、工数から管理工数、顧客対応工数を除いた開発工数と品質の関係を明らかにしている。これから、管理工数、顧客対応工数が、開発工数とは違った特徴を持つことが示唆される。しかしながら、管理工数や顧客対応工数に関しては、適切に分離できているデータが少なく、十分な分析ができていなかった。

本論文では、管理工数や顧客対応工数が適切に分離できているデータを拡充し、ソフトウェア開発プロジェクトにおける工数の構成について明らかにする。またソフトウェア開発プロジェクトにおいて、開発工数はもとより、管理工数も必要不可欠な工数である。そこで、工数の構成分析を通じて、管理工数はどの程度が適切なのかの考察を行う。

紹介文 :
当社において、ソフトウェア品質に関する分析を行ったところ、そこで見つかった問題の多くは、その背後にある「慢性的な高負荷状態」や「スキル・ノウハウの伝承不足」といった根本原因によるものであることが分かった。そして、それを引き起こしている最も大きな要因として「特定の作業が特定の人にしか出来ない」といった過度な属人化があり、この状態を解消することなくして継続的な品質向上活動を行うことは困難であるとの結論に至った。

品質向上活動では、ベストプラクティスを手順化するといった標準化の方法が一般的である。しかし、属人化してしまう知識やノウハウは、ユーザ業務やアプリケーションが異なれば、まったく別のものとなる。そのため、この属人化の問題は、標準化アプローチによって解消できるものではなかった。では、どのように取り組めばよいのか。さんざん悩んだ末、トヨタ自動車の「自工程完結」に問題解決のヒントを見出すこととなった。

このようにして、当社では昨年度から「自工程完結」の考え方をソフトウェア開発に応用した「開発現場のプロセス改善」を、属人化解消の切り口で開始することとなった。本発表では、その活動の概要と進め方、またそのために工夫した点について、事例を交えながら紹介する。

紹介文 :
JAXAでは、新規のシステムを開発する際、ソフトウェアの要求定義や設計段階で、要求の抽出や設計のレビュー、試験ケースの網羅性向上、運用への制約を抽出するためにFMEA（故障モードと影響解析）を行っている。FMEAの効果を向上させるためには、一般的に「故障モード」を如何に網羅的に導出するかと、システムへの影響が大きい「故障」を洗い出せるかが重要である。一方、ソフトウェアの製品としての特性からFMEAを適用する際、下記の課題が発生していた。

課題①：ソフトウェアへFMEAを適用する単位は抽象的なアイテムになるため、ソフトウェアの「故障（求められる機能を遂行できない）」を発想する難易度が高い。
課題②：ソフトウェアは、システムの利用や運用状況を分析して製作されるため、アイテム（機能等）の特性に合わせた上位システムへの影響を分析する難易度が高い。

本発表では、分析フレームワークで技術者の思考を段階的に誘導し、GSN（Goal Structuring Notation）とESD（Event Sequence Diagram）のビューによるレビューを行う方法で解決を試みた結果を説明する。

紹介文 :
ベースソフトを部分的にしか理解できていない状況での作業が強いられる派生開発において、変更漏れに分類される欠陥の流出を防止することは重要な課題である。
組織の流出欠陥情報を分析し、派生開発で特定が漏れるソースコードの変更箇所には、次の3つのタイプがあることがわかった。

　A)変更仕様から直接特定可能な箇所
　B)ソースコードの変化点から直接影響を受ける箇所
　C)設計制約の変化から影響を受ける箇所

C)の「設計制約の変化から影響を受ける箇所」については、変更漏れを防止するための効果的な手法がなく、変更箇所特定漏れにより、欠陥が流出した。この問題は、ベースソフトの調査が、人の知識・経験に依存していることから起きる。

本研究では、「設計制約の変化から影響を受ける箇所」を漏れなく特定するために、ベースソフト調査手法を開発した。提案手法の技術要素として、「欠陥混入メカニズムの知識の表現方法」と「欠陥混入メカニズムの知識を活用したDRBFM実施手順」の2つを定義した。
実験により、提案手法を適用することで、過去に発生した変更箇所の特定漏れが再現しないことを確認した。本手法を実開発に適用することで、派生開発における変更漏れ確実に防止する効果が期待できる。

紹介文 :
我々の部門では昨年度より、開発プロジェクトの一部に、アジャイルプラクティスの導入を推進している。しかし、いくつかのプロジェクトは品質が安定せず、市場不具合が発生していた。そこで、市場不具合を起こしているプロジェクトの傾向を分析すると、バグの摘出がリリース直前に偏っていることが分かった。本発表では、従来ウォーターフォール開発で使われていた「欠陥摘出前倒し率」を、アジャイル開発のようなイテレーティブな開発にも適用可能に改良し、その有用性を検証したため、その取り組みを紹介する。
本取り組みの成果は以下の2点である。

1.「前倒し率」と市場不具合には有意な相関があり、メトリクスの有用性が確認できた。ただし、事例数が少なく、リリース後の経過時間も短いため、継続的な検証が必要である。
2.「前倒し率」は、欠陥をバグトラッキングシステムで管理していれば計算可能であり、メトリクス収集のための追加工数がほとんど必要ない。

紹介文 :
短納期型開発プロジェクトは要件定義・開発・テストが並行で実施されることが多く、以下の理由によりテスト工数の増加を招くという問題があった。

・仕様変更多発のために手順記述式テストの修正による手戻り工数が増える
・テスト実行スケジュールが開発完了のタイミングに左右されるため、計画通りのテストができない

そこで我々は問題解決のために、マインドマップによるテスト分析を活用した探索的テストを適用した。このテスト手法を「FaRSeT（Flexible and Rapid Software Test）／ファルセット」とチーム内で呼んでおり、2015年頃から段階的にブラッシュアップを重ね、多くのプロジェクト（主に短納期の業務系システム）に対して適用してきた。

FaRSeTは、以下の２つの要素から成り立つ。

1.仕様変更の影響を受けづらい業務要件の分析をマインドマップで行い、変更可能性の高いUI部分などは手順記述式テストを採用せずに探索的テストを活用する。
2.開発スケジュールの変更に対応するため、探索的テストマトリクスにて品質状況や実施優先度の可視化と共有を行うことによってテスト実施個所の関係者合意を行う

FaRSeTを短納期プロジェクトへ適用した場合の効果が得られたため、この手法及び効果を報告する。

紹介文 :
レビューを実施しても、重大欠陥の検出漏れは後を絶たない。検出漏れが発生する要因の一つとして、欠陥の検出難易度が高いことが挙げられる。検出難易度が高い欠陥とは、レビュー対象である成果物から記載すべき内容が抜け落ちている欠陥、将来の運用や保守性について考慮が漏れている欠陥が該当する。すなわち、検出難易度の高い欠陥は、成果物の記載内容のみをレビューしていては検出できない。

そこで我々は、作成者に掛かる認知バイアスに着目した。認知バイアスとは、人の思考を無意識に歪め、誘導するものである。作成者が認知バイアスに掛かることで、ヒューマンエラーが引き起こされる。その結果、成果物に必要な情報が記載されず、検出難易度の高い欠陥を混入してしまうのである。

本発表では、認知バイアスに着目したレビュー手法として、D2BOCs（Defect Detection from Background of Cognitive bias）法を提案する。D2BOCs法の特徴は以下の二つである。

1.認知バイアスを推測し、欠陥の傾向を特定する
2.高リスクの範囲を重点的にレビューする

効果検証により、重大欠陥・検出難易度の高い欠陥の検出にD2BOCs法が有効であることを確認できた。

紹介文 :
レビューの必要性と重要性については、既に、多くの論文や報告で指摘されている。しかし、納期との兼ね合い、人的リソースの逼迫などが障害となり、必ずしも実施されていない。本論文では、多岐にわたるレビュー項目の内でソフトウェア構造の問題点の発見を、AIを応用することで自動化が可能かどうかを試みた。具体的には、ソフトウェアの構造上の問題でバグが発生しそうなコードを機械学習により特定、そのコードに対する修正方法のヒントを、Fuzzy推論で開発に提示するシステムを構築した。このシステムの有効性等について報告する。

紹介文 :
システムの出荷後障害を分析したところ、運用を考慮した設計が不十分であることが原因で重大な障害を引き起こしていることが分かった。
運用を考慮した設計を行うためには、設計書レビューに運用の観点を取り入れることが重要と考える。
レビューに観点を取り入れるPerspective-Based Reading（PBR）を開発プロジェクトで実践できるようにするため、全国7拠点113名のエンジニアに対し、レビュー手法の演習教育を実施した。
当部門では、個人の経験に基づいたレビュー（Ad Hoc Reading：AHR）を行うプロジェクトが多い背景を踏まえて、教育ではPBRとAHRの違いを参加者が実感できるような工夫を行った。
また、AHRとPBRのレビュー結果から得られたPBRの有効性について報告する。

紹介文 :
「顧客に言われたとおりに製品を作ってリリースした結果、やり直しになった、あるいは、クレームがきた」という事象は日常的に発生しており、それにより大きなコストの無駄や手戻りが発生している。これは、顧客からすべての情報を引き出すことができず、市場のニーズや開発の背景といったシステム開発工程よりもさらに上流の情報についてを明らかにせず要求や仕様化したうえ、このような状態で作成された仕様書に対して、以下の手段でレビューしていることが原因なのではないかと考えている。

・自らの知識を頼りに、仕様に記載された内容のみをレビューしている。
・要求と仕様を比較するだけのレビューをしている。

その結果、必要な指摘が行われずにレビューを通過してしまうことで、顧客の事前期待や要望を満たしていないまま仕様を確定し、その仕様を実装した結果、このような事態になってしまうのではないだろうか。
我々はそのような状態で作成された仕様書でも、市場のニーズや開発の背景からレビューの観点を導き出し、その観点をもとに仕様書をレビューすることで、ユーザーの利用時や顧客の課題、解決したい問題に応える仕様とするための指摘を行えるのではないかと考え、“コンセプトベースでレビュー”と名付けた手法を実施して検証を行った。
本発表では、その手法の紹介と、検証結果について説明する。

紹介文 :
IoT時代における開発方法論は、セーフティだけやセキュリティだけを意識したものではいけない。例えば、セーフティの考え方では、可用性を重要視するため、機器連携をする際に、情報の機密性を保持できていないことがある。また、セキュリティの考え方では、機密性を重要視するため、利便性や機能性を損なう可能性がある。すなわち、これからIoT時代を迎えるにあたって、セーフティとセキュリティ、それぞれにバランスよく対応できる開発方法論が必要である。しかしながら、バランスよく対応できる開発方法論は確立されておらず、既存のセーフティにおける開発手法や、セキュリティにおける開発手法がどの程度バランスよく対応できる設計手法として使えるのか、検証もされていない。本稿では、セーフティの分野で実績のあるSTAMP/STPAを、セキュリティの分野とコラボレートさせた結果、その有効性を検証できたので、セーフティ＆セキュリティ開発のための方法論として提案する。 本発表では、新しい安全解析手法「STAMP/STPA」をセキュリティ適用し、さらに、STRIDEを脅威分析手法として適用したことによる成果を中心に述べる。

紹介文 :
Selenium等のミドルウェアが整備されたこともあり、WebアプリケーションのUIテストを自動化する事例も増えてきた。しかし、自動テストの開発資産が拡充されるのに比例し、その実行に要する 時間は増大する一方である。
主要なWebブラウザーはヘッドレスモードを搭載しているが、膨大なテストケースの前では「焼け石に水」。UIテストの所要時間を大幅に短縮するには、複数のPCにテストケースを分散するのが最 も効果的である。

そこで注目されるのがラズベリーパイである。インテルのプロセッサを搭載したPCに比べると、スペック的にはだいぶ見劣りするものの、テストクライアントとしての性能は十分である。足りていないのは、（CPUパワーではなく）クライアントの数だからである。
ラズベリーパイは、Ubuntuなどのディストリビューションが利用できるLinux PCである。Linuxのソフトウェア資産をそのまま継承できるため、Dockerコンテナを稼働させることも可能である。ラ ズベリーパイを8台、16台、32台とクラスタリングすることで、数世代前のスパコンに匹敵する計算能力を手にすることができる。

ラズベリーパイのクラスターでUIテストを並列実行するには、自動テストの開発資産についても根本的な見直しが必要になる。本発表では、クラスター構築のノウハウやUIテストを並列実行するための実践的なテクニックを紹介する。

紹介文 :
プロジェクトを遂行する上で、一番厄介なものは人間関係といえる。
プロジェクト内での衝突・言った言わない問題などに代表される人間が関わる問題・課題をできる限り事前に取り除き、プロジェクトの失敗をなくすことが理想である。
本稿では、上述の問題・課題としてコミュニケーションエラーに焦点を当て、解決へのアプローチを提案する。

問題・課題を解決するときには、様々なツールや手法から選択する必要がある。
エラー特性のモデル化、およびツール・手法のモデル化をすることにより、適用特性・場面によって モデルを選択し解決手段を効果的に使うことができる。このことにより、プロジェクトマネジメントの成熟度やチームの友好度が異なる組織においても、これから起こりうる問題・課題に対してモデルを事前に参照し対策を施すことにより、円滑にプロジェクト遂行を行いプロジェクトの失敗を防ぐことができると考える。
これにより、組織やプロジェクトを横断した共通の問題・課題などを解決するためのプラットフォームになるのではと考えた。

そのアプローチ方法として、マズローの欲求段階と TOC の抵抗の六階層を用いてモデル化したもの、およびツールや手法などによる解決手段を心理的障壁（エラー特性の各分類）ごとに分類したRPGモデル（仮）を提案する。

紹介文 :
ソフトウェアを短サイクルでリリースしフィードバックを受け改良を加えていくアジャイル開発プロセスを適用した開発では、スプリントで作り込んだ機能の利用者視点での評価は次のスプリントの期間に並行して行われ、そこで不具合が検出された場合にはさらに後続のスプリントで修正が行われている。このことにより、利用者にとって価値が高いソフトウェアのリリーススピードが期待したほど上がらないという問題があった。今回、ソフトウェアの利用時品質を定量的に表現した指標であるUXメトリクスという考え方を導入し、開発スプリントの開始時にUX評価シナリオを作成するとともに、シナリオに対してUXメトリクスの目標値を設定し、開発スプリント内で作り込んだ機能のUXを同一スプリント内で評価・フィードバックする技法を考案した。

本報告では、UXメトリクスを用いた開発スプリント内でのUXの作り込みの概要と、それを実際のソフトウェア開発プロジェクトの現場で適用した際の成果と知見を報告する。

紹介文 :
既存システムの改修を行う派生開発では、スクラッチ開発に較べて開発コスト、期間を低減できるメリットがある一方、無影響確認を含めた大規模なテストが必要となるが、開発側が作成したテストケースの妥当性を顧客側が判断する事は時間的にもスキル的にも難しいのが一般的である。

そこで我々は、開発工数見積りにおいては普及が進む第三者による検証をテストケース見積りに応用し、開発側が作成したテストケースと第三者が作成したテストケースを比較し検証する手法を考案した。

本発表では、本手法によりテストケースの網羅性を客観的に評価し適正なテスト計画とする事でテスト品質の向上に寄与できることを示す。 加えて、CRUD表からテストケースを自動生成する手法もあわせて発表する。

紹介文 :
ミッションクリティカルなお客様システムに対して、信頼性を中心とした非機能要件の充足性を向上させるために第三者検証を実施している。従来のシステム点検では、システムを構成するハードウェア、ソフトウェアの製品内部仕様や構造が把握できることを前提とし、製品内部の故障事象を始点とするホワイトボックステストにより、リカバリ設計の漏れが無いことを点検し、システム稼働前に障害を検出、対処を行ってきた。

しかしながら、近年のミッションクリティカルシステムはOSSを含めたマルチベンダー構成が主流となっており、構成する製品の内部仕様の全ては公開されていないことから、ホワイトボックステストは適用出来ず、ブラックボックステストによる点検のみとなる。ブラックボックステストの課題は、業務プロセスの無応答のような、外部仕様として表れない例外事象に対するリカバリ設計の不足、および設計漏れにより発生するトラブルを、システム稼働前の点検で検出、対処することが難しいことである。

この課題に対し、内部仕様が不明確なマルチベンダー構成システムの点検手法として、製品内部仕様として表れる故障事象に着目するのではなく、故障がシステムの業務処理に与える影響とその応答をモデル化し、モデル化した応答に対してシステムが備えるべきリカバリ設計を可視化する「フェールセーフ設計に対する点検手法」を開発した。その点検手法と適用結果について報告する。

紹介文 :
システム開発における仕様書や設計書は、制御された抽象度を保った厳密な記述により、開発対象が何であるのか、どう作るのかを明らかにする必要がある。また、開発者やテスト設計者などの後工程担当者の様々な関心事に応じて、参照・活用しやすい情報として整理されていることが望ましい。さらに、例えば機能仕様からテスト仕様を生成するなどの自動処理が実現できれば、開発を効率化することができる。そこで我々は、システム開発における基本設計書を対象としたテストケース一覧を自動生成するツールの検討を通して、設計書フォーマットの書きやすさや読みやすさ、テストケースへの自動変換、仕様記述の自由度について実験、考察した。

本論文では、仕様の構造化や、記述方法を制約するなどの試行錯誤をしていくアプローチを通して、特に、仕様の内容と記述に対する自由度を持たせる方法に関する議論をすることで、「制約を、自動化できる最小限にとどめ、仕様を記述するための自由度を残しつつ、後工程でもつかいやすい」基本設計書フォーマットを作成するためのアプローチを提案する。

紹介文 :
研究開発におけるソフトウェアプロダクトは、インキュベーションから商用にいたるまで幅広く、その種類も業務アプリケーション、メディア処理エンジン、OSS、ミドルウェアなど多種多様である。こうしたプロダクトの多様性が開発ベンダやリリース先の事業サイドとのトラブルの原因になることがある。例えば、開発主管が品質（非機能要件）の作りこみの程度を把握できていないために開発作業に過不足があり要求する品質を達成できない場合や、開発主管（研究所）が想定していない使い方を事業サイドがする場合である。このような問題を解決するために、利用条件を明確化し、どのような品質を念頭において開発をするかをあらかじめ計画することを徹底することが求められていた。

そこで、ソフトウェアプロダクトのリスクマネジメントを目的として開発標準を策定し、プロダクトの使われ方で分類した「品質クラス」の概念と、ISO/IEC 9126の品質特性を105の具体的な観点にブレークダウンした「品質確認表」を導入した。それにより、使われ方を意識した非機能要件設定とそれを具現化するための開発作業の具体的な取捨選択が可能になった。
さらに開発標準を中心に据えた(1)リスクマネジメント運用のルール化、(2)形骸化防止のためのモニタリングと第三者チェック、(3)実プロジェクトの開発文書の公開とe-learningによる自学自習、(4)集合知共有を目的とした統計データ公開を制度設計し、システム化を行った。

本発表ではその概要と効果について述べる。

紹介文 :
開発プロジェクトの終了時に「振り返り」を行い、次の開発プロジェクトへの教訓として「KPT（KEEP：良い点、PROBLEM：問題点、TRY：改善点）」を挙げている。
しかし、次の開発プロジェクトでKPTが十分実践されていないという問題がある。
本問題に対し、以下2つの原因があると考えた。
・振り返りが不十分で、KPTの内容に納得感がない。
・次の開発プロジェクトでの実践を、プロジェクト内メンバに任せている。

そこで、我々は「FOPA(*)振り返りプロセス」を作成し、「十分な振り返り実現による納得性向上」と「KPTの実践支援方法確立」を実現することで、これらの原因を対処した。

さらに、開発現場での実践を通じて「より手軽に振り返りを行い、かつKPTの実践支援を強化したい。」という意見を受け、「FOPA振り返りプロセス Ver.2」として改善し、プロセスの軽量化と支 援体制の強化を行った。

本発表では、「FOPA振り返りプロセス Ver.2」における、狙い、プロセス体系と内容、開発現場での効果検証結果、および今後のさらなる活用に向けた展望について述べる。


*FOPA: Full persuasive and Organized Process of retrospective with Aggressiveness の略
　（十分な納得性をもって 組織的な振り返りプロセスを 意思をもって積極的に行動する）

紹介文 :
ものづくりの観点である「製品品質」は、開発者にとっては当たり前の観点となっているため、SQuaREの品質モデルを知らなくてもレビュー時に使われていることが多い。
しかし、「製品品質」だけでは顧客の要求など顧客視点をカバーできず、ドキュメントレビューにおいて見落としが生じてしまう。
そこで、品質モデルの一つである「利用時の品質」をドキュメントレビューの観点に取り入れることでレビュー時の顧客視点の不足による見落としが減ると考え、「利用時の品質」観点に基づくドキュメントレビューのための教育カリキュラムを作成した。
カリキュラムは、「利用時の品質」を考慮し「利用時の品質」「製品品質」の関係性を理解してもらい、さらに、レビューの演習を実施し現場で活用できるレベルまで落とし込める内容とした。
我々の狙いは、「利用時の品質」「製品品質」をそれぞれ別の観点にするのではなく、「利用時の品質」の品質特性と関連の強い「製品品質」の品質特性を絞り込んで、顧客の利用目的に即したレビューを行うことである。
教育カリキュラムと演習用教材作成に取り組んだ内容を報告する。